Ciclo di seminari su Automatic Software Adaptation

Protocol Specifications and Component AdaptorsYellin and Strom, ACM Transactions on Programming Languages and Systems,

Vol.19, No.2, March 1997.

Corrado Zoccolo

Dipartimento di Informatica, Universita' di Pisa

Outline

� Subject of the work

� Component composition model

� Enhanced Interface Specification

� Protocol semantics, compatibility and implementation

� Results and comparison

� Adaptors

� definition, compatibility, properties and limitations

� (semi)automatic synthesis

� Results and comparison

Subject of the work (1)

� Problems to address

� how can we check whether a particular component interface is a valid mate of another

� how can we provide adaptors to enable the compo-sition of functionally compatible components that are not compatible at the interface level

Subject of the work (2)

� Proposed solutions

� Enhance interface specifications to include protocols

� Provide a simple semantics for protocol compatibility

� Define the notion of a software adaptor that allows the composition of protocol-incompatible comp.

� Define an high-level interface mapping language that can be used to automatically synthesize an adaptor for protocol-incompatible components

Component composition model

� Components interact via typed interfaces

� A component can expose multiple interfaces

� Each connection is between exactly two parties

� Connections are bidirectional

Comp A

Comp C

Comp Bt0

t1

t1

t0

Enhanced interface specification

� An enhanced interface specification consists of

� the interface signature

describes the set of messages that can be exchanged, with the types of parameters and the direction (send or receive)

� the protocol

describes a set of sequencing constraints, which define legal orderings of messages by means of a finite-state grammar

the grammar is specified by means of a set of named states and a set of transitions, one for each message that can be exchanged in a particular state

Protocol semantics

� A protocol defines a finite state machine, with

� a set of states (with a distinguished initial one),

� transitions labeled by in/out-going messages

� no two equally labelled transitions from a single state

� a (possibly empty) set of final states

� Liveness assumption: a component won't block in a state that contains a send transition

� Synchronous collaboration semantics

Protocol implementation

� The message exchange between two components can be implemented in several ways:

� asynchronous vs. synchronous message passing

� immediate invocation vs. queued messages

� passive or active components

� If we have asynchronous message passing, in presence of mixed states, the synchronous semantics must be enforced using arbitrators

� pessimistic vs. optimistic arbitrators

Example of extended interface

Collaboration Reader1 {

Receive Messages {

read(x:Data);

};

Send Messages {

break();

};

Protocol {

States { Rec(init), Stop };

Transitions {

Rec: +read -> Rec;

Rec: -break -> Stop;

};

};

};

Collaboration Reader2 {

Receive Messages {};

Send Messages {

fwrite(x:Data);

fclose();

};

Protocol {

States { Wrt(init), Stop };

Transitions {

Wrt: -fwrite -> Wrt;

Wrt: -fclose -> Stop;

};

};

}; Cannot select target statebased onto the value

of a parameter

Protocol compatibility

� Two protocols have no unspecified reception iff:

� whenever a collaboration can reach the point where a protocol can send a message m, the other party must be willing to receive m

� Two protocols are deadlock free iff

� the collaboration ends with both protocols in a final state or it can continue

� Two protocols are compatible iff they have no unspecified receptions and are deadlock free.

Results and comparison

� Fast algorithm for checking protocol compatibility (can be integrated in type checking)

� deadlock freedom only between two components, not at entire system level

� Other works on component compatibility:

� Allen & Garlan; Magee, Kramer & Uchtiel; ... :

� express component behaviour by means of process algebras

� model checking to prove properties and deadlock freedom

� Inverardi & Uchitel :

� polinomial time algorithm to check deadlock freedom

References

1.A formal basis for architectural connection. R.Allen, D.Garlan. ACM TOSEM vol 6, n.3, July 1997, pp. 213-249.

2.Software Architecture Modeling & Analysis: A Rigorous Approach. J.Kramer, J.Magee, S.Uchitel. In Formal Methods for Software Architectures, LNCS 2804, Sept. 2003. pp 44-51.

3.Proving Deadlock Freedom in Component-Based Programming. P.Inverardi, S.Uchitel. Proceedings FASE 2001, LNCS 2029, Genova April 2001.

Software Adaptor

� An Adaptor is a piece of code that sits between two components and compensates for the differences between their interfaces

� Specification: an adaptor A is a tuple <SA,CA,RA>

� SA is a finite set of states

� CA is a finite set of typed memory cells

� RA is a set of state transitions + memory actions

Adaptor exampleCollaboration Reader {

Receive Messages { read(x:Data); };

Send Messages { break(); };

Protocol {

States { Rec(init), Stop };

Transitions {

Rec: +read -> Rec;

Rec: -break -> Stop;

};

};

};

Collaboration Writer {

Send Messages {

data(x:Data); eof();

};

Protocol {

States { Wrt(init), Stop };

Transitions {

Wrt: -fwrite -> Wrt;

Wrt: -fclose -> Stop };

};

};

Reader WriterAdaptor

EOF

Adaptor compatibility

� An adaptor is compatible with two protocols iff they have no unspecified receptions and are deadlock free

� The collaboration between P1,A and P2 has no unspecified receptions iff

� whenever A can send a message to Pi, it can receive it

� whenever Pi can send a message to A (and Pi is not in a mixed state) then A can receive it

� Deadlock freedom is a straightforward extension of the definition involving only P1 and P2

Limitations

� The definition given for adaptors allows the them to store only one copy of any parameter

� This limitation disallows the construction of adaptors compatible with some pairs of protocols

� compatible under the asynchronous semantics but incompatible under the synchronous one

� requiring some amount of buffering (>1)

� Even if we allow storing a finite number of copies, we can devise protocols for which no suitable adaptor exists

Properties

� Given a collaboration between two protocols and an adaptor, we want to be able to prove that some properties are always satisfied

� Memory consistency:an adaptor never reads from an uninitialized memory cell

� Parameter relationships:the adaptor maintains the correct relationship between the

parameters of P1 and those of P2

� Patterns of collaborations:causality relationships among messages sent and received,

expressed by means of a regular-expression language

Adaptor synthesis

� Given a concise declarative specification relating parameters and messages in the two interfaces

we want either

� automatically synthetize a well-formed adaptor or

� determine that no such adaptor exists

Interface Mapping

� A set of mapping rules

� parameter mapping rule:

� f(x1,...,xn)->p

� x->p

� parameter usage rule:

� one-shot(p)

� causality rule:

� forward m1 as m2

� if m0 then forward m1 as m2

� pattern (regular expression involving messages)

x, xi : parameter names or constants,p : parameter name,f : function name,mi : message names

Algorithm

� The synthesis algorithm constructs the adaptor in phases

� The first constructs the state space for the adaptor, beginning with the initial state and adding the states reached by every enabled transition

� Next phases will remove states in which unspecified receptions or deadlocks occur

� The algorithm terminates with

� a valid adaptor wrt the interface mapping

� or a null adaptor (iff no valid adaptor exists)

Negative adaptor example

Collaboration Reader {

Receive Messages { read(x:Data); };

Send Messages { break(); };

Protocol {

States { Rec(init), Stop };

Transitions {

Rec: +read -> Rec;

Rec: -break -> Stop;

};

};

};

Collaboration Writer {

Send Messages {

data(x:Data); eof();

};

Protocol {

States { Wrt(init), Stop };

Transitions {

Wrt: -data -> Wrt;

Wrt: -eof -> Stop };

};

};

Writer::data.x -> Reader::read.x; // Parameter mapping rule

one-shot(Writer::data.x); // Parameter usage rule

// Causality rules

forward Writer::data as Reader::read;

Cannot write themapping rule for

eof() -> read(EOF)

Adaptor example

Collaboration Printer {

Receive Messages {

printn(x:Data, n:int);

};

Protocol {

States { Rec(init) };

Transitions {

Rec: +printn -> Rec;

};

};

};

Collaboration Client {

Send Messages {

setCopies(n:int); print(x:Data);

};

Protocol {

States { NSt(init), Req };

Transitions {

NSt: -setCopies-> Req;

Req: -print -> NotSet };

};

};

Client::setCopies.n -> Printer::printn.n; // Parameter mapping rule

Client::print.x -> Printer::printn.x; // Parameter mapping rule

one-shot(Client::print.x); // Parameter usage rule

forward Client::print as Printer::printn // Causality rules

(!(Client::print)*.Client::print.!(Client::setCopies+Printer::printn)*.Printer::printn)*

Results and comparison

� First formal foundation for component adaptation

� Definition of a well formed adaptor

� Addresses (semi)automatic adaptor generation

� Some limitations (composition model, mapping, etc.)

� Other works on component adaptation

� Bracciali, Brogi & Canal :

� more powerful protocol and adaptor specification

� Inverardi & Scriboni :

� automatic generation of connectors which ensure system-level deadlock-freedom

References

1.Systematic Component Adaptation. A.Bracciali, A.Brogi and C.Canal. Electronic Notes in Theoretical Computer Science, Vol. 66 (4) (2002).

2.A Formal Approach to Component Adaptation. A.Bracciali, A.Brogi and C.Canal. Journal of Systems and Software, 2003.

3.Connectors Synthesis for Deadlock-Free Component Based Architectures. P.Inverardi, S.Scriboni. IEEE Proc. 16th ASE 2001.