Changes to improve ease of development

Clarification of relationship between the JMS and other Java

EE specifications

EE specifications Definition of a new mandatory API to allow any JMS provider to

be integrated with any Java EE application server

be integrated with any Java EE application server Extensions to support Java EE 7

Other enhancements as requested by the community





@Resource(lookup = "jms/connectionFactory ")

ConnectionFactory connectionFactory;

@Resource(lookup="jms/inboundQueue")

Queue inboundQueue;

public void sendMessageOld (String payload) {

Connection connection = null;

try {

connection = connectionFactory.createConnection();

Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);

MessageProducer messageProducer = session.createProducer(inboundQueue);

TextMessage textMessage = session.createTextMessage(payload);

messageProducer.send(textMessage);

} catch (JMSException e) {

// do something

} finally {

try {

if (connection != null)

connection.close();

} catch (JMSException e2) {

// do something else

}

}

}

Multiple intermediate objects such as Connection ,

Session , and MessageProducer need to

be created in order to send a message. All these objects serve a

purpose but makes the JMS application more complicated. It also

leads to lots of boilerplate code as well.



The arguments to createSession are confusing.

The first argument specifies whether the session is transacted

or not. The second argument specifies, how, if you used the

session to receive messages, how those messages would be

acknowledged. These two arguments are not independent. If the

first argument is set to true then the second argument is

irrelevant. So we only need one argument here.







The other part is when this method is in a EJB then the

transactions are controlled by the container. Or if a

bean-managed transactions are used then the transaction would be

started and committed using the UserTransaction

API, not by methods in the JMS API. In fact, the EJB spec says

that if this code is running in a transaction then the arguments

to createSession are completely ignored. And even

then we are required to supply some arguments here to satisfy

the contract. The Connection need to explicitly closed in the

finally block in order to release the resources appropriately on

the server side. The code does not even show closing of MessageProducer

and Session and And the finally block gets ugly

with nested exceptions.



Java Message Service ( JSR

343 ) is undergoing a major revision as part of Java EE 7. The href="http://jcp.org/aboutJava/communityprocess/edr/jsr343/index.html">EarlyDraft of the specification has been available for a few weeksnow and href="http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/index.html">onlinejavadocs are now available. Several other specifications suchas href="http://jcp.org/aboutJava/communityprocess/edr/jsr338/index.html">JPA2.1, href="http://jcp.org/aboutJava/communityprocess/edr/jsr339/index.html">JAX-RS2.0, href="http://jcp.org/aboutJava/communityprocess/edr/jsr345/index.html">EJB3.2, href="http://jcp.org/aboutJava/communityprocess/edr/jsr344/">JavaServerFaces 2, and href="http://jcp.org/aboutJava/communityprocess/edr/jsr346/index.html">CDI1.1 in the Java EE 7 umbrella have released early drafts. Someof the specs have been explained in detailed:This blog will provide an update on href="http://jcp.org/aboutJava/communityprocess/edr/jsr343/index.html">JMS2.0 Early Draft.JMS 1.1 was released in href="http://www.jcp.org/en/jsr/detail?id=914">Dec 2003. A lothas chnged in the Java landscape since then - think aboutannotations, generics, auto-closeable, dependency injection, and alot more. The Java EE platform itself has evolved extensively sincethen, especially Java EE 6 is a "game changer". There are multipleJMS implementations still running solid and so there is lot ofdevelopment/deployment experience on that as well. Keeping all ofthat, and much more, in mind, the main goals of JMS 2.0 are:This blog will take a code sample from the section 11.4 of the href="http://jcp.org/aboutJava/communityprocess/edr/jsr343/index.html">EarlyDraft to highlight how ease-of-development changes are nowcoming to JMS 2.0.This is how a message is sent using the existing JMS API:This works very well but several issues with it:

Now lets take a look at how the new API will simplify the

programming model:







@Resource(lookup = "jms/connectionFactory")

ConnectionFactory connectionFactory;



@Resource(lookup="jms/inboundQueue")

Queue inboundQueue;



public void sendMessageNew (String payload) {

try (JMSContext context = connectionFactory.createContext();){

context.send(inboundQueue,payload);

}

}

All the boilerplate is gone. Instead just create a ConnectionFactory ,

create a context from it, and invoke send on it. The destinatation (inboundQueue) is now specified on send

insead of MessageProducer . Connection is now auto-closeable so try block

will close it autoamatically. New methods throw runtime exception so the code looks much

cleaner.



Simple, isn't it ?Here are the main changes:

And if you are using Dependency Injection, then the code can be

further simplified to:



@Inject

@JMSConnectionFactory("jms/connectionFactory")

private JMSContext context;



@Resource(mappedName = "jms/inboundQueue")

private Queue inboundQueue;



public void sendMessageNew(String payload) {

context.send(inboundQueue, payload);

}



No need for application to instantiate JMSContext

The same injected JMSContext is available in

other places, if within the same CDI scope





@Inject

@JMSConnectionFactory("jms/connectionFactory")

private JMSContext context;



@Resource(lookup="jms/inboundQueue")

Queue inboundQueue;



public String receiveMessageNew() {

JMSConsumer consumer = context.createConsumer(inboundQueue);

return consumer.receivePayload(String.class);

}

Some clean ups to note here are ...How cool is that ?Here is yet another example on how the simplified API receives amessage synchronously:The section 11.4 of the JMS 2.0 Early Draft provide more lot moresamples with the standard (or existing) API and the simplified (ornew) API.Do you like the direction that the JMS 2.0 Expert Group is taking ?Would you like to provide feedback and contribute ?The latest progress on JMS 2.0 can be tracked at:

Help us make JMS 2.0 better, simpler, easier to use. Join href="http://java.net/projects/jms-spec/lists/users/archive">users@jms-spec

and contribute!





