Hi Everyone,
Some really great ideas here! I'm excited to see folks thinking about and contributing to the future of JMS. David Blevins and I gave a presentation at CodeOne 2018 where we discussed some ideas for JMS and MDBs. We created a GitHub repository that is open to all in which people can contribute their ideas or proposals. We hoped to create a totally open discussion about these things with a central repository for code examples. This is a process that was used in the Java EE security specification to great effect so it's proven itself already. I suggest that we continue to discuss these things here on this mailing list but also encourage folks to put their proposals (even in the back of the napkin) into the GitHub repository.
Here is that link:
I also want to point folks to an idea David and I presented at CodeOne 2018 that is not yet complete but addressed in the GitHub repo. It discusses a radical update to MDBs which remains backward compatible. The idea is to turn MBDs into POJOs which can consume and produce messages. It's similar in some respects to James Roper's
proposal. The idea is to move away from MBD's consumption-only, fixed interface model into something that is far more flexible and can process not only JMS messages from MOM providers but also reactive streams, Kafka streams, and many other messaging systems.
By having specific sets of Incoming and Outgoing annotations for each message type but maintaining the simple POJO programming model things like Cloud Events, timers, and even JAX-RS/REST communications could be covered. Think of it as the start to the standard programming model not only for Jakarta and MicroProfile but also for Function as a Service (e.g. AWS Lambdas, Google Functions, Oracle Fn).
In addition, the new MDBs would no longer be tied to the tight constraints of MDB with regard to supporting transactions. It's a component model that could be universal using CDI as a foundation for defining messaging specific resources and configurations.
Here is a like to the portion of the deck from CodeOne 2018 that talks about this in more details.
I have not had time to fully read through the proposal in this email or the one in Gordon's other email about Reactive Messaging but hopefully, over the coming weeks, we can merge these ideas into one specification for MDBs that can be adopted by Jakarta EE as well as MicroProfile and other things like IoT. One component model that supports any messaging system, asynchronous or not.
Very excited about this conversation!
Richard
