"heiko.braun(a)jboss.com" wrote : anonymous wrote : | | Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs) | | | | Interesting question. Maybe we should elaborate on the question how far the actual PDL influences the design of the API. This will probably reveal that different API's are required: | | - One for building a process model from XML descriptors | (Similar to what's in the PVM already) | - One for invoking on it (Client API) | - One for extending the engine capabilities (i.e. new node types) | - One to solve integration problems (TX, persistence, etc) | | +10 I like the use of jaxb as Thomas is doing. Not fully sure why, but it feels right. "heiko.braun(a)jboss.com" wrote : | | But to answer your question, I'd say that core elements are not language constructs. They are building blocks that predict core runtime capabilities, independent of the actual PDL. | To some extend you are correct, but if you search the net for problems regarding mapping bpmn to bpel or xpdl (improved with bpmn 2.0 and xpdl 2.0) it is not that easy and so they are not independent. "heiko.braun(a)jboss.com" wrote : | | Let's look at a Parallel Gateway for example. To me, this is a core element. But it's semantics are not clear. Does a parallel split require a subsequent join or can both path of execution end differently? | Afaik, but could not find it directly, BPMN is based on structured graphs so a split requires a corresponding join. In JPDL 3 it is fully clear, you need a fully nested fork-join pair. This differs from the statement in the workflow patterns for parallel split: "www.workflowpatterns.com" wrote : These branches may or may not be re-synchronized at some future time. The number of cases that I've came across in the forum where people did | fork 1 | / \ | | fork 2 | | / \ | join 1 | | \ / | join 2 | Are rare and could in most cases simply be modeled in another way. The reason jpdl requires this are simple. The implementation of a join is more simple then. This has been discussed several years ago, so unless bpmn requires otherwise, the decision for this is simple I think ;-) "heiko.braun(a)jboss.com" wrote : | The answer to this question has a technical impact on the implementation (i.e. threading, transactions) and thus an impact on the API. | It indeed influences the transactions (see the issues with the join in jira) and to a lesser extend threading (it was always stated that jBPM was not a thread-control-engine), therefore the async functionality to leverage e.g. jms "heiko.braun(a)jboss.com" wrote : | Why an impact on the API? Because if we chose real parallel execution (open graph, independent path's of execution) then client 'signal' (jBPM3) doesn't make sense anymore. Actually it wouldn't even work because the client will not be in control of execution anymore. | For that one parallel gateway you are correct, but again, the fork is not something that I ever signalled from the client api, so no change in that area. For each of the legs in a fork (weren't they called teeth ;-)) there can be wait-states again (activities) that need to be signalled "heiko.braun(a)jboss.com" wrote : | I believe that there is a small set of core elements, which are not related to the final PDL that, once we got it right, can be used to assemble concrete engines (jBPM4+jpdl) leveraging building blocks. | But those are building blocks behind the scenes, reusable to create a new PDL. Sounds nice, JPDL and e.g. an executable BPMN can leverage both, but that is not related (as you also state above, right?) to the client-api and imo that should be the most stable, simple to use etc... Great.... I get the feeling we are getting somewhere View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181003#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...