Protocol specifications and components adaptors

1
Protocol specifications and components adaptors
Philippe Giabbanelli CMPT 894 Spring 2008
2
We have related the concepts of Web Service
Interface to a number of other work during last
weeks presentation.
Today, we will see how it relates to the work of
Yellin and Strom and add some more related works
for eventual readings.
What where the motivations of Yelling and Strom?
Formal definition of the interfaces
Software adaptors
Related work
1
3
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
4
Motivations Formal definitions
Adaptors Related Work
The Situation
Often, the relationships between messages are
implicit in an application.
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)
3
5
Motivations Formal definitions
Adaptors Related Work
The Situation
The interface by Yellin and Strom was new in
the sense that
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.
4
6
Motivations Formal definitions
Adaptors Related Work
Principles of the Interface
Components communicate between each other via
typed interfaces.
An enhanced interface specification is the
collaborative specification, that specifies
message exchange. It is made out of two parts.
Interface signature set of messages that can
be exchanged, type of the parameters, and whether
it is a send or a receive message.
Warning. In web service interfaces, we also have
something called Signature Interface but it is
different.
Their signature interface is more or less our
consistency interface.
Protocol set of sequencing constraints. A
finite-state grammar defines the orderings of
messages.
5
7
Motivations Formal definitions
Adaptors Related Work
Principles of the Interface
Signature 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!
6
8
Motivations Formal definitions
Adaptors Related Work
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.
7
9
Motivations Formal definitions
Adaptors Related Work
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, its 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.
8
10
Motivations Formal definitions
Adaptors Related Work
Principles of the Interface
Let say that we are doing auctions.
You want the item you raise the prise.
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.
Auctioneer
The auctioneer informs the bidder about the bid
with an update.
bidders
When a bid is received, we evaluate it reject or
accept.
9
11
Motivations Formal definitions
Adaptors Related Work
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!
10
12
Motivations Formal definitions
Adaptors Related Work
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
a1 ? m1 a2 ? m2
Each a is a (s, t) where s is a state of P1 and
t a state of P2
The initial state is a1 (initP1, initP2)
11
13
Motivations Formal definitions
Adaptors Related Work
Toward compatibility
We can have a transition from ai (s, t) to
ai1 (si1, ti1) if
There is a transition si mi ? si1 in P1
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
There is a transition ti mi ? ti1 in P2
Polarity(P1, mi) ? Polarity(P2, mi)
a1 ? m1 a2 ? m2
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.
12
14
Motivations Formal definitions
Adaptors Related Work
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, thats 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.
13
15
Motivations Formal definitions
Adaptors Related Work
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).
14
16
Motivations Formal definitions
Adaptors Related Work
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.
15
17
Motivations Formal definitions
Adaptors Related Work
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 parameters value in a cell
a written cell is called valid
forget the content of a cell
values of the parameters to send
16
18
Motivations Formal definitions
Adaptors Related Work
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.
17
19
Motivations Formal definitions
Adaptors Related Work
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.
18
20
Motivations Formal definitions
Adaptors Related Work
There are four things in this paper/area of
research
adding a specification of behaviour/communicatio
n 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
21
Motivations Formal definitions
Adaptors Related Work
There are four things in this paper/area of
research
adding a specification of behaviour/communicatio
n to interfaces
checking for compatibility of those
specifications
generating adaptors
composition of components
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
22
Motivations Formal definitions
Adaptors Related Work
There are four things in this paper/area of
research
adding a specification of behaviour/communicatio
n to interfaces
checking for compatibility of those
specifications
generating adaptors
composition of components
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.
19
(A synchronization model for protocol
conversions, ShuLiu 1989)
23
Motivations Formal definitions
Adaptors Related Work
There are four things in this paper/area of
research
adding a specification of behaviour/communicatio
n to interfaces
checking for compatibility of those
specifications
generating adaptors
composition of components
Allen and Garlan defined interfaces for
components based on finite-state protocols in a
more general model.
(Formalizing architectural connection, Allen
Garlan, 1994)
19
24
Motivations Formal definitions
Adaptors Related Work
There are four things in this paper/area of
research
adding a specification of behaviour/communicatio
n to interfaces
checking for compatibility of those
specifications
generating adaptors
composition of components
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.
19
25
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 )