jms-spec
  1. jms-spec
  2. JMS_SPEC-134

Declarative Annotation Based JMS Listeners

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      MDB is currently the only declarative way of listening for JMS messages. While the MDB model is adequate, it has a few shortcomings (primarily related to it's true age). The first is that since it is rather generic to JCA, it makes the syntax less than ideal for JMS (ironically, the vast majority of MDB use is for JMS). The MDB model is highly coupled to the EJB component model, which makes generic use in managed beans needlessly difficult. Lastly and perhaps most importantly, reimaging the MDB model using CDI/annotations in a manner specific to JMS introduces the possibility of significant usability improvements/API modernization.

      It is perhaps best to demonstrate these concepts using some simple code examples:

      @Pooled // Documented here: https://java.net/jira/browse/EJB_SPEC-113
      public class MyListenerComponent {
      
        @JmsListener(destinationLookup="...", clientId="...", subsciptionName="...", messageSelector="...", ...)
        @JMSConnectionFactory("...")
        @Transactional
        public void listen (Message message) {
          ...
        }
      }
      
      @ApplicationScoped
      @MaxConcurrency(...) // Documented here: https://java.net/jira/browse/EJB_SPEC-113
      public class MyListenerComponent {
      
        @JmsListener(destinationLookup="...")
        public void listen (String message) { // Message payload automatically type-checked and unwrapped
          ...
        }
      
      }
      
      @RequestScoped // A message received is a "request"
      public class MyListenerComponent {
      
        @JmsListener(destinationLookup="...")
        // Message payload automatically type-checked and unwrapped, 
        // message contents automatically injected, type-checked, unwrapped.
        public void listen (byte[] message, 
                            @JmsMessageProperty boolean myFlag, 
                            @JmsMessageProperty("myFlag2") boolean myFlag2,
                            @JmsCorrelationId String myCorrelationId,
                            ... 
                            ) {
          ...
        }
      
      }
      
      @Pooled
      public class MyListenerComponent {
      
        @JmsListener(destinationLookup="...", batchSize="...", retry="...", retryDelay="...", ...) 
        // Batch delivery, retry, retry delay, DLQ, etc new features.
        public void listen (Message... messages) {
          ...
        }
      
      }
      

      As suggested in the examples above, decoupling from the EJB component model also allows for a great deal of flexibility in putting together the component life-cycle, programming model, features and re-use.

      Although I am entering this in JMS as I feel it is the correct place to get this done, I assume that this body of work will require a great deal of collaboration with the EJB, CDI and platform expert groups.

      Do let me know if anything needs to be explained further - I am happy to help.

      Please note that these are purely my personal views and certainly not of Oracle's as a company.

        Issue Links

          Activity

          Hide
          Nigel Deakin added a comment - - edited

          @John D. Ament: The changes in JCA 1.7 (which allow the resource adapter to query the methods and annotations on the endpoint class) would allow us to define a MDB which has JMS-specific method annotations to define the callback method, the queue or topic, and other consumer parameters. We already have JMS_SPEC-116 (which you logged) to cover that, and I mentioned this as point (3) in my comment above.

          However Reza's issue here is introducing some additional features, which I listed as points (1) and (2) above. These would depend on changes in the EJB spec, which Reza has logged as EJB_SPEC-113. I think that CDI changes may also be needed.

          We might actually be able to develop this in two stages.

          • The first stage could be JMS_SPEC-116 which would define new JMS-specific method annotations which removed the dependence of a JMS MDB on javax.jms.MessageListener whilst keeping keep the same MDB lifecycle model.
          • The second stage could be to define class annotations which would replace or extend MessageDriven and allowed the listener lifecycle to reflect CDI scopes, without losing the key concept of the listener invoking a pool of endpoints. I suspect these class annotations would need to be be defined in the EJB (or CDI) specs and would be generalised to cover cases other than JMS.

          @John D. Ament: I think allowing "JMS listener beans" to have a defined scope would help with your multi-tenancy requirements. For example the use of dependent scope would allow them to have the same lifecycle as some tenant-specific application object. You also make some suggestions which would allow applications to dynamically generate Queue objects on a per-tenant basis. I think it would be worth you logging as a separate issue, since it isn't specific to async listeners but would be needed for sending messages and sync consumers as well. That said, explicit JMS support for multi-tenancy needs to take its lead from the Java EE platform spec. That's where multi-tenancy requirements should be raised initially (and obviously it's early days for Java EE 8 currently).

          Show
          Nigel Deakin added a comment - - edited @John D. Ament: The changes in JCA 1.7 (which allow the resource adapter to query the methods and annotations on the endpoint class) would allow us to define a MDB which has JMS-specific method annotations to define the callback method, the queue or topic, and other consumer parameters. We already have JMS_SPEC-116 (which you logged) to cover that, and I mentioned this as point (3) in my comment above . However Reza's issue here is introducing some additional features, which I listed as points (1) and (2) above . These would depend on changes in the EJB spec, which Reza has logged as EJB_SPEC-113 . I think that CDI changes may also be needed. We might actually be able to develop this in two stages. The first stage could be JMS_SPEC-116 which would define new JMS-specific method annotations which removed the dependence of a JMS MDB on javax.jms.MessageListener whilst keeping keep the same MDB lifecycle model. The second stage could be to define class annotations which would replace or extend MessageDriven and allowed the listener lifecycle to reflect CDI scopes, without losing the key concept of the listener invoking a pool of endpoints. I suspect these class annotations would need to be be defined in the EJB (or CDI) specs and would be generalised to cover cases other than JMS. @John D. Ament: I think allowing "JMS listener beans" to have a defined scope would help with your multi-tenancy requirements. For example the use of dependent scope would allow them to have the same lifecycle as some tenant-specific application object. You also make some suggestions which would allow applications to dynamically generate Queue objects on a per-tenant basis. I think it would be worth you logging as a separate issue, since it isn't specific to async listeners but would be needed for sending messages and sync consumers as well. That said, explicit JMS support for multi-tenancy needs to take its lead from the Java EE platform spec. That's where multi-tenancy requirements should be raised initially (and obviously it's early days for Java EE 8 currently).
          Hide
          Bruno Borges added a comment -

          I'd prefer to simply go with JMS_SPEC-100 for next version of JMS, until we are certain about Cloud use cases.

          Show
          Bruno Borges added a comment - I'd prefer to simply go with JMS_SPEC-100 for next version of JMS, until we are certain about Cloud use cases.
          Hide
          clebertsuconic added a comment -

          I don't see a relation between JMS_SPEC-100 and this...

          Cloud use cases AFAIK are more about multi-tenant support. I don't see that as a stopper on this. Or am I missing something?

          Show
          clebertsuconic added a comment - I don't see a relation between JMS_SPEC-100 and this... Cloud use cases AFAIK are more about multi-tenant support. I don't see that as a stopper on this. Or am I missing something?
          Hide
          reza_rahman added a comment -

          I do agree that it is not necessary to delay this for the clouds to clear . In fact, I think the fundamental programming model is flexible enough such that it could be easily adapted later on to make into account dynamic destination creation, multi-tenancy, etc.

          With regards to https://java.net/jira/browse/JMS_SPEC-100, I think the overlap is a good indication that the current MDB model really does need to be revisited. The reason I did not build upon it is because I felt it did not really take full advantage of the opportunity to revisit the entire programming model, still has a very over-generalized JCA/EJB/MDB centric syntax and did not have sufficient technical detail (with all due respect/credit to Bruno - technical detail is not an easy thing from a non container implementer perspective).

          Show
          reza_rahman added a comment - I do agree that it is not necessary to delay this for the clouds to clear . In fact, I think the fundamental programming model is flexible enough such that it could be easily adapted later on to make into account dynamic destination creation, multi-tenancy, etc. With regards to https://java.net/jira/browse/JMS_SPEC-100 , I think the overlap is a good indication that the current MDB model really does need to be revisited. The reason I did not build upon it is because I felt it did not really take full advantage of the opportunity to revisit the entire programming model, still has a very over-generalized JCA/EJB/MDB centric syntax and did not have sufficient technical detail (with all due respect/credit to Bruno - technical detail is not an easy thing from a non container implementer perspective).
          Hide
          clebertsuconic added a comment -

          We should seriously look into that. People are already taking this approach (look at Camel for instance).. If we keep banging the MDB route, it will become less and less relevant to our users.

          We need something more programmers friendly like this IMHO.

          Show
          clebertsuconic added a comment - We should seriously look into that. People are already taking this approach (look at Camel for instance).. If we keep banging the MDB route, it will become less and less relevant to our users. We need something more programmers friendly like this IMHO.

            People

            • Assignee:
              Unassigned
              Reporter:
              reza_rahman
            • Votes:
              11 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: