2. 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
Prof. Adriano Teixeira de Souza
3. 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/
Prof. Adriano Teixeira de Souza
4. 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)
Prof. Adriano Teixeira de Souza
5. 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
6. 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
Prof. Adriano Teixeira de Souza
7. 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
Prof. Adriano Teixeira de Souza
8. Vantagens
◦ Processos não bloqueáveis
◦ Garantia de entrega
◦ Suporte a múltiplos emissores e receptores
Prof. Adriano Teixeira de Souza
9. 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)
Prof. Adriano Teixeira de Souza
10. 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
Prof. Adriano Teixeira de Souza
11. 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
Prof. Adriano Teixeira de Souza
12. 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
Prof. Adriano Teixeira de Souza
13. 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
Prof. Adriano Teixeira de Souza
14. 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();
}
}
Prof. Adriano Teixeira de Souza
15. 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)
Prof. Adriano Teixeira de Souza
16. ◦ 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
Prof. Adriano Teixeira de Souza
17. 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)
Prof. Adriano Teixeira de Souza
18. 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).
Prof. Adriano Teixeira de Souza
20. 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.
Prof. Adriano Teixeira de Souza