Hierarchical vs. Flat Component Models

Transcription

1 Hierarchical vs. Flat Component Models František Plášil, Petr Hnětynka DISTRIBUTED SYSTEMS RESEARCH GROUP Outline Component models (CM) Desired Features Flat vers. hierarchical CMs Desired features hard in hierarchical CMs Experience SOFA 2.0 Conclusion CHARLES UNIVERSITY PRAGUE Faculty of Mathematics and Physics Czech Republic Classics: A Software component is A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. [C. Szyperski: Component Software] We think: A Software component is A software component: well defined interfaces and behavior unit of deployment distributed application REUSE view: black-box entity Can be reused in different contexts without knowledge of its internal structure (i.e., without modifying its internals) by third parties DESIGN view: gray-box / white box entity internal structure visible a set of communicating sub. Component model Component model The collection of the related abstractions, their semantics and the rules for component composition (creation of component architecture) In our view, the concept of component has always to be interpreted in the semantics of a particular component model. Key abstractions Related to Container 1 Interfaces provided required Binding providing references Communication style Proc calls (synchro) Events (publisher subscriber) Messages (asynchro) Assembly Architecture Deployment Address space & runtime abstraction - container Container2

2 Key abstractions (cont.) Features desirable flat & hierarchical Composition nesting Flat component model black box component Hierarchical model Gray/glass box view Multiple communication styles Deployment & cooperation of heterogeneous Separation of ADL and the target implementation language an early introduction of all types in interfaces is too entangling ~ (not domain types in parameters of interfaces) User-defined controlling part (controllers) Features desirable flat & hierarchical Current status of component models (cont.) Access to service outside the architecture deployed elsewhere at different time Support for design: contract more than signatures (~ behavior types), behavior specification Granularity of contract Service Component (orchestration of service contracts needed!) Versioning Contract/behavior verification at the ADL level Code model checking against (what) Specific properties and/or behavior specification Industrial models CCM, EJB flat component model Ad hoc feature definition (no flexibility/genericity) fixed control functionality (home,..) Transactions in EJB multipurpose deployment descriptor in EJB 2 communication styles in CCM Inherent distribution via CORBA in CCM Academic models Fractal, SOFA, ArchJava,Java/A,Darwin, Wright, ACME, Paladio, KobrA, hierarchical model (composite ) More features User defined controllers Behavior contract definition in ADL... Features reality Flat Features reality (cont.) Flat Multiple communication styles CCM (proc call + events); EJB proc call Deployment & cooperation of heterogeneous CCM: CORBA like, EJB containers Separation of ADL and the target implementation language an early introduction types is too entangling ~ parameters in interfaces CCM CORBA IDL, EJB Java CCM any; EJB uncontrolled User-defined controlling part (controllers) CCM factory; EJB home interface Access to service outside the architecture deployed elsewhere at different time CCM: Corba Object Services; EJB: limited to predefined security, persistence, transactions Support for design more than signatures (~ behavior types), contract/behavior specification Contract/behavior verification at the ADL level Code model checking against (what) Specific properties and/or behavior specification Versioning

3 Current status of Features hard Hierarchical CM Straightforward question Why does industry use just the flat model Answer It is hard to properly balance the semantics of the advanced features Primary issues, e.g. s of an architecture i.e., adding and removing at runtime, passing references to,... Contacting external services Those existing outside the composed architecture activated independently in time by a third party What is hard on hierarchical CMs Evolution gap / Architecture erosion Connection to external services from the non highest-level Deployment & cooperation of heterogeneous nested in different nodes than the parent needs vertical bindings (and potential heterogeneity) Behavior verification to target horizontal and vertical composition Model checking of code requires main not just a (isolated) component How far up we should go when creating an artificial environment Example of a non-trivial hierarchical application Why we need dynamic architecture At least Dynamic # of a component instances Example: Component ~ a customer representative Dynamic # of instances An example Dynamic Reconfiguration in Hierarchical CM # of Token is dynamic Multiple instances of parameterized loggers In a flat component model easy 1 2 In a hierarchical component model how to manage new

4 Approaches to dynamic reconfiguration 1. Forbidding 2. Flattening architecture removing composite at runtime => loosing the correspondence ADL <-> code 3. Restricted reconfiguration a) well-defined patterns b) shared c) formal rules to specify desired reconfigurations 4. Unlimited Evolution gap/ architecture erosion None of them is fully satisfactory Software services and SOA Another widely used software building paradigm From high level view very similar to software But strong emphasis laid on definition of interfaces just provided ones no knowledge about implementation composition of services based on message routing orchestration (ESB ~ MULE, SONIC) no rigid architecture dynamic reconfiguration not a real issue ~ per request architecture Our experience SOFA CM SOFA General Overview SOFA (Software Appliances) Vertical bindings subsume, delegate Distributed deployment Connectors (+ generator) Versioning Contract/ Behavior verification Behavior protocols Both horizontal and vertical Update of a component only No access to external services Prototype implementation Java LGPL Implemented features development ADL compiler repository protocol checker NetBeans module run-time run-time environment dynamic update automatically generated connectors component trading (experimental only) licensing, automated downloads SOFA nodes (distribution centers) SOFA 2.0 new version SOFA evolution over years some inconsistencies between implementation and specifications e.g., protocols vs. connectors, architectures vs. dynamic reconfiguration,... New version: SOFA 2.0 properly balanced features Key improvements dynamic reconfiguration access to outside services (work in progress) Dynamic reconfiguration Elementary operations of reconfiguration 1. removing a component 2. adding a component 3. removing a connection 4. adding a connection 5. adding/removing a component s interface Arbitrary sequence of these operations uncontrolled architectural modification evolution gap problem/ architecture erosion

5 Dynamic reconfiguration Solution: comply with reconfigurations patterns Adding/removing interface forbidden Breaks the fundamental rule of well-defined component interface Other operations via reconfigurations patterns Nested factory pattern Adding new component and new connection new created by other component a factory Recall the example with multiple loggers where to put the new component 1. Nested factory pattern + Component removal pattern 2. Utility interface pattern 2 1 Nested factory pattern Access to external services Two key options A B Access to broadly-needed external services Needed by most of the At different levels of nesting in the architecture We adopted A component, which initiated the creation typically needs to intensively collaborate with the new component B breaks the rule of well-defined component interface Tunneling needed Strictly component-based solution: Service A component on the top level of the architecture hierarchy Connections through all the higher-level composite Consequence escalation of connections, clumsy architecture (some component just mediate access) performance penalties Solution: Utility interface pattern New concept a utility interface reference to a utility interface can be freely passed among connection established orthogonally to the architecture hierarchy WorkerA WorkerB PService Utility interface mixing CBD with SOA Introduction of the utility interfaces Brings into component-based models a feature of service-oriented architectures Takes advantages of both paradigms encapsulation and hierarchical of CM simple dynamic reconfiguration from SOA

6 Evaluation and Current status Patterns chosen based on experience with non-trivial case studies of component-based applications in SOFA and Fractal without dyn. reconfiguration -> dynamic parts of an application ~ predefined max. static architecture Implementing SOFA 2.0 patterns Utility interface pattern Contract/Behavior verification Code verification against behavior specification Evaluation: Experience with Behavior Specification Behavior protocols successfully used to describe nontrivial component projects (Airport demo, SPEEDO) Real-life behavior protocols checked in reasonable time Checking most complex In several hours ~ 60 events in a component (max) ~ 500 lines of spec all together Architecture protocol state space BP specification Good base for a later implementation Lessons for SOFA 2.0 SOFA architecture / frame abstractions Very beneficial: Design, State space size Frame spec needed in reality, not interface spec Interface automata nice, but... Capturing exceptions in behavior specification hard Conclusion Hierarchical a necessity for CBD Challenges Adding support for dynamic reconfiguration to hierarchical component model well-defined reconfiguration patterns Dynamicity in behavior/contract specifications Mixing CBD with external services (SOA, ) As an aside: our experience Proof of the concept!!! a non-trivial application is an invaluable source of research ideas (not a class room example) Questions Answers also at Acknowledgement to those who contributed to the ideas presented in this talk: Pavel Jezek and Jan Kofron (demo application) Tomas Bures, Vladimir Mencl (SOFA, SOFA 2.0) Jiri Adamek, Jan Kofron, Pavel Jezek (behavior protocols) Viliam Holub (exceptions in behavior protocols) Pavel Parizek (code model checking)