Message Oriented Middleware (MOM)

Transcrição

1 Message Oriented Middleware (MOM) November 1, 2009 Sumário Comunicação Assíncrona (MOM) Conceito Java Message Service Implementação

2 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. Sincronização na Comunicação Client Request Synchronize at request submission Synchronize at request delivery Transmission interrupt Storage facility Synchronize after processing by server Reply Server Time 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. No fim do processamento da mensagem pelo destinatário.

3 RPC Assíncrona Cliente bloqueia até pedido ser aceite Client Wait for result Client Wait for acceptance Call remote procedure Return from call Call remote procedure Return from call Request Reply Request Accept request Server Call local procedure and return results Time Server Call local procedure Time (a) (b) Pedido/resposta pode fazer uso de 2 RPCs assíncronas Client Wait for acceptance Interrupt client Server Call remote procedure Request Return from call Accept request Call local procedure Return results Acknowledge Time Call client with one-way RPC Message Oriented Middleware (MOM) 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.

4 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) 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 Mas precisam concordar no protocolo de troca de mensagens 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: ; SMS e MMS. Enterprise Integration Workflow applications.

5 (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.

6 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

7 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;

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

9 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

10 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 ] A arquitectura dos servidores de mensagens é muito semelhante à do serviço de na Internet. O serviço de 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.

11 Sumário Comunicação Assíncrona (MOM) Conceito Java Message Service Implementação 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)