Projeto, Implementac¸ao e Avaliac¸˜ ao de uma˜ Camada...

FUNDACAO EDSON QUEIROZUNIVERSIDADE DE FORTALEZA – UNIFOR

Projeto, Implementacao e Avaliacao de umaCamada Generica de Comunicacao em Grupo

Leandro Sales Holanda Pinto

FORTALEZA

2009

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.


Projeto, Implementacao e Avaliacao de umaCamada Generica de Comunicacao em Grupo

Dissertacao apresentada ao curso de Mestradoem Informatica Aplicada da Universidade deFortaleza como parte dos requisitos necessariospara a obtencao do grau de Mestre em In-formatica Aplicada.

Orientador:Prof. Dr. Nabor das Chagas Mendonca

UNIVERSIDADE DE FORTALEZAMESTRADO EM INFORMATICA APLICADA

FORTALEZA

2009

_____________________________________________________________________________ P659p Pinto, Leandro Sales Holanda. Projeto, implementação e avaliação de uma camada genérica de comunicação em grupo / Leandro Sales Holanda Pinto. - 2009. 70 f. Dissertação (mestrado) – Universidade de Fortaleza, 2009. “Orientação: Prof. Dr. Nabor das Chagas Mendonça.” 1. Sistemas distribuídos. 2. Redes de comunicação de dados. 3. Engenharia de software. I. Título. CDU 681.3:004.75 _____________________________________________________________________________

iii

AGRADECIMENTOS

Meu sinceros agradecimentos ao Prof. Nabor das Chagas Mendonca, pela orientacao, a dedica-

cao e a paciencia, indispensaveis para a conclusao desse trabalho.

Aos meus pais, Sergio e Lıgia, pelo incentivo e dedicacao.

Agradeco em especial a minha esposa, Lenina, pela compreensao e o apoio incondicional.

Aos meus irmaos, Luiz e Lıvia, pelos incentivos.

Ao meu amigo, Henrique Teofilo, pela companhia, sugestoes e ajuda durante todo esse trabalho.

Aos professores Nelson Souto Rosa e Americo Tadeu Falcone Sampaio, pelas sugestoes para a

melhoria desse trabalho.

Aos demais professores do MIA.

A secretaria do MIA, em especial ao Edmilson.

Aos amigos, Jonathan D’Orleans e Rafael Garcia, pela ajuda durante esse trabalho.

Aos amigos da E-NOVAR, pelo apoio e compreensao.

Aos demais colegas aqui nao citados que de alguma forma me ajudaram e incentivaram.

iv

Resumo da Dissertacao apresentada ao MIA/UNIFOR como parte dos requisitos necessariospara a obtencao do grau de Mestre em Informatica Aplicada.

Projeto, Implementacao e Avaliacao de uma Camada Generica de Comunicacao emGrupo


Agosto/2009

Orientador: Prof. Dr. Nabor das Chagas Mendonca

Programa: Informatica Aplicada

O uso de APIs genericas de comunicacao em grupo na implementacao de aplicacoes distribuıdaspode ser motivado por dois fatores principais: (i) desempenho, com a possibilidade de seleci-onar o sistema de comunicacao em grupo mais eficiente para o contexto da aplicacao sem anecessidade de refatoracao de codigo; e (ii) modularidade, atraves de uma arquitetura de soft-ware fracamente acoplada e independente de um sistema de comunicacao em grupo especıfico.Apesar disso, as APIs genericas de comunicacao em grupo atualmente disponıveis oferecemapenas servicos basicos de transmissao de mensagens e gerenciamento de membros, o quetem dificultado a sua adocao por aplicacoes que requerem servicos de mais alto nıvel, comoinvocacao remota de objetos replicados e transferencia de estado entre membros. Este trabalhoapresenta uma camada generica de comunicacao em grupo, chamada G2CL, que implementaum conjunto de servicos de comunicacao em grupo de alto nıvel sobre uma API generica exis-tente. Para demonstrar a viabilidade da utilizacao da G2CL em um sistema real, o trabalhorelata uma avaliacao inicial do esforco de migracao e do impacto de desempenho associadosao uso da G2CL como a solucao de comunicacao em grupo do servidor de aplicacao Java EEJOnAS.

v

Abstract of the Dissertation presented to MIA/UNIFOR as a partial fulfillment of the require-ments for the degree of Master of Applied Informatics.

Design, Implementation and Evaluation of a Generic Group Communication Layer


August/2009

Adviser: Prof. Dr. Nabor das Chagas Mendonca

Program: Applied Informatics

Relying on generic group communication APIs in the development of distributed applicationscan be a good design decision for at least two main reasons: (i) performance, with the possi-bility of selecting the most efficient group communication system for the particular context ofthe application without the need of code refactoring; and (ii) modularity, with the opportunityto use a loosely coupled software architecture that is independent from any specific group com-munication implementation. Despite their clear benefits, the current generic APIs only offerbasic services for message transmission and membership management, which has hamperedtheir adoption by applications that required higher-level services such as invocation of repli-cated objects and state transfer between group members. This dissertation presents a genericgroup communication layer, called G2CL, which implements a set of high-level group commu-nication services on top of an existing generic API. To show the viability of using G2CL in areal system, the dissertation reports on an initial evaluation of the migration effort and perfor-mance impact associated with the use of G2CL as the group communication solution for theJOnAS Java EE open source application server.

vi

Sumario

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Estrutura da dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Comunicacao em Grupo: Conceitos, Sistemas e APIs Genericas . . . . . . . . . . . . . . . . . 5

2.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Servico de gerenciamento de membros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2 Servico de troca de mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Sistemas de comunicacao em grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 JGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.2 Appia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.3 Spread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 APIs genericas de comunicacao em grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 jGCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.2 Hedera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.3 Shoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vii

3 Avaliacao do Impacto de Desempenho de Duas APIs Genericas de Comunicacaoem Grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Metodo de avaliacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 Impacto das APIs genericas sobre o JGroups . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2 Impacto das APIs genericas sobre o Spread . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.3 Impacto das APIs genericas sobre o Appia . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.4 Impacto da camada de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.5 Impacto da migracao para uma API generica . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 G2CL: Uma Camada Generica de Comunicacao em Grupo . . . . . . . . . . . . . . . . . . . . . 35

4.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Principais decisoes de projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1 Escolha da API generica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 Modelo de implementacao dos servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.3 Extensoes realizadas no jGCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3 Servicos implementados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3.1 Servicos de alto nıvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.2 Decoradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4 Passo a passo para implementacao de novos servicos . . . . . . . . . . . . . . . . . . . . . . . . 49

4.5 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Estudo de Caso: Avaliacao da G2CL em um Sistema Real . . . . . . . . . . . . . . . . . . . . . . . 52

5.1 JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.1.1 CMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.2 Uso do JGroups no CMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

viii

5.2 Migracao do JOnAS para a G2CL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.1 Migracao da classe SynchronyzedDistributedTree . . . . . . . . . . . . . . . . . . . . 57

5.2.2 Migracao da classe JGMessageManager . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.3 Migracao em numeros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.3 Avaliacao do impacto do uso da G2CL no desempenho do JOnAS . . . . . . . . . . . . . 59

5.3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.4 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.5 Sumario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1 Contribuicoes e resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.2 Sugestoes para trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Referencias Bibliograficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

ix

Lista de Figuras

2.1 Arquitetura do JGroups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Exemplo de compartilhamento de camadas do Appia em uma aplicacao mul-

timıdia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Arquitetura cliente-servidor do Spread. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Interacoes entre as interfaces do jGCS durante o envio de uma mensagem. . . . . . . 19

2.5 Interacao entre as interfaces do Hedera durante o envio de uma mensagem. . . . . . 21

3.1 Resultados para a configuracao JGroups-UDP em um cluster de 4 nos. . . . . . . . . . 25

3.2 Resultados para a configuracao JGroups-TCP em um cluster de 4 nos. . . . . . . . . . 26

3.3 Resultados para a configuracao JGroups-UDP com mensagens de 10 Kbytes. . . . 27

3.4 Resultados para a configuracao JGroups-TCP com mensagens de10 Kbytes. . . . . 28

3.5 Resultados para o Spread em um cluster de 4 nos. . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Resultados para o Spread com mensagens de 10 Kbytes . . . . . . . . . . . . . . . . . . . . . 29

3.7 Resultados para o Appia em um cluster de 4 nos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.8 Resultados para o Appia com mensagens de 10 Kbytes. . . . . . . . . . . . . . . . . . . . . . 30

3.9 JGroups e Appia vs. jGCS/Spread em um cluster de 4 nos. . . . . . . . . . . . . . . . . . . . 32

3.10 JGroups e Appia vs. jGCS/Hedera em um cluster de 4 nos. . . . . . . . . . . . . . . . . . . 32

4.1 Relacao entre a interface Message do jGCS e a classe G2CLMessage. . . . . . . . . . . 38

4.2 Exemplo de envio de uma mensagem atraves da classe MarshalDataSession. . . . 39

4.3 Classes envolvidas na implementacao do MessageDispatcher. . . . . . . . . . . . . . . . . 42

4.4 Classes envolvidas na implementacao do RpcDispatcher. . . . . . . . . . . . . . . . . . . . . 43

4.5 Classes envolvidas na implementacao do StateTransferDataSession. . . . . . . . . . . . 45

4.6 Classes envolvidas na implementacao do ReplicatedHashMap. . . . . . . . . . . . . . . . 46

x

4.7 Formato de um fragmento da mensagem utilizado pelo FragDataSession. . . . . . . 48

4.8 Formato da mensagem enviada pelo BundleDataSession. . . . . . . . . . . . . . . . . . . . . 49

5.1 Cenarios de acesso ao servico de alta disponibilidade do JOnAS. . . . . . . . . . . . . . . 53

5.2 Utilizacao do RPCDispatcher do JGroups na implementacao do registro dis-

tribuıdo do JOnAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3 Utilizacao do MessageDispatcher do JGroups na implementacao do mecanismo

de replicacao de objetos do JOnAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.4 Cenario de avaliacao do JOnAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5 Resultados para as duas versoes do JOnAS em funcao do aumento no numero

de requisicoes concorrentes, em um cluster com 6 servidores. . . . . . . . . . . . . . . . . 63

5.6 Resultados para as duas versoes do JOnAS em funcao do aumento no tamanho

do cluster de servidores, com 100 requisicoes concorrentes. . . . . . . . . . . . . . . . . . . 64

xi

Lista de Tabelas

3.1 Numero de bytes acrescentados pelo Hedera na camada de transporte. . . . . . . . . . 31

5.1 Numeros da migracao do servidor de aplicacao JOnAS. . . . . . . . . . . . . . . . . . . . . . 59

1

Capıtulo 1

Introducao

Este capıtulo apresenta as principais questoes que motivaram a realizacao deste trabalho, seus

objetivos e contribuicoes, e sua organizacao.

1.1 Motivacao

O desenvolvimento de aplicacoes distribuıdas requer uma serie de decisoes de projeto quanto

a arquitetura a ser utilizada. Embora diferentes modelos de arquitetura possam ser utilizados,

todos tem em comum o fato de serem compostos de processos que se comunicam por meio da

troca de mensagens enviadas atraves de uma rede de computadores (COULORIS et al., 2005).

Assim, a escolha da forma de comunicacao adequada e de como os processos irao interagir

desempenham um papel fundamental na implementacao dos requisitos do sistema.

Em se tratando de servicos tolerantes a falhas, a comunicacao em grupo destaca-se como um

importante mecanismo para implementar comunicacao entre os processos. Comunicacao em

grupo significa disponibilizar uma forma de envio de mensagens de um processo para outros

processos, que sao membros de um mesmo grupo. Os grupos sao identificados por um nome

logico, o que permite que um membro se comunique com os outros membros de seu grupo

enviando mensagens destinadas ao nome do grupo; um sistema de comunicacao em grupo

(SCG) se encarrega de entregar as mensagens, de forma confiavel, ordenada e transparente para

o remetente, para os outros membros (CHOCKLER et al., 2001).

Apesar de sua importancia, projetar e desenvolver um SCG e uma tarefa bastante complexa e de

alto custo. Diante disso, pesquisadores e desenvolvedores de sistemas distribuıdos tem criado

inumeros SCGs que implementam as funcionalidades basicas de comunicacao em grupo, alem

de diversos servicos de mais alto nıvel, e que podem ser facilmente reutilizados no desenvol-

vimento de aplicacoes distribuıdas. Os SCGs mais populares atualmente sao: JGroups (BAN,

1.1 Motivacao 2

1998), Spread (AMIR et al., 2000) e Appia (MIRANDA et al., 2001).

Apesar dos desenvolvedores de aplicacoes distribuıdas se beneficiarem dessa variedade de SCGs,

por exemplo, podendo selecionar o sistema que melhor satisfaz os requisitos e necessidades de

sua aplicacao, tambem se deparam com um novo desafio: qual SCG usar? Escolher um SCG

apropriado e uma importante decisao de projeto que pode ser dificultada pelo fato de que esses

sistemas apresentam grandes diferencas em relacao as funcionalidades que oferecem, incluindo

abstracoes de comunicacao, garantias de qualidade de servico e semanticas de entrega de men-

sagens (CHOCKLER et al., 2001). Alem disso, uma vez que um desenvolvedor opta por um

determinado SCG, sua aplicacao torna-se fortemente acoplada a API e aos servicos oferecidos

pelo sistema escolhido. Esse alto nıvel de acoplamento entre uma aplicacao e um determinado

SCG e indesejavel por pelo menos dois motivos: (i) requer mudancas no codigo fonte da aplica-

cao sempre que a API do SCG evolui; e, talvez o mais importante, (ii) pode vir a desencorajar os

desenvolvedores a experimentarem novos (e potencialmente mais eficientes) SCGs em futuras

versoes de suas aplicacoes.

Uma alternativa interessante para desacoplar uma aplicacao de um SCG especıfico e atraves do

uso de APIs genericas, como aquelas oferecidas por sistemas como Hedera (HEDERA, 2008),

jGCS (CARVALHO et al., 2006) e Shoal (SHOAL, 2008). Esses sistemas disponibilizam um

conjunto de interfaces genericas, a partir das quais, atraves de um mecanismo de plugin, dife-

rentes estrategias de comunicacao em grupo podem ser facilmente implementadas reutilizando

os servicos de diferentes SCGs existentes.

Embora diversos trabalhos sobre a analise de desempenho de SCGs especıficos ja tenham sido

publicados na literatura (ABDELLATIF et al., 2004; AMIR et al., 2004; BALDONI et al.,

2002), algumas questoes fundamentais referentes ao uso de APIs genericas ainda nao foram

completamente exploradas. Por exemplo: qual o impacto causado pelas APIs genericas sobre

os SCGs que elas encapsulam? Como esse impacto e influenciado por fatores como tamanho das

mensagens, quantidade de membros do grupo e o protocolo de transporte utilizado? Sera que

e possıvel obter algum ganho de desempenho ao substituir os servicos de um SCG especıfico

pelos servicos disponibilizados por uma API generica? Claramente, tais informacoes seriam

de grande utilidade para desenvolvedores de aplicacoes distribuıdas, que poderiam decidir de

forma mais confiavel sobre quando adotar um SCG especıfico ou quando migrar para uma

solucao generica.

Por serem solucoes relativamente maduras, os SCGs atuais ja evoluıram bastante desde as suas

primeiras versoes e passaram a fornecer nao apenas as funcionalidades basicas de comunicacao

em grupo, como envio de mensagens para o grupo e gerenciamento de membros, mas tambem

1.2 Objetivos 3

inumeras abstracoes de mais alto nıvel. Tais abstracoes sao tipicamente implementadas como

servicos oferecidos em uma camada acima da camada basica de envio/recebimento de mensa-

gens. Como exemplo desses servicos, podemos citar o envio de mensagens de forma sıncrona, a

transferencia de estado entre membros ou ate mesmo a invocacao remota de metodos em objetos

replicados (JGROUPS, 2009a).

O advento dessa camada de servicos de alto nıvel tem dificultado a migracao e a criacao de

aplicacoes baseadas em APIs genericas, uma vez que tais servicos nao sao implementados

por nenhum dos sistemas que atualmente oferecem APIs genericas. Dessa forma, para usu-

fruir completamente das APIs genericas atuais, os desenvolvedores precisariam implementar

sua propria camada de servicos de alto nıvel, o que nao deixaria de ser uma tarefa complexa,

suscetıvel a falhas e fora do escopo de qualquer aplicacao. Portanto, SCGs baseados em APIs

genericas deveriam oferecer, tambem, uma camada de servicos de alto nıvel. Isto nao apenas

simplificaria seu uso em aplicacoes reais, como reduziria o esforco e o tempo de desenvolvi-

mento, ja que os desenvolvedore estariam focados apenas nos requisitos especıficos de suas

aplicacoes.

1.2 Objetivos

Este trabalho tem como objetivo principal propor uma camada de servicos de alto nıvel para

uma API generica de comunicacao em grupo, a qual sera escolhida a partir de um estudo das

APIs genericas existentes, de forma que aplicacoes que necessitam desses servicos possam

facilmente migrar para essa API generica e usufruir de seus benefıcios.

Os objetivos especıficos a serem alcancados com esta abordagem incluem:

• Conduzir um estudo sobre as APIs genericas de comunicacao em grupo existentes, com

o objetivo de identificar a melhor opcao a ser estendida. Em tal estudo serao levados em

consideracao pontos como estrategias de implementacao, desempenho e a quantidade de

plugins existentes, dentre outros.

• Implementar uma camada de comunicacao em grupo de alto nıvel sobre a API generica

selecionada a partir do estudo realizado. Essa camada sera composta, inicialmente, por

um conjunto de servicos os quais serao escolhidos de acordo com as necessidades mais

comuns identificadas em aplicacoes reais.

• Elaborar um passo a passo para implementacao e inclusao de novos servicos a camada

proposta.

1.3 Contribuicoes 4

• Conduzir uma avaliacao preliminar da camada proposta e do impacto causado pelo seu

uso em um estudo de caso envolvendo uma sistema real de codigo aberto.

1.3 Contribuicoes

Para atingir os objetivos descritos acima, inicialmente realizamos um estudo detalhado sobre

duas das mais utilizadas APIs genericas de comunicacao em grupo existentes e o impacto que

elas causam no desempenho dos SCGs que encapsulam (SALES et al., 2008, 2009a, 2009b).

Alem disso, com base em uma pesquisa sobre os servicos e abstracoes de comunicacao em

grupo mais utilizados por diversas aplicacoes de codigo aberto que fazem uso de SCGs es-

pecıficos, projetamos e implementamos uma biblioteca de software, chamada Generic Group

Communication Layer (ou simplesmente G2CL), que funciona como uma camada extra sobre a

API generica escolhida a partir do estudo realizado, e que fornece um conjunto de servicos de

comunicacao em grupo de alto nıvel uteis para a implementacao de aplicacoes distribuıdas.

Por fim, elaboramos um passo a passo com dicas de como adicionar novos servicos a camada

proposta, de modo que a mesma possa ser facilmente estendida por qualquer desenvolvedor

interessado.

1.4 Estrutura da dissertacao

Alem desta Introducao, a dissertacao esta organizada em mais cinco capıtulos, descritos a seguir.

No Capıtulo 2, abordamos a comunicacao em grupo, com enfase nos principais conceitos en-

volvidos e nos sistemas e APIs genericas existentes.

No Capıtulo 3, avaliamos o impacto causado pelas APIs genericas para justificar a escolha da

API que servira de base para a implementacao da G2CL.

No Capıtulo 4, descrevemos o projeto e a implementacao dos servicos de alto nıvel escolhidos

para compor a implementacao inicial da G2CL, bem como um passo a passo para a sua extensao

com a inclusao de novos servicos.

No Capıtulo 5, relatamos o processo de migracao de um sistema distribuıdo real de codigo

aberto, que utilizava um SCG especıfico, para a G2CL, e avaliamos o impacto de desempenho

causado pelo uso da G2CL na nova versao do sistema.

No Capıtulo 6, concluımos o trabalho e oferecemos sugestoes para trabalhos futuros.

5

Capıtulo 2

Comunicacao em Grupo: Conceitos, Siste-mas e APIs Genericas

Este capıtulo apresenta os principais conceitos sobre comunicacao em grupo e tambem os prin-

cipais sistemas e APIs genericas que, atualmente, oferecem essa funcionalidade.

2.1 Conceitos

Sistemas distribuıdos precisam de uma forma confiavel de realizar a comunicacao entre seus

processos para garantir a correta execucao de suas funcionalidades. Em alguns casos, como

em aplicacoes tolerantes a falha ou que necessitam de balanceamento de carga, e necessario

aumentar ou diminuir a quantidade de processos em execucao de acordo com as caracterısticas

do ambiente de rede ou a variacao da demanda. Nesse contexto, realizar a comunicacao entre

os processos utilizando troca de mensagens aos pares nao e a melhor opcao, sendo necessario

um mecanismo para enviar mensagens de 1 processo para n processos de uma maneira simples,

transparente e segura para o remetente (COULORIS et al., 2005).

Comunicacao em grupo e a definicao para comunicacao multiponto, onde os processos sao

organizados logicamente em um grupo. Os processos que fazem parte de um grupo sao chama-

dos de membros do grupo. Cada grupo esta associado a um nome, de modo que os processos

se comunicam com o grupo simplesmente enviando mensagens para o nome do grupo. Cabe ao

sistema de comunicacao em grupo (SCG) entregar as mensagens de forma confiavel e ordenada

para os membros do grupo (CHOCKLER et al., 2001).

O conceito de comunicacao em grupo compartilha algumas das caracterısticas associadas a

outras tecnologias de comunicacao multiponto, como, por exemplo, sistemas orientados a men-

sagens (EUGSTER et al., 2003) e comunicacao por espaco de tuplas (GELERNTER, 1985). A

principal diferenca e que, como veremos mais adiante, a comunicacao em grupo oferece garan-

2.1 Conceitos 6

tias de entrega, ordenacao e atomicidade, que nao sao oferecidos por esses outros sistemas, que

tem um foco maior em desempenho. Alem disso, na comunicacao em grupo e o remetente que

indica quem deve receber uma determinada mensagens, ao contrario dos outros sistemas, onde

o receptor e quem indica as mensagens de seu interesse. Por fim, na comunicacao em grupo os

membros possuem informacoes de todos os membros ativos, podendo ter seu comportamento

influenciado por eles, enquanto que nos outros sistemas nem sempre a identidade dos membros

do grupo e conhecida pelos remetentes ou receptores de mensagens.

A implementacao de um SCG consiste basicamente na provisao de dois servicos principais: (i)

servico de gerenciamento de membros e (ii) servico de troca de mensagens. Esses dois servicos

estao fortemente relacionados, pois e necessario gerenciar os membros do grupo ao mesmo

tempo que ocorre a troca de mensagens. A seguir, detalhamos um pouco mais sobre cada um

desses servicos.

2.1.1 Servico de gerenciamento de membros

O principal objetivo do servico de gerenciamento de membros e manter uma lista dos processos

ativos e disponibilizar uma visao consistente do grupo para todos os processos.

Para atingir esse objetivo, o servico devera desempenhar as seguintes funcoes:

Manipulacao dos grupos: disponibilizar uma forma para criar e destruir grupos, e adicionar e

remover processos de um grupo. Como dito anteriormente, um grupo e identificado por

um nome.

Deteccao de falhas: oferecer um mecanismo de monitoramento de processos para detectar

possıveis saıdas nao voluntarias de um ou mais processos de seus respectivos grupos.

Essas falhas podem ser causadas por motivos externos, como, por exemplo, falhas de

comunicacao ou falhas inesperadas na aplicacao que impossibilitaram o processo de in-

formar a sua saıda. O servico de gerenciamento de membros utilizara o detector de falhas

para excluir um processo do grupo caso haja alguma suspeita de que ele tenha falhado ou

se tornado inacessıvel.

Notificacao sobre mudancas no grupo: informar aos membros sobre quaisquer mudancas re-

alizadas no grupo, notificando quando um novo processo for adicionado ou quando um

processo existente for excluıdo do grupo, independentemente se a exclusao for causada

por uma falha ou por uma saıda deliberada. Dessa forma, o servico deve garantir que, em

um determinado instante, todos os membros tenha uma visao consistente do grupo.

2.1 Conceitos 7

Alguns requisitos basicos para a notificacao de mudancas devem ser considerados: (i) se

um processo p recebe uma visao v e depois uma visao v’, nenhum processo q, sendo p

�= q, recebe v’ antes de v; (ii) se um processo p recebe uma visao v entao p ∈ v; e (iii)

se o processo p entra em um grupo e se torna acessıvel a partir de um processo q, entao

p estara sempre nas visoes recebidas por q e, analogamente, se um processo p se tornar

inacessıvel a partir de um processo q, entao p nao estara presente nas visoes recebidas por

q.

Alem disso, juntamente com o servico de troca de mensagens, o servico de gerenciamento

de membros podera garantir uma sincronia virtual entre os membros. Isso significa que

se uma mensagem m for enviada em uma visao v, essa mensagem devera ser entregue aos

outros processos antes do recebimento de uma nova visao v’.

2.1.2 Servico de troca de mensagens

O servico de troca de mensagens devera disponibilizar um mecanismo em que um processo

possa enviar uma mensagem direcionada a um grupo, identificado pelo seu nome, e a mensagem

ser entregue de forma transparente para todos os membros do grupo.

O servico podera disponibilizar diferentes semanticas para o envio das mensagens. Essencial-

mente, as seguintes semanticas podem ser oferecidas:

Confiabilidade e atomicidade: garantir que uma mensagem enviada por um membro sera en-

tregue para todos os membros do grupo, identica aquela que foi enviada e nao mais de

uma vez. Alem disso, caso algum membro nao receba uma determinada mensagem, o

servico de entrega garante que nenhum outro membro a recebera, ou seja, nao acontecem

entregas parciais de mensagens.

Ordem de entrega: fornecer formas diferentes de ordenacao na entrega das mensagens de

acordo com polıticas como: (i) fifo, onde se um processo p envia uma mensagem m para

o grupo e depois uma mensagem m’, todos os membros do grupo receberao m antes de

m’; (ii) causal, onde se um processo p recebe uma mensagem m e em seguida envia uma

mensagem m’ potencialmente causada pelo recebimento de m, entao todos os processos

receberao m antes de m’; e (iii) total, onde se um processo p recebe uma mensagem m

antes de m’, entao todos os processos receberao m antes de m’.

2.2 Sistemas de comunicacao em grupo 8

2.2 Sistemas de comunicacao em grupo

Diante da complexidade e da necessidade da implementacao de um mecanismo para comu-

nicacao em grupo, surgiram diversos sistemas que fornecem uma variada gama de servicos e

garantias de comunicacao em grupo e que podem ser reutilizados pelos desenvolvedores de

aplicacoes distribuıdas.

A utilizacao de um SCG reduz bastante o esforco de desenvolvimento de uma aplicacao dis-

tribuıda, alem de trazer uma grande economia de tempo, pois o desenvolvedor preocupa-se

apenas em utilizar os servicos disponibilizados, repassando toda responsabilidade referente a

comunicacao e ao gerenciamento do grupo para o SCG subjacente, sem ter que se preocupar

em como esses servicos sao realmente implementados.

Atualmente, ha diversos SCGs disponıveis, tanto comercialmente quanto de codigo aberto. Os

SCGs mais conhecidos e utilizados sao: JGroups (BAN, 1998), Spread (AMIR et al., 2000)

e Appia (MIRANDA et al., 2001). Todos os tres sistemas implementam os servicos basicos

de gerenciamento de membros e troca de mensagens, citados anteriormente, mas apresentam

tambem caracterısticas peculiares. A seguir, descrevemos, de forma breve, cada um deles.

2.2.1 JGroups

O JGroups (BAN, 1998) e um SCG totalmente escrito em Java e bastante completo no que diz

respeito aos servicos disponibilizados. Por esse motivo e, atualmente, o mais popular.

Alem de implementar os servicos essenciais de comunicacao em grupo, o JGroups fornece

inumeras outras facilidades e servicos para os desenvolvedores de aplicacoes distribuıdas, com

destaque para:

• A possibilidade de usar diferentes protocolos de transporte, como TCP e UDP sobre IP

Multicast;

• Fragmentacao de mensagens;

• Criptografia;

• Controle de fluxo;

• Transferencia de estado.

A principal caracterıstica do JGroups e sua pilha de protocolos flexıvel, que permite ao de-

senvolvedor, de uma forma bastante simples, adapta-la e configura-la da melhor maneira para


suprir as necessidades especıficas de sua aplicacao e de seu ambiente de rede. Alem disso, suas

inumeras possibilidades de combinacao desses protocolos permitem satisfazer as necessidades

de uma grande variedade de aplicacoes. O JGroups tambem oferece a possibilidade do desen-

volvedor implementar seus proprios protocolos e utiliza-los em conjunto com os ja disponıveis.

API

A API fornecida pelo JGroups referente aos servicos basicos de comunicacao em grupo e bas-

tante simples e facil de usar. Esta inclui uma interface chamada Channel, utilizada para enviar

e receber mensagens assıncronas, e monitorar as mudancas no grupo atraves do uso do padrao

Observador (GAMMA et al., 1995). A pilha de protocolos que sera utilizada pelo Channel e

configurada atraves de um arquivo XML externo; dessa forma, mudancas na sua configuracao

podem ser feitas sem necessidade de alteracao no codigo fonte da aplicacao. Atualmente, o

JGroups so disponibiliza uma unica implementacao dessa interface, chamada JChannel.

Embora o Channel do JGroups seja bastante completo no que se refere aos servicos basicos

de comunicacao em grupo que oferece, ainda assim pode ser considerado simples do ponto de

vista da sofisticacao desses servicos. Por esse motivo, o JGroups tambem prove uma camada de

servicos de mais alto nıvel, denominados building blocks, que encapsulam as funcionalidades

oferecidas pelo Channel, mantendo as suas garantias. Dessa forma, a aplicacao passa a contar

com APIs mais sofisticadas de comunicacao em grupo, alem da API basica de gerenciamento

de membros e troca de mensagens.

Figura 2.1: Arquitetura do JGroups.


A Figura 2.1 ilustra a arquitetura do JGroups, destacando a interacao entre a aplicacao, o Chan-

nel e os building blocks. Na pilha de protocolos representada por essa figura, o Channel esta

configurado para garantir ordenacao CAUSAL das mensagens. O protocolo GMS e responsavel

por gerenciar os membros do grupo e o MERGE procura evitar possıveis particionamentos no

grupo. O protocolo FRAG e responsavel por fragmentar mensagens que ultrapassem um deter-

minado tamanho e, por fim, o protocolo UDP indica o protocolo de transporte utilizado por essa

pilha.

A seguir, apresentamos uma breve descricao dos building blocks do JGroups que consideramos

mais relevantes para os programadores de aplicacoes distribuıdas.

MessageDispacther

Como ja vimos anteriormente, um Channel implementa apenas o envio e recebimento de men-

sagens de forma assıncrona, o que nao e suficiente para muitas aplicacoes que precisam que

seus membros se comuniquem de forma sıncrona. Por exemplo, um membro precisa enviar

uma mensagem para o grupo e aguardar que todos os outros membros respondam, ou entao,

precisa enviar uma mensagem e aguardar que pelo menos um membro responda.

O MessageDispatcher do JGroups oferece uma interface que torna possıvel o envio de mensa-

gens sıncronas atraves de um Channel. Alem disso, como mantem uma co-relacao requisicao-

resposta entre as mensagens, esse servico permite que um membro possa retornar uma resposta

para o membro que enviou uma requisicao. Dessa forma, cada membro do grupo funciona

ora como cliente, enviando requisicoes e recebendo respostas, ora como servidor, recebendo

requisicoes e enviando respostas. Com esse servico, tambem e possıvel configurar quantas

respostas o remetente deve aguardar para cada requisicao enviada para o grupo

RpcDispacther

O RpcDispatcher e uma extensao do servico MessageDispatcher. Ele permite que um membro

invoque remotamente um metodo nos outros membros de seu mesmo grupo. Assim como o

MessageDispatcher, o membro que utiliza o servico pode escolher de quantos membros deseja

esperar um retorno.

Para realizar a invocacao, a aplicacao precisa apenas informar o nome do metodo e em qual

objeto ele sera invocado, sendo possıvel inclusive passar parametros. O envio das mensagens,

assim como o uso do Channel, fica totalmente transparente para a aplicacao.


ReplicatedHashMap

O servico ReplicatedHashMap e uma implementacao distribuıda do tipo HashMap de Java, e

que utiliza como base o RpcDispatcher. Qualquer alteracao realizada em um objeto do tipo

ReplicatedHashMap em qualquer um dos membros do grupo e automaticamente replicada para

os demais. A chamada de metodos como put(), clear() ou remove() dispara invocacoes remotas

dos metodos correspondentes em todos os membros do grupo, atraves de uma instancia do

RpcDispatcher, e aguarda ate receber uma resposta de todos os membros antes de modificar

a copia local. Operacoes de leitura, como get(), sao feitas apenas localmente, ja que todas as

replicas possuem estados indenticos. A unica limitacao e que tanto as chaves como os valores a

serem adicionados precisam ser serializaveis, ja que serao embutidos nas mensagens enviadas

ao grupo quando uma invocacao remota for realizada.

Este servico e muito util para aplicacoes que precisam manter um estado comum entre os mem-

bros do grupo. Note que, para utiliza-lo, e necessario usar um protocolo de transferencia de

estado, pois quando um novo membro entra no grupo este precisa ser inicializado com o estado

identico ao dos outros membros para so depois comecar a receber requisicoes.

Versao e disponibilidade

Este trabalho utilizou a versao 2.6.10 do JGroups, disponıvel em http://www.jgroups.org.

2.2.2 Appia

O Appia (MIRANDA et al., 2001) e um framework para realizar comunicacao entre processos

tambem desenvolvido em Java. Assim como o JGroups, e bem flexıvel em relacao a composi-

cao da pilha de protocolos. Para essas composicoes, oferece inumeros protocolos prontos para

o uso, como por exemplo: comunicacao em grupo com sincronia virtual, deteccao de falhas,

comunicacao ponto-a-ponto, fragmentacao de mensagens, criptografia, etc. Alem desses proto-

colos, o desenvolvedor pode implementar seus proprios protocolos e incluı-los na composicao

de sua pilha.

A composicao de uma pilha de protocolos pode ser realizada diretamente pela aplicacao, atraves

de uma API propria oferecida pelo Appia, ou especificada em um arquivo XML externo a

aplicacao.

Apesar de fornecer um variado conjunto de servicos de comunicacao em grupo, o Appia nao

foi desenvolvido apenas para esse fim. Por esse motivo, o sistema nao possui uma API espe-


cificamente direcionada para comunicacao em grupo, tornando a configuracao e utilizacao de

sua pilha de protocolos mais complexa em comparacao ao JGroups. Uma das razoes e que o

usuario precisa tratar eventos em um nıvel de abstracao mais baixo, o que requer uma curva de

aprendizado bem maior por parte do desenvolvedor.

Mais especificamente, no Appia toda a comunicacao se da atraves do tratamento de eventos. Os

protocolos se comunicam entre si por meio de eventos e a aplicacao tambem se comunica com

os protocolos atraves de eventos. Para isso, a aplicacao precisa implementar um protocolo da

pilha de protocolos do Appia, o qual se comunicara com o resto da aplicacao atraves de eventos

definidos pelo usuario. Ou seja, no Appia uma aplicacao nada mais e do que um protocolo a

mais na sua pilha de protocolos. Dessa forma, para enviar e receber mensagens utilizando o

Appia uma aplicacao precisa gerar e tratar os eventos correspondentes na camada mais acima

da pilha de protocolos do Appia, que, como foi explicado anteriormente, e especıfica de cada

aplicacao.

API

A seguir, descrevem-se as principais classes disponibilizadas pela API do Appia:

Layer e a descricao estatica de um camada da pilha de protocolos do Appia. Possui informacoes

relevantes para a criacao de um elemento do tipo Session.

Session e a implementacao concreta de um elemento do tipo Layer. E a classe que implementa

como sera feito o tratamento de cada evento recebido.

QoS e a descricao estatica da pilha de protocolos. E representada por uma lista ordenada de

objetos do tipo Layer e indica as camadas que farao parte da pilha de protocolos.

Channel e a implementacao concreta da pilha de protocolos (QoS). E representada por uma

lista ordenada de objetos do tipo Session e indica o caminho que sera percorrido por um evento.

Event implementa um evento que trafega na pilha de protocolos (Channel), como, por exemplo,

mensagens da aplicacao e mensagens de controle de uma camada.

Cada camada possui uma representacao estatica (declaracao) e uma representacao dinamica

(implementacao). Na representacao estatica, o usuario define os eventos que a camada pode

receber, os que ela precisa receber e os que ela fornece. A definicao estatica de uma camada

permite que o Appia realize otimizacoes interessantes, como, por exemplo, calcular, no mo-

mento da inicializacao do sistema, as rotas que os eventos percorrerao na pilha de protocolos,

permitindo que um evento “pule” as camadas que nao estao interessadas nesse evento. Dessa


forma, um evento nao precisa, necessariamente, passar por todas as camadas sequencialmente.

Uma caracterıstica importante do Appia e que ele permite a composicao de pilhas complexas,

possibilitando que o usuario compartilhe camadas em diferentes Channels. Considere o exem-

plo de uma aplicacao multimıdia, conforme ilustrado na Figura 2.2. Para transmitir todas as

informacoes de dados, vıdeo e audio, a aplicacao precisaria de tres canais de comunicacao dife-

rente, pois cada canal exige um diferente protocolo de transporte. Apesar disso, as informacoes

dos tres canais precisam estar sincronizadas para que a aplicacao funcione corretamente. No

Appia, esses tres canais podem compartilhar uma camada de sincronismo que garante que as

informacoes vao ser entregues de forma consistente a aplicacao.

Figura 2.2: Exemplo de compartilhamento de camadas do Appia em uma aplicacao multimıdia.


Este trabalho utilizou a versao 4.1.0 do Appia, disponıvel em http://appia.di.fc.ul.pt.

2.2.3 Spread

O Spread (AMIR et al., 2000) e um sistema de comunicacao em grupo que prove alto desem-

penho e escalabilidade no envio de mensagens. Dentre os servicos oferecidos pelo Spread,

destacam-se:

• protocolos para ordenacao e garantia de entrega de mensagens;


• mecanismos para gerenciamento dos membros do grupo e deteccao de falhas;

• semanticas de sincronia virtual.

Uma caracterıstica que diferencia o Spread dos outros SCGs apresentados anteriormente e

a adocao de uma arquitetura hierarquizada de acordo com o modelo cliente-servidor. Para

conectar-se a um grupo, a aplicacao precisa se conectar a um servidor, chamado de Spread dae-

mon, que e responsavel por realizar toda a comunicacao entre os membros do grupo (um mesmo

daemon pode gerenciar varios grupos simultaneamente).

O Spread pode ser configurado para utilizar desde um unico daemon ate multiplos daemons na

rede, onde, no caso extremo, cada membro do grupo se conectaria a seu proprio daemon local.

Apesar de criar pontos de falha por possuir responsabilidades centralizadas em um servidor, a

utilizacao do daemon evita a execucao de protocolos de alto custo e/ou complexidade, como

ordenacao de mensagens, em todos os membros do grupo.

A Figura 2.3 ilustra a arquitetura cliente-servidor utilizada pelo Spread. Observe que apesar

de cada uma das maquinas executar varios processos que participam de um ou mais grupos, so

existe um daemon sendo executado em cada maquina. Na arquitetura do Spread nao existe uma

comunicacao direta entre os processos. A comunicacao e sempre feita atraves dos daemons.

Alem disso, diferentemente do JGroups e do Appia, o Spread nao permite que o usuario escolha

o protocolo de transporte que deseja utilizar para o envio de mensagens para o grupo, sempre

utilizando TCP quando a mensagem trafega entre os daemons e UDP quando trafega entre um

processo e o daemon ao qual esta conectado.

Figura 2.3: Arquitetura cliente-servidor do Spread.

2.3 APIs genericas de comunicacao em grupo 15

Embora seu componente daemon seja escrito na linguagem C, o Spread disponibiliza implemen-

tacoes deste componente para diversas plataformas, incluindo Unix/Linux e Windows. Alem

disso, disponibiliza APIs de acesso aos seus servicos em diversas linguagens de programacao,

como C++, C#, Java, Perl, Python e Ruby.

API Java

As principais classes da API Java do Spread sao descritas a seguir:

SpreadConnection e utilizada para estabelecer uma conexao com o Spread daemon e tambem

para enviar e receber mensagens do grupo.

SpreadGroup permite que a aplicacao entre e saia de um grupo.

SpreadMessage representa a mensagem a ser enviada para o grupo. Pode encapsular um array

de bytes ou um objeto do tipo serializavel, a escolha ficando a cargo da aplicacao. No Spread,

diferentemente de outros SCGs, as garantias de ordenacao e confiabilidade de uma mensagem

sao informadas na propria mensagem, no momento do envio, podendo assim ser diferentes para

cada mensagem. As mensagens de alteracao nos membros do grupo tambem sao representadas

por essa classe, as quais diferem das mensagens comuns atraves de um atributo que indica seu

tipo.


Este trabalho utilizou a versao 4.0 do Spread, disponıvel em http://www.spread.org/.

2.3 APIs genericas de comunicacao em grupo

Como vimos na secao anterior, os SCGs, alem de oferecerem diferentes API, oferecem tambem

diferentes servicos com diferentes garantias e semanticas. Com isso, os desenvolvedores pre-

cisam entender os mınimos detalhes envolvidos na implementacao de cada um dos SCGs e

os servicos que disponibilizam, para enfim poderem escolher o que melhor se adapta as suas

necessidades. Ao escolher um SCG especıfico, a aplicacao fica fortemente acoplada e depen-

dente desse SCG e de seus servicos, desencorajando, pelo esforco de refatoramento de codigo

envolvido, o experimento de novos protocolos em futuras versoes da aplicacao.

Uma solucao cada vez mais utilizada para desacoplar uma aplicacao distribuıda de sistemas de

middleware especıficos consiste na utilizacao de APIs genericas (DABEK et al., 2003; PIET-


ZUCH et al., 2007). No contexto da comunicacao em grupo, atualmente as principais APIs

genericas disponıveis sao oferecidas pelos sistemas Hedera (HEDERA, 2008), jGCS (CARVA-

LHO et al., 2006) e Shoal (SHOAL, 2008).

Seguindo a implementacao do padrao de projeto Strategy (GAMMA et al., 1995), cada um des-

ses sistemas disponibiliza um conjunto de interfaces genericas e um mecanismo de plugin que

permitem que diferentes estrategias de comunicacao em grupo sejam facilmente implementadas

(re)utilizando os servicos especıficos fornecidos por diferentes SCGs existentes. Dessa forma,

ao utilizar uma API generica de comunicacao em grupo, o desenvolvedor pode facilmente es-

colher o SCG que melhor atende as suas necessidades, e altera-lo sempre que necessario de

acordo com o contexto onde sua aplicacao esta inserida, bastando, para isso, substituir o SCG

subjacente atraves do mecanismo de plugin fornecidos pela API generica.

2.3.1 jGCS

O Group Communication Service for Java (CARVALHO et al., 2006), ou simplesmente jGCS,

e um framework de comunicacao em grupo desenvolvido em Java cujo objetivo e fornecer uma

API comum para diferentes SCGs existentes, possibilitando a reutilizacao dos servicos basicos

de comunicacao em grupo fornecidos por esses sistemas.

A API do jGCS e dividida em 4 conjuntos de interfaces complementares: interfaces de configu-

racao, interfaces comuns, interfaces de troca de mensagens e interfaces de gerenciamento dos

grupos. A seguir, descrevem-se cada um desses conjuntos.

Interfaces de configuracao

Apoiando-se na ideia da separacao de configuracao e uso, do padrao de projeto Inversion of

control – IoC (FOWLER, 2004), as interfaces de configuracao do jGCS desacoplam a aplicacao

de interesses relacionados ao mecanismo de comunicacao em grupo, como a configuracao do

grupo e as especificacoes de garantias de entrega das mensagens. O SCG que sera utilizado deve

ser informado em tempo de configuracao. Em tempo de execucao, os servicos de comunicacao

em grupo do jGCS sao devidamente instanciados de acordo com a configuracao especificada,

seja atraves de um mecanismo de injecao de dependencia (FOWLER, 2004) seja pela utilizacao

de um ServiceLocator (ALUR et al., 2001).

As principais interfaces desse conjunto sao descritas a seguir:

ProtocolFactory implementa o padrao Abstract Factory (GAMMA et al., 1995), permitindo a


inicializacao de uma instancia de um protocolo de acordo com a configuracao do plugin asso-

ciado.

GroupConfiguration encapsula informacoes sobre o grupo, como, por exemplo, o nome do

grupo, e e usada como parametro para abrir sessoes que permitirao a troca de mensagens e

monitoramento dos membros do grupo.

Service encapsula as especificacoes das garantias a serem utilizadas para o envio de mensagens.

Interfaces comuns

Esse conjunto representa as interfaces que sao comuns a todos os outros conjuntos. A principal

interface desse conjunto e a Protocol, que e criada pela interface ProtocolFactory do conjunto

de interfaces de configuracao. Atraves dela e possıvel criar, para uma determinada instancia de

GroupConfiguration, as instancias das classes responsaveis pela troca de mensagens e gerenci-

amento dos membros do grupo, DataSession e ControlSession, respectivamente, apresentadas

a seguir.

Interfaces de troca de mensagens

Esse conjunto disponibiliza as interfaces necessarias para o envio e recebimento de mensagens.

As principais interfaces desse conjunto sao descritas abaixo:

DataSession e responsavel pelo envio de mensagens, tanto via multicast como ponto-a-ponto.

Atraves dela tambem e possıvel registrar Observadores (GAMMA et al., 1995) para tratar o

recebimento de mensagens.

Message e responsavel por encapsular a mensagem que sera enviada e o endereco do remetente.

Com o objetivo de evitar gargalos na serializacao e o envio de dados desnecessarios, o corpo

da mensagem e sempre representado por um array de bytes, com o processo de serializacao

ficando sob responsabilidade da aplicacao.

MessageListener deve ser implementada pelos interessados em receber mensagens de um grupo,

que, para isso, deverao se registrar em um DataSession.

Interfaces de gerenciamento dos grupos

Estas interfaces disponibilizam um mecanismo de gerenciamento de grupos, desde simples

notificacoes sobre entrada e saıda de membros, para o caso de aplicacoes que nao estejam


necessariamente relacionadas com comunicacao em grupo, ao recebimento de novas visoes. O

suporte para sincronia virtual esta previsto, mas sua disponibilidade vai depender do SCG e do

plugin utilizado.

As principais interfaces desse conjunto sao:

ControlSession disponibiliza metodos para um membro entrar e sair de um grupo, alem de

possibilitar o registro de Observadores para o recebimento de notificacoes referentes a entrada,

saıda e falha de membros.

ControlListener deve ser implementada pelos interessados em receber notificacoes de entrada,

saıda e falha de membros, que, para isso, deverao se registrar em um ControlSession.

Para aplicacoes que desejam mais informacoes sobre as visoes do grupo, as seguintes interfaces

sao disponibilizadas.

MembershipSession e uma extensao da interface ControlSession. Atraves dela e possıvel obter

a lista dos membros atualmente conectados ao grupo. Permite tambem o registro de Observa-

dores para o recebimento de mudancas de visoes.

MembershipListener deve ser implementada pelos interessados em receber notificacoes de mu-

dancas de visoes, que, para isso, deverao se registrar em um MembershipSession.

A Figura 2.4 mostra um diagrama de sequencia que exemplifica as iteracoes entre as inter-

faces do jGCS necessarias para implementar o envio de uma mensagem para o grupo por

uma aplicacao. Os passos 1, 2 e 3 do diagrama representam a instanciacao das interfaces de

configuracao. Nesse exemplo, isto e feita atraves de um ServiceLocator, que le um arquivo de

configuracao e entao cria os objetos correspondente. O passo 4 mostra a criacao de um Proto-

col, que, como ja vimos, e utilizado para criar o DataSession e o ControlSession (passos 5 e 6,

respectivamente). No passo 7, a aplicacao se conecta ao grupo. As configuracoes referente ao

grupo que ela esta se conectando estao encapsuladas na classe GroupConfiguration, que foi uti-

lizada para a criacao do ControlSession. Em seguida, a aplicacao registra um MessageListener

para receber as mensagens do grupo. No passo 9, a mensagem a ser enviada e criada atraves

da classe DataSession, para que ela esteja de acordo com o plugin configurado. No passo 10,

a mensagem e enviada para o grupo. O passo 10.1 representa o momento em que o plugin

repassa a chamada de envio da mensagem para o SCG escolhido pela aplicacao. Finalmente,

no passo 11, o SCG recebe a mensagem e notifica o plugin do jGCS, que por sua vez repassa a

mensagem para a aplicacao.


Figura 2.4: Interacoes entre as interfaces do jGCS durante o envio de uma mensagem.


Este trabalho utilizou a versao 0.6.1 do jGCS, disponıvel em http://jgcs.sourceforge.

net/. Esta versao oferece plugins para os seguintes sistemas: JGroups, Spread e Appia, alem

de implementacoes de referencia para NEeM (PEREIRA et al., 2003) e UDP sobre IP Multicast.

2.3.2 Hedera

O Hedera (HEDERA, 2008) e outro framework de comunicacao em grupo de codigo aberto

desenvolvido em Java com o mesmo objetivo do jGCS, ou seja, fornecer uma API generica

para diferentes SCGs existentes. Seu desenvolvimento foi especificamente direcionado para

ambientes de cluster, onde os membros do grupo sao relativamente estaveis e os grupos sao de

tamanhos moderados (LODI et al., 2007).

A API do Hedera referente aos servicos basicos de comunicacao em grupo, como gerencia-


mento de grupo e troca de mensagens, se concentra em 3 classes principais:

AbstractGroupMembershipService e responsavel por encapsular os servicos referentes ao ge-

renciamento dos grupos. Operacoes como entrar e sair de um grupo podem ser realizadas

atraves dessa classe. O metodo para se conectar ao grupo recebe um objeto da classe Grou-

pIdentifier, utilizado para identificar o grupo a se conectar. Alem disso, essa classe permite

registrar um Observador do tipo GroupMembershipListener para receber notificacoes sobre en-

trada, saıda e falhas de membros e tambem sobre o particionamento de rede.

AbstractReliableGroupChannel e utilizada pela aplicacao para realizar a troca de mensagens

entre os membros de um grupo. Irrestrita em relacao ao tipo da mensagem enviada, essa classe

permite a aplicacao enviar qualquer objeto serializavel. O mecanismo padrao para o recebi-

mento de mensagens e atraves da estrategia de polling, onde a aplicacao e responsavel por peri-

odicamente buscar as mensagens que tenham sido recebidas ao inves de receber uma notificacao

direta sobre sua chegada.

AbstractGroupCommunicationFactory implementa o padrao Abstract Factory, sendo respon-

savel pela criacao dos objetos das interfaces AbstractGroupMembershipService e AbstractRe-

liableGroupChannel, de acordo com o plugin escolhido. A criacao do objeto referente a essa

classe e feita atraves de um metodo da propria classe, que recebe um objeto representando um

conjunto de propriedades como parametro, onde uma das propriedades indica qual classe deve

ser instanciada.

A Figura 2.5 mostra um diagrama de sequencia que exemplifica as interacoes entre as inter-

faces do Hedera necessarias para implementar o envio de uma mensagem para o grupo por

uma aplicacao. Nesse diagrama, o passo 1 indica a instanciacao do plugin atraves da classe

AbstractGroupCommunicationFactory. O passo seguinte mostra a criacao do objeto utilizado

para identificar o grupo ao qual o membro vai se conectar. No passo 3, sao criados os obje-

tos AbstractReliableGroupChannel e AbstractGroupMembershipService, que serao utilizados

mais adiante para conectar e enviar uma mensagem ao grupo (passos 4 e 5, respectivamente).

Note que, no envio da mensagem, e possıvel informar uma lista de membros que devem receber

aquela mensagem; caso todos devam receber, nada precisa ser informado. O passo 5.1 mostra

o momento em que o plugin repassa o envio da mensagem para o SCG utilizado. Finalmente,

os passos 6 e 6.1 mostram o uso do mecanismo de polling para buscar as mensagens recebidas.

Assim como o JGroups, o Hedera disponibiliza abstracoes de mais alto nıvel implementadas a

partir de sua API basica. Sao elas: PullPushAdapter, que oferece uma maneira da aplicacao

ser notificada sobre o recebimento de mensagens atraves de Observadores; e MulticastReques-

tAdapter, que oferece uma funcionalidade similar ao servico MessageDispacther do JGroups,


Figura 2.5: Interacao entre as interfaces do Hedera durante o envio de uma mensagem.

possibilitando o envio de mensagens sıncronas ao grupo.


Este trabalho utilizou a versao 2.0 do Hedera, disponıvel em http://hederagc.sourceforge.

net/. Esta versao oferece plugins para os seguintes sistemas: JGroups, Spread e Appia.

2.3.3 Shoal

O Shoal (SHOAL, 2008) tambem e um SCG escrito em Java com o objetivo de oferecer uma

camada de abstracao para a comunicacao entre grupos de processos. Esse sistema foi desenvol-

vido especialmente para ser utilizado no cenario de cluster de servidores JEE (GLASSFISH,

2008) e, por esse motivo, preve em sua API operacoes referentes a servicos de alto nıvel como

a manutencao de um estado distribuıdo entre os membros do grupo.

Embora seja razoavelmente completo em termos dos servicos que implementa, o Shoal ainda

nao oferece plugins para os principais SCGs existentes, como JGroups e Appia, motivo pelo

qual foi excluıdo de nosso estudo. Alem disso, sua unica implementacao de referencia e baseada

na tecnologia JXTA (JXTA, 2008), muito utilizada na implementacao de aplicacoes peer-to-

peer (P2P). Apesar de JXTA permitir implementar comunicacao entre grupo de processos, seus

protocolos nao oferecem garantias importantes relativas a entrega e ordenacao de mensagens, o

2.4 Sumario 22

que impossibilitaria a comparacao da atual versao do Shoal com outros SCGs.

2.4 Sumario

Neste capıtulo, abordamos os principais conceitos sobre comunicacao em grupo e os principais

sistemas que dao suporte ao desenvolvimento de aplicacoes distribuıdas baseadas nessa forma

de comunicacao.

Ao descrevermos as principais caracterısticas de cada um dos sistemas apresentados, pudemos

perceber suas semelhancas e diferencas, tanto em relacao a variedade e ao nıvel de abstracao

dos servicos implementados quanto as garantias e semanticas oferecidas. Vimos, tambem, como

cada um desses sistemas possui uma API propria, o que torna impraticavel para o desenvolve-

dor de uma aplicacao distribuıda trocar de mecanismo de comunicacao em grupo a cada novo

cenario de uso.

Em seguida, vimos como funcionam os principais sistemas genericos de comunicacao em grupo

e como eles podem beneficiar aplicacoes que desejam ficar desacopladas de um sistema es-

pecıfico.

No proximo capıtulo, apresentaremos um estudo do impacto de desempenho causado pela

utilizacao de dois desses sistemas genericos, quando utilizados sobre diferentes sistemas de

comunicacao em grupo existentes.

23

Capıtulo 3

Avaliacao do Impacto de Desempenho deDuas APIs Genericas de Comunicacao emGrupo

Este capıtulo apresenta uma avaliacao do impacto causado pelas APIs genericas do jGCS e do

Hedera no desempenho de tres sistemas de comunicacao em grupo descritos no capıtulo ante-

rior: JGroups, Spread e Appia. A avaliacao compara o desempenho de diferentes configuracoes

dos tres SCGs em um ambiente de cluster local, sob diferentes tamanhos de mensagens e dife-

rentes tamanhos de cluster.

O restante do capıtulo esta organizado da maneira a seguir. A Secao 3.1 descreve o metodo

de avaliacao adotado e a Secao 3.2 apresenta os resultados obtidos. Algumas implicacoes do

estudo realizado sao discutidas na Secao 3.3. Finalmente, a Secao 3.4 encerra o capıtulo com

um sumario do conteudo apresentado.

3.1 Metodo de avaliacao

A avaliacao foi realizada em um ambiente de cluster local, composto por seis computadores

conectados atraves de um switch dedicado de 10/100 Mbps do tipo FastEthernet. Cada um dos

computadores do cluster possuıa a seguinte configuracao: sistema operacional Linux Debian,

versao 5.0 (kernel 2.6.26-2-686); processador Intel Pentium IV (3.00 GHz); memoria RAM de

2 GB (DDR2); e Maquina Virtual Java da SUN, versao 1.6.0 12 (executada no modo servidor).

Para executar os experimentos, estendemos a aplicacao Java desenvolvida pela equipe do JGroups

para seus testes de desempenho (JGROUPS, 2009b). A extensao realizada consistiu na modi-

ficacao do codigo fonte da aplicacao para que ela pudesse funcionar com os outros sistemas

considerados no estudo, isto e, Spread (atraves de sua API Java), Appia, Hedera e jGCS.

3.1 Metodo de avaliacao 24

Em cada experimento, a nova versao da aplicacao de teste foi executada em cada um dos nos do

cluster, de modo a enviar concorrentemente 1000 mensagens de tamanhos iguais para todos os

membros do grupo. Esse cenario de comunicacao foi escolhido para simular um ambiente de

replicacao Java EE de alta disponibilidade, onde servidores replicados propagam suas alteracoes

de estados para todos os membros do grupo de servidores (LODI et al., 2007).

Foram executados diferentes conjuntos de experimentos para o JGroups, Spread e Appia, com

todos sendo avaliados tanto isoladamente quanto atraves de seus plugi-ns para o Hedera e jGCS.

Alem disso, variou-se o tamanho do cluster entre dois, quatro e seis nos. Cada experimento uti-

lizou diferentes tamanhos de mensagens, definidos de acordo com o seguinte intervalo: 10, 100,

1000 e 10000 bytes. Esse valores foram escolhidos para que se pudesse observar o comporta-

mento dos cinco sistemas em um amplo espectro de tamanhos possıveis de mensagens.1

Para a avaliacao do JGroups, foram utilizadas duas configuracoes, cada uma com um diferente

protocolo de transporte: uma configuracao utilizando UDP sobre IP Multicast e a outra, TCP.

Nas duas configuracoes, foi utilizado o mesmo protocolo de ordenacao total de mensagens,

SEQUENCER, com as opcoes de fragmentacao e bundle de mensagens desabilitadas. Os outros

parametros de configuracao foram definidos de acordo com os valores dos parametros utilizados

nos testes originais de desempenho do JGroups (JGROUPS, 2009b).

No caso do Appia, foi avaliada uma unica configuracao, utilizando TCP como protocolo de

transporte e realizando a entrega de mensagens com garantia de ordenacao total.

No caso do Spread, tambem foi avaliada apenas uma configuracao, com TCP como proto-

colo de transporte (ver Secao 2.2.3) e entrega de mensagens com garantia de ordenacao total.

A configuracao do Spread utilizada nos experimentos possuıa uma arquitetura completamente

descentralizada, com um servidor (daemon) executando em cada um dos nos (membros do

grupo).

Finalmente, foi utilizada a taxa de entrega de mensagens por no como metrica de desempe-

nho (JAIN, 1991). Neste estudo, essa metrica foi computada calculando o numero medio de

mensagens entregues por segundo em cada um dos nos, por experimento. Para atingir um inter-

valo de confianca de 95% nos resultados, cada experimento foi repetido no mınimo 30 vezes,

com valores extremos (outliers) sendo removidos seguindo o metodo boxplots (TRIOLA, 1997).

Em todos os graficos mostrados neste capıtulo, bem como no Capıtulo 5, os intervalos de

confianca foram representados atraves de um par de linhas horizontais desenhadas acima e

abaixo do topo de cada uma das barras de resultado.1Uma faixa similar de tamanhos de mensagens tambem foi usado em uma avaliacao anterior do JGroups no

contexto de servidores de aplicacao J2EE (ABDELLATIF et al., 2004)

3.2 Resultados 25

3.2 Resultados

Primeiramente, mostramos o impacto de desempenho imposto pelas duas APIs genericas sobre

cada um dos tres SCGs investigados. Em seguida, correlacionamos esses resultados com uma

analise da forma como as mensagens sao transmitidas na camada de transporte por cada uma

das APIs genericas, em uma tentativa de explicar suas diferencas de desempenho.

Alem disso, pelo fato do Spread ser conhecido como uma sistema de melhor desempenho

que JGroups e Appia para determinados tamanhos de mensagem (BALDONI et al., 2002),

tambem fizemos uma comparacao dos resultados obtidos com o Appia e as duas configuracoes

do JGroups, em seu modo padrao, contra os resultados obtidos com o Spread quando utilizado

com o plugin para o jGCS e o Hedera. O objetivo dessa comparacao foi investigar se vale-

ria a pena, do ponto de vista estritamente de desempenho, migrar de uma solucao baseada no

JGroups ou Appia, em seu modo padrao, para uma API generica implementada sobre o Spread.

3.2.1 Impacto das APIs genericas sobre o JGroups

As Figuras 3.1 e 3.2 mostram as medias das taxas de entrega observadas para o JGroups nas

configuracoes UDP e TCP, respectivamente, em um cluster de 4 nos, para os 4 tamanhos de

mensagem investigados, tanto em seu modo padrao como quando utilizadas atraves de seus

plugins para o Hedera e jGCS.

Figura 3.1: Resultados para a configuracao JGroups-UDP em um cluster de 4 nos.

Como podemos ver por essas duas figuras, para mensagens de ate 100 bytes, o impacto do jGCS

sobre o JGroups, em qualquer uma das duas configuracoes, e relativamente pequeno, com o

3.2 Resultados 26

Figura 3.2: Resultados para a configuracao JGroups-TCP em um cluster de 4 nos.

jGCS entregando, em media, 10-12% menos mensagens que o JGroups em seu modo padrao.

Uma notavel excecao foi observada para a configuracao UDP com mensagens de tamanho 1000

bytes, onde a taxa de entrega do jGCS e 20% menor que a do JGroups em seu modo padrao. O

Hedera, por outro lado, impoe um maior impacto sobre o desempenho das duas configuracoes

do JGroups, para o mesmo intervalo de tamanho de mensagens, com o primeiro entregando 45-

60% menos mensagens que o JGroups em seu modo padrao. A razao para o pior desempenho

do Hedera e discutido mais adiante na Secao 3.2.4. Esses resultados tambem indicam que as

duas APIs genericas podem estar gerando um impacto de desempenho praticamente constante

para os mesmos tamanhos de mensagem.

Para mensagens maiores (na ordem de alguns milhares de bytes), observamos uma acentuada

queda de desempenho para os tres sistemas, com suas diferencas de desempenho caindo para

menos de 12%(configuracao TCP) ou 28%(configuracao UDP). Note que a queda e ainda maior

para a configuracao TCP, onde as taxas de entrega dos tres sistemas caıram rapidamente abaixo

da marca de menos de 500 mensagens por segundo. A esses resultados, atribuımos o fato de

que, a medida que cresce o tamanho das mensagens, cresce tambem o overhead causado pelo

trafego de mensagens na rede (devido em grande parte ao aumento da taxa de fragmentacao de

mensagens que acontece nas camadas de transporte e de rede), com esse ultimo finalmente pas-

sando a dominar o overhead imposto na camada de aplicacao por cada uma das APIs genericas.

Dada a significativa queda de desempenho observada para todos os tres sistemas com mensa-

gens maiores, tambem investigamos como as duas configuracoes do JGroups escalariam com

mensagens de 10 Kbytes (o maior tamanho investigado) em clusters com tamanhos variando en-

tre 2, 4 e 6 nos. Os resultados para as configuracoes UDP e TCP sao mostrados nas Figuras 3.3

3.2 Resultados 27

e 3.4, respectivamente. Nessas figuras, podemos observar que a configuracao UDP oferece

uma melhor escalabilidade, com seu desempenho ficando praticamente inalterado atraves dos

tres tamanhos de cluster. A configuracao TCP, por outro lado, oferece baixa escalabilidade,

com seu desempenho caindo rapidamente conforme o tamanho do cluster cresce. Isso se deve

provavelmente ao fato de que, na configuracao TCP, para enviar uma mensagem para o grupo,

o JGroups faz uma conexao ponto-a-ponto entre o remetente e cada um dos outros membros.

Dessa forma, a medida que o grupo cresce, aumenta o numero de conexoes que devem ser ge-

renciadas pelo JGroups, afetando negativamente a escalabilidade dessa configuracao. No caso

da configuracao UDP, o uso de um endereco de multicast da rede para a comunicacao com os

membros do grupo elimina a necessidade de manter conexoes individuais com cada membro,

garantindo, assim, uma maior escalabilidade no envio das mensagens ao grupo.

Figura 3.3: Resultados para a configuracao JGroups-UDP com mensagens de 10 Kbytes.

3.2.2 Impacto das APIs genericas sobre o Spread

A Figura 3.5 mostra as medias das taxas de entrega de mensagens observadas para o Spread,

em um cluster de 4 nos, para os 4 tamanhos de mensagens, tanto em seu modo padrao como

quando utilizado atraves de seu plugin para os dois sistemas genericos.

Assim como nas duas configuracoes do JGroups, o impacto causado pelo jGCS sobre o Spread

mostrou-se consideravelmente menor que o do Hedera, com o plugin do jGCS para o Spread

entregando entre 15-30% menos mensagens que o Spread na sua forma padrao para mensagens

de ate 1000 bytes. Ja o desempenho do Hedera foi ainda pior, com seu plugin para o Spread

entregando entre 80-85% menos mensagens que o Spread na sua forma padrao, com mensagens

de ate 100 bytes, e 45% menos com mensagens de 1000 bytes.

3.2 Resultados 28

Figura 3.4: Resultados para a configuracao JGroups-TCP com mensagens de10 Kbytes.

Figura 3.5: Resultados para o Spread em um cluster de 4 nos.

Por outro lado, o Spread se mostrou bem menos eficiente que o JGroups para a entrega de men-

sagens maiores, com seu desempenho caindo drasticamente (seja no modo padrao ou atraves de

seus plugins) quando o tamanho das mensagens se aproxima de 1000 bytes. Para mensagens

de 10 Kbytes, o desempenho do Spread cai ainda mais, com o impacto causado pelas APIs

genericas sendo completamente dominado pelo overhead imposto pela rede.

Esses resultados corroboram os resultados observados com o JGroups, indicando que a duas

APIs genericas podem estar gerando um impacto praticamente constante para os mesmos tama-

nhos de mensagem. Outra conclusao e que o impacto imposto pelas duas APIs genericas nao

e dependente de uma implementacao particular de um plugin, e que pode ser observada com

multiplos SCGs, como sera visto novamente com o Appia na proxima subsecao.

3.2 Resultados 29

Figura 3.6: Resultados para o Spread com mensagens de 10 Kbytes

Em relacao a variacao do tamanho do cluster com mensagens de 10 Kbytes, o Spread se mostrou

ainda menos escalavel que o JGroups. Como pode ser visto na Figura 3.6, o desempenho do

Spread e de seus dois plugins cai abruptamente para abaixo da marca de 300 mensagens por

segundo assim que o tamanho do cluster cresce de dois para quatro nos, permanecendo nesse

mesmo patamar para o cluster de 6 nos.

3.2.3 Impacto das APIs genericas sobre o Appia

A Figura 3.7 mostra a media das taxas de entrega de mensagens observadas para o Appia e seus

dois plugins, em um cluster de 4 nos, com os 4 tamanhos de mensagem. Nessa figura, podemos

observar que o impacto do jGCS sobre o Appia e praticamente inexistente para qualquer dos

4 tamanhos de mensagem, enquanto o impacto causado pelo Hedera e substancial, com esse

ultimo entregando cerca de 30-40% menos mensagens que o Appia, em seu modo padrao,

quando utiliza-se mensagens maiores que 1000 bytes.

Assim como os outros SCGs, o Appia e seus dois plugins tambem sofrem grandes perdas de

desempenho com mensagens de 10 Kbytes, com suas taxas de entrega caindo para quase 25%

do desempenho observado com mensagens menores.

Sobre a sua escalabilidade em relacao ao crescimento do tamanho do cluster, a Figura 3.8

mostra que o Appia tem um comportamento similar ao da configuracao TCP do JGroups, com

seu desempenho e de seus dois plugins caindo gradualmente conforme aumenta o tamanho do

cluster.

3.2 Resultados 30

Figura 3.7: Resultados para o Appia em um cluster de 4 nos.

Figura 3.8: Resultados para o Appia com mensagens de 10 Kbytes.

3.2.4 Impacto da camada de Transporte

Para investigar a possıvel causa do grande impacto imposto pelo Hedera em comparacao ao

jGCS, particularmente para mensagens pequenas, foi realizada uma comparacao entre os tama-

nhos das mensagens enviadas por cada API generica, na camada da aplicacao, e os tamanhos

da mensagens realmente enviadas pelo SCG subjacente, na camada de transporte, considerando

os tres tamanhos de cluster. Essa analise revelou que, na camada de transporte, o Hedera sem-

pre adiciona um numero significativo de bytes a todas as mensagens originalmente geradas na

camada de aplicacao, enquanto o mesmo fenomeno nao foi observado com o jGCS. O numero

de bytes extras acrescentados pelo Hedera na camada de transporte para cada um dos sistemas

e tamanhos de cluster investigados e representado na Tabela 3.1.

3.2 Resultados 31

Tabela 3.1: Numero de bytes acrescentados pelo Hedera na camada de transporte.

pluginTamanho do cluster Appia JGroups-UDP JGroups-TCP Spread

2 1044 1042 1051 7254 1180 1146 1155 8936 1316 1250 1259 1061

Nessa tabela, ve-se claramente que, na camada de transporte, todos os plugins do Hedera sem-

pre enviam mensagens que sao consideravelmente maiores que as mensagens originalmente

enviadas pela aplicacao. Mais precisamente, o Hedera sempre adiciona entre 725 e 1316 bytes

adicionais a cada mensagem da aplicacao, dependendo do numero de nos (membros do grupo)

no cluster e o do plugin utilizado.

Uma inspecao mais minuciosa do codigo fonte do Hedera revelou que esses bytes adicionais

representam dados de controle, gerados por seu mecanismo de plugin, para armazenar, entre

outras informacoes, os identificadores dos membros do grupo. Esses identificadores sao uti-

lizados por uma funcionalidade oferecida pelo Hedera atraves da qual e possıvel enviar uma

mensagem para apenas um subgrupo de membros. Apesar de ser uma funcionalidade util e que

nao e oferecida pelo jGCS, a sua implementacao fere o princıpio “somente pague pelo que voce

usa” (MACLENNAN, 1999). Isto porque o custo de enviar esses bytes adicionais e distribuıdo

para todas as aplicacoes, independente se essa funcionalidade vai ser usada ou nao. Assim,

acreditamos que um importante passo para reduzir o impacto de desempenho da atual versao do

Hedera seria eliminando ou pelo menos diminuindo drasticamente o seu overhead na camada

de transporte.

3.2.5 Impacto da migracao para uma API generica

Como dissemos anteriormente, pelo fato do Spread oferecer um melhor desempenho que o

JGroups e o Appia, particularmente para mensagens menores, seria interessante investigar as

condicoes nas quais valeria a pena migrar de uma solucao baseada no Appia ou no JGroups,

quando utilizados de forma isolada, para uma API generica baseada no Spread. Em outras

palavras, e importante investigar se a melhora de desempenho introduzida pelo Spread e sufici-

ente para compensar o impacto de processamento e de comunicacao imposto pelo uso da API

generica.

As Figuras 3.9 e 3.10 mostram as medias das taxas de entrega de mensagens observadas para os

plugins do jGCS e do Hedera para o Spread, respectivamente, em um cluster de 4 nos, contra os

mesmos valores obtidos com o Appia e as duas configuracoes do JGroups, todas em seu modo

3.2 Resultados 32

padrao.

Figura 3.9: JGroups e Appia vs. jGCS/Spread em um cluster de 4 nos.

Figura 3.10: JGroups e Appia vs. jGCS/Hedera em um cluster de 4 nos.

Na Figura 3.9, podemos observar que, para mensagens acima de 100 bytes, o plugin do jGCS

para o Spread consegue entregar cerca de 3 vezes mais mensagens que as duas configuracoes

do JGroups, e cerca de 4-5 vezes mais mensagens que o Appia. Por outro lado, a Figura 3.10

mostra que, para o mesmo intervalo de tamanhos de mensagens, o plugin do Hedera para o

Spread entrega uma quantidade um pouco menor de mensagens que as duas configuracoes do

JGroups, com um desempenho similar ao do Appia. Para mensagens de 1000 bytes, o mesmo

plugin do Hedera apresenta uma queda de desempenho ainda maior quando comparada a do

JGroups e do Appia em seu modo padrao.

Em essencia, os resultados das Figuras 3.9 e 3.10 sugerem que migrar de um SCG isolado

3.3 Discussao 33

para uma API generica pode ser uma alternativa atrativa para melhorar o desempenho de uma

aplicacao, desde que as tres condicoes a seguir sejam satisfeitas: (i) as mensagens sejam peque-

nas o suficiente para nao sobrecarregar a rede (pelo estudo descrito aqui, na ordem de dezenas

ou ate centenas de bytes); (ii) a API generica ofereca um plugin para outro SCG que seja mais

eficiente que o SCG utilizado originalmente pela aplicacao; e (iii) o ganho de desempenho

oferecido pelo novo SCG seja suficiente para compensar o impacto imposto pela API generica.

Vale ressaltar que, no caso do estudo descrito neste capıtulo, a terceira condicao, dentre as tres

descritas acima, somente seria satisfeita pelo plugin do Spread implementado pelo jGCS, uma

vez que o impacto imposto pelo plugin do Hedera foi bem maior que o ganho de desempenho

oferecido pelo Spread quando comparado ao Appia ou as duas configuracoes do JGroups. As-

sim, podemos concluir que, nesse caso, a migracao de uma aplicacao baseada no Appia ou no

JGroups para uma API generica baseada no Spread, so valeria a pena utilizando a API do jGCS,

e nao a do Hedera.

3.3 Discussao

Existem inumeros fatores que devem ser considerados por um desenvolvedor de aplicacoes

distribuıdas quando for cogitar a possibilidade de usar uma API generica de comunicacao em

grupo. A mais importante talvez seja considerar se e desejavel ter uma arquitetura de comunica-

cao fracamente acoplada (por exemplo, se o desenvolvedor vislumbra a possibilidade de migrar

para um novo SCG no futuro). Essa decisao e importante porque APIs genericas, como aquelas

oferecidas pelo Hedera e jGCS, como foi visto ao longo deste capıtulo, sempre impoem nıveis

adicionais de indirecao entre a aplicacao e o SCG subjacente, o que inevitavelmente resulta em

alguma perda de desempenho.

Outro fator que deve ser levado em conta e o tamanho das mensagens. Em particular, baseado

nos resultados reportados neste capıtulo, e considerando um cenario de execucao e um ambiente

de rede similares, para mensagens de ate 100 bytes valeria a pena migrar para uma API generica,

pois isso permitiria ao desenvolvedor melhorar o desempenho da aplicacao atraves apenas da

substituicao do plugin atual por um novo plugin para um SCG mais eficiente. Entretanto, para

mensagens maiores, na ordem de alguns milhares de bytes, a escolha entre utilizar um SCG

diretamente, em seu modo padrao, ou indiretamente, encapsulado por uma API generica, deve

ser feita baseada completamente nas necessidades e caracterısticas da aplicacao. A razao e

que, para esses tamanhos de mensagens, o custo de transmissao da rede tende a predominar

sobre o impacto de desempenho imposto pela API generica, reduzindo, assim, a possibilidade

3.4 Sumario 34

de melhorar o desempenho da aplicacao simplesmente substituindo o SCG subjacente.

3.4 Sumario

Este capıtulo apresentou uma avaliacao do impacto de desempenho causado por duas APIs

genericas, Hedera e jGCS, sobre tres SCGs amplamente conhecidos, JGroups, Appia e Spread.

Em essencia, os resultados mostraram que existem diferencas significativas no impacto im-

posto por cada uma das APIs genericas sobre o desempenho dos tres SCGs, com o Hedera

apresentando, com uma larga margem, os piores resultados. Esse estudo tambem mostrou

que as diferencas de desempenho observadas estao fortemente relacionadas a variacoes nos

tamanhos das mensagens utilizadas (para mensagens na ordem de alguns milhares de bytes

essas diferencas tendem a ser completamente dominadas pelo custo de comunicacao da rede)

e tambem as caracterısticas de implementacao de cada uma das APIs genericas (o desempe-

nho inferior do Hedera deve-se, em grande parte, a quantidade extra de bytes adicionados as

mensagens pelo seu mecanismo de plugin na camada de transporte).

No proximo capıtulo, apresentaremos os principais detalhes de projeto e implementacao da

biblioteca G2CL, uma camada de servicos de comunicacao em grupo de alto nıvel desenvolvida

sobre a API generica do jGCS, a qual foi escolhida com base nos resultados da avaliacao descrita

neste capıtulo.

35

Capıtulo 4

G2CL: Uma Camada Generica de Comu-nicacao em Grupo

Neste capıtulo, apresentamos aspectos de projeto e implementacao de uma nova biblioteca

generica de comunicacao em grupo, denomina em Ingles de Generic Group Communication

Layer, ou simplesmente G2CL, desenvolvida com o objetivo de enriquecer os servicos ofereci-

dos pela API generica do jGCS. Os novos servicos implementados visam contribuir com uma

solucao generica de comunicacao em grupo que atenda de forma mais satisfatoria as necessi-

dades das aplicacoes distribuıdas atuais, facilitando, assim, o usufruto dos benefıcios de uma

arquitetura de comunicacao em grupo fracamente acoplada, ja listados nos Capıtulo 2.

O restante deste capıtulo esta organizado da maneira a seguir. A Secao 4.1 descreve os motivos

que levaram a implementacao da biblioteca G2CL. A Secao 4.2 discute as principais decisoes

envolvidas no projeto da G2CL, incluindo a escolha da API generica utiliza como base para

o seu desenvolvimento e o modelo de implementacao do seu conjunto de servicos, os quais

sao descritos na Secao 4.3. A Secao 4.4 apresenta um passo a passo de como adicionar novos

servicos a G2CL. Finalmente, a Secao 4.5 sumariza o conteudo do capıtulo.

4.1 Motivacao

Como ja vimos anteriormente, o JGroups (BAN, 1998) e um SCG bastante completo e que ofe-

rece, alem de sua API basica, um conjunto de servicos abstratos, chamados de building blocks,

com funcionalidades de mais alto nıvel comumente utilizadas por aplicacoes distribuıdas. Com

essa facilidade, as aplicacoes que decidiram utilizar o JGroups como solucao de comunicacao

em grupo, acabaram tornando-se mais dependentes de seus building blocks do que de sua API

basica propriamente dita. Na maioria das vezes, o JGroups e escolhido exatamente por oferecer

essas abstracoes, cuja (re)utilizacao certamente representa um ganho consideravel de tempo e

esforco por parte dos desenvolvedores.

4.2 Principais decisoes de projeto 36

A existencia desses servicos de alto nıvel tem, em muitos casos, dificultado a adocao de APIs

genericas, como o jGCS (CARVALHO et al., 2006) e o Hedera (HEDERA, 2008) que, apesar

de possibilitarem diversos ganhos a aplicacao, principalmente quanto a liberdade na escolha

dos SCGs utilizados, oferecem apenas um conjunto limitado de servicos, restritos a troca de

mensagens e ao gerenciamento de membros do grupos. Nesse contexto, o principal objetivo

da biblioteca G2CL e oferecer, assim como o JGroups, um conjunto de servicos de alto nıvel

para comunicacao em grupo, mas, ao contrario do JGroups, cuja implementacao nao dependa

de nenhum SCG em particular.

A expectativa e que a G2CL facilite a adocao de APIs genericas, pois, alem de oferecer todos

os benefıcios atribuıdos ao uso de uma API generica, ja citados anteriormente, tambem oferece

uma camada de servicos de alto nıvel que podera suprir as necessidades de um grande numero

de aplicacoes.

4.2 Principais decisoes de projeto

A biblioteca G2CL foi projetada e desenvolvida buscando oferecer uma forma simples e eficaz

de implementar novas abstracoes de comunicacao em grupo, inclusive por desenvolvedores

que tenham necessidade de implementar servicos especıficos para suas aplicacoes. Para isso,

algumas decisoes de projeto importantes foram consideradas e descritas a seguir.

4.2.1 Escolha da API generica

A primeira decisao de projeto importante foi a escolha da API generica a ser estendida. Dois

motivos principais levaram a escolha do jGCS como a solucao a ser adotada: (i) a maneira

como sua API foi projetada, levando em consideracao varios princıpios e boas praticas da

programacao orientada a objetos; e (ii) os resultados obtidos no capıtulo anterior, onde obser-

vamos que o jGCS e a API generica que impoe o menor impacto sobre os SCGs encapsulados

pelo seu mecanismo de plugin.

4.2.2 Modelo de implementacao dos servicos

O fato do JGroups ser um SCG bastante popular, com um grande numero de aplicacoes ja

tendo sido desenvolvidas utilizando seus building blocks, nos levou a decisao de implementar

um conjunto similar de servicos como parte da G2CL, mantendo, na medida do possıvel, as

mesmas APIs de acesso. Tal decisao teria como principal benefıcio facilitar a utilizacao dos


servicos oferecidos pela G2CL, dada a popularidade dos building blocks do JGroups. Outro

benefıcio importante seria facilitar a migracao para a G2CL de aplicacoes existentes que ja

utilizam os building blocks do JGroups, uma vez que os servicos equivalentes oferecidos pela

G2CL teriam APIs de acesso muito similares as dos building blocks.

Em princıpio, considerou-se a hipotese de implementar a G2CL simplesmente substituindo, na

implementacao dos building blocks do JGroups, a API basica do JGroups pela API do jGCS,

ou seja, o uso da interface Channel do JGroups seria substituıdo pelas interfaces DataSession

ou ControlSession do jGCS, dependendo se o Channel estivesse sendo utilizado para troca de

mensagens ou para receber notificacoes sobre mudancas no grupo, respectivamente.

Entretanto, ao comecarmos a estudar mais detalhadamente o codigo do JGroups, constatamos

que essa hipotese de migracao da implementacao dos building blocks para utilizar as interfaces

generica do jGCS nao seria viavel. A principal razao e que a atual implementacao dos building

blocks do JGroups esta fortemente acoplada aos servicos e recursos oferecidos em sua API

basica, com alguns building blocks chegando ate mesmo a se registrar como um dos protocolos

de sua pilha de protocolos. Outra alternativa considerada foi reimplementar a interface Channel

do JGroups, mapeando seus servicos para os servicos equivalentes oferecidos pelo jGCS. Essa

solucao tambem nao foi levada adiante, pois com ela estarıamos incluindo mais uma camada

entre a aplicacao e o SCG encapsulado pelo jGCS, o que poderia resultar em um impacto de

desempenho ainda maior.

No final, foi tomada a decisao de reimplementar por completo os principais building blocks do

JGroups, utilizando como base os servicos genericos de comunicacao em grupo oferecidos pelo

jGCS, mas tentando preservar ao maximo as mesmas APIs, desde nomes de classes e interfaces

a assinaturas de metodos. Dessa forma, em aplicacoes que ja utilizavam o JGroups e desejassem

migrar para a G2CL, o desenvolvedor teria pouquıssimo trabalho, apenas necessitando alterar

as declaracoes referentes a importacao de pacotes. Para novas aplicacoes, a utilizacao dos

servicos da G2CL seria similar ao uso dos building blocks equivalentes do JGroups, com o

desenvolvedor podendo inclusive usufruir da farta quantidade de informacoes sobre o uso desses

servicos disponıvel na documentacao oficial do JGroups.

Para que o jGCS pudesse ser adequadamente utilizado na implementacao dos servicos genericos

oferecidos pela G2CL, foi necessario realizar algumas extensoes em sua API. Essas extensoes

sao descritas a seguir.


4.2.3 Extensoes realizadas no jGCS

Assim como em diversos outros protocolos de comunicacao que encapsulam camadas de mais

baixo nıvel, por exemplo, TCP e HTTP, na implementacao da G2CL precisarıamos de uma ma-

neira para adicionar cabecalhos as mensagens de forma separada de seu corpo. Esses cabecalhos

seriam utilizados para armazenar informacoes de controle relevantes a implementacao dos

servicos de alto nıvel, mas que nao deveriam chegar a aplicacao. Ao avaliarmos a interface

Message do jGCS, concluımos que seria necessaria a adicao de uma classe de mensagem mais

completa, que permitisse adicionar e remover os cabecalhos de uma forma padronizada e sepa-

rado de seu corpo. A preocupacao de mantermos uma padronizacao na forma de organizar os

cabecalhos foi reforcada, tambem, pelo fato de que servicos podem encapsular outros servicos

e, dependendo da implementacao, poderiam ler os cabecalhos uns dos outros.

A solucao adotada foi a criacao da classe G2CLMessage. Para que esse novo tipo de mensa-

gem ainda fosse compatıvel com a definicao do DataSession do jGCS, a classe G2CLMessage

implementa a interface Message e, dessa forma, pode ser transmitida como qualquer outra men-

sagem por qualquer plugin do jGCS. A Figura 4.1 mostra um diagrama de classes ilustrando a

relacao entre a interface Message do jGCS e a nova classe de mensagem definida pela G2CL.

Figura 4.1: Relacao entre a interface Message do jGCS e a classe G2CLMessage.

Outra decisao de projeto importante na construcao da biblioteca G2CL foi que qualquer ex-

tensao realizada no jGCS nao deveria causar nenhum impacto sobre os plugins ja existentes.

Com isso, nao poderıamos delegar aos plugins a responsabilidade de unir ou separar o cabecalho

e o corpo de uma mensagem no momento que ela fosse enviada ou recebida, pois nao teriam

conhecimento suficiente sobre o conteudo da mensagem nem sobre suas caracterısticas. Para

contornar essa situacao, criamos uma nova implementacao do DataSession do JGCS, que fun-

ciona como um Adaptador (GAMMA et al., 1995) entre o servico oferecido pela G2CL e o

DataSession utilizado pelo plugin. A principal responsabilidade do novo DataSession, cha-

mado de MarshalDataSession, e interceptar todas as chamadas para o plugin, realizando as

4.3 Servicos implementados 39

transformacoes entre uma mensagem do tipo G2CLMessage e a mensagem do tipo Message

criada pelo plugin, sempre que necessario. Os servicos da G2CL passariam entao a depender

do MarshalDataSession (ao inves do DataSession do plugin) para enviar e receber mensagens.

Mantendo o conceito de inversao de controle, a nova classe tambem devera ser instanciada

atraves de um arquivo de configuracao ou via um mecanismo de injecao de dependencia.

O diagrama da Figura 4.2 ilustra o envio de uma mensagem por um MarshalDataSession, com

um exemplo de uma transformacao entre as mensagens. Nesse diagrama, o passo 1.2 corres-

ponde ao momento no qual a mensagem e o corpo sao unificados, atraves da chamada do metodo

getPayload() da classe G2CLMessage.

Figura 4.2: Exemplo de envio de uma mensagem atraves da classe MarshalDataSession.

Com essas extensoes realizadas no jGCS, ja tınhamos a infra-estrutura necessaria para a im-

plementacao dos servicos de alto nıvel a serem oferecidos pela G2CL, os quais sao decritos a

seguir.

4.3 Servicos implementados

Inicialmente, decidiu-se pela implementacao de um conjunto de servicos de comunicacao em

grupo considerados mais importantes ou uteis para o desenvolvimento de aplicacoes distribuı-

das, com base na analise de uma serie de aplicacoes que atualmente utilizam o JGroups. Esse

conjunto inicial de se ˚ vicos foi entao dividido em 2 grupos, denominados servicos de alto nıvel

e servicos Decoradores (GAMMA et al., 1995).

No grupo dos servicos de alto nıvel estao os servicos que encapsulam o MarshalDataSession

e escondem da aplicacao sua funcionalidade basica de troca de mensagens, oferecendo para a

aplicacao APIs mais sofisticadas que facilitam a implementacao de requisitos funcionais. Estao

nesse grupo os seguintes servicos: MessageDispatcher, RpcDispatcher, ReplicatedHashMap e


StateTransferDataSession.

Os servico do grupo dos Decoradores mantem a mesma interface do MarshalDataSession,

de modo que sua presenca e totalmente transparente para a aplicacao. Sua funcao e auxiliar

na implementacao de requisitos nao-funcionais da aplicacao, como compactacao de dados e

seguranca. Estao nesse grupo os seguintes servicos: FragDataSession, BundleDataSession,

CompressDataSession e CryptoDataSession.

4.3.1 Servicos de alto nıvel

A seguir, apresentamos uma descricao de cada um dos servicos de alto nıvel inicialmente ofere-

cidos pela G2CL e de como sua implementacao utiliza as classes e interfaces genericas providas

pelo jGCS.

MessageDispatcher

No jGCS, assim como na maioria dos mecanismos de comunicacao em grupo, por padrao o

envio de uma mensagem para o grupo e feito de forma assıncrona, ou seja, apos o envio da

mensagem, a execucao da aplicacao continua sem ter a garantia de que a mensagem ja foi

realmente entregue para os membros do grupo. Note que existe uma diferenca entre garantir

que a mensagem vai ser entregue e garantir que a mensagem ja foi entregue. Para algumas

aplicacoes, essa diferenca e importante pois, em alguns casos, e preciso enviar uma mensagem

e so continuar a execucao apos ter a garantia de que a mensagem ja foi entregue ou, em outros

casos, a continuacao da execucao depende de uma resposta referente a mensagem enviada.

Em uma aplicacao do tipo cliente-servidor convencional, a definicao de uma mensagem sıncrona

e simples, pois depende apenas de dois processos: o cliente envia uma mensagem e aguarda a

resposta do servidor. No contexto da comunicacao em grupo, esse conceito e diferente, uma

vez que um processo se comunica com n outros processos. Isso fez com que, nesse novo con-

texto, fossem definidas diferentes polıticas para o envio de mensagens sıncronas, dependendo

das necessidades da aplicacao. A aplicacao pode escolher, por exemplo, continuar a execucao

quando um primeiro membro responder; quando a maioria dos membros responder; ou ate

mesmo quando todos os membros responderem. Alem disso, a aplicacao pode ser responsavel

por sinalizar quando a execucao devera continuar, filtrando as respostas ja recebidas.

Na G2CL, o servico de envio de mensagens sıncronas e implementado atraves da classe Mes-

sageDispatcher, descrita a seguir.


Para ser instanciada, a classe MessageDispatcher deve receber um MarshalDataSession e um

MembershipSession. O MarshalDataSession sera utilizado tanto como um cliente, que en-

via requisicoes e recebe respostas, quanto como um servidor, que recebe requisicoes e envia

respostas. O MembershipSession e necessario pois, como as polıticas de envio estao direta-

mente relacionadas ao numero de membros do grupo, o MessageDispatcher precisa receber

notificacoes sobre a saıda de membros para que nao fique aguardando indefinidamente por uma

resposta caso um membro venha a falhar.

No momento em que a aplicacao solicita o envio de uma mensagem, o MessageDispatcher adi-

ciona a ela um cabecalho para indicar que e do tipo REQUEST e, so em seguida, a mensagem

e enviada ao grupo. Nesse momento, atraves de um monitor (HOARE, 1974), o processo fica

bloqueado aguardando ser notificado de que pode continuar. Nos outros membros, o Message-

Dispatcher, que agora funciona como servidor, ao receber a mensagem e detectar que e do tipo

REQUEST, respondera ao remetente que recebeu a mensagem. A resposta podera ser apenas

um sinal, indicando que a mensagem foi recebida, ou nela podera ser enviado algum retorno;

nesse ultimo caso, fica sob a responsabilidade da aplicacao informar o retorno desejado.

A mensagem enviada de volta ao remetente contera um cabecalho indicando o tipo RES-PONSE. No momento que uma mensagem desse tipo e recebida, ela e manipulada pelo pro-

cesso responsavel por armazenar as respostas e verificar se a polıtica utilizada para o envio da

mensagem foi satisfeita. Caso a polıtica tenha sido satisfeita, o processo que estava em espera

e entao notificado de que deve continuar sua execucao; caso contrario, o processo que inicial-

mente recebeu a mensagem ira aguardar por mais respostas, ate que a polıtica seja satisfeita.

Por exemplo, se uma mensagem for enviada com a polıtica de esperar respostas da maioria e

o grupo tiver cinco membros, apenas apos pelo menos tres dos membros tiverem respondido a

requisicao e que o processo sera notificado que pode continuar e as respostas serao finalmente

entregues a aplicacao.

O unico requisito exigido do SCG acoplado ao jGCS, ao se utilizar o MessageDispatcher, e que

ele tenha um protocolo para garantir que a mensagem vai ser entregue a todos os membros do

grupo. Essa garantia e necessaria para evitar que a aplicacao trave aguardando por uma resposta

de uma requisicao que sequer tenha chegado ao seu destino.

Na G2CL, as polıticas de envio sao representadas por constantes definidas na classe GroupRe-

quest. Ja para se criar um filtro para as respostas, deve ser seguida a definicao da interface

RspFilter. As respostas recebidas, representadas pela classe Rsp, sao armazenadas em uma

lista do tipo RspList, que e entregue a aplicacao ao final da requisicao. A classe RspList e

responsavel, tambem, por verificar se as polıticas foram satisfeitas e notificar o processo que


esta aguardando. Para processar as mensagens recebidas e enviar um retorno ao remetente, a

aplicacao precisa se registrar como um Observador do tipo MessageDispatcherListener.

A Figura 4.3 mostra as classes envolvidas nesse processo e como elas se relacionam.

Figura 4.3: Classes envolvidas na implementacao do MessageDispatcher.

RpcDispatcher

A invocacao remota de metodos e um recurso muito utilizado em sistemas distribuıdos. No

contexto de comunicacao em grupo, esse recurso tambem e bastante utilizado, por exemplo, em

aplicacoes tolerante a falhas, quando um cliente invoca um metodo de um servico replicado essa

invocacao precisa ser repassada a todos os outros membros do grupo de replicas do servico, de

modo a garantir que as replicas mantenham um estado consistente.

Assim como no envio de mensagens sıncronas, a invocacao de metodos remotos ganha novas ca-

racterısticas no contexto de comunicacao em grupo no que diz respeito a polıtica de invocacao.

A polıtica a ser usada vai depender das necessidades especıficas de cada aplicacao e pode ser:

esperar o retorno da invocacao do metodo de todos os membros do grupo; esperar o retorno da

invocacao da maioria dos membros; ou esperar retorno de apenas um membro.

A invocacao remota de metodos pode ser considerada como um caso particular do envio sıncrono

de mensagens, onde as mensagens enviadas correspondem as informacoes sobre o metodo que

deve ser invocado, seus parametros de invocacao e o seu retorno. Partindo dessa ideia, a classe

RpcDispatcher foi implementada como uma extensao da classe MessageDispatcher. Alem dos

objetos necessarios para a criacao do MessageDispatcher, para ser instanciado, o RpcDispat-

cher precisa, tambem, receber informacoes sobre o objeto alvo das invocacoes.


Para efetuar a invocacao de um metodo, a aplicacao devera apenas informar os dados do metodo

e a polıtica de invocacao. Os dados do metodo necessarios sao: o nome do metodo, o tipo dos

parametros que ele recebe, para evitar ambiguidade em caso de metodos com sobrecarga, e

os parametros que serao passados na chamada. A unica restricao sobre os parametros e que

precisam ser serializaveis, para que possam ser transportados em forma de bytes atraves da

rede.

Quando o RpcDispatcher e invocado, as informacoes do metodo sao encapsuladas em um unico

objeto e entao serializadas em um array de bytes, que constituira o corpo da mensagem criada

e enviada atraves do MessageDispatcher, utilizando a polıtica escolhida. Como sera necessario

enviar um retorno para a aplicacao que invoca o metodo, o RpcDispatcher informara ao Mes-

sageDispatcher que deseja ser notificado sobre as requisicoes recebidas, para que possa enviar

uma resposta correspondente. Ao receber uma mensagem de invocacao, os dados do metodo

a ser invocado sao deserializados e e feita a invocacao do metodo no objeto alvo informado

no momento da criacao do RpcDispatcher. O retorno do metodo e enviado para o remetente

como parte do corpo da mensagem de resposta, que, ao chegar ao remetente, e repassada para a

aplicacao.

O objeto utilizado para encapsular as informacoes do metodo a ser invocado e representado pela

classe MethodCall. Para se registrar e ser notificado sobre as requisicoes recebidas no Messa-

geDispatcher, o RpcDispatcher tambem implementa a interface MessageDispatcherListener.


Figura 4.4: Classes envolvidas na implementacao do RpcDispatcher.

StateTransferDataSession

O recurso de transferencia de estado e muito util em aplicacoes distribuıdas que precisam ter

a garantia de que todos os membros ativos possuirao o mesmo estado em um determinado ins-

tante. Por exemplo, considere um servico de cache replicado que e constantemente solicitado,


e que em perıodos de pico precisa aumentar o numero de servidores(replicas) para atender a de-

manda. Quando um novo servidor e disponibilizado, ele precisa conter em seu cache as mesmas

informacoes dos outros servidores ja existentes, ou seja, o mesmo estado, de modo que todos

possam responder as requisicoes da mesma forma. Para atender esse requisito, e necessario que

o servico ofereca um mecanismo para que novos membros possam solicitar as informacoes de

estado que os membros mais antigos ja possuem.

A implementacao do servico de transferencia de estado da G2CL foi feita baseada no meca-

nismo de transferencia de estado utilizado pelo JGroups (BAN, 2007). Diferentemente dos

outros servicos de alto nıvel implementados, a transferencia de estado exige, para seu funciona-

mento correto, que o sistema acoplado ao jGCS esteja configurado para entregar as mensagens

de acordo com o protocolo de ordenacao TOTAL.

O processo de transferencia de estado sera iniciado por um membro m, que enviara uma men-

sagem para o grupo informando que deseja receber o estado atual (mensagem identificada pelo

cabecalho REQUEST STATE). Essa mensagem sera recebida por todos os membros, inclusive

por m. Ao receber a mensagem, os membros que ja possuem estado farao uma copia de seu es-

tado atual (essa copia precisa ser feita por todos os membros, pois, nesse momento, nao se sabe

quem ira fornecer o estado para m) e responderao informando que sao possıveis fornecedores

de estado (mensagem identificada pelo cabecalho SET STATE PROVIDER). O membro m, por

sua vez, ao receber sua propria mensagem, comecara a empilhar as mensagens recebidas da-

quele momento em diante. Note que essa mensagem serve como uma mensagem de marcacao,

pois, como o algoritmo de ordenacao de entrega das mensagens e o TOTAL, ele garantira que

todos os membros se preparem para o processo de transferencia de estado na mesma ordem.

Ao receber a primeira mensagem com o cabecalho SET STATE PROVIDER, m identificara seu

remetente e este membro m’ sera escolhido como o fornecedor do estado (as outras mensagens

com o mesmo cabecalho, enviadas pelos outros membros, serao descartadas). E importante res-

saltar que todo esse processo de selecao do membro fornecedor do estado podera ser evitado se

o SCG acoplado ao jGCS ja implementar uma funcionalidade para eleger um coordenador para

o grupo. Nesse caso, o coodenador e sempre escolhido como fornecedor do estado. A seguir,

m enviara uma mensagem para m’ solicitando que o estado seja de fato enviado (mensagem

identificada pelo cabecalho GET STATE); m’, por sua vez, ao receber a solicitacao, respondera

enviando uma mensagem, identificada com o cabecalho SET STATE, com o estado, que foi

copiado no inicio do processo, embutido em seu corpo. Apos receber e processar o estado, m

finalizara o processo enviando uma mensagem para todos os membros do grupo, identificada

pelo cabecalho FINISH STATE TRANSFER. Ao receber essa mensagem, os outros membros


destruirao as copias do estado que haviam feito anteriormente e m entao processara todas as

mensagens que havia empilhado desde do inıcio do processo e passara a funcionar igualmente

aos outros membros, agora com o mesmo estado.

Assim como os outros servicos desse grupo, para ser instanciado o StateTransferDataSession

precisa receber um MarshalDataSession e um MembershipSession. O MarshalDataSession sera

necessario para enviar todas as mensagens de controle envolvidas no protocolo de transferencia

de estado e tambem para enviar as mensagens da aplicacao. O MembershipSession, por sua vez,

sera utilizado para obter informacoes sobre o coordenador do grupo (caso seja fornecido pelo

SCG subjacente). Apos instanciar um objeto do tipo StateTransferDataSession, para solicitar

o estado, a aplicacao deve invocar o metodo requestState(), dando inıcio a todo o processo

explicado anteriormente.

A aplicacao exerce um importante papel no processo da transferencia de estado. O StateTrans-

ferDataSession nao tem a capacidade de assumir a responsabilidade de informar qual o estado

atual dos membros e nem tampouco de tratar um estado quando recebido. Essa funcao deve ser

assumida pela aplicacao, que, para isso, devera registrar um Observador do tipo StateListener.

O objeto que implementar essa interface sera responsavel por informar se esse membro possui

estado, qual seu estado atual e tambem processar um estado recebido.


Figura 4.5: Classes envolvidas na implementacao do StateTransferDataSession.

ReplicatedHashMap

O ReplicatedHashMap e uma implementacao distribuıda de um objeto do tipo HashMap de

Java. Qualquer alteracao realizada no objeto em qualquer um dos membros do grupo e enviada

para os demais membros. Pode ser utilizado por aplicacoes que desejam manter um determinado

estado replicado em varios processos de uma forma transparente para a aplicacao, ou seja, sem

que ela se envolva na logica sobre troca de estado ou envio de mensagens para o grupo. Como


um um novo membro precisa ser inicializado com o estado identico aos demais, este servico

utiliza internamente o servico StateTransferDataSession como mecanismo de transferencia de

estado.

Para poder ser utilizado como um tipo Map de Java, o ReplicatedHashMap implementa a inter-

face java.util.Map. Possui como um de seus atributos um java.util.HashMap, para o qual re-

passa todas as chamadas dos metodos impostos pela interface. A chamada de qualquer metodo

que altera os dados do HashMap local, como put(), clear() ou remove(), dispara, antes, uma

invocacao remota para os outros membros do grupo, atraves de uma instancia do RpcDispatcher,

e so modifica a copia local apos ter invocado o metodo equivalente em todos os outros membros.

Operacoes de leitura, como get(), sao feitas apenas localmente, ja que todas as replicas possuem

estados indenticos. Para nao efetuar invocacoes remotas desnecessarias, o ReplicatedHashMap

recebe notificacoes sobre entrada e saıda de membros e so replicara as chamadas quando nao

estiver sozinho no grupo. Na entrada de um novo membro, quando este solicitar o estado atual,

ele recebera, de algum membro, o HashMap encapsulado com o estado que se encontra nesse

instante.

A Figura 4.6 mostra as classes envolvidas na implementacao do ReplicatedHashMap e como

elas se relacionam.

Figura 4.6: Classes envolvidas na implementacao do ReplicatedHashMap.

4.3.2 Decoradores

Os servicos desse grupo sao implementados de modo que a aplicacao nao tenha conhecimento

de que os esta utilizando. Eles podem ser utilizados em conjunto, formando uma especie de

“cadeia de responsabilidade” (GAMMA et al., 1995), onde funcionalidades podem ser adi-

cionadas ou removidas a um MarshalDataSession sem causar nenhum impacto no codigo ja

implementado.

Seguindo o conceito utilizado pelo jGCS de separar a configuracao de uma classe de seu uso, na


G2CL foi implementada a classe MarshalDataSessionFactory, cuja responsabilidade e a criacao

do MarshalDataSession. A aplicacao, ao inves de invocar o construtor do MarshalDataSession,

invoca o metodo getMarshalDataSession() da classe MarshalDataSessionFactory e recebe uma

instancia do MarshalDataSession ja de acordo com a cadeia de Decoradores configurada.

A criacao do MarshalDataSessionFactory pode ser feita utilizando alguma tecnica de injecao

de dependencia ou atraves de um ServiceLocator. Para ser criada, precisa receber uma String

em um formato pre-definido ou um arquivo XML, informando como sera formada a cadeia de

Decoradores a ser incorporada no MarshalDataSession a ser instanciado.

A seguir, apresentamos uma descricao de cada um dos Decoradores inicialmente fornecidos

com a G2CL e alguns detalhes sobre a sua implementacao.

FragDataSession

Uma das propriedades basicas da comunicacao em grupo e a necessidade de garantir a entrega

das mensagens, independente do protocolo de transporte utilizado. Quando uma mensagem e

perdida e nao chega a todos os seus destinos, ela precisa ser reenviada ate que todos a recebam.

Acontece que, em algumas aplicacoes, as mensagens enviadas podem ser muito grandes e, nesse

caso, cada reenvio causado pela perda de alguma dessas mensagens pode ser muito custoso. O

servico FragDataSession permite que o envio de mensagens que ultrapassem um determinado

tamanho seja feito atraves de fragmentos menores. Dessa forma, caso alguma mensagem se

perca no caminho, sera possıvel reenviar apenas a parte que foi perdida e nao toda a mensagem.

Na criacao do FragDataSession e possıvel informar o tamanho maximo que a mensagem deve

ter para nao ser fragmentada. Esse mesmo valor sera utilizado como o tamanho dos fragmentos

no caso da mensagem ultrapassar esse limite.

Para realizar a fragmentacao, no momento que a mensagem passa pelo FragDataSession, e

checado se a mensagem ultrapassa o tamanho permitido para ser enviada como uma unica men-

sagem. Caso ultrapasse, ela e fragmentada e enviada por partes. Em cada um dos fragmentos e

enviado, alem de uma parte do corpo da mensagem, algumas informacoes adicionais que serao

uteis na hora da reconstrucao da mensagem original no seu destino. O formato do fragmento

pode ser visto na Figura 4.7. O primeiro campo do cabecalho indica a qual mensagem aquele

fragmento pertence e sera utilizado para que seja possıvel agrupar corretamente todos os frag-

mentos de uma mesma mensagem. O segundo campo do cabecalho representa o tamanho total

da mensagem e e utilizado para saber se todos os fragmentos ja foram recebidos. O terceiro e

ultimo campo cabecalho indica a posicao desse fragmento na composicao da mensagem origi-


nal e e utilizado para a reconstrucao correta da mensagem. Este ultimo e importante tambem

para que o mecanismo de fragmentacao nao dependa da ordem em que as mensagens sao entre-

gues. Com essas informacoes, apos o recebimento de todos os fragmentos de uma mensagem,

a mensagem original e reconstruıda e so depois entregue a aplicacao. Caso algum fragmento

seja perdido no caminho, o SCG acoplado se responsabilizara por reenvia-lo e garantir que sera

entregue.

Figura 4.7: Formato de um fragmento da mensagem utilizado pelo FragDataSession.

BundleDataSession

O BundleDataSession e uma adaptacao do algoritmo de Nagle (NAGLE, 1984) ao contexto de

comunicacao em grupo. Nesse algoritmo, ao inves de se enviar varias mensagens de tamanho

pequeno pela rede, uma unica mensagem contendo todas as mensagens e enviada, reaprovei-

tando, assim, recursos que iriam ser desperdicados caso as mensagens fossem enviadas separa-

damente. Antes de serem enviadas, as mensagens menores ficam armazenadas em um buffer,

que, ao encher, e transformado em uma unica mensagem e enviado para os outros membros.

Na criacao do BundleDataSession e possıvel informar o tamanho maximo do buffer de men-

sagens. Para que o ganho causado nao se transforme em perda de desempenho, caso o buffer

demore muito para encher, e possıvel tambem informar um tempo de espera maximo ate que o

buffer atinja sua capacidade maxima. Se esse tempo se esgotar, o que estiver armazenado no

buffer ate o momento e enviado.

No momento em que a mensagem passa pelo BundleDataSession, e verificado se ela ainda

cabe no espaco disponıvel no buffer; em caso afirmativo, ela sera adicionada ao buffer para ser

enviada posteriormente; em caso contrario, os dados que estao no buffer sao enviados e o buffer

e esvaziado, podendo receber uma nova mensagem. A mensagem que e efetivamente enviada

possui um formato pre-definido para facilitar a identificacao das mensagens maiores em seu

destino, incluindo o numero de mensagens contidas no corpo, seguido do tamanho e do corpo

de cada mensagem menor. Esse formato pode ser visto na Figura 4.8.

4.4 Passo a passo para implementacao de novos servicos 49

Figura 4.8: Formato da mensagem enviada pelo BundleDataSession.

CompressDataSession

O CompressDataSession pode ser utilizado pela aplicacao nos casos onde e desejavel compac-

tar a mensagem a ser enviada, independente de ser por motivo de desempenho, nos casos em

que o custo da compressao compensa o custo do envio de toda a mensagem, ou ate mesmo de

economia, no caso que o custo de comunicacao e calculado com base na quantidade de bytes en-

viados. Sua implementacao e bem simples: no momento em que a mensagem e enviada, o corpo

da mensagem e substituıdo pela informacao referente ao corpo antigo compactado. Quando a

mensagem chega ao destino, antes de ser entregue a aplicacao, a mensagem e descompactada

assumindo seu valor original. O algoritmo a ser utilizado para compressao dos dados pode ser

informado pelo usuario, possibilitando ao usuario escolher o melhor algoritmo para o domınio

da sua aplicacao.

CryptoDataSession

O CryptoDataSession pode ser utilizado por aplicacoes que desejem proteger, via criptografia,

as mensagens enviadas ao grupo. Como o CompressDataSession, sua implementacao e bem

simples: no momento em que a mensagem e enviada, o corpo da mensagem e substituıdo pela

informacao referente ao corpo antigo criptografado. Quando a mensagem chega ao destino,

antes de ser entregue a aplicacao, a mensagem e descriptografada, assumindo seu valor original.

Assim como no CompressDataSession, no CryptoDataSession o algoritmo de criptografia dos

dados pode ser informado pelo usuario, por exemplo, caso ele queira um algoritmo mais seguro.

4.4 Passo a passo para implementacao de novos servicos

Apesar de termos implementado inicialmente os servicos que consideramos como os mais im-

portantes ou mais utilizados por aplicacoes distribuıdas, ainda existem inumeros servicos que

podem ser implementados para suprir a necessidade de varios outros cenarios. Por esse mo-

tivo, a seguir e apresentado um passo a passo para a implementacao de novos servicos a serem

adicionados a G2CL.

Passo 1: Determinar o tipo do servico

4.4 Passo a passo para implementacao de novos servicos 50

O primeiro passo e identificar a qual grupo pertence o novo servico. Servicos de alto nıvel

sao aqueles que precisam expor uma API diferenciada e compartilham responsabilidades com

a aplicacao. Na maioria das vezes, estes escondem os servicos basicos de troca de mensagens,

fazendo a comunicacao com os outros membros de forma transparente. Servicos de alto nıvel

exercem importantes papeis na implementacao de requisitos funcionais das aplicacoes e, dessa

forma, e impossıvel retirar ou substituir um deles sem que seja necessario modificar o codigo

da aplicacao. Os servicos Decoradores, por sua vez, sao utilizados para melhorar o funciona-

mento em relacao a requisitos nao funcionais como, por exemplo, desempenho e seguranca,

mas o funcionamento da aplicacao nao depende diretamente deles, podendo ser adicionados ou

removidos sem qualquer alteracao no codigo ou interferencia na aplicacao.

Passo 2: Identificar a necessidade de interacao com a aplicacao

Outro passo importante e identificar se o servico precisara repassar alguma informacao ou res-

ponsabilidade para a aplicacao. Se sim, isso podera ser feito atraves de Observadores, que

deverao implementar uma interface pre-definida pelo proprio servico.

Passo 3: Avaliar a influencia de mudancas no grupo

Nesse passo, busca-se identificar como mudancas nos membros do grupo podem interferir no

funcionamento do novo servico. Por exemplo, no MessageDispatcher e importante ficar atento

aos membros que saem para evitar esperar uma resposta de um membro que ja nao esta mais no

grupo. Para isso, e importante que o servico registre-se para receber as notificacoes referente a

mudancas de visao.

Passo 4: Avaliar a influencia da ordem de entrega das mensagens

Quanto a ordem da entrega das mensagens, e necessario ficar atento a duas coisas: se o fun-

cionamento do novo servico requer o uso de um algoritmo de ordenacao especıfico, como no

caso do StateTransferDataSession, que exige o algoritmo de ordenacao TOTAL; e se a forma

como o servico foi implementado nao podera influenciar na ordem que as mensagens forem en-

tregues pelo SCG acoplado, por exemplo, o BunldeDataSession precisou ser implementado de

uma forma onde as mensagens sejam entregues exatamente na mesma ordem que foram inicial-

mente enviadas pela aplicacao, para evitar a reconstituicao de mensagens a partir de fragmentos

dispostos em uma ordem diferente da ordem original.

Passo 5: Identificar a necessidade de criacao de novos protocolos

A implementacao de um servico de comunicacao em grupo, em alguns casos, depende da

criacao de um novo protocolo que requer a troca de mensagens internas (de controle) entre

os membros do grupo. O objeto do tipo mensagem, introduzido pela G2CL, oferece uma ma-

4.5 Sumario 51

neira bastante intuitiva de criar mensagens de controle, com facilidades de manipulacao de

cabecalho. Isso e importante para evitar incluir cabecalhos na forma de dados embutidos no

corpo da mensagem. Alem disso, e importante se certificar que as mensagens de controle, ou

qualquer outra mensagem nao tratada, nao serao recebidas pela aplicacao. Para isso, o servico

deve disponibilizar uma maneira da aplicacao registrar um MessageListener nele proprio, com

o servico se registrando como o Observador das mensagens entregues pelo DataSession subja-

cente. Dessa forma, o servico ficara responsavel por receber todas as mensagens e repassa-las

de forma correta para a aplicacao.

Passo 6: Verificar a possibilidade de reuso

Ao iniciar o projeto de novos servicos, e importante tentar reutilizar ou estender os servicos ja

existentes, visando poupar trabalho e tempo de desenvolvimento, alem de evitar a reimplemen-

tacao desnecessaria de protocolos ja existentes. Este passo pode ser ilustrado pela relacao de

reuso estabelecida nas implementacoes do RpcDispatcher e do MessageDispatcher.

4.5 Sumario

Neste capıtulo, descrevemos as principais caracterısticas de projeto e de implementacao de uma

nova biblioteca de servicos genericos de comunicacao em grupo, chamada G2CL.

Alem disso, apresentamos um passo a passo com dicas para a implementacao de novos servicos

a serem adicionados a G2CL, ja que os servicos inicialmente implementados nao tem a intencao

de atender 100% das aplicacoes.

O codigo fonte da biblioteca G2CL esta disponıvel publicamente em http://g2cl.googlecode.

com, sob a licenca GNU General Public License, version 2(GNU, 1991).

No proximo capıtulo, mostraremos os resultados de uma avaliacao inicial do esforco e do im-

pacto de desempenho associados a utilizacao da G2CL em um sistema real, que atualmente

utiliza o JGroups como seu mecanismo de comunicacao em grupo.

52

Capıtulo 5

Estudo de Caso: Avaliacao da G2CL emum Sistema Real

Esse capıtulo apresenta um estudo de caso sobre a implantacao da biblioteca G2CL em um

sistema real. O sistema escolhido como alvo do estudo foi o servidor de aplicacao Java EE

JOnAS (JONAS, 2009), que atualmente utiliza o JGroups como solucao de comunicacao em

grupo em sua arquitetura de replicacao. O objetivo do estudo foi avaliar o esforco de migracao e

o impacto de desempenho associados ao uso da G2CL. Para isso, o capıtulo descreve a estrategia

de migracao adotada, incluindo quais elementos do codigo fonte do JOnAS tiveram que ser

modificados para substituir o uso do JGroups pelos servicos da G2CL, e apresenta os resultados

de uma avaliacao experimental onde foram comparados os desempenhos da versao original

do JOnAS, baseda no JGroups, e da nova versao, baseada na G2CL, considerando diferentes

configuracoes de plugins para o jGCS.

O restante do capıtulo esta organizado da maneira a seguir. A Secao 5.1 da uma visao geral do

JOnAS e da forma como ele utiliza os servicos do JGroups em sua arquitetura de replicacao. A

Secao 5.2 descreve a estrategia de migracao adotada. A Secao 5.3 apresenta a metodologia e os

resultados da avaliacao experimental realizada. A Secao 5.4 apresenta uma discussao sobre a

migracao do JOnAS para a biblioteca G2CL. Finalmente, a Secao 5.5 sumariza o conteudo do

capıtulo.

5.1 JOnAS

O JOnAS, acronimo para Java Open Application Server, e uma implementacao de codigo aberto

da especificacao Java EE 5 (SUN, 2006). As principais tecnologias que fazem parte dessa

especificacao e que sao implementadas pelo JOnAS incluem: EJB, JMS, Servlets, JSP, JSF,

JPA, JAX-WS, JAX-RPC, entre outras (JONAS, 2009). A versao do JOnAS utilizada neste

trabalho foi a 5.1.0-M5, disponıvel em http://jonas.ow2.org.

5.1 JOnAS 53

Para garantir uma maior robustez em aplicacoes baseadas na tecnologia EJB, o JOnAS oferece

um servico de alta disponibilidade implementado a partir de um cluster de servidores. Quando

um cliente solicita a criacao de um Stateful Session Bean (SFSB), um dos servidores do cluster e

escolhido para responder as requisicoes desse cliente ate que ele encerre sua execucao e solicite

a remocao desse SFSB. De uma forma totalmente transparente para a aplicacao, antes de enviar

a resposta para o cliente, o estado do novo SFSB e enviado para os outros servidores do cluster,

que passam a atuar como servidores de backup. No caso do servidor inicialmente escolhido para

aquele cliente falhar, o estado do SFSB pode ser reconstituıdo em um dos outros servidores, o

qual passara a responder pelas novas requisicoes a esse SFSB sem que o cliente perceba tal

mudanca. Os principais cenarios de acesso ao servico de alta disponibilidade do JOnAS estao

representado na Figura 5.1.

Figura 5.1: Cenarios de acesso ao servico de alta disponibilidade do JOnAS.

5.1.1 CMI

Para implementar seu mecanismo de replicacao, o JOnAS faz uso de um protocolo chamado

CMI (Clustered Method Invocation), que, entre outras funcionalidades, oferece uma alternativa

de replicacao para a especificacao RMI. Uma das diferencas do CMI para o RMI convencional

e que o primeiro possui em seu registro JNDI, alem de uma area local, contendo os objetos

registrados localmente em cada servidor, uma area global, compartilhada por todos os servido-

res do cluster. Nessa area global sao registradas informacoes sobre os objetos que devem ser

replicados em mais de um servidor. Dentre essas informacoes, estao, por exemplo, dados sobre

quais servidores possuem o registro de um determinado objeto e qual a polıtica (round-robin,

5.1 JOnAS 54

first available ou random) utilizada para a escolha de um servidor no momento da criacao de

uma referencia remota.

Outra diferenca do CMI em relacao ao RMI e que o stub do objeto remoto criado pelo CMI

possui internamente uma lista de stubs do RMI apontando para os servidores que podem res-

ponder as requisicoes daquele objeto. A lista dos servidores disponıveis e obtida no momento

da criacao do stub e atualizada de tempos em tempos pelo stub do CMI, de forma transparente

para a aplicacao cliente. Dessa modo, toda a logica de balanceamento de carga e de recuperacao

pos-falha fica concentrada na implementacao dos stubs do CMI. Para que os stubs sejam criados

e funcionem corretamente, o CMI deve estar devidamente configurado tambem no lado cliente

da aplicacao.

Outro servico oferecido pelo CMI, dessa vez apenas no lado do servidor, e um mecanismo de

replicacao que pode ser utilizado para propagar aos outros servidores informacoes sobre o es-

tado dos objetos ja criados. Assim, caso um dos servidores venha a falhar, outro servidor podera

continuar respondendo as requisicoes feitas aos objetos originalmente registrados naquele ser-

vidor. Esse mecanismo funciona em conjunto com a logica de balanceamento de carga e de

recuperacao pos-falha dos stubs, essa ultima ficando responsavel apenas por detectar que um

determinado servidor nao esta mais disponıvel e entao escolher um dos outros servidores dis-

ponıveis para onde redirecionar as novas requisicoes. O mecanismo de replicacao do JOnAS

garante que, quando um servidor falha, o novo servidor que assumir o seu papel contera todas

as informacoes necessarias para continuar a responder a todas as requisicoes antes destinadas

ao servidor que falhou.

5.1.2 Uso do JGroups no CMI

Na implementacao do CMI, algumas funcionalidades exigem o uso de um mecanismo de co-

municacao em grupo, para garantir que a troca de mensagens entre os servidores do cluster seja

feita de forma confiavel, atomica e ordenada. Para isso, a atual versao do CMI utiliza varios

servicos e building blocks do JGroups. Esse uso do JGroups pelo CMI se da em duas situacoes:

(i) na implementacao do registro JNDI distribuıdo, para garantir que todas as alteracoes no

registro de qualquer um dos membros sejam propagadas para os outros membros (por exemplo,

quando um novo objeto e incluıdo no registro local de algum servidor); e (ii) na implementacao

do mecanismo de replicacao de objetos, para garantir que todas alteracoes realizadas no estado

de um objeto replicado sejam propagadas para os outros servidores que contenham replicas

desse objeto.

Essas duas situacoes sao descritas em maiores detalhes a seguir.

5.1 JOnAS 55

Registro distribuıdo

O registro distribuıdo utilizado pelo CMI e implementado atraves da classe SynchronizedDistri-

butedTree. Essa classe e utilizada por cada um dos membros do grupo de servidores do JOnAS

para criar uma estrutura de arvore distribuıda, na qual qualquer operacao de escrita (por exem-

plo, adicao e remocao de nos) invocada localmente e automaticamente propagada para os outros

membros do grupo atraves do building block RPCDispatcher do JGroups. Dessa forma, a fun-

cionalidade de distribuicao do registro fica totalmente encapsulada e transparente para o resto

da implementacao do CMI.

Figura 5.2: Utilizacao do RPCDispatcher do JGroups na implementacao do registro distribuıdodo JOnAS.

Outra funcionalidade do JGroups utilizada na implementacao do registro distribuıdo e o meca-

nismo de transferencia de estado entre membros do grupo. Esse mecanismo e requisitado para

transferir o estado entre os servidores sempre que um novo servidor e adicionado ao cluster.

No CMI, a classe SynchronizedDistributedTree e utilizada pela classe JGroupsClusterViewMa-

nager, que contem a logica de criacao dos objetos do lado do servidor e e responsavel por

manter os dados do registro global.

A Figura 5.2 ilustra a utilizacao do RPCDispatcher do JGroups pelo registro distribuıdo do

JOnAS. Pela figura, podemos ver que no no 1 estao registrados dois EJBs e no no 2, apenas

um. Apesar disso, com a utilizacao do registro JNDI distribuıdo, o no 2 podera receber uma

solicitacao para criar um objeto referente ao EJB2, informando ao cliente que ele devera fazer

as requisicoes ao no 1.

5.1 JOnAS 56

Replicacao de objetos

O outro uso do JGroups na implementacao do CMI e a partir da classe JGMessageManager, que

oferece um mecanismo para que um servidor possa propagar aos outros servidores informacoes

sobre o estado de seus objetos ja inicializados. Para implementar esse mecanismo, o JOnAS uti-

liza outro building block do JGroups, o MessageDispatcher. O MessageDispatcher e utilizado

para garantir que, ao continuar a execucao de uma operacao que foi interrompida pela falha de

um servidor, pelo menos um dos servidores disponıveis ja possua o novo estado do objeto alvo

da operacao, de modo que um desses servidores possa assumir o papel do servidor que falhou.

No CMI, a classe JGMessageManager e utilizada pela classe ReplicationManagerImpl, res-

ponsavel pela logica de como o estado dos objetos serao propagados e reconstituıdos em caso de

falha. A classe ReplicationManagerImpl, por sua vez, e utilizada pelo JOnAS na implementacao

de seu servico de alta disponibilidade (HAService), que gerencia todo o processo de replicacao

dos SFSBs.

A Figura 5.3 ilustra a utilizacao do MessageDispatcher do JGroups pelo mecanismo de re-

plicacao de objetos do JOnAS. Nessa Figura, vemos que a replicacao e iniciada quando um

cliente invoca um EJB em um servidor JOnAS. Essa operacao e entao propagada para os outros

servidores a partir da classe HaServiceImpl, que implementa o servico de alta disponibilidade

(HA). Em seguida, a chamada e repassada para a classe ReplicationManagemImpl, que, por

sua vez, a repassa para a classe JGMessageManager. Essa classe contem uma instancia do

MessageDispatcher, usada para enviar a mensagem para os outros membros utilizando a polıtica

GET FIRST, que espera a resposta de pelo menos um membro do grupo antes de continuar a

execucao.

Figura 5.3: Utilizacao do MessageDispatcher do JGroups na implementacao do mecanismo dereplicacao de objetos do JOnAS.

5.2 Migracao do JOnAS para a G2CL 57

5.2 Migracao do JOnAS para a G2CL

Esta secao descreve a estrategia empregada na migracao dos servicos do JOnAS que utilizavam

o JGroups como mecaniso de comunicacao em grupo, para os servicos genericos corresponden-

tes oferecidos pela biblioteca G2CL.

O processo de migracao concentrou-se nas classes SynchronyzedDistributedTree e JGMessage-

Manager, que, como vimos anteriormente, fazem parte da implementacao do CMI. Os detalhes

envolvidos na migracao de cada uma dessas classes sao descritos a seguir.

5.2.1 Migracao da classe SynchronyzedDistributedTree

Como a implementacao original dessa classe depende principalmente do uso do RPCDispatcher

do JGroups, a estrategia de migracao adotada aqui consistiu na substituicao desse building block

do JGroups pelo servico de mesmo nome oferecido pela G2CL. Este processo foi enormemente

facilitado pelo fato de que os servicos de alto nıvel da G2CL oferecem praticamente as mesmas

APIs oferecidas pelos building blocks correspondente do JGroups. Isto permitiu aproveitar

a maior parte da implementacao original dessa classe do JOnAS, exigindo apenas mudancas

mınimas nas declaracoes de importacao de pacote.

O unico trecho de codigo que necessitou de uma maior modificacao foi na parte de criacao do

RPCDispatcher. Na versao original do JOnAS, o RPCDispatcher era criado a partir de um

Channel do JGroups, enquanto na nova versao a criacao do RPCDispatcher e feita a partir de

tres recursos oferecidos pelo jGCS, quais sejam, DataSession, MembershipSession e Service,

que sao as classes exigidas para a criacao de um RPCDispatcher na G2CL.

Outra modificacao realizada foi a maneira como era feita a transferencia de estado entre os

registros. A implementacao original do JOnAS utilizava o mecanismo oferecido pelo proprio

Channel do JGroups. Para isso, a classe SynchronyzedDistributedTree implementava a inter-

face MessageListener, que define os metodos de recuperacao e de instalacao de um estado. Na

nova versao, a troca de estado e feita utilizando o servico StateTransferDataSession e a in-

terface StateListener, ambos oferecidos pela G2CL. Como a interface StateListener da G2CL

define metodos praticamente identicos aos definido pela interface MessageListener do JGroups,

a logica utilizada pelo JOnAS na serializacao e deserializacao de um estado foi totalmente apro-

veitada.

A ultima modificacao realizada na classe SynchronyzedDistributedTree foi na interface ViewLis-

tener, originalmente utilizada pelo JOnAS para notificar os interessados sobre alteracoes nos

5.2 Migracao do JOnAS para a G2CL 58

membros que compartilham uma mesma estrutura de arvore. Essa modificacao foi necessaria

pois a interface ViewListener fazia referencia a classe Address do JGroups, que identifica o

endereco de um membro do grupo. Na nova versao dessa interface, a classe Address foi subs-

tituıda pela classe SocketAddress, que e classe usada para identifica um membro do grupo no

jGCS.

Todas essas modificacoes realizadas na classe SynchronyzedDistributedTree refletiram na classe

JGroupsClusterViewManager, responsavel por inicializar e manipular os dados da arvore de re-

gistro. Na nova versao do JOnAS, essa classe foi substituıda por uma nova classe, chamada

JGCSClusterViewManager, cuja implementacao faz uso da nova implementacao da classe Syn-

chronizedDistributedTree.

5.2.2 Migracao da classe JGMessageManager

Assim como ocorreu com migracao do building block do JGroups utilizado na classe Synch-

ronizedDistributedTree, a migracao do MessageDispatcher, originalmente utilizado na classe

JGMessageManager do JOnAS, para o servico de mesmo nome da G2CL foi relativamente

simples, devido ao fato de que os dois servicos oferecem APIs praticamente identicas. Tambem

como na migracao do RPCDispatcher, o trecho que sofreu maior modificacao foi na parte rela-

tiva a criacao do MessageDispatcher, que teve que ser alterado para criar o servico equivalente

da G2CL utilizando apenas os recursos oferecidos pelo jGCS.

Outro trecho que tambem precisou ser alterado foi na parte que trata do envio e recebimento

de mensagens. A razao e que o JGroups permite que uma mensagem seja criada a partir de

qualquer objeto serializavel. Ja no jGCS so e permitida a criacao de uma mensagem a partir de

um array de bytes, cabendo a aplicacao a tarefa de serializar e deserializar os objetos enviados

e recebidos, respectivamente. Dessa forma, foi necessario incluir na nova versao da classe

JGMessageManager, a logica necessaria para realizar a serializacao/deserializacao dos objetos

embutidos nas mensagens, o que antes era feito pelo proprio JGroups.

As modificacoes realizadas na classe JGMessageManager refletiram diretamente na classe Re-

plicationManagerImpl do CMI, responsavel pela criacao e gerenciamento do mecanismo de

replicacao do JOnAS. Da mesma forma que foi feito com a classe JGroupsClusterViewMa-

nager, duas novas classes, chamadas JGCSMessageManager e JGCSReplicationManagerImpl,

foram criadas para substituir as classes JGMessageManager e ReplicationManagerImpl, res-

pectivamente, na nova versao do JOnAS. Basicamente, essas novas classes mantiveram as

mesmas funcionalidades implementadas nas classes correspondentes da versao anterior, com

a diferenca entre elas ficando restrita a substituicao dos recursos e servicos fornecidos pelo

5.3 Avaliacao do impacto do uso da G2CL no desempenho do JOnAS 59

JGroups para os recursos e servicos equivalentes oferecidos pela G2CL e pelo jGCS.

Por fim, a criacao dessas duas novas classes refletiu tambem na criacao de uma nova classe para

o servico de alta disponibilidade do JOnAS, chamada JGCSHAService. Assim como com as

outras classes que foram substituıdas, essa nova classe difere da anterior apenas na forma de

criar os objetos de que precisa, que passaram a ser instanciados a partir dos recursos e servicos

oferecidos pela G2CL e pelo jGCS, ao inves do JGroups.

5.2.3 Migracao em numeros

Como vimos anteriormente, na migracao do JOnAS realizada para utilizar os servicos ofe-

recidos pela biblioteca G2CL foi necessario modificar varias classes, em diferentes projetos,

incluindo JOnAS, CMI e OW2-UTIL (OW2, 2009). O projeto OW2-UTIL nao foi citado ante-

riormente pois possui apenas classes utilitarias, sem grande importancia para entendimento das

funcionalidades do JOnAS. Para quantificar o esforco envolvido nessa migracao, foi feito um

levantamento do numero total de pacotes e classes de cada um dos projetos e de quanto des-

ses pacotes e classes tiveram que ser modificados para a realizacao da migracao. O resultado

desse levantamento e apresentado na Tabela 5.1. Pela tabela, podemos ver que a maior parte

das modificacoes foram concentradas no projeto CMI, onde foi modificado 11% do projeto,

sob o ponto de vista do total de linhas de codigo. Nos outros projetos, apesar das mudancas

terem sido relativamente pequenas, menos de 1%, ha uma enorme complexidade envolvida nes-

sas mudancas, pois se tratam projetos com grande quantidade de pacotes, classes e linhas de

codigo.

Tabela 5.1: Numeros da migracao do servidor de aplicacao JOnAS.

# Pacotes # Classes # LOCProjeto Total Modificadas (%) Total Modificadas (%) Total Modificadas (%)CMI 80 2 (2,50%) 216 6 (2,78%) 18.691 2.106 (11,28%)OW2-UTIL 235 1 (0,42%) 596 5 (0,84%) 33.538 270 (0,80%)JOnAS 396 1 (0,25%) 2133 1 (0,04%) 180.030 111 (0,06%)TOTAL 711 4 (0,56%) 2945 12 (0,41%) 232.259 2.487 (1,01%)

5.3 Avaliacao do impacto do uso da G2CL no desempenho doJOnAS

Apesar de existirem inumero benefıcios inerentes ao uso de uma API generica, conforme dis-

cutido no capıtulo 2, o possıvel impacto de desempenho causado pela adocao de uma arqui-


tetura fracamente acoplada nao pode ser desconsiderado pelos desenvolvedores. Com essa

preocupacao em mente, foi realizada uma avaliacao inicial do impacto de desempenho decor-

rente do uso da G2CL e do jGCS, com diferentes configuracoes de plugins, na nova versao do

JOnAS. A metodologia utilizada nessa avaliacao e os principais resultados obtidos a partir dela

sao descritos a seguir.

5.3.1 Metodologia

A avaliacao foi realizada em um ambiente tıpico de configuracao do JOnAS, representado pela

Figura 5.4 e descrito a seguir.

Figura 5.4: Cenario de avaliacao do JOnAS.

O ambiente de rede utilizado era composto por oito maquinas conectadas atraves de um switch

dedicado de 10/100 Mbps do tipo Fast Ethernet. As oito maquinas foram configuradas da

seguinte forma: uma das maquinas tinha instalado exclusivamente o servidor Apache versao

2.2.11, o qual era responsavel por realizar o balanceamento de carga entre os servidores da

camada de apresentacao; outra maquina tinha instalados dois servidores operacionais virtua-

lizados atraves do sistema XEN hypervisor (BARHAM et al., 2003), sendo ambos utilizados

como servidores da camada de apresentacao e configurados com servidores JOnAS atuando

tanto como containers WEB e clientes CMI; finalmente, as seis maquinas restantes foram uti-

lizadas como servidores da camada de negocio, e configuradas com servidores JOnAS atuando

como container EJB, com o CMI habilitado no modo servidor e com o servico de alta disponi-

bilidade ativo.

Todas as maquinas utilizaram o sistema operacional Linux Debian, versao 5.0 (kernel 2.6.26-2-

686). A maquina com os dois servidores virtualizados estava configurada com um processador

Intel Core 2 Duo e memoria RAM de 2 GB (DDR2). As maquinas da camada de negocio, por

sua vez, estavam configuradas com um processador Intel Pentium IV (3.00 GHz) e memoria


RAM de 2 GB (DDR2).

Para realizar os experimentos, foi desenvolvida uma aplicacao EJB, com um unico Stateful

Session Bean (SFSB). Este SFSB implementava as funcionalidade tıpicas de um carrinho de

compras em uma aplicacao de comercio eletronico, oferecendo operacoes para incluir, atualizar

e remover itens no carrinho e tambem salvar um pedido. Essa aplicacao foi instalada em todos

os servidores da camada de negocio, com o SFSB sendo configurado como um objeto que de-

veria ser replicado. Alem disso, foi desenvolvida uma aplicacao WEB responsavel por realizar

as invocacoes remotas aos objetos replicados da camada de negocio. Tanto a aplicacao EJB

quanto a aplicacao WEB foram desenvolvidas de modo a criar um cenario de execucao similar

ao cenario utilizado por Lodi et al. para avaliar o desempenho de outros servidores de aplicacao

Java EE (LODI et al., 2007).

Foram executados diferentes conjuntos de experimentos, com o objetivo de avaliar possıveis

diferencas de desempenho entre a versao original do JOnAS, baseada no JGroups, e a nova

versao, baseada na G2CL e no jGCS. No caso da nova versao, foram consideradas tres configu-

racoes distintas, utilizando os plugins do jGCS para o Spread, o JGroups e o Appia, respectiva-

mente.

As duas versoes do JOnAS foram avaliadas em clusters de 4 e 6 servidores. Alem disso, cada

experimento foi realizado com uma quantidade diferente de clientes, com o numero de clien-

tes por experimento variando entre 50 e 100. Esses clientes faziam requisicoes simultaneas a

aplicacao WEB utilizada nos experimentos, de modo a permitir observar o comportamento da

aplicacao, e, por consequencia, do JOnAS, diante de um crescente aumento da demanda pelos

servicos da aplicacao. Para gerar a carga de clientes exigida em cada experimento, foi utilizada

a ferramenta ApacheBench(ab), versao 2.0 (APACHE, 1996).

A aplicacao WEB desenvolvida implementava um conjunto fixo de operacoes sobre o carrinho

de compras, de acordo com o seguinte roteiro. Inicialmente, a aplicacao adicionava tres itens

ao carrinho de compras. Em seguida, a quantidade de dois dos itens do carrinho era alterada e

o terceiro, removido. Cada uma dessas operacoes implicava na alteracao do estado do objeto

replicado que continha os dados do carrinho, fazendo com que o mecanismo de replicacao

do JOnAS propagasse essas alteracoes para todos os outros servidores da camada de negocio.

Por fim, o pedido era salvo pelo usuario, o que internamente era feito armazenando os dados

do pedido em um banco de dados relacional. Neste estudo, foi utilizado o banco de dados

PostgreSQL, versao 8.3 (POSTGRESQL, 2009).

Com relacao a configuracao dos SGCs avaliados, foram consideradas as seguintes configura-

coes.


No caso do JGroups, foram utilizadas as mesmas pilhas de protocolos definidas na versao ori-

ginal do JOnAS. Uma pilha, utilizada no mecanismo de sincronizacao dos registros JNDI dis-

tribuıdos, definiu como protocolo de transporte UDP sobre IP Multicast, com a ordenacao das

mensagens definida para o protocolo SEQUENCER. A outra pilha, utilizada no mecanismo de

replicacao, definiu o mesmo protocolo de transporte da primeira pilha, mas com a ordenacao

das mensagens definida para o protocolo FIFO.

No caso do Spread, que nao permite a reconfiguracao de seus protocolos de transporte, foi uti-

lizado o protocolo de ordenacao total para o mecanismo de sincronizacao dos registros, e o

protocolo FIFO para o mecanismo de replicacao. Em ambos os casos, foi utilizada uma arqui-

tetura de comunicacao completamente descentralizada, com um daemon do Spread executado

em cada membro do grupo de servidores da camada de negocio.

No caso do Appia, foi utilizado o TCP como protocolo de transporte tanto no mecanismo

de sincronizacao dos registros como tambem no mecanismo de replicacao. Assim como na

configuracao dos outros dois sistemas, foram utilizados os protocolos de ordenacao de men-

sagens TOTAL e FIFO para os mecanismos de sincronizacao dos registros e de replicacao,

respectivamente.

Ja com relacao a configuracao do mecanismo de selecao dos servidores da camada de negocio,

que e feita na camada de apresentacao do JOnAS, foi utilizada a polıtica round-robin, a mesma

definida na versao original do JOnAS. Com essa polıtica, os servidores da camada de negocio

sao alocados aos novos clientes de forma alternada, garantindo, assim, um equilıbrio na distri-

buicao da carga entre o todo o grupo de servidores. O uso dessa polıtica tambem garantiu que,

durante a execucao dos experimentos, todos os servidores da camada de negocio receberiam

requisicoes de acesso ao SFSB definido pela aplicacao e, portanto, precisariam continuamente

propagar suas alteracoes de estado aos outros servidores do grupo.

Finalmente, foi utilizado o tempo de resposta das requisicoes como metrica de desempenho

(JAIN, 1991). Neste estudo, essa metrica foi computada calculando a media dos tempos de

resposta medidos por cada cliente durante um mesmo experimento. Assim como na avaliacao

dos sistemas genericos de comunicacao, apresentada no Capıtulo 3, para atingir um intervalo de

confianca de 95% nos resultados, cada experimento foi repetido pelo menos 30 vezes, com os

valores extremos novamente sendo removidos utilizando o metodo boxplots (TRIOLA, 1997).


5.3.2 Resultados

Primeiramente, e feita uma analise de desempenho das duas versoes do JOnAS em funcao

do aumento no numero de requisicoes concorrentes. Em seguida, analisa-se o desempenho das

duas versoes em funcao do aumento no tamanho do cluster de servidores da camada de negocio.

A Figura 5.5 mostra os tempos medios de resposta medidos em funcao do numero de requisicoes

concorrentes ao SFSB da camada de negocio, para um cluster com 6 servidores, tais como

observados para a versao original do JOnAS, bem como para a sua nova versao, baseada no

uso da G2CL e do jGCS. No caso da nova versao, sao mostrados os resultados referentes a tres

diferentes configuracoes do jGCS, utilizando, respectivamente, os seguintes plugins: JGroups,

Spread e Appia.

Figura 5.5: Resultados para as duas versoes do JOnAS em funcao do aumento no numero derequisicoes concorrentes, em um cluster com 6 servidores.

Como pode-se observar na Figura 5.5, o desempenho das diferentes configuracoes consideradas

para a nova versao do JOnAS e influenciado de forma diferente pelo aumento do numero de

requisicoes concorrentes. Isto mostra que o desempenho dos servicos genericos oferecidos pela

G2CL esta diretamente relacionado ao desempenho do SCG acoplado ao jGCS.

Comparando os resultados da versao original do JOnAS, que utiliza o JGroups como meca-

nismo padrao de comunicacao em grupo, com os resultados da nova versao configurada com

o plugin do proprio JGroups, nota-se que ambas apresentam desempenhos muito proximos, e

que essa diferenca diminui a medida que o numero de requisicoes concorrentes aumenta. Isto

mostra que o impacto de desempenho causado apenas pelo uso da G2CL e mınimo (no caso do

experimentos realizados, a diferenca comeca em torno de 27%, para 50 requisicoes concorren-

5.4 Discussao 64

tes, e cai para menos de 5% ja a partir de 70 requisicoes), o que e reforcado pelo fato de que

ambas as versoes compartilham as mesmas pilhas de protocolos.

Ja a nova versao configurada com o plugin do Appia apresentou uma perda de desempenho

praticamente constante, da ordem de 25%, para todas as quantidades de requisicoes avaliadas.

No caso em que a nova versao do JOnAS foi configurada com o plugin do Spread, a perda

de desempenho em relacao a versao original foi ainda maior. Nesse caso, as perdas variaram

entre 29% e 42%, para 60 e 100 requisicoes concorrentes, respectivamente, em relacao ao

desempenho da versao original.

A Figura 5.6, por sua vez, mostra a variacao dos tempos medios de resposta observados para as

duas versoes do JOnAS em funcao do aumento no tamanho do cluster, para o cenario com 100

requisicoes concorrentes. Nessa figura, observa-se que as perdas de desempenho impostas pelas

diferentes configuracoes da nova versao do JOnAS em relacao a versao original mantiveram-se

em patamares muito proximos nos dois tamanhos de cluster. A excecao foi o desempenho da

nova versao configurada com o JGroups, cuja perda de desempenho em relacao a versao original

do JOnAS caiu de cerca de 21%, no cluster com 4 servidores, para apenas 1%, no cluster com

6 servidores.

Figura 5.6: Resultados para as duas versoes do JOnAS em funcao do aumento no tamanho docluster de servidores, com 100 requisicoes concorrentes.

5.4 Discussao

O estudo de caso envolvendo a migracao com sucesso dos mecanismos de sincronizacao de

registros distribuıdos e de replicacao de SFSBs do JOnAS, que na sua versao original utilizavam

o JGroups como solucao de comunicacao em grupo, para os servicos genericos oferecidos pela

5.5 Sumario 65

G2CL, mostrou que a adocao de uma arquitetura de comunicacao fracamente acoplada e uma

alternativa viavel e, portanto, pode ser considerada como uma importante decisao de projeto

por parte dos desenvolvedores de aplicacoes distribuıdas.

Alem disso, os resultados da avaliacao de desempenho realizada mostraram que o impacto cau-

sado pelo uso dos servicos fornecidos pela G2CL esta diretamente relacionado ao desempenho

do SGC acoplado ao jGCS, sendo praticamente independente da implementacao dos servicos

propriamente dita.

Embora nao tenham sido observadas melhorias significativas de desempenho na nova versao do

JOnAS, com quaisquer das configuracoes avaliadas, em relacao ao desempenho da versao ori-

ginal, o fato da G2CL oferecer um baixo overhead, quando configurada com as mesmas pilhas

de protocolos utilizadas originalmente pelo JOnAS, nao deixa de ser um resultado promissor.

Isto porque, caso venha a surgir um novo SCG oferecendo um desempenho superior aos SCGs

avaliados neste trabalho, ou mesmo alguns desses sistemas venham a apresentar melhorias sig-

nificativas de desempenho em versoes futuras, a nova versao do JOnAS, atraves das facilidades

de reconfiguracao de servicos oferecidas pela G2CL e pelo jGCS, e com um mınimo esforco de

programacao, estara pronta para usufruir rapidamente desses ganhos.

5.5 Sumario

Este capıtulo apresentou um estudo de caso sobre a migracao de um sistema real, no caso, o

servidor de aplicacao Java EE 5 JOnAS, que originalmente utilizava o JGroups como solucao

de comunicacao grupo, para utilizar os servicos genericos oferecidos pela G2CL. Em essencia,

foi mostrado que a utilizacao da solucao generica proposta, composta pelo jGCS e pela G2CL,

e uma alternativa viavel, tanto do ponto de vista de esforco de desenvolvimento quanto de

desempenho.

No proximo capıtulo, o trabalho sera concluıdo com uma reflexao sobre os principais resultados

obtidos e algumas sugestoes para trabalhos futuros.

66

Capıtulo 6

Conclusao

Este capıtulo apresenta a conclusao deste trabalho, destacando os principais resultados obtidos

e sugestoes para trabalhos futuros.

6.1 Contribuicoes e resultados

Inicialmente, este trabalho realizou um estudo sobre o impacto causado pela utilizacao de duas

API genericas de comunicacao em grupo, Hedera e jGCS, em relacao aos tres sistemas que elas

encapsulavam, quais sejam, JGroups, Appia e Spread. Os resultados desse estudo mostraram

que, para determinados tamanhos de mensagens e configuracoes de rede, a utilizacao de uma

solucao generica eficiente, como o jGCS, pode ser uma alternativa viavel de projeto e ate mesmo

propiciar ganhos de desempenho para a aplicacao (SALES et al., 2009a, 2009b).

Apesar dos importantes benefıcios que podem trazer para o desenvolvimento de aplicacoes

distribuıdas, as APIs genericas atuais ainda nao sao suficientes para suprir as necessidades de

aplicacoes que demandas servicos de comunicacao em grupo mais sofisticados, como a transfe-

rencia de estado entre membros e a invocacao de objetos remotos replicados. Visando contribuir

para diminuir as diferencas entre os servicos genericos de comunicacao em grupo disponıveis

atualmente e as necessidades de aplicacoes distribuıdas reais, este trabalho apresentou uma

nova biblioteca de servicos genericos de comunicacao em grupo, chamada G2CL, a qual foi

implementada como uma camada acima da API generica do jGCS.

Com o intuito de validar a solucao proposta, foi feito um estudo de caso envolvendo o servidor

de aplicacao Java EE JOnAS, onde o sistema de comunicacao em grupo originalmente utilizado

pelo JOnAS, no caso, o JGroups, foi substituıdo pela API generica do jGCS juntamente com os

servicos genericos da biblitoeca G2CL. Esse estudo tambem avaliou o impacto de desempenho

causado pelo uso do jGCS e da G2CL na nova versao do JOnAS, sendo constatado que esse

6.2 Sugestoes para trabalhos futuros 67

impacto e diretamente relacionado com o desempenho do sistema de comunicacao em grupo

que esta sendo encapsulado pelo jGCS.

6.2 Sugestoes para trabalhos futuros

Uma linha interessante para trabalhos futuros e avaliar o impacto da biblioteca G2CL em clus-

ters formados por um maior numero de maquinas, e tambem sob outros pontos de vista, como,

por exemplo, custo de processamento e consumo de memoria.

Outro melhoria importante e viabilizar o monitoramento e gerenciamento dos sistemas de

comunicacao em grupo acoplados a API generica do jGCS, atraves do uso de tecnologias com-

patıveis com o padrao Java Management eXtension (JMX), como ja ocorre com o JGroups.

Por fim, novos servicos poderiam ser implementados e adicionados a biblioteca G2CL, possi-

bilitando que mais aplicacoes possam se beneficiar de seus servicos e funcionalidades.

68

Referencias Bibliograficas

ABDELLATIF, T.; CECCHET, E.; LACHAIZE, R. Evaluation of a Group CommunicationMiddleware for Clustered J2EE Application Servers. In: Proceedings of the 6th InternationalSymposium on Distributed Objects and Applications (DOA’04). Agia Napa, Cyprus: Springer,2004. p. 1571–1589.

ALUR, D.; MALKS, D.; CRUPI, J.; BOOCH, G.; FOWLER, M. Core J2EE Patterns: BestPractices and Design Strategies. 2nd.. ed. Mountain View, CA, USA: Sun Microsystems, Inc.,2001.

AMIR, Y.; DANILOV, C.; MISKIN-AMIR, M.; SCHULTZ, J.; STANTON, J. The SpreadToolkit: Architecture and Performance. Johns Hopkins University, 2004.

AMIR, Y.; DANILOV, C.; STANTON, J. A Low Latency, Loss Tolerant Architecture andProtocol for Wide Area Group Communication. In: Proceedings of the 2000 InternationalConference on Dependable Systems and Networks (FTCS-30, DCCA-8). New York, NY, USA:IEEE CS Press, 2000. p. 327–336.

APACHE. Apache HTTP server benchmarking tool. 1996. Disponıvel em:<http://httpd.apache.org/docs/2.0/programs/ab.html>.

BALDONI, R.; CIMMINO, S.; MARCHETTI, C.; TERMINI, A.; TERMINI, R. PerformanceAnalysis of Java Group Toolkits: A Case Study. In: Proceedings of International Workshopon Scientific Engineering for Distributed Java Applications (FIDJI’02). Luxembourg,Luxembourg: Springer, 2002. p. 49–60.

BAN, B. Design and Implementation of a Reliable Group Communication Toolkit for Java.Cornell University, 1998.

BAN, B. A Flexible API for State Transfer in the JavaGroups Toolkit. Unpublished manuscript.2007.

BARHAM, P.; DRAGOVIC, B.; FRASER, K.; HAND, S.; HARRIS, T.; HO, A.;NEUGEBAUER, R.; PRATT, I.; WARFIELD, A. Xen and the Art of Virtualization. In:Proceedings of the 19th ACM symposium on Operating systems principles (SOSP’03). BoltonLanding, NY, USA: ACM Press, 2003. p. 164–177.

CARVALHO, N.; PEREIRA, J.; RODRIGUES, L. Towards a Generic Group CommunicationService. In: Proceedings of the 8th International Symposium on Distributed Objects andApplications (DOA’06). Montpellier, France: Springer, 2006. p. 1485–1502.

CHOCKLER, G. V.; KEIDAR, I.; VITENBERG, R. Group Communication Specifications: AComprehensive Study. ACM Computing Surveys, ACM Press, New York, NY, USA, v. 33, n. 4,p. 427–469, 2001.

Referencias Bibliograficas 69

COULORIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed Systems – Concepts andDesign. 4th. ed. Boston, MA, USA: Addison-Wesley, 2005.

DABEK, F.; ZHAO, B.; DRUSCHEL, P.; KUBIATOWICZ, J.; STOICA, I. Towards aCommon API for Structured Peer-to-Peer Overlays. In: Proceedings of the 2nd InternationalWorkshop on Peer-to-Peer Systems (IPTPS’03). Berkeley, CA, USA: Springer, 2003. p. 33–44.

EUGSTER, P. T.; FELBER, P. A.; GUERRAOUI, R.; KERMARREC, A.-M. The many facesof publish/subscribe. ACM Comput. Surv., ACM, New York, NY, USA, v. 35, n. 2, p. 114–131,2003. ISSN 0360-0300.

FOWLER, M. Inversion of Control – IoC. 2004. Disponıvel em:<http://martinfowler.com/articles/injection.html>.

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements ofReusable Object-Oriented Software. Boston, MA, USA: Addison-Wesley, 1995.

GELERNTER, D. Generative communication in linda. ACM Trans. Program. Lang. Syst.,ACM, New York, NY, USA, v. 7, n. 1, p. 80–112, 1985. ISSN 0164-0925.

GLASSFISH. GlassFish – Open Source Application Server. 2008. Disponıvel em:<https://glassfish.dev.java.net/>.

GNU. GNU General Public License, version 2. 1991. Disponıvel em:<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>.

HEDERA. Hedera Group Communications Wrappers. 2008. Disponıvel em:<http://hederagc.sourceforge.net/>.

HOARE, C. A. R. Monitors: An Operating System Structuring Concept. Comm. ACM, ACMPress, New York, NY, USA, v. 17, n. 10, p. 549–557, 1974.

JAIN, R. The Art of Computer Systems Performance Analysis: Techniques for ExperimentalDesign, Measurement, Simulation, and Modeling. New York, NY, USA: Wiley-Interscience,1991.

JGROUPS. JGroups – Building Blocks. 2009. Disponıvel em:<http://www.jgroups.org/blocks.html>.

JGROUPS. JGroups – Performance. 2009. Disponıvel em:<http://www.jgroups.org/performance.html>.

JONAS. JOnAS – Java Open Application Server. 2009. Disponıvel em:<http://jonas.ow2.org/>.

JXTA. JXTA Community Project. 2008. Disponıvel em: <https://jxta.dev.java.net/>.

LODI, G.; PANZIERI, F.; ROSSI, D.; TURRINI, E. SLA-Driven Clustering of QoS-AwareApplication Servers. IEEE Transactions on Software Engineering, v. 33, n. 3, p. 186–197,2007.

MACLENNAN, B. J. Principles of Programming Languages: Design, Evaluation, andImplementation. 3rd. ed. Austin, TX, USA: Oxford University Press, 1999.

Referencias Bibliograficas 70

MIRANDA, H.; PINTO, A.; RODRIGUES, L. Appia – a Flexible Protocol Kernel SupportingMultiple Coordinated Channels. In: Proceedings of the 21st International Conference onDistributed Computing Systems (ICDCS’01). Phoenix (Mesa), Arizona, USA: IEEE CS Press,2001. p. 707–710.

NAGLE, J. Congestion Control in IP/TCP Internetworks. ACM SIGCOMM ComputerCommunication Review, ACM Press, New York, NY, USA, v. 14, n. 4, p. 11–17, 1984.

OW2. OW2 – UTIL. 2009. Disponıvel em:<svn://svn.forge.objectweborg/svnroot/easybeans/tags/OW2 UTIL 1 0 12>.

PEREIRA, J.; RODRIGUES, L.; MONTEIRO, M. J.; OLIVEIRA, R.; KERMARREC, A. M.NEEM: Network-friendly Epidemic Multicast. In: Proceedings of the 22nd Symposium onReliable Distributed Systems (SRDS’03). Florence, Italy: IEEE CS Press, 2003. p. 15–24.

PIETZUCH, P.; EYERS, D.; KOUNEV, S.; SHAND, B. Towards a Common API forPublish/Subscribe. In: Proceedings of the 2007 Inaugural International Conference onDistributed Event-based Systems. Toronto, Ontario, Canada: ACM, 2007. p. 152–157.

POSTGRESQL. PostgreSQL. 2009. Disponıvel em: <http://www.postgresql.org/>.

SALES, L.; MENDONCA, N. C.; BARBOSA, R.; D’ORLEANS, J.; TRINTA, F.; TEOFILO,H. Um Estudo do Impacto de Desempenho de Dois Sistemas Genericos de Comunicacaoem Grupo sobre o JGroups. In: Anais do IX Workshop de Sistemas Computacionais de AltoDesempenho (WSCAD-SSC’08). Campo Grande, MS, Brasil: SBC, 2008. p. 161–168.

SALES, L.; TEOFILO, H.; D’ORLEANS, J.; MENDONCA, N. C.; BARBOSA, R.; TRINTA,F. An Evaluation of the Performance Impact of Generic APIs on Two Group CommunicationSystems. In: Anais do XXVII Simposio Brasileiro de Redes de Computadores e SistemasDistribuıdos (SBRC’09). Recife, PE, Brasil: SBC, 2009. p. 801–812.

SALES, L.; TEOFILO, H.; D’ORLEANS, J.; MENDONCA, N. C.; BARBOSA, R.; TRINTA,F. Performance Impact Analysis of Two Generic Group Communication APIs. In: Proceedingsof the 1st IEEE International Workshop on Middleware Engineering (ME’09). Bellevue, WA,USA: IEEE CS Press, 2009. p. 148–153.

SHOAL. Shoal – A Dynamic Clustering Framework. 2008. Disponıvel em:<https://shoal.dev.java.net/>.

SUN. Java Platform, Enterprise Edition (Java EE). 2006. Disponıvel em:<http://java.sun.com/javaee/>.

TRIOLA, M. F. Elementary Statistics. 7th. ed. Boston, MA, USA: Addison-Wesley, 1997.

Livros Grátis( http://www.livrosgratis.com.br )

Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas










http://www.livrosgratis.com.br/cat_1/administracao/1







http://www.livrosgratis.com.br/cat_2/agronomia/1







http://www.livrosgratis.com.br/cat_3/arquitetura/1







http://www.livrosgratis.com.br/cat_4/artes/1







http://www.livrosgratis.com.br/cat_5/astronomia/1







http://www.livrosgratis.com.br/cat_6/biologia_geral/1









http://www.livrosgratis.com.br/cat_8/ciencia_da_computacao/1











http://www.livrosgratis.com.br/cat_9/ciencia_da_informacao/1











http://www.livrosgratis.com.br/cat_7/ciencia_politica/1









http://www.livrosgratis.com.br/cat_10/ciencias_da_saude/1











http://www.livrosgratis.com.br/cat_11/comunicacao/1







http://www.livrosgratis.com.br/cat_12/conselho_nacional_de_educacao_-_cne/1















http://www.livrosgratis.com.br/cat_13/defesa_civil/1









http://www.livrosgratis.com.br/cat_14/direito/1







http://www.livrosgratis.com.br/cat_15/direitos_humanos/1









http://www.livrosgratis.com.br/cat_16/economia/1







http://www.livrosgratis.com.br/cat_17/economia_domestica/1









http://www.livrosgratis.com.br/cat_18/educacao/1







http://www.livrosgratis.com.br/cat_19/educacao_-_transito/1









http://www.livrosgratis.com.br/cat_20/educacao_fisica/1









http://www.livrosgratis.com.br/cat_21/engenharia_aeroespacial/1









http://www.livrosgratis.com.br/cat_22/farmacia/1







http://www.livrosgratis.com.br/cat_23/filosofia/1







http://www.livrosgratis.com.br/cat_24/fisica/1







http://www.livrosgratis.com.br/cat_25/geociencias/1







http://www.livrosgratis.com.br/cat_26/geografia/1







http://www.livrosgratis.com.br/cat_27/historia/1







http://www.livrosgratis.com.br/cat_31/linguas/1







Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo

http://www.livrosgratis.com.br/cat_28/literatura/1







http://www.livrosgratis.com.br/cat_30/literatura_de_cordel/1











http://www.livrosgratis.com.br/cat_29/literatura_infantil/1









http://www.livrosgratis.com.br/cat_32/matematica/1







http://www.livrosgratis.com.br/cat_33/medicina/1







http://www.livrosgratis.com.br/cat_34/medicina_veterinaria/1









http://www.livrosgratis.com.br/cat_35/meio_ambiente/1









http://www.livrosgratis.com.br/cat_36/meteorologia/1







http://www.livrosgratis.com.br/cat_45/monografias_e_tcc/1







http://www.livrosgratis.com.br/cat_37/multidisciplinar/1





http://www.livrosgratis.com.br/cat_38/musica/1







http://www.livrosgratis.com.br/cat_39/psicologia/1







http://www.livrosgratis.com.br/cat_40/quimica/1







http://www.livrosgratis.com.br/cat_41/saude_coletiva/1









http://www.livrosgratis.com.br/cat_42/servico_social/1









http://www.livrosgratis.com.br/cat_43/sociologia/1







http://www.livrosgratis.com.br/cat_44/teologia/1







http://www.livrosgratis.com.br/cat_46/trabalho/1







http://www.livrosgratis.com.br/cat_47/turismo/1







Projeto, Implementac¸ao e Avaliac¸˜ ao de uma˜ Camada...

Documents

Transcript of Projeto, Implementac¸ao e Avaliac¸˜ ao de uma˜ Camada...