[kukeltje]

EstebanYep, that is exactely what I would suggest. Assuming messageProp can hold an xpath expression (or do you guys think of other property types?

I'm working on something similar to be able to call a webservice from jBPM where there is an xml document to be filled based on process variables.

[rex.sheridan]

Esteban, that sounds good to me. It would be nice if we could control the variable name used to insert the message into the context as well.

[estebanschifman]

Thanks to both of you. Now give me time to cut some code and I'll let everybody know when the changes are committed.
:-)

[kukeltje]

jBPM has the notion of actionhandlers. These can be synchronous (blocking) or asynchronous (non-blocking). Maybe we (I ?) should create a default actionhandler base class which makes it possible to call services on the bus from jBPM. Did you guys give that any thought?

[rex.sheridan]

Ronald,

Does org.jboss.soa.esb.actions.jbpm.BaseActionHandler address what you are talking about?

[estebanschifman]

Latest versions of jBPM-ESB integration classes are not in the trunk, and won't be there until we are sure they won't break the build.
There is however a workspace (...workspace/eschifman) where code in progress is being held. Just keep in mind that what is there is 'work in progress' and some things still don't work as we all expect.

[bill.burke]

Esteban,

Have you considered at all using JBPM as a backbone for the ESB? I see a lot of overlap/similarities between the core ESB engine and JBPM. Maybe ESB actions could be written as JBPM nodes or actions? For instance, take a look at the Seam Drools JBPM decision handler. Looks almost exactly the same as ESB's. ESB's split/aggragate are similar to JBPMs fork/join. Context variables are very analogous to a message map.

What are the advantages/disadvantages to using JBPM as the core process engine? Here's some I thought of off the top of my head:

Advantages:
* JBPM eclipse designer
* JBPM persistence
* JBPM asynchronicity
* versioning
* richer IoC
* parameter/context mappings

Disadvantages:
* A little extra verbose for small tasks (I think this could be overcome by writing our own node type.)

I don't know, what do you think??? In the least, we should create some JBPM adapters so that ESB actions/nodes could be used as JBPM nodes/actions.

[rex.sheridan]

On a related note, I was wondering the other day about the following: what if someone were to implement an ESB gateway using a jBPM process. You could basically have a long running process and send it a "poll" signal at some interval. I wonder if it would be useful.

I've been thinking in jBPM mode for so long I've started finding all sorts of uses for it :)

[bill.burke]

"rex.sheridan" wrote:
On a related note, I was wondering the other day about the following: what if someone were to implement an ESB gateway using a jBPM process. You could basically have a long running process and send it a "poll" signal at some interval. I wonder if it would be useful.

I've been thinking in jBPM mode for so long I've started finding all sorts of uses for it :)

Not only that, but you could have the ESB message be put in a wait state while it was waiting for some external system to respond. You could have timers fire off. It just seems like there's so much you could do if the two were combined into one metamodel. Combine ESB's rich component set, with JBPMs clean process model.