Quality of Service and Object-Oriented Middleware Multiple Concerns and their Separation

Transcription

1 Quality of Service and Object-Oriented Middleware Multiple Concerns and their Separation Christian Becker Department of Computer Science University of Frankfurt/Main Germany Kurt Geihs Department of Computer Science University of Frankfurt/Main Germany Keywords: Quality of Service, Aspect Oriented Programming, Reflective Middleware Abstract Quality of Service is an important requirement of nowadays distribution infrastructures. The popularity of objectoriented middleware makes QoS provision in those infrastructures desirable. The system dependent nature of QoS necessitates a clear separation of concerns and the insulation from the application objects. In this paper QoS integration is investigated under two views. First, based on the aspect-oriented programming, the integration of QoS mechanisms into the application objects is presented and second, the hierarchical structure of QoS mechanisms is addressed by a reflection based approach. 1 Introduction Quality of Service provision is an increasing demand on nowadays distribution infrastructures. While a variety of specialized architectures support single category QoS management, i.e. only address a specific facet of the systems QoS requirements, e.g. real-time, fault-tolerance, or multimedia, larger systems encounter a variety of different QoS requirements. Generic multi-category QoS management aims at the provision of arbitrary QoS. Since QoS provisions is supplementary to the problems arising from the distribution of components in a distributed system it is feasible to rely on a distribution infrastructure that already offers the interaction of remote objects. Such middleware platforms are quite popular because of the provided abstractions for programming. However, integration of generic QoS provision in such infrastructures raises some questions. QoS provision is typically a system centered task and exposed to platform related details which should be hidden by the distribution infrastructure. A major objective of generic QoS management is the separation of application logic and the QoS related behaviour. Thus, application specific concerns are not exposed to application programmers. Because of the end-toend property of QoS that is, the QoS provision has to be ensured along all layers of the communication path between client and service structuring the QoS provison will help construction, maintainance and reuse of QoS mechanisms. This paper will present an aspect oriented programming based framework (Management Architecture for Quality of Service (MAQS) [2], [4], [1]) which addresses this separation of concerns. At first, the objectives of generic QoS management are briefly introduced and a short overview of an object-oriented distribution infrastructure is presented. The major part of the paper deals about the QoS concerns and their embeddment in the application and the mechanism hierarchie respectively. After the related work is discussed, the paper closes with a conclusion and an outlook. 2 Objectives and Properties of generic QoS Management 2.1 Definitions The importance of QoS provision has been recognized and manifested already in documents such as [14], [9], and [8]. For sake of brevity we don t present these definitions here and only supplement definitions of QoS management architectures. QoS management architectures provide a coherent set of abstractions and components in order to enable applications for QoS handling. A QoS framework combines interfaces and mechanisms that support the development, implementation and operation of QoS enabled applications. It also provides infrastructure services such as for the negotiation of QoS agreements and for monitoring them. Furthermore,

2 access points for the communication are part of the framework. QoS management architectures can be classified by two criteria (among others): Generic QoS management architectures allow the definition and implementation of arbitrary QoS characteristics. In contrast, non-generic QoS management architectures only provide a fixed set of QoS parameters and corellative QoS mechanisms. Multi-category QoS management architectures support several different QoS categories, e.g. fault-tolerance and real-time, in contrast to single-category QoS management architectures. 2.2 QoS Properties and Requirements QoS provision for interactions between a client and a service has to be done along the whole path of communication through the system. From a client and service perspective, only the actual service quality perceived at the top layer is relevant. However, implementing QoS addresses all layers and is a system dependent task. Underlying layers have to support a distinct quality as a base for the quality of the upper layers. A distributed object system encounters manifold application requirements during its lifetime. Hence, a QoS management architecture should provide the ability to grow and change with its environment. Technically, this implies genericity and multi-category support. Providing genericity and multi-category support alone is not sufficient to meet the user requirements. Separation of concerns must be an objective here. Client and service code should not be mixed unnecessarily with QoS specific behaviour, and the complexity of QoS implementations should be transparent for application developers. The QoS support framework should not stop at the design and implementation time but rather provide assistance throughout the whole application lifetime. Thus, infrastructure services for e.g. trading, negotiation, monitoring and accounting should be an integral part of the framework. However, in the context of this paper the focus will be merely on the structure of QoS mechanisms and the separation of concerns in the framework. 2.3 Object-oriented Middleware Object-oriented middleware denominates a layer of software between applications and the underlying platform, i.e. operating system and network. Based on the object model abstractions are offered which allow the communication with remote objects as if they were local objects. Figure 1 illustrates the components of a middleware architecture CORBA [17] as an example at runtime. On the client side access to the remote object is established through a stub or proxy object which offers the same service Client Invocation I Stub Client ORB Application centered QoS Network centered QoS Skeleton Skeleton I Object Adapter Server ORB Service Network Figure 1. Layers of potential QoS in CORBA as the remote object. The stub collects all calls to the server and hands them over to the object request broker (ORB). The ORB is responsible for locating target objects and delivering requests. The skeleton on the server side reflects the pendant to the stub object. Incoming requests via the ORB are delegated to the service. A designated protocol on the network layer can ensure interoperability. The potential heterogeneity of client and server objects is solved through an interface definition language (IDL). The interfaces of a service are specified in the language neutral IDL and translated into implementation languages which may differ between client and service side. 3 QoS concerns and application objects The IDL definition of an interface is translated into the target language of client and server. Application programmers rely on the abstractions provided by stub and skeleton object. Thinking of QoS provision as a client/server relationship means in terms of an object-oriented middleware the interaction between stub and skeleton object have to be augmented with QoS specific behaviour. The integration of QoS provision in middleware has to address the following points: ffl QoS specification: QoS parameters have to be specified along with the operations a distinct QoS mechanism offers in oder to be customized, configured, and monitored. There are additional responsibilities covered in the specification which arise from the aspect nature of QoS in distributed object systems. These are covered in subsection 3.1. ffl QoS mechanism integration: The specification of QoS parameters and the operation of the related QoS mechanisms is not enough. QoS provision has to be integrated thus QoS mechanisms can ensure the QoS requirements along the communication path between

3 client and server. Figure 1 illustrates two possible layers of QoS integration in an object-oriented middleware platform. In this section the focus is set on the application centered QoS mechanism integration and the separation of application logic from QoS mechanisms. ffl QoS binding: So far, the discussion has separated the QoS concerns from the application logic and demanded a proper separation in the system. However, in order to attribute the interactions between client and service with a distinct QoS provision an assignment of a QoS characteristik to the client/server relationship has to be established. This assignement can vary in time, e.g. assigment at design/implementation time or at runtime, and in granularity, e.g. assigment of QoS to parameters, operations, or interfaces. ffl QoS adaptation: The possible level of a QoS characteristic depends on the resource availability in the system. Additionally the location of client and server is important. Hence, there is no system wide view on the QoS capability of a system but each QoS agreement has to be negotiated independently. Moreover, varying resource availability should be addressed through adaption, i.e. renegotiations if the resource availability in- or decreases. The next subsection will cover an important property of QoS when integrated in an object model. Based on this insight, an extension of the IDL will be presented which offers separation of QoS and application concerns. 3.1 QoS as an aspect in the sense of AOP The aspect oriented programming approach (AOP) [10] provides a classification of modelling effects. Components are entities which can be clearly encapsulated using the abstractions of the underlying paradigm, i.e. procedures in imperative programming or classes in the object model. In constrast to components Aspects are referred to as being not properly encapsulated. Aspects are characterized through their cross-cut among other entities. Examples are errorhandling by exceptions, optimization of numerical applications, and synchronization as well as distribution of objects. Besides the classification, the AOP offers a solution to the integration of aspects. Aspects are described in specialized languages. A tool the AspectWeaver combines the aspects and emits a program built from the aspects and their dependencies. QoS is an aspect in the sense of the AOP considering an object model for the application logic. First, QoS is not self-contained. A QoS characteristic for availability is not an entity of its own, but rather an ability of another entity. Furthermore, QoS mechanisms tangle with application objects. Again, let us consider availability. Crashes of servers can be masked when using a group of replicas. As long as there is one replica running, the service can be fulfilled. This implies that every replica delivers the same result upon a request. Hence, new replicas need to be initialized to the same state as already running replicas. The state of a server is encapsulated by the interface. Therefore, the ability for this QoS violates the encapsulation of a server. The classification of QoS as an aspect is shared by other approaches as well [12], [6]. 3.2 QoS Specifications in QIDL The already involved languages in object-oriented middleware are related with the interface and the implementation of objects. In our QoS framework, we extend the interface definition language with QoS specifications the Quality of Service IDL, called QIDL and provide the aspect weaving through a distinct mapping to entities in the target language. A deeper discussion of specification alternatives and the specification as well as the mapping can be found in [3]. Basically, a QIDL specification consists of the QoS parameters and the operations related with the QoS responsibility. The QoS responsibility is related with the following tasks: ffl QoS mechanism management: Operations concerned with the initial setup, control, and monitoring of QoS mechanisms. ffl QoS to QoS: QoS mechanisms on client and service side have to communicate in order to establish a QoS enabled communication, e.g. exchange of multicast address or on the fly change of encryption keys. These should use the underlying middleware and therefore have to provide an interface. ffl QoS aspect integration: Beside the merging of QoS and application aspects which will be covered in the next subsection additional customization might be necessary in order to provide clear interfaces between the aspects, e.g. access to an objects state for replica groups. QoS specifications in QIDL can be assigned to interfaces only. This is an implication from the underlying interface to object relation. Possible conflicts between different QoS characteristics if finer granularity is considered are hard to resolve and therefore forbidden, i.e. QoS assignment to operations or parameters.

4 3.3 Decoupling of aspects through the QIDL language mapping The aspects QoS and application are specified in QIDL. The implementation of the aspects in the target language and their separation is accomplished by the QIDL language mapping. Basically, the aspect weaving focuses on the QoS mechanisms on the application layer. The internal structure of QoS mechanisms is a different concern. We will come back to it in section 4. The mapping of QIDL has to ensure two objectives: ffl Aspect Integration: QoS related behaviour has to be called for each request: client side: before the request is handed over to the ORB. server side: before the request is delivered to the server. server side: after processing before the result is handed over to the ORB. client side: before the result is handed back to the client. Hence, there have to be skeletons for the QoS implementation which are called accordingly by the stub and skeleton object. Moreover, the aspect integration on server side has to take care that the interface between application and QoS is appropriately handled. ffl Decoupling: While the injection of precautions for QoS handling in the request path can be done transparently to client and service, the decoupling of the server side aspect integration needs additional care. The awareness of an application should be restricted to this interface in order to maximize the decoupling. On the client side the stub is extended by a so called mediator. The QoS implementor implements the generated mediator skeleton. At runtime the mediator of the desired QoS is set in the stub as a delegate. Each call is intercepted and delegated to the mediator which can issue the QoS behaviour on the client side. For each QoS characteristic a mediator is generated. The server side mapping is a bit more complicated. The mapping has to ensure that a QoS enabled server accepts potentially all assigned QoS operations. But only those of the actual negotiated QoS characteristic should be processed. Along with that, the QoS related behaviour should be handled by the QoS implementation. Only the QoS server side aspect integration should be forwarded to the server. In figure 2 the server side mapping is sketched. The server inherits from the QoS skeleton and the server skeleton or Client Server QoS- Skel Server- Skeleton QoS- Impl. Figure 2. QIDL: server side mapping in case of more assigned QoS from a list of QoS skeletons. The server skeleton is extended by a delegate to the actual QoS implementation. This will be exchanged at runtime to the actual QoS characteristic s QoS implementation. Hence, only the operations of the actual negotiated QoS characteristic are processed while others raise an exception. The server skeleton takes incoming requests from the ORB and calls a prolog and an epilog operation on the QoS implementation before and after the operation is processed by the server. As a result, the QIDL compiler acts as an aspect weaver, which combines the application objects with QoS provision. Little adaptation has to be provided when a QoS characteristic needs responsibility from the server. But this cross-cut of aspects is separated through a dedicated interface. 4 QoS concerns and their hierarchical structure Another important concern when generic QoS management is addressed is the hierarchical decomposition of QoS mechanisms along the communication path. The integration of QoS mechanisms so far has only dealt with the application centered QoS provision. This is sufficient for a variety of different QoS characteristics, e.g. load balancing, encryption. However, in order to reuse existing QoS mechanisms from the underlying network, operating system, or libraries, e.g. bandwidth reservation, scheduling, or group communication, some precautions have to be integrated into the ORB. This allows the structuring of QoS mechanisms along the hierarchie of involved layers. Figure 3 illustrates the integration of QoS mechanisms into the ORB. A request between client and server with QoS awareness is tagged, thus the invocation interface can decide how to dispatch the request internally. The QoS transport is an entity which administrates all QoS transport modules. Each QoS module offers a common static interface and a specific dynamic interface. The common interface allows the dynamic loading of QoS modules on request. The

5 QoS-Module No Invocation Interface With QoS? rely on the QoS mechanisms on transport layer, which are constituted as QoS modules in the QoS transport. A simple reflection mechanism allows the extension of the ORB at runtime. 5 Related Work GIOP IIOP QoS-Transport Module? No IIOP-Module request? Modul-Command No: command Module? Figure 3. QoS Integration into the ORB dynamic interface offers the necessary module specific interface, e.g. reserve a distinct bandwidth or assign a client to an object group. The static interface is modelled as a pseudo object and therefore can be accessed like any other object whereas the dynamic interace is handled through the dynamic invocation interface (DII) which is part of standard CORBA. The CORBA request is used in a dual fashion. Naturally, it is used to transport a service-request from the client to the server. It is also used, to configure and control the QoS mechanisms and the QoS transport in the ORB. The request is tagged, indicating whether it is used as a command or a request. A command can be interpreted by the QoS transport or any of the modules which is specified in the target member of the request. The different interpretations of a request are illustrated in figure 3. Requests with no QoS awareness are handed over to the GIOP/IIOP-transport of the ORB. If a request is QoS aware which can be determined by a distinct tag in the interoperable object reference (IOR) it is handed over to the QoS transport. If the request is a command to either the QoS transport or a QoS module it is dispatched to the corresponding entity. If the request is a QoS aware servicerequest it is delivered through an assigned QoS module. If a QoS module is not assigned to a client server relationship the GIOP/IIOP module is used. This allows initial negotiation of a QoS agreement between client and service as well as communication between the QoS mechanisms in order to setup the necessary precautions for the QoS provision. As a result, the QoS mechanisms built a hierarchie with two layers. The first layer is constituted by the QoS mechanisms on the application layer. These mechanisms are generated as implementation skeletons from the QIDL specifications. The implementation of these QoS mechanisms can No Transport-Command The classification of QoS as an aspect in the sense of AOP is recognized by other groups as well. The Quality Objects (QuO) project addresses QoS concerns by an AOP based approach on the application layer and through an augmented ORB on transport layer [12], [11], [19]. Composition Filters [6] are a different approach which address layered QoS mechanisms as aspects in distributed middleware architectures in combination with reflection. Meta Spaces [7] address the same topic as composition filters. Again, there is a combination of aspect separation on the application layer and reflection in order to compose hierarchies of mechanisms. QoS provision for object-oriented middleware is not only a topic within the AOP community. The need for QoS provision in middleware platforms has been targeted by several groups from research and industry. The Ace Orb (TAO) [18] is an extension of CORBA to provide hard real-time guarantees. Electra [13] allows for the fault tolerant services via the integration of multicast protocols in CORBA. The Object Management Group has als recognized the need for distinct QoS categories and addresses them in actual specifications, like the CORBA messaging [15] or the CORBA Realtime [16]. However, these specifications are specialized for a distinct QoS category only and still lack of some necessary informations. The pluggable protocols from the CORBA Realtime specification for instance need further refinement as stated in the specification. 6 Conclusion and Outlook This paper presented an overview of our research how to integrate QoS aspects in common object-oriented middleware. Our main objective is a clear separation of concern. This lead to two major concerns which are addressed independently. QoS mechanisms are an aspect in the sense of the AOP when beeing integrated in an object-model. We provided an aspect oriented approach relying on an extension of IDL for the aspect specification and a corresponding mapping into the target language in order to separate QoS from application concerns. Because of the end-to-end view of QoS provision, QOS mechanisms form a hierarchie. The structure of this hierarchie is supported by a well defined integration of QoS mechanisms into the ORB. Relying on the dynamic invocation interface a simple reflection mechanism can be established allowing dynamic loading of QoS mechanisms.

6 So far the framework has been evaluated by implementing QoS characteristics from diverse QoS categories, e.g. fault-tolerance through replica groups, performance by load-balancing, compression for channels with small bandwidth, actuality of data, and privacy through encryption. The documentation of such QoS characteristics has to be targeted at two groups. First, application developers who want to use a distinct QoS characteristic and need to know how to use it and which possible adaption has to be provided and second, QoS implementors who might want to reuse distinct QoS mechanisms from an existing QoS characteristic, e.g. a multicast on network layer can be used for k-availability as well as for diversity through majority votes on results. We think, that a catalog similar to those for design patterns is an appropriate way to document QoS implementations. Since our work aims at QoS management in a larger context, additional support is needed at runtime in order to allow negotiation and accounting of QoS enabled communication. Currently our work focusses on the implementation of infrastructure services. However, QoS induces one more concern in the system which has to be handled at runtime. The rating of which QoS cahracteristic and its level is preferable to another is depending on the client. There is no system wide shared view on QoS levels especially when the price is embraced. Therefore, client preferences have to be incorporated in the negotiation process. For sake of brevity, this concern is not presented here. An overview can be found in [5]. [9] International Telecommunication Union (ITU). E.800 Quality of Service and Dependability Vocabulary, [10] G. Kiczales et al. Aspect-Oriented Programming. Technical Report SPL97-008P , Xerox Palo Alto Research Center, [11] J. P. Loyall, R. E. Schantz, J. A. Zinky, and D. E. Bakken. Specifying and Measuring Quality of Service in Distributed Object Systems. In Proceedings of ISORC 98, Kyoto/Japan, April [12] J.P. Loyall, D. E. Bakken, R. E. Schantz, J. A. Zinky, D.A. Karr, R. Vanegas, and K.R. Anderson. QoS Aspect Languages and their Runtime Integration. Springer LNCS, [13] S. Maffeis. Adding Group Communication and Fault Tolerance to CORBA. In Proceedings of the USENIX Conference on Object Oriented Technologies, June [14] Object Management Group (OMG). Quality of Service (QoS) OMG Green Paper, , June [15] Object Management Group (OMG). CORBA Messaging. Technical Report orbos/ , OMG, Framingham, MA, [16] Object Management Group (OMG). Realtime CORBA, joint submission. Technical Report orbos/ , OMG, Framingham, MA, [17] Object Management Group (OMG). The Common Object Request Broker: Architecture and Specification (Revision 2.3). Technical Report , Object Management Group (OMG), Framingham, MA, July [18] D. C. Schmidt, D. L. Levine, and S. Mungee. The Design of the TAO Real Time Object Request Broker. Computer Communications Journal, [19] J. A. Zinky, D. E. Bakken, and R. E. Schantz. Architectural Support for Quality of Service for COBA Objects. Theory and Practice of Object Systems, Vol. 3(1), 55-73, References [1] C. Becker and K. Geihs. MAQS - Management for Adaptive QoSenabled Services. In Proceedings of IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, San Francisco, USA, December [2] C. Becker and K. Geihs. QoS as a Competitive Advantage for Distributed Object Systems. In Proceedings of EDOC 98, La Jolla, USA, November [3] C. Becker and K. Geihs. Generic QoS Specifications for CORBA. In Proceedings of KIVS 99, Darmstadt, Springer Verlag, Germany, March [4] C. Becker and K. Geihs. Generic QoS-Support for CORBA. In Proceedings of ISCC 00, Antibes, France, July [5] C. Becker, K. Geihs, and J. Gramberg. Representing Quality of Service Preferences by Hierarchies of Contracts. In Elektronische Dienstleistungswirtschaft und Financial Engineering, Augsburg, Germany, September [6] L. M. J. Bergmans and M. Aksit. Aspects and Crosscutting in Layered Middleware Systems. In Reflective Middleware Workshop (RM 2000), New York/USA, April [7] G. S. Blair, G. Coulson, P. Robin, and M. Papathomas. An Architecture for Next Generation Middleware. In Proceedings of Middleware 98, The Lake District/England, September [8] International Organization for Standardization (ISO). Quality of Service Basic Framework N9309, 1995.