Communication Abstraction Based on Multi-Level System Description

1. Communication Abstraction Based on Multi-Level System Description Gary Mathers Gary.Mathers@cern.ch

2. Contents • Vertical and Horizontal Abstraction • Description Driven System (DDS) • The CRISTAL Project • Components and DDS • Components Communication using Descriptions • Conclusions

3. Model & Data Abstraction OMG’s Multi-Layered Metal-modelling Architecture Active Object Model Architecture

4. Abstraction offers Reusable constructs, at each layer Adaptable to environment Cope with change by Objectifying aspects Modifiable at runtime Many research projects are concerned with abstraction, reflective middleware Active Objects are populated by Meta-objects Descriptions Store Edit Version Abstraction

5. Description Driven Systems • Horizontal and vertical abstraction • Vertical = Model • Horizontal = Data • Separation of description and description instances • Versioning • Co-existence

6. DDS example • Vertical Each car object is an instance of a type of car. Each option is an instance of a type of option • Horizontal The option types describe the option choices for a type of car. The option choice describes the chosen option for a particular car

7. Vertical Each instance of a BMW Z3, is identifiable by a identification Number. An instance of the colour option is an element in BMW’s colour range. Horizontal A BMW Z3 has several possible colours The car X123 ABC is ‘black’, has a ‘3 litre engine’ and ‘leather interior’. DDS example cont.

8. CRISTAL is a: Production Data and Workflow Management System Developed for: The High Energy Physics (HEP) community at CERN Requirements for experiment detector production Adaptability over extended period System evolution Interoperability Complexity handling Reusability CRISTAL an example of a DDS

9. CRISTALthe next phase • Separation between: • Kernel • Domain layer added (HEP) to limit kernel artefacts and vocabulary Plus: • Tool set for developing and configuring descriptions • New Technologies • XML • Components

10. Components offer: Reuse Standard Interface Encapsulation Unit of deployment Adaptable to changing environments and relationships Description Driven Components: Reuses configurable Descriptions configure: Behaviour (lifecycle, process) Structure (composition) Relationships (communication) Data (domain) Components and DDS

11. Components and their descriptions are decoupled • Descriptions of relationships between components indicate the need for component communication

12. Component Communication • Relationships indicate component communication • Described communication requirements • Connectors are elements internal to the component • Two styles of Connector • Implicit • Explicit

13. Description Driven Systems Reusability Scalability Version Handling System Evolution Interoperability Cristal is a proof of concept Description Driven Component Communication Configured by description High Requirement/Technology framework Map relationship requirements to available technology Reliability Synchronisation Implicit/explicit Event Bundling To reduce the amount of traffic between processes Conclusion