1 In the beginning there were interactions. Then interactions formed conversations. There were more conversations from more interactions, filling the earth. Conversations were separated from non-conversations.1.1 This was the first day, when we first had conversations.
2 A conversation needs conversants. So it was said, ‘Let there be two or more conversants in each conversation.’ 2.1 Then conversants are separated from conversations, and so are called participants. This is how participants came about. And there was evening and there was morning, the second day.
3 Interactions in a conversation need be addressed at ports, to avoid confusion, since confusion was evil.3.1 It was said, ‘Let there be one or more fresh3.2 ports for each conversation.’ Ports are separated from conversations, and so are called channels. This is how channels came about. And there was evening and there was morning, the third day.4 It was said, ‘Let an interaction in a conversation be with an operator and values since it gives us both rigour and freedom.4.1 A decree therefore said:
An interaction consists of a channel, a participant who sends it, a participant who receives it, and an operator, and messages.This was the fourth day: it brought a decree for an interaction.
5 And it was said, ‘Let a conversation be thoroughly distilled and the result be separated from a conversation, called the signature of a conversation, and in it include the participants it uses, the channels it uses, and the paths a conversation can take, where a path can branch or loop or escape.’ Signatures of conversations were separated from conversations, and so were called protocols.5.1 Each conversation has a protocol, and obeys a protocol. This is how protocols first came about. Two conversations which have the same protocol are similar. Two conversations whose protocols differ are not similar.5.2 This is the fifth day: we now had protocols.
Comments: We covered a lot in this first post. Two more posts are enough. "Separated" means an idea is articulated as an independent concept, like from water we find liquid and coldness etc.
1.1 Separation of a conversation as an independent structure is the starting point of this whole design endeavour. Historically this was first done (perhaps) in cryptographic protocols and later in UML sequence diagrams as well as in message sequence charts, and with more type-theoretic inclination in session types.
2.1 It is assumed that even if a participant has two threads they are not to converse: you can use sub-conversation (and sub-participants) so this does not lose generality.
3.1 If Alice sends to Bob two messages in parallel and do not wish to incur confusion then Alice can send it to two channels at Bob and Bob receive them as distinct messages. Channels can be omitted from scribbling in some cases though they are always implicit in descriptions.
3.2 Here "fresh" means (like variables declared inside a block) each channel is made fresh for each run of a conversation.
4.1 If we wish to be without an operator use a default operator "send". The use of operators is to use them as labels when we abstract a conversation as a finite state automata. So it is good to use them. Scribblers may as well start very informally however: our language formally defines how we can be informally in different ways.
5.1 A protocol is extracted from a real conversation, distilling its fundamental structure as a finite state automata. A protocol should not contain any concrete expressions nor their evaluation since if so it is not "thoroughly distilled": it should only contain static structure and should still be able to check whether a real conversation follows a protocol or not just by checking its program text (this is the MDA part of the signature). A real "class model" (which we shall call "conversation model") will include a little more than this, but it is good first we fix the notion of signature, since unlike signature in OOPLs we do not have this idea explicitly beforehand.
5.2 Thus a protocol can be used for classifying whether two programs realising conversations are similar --- in other words we can check whether a program conforms to a conversation structure given by a protocol. A protocol is a way to classify conversations, just as a class is a way to classify objects.
[to be continued to the next post, moving to internal structure of conversation]
