Component Interaction in Distributed Systems

Nat PryceImperial College

np2@doc.ic.ac.ukhttp://www-dse.doc.ic.ac.uk/~np2

Architectural View

Components “package”

behaviour behind interfaces

Explicit component interactions

Explicit structure

Provided servicesRequired services

Current Middleware

• Single or limited set of interaction styles– Typically RPC or Object Invocation– Some ad-hoc additions (media streams)

• Using other interaction styles complex– Implemented in terms of provided styles– Obscures intent– Complicates design & documentation

• E.g: CORBA Event Service specification

“Open” Interactions

• System designers must be able to specify how components interact at the architectural level

• Specification must support:– System design...– System construction...– …and link the two

• Need a model of component interactions

Interaction Model

Asynchronous Messages

SynchronisationClient-sideAPI

Client-sideMessageInterface

Client thread(s)

SynchronisationServer-sideMessageInterface

Server-sideAPI

Server thread(s)

actionsactions

Client Endpoint Service Endpoint

Protocol independent of components’ implementations

Midas Example

namespace regent {namespace interact {

interaction Event< type T > {provide {

enable();disable();

};require {

event( T data );ack();

};

spec “FSP” {...

};};

};};

Message interface signatures:

• Messages are named & can have named, typed parameters

Protocol specifications:

• Valid message sequences• Communication patterns

Multiple notations

Compiling Midas Specifications

Midas Specification

M essage S etD eclara tions

Endpoin tD eclara tions

Specs &Properties

AbstractIn terfaces

D istribu tionSupport

Endpoin t S tubs(b ind ing support)

P ro toco lVa lidators

Endpoin tC lasses

Binding

binding

back-binding

Endpoints bound with direct pointers to abstract message interfaces

Distributed Binding

Transport Connection

Client Address Space Server Address Space

ServiceProxy ClientProxy

Binding Establishment

C lient A ddress S pace S ervice A ddress S pace

transport reference

ClientEndpoint

Client Proxy

ServiceEndpoint

InteractionSAP

TransportSession

TransportSession

TransportSAP

ServiceProxy

Connection

creates

creates

Transport Protocols

• Proxies and SAPs interface with transport framework.

• Platform independent API to communication protocols.

• New protocols constructed from components.

• Protocol stacks constructed dynamically at run-time.

reliable

cod

udp

ip

Modeling & Analysis

Clientendpoint

Transport connection

Service endpoint

Component model

Component model

• Interaction protocol modeled using FSP– Process calculus - labeled transition systems– Interaction protocol can be analysed mechanically– Model architectures of interacting components

Modelling Constraints

• Properties define valid message sequences over a single binding

• Property for each party, not the entire protocol– Allows various transports

• Does not model protocol “mechanics”– How are messages

processed?

property EVENT_REQUIRE = DISABLED,

DISABLED =

( out.enable -> ENABLED ),

ENABLED =

( in.event -> ENABLED

| out.disable -> DISABLING ),

DISABLING =

( in.event -> DISABLING

| in.disableAck -> DISABLED ).

property EVENT_PROVIDE = DISABLED,

DISABLED =

( in.enable -> ENABLED ),

ENABLED =

( out.event -> ENABLED

| in.disable -> DISABLING ),

DISABLING =

( out.event -> DISABLING

| out.disableAck -> DISABLED ).

Modelling Implementations

Models of endpoints…

• Aid development– Detect design errors– No compile/link/test cycle

• Aid implementation– Specify behaviour to be

implemented– Highlight synchronisation– Animation tools help

understanding of protocol

Exploring A Model

Interaction Protocol Monitors

Client Address Space

ProxyMonitorEndpoint

Transport Connection

• Monitor dynamic properties of protocol• Verify endpoint implementations

Interaction Protocol Monitors

• Generated from FSP properties

• Implement the state machine specified by the property

• Report protocol errors to application

int _state = 0;

void enable( ClientMessages m ) {

switch(_state)

{

case 0:

_state = 2;

super.enable(this);

break;

case 1:

transmitError(“enable”);

break;

case 2:

transmitError(“enable”);

break;

}

}

Conclusion

• Distributed systems require multiple styles of interaction between components

• Designers need to specify interaction styles– Support design and implementation

– Separate concerns of interaction & transport

• Midas language– Java code using Regent frameworks– FSP for design-time analysis– Protocol verification monitors from specifications