Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jms-dev] JMS 3.0- make it fit well for JMS over Kafka?
Possibly someone at IBM?

On Fri, Nov 9, 2018 at 5:03 PM Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
I could reach out to him, although I don't know him well I spoke to him back in 2004 when I was an analyst for Burton Group (aka Gartner).  I had purchased his book and read it and probably didn't understand as well as I would have liked but was intrigued.  Anyway, I've been thinking that perhaps Flow-based is too restrictive because it requires that all messaging is asynchronous. It would be nice if the new MDB could handle JAX-RS and allow for synchronous as well as asynchronous messaging.  Does anyone else know J. Paul Morrison?

On Fri, Nov 9, 2018 at 9:47 AM, Werner Keil <werner.keil@xxxxxxxxx> wrote:
Flow Based Programming: https://github.com/tomitribe/jms-proposals/tree/master/flow-based-programming That's funny, because the guy who invented it (at IBM in the 70s https://en.wikipedia.org/wiki/Flow-based_programming) helped us with JSR 363 and Eclipse UOMo. He is based in Canada, so although he is quite old, maybe someone could reach out to him on that as well (can't say if he would join Eclipse Foundation, but he worked at IBM until he retired)

Werner



On Fri, Nov 9, 2018 at 3:19 PM Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
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

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

_______________________________________________
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

Back to the top