Talk presented by Nick Wright - C2B2 Senior Consultant - at Devoxx on the 14th of November 2012. In this quickie talk Nick discussed the motivations for undertaking JSR343 Java Message Service 2.0 (the longest awaited update for JEE7!), it's current status as we head into public review and the future directions we expect to take.

2. JMS 2.0 Update
Your Logo Here
Nick Wright
Senior Consultant
C2B2
@nwrightesq
@c2b2consulting

3. Before we begin...
A brief disclaimer
■ Everything being presented is based on the draft spec as it stands and
discussions with the EG / community
■ Don’t write code against these slides! It will change!
■ Wonderful. Let’s resume.
@nwrightesq
3

4. Briefly about me...
Why am I here?
■ Started off as an embedded C engineer (so I actually know what a function
pointer is)
■ Worked with Java since 2001, JEE since 2006
■ Now I work around the world, primarily with JEE technologies
■ I’m on the JMS 2.0 expert group. Just got back from presenting with Spec
lead, Nigel Deakin, at JavaOne
■ I’m not a JMS vendor - I have my own thoughts and feelings on where JSR
343 should go...
■ Nick enjoys Belgian beer (probably better than UK Real Ale), being bad at
Kung Fu
@nwrightesq4

5. Java Message Service
■ The Java Message Service JSR defines an API for interacting with Java
messaging systems (JavaSE or JavaEE)
We already have one. Why are you doing this?
■ JMS 1.1 April 2002 Header Body
■ No updates since... Queue
Queue
Connection
Connection
Message
■ (Picture not fully reflective Queue
of spec features)
P2P
Session
Session JMS 1.1
Topic Session Pub/Sub
Topic
Connection
Pub/Sub
■ What happens to a specification under these conditions?
@nwrightesq
5

6. JMS 1.1
Magic More Body
Properties Types
Header Body
Queue
Queue
Connection Monitoing
Connection Message
Queue Management
P2P JMX
Session
Session JMS 1.1
Topic Session Pub/Sub
Topic
Connection
Pub/Sub
Over time vendors implement extra features. This is a Good Thing™
@nwrightesq
6

7. JMS 1.1 (Cell Division?)
Magic More Body
Properties Types
and more...
Header Body
and more...
Queue AMQP
Queue
Connection Message Message
Connection Batching
Monitoing
Queue
P2P
Session
JMS 1.1 JMX
Session
Management
Topic Session Pub/Sub
Cloud/WAN Clustering/
Topic support Failover
Connection
Pub/Sub
Virtual Topics
and more...
End result: Lots of features, but we move away from portability
across vendors.
@nwrightesq
7

8. What’re the goals for JMS 2.0?
A cross between...
■ Rationalising based on EG & community proposed advances in the JMS space
■ Aligning with the goals of JEE7
From Arun Gupta’s Technical Keynote at JavaOne
■ Revised Scope of JavaEE7
■ Higher Productivity – Less Boilerplate – Richer Functionality – More Defaults
■ ... other things of course
■ Simpler API, clarifications
■ Easier to manage EE integration
■ Adopted features
■ Evolution not Revolution...
@nwrightesq
8

9. I’m new to this. What’s JavaEE7?
JavaEE7 Overview (http://glassfish.java.net/javaone2012/JavaEE_Technical_Keynote.pdf)
JMS 2.0 fits in with the JSR 343 Roadmap (http://java.net/projects/jms-spec)
When can I have it? | Goodness me, when must I start thinking of making my JMS implementation compliant?
09 Dec 2012 Submission of Public Review Draft to the JCP 20 Mar 2013 Submission of Materials for Final Ballot to the JCP
03 Jan 2013 Start of Public Review 26 Mar 2013 Start of Final Ballot
04 Feb 2013 End of Public Review 08 Apr 2013 Completion of Final Ballot
18 Feb 2013 Completion of JCP Public Review Ballot 15 Apr 2013 Release of Spec, RI, TCK
20 Feb 2013 Submission of Proposed Final Draft to the JCP @nwrightesq

10. Goals: Simpler API
New Objects! New Powers!
■ JMSContext/Producer/Consumer
■ These give you Method Chaining, Throw Unchecked Exceptions only...
■ JMSProducer does not encapsulate a MessageProducer, more lightweight
■ Autoclosable (JDK 7+ only) Text
Text
■ To be used in SE and EE, fully functional natural replacement for 1.1 API
■ Default connection.createSession(transacted,deliveryMode) is now
connection.createSession(), options remain
■ Old MessageProducer/Consumer retained for compatibility with 1.1
implementations
@nwrightesq
10

11. Goals: Simpler API
New Objects! New Powers!
■ JMSContext/Producer/Consumer
JMSContext
■ Wraps Connection & Session (& an anonymous MP) JMSConsumer
■ Injectable via CDI Text
Text
■ Sync/async message consumption... (receiveX() or
listeners)
■ Makes use of NEW defaults!
■ Can receive the message OR the payload directly...
<T> T receiveBody(Class<T> c);
JMSProducer ■ Connection.start() now called automatically, this is
■ Can now have options/properties/headers set that all configurable... (if you’ve ever asked ‘where are my
sent messages will use (was per-message level messages!!?’)
previously)
■ Can send payloads directly (no need for a message
object)
@nwrightesq 11

12. JMS 1.1 API; 13 lines = send a message
@Resource(lookup = "myConnectionFactory”)
ConnectionFactory connectionFactory;
App Server Config
@Resource(lookup = "myQueue”)
Queue myQueue;
public void sendMessage (String payload) {
Connection connection = null;
try {
connection = connectionFactory.createConnection();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer messageProducer = session.createProducer(myQueue);
Lots of Boilerplate!
TextMessage textMessage = session.createTextMessage(payload);
messageProducer.send(textMessage);
} catch (JMSException ex) {
//. . .
} finally {
if (connection != null) {
try {
connection.close();
Error Handling
} catch (JMSException ex) {
//. . .
}
}
}
}
@nwrightesq12

13. JMS 2.0 API; Greater burger:bun
@Inject
JMSContext context; Uses Default resource definition, alternatively
@Resource(lookup = "myQueue”) add a @JMSConnectionFactory
Queue myQueue;
public void sendMessage (String payload) {
}
context.createProducer().send(myQueue, payload); ~18 lines to one. ONE!
~18 lines to five with
Autoclose try/catch
Similar for receiving
messages with
JMSConsumer
@nwrightesq
13

14. Goals: JavaEE specific highlights
All aimed at making it simpler. More defaults, less config.
■ How do I get in?!
■ There's a standard, cross platform OOTB reference to the app server's default JMS connection factory.
■ Deployer configs can tailor a JMS resource via annotation or xml (incl non standard property elements)
■ How do I fire my beans?
■ Stronger definition of MDB association to JMS resources via activationConfig =
{@ActivationConfigProperty...}, ejb-jar.xml (expect this to be tidied up more in future!)
■ Clustered Topic MDB Delivery, subscriptions, client-ids, etc locked down a bit more (client ids not required /
autogenerated in EE, subs naming rules)
■ How do I do cross-vendor messaging?
■ A JCA RA for JMS is now mandatory (many vendors provide one, but not all are quite tck compliant)
■ About time :) @nwrightesq 14

15. Got it. New API, JEE things. What else?
Topiqueues! Queueipics! (??!)
■ Durable and Non Durable Subscriptions can now be shared
■ More parallelisation (threads, JVMs, etc)
■ Seen elsewhere (Virtual Topics in ActiveMQ)
.. not now, but soon!
■ Delivery Delay
■ The minimum time after delivery delivery can occur - now explicitly included in the API
More power Scotty!
■ Async Send
■ Message/JMS producers now specify a non blocking send. Send and move on.
■ Producers now accept a callback method and an exception handler for responses
@nwrightesq
15

16. And then?
You got chocolate in my peanut butter...
■ Better poison message handling
■ Delivery count is now mandatory - this helps the provider determine if delivering a message is not possible, this
could be due to the client not liking the payload (chocolate:peanut butter interface).
Yes, I know that is a message on this topic. I sent it!
■ NoLocal use clarified, supported on non-durable subs
■ Was missing for some reason...
...These are actually just a selection of the minor changes.
Nigel has done a really good job with the spec. It’s quite readable, have a look
here (http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf)
@nwrightesq 16

17. What missed the boat?
A few examples of things we might like to see...
■ Paas / Multi Tennancy
■ A proposal for JMS multi tenancy was created
■ PaaS was deferred to JavaEE8 due to a lack of standardisation amongst cloud providers (simplified).
■ JMX API Standardisation
■ Management/Monitoring
■ Pre-Ack
■ Ability to acknowledge messages on delivery to the server, not the client. Good for high throughput.
Constrained by time/support these issues were lower in the pecking order. This doesn’t mean we
don’t want them going forwards...
@nwrightesq
17

18. This sucks! Where is X?!
A Plea
■ I’m sure X is awesome...
■ We want to know about it!
■ This isn’t an empty gesture...
■ A Simple Initiative http://java.net/projects/jms-spec/pages/Whiteboad-alpha
‣ From today we’re hosting an ideas whiteboard page on our java.net wiki
‣ Anything you think might be a good idea, either now or for the future of messaging, leave a statement or a picture.
➡ No need to raise a JIRA issue
➡ No need to trawl the message boards to check if you’re going to sound silly by making your suggestion. Crack
on.
‣ (We know wiki pages aren’t great for this, if anyone has a better idea please post it on... the wiki! I’d love a sort of
collaborative whiteboard that we can use in real time and save at the end...)
‣ It sounds simple. It is. This is all about lowering the barrier for entry - all you need is 10 minutes and an idea.
‣ Look out for podcasts and things in the future!
@nwrightesq 18

19. fin
Please note: none of this is
definitive yet, as per the timeline!
Thanks for your time!
Enjoy the rest of the conference.
@nwrightesq
19

20. Thanks! Do we have time for a
Q&A?
Any further q’s come find me, we can chat over a coffee
(or beer)!
I will be posting the slides on my twitter account.
Send me messages (or attack tweets) at:
@nwrightesq
Email me at:
nwright@c2b2.co.uk
Send me presentation feedback on our whiteboard at
http://java.net/projects/jms-spec/pages/Whiteboad-alpha