Re: [jms-dev] JMS 3.0- make it fit well for JMS over Kafka?

[Gordon Hutchison <gordon_hutchison@xxxxxxxxxx>]

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