Message Oriented Middleware (MOM) March 24, 2010 Comunicação Assíncrona Problema: Nem sempre as entidades comunicantes estão disponíveis simultaneamente. Por exemplo, um servidor de submissão pode estar inacessível ou indisponível quando vocês tentam submeter um trabalho. Quer sockets quer RPC ou RMI exigem que as entidades comunicantes sincronizem para que a troca de informação se realize. Solução: Usar mecanismos para comunicação assíncrona/diferida (asynchronous communication): As entidades comunicantes não precisam estar activas simultaneamente.
Comunicação via Mensagens: Aspectos Client Request request submission request delivery Transmission interrupt Storage facility Synchronize after processing by server Reply Server Time 1. Persistência vs. Transitoriedade 2. Sincronização com o serviço de comunicação 3. Assincronia vs. Sincronia Sincronização entre entidades comunicantes. Comunicação via Mensagens: Persistência vs... Client request submission request delivery Synchronize after processing by server Request Transmission interrupt Storage facility Reply Server Time Comunicação Transitória O serviço de comunicação pode descartar uma mensagem em trânsito se surgirem problemas na sua entrega para o nó seguinte (pode ou não ser o destino final). Exemplo: TCP/UDP. Comunicação Permanente O serviço de comunicação mantém a mensagem até ser entregue, mesmo que surjam problemas na sua entrega. Exemplo: SMTP.
Comunicação via Mensagens: Sincronização Client request submission request delivery Synchronize after processing by server Request Transmission interrupt Storage facility Reply Server Time O emissor pode sincronizar em pelo menos 3 pontos: 1. Quando submete a mensagem ao serviço de comunicação. Exemplo? 2. Quando o serviço de comunicação entrega a mensagem ao destinatário. 3. Após recepção de mensagem enviada pelo destinatário. Exemplo? Comunicação via Mensagens: Assincronia vs.... Sender running Sender running Sender passive Sender passive Receiver running Receiver passive Receiver running Receiver passive (a) (b) (c) (d) O emissor e o receptor não precisam de executar simultaneamente
Message Oriented Middleware (MOM) Comunicação assíncrona e persistente com mensagens. Processos não precisam de sincronizar entre si quando enviam mensagens. O serviço de comunicação (middleware) mantém as mensagens o tempo necessário para as entregar. A abstracção é muito semelhante à do serviço de correio: As propriedades do serviço podem variar: ordem; fiabilidade (persistência ou não); Alguns sistemas fornecem também uma abstracção semelhante à de foros de discussão (news groups): publishers podem enviar mensagens; subscribers podem receber mensagens. Aplicações de Comunicação Assíncrona Este tipo de comunicação é particularmente adequada quando as ligações entre o emissor e o receptor são fracas (loosely coupled) Aplicação de submissão de documentos: Permite mascarar avarias: O submissor não precisa tentar de novo, se o servidor não estiver acessível ou disponível o próprio serviço de mensagens se encarrega disso. Comunicação via mensagens: Email; SMS e MMS. Enterprise Integration Workflow applications.
(Workflow s) Este tipo de aplicações está ligado à automatização de processos de negócio: por exemplo, o processamento de pedidos de empréstimo num banco. Um processo de negócio pode ser decomposto em actividades cuja execução depende: de outras actividades desse processo; de eventos externos (que podem ser gerados por outros processos). As diferentes actividades podem ser executadas por aplicações independentes. A comunicação entre actividades pode ser feita via MOM: A actividade receptora pode não existir porque as condições necessárias para a sua execução podem ainda não estar reunidas. Java Message Service (JMS) JMS é uma API da J2EE da Sun: permite que aplicações em Java acedam duma forma portável a serviços de mensagens assíncronas, i.e. a MOM. JMS dá uma ideia de funcionalidades fornecidas por MOM que podem ser úteis no desenvolvimento de aplicações empresariais. JMS pode beneficiar bastante do Java Transaction Service: Falaremos em transacções mais para diante.
Arquitectura e Modelo de JMS JMS define 2 componentes fundamentais: JMS Provider, i.e. um sistema MOM; JMS Client, i.e. uma aplicação que envia/lê mensagens para/de um destinatário (destination) através do JMS provider. Para usar o serviço JMS, um cliente tem que primeiro estabelecer uma conexão (connection) ao provider. Clientes enviam/recebem mensagens para/de um destinatário no contexto duma sessão(session). Sessões (normalmente) são criadas no contexto duma conexão. Modelo de JMS Source: Sun
Destinatários e Mensagens JMS define 2 tipos de destinatários(destinations): Queues, semelhantes a caixas de correio; Topics, semelhantes a news groups, i.e. permitem que as mensagens sejam lidas por vários assinantes (subscribers). Mensagens em JMS têm 3 partes: header: contêm campos necessários pelos clientes e pelos providers para identificar e encaminhar mensagens; properties: são campos opcionais, que logicamente fazem parte do header i.e. são meta-data. body: a informação a enviar. JMS suporta diferentes tipos de informação. Algumas Questões Fiabilidade Mensagens (cujo modo de entrega é) PERSISTENT são entregues uma e uma só vez ao destino. Mensagens NON_PERSISTENT garantem uma semântica at-most-once Acknowledgement: há vários comportamentos incluindo: AUTO_ACKNOWLEDGE: métodos da interface confirmam a recepção automáticamente, quando apropriado. CLIENT_ACKNOWLEDGE: permite o cliente confirme a recepção de várias mensagens através da invocação do método acknowledge. Ordem: mensagens enviadas para o mesmo destino através duma sessão; mensagens lidas (possivelmente por diferentes consumidores) duma sessão; efeito de prioridade, filtros (selectors), fiabilidade.
Tópicos JMS (JMS Topics) Assincronismo das assinaturas e publicações (publishing): uma mensagem enviada depois duma assinatura pode não ser entregue; uma mensagem enviada antes duma assinatura pode ser entregue. Assinaturas podem ser ou não duráveis: Mensagens do tipo PERSISTENT são garantidamente entregues a um cliente que fez uma assinatura durável. Clientes com assinaturas não duráveis podem perder mensagens do tipo PERSISTENT (em princípio, só se estiverem inactivos). O Que JMS Não Fornece Um serviço: JMS é uma API. A implementação da Sun de J2EE actualmente oferece um JMS provider. Não suporta: Replicação de clientes (para tolerância a avarias ou distribuição da carga, p.ex.). Notificação de erros/avisos. Administração do JMS provider. Segurança i.e. não fornece uma API para controlar aspectos relativos à segurança das mensagens enviadas.
Implementação dum Serviço de Mensagens Comunicação assíncrona é feita recorrendo a um serviço de mensagens. Messaging interface Sending host Communication server Communication server Receiving host Routing program Buffer independent of communicating hosts Routing program To other (remote) communication server Local buffer Local network Internetwork Local buffer Incoming message Ao nível mais baixo a comunicação via mensagens exige sincronização entre emissor e receptor. Arquitectura Em sistemas mais sofisticados, pode usar-se message relays que se encarregam do encaminhamento das mensagens: Sender A Receive queue Send queue Message R2 R1 Router Receiver B
Message Brokers MOM é usada para interligar aplicações, cujas entradas e saídas podem ter sintaxe e semântica diferentes. Muitas vezes, essas aplicações foram desenvolvidas independentemente. Message brokers são aplicações que permitem converter o formato das mensagens. Não fazem parte do sistema de mensagens. Source client Message broker Database with conversion rules Destination client Broker program Queuing layer Network [MOM e Email] A arquitectura dos servidores de mensagens é muito semelhante à do serviço de email na Internet. O serviço de email da Internet pode ser usado em muitas aplicações que precisam dum serviço de mensagens simples: SOAP, um protocolo para comunicação para WebServices, especificado pelo W3C, pode usar quer HTTP quer SMTP como protocolo de transporte. Há quem advogue o uso de SOAP/SMTP como MOM para a Internet. O uso de XML facilita o desenvolvimento de message brokers.
Leitura Adicional Secção 4.3 de Tanenbaum e van Steen, Distributed Systems, 2nd Ed. Java Message Service (JMS) Specification (v 1.1) Java Message Service Tutorial, da Sun (Secções 1, 2 e 3) Enterprise Integration Patterns: Introduction to Messaging Systems (para explorar)