JMS 2.0: Simplificação da API

As novidades do
Java Message Service 2.0
Bruno Borges
Java EE Evangelist, Product Manager


The following is intended to outline our general product direction. It is intended
for information purposes only, and may not be incorporated into any contract.
It is not a commitment to deliver any material, code, or functionality, and should
not be relied upon in making purchasing decisions. The development, release,
and timing of any features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.


JMS

 API java para enviar e receber mensagens
 Diversas implementações no mercado
 Duas variações distintas
– Aplicações Java SE
– Aplicações Java EE (web, EJB, client)
 suporta JTA e MDBs
 remove funcionalidades consideradas inapropriadas em um ambiente
de servidor de aplicação gerenciado


O que o JMS é e não é

 Uma API padronizada
– Não é um sistema de mensagens pronto para ser utilizado
– Não é um protocolo de comunicação
 Define somente uma API Java
– Não define uma API para clientes de outras linguagens (C++, HTTP, C#,
etc)
 Uma API para aplicações
– Não é (ainda) uma API para administrar, gerenciar ou monitorar


JMS 2.0

 JMS 1.1: última atualização em 2002
 JMS 2.0 proposto em 2011 pela JSR 343
– EG possui 20 membros:
 FuseSource, IBM, Oracle, Pramati, Red Hat, TIBCO
– Public Review aprovado em 18 de Fevereiro de 2013
 20 a favor, 4 abstenções
– Participação do SouJava
– Será lançado como parte do Java EE 7


 Simplicidade e facilidade de uso
 Novas funcionalidades de mensageria
Objetivos
 Melhor integração com o Java EE
JMS 2.0
– API c/ maior clareza de acordo com a
especificação
– Configuração simplificada de recursos
– Padronização de configuração de MDBs
– Melhor plugabilidade entre servidores de aplicação

 Pequenas correções
 Cloud / PaaS postergadas p/ Java EE 8


JMS 2.0:
Simplificação da API


Qual o problema da versão
1.1 da API?


JMS 1.1: Enviando uma mensagem
@Resource(lookup = "java:global/jms/demoConnectionFactory")
ConnectionFactory connectionFactory;

@Resource(lookup = "java:global/jms/demoQueue")
Queue demoQueue;

public void sendMessage(String payload) {
try {
Connection connection = connectionFactory.createConnection();
try {
Session session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
MessageProducer messageProducer = session.createProducer(demoQueue);
TextMessage textMessage = session.createTextMessage(payload);
messageProducer.send(textMessage); 13 linhas
} finally { de código
connection.close();
pra enviar
}
} catch (JMSException ex) { 1 msg
Logger.getLogger(getClass().getName()).log(Level.SEVERE, null, ex);
}
}


Simplificação da JMS 1.1 API
Estratégia

 Simplificar a API 1.1 existente sem quebrar compatibilidade
 Definir a nova API de forma mais simplificada exigindo poucos objetos
– JMSContext, JMSProducer, JMSConsumer
 No Java EE, permitir que o JMSContext seja injetado e gerenciado
pelo container


API mais simples para criar uma Session

 Precisa manter compatibilidade e limitar escopo de mudanças
 Novos métodos javax.jms.Connection para criar Session:
– Método atual (será mantido)
connection.createSession(transacted,deliveryMode)
– Novo método (para usar em ambiente Java SE)
connection.createSession(sessionMode)
– Novo método (para usar em ambiente Java EE)
connection.createSession()



connection.createSession(transacted,sessionMode)
 Java EE
– com JTA: argumentos são ignorados. Sessão participa da tx
– sem JTA: ‘transacted’ é ignorado, sempre local-tx.
‘sessionMode’ é propcessado (AUTO_ACK ou DUPS_OK)
 Java SE
– ‘transacted’ = true: sessão usa local-tx. ‘sessionMode’ é ignorado
– ‘transacted’ = false: sessão non-tx. ‘sessionMode’ será lido e interpretado
de acordo com a documentação



connection.createSession(sessionMode)
 Java EE
– com JTA: ‘sessionMode’ é ignorado
– sem JTA: sessão non-tx. ‘sessionMode’ = AUTO ou DUPS_OK
 Java SE
– ‘sessionMode’ = SESSION_TRANSACTED: possui local-tx
– ‘sessionMode’ = CLIENT, AUTO, DUPS_OK: non-tx, mensagens será ACK
pelo modo definido.


API simplificada para criar uma Session

connection.createSession()
 Java EE
– com JTA: participate da TX
– sem JTA: sessão non-tx. AUTO_ACK é usado
 Java SE
– Sessão non-tx. AUTO_ACK é usado


API simplificada para fechar os objetos JMS

 Definir objetos JMS como java.jang.AutoCloseable
– Connection
– Session
– MessageProducer
– MessageConsumer
– QueueBrowser

 Requer Java SE 7


API simplificada para fechar os objetos JMS
@Resource(lookup = "jms/connFactory") Fecha recursos
ConnectionFactory cf;
 Make JMS objects implement java.jang.AutoCloseable
dentro do bloco
@Resource(lookup="jms/inboundQueue") try-with-resources
– Connection, Session, MessageProducer, MessageConsumer,
Destination dest;
QueueBrowser
public void sendMessage (String payload) throws JMSException {
try ( Connection conn = connectionFactory.createConnection();
Session session = conn.createSession();
MessageProducer producer = session.createProducer(dest);
){
Message mess = sess.createTextMessage(payload);
producer.send(mess); close() é chamado
} catch(JMSException e){ automaticamente
// exception handling no final do bloco
}
}

Nova API simplificada para o JMS 2.0
Introdução ao JMSContext e JMSProducer

@Resource(lookup = "java:global/jms/demoConnectionFactory")
ConnectionFactory connectionFactory;

@Resource(lookup = "java:global/jms/demoQueue") 13 linhas
Queue demoQueue; reduzido
para 5
public void sendMessageNew(String payload) {
try (JMSContext context = connectionFactory.createContext();){
context.createProducer().send(demoQueue, payload);
} catch (JMSRuntimeException ex) {
Logger.getLogger(getClass().getName()).log(Level.SEVERE, null, ex);
}
}


JMSContext (1/2)

 Novo objeto que encapsula Connection, Session e MessageProducer

 Criado através de um ConnectionFactory
JMSContext context = connectionFactory.createContext(sessionMode);

 Chamar close() depois de usar, ou colocar em um bloco try-with-
resources
 Pode ser injetado (numa aplicação EJB ou Java EE Web)


JMSContext (2/2)

 Pode ser criado a partir de outro JMSContext
(para reutilizar conexão – Java SE somente)
JMSContext context2 = context1.createContext(sessionMode);

 Usado para criar objetos JMSProducer
 Usado para criar JMSConsumer
 Métodos do JMSContext, JMSProducer e JMSConsumer só disparam
unchecked exceptions


JMSProducer

 JMS 1.1
MessageProducer producer = session.createProducer();
producer.send(destination,message);

 JMS 2.0
JMSProducer producer = context.createProducer();


JMSProducer
Configuração de delivery com Fluent API ou method chaining

 JMS 1.1

producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
producer.setPriority(1);
producer.setTimeToLive(1000);

 JMS 2.0

context.createProducer().setDeliveryMode(DeliveryMode.NON_PERSISTENT).
setPriority(1).setTimeToLive(1000).send(destination,message);


JMSProducer
Configuração de headers e propriedades de mensagens

 JMS 1.1

TextMessage textMessage = session.createTextMessage("Hello);
textMessage.setStringProperty("foo","bar");

 JMS 2.0

context.createProducer().setProperty("foo","bar").send(destination,"Hello");


JMSProducer
Envio de mensagens diretas

 Métodos do JMSProducer para enviar a Message
– send(Destination dest, Message message)
 Não precisa criar um Message
– send(Destination dest, Map<String,Object> payload)
– send(Destination dest, Serializable payload)
– send(Destination dest, String payload)
– send(Destination dest, byte[] payload)


JMSConsumer

 Mensagens são consumidas criando um objeto JMSConsumer
– Encapsula um MessageConsumer
– Funcionalidade e API similar do MessageConsumer
 Synchronous
JMSConsumer consumer = context.createConsumer(destination);
Message message = consumer.receive(1000);

 Asynchronous
JMSConsumer consumer = context.createConsumer(destination);
consumer.setMessageListener(messageListener);

 Connection is automatically started (configurable)

JMSConsumer
Recebendo conteúdo de mensagens diretamente

 Métodos do JMSConsumer que retornam a Message
– Message receive();
– Message receive(long timeout);
– Message receiveNoWait();

 Métodos do JMSConsumer que retornam o conteúdo da mensagem
diretamente
– <T> T receivePayload(Class<T> c);
– <T> T receivePayload(Class<T> c, long timeout);
– <T> T receivePayloadNoWait(Class<T> c);


JMSConsumer
Recebendo conteúdo de mensagens diretamente

public String receiveMessage() throws NamingException {
InitialContext initialContext = getInitialContext();
ConnectionFactory connectionFactory =
(ConnectionFactory) initialContext.lookup("jms/connectionFactory");
Queue inboundQueue = (Queue)initialContext.lookup("jms/inboundQueue");

try (JMSContext context = connectionFactory.createContext();) {
JMSConsumer consumer = context.createConsumer(inboundQueue);
return consumer.receivePayload(String.class);
}
}


Injeção de objetos JMSContext
Em um container EJB ou Java EE Web

@Inject
@JMSConnectionFactory("jms/connectionFactory")
private JMSContext context;

@Resource(mappedName = "jms/inboundQueue")
private Queue inboundQueue;

public void sendMessage (String payload) {
context.createProducer().send(inboundQueue, payload);
}


Use @Inject
para injetar o
@Inject JMSContext,
@JMSConnectionFactory("jms/connectionFactory") especificando
private JMSContext context; connection
factory
@Resource(mappedName = "jms/inboundQueue")

public void sendMessage (String payload) {
context.createProducer().send(inboundQueue, payload);
}

Container se
responsabiliza em
fechar o objeto



 Connection factory padrão do container
@Inject private JMSContext context;

 Com definição de Session Mode
@Inject
@JMSSessionMode(JMSContext.AUTO_ACKNOWLEDGE)

 Com definição de user e password
@Inject
@JMSPasswordCredential(userName="admin",password="mypassword")


 Objetos JMSContext injetados possuem escopo
– Com JTA transaction, escopo é a transação
– Sem JTA transaction, escopo é o request
 JMSContext é automaticamente fechado quando o escopo termina
 Injete dois objetos JMSContext com mesmo escopo e terá o mesmo
objeto
– se valores de @JMSConnectionFactory, @JMSPasswordCredential e
@JMSSessionMode são idênticos
– Torna mais fácil usar a mesma sessão dentro de uma transação


JMS 2.0:
Novas features da API


Mais fácil criar Durable Subscribers

 Durable subscriptions são identificados por
{clientId, subscriptionName}
 ClientId não é mais obrigatório quando usar durable subscriptions
 Para MDBs, o container vai gerar um nome padrão (EJB 3.2)


Delivery delay

 Permite um cliente JMS agendar entrega futura de mensagem
 Novo método no MessageProducer
public void setDeliveryDelay(long deliveryDelay)

 Novo método no JMSProducer

public JMSProducer setDeliveryDelay(long deliveryDelay)

 Configure tempo minimo em ms para quem uma mensagem deve ser
retida no sistema até ser enviada


Envio Assíncrono

 Envia uma mensagem e retorna imediatamente sem bloquear até o
ACK de que foi recebida pelo servidor
 Uso de callback quando tiver o ACK do servidor
 Novo método do MessageProducer

messageProducer.send(message,completionListener)

 Disponível também no JMSProducer


Envio Assíncrono

 Aplicação define um CompletionListener

public interface CompletionListener {
void onCompletion(Message message);
void onException(Message message, Exception exception);
}


Melhor tratamento de mensagens ruins
Torna a propriedade JMSMXDeliveryCount obrigatória

 JMS 1.1 define uma propriedade de mensagem opcional
JMSXDeliveryCount.
– Quando usado, é setado pelo provedor JMS quando a mensagem é
recebida, e indica o número de vezes que esta mensagem foi entrege
(incluindo a primeira vez).
 JMS 2.0 torna esta propriedade obrigatória pelas implementações


Múltiplos consumidores numa subscrição de
tópico
 Permite consumo escalável de mensagems a partir de um Topic
Subscription
– Múltiplas threads, multiplas JVMs
 Novos métodos para non-durable subscriptions
MessageConsumer messageConsumer=
session.createSharedConsumer(topic,sharedSubscriptionName);

 Métodos existentes para durable subscriptions
MessageConsumer messageConsumer=
session.createDurableConsumer(topic,durableSubscriptionName);

 Disponível também no JMSContext

Definição de recursos JMS
simplificada no Java EE

Em conjunto com
JSR 342 (Java EE 7 platform)


Definição de recursos JMS simplificada no Java
EE
O problema

 Java EE e JMS recomenda que aplicações devem obter o
ConnectionFactory e a Destination via JNDI
@Resource(lookupName = "jms/inboundQueue")

 Mantém o código portável
 Criar estes recursos é um incômodo para os desenvolvedores


Connection Factory default na plataforma
Simplifica o uso de JMS na maioria dos casos

 Se você quiser somente usar o serviço JMS do servidor de aplicação

@Resource(lookup="java:comp/defaultJMSConnectionFactory")
ConnectionFactory myJMScf;


Definição de recursos JMS simplificada no Java EE
Funções novas e opcionais no Java EE 7

 Aplicação pode especificar os JMS connection factories e JMS
destinations que precisa via anotações
 Deployer pode então definir requerimentos com os deployment
descriptors
 Servidor de aplicação pode usar esta informação para criar
automaticamente os recursos quando a aplicação for instalada
 Equivalente às anotações referentes a @DataSourceDefinition
 É opcional suportar estes recursos


Uso de anotações para definir recursos

@JMSConnectionFactoryDefinition(
name="java:global/jms/demoConnectionFactory",
className= "javax.jms.ConnectionFactory",
description="ConnectionFactory to use in demonstration")

@JMSDestinationDefinition(
name = "java:global/jms/demoQueue",
description = "Queue to use in demonstration",
className = "javax.jms.Queue",
destinationName="demoQueue")


Deployer configura informações específicas posteriormente
<jms-destination>
<name>"java:global/jms/demoQueue</name>
<class-name>javax.jms.Queue</class-name>
<resource-adapter-name>jmsra</resource-adapter-name>
<destination-name>demoQueue</destination-name>
</jms-destination>

<jms-connection-factory>
<name>java:global/jms/demoConnectionFactory</name> Pode definir
<property> propriedades
<name>addressList</name> específicas
<value>mq://localhost:7676</value> do provedor
JMS
</property>
<max-pool-size>30</max-pool-size>
<min-pool-size>20</min-pool-size>
<max-idle-time>5</max-idle-time>
</jms-connection-factory>

Configuração padronizada
de MDBs

Em conjunto com
JSR 345 (EJB 3.2)


Configuração padronizada de MDBs

 Configuração de MDBs não é padronizada
 EJB 3.1 não define como especificar
– Nome JNDI da queue or topic (usando annotation)
– Nome JNDI da connection factory
– clientID
– durableSubscriptionName
 EJB 3.1 não define como que mensagens de tópicos devem ser
entregues para MDBs clusterizados


Novas propriedades de ativação para Queue ou Topic

@MessageDriven(activationConfig = {
@ActivationConfigProperty(
propertyName = "destinationLookup",
propertyValue = "jms/myTopic"),
. . .
})

 Também pode ser definido no ejb-jar.xml



propertyName = "connectionFactoryLookup",
propertyValue = "jms/myCF"),
. . .
})

 Também pode ser definido no ejb-jar.xml



propertyName = "subscriptionDurability",
propertyValue = "Durable"),
propertyName = "clientId",
propertyValue = "myClientID"),
propertyName = "subscriptionName",
propertyValue = "MySub"),
. . .
})

 Estas propriedades nunca tinham sido padronizadas


Topic delivery para MDBs em cluster
Uma mensagem por instância ou uma por cluster?

Topic

?
MDB MDB MDB MDB MDB MDB MDB MDB MDB

Application server instance Application server instance Application server instance

Application server cluster

Topic delivery para MDBs em cluster

 Se subscriptionName e clientId não estão definidos
– cada mensagem será entregue uma vez, por cluster
– instâncias do cluster compartilharão o mesmo nome de subscrição
 Para desligar configure sharedSubscriptions para false
– cada mensagem será entregue uma por instância de MDB
– cada instância do servidor de aplicação terá uma subscription separada
 Aplica-se a durable e non-durable subscriptions


Melhor plugabilidade com
Java EE


Melhor plugabilidade com Java EE

 Objetivo
– Facilitar o uso de um provedor JMS em outros servidores de aplicação
– e.g. aplicação GlassFish enviando mensagens para o WebLogic JMS
 Solução
– Obrigar provedores JMS a oferecer um adaptador JCA


Melhor plugabilidade com Java EE
usando a especificação Java Connector Architecture (JCA)

 Java Connector Architecture é desenhado para:
– Integrar recursos transacionais com o servidor de aplicação
– processamento assíncrono de MDBs
 Suporte ao JCA é obrigatório no Java EE
 Muitos vendors de JMS vendors já oferecem adaptadores
 JMS 2.0 obriga o provisionamento de adaptador JCA
 Deve ser transparente para as aplicações!


 Simplicidade e facilidade de uso
 Novas features
Novidades – multi-threaded Topic Subscribers
do JMS 2.0 – delivery delay
– envio async

 Melhor integração com Java EE
– configuração de recursos simplificada
– Padronização na configuração de MDBs
– melhor plugabilidade entre servidores de aplicação

 Muitas outras melhorias e correções


Experimente o Java EE 7
JMS 2.0, EJB 3.2 and Java EE

 GlassFish 4.0
– http://glassfish.java.net/
– http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/
 Open Message Queue 5.0
– http://mq.java.net/
– http://mq.java.net/5.0.html


Perguntas?


Graphic Section Divider


JMS 2.0: Simplificação da API

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a JMS 2.0: Simplificação da API

Semelhante a JMS 2.0: Simplificação da API (20)

Mais de Bruno Borges

Mais de Bruno Borges (20)

JMS 2.0: Simplificação da API