XI Workshop de Testes e Tolerância a Falhas (WTF) - SBRC 2010

XI Workshop de Testes e Tolerância a Falhas 153
3. Trabalhos relacionados
O requisito de disponibilidade, um dos principais componentes da confiabilidade de um
sistema, é particularmente difícil de atingir no ambiente heterogêneo em que serviços web
habitualmente operam. A tarefa de construir modelos de falha, por exemplo, é dificultada
pela natureza da publicação dos serviços, já que a descrição de um serviço, obrigatoriamente,
especifica apenas informações básicas necessárias à sua invocação, de modo que
informações sobre aspectos não-funcionais, tais como disponibilidade e desempenho, não
são publicadas. Dessa forma, determinar quais as possíveis falhas que um determinado
serviço pode vir a apresentar pode ser impossível sem as informações necessárias sobre
cada serviço que o compõe. De fato, a disponibilidade de um serviço pode ser até menor
que qualquer um dos componentes que lhe dão forma [Moser et al. 2007].
Apesar da evidente necessidade, nenhuma especificação de confiabilidade no
que tange à disponibilidade de serviços ainda foi desenvolvida. Isso ocorre, em
grande parte, devido à dificuldade de estender as técnicas de replicação além das
fronteiras de uma única organização, já que as tecnologias que elas usam no desenvolvimento
de seus serviços são, possivelmente, não equivalentes. Nos últimos anos,
vários middleware de replicação em serviços web foram desenvolvidos com o propósito
de contornar essa limitação, dentre eles FT-SOAP [Chen 2007], WS-Replication
[Jiménez-Peris et al. 2006], Conectores de Tolerância a Falhas [Fabre and Salatge 2007]
e a replicação híbrida adotada em [Froihofer et al. 2007].
3.1. FT-SOAP
FT-SOAP [Chen 2007] é um mecanismo de replicação passiva. Os componentes básicos
dessa especificação são: o Gerenciamento de Falhas que é utilizado para realizar o monitoramento
de estado das réplicas, o Mecanismo de Log e Recuperação, responsável por
fazer o log das invocações, de forma que elas não sejam perdidas na falha do gerenciador
primário, e o Gerenciador de Replicação, que tem a função de monitorar e constituir os
grupos de réplicas.
O uso de componentes centralizados adiciona novos pontos de falhas ao sistema,
de forma que até os componentes do próprio middleware devem ser replicados.
No mecanismo proposto neste artigo, cada réplica funciona como um mecanismo
de replicação independente, evitando a centralização encontrada na proposta FT-SOAP.
3.2. WS-Replication
WS-Replication [Jiménez-Peris et al. 2006] implementa replicação ativa no contexto dos
serviços web. O protocolo de replicação aplicado é baseado no componente WS-Multicast
que utiliza tecnologias básicas de WS (SOAP e WSDL) para promover sincronia entre as
réplicas. Ao utilizar o WS-Multicast em sua estrutura, WS-Replication mantém na estrutura
de replicação a independência de plataformas inerente à arquitetura SOA, escalando
o protocolo a operar diretamente sobre os serviços na Internet. Além disso, como nenhuma
modificação é imposta à implementação dos serviços, a replicação é totalmente
transparente aos usuários.
O mecanismo de replicação implementado neste artigo, de maneira semelhante ao
WS-Replication, é transparente aos usuários. No entanto, ao aplicar a replicação passiva,
o mecanismo proposto requer menor processamento.