[Design of JBoss jBPM] - Re: Making the BPM API more generic?
by thomas.diesler＠jboss.com
anonymous wrote :
| the 'BPM API' is something that is separated from the PVM, since it is a refactoring of jBPM3
|
This is not true. The JBossBPM API, together with its RI and CTS is a separate project with no relation to jBPM3
anonymous wrote :
| I call myself a 'jbpm power-user' since I use it on a daily basis in real-life projects. But I find it quite confusing that these 'BPM API' and 'PVM' ideas seem separated while efforts should be bundled to have a better product. If I'm wrong (which would be good), please correct me.
|
Yes, it'd be good if we could actually see some of the PVM concepts and API - so we can discuss them at a conceptional level. Implementation detail is not useful for that purpose.
CONCEPTS not detail is what needs to be discussed in a early design phase.
The first release of the API will come out 1-Sep-2008
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168462#4168462
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168462
15 years, 9 months
[Design of JBoss jBPM] - Re: Making the BPM API more generic?
by thomas.diesler＠jboss.com
anonymous wrote :
| A generic BPM API could be very useful
|
Yes, moreover. JBossBPM customers need a stable API that they can rely on between version updates. For details on compatibility see
http://jbpm.dyndns.org/jbpmwiki/index.php?title=APIMission#What_is_expect...
As documented in the wiki the JBossBPM conceptually follows the BPMN specification
http://en.wikipedia.org/wiki/BPMN
Using that spec we created a model which is meant to accommodate the conceptual constructs from the BPM world
* Event (start, stop, intermediary)
* Gateway (exclusive, inclusive, parallel, complex)
* Task (None, User, Send, Receive, Script, etc)
* SequenceFlow, MessageFlow
* Pools, Swimlanes
* SubProcesses
* CompensationFlow, ExceptionFlow.
* InputSet, OutputSet, IORules
See http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMNGlossary for the definition of terms.
Together with the API we define a Compatibility Test Suite (CTS) that checks whether a BPM implementation is actually fulfils the SOA-Platform product requirements. At this point jBPM4 is expected to do so. It is ready when it passes the CTS through the API.
With respect to DroolsFlow, I would expect that you can map your model to the API model implementing a DialectHandler
http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMPublicAPI
http://jbpm.dyndns.org/jbpmwiki/index.php?title=APIDialectHandler
For even more detail you can have a look at the API JavaDocs.
http://jbpm.dyndns.org/jbpm-site/jbpm-api/apidocs/index.html
You can have a look at the Airticket GWT Sample Application (to be documented in the wiki) from the JBossBPM reference implementation (RI). There you find a standard BPMN process definition created with the Eclipse BPMN Editor from the SOA Tools Package (STP). Additionaly an API native descriptor that adds BPMN constructs that are not currently supported by STP. The API Dialect handler includes the STP process definition, builds the API model and executes it on the RI.
A process modelling tool that supports the full set of BPMN constructs would have very little externally defined.
In short: A good modelling tool is one that supports a large set of standard constructs plus proprietary extensions. A DialectHandler should be able to map that to the API model. A BPM provider that implements the API should be able to execute that model.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168458#4168458
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168458
15 years, 9 months
[Design of JBoss jBPM] - Re: Making the BPM API more generic?
by jbarrez
anonymous wrote : .. split the API into a more generic part (offering methods to interact with processes of any type) and allow specific process languages (like jPDL3 or 4 or Drools Flow) to extend this API with more specific constructs. ... API for interacting with a process engine (starting processes, signalling events , communicating with external services, etc.) can all be made independent of the underlying process model and implementation (
Isn't this what the PVM is all about: extracting what is generic and allowing process languages to be built on top of that?
If I'm following the discussions here, the 'BPM API' is something that is separated from the PVM, since it is a refactoring of jBPM3.
I call myself a 'jbpm power-user' since I use it on a daily basis in real-life projects. But I find it quite confusing that these 'BPM API' and 'PVM' ideas seem separated while efforts should be bundled to have a better product. If I'm wrong (which would be good), please correct me.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168444#4168444
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168444
15 years, 9 months
[Design of JBoss jBPM] - Making the BPM API more generic?
by KrisVerlaenen
I believe that the idea of creating a public API for jPDL or BPM in general is very interesting. We (the JBoss Drools team) try to achieve close integration between processes and rules. A generic BPM API could be very useful here. Our vision is to create a unified platform where rules and processes are simply different ways of expressing (some of your) business logic and can be seamlessly integrated. This would allow users to select the most appropriate paradigm for their problem and integrate rules and processes without requiring them to learn and integrate different products themselves.
This is partially based on the observation that both rules and processes have a very similar life cycle: creation in a custom editor, storing your business logic in a repository, deployment to a runtime environment, monitoring and management of the execution, etc. We believe that is should be possible to offer an unified environment where this life cycle is supported as much as possible and both rules and processes are considered different types of business logic.
Drools has a RuleFlow language (for specifying the order in which rules should be executed using a flow chart) since v4.0 and is now extending that scope to become a more generic workflow language as well, where rules and processes can be integrated seamlessly (called Drools Flow). It would be interesting to see whether Drools Flow (or any other language like e.g. BPEL) can also fit in this common API effort, and maybe in the long term whether we can offer a similar API for both rules and processes.
I think it would be possible to achieve this if we split the API into a more generic part (offering methods to interact with processes of any type) and allow specific process languages (like jPDL3 or 4 or Drools Flow) to extend this API with more specific constructs. For example, different languages would probably have a different process model, but they all could implement a generic process interface. I also believe that the API for interacting with a process engine (starting processes, signalling events , communicating with external services, etc.) can all be made independent of the underlying process model and implementation (the user should not be confronted with these details in most cases). The interfaces defined by the WfMC are a very good example of this.
I'd be glad to provide more details on the different APIs Drools Flow is currently using to communicate with the outside world if needed !
Kris
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168441#4168441
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168441
15 years, 9 months
Re: Collaboration
by Thomas Diesler
Hi Kris,
thanks for this feedback. Could you please put this on the dev forum,
I'll be glad to answer there.
cheers
-thomas
Kris Verlaenen wrote:
> Thomas,
>
> I don't know if you know me but I'm a member of the JBoss Drools team
> and leading the ruleflow efforts and the integration between processes
> and rules. Our vision is to create a unified platform where rules and
> processes are simply different ways of expressing (some of your)
> business logic and can be seamlessly integrated. This would allow users
> to select the most appropriate paradigm for their problem and integrate
> rules and processes without requiring them to learn and integrate
> different products themselves. This is partially based on the
> observation that both rules and processes have a very similar life
> cycle: creation in a custom editor, storing your business logic in a
> repository, deployment to a runtime environment, monitoring and
> management of the execution, etc. We believe that is should be possible
> to offer an unified environment where this life cycle is supported as
> much as possible and both rules and processes are considered different
> types of business logic.
>
> Mark told me that you are creating a BPM API that can be used for both
> jBPM 3 and 4. It would be interesting to see whether ruleflow can also
> fit in here (and maybe in the long term whether we can offer a similar
> API for both rules and processes). I'm already working with Koen Aers
> on creating a shared core process definition model for both jBPM and
> Drools Flow, so there might be some overlap. I attached a screenshot of
> our progress so far (the core concepts). Is there any information
> available about the API that I could take a look at. I'd also be glad
> to provide you with more information about our approach or links to our
> API as well.
>
> I hope we'll be able to share some of the efforts of both teams. As I
> said already, I'm working with Koen on integrating and extending the
> eclipse-based process designer. But I'm also thinking about our
> repository (Guvnor) for storing business logic, or the BAM/SAM efforts.
> I would be interested in knowing what you guys are up to in the future
> to see whether there are some opportunities for collaboration. I've
> also been told that you are going to provide WS-HumanTask integration
> for handling human tasks. I have implemented a proof of concept
> implementation for Drools Flow that uses the WS-HT service from
> ActiveEndpoints to execute human tasks in Drools Flow. I also have some
> experience with Eclipse-BIRT for creating basic monitoring reports for
> our execution engine. So if I can be of any assistance, let me know.
>
> Kris
>
> ------------------------------------------------------------------------
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 9 months