Component Interaction in Distributed Systems Nat Pryce Imperial College

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-side API Client-side Message Interface Client thread(s) SynchronisationServer-side Message Interface Server-side API Server thread(s) actions Client EndpointService Endpoint Protocol independent of components’ implementations

Midas Example namespace regent { namespace interact { interaction Event { 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

Binding binding back-binding Endpoints bound with direct pointers to abstract message interfaces

Distributed Binding Transport Connection Client Address SpaceServer Address Space ServiceProxyClientProxy

Binding Establishment

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 Client endpoint Transport connection Service endpoint 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