QuA

Review of “The COMQUAD Component Model”

Tore Engvig30 April 2004

QuA

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

• 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

QuA

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

QuA

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.

QuA

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

QuA

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

QuA

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 Functional Part

Profile A1.1 Profile A2.2Profile A2.1Profile A1.3Profile A1.2

QuA

Video Player Example

«active»Demuxer

«active»VideoDecoder

«active»AudioDecoder

«active»Synchronizer

CompressedVideoOut

compressedAudioOut

compressedVideoIn

compressedAudioIn

uncompressedVideoOut

uncompressedAudioOut

uncompressedVideoIn

uncompressedAudioIn

controlPlayer

clockRepresentation

videoOut

audioOut

Sink (Stream)

Source (Stream)

Dependency between ports

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

QuA

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)

QuA

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…

QuA

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.

QuA

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.

QuA

Descriptors

-Assembly_ID

Assembly Descriptor

-Nameserver_Entry

Homeplacement-Component_Interface-Home_Interface-Specification_ID

Specification Descriptor

-Implementation_Class-Interface_Class-Implementation_ID

Implementation Descriptor

-Quality_Characteristics-Quality_Statements-Profiles

CQML+ Descriptor

-Name-Type

Port

ConnectionComponent Net Template

0..*

0..*to

*

instances 0..*

from

0..*1..*

provides1..*

-uses

1..*

1 0..*0..1

1

1

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

QuA

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.

QuA

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.

QuA

Container Architecture

The figures are from the Tech Report

QuA

Related Work

• CCM

• EJB

• QuA

• CIAO

• CCM

• EJB

• QuA

• CIAO

QuA

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.

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

QuA

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.

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