| Re: [jms-dev] JMS 3.0- make it fit well for JMS over Kafka? |
Werner
Thanks, Werner. Your efforts are much appreciated!! I'm not sure about creating a 3.0 just yet. I would like, if everyone is ok with it, to flush out our ideas in the jms-proposals project for a while first. Thoughts?_______________________________________________On Fri, Nov 9, 2018 at 10:53 AM, Werner Keil <werner.keil@xxxxxxxxx> wrote:I also created a 2.0.2 Milestone in https://github.com/eclipse-ee4j/jms-api/milestonesPlease think (and committers should also be able to maintain it) of other milestones including a 3.0 version that make sense.All the others were before 2.0 they were 100% done and I closed them.Werner
On Fri, Nov 9, 2018 at 5:46 PM Gordon Hutchison <gordon_hutchison@xxxxxxxxxx> wrote:Hmmm, I raised my "JMS 3.0 - make it fit well for JMS over Kafka" issue over at https://github.com/eclipse-ee4j/jms-api
before I got the note below. I was not trying to be controversial (or even make any statement at all) in the choice of repository.
Gordon Hutchison
IBM Systems Middleware
Websphere Application Server Development
IBM Hursley Lab, UK.
gordon_hutchison@xxxxxxxxxx
From: Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
To: jms developer discussions <jms-dev@xxxxxxxxxxx>
Date: 09/11/2018 14:19
Subject: Re: [jms-dev] JMS 3.0- make it fit well for JMS over Kafka?
Sent by: jms-dev-bounces@xxxxxxxxxxx
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:
https://github.com/tomitribe/jms-proposals/tree/master
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.
https://docs.google.com/presentation/d/e/2PACX-1vQm-fnNOWbLsHIdOZFAyCjAwggVuzByczcxd1RZLOoY4rBhAasajRq2ESJnNVOLS3b8ru3MDSIKUCWu/pub?start=false&loop=false&delayms=3000&slide=id.g44d1c379b5_0_164
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
On Fri, Nov 9, 2018 at 4:56 AM, Gordon Hutchison <gordon_hutchison@xxxxxxxxxx> wrote:
Hi Message Folks,
I was wondering what the 'gaps' were between a future JMS 3.0 specification and its use to read and write from Kafka topic queues.
Of course JMS is an API so perhaps some aspects are just completely outside its scope.
Nonetheless, I think it would be interesting to look at.
If JMS was advancing to 3.0 what might be missing that would enable it to fit 'well'
over a subscope of Kafka use cases:
For example how would the JMS {que,topic} work for the Kafka {consumer-group} concept...
could JMS shared subscriptions be evolved slightly to provide a good fit?
https://www.ibm.com/support/knowledgecenter/en/SSWMAJ_2.0.0/com.ibm.ism.doc/Developing/sharedsubscriptionsinjms.html
"Shared subscriptions can be bound to a client ID, or can exist within a global namespace. If a client ID is specified for a connection that is used to create or join a shared subscription, then the subscription is bound to only that client ID. In this case, the client ID specifies the namespace for the subscription name. If no client ID is specified for a connection that is used to create or join a shared subscription, then the global namespace is used. By using a global namespace, it is possible to share a subscription between multiple connections. This configuration can be used, for example, to allow load balancing of a message-driven bean application that runs on an application server cluster."
If it could be made to have a good fit - could the environment that exits in a JEE context allow some
real customer value add from the container that might be currently missing in the Java SE Kafka client?
Gordon Hutchison
IBM Systems Middleware
Websphere Application Server Development
IBM Hursley Lab, UK.
gordon_hutchison@xxxxxxxxxx
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jms-dev
_______________________________________________
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jms-dev
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jms-dev
_______________________________________________
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jms-dev
jms-dev mailing list
jms-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jms-dev