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

tom.baeyens@jboss.com do-not-reply at jboss.com
Fri Oct 10 09:08:29 EDT 2008


"heiko.braun at jboss.com" wrote : So what do we got? A generic API that tries to be PDL agnostic (PVM) and  the suggestion that we focus on one specific PDL and it's API? 
  | Is this right? Can you elaborate on how these are distinguished?  

PVM focusses on state management in a Java environment (as a java library).

Different PDLs run in a different environments.  These are build on top of the PVM state management and add typically a number of build-in features.  In case of BPEL that is e.g. (web) service consumption and (web) service publication.  For pageflow that is specifying the next page in a JSF request.

jPDL is the language that only adds XML parsing on top of the java component technology.  It's like the thinnest possible peal around the PVM.  It binds the state management straight into a Java environment.  That is the basics.  For convenience, we'll be adding more functional node types, but that should not be confused with the core essence, which is state management in Java.

Because PVM and jPDL both target Java environments, they are close and benefit from having one single API.

Only when clients would need access to e.g. swimlanes or BPEL correlation sets.  In that case you would need a process language specific API.  But I believe that those are edge cases.  Mostly, people only need to be able to start process instances, feed in external signals/triggers/events and manage process variables and tasks.  I believe all those functionalities can easily be developed in a PDL-neutral way and that they still remain easy to use, easy to understand and convenient.

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

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



More information about the jbpm-dev mailing list