Alice -> Bob: integer;and examine it again from a different angle.
Alice -> Bob: string;
Suppose Alice and Bob are using some messaging service which usually delivers messages to the same target in the order they are sent but sometimes, if rarely, fail to deliver them in the sending order, even though it does guarantee (at some level of assurance) the delivery of a message.
So one day what happened is the following message delivery
- Alice's string, sent later, arrives at Bob first
- Then Alice's integer, sent first, arrives at Bob next
Buyer -> Seller: PurchaseOrder;
choice {
Buyer -> Seller: ConfirmPurchaseOrder;
} or {
Buyer -> Seller: CancelPurchaseOrder;
}
We are assuming the following business scenario:
- Buyer sends to Seller his purchase order (of type PurchaseOrder: consider this as an XML schema or a UML class model)
- Buyer then will either:
- confirm the purchase order by sending a document of type ConfirmPurchaseOrder or
- cancel the purchase order by sending a document of type CancelPurchaseOrder
Now suppose a preposterous delivery of messages occur between the initial "purchase order" and, taking the second choice, its cancellation: on that day, by some hiccup of a router or something, before a purchase order message arrives at Seller, its cancellation message has arrived. Then what Seller sees is:
- Seller obtains a cancellation of some purchase order
- Seller then obtains that purchase order
The answer is simple: because Seller is aware of the conversation scenario ("signature of a conversation") she is now in, she has safe knowledge that this first message is in fact a second-message-to-be which has arrived too early: so she saves this preposterous message and serenely waits for another message to arrive: and, when it does arrive, she can reorder them and start from processing the purchase order. In practice, such a reordering can of course be done by a runtime which manages conversations and associated message passing, insulating applications from troubles: or in some cases such a service can even be offered as part of a messaging service (does AMQP do this, now or in future, or should it be better left to runtime? John? Alexis?).
Above we are assuming the messaging service guarantees message delivery (up to some assurance), even though we can easily combine timer with it: in that case when Seller cannot wait any longer then she can simply time-out. We can think of other ways to treat different unexpected situations.
But in what way does this story of mix-up and re-ordering of messages have to do with signature of conversation? Well what we have been talking about is the use of the signature in the world of interaction: it allows you to expect what to come, and so it allows you to act on non-default situations in a methodological way. (Well by allowing you to expect, it of course also allows you to get disappointed, but you can at least be sure whether you should be pleased or disappointed, and if so you may also be prepared to deal with the latter case better than otherwise).
Such a use of signature is in fact close to how the signature for methods/functions is being used. Our simpler predecessor does not entail something as exquisite as reordering of messages, but it does allow you to interpret a datum you get, or check whether the datum you get is of the expected type or not. It allows you to expect, to make clear what is expected and what is not expected, and thus allows you to treat both cases in a principled way: you have no doubt (or you know how and when to have doubts and what kinds, which is the same thing).
This principle is also closely related with monitoring, as we shall discuss later.
So we have seen how a simple two-line scribbling can contain richness we may not have imagined. With his we end Matthew's examples on asynchrony. In the next post we move to another two-liner, contributed by Gary.
