Hierarchical State Machines

[Gary Brown]

This topic came up on the call a couple of days ago. Looking at the example that was presented, it would appear to me that the only way to solve this would be to define a mechanism equivalent to traditional exception handling - at least that is what it would appear like within the local projections. It also means that probably the current 'interruptible' construct may not satisfy current requirements, except for possibly the most basic cases.

The reason I am very interested in having this capability supported in the language is that higher level modelling languages (e.g. BPMN2, CDL) as well as endpoint implementation languages (e.g. Java, WS-BPEL, etc) have support for this type of structure - and therefore it is required by Savara, which uses Scribble as an internal canonical representation between these modelling and programming languages.

So thought it would be a good idea to start a discussion around the various issues that need to be addressed. Before discussing the points, I just wanted to mention that from my perspective, in terms of the technologies/environments I work with, a communicating system is a network of interacting participants - i.e. with point to point connections established based on the emerging conversation, rather than all participants being in some form of fully connected network. So with this context in mind.....

The action of an interrupt will most likely be initiated by a single participant and communicated to another participant (e.g. to cancel a transaction). The effect of that interrupt communication may then be propagated to other relevant parties based on the relationships established through that network, and also based on a need to know (i.e. unaffected participants should not need to be informed).

The main issue appears to be ensuring that both these parties are synchronized to ensure they take the same subsequent path.

Two common cancel patterns are: (we need to collect others that may be relevant)

(a) termination of a stream of events - so A initiates communication with B, B then sends a stream of events to A until A sends a message to cease the stream. There are two ways this may end, either:

- the stream will continue until B acts on the cancel and no longer sends any messages. A simply carries on, after it has sent its cancel message, in which case something would need to silently ignore the messages from B until they stop

- B will eventually respond with a message indicating that it acknowledges the cancel, in which case there is a more predictable window in which messages should be disgarded. Its possible that this could be a constraint - i.e. that an acknowledgement is always required to ensure synchronization.

Atleast with this scenario, B will remain in the interrupt region until it gets a message from A.

(b) Attempt to cancel a transaction before it completes

With this scenario, its possible that B would complete and move out of the interrupt region before it has received its message from A. However maybe this is just another case where a message may need to be ignored (whether by a monitor or endpoint implementation deciding whether to forward the message up the stack).


The other issue is ensuring compensating actions are only taken when necessary. For example, if a cancel is sent to a broker, and that broker has not yet communicated with the supplier, then the supplier does not need to be informed of the cancel, and the cancel should be confirmed. If however the supplier has been contacted, then the broker must first attempt to cancel the transaction with the supplier, before informing the buyer (i.e. confirming the cancellation or the original transaction if the cancel was too late). This shows the hierarchical nature of the interrupt mechanism, which is supported in business process languages typically using fault handlers, and in programming languages using exception handling. Both these languages also provide ways to propagate the faults/exceptions as a way to progressively handle the same interrupt at the multiple levels.

I believe there are three areas that need to be tackled:

(1) Description - needs to be clear, and as mentioned above the try/catch exception handling style could be a good model to follow

(2) Type checking - define a set of rules that need to be followed - this could be based on the patterns that are identified, to constrain what can be specified.

(3) Monitoring semantics - which may just be a case (in combination with appropriate type checking rules) of understanding when ignorable messages may occur. For example, in the case of (b) above, where participant B receives a cancel message after it has already sent the confirm - the semantics could be that when leaving an interrupt region without interrupt occurring, then any potential message from the cancelling party should be added to an ‘ignore’ list until a subsequent communication is received from the cancelling party showing that it has correctly synchronised with the normal path.


This approach of ignoring irrelevant messages is how an endpoint implementation would deal with such a situation, so it could provide an answer to how monitors should behave. The other approach may be to use hidden control messages to handle synchronization, but I would like to explore the alternative as it may make reusing legacy services (with no understanding of conversation/session types) easier - i.e. making adoption of this technology easier.

Sorry for the long initial post - but wanted to kick off the discussion, even if it won’t be address in the current version of scribble.

Regards
Gary

[Nobuko Yoshida]

Dear Gary,

Thank you very much for your detailed post. 

We can discuss on Thursday the three points you list. We think the exceptions and interrupts are the key issue for  Scribble. 

Three points you listed, (a) description, (b) type-checking (we believe this is also related to well-formed checking) and (c) monitoring semantics are the keys. For me, it sounds you are talking runtime implementation as (c) as your point is also valid for the static checking. 

As far as I know, Romain and Malo talked a lot with Kohei (around last April) and Rumi also thought about a lot. 

At this moment, since we do not need more complicated exception for OOI usecases and we have not reached a conclusion (agreement) yet, we keep a simple exception in Scribble for the first version. 

One remark: 

The other issue is ensuring compensating actions are only taken when necessary. For example, if a cancel is sent to a broker, and that broker has not yet communicated with the supplier, then the supplier does not need to be informed of the cancel, and the cancel should be confirmed. If however the supplier has been contacted, then the broker must first attempt to cancel the transaction with the supplier, before informing the buyer (i.e. confirming the cancellation or the original transaction if the cancel was too late). This shows the hierarchical nature of the interrupt mechanism, which is supported in business process languages typically using fault handlers, and in programming languages using exception handling. 

"The invitation" is considered and formalised by Tzu-chun and Romain. The last discussion with Kohei is how to write invitation in Scribble and  this should be combined with exceptions in future. We can surely talk on Thursday. 

Best regards, 

Nobuko Yoshida 

--
You received this message because you are subscribed to the Google Groups "scribble-lang" group.
To post to this group, send email to scribb...@googlegroups.com.
To unsubscribe from this group, send email to scribble-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/scribble-lang?hl=en-US.