[jbpm-dev] [Design of JBoss jBPM] - Re: Making the BPM API more generic?

[tom.baeyens@jboss.com]

"KrisVerlaenen" wrote : 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

PVM contains 3 different API views:
1) client
2) activity implementation
3) event listener

In its current shape, Thomas' BPM API has the same scope and target then the client API part (1) of the PVM.  I think this is to be considered a learning excercise in Thomas' start to work out the BPM product requirements.

But to answer your question, I think it is always good to compare each other's work.  Are your API docs online ?  A link would be great.

PVM API lastest version is here: http://docs.jboss.com/jbpm/pvm/api/  This is still in flux, but the next version to a couple of weeks will be pretty much stable.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168469#4168469

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168469