Este artigo descreve (1) o paradigma de publish-subscribe e como ele fornece uma abordagem push-based para disseminar informações de forma persistente para múltiplos consumidores, (2) alguns middlewares que implementam este paradigma, incluindo suas características-chave como expressividade, topologia, eventos, transmissão e qualidade do serviço, e (3) exemplos de middlewares publish-subscribe como o Data Distribution System, WebSphere MQ e Tuxedo.

1. Publish-Subscribe Middleware
Pedro Fernandes
Departamento de Ciência de
Computadores
Faculdade de Ciências da Universidade
do Porto
RESUMO interessados. Um evento pode ser visto como uma mensagem
Neste artigo vamos descrever os conceitos associados ao enviada por um produtor de informação e implicitamente
paradigma de Publish-Subscribe, assim como alguns endereçada ao conjunto de todos os consumidores que
Middlewares que os implementam. subscreveram esse género de evento. (ver Figura 1)
Palavras-chave
Publish-Subscriber Middleware.
1. INTRODUÇÃO Figura 1: Paradigma Publish-Subscribe.
As aplicações de software, fruto da miniaturização e mobilidade
crescente dos equipamentos, estão cada vez mais a necessitar de As necessidades de processamento de informação neste género
seguir modelos distribuídos. Hoje em dia, as aplicações de paradigma são imensas. Sendo que a plataforma de
necessitam de comutar dados de e para muitos outros nós middleware está encarregue de executar o processamento,
computacionais vizinhos, agregando muitas vezes o seu poder filtrando informação para teoricamente milhões de utilizadores,
computacional, num sistema em rede cada vez mais extenso. dadas as suas alterações de localização, alteração de perfil (i.e.,
Este género de aplicações encontra diversas finalidades: as subscrições que fazem no momento) e a informação estática e
aeroespaciais, militares, industriais e comerciais. [1] dinâmica do meio ambiente. [1] O local, no seio do sistema, onde
Comum a todas estas aplicações está a necessidade de colectar é feito esse processamento vai depender depois da topologia
continuamente dados e integrá-los de forma distribuída entre um adoptada (como veremos no tópico 3.2).
largo conjunto de utilizadores, sítios e aplicações. A aplicação Estes novos sistemas necessitam de novos padrões e algoritmos
tem pois de filtrar e distribuir dados relevantes para o interesse de comunicação. Dos vários middlewares que surgiram para
dos utilizadores e outros componentes, de uma forma persistente. colmatar as novas exigências, temos que a maior parte inclui as
Mais abstractamente, na maior parte dos cenários, a maioria dos arquitecturas publish-subscribe. Estas representam actualmente
referidos nós constituem entidades desconhecidas das restantes e os padrões mais eficientes para a transmissão de dados desde o
tanto a fonte dos dados como o destinatário podem por vezes não produtor até aos muitos consumidores. [2]
estar presentes na rede ao mesmo tempo. [1]
O paradigma tradicional de request-response, altamente
2.1 O que é um Middleware?
advogado como um paradigma de computação distribuída de
Um middleware é uma peça de software reutilizável que reside
eleição, não é adequado para encarar estes novos desafios. Nesse
entre as camadas de aplicação e o sistema operativo, camadas de
modelo clássico de abordagem dita pull-based, um cliente, que
rede e camadas físicas. (Figura 2)
necessite de updates instantâneos de informação, necessitaria de
questionar o provider (ou servidor) continuamente, levando a
congestão da rede.
Os requisitos actuais estão a levar a necessidade de adopção de
modelos de disseminação de informação que, ofereçam aos
utilizadores informação pertinente com um elevado grau de
disponibilidade, através duma abordagem push-based. É este tipo
de abordagem que o paradigma publish-subscribe segue.
2. PARADIGMA
Este paradigma constitui um simples modelo de interacção que
consiste em produtores (publishers) de informação, que publicam Figura 2: Localização do Middleware no modelo OSI.
eventos no sistema, e pelos consumidores (subscribers) de
informação, que subscrevem os eventos que lhes interessam O principal papel do middleware é então o de interligar as
dentro do sistema. O sistema de publish-subscribe assegura a aplicações com as restantes camadas de mais baixo nível, assim
notificação por ordem temporal dos eventos aos subscribers

2. como outras infra-estruturas, coordenando a forma como as 3.2 Topologia
aplicações interagem entre si. Na topologia dos event dispatcher podemos ter duas opções de
O recurso a middlewares é especialmente importante em configuração: centralizado ou distribuído. No primeiro caso
situações onde os processos executam em plataformas ou temos um componente único que age como event dispatcher, o
arquitecturas diferentes, visto potenciar a interoperabilidade e que potencialmente reduz a escalabilidade do sistema e introduz
comunicação das mesmas. um ponto único de falha.
No caso de middlewares publish subscribe que providenciem
arquitecturas distribuídas verifica-se um conjunto de dispatching
3. PUBLISH-SUBSCRIBE MIDDLEWARE servers inter-ligados que, cooperam na colecta de subscrições
As aplicações que exploram os mecanismos do publish-subscribe vindas de clientes e no roteamento dos eventos, com o objectivo
middleware organizam os seus clientes como colecções de de reduzir a sobrecarga da rede e aumentar a escalabilidade da
componentes autónomos, que interagem publicando notificações mesma. [1]
de eventos, ao mesmo tempo que subscrevem as classes de É natural que, em sistemas com arquitectura distribuída, cada
eventos nas quais estão interessados. O event dispatcher (ou middleware apresente estratégias diferentes para os seus
event broker) é o componente da arquitectura responsável por dispatchers, no que concerne ao processamento de eventos e
colectar as subscrições e enviar os eventos para os subscribers. subscrições proveniente de um mesmo conjunto de clientes. [2]
(ver Figura 1)
Existem mesmo alguns sistemas de publish-subscribe que
Dado o enorme potencial deste paradigma, nos últimos anos têm eliminam por completo os dispatchers, deixando a tarefa de
sido desenvolvidos um grande número de publish-subscribe roteamento e filtragem encarregue aos próprios publishers e
middlewares, alguns deles com diferentes abordagens para o subscribers, permitindo assim que as mensagens sejam
mesmo paradigma. transmitidas directamente entre ambos. [7]
Em cada uma dessas abordagens são criadas Application
Programming Interface (API) específicas que permitem então
controlar o fluxo de comunicação entre os subscribers, os
3.3 Eventos
As unidades trocadas entre publishers, dispatchers e subscribers
publishers e os dispatchers.
dentro do sistema publish-subscribe designam-se por eventos. Ao
De entre essas diversas abordagens, destacamos alguns pontos nível dos eventos podemos destacar dois tipos: baixo e alto nível.
que consideramos preponderantes para o sucesso de um
Os eventos de baixo nível incluem as mensagens de texto ou
middleware deste género:
formatos mais complexos como o XML. (que favorece, em larga
medida, a troca de mensagens entre plataformas assentes em
3.1 Expressividade sistemas operativos ou arquitecturas diferentes)
A expressividade da linguagem de subscrição delineia a Os eventos de alto nível incluem a invocação de métodos
separação entre sistemas considerados topic-based, onde as remotos. Nestes casos é conveniente que existam Interfaces pré-
subscrições identificam apenas as classes dos eventos definidas, para que a comunicação consiga estabelecer-se entre
pretendidos (enunciados por intermédio de URL1), e os sistemas os componentes.
content-based, onde as subscrições contêm expressões
Outra das características dos eventos é o facto de serem stateless.
(chamados de event patterns) que permitem um sofisticado Conceptualmente, os eventos não têm persistência no sistema
mecanismo de busca, no próprio conteúdo do evento, orientado nem forma de confirmar a sua recepção. Eles são enviados
aos assuntos pretendidos. [7] apenas para os componentes que subscreveram o evento antes de
Estes são os graus de expressividade mais comuns, mas existem este ser publicado. No entanto é possível contornar esta
algumas publicações que enunciam outros mais. Nomeadamente característica, como veremos mais adiante. [6]
a type-based e a hybrid-based.
As type-based valem-se das capacidades das próprias linguagens
de programação em definir tipos e subtipos, classificando dessa 3.4 Transmissão
forma os eventos. Proporciona-se assim um grau mais elevado de Ao nível da transmissão podemos ter dois tipos: ponto-a-ponto ou
especialização, que a maior parte dos outros métodos de multi-ponto.
subscrição (especialmente o topic-based) não suporta. [5] As transmissões ponto-a-ponto são mais comuns em sistemas
No caso do hybrid-based, propõe-se estabelecer um mecanismo request-response que, operam segundo arquitecturas
simbiótico entre content-based e topic-based, oferecendo dessa centralizadas, onde os eventos são enviados individualmente para
forma uma maior escalabilidade decorrente do uso de técnicas de o cliente respectivo.
comunicação sofisticadas e orientadas para a resolução de Em multi-ponto, os eventos são transmitidos directamente para
situações muito específicas. [4] um conjunto de subscribers que estão interessados nos mesmos.
Esta forma de transmissão permite uma maior escalabilidade e
eficiência. [6]
1
Uniform Resource Locator

3. 3.5 Quality of Service
Alguns dos middlewares possibilitam catalogar os eventos com Instabilidade de throughtput (períodos de forte
uma série de parâmetros extra que, ajudam a implementar sobrecarga contrastam com outros de total silêncio)
mecanismos de suporte ao publish-subscribe e assim colmatar
Lentidão - quando mais e mais aplicações/componentes
algumas das suas lacunas. [6]
usam a infra-estrutura (mesmo quando tratam de
Alguns dos benefícios dessa simbiose traduzem-se a nível de: eventos diferentes)
Persistência: garantia de que o evento não é extraviado; IP broadcast storms (que ao saturarem a rede local
Prioridades: eventos podem ser catalogados consoante a podem levar a desactivação da mesma)
sua importância;
Transacções: eventos relacionados podem ser
agrupados a nível atómico;
6. EXEMPLOS DE PUBLISH-SUBSCRIBE
MIDDLEWARE
Confiança: garantia de entrega dos eventos. A nível conceptual o paradigma publish-subscribe fornece já uma
série de características base que, dependendo do objectivo de
cada middleware e das suas necessidades, podem ser exploradas.
4. VANTAGENS Mas para além disso existem uma série de mecanismos extra
Recapitulando, o paradigma de publish-subscribe introduz uma (como já vimos) que podem ser implementados em conjunto para
série de vantagens, em relação a outros (como o request- adicionar mais capacidades ao middleware.
response), que os middlewares que o utilizam podem potenciar.
Na tabela seguinte, podemos ver alguns dos principais
Desde logo porque os publishers são loosely-coupled em relação middlewares que implementam serviços baseados em publish-
aos subscribers, ou seja, não necessitam sequer de saber da sua subscribe e que estão disponíveis no mercado. (ver Tabela 1)
existência. Estando o foco direccionado para o evento, tanto os
subscribers como os publishers permanecem ignorantes
relativamente a topologia do sistema onde se encontram. Cada Tabela 1: Alguns Publish-Subscribe Middlewares. [8-13]
um deles pode operar independentemente do outro. Nome Linguagem Patrocínio Expressividade
Num paradigma request-response (dito tightly-coupled), o cliente BizTalk .NET Microsoft Content-based
não pode enviar mensagens enquanto o processo do servidor não ActiveMQ Java Apache Software (indefinido)
estiver a executar. Nem o servidor pode receber mensagens Foundation
enquanto o cliente não executar o pedido.
Tuxedo C,C++ e Oracle Content-based
Portanto, em publish-subscribe o sistema está desacoplado não COBOL Corporation
só a nível de sincronização, mas também a nível temporal e WebSphere MQ C, COBOL, IBM (indefinido)
espacial. [6] Perl e Java
Para sistemas de média escala, os paradigmas de publish- Data C,C++,C# e Object Topic-based
subscribe providenciam uma melhor escalabilidade do que os Distribution Java Management
Service Group
tradicionais request-response. Seja por operações paralelas,
caching de mensagens ou diferentes tipologias de routing.
No entanto, e à medida que os sistemas escalam para tornar-se Podemos então explorar mais em pormenor algumas das
datacenters com centenas de servidores partilhando a características desses middlewares. Nomeadamente do Data
infraestrutura publish-subscribe, estas grandes vantagens podem Distribution System, que é um standard muito conhecido para
tornar-se problemáticas. mecanismos publish-subscribe; o WebSphere MQ que é dos
mecanismos com mais tradição e mais utilizados actualmente a
nível de produção; o Tuxedo por ter sido recentemente adquirido
5. DESVANTAGENS por uma das empresas em maior expansão no mundo das novas
Os problemas mais sérios do publish-subscribe advêm dos tecnologias.
efeitos secundários de um dos seus trunfos: o facto da relação
6.1.1 Data Distribution System
entre publisher e subscriber ser loosely-coupled. [7]
O Data Distribution Service (DDS) surge fruto do consórcio
Por exemplo, quando uma aplicação necessita de uma garantia de entre os dois maiores impulsionadores do DDS: American Real-
entrega, (i.e., de que a mensagem é sempre entregue ou que caso Time Innovations e o French Thales Group. Ambas as
não seja possível confirmar a entrega, o publisher é informado) o instituições juntaram esforços no sentido de criar uma
sistema publish-subscribe em si, conceptualmente, não tem especificação única que, foi mais tarde aprovada pela Object
forma de providenciar essa certeza. Management Group2, resultando em 2003 no aparecimento da
As dificuldades em escalar, para sistemas de muito grande primeira versão do DDS.
dimensão, acabam também por traduzir-se em mais
desvantagens: 2
Também responsável por standards como UML e CORBA.

4. O DDS é uma especificação de publish-subscribe middleware envia, o Queue Manager armazena a mensagem até que o
para sistemas distribuídos, criado em resposta a necessidade de receptor a peça de novo.
standardização de modelos publish-subscribe em tempo real e A ordem de todas as mensagens é assim também preservada
centrados na troca de dados. através do uso de ordenação FIFO, para cada tipo de prioridade.
O middleware do DDS simplifica a programação de redes [11]
complexas, implementando um modelo de publish-subscribe
para envio e recepção de dados, eventos e comandos entre os
componentes. Componentes que estejam a produzir informação 6.1.3 Tuxedo
(publishers) criam tópicos (por exemplo, temperatura, O Tuxedo foi originalmente desenvolvido pela AT&T em 1983
localização, pressão) e publicam amostras. O DDS encarrega-se com o objectivo de criar e administrar sistemas de suporte a
então da entrega das amostras a todos os subscribers que operações e processamento de transacções online (OLTP). Após
declararam interesse no tópico respectivo. uma série de aquisições e fusões a empresa BEA Systems, na
O DDS trata de todos os aspectos necessários a entrega da altura detentora dos direitos do Tuxedo, acabou por ser adquirida
mensagem automaticamente, sem requerer qualquer intervenção pela Oracle em 2008.
por parte das aplicações do utilizador. Alguns desses aspectos O middleware Tuxedo foi desenhado desde o início para dar
prendem-se com: suporte a aplicações de alta disponibilidade e providenciar
mecanismos escaláveis que possibilitassem centenas de
transacções por segundo em sistemas distribuídos comuns.
determinar quem vai receber as mensagens
A sua base assenta fortemente no mecanismo de Bulletin Board
onde estão localizados os destinatários (BB) responsável pelo clustering do sistema. Este consiste num
o que acontece caso a mensagem não seja entregue segmento de memória partilhada que contêm o estado do
domínio gerido pelo Tuxedo. Servidores, serviços, transacções e
clientes estão todos registados no BB providenciando assim uma
O DDS permite que o utilizador especifique uma série de visão global do estado particular de cada um dos componentes.
parâmetros QoS3 de forma a configurar os mecanismos de
Para assegurar a manutenção desses dados existe um processo
descoberta automática de mensagens e especificar os
chamado Bulletin Board Liaison (BBL) que executa em cada um
comportamentos a ter quando envia e recebe as mesmas.
dos componentes de forma a manter a cópia central do BB
O DDS permite também executar automaticamente mecanismos sempre actualizada. [10]
de redundância entre os publishers, caso algum deles falhe.
Dessa forma garante-se que os subscribers recebem sempre uma
amostra dos dados cuja prioridade tenha sido configurada como
elevada e cujo período de validade não tenha ainda expirado. Isto 7. CONCLUSÃO
ocorre de forma transparente para o subscriber. [8] Decorrente do facto de assentar num mecanismo loosely-coupled,
o paradigma de Publish-Subscribe apresenta-se como a melhor
alternativa para comunicação entre sistemas que necessitem de
6.1.2 WebSphere MQ uma elevada escalabilidade. Proporcionando um desacoplamento
O WebSphere MQ (WMQ) representa a evolução do trabalho a nível de: sincronização, tempo e espaço.
desenvolvido pela IBM desde 1992 na primeira versão do seu No entanto, deve-se ter alguma reserva na sua utilização uma vez
MQSeries. que, dependendo da arquitectura pretendida e a utilização mais
intensiva do sistema, as suas características podem tornar-se
O middleware WMQ providencia a chamada one-time delivery de
mensagens entre uma larga variedade de plataformas. Este problemáticas. Originando instabilidade de throughput, IP
broadcast storms e lentidão na obtenção de resposta.
middleware enfatiza a segurança e robustez (através do uso de
logs) do tráfego de mensagens, para que nunca sejam dadas como Apesar de tudo, existe um grande suporte ao paradigma Publish-
perdidas num sistema bem configurado. Subscribe vindo de algumas das referências no mundo das novas
O agente principal de comunicação no WMQ é o Queue tecnologias: Oracle, IBM e Microsoft, são exemplos disso.
Manager. Este trata do armazenamento, temporização, triggering No futuro, fruto desse suporte, prevê-se então o aparecimento de
e todas as outras funções não relacionadas com o trajecto a mais e melhores middlewares que tirem partido das
percorrer pelos dados. características conceptuais do Publish-Subscribe, e se possível
O middleware WMQ providencia assim aos programadores um resolvam algumas das suas lacunas.
mecanismo para alcançar arquitecturas onde as mensagens são Prevê-se também a adopção consistente deste paradigma em
enviadas de uma aplicação para outra, sem que ambas aplicações direccionadas a dispositivos móveis, nomeadamente
necessitem de estar a executar ao mesmo tempo. Se uma para telemóveis. [1]
aplicação receptora não está a escuta, quando o remetente a
3
Quality of Service

5. [7] Publish-Subscribe
8. REFERÊNCIAS http://en.wikipedia.org/wiki/Publish/subscribe
4 de Dezembro 2009.
[1] Gianpaolo Cugola and Arno Jacobsen. Using
Publish/Subscribe Middleware for Mobile Systems. Mobile [8] Data Distribution Service
Computing and Communications Review, Volume 1, http://en.wikipedia.org/wiki/Data_Distribution_Service
Number 2.
4 de Dezembro 2009.
[2] Mohamed Mastouri and Salem Hasnaoui. Performance of a
Publish/Subscribe Middleware for the Real-Time [9] Apache ActiveMQ
Distributed Control systems. IJCSNS, VOL.7 No.1, Janeiro http://en.wikipedia.org/wiki/Apache_ActiveMQ
2007 4 de Dezembro 2009.
[3] Bogumil Zieba, Maurice Glandrup, Marten van Sinderen, [10] Tuxedo
Maarten Wegdam. Reconfiguration Service for
Publish/Subscribe Middleware. European Research http://en.wikipedia.org/wiki/Tuxedo_(software)
Programme. 4 de Dezembro 2009.
[4] Roman Szarowrski. Hybrid Publish-Subscribe: A [11] IBM WebSphere MQ
compromise approuch for large scale. Czech Technical
http://en.wikipedia.org/wiki/IBM_WebSphere_MQ
University in Prague.
4 de Dezembro 2009.
[5] Patrick Eugster, Rachid Guerraoui. Type-Based
Publish/Subscribe. Agilent Laboratories Scotland, [12] Microsoft BizTalk Server
Edinburgh. http://en.wikipedia.org/wiki/Microsoft_BizTalk_Server
[6] Patrick Eugster, Pascal Felber, Rachid Guerraoui. The many 4 de Dezembro 2009.
faces of Publish-Subscribe Middleware. ACM Computing
Surveys vol. 35 no. 2, 2003