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.