Review of “The COMQUAD Component Model” Tore Engvig 30 April 2004

1. Review of “The COMQUAD Component Model”Tore Engvig30 April 2004

2. Publishing details • Paper title:The COMQUAD Component Model: Enabling Dynamic Selection of Implementations by Weaving Non-functional Aspects • Authors;Steffen Göbel (Institute for System Architecture, TU Dresden) Cristoph Pohl (…)Simone Röttger (Institute for Software Engineering, TU Dresden)Steffen Zschaler (…) • Published:Proceedings of the 3rd International Conference on Aspect-Oriented Software Development (AOSD’04), 2004 • Objective;A Component model and framework for QoS aware components with separation of functional and extra-functional concerns. • URL:http://doi.acm.org/10.1145/976270.976281

3. Paper structure In order; • Introduction. • Presentation of the component model. • Container support. • Related work. • Future research

4. Introduction • COMQUAD was established to understand the issues involved with supporting non-functional properties in component-based systems. • Non-functional properties are a good example of crosscutting concerns that should be handled in an aspect-oriented manner. • Non-functional properties are described in contracts which are woven together with the functional properties by the container at runtime. • The container is responsible for negotiation and monitoring of non-functional properties.

5. Introduction (2) • COMQUAD component model extends EJB and CCM models with: • Specification of non-functional issues • Container-managed instantiation and connection of component implementations based on the specific quantitative capabilities of the system • Streaming interfaces

6. Component Model • Based on Szyperski’s definition, with the addition of the following levels of instantiation: • (Functional) component specification • Component implementation • Installed component • Component instance • From CCM: • Facets and receptacles • From EJB • Home interfaces

7. Component Specification • Non-functional properties are associated with component implementations. • There may exist multiple implementations of the same component with different non-functional properties. • Each implementation may have multiple profiles. A profile are specified with CQML+ and describe the required resources for a given QoS specification. Component Specification A Component Implementation A1 Component Implementation A2 Profile A1.1 Profile A1.2 Profile A2.1 Profile A2.2 Profile A1.3 provides provides provides provides provides uses uses uses uses uses resources resources resources resources resources Functional Part Functional Part

8. Video Player Example COMQUAD-IDL: component Synchronizer { provides IControlPlayer controlPlayer; uses IClockRep clockRepresentation sink Video uncompressedVideoIn; sink Audio uncompressedAudioIn; source Video videoOut; source Audio audioOut; …} COMQUAD-IDL is the same as CCM-IDL with the addition of keywords for sources and sinks of streams of data

9. Component Model • A deployer installs component implementations on a component container. • There can be multiple installed components for the same implementation differing only in the setting of configuration parameters. • Active Components: Components that run in their own thread (e.g. components that stream A/V data. • Passive Components: Components that don’t run in their own thread (e.g. components that compute the value of PI)

10. Component Model: Terms • Component Net: Component Network, a network of collaborating components. • Component Net Template: A functional description of a component net – or a description of component assemblies? • Assembly: Tech report and AOSD paper doesn’t seem to agree on the definition…

11. Component Model: Streams • Streams have an internal component representation • Streams are packet oriented and each packet is of the type indicated by the component (video/audio) • The container selects stream implementation.

12. Descriptors and Container Support • Assembly Descriptor: • The mother of all descriptors. • Template descriptions that connects components to each other by using ports. • Specification Descriptor: • Home interface. • Named used and provided ports. • Implementation Descriptor: • Mapping from interfaces to implementation classes. • CQML+ Descriptor: • Quality statements and requirements for all profiles.

13. Descriptors Shaded classes represents actual XML descriptor files and unshaded classes illustrate XML elements in the descriptor files

14. Container Support • Components are instantiated by the container based on the required QoS. This is done by a Contract Manager when a client tries to instantiate a component by the use of the home interface. • The NRT part tries to create a component graph (component network). • The RT part does resource reservations and instantiates components in the graph. • At runtime, interceptors ensures that components adhere to the contracts. • Adaptation and composite components are not yet supported • … but according to their newer Tech Report, the container are able to perform adaptation.

15. Container Support (2) • Implementation based on JBoss and DROPS (Dresden Realtime OPerating System). • Split into an NFP-aware real-time (RT) part and an NFP unaware non-real-time(NRT) part • RT part is written in C++ and does all resource reservation, contract monitoring and enforcement and resource scheduling. RT Components have to be written in C++. • NRT part is written in Java and does component management (deployment, negotiation of component contracts). The NRT part contains everything that doesn’t need real-time. NRT Components have to be written in Java.

16. Container Architecture The figures are from the Tech Report

17. Related Work • CCM • EJB • QuA • CIAO

18. Summary • QoS requirements are isolated in descriptor files • CQML+ are used to describe the component profiles QoS capabilities and requirements • Container selects the component implementation (service planning?) • Container selects the component implementation (service planning?) • Container selects the component implementation (service planning?) • Container selects the component implementation (service planning?) • Container monitors the components and ensure that they don’t break the contract. • Container able to perform adaptation of running components.

19. Highlights from the list of references [4] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos. Non-functional Requirements in Software Engineering. Kluwer Academic publishers, 2000. [20] S. Röttger and S. Zschaler. Model-driven development for non-functional properties: Refinement through model transformation. Submitted for publication, 2004. [24] R. Staehli and F. Eliassen. QuA: A QoS-aware component architecture. Technical Report Simula 2002-12, Simula Research Laboratory, 2002. [26] N. Wang, C. D. Gill, D. C. Schmidt, A. Gokhale, B. Natarajan, C. Rodrigues, J. P. Loyall, and R. E. Schantz. Total quality of service provisioning in middleware and applications. Microprocessors and Microsystems,27(2):45-54, Mar. 2003. Special Issue on Middleware Solutions for QoS-enabled Multimedia Provisioning over the Internet. [19] S. Röttger and S. Zschaler. CQML+: Enhancements to CQML. In J.-M. Bruel, editor, 1st Intl. Workshop on Quality of Service in Component-Based Software Engineering,pages 43-56, Toulouse, France, June 2003.