GRAFCET and resource state management

My idea on using GRAFCET as a coordination language was quoted by an article on infoq by Jean-Jacques Dubray. The author made a very interesting remark about how services, resources and business processes are tied together: resources are modeled as business objects which states are mutated by services. These services are then tied together using business processes. In this posting I would like to put forward an idea on how resources state management can be done with GRAFCET (Jean-Jacques proposes a solution using BPEL+BPMN+SOAP)

First I would like to emphasis that this is just another way of looking at the problem. It has it's own advantages and drawbacks (especially since this is just an unpolished idea at this stage)

One of the advantages of GRAFCET (and also JBPL and Petri nets) is the notion of tokens. Tokens is what actually mutates the state of a GRAFCET. A step with a token is active and a step without a token is not active. When a step is active, an action attached to the step is then invoked. [In your usual industrial setting, we would not evoke the notion of tokens because there is only one type (or color if you prefer the Petri net notation) of token at one time. In such a case it would be easier to argue in terms of active steps instead of tokens]

Now integrating the notion of colored tokens into GRAFCET (yes yes, colored tokens are not part of the IEC standard but having colored tokens is just like having GRAFCETs without colored tokens duplicated and runned in parallel), we can easily model a resource as a particular color of a token.

So now, a GRAFCET can model exactly the state-machine of a resource. In fact, with the notion of parallelism integrated within a GRAFCET, we can go beyond single active state state-machines: I.E. a resource can be in several states at the same time (imagine for example, a document is being reviewed by 3 different reviewers and thus would have three distinct state at the same time - Reviewed by A, reviewed by B, reviewed by C) and these parallel states can evolve as independently as needed but can also be synchronized at some point.

To accommodate this idea, the actions in a GRAFCET should be modeled as loosely coupled services that accept tokens, mutate the tokens' state and return the tokens back to the originating GRAFCET. Note that in such a case, the GRAFCET is not strictly centralized since actions can be distributed. [In fact, the GRAFCET itself can be distributed (Gemma + master slave architecture) but that's a topic for another day]. The tokens are actually "injected" into an action, prompting the action to start working and returned back (outjected? - borrowing from Seam framework) to the GRAFCET once the action is over.

Note: The token is actually passed around and therefore can contain data such as history, say for compensation. These data do not have to reside directly within the token, rather, the token's id can be used as a key to the data residing in some database somewhere.

Note2: An action in a GRAFCET does not necessarily have to be a computation. It can also be human intervention. A token can be passed to a web server that will take display the token (remember a token is a resource, like a document for example) on a user "task portal". The user can inspect the token, mutate its sate and click on "done" by which the token would be delivered back to the GRAFCET.

Note3: GRAFCET is a reactive system. I.e. a step is not active until a token is delivered to it. An action does nothing until a token is injected to it. Because of this, GRAFCET is ideal in long-running processes. It can be days before an action is done but that will not bother the GRAFCET a bit. In fact, the whole GRAFCET can be serialized and stored somewhere and deserialized back once a token arrives from an action.

Decoupling BPM and messaging

I was reading a post by John Reynolds asking why Java programmers hate BPM. The response from The Java community is mixed between "programmers don't hate BPM, they hate coding in XML" to BPM is a tool for managers, not programmers.

Here's my own take on why programmers hate BPM. My answer is, programmers don't hate BPM< they hate BPEL due to its complexity. Now why is that? after working with BPEL for a couple of years now, besides the usual "writting xml is not programming" reason (which I totally agree BTW) I suspect that there is a more sinister evil behind BPEL: mixing concerns which may or may not be congruent with each other. Specifically, mixing coordination and messaging.

Heck, one of the reason why the abomination that is BPELJ was introduced was to facilitate the transfer of Java objects through BPEL without going through XML serialization.

I really think the reason GRAFCETs are very successful in the heavy industry (for e.g. coordinating large scale manufacturing) is because GRAFCET is a pure boolean system (0 or 1). No messages are going through a GRAFCET. Now, this does not mean that messages are inexistant, they do, just outside of the so called "BPM".

This really facilitates GRAFCET design a whole lot. All the BPM needs to do now is, given the state and condition (which are boolean) of the BPM, an action is either fired or not.

I was wondering if "Boolean BPM" is not what is needed to do away with BPEL and allow for a simpler language like the GRAFCET to be used. (need to investigate this idea further). I wonder how this would effect, say, long running transactions within a BPM.

Note: I do a see a tendency towards this "Boolean BPM" ( especially in this discussion ). Several Jbossian were touting the new Drools rule engine integration into BPMs. Now, rule engine is very much a boolean system. So, maybe my thoughts are not that far off :)