Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jms-dev] MicroProfile Reactive Messaging: Message Driven Beans Redux

I would also prefer one unified model and the one centered on POJOs is what has been prevalent for Java EE and Spring.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>
Date: 11/9/18 12:10 PM (GMT-05:00)
To: jms developer discussions <jms-dev@xxxxxxxxxxx>
Subject: Re: [jms-dev] MicroProfile Reactive Messaging: Message Driven Beans Redux

Hi Gordon (and all):

I'm probably not groking this Reactive Messaging proposal properly, but it seems to introduce a lot of new types that could be avoided (I think) using the POJO programming model I was talking about.  Again, I'm not sure I really am clear on the Reactive Messaging proposal but wouldn't it be simpler to just use the POJO model with annotations specific to Reactive or Kafka or whatever?  Have I missed something?

Also, I think it would be better for everyone if the new MDBs programming model and this Reactive Messaging proposal could be combined into a single effort. As I mentioned before the POJO MDBs I proposed could be used in Jakarta EE as well as MicroProfile (and also other projects) with JMS, streaming, JAX-RS, etc.  Rather than have several different message processing standards, let's see if we can create just one that is flexible enough (using flavors or profiles) to accommodate any messaging system. 

My thinking is that each messaging system supported by the POJO MDBs would be like a Profile in the sense that it can either be supported or not by vendors.  Jakarta EE would require the JMS one be supported, but other platforms may require other things.  So, for each messaging system, the new POJO MDBs would support, you create a flavor or profile of the MDB spec with specific annotations and message types.


On Fri, Nov 9, 2018 at 5:31 AM, Gordon Hutchison <gordon_hutchison@xxxxxxxxxx> wrote:

For those interested in JMS 3.0, I would draw their attention to

Where an annotation based message driven bean specification is forming.

To whet your appetite, it here is an example:

@Incoming( "myTopic" )
public CompletionStage<Void> processMessage(Message<IncomingMessage> msg) {
 System.out.println("Got message " + msg.getPayload());
 return msg.ack();

Versus I recent JMSnext presentation I saw from David Blevins and Richard Monson-Haefel (paraphrased  here)

public class BuildTaskMessageListener {

   @Destination( value = "TASK_QUEUE" )                   // this could of course be @Destination( TASK_QUEUE )
   @DestinationType( Queue.class )
   @MessageType( ObjectMessage.class)
   public void process( Tazk t ) throw JMS Exception {

Personally for JMSnext I would propose:
1 - discuss having seperate annotations for each of {send-que, receive-que, send-topic, receive-topic} to enable the first two lines to be one line.
2 - I would explore if it is possible to infer the @MessageType from the parameter to the annotated method.
but that is a seperate topic. :-)


Gordon Hutchison
IBM Systems Middleware
Websphere Application Server Development
IBM Hursley Lab, UK.
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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top