Implementação de um middleware publish/subscribe de larga escala

(1)

Tiˆ

e Teixeira Lima Penatti

TOLER ˆ

ANCIA A INTRUS ˜

OES EM

MIDDLEWARE PUBLISH/SUBSCRIBE DE

LARGA ESCALA

Florian´opolis

(2)

Tiˆ

e Teixeira Lima Penatti

TOLER ˆ

ANCIA A INTRUS ˜

OES EM

MIDDLEWARE PUBLISH/SUBSCRIBE DE

LARGA ESCALA

Trabalho apresentado na disciplina INE5328, ministrada pelo Professor Renato Cislaghi, como Trabalho de Conclusão do Curso de Bacharelado em Ciências da Computa¸cão pela Universidade Federal de Santa Catarina.

Orientador: Rafael Rodrigues Obelheiro

Florian´opolis

(3)

Tiˆ

e Teixeira Lima Penatti

TOLER ˆ

ANCIA A INTRUS ˜

OES EM MIDDLEWARE

PUBLISH/SUBSCRIBE DE LARGA ESCALA

Trabalho de conclusão de curso apresentado como requisito parcial para obeten¸cão do t´ıtulo de Bacharel em Ciência da Computa¸cão e aprovada pela banca examinadora

constitu´ıda pelos doutores:

Dr. Rafael Rodrigues Obelheiro DAS - UFSC

Orientador

Prof. Dr. Frank Siqueira INE - UFSC

Msc. Eduardo Alchieri DAS - UFSC

(4)

(5)

AGRADECIMENTOS

Agrade¸co primeiramente a Deus pelas oportunidades que tive em minha vida, e me possibilitaram estar aqui agora.

Agrade¸co aos meus pais, especialmente a minha m˜ae, Raquel, por acreditar e investir em mim incondicionalmente, e por tudo mais, enfim, por ser minha m˜ae.

Aos colegas de classe, amizades que criei e que n˜ao se acabar˜ao com o fim do curso.

Agrade¸co a minha t˜ao querida Paulinha, por compartilhar comigo durante grande parte do curso momentos e sentimentos maravilhosos e inesquec´ıveis. E por sempre acre-ditar no meu potencial e me apoiar em qualquer momento.

Ao pessoal da automa¸cão pela inicia¸cão cient´ıfica, Alysson pelos trabalhos anteriores e pela motiva¸cão deste, Obelheiro pela excelente orienta¸cão, Eduardo pelas conversas e ajudas, e ao professor Frank pela valiosa co-orienta¸cão.

(6)

“N˜ao sabendo que era imposs´ıvel, foi la e fez” - Jean Cocteau

(7)

RESUMO

Na área de programa¸cão distribu´ıda, o modelo de comunica¸cão conhecida como pu-blish/subscribe é encontrado nas mais diversas áreas de aplica¸cão. Ele apresenta diversas qualidades como baixo acoplamento e alta escalabilidade, e por isso praticamente todas as plataformas/padrões de middleware implementam ou definem algum tipo de suporte a este. Essas implementa¸cões são, em sua maioria, centralizadas, i.e., o canal (ou dissemi-nador) de eventos é implementado em um único servidor. Isto traz alguns problemas: por ser um ponto único, o canal de eventos central está sujeito a falhas, e pode ficar sobrecar-regado. Além disso, se estiver distribu´ıdo em larga escala, sobre a Internet, pode tornar a comunica¸cão publishers-subscribers extremamente ineficiente. Para resolver estes pro-blemas, foram desenvolvidos sistemas em larga escala, que são sistemas publish/subscribe com diversos disseminadores, formando uma rede overlay sobre a rede de larga escala (Internet). Esses disseminadores possuem algoritmos de roteamento próprios para disse-mina¸cão de informa¸cões de controle e eventos entre os processos que querem se comu-nicar. Grande parte das implementa¸cões existentes não trata de viola¸cões de seguran¸ca complexas. Em vista disso, este trabalho propõe fazer a integra¸cão de uma rede overlay tolerante a intrusões (já desenvolvida e estudada por Obelheiro, 2006) com um sistema publish/subscribe em larga escala, baseado em servi¸cos Web, seguindo as especifica¸cões para publish/subscribe em servi¸cos Web, o WS-Notification, desenvolvida pelo consórcio OASIS.

(8)

ABSTRACT

In distributed programming area, a communication model known as publish/subscribe is found in the most diverse areas of application. It presents diverse qualities like low cou-pling and high scalability, and therefore practically all the platforms/standards of mid-dleware implement or support it. These implementations are, in its majority, centered, i.e., the events channel (or disseminator) are implemented in just one server. This brings some problems: for being a lonely point, the central event channel is subject to faults, and can be overloaded. In a large scale context, over the Internet, the publish-subscribe communication can become extremely inefficient. To solve these problems, systems had been developed on a large scale, which are publish/subscribe with many disseminators, forming an overlay network on a wide scale network (Internet). These disseminators has proper routing algorithms for dissemination of control and event information between the processes that want to communicate themselves. Great part of the existing implementati-ons does not deal with complex breakings of security. In this context, this work proposes the integration of an intrusion tolerant overlay network (already developed and studied by Obelheiro, 2006) with a large scale publish/subscribe system, based in Web servi-ces, following the specifications for publish/subscribe in Web serviservi-ces, WS-Notification, developed by OASIS consortiun.

(9)

SUM ´

ARIO

Lista de Figuras Lista de Siglas 1 Introdu¸cão p. 12 1.1 Motiva¸cão . . . p. 12 1.2 Objetivos . . . p. 13 1.3 Organiza¸cão do texto . . . p. 13 2 Publish/Subscribe p. 15 2.1 Defini¸cão . . . p. 15

2.2 Uso e Aplica¸c˜oes . . . p. 16

2.3 Dificuldades . . . p. 17

2.4 Resumo do cap´ıtulo . . . p. 18

3 Servi¸cos Web p. 19

3.1 Defini¸cão e uso . . . p. 19 3.2 WS-Notification . . . p. 22 3.2.1 WS-BaseNotification . . . p. 23 3.3 Resumo do cap´ıtulo . . . p. 25 4 Muse p. 26 4.1 Defini¸cão e Uso . . . p. 26 4.2 Modelo de Programa¸cão . . . p. 27

(10)

4.2.1 Descritor de implanta¸cão (Deployment Descriptor) . . . p. 29 4.3 Implementa¸cão do WS-Notification . . . p. 30 4.4 Resumo do cap´ıtulo . . . p. 31 5 Redes Overlay p. 32 5.1 Defini¸cão e uso . . . p. 32 5.2 ROTI . . . p. 33 5.3 Adapta¸cões . . . p. 36 5.4 Resumo do cap´ıtulo . . . p. 39 6 Integra¸cão p. 41

6.1 Altera¸c˜oes no Muse . . . p. 41

6.2 Resultados . . . p. 44

6.3 Resumo do cap´ıtulo . . . p. 45

7 Conclus˜ao p. 46

7.1 Perspectivas futuras . . . p. 47

(11)

LISTA DE FIGURAS

2.1 Publish/subscribe simples . . . p. 15

2.2 Publish/subscribe em larga escala . . . p. 17

3.1 Rela¸c˜ao entre clientes e fornecedores de servi¸co Web, SOAP, WSDL e

UDDI . . . p. 21

4.1 Modelo de programa¸c˜ao do Muse (retirada do s´ıtio do Muse) . . . p. 28

5.1 Exemplo de rede overlay . . . p. 33

5.2 Intera¸c˜ao entre os sub-sistemas da ROTI (OBELHEIRO; FRAGA, 2005) p. 35

5.3 Estrutura das classes da ROTI usando o simulador (OBELHEIRO, 2006) p. 40

6.1 Pilha nativa do Muse . . . p. 42

6.2 Pontos de altera¸c˜ao do framework Muse . . . p. 43

6.3 Pilha adaptada `a ROTI . . . p. 43

6.4 Tempos de respostas de diferentes vers˜oes do Muse . . . p. 44

(12)

API Application Programming Interface CORBA Common Object Request Broker Architecture

DiffServ Differentiated Services EPR End-Point Reference FTP File Transfer Protocol

HMAC Hash Message Authentication Code HTML Hypertext Markup Format HTTP Hypertext Transfer Protocol

ICP Infra-estrutura de Chave P´ublica IntServ Integrated Services

IP Internet Protocol

ITON Intrusion Tolerant Overlay Network JEE Java Enterprise Edition JMS Java Message Service MAC Middle Access Control

OASIS Organization for the Advancement of Structured Information Standards RMI Remote Method Invocation

ROTI Rede Overlay Tolerante `a Intrus˜oes RPC Remote Procedure Call RTT Round-Trip Time SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol

TCP Transmission Control Protocol

UDDI Universal Description, Discovery and Integration UDP User Datagram Protocol

URI Uniform Resource Identifier URL Uniform Resource Locator WSN Web Services Notification WSRF Web Services Resource Framework

WSA Web Service Addressing WSR Web Service Resource WSBF Web Service Base Faults WSRL Web Service Resource Lifetime WSRP Web Service Resource Properties

(13)

WSSG Web Service Service Group

WSRMD Web Service Resource Metadata Descriptor WSDM Web Service Distributed Management WSBaN Web Service Base Notification WSBrN Web Service Brokered Notification

WST Web Service Topics WS Web Service

W3C World Wide Web Consortiun WSDL Web Service Description Language

(14)

12

1 INTRODU ¸

C ˜

AO

1.1 MOTIVA ¸

C ˜

AO

O atual avan¸co da computa¸cão, de modo geral, e o crescimento exponencial da Inter-net, têm exigido cada vez mais das aplica¸cões distribu´ıdas (aplica¸cões que executam em mais de uma máquina). Estas têm desafiado os pesquisadores de sistemas distribu´ıdos a definirem novos modelos e algoritmos que possam lidar com sua complexidade, hete-rogeneidade, dinamismo e escala. Dentre estas aplica¸cões, muitas trabalham com um número indefinido de participantes que se altera durante a sua execu¸cão. Um modelo de comunica¸cão que se adapta muito bem a este cenário é conhecido como publish/subscribe (EUGSTER et al., 2003).

Veremos que implementa¸cões simples deste modelo, como são encontradas na maioria das especifica¸cões e implementa¸cões, não atendem aos requisitos das aplica¸cões distribu´ı-das atuais, geralmente executadistribu´ı-das no contexto da Internet. Uma poss´ıvel solu¸cão é o uso de sistemas em larga escala, baseados em redes overlay. Grande parte das implementa-¸cões de overlays ainda não levam em conta todas amea¸cas à seguran¸ca, com destaque para comportamento malicioso. Entretanto, Obelheiro (2006) desenvolveu um overlay tolerante a intrusões, que será usado como infra-estrutura para nosso trabalho. Ela irá fornecer requisitos de seguran¸ca como também uma maior disponibilidade dos servi¸cos oferecidos.

Por outro lado, um padrão de comunica¸cão distribu´ıda que também se adapta bem neste atual cenário é o de servi¸cos Web. Ele vem tendo um grande crescimento e aceita¸cão na área de programa¸cão distribu´ıda gra¸cas às suas versatilidade, interoperabilidade e inde-pendência de plataforma, que são garantidas pelo protocolo SOAP, baseado na linguagem XML (Extensible Markup Language). A comunica¸cão deste protocolo se baseia na troca de documentos XML entre diferentes hosts, utilizando para isso qualquer protocolo de transporte e aplica¸cão, como por exemplo, HTTP, ou UDP. Com isso, poder´ıamos juntar esses conceitos, concretizando alguns objetivos detalhados adiante.

(15)

13

1.2 OBJETIVOS

O objetivo geral deste trabalho é desenvolver uma infra-estrutura publish/subscribe para sistemas distribu´ıdos de larga escala satisfazendo a requisitos de seguran¸ca e tole-rância a faltas. Para isso, são definidos os seguintes objetivos espec´ıficos:

• realizar estudos sobre redes overlay e servi¸cos Web, incluindo as especifica¸c˜oes sobre notifica¸c˜oes (Web Service Notifications);

• portar e adaptar uma rede overlay j´a desenvolvida (OBELHEIRO, 2006), imple-mentada em um simulador, para que trabalhe na rede real, utilizando a pilha de protocolos UDP/IP;

• e integrar uma aplica¸c˜ao que implementa o sistema publish/subscribe usando servi¸cos Web com esta rede, constituindo um middleware1 tolerante a intrus˜oes e falhas.

1.3 ORGANIZA ¸

C ˜

AO DO TEXTO

Este trabalho est´a organizado em sete cap´ıtulos. Este cap´ıtulo inicial descreveu o contexto do trabalho.

O cap´ıtulo 2 apresenta a descri¸cão do modelo publish/subscribe, seus pontos positivos e negativos, algumas aplica¸cões e varia¸cões encontradas na literatura.

O cap´ıtulo 3 contém uma revisão dos conceitos e especifica¸cões sobre servi¸cos Web, e uma ênfase maior é dada às especifica¸cões voltadas ao modelo publish-subscribe: é mos-trada em detalhe a especifica¸cão do OASIS (OASIS, 2007) chamada de WS-Notification.

Para facilitar a implementa¸cão destes padrões e a integra¸cão com a estrutura de larga escala, utilizamos como ponto de partida um framework de aplica¸cões desenvolvido pela Apache, conhecido como Muse. O cap´ıtulo 4 mostra detalhadamente o funcionamento deste framework, como ele implementa as especifica¸cões, e como suporta a aplica¸cão que executa sobre ele.

O cap´ıtulo 5 apresenta os principais conceitos referentes a redes overlay, e nos intro-duz a rede ROTI (OBELHEIRO, 2006), mostrando suas caracter´ısticas, e as adapta¸c˜oes

1_{Podemos definir middleware num contexto distribu´ıdo como sendo uma camada de software que faz}

a intermedia¸cão entre aplica¸cões (que utilizam o middleware) e o sistema operacional, que realiza o I/O para a rede. Abstraindo um pouco mais, podemos defin´ı-lo como a camada de software que cuida da comunica¸cão entre duas ou mais aplica¸cões distribu´ıdas, ocultando ao desenvolvedor dependências de máquina como plataforma utilizada, protocolo de comunica¸cão e sistema operacional.

(16)

14

necess´arias para se integrar a este trabalho.

Por fim, o cap´ıtulo 6 descreve a integra¸cão feita entre a rede overlay e o sistema publish/subscribe, bem como os resultados obtidos e os testes de confiabilidade e desem-penho. Em seguida, são discutidas as conclusões do trabalho, onde é apresentada uma visão geral do que foi obtido, as qualidades e os pontos fracos, bem como as poss´ıveis continua¸cões deste trabalho.

(17)

15

2 PUBLISH/SUBSCRIBE

Esse cap´ıtulo apresenta a descri¸cão do modelo publish/subscribe, mostrando as prin-cipais vantagens deste modelo, assim como suas limita¸cões. Em seguida são relatadas algumas varia¸cões deste modelo encontradas na literatura, juntamente com alguns exem-plos de utiliza¸cão destes.

2.1 DEFINI ¸

C ˜

AO

Publish/subscribe é um modelo de comunica¸cão distribu´ıda. Neste modelo temos um conjunto de processos que se registram (subscribers) para o recebimento de eventos de um determinado tipo. Quando um processo (publisher ) publica um novo evento deste tipo, todos os processos que registraram seu interesse são notificados. Em geral, um ou mais mediadores ou disseminadores são responsáveis pela propaga¸cão ass´ıncrona de eventos de seus produtores até os interessados.

Figura 2.1: Publish/subscribe simples

Como podemos observar na figura 2.1, em um sistema publish/subscribe simples temos geralmente um conjunto de participantes no papel de produtores (publishers) de eventos, e um outro conjunto no papel de consumidores (subscribers). O produtor cria eventos e os publica no canal de eventos (uma abstra¸c˜ao que captura a no¸c˜ao de tipo de evento,

(18)

16

algumas vezes chamado de tópico). Os consumidores que se registraram neste canal de eventos sempre recebem os eventos publicados pelos produtores. É interessante ressal-tar que este modelo implementa o suporte básico de comunica¸cão desacoplada em três dimensões (EUGSTER et al., 2003):

• desacoplados no espa¸co: os produtores n˜ao necessariamente conhecem os consumi-dores;

• desacoplados no tempo: produtores e consumidores n˜ao precisam participar ativa-mente na intera¸c˜ao durante o mesmo tempo;

• desacoplados em sincronia: produtores n˜ao ficam bloqueados esperando at´e que os consumidores receberam os eventos.

O fato de possuir um baixo acoplamento também ajuda a tornar este modelo bem es-calável: adicionar ou retirar produtores e consumidores sem afetar o resto da comunica¸cão e a qualquer momento se torna muito simples.

2.2 USO E APLICA ¸

C ˜

OES

Existem muitas varia¸cões do modelo descrito acima, entretanto o conceito básico permanece sempre o mesmo. Dadas as qualidades deste modelo, em especial o de-sacoplamento, comunica¸cão ass´ıncrona e simplicidade, praticamente todas as platafor-mas/padrões de middleware implementam ou definem algum tipo de suporte a este: no JEE (Java Enterprise Edition) temos o JMS (Java Message Service) (SUN, 2005), nos servi¸cos Web temos o WS-Notification (GRAHAN; HULL; MURRAY, 2006) e no CORBA (Common Object Request Broker Architecture) temos os Servi¸cos de Eventos (OMG, 2004a) e Notifica¸cão (OMG, 2004b).

Dada a grande versatilidade deste modelo, seus benef´ıcios, e sua ampla disponibili-dade e implementa¸cão, praticamente qualquer aplica¸cão distribu´ıda poderia utilizar como estrutura um modelo publish/subscribe. Como simples exemplos temos programas de co-munica¸cão instantânea, programas de e-mails, jogos, sistemas utilizados no controle de telefonia, etc.

(19)

17

2.3 DIFICULDADES

Grande parte das implementa¸cões de publish/subscribe existentes são centralizadas, i.e., o canal de eventos é implementado em um servidor que recebe eventos publicados por publishers e os dissemina para os subscribers interessados. Esse mecanismo centralizado traz três problemas (EUGSTER et al., 2003):

1. O disseminador de eventos é um ponto único de falhas, podendo também ser alvo de ataques e outros incidentes de seguran¸ca;

2. O disseminador de eventos pode ficar sobrecarregado em ambientes com muitos processos (publishers e subscribers) e uma alta taxa de dissemina¸c˜ao de eventos;

3. A comunica¸c˜ao entre o disseminador de eventos e os processos comunicantes pode ser extremamente ineficiente se estes ´ultimos estiverem distribu´ıdos por uma rede de larga escala geograficamente distribu´ıda, como a Internet.

Visando contornar estas limita¸cões (especialmente a 2 e a 3) foram desenvolvidos sistemas publish/subscribe de larga escala. Esses sistemas consideram uma rede de disse-minadores de eventos instalada sobre a rede de larga escala. Os dissedisse-minadores possuem algoritmos de roteamento próprios para dissemina¸cão de informa¸cões de controle (subscri-¸cão e cancelamento de subscri¸cão) e eventos entre os processos que se comunicam através do sistema. A figura 2.2 ilustra essa idéia.

Figura 2.2: Publish/subscribe em larga escala

Na figura 2.2 podemos ver uma rede de disseminadores de eventos conectando dois publishers a quatro subscribers. As setas em cinza nessa rede mostram a rota de dissemi-na¸cão de um evento desde o processo que o publicou até os subscribers que têm interesse nele. A tarefa fundamental dessa rede é fazer com que informa¸cões de controle e eventos

(20)

18

sejam disseminadas eficientemente no sistema publish/subscribe, superando as limita¸c˜oes supracitadas de um sistema simples. Esses disseminadores de eventos formam uma rede overlay, que ser´a discutida em maiores detalhes no cap´ıtulo 5, sobre a rede de larga escala que conecta esses processos (Internet).

2.4 RESUMO DO CAP´

ITULO

Comunica¸cões ponto-a-ponto e s´ıncronas tornam uma aplica¸cão distribu´ıda estática e pouco flex´ıvel, dificultando muito o desenvolvimento de aplica¸cões dinâmicas e de larga escala. Como alternativa a esse quadro temos o modelo de comunica¸cão publish/subscribe. Esse modelo de aplica¸cões é bastante genérico, portanto adaptável a inúmeras situa¸cões, sendo uma ótima op¸cão de comunica¸cão entre aplica¸cões distribu´ıdas. O modelo pu-blish/subscribe fornece a um usuário final uma API de comunica¸cão simples, versátil e eficiente, sendo portanto uma ótima op¸cão para nosso trabalho. O próximo cap´ıtulo apresenta a descri¸cão de servi¸cos Web e descreve o padrão WS-Notifications, padrão que especifica um modelo publish/subscribe baseado nesse tipo de servi¸co.

(21)

19

3 SERVI ¸

COS WEB

Esse cap´ıtulo apresenta a descri¸cão da tecnologia conhecida como servi¸cos Web enfa-tizando sua interoperabilidade, e apontando suas limita¸cões. Em seguida é descrito com maior detalhe o padrão pra servi¸cos Web que implementa o modelo descrito no cap´ıtulo 2, denominado Web Service Notification.

3.1 DEFINI ¸

C ˜

AO E USO

O grupo World Wide Web Consortium é um consórcio criado para desenvolver tec-nologias (especifica¸cões, software, e ferramentas) vinculadas à Internet, entre elas uma conhecida como servi¸cos Web. Eles definem servi¸co Web como um sistema de software desenvolvido para fornecer comunica¸cão entre diferentes máquinas ligadas por uma rede, o que caracteriza sistemas distribu´ıdos. Porém, seu grande diferencial de tecnologias como Common Object Request Broker Architecture (CORBA), Java Remote Method Invocation (RMI), etc, é fornecer um ambiente distribu´ıdo independente de plataforma (arquitetura de máquina, sistema operacional), linguagem de programa¸cão ou protocolos utilizados na Internet (como HTTP, SMTP ou algum outro protocolo proprietário). Isso é poss´ıvel gra¸cas ao protocolo em que se baseia, chamado de SOAP, detalhado mais adiante e à utiliza¸cão da linguagem XML, que fornece uma forma de representar os dados indepen-dentemente de linguagens de programa¸cão. Vogels (2003) enfatiza que a grande idéia dos servi¸cos Web é o fato da comunica¸cão se dar por troca de documentos XML, que contém todas as informa¸cões espec´ıficas que o servi¸co precisa para executar e responder ao requisitante. Outras caracter´ısticas deste sistema incluem (CHAPPELL; JEWELL, 2002):

• Baixo acoplamento entre clientes e servidores: o consumidor de um servi¸co web não está diretamente ligado à sua interface, que pode alterar durante o tempo sem comprometer a habilidade do cliente de interagir com o fornecedor do servi¸co;

(22)

20

• Sincronismo: servi¸cos Web podem ser s´ıncronos ou ass´ıncronos, ou seja, o cliente pode (sincronamente) ou não (assincronamente) bloquear e ficar esperando até que uma solicita¸cão seja processada e respondida. No modo ass´ıncrono, que é essencial para o baixo acoplamento, o cliente invoca um servi¸co e pode logo em seguida execu-tar outras fun¸cões, retornando mais tarde para receber o resultado, ou ser informado por um sistema de call back, onde o servidor contata o cliente para responder à re-quisi¸cão;

• Suporte a chamadas remotas de procedimento (RPCs): servi¸cos Web permitem a clientes a chamada de m´etodos, fun¸c˜oes e procedimentos em objetos remotos;

• Permite troca de documentos: por se basear em XML, o protocolo SOAP pode trans-mitir não apenas dados, mas também qualquer tipo de documento, quão complexo for.

Juntamente com servi¸cos Web, outras tecnologias ganharam espa¸co, e complementam o uso destes servi¸cos. O nome do protocolo SOAP teve origem do acrónimo Simple Object Access Protocol, mas é um nome que não expressa de maneira correta o significado do protocolo (SOAP não é um protocolo de acesso a objetos), então passou a ser chamado apenas de SOAP. Ele se baseia na troca de documentos em XML entre provedores e requisitantes de servi¸cos Web, padronizando as estruturas de transporte desses documen-tos sobre uma variedade de padrões de tecnologias da Internet, incluindo HTTP, FTP, SMTP, SNMP, TCP, UDP, etc. Entretanto, HTTP é sem dúvida o mais difundido destes padrões, por ser largamente utilizado na Internet. Fundamentalmente, mensagens SOAP são mensagens “one way” de um remetente a um destinatário, entretanto, freqüentemente são combinadas de forma a implementar um par de requisi¸cão-resposta. Uma mensagem SOAP é definida com o nome de envelope (SOAP envelop), e consiste em dois poss´ıveis elementos, o cabe¸calho e o corpo. No cabe¸calho são colocadas informa¸cões sobre o sistema e no corpo o documento a ser processado pelo servi¸co Web. Este protocolo também define padrões para codificar chamadas de métodos RPC que não utilizam XML em documentos XML para o transporte.

Web Service Description Language (WSDL) é uma tecnologia, também baseada em XML, que descreve a interface de um servi¸co Web de um modo padronizado. Ela permite especificar como um servi¸co representa sua entrada e sua sa´ıda, os parâmetros de invoca-¸cão, a estrutura de tipos complexos, definidos pelo usuário (estruturas compostas por um ou mais tipos primitivos como inteiros ou strings), se os métodos possuem retorno ou são somente “one way”. Ou seja, um WSDL é um documento XML que descreve

(23)

detalhada-21

mente todas as poss´ıveis formas de intera¸cão com o servi¸co, útil a um cliente que deseja saber como utilizá-lo.

Por fim, temos uma tecnologia conhecida como Universal Description, Discovery, and Integration (UDDI). Ela possibilita informar, disponibilizar e descobrir servi¸cos dispo-n´ıveis na Web, atrav´es de um amplo registro de WSDLs. Um cliente utiliza o UDDI para procurar (por nomes, categorias, identificadores, etc) servi¸cos dispon´ıveis na Web. A figura 3.1 ilustra a intera¸c˜ao entre estas tecnologias. As setas que ligam o UDDI represen-tam trocas de documentos WSDL, enquanto que as trocas entre o cliente e o fornecedor do servi¸co representam troca de documentos SOAP. A linha tracejada representa uma resposta opcional.

Cliente

UDDI

Serviço

SOAP

WSDL

Figura 3.1: Rela¸c˜ao entre clientes e fornecedores de servi¸co Web, SOAP, WSDL e UDDI

Servi¸cos Web vˆem tendo uma grande aceita¸c˜ao e crescimento, principalmente devido `

a sua versatilidade e independência de plataforma. Eles podem ser utilizados nos mais diversos contextos e finalidades, como por exemplo, um servi¸co Web que fornece a con-versão de valor entre distintas moedas, ou um servi¸co de tradu¸cão de linguagens naturais, como do inglês para o português, ou até em servi¸cos mais complexos, como transa¸cões bancárias que necessitam de seguran¸ca e confiabilidade. Justamente para ajudar em casos como este (servi¸cos Web mais sofisticados), existem diversas especifica¸cões que comple-mentam e padronizam o uso destes servi¸cos. Podemos citar aqui diversos deles, criados e mantidos por diferentes organiza¸cões:

• WS-Addressing, provˆe padr˜oes de endere¸camento;

(24)

22

• WS-Resource Framework, define um framework aberto e gen´erico que modela um recurso;

• WS-Reliable Messaging, define formas de garantir a entrega de mensagens utilizando servi¸cos Web;

• WS-Notification, padroniza o modelo publish/subscribe utilizando servi¸cos Web.

Este último é um padrão que foi utilizado neste trabalho, portanto será detalhado a seguir.

3.2 WS-NOTIFICATION

WS-Notification é uma fam´ılia de especifica¸cões formais de um sistema de comunica¸cão seguindo o modelo publish/subscribe implementado em servi¸cos Web, composta por três documentos:

• WS-BaseNotification (GRAHAN; HULL; MURRAY, 2006)

• WS-BrokeredNotification (OASIS, 2006a)

• WS-Topics (OASIS, 2006b)

Todos est˜ao atualmente na vers˜ao 1.3, disponibilizados em outubro de 2006 no endere¸co do s´ıtio da OASIS (OASIS, 2007).

O primeiro documento especifica a forma como a comunica¸cão básica entre publishers e subscribers deve ser feita, e é tratado em mais detalhes na próxima se¸cão. O segundo define a interface NotificationBroker, que representa um servi¸co Web intermediário a pu-blishers e subscribers quando o publisher não é implementado diretamente como um for-necedor de servi¸co. O terceiro documento, WS-Topics, define um mecanismo de divisão de mensagens conhecido como tópico. Um tópico é uma abstra¸cão que categoriza ou divide as notifica¸cões. Quando uma notifica¸cão é criada, ela é associada a um ou mais tópicos, e subscribers podem usar tópicos como filtros de notifica¸cões, recebendo apenas as notifica¸cões que lhe forem de interesse.

O WS-Topics define três formas de descrever tópicos, chamadas de expression dialects. A primeira forma, mais simples, chamada de SimpleTopicExpression Dialect, é represen-tada simplesmente por um nome de tópico e uma mensagem como conteúdo. A segunda forma é chamada de ConcreteTopicExpression Dialect e permite a defini¸cão de mais de

(25)

23

um tópico sob uma hierarquia, na forma de árvore, mas tendo apenas um tópico raiz. Já a terceira forma é chamada de FullTopicExpression Dialect. Esta forma define a expressão de um tópico como sendo composto por um ou mais tópicos ra´ızes, cada um podendo conter sua própria árvore, e também define o uso do caractere “*” para representar todos os tópicos filhos de um dado tópico e da expressão “//” para representar toda uma sub-´

arvore. Esta última ainda possibilita a defini¸cão de um tópico como sendo um aliás de outro tópico (ou um conjunto deles). De acordo com esta estrutura, a primeira forma é um sub-conjunto da segunda, e a segunda, por sua vez, é um sub-conjunto da terceira.

3.2.1 WS-BASENOTIFICATION

A especifica¸cão WS-BaseNotification define um padrão para servi¸cos Web que segue a abordagem publish/subscribe baseada em tópicos, padronizando as terminologias, con-ceitos, opera¸cões, trocas de mensagens, e WSDL. Neste documento são conceituados os elementos NotificationProducer e NotificationConsumer, que implementam suas respecti-vas interfaces (homônimas, mostradas a seguir) e que representam publishers e subscribers, conforme já foram descritos no cap´ıtulo 2. É definido o termo Subscription como sendo o elemento que representa a união entre um Consumer e um Producer (incluindo algum poss´ıvel filtro de mensagens ou o próprio tópico utilizado), ou seja, representa o interesse de um Consumer em receber notifica¸cões do Producer. Um recurso Subscription é criado no momento que um NotificationProducer recebe uma solicita¸cão de subscription de um NotificationConsumer. Os recursos Subscription são controlados por mensagens envia-das ao SubscriptionManager, um servi¸co Web representado por um End-Point Reference1 (EPR), que implementa a interface SubscriptionManager, descrita mais adiante, mas ba-sicamente permite a consulta e manipula¸cão das Subscriptions manipuladas por ele. Um recurso SubscriptionManager está subordinado ao NotificationProducer, e geralmente é implementado pelo provedor do servi¸co do NotificationProducer. Um Subscriber é um ele-mento que envia a mensagem de Subscribe a um NotificationProducer, mas não precisa ser necessariamente um NotificationConsumer. É importante notar que um esquema clássico publish/subscribe é composto por uma entidade central (comumente chamada de canal de eventos), que faz o desacoplamento da comunica¸cão entre produtores e consumidores. Essa entidade é descrita na especifica¸cão WS-BrokeredNotification (OASIS, 2006a) e não será estudada profundamente neste trabalho.

1_{A defini¸}_c˜_{ao formal de EPR est´}_{a no documento Web Service Addressing (W3C, 2004), disponibilizado}

pelo consórcio W3, mas basicamente representa uma forma de se referenciar ou identificar o endere¸co ou local por onde um servi¸co pode ser acessado, e contém informa¸cões que podem ser processadas indepen-dente de protocolo de transporte ou aplica¸cão.

(26)

24

NOTIFICATIONCONSUMER INTERFACE

Essa interface define que NotificationConsumers podem receber notifica¸cões simples, contendo somente o dado espec´ıfico da aplica¸cão, ou receber mensagens Notify. Existe uma estrutura padrão de tags XML que devem ser seguidas para montar uma mensagem Notify, detalhada com exemplos na especifica¸cão (GRAHAN; HULL; MURRAY, 2006).

NOTIFICATIONPRODUCER INTERFACE

Essa interface define que devem ser aceitas duas mensagens, Subscribe e GetCur-rentMessage. A primeira, enviada por um Subscriber, indica ao NotificationProducer o interesse de um Consumer em determinado tópico, e se for aceito, o producer precisa responder com uma mensagem de confirma¸cão contendo a referência ao recurso Subs-cription. Se forem recebidas duas mensagens Subscribe iguais, devem ser criados dois Subscriptions. A segunda mensagem, GetCurrentMessage, deve retornar uma cópia da ´

ultima Notification publicada no determinado tópico, possibilitando que um Consumer recém-inscrito receba a notifica¸cão que outros Consumers previamente inscritos no tópico já haviam recebido. Um recurso NotificationProducer pode implementar também os pa-drões WS-ResourceProperties (WSRP), e se for o caso, deve conter os atributos referentes aos tópicos por ele aceitos. Assim um Subscriber pode consultar quais tópicos são aceitos.

SUBSCRIPTIONMANAGER INTERFACE

Essa interface define mensagens para manipular um recurso Subscription, controlando ent˜ao seu ciclo de vida:

• Renew - Usada para alterar o tempo de dura¸c˜ao de um recurso Subscription

• Unsubscribe - Usada para encerrar um recurso Subscription

• PauseSubscription - Pode ser implementada opcionalmente, e interrompe momen-taneamente a produ¸c˜ao de Notifications

• ResumeSubscription - Implementada opcionalmente com a anterior, retoma a pro-du¸c˜ao de Notifications no determinado recurso Subscription

(27)

25

3.3 RESUMO DO CAP´

ITULO

Servi¸cos Web fornecem um ambiente distribu´ıdo independente de plataforma e pro-tocolo, sendo bastante prop´ıcio para uso neste trabalho, que irá utilizar os servi¸cos de uma rede overlay (explicada no cap´ıtulo 5) como protocolo de transmissão de mensagens SOAP, e utiliza como base a implementa¸cão das especifica¸cões de publish/subscribe para servi¸cos Web, descrito no próximo cap´ıtulo.

Foi visto também que a especifica¸cão WS-Notifications define basicamente as interfa-ces NotificationProducer e NotificationConsumer e os métodos que implementam (subs-cribe e notify, respectivamente), padronizando assim a forma e os parâmetros destas mesnsagens SOAP.

(28)

26

4 MUSE

Este cap´ıtulo apresenta a aplica¸cão Muse, implementa¸cão das especifica¸cões que for-necerão a comunica¸cão seguindo o padrão publish/subscribe utilizando como base a co-munica¸cão por servi¸cos Web.

4.1 DEFINI ¸

C ˜

AO E USO

O projeto Apache Muse consiste em um framework implementado na linguagem Java, que segue uma série de especifica¸cões descritas mais adiante. E uma implementa¸c˜´ ao aberta, dispon´ıvel no s´ıtio da Apache Software Foundation (APACHE, 2007b), de três padrões de servi¸cos Web, ambos especificados pelo grupo OASIS (OASIS, 2007):

• WS-ResourceFramework (WSRF) WS-Resource (WS-R) WS-BaseFaults (WS-BF) WS-ResourceLifetime (WS-RL) WS-ResourceProperties (WS-RP) WS-ServiceGroup (WS-SG) WS-ResourceMetadataDescriptor (WS-RMD) • WS-Notification (WSN) WS-BaseNotification (WS-BN) WS-Topics (WS-T) • WS-DistributedManagement (WSDM)

Este framework permite aos seus usuários a constru¸cão de suas aplica¸cões baseadas em servi¸cos Web, compat´ıveis com os padrões descritos acima, sem despender muito tempo na

(29)

27

implementa¸cão da especifica¸cão em si. O Muse inclui toda a parte de parser XML-Objetos Java, abstra¸cões de baixo n´ıvel referentes à conexão de rede e protocolos HTTP e SOAP, uma API de persistência, onde usuários podem recuperar o estado de um servi¸co Web após a reinicializa¸cão do host, e ferramentas de automatiza¸cão de documentos WSDL, próprias para a implanta¸cão (deployment ) usando Axis2 (APACHE, 2007a). Entre estas ferramentes, está dispon´ıvel uma chamada WSDL-to-Java, que, dado um arquivo WSDL, permite a gera¸cão do código correspondente a descri¸cão do arquivo, tanto para o lado cliente quanto para o servidor.

Este framework permite que desenvolvedores de aplica¸cões utilizem o modelo de co-munica¸cão publish/subscribe descrito na especifica¸cão WS-Notification para sua aplica¸cão, sem se preocupar com toda a parte de baixo n´ıvel que faz a conexão f´ısica entre os hosts com a implementa¸cão da especifica¸cão em si, tornando a programa¸cão da aplica¸cão mais rápida e eficiente. Vale ressaltar que o Muse não implementa uma entidade central na comunica¸cão publish/subscribe, comforme especificado por WS-BrokeredNotification (OA-SIS, 2006a), portanto a comunica¸cão se dá ponto-a-ponto, conforme explicado no cap´ıtulo 3, que descreve a especifica¸cão WS-BaseNotification.

O que mais nos interessa é a implementa¸cão do segundo padrão, que já foi discu-tido em detalhes na se¸cão 3.2. Para entender melhor o funcionamento do Muse, ele nos disponibiliza um modelo de programa¸cão, descrito a seguir.

4.2 MODELO DE PROGRAMA ¸

C ˜

AO

O framework Muse foi implementado com base em quatro conceitos:

• Capability, que é a abstra¸cão de um conjunto de dados e opera¸cões que são expostas por um servi¸co Web. É a menor unidade de representa¸cão de um servi¸co, sendo representada por simples classes Java.

• Resource (recurso), que é a abstra¸cão de todos os dados e opera¸cões de um servi¸co Web, descrito pelo documento WSDL. É representado por um conjunto de Capabi-lities.

• Um conceito chamado de Implied Resource Pattern, que é a abstra¸cão de um tipo de dado usado para guardar valores referentes à rede e dados de execu¸cão necessários para localizar um recurso e invocar seus métodos. Ou seja, guarda a rela¸cão direta entre os recursos e os endere¸cos EPR que os representam.

(30)

28

• A camada de isolamento, que é a abstra¸cão de uma camada que guarda dados referentes a plataforma utilizada, possibilitando que a camada de lógica seja imple-mentada uma única vez e mantenha o funcionamento em diferentes ambientes ou plataformas, como servidores de aplica¸cões J2EE, OSGI, etc...

Esses conceitos se relacionam da forma ilustrada pela figura 4.1.

Figura 4.1: Modelo de programa¸c˜ao do Muse (retirada do s´ıtio do Muse)

A camada de isolameto é o ponto de inicializa¸cão do framework e é também o ponto de chegada de requisi¸cões. Como o nome indica, esta camada é dependente da plataforma (protocolo de transporte e aplica¸cão utilizado, sistema operacional, etc) utilizada, no caso é utilizado o protocolo HTTP, tendo o Tomcat como web-container e o Axis como engine, ambos desenvolvido pela Apache. A fun¸cão desta camada é isolar essas dependências das próximas camadas (roteador de recursos, gerenciador de recursos, recursos e capabilities, como podemos observar na figura 4.1), inicializar o roteador (quando receber a primeira requisi¸cão) e a ele delegar qualquer requisi¸cão SOAP recém-chegada.

O conceito Implied Resource Pattern é implementado pelas camadas gerenciador de recursos e roteador de recursos, conforme mostra a figura 4.1. O roteador é a abstra¸cão da porta de acesso à camada de resource, situada logo após a camada de isolamento, portanto não depende da plataforma utilizada. Em uma aplica¸cão deve existir apenas uma instância da classe ResourceRouter, entretanto, essa aplica¸cão pode implementar diversos recursos, cada um representado por um documento WSDL diferente. Um roteador é responsável por instanciar todos os recursos descritos no arquivo de configura¸cão do

(31)

29

Muse, e delegar uma requisi¸cão SOAP qualquer, recebida pela camada de isolamento, para o objeto resource responsável. Para isso, o roteador analisa o cabe¸calho SOAP e através do padrão WS-Adressing determina qual o endere¸co EPR de destino. Com este, ele solicita ao ResourceManager o resource responsável pelo EPR, e delega a ele a opera¸cão. Ou seja, o ResourceManager é responsável por manter a rela¸cão de objetos resource e endere¸cos EPR correspondentes.

Então, cada recurso é representado por um arquivo WSDL, que define um único endere¸co EPR. Ele é responsável por delegar à capability responsável as requisi¸cões vindas do roteador, e por inicializar e gerenciar as capabilities que implementam esse recurso. É também um ponto de acesso entre capabilities (quando querem comunicar-se entre si utilizam o recurso como intermediador). Por fim, a capability é a unidade final, que realmente implementa a opera¸cão requisitada pelo cliente via SOAP. Ela é representada por uma URI, que a identifica unicamente perante o recurso. Esta classe é inspecionada durante a inicializa¸cão para saber quais métodos dentre os descritos no WSDL ela é responsável por implementar.

O Muse fornece ao usuário final, então, um modelo de agrega¸cão, montando uma interface através dos padrões implementados no framework e op¸cões personalizadas, que podem incluir port types ou comportamentos associados é funcionalidades espec´ıficas do contexto da aplica¸cão. Podemos utilizá-lo de duas maneiras: descrevendo-os no arquivo WSDL, que será lido pelo cliente, e/ou utilizando a API do Muse, no lado do servidor.

4.2.1 DESCRITOR DE IMPLANTA ¸

C ˜

AO (DEPLOYMENT

DES-CRIPTOR)

O Muse apresenta um arquivo de configura¸cão escrito em XML chamado de muse.xml, onde é feita a descri¸cão de detalhes da implanta¸cão. Ele armazena importantes informa-¸cões de configura¸cões como qual o n´ıvel de logs que desejamos receber, em qual arquivo será gravado, quais recursos a aplica¸cão (Muse) deverá gerenciar, a quais arquivos WSDL estão vinculados, qual a classe que o implementa, quais capabilities serão usados para implementar as opera¸cões descritas no WSDL, juntamente com a URI que identifica uni-camente cada capability.

(32)

30

4.3 IMPLEMENTA ¸

C ˜

AO DO WS-NOTIFICATION

Conforme é especificado no WS-Notification e descrito na se¸cão 3.2, o Muse imple-menta as interfaces NotificationConsumer, NotificationProducer e SubscriptionManager. Além destas, ele apresenta a NotificationMessage, que representa um tipo de dado descrito no WS-Notification 1.3 schema, e que é utilizado nas opera¸cões Notify e GetCurrentMes-sage. Todas interfaces criadas pelo Muse são implementadas de modo padrão em um pacote cujo nome é derivado da classe, acrescentando-se o sufixo .impl, e o prefixo Simple. Por exemplo, a interface org.apache.muse.ws.notification.NotificationProducer é implementada por org.apache.muse.ws.notification.impl.SimpleNotificationProducer. Essa implementa¸cão permite que, se optarmos por desenvolver uma classe mais espec´ıfica, adaptada a uma determinada aplica¸cão, tenhamos um baixo acoplamento, facilitando a altera¸cão.

Todas estas classes e interfaces derivam da classe Capability, que tem seu ciclo de vida (cria¸cão, inicializa¸cão, e destrui¸cão) gerenciado pelo framework. Quando especificamos quais capabilities e resources farão parte da aplica¸cão, através do arquivo de descri¸cão de implanta¸cão, o Muse analisa o arquivo WSDL correspondente a cada resource, e garante que cada opera¸cão definida neste arquivo possui um método Java equivalente procurando em cada capability, através da chamada Class.getMethods(), até encontrar um método de mesmo nome, mas com a primeira letra minúscula.

A capability NotificationProducer, ao receber uma requisi¸cão Subscribe, cria um Subs-cription WsResource, cujo ciclo de vida pode ser controlado pelo cliente, que fez a re-quisi¸cão. Essas subscriptions são gerenciadas pelo ResourceManager do Muse, mas são referenciadas pelo NotificationProducer para que enviem as notifica¸cões para os interes-sados corretos, no tempo certo. Esta capability não pode ser usada se não for junto com o recurso SubscriptionManager. Se não forem implantadas juntas, a inicializa¸cão desta capability irá falhar.

A capability SubscriptionManager representa o acordo entre um produtor e um consu-midor interessado em receber as notifica¸cões. Destruir um recurso destes significa romper esta rela¸cão, e com isto o consumidor não receberá mais mensagens. O Muse representa todas as subscriptions como recursos impl´ıcitos WS-RF. Eles são acess´ıveis por um único EPR que pode ser destru´ıdo pelo WS-ResourceLifetime (se for usado).

(33)

31

4.4 RESUMO DO CAP´

ITULO

O Muse foi implementado visando utilizá-lo sobre o protocolo HTTP, utilizando um Web-Container como gerenciador de conexões TCP para o recebimento de mensa-gens SOAP. Para o envio de requisi¸cões, o framework utiliza métodos da interface Java java.net.Connection, que abrem diretamente uma conexão TCP/IP na rede para o envio de requisi¸cões SOAP. Como queremos que ele não utilize a rede real (Internet), e sim a rede overlay, apresentada no próximo cap´ıtulo, necessitamos fazer algumas altera¸cões, que serão explicadas e detalhadas no cap´ıtulo 6.

(34)

32

5 REDES OVERLAY

Sistemas de comunica¸c˜ao distribu´ıda seguindo o modelo publish/subscribe em larga escala s˜ao sistemas que consideram uma rede de disseminadores de eventos instalada sobre uma rede de larga escala como a Internet, ou um subconjunto dela, como em redes overlay, conforme veremos a seguir.

5.1 DEFINI ¸

C ˜

AO E USO

Redes overlay são redes virtuais, lógicas, que são constru´ıdas sobre uma rede já exis-tente, como a Internet. Cada nó overlay é também um nó da rede subjacente. Um enlace virtual é o nome dado à conexão entre dois nós virtuais, e corresponde à rota da rede subjacente que os conecta. A figura 5.1 ilustra um exemplo deste tipo de rede. Note que um enlace virtual pode ser implementado por mais de um nó da rede subjacente, e que o roteamento na rede overlay segue critérios espec´ıficos da aplica¸cão que utiliza o overlay, envolvendo apenas nós e enlaces virtuais, sem interferência no roteamento da rede subja-cente. Em outras palavras, o roteamento da rede lógica não tem controle nenhum sobre o roteamento da rede subjacente, porém pode controlar por quais nós virtuais a informa¸cão deve passar até alcan¸car o destino.

Um tipo de rede overlay que tem ganhado destaque, sendo bastante utilizado é co-nhecido como overlay de roteamento. Esse tipo de overlay tem por objetivo substituir o servi¸co de roteamento da camada de rede da arquitetura de protocolos TCP/IP, ofere-cendo uma interface de servi¸cos equivalente à da camada de rede, mas agregando novas funcionalidades, e implementa pacotes de dados da aplica¸cão acima, que utiliza os ser-vi¸cos desta camada, e de controle ou roteamento, utilizados no protocolo de roteamento do overlay. Ambos são encapsulados como dados nos protocolos das camadas inferiores, assim como já acontece entre as camadas do modelo TCP/IP.

Um grande atrativo de redes overlay ´e a possibilidade de adicionar novas funciona-lidades e quafunciona-lidades de servi¸co diferenciadas sem a necessidade de qualquer altera¸c˜ao

(35)

33

rede subjacente

rede lógica

Figura 5.1: Exemplo de rede overlay

de infra-estrutura na rede, o que é atualmente um dos maiores problemas da Internet. Propostas de funcionalidades que atuam na camada de rede (como IntServ, DiffServ, IP Multicast, o próprio IPv6...) necessitam de uma altera¸cão na infra-estrutura f´ısica que não possui demanda técnico-econômica que o permita ou justifique a altera¸cão. É necessária a altera¸cão de todos os roteadores da rede, o que possui um alto custo financeiro, e as especifica¸cões de tais funcionalidades são muitas vezes imaturas e bastante voláteis. Os softwares, por serem bastante atuais, muitas vezes são pouco testados, podendo causar instabilidade. Além disso, geralmente não há mecanismos claros e seguros que viabilizem estas transi¸cões. Assim, redes overlay ganham merecida importância.

Para este trabalho foi escolhida uma implementa¸cão de rede overlay dispon´ıvel livre-mente, detalhada na próxima se¸cão.

5.2 ROTI

Dentre os diversos propósitos para os quais são usados redes overlay destacam-se a tolerância a falhas do roteamento Internet e multicast em n´ıvel de aplica¸cão. A maior parte das propostas de redes existentes, porém, trata apenas de cenários simples de fa-lhas, como queda de algum enlace ou roteador por falta de energia ou outro acidente. Não se encontra a preocupa¸cão com a ocorrência de comportamento malicioso devido a viola¸cões de seguran¸ca, como invasão de algum nodo. Exemplos de comportamento mali-cioso podem ser inje¸cão de pacotes falsos de controle da rede com a inten¸cão de prejudicar seu funcionamento, a modifica¸cão ou altera¸cão de rotas, o descarte seletivo de pacotes, etc. Outro comportamento tipicamente malicioso consiste em responder corretamente a

(36)

34

pacotes de controle, como probes1, e se recusar a transmitir pacotes de dados. Neste con-texto foi desenvolvida uma rede overlay denominada Rede Overlay Tolerante a Intrusões (ROTI) (OBELHEIRO, 2006; OBELHEIRO; FRAGA, 2005), que é capaz de assegurar a comunica¸cão entre os nós do overlay mesmo que parte dos nós da rede falhe ou tenha a sua seguran¸ca comprometida.

Sua arquitetura b´asica est´a dividida em alguns sub-sistemas:

• API do usuário, que oferece à aplica¸cão servi¸cos de comunica¸cão de dados, base-ados nas primitivas send e receive;

• subsistema de encaminhamento, responsável por transmitir dados vindos da aplica¸cão encapsulando-os em pacotes de dados ROTI, e recepcionar pacotes de dados roteados e disponibilizá-lo na forma de dados escritos em um buffer até que uma aplica¸cão fa¸ca a leitura destes dados;

• cache de rotas, que mant´em armazenadas diversas rotas conhecidas da rede, man-tendo assim informa¸c˜oes sobre alcan¸cabilidade de alguns nodos, servindo o subsis-tema de encaminhamanto;

• subsistema de roteamento, que é responsável por gerenciar as rotas mantidas em caches e por realizar toda troca de informa¸cões de controle do roteamento;

• subsistema de deteçcão de falhas e recupera¸cão de faltas, que monitora da-dos estat´ısticos como a latência média das transmissões e o ´ındice de perdas, forne-cidos pelos subsistemas de encaminhamento e roteamento, e baseado neles identifica uma falha, agindo diretamente nesses subsistemas para realizar a recupera¸cão;

• gerência criptográfica é a parte que gerencia todo o esquema de seguran¸ca base-ado em criptografia e na infra-estrutura de chaves públicas (ICP). Esta parte ainda está sendo desenvolvida.

Uma representa¸cão da intera¸cão entre esses sub-sistemas pode ser observada na figura 5.2. Nela são utilizadas setas tracejadas para indicar fluxo de controle e setas cont´ınuas para fluxo de dados.

1_{Probes s˜}_{ao mecanismos bastante utilizados para se verificar se n´}_{os est˜}_{ao alcan¸}_c´_{aveis e funcionando}

corretamente. Entretanto este mecanismo detecta apenas falhas “benignas”, não levando em considera¸cão comportamento malicioso, uma vez que um nó malicioso pode responder perfeitamente às mensagens de probe, porém se recusar a entregar uma mensagem de dados, por exemplo.

(37)

35

Figura 5.2: Intera¸c˜ao entre os sub-sistemas da ROTI (OBELHEIRO; FRAGA, 2005)

As amea¸cas de seguran¸ca às quais nós (incluindo os nós virtuais) na Internet estão sujeitos podem ser divididas basicamente em três classes: confidencialidade, integri-dade e disponibiliintegri-dade. As amea¸cas à confidencialidade dizem respeito a pessoas não autorizadas obterem acesso a mensagens da rede. Essas amea¸cas não foram tratadas na implementa¸cão da ROTI discutida neste trabalho.

As amea¸cas à integridade, por sua vez, podem se subdividir em três grupos: modifi-ca¸cão não autorizada, falsifica¸cão de mensagens e replay de mensagens. Os dois primei-ros grupos de amea¸cas são contornados com uso de assinaturas digitais, baseadas numa infra-estrutura de chaves públicas, na parte de controle, e na parte de dados são usados mecanismos de keyed-Hash Message Authentication Codes (HMACs)2 . Já as amea¸cas de replay de mensagens, que consistem em reproduzir mensagens anteriormente enviadas a fim de confundir e atrapalhar a comunica¸cão, são contornadas adicionando um controle de número de seqüência de pacotes.

As amea¸cas à disponibilidade, que compõem o principal foco desta implementa¸cão, podem também ser divididas em três sub-grupos: descarte de pacotes, desvio de pacotes e sobrecarga. O descarte de pacotes de controle é tratado com simples retransmissões periódicas, caracterizando o roteamento pró-ativo. O descarte de pacotes de dados é tratado primeiramente com retransmissões, seguido da altera¸cão da rota utilizada, e ainda, se ela continuar faltosa posteriormente, sua invalida¸cão definitiva. O problema de desvios

2_{HMACs s˜}_{ao mecanismos criptogr´}_{aficos baseados em chaves sim´}_{etricas compartilhadas, que garantem}

(38)

36

de pacotes de controle é tratado com a verifica¸cão das rotas de cada pacote. Nos pacotes de dados, além desta verifica¸cão, é utilizado o mesmo comportamento quanto ao descarte de pacotes. Por fim, amea¸cas referentes a sobrecarga, que não representam o objetivo da implementa¸cão, são tratadas apenas a n´ıvel do plano de controle, limitando-se a taxa de emissão de mensagens de roteamento.

5.3 ADAPTA ¸

C ˜

OES

A ROTI, descrita na se¸cão 5.2, havia sido implementada na forma de uma simula¸cão usando o Simmcast3 (MUHAMMAD; BARCELLOS, 2002), um simulador de redes base-ado na linguagem Java. Portanto, o esfor¸co inicial deste trabalho consistiu em adaptar essa simula¸cão existente para executar em uma rede real, utilizando para a comunica¸cão entre os nós o protocolo UDP como protocolo de transporte. A escolha do UDP como protocolo de transporte se deu pelo fato do protocolo TCP fornecer confiabilidade, inde-sejada no caso, ou seja, o protocolo realiza automaticamente retransmissões de pacotes perdidos de forma transparente, mascarada. Esse fato obviamente atrapalha a deteçcão de falhas da ROTI, pois esta se baseia em fatores como porcentagem de pacotes perdidos e o tempo de resposta de um ACK. Em outras palavras, o protocolo TCP executa os controles que devem ser tomados na própria ROTI, portanto seu uso se torna proibitivo.

O simulador Simmcast exigia um certo grau de acoplamento da aplica¸cão que o uti-lizava, o que tornou o porte à rede real um pouco mais trabalhoso. O Simmcast exige que classes que enviem ou recebam dados da rede simulada derivem de classes threads implementadas e gerenciadas pelo próprio simulador, chamadas de NodeThread. Ele tam-bém define uma classe central, chamada de Node, que representa um nó da rede e possui um identificador único na rede, representado por um inteiro. A figura 5.3 representa as principais classes utilizadas na implementa¸cão da ROTI.

Essa figura relaciona o fluxo de dados e eventos com as principais classes, omitindo algumas classes auxiliares e aquelas que basicamente encapsulam dados (como as classes que representam pacotes de dados e de roteamento). Conforme já mensionado, a classe base da simula¸cão é a ITONNode, derivada de Node, pertencente ao Simmcast. Cada nó overlay é representado por uma única instância de ITONNode. Uma instância desta classe possui um ITONRouter, que é a interface de servi¸co do subsistema de roteamento, e um ITONForwarder, que e a interface de servi¸co do subsistema de encaminhamento de

paco-3_{O simulador Simmcast est´}_{a dispon´ıvel no site <http://www.inf.unisinos.br/ simmcast/> e foi}

(39)

37

tes. O ITONRouter é responsável por mediar o acesso ao cache de rotas (RouteCache) e controlar a emissão de ROUTE-UPDATEs e ROUTE-REQUESTs. Estes são pacotes de con-trole utilizados para troca de informa¸cões sobre roteamento da rede overlay, e possuem informa¸cões sobre atualiza¸cão e requisi¸cão de rotas, respectivamente. Além de manter um cache de rotas válidas, RouteCache também guarda informa¸cões sobre rotas e enlaces em quarentena ou permanentemente inválidos4 (a manipula¸cão dessas informacões fica a cargo de ITONRouter). O ITONForwarder implementa os métodos send() e receive() que são chamados pela ITONNode, que por sua vez os fornece à API de usuário. ITON-Forwarder também interage com ConnectionState e ConnectionManager para gerenciar reconhecimentos e buffers de transmissão e recep¸cão.

A thread ListenerThread, como o nome indica, é a única thread do nó overlay que recebe diretamente pacotes da rede, e é responsável por delegar os pacotes às threads responsáveis, realizando uma tarefa de demultiplexa¸cão: durante a inicializa¸cão, ITON-Node registra junto a ListenerThread uma associa¸cão entre threads de processamento e os tipos espec´ıficos de pacotes que são capazes de processar. A ListenerThread classi-fica, então, os pacotes recebidos e os insere em uma fila de acordo com o seu tipo. As threads de processamento definidas na simula¸cão são DataThread, RouteUpdateThread, RouteRequestThread e RouteReplyThread. A primeira thread processa pacotes de da-dos, enquanto as demais processam pacotes de roteamento. Outro tipo de thread utilizado na simula¸cão é chamado de thread de transmissão, que compreende TransmissionThread e ITONRouterThread. A primeira é responsável por transmitir pacotes de dados, e a se-gunda pacotes de roteamento, disparados pelo ITONRouter. A última thread mostrada na figura é SenderThread, que é usada para simular um cliente que envia dados através da rede. Após a nossa adapta¸cão à rede real essa classe foi eliminada. Todas essas threads são o derivadas de NodeThread, do simulador. Algumas delas (especialmente as de transmis-são) foram criadas porque, no Simmcast, apenas a classe NodeThread e suas descendentes podem acessar métodos de transmissão e recep¸cão de pacotes. Essa separa¸cão de fun¸cões faz com que seja necessário gerenciar filas de pacotes para a comunica¸cão entre as classes que contêm lógica de aplica¸cão (como ITONForwarder e ITONRouter) e aquelas que têm acesso a rede; por outro lado, ela favorece a modularidade, reduzindo o acoplamento entre as classes e permitindo com que elas sejam facilmente substitu´ıdas.

Como na simula¸cão não existe nenhum protocolo de transporte confiável como o TCP

4_{Rotas e enlaces que foram certa vez detectados como faltosos s˜}_{ao colocados em quarentenas, sendo}

temporariamente desutilizados. Após o tempo de quarentena a rota se torna funcional novamente, vol-tando a ser utilizada. Se uma rota entra diversas vezes em quarentena, é definido um limiar em que, a partir dele essa rota é marcada como inválida permanentemente. Só poderia voltar a ser utilizada configurando-a explicita e manualmente

(40)

38

executando sobre a ROTI, foi implementado um protocolo simples de janelas deslizantes com reconhecimentos seletivos para melhorar o desempenho da transmissão. A gerência de todo o estado da conexão com outro nó, como buffers de envio e recep¸cão de dados e janelas de transmissão e recep¸cão) ficou a cargo da classe ConnectionState. Ela também é responsável por controlar os reconhecimentos pendentes e recebidos: quando um ACK é recebido ou um timeout expira, a classe ConnectionState passa a informa¸cão corres-pondente (RTT5 ou perca, respectivamente) para a classe RouteMonitor, que é a classe responsável pela deteçcão de falhas. Quando uma falha é detectada, esta classe interage com ITONRouter para invalidar (temporária ou permanentemente) a rota afetada. Cada nó possui uma instância da classe ConnectionState para cada um dos seus vizinhos, e a classe ConnectionManager se responsábiliza por gerenciar essas instâncias.

Como a estrutura da ROTI foi implementada seguindo a base do Simmcast, nossa es-tratégia foi manter a estrutura, eliminando apenas as dependências do Simmcast, e substi-tuindo chamadas da rede do simulador por chamadas UDP. Para isso foi necessário fazer o mapeamento dos endere¸cos dos nós overlay como inteiros para endere¸cos dos nós como IPs, encapsulados na classe java.net.InetAddress. As classes java.net.DatagramSocket e java.net.DatagramPacket forneceram primitivas de comunica¸cão UDP (send e receive) pela rede real. Todas as threads usadas, que antes derivavam da classe NodeThread, do Simmcast, agora são derivadas de threads Java (java.lang.Thread), e transferˆ en-cias de pacotes entre as threads agora são feitas com o aux´ılio de uma fila bloqueante (java.util.concurrent.LinkedBlockingQueue), que cuida da sincroniza¸cão das threads de forma transparente. Por fim, um arquivo de configura¸cão é utilizado na inicializa¸cão de cada nó. Esse arquivo, passado como parâmetro na inicializa¸cão, possui a configura¸cão estática do in´ıcio da rede, e deve informar qual o identificador ROTI (um número inteiro) do nó, além do par <identificador ROTI, endere¸co IP> de cada um de seus vizinhos.

As primitivas de servi¸co oferecidas pela ROTI (que se assemelham muito `as fornecidas por uma camada de rede) foram concentradas na classe central da ROTI, ITONNode, e fornece os seguintes m´etodos:

• bool send (byte[] data, int dst) - método que envia dados do usuário no formato de by-tes, para um destino representado por um número inteiro que identifica unicamente um nó overlay, e retorna um valor booleano indicando se o destino é alcan¸cável ou não;

5_{Round-Trip Time (RTT) significa o tempo que um dado leva para ir pela rede ao destino e retornar,}

(41)

39

• byte[] receive() - método bloqueante, que escuta determinada porta até receber algum dado de outro nó;

• bool encryptedSend (byte[] data, int dst) - o mesmo que o primeiro, porém utiliza criptografia para proteger o conteúdo da mensagem ao trafegar pela rede. O subsis-tema de criptografia da rede ROTI ainda está sendo desenvolvido, portanto ainda não foi testado.

Esses métodos se baseiam nos métodos fornecidos pela classe iton.ITONRouter, que é quem gerencia todo o sub-sistema de roteamento de dados e mensagens de controle.

5.4 RESUMO DO CAP´

ITULO

A idéia de utilizar uma rede overlay como a ROTI para formar os nodos dissemi-nadores de eventos de uma aplica¸cão publish/subscribe é fazer com que informa¸cões de controle e eventos sejam disseminadas eficientemente no sistema publish/subscribe ga-rantindo a disponibilidade da rede e a tolerância a intrusões, mecanismos providos pela utiliza¸cão deste overlay.

A integra¸cão da rede ROTI com a aplica¸cão publish/subscribe é discutida no próximo cap´ıtulo.

(42)

40 ITONNode ITONForwarder ITONRouter ListenerThread DataThread Data/ACK RouteRequestThread ROUTE-REQUEST RouteReplyThread ROUTE-REPLY CACHE-REPLY RouteUpdateThread ROUTE-UPDATE SenderThread send() Data/ACK Simmcast Network DataPacket

ROUTE-REQUEST ROUTE-REPLY CACHE-REPLY ROUTE-REPLY CACHE-REPLY ROUTE-REPLY CACHE-REPLY ROUTE-UPDATE ITONRouterThread ROUTE-REQUEST ROUTE-UPDATE TransmissionThread RouteMonitor transmission DataPacket ConnectionState ACK ConnectionManager RouteCache PendingPacket DataPacket loss/RTT Packet

(43)

41

6 INTEGRA ¸

C ˜

AO

Este cap´ıtulo descreve a estrat´egia utilizada para a integra¸c˜ao entre o framework Muse e a rede overlay ROTI. Ao final apresenta alguns resultados preliminares de desempenho do software resultante.

6.1 ALTERA ¸

C ˜

OES NO MUSE

O framework Muse foi implementado visando sua utiliza¸cão/integra¸cão com algumas ferramentas também dispon´ıveis livremente na Internet. Todas elas utilizam como base o protocolo de transporte HTTP. Com esse framework, a aplica¸cão publish/subscribe (ou outra qualquer) do usuário é tipicamente compactada em um arquivo .war para ser im-plantado em um web-container, como o Tomcat. O framework também pode ser utilizado com ferramentas que auxiliam o desenvolvimento de aplica¸cões voltadas à web, como Axis2 e OSGi. Porém, a forma de utiliza¸cão mais simples consiste na utiliza¸cão de um Servlet1, implementado pela classe org.apache.muse.platform.mini.MiniServlet, que estende a classe javax.servlet.http.HttpServlet. Este pacote faz parte da camada de isola-mento do Muse, e portanto é dependente da arquitetura, protocolo e tecnologia utilizada na máquina. A figura 6.1 ilustra a pilha de protocolos utilizados por padrão pelo Muse.

As setas pretas indicam o caminho percorrido por requisi¸cões SOAP utilizadas por uma aplica¸cão do framework constru´ıda da maneira mais simples, ou seja, sem utilizar Axis ou OSGi. É importante observar dois casos, cada um representado por uma das setas:

1. Para receber uma requisi¸c˜ao (seta que chega da rede e aponta para a aplica¸c˜ao final

1_{Inicialmente criada pela Sun, a especifica¸}_c˜_{ao de Servlet define seu ciclo de vida e intera¸c˜}_{oes com um}

web-container, que é o responsável por gerenciar o Servlet. A principal fun¸cão de um objeto Servlet é cuidar da interface com a rede, utilizada principalmente com o protocolo HTTP. Assim, são definidos métodos doPost e doGet(entre outros), que são métodos chamados pelo web-container quando este recebe uma requisi¸cão HTTP do determinado tipo (GET, POST), e que prevê o retorno de alguma informa¸cão, tipicamente uma página em HTML

(44)

42

Figura 6.1: Pilha nativa do Muse

do usuário), o Muse implementa um HttpServlet, que é gerenciado pelo Tomcat. Então, solicita¸cões vindas de outros nós são recebidas e respondidas passando pelo Tomcat.

2. Para enviar uma requisi¸cão (seta que sai da aplica¸cão do usuário e aponta para a rede), o Muse abre diretamente uma requisi¸cão HTTP, e obtendo assim também a resposta da requisi¸cão.

Como a rede overlay tolerante a intrusões trabalha apenas com protocolo UDP, as altera¸cões necessárias foram em fun¸cão de isolar toda parte que trata de conexões HTTP dentro do Muse, e nestes lugares, substituir pelos servi¸cos oferecidos pela ROTI. A figura 6.2 detalha a localiza¸cão destes pontos no framework.

Conforme já mencionado anteriormente, o Muse mantinha conexões HTTP em dois momentos: (1) quando recebia uma requisi¸cão SOAP e enviava uma resposta, e (2) quando um nó enviava uma requisi¸cão SOAP e esperava sua resposta. A primeira é realizada pela camada de isolamento, implementada pela classe MiniServlet. Esta classe sobrescreve o método doPost que realizava o processamento da requisi¸cão e enviava uma resposta. A segunda é feita por um capability, implementado pela classe SimpleSoapClient, quando a aplica¸cão do usuário realizava uma requisi¸cão. Neste caso, apesar de também depender de protocolo (HTTP), esta classe não faz parte da camada de isolamento do Muse, o que não parece muito lógico. Entretanto, a estratégia utilizada foi a de alterar o m´ınimo poss´ıvel do código original para se chegar a uma primeira versão, para que, a partir dela, se possa

(45)

43

Figura 6.2: Pontos de altera¸c˜ao do framework Muse

definir novas estrat´egias. Portanto essa estrutura foi mantida.

A integra¸cão do Muse com a ROTI consistiu, então, em alterar estes dois pontos do framework, inserindo chamadas da rede overlay ao invés de conexão HTTP. A figura 6.3 ilustra a idéia do middleware após as altera¸cões, utilizando para transporte a ROTI.

Figura 6.3: Pilha adaptada `a ROTI

Para realizar estas altera¸cões, foi criada uma com a mesma fun¸cão da classe Mi-niServlet, porém com outro protocolo. Ela foi chamada de UDPServlet, e contata a rede overlay e o roteador do Muse. No outro ponto de altera¸cão, na classe SimpleSo-apClient, foi alterada a chamada de requisi¸cão de URL.openConnection(), connec-tion.setRequestMetod(POST) e connection.connect()(que utilizam HTTP), para a rede overlay, através do método iton.init.NodeInitializer.getNodeInstance(null)

(46)

44

e node.send(destinationIP, soapBytes).

6.2 RESULTADOS

Após a integra¸cão, fizemos alguns testes preliminares de medida de tempo de resposta. A medi¸cão de tempo come¸ca quando uma requisi¸cão SOAP já transformada em bytes é enviada do framework para a unidade de rede responsável por transportá-la2. Após chegar no destino, a requisi¸cão é transformada em XML, processada pelo Muse, entregue `

a aplica¸cão do usuário. O Muse gera então uma resposta em XML, que é transformada em bytes, retorna pela rede ao requisitante, que entrega de volta a resposta ao Muse, que só então termina a medi¸cão do tempo. Foi gerado um gráfico comparativo entre as diferentes versões do Muse e seus respectivos tempos de resposta. Foram feitas em cada versão o envio de mil requisi¸cões, com intervalo de 200 milisegundos entre elas. O gráfico a seguir mostra os resultados.

Figura 6.4: Tempos de respostas de diferentes vers˜oes do Muse

Como podemos observar (e já era esperado), o tempo de resposta do Muse utilizando a ROTI é 57,38% maior que utilizando UDP diretamente, que por sua vez é 109,32% maior do que o Muse original, sem altera¸cão (utilizando HTTP). Entretanto, algo que não era esperado foi um alto desvio padrão dos casos com o Muse modificado. Esse fato pode ser explicado pelo fato dos testes terem sido feitos em uma rede local utilizada por

2_{Para compara¸}_c˜_{ao, fiz medi¸}_c˜_{oes com o Muse original, utilizando HTTP, com o Muse alterado,}

utili-zando no lugar da ROTI chamadas UDP diretas, e o Muse final, que utiliza a rede ROTI para o transporte das requisi¸c˜oes

(47)

45

outros computadores em um laboratório da UFSC, assim como alguma carga extra de processamento na máquina receptora, que estava utizando um sistema operacional base-ado em interface gráfica. O gráfico 6.5 mostra os tempos de respostas em milisegundos, na sequência em que foram enviados. Como pode se observar, existem alguns momentos em que a rede possui um comportamento estável e constante, abaixo de 100 ms. Entre-tanto, em outros momentos, possivelmente quando o Muse compete pelo processador com outras tarefas, ou fluxo de informa¸cões na rede aumenta, o tempo de resposta se torna absolutamente instável, como no final, com diversos tempos ultrapassando os 500 ms.

Figura 6.5: Tempos de respostas do Muse com ROTI

Estes resultados representam o tempo de resposta do middleware em sua primeira versão, sem ser otimizado, e sem ter implementado a parte de criptografia, que está em andamento. Enfim, são testes preliminares, mas que nos possibilitam concluir que o uso do middleware para comunica¸cão publish/subscribe é perfeitamente aceitável.

6.3 RESUMO DO CAP´

ITULO

Este cap´ıtulo descreveu como foi realizada as altera¸c˜oes no Muse e apresentou alguns resultados preliminares que comprovam a viabilidade de seu uso como middleware.