Handling timeouts and the cancel pattern

[Gary Brown]

In the previous version of the language, we had the concept of a global escape - a construct that enabled the normal flow of behaviour within a scope to be interrupted, to jump to alternative behaviour. Although this construct was useful for describing some common interaction patterns, such as a timeout or the cancel pattern, it has proved difficult in terms of defining a theoretical basis.

In the new version of the language there is the interruptible concept - however this just defines how the protocol can be prematurely terminated, and does not allow for subsequent interaction behaviour depending upon how the main scope was interrupted.

While looking at the differences between the scribble language versions, and what is required for savara (and more specifically BPMN2 support), it got me thinking more about what is actually required.

The main (and possibly only) use cases for this type of construct are the ones outlined above:

(a) timeout - where the initiator of a request/response interaction does not receive the response within a predefined time
(b) cancel - where the initiator of a request/response interaction wishes to cancel the interaction with another party(s) before it has received the response

In both of these cases, we are dealing with a single request/response interaction and just two parties (not sure if either pattern would work with multiple recipients, as only a single response would be expected). Although the receiver may perform other interactions prior to returning the response, the behaviour of interest is just between the two parties.

An example (for now in pseudo notation, and ignore the keywords as these are just placeholders):

do { // Request block
    A->B req;
    B->C m1;
    C->B m2;
    .....
} normal { // Response block
    B->A resp;
    .....
} interrupt { // Cancel block
    A->B cancel;
    .....
} timeout { // Timeout block
    A-> (potentially any role)
    .....
}

Some rules:
- request block starts with community from sender to receiver
- request block cannot include any further interaction (in either direction) between sender and receiver
- response block MUST start with interaction from receiver to sender
- cancel block MUST start with interaction from sender to receiver
- the behaviour in the cancel and timeout blocks must conform to the same wellformedness rules as parallel (needs more thought, but essentially needs to cater for the fact that the request block may continue to execute until the relevant roles receive a communication associated with either the interrupt or timeout blocks that indicate otherwise)
- if cancel or timeout blocks activated in sender, then in terms of monitoring sender, the monitor must remain open to receiving a normal response, until either the session ends or the sender receives any other message from the receiver
- zero or more interrupt blocks could potentially be defined
- only a single optional timeout block should be defined

One complexity not handled above is if B returns a response and continues in the Response block, while A has sent a cancel. Possibly the only way to address this is to require a further confirmation interaction from the other party. For example, it would be reasonable to expect that a cancel request would need to be acknowledged. Therefore the 'sender' would either receive the normal response, or cancel confirmation, to confirm which path should actually be taken by the sender.

Another complexity is how to represent priority. For example, does the normal or cancel path take precedence if they both occur? One option would be to define the normal and interrupt paths in the same way, and the order in which they are specified determines which takes precedence. Alternatively, as described in the previous para, the cancel paths require acknowledgement, and therefore the normal path always takes precedence.

[santosh.s...@ncl.ac.uk]

I was reading about Scribble and came across Gary Brown's
notes on 'Handling timeouts and the cancel pattern' in the Forum. I am 
not addressing the timeout and cancel issues raised there
(although I have ideas on that topic), since I feel that a more basic
issue needs attention first. I think  in Scribble (or any other
choreography description lang) you need to expose exceptions at
messaging level...... a message send should return 'success' or
'failure(...params...) and the need/assumption concerning state
alignment should be explicitly stated. Explanation follows:

I will concentrate on B2B messaging (sendPO, Order, Invoice etc like 
messages, referred to here as B messages) as Buyer-Seller examples are 
frequently used for explaining Scribble features. In practice, B 
messages are really quite 'heavy weight' (lots of baggage re. 
authentication, non-repudiation etc) and a received message goes through 
a series of validations before it is finally handed over to the 
application for processing.  Such messages make use of eb-XML OASIS 
standard (there are other variations - e.g., RosettaNet, but differences 
are minor and can be ignored). Reliable, ordered delivery assumption by 
itself is not sufficient to fully describe the behaviour of a B message. 
A B message protocol uses reliable messaging and is composed of the 
actual message itself (request message from the sender) followed by one 
or more ack messages, from the responder, necessary for 'state 
alignment'. Ack messages could be: Acknowledgement of 
Receipt/Notification of Reception Failure ("message delivered/not 
delivered to the application layer") followed by Acknowledgement of 
Validity/ Notification of Validation Failure, where validation  could 
involve 'checking that business document is a well-formed document'.
In effect, sending of a B message needs to admit the possibility of a 
‘reliably’ delivered message getting rejected at the application level, 
say due to validation failure. Thus a B message send should capture the 
following ‘atomic’ intention:



The sender needs a timely assurance that the sent document will be 
processed by the receiver, and the receiver needs the assurance that if 
it accepts the document for processing, the sender will be informed of 
the acceptance in a timely manner; if such assurances are met then a 
success outcome is returned to both parties; in all other cases, the 
interaction returns a failure exception to both the parties. This way 
states are aligned  (that is sender and receiver have identical notion concerning the fate of the message). (Note: the eb-XML standard actually has 
bugs/shortcomings that can cause state mis-alignment, but the intention 
of the B message protocol, which they call ‘business transaction’ is as 
stated here).

The above behaviour can be modelled in BPMN2 (which is really very 
general purpose) but not in Scribble (I think).  I hope this is making 
some sense.....



Santosh

[Gary Brown]

Hi Santosh

I think there may be two ways to address this:

1) If we view the business protocol at a high level, then essentially they are simple message exchanges (e.g. send purchase order) and can be described in that way. This can be thought of as an abstract description, with the complex message exchanges that go into 'implementing' that message exchange, as implementation details.

This is no different to a described message exchange (e.g. send purchase order) that may be affected by a network fault.

The advantage to looking at the protocol in this way is that it is then portable across different environments - but just with different "on the wire" implementations.

2) We could encode the ebxml exchanges as a protocol definition, and using generics, instantiate the particular protocol instances based on a particular message type.

Regards
Gary

--
You received this message because you are subscribed to the Google Groups "scribble-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scribble-lan...@googlegroups.com.
To post to this group, send email to scribb...@googlegroups.com.
Visit this group at http://groups.google.com/group/scribble-lang.

For more options, visit https://groups.google.com/d/optout.