Serviços de Notificação de Eventos Baseados em Publish/Subscribe

Transcrição

1 Serviços de Notificação de Eventos Baseados em Publish/Subscribe Bruno Oliveira Silvestre 4 de julho de Introdução O modelo de comunicação publish/subscribe é baseado na troca assíncrona de mensagens, conhecidas como eventos. Ele consiste de um conjunto de clientes que publicam esses eventos (produtores), os quais são encaminhados para clientes que registraram interesse em recebê-los (consumidores). Além do assincronismo, esse modelo oferece o desacoplamento entre o produtores e o consumidores de eventos, dando mais flexibilidade e extensibilidade às aplicações que utilizam esse modelo, pois a inclusão de novos produtos e consumidores se torna simples [1, 2, 3, 4]. Alguns sistemas fornecem ainda a possibilidade de persistência dos eventos, permitindo que um cliente que não esteja ativo no momento possa recebê-los posteriormente [2, 3]. A implementação de um serviço de notificação de eventos utilizando publish/ subscribe pode seguir um abordagem centralizada onde um único elemento é responsável por manter o registro de interesse dos consumidores e por disseminar os eventos que são gerados. Essa arquitetura, apesar da simplicidade, apresenta problemas de escalabilidade, sendo inviável para ser adotado com uma grande-escala de clientes conectados. Um modelo distribuído para o serviço consiste de um conjunto de servidores interconectadores, cada um responsável por prover serviços para uma parte dos clientes. A eficiência desse modelo depende de como os servidores estão interligados, como os eventos são propagados e a estratégia de processamento dos interesses dos consumidores [1]. Neste trabalho serão apresentados quatro serviços de notificação de eventos baseados em publish/subscribe que adotam um modelo distribuído. O objetivo é mostrar as estratégias adotadas por cada um deles para alcançar escalabilidade na disseminação em larga-escala de eventos. 1

2 A forma como os consumidores selecionam que tipo de eventos querem receber pode variar. Os quatro serviços a seguir permitem que a seleção seja feita através de filtros que são aplicados sobre o conteúdo dos dos eventos. Esses filtros são passados na hora em que o cliente efetua uma subscrição no sistema. A seção 2 apresenta os sistemas SIENA, Rebeca, Meghdoot e Terpstra et al. Na seção 3 são apresentados comentários finais sobre os sistemas. 2 Serviços de Notificação Publish/Subscribe Nesta seção apresentaremos quatro serviços de notificação distribuídos baseados em conteúdo, com diferentes abordagens de arquiteturas de interligação dos servidores e formas de propagação das notificações de eventos. 2.1 SIENA O SIENA [5, 1] é um sistema de notificação de eventos que adota uma estrutura de servidores interconectados que propagam as notificações e servem de ponto de acesso, através dos quais os clientes podem registrar seus interesses e receber as notificações de eventos. Esses clientes são divididos em duas categorias, os objetos de interesse, que são as fontes de eventos, e as partes interessadas, que consomem as notificações. A figura 1 ilustra a arquitetura geral do sistema. Figura 1: Serviço de notificação SIENA. Em geral as partes interessadas não desejam receber todo os tipos de eventos que estão sendo propagados na rede. Ao se registrarem em um servidor para receber eventos, os clientes informam filtros que serão aplicados às notificações. Apenas as notificações que casam com esses filtros são repassadas aos clientes. 2

3 O SIENA também permite que os objetos de interesse anunciem quais os tipos de eventos eles geram, possibilitando que o sistema utilize essa informação em conjunto com os filtros para otimizar o repasse dos eventos ao cliente. Com o objetivo de usar a rede de forma mais eficiente, o SIENA adota uma entrega seletiva, empregando algoritmos de roteamento baseados no conteúdo das notificações, nos filtros das partes interessadas, nos anúncios dos objetos de interesse e na forma como os servidores estão conectados. O objetivo é enviar os dados apenas para os servidores que possuem clientes com interesse nessas informações, seguindo o caminho mais curto possível. Quando um cliente se registra, o servidor necessita propagar pela rede o interesse do cliente em um dado tipo de evento (filtro) para que os demais servidores possam encaminhar esses eventos até o ponto de acesso, e assim, até o cliente. No entanto, se os interesses de todos os clientes forem propagados, haveria um grande tráfego de mensagens de controle. Para reduzir o número de propagações, o sistema dissemina apenas os filtros mais gerais que englobam filtros mais específicos. Por exemplo, suponha que o sistema seja empregado para notificar os valores dos ações de uma bolsa e que três clientes, A, B e C, registram interesse em receber notificações sobre o valor das ações de uma mesma empresa. Seja o filtro de A valor>10, o de B valor>12 e o de C valor>15. Neste caso, apenas o filtro de A é propagado para os demais servidores, pois ele engloba os filtros de B e C. Os servidores no SIENA podem estar interligados seguindo duas configurações primárias, que podem ser combinadas gerando configurações híbridas: hierárquica e peer-to-peer. A estrutura hierárquica utiliza o conceito de cliente/servidor para a propagação das notificação, e na abordagem peer-to-peer os servidores estão conectados na forma de um grafo não direcionado. Os detalhes sobre cada uma delas são descritos a seguir. Hierárquica Na estrutura hierárquica os servidores são dispostos como um grafo orientado, como mostra a figura 2. O protocolo utilizado para a comunicação entre clientes e servidores e entre servidores é o mesmo, ou seja, um dado servidor não sabe distinguir se as notificações estão sendo enviadas ou recebidas de um outro servidor ou de um cliente. Isso pode ser visto como a extensão do modelo centralizado de notificação pois não há um protocolo diferenciado entre os servidores. Com essa disposição, os servidores se comunicam apenas com o seus pais e com os seus filhos, reduzindo o número interação entre os nós da rede. Quando um servidor recebe um pedido de subscrição de um cliente, ele primeiro verifica se esse cliente já realizou anteriormente uma subscrição usando um 3

4 Figura 2: Topologia hierárquica do SIENA. filtro mais abrangente que o atual. Nesse caso o pedido é simplesmente descartado. Caso contrário, duas possibilidades podem ocorrer: (i) o filtro existe no servidor, mas o cliente não está relacionado ao mesmo, ou (ii) é um novo filtro. Se o filtro já existe, o servidor apenas adiciona o cliente na lista de nós a serem notificados quando um evento relacionado for recebido. Perceba que quando o servidor já possui o filtro, não há nenhuma propagação do mesmo, ou seja, não há troca de mensagens entre os servidores da rede para atualização do roteamento dos eventos. A propagação só ocorre quando o filtro introduzido é mais abrangente que os demais já registrados, e mais, ela é enviada apenas para o pai. Para exemplificar, a figura 3 mostra um servidor S 1, que já havia propagado o interesse valor>15 do cliente C 1 para o pai S 2, recebendo o pedido de subscrição de C 2 contendo o filtro valor>10. Como o filtro de C 2 é mais abrangente que o filtro de C 1, S 1 comunica S 2 de que o filtro anterior não cobre o interesse de todos os cliente de S 1 e que um novo filtro ( valor>10 ) deve ser utilizado. Da mesma forma que um cliente afeta a relação de filtros de um servidor, um servidor pode afetar a relação de outro servidor. O tratamento dado a uma propagação entre servidores é o mesmo dado à subscrição entre clientes e servidores. Assim, no exemplo anterior, a propagação do novo filtro para S 2 pode ocasionar em uma propagação desse filtro para o pai de S 2, desde que esse filtro seja mais abrangente que os já registrados. Esse processo pode continuar até atingir a raiz da árvore onde ele é interrompido, pois a raiz não propaga os interesses de seus filhos. As notificações são encaminhadas para os nós filhos (clientes e servidores) de acordo com os filtros registrados. Quando um servidor recebe a publicação de 4

5 Figura 3: Propagação de subscrição na estrutura hierárquica. um evento vindo de um objeto de interesse, ele verifica quais de seus filhos estão interessados em tal evento e notifica-os. Entretanto, como os filtros são propagados somente para os pais até eventualmente atingir a raiz, um servidor em um ramo da árvore pode desconhecer os interesses de clientes em outro ramo. Dessa forma, o servidor deve propagar o evento para seu pai, que propaga para seus filhos e seu pai, e assim por diante, até que um ancestral comum com os interessados seja atingido. Então, esse ancestral propaga o evento pelo ramo onde os clientes se encontram. Por exemplo, na figura 3, se o cliente C 3 estiver interessados em eventos gerados por C 2, S 1 não possui tal conhecimento. Mas, ao receber a propagação os eventos de C 2 vindas de S 1, S 2 identifica o interesse de C 3 e notifíca-o. Quando um cliente não deseja mais receber notificações de um dado tipo de evento ele deve comunicar ao servidor. O SIENA permite que o cliente cancele mais de uma subscrição de uma só vez. Ao solicitar o cancelamento, o cliente fornece ao seu ponto de acesso um filtro que será usado para identificar todos os registros a serem removidos, da seguinte forma: o servidor procura todos os filtros registrados que são cobertos pelo filtro do cancelamento e retira o cliente de todas as listas de notificações associadas com esses filtros. Caso algum filtro fique com sua lista de notificações vazia, ele é removido do servidor. O fato de remover filtros de um servidor pode alterar o esquema de propagação de eventos na árvore. Ao cancelar um filtro, o servidor deve verificar se o filtro não foi o propagado para o pai. Nesse caso, o servidor deve comunicar o seu pai de que o filtro antigo não é mais utilizado e que um novo filtro (se houver) deve ser utilizado. Isso pode causar um efeito em cadeia pois o pai também deve verificar se o filtro a ser substituído foi propagado. Como exemplo, se na figura 3 o cliente C 2 cancelar o seu interesse por eventos cujo valor seja maior que 10, o servidor S 1 deve remover o filtro, pois apenas C 2 estava relacionado com o mesmo, e deve 5

6 comunicar S 2 de que o novo filtro é valor>15. Peer-to-Peer Na arquitetura peer-to-peer os servidores que fazem parte do serviço de notificação são interligados formando um grafo não dirigido, como mostra a figura 4(a). Entretanto, mesmo admitindo que mais de um caminho possa ligar dois servidores, os mecanismos de seleção e entrega do SIENA se baseiam na árvore geradora mínima do grafo, reduzindo as ligações entre servidores a um grafo acíclico (figura 4(b)). Figura 4: Estrutura peer-to-peer do SIENA. Aparentemente, o SIENA designa o termo peer-to-peer para uma rede não estrutura, considerando estáticos os membros da rede. O processo de tratamento dado às subscrições estende o processo do modelo hierárquico, sendo que a principal diferença é como são definidos os vizinhos para os quais serão propagadas as subscrições. Assim, quando um servidor recebe uma subscrição (seja de um cliente ou de uma propagação), se o filtro já estiver registrado no servidor ou for menos abrangente que um filtro submetido anteriormente, o processo se dá da mesma maneira que na arquitetura hierárquica. Contudo, se o servidor não possui o filtro, ele registra-o e verifica a necessidade de propaga-lo para seus vizinhos. Para definir quais servidores devem receber a propagação, avaliada-se a seguinte expressão vizinhos NPAG( f ) f f propagado( f ) (1) onde f é o filtro da subscrição. NPAG representa os vizinhos que não participam da árvore geradora mínima ou que já receberam a propagação de f. O último termo indica o conjunto dos vizinhos por onde foram propagados filtros f mais abrangentes que f. 6

7 O algoritmo de notificação de eventos e de cancelamento de subscrição da arquitetura peer-to-peer são similares aos empregados pela hierárquica. Quando um objeto de interesse publica um evento, o seu ponto de acesso verifica quais de seus clientes estão interessados em tal evento e notificando-os. Ele também propaga o evento para os vizinhos que registraram interesse, que realizarão o mesmo procedimento. Assim, o evento é disseminado por toda a rede de servidores até atingir as partes interessadas. Como visto anteriormente, os clientes selecionam as subscrições a serem canceladas através de um filtro, isto é, todos as subscrições do cliente que são abrangidas por esse filtro são removidas do ponto de acesso. Após remover as subscrições, o servidor deve reavaliar a expressão (1). Isso pode acarretar na mudança do filtro que deve ser propagado ou no conjunto de vizinhos que devem receber as notificações. Caso haja mudança, o servidor interage com seus vizinhos para manter consistente o caminho de propagação, atualizando ou cancelando os interesses por eventos. Um aprimoramento que pode ser introduzido nesta arquitetura é o anúncio de eventos. Os objetos de interesses anunciam aos seus pontos de acesso quais os tipos de eventos que são gerados, com isso, os servidores podem usar as informações dos anúncios como limitadores para a propagação das subscrições, isto é, um servidor só propaga os interesses por eventos para os vizinhos que possuem objetos de interesse geradores de tal tipo de evento. Para que os servidores saibam quais os tipos de evento gerados por cada cliente, os anúncios são propagados pela rede segundo uma expressão semelhante à expressão (1). A diferença é que em vez de utilizar o filtro da subscrição, é utilizado o tipo de evento que é gerado pelo objeto de interesse. A fórmula de propagação de subscrição foi alterada para utilizar os anúncios na derivação dos vizinhança de propagação, sendo ela (vizinhos NPAG( f ) f f propagado( f )) f a anunciadores(a) (2) onde anunciadores fornece um conjunto de vizinhos que realizaram anúncios a, que casam com o filtro f. 2.2 Rebeca Rebeca [2, 6] é um serviço de notificação com suporte a variados algoritmos de roteamento baseados no conteúdo da notificação e em anúncios. Ele conta com implementações em JAVA e Microsoft.Net. A infra-estrutura do serviço consiste de um conjunto de brokers interconectados, divididos em duas categorias: brokers locais, que servem de ponto de acesso para os clientes, e roteadores, responsáveis por propagar as notificações pela rede. 7

8 A implementação descrita em [2] considera a interconexão dos brokers em forma de árvore (figura 5), citando como trabalho futuro uma implementação que considera a possibilidade de ciclos na conexão dos roteadores. Figura 5: Interligação dos brokers no Rebeca. As notificações são compostas de um conjunto de atributos, definidos como o par (nome, valor), como por exemplo, {(tipo, StockQuote), (nome, Infineon ), (preço, 45,00)}. Uma das vantagens do Rebeca é o uso de uma arquitetura que permite o desenvolvimento de outros tipos de algoritmos de roteamento das notificações. Em sua avaliação inicial, cinco algoritmos de roteamento foram acoplados ao sistema: flooding, baseado em filtros simples, baseado em identidade de filtros, baseado em cobertura de filtros e baseado em fusão de filtros [2]. O algoritmo de flooding é o mais simples, os brokers apenas propagam por toda rede a publicação de um evento realizado por um dos clientes do serviço, não realizando nem um tipo de otimização na entrega. Os demais algoritmos adotam filtros para estabelecer o caminho de entrega das notificações. No algoritmo baseado em filtros simples, quando um ponto de acesso recebe uma subscrição, o respectivo filtro de interesse é propagado para todos os brokers da rede. Assim, todos os brokers sabem os interesses de todos os clientes. Essa técnica, apesar de simples, apresenta desvantagem quando o número de subscrições é alto, pois a tabela de rotas de cada broker possuirá muitas entradas, dificultando a localização dos nós para os quais a notificação deve encaminhada. O cancelamento de uma subscrição se dá propagando o pedido pela rede e cada um dos brokers retira de sua tabela de rotas a entrada referente ao cancelamento. 8

9 O roteamento baseado em identidade de filtros segue o mesmo princípio utilizado no filtro simples, mas evita a propagação de filtros que sejam iguais, na tentativa de reduzir o fluxo na rede. Esse algoritmo é uma particularidade do algoritmo baseado em cobertura de filtros, o qual é idêntico ao utilizado pela arquitetura peer-to-peer do SIENA. Assim, em vez de considerar se um filtro mais abrangente já foi propagado, o roteamento baseado em identidade de filtro verifica se um filtro igual foi propagado. A fusão de filtros tem por objetivo reduzir o números de entradas na tabela de roteamento dos brokers. Esse algoritmo é montado sobre o algoritmo baseado em cobertura de filtros e tenta unificar filtros de interesses por diferente eventos em um único filtro, tornando a avaliação de uma notificação mais rápida. Uma das dificuldades é encontrar um filtro que consiga substituir os demais filtros sem perder ou adicionar notificações na hora da avaliação. Empregar a fusão considerando filtros com o mesmo destino facilita a definição do filtro equivalente. Como exemplo, suponha que um cliente C tenha efetuado uma subscrições em seu ponto de acesso com o filtro F 1. Quando o cliente efetua uma nova subscrição com o filtro F 2, o ponto de acesso realiza a fusão de ambos os filtros, criando um filtro substituto F 3, e o propaga para os vizinhos. Lembrando que este algoritmo é uma camada sobre o algoritmo baseado em cobertura de filtros, os vizinhos tomam F 3 como uma subscrição mais abrangente e o utilizam na hora de selecionar quais notificações devem ser propagadas para C. Assim, o filtro F 1, referente à primeira subscrição, poderá ser descartado pelos brokers (exceto o ponto de acesso) caso ele não esteja sendo usado como rota para outro cliente. Os pontos de acesso devem armazenar todos os filtros de seus clientes e suas respectivas fusões para serem capazes de desfazer o processo no caso de um cliente cancelar uma ou mais subscrições cujos filtros foram usados em uma fusão. Deve-se propagar para os vizinhos o cancelamento do filtro derivado da fusão bem como os filtros que não removidos para que as rotas sejam mantidas. Rebeca também disponibiliza o mecanismo de anúncio, onde os clientes anunciam quais os tipos de eventos que eles geram. Como no SIENA, os anúncios são usados para otimizar a propagação das subscrições, ou seja, as subscrições serão propagadas pelas subredes da arquitetura onde exista um cliente que anunciou tipos de eventos relacionados com o filtro da subscrição. Essa estratégia visa diminuir o número de mensagens de controle na rede. Vale destacar que esse mecanismo não se aplica ao algoritmo de flooding. O modelo tradicional de publish/subscribe não permite que novos clientes tenham acesso a notificações já publicadas. Rebeca estende esse modelo permitindo que os clientes solicitem notificações antigas. Quando um cliente realiza uma subscrição, ele pode informar ao serviço que as notificações dadas a partir de uma certa data sejam publicadas novamente. No entanto, o sistema deve garantir que apenas o novo cliente receba essas notificações. 9

10 O armazenamento do histórico das notificações pode seguir duas estratégias. Na primeira, as próprias fontes de eventos gerenciam os seus históricos. A segunda e mais complexa abordagem é encarregar os brokers de gerenciar o histórico, poupando os clientes. Contudo, a medida que os brokers vão encaminhando as notificações para o cliente, o serviço deve se certificar de que notificações repetidas não estejam sendo repassadas. Isso pode ocorrer pois os brokers armazenam as notificações que trafegaram por ele. Assim, ao propagar uma notificação pela rede, mais de um broker pode tê-la armazenado. 2.3 Meghdoot O Meghdoot [7] emprega uma abordagem diferente do SIENA e do Rebeca para tratar as subscrições e o roteamento das notificações. O serviço é baseado em uma arquitetura peer-to-peer, onde cada nó é ser um ponto de acesso para o sistema e também um roteador de notificações. A definição de onde as subscrições são armazenadas é dada através do uso de tabelas hash distribuídas [8]. Normalmente, sistemas baseados em peer-to-peer são desenvolvidos para suportar uma maior flexibilidade, modularidade e escalabilidade. Um dos desafios nesse caso é distribuir a carga de tratamento das subscrições e da entrega dos eventos. O serviço emprega um esquema de atributos para gerenciar as tabelas hash. Um atributo é definido como uma tupla (Nome: Tipo, Min, Max), onde Min e Max definem o intervalo de valores que o atributo pode assumir, por exemplo, (preço: float, 0.0, 50.0). O Meghdoot constrói um espaço lógico com 2n dimensões, sendo n o número de atributos do esquema, e mapeia as subscrições e notificações nesse espaço para determinar quais clientes devem ser notificados. Dado um esquema{a 1, A 2,.., A n }, as dimensões 2i 1 e 2i do espaço correspondem ao intervalo [Min i, Max i ] do atributo A i, para 1 i n. Considerando um esquema {(preço: float, 0.0, 50.0)} temos um espaço com duas dimensões, cujo intervalo de cada uma delas é [0.0, 50.0], como mostra a figura 6. Após a definição, o espaço é particionado em zonas, de acordo com o número de nós que compões a rede. A figura 6 apresenta o espaço divido em cinco zonas. Cada nó fica responsável por uma zona e, por conseguinte, pelas subscrições nela mapeada, sendo que a definição da zona correspondente a subscrição é dada através do filtro utilizado. Um filtro tem a seguinte forma F= (l 1 A 1 h 1 ) (l 2 A 2 h 2 )... (l n A n h n ), ou seja, restringe um intervalo para cada um dos atributos. A igualdade é alcançada fazendo com que l e h sejam iguais ao valor desejado. Caso o cliente omita um dos atributos na criação do filtro, l e h assumem respectivamente os valores Min e Max do atributo ausente, definidos no esquema. 10

11 Figura 6: Exemplo de espaço de 2 dimensões usado pelo Meghdoot. As subscrições representam um ponto no espaço lógico dado pelas coordenadas l 1, h 1, l 2, h 2,..., l n, h n, onde l e h são extraídos do filtro. Assim, quando um cliente realiza um subscrição, esta deve ser encaminhada para o nó responsável pela zona que contém o ponto equivalente à essa subscrição. Esse nó ficará encarregado de notificar o cliente quando ocorrer um evento que satisfaça o filtro de interesse. Pela forma como o ponto é estabelecido, as subscrição sempre são mapeadas para as zonas acima do hiperplano diagonal. As zonas abaixo do hiperplano são usadas no roteamento das subscrições e das notificações. Por exemplo, considerando o espaço bidimensional da figura 7, as subscrições seriam mapeadas na região sombreada. Figura 7: Área de mapeamento das subscrições. 11

12 Os nós possuem conhecimento apenas de quem são os responsáveis pelas áreas vizinhas as suas. Quando uma subscrição é recebida por um nó, este identifica a zona a qual a subscrição pertence. Caso não seja a sua zona, o nó deve efetuar o seu roteamento da subscrição, encaminhando-a para o vizinho mais próximo da zona destino. Assim, a subscrição vai sendo encaminhada até atingir a zona correta. Da mesma forma que uma subscrição, os eventos também são mapeados em pontos no espaço para determinar quais clientes devem ser notificados. Seja um evento E = {A 1 = v 1, A 2 = v 2,..., A n = v n }, o ponto relativo a ele é p = c 11, c 12, c 21, c 22,...,c n1, c n2, onde c i1 e c i2 assumem o valor do atributo A i pertencente ao evento, por exemplo, c 11 = v 1 e c 12 = v 1. Entretanto, como o sistema de notificação assume que um evento pode não conter todos os atributos descritos no esquema, c i1 e c i2 assumem os valores Min e Max do atributo A i, caso este seja omitido no evento. Para identificar quais clientes devem ser notificados, o Meghdoot avalia a seguinte propriedade i {1, 2,...,n} l i c i1 c i2 h i (3) considerando um filtro F= (l 1 A 1 h 1 ) (l 2 A 2 h 2 )... (l n A n h n ) de um subscrição e um ponto P= c 11, c 12, c 21, c 22,..., c n1, c n2 do evento. Contudo, o sistema não avalia todas as subscrições do espaço quando um evento é publicado. De acordo com a formulação apresentada, num espaço de 2n dimensões, as subscrições que casam com um evento residem na região hiper retangular compreendida pelos pontos Min 1, c 11, Min 2, c 21,..., Min n, c n1 e c 12, Max 1, c 22, Max 2,..., c n2, Max n. Para ilustrar, a figura 8 mostra um espaço de 2 dimensões onde a região sombreada contém as subscrições que casam com o evento p={ preço=10.0}. Da mesma forma que as subscrições, uma notificação deve ser roteada para sua zona correspondente para que possa ser processada, neste caso, para que os clientes interessados no evento possam ser identificados e notificados. O processo de roteamento é idêntico ao roteamento de uma subscrição: o nó encaminha a notificação para o vizinho mais próximo da zona destino. Após atingir a zona designada e o nó responsável notificar os devidos clientes, a notificação deve ser propagadas pelas zonas que possuem interseção com a região hiper retangular referente a essa notifica, pois também podem haver clientes nessas zonas que estejam interessados no evento. Por exemplo, na figura 8, o nó responsável pela zona A recebe a publicação do evento que deve ser encaminhada para a zona Z. A notificação é então encaminhada através das zonas B e C até Z. Os clientes mapeados em Z e que estão interessados no evento são notificados (subscrições pertencentes à área sombreada de Z). O evento é então propagado para X e depois Y para que os clientes mapeadas naquelas zonas possam ser notificados. 12

13 Figura 8: Roteamento de uma notificação de evento. Essa modelagem baseada no esquema dos atributos para identificar a posição da subscrição e do evento no espaço é penalizada quando há muitos nós interessados em um evento, o que leva a concentração de uma grande quantidade de subscrições em uma única zona. Um efeito semelhante ocorre quando um mesmo tipo de evento é publicado freqüentemente por diversos clientes. O balanceamento da carga entre os nós é alcançado através da divisão e replicação de zonas. A divisão de uma zona visa reduzir o número de subscrições que um nó da rede peer-to-peer deve gerenciar. A estratégia de replicação de zona é mais aplicável quando ocorre uma grande quantidade de publicações de um mesmo evento, ou eventos muito parecidos. Isso faz com que um determinado conjunto de zonas gerem um grande fluxo de notificações para os clientes, sobrecarregando os nós responsáveis. Quando um evento está sendo propagado, os vizinhos de uma zona replicada podem selecionar qual das réplicas ficará responsável em notificar os clientes, utilizando, por exemplo, um esquema de round robing. A divisão de uma zona ou a criação de uma réplica ocorrem geralmente quando novos membros se juntam a rede. O sistema decide, baseado na carga atual, se uma zona já existente será divida em duas partes, ficando o novo membro responsável por uma delas, ou se uma réplica será gerada. 2.4 Terpstra et al. Terpstra et al. [9] propuseram um sistema de notificação peer-to-peer baseado na arquitetura de comunicação do Chord [10] juntamente com os conceitos de cobertura e fusão de filtros do Rebeca [2]. Nessa arquitetura os nós são clientes e 13

14 pontos de acesso ao mesmo tempo, ou seja, eles participam do sistema provendo acesso a outros clientes, mas também realizam suas próprias subscrições e notificam eventos. Um dos objetivos é obter um sistema mais tolerável à falhas, adicionando na arquitetura caminhos variados de roteamento, diferente do que é feito no modelo peer-to-peer do SIENA e no Rebeca, que utilizam uma árvore geradora mínima como caminho de propagação. Isso é obtido seguindo o modelo de comunicação do Chord. O Chord foi desenvolvido para mapear chaves em nós da redes de forma a localizá-las eficientemente. Ele emprega um esquema de funções hash consistentes que distribuem os nós em um espaço circular ordenado de tamanho 2 m. A posição de cada nó no círculo é dado pelo valor de retorno da função de hash aplicada ao nó esse valor é conhecido como chave do nó. Uma chave qualquer K irá residir no nó N, ou seja, N será responsável por essa chave, caso o valor da chave K seja igual ao da chave de N ou N é o nó sucessor. Considerando o espaço circular, o nó sucessor de uma chave é o primeiro nó no sentido horário após a chave. A figura 9 ilustra um espaço circular com dez nós, armazenando cinco chaves. Figura 9: Espaço circular do Chord. O Chord adota uma estratégia de que um nó N da rede mantém uma tabela de informações sobre um conjunto menor de nós. Os membros desse conjunto são os nós responsáveis pela chaves (n+2 i 1 ), onde n é o valor da chave de N e 1 i m. Assim, quando N deseja localizar uma chave K e esta não está sob a responsabilidade de um dos nós de sua tabela, N delega a busca para um nó N da tabela a seleção é baseada no valor de K [10]. Caso não saiba a localização da chave, N também pode delegar o pedido para um dos integrantes 14

15 de sua tabela. Isso prossegue até que K seja encontrada. A figura 10 mostra o processo de localização de K54, onde ocorrem duas delegações. Figura 10: Localização de uma chave no Chord. Seguindo esse esquema de delegação, o Chord tem um funcionamento semelhante às tabelas hash distribuídas utilizadas pelo Meghdoot, sendo os nós do sistemas responsáveis por partes do espaço circular. Terpstra et al. empregaram esse conceito para definir as árvores de propagação das subscrições. Cada árvore é montada tendo como raiz o nó que publica o evento. Esse nó raiz propaga o evento para os nós com chaves (n+2 i 1 ) pertencentes à tabela de localização, que demonstraram interesse pelo evento. Isso pode ser visto como se a raiz delegasse para esses nós a responsabilidade de divulgar o evento dentro de um subespaço. Nessa divulgação, o nó responsável pelo subespaço pode delegar a entrega do evento para outros nós também pertencentes ao subespaço. Como exemplo, na figura 11(a) podemos ver um nó N publicando um evento que é propagado por todo o espaço circular, considerando que todos os nós estão interessados no evento. A propagação do evento também pode ser vista como uma árvore, como mostra a figura 11(b). Se considerarmos cada nó n do sistema, percebemos que existem n árvores diferentes, ou seja, dependendo do nó que publica o notificação, esta será roteada por caminhos distintos. Este sistema de notificação emprega o algoritmo de fusão de filtros do Rebeca, e da mesma forma que ocorre na divulgação dos eventos, cada nó possui um caminho diferente para propagar as subscrições. Consideremos que o nó N deseja efetuar uma subscrição para receber um determinado tipo de evento e que o filtro é mais abrangente que os das subscrições anteriores. N propaga sua subscrição no caminho inverso que uma notificação 15

16 Figura 11: Propagação das notificações de um nó. faria até atingi-lo. Para isso, além de N manter a tabela de quais nós ele deve notificar quando um evento ocorre, N também deve possuir uma tabela T contendo quais nós notificam-no. Então, N unifica os seus filtros mais abrangentes e propaga o resultado para os nós da tabela T. Estes atualizam o interesse de N e, baseados na cobertura de filtros, analisam a necessidade de propagar para seus responsáveis o interesse de N. O processo termina quando todos os caminhos para atingir N sejam atualizados. A figura 12 mostra um exemplo de todos os caminhos percorridos por uma subscrição para um dado N da rede. Figura 12: Propagação das subscrições de um nó. 16

17 3 Comentários Finais Neste trabalho foram apresentadas as arquiteturas do SIENA, Rebeca, Meghdoot e Terpstra et al., bem como suas estratégias para prover um serviço de notificação de eventos de grande-escala. O modelo hierárquico do SIENA, ao propagar os filtro apenas para os pais, gera um número menor de mensagens de controle para manter os interesses dos consumidores, comparado com o modelo peer-to-peer. Por outro lado, quando o número de publicações aumenta, os servidores dos níveis mais altos da hierarquia lidam com um grande número de eventos, comprometendo o desempenho. Nesse caso o modelo peer-to-peer se mostra mais eficiente. Tanto o SIENA como o Rebeca empregam algoritmos de cobertura de filtros para designar a propagação dos eventos. O Rebeca disponibiliza ainda mais três outros algoritmos de roteamento e uma arquitetura extensível que permite o acoplamento de novos algoritmos sem afetar o funcionamento do sistema. O Rebeca também implementa o histórico de notificações, o que possibilita que os clientes recuperem eventos publicados anteriormente. Essa funcionalidade é comumente empregada por aplicações que se baseiam em contexto ou que que necessitam do estado atual para seu funcionamento. Meghdoot utiliza uma arquitetura peer-to-peer, com entradas e partidas de servidores, e um esquema de tabelas hash distribuídas que mapeia subscrições e eventos em zonas de um espaço lógico. Os testes mostraram que o seu algoritmo de roteamento baseado em zonas utiliza poucos nós da infra-estrutura do sistema até que o evento seja notificado aos interessados [7]. O Meghdoot também provê dois mecanismos de balanceamento de carga que consistem em divisão e replicação das zonas. No Rebeca e no SIENA há apenas um caminho de propagação, o que pode levar ao particionamento da rede caso um dos servidores da arquitetura falhe. O sistema desenvolvido por Terpstra et al. utiliza conceitos do Chord para definir caminhos diferenciados de propagação das subscrições e dos eventos na tentativa de reduzir os dados no caso de falha de um dos membros da rede. Alguns trabalhos estão avaliando o uso de serviços de notificação empregando publish/subscribe para comunicação com dispositivos móveis, cujos requisitos casam com as características do modelo publish/subscribe, principalmente o assincronismo e o desacoplamento [11, 12, 13]. Referências [1] Antonio Carzaniga, David S. Rosenblum, and Alexander L. Wolf. Design and evaluation of a wide-area event notification service. ACM Trans. Com- 17

18 put. Syst., 19(3): , [2] Gero Mühl. Large-Scale Content-Based Publish/Subscribe Systems. PhD thesis, Darmstadt University of Technology, [3] Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. The many faces of publish/subscribe. ACM Comput. Surv., 35(2): , [4] The Gryphon Team. Achieving scalability and throughput in a publish/subscribe system. Technical report, IBM Research Report, February [5] Antonio Carzaniga, David S. Rosenblum, and Alexander L. Wolf. Achieving scalability and expressiveness in an internet-scale event notification service. In PODC 00: Proceedings of the 19th annual ACM symposium on Principles of distributed computing, pages , New York, NY, USA, ACM Press. [6] Gero Mühl, Andreas Ulbrich, Klaus Herrmann, and Torben Weis. Disseminating information to mobile clients using publish-subscribe. IEEE Internet Computing, 8(3):46 53, May [7] Abhishek Gupta, Ozgur D. Sahin, Divyakant Agrawal, and Amr El Abbadi. Meghdoot: content-based publish/subscribe over p2p networks. In Proceedings of the 5th ACM/IFIP/USENIX international conference on Middleware, pages , New York, NY, USA, Springer-Verlag New York, Inc. [8] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott Schenker. A scalable content-addressable network. In SIGCOMM 01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA, ACM Press. [9] Wesley W. Terpstra, Stefan Behnel, Ludger Fiege, Andreas Zeidler, and Alejandro P. Buchmann. A peer-to-peer approach to content-based publish/subscribe. In DEBS 03: Proceedings of the 2nd international workshop on Distributed event-based systems, pages 1 8, New York, NY, USA, ACM Press. [10] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet applications. In SIGCOMM 01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA, ACM Press. 18

19 [11] Mauro Caporuscio, Antonio Carzaniga, and Alexander L. Wolf. Design and evaluation of a support service for mobile, wireless publish/subscribe applications. IEEE Transactions on Software Engineering, 29(12): , December [12] Ludger Fiege, Felix C.Gartner, Oliver Kasten, and Andreas Zeidler. Supporting mobility in content-based publish/subscribe middleware. In Proceedings of Middleware 2003, pages , [13] Yongqiang Huang and Hector Garcia-Molina. Publish/subscribe in a mobile environment. Wirel. Netw., 10(6): ,