Graphic Section Divider

1. Graphic Section Divider

2. Easier Messaging with JMS 2.0 Nigel DeakinJMS 2.0 Specification LeadOracle

3. 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.

4. Bof What’s Next for JMS? Nigel Deakin, John Ament 1730 Tues 24 SeptParc 55 – Cyril Magnin I

5. Java Message Service (JMS) • A Java API for sending and receiving messages • Many competing implementations • Two distinct API variants • Java SE applications • Java EE applications – adds additional features • JTA (XA) transactions • replaces asyncMessageListener with MDBs, • injection of connection factories and destinations using @Resource • (new!) injection and management of JMSContext objects

6. What JMS is and isn't • A standard API • Not a messaging system in itself • Not a wire protocol • Defines Java API only • Doesn't define API for non-Java clients (e.g. C++, HTTP) - but many implementations do • An application API • Not (currently) an admin, management or monitoring API

7. JMS 2.0 • JMS 1.1 (2002) • dozens of implementations, both standalone and as part of a full Java EE provider • JMS 2.0 (2013) • launched in 2011 as JSR 343 • released in 2013 with Java EE 7 • available in Open Message Queue 5.0 (standalone JMS provider) and in GlassFish 4.0 (full Java EE provider) • other implementations announced or in progress

8. What's new in JMS 2.0 • Simpler and easier to use • New messaging features • Better Java EE integration • define differences between JMS in SE and EE more clearly • simpler resource configuration • standardized configuration of JMS MDBs • Minor corrections and clarifications

9. JMS 2.0Simpler and easier to use

10. JMS API simplifications Twin-track strategy • Make minor simplifications to existing standard API where it won't break compatibility • Define new simplified API requiring fewer objects • JMSContext, JMSProducer, JMSConsumer • In Java EE, allow JMSContext to be injected and managed by the container

11. Why did JMS 1.1 need simplifying?

12. JMS 1.1: Sending a message 13 lines of code just to send a message

13. JMS 1.1: Sending a message must create several intermediate objects

14. JMS 1.1: Sending a message redundant and misleading arguments

15. JMS 1.1: Sending a message must close resources after use!

16. JMS 1.1: Sending a message all methods throw checked exceptions

17. Minor simplifications to the existing standard API

18. Minor simplifications to the standard API Simpler API to create a Session • Methods on javax.jms.Connection to create a Session: • JMS 1.1 method remains • New method combines two parameters into one: • New method mainly for Java EE

19. Minor simplifications to the standard API Simpler API to close JMS objects • Make JMS objects implement java.jang.AutoCloseable • Connection • Session • MessageProducer • MessageConsumer • QueueBrowser • Requires Java SE 7

20. Minor simplifications to the standard JMS API Create closeable resources in a try-with-resources block Simpler API to close JMS objects • Make JMS objects implement java.jang.AutoCloseable • Connection, Session, MessageProducer, MessageConsumer, QueueBrowser close() is called automatically at end of block

21. Completely new simplified API

22. Completely new simplified API Introducing JMSContext and JMSProducer 13 lines reduced to 5

23. Completely new simplified API JMSContext combines Connection and Session Introducing JMSContext and JMSProducer Payload can be sent directly

24. JMSContext (1/2) • A new object which encapsulates a Connection, a Session and an anonymous MessageProducer • Created from a ConnectionFactory • Call close() after use, or create in a try-with-resources block • Can also be injected (into a Java EE web or EJB application)

25. JMSContext (2/2) • Can also create from an existing JMSContext (to reuse its connection – Java SE only) • Used to create JMSProducer objects for sending messages • Used to create JMSConsumer objects for receiving messages • Methods on JMSContext, JMSProducer and JMSConsumer throw only unchecked exceptions

26. JMSProducer • Messages are sent by creating a JMSProducer object • does not encapsulate a MessageProducer so is lightweight • supports method chaining for a fluid style • JMS 1.1 • JMS 2.0

27. JMSProducer Setting message delivery options using method chaining • JMS 1.1 • JMS 2.0

28. JMSProducer Setting message properties and headers • JMS 1.1 (need to set on the message) • JMS 2.0 (can also set on the JMSProducer)

29. JMSProducer Sending message bodies directly • Methods on JMSProducer to send a Message • send(Destination dest, Message message) • No need to create a Message • send(Destination dest, Map<String,Object> payload) • send(Destination dest, Serializable payload) • send(Destination dest, String payload) • send(Destination dest, byte[] payload) • Use methods on JMSProducer to set delivery options, message headers and message properties

30. JMSConsumer • Messages are consumed by creating a JMSConsumer object • encapsulates a MessageConsumer • similar functionality and API to MessageConsumer • Synchronous • Asynchronous • Connection is automatically started (configurable)

31. JMSConsumerReceiving message bodies directly When consuming messages synchronously • Methods on JMSConsumer that return a Message • Message receive(); • Message receive(long timeout); • Message receiveNoWait(); • Methods on JMSConsumer that return message body directly • <T> T receiveBody(Class<T> c); • <T> T receiveBody(Class<T> c, long timeout); • <T> T receiveBodyNoWait(Class<T> c);

32. JMSConsumerReceiving message bodies directly

33. Extracting the body from a message In both the standard and simplified APIs • Old way • New way

34. Injection of JMSContext objects into a Java EE web or EJB container

35. Injection of JMSContext objects into a Java EE web or EJB container • Connection factory will default to platform default JMS • Specifying session mode • Specifying user and password (not for production use)

36. Injection of JMSContext objects into a Java EE web or EJB container • Injected JMSContext objects have a scope • In a JTA transaction, scope is the transaction • If no JTA transaction, scope is the request • JMSContext is automatically closed when scope ends • Inject two JMSContext objects within the same scopeand you get the same object • if @JMSConnectionFactory, @JMSPasswordCredential and @JMSSessionMode annotations match • Makes it easier to use same session within a transaction

37. The four JMS APIs new and simplified slightly simplified deprecated

38. New messaging features

39. Delivery delay In both the standard and simplified APIs • Allows a JMS client to schedule the future delivery of a message • New method on MessageProducer • New method on JMSProducer • Sets minimum time in ms from that a message should be retained by the messaging system before delivery to a consumer • Why? If the business requires deferred processing, e.g. end of day

40. Async send In both the standard and simplified APIs • Send a message and return immediately without blocking until an acknowledgement has been received from the server. • Instead, when the acknowledgement is received, an asynchronous callback will be invoked • New methods on MessageProducer • Feature also available on JMSProducer • Why? Allows thread to do other work whilst waiting for the acknowledgement

41. Async send In both the standard and simplified APIs • Application specifies a CompletionListener instance

42. Better handling of "poison" messages:Make JMSMXDeliveryCount mandatory In both the standard and simplified APIs • JMS 1.1 defines an optional JMS defined message property JMSXDeliveryCount. • When used, this is set by the JMS provider when a message is received, and is set to the number of times this message has been delivered (including the first time). The first time is 1, the second time 2, etc • JMS 2.0 will make this mandatory • Why? Allows app servers and applications to handle "poisonous" messages better

43. Multiple consumers on a topic subscription

44. How topics work in JMS 1.1 Consumer Subscription Topic Consumer Subscription Producer Consumer Subscription Each message is copied to every subscription In JMS 1.1, each subscription has a single consumer Subscription may be persisted (durable) or memory-only (non-durable)

45. Making topic subscriptions more scalable • In JMS 1.1 a topic subscription can have only one consumer • only one thread can process messages • limits scalability • JMS 2.0 introduces shared subscriptions • a new type of topic subscription which may have multiple consumers • allows the work of processing messages from a topic subscription to be shared amongst multiple threads, and multiple JVMs

46. Shared subscriptions in JMS 2.0 Consumer Unshared subscription Topic Consumer Producer Shared Subscription Consumer Consumer Each message is copied to every subscription Subscription may be persisted (durable) or memory-only (non-durable) Each message on the shared subscription is delivered to only one consumer A shared subscription may have multiple consumers

47. JMS 1.1 API for topic subscriptions In the standard API (Session)

48. JMS 2.0 API for topic subscriptions In both the standard and simplified APIs (Session and JMSContext) • For unshared durable subscriptions, clientId must be set and is used to identify subscription • For shared subscriptions, clientId is optional. If set, it is used to identify subscription.

49. Easier definition of JMS resources in Java EE(This is actually part of Java EE 7)

50. Easier definition of JMS resources in Java EE The problem • Java EE and JMS recommend applications should obtain JMS ConnectionFactory and Destination resources by lookup from JNDI • Keeps application code portable • Creating these resources is a burden on the deployer, and is non-standard