Publish-Subscribe Middlewares

1,675
-1

Published on

Publish-Subscribe Middleware article for Distributed Systems course.

Published in: Education, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,675
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Publish-Subscribe Middlewares

  1. 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. 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. 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. 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. 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

×