IV Congresso Tecnolgico InfoBrasil Fortaleza, 26 a 29 de Abril de 2011

Confiabilidade nos Servios WEB: Um Estudo Sobre as Tcnicas de Tolerncia a Falhas

Jaguaraci Batista Silva, Marcus Vincios, Ranulfo Netto
Departamento de Computao Universidade Federal da Bahia, Salvador, BA
Os Servios Web tm se consolidado no mercado, como uma soluo para interoperabilidade entre sistemas. No ambiente internet, no qual esses servios esto inseridos, a garantia de confiabilidade pode ser obtida atravs de diferentes tcnicas. Nesse trabalho so apresentadas tcnicas de confiabilidade que atuam nas diferentes camadas de um servio web: provedor de servio, protocolo de transporte, SOAP e negcios. Index TermsWeb Service, Fault Tolerance, Dependability

I. INTRODUO

or algum tempo as organizaes viviam em mercado de poucas transformaes e pouca competitividade. Entretanto com a globalizao, essa realidade se desconfigurou drasticamente fazendo com que as mesmas buscassem meios de sobrevirem frente a um mercado cada vez mais competitivo, como as solues que automatizam seus fluxos de trabalhos, mantendo a flexibilidade exigida pelo mercado. As solues tecnolgicas foram revisadas e hoje existem propostas como a Arquitetura Orientada a Servios (SOA), em que aplicaes monolticas com limites bem definidos so substitudas por servios Web orquestrados. Garantir a confiabilidade nesse novo ambiente dinmico e hetogneo um desafio para a comunidade de software. Diversas abordagens so discutidas pela literatura especfica. Nesse trabalho so apresentadas algumas dessas tcnicas com base na proposta de (Erradi et al, 2005) para a garantia de confiabilidade nas diferentes camadas de um servio Web: provedor de servio, protocolo de transporte, SOAP e negcios. O trabalho possui a seguinte estrutura: a sesso 2 apresenta uma viso geral dos servios Web destacando os principais conceitos relacionados aos mesmos. Na terceira sesso so princpios de confiabilidade, caracterizando o uma falha e formas gerais de toler-las. Na quarta sesso so apresentadas tcnicas de confiabilidade em servios Web para cada camada. E por fim, a sesso 5 destina-se as consideraes obtidas sobre o trabalho. II. UMA VISO GERAL DOS SERVIOS WEB

Figura 1 Arquitetura dos servios Web (Coulouris, 2005 P. 785). As aplicaes, representadas na camada superior da Figura 4, acessam os servios Web descritos na linguagem WSDL (Web Services Description Language) (W3C, 2007), utilizando um servio de diretrio repositrio de informaes sobre os servios Web ou diretamente quando possui o conhecimento da sua URL (Uniform Resource Location). Os dados so empacotados usando o protocolo de troca de mensagens SOAP (Simple Object Access Protocol), possuindo as caractersticas de formatao da linguagem XML (Extended Markup Language) para representao dos dados. So enviados dos servidores Web, onde residem os servios, usando o protocolo HTTP para os clientes que os requisitam atravs de browsers (e. g. Internet Explorer, Netscape Navigator e Firefox), aplicaes que utilizam middlewares especficos (e.g. RMI, CORBA e .Net Remoting) ou outros servios Web. O protocolo SOAP surgiu como uma alternativa aos problemas causados pelo aumento do nmero de portas de comunicao usadas nas aplicaes distribudas e nos servios dos sistemas operacionais, devido a necessidade de se estabelecer uma comunicao entre os extremos usando um protocolo da camada de transporte (Tanenbaum, 1994, P. 443). Por questes de segurana das informaes internas, as empresas que expe os seus servios na Internet, utilizam um firewall software que controla as portas virtuais entre os extremos de uma comunicao. Pela configurao do firewall ser feita manualmente e a vasta gama de servios que fazem o uso de portas virtuais, muitos profissionais que administram as redes de computadores e as empresas so bastante criteriosos em permitir o acesso sua infraestrutura, ocasionando em um

Com o crescimento da utilizao da Internet, vrias empresas comearam a publicar servios e trocar informaes entre aplicaes na Web. A necessidade de uma padronizao motivou o surgimento de vrias tecnologias, entre elas, os servios Web. Os servios Web provem uma forma mais estruturada de comunicao entre os pontos finais de comunicao. Na Figura 1, possvel conhecer a sua arquitetura.

IV Congresso Tecnolgico InfoBrasil Fortaleza, 26 a 29 de Abril de 2011 retardo ou prejuzo para o consumidor desses servios. Com a utilizao do protocolo HTTP para o trfego de informaes, o SOAP facilitou o uso e a disseminao dos servios Web, pois as portas de comunicao do protocolo HTTP j esto configuradas para o acesso ao contedo de sites nas empresas. Uma empresa que deseja implementar um servidor para suportar os servios Web usando o protocolo SOAP, deve seguir a especificao do padro (W3C, 2007). A especificao contm informaes que definem: a forma em que o contedo das mensagens devero estar com a linguagem XML; padro de mensagens de requisio e resposta; as regras que o recipiente das mensagens deve seguir para processar o contedo XML; e como deve ser o protocolo de comunicao. Felizmente, existem atualmente inmeras APIs (Application Programming Interface) que facilitam a utilizao dos protocolos de comunicao, ocultando os detalhes durante a implementao (Couloris, 2005, P. 789). A Figura 2 ilustra como o funcionamento dos servios WEB.

evitado que o sistema apresente defeito. Define-se que um sistema est em estado errneo, ou em erro, se o processamento posterior a partir desse estado pode levar a um defeito. Finalmente, define-se falha ou falta (fault) como a causa fsica ou algortmica do erro (Weber, 2002). A confiabilidade dos servios WEB pode ser afetada por diversos fatores (e.g. performance, tolerncia a falhas dos endpoints, confiabilidade dos mecanismos usados para o transporte e acesso s mensagens). O objetivo de tolerncia a falhas alcanar dependabilidade. O termo dependabilidade uma traduo literal do termo ingls dependability, que indica a qualidade do servio fornecido por um dado sistema e a confiana depositada no servio fornecido (Weber, 2002). A definio do conceito de confiabilidade por (Avizienis et al, 2004) dada pela capacidade de entregar um servio que pode ser considerado confivel. Os atributos de tempo de disponibilidade, confiabilidade, segurana, integridade e manutenibilidade indicam a que grupos de mtricas e valores os servios podem ser medidos, comparados ou definidos para a garantia de sua confiabilidade. O atributo de disponibilidade define qual o tempo mximo de indisponibilidade de um servio e indicando formas alternativas de tolerar ou no a interrupo de um servio. A confiabilidade define as caractersticas de continuidade do servio correto. A segurana preocupa-se com as conseqncias desastrosas de um mau comportamento. A integridade com a ausncia de alteraes imprprias e a manuteno com a capacidade do servio sofrer modificaes e reparos. Em (Avizienis et al, 2004), so apresentadas tcnicas de preveno, remoo e tolerncia a falhas, a fim de implementar dependabilidade nos sistemas. A preveno a falhas pode ser utilizada para incluir um controle mais rigoroso durante a fase de anlise e projeto de software (Booch et al, 1999), estabelecendo um processo de construo de software com atividades que visam a identificao de falhas antes da sua implementao. A tcnica de remoo utiliza ferramentas de verificao, validao e diagnstico para reduzir o nmero de falhas durante a fase de implementao do software (Booch et al, 2005). Embora sejam utilizadas nas etapas iniciais e durante a implementao do software, essas tcnicas no oferecem garantia para um tratamento adequado a diversas falhas que podem acontecer, pois todos os componentes envolvidos durante a execuo do software tambm so passveis a erros (e.g. sistema operacional, banco de dados, middlewares, protocolos de transporte de mensagens). A tcnica de tolerncia a falhas visa a garantir a correta execuo do software mesmo quando h falhas, desse modo, assegurado ao cliente de um servio a sua continuidade atendendo aos requisitos exigidos. IV. TCNICAS DE CONFIABILIDADE EM SERVIOS WEB As tcnicas que visam a reduo e o tratamento de erros, apresentadas anteriormente podem ser aplicadas no processo de desenvolvimento dos servios WEB, entretanto, no o bastante para a garantia de confiabilidade (Erradi et al, 2005). Novas tcnicas precisam ser desenvolvidas para

Figura 2 Ciclo de vida do Web Service (Lopes e Ramalho, 2004, P. 4). O ciclo de vida de um Web Service constitudo de quatro estados: publicao, descoberta, descrio e invocao. A publicao um processo opcional, atravs do qual o fornecedor do Web Service torna pblica a existncia do seu servio, efetuando o seu registro no repositrio (e.g. UDDI). A descoberta um processo no qual uma aplicao cliente toma conhecimento da existncia do Web Service pretendido pesquisando em um repositrio UDDI. A descrio expe a sua API (e.g. documento WSDL), desta maneira, a aplicao cliente tem acesso a interface do Web Service, onde se encontram descritas todas as funcionalidades por ele disponibilizadas, assim como os tipos de mensagens que podem ser enviadas e recebidas atravs dessas funcionalidades. A invocao o processo pelo qual o cliente e servidor interagem atravs do envio de mensagens de requisio e de eventual recepo de mensagem de output. III. PRINCPIOS DE CONFIABILIDADE Um defeito (failure) definido como um desvio da especificao. Defeitos no podem ser tolerados, mas deve ser

IV Congresso Tecnolgico InfoBrasil Fortaleza, 26 a 29 de Abril de 2011 assegurar a confiabilidade em 4 nveis (Erradi et al, 2005): Provedor de servios, do protocolo de transporte, da camada SOAP e de negcios. No nvel do provedor de servio, a confiabilidade tem o foco no container que hospeda os servios WEB. Este pode utilizar tcnicas de tolerncia falhas (e.g. redundncia de servidores, load balance, clustering) para tratar problemas relacionados a disponibilidade dos servios. No nvel do protocolo de transporte so inmeras as pesquisas realizadas, a preocupao a garantia da entrega das mensagens, onde o HTTP o protocolo mais utilizado para este fim. Na camada de transporte de mensagens SOAP os requisitos de confiabilidade so baseados em padronizaes (e.g. W3C) para resolver diversas questes envolvendo: entrega ordenada de mensagens, eliminao de mensagens duplicadas, persistncia dos dados, regras governamentais para troca de informaes e a confirmao da entrega da mensagem ao destinatrio. No nvel da camada de negcios a composio de servios WEB uma questo prioritria, porm esta rea bastante nova e as pesquisas esto em fase de amadurecimento (Erradi et al, 2005). Na camada de protocolo, a replicao de dados uma abordagem amplamente utilizada para se garantir a confiabilidade de servios Web. Isto implica na implementao de um protocolo de consistncia de rplica, tambm chamado protocolo de replicao cujos duas principais representaes so: o de replicao ativa (AR) e o de replicao passiva (PR). A replicao ativa ocorre quando todas as rplicas processam concorrentemente todas as mensagens recebidas. E a replicao passiva ocorre quando somente uma rplica processa concorrentemente e, de tempos em tempos, envia seu estado atual para as outras rplicas do grupo de rplicas de um determinado agente, a fim de manter a consistncia. Na replicao ativa (AR), um sistema consiste de vrios sites chamados rplicas. Um cliente envia sua requisio para todas as rplicas que manipulam a requisio e mandam de volta a resposta ao cliente. Para se certificar que os estados das rplicas so consistentes, necessrio que o cdigo executado nas rplicas seja determinstico e que as requisies sejam enviadas s rplicas na mesma ordem. Para isso, aplica-se o algoritmo de ordenao total, no qual todas as requisies so entregues na mesma ordem, mesmo que os remetentes sejam diferentes. Primitivas de comunicao em grupo podem ser usadas para garantir a ordenao das requisies, no entanto, essas primitivas geram sobrecarga em funo do alto custo de sincronizao das rplicas (Xinfeng, 2007). Na replicao ativa do tipo otimista (OAR), um processo seqenciador envia periodicamente uma mensagem com a ordem das requisies (por exemplo, com nmeros seqenciais) para todas as rplicas com o objetivo de informlas a ordem de execuo das requisies. Ao receber uma requisio, a rplica aguarda o recebimento da mensagem de ordenao para ento processar a requisio. Uma vez que a rplica precisa aguardar a mensagem do seqenciador antes de processar as requisies, possvel obter um esquema com desempenho mais eficiente do que a replicao otimista (Xinfeng, 2007). Replicao baseada em marcas de tempo (TSR)

Uma tcnica bastante eficiente utiliza uma replicao baseada em marcas de tempo (TSR) par garantir que todas as rplicas executam as requisies dos clientes na mesma ordem (Xinfeng, 2007). Os resultados dos experimentos, segundo a pesquisa feita em (Xinfeng, 2007), demonstram que o TSR possui desempenho melhor que o OAR em sistemas nos quais os clientes raramente enviam requisies simultneas. Quando um Web service replicado, para assegurar a consistncia dos estados das rplicas, algumas operaes de sincronizao precisam ser levadas pelas rplicas quando as requisies dos clientes so processadas. Modificar o cdigo dos servios Web para incorporar operaes de sincronizao podem introduzir bugs nos sistemas e tambm torn-los menos flexvel. Desta forma, ao invs de modificar o cdigo dos servios Web, um middleware utilizado para gerenciar a replicao dos servios Web. Esse middleware faz uso do protocolo TSR para lidar com a sincronizao e assim garantir o estado das rplicas. Para o seu funcionamento, assume-se que: as rplicas se comunicam entre si atravs de canais FIFO confiveis; as rplicas falham por crash; as operaes disparadas pelas requisies dos clientes podem ser desfeitas. Um Web service replicado em vrios sites. Cada rplica consiste em um site proxy de Web service (PWSS - Proxy Web Service Site) e um site de Web service (WSS - Web Service site), sendo que o WSS um provedor de servios Web convencional. Ele prov cdigo e dados referentes funcionalidade disponibilizada pelo Web service. O PWSS reside entre o cliente e o WSS e responsvel por manter a consistncia da rplica, como pode ser visualizado na Figura 3. Os clientes interagem somente com o PWSS, s precisando enviar sua requisio a um nico PWSS que se encarrega de direcionar a requisio a todas as rplicas e ento retornar o resultado ao cliente.

Figura 3 Arquitetura do middleware para servios Web replicados (Xinfeng, 2007 P. 2). A utilizao da replicao ativa traz tona o problema da redundncia de invocaes aninhadas (RNI). Esse problema acontece quando servidores em um grupo replicado enviam requisies a outro grupo de servidores em funo da requisio de um cliente. Podemos ilustrar tal situao quando h invocao de um servidor B, a partir de um servidor A, em funo de uma requisio feita ao servidor A. O problema existe quando todas as rplicas de um grupo fazem a mesma

IV Congresso Tecnolgico InfoBrasil Fortaleza, 26 a 29 de Abril de 2011 invocao a outros servidores, fazendo com que haja vrios processamentos do outro lado. A OMG (RFP, 1998) defende a utilizao de um mecanismo de supresso (SM) de invocaes aninhadas redundantes em grupos replicados ativamente. O propsito de tal mecanismo garantir que apenas uma requisio aninhada seja encaminhada a outro servidor. Em outras palavras, esse mecanismo identifica todas as invocaes redundantes e as suprime, exceto uma, que ser encaminhada. Alm disso, esse mecanismo deve ser capaz de encaminhar a resposta a todas as rplicas do servidor que fez a invocao aninhada. Um mecanismo de supresso de invocaes aninhadas redundantes baseadas na identificao das requisies proposto (Fang et al, 2004) para resolver esse problema. Basicamente, a arquitetura do mecanismo proposto dividida em dois componentes principais: O notificador de invocaes aninhadas (NND) e o dispositivo de autosupresso de redundncia (RAD). O NND reponsvel por coletar informaes de cada invocao aninhada com o objetivo de criar uma estrutura de dados chamada de identificador de invocaes (IID). Ele anexa o IID ao cabealho da invocao. J o RAD identifica que as requisies so redundantes se os seus IID's so iguais. Uma vez recebida uma invocao pelo RAD, ele inspeciona o IID em busca de redundncia encaminhando apenas uma invocao ao servidor destino e devolvendo respostas os requisitantes. A garantia de entrega das mensagens um dos requisitos mais importantes quando se pensa em confiabilidade no mbito dos servios WEB. No tocante a camada de transporte de mensagens SOAP, duas especificaes esto competindo nesta rea: a WS-Reliability (WSR) e WS-Relability Message (WSRM). Nesta seo, ser feita uma anlise comparativa das duas especificaes em funo dos atributos de: funcionamento sobre o protocolo HTTP, agregao de requisitos no-funcionais, padres de troca de mensagens, grupo de mensagens, confirmao de recebimento de mensagens, correo de erros e retransmisso e os modos de entrega de mensagens suportados. Os sistemas que utilizam esse modelo de mensagens, baseado em um servio de publicao e subscrio (e. g. uma publicao e muitos subscritores), a mensagem ser enviada para um container e este ir imediatamente realizar um envio de uma cpia desta mensagem para todos os clientes que estiverem inscritos para receb-la. Funciona semelhante a um broadcast de mensagens de uma rede. Um dos pontos fracos deste tipo de sistema a alta latncia, uma vez que as mensagens so armazenadas antes de serem propagadas. As especificaes WSR e WSRM so baseadas em XML (W3C, 2007) e provem a entrega confivel de mensagens entre endpoints, permite a eliminao de mensagens duplicadas, ordenamento, agrupamento e confirmao de recebimento de mensagens, qualidade de servio e relatrios de diagnstico e falhas. Entretanto, o WSRM utiliza XML-Schema (W3C, 2007) para os elementos da mensagem SOAP que exigem aspectos de confiabilidade, incluindo o SOAP binding, enquanto o WSR, por outro lado, garante a confiabilidade das mensagens no nvel do protocolo SOAP e tambm oferece alguns recursos para o HTTP (e.g. binding, code, SOAP action) que podem ser usados para exibio de mensagens do

protocolo, inclusive falhas. A especificao WSR probe, explicitamente, a presena de qualquer SOAP intermediaries na sua implementao, isso implica que no possvel delegar qualquer operao para o protocolo SOAP (e.g. Logging) enquanto o WSRM no impede o uso desta estratgia. O WSR define vrios padres para troca de mensagens, os MEPs (Message Exchange Patterns). Os MPEs utilizam SOAP e viabilizam a troca de mensagens one-way e request-response, com isso, um subscritor pode enviar confirmaes ou avisar que houve falha no recebimento da mensagem. Os padres suportados so: response, callback e Poll. O WSRM no especifica qualquer MEPs. Nas duas especificaes, cada mensagem faz parte de um grupo, no WSR o grupo referenciado como group, enquanto no WSRM chamado de sequence. As mensagens tm um nmero de identificao e este incrementado quando da ocorrncia de novas mensagens. No WSR, este nmero chamado de sequence number e no WSRM de message number. Os nmeros de seqncia so combinados com a identificao do grupo e possuem a facilidade de verificar qual a ltima mensagem enviada para os subscritores dentro do grupo. Uma mensagem pode ser publicada sem o sequence number ser inicializado no WSR, o que pode resultar na ocorrncia de mensagens duplicadas, o que no ocorre no WSRM (Pallickara et al, 2005). A simples presena de uma nova mensagem garante a criao de novo grupo, podendo gerar desta forma, problemas de coliso, pois do lado dos subscritores a informao de identificao do grupo no atualizada no WSR, pela ausncia de uma poltica de atualizao do identificador do grupo, o que no ocorre no WSRM. As regras para finalizar um grupo so baseadas no tempo de expirao do envio da mensagem, quando todas as mensagens forem entregues, se um nmero de seqncia excede o mximo de 18.446.744.073.709.551.615 ou h falha na entrega ordenada de mensagens. No WSRM, quando a ltima mensagem enviada, o subscritor recebe uma mensagem de controle para confirmar o recebimento de todas as mensagens, o WSR no mantm qualquer mecanismo explcito para tal funcionalidade. As retransmisses de mensagens quando ocorre qualquer tipo de falha no recebimento ou correo de erro, sempre iniciada do lado do servidor no caso do WSR, pois este no suporta confirmao negativa de envio (Negative Acknowledgements) e as tentativas de retransmisso so feitas at um limite pr-configurado. O WSRM alm de incorporar a tcnica de confirmao negativa de envio, resultando em pedidos de retransmisso do lado do subscritor, possui as polticas de retransmisso baseada em um intervalo como no WSR e no exponencial backoff (Tanenbaum, 1994, P. 250). Os modos de operao para a entrega de mensagens suportados no WSR so os mesmos no WSRM (e.g. noconfiveis, ao menos uma mensagem, ordenada, exatamente uma mensagem), porm, no WSRM podem ser feitas configuraes para deteco de mensagens duplicadas, entrega confivel e ordenamento de mensagens independentes dos modos de operao suportados (Pallickara et al, 2005). Uma vez que as organizaes disponibilizam servios Web torna-se necessrio o estabelecimento de diretrizes para garantia de confiabilidade na cooperao entre esses servios.

IV Congresso Tecnolgico InfoBrasil Fortaleza, 26 a 29 de Abril de 2011 A camada de negcios visa fornecer confiabilidade na composio de servios Web atravs de diferentes abordagens. As pesquisas para garantia de confiabilidade nessa camada so extensas, algumas propostas envolvendo protocolos transacionais so tratadas em (Erradi, 2005). Uma transao, quer em um ambiente centralizado ou distribudo, caracterizada pelas propriedades Atomicidade, Consistncia, Isolamento, Durabilidade (ACID). A propriedade Atomicidade trata o trabalho como parte indivisivel, o que implica que todas as operaes efetuadas durante uma transao sero efetivadas em caso de sucesso e em caso de falha em alguma dessas operaes, todas sero canceladas. J na Consistncia, as regras de integridade so asseguradas. O Isolamento define que o resultado de uma transao executada concorrentemente a outra deve ser o mesmo que o de sua execuo de forma isolada. E por fim, a Durabilidade define que os efeitos de uma transao em caso de sucesso (commit) so permanentes mesmo em presena de falhas (Chapple, 2007). As transaes distribudas consistem em um dos conceitos fundamentais para garantia de confiabilidade para os Web Services. Entretanto, eles necessitam de um mecanismo flexvel e extensvel para troca de mensagens entre servios, em comparao aos mecanismos do modelo transacional dos bancos de dados, levando-se em considerao atividades de longa durao e suporte a colaboraes entre aplicaes corporativas. A abordagem orientada a processos aplica o comportamento transacional necessrio as aplicaes ao longo do processo mapeado na composio de servios (Portilla et al, 2006). As seguintes propostas sero descritas: Web Services Transactions (IBM, 2005) e Business Transactional protocol (BTP). O consrcio envolvendo as 3 empresas BEA, IBM e Microsoft propuseram trs especificaes para aplicao de transaes distribudas, no contexto de Web Services: WSCoordination, WS-AtomicTransation (WS-AT) e WSBusinessTransaction (WS-BT) (IBM, 2005). O WSCoordination um framework extensvel para fornecer protocolos que coordene aes em aplicaes distribudas, como as transaes que necessitam de um acordo consistente sobre o resultado das atividades distribudas. Contempla-se nesse framework a definio da estrutura de um contexto, para a propagao de informaes aos participantes de uma atividade, e os requisitos para propagao do contexto entre os servios que cooperam entre si, alm de incluir: um coordenador genrico, participantes e o protocolo de coordenao. O primeiro atuando como um mediador entre os participantes e o ltimo definindo principalmente as mensagens que podem ser trocadas entre o coordenador e os participantes (Cabrera, 2005a). A especificao WS-AT uma extenso do WSCoordination que fornece a definio de coordenao para transaes atmicas. Essa especificao utiliza duas variaes do protocolo Two-Phase-Commit (2PC) para que os participantes cheguem a um consenso sobre o desfecho de uma transao distribuda: 2PC durvel, participantes cujos recursos transacionais so durveis banco de dados, e voltil, participantes cujos recursos transacionais so volteis cache. (Cabrera, 2005b). No cenrio para composio de servios a caracterstica interinstitucional torna muitas vezes inivivel a utilizao do WS-AT, pois as organizaoes no permitiriam

que fossem aplicadas travas em seus recursos, alm de que o tempo de execuo de cada atividade nem sempre curto, na ordem de milisegundos(eg. autorizao bancria). Aplicar travas em atividades longas (eg. enviar uma fatura) pode ser muitas vezes invivel pois caso um roolback seja necessrio o custo ser alto para execuo de tal processamento. Para esse tipo de situao existe a WS-BT que tambm uma extenso do WS-Coordination que fornece a definio de coordenao para transaes distribudas de longas durao. Essa especificao permite que caso ocorra alguma falha durante a execuo da transao, operaes de compensao so executadas para compensar uma falha (Cabrera, 2005c). O Comit Tcnico da OASIS, Business Transactions, concentra-se no desenvolvimento de tecnologias para transaes de negcios pela Internet. Esse comit props o OASIS BTP (Business Transaction Protocol) que um protocolo para processos de longa durao (OASIS, 2007). Para tal o BTP prope transaes distribudas com um enfraquecimento das garantias transacionais (propriedades ACID) atravs de dois tipos de transaes: transaes atmicas e transaes coesivas. Na primeira o resultado do trabalho como um todo ser confirmado ou cancelado, com um relaxamento da propriedade de isolamento, na segunda alm do relaxamento da propriedade de isolamento prope o semi-atmico em que alguns participantes efetivam e outros podero cancelar baseados em regras de negcios prdefinidas (Portilla et al, 2006). O protocolo permite ainda a interveno da aplicao na definio do que poder ser confirmado e definio de abordagens para reverter os efeitos de uma transao (eg. compensao) (Degan, 2005). WS Transactions e BTP so dois frameworks para adicionar comportamento transacional aos servios Web. WS-TX oferece um framework extensvel especfico para Web Services, j o BTP oferece um framework genrico para aplicaes baseadas em servios . Alm desses servios a literatura especfica dispe de outras especificaes, sendo necessrio um levantamento atravs de um estudo comparativo entre as solues disponveis para identificar qual desses mais adequado ao ambiente dinmico e heterogneo em que os servios Web encontram-se (Portilla et al, 2006). V. CONCLUSO Com o crescimento da utilizao da Internet, vrias empresas comearam a publicar servios e trocar informaes entre aplicaes na Web. A necessidade de uma padronizao motivou o surgimento de vrias tecnologias, entre elas, os servios Web. Com o aumento da utilizao dos servios Web como um padro de trocas de mensagens entre grandes empresas, surgiu tambm a preocupao com a confiabilidade desses servios. Neste trabalho, foram mostradas novas tcnicas que precisam ser desenvolvidas para assegurar a confiabilidade nos nveis do provedor de servios, no protocolo de transporte de mensagens e nas camadas SOAP e de negcios. As tcnicas apresentadas no substituem as tcnicas tradicionais para garantia de confiabilidade, porm agregam novas solues devido s especificidades encontradas nos servios Web. O conhecimento dessas tcnicas relevante, entretanto, a implementao das mesmas tem um certo custo associado. Portanto, torna-se indispensvel, que os

IV Congresso Tecnolgico InfoBrasil Fortaleza, 26 a 29 de Abril de 2011 fornecedores de servios web ponderem a relao custo benefcio para cada caso em particular e determine quais as melhores tcnicas para garantia da confiabilidade necessria para o projeto. Apesar de existirem diversos trabalhos relacionados com servios web, essa rea mostra-se ainda incipiente, mesmo porque o protocolo SOAP foi proposto em 1998. A prpria W3C ainda no definiu os padres para confiabilidade nos servios web. As propostas apresentadas nesse artigo esto sendo analisadas pelo consrcio. REFERENCES
[1] Avisienis, A., Laprie, J.C., Randell, B., Landwehr, C.. (2004) Basic Concepts and Taxonomy of Dependable and Secure Computing, IEEE Transactions on Dependable and Secure Computing, Vol 1, No 1, Janeiro. Booch, G., Jacobson, I., Rumbaugh, J (1999). Unified Modeling Language Users Guide. Addison-Wesley, ISBN 0201571684. Cabrera, LF, et al. (2005). Web Services Coordination (WSCoordination). Specification, gosto 2005. http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/wstx/WS-Coordination.pdf. Dezembro. Cabrera, LF, et al.(2005) Web Services Atomic Transaction (WSAtomicTransaction). Specification.http://download.boulder.ibm.com/ibmdl/pub/software/dw /specs/ws-tx/WS-AtomicTransaction.pdf. Dezembro. Cabrera, LF, et al. (2005) Web Services Business Activity Framework (WS-BusinessActivity), http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/wstx/WS-BusinessActivity.pdf. Dezembro. Chapple, Mike (2007). The ACID Model. Disponvel em http://databases.about.com/od/specificproducts/a/acid.htm. Dezembro. Couloris, G., Dollimore, J., Kindberg, T.. (2005) "Distributed Systems concepts and Design". Addison Wesley, 4 Edio, ISBN 0321263545. Degan, Joyce.( 2005). Integrao de dados corporativos: uma proposta de arquitetura baseada em servios de dados. Universidade Estadual de CAMPINAS SP - Mestrado Profissional em Computao. Dezembro. Erradi, A., Maheshwari, P.. (2005) A Broker-Based Approach for Improving Web Services Reliability. IEEE Internacional Coference on Web Services (ICWS05) Procedings. Fang, Chen-Liang, et al. (2004) " A Redundant Nested Invocation Suppression Mechanism for Active Replication Fault-Tolerant Web Service". Proceedings of the 2004 IEEE Internacional Conference on eTechnology, e-Commerce and e-Service (EEE04). Freund, Tom, Storey, Tony. (2002) Transactions in the world of web services, part 2. IBM, developerWorks, http://www.ibm.com/developerworks/library/ws-wstx2/. Dezembro. IBM, (2005). Web Services Transactions specifications. http://www.ibm.com/developerworks/library/specification/ws-tx/ Dezembro. Lopes, C. J.F., Ramalho, J. C.. (2004) Web Services: Metodologias de Desenvolvimento. XATA (XML, Aplicaes e Tecnologias Relacionadas) 2004, Porto-Portugal, Fevereiro. Pallickara, S., Fox, G., Pallickara, S. L.. (2005) An Analysis of Reliable Delivery Specification for Web Services. IEEE Internacional Conference on Informations Technology: Coding and Computing (ITCC05) Procedings. Portilla, G Vargas-Solar, JL Zechinelli-Martini (2006). A survey for analyzing transactional behavior in service based applications. Computer Science, 2006. ENC '06. Seventh Mexican International Conference on. Disponvel em < http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4020870 > Tanenbaum, A. S.. (1994) "Redes de computadores". Editora Campus, 2 Edio, ISBN 8570018800. W3C. World Wide Web Consortium (2007). OWL Web Ontology Language Guide. http://www.w3.org/TR/owl-guide/. Dezembro. Weber, T.S.. (2007) Um Roteiro para Explorao dos Conceitos Bsicos de Tolerncia a Falhas, Instituto de Informtica UFRGS, Especializao em Sistemas Distribudos. www.inf.ufrgs.br/~taisy/disciplinas/textos/indiceroteiro.htm. Dezembro.

[19] Xinfeng, Ye. "Providind Reliable Web Services through Active Replication". 6th IEEE/ACIS Internacional Coference on Computer and Information Science (ICIS 2007). [20] RFP.Object Management Group, Fault tolerant CORBA using entity redundancy: Request for proposal. OMG Technical Committee Document orbos/98-04-01, Abril 1998.

[2] [3]

[4]

[5]

[6] [7] [8] [9] [10]

[11] [12] [13] [14]

[15]

[16] [17] [18]