[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 the new POJO MicroContainer] - Re: MC roadmap - 2.0.0.CR1/GA, Post Final, 3.x
by adrian@jboss.org
"alesj" wrote :
| * Valves, container construction
|
There isn't very much on the wiki page since I put "etc." :-)
http://wiki.jboss.org/wiki/JBossKernel
anonymous wrote :
| Provide kernel aspects - IOC, lifecycle, valve, state, etc.
|
IOC is just the annotations we've already done, lifecycle would allow
somebody for example to intercept the "start" method even when it is not
actually called start(), essentially an aspect defined against the lifecycle annotation.
"state" is essentially what POJOCache does, but something
needs to be responsible for putting an MC managed bean into the cache
at installation and removing it at undeployment.
I'm sure you can think of a number of other MC aspects, e.g.
annotating a bean to expose it in jsr77 (which already has a JIRA issue
somewhere?) similar to what we do for JMX.
The "container construction' is an example of how to use aop-mc-int to build
containers without all the boilerplate, i.e. injecting onto the interceptors/aspects
instead of writing a container explicitly to do all the work and making use
of the MDR within the aspect.
There is a simple example (pre-MDR) of this in the jboss-jca prototype.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168445#4168445
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168445
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