10 Replies Latest reply on Mar 1, 2006 3:16 PM by ralfoeldi

    Asynchronous processing future

    jimrigsbee

      I have been working at replacing a commercial product, Carnot, with jBPM at my current organization. It has some interesting features that look like they would be a good fit for jBPM.

      An MDB can receive messages from outside that tell the workflow engine to start a process, apply changes to the context of an active process, or can signal a node to move on.

      I see that we have the beginnings of JMS asynchronous processing but I'm not sure how it works. It looks as if some of it is no complete as yet?

      I would appreciate any information about the current release and future plans for this type of processing. Also, how does this tie into BPEL?

      Cheers, Jim

        • 1. Re: Asynchronous processing future
          tom.baeyens

          these things would indeed make sense.

          currently there is a simplistic asynchronous messaging system build-in into jbpm. it is replacable with JMS.

          the next thing is a command framework. commands can be sent to the command executor. the command executor runs in a different thread and listens to the commands that are send on the asyncronous messaging system. When a command arrives, the command executor just executes it.

          In the current implementation, only 2 commands are used
          1) ExecuteNodeCommand: this command is sent when an asynchronous node is about to be executed. The command will invoke the execute method on the node and that will resume the execution asynchronously. That is to support asynchronous continuations.

          2) ExecuteActionCommand: this command simple executes an action.

          Other commands are envisioned, but not yet completed. Sending signals, updating variables, finishing tasks, ... most of the jbpmContext operations should be offered as commands so that they can be executed asynchronously.

          Does this answer your question ?

          regards, tom.

          • 2. Re: Asynchronous processing future
            jimrigsbee

            Yes, thanks. That matches what I saw in the source code. Do you have a timeframe in mind for this?

            Thanks, Jim

            • 3. Re: Asynchronous processing future
              jimrigsbee

              Tom,

              Can I pursue this for 3.2?

              Jim

              • 4. Re: Asynchronous processing future
                tom.baeyens

                Absolutely !

                I'm interested to hear your thoughts on where you want to get started.

                This is where i think the first work needs to be done:
                * get the JmsMessageServiceFactoryImpl working. i just wrote it against the javadoc APIs... probably it is not yet complete.
                * also an MDB is lacking to execute the commands
                * then we should find out and document what has to be changed in the configuration to replace the default message service with the JMS based message service.
                * then a few test cases with the JMS message service
                * then adding/finishing some org.jbpm.command.* commands for sending signals and finishing tasks.

                what are your ideas ?

                regards, tom.

                • 5. Re: Asynchronous processing future
                  jimrigsbee

                  Tom,

                  You pretty much hit all the points. We need to make sure we deal with transactions with JMS the way you did with DB messages. Might need a JTA transaction for this so that the DB and JMS message sources are dually committed.

                  I would like to refactor the command thread so that the core logic can be shared by this thread and the MDB. The main control structure of how the thread works and gets invoked, etc. don't need to change.

                  Looks like we need to add a few commands for initiating a process instance, but otherwise looks like that most of the items are there.

                  I'll create a JIRA issue as a feature.

                  My company is really interested in these features to save them big $$$ by switching to jBPM.

                  Regards, Jim

                  • 6. Re: Asynchronous processing future
                    jimrigsbee

                    Need to clarify one point from previous post: dual commit is for taking the message off the queue and committing the work done by hibernate to persist the graph.

                    Jim

                    • 7. Re: Asynchronous processing future
                      edgarpoce

                      Great to hear the JMS stff is moving!!!. I'll be happy to test it ;)

                      br,
                      edgar

                      • 8. Re: Asynchronous processing future
                        jimrigsbee

                        Edgar,

                        Great I'll take you up on that...stay tuned to this post.

                        Regards, Jim

                        • 9. Re: Asynchronous processing future
                          tom.baeyens

                           

                          "jimrigsbee" wrote:
                          Might need a JTA transaction for this so that the DB and JMS message sources are dually committed.


                          yes, exactly my thoughts too.

                          "jimrigsbee" wrote:

                          I would like to refactor the command thread so that the core logic can be shared by this thread and the MDB. The main control structure of how the thread works and gets invoked, etc. don't need to change.


                          Not sure about this. I was thinking of throwing runtime exceptions in the MDB was the way to go. The the message queue could be configured to put the message in the error queue after x number of retries.

                          Then you leave the transaction rollback and the moving of the message to the error queue to the JMS implementation.

                          Within this approach, parts of the command executor might still be reusable. It would be great if you refactor to allow reuse for those parts.

                          I was thinking of serializing the commands to a binary message. I think that would require a readResolve implementation on the commands to rebind the persistent objects to the new persistence session.

                          "jimrigsbee" wrote:

                          Looks like we need to add a few commands for initiating a process instance, but otherwise looks like that most of the items are there.


                          FYI: only the ExecuteNodeCommand and the ExecuteActionCommand are tested. The others show the ideas that i got in mind but are still untested.

                          "jimrigsbee" wrote:

                          My company is really interested in these features to save them big $$$ by switching to jBPM.


                          that's the idea :-)

                          regards, tom.

                          • 10. Re: Asynchronous processing future
                            ralfoeldi

                            Hi guys,

                            Tom asked my to write up my experience with jBPM and JMS. It's still in a rough version. I hope I'll get around to documenting / explaining more during the next days.

                            http://wiki.jboss.org/wiki/Wiki.jsp?page=JBPMJMS

                            Any comments welcome.

                            Greetings

                            Rainer