Sumário Message Oriented Middleware (MOM) October 16, 2008 Comunicação Assíncrona (MOM) Conceito Java Message Service Implementação Comunicação Assíncrona Problema: Nem sempre as entidades comunicantes estão disponíveis simultaneamente. Por exemplo, o servidor de submissão pode estar inacessível ou indisponível quando vocês tentam submeter o vosso 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. Sincronização na Comunicação Client Synchronize at request submission Synchronize at request delivery Transmission interrupt Storage facility Reply Synchronize after processing by server A sincronização pode ocorrer em 1 de pelo menos 3 pontos: 1. No envio da mensagem pedido do lado do emissor. 2. Na recepção da mensagem pedido do lado do destinatário. 3. Na recepção da mensagem do lado do destinatário.
RPC Assíncrona Cliente bloqueia até pedido ser aceite Client Wait for result Client Wait for acceptance Message Oriented Middleware (MOM) A abstracção é muito semelhante à do serviço de correio: Reply Accept request Call local and return results (a) Call local Pedido/resposta pode fazer uso de 2 RPCs assíncronas Client Wait for acceptance Accept request Call local Interrupt client results Acknowledge Call client with one-way RPC (b) As propriedades do serviço podem variar: ordem; fiabilidade (persistência ou não); Talvez seja mais adequado dizer que a comunicação se faz via uma fila de mensagens (message-queueing systems). Alguns sistemas fornecem também uma abstracção semelhante à de foros de discussão (news groups): publishers podem enviar mensagens; subscribers podem receber mensagens. Sincronização em MOM Este tipo de comunicação é particularmente adequada quando as ligações entre o emissor e o receptor são fracas (loosely coupled); (a) (b) (c) (d) Aplicações de Comunicação Assíncrona 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. O emissor e o receptor não precisam estar a executar ao mesmo tempo. Mas precisam concordar no protocolo de troca de mensagens.
(Workflow s) Java Message Service (JMS) 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. 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 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. 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. Tópicos JMS (JMS Topics) 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 por diferentes consumidores duma sessão; efeito de prioridade, filtros (selectors), fiabilidade. O Que JMS Não Fornece 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). 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. Arquitectura Em sistemas mais sofisticados, pode usar-se message relays que se encarregam do encaminhamento das mensagens: Sending host Messaging interface Communication server Communication server Receiving host A Routing Buffer independent of communicating hosts To other (remote) communication server Routing Receive queue Send queue Message R2 Local buffer Local network Internetwork Local buffer Incoming message R1 Ao nível mais baixo a comunicação via mensagens exige sincronização entre emissor e receptor. Router 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 Broker Database with conversion rules Queuing layer Destination client [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. Network