1 / 22

Graphic Section Divider

Graphic Section Divider. What’s next for JMS?. Nigel Deakin, Oracle John Ament, Sparta Systems, Inc.

kare
Télécharger la présentation

Graphic Section Divider

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Graphic Section Divider

  2. What’s next for JMS? Nigel Deakin, Oracle John Ament, Sparta Systems, Inc

  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. JMS 2.0Where we are now • JMS 1.1 released in in 2002 • JMS 2.0 launched in 2011 as JSR 343 • JMS 2.0 released in 2013 (with Java EE 7)

  5. JMS What next? • JMS 2.x maintenance release • Continuation of JSR 343 • An opportunity to errors and typos in JMS 2.0 • May contain small changes appropriate for a MR • Depends on what feedback we get on JMS 2.0 • JMS 2.y complete new release • Requires a new JSR • May contain whatever we want it to! • Probably aligned with Java EE 8

  6. Some general points • Nothing is decided yet, the agenda is open • Proposals may be logged in the issue tracker at jms-spec.java.net • The development of a specification is a community effort. • Whether a feature gets added may depend on whether there is somebody on the expert group prepared – and expert enough – to define it • A specification is not the best place for completely new innovations • JCP is here to standardise innovations, not to innovate

  7. Possible features for a full new version

  8. Next steps in simplifying JMS • JMS 2.0 has simplified the API for sending messages • JMSContext replaces Connection and Session • @Inject JMSContext removes need to create and close in Java EE • Try-with-resources block removes need to close JMSContext in Java SE • Lightweight JMSProducer simpler than MessageProducer • Methods to send message body directly remove need to create Message • Similar benefits for receiving messages synchronously • But receiving messages asynchronously is mostly unchanged

  9. Next steps in simplifying JMS Make it simpler to define async message listeners • Java EE offers the best scope for simplification • MDBs are already declarative: simply define a MessageListener and annotate it • Lots of scope to make even simpler • Java SE is harder to simplify • We have no runtime container

  10. Simpler message-driven beans Now • Must implement MessageListener • One callback method only

  11. Simpler message-driven beans Future, exploiting new features already in JCA 1.7 and EJB 3.2 • No need to implementMessageListener, just a new marker interface • Multiple callbacks on different destinations • Still tied to lifecycle and pooling of MDB

  12. Dynamically-created listener objects in Java EE • A managed bean, not a MDB – can have shorter lifecycles than MDB • But can be pooled, like a MDB

  13. Major new messaging features "Do something about...." • Web APIs: HTTP, REST, SOAP • AMQP • STOMP • Leveraging at the client protocol level, recommending implementations • Vast, cloud-scale applications • may need relaxed message ordering • These are common requests, but they need specific proposals • Ideally, try to standardise what vendors do already

  14. Other new messaging features • Topic hierarchies • Batch delivery • deferred from JMS 2.0 until MDBs made more flexible • Topic delivery to a cluster • PaaS/multi-tenancy support (whatever is in Java EE 8...) • Individual message acknowledgement • etc...

  15. More standardisation • Standard API to create and configure ConnectionFactory objects • Standard API to create and configure Queue and Topic objects • Standard API for querying state of queues and topics • beyond the QueueBrowser • Standard API for management • Standard API for monitoring

  16. Interaction with Java EE transactions • Resolve some undefined use cases • Create session when there's a TX, use it when there's no TX • Create session when there's no TX, use it when there's a TX • Currently undefined; vendors define their own behaviour here • Allow a session to opt out of a Java EE transaction • Create a non-transacted session even though there's a current TX • Allow client-acknowledgement and local transactions • Currently not allowed in EJB or web applications • some vendors allow it anyway

  17. How do we get JMS in to the Cloud?

  18. How do we get JMS in to the Cloud?

  19. How does JMS deal with Multi-Tenancy?

  20. What would you like to see in the next version of JMS?Discuss…

  21. How to give your views • Join and contribute to users@jms-spec.java.net • Submit ideas to JMS spec issue tracker (or comment on existing ideas) • Contact nigel.deakin@oracle.com • See jms-spec.java.net for details

More Related