UNIVERSIDADE FEDERAL DA BAHIA€¦ · UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA...

UNIVERSIDADE FEDERAL DA BAHIAINSTITUTO DE MATEMÁTICA

DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO

Marcelo Jorge Pereira da Luz

Avaliação de Desempenho de Mecanismos de

Replicação para Serviços Web Stateful através do

Axis2

Salvador

2009

Marcelo Jorge Pereira da Luz

Avaliação de Desempenho de Mecanismosde Replicação para Serviços Web Stateful

através do Axis2

Monografia apresentada ao Curso degraduação em Ciência da Computação,Departamento de Ciência da Computação,Instituto de Matemática, Universidade Fe-deral da Bahia, como requisito parcial paraobtenção do grau de Bacharel em Ciência daComputação.

Orientadora: Daniela Barreiro Claro

Salvador

2009

RESUMO

Os serviços Web estão cada vez mais sendo utilizados pelas empresas para tornar maiseficiente o processo de comunicação entre as aplicações. Devido a esta ampla utilização, apli-cações críticas estão também fazendo uso dos serviços Web como meio de publicar as suasfuncionalidades na Internet. Neste caso, é imprescindível que estes serviços sejam tolerantes àfalhas. Dentre as principais técnicas para fornecer tolerância à falhas encontra-se a replicaçãode estado. Diversos trabalhos já vem incorporando a replicação de estados, porém a maioria de-les implementa as soluções para frameworks proprietários e com restrições de utilização. Nestesentido, o presente trabalho analisou as técnicas de replicação já incorporadas dentro do Axis2e implementou uma nova técnica de replicação ativa com garantia de estado. Experimentosforam realizados em ambiente Web com o intuito de avaliar o desempenho da implementaçãoproposta.

Palavras-chave:Replicação, Serviços Web, Axis2.

SUMÁRIO

Lista de Figuras

1 Introdução 6

2 Serviços Web 8

2.1 Tecnologias Básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.3 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Estado de um Serviço Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Confiabilidade e Serviços Web . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 Critérios de Confiabilidade . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.2 Confiabilidade nos Serviços Web . . . . . . . . . . . . . . . . . . . . 17

3 Tolerância à Falhas 19

3.1 Replicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Comunicação em Grupo . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2 Protocolos de Replicação . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.2.1 Replicação Ativa . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.2.2 Replicação Semi-Ativa . . . . . . . . . . . . . . . . . . . . 24

3.1.2.3 Replicação Passiva . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.2.4 Replicação Semi-Passiva . . . . . . . . . . . . . . . . . . . 26

4 Mecanismos de Replicação nos Serviços Web 27

4.1 WS-Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 FT-SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Protocolos Híbridos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Implementação 32

5.1 AXIS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1.1 Modelo de Informação . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.2 Modelo de Processamento SOAP . . . . . . . . . . . . . . . . . . . . 35

5.2 JGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3 Protótipos Desenvolvidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Replicação Passiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.5 Replicação Híbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.6 Replicação Ativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Experimentos 43

6.1 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 Testes Realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3 Resultados Obtidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Conclusão 49

Referências 51

LISTA DE FIGURAS

1 Arquitetura SOA(CLARO; MACêDO, 2008) . . . . . . . . . . . . . . . . . . . . 9

2 Estrutura de uma mensagem SOAP(LEOPOLDO, 2003) . . . . . . . . . . . . . . 12

3 UDDI e os padrões de serviço Web (UDDI, 2006) . . . . . . . . . . . . . . . . 16

4 Pilha de padrões dos serviços Web (JAYASINGHE, 2008) . . . . . . . . . . . . . 18

5 Modelo de sistema geral para gerenciar réplicas(COULOURIS; DOLLIMORE; KINDE-

BERG, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Modelo de replicação ativa (COULOURIS; DOLLIMORE; KINDEBERG, 2007). . . . 24

7 Modelo de replicação passiva (COULOURIS; DOLLIMORE; KINDEBERG, 2007). . 25

8 Modelo de replicação semi-passiva (DéFAGO; SCHIPER, 2001) . . . . . . . . . . 26

9 Exemplo de Requisição e Respostas no WS-Replication (SALAS et al., 2006) . . 28

10 Um exemplo de tag WSG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

11 Modelo de replicação híbrida (OSRAEL et al., 2007). . . . . . . . . . . . . . . . 30

12 Componentes da Arquitetura Axis2 (JAYASINGHE, 2008). . . . . . . . . . . . . 33

13 Modelo de Informação Axis2 (JAYASINGHE, 2008). . . . . . . . . . . . . . . . 34

14 Fluxos de entrada e saída do Axis2(AXIS2, 2009) . . . . . . . . . . . . . . . . 36

15 Arquitetura do JGroups (BAN, 2009). . . . . . . . . . . . . . . . . . . . . . . . 37

16 Comparativo entre os protótipos . . . . . . . . . . . . . . . . . . . . . . . . . 45

17 Tempo de execução X Número de Réplicas (Replicação Passiva) . . . . . . . . 46

18 Tempo de execução X Número de Réplicas (Replicação Híbrida) . . . . . . . . 47

19 Tempo de execução X Número de Réplicas (Replicação Ativa) . . . . . . . . . 47

6

1 INTRODUÇÃO

A Internet teve como objetivo inicial possibilitar a troca de documentos entre os computa-

dores distribuídos na grande rede. Porém, com a evolução e popularização desta, passou-se a

utilizá-la como base para comunicação entre aplicações distribuídas que necessitavam de um

método eficiente para intercâmbio de dados.

Para permitir esta integração, diversas tecnologias foram desenvolvidas procurando, basi-

camente, prover meios de realizar troca de informação. Entre essas tecnologias destacam-se

os serviços Web (Web Services), que por usarem protocolos padrões na Internet, tornaram-se

amplamente utilizados por diversas empresas para tornar mais eficiente o processo de comuni-

cação entre as suas aplicações e para publicar os seus serviços na Internet. O uso de serviços,

porém, introduz novas fontes de falhas ao modelo de execução de cada organização, pois fal-

has em sistemas de uma empresa podem ocasionar efeitos colaterais em sistemas de diversas

outras empresas. Diante deste novo cenário, torna-se cada vez mais crescente a necessidade de

comunicação confiável e tolerância a possíveis falhas nestes ambientes computacionais.

Apesar dessa evidente necessidade, nenhuma especificação de confiabilidade no sentido de

adicionar tolerância a falha ao serviços Web foi incorporada à sua pilha padrão de protocolos

para garantir a continuidade de aplicações orientadas a serviços. Visando eliminar essa deficiên-

cia vários mecanismos de replicação de estado aplicados aos serviços Web vem sendo propostos

por pesquisadores do mundo inteiro.

Assim, este trabalho tem como objetivo examinar algumas técnicas de replicação já apli-

cadas em serviços Web através do framework Axis2 e implementar uma nova técnica de repli-

cação ativa com garantia de estado, assim como prover uma análise do tempo de processamento

adicionado ao serviços devido à sua utilização.

O restante deste trabalho está organizado da seguinte maneira: o capítulo 2 introduz as tec-

nologias básicas envolvidas na utilização dos serviços Web. O capítulo 3 aborda as principais

técnicas de tolerância as falhas existentes. O capítulo 4 analisa algumas técnicas de replicação

aplicadas ao serviços Web já desenvolvidas. No capítulo 5, aspectos sobre os componentes uti-

7

lizados para realizar a implementação dos protótipos são detalhados. No capítulo 6, os detalhes

sobre os testes realizados para mensurar a sobrecarga imposta pelos protótipos de replicação

estudados são apresentados, além dos resultados obtidos. O capítulo 7 apresenta a conclusão e

considerações finais.

8

2 SERVIÇOS WEB

Um serviço Web é uma maneira de expor uma funcionalidade de um sistema de informação

e torná-la disponível através de padrões de tecnologias Web(CLARO; MACêDO, 2008). É uma

solução que permite a comunicação e integração de aplicações que podem possuir plataformas

ou arquiteturas diferentes, pois permitem que as aplicações enviem e recebam dados em um

formato uniforme. Os serviços Web tornam a comunicação entre as aplicações, padronizada, o

que possibilita a independência de plataforma ou de linguagem de programação e cria a opor-

tunidade de criação de novos negócios inter-empresas na Internet.

Durante muito tempo o principal foco do desenvolvimento de sistemas distribuídos foi

a utilização de plataformas comerciais que utilizavam arquitetura baseada em objetos como:

CORBA(Commom Object Request Broker Architeture)(CORBA, 2009), DCOM (Distributed

Component Object Model)(DCOM, 2009) e RMI (Remothed Method Invocation)(RMI, 2009).

No entanto, nenhuma dessas infra-estruturas de desenvolvimento e gerenciamento de aplicações

distribuídas visava primordialmente o ambiente da Internet. Com o passar do tempo e a dissem-

inação do uso da Internet, o desenvolvimento de aplicações distribuídas tornou-se mais com-

plexo e custoso.

Com o passar dos anos e a necessidade em se adequar as novas possibilidades de negó-

cio geradas pelo compartilhamento de recursos na Internet porporcionadas pela computação

distribuída, um novo paradigma de desenvolvimento e utilização de software vem ganhando

destaque e deslocando o foco anterior voltado para a arquitetura orientada a objetos para uma ar-

quitetura orientada a serviços (SOA). A arquitetura SOA (Service Oriented Architecture)(SOA,

2009) é um estilo de arquitetura de software cujo princípio fundamental é que aplicativos ou

rotinas implementadas pelas aplicações devem ser disponibilizadas na forma de serviços em

uma rede de computadores de forma indepentende e utilizando padrões abertos para realizar a

comunicação entre si(LUBLINSKY, 2007).

A arquitetura SOA propõe uma estrutura para a criação e utilização dos serviços baseada em

três elementos básicos(CLARO; MACêDO, 2008): O solicitante do serviço, o provedor do serviço

9

e o repositório do serviço. Um serviço pode ser considerado como uma função independendente

que aceita uma ou mais requisições e deve devolver uma ou mais respostas a estas requisições

de maneira padronizada e bem definida. Na Figura 1 é apresentada uma estrutura para criação

e utilização dos serviços proposta por uma arquitetura SOA.

Figura 1: Arquitetura SOA(CLARO; MACêDO, 2008)

O primeiro passo acontece quando o serviço é desenvolvido e publicado em um repositório

público pelo provedor de servicos. O solicitante que deseja utilizar o serviço deve localizar no

repositório o serviço que atenda a sua necessidade (passo 2). Após a localização do serviço, o

solicitante deve fazer a requisição diretamente ao seu provedor através do endereço fornecido

pelo repositório (passo 3). Este processo é conhecido como paradigma find, bind and execute ou

em uma tradução aproximada paradigma procura, consolida e executa. É neste paradigma apre-

sentado que reside uma das vantagens da arquitetura SOA: a interoperabilidade. Os provedores

e consumidores podem ser construídos em estruturas ou plataformas diferentes e, ainda assim,

comunicarem-se, pois a comunicação entre serviços é feita através de tecnologias padronizadas.

Aliado a isso, está a possibilidade de os seus componentes estarem geograficamente separados,

sejam em diferentes salas de um mesmo prédio ou em países distintos, já que as interações são

feitas através da rede.

Toda essas características fazem que a utilização da SOA venha tendo, cada vez mais,

um crescimento notável no âmbito empresarial. Este crescimento deve-se à possibilidade de

disponibilizar suas atividades internas na forma de serviços para que o seus clientes e/ou ou-

tras empresas possam acessar serviços disponibilizados por outras empresas de maneira segura.

Juntam-se a isso vantagens inerentes a arquitetura orientada a serviços como: reutilização de

software, aumento de produtividade e maior agilidade. Vantagens essas, importantes para as

grande empresas.

A maior parte das implementações de SOA utilizam-se de serviços Web. Um servico Web é

um software modular designado para suportar interações aplicação x aplicação através da Web,

independentemente de plataformas ou linguagens de programação(BOOTH et al., 2004). Basi-

10

camente um serviço Web consiste em um operação ou conjunto de operações que podem ser

usadas por um cliente na Internet. As operações de um serviço Web podem ser oferecidas por

uma variedade de recursos diferentes, por exemplo, programas em diversas linguagens de pro-

gramação, objetos ou banco de dados e que podem ser gerenciados por um servidor web, quer

seja junto com páginas Web ou isoladamente(COULOURIS; DOLLIMORE; KINDEBERG, 2007).

Muitos servidores comerciais bastante conhecidos como Amazon(AMAZON, 2009) , Ya-

hoo(YAHOO, 2009), eBay(EBAY, 2009) e o Google(GOOGLE, 2009) vem oferecendo interfaces

de serviços que possibilitam aos seus clientes manipular seus recursos na web. Neste sentido,

pode-se citar um serviço Web oferecido pela Amazon.com que fornece operações com as quais

os seus cliente podem obter informações sobre produtos disponíveis, adicionar determinado

item ao seu carrinho de compras e inclusive verificar o andamento de uma transação. Com

isso as aplicações de outras empresas podem construir serviços que cooperem com os da Ama-

zon.com. Por exemplo, uma aplicação que tem como funcionalidade controlar o estoque de

sua empresa poderia automaticamente pedir o fornecimento de mercadorias da Amazon.com

ao perceber que é necessário reabastecer o estoque de determindao produto. O fornecimento

dessas interfaces de serviços permite que suas operações sejam combinadas com as de outros

serviços para fornecer novas funcionalidades.

2.1 TECNOLOGIAS BÁSICAS

Serviços Web são identificados por uma URI (Unique Resource Identifier)(URI, 2001) e

utilizam XML (Extensible Markup Language)(XML, 2009) para a representação de dados e

empacotamento das mensagens trocadas com os seus clientes. A XML é uma recomendação da

W3C (World Wide Web Consortium) para gerar linguagens de marcação de formatos especiais.

A XML foi derivada da SGML (Standard Generalized Markup Language)(SGML, 2009) e foi

desenvolvida em 1998 com o objetivo de combinar a flexibilidade da SGML com a simplicidade

da HTML(Hyper Text Markup Language)(HTML, 2009) e criar uma linguagem que pudesse ser

lida por software, e integrar-se com as demais linguagens.

Assim como a HTML a XML é baseada em marcadores (ou tags), mas não utiliza tags pré-

definidas e limitadas como a HTML. Enquanto que na HTML, as tags são usadas para definir

a formatação de caracteres e parágrafos, a XML provê um sistema para criar tags para dados

estruturados. Através delas é possível separar o conteúdo dos dados de sua formatação.

Quando um método de um serviço é invocado, os dados são retornados, seja como strings,

como inteiros ou um objeto persona-lizado, e seriados como XML, sendo enviados de volta

11

para o cliente.

Para que o uso dos serviços Web se tornasse unificado instituições como a OASIS(Organization

for the Advancement of Structured Information Standards)(OASIS, 2009) e o W3C ficaram

responsáveis por definir os padrões para a criação e interpretação dos serviços. Para aten-

der estas exigências novas especificações foram definidas dentre as quais destacam-se: SOAP

(Simple Object Access Protocol)(GUDGIN et al., 2007),WSDL(Web Services Description Lan-

guage)(CHRISTENSEN et al., 2001),UDDI (Universal Description, Discovery and Integration)(UDDI,

2006). Cada uma dessas especificações são discutidas a seguir.

2.1.1 SOAP

O SOAP é o protocolo padrão de comunicação entre os serviços Web. Este protocolo foi

criado inicialmente para possibilitar a invocação remota de métodos pela Internet. Sua especi-

ficação foi desenvolvida com o intuito de prover maneiras para se construir mensagens que

pudessem trafegar através de diversos protocolos independentemente de qualquer modelo de

programação ou outra implementação específica. Geralmente servidores SOAP são implemen-

tados utilizando servidores HTTP (Hyper Text Transfer Protocol)(HTTP, 2009), o que se torna

uma vantagem para este protocolo, pois problemas de tráfego na Internet, existentes em pro-

tocolos como DCOM, CORBA ou RMI, como os firewalls e proxys são solucionados com a

utilização de servidores HTTP. As mensagens SOAP são documentos XML que aderem a uma

especificação fornecida pelo W3C e que consistem em, basicamente, os seguintes elementos:

Envelope: o elemento principal de uma mensagem SOAP. Tem a função de identificar o ar-

quivo XML como uma mensagem SOAP. Dentro dele encontra-se os subelementos Cabeçalho

e Corpo.

Cabeçalho (SOAP Header): é um elemento opcional de uma mensagem SOAP. É uma maneira

de adicionar informações de controle em mensagens SOAP, normalmente de contexto de

configuração ou sobre quem deve processar determinada mensagem.

Corpo (SOAP Body): é o elemento que contém o corpo da mensagem, tanto a que está sendo

enviada, em uma requisição, quanto a que está sendo recebida.

Uma mensagem SOAP pode ser usada para transmitir um documento diretamente para o

destino onde ele deve ser processado ou para suportar interações entre um cliente e um servidor.

Na comunicação direta com o servidor o documento a ser comunicado é colocado diretamente

no elemento corpo da mensagem, juntamente com uma descrição que define os nomes e tipos

12

usados no documento. Já na segunda situação o elemento corpo da mensagem contém uma

requisição ou uma resposta. Na figura 2 é mostrado a estrutura de uma mensagem SOAP.

Figura 2: Estrutura de uma mensagem SOAP(LEOPOLDO, 2003)

Um protocolo de transporte é exigido para enviar uma mensagem SOAP para o seu desti-

natário, porém as mensagens independem do tipo de transporte utilizado, pois seus envelopes

não contém nenhuma referência ao endereco de destino. Logo, fica a cargo do protocolo HTTP

ou qualquer outro protocolo utilizado, especificar o endereço do destinatário das mensagens.

Por causa dessa variedade de protocolos de transporte, a especificação cria o conceito de bind-

ing para dizer como a mensagem devera passar de um nó para outro em uma cadeia de execução.

No caso do protocolo HTTP, por exemplo, é utilizado o HTTP SOAP Binding que usa somente

os métodos GET e POST do protocolo.

O GET é utilizado para efetuar requisições idempotentes, ou seja, requisições que devem,

dados os mesmos parâmetros, retornar a mesma resposta não importando quantas vezes elas

forem feitas. O método POST do protocolo é utilizado para requisições que alterem o estado

do servidor Web, ou seja, requisições que não podem ser repetidas sem alterar as informações

mantidas do servidor Web. Na listagem 2.1 é mostrado um exemplo de uma requisição SOAP

para soli-citar o preço de determinado produto de um estoque, onde uma string é passada como

parâmetro e obtém o valor do produto. Na listagem o elemento SOAPAction define qual oper-

ação deve ser invocada no endereço final definido no método POST. Seu valor é uma URI iden-

tificando o destino, o que possibilita que este campo possa ser utilizado como um firewall para

filtrar apropriadamente as mensagens de requisição SOAP. Por exemplo, caso o campo tenha

o valor vazio, significa que o destino da mensagem deve ser definido pela URI da resquisição

13

HTTP.

Listagem 2.1: Exemplo de uma mensagem SOAP embutida em uma requisição HTTP

POST / StockQuote HTTP / 1 . 1

H o s t : www. s t o c k q u o t e s e r v e r . com

Conten t−Type: t e x t / xml ; c h a r s e t =" u t f −8"

Conten t−L e n g t h : nnnn

SOAPAction: " Alguma−URI"

<SOAP−ENV:Envelope

xmlns:SOAP−ENV=" h t t p : / / schemas . xmlsoap . o rg / soap / e n v e l o p e / "

SOAP−ENV:encod ingS ty le =

" h t t p : / / schemas . xmlsoap . o rg / soap / e n c o d i n g / ">

<SOAP−ENV:Body>

< m:GetUl t imoPreco xmlns:m=" Alguma−URI">

<symbol>DIS< / symbol>

< / m:GetUl t imoPreco >

< / SOAP−ENV:Body>

< / SOAP−ENV:Envelope>

Na listagem seguinte temos a resposta HTTP com a mensagem SOAP embutida.

Listagem 2.2: Exemplo de uma mensagem SOAP embutida em uma resposta HTTP

HTTP / 1 . 1 200 OK

Conten t−Type: t e x t / xml ; c h a r s e t =" u t f −8"

Conten t−L e n g t h : nnnn

<SOAP−ENV:Envelope

xmlns:SOAP−ENV=" h t t p : / / schemas . xmlsoap . o rg / soap / e n v e l o p e / "

SOAP−ENV:encod ingS ty le =

" h t t p : / / schemas . xmlsoap . o rg / soap / e n c o d i n g / " / >

<SOAP−ENV:Body>

< m:GetUl t imoPrecoResponse xmlns:m=" Alguma−URI">

< Preco > 3 4 . 5 < / Preco >

< / m:GetUl t imoPrecoResponse >

< / SOAP−ENV:Body>

< / SOAP−ENV:Envelope>

14

2.1.2 WSDL

A WSDL é uma linguagem baseada em XML utilizada para descrever serviços Web. Trata-

se de um documento que além de descrever o serviço, especifica como acessá-lo e quais as suas

operações ou métodos disponíveis. Conforme consta na definição da WSDL, um documento

WSDL é formado pelos seguintes elementos (JUNIOR, 2006):

Tipos: definição de dados usada nas mensagens trocadas pelos serviços.

Mensagem: a definição abstrata dos dados sendo trocados por um serviço e o cliente.

Operação: a definição abstrata da ação realizada pelo serviço.

Interface (Port Type): um conjunto abstrato de operações suportadas por uma porta.

Ligação (Binding): uma especificação concreta de protocolo e formato de dados para uma

interface.

Porta: um único endpoint formado pela combinação de uma Ligação e um endereco de rede.

Serviço: uma coleção de portas relacionadas.

No momento da definição de um serviço Web é necessário especificar os tipos de dados a

serem usados nas mensagens. Após, é necessário definir as mensagens compostas pelos tipos

previamente definidos. Então, deve-se definir as interfaces compostas pelas operações supor-

tadas por uma Porta e finalmente associar cada Porta com uma interface definida e um endereço

para acesso ao serviço. Na listagem 2.3 é mostrada a definição WSDL de um serviço para

solicitar o preço de determinado produto de um estoque.

Listagem 2.3: Exemplo de um documento WSDL e seus elementos

<? xml v e r s i o n =" 1 . 0 " ?>

< d e f i n i t i o n s name=" StockQuote "

t a r g e t N a m e s p a c e =" h t t p : / / example . com / s t o c k q u o t e . wsdl "

< t y p e s >

<schema t a r g e t N a m e s p a c e =" h t t p : / / example . com / s t o c k q u o t e . xsd "

xmlns=" h t t p : / /www. w3 . org / 2 0 0 0 / 1 0 / XMLSchema">

. . .

< / schema>

< / t y p e s >

<message name=" G e t U t i m o P r e c o I n p u t ">

15



< / message>



< o p e r a t i o n name=" Ge tUl t imoPreco ">



< o u t p u t message=" t n s : G e t U l t i m o P r e c o O u t p u t " / >

< / o p e r a t i o n >





< s o a p : b i n d i n g s t y l e =" document "

t r a n s p o r t =" h t t p : / / schemas . xmlsoap . o rg / soap / h t t p " / >

< s e r v i c e name=" S t o c k Q u o t e S e r v i c e ">

< d o c u m e n t a t i o n >Meu S e r v i ç o < / d o c u m e n t a t i o n >





< / s e r v i c e >

< / d e f i n i t i o n s >

2.1.3 UDDI

O UDDI é um protocolo aprovado como padrão pela OASIS que especifica um método para

publicar e descobrir diretórios de serviços em uma arquitetura orientada a serviços. É utilizado

pelos provedores de serviços para publicá-los e pelos usuários de serviços para pesquisar e

descobrir serviços que lhes interessem e consequentemente obter os dados necessários para

a utilização destes serviços. Um serviço de registro UDDI é um serviço Web que gerencia

informações sobre provedores, implementações e metadados de serviços. Nesse repositório

as descrições WSDL dos serviços podem ser pesquisadas pelo nome, como em um serviço

de catálogo telefônico, ou pelo atributo, como os serviços das páginas amarelas em uma lista

telefônica. O UDDI é baseado em vários outros padrões de indústria já estabelecidos, como o

HTTP, XML, XML Schema (xsd)(SCHEMA, 2009), SOAP e WSDL como pode-se observar na

figura 3, que ilustra o relacionamento entre o UDDI e outros padrões relacionados aos serviços

Web.

16

Figura 3: UDDI e os padrões de serviço Web (UDDI, 2006)

2.2 ESTADO DE UM SERVIÇO WEB

Serviços Web são naturalmente stateless, ou seja, cada requisição é tratada como uma

transação independente, sem nenhum tipo de relação com requisições processadas previamente.

Como todas as informações necessárias para a interação com seus clientes estão contidas nos

envelopes de suas mensagens SOAP trocadas, seja ela uma requisição ou uma resposta, nen-

huma informação que possa ser utilizada nas requisições subsequentes do mesmo serviço é

armazenada. Essa natureza stateless é que provê a maior agilidade e simplicidade inerente ao

serviços Web, pois, por exemplo, um serviço pode ser requisitado milhares de vezes em um

curto período de tempo por diversos clientes simultaneamente, e armazenar informações das

diversas requisições de cada cliente poderia tornar o processo muito mais complexo.

Entretanto, as aplicações modernas que utilizam serviços Web tem requisitado dos serviços

a manutenção do estado entre as suas invocações, configurando assim os serviços stateful. Nesse

caso, o cliente utiliza uma referência única para identificar instâncias anteriores de um serviço.

Para isso várias técnicas, como replicação de informações e uso de logs, tem ganhado cada vez

mais destaque no âmbito do desenvolvimento de aplicações baseadas em serviços.

2.3 CONFIABILIDADE E SERVIÇOS WEB

O IEEE(Institute of Electrical and Electronics Engineers) define confiabilidade como "a

probabilidade de que o software não vai causar a falha de um sistema durante um tempo especí-

17

fico, sob condições específicas"(IEEE, 1988). Tornar os sistemas distibuídos confiáveis é, cada

vez mais, necessário, pois estes tem sido amplamente utilizados por grandes empresas em apli-

cações de caráter crítico, como o gerenciamento de tráfego aéreo e manipulação de transações

bancárias. Pode-se imaginar o nível de problemas ocasionados, caso um serviço que disponibi-

liza as rotas utilizadas por aviões torne-se indisponível enquanto um avião está voando, ou ainda

se há uma queda de energia no meio de uma transação bancária e registros dessa transação sejam

perdidos por completo.

2.3.1 CRITÉRIOS DE CONFIABILIDADE

Um serviço Web deve considerar vários requisitos, tanto não-funcionais quanto funcionais,para

que esteja de acordo com a definição de confiabilidade. Dentre eles(ZHANG; ZHANG, 2005):

Corretude: significa que o serviço Web apresenta saídas corretas para um determinado con-

junto de entradas.

Disponibilidade: a probabilidade de que um serviço vai operar sempre que for necessário.

Interoperabilidade: o serviço Web deve poder coexistir com outros componentes de outros

sistemas.

Desempenho: o serviço Web deve executar a sua função em uma velocidade aceitável a partir

do momento que é requisitado.

Integridade: ausência de alterações não autorizadas no serviço.

Tolerância à Falhas: a capacidade de fornecimento do serviço requisitado, mesmo na pre-

sença de falhas(SANTOS; LUNG; MONTEZ, ).

2.3.2 CONFIABILIDADE NOS SERVIÇOS WEB

Apesar dos serviços Web estarem cada vez mais sendo difundidos e utilizados dentro de

organizações empresariais, muitas características desejáveis de sistemas distribuídos, tais como

confiabilidade e segurança, ainda não foram incorporadas. A incorporação destas características

nos serviços Web de maneira padronizada está sendo pesquisada pela comunidade acadêmica

nacional e internacional. Na figura 4 são mostrados exemplos de especificações que compõem

a camada de de QoS (Quality of Service), cada vez mais utilizadas para garantir confiabilidade

e segurança ao serviços web.

18

Figura 4: Pilha de padrões dos serviços Web (JAYASINGHE, 2008)

Como exemplo pode-se citar o WS-ReliableMessaging (RELIABLE, 2009), que é uma es-

pecificação baseada em SOAP que tenta atender os requisitos necessários para uma troca con-

fiável de mensagens entre aplicações que utilizam Serviços Web, visto que somente o SOAP

sobre o HTTP não é suficiente quando o protocolo de trocas de mensagens deve garantir con-

fiabilidade e segurança. O WS-ReliableMessaging tem como finalidade prover as seguintes

características para a troca de mensages SOAP.

• Garantia de entrega de mensagens: garantia de que toda mensagem que é enviada é en-

tregue ao seu destino ou o erro é indicado.

• Eliminação de mensagens duplicadas: garantia que todas as mensagens duplicadas são

detectadas e eliminadas.

• Ordenação de mensagens: Como a comunicação entre as partes requer uma troca de um

considerável número de mensagens, esse requisito garante que as mensagens enviadas

chegarão na parte de destino na mesma ordem que saíram da parte que as enviou.

19

3 TOLERÂNCIA À FALHAS

Define-se a falha de um sistema como uma condição anormal que pode causar uma redução

ou perda da capacidade do mesmo de executar a função para qual foi desenvolvido, corretamente

(AVIZIENIS et al., 2004). Existem várias classificações de falha que podem ocorrer durante a

existência de um sistema, entre elas tem-se:

Acidentais: são falhas físicas, causada por fenômenos naturais sem a participação humana.

Ambiente: falhas causadas por problemas que podem ocorrer no ambiente do sistema (hard-

ware, software). Por exemplo, falhas em discos, memórias do sistema.

Projeto: falhas ocasionadas durante o processo de desenvolvimento do sistema. Um erro na

implementação, por exemplo.

Envelhecimento de componentes: falhas ocasionadas pelo envelhecimento natural dos com-

ponentes e ao desgate devido à demanda exigida dos mesmos, aumentando assim, a prob-

abilidade da ocorrência de falhas.

Intencionais: são falhas resultantes de ações humanas ou ausência destas quando medidas contra

as possíveis falhas poderiam ter sido tomadas.

Ataques: falhas introduzidas por humanos com o objetivo de causar a negação de serviço,

acessar informações ou modificar indevidamente o sistema.

Existem várias maneiras de lidar com as falhas em sistemas de informação. Dentre elas tem-se

(AVIZIENIS et al., 2004):

Prevenção de Falhas(Fault Prevention): significa evitar a ocorrência das falhas. Para evitar

falhas podem ser usados provas de correção, provadores de teoremas ou testes no mo-

mento do desenvolvimento do sistema.

20

Prevenção de Falhas(Fault Removal): consiste em detectar e remover as falhas antes que elas

causem danos ao sistema.

Predição de Falhas(Fault Forecasting): estimar a probabilidade de que falhas ocorram. Con-

sequentemente pode-se avaliar os riscos das falhas.

Tolerância à falhas(Fault Tolerance): na presenca de falhas, evitar que o sistema pare de

prover o serviço.

Entre as técnicas citadas acima, destaca-se a tolerância à falhas, pois prevenção e remoção de

falhas não são suficientes quando um sistema exige alta confiabilidade e alta disponibilidade.

O fornecimento de tolerância à falha está fundamentado na utilização de técnicas que forneçam

um alicerce sólido para que uma determinada falha possa ser tolerada da melhor maneira pos-

sível, de modo a não afetar o funcionamento do software quando a falha se manifestar. Nessa

base fundamental, técnicas tais como replicação de estado (JALOTE, 1994), detecção de falha

(CHANDRA; TOUEG, 1996), comunicação confiável (CHOCKLER; VITENBERG, 2001), entre out-

ras, se tornam cruciais no intuito de fornecer tolerância a falha em um nível aceitável.

3.1 REPLICAÇÃO

Sistema distribuídos são desenvolvidos de maneira que seus recursos possam estar loca-

lizados em diferentes servidores(nós) e mesmo assim possam cooperar para prover os serviços.

É essa natureza distribuída que torna esses sistemas tão vulneráveis a falhas, pois uma possível

falha em um nó que compõe esse sistema pode fazer com que todo o sistema passe a funcionar

de maneira incorreta. Entretanto essa mesma natureza, permite a utilização desses servidores

como réplicas, para aumentar a disponibilidade dos sistemas. Se os dados ou serviços são repli-

cados em dois ou mais servidores que falham independentemente, então o cliente tem a possi-

bilidade de acessar um servidor alternativo, caso o servidor padrão falhe ou se torne inacessível.

A figura 5 apresenta um modelo de arquitetura para o gerenciamento de dados replicados.

Figura 5: Modelo de sistema geral para gerenciar réplicas(COULOURIS; DOLLIMORE; KINDE-BERG, 2007)

21

Neste modelo um conjunto de gerenciadores de réplica (GR) fornece determinado serviço

para o cliente (C). Os clientes vêem os serviços que dão acesso aos objetos de sua necessi-

dade (serviços de reserva hóteis ou contas bancárias, por exemplo) e que estão replicados nos

gerenciadores, e podem fazer uma série de requisições para estes serviços. Estas requisições

são primeiramente processadas pelos front ends(FE), que são uma espécie de interface que inter-

agem diretamente com o usuário e que tem como função comunicar-se, por meio de mensagens,

com um único ou vários gerenciadores via multicast(COULOURIS; DOLLIMORE; KINDEBERG,

2007).

Quando a replicação de dados ou serviços ocorre, é necessário que ela seja transparente

ao cliente, ou seja, os clientes não devem saber da existência de várias réplicas dos dados ou

serviços. O usuário deve acessá-los da mesma forma que o faria caso não existisse replicação.

Neste cenário apresentado a transparência para o usário é contemplada devido ao uso dos front

ends, pois eles fazem a comunicação entre os clientes e os gerenciadores, ao invés, de deixar que

eles façam isso sozinhos, explicitamente. Outro requisito geral para a replicação é a consistência

de estado entre as suas réplicas. Caso haja uma falha em uma réplica, as réplicas restantes devem

ser capazes de continuar provendo o serviço a partir do último estado consistente acordado

entre as réplicas. Para eliminar estas possíveis inconsistências de estado na comunicação entre

processos distribuídos são utilizadas abstrações, como a comunicação em grupo.

3.1.1 COMUNICAÇÃO EM GRUPO

Um grupo pode ser considerado, como um conjunto de processos que cooperam para obter

um objetivo comum, recebendo e processando o mesmo conjunto de mensagens. Um sistema

de comunicação em grupo deve fornecer vários serviços de comunicação e coordenação entre

os membros de determinado grupo.

Um serviço de coordenação entre membros do grupo tem quatro tarefas principais(COULOURIS;

DOLLIMORE; KINDEBERG, 2007):

Fornecer interface para alterações na participação dos membros: fornecer operações para

a criação e destruição de grupos de processos. Além de adicionar ou remover determinado

membro do grupo.

Implementar um detector de falhas: para monitorar os membros do grupo em caso de falhas,

ou em caso de se tornarem inacessíveis.

Notificação sobre alterações no grupo: avisar os membros do grupo quando um processo é

22

adicionado ou removido do grupo.

Realizar a expansão de endereço do grupo: no momento do envio de uma mensagem, é tarefa

do serviço de coordenação fornecer o identificador do grupo, ao invés de listar cada pro-

cesso de um grupo. Dessa maneira determinada mensagem pode ser enviada para um

grupo mesmo que no momento do envio esteja havendo alterações no conjunto de mem-

bros do grupo.

Para que o serviço de coordenação entre os membros de um grupo consiga realizar suas tarefas

ele faz uso dos modos de visualização do grupo (views), que são listas com os membros atuais

de um grupo, onde cada membro possui seu próprio identificador. Todas as vezes que processos

são adicionados ou excluídos do grupo, uma nova view é gerada. Todas a réplicas devem possuir

views idênticas, ou seja, ser consistentes, para isso todas a proposições de views são mantidas

em uma fila até que todos os membros do grupo entrem em um acordo quanto ao seu envio

(COULOURIS; DOLLIMORE; KINDEBERG, 2007). Toda mudança nos elementos de uma view é

entregue a todos os participantes de um grupo, permitindo assim que todas as mensagens sejam

enviadas a todos os membros do grupo, independentemente de qual membro é o emissário da

mensagem.

A comunicação entre processos que formam um grupo é feita através do envio de men-

sagens por difusão(multicast). Uma mensagem ao ser transmitida é enviada a todos os parti-

cipantes do grupo. Em geral, protocolos de comunicação em grupo garantem que uma men-

sagem, uma vez entregue a um processo de determinado grupo, seja também entregue a todos

os outros processos em funcionamento do mesmo grupo, caracterizando assim, a atomicidade

da comunicação. Outra característica garantida pela abstração de comunicação em grupo, é a

ordem em que mensagens são entregues a diferentes processos que podem ser classificadas das

seguintes maneiras:

Total: todos os processos recebem as mensagens na mesma ordem.

Causal: processos só devem processar uma mensagem depois de ter recebido as mensagens

precedentes causalmente. Se, por exemplo, o envio da mensagem m pelo processo P

precede o envio da mensagem n pelo processo Q, então o recebimento de m precede o

recebimento de n no processo R.

Ordem FIFO: as mensagens de um processo são entregues pela ordem de emissão.

Várias ferramentas de comunicação em grupo já foram desenvolvidas. Dentre elas tem-

se o JGroups (BAN, 2009), Spread (SPREAD, 2009), Horus (HORUS, 2009) e ISIS (ISIS, 2009).

23

JGroups foi o toolkit de comunicação em grupo utilizado na construção dos experimentos deste

trabalho, por possuir uma pilha de protocolos flexível que permite aos desenvolvedores de sis-

temas distribuídos integrar a confiabilidade na troca de mensagens sem a preocupação de ter que

implementá-la. Esta característica diminui esforços no desenvolvimento da aplicação e permite

que ela seja implantada em ambientes diferentes, sem a necessidade de modificações no código

fonte da aplicação.

3.1.2 PROTOCOLOS DE REPLICAÇÃO

Os protocolos de replicação podem ser divididos em dois grupos, que se diferenciam na

maneira de efetuar o processamento de suas requisições: os protocolos de processamento re-

dundante (redundant processing) e protocolos de processamento moderado (parsimonious pro-

cessing)(DéFAGO; SCHIPER, 2001). Nos protocolos de processamento redundante todas as répli-

cas de um grupo devem processar todas as requisições de um cliente. Desta forma, o tempo de

resposta das requisições é constante, mesmo na presença de falhas. Existem dois modelos prin-

cipais de processamento redundante: o modelo de replicação ativa e o de replicação semi-ativa.

Já nos protocolos de processamento moderado, as requisições devem ser processadas apenas

por uma réplica. As diferentes técnicas que pertencem a essa família diferem pelo nível de

moderação, são eles(DéFAGO; SCHIPER, 2001):

Moderação Forte (Strong Parsimony): se uma requisição req é processada por uma réplica r,

então req nao é processada por nenhuma outra réplica.

Moderação Parcial (Quasi-Strong Parsimony): se uma mesma requisição req é processada

por duas réplicas r e q, entao uma delas é considerada defeituosa e é forçada a falhar.

Moderação Fraca (Weak Parsimony): se uma mesma requisição req é processada por duas

réplicas r e q, então uma dessas réplicas é marcada como suspeita.

Dentre os protocolos que fazem parte dessa família destacam-se a replicação passiva e a repli-

cação semi-passiva. Estes protocolos se diferenciam apenas pelo nível de moderação adotado e

serão aprofundados nas próximas seções.

3.1.2.1 REPLICAÇÃO ATIVA

No modelo de replicação ativa as requisições do cliente devem ser enviadas para todas

as réplicas. Estas, devem processar as requisições da mesma maneira e na mesma ordem de

24

processamento, produzindo a mesma saída para o mesmo conjunto de entradas, ou seja, o

processamento deve ser determinístico1. A técnica de máquina de estados é utilizada para

contemplar este requisito. Uma máquina de estados consiste em variáveis que encapsulam as

informações de seu estado e de comandos, que modificam essas variáveis ou produzem uma

resposta (SCHNEIDER, 1990).

Os seguintes passos são executados quando um cliente(C) solicita a execução de uma ope-

ração replicada(COULOURIS; DOLLIMORE; KINDEBERG, 2007):

1. Requisição: o front end(FE) difunde a requisição via multicast para todos os membros.

Para isso uma primitiva de multicast com ordenação total e confiável deve ser utilizada.

2. Coordenação: o sistema de comunicação em grupo envia a requisição para os gerenci-

adores de grupo(GR).

3. Execução: todas as réplicas executam a requisição e como elas funcionam como máquinas

de estados devem gerar saídas iguais

4. Resposta: cada réplica envia sua resposta para o front end.

Figura 6: Modelo de replicação ativa (COULOURIS; DOLLIMORE; KINDEBERG, 2007).

O fato de todas as réplicas receberem a requisição torna o processo de recuperação após

uma falha muito mais rápido, pois não é necessário o reenvio da mensagem, o que torna-se uma

vantagem desse estilo de replicação. Entretanto essa redundância consome muito recurso de

processamento.

3.1.2.2 REPLICAÇÃO SEMI-ATIVA

Replicacao semi-ativa (DéFAGO; SCHIPER, 2001) é um protocolo de processamento redun-

dante baseado na replicação ativa. Esta técnica diminui o consumo de recurso que ocorre na1Determinismo significa que o resultado de determinada operação depende unicamente do estato inicial de uma

réplica e da sequência de operações que ela já executou.

25

replicação ativa, permitindo o processamento não-determinístico em mecanismos de processa-

mento redundante. As requisições, assim como na replicação ativa, são difundidas para todas as

réplicas, porém a replicação semi-ativa introduz o conceito de líderes(leaders) e seguidores (fol-

lowers). Todas as réplicas continuam processando as requisições determinísticamente, mas é de

incumbência do líder tratar a requisições que necessitam de um processamento não-determinístico,

como geração de números randômicos, por exemplo, e informar as atualizações de estado para

o seu seguidores.

3.1.2.3 REPLICAÇÃO PASSIVA

Na replicação passiva, também chamada de primary-backup somente uma réplica, a primária,

processa as requisições dos clientes e é responsável por enviar as atualizações de estado para

as outras réplicas(backups). Somente após atualizar todas as réplicas backups é que réplica

primária retorna a resposta para o cliente. Caso aconteça uma falha em uma réplica primária

durante uma requisição, uma das réplicas backups é promovida a primária, mas é de respon-

sabilidade do cliente reenviar a requisição para a nova réplica primária. Para a escolha da nova

réplica primária, o conceito de views é utilizado. No momento que a réplica primária falha,

uma nova view é enviada para todos os membros restantes, mas sem a participação da réplica

faltosa. Qualquer réplica que compõe esse novo módulo de visualização pode ser escolhida

como réplica primária. Na figura 7 temos um modelo de replicação passiva.

Figura 7: Modelo de replicação passiva (COULOURIS; DOLLIMORE; KINDEBERG, 2007).

Nesse modelo de replicação os seguintes passos são executados no momento de uma requi-

sição de um cliente(C)(COULOURIS; DOLLIMORE; KINDEBERG, 2007):

1. Requisição: a requisição é emitida pelo front end(FE) para a réplica primária.

2. Coordenação: a réplica primária escolhe cada requisição pela ordem em que as recebe.

26

3. Execução: a réplica primária executa a requisição e a resposta é armazenada

4. Acordo: a réplica primária envia a atualização de estado para todas as réplicas backups.

5. Resposta: após todos os backups estarem atualizados, a réplica primária envia a resposta

armazenada para o cliente.

3.1.2.4 REPLICAÇÃO SEMI-PASSIVA

A replicacao semi-passiva(DéFAGO; SCHIPER; SERGENT, 1998) é um técnica que utiliza-se

das vantagens da replicação passiva clássica, como baixo custo de processamento e possibili-

dade de executar tarefas não-determinísticas, e tem como objetivo remover uma das suas prin-

cipais desvantagens, o alto tempo de recuperação na presença de uma falha.

Na replicação semi-passiva, diferentemente da replicação passiva onde o cliente envia suas

requisições somente para a réplica primária, todas as réplicas devem receber as requisições de

um cliente, mas somente a réplica primária deve processá-las e enviar as atualizações de estado

para as réplicas backup.

Na figura 8 é apresentado o modelo de processamento de um requisição utilizando repli-

cação semi-passiva. O fato de todas a réplicas receberem as requisições torna esta replicação

Figura 8: Modelo de replicação semi-passiva (DéFAGO; SCHIPER, 2001)

mais transparente ao usuário, pois em uma possível falha na réplica primária, não há necessi-

dade de o cliente reenviar a requisição, visto que, a réplica que se tornará a nova primária já

recebeu esta requisição.

Diversas destas técnicas de replicação vem sendo incorporadas aos serviços Web, visto

que, estes tem obtido um crescimento notável de sua utilização em sistemas que demandam alta

disponibilidade. As maneiras de aplicar essas técnicas nesses serviços tem se tornado fruto de

pesquisas atual na comunidade acadêmica e serão abordadas no próximo capítulo.

27

4 MECANISMOS DE REPLICAÇÃONOS SERVIÇOS WEB

Os mecanismos de replicação nos serviços Web fazem uso das mesmas técnicas de repli-

cação aplicadas aos sistemas distribuídos. No entanto, estes mecanismos precisam adaptar-se

ao ambiente heterogêneo em que os serviços Web operam. Neste sentido várias iniciativas

acadêmicas visando prover tolerância à possíveis falhas tem sido propostas. Estes mecanismos

seguem duas linhas básicas:

• Consideram as réplicas em um ambiente mais homogêneo e aplicam aproximações uti-

lizadas sobre objetos distribuídos diretamente, como as abordagens adotadas em (OSRAEL

et al., 2007) e em (SANTOS; CLARO, 2009) e o FT-WEB(SANTOS; LUNG; MONTEZ, )

• Levam em conta as tecnologias inerentes aos serviços e efetuam a replicação de maneira

que possam operar diretamente sobre os serviços na Internet, como o WS-Replication(SALAS

et al., 2006) e o FT-SOAP(LIANG; FANG; CHEN, 2007).

4.1 WS-REPLICATION

WS-Replication é um framework para prover replicação ativa em serviços Web baseado

em SOAP. O WS-Replication faz uso de dois componentes para alcançar a replicação ativa: o

componente de replicação e componente confiável de multicast, o WS-Multicast.

O componente de replicação é o que garante que as réplicas irão funcionar como máquinas

de estados. Ele é formado basicamente por dois subcomponentes:

Publicador de serviços: provê uma forma de publicar o serviço em várias instâncias diferentes

a partir de uma única e centralizada localidade. O desenvolvedor do serviço age como se

estivesse publicando o serviço em apenas uma réplica, mas este é publicado em todas as

réplicas que compõem o grupo.

28

Gerador de proxy: gera um proxy para cada operação de um serviço Web, que tem como

função, interceptar a requisição e interagir com o despachante (dispatcher) para replicá-

la, e após receber a resposta do despachante entregá-la ao cliente.

O componente de multicast(WS-Multicast) permite comunicação em grupo através do pro-

tocolo SOAP. Consiste em uma interface para realizar o multicast de mensagens de maneira

confiável. Esse componente é dividido em duas outra interfaces:

Interface de usuário: permite a criação, destruição ou configuração de um grupo. Com ela é

possível também descobrir os membros de um grupo, seja através das primitivas unicast

ou multicast.

Interface interna: usada pelo sistema de comunicação em grupo para realizar o multicast das

mensagens, além de detectar possíveis membros faltosos através de um mini-protocolo

de ping baseado em SOAP que monitora periodicamente os membros.

Na figura 9 é mostrada uma visão detalhada dos passos efetuados pelo WS-Replication para

processar um requisição a um serviço Web e entregar a resposta para o cliente.

Figura 9: Exemplo de Requisição e Respostas no WS-Replication (SALAS et al., 2006)

No passo 1 o serviço Web é invocado como um serviço comum, sem replicação. Em

seguida, a requisição é interceptada pelo proxy(ws-proxy)(passo 2), que manda ela para o

despachante. No passo 3 o despachante utiliza o componente WS-Multicast para difundir a

mensagem para todas as réplicas. Quando todas as réplicas recebem a requisição (passos 4 e 5)

29

o WS-Multicast entrega a mensagem para o despachante(passo 6), que então, fica responsável

por executar o serviço Web local(passo 7).

No momento de responder ao cliente, o serviço local entrega a resposta para o despachante

(passo 8). Após isso o despachante, onde a requisição foi originada, deve esperar pela primeira,

todas ou a maioria das respostas, que são enviadas pelos despachantes das outras réplicas,

utilizando-se da primitiva unicast do WS-Multicast(passos 9, 10 e 11). Então o despachante

tendo recebido o número estabelicido de respostas(passo 12), envia a resposta para o cliente

através do proxy(passo 13).

4.2 FT-SOAP

O FT-SOAP é um framework baseado em SOAP e em replicação passiva, proposto por

pesquisadores para tratar a tolerância à falhas neste protocolo. Nessa especificação são pro-

postas quatro componentes básicos: gerenciador de replicação, gerenciador de falhas, mecanis-

mos de logging e recuperação e tolerância à falha transparente ao cliente.

O gerenciador de replicação é definido como interfaces na WSDL do serviço e tem como

função gerenciar e constituir os grupos de replicação tolerantes a falhas. O Mecanismo de

logging é responsável por registrar todas as requisições em um arquivo centralizado confiável

de logging para as futuras recuperações que possam ocorrer. No momento em que o mecanismo

de recuperação no novo membro primário do grupo é ativado, o mecanismo de recuperação

busca os registros de requisição no arquivo e, se necessário, processa as requisições novamente.

O gerenciador de falhas também é definido como interfaces na WSDL. É composto pelo no-

tificador de falhas e pelo detector de falhas. Quando é detectada uma falha o notificador recebe

o relatório do detector de falhas, então o notificador envia a notificação para o gerenciador de

replicação referente ao grupo em que a falha ocorreu. A partir daí o gerenciador de replicação

inicia o processo de recuperação, modifica a WSDL do grupo e registra a nova WSDL do grupo

na UDDI.

A tolerância a falhas deve ser transparente para o cliente, para isso uma nova tag é inserida

pelo FT-SOAP na WSDL dos serviços para criar um grupo de serviços Web tolerante a falhas, a

tag WSG (Web Service Group). Esta tag permite que, caso uma falha ocorra em uma requisição

do cliente, por exemplo, a requisição possa ser enviada para outras réplicas que compõem o

grupo, até que a requisição seja executada com sucesso. Somente se todas as réplicas do grupo

não puderem responder a requisição é que um erro é emitido para a aplicação do cliente. Um

exemplo da tag WSG é mostrado na figura 10.

30

Figura 10: Um exemplo de tag WSG

4.3 PROTOCOLOS HÍBRIDOS

Protocolos híbridos são protocolos que combinam elementos da replicação passiva e da

replicação ativa. Nesse sentido vários middlewares vem sendo desenvolvidos pela comunidade

acadêmica, como os desenvolvidos por (OSRAEL et al., 2007) e (SANTOS; CLARO, 2009), am-

bas construídas baseadas na arquitetura do engine baseado em SOAP conhecido como Axis2

(AXIS2, 2009).

Na abordagem definida em(OSRAEL et al., 2007) as requisições dos clientes são enviadas

apenas para uma réplica primária, exatamente como a replicação passiva clássica, porém as

invocações são interceptadas no fluxo de entrada do Axis2 por interceptadores desenvolvidos e

acoplados ao engine e enviadas para todas as outras réplicas através do toolkit de comunicação

em grupo confiável SPREAD. As outras réplicas também devem processar as invocações, esta

característica, herdada da replicação ativa. Na figura 11 é mostrado o funcionamento do modelo

de replicação adotado em (OSRAEL et al., 2007):

Figura 11: Modelo de replicação híbrida (OSRAEL et al., 2007).

31

No fluxo mostrado na figura, no primeiro passo a mensagem SOAP chega a interface de

transporte do Axis2. A mensagem passa pelas fases padrões do Axis2 até ser interceptada pelo

módulo desenvolvido (passo 2) que é o responsável por difundir a invocação para todas as ré-

plicas, inclusive a réplica primária, através do SPREAD. O fluxo de entrada na réplica primária

é bloqueado até que a mensagem reapareça no interceptador(InFlowReplicationHandler), isso

é feito para garantir a consistência de estado entre as réplicas. No momento em que recebe uma

invocação, uma réplica backup deve remontar a invocação e enviá-la para o topo do fluxo de

entrada da réplica (passos 4 e 5). Novamente a mensagem passa através das fases padrões até

chegar no interceptador desenvolvido. Este interceptador verifica se o envelope SOAP contém

um cabeçalho SOAP da réplica primária. Se este for o caso, o middleware sabe que a mensagem

recebida é uma mensagem replicada e pode agir de duas maneiras. Se a réplica for a primária,

o bloqueio da mensagem SOAP original é desativado, ela é processada e o resultado é entregue

para o cliente. A mensagem replicada é descartada. Se for uma réplica backup, a mensagem

replicada é processada, porém nenhuma resposta é enviada para o cliente.

O mecanismo de interceptação e o esquema de replicação híbrido deste middleware servi-

ram de base ao desenvolvimento dos protótipos de replicação desenvolvidos em (SANTOS;

CLARO, 2009), porém o modelo adotado por este difere do introduzido em(OSRAEL et al., 2007)

por efetuar a serialização não somente da invocação, mas também do contexto da mensagem.

Dessa maneira não é necessário reinserir a invocação no ínicio do fluxo de entrada do Axis2. O

contexto ao qual o handler implementado tem acesso está completo e pronto para dar ínicio ao

processamento da requisição. A fase de processamento é imediatamente iniciada nas réplicas

backup. Outra diferença está no toolkit de comunicação em grupo utilizado nessa abordagem.

A ferramenta utilizada foi o JGroups. Os protótipos desenvolvidos por (SANTOS; CLARO, 2009)

serviram como motivação para a implementação dos protótipos deste trabalho. Aspectos com-

plementares sobre sua implementação, como o funcionamento e informações sobre os compo-

nentes utilizados, serão abordados no próximo capítulo.

32

5 IMPLEMENTAÇÃO

Com o intuito de testar as técnicas de replicação voltadas aos serviços Web stateful, foram

utilizados os modelos de replicação passiva e replicação híbrida desenvolvidos em (SANTOS;

CLARO, 2009), implantados em um ambiente em redes de computadores. Os testes de repli-

cação executados em (SANTOS; CLARO, 2009) foram executados em uma única máquina, sem

levar em conta as sobrecargas da execução da replicação de serviços em um ambiente computa-

cional distribuído. Um protótipo baseado em replicação ativa foi desenvolvido para realizar

uma comparação com os dados obtidos pelos testes efetuados utilizando as outras técnicas de

replicação. Os serviços testados foram desenvolvidos em Axis2 e a comunicação em grupo

confiável entre as réplicas foi implementada através do toolkit JGroups.

5.1 AXIS2

O Apache Axis2 é um engine baseado em SOAP, desenvolvido para tornar o desenvolvi-

mento de serviços Web mais flexível e extensível. Ele é construído em uma arquitetura modular

que consiste em módulos essenciais (core) e não essenciais (non-core) e onde o usuário pode

desenvolver e adicionar seus próprios módulos à estrutura do Axis2. Na figura 12 é mostrada a

arquitetura desse engine . Entre os módulos essenciais tem-se(JAYASINGHE, 2008):

Modelo de processamento SOAP: responsável por processar as mensagens SOAP que chegam.

Modelo de informação: tem a função de manter informações sobre os estados dos serviços.

Modelo de Publicação: permite ao usuário publicar seus serviços, configurar protocolos de

transporte e estender o modelo de processamento SOAP.

API do cliente: provê interfaces para facilitar a interação dos clientes com os serviços Web.

Transporte: define um framework de transporte que permite o uso de um serviço em múltiplos

protocolos de transporte.

33

Figura 12: Componentes da Arquitetura Axis2 (JAYASINGHE, 2008).

Para que o funcionamento da implementação dos módulos criados nesse trabalho seja en-

tendido torna-se necessário uma análise aprofundada em dois componentes especiais do Axis2:

o modelo de processamento SOAP e o modelo de informação.

5.1.1 MODELO DE INFORMAÇÃO

Este componente é formado por duas hierarquias, criadas para separar as informações es-

táticas das dinâmicas: hierarquia de descrição e hierarquia de contexto. A figura 13 apresenta a

hierarquia de descrição e a hierarquia de contexto.

A hierarquia de descrição representa os dados informados no momento que o Axis 2 é

iniciado, informações fornecidas em arquivos de configuração por exemplo. Nesse sentido o

axis2 possui três tipos de arquivos de configuração:

axis2.xml: é o arquivo de configuracao global do axis2. Contém todas as informações mínimas

para iniciar o Axis2. Este arquivo pode ser editado para adicionar funções específicas ao

Axis2.

service.xml: arquivo que mantém informações estáticas sobre os serviços Web implantados no

Axis2. Todo serviço implantado no Axis2 deve ter este tipo de arquivo.

module.xml: arquivo com as informações para configuração dos módulos existentes no Axis2

e os módulos que podem ser adicionados pelo usuário ao engine.

A hierarquia de contexto representa os dados recebidos em tempo de execução pelo Axis2.

34

Figura 13: Modelo de Informação Axis2 (JAYASINGHE, 2008).

Ela muda constantemente a medida que o Axis2 recebe e processa as mensagens. Ela é dividida

em(JAYASINGHE, 2008):

Contexto de configuração(ConfigurationContext): encontra-se no topo da hierarquia e man-

tém informações sobre os dados dinâmicos de todo o sistema. As informações armazenadas

nesse contexto tem o ciclo de vida igual à duração do sistema.

Contexto de grupo de serviços (ServiceGroupContext): criado sempre que uma mensagem é

recebida pelo Axis2 e tem como função armazenar e compartilhar informações entre os

serviços.

Contexto de serviços (ServiceContext): representa os dados em tempo de execução gerados

por um determinado serviço.

Contexto de operação (OperationContext): representa o ciclo de vida de um padrão de troca

de mensagens estabelecido.

Contexto de mensagem (MessageContext): contexto criado toda vez que uma mensagem é

recebida. Contém informações da sessão e do envelope SOAP das mensagens. Ele é

armazenado até que a mensagem seja processada, após isso ele é apagado.

35

5.1.2 MODELO DE PROCESSAMENTO SOAP

Este módulo engloba o processamento de todas as mensagens recebidas pelo Axis2 e conse-

quentemente as respostas devolvidas para o cliente. O processamento das mensagens é dividido

em dois fluxos: o fluxo de entrada (InFlow) e fluxo de saída (OutFlow). Esses fluxos são cons-

tituídos por várias fases (phases) através das quais as mensagens devem trafegar quando estão

sendo processadas, quer seja no fluxo de entrada ou no fluxo de saída.

Existem dois tipos de fases no Axis2: globais (global phases) ou de operação (operation

phases). A única diferença entre esses dois tipos é a posição em que se encontram na cadeia

de execução dos fluxos. As fases globais são fases que são invocadas para todos os serviços,

todas as vezes em que uma nova mensagem é recebida. Já as fases de operação são fases

executadas para um conjunto específico de operações. O motivo de dividir as fases nesses

dois tipos é prover facilidades para que um usuário possa criar suas próprias fases. Estas fases

devem ser acopladas como fases de operação. Na listagem 5.1 são mostradas algumas fases e

seus respectivos interceptadores, descritas no arquivo de configuração axis2.xml.

Listagem 5.1: Fases e interceptores padrões do fluxo de entrada do Axis2

1− 

2− < !−− Sys tem p r e d e f i n e d ph as e s −−>

3− < phase name=" T r a n s p o r t ">

4− < h a n d l e r name=" R e q u e s t U R I B a s e d D i s p a t c h e r "

c l a s s =" org . apache . a x i s 2 . d i s p a t c h e r s . R e q u e s t U R I B a s e d D i s p a t c h e r ">

5− < o r d e r phase =" T r a n s p o r t " / >

6− < / h a n d l e r >

7− < h a n d l e r name=" SOAPAct ionBasedDispa tcher "

c l a s s =" org . apache . a x i s 2 . d i s p a t c h e r s . SOAPAct ionBasedDispa tcher ">

8− < o r d e r phase =" T r a n s p o r t " / >

9− < / h a n d l e r >

10− < / phase >

11− < phase name=" A d d r e s s i n g ">

12− < h a n d l e r name=" A d d r e s s i n g B a s e d D i s p a t c h e r "

c l a s s =" org . apache . a x i s 2 . d i s p a t c h e r s . A d d r e s s i n g B a s e d D i s p a t c h e r ">

13− < o r d e r phase =" A d d r e s s i n g " / >

14− < / h a n d l e r >

15− < / phase >

16− < phase name=" O p e r a t i o n I n P h a s e ">

36

17− < h a n d l e r name=" Mus tUnders t andChecker "

c l a s s =" org . apache . a x i s 2 . jaxws . d i s p a t c h e r s . Mus tUnders t andChecker ">

18− < o r d e r phase =" O p e r a t i o n I n P h a s e " / >

19− < / h a n d l e r >

20− < / phase >

Cada fase é constituída por um ou mais interceptadores (handlers), que são responsáveis por

efetuar diversas operações nas mensagens recebidas ou escrever/ler informações no contexto

de mensagem (MessageContext). Na linha 3 da listagem 5.1 é mostrado um exemplo de uma

fase padrão do Axis2 chamada Transport, constituída por dois interceptadores(linhas 4 e 7). Os

interceptadores são stateless por natureza, ou seja, eles não armazenam nenhuma informação

das suas execuções em sua memória, apenas executam as suas funções e passam a mensagem

para um outro interceptador da mesma fase ou para outra fase do fluxo.

No fluxo de entrada caso uma mensagem trafegue através de todas as fases do fluxo sem

nenhum problema, o engine passa a mensagem para o receptor de mensagens (Message Re-

ceiver), que é o último interceptador do fluxo de entrada e é responsável por invocar o serviço

e enviar uma resposta, caso seja necessário, como mostrado na figura 14, onde os fluxos de

entrada e saída são apresentados.

Figura 14: Fluxos de entrada e saída do Axis2(AXIS2, 2009)

Dois fluxos adicionais são utilizados pelo Axis2 para o tratamento de falhas: fluxo de en-

trada com falhas (InFaultFlow) e fluxo de saída com falhas (OutFaultFlow). O fluxo de entrada

com falhas é acionado sempre que uma requisição faltosa é recebida. Já o fluxo de saída com

falhas, sempre que alguma coisa de errado acontece no fluxo de saída normal.

37

5.2 JGROUPS

JGroups é um toolkit de comunicação em grupo confiável, escrito em Java e baseado em IP

multicast. Com ele processos podem ingressar em um grupo e mandar ou receber mensagens

de/para os membros do grupo via primitivas unicast ou multicast. A arquitetura do JGroups é

mostrada na figura 15.

Figura 15: Arquitetura do JGroups (BAN, 2009).

Esta arquitetura consiste de três partes básicas:

API Canal (Channel): utilizada pelos desenvolvedores de sistemas para construir a comuni-

cação em grupo confiável entre suas aplicações. Para entrar em um grupo um processo

deve criar um canal e conectar-se com o grupo através do nome do grupo. Uma vez

conectado um membro pode enviar e receber mensagens.

Blocos de Implementação (Building Blocks): encontra-se em uma camada acima da API Canal

e provê um nível de abstração maior desta API para as aplicações. Com eles as aplicações

podem usar o conjunto de funções que necessitam sem ter que incluir todo o conjunto de

classes da API, que ela pode nem chegar a usar.

Pilha de protocolos (Protocol Stack): implementam as propriedades especificadas por um canal

criado. Todas as mensagens, enviadas ou recebidas, devem passar através de toda a pilha

de protocolos, onde cada camada pode modificar, reorganizar ou adicionar um cabeçalho

(header) às mensagens.

5.3 PROTÓTIPOS DESENVOLVIDOS

Como descrito na seção 5.1 o engine Axis2 é formado por um fluxo de entrada e um fluxo

de saída, onde cada fluxo é constituído por fases de processamento. Estas fases podem ser

38

fases padrões do Axis2 ou fases adicionadas por desenvolvedores. Dentro de cada fase devem

existir um ou mais interceptadores de mensagens que são ativados no momento que a mensagem

encontra-se nesta fase e que são responsáveis por efetuar diversas operações nas mensagens

recebidas ou escrever/ler informações no contexto de mensagem (MessageContext).

Com intuito de efetuar estudos nos mecanismos de tolerância à falha voltados para os

serviços Web stateful, os protótipos de replicação híbrida e passiva desenvolvidos em (SANTOS;

CLARO, 2009) foram utilizados como base para o desenvolvimento deste projeto. Modificações

na pilha de protocolos do JGroups utilizados na replicação híbrida e passiva foram feitas, com

o intuito de permitir que a comunicação entre as réplicas pudesse ser feita através de máquinas

distribuídas em uma rede de computadores, ao contrário do caráter local dos testes realizados

em (SANTOS; CLARO, 2009).

Neste trabalho, a pilha de protocolos do JGroups foi modificada para proporcionar ordena-

mento total de mensagens, ao contrário do ordenamento FIFO adotado em (SANTOS; CLARO,

2009), para garantir que todas as réplicas recebessem as mensagens na mesma ordem. O or-

denamento total de mensagens no JGroups é proporcionado pelo protocolo SEQUENCER, este

protocolo foi inserido no topo da pilha de protocolo utilizada, realizando-se alterações no ar-

quivo de configuração da pilha de protocolos padrão.

No protocolo de replicação híbrida foram introduzidos mecanismos de espera por confir-

mação de recebimento de mensagens trocadas entre as réplicas, para mensurar a sobrecarga dos

mecanismos provocada pela latência de rede. Com o intuito de efetuar uma comparação entre

as técnicas de replicação, foi desenvolvido um protótipo de replicação ativa.

5.4 REPLICAÇÃO PASSIVA

Para contemplar os requisitos da replicação passiva, o protótipo desenvolvido em (SANTOS;

CLARO, 2009), adicionou uma nova fase ao fluxo de entrada do Axis2, chamada "FaseRepli-

cacaoPassiva". Essa fase foi acopladada imediatamente antes da fase de processamento de

mensagens, o que garante a consistência de estado entre as réplicas. O novo fluxo de entrada do

engine é constituído pelos seguinte passos(SANTOS; CLARO, 2009):

1. A requisição do cliente chega a interface de transporte da réplica primária e é encami-

nhada para as fases posteriores do fluxo de entrada, exatamente como o fluxo de entrada

padrão.

39

2. No momento que a "FaseReplicacaoPassiva"é alcançada. O inteceptador (handler) que

a compõem, verifica se a réplica já está conectada ao grupo, senão efetua a conexão do

canal, caso contrário, serializa o contexto de mensagem e a invocação do cliente.

3. Com o contexto de mensagem serializado, o handler envia uma mensagem de atualiza-

ção para todas as réplicas, exceto a réplica primária que está enviando a mensagem e

logicamente já a possui. O envio multicast é feito utilizando o bloco de implementação

(building block) RPCDispatcher (BAN, 2009) do JGroups que permite aos desenvolve-

dores invocar métodos remotamente em uma ou em todas as réplicas que sejam membros

de um determinado grupo. Neste caso, o método invocado nas réplicas é o metodo "rece-

berContexto"como mostrado na listagem 5.2:

Listagem 5.2: Envio de mensagem de atualização para as réplicas

1− p r i v a t e s t a t i c R p c D i s p a t c h e r d i s p ;

2− p r i v a t e R s p L i s t r s p _ l i s t ;

. . .

3− MethodCal l metodo = new MethodCal l ( ) ;

4− metodo . setName ( " r e c e b e r C o n t e x t o " ) ;

5− t r y {

6− metodo . s e t A r g s ( new O b j e c t [ ] { t h i s . p e g a C o n t e x t o ( ) } ) ;

7−} ca tch ( IOExcep t ion e ) {

8− e . p r i n t S t a c k T r a c e ( ) ;

9− }

11− r s p _ l i s t = d i s p . ca l lRemoteMethods ( nul l ,

metodo , GroupReques t . GET_NONE, 0 ) ;

Na linha 6 o contexto é definido como parâmetro do método "receberContexto"e colo-

cado em um vetor de objetos. Na linha 11 o método é invocado através da função call-

RemoteMethods. Esta função recebe quatro parâmetros, o primeiro indica a lista de des-

tinatários onde o método deve ser chamado, caso tenha valor null, significa que o método

deve ser chamado em todos os membros do grupo. O segundo parâmetro é o nome do

método a ser invocado. O terceiro parâmetro define a abordagem de espera por confir-

mação. Neste caso nenhum mecanismo de espera por confirmação de execução é neces-

sario, pois o processamento é moderado. Já o último parâmetro define o tempo máximo

de espera por confirmações em milisegundos.

4. As réplicas executam o método receberContexto, mostrado na listagem 5.3

40

Listagem 5.3: Metodo receberContexto

1− S t r i n g nomeServico = c o n t e x t o . g e t ( 0 ) ;

2− S t r i n g c o n t e x t o S e r i a l i z a d o = c o n t e x t o . g e t ( 1 ) ;

3− h i s t o r i c o M e n s a g e m . p u t ( nomeServico , c o n t e x t o S e r i a l i z a d o ) ;

Caso o gerenciador primário falhe a eleição do novo primário faz uso do bloco de imple-

mentação ReceiverAdapter que faz parte da API do Jgroups. A eleição do novo membro, foi

feita através de pequenas alterações feitas no método viewAccepted do bloco de implementação.

Este método é chamado toda vez que há uma mudança na composição da view de um grupo,

quer seja quando um novo membro ingressa ao grupo, ou quando um membro deixa-o. No mo-

mento que a réplica primária falha o método é invocado, uma nova view é gerada e os endereços

de seus membros são armazenados em uma lista de endereços onde o primeiro elemento dessa

lista é escolhido com o novo primário.

O contexto da mensagem é armazenado em um objeto hashmap mantido em cada réplica

para garantir o caráter stateful dos serviços. A cada requisição de um determinado serviço, o

histórico do seu contexto é sobrescrito, como mostrado na linha 3 da listagem 5.3, o que permite

que em caso de falhas na réplica primária, a réplica backup eleita como primária recupere o

estado, reaplicando as requisições feitas a cada serviço isoladamente.

5.5 REPLICAÇÃO HÍBRIDA

Como no protótipo de replicação passiva uma nova fase foi acoplada ao fluxo de entrada

do Axis2 antes da fase de processamento, chamada "FaseReplicacaoHibrida". Entretanto, neste

trabalho, foram feitas alterações no código fonte do módulo de replicação híbrida desenvolvido

em (SANTOS; CLARO, 2009) para introduzir o mecanismo de espera por confirmação de rece-

bimento entre as réplicas. O novo fluxo de entrada do engine, introduzido por este trabalho é

constituído pelos seguinte passos:

1. O contexto e a invocação são serializados e enviados para as outras réplicas como os

passos 2 e 3 do protótipo de replicação passiva. A diferença reside no fato de que como

o processamento é redundante, a réplica primária deve esperar as confirmações de rece-

bimento de todas as réplicas backups pertencentes ao seu grupo, como configurado no

terceiro parâmetro do método "callRemoteMethods"na linha 8 da listagem 5.4.

Listagem 5.4: Envio de mensagem de atualização para as réplicas

41

1− MethodCal l metodo = new MethodCal l ( ) ;

2− metodo . setName ( " r e c e b e r C o n t e x t o " ) ;

3− t r y {

4− metodo . s e t A r g s ( new O b j e c t [ ] { t h i s . p e g a C o n t e x t o ( ) } ) ;

5−} ca tch ( IOExcep t ion e ) {

6− e . p r i n t S t a c k T r a c e ( ) ;

7− }

8− r s p _ l i s t = d i s p . ca l lRemoteMethods ( nul l ,

metodo , GroupReques t . GET_ALL , 6 0 0 0 0 ) ;

2. As réplicas recebem o contexto serializado, o reconstróem e o reativam para que o pro-

cessamento seja iniciado.

Todas réplica deve processar as requisições e consequentemente enviar sua resposta para a

replica primária, assim a fase "FaseReplicacaoHibrida"foi adicionada ao fluxo de saída do Axis2

e consiste nas seguintes etapas:

1. Caso a réplica seja primária, ela deve aguardar o envio de confirmações de processamento

das outras réplicas antes de entregar a resposta para o cliente.

2. Se a réplica for secundária, ela deve enviar uma mensagem via unicast para a réplica

primária confirmando a execução da requisição, e feito isso, abortar o envio da resposta

para o cliente como pode ser visto na linha 4 da listagem 5.5

Listagem 5.5: Envio de mensagem de confirmação de processamento via unicast

1− metodo . setName ( " c o n f i r m a r E x e c u c a o " ) ;

2− meto . s e t A r g s ( new O b j e c t [ ] { idMensagemEnviada } ) ;

3− t r y {

4− d i s p . calRemoteMethod ( r e p l i c a P r i m a r i a , metodo ,

GroupReques t . GET_NONE, 0 ) ;

5− }

O processo de eleição da nova réplica primária é exatamente igual ao utilizado no protótipo

de replicação passiva, porém possuindo um tempo de recuperação de estado otimizado, visto

que, qualquer réplica que assuma o posto de réplica primária já processou todas as requisições

feitas por um cliente.

42

5.6 REPLICAÇÃO ATIVA

O protótipo de replicação ativa desenvolvido neste trabalho, foi construído de forma análoga

à implementação adotada em (SALAS et al., 2006). O bloco de implementação (building block)

RPCDispatcher do Jgroups foi utilizado para realizar o multicast e o protocolo SEQUENCER da

sua pilha, inserido ao topo da sua pilha para garantir a ordenação total da entrega de mensagens.

Os seguintes passos são executados no momento que uma requisição é feita por um cliente:

1. No momento que uma invocação de um determinado método de serviço é feita, ela é

interceptada.

2. A chamada ao método difundida para todas as réplica membros de um grupo, inclusive

a réplica que originou a requisição. A função callRemoteMethod da API do JGroups é

utilizada para garantir as propriedades de ordenamento e confiabilidade, como mostrado

na listagem 5.6.

Listagem 5.6: Multicast das Mensagens

1− d i s p . calRemoteMethod ( nul l , metodo ,

GroupReques t . GET_ALL , 6 0 0 0 0 0 ) ;

3. O método é executado localmente em cada réplica pertecente ao grupo.

4. A réplica onde a requisição foi originada, deve esperar a confirmação de execução do

método de todas as réplicas que receberam a invocação, via unicast, conforme especifi-

cado no valor do terceiro parâmetro da função callRemoteMethod.

5. No momento que todas as respostas esperadas são recebidas, a resposta à requisição é

entregue ao cliente.

A manutenção do estado entre as réplicas é alcançada devido ao fato de todas as requisições

serem processadas por todas as réplicas membro do grupo, independentemente de em qual

réplica do grupo a requisição foi feita. A consistência de estado é garantida através da utilização

do protocolo de ordenamento total.

O próximo capítulo apresenta os experimentos realizados com o intuito de aferir a sobre-

carga imposto pela adição da replicação e atestar a manutenção da consistência de estado entre

as réplicas.

43

6 EXPERIMENTOS

Visando avaliar o desempenho dos protótipos em um ambiente distríbuido foram realiza-

dos testes com o intuito de mensurar o processamento adicional existente quando serviços são

replicados e precisam efetuar comunicação em grupo através de tráfego em rede. Testes para

aferir a consistência de estado entre as réplicas também foram realizados.

6.1 AMBIENTE

Para efetuar os testes foram utilizados três PCs Pentium D 3.00GHz com 1,00 GB de memo-

ria RAM e disco rígido de 150 GB, com o sistema operacional Microsoft Windows XP Profes-

sional 2002 Service Pack 2, conectados em uma LAN (Local Area Network). Cada máquina

possui uma instância do servidor Tomcat 6.0.18, com uma instância do Axis2-1.5. Para a co-

municação entre as réplicas foi utilizado o toolkit JGroups-2.6.8 e na sua pilha de protocolos

foi utilizaddo o ordenamento total de mensagens.

6.2 TESTES REALIZADOS

Os testes foram desenvolvidos através de um serviço Web que mantém um vetor de strings

no Contexto de Serviço (ServiceContext) do Axis2 e que foi publicado em cada instância Axis2

instalada nos três computadores. O serviço Web é constituído por quatro métodos principais:

Criar Sessão: método responsável por criar o vetor e adicioná-lo a sessão. Como mostrado na

listagem 6.1.

Listagem 6.1: Método Criar Sessão

1− A r r a y L i s t a r r a y l i s t = new A r r a y L i s t ( ) ;

2− S e r v i c e C o n t e x t s e r v i c e c o n t e x t = MessageContex t .

g e t C u r r e n t M e s s a g e C o n t e x t ( ) . g e t S e r v i c e C o n t e x t ( ) ;

3− s e r v i c e c o n t e x t . s e t P r o p e r t y ( "SHOPPING_CART" , a r r a y l i s t ) ;

44

Na linha 2 da listagem o contexto de mensagem (MessageContext) atual é atribuído ao

contexto de serviço. Na linha 3 o vetor criado na linha 1 é adicionado ao contexto.

Adicionar elemento: adiciona um elemento ao vetor mantido na sessão. Como mostrado na

linha 2 da listagem abaixo:

Listagem 6.2: Método Adicionar elemento

1− L i s t l i s t = ( L i s t ) s e r v i c e c o n t e x t .

g e t P r o p e r t y ( "SHOPPING_CART" ) ;

2− l i s t . add ( omelement . g e t T e x t ( ) ) ;

3− l i s t = ( L i s t ) s e r v i c e c o n t e x t . g e t P r o p e r t y ( "SHOPPING_CART" ) ;

Remover Elemento: remove o primeiro elemento atual do vetor

Listar número de elementos: método que tem como função retornar a quantidade de elemen-

tos no vetor mantido na sessão

Listar elementos: retorna os elementos de uma sessão na forma de uma string

Para avaliar o desempenho dos protótipos, foram feitas uma série de 3000 requisições,

onde assim que a resposta de uma requisição é entregue para o cliente, uma nova requisição é

feita para a réplica primária, no caso das replicações passiva e híbrida, e no caso da replicação

ativa, para todas as réplicas, com o intuito de calcular a média e o desvio padrão do tempo de

processamento das requisições. Cada requisição adiciona ao vetor alocado na sessão a string

"elemento i", onde i é o número da requisição atual, variando dessa forma de "elemento 0"a

"elemento 2999". Os seguintes cenários de teste foram aplicados:

• Um serviço sem nenhum tipo replicação acoplada.

• Replicação passiva com 1, 2 e 3 réplicas conectadas ao grupo.

• Replicação híbrida com 1, 2 e 3 réplicas conectadas ao grupo.

• Replicação ativa com 1, 2 e 3 réplicas conectadas ao grupo.

Foram realizados também, testes para garantir a manutenção de estado entre as réplicas

conforme mostrado a seguir:

45

1. No caso da replicação passiva a réplica primária foi forçada a falhar e o método de listar

o número de elementos foi invocado na réplica eleita como nova primária.

2. No protótipo de replicação híbrida tornou-se necessário garantir o processamento redun-

dante, para isso o método listar número de elementos foi invocado em cada réplica na

ausência de falhas. A réplica primária foi forçada a falhar sucessivamente e novamente o

método listar número de elementos é invocado na nova réplica primária. Para garantir a

consistência, a função lista elementos foi invocada em cada réplica e seus valores foram

comparados

3. Na replicação ativa, assim como na híbrida, é necessário atestar o processamento redun-

dante, logo o método usado para listar o número de elementos foi invocado na ausência

de falhas e como o processamento deve ser determinístico, o método para listar os ele-

mentos contidos na sessão foi invocado e seus valores comparados para confirmar esta

característica.

6.3 RESULTADOS OBTIDOS

Com o intuito de mensurar o processamento em excesso provocado pela latência de rede na

comunicação em grupo, foram realizados testes na presença de uma única réplica. Os valores

obtidos são mostrados no gráfico da figura:

Figura 16: Comparativo entre os protótipos

A média de execução do serviço para o cenário sem replicação foi de 90,1453 milisegun-

dos, já a no segundo cenário, onde o protótipo de replicação passiva foi utilizado, a média foi

46

de 98,6822, impondo uma sobrecarga de 9,5%. No terceiro cenário o protótipo de replicação

híbrida foi acoplado ao serviço Web e a média calculada foi de 118,5393 milisegundos aumen-

tando o tempo médio em 31,5%, já no quarto cenário foi utilizado o protótipo de replicação

ativa e a média de processamento em milisegundos foi de 105,6826 provocando assim uma

sobrecarga de 17,2%.

O aumento do tempo de execução nos protótipos de replicação passiva e híbrida deve-se

basicamente à adição de mais uma fase ao fluxo de entrada do Axis2 e, especialmente no caso

da replicação híbrida, à adição de outra fase ao fluxo de saída. Cada fase que é adicionada ao

fluxo representa mais um passo na cadeia de execução do Axis2. A serialização do contexto

nestes protótipos é outro fator que influencia o tempo de processamento, visto que, apesar de

só existir uma réplica membro do grupo, o contexto continua sendo serializado. Como a cada

requisição mais informações são adicionadas a sessão, o tamanho do contexto também aumenta

e ocasiona um aumento de processamento para serializá-lo nas últimas requisições. No caso da

replicação ativa,a sobrecarga observada deve-se ao mecanismo empregado para efetuar a espera

por confirmação de execução, que demanda um tempo adicional.

Outros testes foram realizados utilizando mais de uma réplica para medir a média de pro-

cessamento na requisição quando a comunicação em grupo é realmente utilizada. Os testes

foram efetuados cinco vezes para cada protótipo com o intuito de determinar o intervalo de

confiança do experimento realizado. No protótipo de replicação passiva é notável o grande au-

mento do tempo de processamento ocasionado pelas mensagens de atualização enviadas pela

réplica primária às réplicas backups, como mostrado na figura 17:

Figura 17: Tempo de execução X Número de Réplicas (Replicação Passiva)

Neste cenário o tempo de processamento máximo foi obtido na presença de três répli-

cas, onde a média de processamento das requisições foi de 274,1385 com desvio padrão de

0,918914999 e com um intervalo de confiança de 0,80544971 para um nível de 95%. Já no pro-

tótipo de replicação híbrida a sobrecarga de processamento é mais evidente, devido a adição de

47

mais uma fase ao fluxo de saída da cadeia de execuçao do Axis2 e ao mecanismo de espera por

confirmação implantado ao protótipo. No cenário realizado com três réplicas foi obtido o valor

de processamento máximo, com uma média de 280,26132, desvio padrão igual à 0,763622608

e com um intervalo de confiança de 0,669332428 para um nível de 95%, como mostrado na

figura 18:

Figura 18: Tempo de execução X Número de Réplicas (Replicação Híbrida)

O protótipo de replicação ativa apresentou valores próximos aos observados no de repli-

cação híbrida, por também implementar mecanismos de espera por confirmações de processa-

mento, apresentando seu valor máximo de 301,1642 com desvio padrão igual à 0,741485469 e

intervalo de confiança igual à 0,649928727 para um nível de 95%, como mostrado na figura 19:

Figura 19: Tempo de execução X Número de Réplicas (Replicação Ativa)

Os testes efetuados para conferir a consistência e a manutenção de estado obteram os re-

48

sultados esperados, ou seja, todas as vezes em que foi invocado o método listar número de

elementos apresentou 3000 itens, o que garante a manutenção de estado. O método que testa

a consistência entre as réplicas, conferindo o conteúdo dos vetores alocados na sessão de cada

réplica, obteve retornos iguais todas as vezes que executado, mostrando a consistência entre as

réplicas e comprovando a funcionalidade dos mecanismos.

49

7 CONCLUSÃO

A replicação de serviços Web é um campo de pesquisa que, apesar de estar adquirindo

destaque na comunidade acadêmica, ainda carece de ferramentas que possam prover tolerância

à falhas e que possam ser incorporadas aos serviços de maneira padronizada. Neste sentido,

diversos trabalhos já vêm incorporando a replicação de estados nos servicos Web, embora a

maioria deles implemente suas soluções para frameworks proprietários e com restrições de uti-

lização. Este trabalho teve como objetivo mensurar a sobrecarga de processamento inerente aos

mecanismos de replicação e analisar as suas causas.

Após a análise dos resultados obtidos nos testes aplicados foi observado que a latência de

rede causada pela comunicação em grupo influencia no tempo de processamento de uma requi-

sição de um cliente, e que pode ocasionar altas médias de tempo de execução caso o tráfego de

dados na rede seja alto. Aliado a este fator encontra-se o mecanismo de monitoração de estado

dos membros de um grupo, cujo processamento cresce de maneira diretamente proporcional

ao número de réplicas presentes. Entretanto os resultados dos testes realizados para aferir a

consistência, mostram que apesar do aumento de tempo no processamento a consistência e

manutenção de estado foram contempladas.

Este trabalho abre algumas possibilidades para o desenvolvimento de trabalhos futuros.

Entre elas:

• Estudar melhor a pilha de protocolos do JGroups, para customizá-la de maneira que se

possa reduzir o número de camadas de protocolos pelas quais as mensagens devem trafe-

gar, para tentar diminuir a sobrecarga imposta pela comunicação em grupo

• Implementar mecanismos de espera por confirmação de processamento diferentes dos

adotados nestes trabalho e efetuar uma comparação nos resultados obtidos. Utilizar co-

municação assíncrona pode ser uma maneira de obter melhores médias de processamento,

caso a garantia de consistência entre as réplicas possa ser enfraquecida.

• Desenvolver novos protótipos que utilizem outras técnicas de replicação, como por e-

50

xemplo, replicação semi-ativa e semi-passiva e comparar os seus resultados.

51

REFERÊNCIAS

AMAZON. Amazon Web Services. [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://aws.amazon.com/>.

AVIZIENIS, A. et al. Basic concepts and taxonomy of dependable and secure computing. In:IEEE Transaction on Dependable and Secure Computing. [S.l.: s.n.], 2004.

AXIS2. Apache Axis2. [S.l.], 2009. Disponível em: <http://ws.apache.org/axis2/>.

BAN, B. JGroups - A Toolkit for Reliable Multicast Communication. [S.l.], 2009. Últimoacesso em 15 de novembro de 2009. Disponível em: <http://www.jgroups.org/>.

BOOTH, D. et al. Web Services Architeture. [S.l.], 2004. Disponível em:<http://www.w3.org/TR/ws-arch/#id2260892>.

CHANDRA, T. D.; TOUEG, S. Unreliable failure detectors for reliable distributed systems.Journal of the ACM, 1996.

CHOCKLER, G. V.; VITENBERG, R. Group communication specifications: A comprehensivestudy. ACM Computing Surveys 33, 2001.

CHRISTENSEN, E. et al. Web Services Description Language (WSDL) 1.1. [S.l.], 2001.Último acesso em 12 de novembro de 2009. Disponível em: <http://www.w3.org/TR/wsdl>.

CLARO, D. B.; MACêDO, R. J. Web services e sua relação com sistemas de informação. In:IV Simpósio Brasileiro de Sistemas de Informação (SBSI’08). [S.l.: s.n.], 2008.

CORBA. Catalog of OMG CORBA/IIOP Specifications. [S.l.], 2009.Último acesso em 15 de novembro de 2009. Disponível em:<http://www.omg.org/technology/documents/corba_spec_catalog.htm>.

COULOURIS, G.; DOLLIMORE, J.; KINDEBERG, T. Sistemas distribuídos: Conceitos eprojeto. In: . [S.l.]: Bookman, 2007. cap. 15.

DCOM. Distributed Component Object Model (DCOM) Remote Protocol Specifi-cation. [S.l.], 2009. Último acesso em 11 de novembro de 2009. Disponível em:<http://msdn.microsoft.com/pt-br/library/cc201989%28en-us,PROT.10%29.aspx>.

DéFAGO, X.; SCHIPER, A. Specification of replication techniques, semi-passive replication,and lazy consensus. 2001.

DéFAGO, X.; SCHIPER, A.; SERGENT, N. Semi-passive replication. In: Proceedings of theThe 17th IEEE Symposium on Reliable Distributed Systems. [S.l.: s.n.], 1998.

EBAY. eBay Developers Program. [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://developer.ebay.com/>.

52

GOOGLE. Google Code. [S.l.], 2009. Último acesso em 15 de novembro de 2009. Disponívelem: <http://code.google.com/intl/en/>.

GUDGIN, M. et al. Simple Object Access Protocol (SOAP) Version 1.2. [S.l.], 2007. Últimoacesso em 10 de novembro de 2009. Disponível em: <http://www.w3.org/TR/soap12-part1/>.

HORUS. The Horus Project. [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://www.cs.cornell.edu/Info/Projects/Horus/>.

HTML. HyperText Markup Language. [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://www.w3.org/TR/html5/>.

HTTP. Hypertext Transfer Protocol). [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://www.w3.org/Protocols/>.

IEEE. IEEE Guide for de use of IEEE Standard Dictionary of Measures to Produce ReliableSoftware). [S.l.], 1988.

ISIS. The Isis Project. [S.l.], 2009. Último acesso em 15 de novembro de 2009. Disponível em:<http://www.cs.cornell.edu/Info/Projects/ISIS/>.

JALOTE, P. Fault Tolerance in Distributed Systems. [S.l.]: Prentice Hall PTR, 1994.

JAYASINGHE, D. Quickstart Apache Axis2. [S.l.]: Packt Publishing, 2008.

JUNIOR, C. S. de M. Soa e web services em java. In: . [S.l.]: Brasport Livros eMultimidia, 2006. cap. 3 e 4.

LEOPOLDO, M. R. B. Entendendo o simple object access protocol (soap). 2003.

LIANG, D.; FANG, C.-L.; CHEN, C. Ft-soap: A fault-tolerante web service. Journal ofSystems Architecture: the EUROMICRO Journal, 2007.

LUBLINSKY, B. Defining soa as an architectural style. 2007. Disponível em:<http://www.ibm.com/developerworks/library/ar-soastyle/>.

OASIS. Organization for the Advancement of Structured Information Standards. [S.l.],2009. Último acesso em 10 de novembro de 2009. Disponível em: <http://www.oasis-open.org/home/index.php>.

OSRAEL, J. et al. Axis2-based replication middleware for web services. In: Proceedings of theIEEE International Conference on Web Services. [S.l.: s.n.], 2007.

RELIABLE. Web Services Reliable Messaging. [S.l.], 2009. Último acesso em 15 de novembrode 2009. Disponível em: <http://www.ibm.com/developerworks/library/specification/ws-rm/>.

RMI. Java Remote Method Invocation. [S.l.], 2009. Último acesso em 15 de novembro de2009. Disponível em: <http://java.sun.com/javase/technologies/core/basic/rmi/index.jsp>.

SALAS, J. et al. Ws-replication: A framework for highly available web services. In:Proceedings of the 15th international conference on World Wide Web. [S.l.: s.n.], 2006.

53

SANTOS, G. T.; LUNG, L. C.; MONTEZ, C. Ftweb: A fault tolerant infrastructure for webservices. In: Proceedings of the Ninth IEEE International EDOC Enterprise ComputingConference. [S.l.: s.n.].

SANTOS, I. N.; CLARO, D. B. Aspectos de replicação em serviços web stateful através doaxis2. In: WTICG/ERBASE 2009. [S.l.: s.n.], 2009.

SCHEMA. XML Schema). [S.l.], 2009. Último acesso em 15 de novembro de 2009. Disponívelem: <http://www.w3.org/XML/Schema>.

SCHNEIDER, F. B. Replication management using the state machine approach. ACMComputing Surveys 22, 1990.

SGML. Overview of SGML Resources. [S.l.], 2009. Último acesso em 15 de novembro de2009. Disponível em: <http://www.w3.org/MarkUp/SGML/>.

SOA. New to SOA and Web services. [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://www.ibm.com/developerworks/webservices/newto/index.html>.

SPREAD. The Spread Toolkit. [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://www.spread.org/index.html>.

UDDI. Universal Description, Discovery, and Integration (UDDI). [S.l.], 2006. Último acessoem 12 de novembro de 2009. Disponível em: <http://uddi.xml.org/uddi-101>.

URI. URIs, URLs, and URNs: Clarifications and Recommendations 1.0. [S.l.], 2001.Último acesso em 15 de novembro de 2009. Disponível em: <http://www.w3.org/TR/uri-clarification/>.

XML. eXtensible Markup Language. [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://www.w3.org/XML/>.

YAHOO. Yahoo Developer Network. [S.l.], 2009. Último acesso em 15 de novembro de 2009.Disponível em: <http://developer.yahoo.com/>.

ZHANG, J.; ZHANG, L.-J. Criteria analysis and validation of the reliability of webservices-oriented systems. In: Proceedings of the IEEE International Conference on WebServices. [S.l.: s.n.], 2005.

UNIVERSIDADE FEDERAL DA BAHIA€¦ · UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA...

Documents

Transcript of UNIVERSIDADE FEDERAL DA BAHIA€¦ · UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMÁTICA...