"heiko.braun(a)jboss.com" wrote : | Agree, it's API stuff. But I was referring to this | anonymous wrote : | | Questions were more about declaring vars, typing them, giving default values etc | | | My concern was more about granularity of the discussion. I.e. Thomas reply is more likely what I consider an appropriate level to have a discussion at the team meeting. | Does that make sense? In the first couple of years as we build jBPM, we had a lot of "can you do this process construct?" type of questions. We realized that by overwriting the Node's execute method, we could just implement any behaviour we want in plain Java. The focus then quickly shifted to the runtime data structure (the tree of executions). As only that becomes the limiting factor of what kind of process constructs the engine can handle.We also realized that this way, we can implement any process language as it is just a set of process construct implementations. Next came pluggable aspects. Swimlanes in jPDL don't make sense in BPEL. Even other process languages that include task management (like bonita) have other interpretations of process roles. Correlation sets only make sense in BPEL. So it must be possible to plug these kinds of aspects on top of the core execution data. And the last factor was the different environments: BPEL runs in an ESB-like environment (based on WSDL services). jPDL runs in any kind of Java environment and wants to bind to different transaction demarcation technology. Pageflow executions must be able to persist themselves in the http session, and so on. These 3 aspects * node pluggability * pluggable aspects * embeddability lead to the design goals of the PVM based approach to jBPM 4. So IMO it makes sense to see if the BPMN constructs can be build on top of the PVM. But I'm pretty confident that is going to be possible. That is not where the challenge is IMO. We'll be pursuing following process languages: * jPDL * BPEL (Bull) * XPDL (Bull) * Pageflow (SEAM) * Thread Control Language (TODO) * Executing BPMN directly from the STP-BPMN file format could be another potential candidate. In the context of those target languages, I don't think that a dogmatic adoption of BPMN has the answers. We should look at the executable process parts of BPMN and see to what extend it makes sense to align jPDL with BPMN. Then we should use the BPMN figures in the designer where appropriate. The real challenge with BPM and the process languages that we target is to identify the common parts and define how we're going to add the process language specific parts. The PVM is focussed on the common parts, but with a clear strategy on how all of those specific process language features can be build on top. In terms of the API, we are currently far enough advanced to see that a common API is possible that is shared between all these process languages. This means one API for all kinds of workflow. Another challenge is the impact of persistence. The more you try to hide that aspect, the more it pops up in unexpected places. Over the last years, we found out that the clue has been to align jBPM's persistence with the user's domain model persistence. That is why embeddability is such a crucial part of what we do. By making the embeddability of jBPM easy into a Java project, we make our own market. A real discussion point in this sense could be JPA. As more projects start with non-hibernate based JPA persistence, we loose a big part of our embeddability. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180766#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...