-
15. Re: Why JBPM does not use XPDL
That's a good point about multiple languages executing on th same engine. Of course, once a CIO starts thinking of something as a 'BPM" solution, it's not always easy to convince them that we should be using two different process definition languages instead of just one.
XML schema types, WSDL definitions and structured constructs aren't in the vocabulary of business analysts.
Indeed, with BPEL a developer would have to provide partner services (dealing with all the WSDL stuff, etc.) for use in the parent process by the analyst; and actually, the analyst would still need to become a bit more "technical".
It might also be difficult to rule out any need for a simple user interaction or two in the parent process--at which point it becomes difficult for BPEL to make the grade. With BPEL as the parent process definition lanquage, all human tasks would need to be relagated to a sub-process (of some sort), even the simplest ones. Oracle's BPEL product exemplifies this by supplying a pre-built web service that handles human tasks. -
16. Re: Why JBPM does not use XPDL
Ronald,
We keep looking at BPMN and the other notations, but I still feel a mismatch. There should be a more natural mechanism to show or hide (technical) details that is not yet provided by BPMN.
Besides that, BPMN provides an executional model that is not completely aligned to the JBPM model.
There is still some work to do...
Regards,
Koen -
17. Re: Why JBPM does not use XPDL
Koen,
I agree about hiding/showing the technical details and definately do not suggest the notation should be used by jBPM fully. Maybe by adding additional stereotypes, it can be done. I'll definately try to go into this a little more.
With regard to the executional model, can you point in a direction? I did not find a real mismatch yet (but have only compared the two for two hours, late at night) -
18. Re: Why JBPM does not use XPDL
Ronald,
I was trying to answer this, but somehow got distracted and forgot to post :-(
One important incompatibility IMO is that BPMN defines the concept of a token. It is quite similar as in jBPM but instead of modeling this as a tree, they define it as a segmented string. In addition, they define the behaviour of this token when it travels through the BPMN nodes. So an important conclusion here is that BPMN is not only a modeling notation, but also an executional language and that makes things not so clear anymore.
Another thing is for instance the transaction annotation. In BPMN you can define a scope in your model and annotate it as transactional. It is very difficult to map such constructs on the very simple execution algorithm that we provide with jBPM.
Anyway, it is also not very clear what is necessary and what not to be really BPMN compliant. Is supporting the xml notation with attributes etc, etc enough? Does the execution exactly have to follow the rules described in the standard? Do the rectangles really have to be round-edged. According to the spec this is all the case and that makes it very difficult to swap over to that notation from ours with a snap of the finger.
Nevertheless, I think that it is very easy to support BPMN by implementing custom node types and providing a BPMN palette in the designer. But then the question is if we want to support a system that is not quite so good as ours in order to comply with a standard. At least at the moment the priorities are in trying to push the graph-oriented programming idea. But priorities can change of course ;)
Regards,
Koen