1 / 18

Interactivity in Component Architecture: Efficient Design & Implementation Strategies

This analysis delves into the architectural view and necessity of explicit structures and interactions in distributed systems, emphasizing the complexities of components' behavior behind interfaces. It underlines the importance of specifying interaction styles at the architectural level, detailing the Midas Example namespace, message interface signatures, protocol specifications, and binding. The text advocates for robust modeling and analysis using FSP and process calculus, and illustrates how model architectures aid in error detection and implementation specifications. It also elaborates on the significance of monitoring dynamic properties of protocols and employing Java code with Regent frameworks.

mjeraldine
Download Presentation

Interactivity in Component Architecture: Efficient Design & Implementation Strategies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Component Interaction in Distributed Systems Nat PryceImperial Collegenp2@doc.ic.ac.ukhttp://www-dse.doc.ic.ac.uk/~np2

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

  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. Client-sideAPI Server-sideMessageInterface Synchronisation Synchronisation Client-sideMessageInterface Server-sideAPI Interaction Model Client thread(s) Client Endpoint Service Endpoint Server thread(s) Asynchronous Messages actions actions Protocol independent of components’ implementations

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

  7. Compiling Midas Specifications

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

  9. Distributed Binding Client Address Space Server Address Space Transport Connection ServiceProxy ClientProxy

  10. Binding Establishment

  11. reliable cod udp ip 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.

  12. Component model Clientendpoint Transport connection Service endpoint Component model Modeling & Analysis • Interaction protocol modeled using FSP • Process calculus - labeled transition systems • Interaction protocol can be analysed mechanically • Model architectures of interacting components

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

  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 • Monitor dynamic properties of protocol • Verify endpoint implementations Client Address Space Transport Connection Endpoint Monitor Proxy

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

  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

More Related