Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
A QoS Metamodel and its Realization in a CORBA Component Infrastructure Tom Ritter, Marc Born Fraunhofer FOKUS, Kaiserin-Augusta-Allee 31, 10589 Berlin, Germany {ritter, born}@fokus.fhg.de Thomas Unterschütz T-Systems Nova, Am Kavalleriesand 3, 64307 Darmstadt, Germany
[email protected] Torben Weis Technical University of Berlin, Einsteinufer 17, 10587 Berlin, Germany
[email protected] Abstract This paper presents a generic model driven approach to enable Quality of Service (QoS) modeling and realization for component based middleware platforms. We describe a QoS metamodel that makes it possible to support multi category QoS instead of introducing a static set of QoS properties into the modeling method. The metamodel is integrated with the UML metamodel and the Component Implementation Framework (CIF) metamodel of the CORBA Component Model (CCM). Extensions to the CCM are described that are necessary to realize the QoS models in the software components and infrastructure. In addition an example QoS category is presented to demonstrate the application of the presented approach. Keywords: QoS control metamodeling, CORBA, CCM
for
Middleware,
1. Introduction Component based software development becomes the most important design pattern for large-scale distributed systems as usually needed in the Telecom domain. One of the recent component based frameworks for software development is the CORBA Component Model (CCM) [4]. Although the CCM is a major step forward to support the design and implementation of component based distributed telecommunication systems, it has not sufficiently addressed the non-functional, i.e. QoS related aspects of distributed systems. This paper will present a fundamental model driven approach that enhances the CCM framework by generic QoS support. The QoS modeling itself is however independent of the CCM and
because of the model driven approach applicable to other component architectures. Instead of just adding a fixed set of QoS categories to the modeling approach we decided to design a generic, flexible and multi category architecture. For that reason we define a metamodel that allows a generic specification of QoS contracts, which can be negotiated between software components. We have integrated this metamodel with the CCM metamodel and the UML metamodel. Both metamodels are widely used to model the functional aspects of distributed systems. Due to our metamodel approach it is possible to integrate the same QoS metamodel with different approaches for the functional design. Such a generic and flexible approach offers the possibility to define application domain specific QoS contract types. One of these application domains is the Telecom domain on which we concentrate in this paper, because we believe, that this domain is one of the most challenging ones. In this domain the bandwidth of a stream-based communication is of special importance. To demonstrate the QoS category bandwidth we have extended the standard CCM by the possibility to model and realize stream-based interaction between distributed software components. Our approach enables CCM based software components to negotiate a certain set of QoS properties (QoS contract) before they start to interact. This negotiation mechanism can be used in every application domain. In contrast, the concrete QoS contracts that are subject of the negotiation are domain specific. To implement the QoS architecture some changes in the container architecture and language mapping of CCM are needed. The design of the proposed architecture implies only minor changes to the standard. Furthermore it defines additional features (mainly portable
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
1
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
interceptors) that are to be plugged into an existing CCM Implementation. It is also possible to switch the QoS support on or off for a given component implementation. To proof the general applicability and usability we decided to implement our concepts on top of an already existing CCM based middleware developed by Fraunhofer FOKUS. With our QoS related extensions we build a new incarnation of this middleware. This new version is now available as an Open Source project called Qedo (QoS Enabled Distributed Objects) [9]. The paper is structured as follows. First, we describe the importance of Quality of Service for componentbased middleware from a telecommunication viewpoint and why this implies the usage of CCM. In chapter 3 we describe the QoS metamodel and the necessary changes to the metamodel of CCM to support the QoS specification and negotiation of QoS contracts between components. We also apply the QoS metamodel to the UML by defining an UML Profile for QoS. In chapter 4 we describe the modifications. Finally chapter 5 contains an overview of related and future work and the conclusion.
2. Quality of Service in the Telecom domain For a big telecommunications company customer loyalty is a crucial and decisive criteria for generating turnover and therefore for profit. Beside other measures turnover can be achieved for example by offering high quality products or by tailor-made service adaptations for customers or groups of customers. Telecommunication services must be adjustable flexibly over the whole spectrum spanning from design (service creation) to individual usage (customization). In any case this must be realized considering Quality of Service aspects. QoS passes through the whole service life cycle in a lot of many-facetted details. The newly emerged CORBA Component Model is very interesting for the Telecom domain. With its Container based architecture it provides a good separation of business code and platform dependant code. It defines clean interfaces between these two kinds of code. This makes it possible to easily integrate specialized software or even hardware into the middleware. This is the precondition to add Quality of Service to Telecom Systems with minimum effort. CORBA based Middleware is a well-tested and wide spread concept. There are also a lot of approaches to integrate QoS into CORBA based middleware. Quality of Service of component based middleware is in the context of telecommunications not investigated sufficiently yet. A generic technology to access QoS categories and parameters for telecommunication services is not yet
available. As a relatively new technology the ongoing development of CCM may still be easily influenced by the needs of the Telecom world. The CORBA CM (emphasizing CORBA) offers just because of the dominating position of the Enterprise Java Beans (EJB) based application server products a risky but high market potential. The CCM is not restricted to one programming language but offers beside Java a high number of alternative language mappings. This set comprises e.g. the “legacy”-language Fortran as well as the widest spread Telecom language C++ or highly specialized nice languages like Eiffel. Although we concentrate with our examples presented in this paper on the telecom domain we aimed for general concepts and architecture that can be applied to other domains as well.
3. The metamodel The first step that is necessary to integrate QoS support in a middleware is to find a way of specifying the required QoS categories and the desired service levels. In our work we focus on a multi category QoS middleware. That means we do not just want to extend an existing middleware with a fixed set of QoS categories. Instead we want to build the foundations for generic QoS support. As a matter of this we need a generic way of describing QoS contracts of all possible categories. The scientific community has done quite some work in finding such a generic specification language. We want to mention especially the work of Frolund and Koistinen [5]. However, instead of providing something like an EBNF grammar for defining the concepts and their relation to one another, we use metamodeling. The metamodel is able to describe all the concepts that are needed for the specification of a QoS contract. However, it does not talk about any concrete notation. The advantage of a metamodeling approach is two fold • •
We can provide different notations for the same thing We can bind our concepts to different technologies such as IDL and UML very easily.
To prove that this advantage is not just a theoretical one we will show in the following sections that our QoS contract metamodel can be bound to CCM/IDL and UML quite easily. The extension of IDL is crucial for integrating QoS support with the CORBA middleware itself. Changing the IDL metamodel results in an extended IDL that is
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
2
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
then able to describe QoS contracts in addition to usual functional interfaces. The extension of UML concepts allows us to model a component, its interfaces, events and QoS contracts in a graphical manner. In [6] we demonstrated how UML can be extended to support contracts for non-functional aspects in general and QoS in special. The UML drawings can help a lot to gain an overview of all components, interfaces and their possible QoS contracts during the application design phase. Once this design step is finished it is possible to convert this UML based specification into an IDL file. Converting standard UML into IDL is already standard practice in most industrial strength modeling tools. Since the very same QoS metamodel is bound to UML and CCM/IDL it is clear that we can convert the extended UML concepts in the extended IDL without loss. However, the code generator of the UML tool has to be modified to achieve this goal. In the following sections we will first of all present our QoS contract metamodel. Then we discuss how it fits into CCM and finally its integration with UML.
The QoS contract metamodel has to address two key issues
•
Di mension ordering : Ordering unit : Unit
Support the specification of contract types for every possible QoS category Define a binding that connects interfaces, methods and the like with QoS contract types.
We follow the approach of QML [5] and think of a contract type as a composition of dimensions. Therefore we introduce the metaclasses Dimension and ContractType. Both are indirectly connected by a composition that specifies that a ContractType is composed of an arbitrary number of Dimensions (Figure 1). A ContractType has one attribute called name. This attribute is used to store the name of the QoS category that is described by the contract type, i.e. “Availability” or “Bandwidth”. The metaclass Generalization allows for modeling multiple inheritance among contract types. One obvious constraint is that circular inheritance is forbidden. Specializations of a contract type inherit all dimensions of its generalizations. There are two reasons for introducing inheritance in QoS contract types. If we want to negotiate about two contract types in an atomic manner then we can
DimensionBas e name : String +dimension
1.. n
Dimensio nUnionMember label : Any +dimension
+contract
1 DimensionUnion
Context +context 1
Ordering
+child 0..n
1
ContractType name : String
1.. n
+union
+type
1
generalization
0..n +parent
+binding 0.. n +binding Binding 0..n +binding 0.. n
Unit
DECREASING INCREASING
3.1. QoS contract metamodel
•
introduce a new contract type, which inherits from these two but does not introduce any new dimensions. We realized in our project that it is almost impossible to define one set of dimensions that are able to describe all possible contracts of one QoS category. The reason is that the contract type does not describe the QoS category itself. Instead it describes constraints on the delivery of the service’s quality.
AMOUNT BYTE PERCENT MSEC
+element 0.. n InteractionElement
Figure 1. QoS metamodel For example it may be possible to agree on one definition of availability, one definition of bandwidth and so on. The result of such a definition is a set of variables. In other domains other variables may be appropriate to characterize a QoS category. While the service is running we can monitor the values of these variables and plot them in a chart as time evolves. Unfortunately we cannot deduce the dimensions of a contract type entirely from these variables. The values of the variables describe the quantified QoS that is actually delivered by the service. In the ideal case a diagram showing a measuring-variable together with the time axis will show a horizontal line. In this case the delivered quality is always exactly the quality that has been negotiated between client and server. Usually we do not have these horizontal lines in real life measurements. So we have to define in a contract what we still consider to be ok and what we have to reject. From a mathematical point of view there is an unlimited number of possibilities for specifying these constraints. Some mathematical instruments are very common in this situation. We could describe minimum boundaries, which must not be crossed. Or we can demand that the average quality measured over a certain time range has to be at least a certain value.
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
3
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
However, in other situations different constraints may be useful. While considering the QoS category availability there is only one Boolean variable that we can measure. Either the service is available for a request or it is not. Nevertheless we can have different demands • • •
The service must not be continuously unavailable for longer than t minutes. The accumulated downtime in one month must not be longer than 10 hours but no more than 5 hours per day. The service has to be continuously available for at least t hours per day.
There may be other possibilities that are more appropriate in other situations. As a matter of these observations we considered it to be a useful approach to define a base contract type so that all of its dimensions correspond to one of the measuring-variables. Then we define other contract types, which inherit from the base type. These specialized types add dimensions that allow us to express the constraints, for example the maximum downtime or the like. From a modeling point of view this is fine. However, in real life that may limit the possibilities of interoperability. If everybody defines his own set of contract types then we may have a hard time to smoothly integrate off the shelf components (COTS) in the development and deployment process. In the settings of our project we selected certain constraints for each supported QoS category and standardized on these internally. However, we want to keep the middleware flexible enough to deal with a different set of constraints. Another problem that we encountered is that it is sometimes hard to determine one of the measuring variables. An example is security. It is actually not possible to measure security in a way we do with performance, bandwidth and the like. So we use values that are more closely bound to the mechanism that is used to provide a certain QoS category. Possible dimensions are the key length or the encryption algorithm used. Unfortunately, this leads once again to different possibilities. We introduced the concept of a DimensionUnion, to cope with that. Such a union is composed of a non empty set of DimensionUnionMembers. Such a union member is simply a usual dimension with an additional label. The label is urgently needed because a union will require a discriminator. The semantics of a DimensionUnion say that an instance of a union in some contract has two values. One is the discriminator and the other one is a value for the dimension denoted by the discriminator.
This way we can solve the problem of defining one single contract type for security. Depending on the security mechanism used we can select the matching union member. On the other hand we could have derived a special contract type for every single security mechanism. However, this way the number of contract types explodes, which makes the model unreadable and the implementation too difficult. The metaclass DimensionBase has been introduced to simplify the design of ContractType and to show that both concepts Dimension and DimensionUnion have a lot in common – structural aspects and semantics. Now it’s time to have a close look at the attributes of the metaclass Dimension. The attribute ordering is useful for comparing contracts. We want to enable a generic algorithm to determine how two values for one dimension relate. The same is done by QML. The attribute unit is needed to determine what value type is supposed to be stored in a contract. A dimension of a contract type can for example specify that the contract must have an integer that has to be interpreted as seconds or a float that has to be interpreted as a percentage. The binding of contract types to a certain Context remains to be explained. Such a context is usually something like a component, streaming port or an event port. If the context is a component then the contract negotiation affects the entire component including all of its interfaces, stream ports, event ports and so on. A context allows for determining about which contract types can be negotiated. The straightforward solution would be to associate a context directly with a contract type. However, imagine we want to attach a contract type directly to some interface (which can be a context too). This interface can be used by multiple components or even multiple times by one component for different purposes. Attaching a contract type directly to the interface would mean that every component that implements this interface is able to negotiate about this contract type. However, that is most often not the case. Instead, we want to specify that a certain component is able to negotiate about the contract type and that this contract will cover all interaction via this interface. That means three things have to be combined: The component, the interface and the contract type. In this case the component acts as a Context while the interface acts as an InteractionElement. All three are related to each other via the metaclass Binding. (Figure 1) A binding tells in which contract types can be negotiated context and which interaction element will be subject to the negotiated QoS. However, sometimes interaction element and context may be the same thing. Therefore we made the association between
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
4
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
InteractionElement and Binding optional while that between Context and ContractType is mandatory. The metaclasses Context and InteractionElement are abstract. That means it is not possible to instantiate any of these metaclasses. They are more a kind of a placeholder for interfaces, methods, attributes and so on.
Contained
Container (from BaseIDL)
(from BaseIDL)
0..1
lookupName() +definedIn lookup() getFilteredContents ()
0..n +contents
identifier : string repositoryId : string vers ion : s tring / abs oluteNam e : s tring
InterfaceDef (f rom BaseID L)
StreamPortDef
isAbstract : boolean isLocal : boolean
3.2 Extension of the metamodel The CORBA Component Model (CCM) contains a Component Implementation Framework (CIF), which supports the designer by the provision of modeling support for the functional aspects of components. The CIF is defined in terms of a metamodel. This metamodel extends the basic IDL modeling capabilities by concepts which allow to define component types who’s instances interact via a set of well-defined interfaces. Such interfaces can be declared either as being provided or used by a certain component type. In the first case, the component types instance has the server role whereas in the second case it has the client role. In addition to the operational interaction via (IDL-) interfaces components can interact asynchronously by exchanging events. To model a component based system with the above modeling concepts; the metamodel is defined as an extension of the IDL metamodel. It is structured in packages as follows: Bas eIDL
Contains
ComponentIDL
ComponentDef
SinkDef
SourceDef
(f rom ComponentIDL)
Figure 3. Stream port definition A stream definitions in a model are used to declare a potential stream interaction in a context of a component either as sink definition or as source definition depending on the direction of the data flow. Both SinkDef and SourceDef are metaclasses in the extended metamodel defined as specializations of StreamPortDef (Figure 3) that is itself a specialization of Contained. Hence, Components as a specialization of Container are able to contain stream sinks and sources in addition to used and provided operational interfaces and consumed or produced events. For QoS-modeling we provided a new package QoS that addresses the following issues:
CIF
Figure 2. Package structure Package BaseIDL contains the metamodel of IDL, package ComponentIDL contains the concept of component types and their interaction capabilities as described and package CIF contains concepts for the description of implementation structures for component types. A detailed definition of this metamodel can be found in [4]. In this paper we will describe our extensions only. We have extended this CCM metamodel in two ways. First, we included the possibility to model stream interactions for component types. As motivated in the introduction stream based interactions are essential in the telecommunication domain and we want to demonstrate the QoS category bandwidth with stream-based interactions. Second, we related our QoS-modeling concepts (i.e. the QoS-metamodel) to the CCM metamodel concepts.
• •
Specification of QoS-contract types Binding these contract types to contexts
For the first issue two basic design principles of the CCM metamodel can be used. These are the containercontained principle and the type-typed principle. The first is applied to model containment relations the second to model the relationship between an element that has a type and the type of that element. The metaclass QoSContractType contains elements of the type Dimension. Hence, the QoSContractType is defined as a specialization of the abstract metaclass Container whereas Dimension is defined as specialization of the abstract metaclass Contained. Furthermore, the instances of the metaclass DimensionUnion contain instances of DimensionUnionField that is similarly modeled applying the container-contained principle. Dimensions always have a certain type. Hence, they are typed elements. Therefore, Dimension is a specialization of the abstract metaclass Typed, re-using the type-typed principle of the IDL metamodel. Types that can be assigned to Dimensions cover all IDL Types and in addition QoSContractTypes and DimensionUnions. The latter are declared as
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
5
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
specializations of the abstract metaclass IDLType. With a constraint definition we restrict the concrete types, which can be assigned to Dimensions to IDLTypes, which are numeric, and QoSContractType/DimensionUnion. Structured IDL types are not allowed since they would cause the problem of being not comparable. To define the context of potential QoS-negotiations we use the concept of component features. Since component features contain all possible interactions of a component type with its environment, QoS-negotiations occur always in the context of a component feature. As mentioned before, component features are used and provided interfaces (metaclasses UseDef and ProvidesDef), produced and consumed events (metaclass EventPortDef), produced or consumed streams (metaclass StreamPortDef) and the component itself (metaclass ComponentDef). Consequently, all these metaclasses are defined as specializations of the abstract metaclass QoSContext. QoSContext itself is associated to the metaclass NegotiatableBinding that aggregates a set of QoSContractTypes and represents the Binding metaclass. These are the contract types that are subject to negotiation within the context to which the binding is associated. In order to restrict the negotiation to specific interaction elements (i.e. operations and/or attributes) of an operational interface there is an association from NegotiatabelBinding to InteractionElement as the base class for OperationDef and AttributeDef. The occurrence of instances of this association in a model implies, that QoS-negotiations are not applied to all operations/attributes of an interface but only to those, which are associated to the binding. (See section 3.1) QosContext 1
attributes or associations. However, the drawback of this method is that most common modeling tools are not able to deal with these extensions. Furthermore, the new metaclasses need some kind of notation. For example the UML standard defines that a class is depicted as a rectangle with several vertically stacked compartments. The same job has to be done for every new metaclass. Unfortunately, this means that the code base of the UML modeling tool has to be extended. Because of these inconveniences there exists a more lightweight method for extending the UML. With the concept of tagged values and stereotypes [7] we can almost simulate new metaclasses, attributes and associations. The notation is inherited from the stereotyped metaclass. Instead of the metaclass ContractType we introduce a stereotype called QoSContractType that extends the UML metaclass Class. The reasoning for this is simply that contract types can be instantiated almost like classes in object oriented languages. A Dimension becomes a stereotyped UML Attribute, which is pretty straightforward because a Class contains Attributes just like a ContractType contains Dimensions. The additional attributes of the metaclass Dimension become so called tagged values in the stereotype. A DimensionUnion is considered to be a stereotyped class, too. So a DimensionUnionMember is mapped to an attribute just like Dimension. As a matter of this decision a ContractType does not directly contain a DimensionUnion. Instead it can have a normal UML attribute which has a type that is in turn a DimensionUnion. This seems to impose quite some structural difference between our QoS metamodel and the UML profile. However, the only important point is that we map concepts one to one so that we can translate the UML model in an extended IDL file without loss.
+context QosBinding Class
+bin ding 0..n NegotiableBinding
+binding
ma nadatory : Bo olea n
+element InteractionElement
restricted_to 0..n
Attribute
+bind ing QoSBinding
+bas e
+type QoSContractType
AttributeDef
OperationDef
(f rom BaseIDL)
(f rom BaseIDL)
is Readonly : boolean +derived
QoSContractType
QoSUnion
QoSDimension unit : Unit ordering : Ordering
QoSInteractionElement operation : Operation
isOneway : boolean param eters : ParameterDef contexts : string QoSUnionMember
Derived_from
label : String
Figure 4. Binding in CIF Figure 5. Contract and Dimension in UML Profile
3.3. A UML profile for QoS Typically, there exist two different methods for adding new concepts to the UML. One way is to directly extend the metamodel, i.e. introducing new metaclasses,
The Binding is a bit more difficult to deal with. In UML a component provides an interface if both are connected by a Realization dependency (a dashed line with a closed arrow). Instead of extending the UML metaclass Realization so that we can map our metaclass
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
6
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
Binding to it, we treat a Binding as a stereotyped UML Class. The UML component does always play the role of the Context. The connection between the component and the binding is depicted by an aggregation. The connection between the binding and the contract type is depicted by a normal dependency (dashed line with open arrow). If there are no additional dependencies present then the contract type is assumed to be negotiable for all interfaces of the component at once. Otherwise we draw a normal dependency between the binding and one or multiple interfaces to indicate that the contract type only affects these interfaces. The concept of an InteractionElement is needed if the contract type is supposed to affect only certain methods of an interface. To solve the problem we stereotype an UML Attribute so that it can store a reference to some UML Operation. This stereotyped attribute is owned by the class, which is stereotyped as a Binding. In the figure 6 we illustrate the usage of the UML profile in a little example. A component StockMarket features an interface Buy and the binding HighAvail shows that the component can negotiate about the Availability contract type. The little arrow in the contract type’s dimension illustrates the ordering and the string in brackets denotes the dimension’s unit.
Figure 6. Example of QoS Category
4. Enabling QoS implementations
support
for
CCM
4. 1 Binding The Binding takes place when two components are explicitly connected via their ports. Ports are externally visible interactions elements. Figure 7 shows all available port types of a CCM conforming component.
Figure 7. CORBA component This initial binding process should normally be part of the deployment process. A 3rd party controls this deployment process. This 3rd party can be a deployment tool. Nevertheless, one of the involved components could play the 3rd party role. This is true in particular for small systems or for systems that change their configuration of instantiated components rapidly and application dependant. But for explaining the process of binding of two components it is important to identify this role. To seamlessly integrate QoS support into the CCM infrastructure this binding procedure has to be extended by a negotiation phase. But this phase should only be started if the components want to negotiate a certain QoS contract. The container of the client component decides on this. The container knows whether the hosted component wants to negotiate a certain QoS contract or not. If a negotiation is taking place the connection setup will not be completed successfully if the negotiation fails. The following diagram illustrates the integration of the negotiation phase into the connection set-up. Client
The modeling concepts presented so far are the basis for enabling a very flexible and generic QoS support in the CCM infrastructure. We have designed and implemented a flexible and generic negotiation mechanism. In addition we extended the Component Implementation Framework (CIF) of the CCM by interfaces that are used to control the currently established QoS level. There are two points where the QoS support has to be plugged into the existing CCM architecture. The first is the binding mechanism between two components and the second is the interaction between container and component implementation (business code).
S erver
3rd party
provide_fac et
connect_facet req_cont rac t acc ept
Figure 8. Negotiation After receiving the connect() operation the client side checks whether it wants to establish a QoS enabled connection or not. If the clients want to establish a QoS
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
7
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
connection it calls req_contract(). As input of this operation the client provides its minimum requirements. The server responds with a list of concrete contract offers that shall meet the client requirement. The client can now choose the most appropriate offer. The client calls the accept() operation together with the selected offer and the reference to the client itself. This is needed by the server component to inform the client about the termination of a contract if it is needed. The client can terminate a contract too. module Components { module QoS { … interface Negotiation { ContractBaseSeq req_contract( in ContractBase min ); ContractId accept( in ContractBase accept, in Components::CCMObject own_ref) raises(AcceptionFailed); void terminate_contract( in ContractId contract_id); string get_facet_name( in Object facet_ref) raises(NoFacet); }; // Negotiation }; // Qos }; // Components
This interface definition illustrates the interface Negotiation that will be offered by a QoS aware component. The container of each QoS aware component provides the implementation of this interface. Once a QoS contract is establish every single transaction has to be analyzed. It is important to know what are the active contracts for a transaction to deliver the right QoS. Certainly this process consumes time. However, this time is only a very small fraction of the overhead inherited to all distributed applications. If the two components that are part of the transaction are collocated this time will have a higher impact on the overall transaction time. Further studies will try to figure out the specific amount of this overhead. The business code will normally not control the binding process. Nevertheless, it is important for the business code to get information about this binding process especially about the established QoS contract. This will be described in the next section. For this reason the business code can implement callback operations or can actively request the current QoS state. A violation of a QoS contract leads to the termination of that contract. In this case the business code is informed and can act appropriately. One possibility is to try to negotiate a contract with a lower quality of service. In our future work we want to address automatic transitions between
different levels of QoS contracts as part of an automatic re-negotiation.
4.2 Language mapping As described above a 3rd party will coordinate the initial binding between two components. This means the business code of each involved component will not directly influence the QoS negotiation. This is done to decouple the QoS negotiation from business code. The information about the required and provided QoS levels will be submitted to the container of each component via the deployment descriptors. If it is needed the business code will also be able to modify the established QoS later on. In this case the business code may need information about the established QoS properties. There are two ways of retrieving this information. The component can actively query the container about the actual QoS or the container informs the component about every change of the QoS properties. For this reason we have to specify new interfaces. One internal interface provided by the container and one callback interface that could be optionally implemented by a component. The callback interface QoSComponent serves the purpose of announcing QoS changes that could handled automatically by the container to the component. Furthermore it is used to inform the component if a QoS contract was terminated. interface QoSComponent { void QoS_changed (in ContractId old_id, in ContractId new_id, in string component_feature); void QoS_termitated (in ContractId old_id); };
The internal interface QoSContext is needed to fulfill two tasks. The first is to query currently active QoS properties and the second is to change the QoS properties by terminating an actual contract and perhaps trying to establish a new one. interface QoSContext { ContractId get_contract ( in string component_feature); void terminate_contract( in ContractId contract); ContractId modify_contract( in ContractId id, in ContractBase contract); };
With this interface the business code itself is able to influence the negotiation of QoS. It may be needed to change the QoS of such a connection at run-time depending on application behavior. A modify_contract() operation will result in a disconnection of the two components and a reconnection with the new QoS contracts if possible.
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
8
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
The QoS provider is the entity that is responsible for implementing and providing mechanisms to ensure certain levels of quality. The QoS provider should be as separate as possible. This will enable the implementation of various QoS contracts within an application. Each QoS contract will have a responsible QoS provider to serve the contract. This QoS provider has to be instantiated within the container before components can negotiate a particular QoS contract. At the moment we have only a limited support for the integration of a new QoS provider into our container. The following IDL fragment displays the interface that a QoS provider has to implement. interface QoSProvider { … ContractBaseSeq req_contract( in ContractBase min ); ContractId accept(in ContractBase accept, in Components::CCMObject own_ref); String client_accept(in ContractBase accept, in ContractId remote_contract_id); void terminate_contract( in ContractId contract_id); … }; // QoSProvider
While implementing the example QoS providers we learned that this task needs more support by development tools. Therefore we plan to design and implement a QoS provider framework in our future work. This framework will reduce the effort that is needed to implement a new QoS provider.
4.3 Example QoS category To consolidate the architecture we have developed and presented in section 4.2 and to proof the usefulness of the concepts the generic negotiation mechanism was implemented in the Qedo Project [9]. This is an Open Source implementation of the CORBA Component Model which emphasizes on the QoS support. Furthermore we have implemented several example QoS categories such as bandwidth and availability that we identified to be important in the Telecom domain. The following outlines what has to be done to implement a QoS category. At first we need the definitions of the components that will be connected via an interfaces. The following IDL fragment displays a server and a client each has a stream port. The server has a source and the client has a sink both of the same stream type RealStream. There is also a management interface for each that is used in a complete demo scenario. interface server_control{ … }; interface client_control{ … }; streamtype RealStream; component video_server { provides server_control control; source RealStream live_news; };
component video_user { provides client_control control; sink RealStream input_stream; }
Specifically for an application domain we can define a contract type BandwidthContract for that kind of streams as follows. valuetype BandwidthContract: ContractBase{ public Dimension bit_rate; }
Then a QoS provider has to be developed that is able to manage this QoS category. This is achieved by implementing the QoSProvider interface presented above. An instance of this QoS provider on each side will handle QoS category related activities in the containers. Keeping the bandwidth example the QoS provider itself uses the mechanism provided by the streaming technology to control the level of QoS. This is of course QoS category dependant and to some extend container dependant too. In this case we have used the Real streaming protocol and the two Software Development Kits (SDK’s) that are provided by Real Networks [10]. By using this technology we have accomplished two tasks at once. First, we have a streaming protocol that is able to transmit streaming data with different bit rates. Second, we have encoding, decoding, grabbing, and presentation capabilities without implementing this by our own. Furthermore we need to define an installation and deployment description, which includes the QoS requirements and capabilities of the components. The deployment of such systems is another major issue which we are also addressing in the Qedo project. But this work is out of the scope of this paper. The outcome of a deployment process is the instantiation of the two components and the connection of their ports with an automatic negotiation of the contracts as outlined before. The implementation of example QoS categories gave us a good feedback for improving the design of our architecture.
5. Conclusion In this paper we presented a model driven approach to enable QoS negotiation and QoS support in a CCM based middleware. We have presented a QoS metamodel and its integration with the UML metamodel and the CIF metamodel. The QoS metamodel can be applied to other middleware platforms as well. The metamodel supports the definition of application domain specific multi category QoS contracts. Although we have a first working implementation of our concepts we know that there is still a lot of work to do.
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
9
Proceedings of the 36th Hawaii International Conference on System Sciences - 2003
5.1 Related work A lot of work has already been undertaken in the area of QoS for CORBA. Most of these approaches emphasize on the implementation of a couple of concrete QoS categories (e.g. bandwidth reservation) and are not targeted on a generic QoS architecture. Quality Objects (QuO) [2] is one of the most advanced concepts to integrate QoS into distributed application based on CORBA. QuO stresses also that business code and other code (i.e. QoS supporting code) shall be independent. On the other side the QuO toolkit is not aligned with the CCM and is not directly applicable on CCM based systems. There is one project that deals with QoS for CCM based middleware. This project is the TAO CCM Project [1]. This project is going to integrate some of the achievements of QuO into their container implementation. The TAO CCM project is specialized for DRE application and is strongly connected with the TAO ORB. Whereas our approach focuses on the metamodeling approach and the negotiation architecture. The MAQS project (Management Architecture for Quality of Service) [8] implemented a framework for generic QoS support on top of CORBA 2.1. MAQS features an aspect oriented extension of the IDL to support the definition of QoS contracts in IDL. The focus of MAQS is on the management and implementation side of QoS. The IDL extension allows to describe the nonfunctional interfaces of a CORBA object which are used for negotiation, administration and monitoring of QoS contracts. Another approach that deals also with a plain CORBA middleware is the Quartz project [3]. This project has a flexible architecture to implement certain QoS categories in Open Systems. And they have presented an adaptation to the CORBA based middleware.
5.2 Ongoing work We are trying to influence the standardization bodies (e.g. OMG). Further research will also be complemented by an European project called COACH. In this project we will improve our concepts and implementations. Some more study has to done on integration of a more advance negotiation mechanism with a fundamental mathematical background. We also want to address the chaining of QoS contracts over several hops. A QoS provider framework will be developed to support an easier implementation and integration of new QoS providers that support new QoS categories. We expect that other domains will require other contract types and therefore other QoS providers. To increase the
acceptance of our approach a fast and easy way for adding new QoS categories is needed. We have to check whether one of the already existing QoS approaches for plain CORBA based middleware (See 5.1) could be easily integrated into the CCM container to enable more advanced QoS category implementations. Especially for the Telecom domain we have to design concepts for propagating established QoS contracts to a Telecom charging and accounting system.
6. References [1] Wang N., Schmidt, D., Kircher, M. and Parameswaran, K. , “Adaptive and Reflective Middleware for QoS-Enabled CCM Applications”, DS Online, 2001 [2] Zinky, J., Bakken, D., Schantz, R., “Architectuial Support for Quality of Service for CORBA Objects”, Theory and Practice of Object Systems, Vol. 3(1), 1997 [3] Siqueria, F., Cahill, V., “Delivering QoS in Open Distributed Systems” The 7th Workshop on future trends of distributed computing systems, 1999 [4] Components December 2000 FTF, “New Component Chapters”, OMG, Document number: ptc/2001-11-03, 2001 [5] Frolund, S., Koistinen, J., “Quality of Service Specification in Distributed Object System Design”, Proceedings of the COOTS 98, 1998 [6] Weis, T., Becker, C., Geihs, K., Plouzeau, N., “A UML Meta-model for Contract Aware Components”, Springer LNCS 2185, 2001 [7] OMG, “Unified Modeling Language Specification”, Document Number 01-09-67, 2001 [8] Becker, C., Geihs, K., “Generic QoS Support for CORBA”, Proceedings ISCC’00, 2000 [9] Qedo, “Qedo Project Homepage”, QoS Enabled Distributed Objects, http://qedo.berlios.de [10] RealNetworks, “Download of Real Streaming Software Development Kit (SDK)”, http://www.realnetworks.com/resources/sdk/index.html
0-7695-1874-5/03 $17.00 (C) 2003 IEEE
10
