Servios de Notificao de Eventos Baseados

em Publish/Subscribe
Bruno Oliveira Silvestre
brunoos@inf.puc-rio.br
4 de julho de 2005

1 Introduo
O modelo de comunicao publish/subscribe baseado na troca assncrona de
mensagens, conhecidas como eventos. Ele consiste de um conjunto de clientes
que publicam esses eventos (produtores), os quais so encaminhados para clientes
que registraram interesse em receb-los (consumidores).
Alm do assincronismo, esse modelo oferece o desacoplamento entre o pro-
dutores e o consumidores de eventos, dando mais flexibilidade e extensibilidade
s aplicaes que utilizam esse modelo, pois a incluso de novos produtos e con-
sumidores se torna simples [1, 2, 3, 4]. Alguns sistemas fornecem ainda a possibi-
lidade de persistncia dos eventos, permitindo que um cliente que no esteja ativo
no momento possa receb-los posteriormente [2, 3].
A implementao de um servio de notificao de eventos utilizando publish/
subscribe pode seguir um abordagem centralizada onde um nico elemento res-
ponsvel por manter o registro de interesse dos consumidores e por disseminar os
eventos que so gerados. Essa arquitetura, apesar da simplicidade, apresenta pro-
blemas de escalabilidade, sendo invivel para ser adotado com uma grande-escala
de clientes conectados.
Um modelo distribudo para o servio consiste de um conjunto de servido-
res interconectadores, cada um responsvel por prover servios para uma parte
dos clientes. A eficincia desse modelo depende de como os servidores esto in-
terligados, como os eventos so propagados e a estratgia de processamento dos
interesses dos consumidores [1].
Neste trabalho sero apresentados quatro servios de notificao de eventos
baseados em publish/subscribe que adotam um modelo distribudo. O objetivo
mostrar as estratgias adotadas por cada um deles para alcanar escalabilidade na
disseminao em larga-escala de eventos.

1
 A forma como os consumidores selecionam que tipo de eventos querem re-
ceber pode variar. Os quatro servios a seguir permitem que a seleo seja feita
atravs de filtros que so aplicados sobre o contedo dos dos eventos. Esses filtros
so passados na hora em que o cliente efetua uma subscrio no sistema.
A seo 2 apresenta os sistemas SIENA, Rebeca, Meghdoot e Terpstra et al.
Na seo 3 so apresentados comentrios finais sobre os sistemas.

2 Servios de Notificao Publish/Subscribe

Nesta seo apresentaremos quatro servios de notificao distribudos baseados
em contedo, com diferentes abordagens de arquiteturas de interligao dos ser-
vidores e formas de propagao das notificaes de eventos.

2.1 SIENA
O SIENA [5, 1] um sistema de notificao de eventos que adota uma estrutura
de servidores interconectados que propagam as notificaes e servem de ponto
de acesso, atravs dos quais os clientes podem registrar seus interesses e receber
as notificaes de eventos. Esses clientes so divididos em duas categorias, os
objetos de interesse, que so as fontes de eventos, e as partes interessadas, que
consomem as notificaes. A figura 1 ilustra a arquitetura geral do sistema.

Figura 1: Servio de notificao SIENA.

Em geral as partes interessadas no desejam receber todo os tipos de eventos

que esto sendo propagados na rede. Ao se registrarem em um servidor para
receber eventos, os clientes informam filtros que sero aplicados s notificaes.
Apenas as notificaes que casam com esses filtros so repassadas aos clientes.

2
O SIENA tambm permite que os objetos de interesse anunciem quais os tipos
de eventos eles geram, possibilitando que o sistema utilize essa informao 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 contedo das
notificaes, nos filtros das partes interessadas, nos anncios dos objetos de in-
teresse e na forma como os servidores esto conectados. O objetivo enviar os
dados apenas para os servidores que possuem clientes com interesse nessas infor-
maes, seguindo o caminho mais curto possvel.
Quando um cliente se registra, o servidor necessita propagar pela rede o inte-
resse 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 trfego de mensagens de controle. Para reduzir o nmero de propagaes,
o sistema dissemina apenas os filtros mais gerais que englobam filtros mais espe-
cficos.
Por exemplo, suponha que o sistema seja empregado para notificar os valores
dos aes de uma bolsa e que trs clientes, A, B e C, registram interesse em receber
notificaes sobre o valor das aes 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 primrias, que podem ser combinadas gerando configuraes hbridas: hie-
rrquica e peer-to-peer. A estrutura hierrquica utiliza o conceito de cliente/servi-
dor para a propagao das notificao, e na abordagem peer-to-peer os servidores
esto conectados na forma de um grafo no direcionado. Os detalhes sobre cada
uma delas so descritos a seguir.

Hierrquica
Na estrutura hierrquica os servidores so dispostos como um grafo orientado,
como mostra a figura 2. O protocolo utilizado para a comunicao entre clientes e
servidores e entre servidores o mesmo, ou seja, um dado servidor no sabe dis-
tinguir se as notificaes esto sendo enviadas ou recebidas de um outro servidor
ou de um cliente. Isso pode ser visto como a extenso do modelo centralizado de
notificao pois no h um protocolo diferenciado entre os servidores. Com essa
disposio, os servidores se comunicam apenas com o seus pais e com os seus
filhos, reduzindo o nmero interao entre os ns da rede.
Quando um servidor recebe um pedido de subscrio de um cliente, ele pri-
meiro verifica se esse cliente j realizou anteriormente uma subscrio usando um

3
 Figura 2: Topologia hierrquica do SIENA.

filtro mais abrangente que o atual. Nesse caso o pedido simplesmente descar-
tado. Caso contrrio, duas possibilidades podem ocorrer: (i) o filtro existe no
servidor, mas o cliente no est relacionado ao mesmo, ou (ii) um novo filtro.
Se o filtro j existe, o servidor apenas adiciona o cliente na lista de ns a serem
notificados quando um evento relacionado for recebido. Perceba que quando o
servidor j possui o filtro, no h nenhuma propagao do mesmo, ou seja, no
h troca de mensagens entre os servidores da rede para atualizao do roteamento
dos eventos.
A propagao 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 C1 para o pai S 2 , recebendo o pedido de subscrio de C2 contendo o
filtro valor > 10. Como o filtro de C2 mais abrangente que o filtro de C1 , S 1
comunica S 2 de que o filtro anterior no 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 relao de filtros de um servidor, um
servidor pode afetar a relao de outro servidor. O tratamento dado a uma propa-
gao entre servidores o mesmo dado subscrio entre clientes e servidores.
Assim, no exemplo anterior, a propagao do novo filtro para S 2 pode ocasionar
em uma propagao 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 no propaga os interesses de seus
filhos.
As notificaes so encaminhadas para os ns filhos (clientes e servidores) de
acordo com os filtros registrados. Quando um servidor recebe a publicao de

4
 Figura 3: Propagao de subscrio na estrutura hierrquica.

um evento vindo de um objeto de interesse, ele verifica quais de seus filhos esto
interessados em tal evento e notifica-os.
Entretanto, como os filtros so propagados somente para os pais at eventu-
almente 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. Ento, esse ances-
tral propaga o evento pelo ramo onde os clientes se encontram. Por exemplo, na
figura 3, se o cliente C3 estiver interessados em eventos gerados por C2 , S 1 no
possui tal conhecimento. Mas, ao receber a propagao os eventos de C2 vindas
de S 1 , S 2 identifica o interesse de C3 e notifca-o.
Quando um cliente no deseja mais receber notificaes de um dado tipo de
evento ele deve comunicar ao servidor. O SIENA permite que o cliente cancele
mais de uma subscrio 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 so cobertos pelo filtro do cancelamento e retira o cliente de todas
as listas de notificaes associadas com esses filtros. Caso algum filtro fique com
sua lista de notificaes vazia, ele removido do servidor.
O fato de remover filtros de um servidor pode alterar o esquema de propagao
de eventos na rvore. Ao cancelar um filtro, o servidor deve verificar se o filtro
no foi o propagado para o pai. Nesse caso, o servidor deve comunicar o seu pai
de que o filtro antigo no mais utilizado e que um novo filtro (se houver) deve ser
utilizado. Isso pode causar um efeito em cadeia pois o pai tambm deve verificar
se o filtro a ser substitudo foi propagado. Como exemplo, se na figura 3 o cliente
C2 cancelar o seu interesse por eventos cujo valor seja maior que 10, o servidor
S 1 deve remover o filtro, pois apenas C2 estava relacionado com o mesmo, e deve

5
comunicar S 2 de que o novo filtro valor > 15.

Peer-to-Peer
Na arquitetura peer-to-peer os servidores que fazem parte do servio de notifica-
o so interligados formando um grafo no dirigido, como mostra a figura 4(a).
Entretanto, mesmo admitindo que mais de um caminho possa ligar dois servido-
res, os mecanismos de seleo e entrega do SIENA se baseiam na rvore geradora
mnima do grafo, reduzindo as ligaes entre servidores a um grafo acclico (fi-
gura 4(b)).

Figura 4: Estrutura peer-to-peer do SIENA.

Aparentemente, o SIENA designa o termo peer-to-peer para uma rede no

estrutura, considerando estticos os membros da rede.
O processo de tratamento dado s subscries estende o processo do modelo
hierrquico, sendo que a principal diferena como so definidos os vizinhos para
os quais sero propagadas as subscries. Assim, quando um servidor recebe uma
subscrio (seja de um cliente ou de uma propagao), se o filtro j estiver regis-
trado no servidor ou for menos abrangente que um filtro submetido anteriormente,
o processo se d da mesma maneira que na arquitetura hierrquica.
Contudo, se o servidor no possui o filtro, ele registra-o e verifica a necessi-
dade de propaga-lo para seus vizinhos. Para definir quais servidores devem rece-
ber a propagao, avaliada-se a seguinte expresso
[
0
vizinhos NPAG( f ) f f 0 propagado( f ) (1)

onde f o filtro da subscrio. NPAG representa os vizinhos que no participam

da rvore geradora mnima ou que j receberam a propagao de f. O ltimo
termo indica o conjunto dos vizinhos por onde foram propagados filtros f 0 mais
abrangentes que f.

6
 O algoritmo de notificao de eventos e de cancelamento de subscrio da ar-
quitetura peer-to-peer so similares aos empregados pela hierrquica. Quando um
objeto de interesse publica um evento, o seu ponto de acesso verifica quais de seus
clientes esto interessados em tal evento e notificando-os. Ele tambm propaga o
evento para os vizinhos que registraram interesse, que realizaro o mesmo proce-
dimento. Assim, o evento disseminado por toda a rede de servidores at atingir
as partes interessadas.
Como visto anteriormente, os clientes selecionam as subscries a serem can-
celadas atravs de um filtro, isto , todos as subscries do cliente que so abran-
gidas por esse filtro so removidas do ponto de acesso. Aps remover as subscri-
es, o servidor deve reavaliar a expresso (1). Isso pode acarretar na mudana
do filtro que deve ser propagado ou no conjunto de vizinhos que devem receber as
notificaes. Caso haja mudana, o servidor interage com seus vizinhos para man-
ter consistente o caminho de propagao, atualizando ou cancelando os interesses
por eventos.
Um aprimoramento que pode ser introduzido nesta arquitetura o anncio de
eventos. Os objetos de interesses anunciam aos seus pontos de acesso quais os
tipos de eventos que so gerados, com isso, os servidores podem usar as infor-
maes dos anncios como limitadores para a propagao das subscries, 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 cli-
ente, os anncios so propagados pela rede segundo uma expresso semelhante
expresso (1). A diferena que em vez de utilizar o filtro da subscrio,
utilizado o tipo de evento que gerado pelo objeto de interesse.
A frmula de propagao de subscrio foi alterada para utilizar os anncios
na derivao dos vizinhana de propagao, sendo ela
[ \
0
(vizinhos NPAG( f ) f f propagado( f ))
0 f a anunciadores(a) (2)

onde anunciadores fornece um conjunto de vizinhos que realizaram anncios a,

que casam com o filtro f.

2.2 Rebeca
Rebeca [2, 6] um servio de notificao com suporte a variados algoritmos de
roteamento baseados no contedo da notificao e em anncios. Ele conta com
implementaes em JAVA e Microsoft .Net.
A infra-estrutura do servio consiste de um conjunto de brokers interconecta-
dos, divididos em duas categorias: brokers locais, que servem de ponto de acesso
para os clientes, e roteadores, responsveis por propagar as notificaes pela rede.

7
A implementao descrita em [2] considera a interconexo dos brokers em forma
de rvore (figura 5), citando como trabalho futuro uma implementao que consi-
dera a possibilidade de ciclos na conexo dos roteadores.

Figura 5: Interligao dos brokers no Rebeca.

As notificaes so compostas de um conjunto de atributos, definidos como

o par (nome, valor), como por exemplo, {(tipo, StockQuote), (nome, Infineon),
(preo, 45,00)}.
Uma das vantagens do Rebeca o uso de uma arquitetura que permite o de-
senvolvimento de outros tipos de algoritmos de roteamento das notificaes. Em
sua avaliao 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 fuso de filtros [2]. O algoritmo de flooding
o mais simples, os brokers apenas propagam por toda rede a publicao de um
evento realizado por um dos clientes do servio, no realizando nem um tipo de
otimizao na entrega. Os demais algoritmos adotam filtros para estabelecer o
caminho de entrega das notificaes.
No algoritmo baseado em filtros simples, quando um ponto de acesso recebe
uma subscrio, o respectivo filtro de interesse propagado para todos os brokers
da rede. Assim, todos os brokers sabem os interesses de todos os clientes. Essa
tcnica, apesar de simples, apresenta desvantagem quando o nmero de subscri-
es alto, pois a tabela de rotas de cada broker possuir muitas entradas, difi-
cultando a localizao dos ns para os quais a notificao deve encaminhada. O
cancelamento de uma subscrio se d propagando o pedido pela rede e cada um
dos brokers retira de sua tabela de rotas a entrada referente ao cancelamento.

8
 O roteamento baseado em identidade de filtros segue o mesmo princpio uti-
lizado no filtro simples, mas evita a propagao 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 idntico ao utilizado pela ar-
quitetura 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 fuso de filtros tem por objetivo reduzir o nmeros 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 avaliao de uma notificao mais rpida. Uma
das dificuldades encontrar um filtro que consiga substituir os demais filtros sem
perder ou adicionar notificaes na hora da avaliao. Empregar a fuso conside-
rando filtros com o mesmo destino facilita a definio do filtro equivalente.
Como exemplo, suponha que um cliente C tenha efetuado uma subscries em
seu ponto de acesso com o filtro F1 . Quando o cliente efetua uma nova subscrio
com o filtro F2 , o ponto de acesso realiza a fuso de ambos os filtros, criando um
filtro substituto F3 , e o propaga para os vizinhos. Lembrando que este algoritmo
uma camada sobre o algoritmo baseado em cobertura de filtros, os vizinhos tomam
F3 como uma subscrio mais abrangente e o utilizam na hora de selecionar quais
notificaes devem ser propagadas para C. Assim, o filtro F1 , referente primeira
subscrio, poder ser descartado pelos brokers (exceto o ponto de acesso) caso
ele no esteja sendo usado como rota para outro cliente.
Os pontos de acesso devem armazenar todos os filtros de seus clientes e suas
respectivas fuses para serem capazes de desfazer o processo no caso de um cli-
ente cancelar uma ou mais subscries cujos filtros foram usados em uma fuso.
Deve-se propagar para os vizinhos o cancelamento do filtro derivado da fuso bem
como os filtros que no removidos para que as rotas sejam mantidas.
Rebeca tambm disponibiliza o mecanismo de anncio, onde os clientes anun-
ciam quais os tipos de eventos que eles geram. Como no SIENA, os anncios so
usados para otimizar a propagao das subscries, ou seja, as subscries se-
ro propagadas pelas subredes da arquitetura onde exista um cliente que anunciou
tipos de eventos relacionados com o filtro da subscrio. Essa estratgia visa
diminuir o nmero de mensagens de controle na rede. Vale destacar que esse
mecanismo no se aplica ao algoritmo de flooding.
O modelo tradicional de publish/subscribe no permite que novos clientes te-
nham acesso a notificaes j publicadas. Rebeca estende esse modelo permitindo
que os clientes solicitem notificaes antigas. Quando um cliente realiza uma
subscrio, ele pode informar ao servio que as notificaes dadas a partir de uma
certa data sejam publicadas novamente. No entanto, o sistema deve garantir que
apenas o novo cliente receba essas notificaes.

9
 O armazenamento do histrico das notificaes pode seguir duas estratgias.
Na primeira, as prprias fontes de eventos gerenciam os seus histricos. A se-
gunda e mais complexa abordagem encarregar os brokers de gerenciar o hist-
rico, poupando os clientes. Contudo, a medida que os brokers vo encaminhando
as notificaes para o cliente, o servio deve se certificar de que notificaes repe-
tidas no estejam sendo repassadas. Isso pode ocorrer pois os brokers armazenam
as notificaes que trafegaram por ele. Assim, ao propagar uma notificao 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 subscries e o roteamento das notificaes. O servio baseado em uma
arquitetura peer-to-peer, onde cada n ser um ponto de acesso para o sistema
e tambm um roteador de notificaes. A definio de onde as subscries so
armazenadas dada atravs do uso de tabelas hash distribudas [8].
Normalmente, sistemas baseados em peer-to-peer so desenvolvidos para su-
portar uma maior flexibilidade, modularidade e escalabilidade. Um dos desafios
nesse caso distribuir a carga de tratamento das subscries e da entrega dos
eventos.
O servio 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, (preo:
float, 0.0, 50.0).
O Meghdoot constri um espao lgico com 2n dimenses, sendo n o nmero
de atributos do esquema, e mapeia as subscries e notificaes nesse espao para
determinar quais clientes devem ser notificados. Dado um esquema {A1 , A2 , .., An },
as dimenses 2i 1 e 2i do espao correspondem ao intervalo [Mini , Maxi ] do
atributo Ai , para 1 i n. Considerando um esquema {(preo: float, 0.0,
50.0)} temos um espao com duas dimenses, cujo intervalo de cada uma delas
[0.0, 50.0], como mostra a figura 6.
Aps a definio, o espao particionado em zonas, de acordo com o nmero
de ns que compes a rede. A figura 6 apresenta o espao divido em cinco zo-
nas. Cada n fica responsvel por uma zona e, por conseguinte, pelas subscries
nela mapeada, sendo que a definio da zona correspondente a subscrio dada
atravs do filtro utilizado.
Um filtro tem a seguinte forma F = (l1 A1 h1 ) (l2 A2 h2 ) ... (ln
An hn ), ou seja, restringe um intervalo para cada um dos atributos. A igualdade
alcanada fazendo com que l e h sejam iguais ao valor desejado. Caso o cliente
omita um dos atributos na criao do filtro, l e h assumem respectivamente os
valores Min e Max do atributo ausente, definidos no esquema.

10
 Figura 6: Exemplo de espao de 2 dimenses usado pelo Meghdoot.

As subscries representam um ponto no espao lgico dado pelas coordena-

das hl1 , h1 , l2 , h2 , ..., ln , hn i, onde l e h so extrados do filtro. Assim, quando um
cliente realiza um subscrio, esta deve ser encaminhada para o n responsvel
pela zona que contm o ponto equivalente essa subscrio. Esse n ficar en-
carregado de notificar o cliente quando ocorrer um evento que satisfaa o filtro de
interesse.
Pela forma como o ponto estabelecido, as subscrio sempre so mapeadas
para as zonas acima do hiperplano diagonal. As zonas abaixo do hiperplano so
usadas no roteamento das subscries e das notificaes. Por exemplo, consi-
derando o espao bidimensional da figura 7, as subscries seriam mapeadas na
regio sombreada.

Figura 7: rea de mapeamento das subscries.

11
 Os ns possuem conhecimento apenas de quem so os responsveis pelas reas
vizinhas as suas. Quando uma subscrio recebida por um n, este identifica a
zona a qual a subscrio pertence. Caso no seja a sua zona, o n deve efetuar
o seu roteamento da subscrio, encaminhando-a para o vizinho mais prximo
da zona destino. Assim, a subscrio vai sendo encaminhada at atingir a zona
correta.
Da mesma forma que uma subscrio, os eventos tambm so mapeados em
pontos no espao para determinar quais clientes devem ser notificados. Seja um
evento E = {A1 = v1 , A2 = v2 , . . . , An = vn }, o ponto relativo a ele p =
hc11 , c12 , c21 , c22 , . . . , cn1 , cn2 i, onde ci1 e ci2 assumem o valor do atributo Ai per-
tencente ao evento, por exemplo, c11 = v1 e c12 = v1 . Entretanto, como o sistema
de notificao assume que um evento pode no conter todos os atributos descritos
no esquema, ci1 e ci2 assumem os valores Min e Max do atributo Ai , caso este seja
omitido no evento.
Para identificar quais clientes devem ser notificados, o Meghdoot avalia a se-
guinte propriedade
i {1, 2, . . . , n} li ci1 ci2 hi (3)
considerando um filtro F = (l1 A1 h1 ) (l2 A2 h2 ) ... (ln An hn )
de um subscrio e um ponto P = hc11 , c12 , c21 , c22 , ..., cn1 , cn2 i do evento.
Contudo, o sistema no avalia todas as subscries do espao quando um
evento publicado. De acordo com a formulao apresentada, num espao de
2n dimenses, as subscries que casam com um evento residem na regio hi-
per retangular compreendida pelos pontos hMin1 , c11 , Min2 , c21 , ..., Minn , cn1 i e
hc12 , Max1 , c22 , Max2 , ..., cn2 , Maxn i. Para ilustrar, a figura 8 mostra um espao
de 2 dimenses onde a regio sombreada contm as subscries que casam com o
evento p = { preo=10.0 }.
Da mesma forma que as subscries, uma notificao 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 idntico ao roteamento de uma subscrio: o n encaminha a
notificao para o vizinho mais prximo da zona destino.
Aps atingir a zona designada e o n responsvel notificar os devidos clientes,
a notificao deve ser propagadas pelas zonas que possuem interseo com a re-
gio hiper retangular referente a essa notifica, pois tambm podem haver clientes
nessas zonas que estejam interessados no evento. Por exemplo, na figura 8, o n
responsvel pela zona A recebe a publicao do evento que deve ser encaminhada
para a zona Z. A notificao ento encaminhada atravs das zonas B e C at Z. Os
clientes mapeados em Z e que esto interessados no evento so notificados (subs-
cries pertencentes rea sombreada de Z). O evento ento propagado para X
e depois Y para que os clientes mapeadas naquelas zonas possam ser notificados.

12
 Figura 8: Roteamento de uma notificao de evento.

Essa modelagem baseada no esquema dos atributos para identificar a posio

da subscrio e do evento no espao penalizada quando h muitos ns interes-
sados em um evento, o que leva a concentrao de uma grande quantidade de
subscries em uma nica zona. Um efeito semelhante ocorre quando um mesmo
tipo de evento publicado freqentemente por diversos clientes.
O balanceamento da carga entre os ns alcanado atravs da diviso e repli-
cao de zonas. A diviso de uma zona visa reduzir o nmero de subscries que
um n da rede peer-to-peer deve gerenciar.
A estratgia de replicao de zona mais aplicvel quando ocorre uma grande
quantidade de publicaes de um mesmo evento, ou eventos muito parecidos. Isso
faz com que um determinado conjunto de zonas gerem um grande fluxo de notifi-
caes para os clientes, sobrecarregando os ns responsveis. Quando um evento
est sendo propagado, os vizinhos de uma zona replicada podem selecionar qual
das rplicas ficar responsvel em notificar os clientes, utilizando, por exemplo,
um esquema de round robing.
A diviso de uma zona ou a criao de uma rplica ocorrem geralmente quan-
do 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 respon-
svel por uma delas, ou se uma rplica ser gerada.

2.4 Terpstra et al.

Terpstra et al. [9] propuseram um sistema de notificao peer-to-peer baseado na
arquitetura de comunicao do Chord [10] juntamente com os conceitos de co-
bertura e fuso de filtros do Rebeca [2]. Nessa arquitetura os ns so clientes e

13
pontos de acesso ao mesmo tempo, ou seja, eles participam do sistema provendo
acesso a outros clientes, mas tambm realizam suas prprias subscries e notifi-
cam eventos.
Um dos objetivos obter um sistema mais tolervel 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 mnima
como caminho de propagao. Isso obtido seguindo o modelo de comunicao
do Chord.
O Chord foi desenvolvido para mapear chaves em ns da redes de forma a
localiz-las eficientemente. Ele emprega um esquema de funes hash consisten-
tes que distribuem os ns em um espao circular ordenado de tamanho 2m . A
posio de cada n no crculo dado pelo valor de retorno da funo 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 responsvel por essa
chave, caso o valor da chave K seja igual ao da chave de N ou N o n sucessor.
Considerando o espao circular, o n sucessor de uma chave o primeiro n no
sentido horrio aps a chave. A figura 9 ilustra um espao circular com dez ns,
armazenando cinco chaves.

Figura 9: Espao circular do Chord.

O Chord adota uma estratgia de que um n N da rede mantm uma tabela

de informaes sobre um conjunto menor de ns. Os membros desse conjunto
so os ns responsveis pela chaves (n + 2i1 ), onde n o valor da chave de N
e 1 i m. Assim, quando N deseja localizar uma chave K e esta no est
sob a responsabilidade de um dos ns de sua tabela, N delega a busca para um
n N 0 da tabela a seleo baseada no valor de K [10]. Caso no saiba a
localizao da chave, N 0 tambm pode delegar o pedido para um dos integrantes

14
de sua tabela. Isso prossegue at que K seja encontrada. A figura 10 mostra o
processo de localizao de K54, onde ocorrem duas delegaes.

Figura 10: Localizao de uma chave no Chord.

Seguindo esse esquema de delegao, o Chord tem um funcionamento se-

melhante s tabelas hash distribudas utilizadas pelo Meghdoot, sendo os ns do
sistemas responsveis por partes do espao circular. Terpstra et al. empregaram
esse conceito para definir as rvores de propagao das subscries.
Cada rvore montada tendo como raiz o n que publica o evento. Esse n
raiz propaga o evento para os ns com chaves (n + 2i1 ) pertencentes tabela de
localizao, que demonstraram interesse pelo evento. Isso pode ser visto como
se a raiz delegasse para esses ns a responsabilidade de divulgar o evento dentro
de um subespao. Nessa divulgao, o n responsvel pelo subespao pode dele-
gar a entrega do evento para outros ns tambm pertencentes ao subespao. Como
exemplo, na figura 11(a) podemos ver um n N publicando um evento que propa-
gado por todo o espao circular, considerando que todos os ns esto interessados
no evento.
A propagao do evento tambm pode ser vista como uma rvore, como mos-
tra a figura 11(b). Se considerarmos cada n n do sistema, percebemos que exis-
tem n rvores diferentes, ou seja, dependendo do n que publica o notificao,
esta ser roteada por caminhos distintos.
Este sistema de notificao emprega o algoritmo de fuso de filtros do Re-
beca, e da mesma forma que ocorre na divulgao dos eventos, cada n possui um
caminho diferente para propagar as subscries.
Consideremos que o n N deseja efetuar uma subscrio para receber um de-
terminado tipo de evento e que o filtro mais abrangente que os das subscries
anteriores. N propaga sua subscrio no caminho inverso que uma notificao

15
 Figura 11: Propagao das notificaes de um n.

faria at atingi-lo. Para isso, alm de N manter a tabela de quais ns ele deve
notificar quando um evento ocorre, N tambm deve possuir uma tabela T con-
tendo quais ns notificam-no. Ento, N unifica os seus filtros mais abrangentes
e propaga o resultado para os ns da tabela T. Estes atualizam o interesse de N
e, baseados na cobertura de filtros, analisam a necessidade de propagar para seus
responsveis 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 subscrio para um dado N da rede.

Figura 12: Propagao das subscries de um n.

16
3 Comentrios Finais
Neste trabalho foram apresentadas as arquiteturas do SIENA, Rebeca, Meghdoot
e Terpstra et al., bem como suas estratgias para prover um servio de notificao
de eventos de grande-escala.
O modelo hierrquico do SIENA, ao propagar os filtro apenas para os pais,
gera um nmero menor de mensagens de controle para manter os interesses dos
consumidores, comparado com o modelo peer-to-peer. Por outro lado, quando o
nmero de publicaes aumenta, os servidores dos nveis mais altos da hierarquia
lidam com um grande nmero 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 propagao dos eventos. O Rebeca disponibiliza ainda mais trs
outros algoritmos de roteamento e uma arquitetura extensvel que permite o aco-
plamento de novos algoritmos sem afetar o funcionamento do sistema.
O Rebeca tambm implementa o histrico de notificaes, o que possibilita
que os clientes recuperem eventos publicados anteriormente. Essa funcionalidade
comumente empregada por aplicaes 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 distribudas que mapeia subscries e
eventos em zonas de um espao lgico. Os testes mostraram que o seu algoritmo
de roteamento baseado em zonas utiliza poucos ns da infra-estrutura do sistema
at que o evento seja notificado aos interessados [7]. O Meghdoot tambm prov
dois mecanismos de balanceamento de carga que consistem em diviso e replica-
o das zonas.
No Rebeca e no SIENA h apenas um caminho de propagao, 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 propagao das subscries e dos eventos na tentativa
de reduzir os dados no caso de falha de um dos membros da rede.
Alguns trabalhos esto avaliando o uso de servios de notificao empregando
publish/subscribe para comunicao com dispositivos mveis, cujos requisitos ca-
sam com as caractersticas do modelo publish/subscribe, principalmente o assin-
cronismo e o desacoplamento [11, 12, 13].

Referncias
[1] Antonio Carzaniga, David S. Rosenblum, and Alexander L. Wolf. Design
and evaluation of a wide-area event notification service. ACM Trans. Com-

17
 put. Syst., 19(3):332383, 2001.
[2] Gero Mhl. Large-Scale Content-Based Publish/Subscribe Systems. PhD
thesis, Darmstadt University of Technology, 2002.
[3] Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie
Kermarrec. The many faces of publish/subscribe. ACM Comput. Surv.,
35(2):114131, 2003.
[4] The Gryphon Team. Achieving scalability and throughput in a pu-
blish/subscribe system. Technical report, IBM Research Report, February
2004.
[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 Princi-
ples of distributed computing, pages 219227, New York, NY, USA, 2000.
ACM Press.
[6] Gero Mhl, Andreas Ulbrich, Klaus Herrmann, and Torben Weis. Dissemi-
nating information to mobile clients using publish-subscribe. IEEE Internet
Computing, 8(3):4653, May-2004.
[7] Abhishek Gupta, Ozgur D. Sahin, Divyakant Agrawal, and Amr El Abbadi.
Meghdoot: content-based publish/subscribe over p2p networks. In Procee-
dings of the 5th ACM/IFIP/USENIX international conference on Middleware,
pages 254273, New York, NY, USA, 2004. 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: Pro-
ceedings of the 2001 conference on Applications, technologies, architectu-
res, and protocols for computer communications, pages 161172, New York,
NY, USA, 2001. ACM Press.
[9] Wesley W. Terpstra, Stefan Behnel, Ludger Fiege, Andreas Zeidler, and
Alejandro P. Buchmann. A peer-to-peer approach to content-based pu-
blish/subscribe. In DEBS 03: Proceedings of the 2nd international
workshop on Distributed event-based systems, pages 18, New York, NY,
USA, 2003. ACM Press.
[10] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Ba-
lakrishnan. Chord: A scalable peer-to-peer lookup service for internet appli-
cations. In SIGCOMM 01: Proceedings of the 2001 conference on Applica-
tions, technologies, architectures, and protocols for computer communicati-
ons, pages 149160, New York, NY, USA, 2001. ACM Press.

18
[11] Mauro Caporuscio, Antonio Carzaniga, and Alexander L. Wolf. Design and
evaluation of a support service for mobile, wireless publish/subscribe appli-
cations. IEEE Transactions on Software Engineering, 29(12):10591071,
December 2003.

[12] Ludger Fiege, Felix C.Gartner, Oliver Kasten, and Andreas Zeidler. Sup-
porting mobility in content-based publish/subscribe middleware. In Procee-
dings of Middleware 2003, pages 103122, 2003.

[13] Yongqiang Huang and Hector Garcia-Molina. Publish/subscribe in a mobile

environment. Wirel. Netw., 10(6):643652, 2004.

19