Re: [jms-dev] MicroProfile Reactive Messaging: Message Driven Beans Redu

[Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>]

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.

Richard

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
https://github.com/eclipse/microprofile-reactive-messaging/blob/master/spec/src/main/asciidoc/architecture.asciidoc

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)

@MessageDriven
@MaxSessions(3)
@MaxMessagesPerSession(1)
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 {
        t.doSomething();  
   }
}


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

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