"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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...