As the Jakarta EE Working Group at Eclipse prepares for the release of Jakarta EE 8, we are starting to think about what comes next. Actually, most of us have been thinking about that for a while, but we have to get Jakarta EE 8 out before we can start to overhaul the platform. One of the technologies that is due for an overhaul after Jakarta EE 8, is the Java Message Service (JMS) which was originally introduced in 2000 – nearly 20 years ago.
Since 2000, the JMS specification has evolved slowly, but steadily, and while it remains one of the most popular of the enterprise APIs, its age is starting to show. David Blevins, CEO of Tomitribe, has been charged with leading the JMS specification. He’s interested, as am I, in moving the technology platform forward to better match the modern development environment and to clear out some of the cobwebs that have accumulated in the specification.
But JMS doesn’t belong to David or me or any one person, or entity any longer, it belongs to everyone. We want to extend an invitation to anyone who has an interest in this platform to contribute to its success. To get things rolling, we ask that folks contribute to conversations on the JMS-Dev mailing list. In addition, David has set up an informal repository called jms-proposals which will probably be moved under the EE4J at some point, but is currently stand-alone. The idea is that the jms-proposals repo is a “back-of-the-napkin” forum for showcasing new proposals for JMS. David set up a similar repo for the Java EE Security specification and it ended up being very important.
David and I have already seeded the jms-proposals repository with a few ideas; chief among them is the proposal to move the Message-Driven Bean (MDB) technology out of the EJB specification and into the JMS specification, where we believe it belongs. As EJB begins to take a back seat to Contexts and Dependency Injection (CDI), it makes sense to continue to evolve the MDB technology under the JMS specification.
Another idea is to aline both the JMS API and the MDB component model with CDI to improve the programming model and simplify the process of integrating these solutions into modern platforms that use CDI.
A third idea is to turn MDBs into a CDI-driven POJO programming model that can both consume and produce messages, not just for JMS, but for many other messaging systems including JavaMail, JAX-RS, streaming, IoT, and any other domain that requires or would benefit from standardized processing of data flows.
Finally, the repository has been seeded with a proposal to deprecate and eventually eliminate the domain-specific and classic JMS APIs in favor of continued development of the Simplified API introduced in JMS 2.1.
None of the ideas mentioned above are written in stone; they are just proposals at this point that can be greatly improved, expanded, or abandoned according to the consensus of the Jakarta EE community. JMS-Dev mailing list will be the place to introduce concepts and the jms-proposals repo will be the place to flush those ideas with code for more careful consideration.
So, in the spirit of open source and open standards, we encourage people to tune in, speak out, and propose ideas for improving and expanding the JMS specification for the future. If you want to get involved I suggest starting with the JMS-Dev mailing list at the Eclipse EE4J project. Your ideas matter, so jump on board and start to make a difference.
