Friday 20 July 2007

Poor Buyers' Protocol: another kind of interleaving

I did not wish to present this protocol so early, if at ever. No. What was our previous example? Well it was a call back and its generalisation. My idea is to refine it further to reach a fully fledged financial protocol from fpML.

As an intermediate one, I could have for example used the Buyer-Seller protocol. That is already classical. But poor buyers' protocol --- this one will never have a proper status in the History of Conversation Protocol.

No it will not have any kind of status. But it's a simple example one can fully comprehend and it has its own subtleties --- and it does tell us something about interleaving. It is so to speak the other extreme of interleaving, in contrast to "hotel search" example. So I decide, Caveat Emptor, here it goes:

Two buyers, Buyer1 and Buyer2, wish to buy an expensive book from Seller by
combining their funds. After agreeing that they enter a protocol and establishing a link, Buyer1 sends the title of the book to Seller, Seller sends to both Buyer1 and Buyer2 its quote, Buyer1 tells Buyer2 how much s/he can pay, and Buyer2 either accepts the quote or receives the quote by notifying Seller.


I put the sequence diagram presentation (due to Marco) on the right-hand side. Simple-minded as it looks, this protocol has one basic form of interleaving of conversations. To see this let's see how many bilateral conversations this protocol consists of:
  1. Between Buyer1 and Seller
  2. Between Buyer1 and Buyer2
  3. Between Buyer2 and Seller
Well, when Seller sends out its quote to Buyer1/2, perhaps this may be counted as another unit. Anyway these different conversations are interleaving in this protocol. A basic point I wish to communicate in this example is that: each of 1,2,3 above does not make sense by itself. So this is not interleaving of several conversations. The whole interaction sequence does not make sense in its bilateral decompositions: they as a whole create a single conversation.

So in such a case we do not call this interleaving since after all this as a whole makes up one protocol, one conversation. So we are forced to capture the whole of this structure as one abstract unit.

Function signature can add callback (Java programmers are already adding exception to it). And certainly in some cases interleaved conversations can be ignored --- you still just have a function signature as your basis, you wish to forget about it.

But in interaction this is different. Sometimes you need to capture a chunk of multistep (and even multparty) collaboration scenario in one go ---- that is a unit of abstraction, that is a unit of modelling. And this unit is reached as a gradual elaboration of that familiar notion of static structure in modelling and programming, the class/method signature.

So today's story ends here. I know I have not fully conveyed what this paradigm shift is telling us. I mean, I have here something I wish to tell, but perhaps it has not made a truly clear picture I wish to make.

But that is not to be avoided. Through conversations we shall reach a good understanding. Today just a problem presentation: what is this? how can we use this for our abstraction?