"heiko.braun(a)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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...