Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS

Comunicação Distribuída – Middleware - JMS
Prof. Adriano Teixeira de Souza

 Método de comunicação entre componentes ou
aplicações
◦ ƒ Arquitetura peer-to-peer com serviço centralizado para
repasse de mensagens recebidas e enviadas
◦ ƒ Clientes e servidores enviam e recebem mensagens para
canais administrados por serviço central de mensagens
(MOM)
 Viabiliza comunicação distribuída com
acoplamento fraco
◦ ƒ Interface genérica: MOM ignora conteúdo e repassa
qualquer coisa. Formato do conteúdo deve ser conhecido
pelas partes
◦ ƒ Assíncrona: Comunicação pode ocorrer mesmo que o
cliente e servidor não estejam disponíveis ao mesmo tempo


 Sistemas de messaging são freqüentemente
chamados de Message-Oriented Middleware (MOM)
◦ ƒ Conceito não é novo: já existiam há algum tempo em
implementações proprietárias (e incompatíveis)
◦ ƒ JMS API: solução independente de fabricante para acessar
serviços MOM a partir de clientes Java

 Alguns produtos MOM compatíveis com JMS:
◦ ƒ Open source: JBossMQ, OpenJMS, JORAM
◦ ƒ IBM MQSeries, IPlanet MQ, Bea WebLogic, HP-MS, Progress
SoniqMQ
◦ ƒ Mais em: java.sun.com/products/jms/


 Escalabilidade
◦ Para aumentar a capacidade servidora, basta acrescentar
mais servidores (não é preciso mexer nos componentes)
◦ Novos clientes podem se conectar para usar mensagens em
outras aplicações
◦ Infraestrutura é reutilizada para novas aplicações

 Comunicação assíncrona
◦ ƒ Componentes podem realizar outras tarefas enquanto não
estão ocupados lidando com requisições
◦ Podem sondar o servidor em busca de novas mensagens
quando estiverem livres (PTP)
◦ Podem se cadastrar para, quando houver mensagens
novas, receber notificação (pub/sub)


 Desacoplamento
◦ ƒ Maior modularidade, maior reuso
(substituibilidade), maior simplicidade, maior robustez
(falhas localizadas)
◦ ƒ Papéis bem definidos simplificam o desenvolvimento:
produtor, consumidor e serviço tem única
interface, independente da aplicação
◦ ƒ Servidor de messaging é responsável pela qualidade do
serviço (não é preocupação dos componentes)

 Flexibilidade
◦ ƒ API definida pelo tipo das mensagens (e não por
interfaces)
◦ ƒ Meio comum é a mensagem: se componentes a
entendem, o resto (linguagens, plataformas, etc.) não
importa Prof. Adriano Teixeira de Souza

 Desvantagens
◦ ƒ Camada adicional para repasse de mensagens ƒ
◦ Centralização em único ponto introduz risco de falha de todo
o sistema caso o serviço de mensagens falhe
 Solução: replicação, clustering

 Desvantagens relativas
◦ Muito genérica: aplicações precisam decifrar as mensagens
para que possam operar; esconde a interface de programação
remota dentro das mensagens
◦ ƒ Comunicação assíncrona (geralmente): dificulta a criação de
aplicações que necessitam de comunicação síncrona.
◦ ƒ Não faz tratamento de representação de dados (data
marshalling) - MOM é apenas meio de transporte


 Mensagens são uma alternativa a invocação
de métodos remotos.

 A idéia é inserir uma camada entre o cliente e
o servidor
Invocação de método remoto

Aplicação Aplicação

Messaging
Message
Aplicação Middleware Aplicação


 Vantagens

◦ Processos não bloqueáveis

◦ Garantia de entrega

◦ Suporte a múltiplos emissores e receptores


 JMS é um padrão para Messaging

 Tem como objetivo eliminar muitas das
desvantagem que MOMs encontraram com o
passar dos anos

 O Desenvolvedor aprende a usar a API de JMS
e reusa seu código com diferentes
implementações plugáveis de MOM (idéia
similar APIs do JEE, como JNDI e JDBC)


 Publish/subscribe(pub/sub)

◦ Análogo a assistir televisão. Pode haver muitos
produtores de mensagens e muitos consumidores.

Produtor 1 Consumidor 1

Canal

Produtor 2 Consumidor 2


 Point-to-point(PTP)

◦ Múltiplos produtores podem enviar mensagens
para a fila mas cada mensagem é entregue a
apenas um consumidor

Produtor 1
Fila Consumidor 1

Produtor 2


 Passos
◦ 1. Localizar o provedor JMS, instancia de
ConnectionFactory
◦ 2. Criar um conexão JMS
◦ 3. Criar uma Sessão JMS
◦ 4. Localizar o destino
◦ 5. Criar um JMS Provider ou um JMS Consumer
◦ 6. Enviar ou Receber suas mensagens


2. Criar JMS Connection
conexão Factory
Fila1

3. Criar
JSM Connection
sessão
Fila2

Cliente 5. Criar
producer ou JMS Session
consumer Tópico1
1. Obter o
Driver JMS
6. Enviar ou
(ConnectionF JSM Prosucer ou Servidor JMS
receber
actory) Consumer
mensagens
4. Obter o
destino JMS Driver JMS do cliente

6. Enviar ou
receber
mensagens
JNDI

Serviço de nomes

public static void main (String[] args) throws Exception {
TransportConfiguration transportConfiguration =
new TransportConfiguration(NettyConnectorFactory.class.getName());

ConnectionFactory factory = (ConnectionFactory)
HornetQJMSClient.createConnectionFactoryWithoutHA(
JMSFactoryType.CF, transportConfiguration);
//O nome da queue deve ser o nome do jms-queue em standalone.xml
Queue queue = HornetQJMSClient.createQueue("testQueue");
Connection connection;
try {
connection = factory.createConnection();
Session session = connection.createSession(false,
QueueSession.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(queue);
TextMessage message = session.createTextMessage();
message.setText("Hello EJB3 MDB Queue!!!");
producer.send(message);
session.close();
connection.close();
} catch (JMSException e) {
e.printStackTrace();
}
}


 O que são?
◦ Introduzido na especificação EJB 2.0

◦ São componentes EJBs especiais capazes de
receber mensagens enviadas a filas e canais JMS

◦ Invocados pelo Container dada a chegada de um
mensagem ao destino que um MDB escuta
 Não se envia uma mensagem direto a um MDB(envia-se
ao canal que o bean escuta)
 Proporcionando acoplamento fraco entre cliente e MDB
(conhecimento do canal de comunicação)


◦ Para efetuar a comunicação é necessário o uso de
uma API específica, como JMS

Pool de MDBs

Cliente Destino JMS

Instancias de
Message-Driven
Beans


 Características
◦ Não possuem interface home, local
home, interface remota, nem interface local
◦ Possuem apenas um método que recebe qualquer
tipo de mensagem
◦ Não têm retorno, e também não lançam exceções
ao cliente
◦ São Stateless
◦ Podem ser ouvintes de uma fila, ou assinantes de
um canal(Topic)


 MDBs devem implementar a interface:
◦ javax.jms.MessageListener

 Método de MessageListener
◦ onMessage(Message m): chamado cada vez que uma
mensagem é enviada para o canal do bean (se o bean
estiver ativado).


@MessageDriven(name = "MessageMDBSample",
activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination",
propertyValue = "queue/test"),
})
public class MDBSample implements MessageListener {

public void onMessage(Message message) {

TextMessage tm = (TextMessage) message;

try {

System.out.println("Received message "+tm.getText());

} catch (Exception e) {
e.printStackTrace();
}

}
}


 Tipos de mensagens:

Tipo de Mensagem Estrutura de dados compatível

TextMessage java.lang.String

ObjectMessage objeto Java serializável

BytesMessage array de bytes

StreamMessage stream de tipos primitivos Java (int, double, char, etc.)

Conjunto de pares name-value. Os valores tem que ser tipos
MapMessage primitivos Java ou
seus encapsulamentos OO (wrappers), como Integer, Float,
etc.


Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS

Mais de Adriano Teixeira de Souza

Sistemas Distribuídos - Comunicacao Distribuida - Middleware - JMS