[jbpm-dev] [Design of JBoss jBPM] - Re: meeting context

heiko.braun@jboss.com do-not-reply at jboss.com
Wed Oct 8 07:10:48 EDT 2008


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)

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.

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? The answer to this question has a technical impact on the implementation  (i.e. threading, transactions) and thus an impact on the API.

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.

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. 







View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180995#4180995

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180995



More information about the jbpm-dev mailing list