[Design of JBoss jBPM] - Re: API first cut available for jBPM3
by thomas.diesler@jboss.com
Here a few notes on differences and limitations
ProcessInstance => Process
In Java an object instance is commonly called Foo not FooInstance. The standard talks about an "instance of a Process" rather than a ProcessInstance
Execution => Token
We agreed that an 'Execution' is not the same as a 'ProcessInstance' and should therefore exist as two separate entities in the API. Token is the concept that is known to jBPM3 users already and also appears under this name in the standards.
Tokens may have a parent child relationship, Process' do not.
A Process can be started, a Token cannot.
A Process has structure (i.e. child Nodes), a Token has not.
I didn't (yet) adapt the XML marshalling layer. Currently this is implementation detail of the dialect that is actually used in combination with the CTS and does neither effect CTS test cases nor API signatures. In other words, if the dialect is pluggable anyway it does not matter much what the actual XML will look like.
This becomes however important as soon as XML snippets enter the documentation. My mid Dec this should be settled so that we can start posting process definitions in XML
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190009#4190009
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190009
17 years, 4 months
[Design of JBoss jBPM] - API first cut available for jBPM3
by thomas.diesler@jboss.com
Folks,
following our team meeting in Antwerp I trimmed down the API+CTS that I had in the incubator project to the functionality and concepts that we agreed on.
http://www.jboss.org/community/docs/DOC-12945
In Antwerp we decided that the threading model that is native to jBPM (i.e. borrowing the client Thread) should be supported by the API, which actually makes a mapping to the jBPM3 code base possible.
How the API+CTS can be integrated in the Maven build is documented here
http://www.jboss.org/community/docs/DOC-12871
the Java Doc is here
http://jbpm.dyndns.org/jbpm-spec/jbpm-spec-api/apidocs/index.html
Doing this work for jBPM3 has multiple benefits.
#1
It will be much easier to decide when jBPM3 functional equivalence is reached
#2
Projects that require a stable API but also have a dependency on jBPM3 can start to decouple from jBPM3 implementation detail and interface with the API. This is particularly true for the GWT-Console and to some extend to the GPD.
#3
The migration to jBPM4 will be seamless for projects that use the API as an integration point
#4
TomB who leads the API and provides an implementation for jBPM4 can reuse the jBPM3 integration and make good progress in jBPM4.
#5
Folks that know jBPM3 can start to provide qualified and meaningful feedback based on API signatures and CTS test implementations
Over the next couple of weeks I still expect to see some movement in the API+CTS snapshot artefacts until it becomes clear what will actually go into 3.3.1 and 4.0.0.Alpha1 respectively
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190004#4190004
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190004
17 years, 4 months