Imo, also the logic gets more natural. Saving an entity (eg an order), will practically always mean starting a new order-process. By putting the save-entity and start-process instance operation together, you get something that is very natural to develop and maintain. I’m speaking out of real-life experience here.

Regarding the business object state problem. This is something I have encountered many, many times. In fact, it is my opinion that every BPM project get to this questions at a certain point in time. So, I have a very clear answer for you:

The state of a business object should always be maintained in the business object itself. There is no need to duplicate this in the workflow (duplicate data is never good). Every process revolves around a certain object. And every object always has a unique ID:

* An order process revolves around an order (orderId)
* A jira-like workflow revolves around a project (projectId)
* …

In jBPM there is the concept of a ‘business key’. This key is a process-global unique value and every process instance can (and should!) have a business key. This means that process instances can uniquely be found once you know the business key.

* Give me the process instance for order 15987
* Give me all the tasks open for project 54
* Give me all the tasks from orders that are in the state ‘submitted’ -> select first the ids of the orders, than the processes.

Altough, there is not much literature around this concept, all the jBPM team members agree that using a business key:

1) simplifies your development a lot
2) It gives you great performance (put an index on the business key column and that’s it)
3) Is a simply a BEST PRACTICE when using jBPM

Trust me, I’ve used jBPM before the business key concept was introduced and once you get a lot of processes writing queries was just hell.

Mmmm, while writing this answer I realized that I better should blog about this in the close future. Many people could benefit from this knowlegde. Thanks for triggering me, Yuri !

The “PAO” pattern is not a bad idea of a term to call this approach. Aervices should be stateless by thier nature and when they interact with workflows, they communicate with the outside world.
Example: the save() method of a service starts a new process instance which in turn has a verificaton task. As soon as this proc.instance reaches that task, a new task item appears in the work list of an employee who completes that task (i.e. client app calls service method verify(), which again signals the process to go on) and the workflow runs on to the next node.

Thus the complete state management is independant from the service.

Another interesting point to hear your opinion on would be, is it a good practice to save the state of the object (for example pending-submitted-accepted-removed) not only in the workflow but in an attribute of the business objet itself. If your business object is completely unaware of the workflow it is used in, it is very hard if not impossible to make queries against such objects in order to, say, find all objects in the archived state. If the object itself has no idea of its state, you have to query the associated process instance each time you want to get its state, which means pretty bad performance. Have you had similar requirements in your projects?

Both are certainly valid approaches. The ‘BPM layer’ approach is indeed a more classical way of looking at the problem. I wouldn’t necessarily see this layer ‘on top’ of the existing service layer, but as a integral part of it. Eg as you’ll see in one of the next articles, my ‘TicketService’ is conceptually on the same layer as the rest of the services. This ticketServices then gives you CRUD like operations, but then for workflows (ie start, stop, etc.).

The second approach you mention can mean a boost in productivity, if you choose the granularity of the subactivitities of the workflow fine enough. Imo, it is completely valid to eg start a new workflow when you do a save operation of some entity in some service.

This way, workflow is not used as a separate component in your design, but as a integral part of your logic, what is a more natural design imo.

Regards

Joram