Process Engines, usually BPEL engines or Workflow engines, execute proces-steps based on a predefined process. This is a sound practice, however not for long-running processes.
Long-running processes have the nasty habit to change over time. This will affect all active and running processes. Why? Because the process engines usually store the process state and corresponding data in a persistence store. The effect of a change in the process requires you to migrate all those saved instances, unless you are able to leave them running the old version of the process.
A different approach is a State engine, where the next step in the process is not determined by the predefined steps in the process, but on the current state of the subject and the event that has been received. This leads to more decoupling between process and services. However, so far I haven't seen any Process engine that works like this.
In theory there's not much difference between the two approaches. You could state that a process engine uses implicit states as defined in the process, whereas a state engine uses explicit states. The end result could/should be exactly the same. A state engine would give some more flexibility, but also needs more functionality to be able to have an overview and control of the process.
Anyone knows of any tool that works like a state engine? I'd really like to know.
Hi Mike,
ReplyDeleteA Way you certainly know to use BPEL Engines as a state Engine is to split long-running process into continous sub processes. You can then use a JMS Queue to represent states of the process between sub processes. This Way if a part of the process change, running processes instances take benefit from updates.
However, it's just a workaround, it's not really a state engine.
How does this work when you decide to change the definition of your state engine? And what about petri-nets? Are they just a different way to chart state diagrams, or are they different. Is there a executable petri-net implementation?
ReplyDeleteA state engine uses both the state of the subject as well as the event to determine the next action. It's as if you take a petri-net and interpret it. Changes to the action taken for a event/state combination does not affect the engine itself, unless actions disappear - then you might have a problem. But it's a lot simpler then in-flight migration of processes.
ReplyDelete@Adrien: yes, that's a good way to do that, but I'm really looking for a standard solution instead of a workaround. Thanks for the feedback, though!
Hi Mike,
ReplyDeletehave a look at JBoss jBPM. This is a nice and small state machine. Currently they try to add BPEL to it, but I think this isn't the right way for them. As a state machine, jBPM works great.
Torsten
Mike,
ReplyDeleteI posted few examples of state machines which could be applicable to SOA at State Machine Gallery
www.StateSoft.org
-Janusz