1. Component Interaction in Distributed Systems Nat Pryce Imperial College np2@doc.ic.ac.uk http://www-dse.doc.ic.ac.uk/~np2

2. Architectural View Components “package” behaviour behind interfaces Explicit component interactions Explicit structure Provided servicesRequired services

3. 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

4. “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

5. 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

6. 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

7. Compiling Midas Specifications

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

9. Distributed Binding Transport Connection Client Address SpaceServer Address Space ServiceProxyClientProxy

10. Binding Establishment

11. 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

12. 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

13. 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 ).

14. 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

15. Exploring A Model

16. Interaction Protocol Monitors Client Address Space ProxyMonitorEndpoint Transport Connection Monitor dynamic properties of protocol Verify endpoint implementations

17. 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; }

18. 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