1. Review of “The COMQUAD Component Model” Tore Engvig 30 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 3 rd 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 http://doi.acm.org/10.1145/976270.976281 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 3 rd 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 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 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. 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: 1. Specification of non-functional issues 2. Container-managed instantiation and connection of component implementations based on the specific quantitative capabilities of the system 3. Streaming interfaces COMQUAD component model extends EJB and CCM models with: 1. Specification of non-functional issues 2. Container-managed instantiation and connection of component implementations based on the specific quantitative capabilities of the system 3. 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 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 A Component Implementation A2Component Implementation A1 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. 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. provides uses resources provides uses resources provides uses resources provides uses resources provides uses resources Functional Part Profile A1.1 Profile A2.2Profile A2.1 Profile A1.3 Profile A1.2

8. Video Player Example component Synchronizer { provides IControlPlayer controlPlayer; uses IClockRep clockRepresentation sink Video uncompressedVideoIn; sink Audio uncompressedAudioIn; source Video videoOut; source Audio audioOut; … } COMQUAD -IDL: 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) 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… 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. 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. 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. 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. 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 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 monitors the components and ensure that they don’t break the contract. Container able to perform adaptation of running components. 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 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, 1 st Intl. Workshop on Quality of Service in Component-Based Software Engineering, pages 43- 56, Toulouse, France, June 2003. [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, 1 st Intl. Workshop on Quality of Service in Component-Based Software Engineering, pages 43- 56, Toulouse, France, June 2003.