protocol specifications and components adaptors philippe giabbanelli cmpt 894 – spring 2008

Protocol specifications and components adaptors

Philippe Giabbanelli CMPT 894 – Spring 2008

What where the motivations of Yelling and Strom?

Formal definition of the interfaces

We have related the concepts of Web Service Interface to a number of other work during last week’s presentation.

Today, we will see how it relates to the work of Yellin and Strom and add some more related works for eventual readings.

Related work

Software adaptors

1

Motivations Formal definitions Adaptors Related Work

• The whole idea is components trying to communicate together.

∙ How can we specify that two components will work together?

∙ What if two components are functionnally compatible, but their interfaces are not ?

We provide a specification and a way to construct adaptors so that components can speak together.

2


3

• Often, the relationships between messages are implicit in an application.

The Situation

• If you have an interface to specify it, it is clearer for the programmer how to use it, and you can check for compatibility (less errors).

• So, the idea of having a specification is not brand new. But there are always some things that are missing, and more or less things we can do…

∙ In CORBA, an Interface between A and B is just a set of procedures implemented in B and called in A.

∙ We need to know more about the order to send the messages!

∙ What if we want to specify that B can only send a particuliar message to A after it received another special one?

(more in ∙ « Regular types for active objets » by Nierstrasz ____ ___.___ ∙« Formalizing architectural connection » by Allen & Garlan)


4

• The interface by Yellin and Strom was new in the sense that:

The Situation

∙ it describes both what a component can send and receive

∙ we can easily check for compatibility of the composition

∙ do not require any new mysterious language or fancy settings : the protocol semantics can be on top on many languages

• The adaptors that they produce are also new in that they try to perform a protocol conversion while most things only do a data type conversion.

(for a review on the topic, refer to Wiederhold 1992 « Mediators in the architecture of future information systems »)

• Their interface is purely synchronous.


5

• Components communicate between each other via typed interfaces.

Principles of the Interface

• An enhanced interface specification is the collaborative specification, that specifies message exchange. It is made out of two parts.

Warning. In web service interfaces, we also have something called Signature Interface but it is different.

∙ Interface signature: set of messages that can be exchanged, type of the parameters, and whether it is a send or a receive message.

Their signature interface is more or less our consistency interface.

∙ Protocol: set of sequencing constraints. A finite-state grammar defines the orderings of messages.


6

Principles of the InterfaceSignature Interface Interface

Consistency Interface Interface signature

Protocol Interface Protocol

Web Service Interfaces Yellin & Strom

We are not alone on our island

trying to write a specification!


7

Principles of the Interface• We said that a finite-state grammar defines the orderings of messages.

• A production of this grammar (i.e. transition) is of the following form:

State ::= direction message → state

Symbolic name + for receive – for send

A message described in the interface signature

• Given a state, a message can only appear once for a given direction.

S1 : + M1 → S2 and S1 : + M2 → S3, then M1 ≠ M2

S1 : – M1 → S2 and S1 : – M2 → S3, then M1 ≠ M2

• For all protocol P, the collaboration begins on a unique initial state initP.

• This specification can tell us what we are allowed to send/receive.


8

Principles of the Interface• A protocol might terminate, or might not…

→ There can be final states with not outgoing transitions in this case.

• If we are in a state from which we can only send, it is a send state.

→ If we can only receive it is a receive state. Otherwise: mixed state.

• Let say that one component is in a state where it can send m, and the other one is able to receive m.

→ If the sender chooses never to send m, it’s not working very well!

→ The liveness asumption considers that if we are at a state with a send transition, then we will use this transition at some point.


9

Principles of the InterfaceLet say that we are doing

auctions.

You want the item: you

raise the prise.

Auctioneer

bidders

The auctioneer has an instance of the interface for each bidder.

The process begins with the auctioneer sending a newItem

message with an ID to use to bid.

The auctioneer informs the bidder about the bid with an update.

When a bid is received, we evaluate it: reject or accept.


10

Asynchronous vs Synchronous• If we are asynchronous, a component can send a message m whenever it is in a state with an m transition. It does not know the state of the other component. Thus, each component has a queue for messages.

• It is not easy to reason about asynchronous system, and it has been shown that properties such as deadlock are then undecidable.

• In the synchronous case, we send a message only if the receiver is ready to accept it.

• The finite-state machine for each protocol advance synchronously. Easier to reason about, no queue: the author chose this one!


11

Toward compatibility• Given a protocol P, we will use a shortcut to denote the transitions:

s : m → s’

• The function Polarity(P, m) will return + or – whether m is a send or a receive message.

• A collaboration history is a trace of the collaboration between two protocols P1 and P2, i.e. a run in the two automata taken together:

α1 → m1 α2 → m2

∙ Each α is a (s, t) where s is a state of P1 and t a state of P2

∙ The initial state is α1 = (initP1, initP2)


12

Toward compatibility

• A collaboration history is a trace of the collaboration between two protocols P1 and P2, i.e. a run in the two automata taken together:

α1 → m1 α2 → m2

• We can have a transition from αi = (s, t) to αi+1 = (si+1, ti+1) if:

There is a transition si : mi → si+1 in P1

There is a transition ti : mi → ti+1 in P2

Polarity(P1, mi) ≠ Polarity(P2, mi)

• The meaning is that one automaton is sending a message to the other one. It sent the message: it goes in a new state. The other automaton receives the message and also goes in a new state.


13

Toward compatibility• All the traces that can occur if P1 and P2 collaborate are Collabs(P1, P2).

∙ Every prefix (i.e. the first steps) of a collaboration history is a collaboration history. After all, that’s just a set of steps starting from the initial state.

• P1 and P2 do not have any unspecified receptions if when P1 reaches a state where it can send a message, then P2 is in a state to receive it.

∙ In other words, there exists a collaboration history where this message is exchanged at some point.

• If for all collaboration history either it ends with final state or there is another collaboration history one that can keep going, then protocols P1 and P2 are deadlock free.


14

Toward compatibility

• Two protocols are compatible if they have no unspecified receptions and are deadlock free.

• Thus, the algorithm to check if two protocols are compatible is easy.

• This solves the common question of compatibility. The other common one is about subprotocol: when is a protocol a ‘sub-protocol’ of another?

∙ P’ is a sub-protocol if it has the same initial/final states, with maybe an additional set S of vertices with corresponding new transitions.

• As usual, if P’ is a subprotocol of P and P is compatible with Q then P’ is compatible with Q (subsituting P’ by P is therefore acceptable).


15

Principles of adaptors• Let say that I have a very nice lens for an old camera.

• Now, I buy a new camera and I would still like to use my lens.

• Sadly, physically the camera have different « diameter »: I need an adaptor. We get rid of the ‘interface difference’ and keep the functional.

An adaptor is a piece of code that sits between two objects and compensates for the difference

between their interfaces.


16

Principles of adaptors• All messages exchanged by the two components to adapt will go through the adapter.

• An adapter is based on a finite-state machine, that we also allow to perform simple actions on transitions. Formally, it is made out of:

∙ a set of states

∙ a set of memory cells. Each cell has a type and holds the content of a parameter received in a message. ∙ a set of rules, based on states and memory cells.

write a parameter’s value in a cella written cell is called ‘valid’

values of the parameters to send

forget the content of a cell


17

Limitations of adaptors• An adaptor can store only one copy of any parameter.

• The situation where one protocol send a number of messages before receiving messages from the other one cannot be represented.

• Having more memory cannot solve that: a protocol can send an unbounded number of messages that we would have to store, and it would lead to undecidability on some properties.

• Good properties of adaptors:∙ we can check that every parameter that will be send has first been received (memory consistency)

∙ we can check if a parameter is used at most once (one-shot)

∙ the behaviour can be expressed with a pattern, and we can check if a behaviour violates a pattern.


18

Creating adaptors• Let say that we have a declarative specifications relating parameters and messages in the protocols we want to adapt…

If we submit it to a program, it should tell us if it is duable. If so, then it can do it for us.

• The set of rules defining the specification has to be written in a special syntax that shows well the constraints.


19

• There are four things in this paper/area of research:

∙ adding a specification of behaviour/communication to interfaces

∙ checking for compatibility of those specifications

∙ generating adaptors

∙ composition of components

• A language called Rapide models the architecture of a system made out of many components. It has an execution model « which captures distributed behavior and timing as precisely as possible ».

(Specification and Analysis of System Architecture Using Rapide, Luckham, Kenney, Augustin, Vera, Bryan and Mann, 1995)

• A path expression gives sequencing constraints on method invocations.(The Specification of Process Synchronization by Path expression,

Campbell & Habermann, 1974)


19






• There is a litterature on communicating finite-state machines. However, under these models, a protocol sending a and receiving b would be compatible with another one sending b and receiving a.

(On communicating finite-state machines, Brand & Zafiropulo, 1983)

(On the progress of communication between two finite-state machines, Gouda & Manning, 1984)


19






• A language called NIMBLE allows programmers to express mappings between « the client invocation of a function and that invocation of the server ». It can convert the type of parameters, their orders, and specifies default values for missing parameters.

(Module reuse by interface adaption, Purtilo & Atlee, 1991)

• NIMBLE is a translation of objects. There are also works where protocols are used to specify interfaces; then, we give a specification to define the relation between protocols and we get an adaptor.

(A synchronization model for protocol conversions, Shu&Liu 1989)


19






• Allen and Garlan defined interfaces for components based on finite-state protocols in a more general model.

(Formalizing architectural connection, Allen & Garlan, 1994)


19






• Kramer has developped protocols based on automata and theory of concurrency, having some work on reachability problems and a tool named Tracta.

(Behaviour Analysis of Distributed Systems Using the Tracta Approach, Giannakopoulou & Kramer & Cheung, 1999)

• Plasil has a protocol in three layers (not very clearly separated).(Behaviour protocols for software components, Plasil & Visnosky, 2002)

• Canal worked on extentions of Corba specifying sequences of calls.

Article used for this presentation

Protocol Specification and Component Adaptors (Daniel Yellin and Robert Strom, ACM Transactions on Programming Languages and Systems Vol 19 No 2, March 1997 )

protocol specifications and components adaptors philippe giabbanelli cmpt 894 – spring 2008

Documents

work of yellin

motivations of yelling

collaborative specification

protocol specifications

protocol semantics

orderings of messages

protocol conversion

new mysterious language