7 Replies Latest reply on Nov 10, 2006 8:48 AM by kukeltje

    a jms message sending node type

    tom.baeyens

      Here's a discussion that started as an email thread and that i think might be interesting enough for the general public :-)

      Tom Baeyens wrote:
      
      for the email node, this also took a long time till we found a proper template language.
      
      for the JMS node, we can write it if we limit ourselves to e.g. Map based messages and have a configuration like this.
      
      <message name="message node" destination="">
       <properties>
       <property expression="#{a.jsf.like.expression}" />
       <property expression="#{a.jsf.like.expression}" />
       <property expression="#{a.jsf.like.expression}" />
       </properties>
       <entry key="a fixed value">
       <value expression="#{a.jsf.like.expression}" />
       <value expression="#{a.jsf.like.expression}" />
       <value expression="#{a.jsf.like.expression}" />
       </entry>
      </message>
      
      we would have to add destination configurations that map destination names to actual JNDI queue names for that to work generic enough.
      
      i'm in doubt about the actual value we would create with this kind of effort. because this is of course a very limited usage of the JMS API's. so people are definitely going to want things that are outside the scope of these configuration options. also for processing the message, you need to write java code anyway. so the user of this message node would already have to have knowledge of how to write an MDB. that is why i am still reluctant to put that kind of effort into developing this.
      
      regards, tom.
      
      
      | -----Original Message-----
      | From: Jeff Delong
      | Sent: donderdag 2 november 2006 17:54
      | To: Tom Baeyens
      | Subject: RE: jBpm Requirements
      |
      | Ok, you confirmed what I understood from looking at the code.
      | JMSMessageService is NOT a general purpose messaging sending
      | component, rather it's purpose is to support asynchronous
      | continuations via JMS.
      |
      | Back to the customer requirement.
      |
      | "Message delivery via JMS in support of asynchronous task
      | processing occurring in an MDB"
      |
      | Ok, this statement is not very precise, but generally what
      | customers want to be able to send a message to another
      | component (e.g., MDB), that does some processing, and then
      | returns a response message to the process to tell it to move on.
      |
      | This requires a JMS Node and an MDB to receive responses. The
      | CommandListenerBean should satisfy the requirements for the
      | MDB, which leaves the issue of the JMS Node. I see this as
      | similar to the Email Node. It has similar requirements - you
      | have to configure it to provide a destination (queueName) and
      | a message. How the message is constructed should be flexible,
      | allowing any object or string to be the message, or allowing
      | the construction of a message from a list of jBPM context
      | variables. The specification of a correlationId should also
      | be possible, for example a tokenId. And all of this node
      | configuration should be exposed via the GPD.
      |
      | For today's call we can ignore this, but sooner or later this
      | type of functionality needs to be provided by jBPM.
      |
      | Jeff
      |
      | Jeff DeLong
      |
      | -----Original Message-----
      | From: Tom Baeyens
      | Sent: Thursday, November 02, 2006 1:38 AM
      | To: Jeff Delong
      | Subject: RE: jBpm Requirements
      |
      | for async continuations, jbpm knows what message to send to
      | the job executor.
      |
      | but if you put a send on a node, what message should be sent
      | ? whereto ? so i don't see yet how we could implement a
      | configurable node type for send message. also, the POJO
      | message service doesn't support multiple destinations yet.
      | should not be hard, but it could be an effort to take into
      | account when implementing one reusable msg-node.
      |
      | but the biggest problem is the message. how will such a
      | msg-node compose the message ? this should be done with an
      | API that is usable for both the JMS and POJO implementations
      | of the message service.
      |
      | regards, tom.
      


        • 1. Re: a jms message sending node type
          brittm

          I understand what Jeff is looking for. That need can be addressed by a HowTo that presents an extendable action handler for sending a message and a RequestLog for correlating requests and responses. Of course, as you mentioned there will almost always be custom code needed beyond that. I don't have the HowTo, but I have everything else. I'll try to post my solution to the contributions page in a few days.

          Perhaps jBPM needs something like a set of 'offcially supported add-ons/solutions' to common use cases.

          -Britt

          • 2. Re: a jms message sending node type
            tom.baeyens

            brittm, i like your idea of a presenting the user with code meant for extensions.

            we could do it in the wiki or in the sources and call it the 'steal-away' or 'cherry-pick' pages.

            in those pages we would provide the action handler implementation for sending a message (and e.g. actionhandlers for all sorts of other things). users can then take this code and use it as a basis for their own implementation.

            what do you think, jeff ? would that also cover your requirements or do you still think that a configurable jms node would be better ?

            • 3. Re: a jms message sending node type
              kukeltje

              I'd go for doing it in the sources AND on the wiki. Required libraries should be handled just like with the examples.

              • 4. Re: a jms message sending node type
                andyredhead

                A collection of useful "How-To"s sounds like a very good idea :)

                For part of this case (sending messages to JMS through an action handler) I have some generic code which I'd be quite happy to post if its of interest - sorry, I don't have anything that does the listening for responses part :(

                A lesson learned the hard way when using jBPM and JMS message queues inside JBoss is if you use a transaction to wrap some jbpm activity and sending a message and you want a rollback of the transaction to include not sending a message - make sure you use the JMS factory bound under java:/JmsXA

                • 5. Re: a jms message sending node type
                  jeffdelong

                  I think an example would be a good first step, as this can provide a base for customization.

                  I think a second step is a JMS ESB Node that supports the requirements for integration with JBoss-ESB. I have already been working on an example with the ESB guys, and jBPM / ESB integration will (at least initially) be done via JMS. So a JMS Node and MDB that supported ESB integration would be very valuable.

                  Configuration in this case could be fairly simple to start. The name of an object that is stored as a jBPM context variable can be specified on the node, along with the destination and a few other properties. The object would be used to create an ObjectMessage and sent to a JMS Queue that is consumed by the ESB.

                  I agree though that a general purpose, one size fits all, supports every conceivable configruation option for a JMS Node is probably not doable, but we should try to get something moiving in that direction.

                  • 6. Re: a jms message sending node type
                    tom.baeyens

                    jeff,

                    why should the initial esb integration be done with JMS. I expected this to occur via the JBI binding component interface ?

                    • 7. Re: a jms message sending node type
                      kukeltje

                      Doesn't the JBI binding component interface needs an implementation? Can't that have jms underneath?