[jbpm-dev] [Design of JBoss jBPM] - Re: meeting context

[tom.baeyens@jboss.com]

"heiko.braun at jboss.com" wrote : - ProcessEngine, Process, ProcessDefinition
  | - StartEvent (None, Signal, Message)
  | - Task (None, Send, Receive)
  | - EndEvent (None, Signal, Message)
  | - Gateway (Inclusive, Exclusive, Parallel)
  | - Process, Activity Properties
  | - Process, Activity Assignments
  | - Signal, Message
  | - SequenceFlow 
  | 

Indeed we need to go over those concepts and establish a common vocabulary.  

But the complexity of the process constructs does not have to influence the client APIs (and service APIs).

The concepts that are exposed in the Activity API do have a direct impact on what kind of process constructs you can build.  That exposes e.g. the tree of executions to an activity implementation.

"kukeltje" wrote : Basic things I did do with 'the api' are
  | - start a process
  |   | - end a process
  |   | - signal process to continue (either via default or supplied transition)
  |   | - set a variable
  |   | - read variable
  |   | - get a tasklist
  |   | - end a task
  |   | - get basic properties of a task/node/.... in a process instance (e.g. task.hasEnded())
  |   | - ...
  |   | 

This lists indeed the typical basic client API operations.  This is the most important interface to get right as this is the first interface that every project using jBPM will be using.  And it is unrelated to the complexity of the process constructs.

The client API can be developed in the simple-to-complex fashion.  Adding new capabilities typically does not influence the previous features that you've build.

The event listener API is used in most projects and activity API is only used rarely by our users.  But i agree that even for those API's it would be good if we could keep them minimal and stable.

For the activity API, the simple-to-complex development strategy does not prevent big changes to the public API.  Different forms of concurrency might lead to a different structure of the runtime data.  (e.g. changing the tree of executions in a map of activity instances).  Such changes have a big impact on the whole activity API and when such a change happens, you'll need to rewrite all the activities.

It is in that context that I have been building the PVM over the last two years: shaping the runtime data structure and verifying that all kind of process constructs can be build on top of it.

But no matter how long I worked on it and how much of these discussions I already had with the Bull people, I still think it is good to have these concepts reviewed and challenged in the group.

The discussions on process constructs should however not take up the full team meeting. Our history shows that out-of-the-box support for the different patterns/constructs has not been a critical success factor.  Still I want to improve a on that.  (we basically only miss the concurrency pattern that ronald mentions: unstructured forks and joins, which is easy to implement)

As mentioned before, apart from the process constructs capabilities, there are the rest of the API concepts like ProcessEngine, Configuration, event/signal/log,and so on.   Those things can even more use a good review and debate.

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

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