Confiabilidade nos serviços WEB: Um estudo sobre as

técnicas para implementação de dependabilidade

Jaguaraci Batista Silva, Marcus Vinícius, Ranulfo Netto

Departamento de Computação – Universidade Federal da Bahia (UFBA)

Av. Adhemar de Barros s/n, Ondina – Salvador – BA – Brazil
jaguarac@ufba.br, marcusvas@gmail.com, rcnetto@gmail.com

Resumo. Os Serviços Web têm se consolidado no mercado, como uma solução

para interoperabilidade entre sistemas. No ambiente internet, no qual os serviços
web estão inseridos, a garantia de confiabilidade pode ser obtida através de
diferentes técnicas. Nesse trabalho são apresentadas técnicas de confiabilidade
que atuam nas diferentes camadas de um serviço web: provedor de serviço,
protocolo de transporte, SOAP e negócios.

1. Introdução

Por algum tempo as organizações viviam em mercado de poucas transformações e pouca

competitividade. Entretanto com a globalização, essa realidade se desconfigurou
drasticamente fazendo com que as mesmas buscassem meios de sobrevirem frente a um
mercado cada vez mais competitivo, como as soluções que automatizam seus fluxos de
trabalhos, mantendo a flexibilidade exigida pelo mercado.
As soluções tecnológicas foram revisadas e hoje existem propostas como na
Arquitetura Orientada a Serviços (SOA), em que aplicações monolíticas com limites bem
definidos são substituídas pelo conceito de aplicações compostas por serviços
coreografados.
Garantir a confiabilidade nesse novo ambiente dinâmico e hetogêneo é um desafio para
a comunidade de software. Diversas abordagens são discutidas pela literatura específica.
Nesse trabalho são apresentadas algumas dessas técnicas de confiabilidade para serviços
web utilizando a definição proposta por Erradi et al (2005) para garantia de confiabilidade
nas diferentes camadas de um serviço web: provedor de serviço, protocolo de transporte,
SOAP e negócios.
O trabalho possui a seguinte estrutura: a sessão 2 apresenta uma visão geral dos
serviços web destacando os principais conceitos relacionados aos mesmos. Na terceira
sessão são princípios de confiabilidade, caracterizando o uma falha e formas gerais de
tolerá-las. No quarta sessão são apresentadas técnicas de confiabilidade em serviços web
para cada camada. E por fim, a sessão 5 destina-se as considerações obtidas sobre o
trabalho.

2. Uma visão geral dos serviços WEB

Com o crescimento da utilização da Internet, várias empresas começaram a publicar
serviços e trocar informações entre aplicações na Web. A necessidade de uma padronização
motivou o surgimento de várias tecnologias, entre elas, os serviços Web. Os serviços Web
provêem uma forma mais estruturada de comunicação entre os pontos finais de
comunicação. Na Figura 1, é possível conhecer a sua arquitetura.

Figura 1 – Arquitetura dos serviços Web (Coulouris, 2005 P. 785).

As aplicações, representadas na camada superior da Figura 4, acessam os serviços
Web descritos na linguagem WSDL (Web Services Description Language) (W3C, 2007),
utilizando um serviço de diretório – repositório de informações sobre os serviços Web – ou
diretamente quando possui o conhecimento da sua URL (Uniform Resource Location). Os
dados são empacotados usando o protocolo de troca de mensagens SOAP (Simple Object
Access Protocol), possuindo as características de formatação da linguagem XML (Extended
Markup Language) para representação dos dados. São enviados dos servidores Web, onde
residem os serviços, usando o protocolo HTTP para os clientes que os requisitam através de
browsers (e. g. Internet Explorer, Netscape Navigator e Firefox), aplicações que utilizam
middlewares específicos (e.g. RMI, CORBA e .Net Remoting) ou outros serviços Web.
O protocolo SOAP surgiu como uma alternativa aos problemas causados pelo
aumento do número de portas de comunicação usadas nas aplicações distribuídas e nos
serviços dos sistemas operacionais, devido a necessidade de se estabelecer uma
comunicação entre os extremos usando um protocolo da camada de transporte (Tanenbaum,
1994, P. 443). Por questões de segurança das informações internas, as empresas que expõe
os seus serviços na Internet, utilizam um firewall – software que controla as portas virtuais
entre os extremos de uma comunicação. Pela configuração do firewall ser feita
manualmente e a vasta gama de serviços que fazem o uso de portas virtuais, muitos
profissionais que administram as redes de computadores e as empresas são bastante
criteriosos em permitir o acesso á sua infraestrutura, ocasionando em um retardo ou
prejuízo para o consumidor desses serviços. Com a utilização do protocolo HTTP para o
tráfego de informações, o SOAP facilitou o uso e a disseminação dos serviços Web, pois as
portas de comunicação do protocolo HTTP já estão configuradas para o acesso ao conteúdo
de sites nas empresas.
Uma empresa que deseja implementar um servidor para suportar os serviços Web
usando o protocolo SOAP, deve seguir a especificação do padrão (W3C, 2007). A
especificação contém informações que definem: a forma em que o conteúdo das mensagens
deverão estar com a linguagem XML; padrão de mensagens de requisição e resposta; as
regras que o recipiente das mensagens deve seguir para processar o conteúdo XML; e como
deve ser o protocolo de comunicação. Felizmente, existem atualmente inúmeras APIs
(Application Programming Interface) que facilitam a utilização dos protocolos de
comunicação, ocultando os detalhes durante a implementação (Couloris, 2005, P. 789). A
Figura 2 ilustra como é o funcionamento dos serviços WEB.

Figura 2 – Ciclo de vida do Web Service (Lopes e Ramalho, 2004, P. 4).

O ciclo de vida de um Web Service é constituído de quatro estados: publicação,
descoberta, descrição e invocação. A publicação é um processo opcional, através do qual o
fornecedor do Web Service torna pública a existência do seu serviço, efetuando o seu
registro no repositório (e.g. UDDI). A descoberta é um processo no qual uma aplicação
cliente toma conhecimento da existência do Web Service pretendido pesquisando em um
repositório UDDI. A descrição expõe a sua API (e.g. documento WSDL), desta maneira, a
aplicação 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 através dessas funcionalidades. A invocação é o processo pelo qual
o cliente e servidor interagem através do envio de mensagens de requisição e de eventual
recepção de mensagem de output.

3. Princípios de confiabilidade
Um defeito (failure) é definido como um desvio da especificação. Defeitos não podem ser
tolerados, mas deve ser evitado que o sistema apresente defeito. Define-se que um sistema
está em estado errôneo, 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 física ou
algorítmica do erro (Weber, 2002). A confiabilidade dos serviços WEB pode ser afetada
por diversos fatores (e.g. performance, tolerância a falhas dos end-points, confiabilidade
dos mecanismos usados para o transporte e acesso ás mensagens). O objetivo de tolerância
a falhas é alcançar dependabilidade. O termo dependabilidade é uma tradução literal do
termo inglês dependability, que indica a qualidade do serviço fornecido por um dado
sistema e a confiança depositada no serviço fornecido (Weber, 2002).
A definição do conceito de confiabilidade por (Avizienis et al, 2004) é dada pela
capacidade de entregar um serviço que pode ser considerado confiável. Os atributos de
tempo de disponibilidade, confiabilidade, segurança, integridade e manutenibilidade
indicam a que grupos de métricas e valores os serviços podem ser medidos, comparados ou
definidos para a garantia de sua confiabilidade. O atributo de disponibilidade define qual o
tempo máximo de indisponibilidade de um serviço e indicando formas alternativas de
tolerar ou não a interrupção de um serviço. A confiabilidade define as características de
continuidade do serviço correto. A segurança preocupa-se com as conseqüências
desastrosas de um mau comportamento. A integridade com a ausência de alterações
impróprias e a manutenção com a capacidade do serviço sofrer modificações e reparos.
Em (Avizienis et al), são apresentadas técnicas de prevenção, remoção e tolerância
a falhas, a fim de implementar dependabilidade nos sistemas. A prevenção a falhas pode
ser utilizada para incluir um controle mais rigoroso durante a fase de análise e projeto de
software (Booch et al, 1999), estabelecendo um processo de construção de software com
atividades que visam a identificação de falhas antes da sua implementação. A técnica de
remoção utiliza ferramentas de verificação, validação e diagnóstico para reduzir o número
de falhas durante a fase de implementação do software (Booch et al, 2005). Embora sejam
utilizadas nas etapas iniciais e durante a implementação do software, essas técnicas não
oferecem garantia para um tratamento adequado a diversas falhas que podem acontecer,
pois todos os componentes envolvidos durante a execução do software também são
passíveis a erros (e.g. sistema operacional, banco de dados, middlewares, protocolos de
transporte de mensagens). A técnica de tolerância a falhas visa a garantir a correta execução
do software mesmo quando há falhas, desse modo, é assegurado ao cliente de um serviço a
sua continuidade atendendo aos requisitos exigidos.

4. Técnicas de confiabilidade em Serviços Web

As técnicas que visam a redução e o tratamento de erros, apresentadas anteriormente
podem ser aplicadas no processo de desenvolvimento dos serviços WEB, entretanto, não é
o bastante para a garantia de confiabilidade (Erradi et al, 2005). Novas técnicas precisam
ser desenvolvidas para assegurar a confiabilidade em 4 níveis (Erradi et al, 2005): Provedor
de serviços, do protocolo de transporte, da camada SOAP e de negócios. No nível do
provedor de serviço, a confiabilidade tem o foco no container que hospeda os serviços
WEB. Este pode utilizar técnicas de tolerância á falhas (e.g. redundância de servidores,
load balance, clustering) para tratar problemas relacionados a disponibilidade dos serviços.
No nível do protocolo de transporte são inúmeras as pesquisas realizadas, a preocupação é 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 são baseados
em padronizações (e.g. W3C) para resolver diversas questões envolvendo: entrega
ordenada de mensagens, eliminação de mensagens duplicadas, persistência dos dados,
regras governamentais para troca de informações e a confirmação da entrega da mensagem
ao destinatário. No nível da camada de negócios a composição de serviços WEB é uma
questão prioritária, porém esta área é bastante nova e as pesquisas estão em fase de
amadurecimento (Erradi et al, 2005).
4.1 Protocolo de transporte
Na camada de protocolo, a replicação de dados é uma abordagem amplamente utilizada
para se garantir a confiabilidade de serviços web. Isto implica na implementação de um
protocolo de consistência de réplica, também chamado protocolo de replicação cujos duas
principais representações são: o de replicação ativa (AR) e o de replicação passiva (PR). A
replicação ativa ocorre quando todas as réplicas processam concorrentemente todas as
mensagens recebidas. E a replicação passiva ocorre quando somente uma réplica processa
concorrentemente e, de tempos em tempos, envia seu estado atual para as outras réplicas do
grupo de réplicas de um determinado agente, a fim de manter a consistência.
Na replicação ativa (AR), um sistema consiste de vários sites chamados réplicas.
Um cliente envia sua requisição para todas as réplicas que manipulam a requisição e
mandam de volta a resposta ao cliente. Para se certificar que os estados das réplicas são
consistentes, é necessário que o código executado nas réplicas seja determinístico e que as
requisições sejam enviadas às réplicas na mesma ordem. Para isso, aplica-se o algoritmo de
ordenação total, no qual todas as requisições são entregues na mesma ordem, mesmo que os
remetentes sejam diferentes. Primitivas de comunicação em grupo podem ser usadas para
garantir a ordenação das requisições, no entanto, essas primitivas geram sobrecarga em
função do alto custo de sincronização das réplicas (Xinfeng, 2007).
Na replicação ativa do tipo otimista (OAR), um processo seqüenciador envia
periodicamente uma mensagem com a ordem das requisições (por exemplo, com números
seqüenciais) para todas as réplicas com o objetivo de informá-las a ordem de execução das
requisições. Ao receber uma requisição, a réplica aguarda o recebimento da mensagem de
ordenação para então processar a requisição. Uma vez que a réplica precisa aguardar a
mensagem do seqüenciador antes de processar as requisições, é possível obter um esquema
com desempenho mais eficiente do que a replicação otimista (Xinfeng, 2007).

4.1.1 Replicação baseada em marcas de tempo (TSR)

Uma técnica bastante eficiente utiliza uma replicação baseada em marcas de tempo (TSR)
par garantir que todas as réplicas executam as requisições dos clientes na mesma ordem
(Xinfeng, 2007). Os resultados dos experimentos demonstram que o TSR possui
desempenho melhor que o OAR em sistemas nos quais os clientes raramente enviam
requisições simultâneas.
Quando um web service é replicado, para assegurar a consistência dos estados das
réplicas, algumas operações de sincronização precisam ser levadas pelas réplicas quando as
requisições dos clientes são processadas. Modificar o código dos serviços web para
incorporar operações de sincronização podem introduzir bugs nos sistemas e também torná-
los menos flexível. Desta forma, ao invés de modificar o código dos serviços web, um
middleware é utilizado para gerenciar a replicação dos serviços web. Esse middleware faz
uso do protocolo TSR para lidar com a sincronização e assim garantir o estado das réplicas.
Para o seu funcionamento, assume-se que: as réplicas se comunicam entre si através
de canais FIFO confiáveis; as réplicas falham por crash; as operações disparadas pelas
requisições dos clientes podem ser desfeitas.
Um web service é replicado em vários sites. Cada réplica 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 serviços web convencional. Ele provê código e
dados referentes à funcionalidade disponibilizada pelo web service. O PWSS reside entre o
cliente e o WSS e é responsável por manter a consistência da réplica, como pode ser
visualizado na Figura 3. Os clientes interagem somente com o PWSS, só precisando enviar
sua requisição a um único PWSS que se encarrega de direcionar a requisição a todas as
réplicas e então retornar o resultado ao cliente.

Figura 3 – Arquitetura do middleware para serviços web replicados (Xinfeng, 2007 P. 2).

4.1.2 Mecanismo de supressão de invocações aninhadas redundantes

A utilização da replicação ativa traz à tona o problema da redundância de invocações

aninhadas (RNI). Esse problema acontece quando servidores em um grupo replicado
enviam requisições a outro grupo de servidores em função da requisição de um cliente.
Podemos ilustrar tal situação quando há invocação de um servidor B, a partir de um
servidor A, em função de uma requisição feita ao servidor A. O problema existe quando
todas as réplicas de um grupo fazem a mesma invocação a outros servidores, fazendo com
que haja vários processamentos do outro lado.
A OMG (RFP, 1998) defende a utilização de um mecanismo de supressão (SM) de
invocações aninhadas redundantes em grupos replicados ativamente. O propósito de tal
mecanismo é garantir que apenas uma requisição aninhada seja encaminhada a outro
servidor. Em outras palavras, esse mecanismo identifica todas as invocações redundantes e
as suprime, exceto uma, que será encaminhada. Além disso, esse mecanismo deve ser capaz
de encaminhar a resposta a todas as réplicas do servidor que fez a invocação aninhada.
Um mecanismo de supressão de invocações aninhadas redundantes baseadas na
identificação das requisições é proposto (Fang et al, 2004) para resolver esse problema.
Basicamente, a arquitetura do mecanismo proposto é dividida em dois componentes
principais: O notificador de invocações aninhadas (NND) e o dispositivo de auto-supressão
de redundância (RAD). O NND é reponsável por coletar informações de cada invocação
aninhada com o objetivo de criar uma estrutura de dados chamada de identificador de
invocações (IID). Ele anexa o IID ao cabeçalho da invocação. Já o RAD identifica que as
requisições são redundantes se os seus IID's são iguais. Uma vez recebida uma invocação
pelo RAD, ele inspeciona o IID em busca de redundância encaminhando apenas uma
invocação ao servidor destino e devolvendo respostas os requisitantes.
4.2 Camada SOAP
A garantia de entrega das mensagens é um dos requisitos mais importantes quando se pensa
em confiabilidade no âmbito dos serviços WEB. No tocante a camada de transporte de
mensagens SOAP, duas especificações estão competindo nesta área: a WS-Reliability
(WSR) e WS-Relability Message (WSRM). Nesta seção, será feita uma análise comparativa
das duas especificações em função dos atributos de: funcionamento sobre o protocolo
HTTP, agregação de requisitos não-funcionais, padrões de troca de mensagens, grupo de
mensagens, confirmação de recebimento de mensagens, correção de erros e retransmissão e
os modos de entrega de mensagens suportados.
Os sistemas que utilizam esse modelo de mensagens, é baseado em um serviço de
publicação e subscrição (e. g. uma publicação e muitos subscritores), a mensagem será
enviada para um container e este irá imediatamente realizar um envio de uma cópia 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 latência, uma vez que as mensagens são armazenadas antes de serem
propagadas.
As especificações WSR e WSRM são baseadas em XML (W3C, 2007) e provêem a
entrega confiável de mensagens entre endpoints, permite a eliminação de mensagens
duplicadas, ordenamento, agrupamento e confirmação de recebimento de mensagens,
qualidade de serviço e relatórios de diagnóstico 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 nível do protocolo SOAP e também oferece alguns
recursos para o HTTP (e.g. binding, code, SOAP action) que podem ser usados para
exibição de mensagens do protocolo, inclusive falhas.
A especificação WSR proíbe, explicitamente, a presença de qualquer SOAP
intermediaries na sua implementação, isso implica que não é possível delegar qualquer
operação para o protocolo SOAP (e.g. Logging) enquanto o WSRM não impede o uso desta
estratégia. O WSR define vários padrões 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 confirmações ou avisar que houve
falha no recebimento da mensagem. Os padrões suportados são: response, callback e Poll.
O WSRM não especifica qualquer MEPs.
Nas duas especificações, cada mensagem faz parte de um grupo, no WSR o grupo é
referenciado como group, enquanto no WSRM é chamado de sequence. As mensagens têm
um número de identificação e este é incrementado quando da ocorrência de novas
mensagens. No WSR, este número é chamado de sequence number e no WSRM de message
number. Os números de seqüência são combinados com a identificação 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 ocorrência de mensagens duplicadas, o que não ocorre no
WSRM (Pallickara et al, 2005). A simples presença de uma nova mensagem garante a
criação de novo grupo, podendo gerar desta forma, problemas de colisão, pois do lado dos
subscritores a informação de identificação do grupo não é atualizada no WSR, pela ausência
de uma política de atualização do identificador do grupo, o que não ocorre no WSRM. As
regras para finalizar um grupo são baseadas no tempo de expiração do envio da mensagem,
quando todas as mensagens forem entregues, se um número de seqüência excede o máximo
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 não mantêm qualquer mecanismo
explícito para tal funcionalidade.
As retransmissões de mensagens quando ocorre qualquer tipo de falha no
recebimento ou correção de erro, sempre é iniciada do lado do servidor no caso do WSR,
pois este não suporta confirmação negativa de envio (Negative Acknowledgements) e as
tentativas de retransmissão são feitas até um limite pré-configurado. O WSRM além de
incorporar a técnica de confirmação negativa de envio, resultando em pedidos de
retransmissão do lado do subscritor, possui as políticas de retransmissão baseada em um
intervalo como no WSR e no exponencial backoff (Tanenbaum, 1994, P. 250). Os modos
de operação para a entrega de mensagens suportados no WSR são os mesmos no WSRM
(e.g. não-confiáveis, ao menos uma mensagem, ordenada, exatamente uma mensagem),
porém, no WSRM podem ser feitas configurações para detecção de mensagens duplicadas,
entrega confiável e ordenamento de mensagens independentes dos modos de operação
suportados (Pallickara et al, 2005).

4.3 Camada de negócios

Uma vez que as organizações disponibilizam serviços web torna-se necessário o

estabelecimento de diretrizes para garantia de confiabilidade na cooperação entre esses
serviços. A camada de negócios visa fornecer confiabilidade na composição de serviços
web através de diferentes abordagens. As pesquisas para garantia de confiabilidade nessa
camada são extensas, algumas propostas envolvendo protocolos transacionais são tratadas
em (Erradi, 2005).
Uma transação, quer em um ambiente centralizado ou distribuído, é caracterizada
pelas propriedades Atomicidade, Consistência, Isolamento, Durabilidade (ACID). A
propriedade Atomicidade trata o trabalho como parte indivisivel, o que implica que todas as
operações efetuadas durante uma transação serão efetivadas em caso de sucesso e em caso
de falha em alguma dessas operações, todas serão canceladas. Já na Consistência, as regras
de integridade são asseguradas. O Isolamento define que o resultado de uma transação
executada concorrentemente a outra deve ser o mesmo que o de sua execução de forma
isolada. E por fim, a Durabilidade define que os efeitos de uma transação em caso de
sucesso (commit) são permanentes mesmo em presença de falhas (Chapple, 2007).
As transações distribuídas consistem em um dos conceitos fundamentais para garantia
de confiabilidade para os Web Services. Entretanto, eles necessitam de um mecanismo
flexível e extensível para troca de mensagens entre serviços, em comparação aos
mecanismos do modelo transacional dos bancos de dados, levando-se em consideração
atividades de longa duração e suporte a colaborações entre aplicações corporativas.
A abordagem orientada a processos aplica o comportamento transacional necessário
as aplicações ao longo do processo mapeado na composição de serviços (Portilla et al,
2006). As seguintes propostas serão descritas: Web Services Transactions (IBM, 2005) e
Business Transactional protocol (BTP).
 O consórcio envolvendo as 3 empresas BEA, IBM e Microsoft propuseram três
especificações para aplicação de transações distribuídas, no contexto de Web Services: WS-
Coordination, WS-AtomicTransation (WS-AT) e WS-BusinessTransaction (WS-BT) (IBM,
2005).
O WS-Coordination é um framework extensível para fornecer protocolos que
coordene ações em aplicações distribuídas, como as transações que necessitam de um
acordo consistente sobre o resultado das atividades distribuídas. Contempla-se nesse
framework a definição da estrutura de um contexto, para a propagação de informações aos
participantes de uma atividade, e os requisitos para propagação do contexto entre os
serviços que cooperam entre si, além de incluir: um coordenador genérico, participantes e o
protocolo de coordenação. 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 especificação WS-AT é uma extensão do WS-Coordination que fornece a
definição de coordenação para transações atômicas. Essa especificação utiliza duas
variações do protocolo Two-Phase-Commit (2PC) para que os participantes cheguem a um
consenso sobre o desfecho de uma transação distribuída: 2PC durável, participantes cujos
recursos transacionais são duráveis – banco de dados, e volátil, participantes cujos recursos
transacionais são voláteis – cache. (Cabrera, 2005b).
No cenário para composição de serviços a característica inter institucional torna
muitas vezes iniviável a utilização do WS-AT, pois as organizaçoes não permitiriam que
fossem aplicadas travas em seus recursos, além de que o tempo de execução de cada
atividade nem sempre é curto, na ordem de milisegundos(eg. autorização bancária). Aplicar
travas em atividades longas (eg. enviar uma fatura) pode ser muitas vezes inviável pois
caso um roolback seja necessário o custo será alto para execução de tal processamento.
Para esse tipo de situação existe a WS-BT que também é uma extensão do WS-
Coordination que fornece a definição de coordenação para transações distribuídas de longas
duração. Essa especificação permite que caso ocorra alguma falha durante a execução da
transação, operações de compensação são executadas para compensar uma falha (Cabrera,
2005c).
O Comitê Técnico da OASIS, Business Transactions, concentra-se no
desenvolvimento de tecnologias para transações de negócios pela Internet. Esse comitê
propôs o OASIS BTP (Business Transaction Protocol) que é um protocolo para processos
de longa duração (OASIS, 2007). Para tal o BTP propõe transações distribuídas com um
enfraquecimento das garantias transacionais (propriedades ACID) através de dois tipos de
transações: transações atômicas e transações coesivas. Na primeira o resultado do trabalho
como um todo será confirmado ou cancelado, com um relaxamento da propriedade de
isolamento, na segunda além do relaxamento da propriedade de isolamento propõe o semi-
atômico em que alguns participantes efetivam e outros poderão cancelar baseados em
regras de negócios pré-definidas (Portilla et al, 2006). O protocolo permite ainda a
intervenção da aplicação na definição do que poderá ser confirmado e definição de
abordagens para reverter os efeitos de uma transação (eg. compensação) (Degan, 2005).
WS Transactions e BTP são dois frameworks para adicionar comportamento
transacional aos serviços web. WS-TX oferece um framework extensível específico para
Web Services, já o BTP oferece um framework genérico para aplicações baseadas em
serviços . Além desses serviços a literatura específica dispõe de outras especificações,
sendo necessário um levantamento através de um estudo comparativo entre as soluções
disponíveis para identificar qual desses é mais adequado ao ambiente dinâmico e
heterogêneo em que os serviços web encontram-se (Portilla et al, 2006).

5. Conclusão

Com o crescimento da utilização da Internet, várias empresas começaram a publicar

serviços e trocar informações entre aplicações na Web. A necessidade de uma padronização
motivou o surgimento de várias tecnologias, entre elas, os serviços Web. Com o aumento
da utilização dos serviços Web como um padrão de trocas de mensagens entre grandes
empresas, surgiu também a preocupação com a confiabilidade desses serviços. Neste
trabalho, foram mostradas novas técnicas que precisam ser desenvolvidas para assegurar a
confiabilidade nos níveis do provedor de serviços, no protocolo de transporte de mensagens
e nas camadas SOAP e de negócios.
As técnicas apresentadas não substituem as técnicas tradicionais para garantia de
confiabilidade, porém agregam novas soluções devido as especificidades encontradas nos
serviços Web. O conhecimento dessas técnicas é relevante, entretanto, a implementação das
mesmas tem um certo custo associado. Portanto, torna-se indispensável, que os
fornecedores de serviços web ponderem a relação custo benefício para cada caso em
particular e determine quais as melhores técnicas para garantia da confiabilidade necessária
para o projeto.
Apesar de existerem diversos trabalhos relacionados com serviços web, essa área
mostra-se ainda incipiente, mesmo porque o protocolo SOAP foi proposto em 1998. A
própria W3C ainda não definiu os padrões para confiabilidade nos serviços web. As
propostas apresentadas nesse artigo estão sendo analisadas pelo consórcio.

6. Referências
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 – User’s
Guide”. Addison-Wesley, ISBN 0201571684.
Cabrera, LF, et al. (2005). “Web Services Coordination (WS-Coordination). Specification”,
gosto 2005. http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-tx/WS-
Coordination.pdf. Dezembro.
Cabrera, LF, et al.(2005) “Web Services Atomic Transaction (WS-AtomicTransaction).
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/ws-
tx/WS-BusinessActivity.pdf. Dezembro.
Chapple, Mike (2007). “The ACID Model”. Disponível 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º Edição, ISBN 0321263545.
Degan, Joyce.( 2005). “Integração de dados corporativos: uma proposta de arquitetura
baseada em serviços de dados”. Universidade Estadual de CAMPINAS SP - Mestrado
Profissional em Computação. Dezembro.
Erradi, A., Maheshwari, P.. (2005) “A Broker-Based Approach for Improving Web
Services Reliability”. IEEE Internacional Coference on Web Services (ICWS’05)
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 e-Technology, e-Commerce and e-Service (EEE’04).
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, Aplicações 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 (ITCC’05) 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. Disponível em <
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4020870 >
Tanenbaum, A. S.. (1994) "Redes de computadores". Editora Campus, 2º Edição, 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 Exploração dos Conceitos Básicos de Tolerância a
Falhas”, Instituto de Informática – UFRGS, Especialização em Sistemas Distribuídos.
www.inf.ufrgs.br/~taisy/disciplinas/textos/indiceroteiro.htm. Dezembro.
Xinfeng, Ye. "Providind Reliable Web Services through Active Replication". 6th
IEEE/ACIS Internacional Coference on Computer and Information Science (ICIS 2007).
RFP.Object Management Group, Fault tolerant CORBA using entity redundancy: Request
for proposal. OMG Technical Committee Document orbos/98-04-01, Abril 1998.