Germán Sánchez., who played an important role in my Master's degree, for all their ... 1.3 The Role of Resource Management in Distributed Multimedia Systems.
A Resource Management Framework for Reflective Multimedia Middleware
Héctor Alejandro Durán-Limón B.Sc. Autonomous Metropolitan University (UAM), 1991 M.Sc. Autonomous National University of Mexico (UNAM), 1996
Computing Department Lancaster University, UK
A Thesis Submitted for the degree of Doctor of Philosophy October, 2001.
Abstract A Resource Management Framework for Reflective Multimedia Middleware Héctor A. Durán-Limón The last decades have experienced a rapid expansion of computer network systems. In addition, different operating systems and hardware platforms have emerged. These facts have led to problems of heterogeneity and complexity. To tackle this situation object-oriented middleware technologies, such as CORBA and DCOM, have recently been developed. These technologies have succeeded in providing standardised programming models that address the problems mentioned above. However, the monolithic and inflexible nature of current middleware has made it difficult to deal with emerging technologies such as multimedia. That is, distributed multimedia applications have timeliness constraints that are severely affected by changes introduced into the environment. Therefore, there is a need to achieve support for configuration and reconfiguration in middleware. Resource management plays an important role in this adaptation process in terms of both resource awareness and dynamic reallocation of resources. The former is related to facilities for discovering the availability of resources. This information is useful for both carrying out checks on the allocation of resources and driving adaptation decisions. The latter is then related to the dynamic reconfiguration of the resources system, e.g. a redistribution of CPU-time to the processes currently run in the system. This clearly requires a much higher-level of openness than that provided by existent platforms. This thesis investigates the support required in reflective multimedia middleware platforms for both the configuration and reconfiguration of resources. Reflection techniques are used as a structured and principled approach for obtaining openness. A resource framework is presented that offers support for resource management in reflective middleware. This framework encompasses both a resources model and a task model. The former is in charge of representing the physical resources of the system at various levels of abstraction whereas the latter allows for the high-level analysis and design of the resources sub-system. In addition, two description
i
languages namely, Xelha and the RCDL are introduced. These languages aim at specifying configuration and reconfiguration aspects of the resources sub-system. The proposed approach is validated by the implementation of a prototype of the framework. In addition, the implementation of a case study demonstrates the feasibility of the work carried out in this thesis.
ii
Declaration This thesis has been written by myself and the work reported here is my own. I have been financially supported by the Autonomous National University of Mexico (UNAM) and also partially funded by the “The OpenORB Project - The Role of Reflection in the Design of Middleware Platforms” sponsored by France Telecom R&D (Grant Reference CNET-981B272). The work reported in this thesis has benefited from the discussions with colleagues in the reflection group at Lancaster University. The overall OpenORB framework is a joint effort to which the research presented in the thesis has contributed. Some initial insights on the resource model were provided by Jean-Bernard and his group at CNET. The resource framework comprising both the resource model and the task model (sections 4.3 and 4.4) were developed and integrated into the OpenORB architecture by myself. In addition, the Xelha and RCDL description languages (sections 5.2 and 5.3) were designed by myself. Furthermore, I developed a prototype for the purposes of evaluating the proposed approach. The prototype comprises: extensions to existent technologies, a particular instantiation of the resource framework and tool support for the description languages (section 6.4). The work reported in this thesis has not been previously submitted for a degree, in this or any other form.
iii
Acknowledgements In the first place, I would like to thank my sponsor the Autonomous National University of Mexico. I would also like to thank Dr. Hanna Oktaba and Dr. Victor Germán Sánchez., who played an important role in my Master’s degree, for all their support and encouragement for me to pursue a Ph.D. I also thank Dr. Fabián García Nocetti for all the support he provided me as my national supervisor. Particular thanks are due to Jean-Bernard Stefani and his group at CNET who provided one of the cornerstones for the development of the research reported in this thesis. I would also like to thank the colleagues of the reflection group who provided an environment of interesting discussions and helpful feedback. In particular, special thanks are due to Dr. Geoff Coulson for all his advice and patience in teaching me the internals of GOPI. I also thank my supervisor, Professor Gordon G. Blair, for all his great willingness and helpful support for conducting the well development of this research. The work carried out would not have reached maturity without his precious advice. Finally, I wish thank my family for providing unconditional support throughout. Especial thanks are due to my father who was the first person to encourage me to do a Ph.D. I also want to mention that I thank Alan, my son, for smiling at me when I get home after a difficult day. Above all, I would like to extend very especial thanks to Edna, my wife, for providing endless support in the most difficult moments of my Ph.D. I thank her for sharing with me the good and the bad moments of my studies. Her deep love and constant encouragement made the completion of this thesis possible.
iv
With love to Edna
v
Contents
CHAPTER 1 ........................................................................................................................................... 1 INTRODUCTION ..................................................................................................................................... 1 1.1 Overview .................................................................................................................................... 1 1.2 Open Distributed Processing and Middleware .......................................................................... 1 1.3 The Role of Resource Management in Distributed Multimedia Systems.................................... 4 1.3.1 The Nature of Multimedia ................................................................................................... 4 1.3.2 The Need for Adaptation in Distributed Multimedia Systems ............................................ 5 1.3.3 Resource Management in Distributed Multimedia Systems................................................ 6 1.4 Adaptive Middleware ................................................................................................................. 7 1.5 Reflection.................................................................................................................................... 8 1.5.1 Overview of Reflection ....................................................................................................... 8 1.5.2 Towards Reflective Middleware ......................................................................................... 9 1.6 Aims.......................................................................................................................................... 10 1.7 Structure of the Thesis.............................................................................................................. 10 CHAPTER 2 ......................................................................................................................................... 13 TOWARDS ADAPTIVE MIDDLEWARE ................................................................................................... 13 2.1 Introduction.............................................................................................................................. 13 2.2 What is Middleware? ............................................................................................................... 13 2.2.1 Types of Middleware......................................................................................................... 14 2.2.2 Discussion ......................................................................................................................... 16 2.3 Requirements for Object-Oriented Multimedia Middleware.................................................... 16 2.4 Major Object-Oriented Middleware Standards and Technologies .......................................... 19 2.4.1 Reference Model of Open Distributed Processing ............................................................ 19 2.4.2 CORBA ............................................................................................................................. 22 2.4.3 DCOM and .NET .............................................................................................................. 24 2.4.4 Java/RMI ........................................................................................................................... 27 2.4.5 Analysis............................................................................................................................. 28 2.5 Reflection.................................................................................................................................. 29 2.5.1 Open Implementations ...................................................................................................... 29 2.5.2 The Emergence of Reflection............................................................................................ 30 2.6 Reflection in Object-Oriented Languages and Systems............................................................ 32 2.6.1 Overview ........................................................................................................................... 32 2.6.2 Relevant Reflective OOLs and Systems............................................................................ 33 2.6.3 Analysis............................................................................................................................. 37 2.7 Reflective Middleware.............................................................................................................. 37 2.7.1 Introduction ....................................................................................................................... 37 2.7.2 FlexiNet............................................................................................................................. 38 2.7.3 OpenCorba ........................................................................................................................ 39 2.7.4 Quarterware....................................................................................................................... 40 2.7.5 dynamicTAO and UIC ..................................................................................................... 41 2.7.6 mChaRM ........................................................................................................................... 43 2.7.7 Analysis............................................................................................................................. 44 2.8 Summary................................................................................................................................... 46 CHAPTER 3 ......................................................................................................................................... 48 RESOURCE MANAGEMENT IN MIDDLEWARE ....................................................................................... 48 3.1 Introduction.............................................................................................................................. 48 3.2 Requirements for Resource Management in Multimedia Middleware ..................................... 48 3.3 Approaches to Resource Management in Middleware............................................................. 50 3.3.1 The Global Resource Management System....................................................................... 50 3.3.2 The ERDoS QoS Architecture........................................................................................... 52
vi
3.3.3 QuO Project....................................................................................................................... 55 3.3.4 The Agilos Architecture .................................................................................................... 57 3.3.5 Other Research .................................................................................................................. 58 3.3.6 Analysis............................................................................................................................. 62 3.4 Standards for Resource Management in Middleware .............................................................. 63 3.4.1 Real-Time CORBA ........................................................................................................... 63 3.4.2 Dynamic Scheduling Real-Time CORBA......................................................................... 66 3.4.3 UML Profile for Scheduling.............................................................................................. 68 3.4.4 Analysis............................................................................................................................. 70 3.5 Summary................................................................................................................................... 71 CHAPTER 4 ......................................................................................................................................... 72 THE RESOURCE FRAMEWORK ............................................................................................................. 72 4.1 Introduction.............................................................................................................................. 72 4.2 Background on the OpenORB Architecture ............................................................................. 72 4.2.1 Overall Approach .............................................................................................................. 72 4.2.2 Meta-Space........................................................................................................................ 73 4.3 Resource Model........................................................................................................................ 76 4.3.1 Overview ........................................................................................................................... 76 4.3.2 The Resource, the Factory and Manager Hierarchies........................................................ 77 4.3.3 The Resources Meta-Object Protocol................................................................................ 79 4.3.4 Providing QoS Management Support for the Resource Model ......................................... 84 4.4 The Task Model ........................................................................................................................ 87 4.4.1 Overview ........................................................................................................................... 87 4.4.2 Tasks and VTMs ............................................................................................................... 88 4.4.3 Task Graph Configurations ............................................................................................... 91 4.5 An Explanatory Example of the Resource and Task Models .................................................... 93 4.5.1 Introspection and Fine-Grained Reconfiguration .............................................................. 93 4.5.2 Coarse-Grained Reconfiguration....................................................................................... 95 4.6 Summary................................................................................................................................... 97 CHAPTER 5 ......................................................................................................................................... 98 ENGINEERING ADAPTIVE RESOURCE MANAGEMENT .......................................................................... 98 5.1 Overview .................................................................................................................................. 98 5.2 Xelha: a Resource-Aware ADL ................................................................................................ 99 5.2.1 Introduction ....................................................................................................................... 99 5.2.2 Components, Connectors and Interfaces ......................................................................... 100 5.2.3 QoS Management ............................................................................................................ 105 5.2.4 A Complete Example of the Use of Xelha ...................................................................... 111 5.3 A Description Language for the Specification of Resource Management.............................. 115 5.3.1 Overview ......................................................................................................................... 115 5.3.2 Aspect Languages of the RCDL...................................................................................... 116 5.4 Summary................................................................................................................................. 125 CHAPTER 6 ....................................................................................................................................... 126 SYSTEM PROTOTYPING ..................................................................................................................... 126 6.1 Introduction............................................................................................................................ 126 6.2 Overall Approach................................................................................................................... 126 6.3 Background on Technologies Used ........................................................................................ 127 6.3.1 Overview ......................................................................................................................... 127 6.3.2 OOPP............................................................................................................................... 128 6.3.3 GOPI ............................................................................................................................... 129 6.3.4 QoSMonAuTA ................................................................................................................ 131 6.4 Implementation....................................................................................................................... 132 6.4.1 Overview ......................................................................................................................... 132 6.4.2 Extensions to GOPI and Python’s Interface of GOPI ..................................................... 133 6.4.3 Extensions to OOPP ........................................................................................................ 141 6.4.4 The Resource Framework ............................................................................................... 146 6.4.5 The ADL Tool................................................................................................................. 150 6.5 Summary................................................................................................................................. 155
vii
CHAPTER 7 ....................................................................................................................................... 156 EVALUATION .................................................................................................................................... 156 7.1 Introduction............................................................................................................................ 156 7.2 Quantitative Evaluation ......................................................................................................... 156 7.2.1 Overview ......................................................................................................................... 156 7.2.2 Evaluation of the Prototype’s Overhead.......................................................................... 157 7.2.3 Evaluation of the Facilities for Dynamic CPU Reconfiguration ..................................... 162 7.2.4 Discussion ....................................................................................................................... 176 7.3 Qualitative Evaluation ........................................................................................................... 177 7.3.2 Resource Framework....................................................................................................... 177 7.3.3 Description Languages .................................................................................................... 183 7.4 Summary................................................................................................................................. 186 CHAPTER 8 ....................................................................................................................................... 188 CONCLUSIONS ................................................................................................................................... 188 8.1 Introduction............................................................................................................................ 188 8.2 Summary of the Thesis............................................................................................................ 188 8.3 Contributions.......................................................................................................................... 191 8.3.1 Main Contributions ......................................................................................................... 191 8.3.2 Other Significant Contributions ...................................................................................... 194 8.4 Future Work ........................................................................................................................... 195 8.4.1 Extension of the Resource Framework’s Prototype ........................................................ 195 8.4.2 Integration of Resource Meta-Space with Other Meta-Spaces........................................ 196 8.4.3 More Comprehensive Support for the Description Languages ....................................... 196 8.4.4 Operating System Support for Multimedia Middleware ................................................. 197 8.5 Concluding Remarks .............................................................................................................. 197 APPENDIX A ..................................................................................................................................... 199 REFERENCES................................................................................................................................... 202
viii
Figures Figure 2.1 Viewpoints in RM-ODP....................................................................................................... 21 Figure 4.1. The Structure of the Meta-Space......................................................................................... 74 Figure 4.2. The Resource Management Framework ........................................................................... 77 Figure 4.3. A Particular Instantiation of the Resource Meta-Model ..................................................... 78 Figure 4.4. An Example Integrating the Three Hierarchies of the Resource Framework ..................... 79 Figure 4.5. UML Class Diagram of the Resource Framework Including Most of the Resources MOP 80 Figure 4.6. QoS Management Support for the Resource Framework.................................................... 85 Figure 4.7. UML Diagram of Relationships between Tasks and VTMs ............................................... 89 Figure 4.8. Example of a Task Hierarchy with its Associated VTMs ................................................... 90 Figure 4.9. Types of Task Switching Points.......................................................................................... 92 Figure 4.10. Example Scenario ............................................................................................................. 93 Figure 4.11. Internal Configuration of the Audio Binding 1 ................................................................. 94 Figure 5.1 Component Specification................................................................................................... 100 Figure 5.2 Example of a Connector Specification............................................................................... 102 Figure 5.3. Example of an Interface Specification .............................................................................. 102 Figure 5.4. Dynamic System Architecture .......................................................................................... 104 Figure 5.5. The UML Inheritance Diagram of the StreamBinding Connector Type........................... 105 Figure 5.6 Example of a Component Configuration Associated with Task Graphs............................ 106 Figure 5.7 Representation of task switching points in UCM............................................................... 106 Figure 5.8 Task Specification.............................................................................................................. 107 Figure 5.9. Example of the Specification of the System Architecture’s Services. ............................. 108 Figure 5.10 QoS Management Structure Specification. ...................................................................... 109 Figure 5.11. Example of Connector with a QoS Management Structure. ........................................... 111 Figure 5.12. Audio System Architecture. ............................................................................................ 111 Figure 5.13. Audio System Architecture Specification ...................................................................... 112 Figure 5.14. Interface Specification .................................................................................................... 113 Figure 5.15. Specification of the AudioConnection Component Type. ....................................... 113 Figure 5.16. Task Specification........................................................................................................... 114 Figure 5.17. Example of SDL Descriptions ........................................................................................ 118 Figure 5.18. Example of TSDL Descriptions ...................................................................................... 119 Figure 5.19. Example of Object Configuration Associated with Two Tasks ...................................... 120 Figure 5.20. Definitions in TDL.......................................................................................................... 121 Figure 5.21. Example of the Specification of Abstract Resources. ..................................................... 122 Figure 5.22. Example of a Protocol Stack Sharing CPU Resources.................................................... 122 Figure 5.23. Example of RDL Descriptions ........................................................................................ 123 Figure 5.24. Example of QMGDL Descriptions. ................................................................................ 124 Figure 6.1. Implementation of the Resource Framework .................................................................... 127 Figure 6.2. Component Configuration of QoSMonAuTA................................................................... 131 Figure 6.3. Priority Scheduling Structure............................................................................................ 139 Figure 6.4. Example of the Generation of a Dispatch Table. .............................................................. 140 Figure 6.5. Interceptors. ...................................................................................................................... 142 Figure 6.6. New Version for Local Bindings. ..................................................................................... 143 Figure 6.7. Internal Configuration of an Audio Binding. .................................................................... 144 Figure 6.8. UML Class Diagram of Resources. .................................................................................. 147 Figure 6.9. UML Class Diagram of Factories. .................................................................................... 147 Figure 6.10. UML Class Diagram of Managers. ................................................................................. 148 Figure 6.11. Processing Xelha Specifications. .................................................................................... 151 Figure 6.12. Generated Object Class for the AudioConnector_V1 Component Type. ................ 152 Figure 6.13. TSDL Descriptions Generated by the Tool..................................................................... 153 Figure 6.14. SDL Descriptions Generated by the Tool. ...................................................................... 153 Figure 7.1 Introspection of the Lower-Level Resources of a VTM .................................................... 157 Figure 7.2. Scenario 1 ........................................................................................................................ 163 Figure 7.3 Structure of a Binding Component .................................................................................... 164 Figure 7.4 Timed Automata Specification of the Automaton Component .......................................... 164 Figure 7.5. Task Description Language (TDL) ................................................................................... 165
ix
Figure 7.6 RDL Descriptions for transmitAudio_V1.................................................................. 166 Figure 7.7 Code Executed for the CPU Reconfiguration .................................................................... 168 Figure 7.8 Inter-Packet Time Measurement for the Audio Binding 1 and the Audio Binding 2 in Scenario 1 without CPU Reconfiguration .................................................................................... 169 Figure 7.9 Inter-Packet Time Measurement for the Audio Binding 3 in Scenario 1 without CPU Reconfiguration............................................................................................................................ 170 Figure 7.10 Inter-Packet Time Measurement for the Audio Binding 1 and the Audio Binding 2 in Scenario 1 with CPU Reconfiguration ......................................................................................... 170 Figure 7.11 Inter-Packet Time Measurement for the Audio Binding 3 in Scenario 1 with CPU Reconfiguration............................................................................................................................ 171 Figure 7.12 Inter-Packet Time Measurement for the Audio Binding 3 in Scenario 2 without CPU Reconfiguration............................................................................................................................ 172 Figure 7.13 Inter-Packet Time Measurement for the Audio Binding 1 and the Audio Binding 2 in Scenario 2 without CPU reconfiguration. .................................................................................... 173 Figure 7.14 Inter-Packet Time Measurement for the Audio Binding 3 in Scenario 2 with CPU Reconfiguration............................................................................................................................ 174 Figure 7.15 Inter-Packet Time Measurement for the Audio Binding 1 and the Audio Binding 2 in Scenario 2 with CPU reconfiguration. ......................................................................................... 174 Figure 7.16 Inter-Packet Time Measurement for Audio Binding 3 and Performance of a Loop Test Program in Scenario 3. ................................................................................................................. 176
x
Tables Table 2.1. Summary of Evaluation of Reflective Middleware Platforms.............................................. 46 Table 3.1. Summary of Evaluation of Middleware Platforms. .............................................................. 63 Table 3.2. Summary of Evaluation of Standards. .................................................................................. 71 Table 4.1. Operations on the Resources Meta-Object ........................................................................... 82 Table 4.2. The MOP of the QoS Manager, Resource Server and Resource Server Proxy .................... 86 Table 5.1. Aspect Languages of RCDL............................................................................................... 117 Table 6.1. Operations Added to the GOPI’s Thread Module. ............................................................. 134 Table 6.2. Operations Provided by the Module typethread. ......................................................... 137 Table 6.3. Operations Provided by the Module bpooltype............................................................. 137 Table 6.4. Operations Provided by the Module AuBuf. .................................................................... 138 Table 6.5. Comparison of Compression Algorithms. .......................................................................... 145 Table 7.1. Time Taken to Perform Introspection of the Lower-Level Resources of a VTM............... 158 Table 7.2. Times Taken to Generate the Dispatch Table when Using Rate-Monotonic Policy .......... 158 Table 7.3. Average Time to Perform CPU Reconfiguration for Lottery Scheduling .......................... 159 Table 7.4. Time Taken by the First Scheduling level when Using the Lottery Scheduling................. 159 Table 7.5. Time Taken by the First Scheduling level when Using Rate-Monotonic ........................... 160 Table 7.6. Time Taken by the Second Scheduling level when Using Round Robin ........................... 160 Table 7.7. Overhead imposed by task interceptors and buffer interceptors......................................... 161 Table 7.8. Time Taken to Create a VTM............................................................................................. 161 Table 7.9. Fulfilment of Requirements for the Resource Framework ................................................. 183 Table 7.10. Fulfilment of Requirements for the Description Languages............................................. 186
xi
Chapter 1 Introduction 1.1 Overview The rapid expansion of computer network systems such as the Internet has led to problems of heterogeneity and complexity. To tackle these problems middleware technologies such as CORBA [OMG01a], .NET [Microsoft00a] and Enterprise Java Beans [Sun01a] have recently been developed. Heterogeneity is overcome by the provision of a platform and language independent programming model. In addition, the provision of facilities such as name resolution and object location help to alleviate the inherent complexity of distributed systems. However, the monolithic and inflexible nature of current middleware has made it difficult to deal with applications that have dynamic requirements, such as those of soft real-time applications (e.g. experiencing a shortage of computing resources as a result of unexpected changes to the environment). This thesis examines the issue of introducing more openness into middleware platforms for the support of dynamic reconfiguration of resources in distributed multimedia systems. This chapter discusses the emergence of middleware platforms and the need to introduce adaptation mechanisms for distributed multimedia systems. Furthermore, the role of resource management in this adaptation process is described. The use of reflection is then discussed as a principled means of obtaining adaptation. Finally, the aims and the general structure of this thesis are outlined.
1.2 Open Distributed Processing and Middleware The expansion of distributed systems is due to the number of advantages they offer over centralised systems. The most important benefits introduced by a distributed system are: resource sharing, scalability, fault tolerance and high performance. Resource sharing offers the possibility of sharing resources such as processors, storage and printers among multiple users. Regarding scalability, additional workstations and extra storage can be
1
easily introduced in a distributed system. In addition, the loss of a particular resource, e.g. a processor, does not represent a drastic problem and these systems are able to continue. Finally, distributed systems can potentially achieve a high performance by parallelising applications. Throughout this thesis the author’s understanding of a distributed system is expressed by the following definition [Blair97]: “A distributed system is a system designed to support the development of applications and services which can exploit a physical architecture consisting of multiple, autonomous processing elements that do not share primary memory but cooperate by sending asynchronous messages over a communication network.” Fundamentally, a distributed system is characterised by autonomous elements which communicate with each other in an asynchronous fashion. The vast complexity of distributed systems arises from these two properties. Firstly, some of the complexity problems introduced due to the autonomy property are those of location and accessability. Secondly, since communication is asynchronous and interactions are concurrent, means for ensuring the consistency of the system are also necessary. Furthermore, the tremendous expansion and popularisation of distributed systems have made them quite heterogeneous. There is a great variety of hardware, operating systems and programming languages that has increasingly been propagated in the last decades. There is therefore a need for introducing openness in distributed processing in order to overcome the complexity and heterogeneity problems described above. The main function of open distributed processing is to allow distributed services to be transparently located and accessed regardless of the underlying platform they are residing on. An open system is basically one that can be extended and implemented in different ways; for this the key interfaces must be made public [Coulouris01]. That is, well-defined interfaces must conform to a standard definition. As a result, interoperability between diverse open distributed processing platforms, possibly implemented by different vendors, can be achieved. Portability can also be obtained so that an application running on a particular
2
open processing platform should run in any platform conforming to the standard regardless of how it was implemented. The software that masks out the heterogeneity problems of a distributed environment and that alleviates the complexity of distribution is often referred to as middleware. One of the main functions of middleware is to provide a platform independent programming model. In these systems a common programming interface is achieved regardless of the hardware, the operating system and the language the application is relying on. There are three major efforts for the standardisation of middleware in the context of open distributed processing: a) ISO/ITU-T Reference Model for Open Distributed Processing [ITU-T/ISO95]. The Reference Model for Open Distributed Processing (RM-ODP) is the result of a joint effort by two international standards bodies: ISO and ITU-T. This standard is based in an object model and provides support for distribution, interworking, interoperability and portability. The standard offers a set of views of a distributed system that provide a separation of concerns and different levels of abstraction. b) The Object Management Group’s Common Object Request Broker Architecture [OMG01a]. The Common Object Request Broker Architecture (CORBA) is a standardisation activity conducted by the Object Management Group (OMG). This standard promotes a distributed object-oriented framework in which objects transparently interact regardless of their location, underlying platform and the programming language. c) The Open Group’s Distributed Computing Environment [OpenGroup01]. The Distributed Computing Environment (DCE) is a standard developed by the Open Group, formerly called The Open Software Foundation. In contrast with the other two standards, this one is not based on an object model but on a procedural style. DCE consists of an integrated set of services for the construction of large distributed systems.
3
It is worth mentioning that there is another group of middleware standards, called vendor-initiated standards, developed by specific manufacturers. Examples of this group are Java based technologies (e.g. RMI) and Microsoft’s .NET. This group of standards generally suffer from interoperability problems since these technologies are commonly attached to either a particular operating system or a single programming language.
1.3 The Role of Resource Management in Distributed Multimedia Systems 1.3.1 The Nature of Multimedia Multimedia is a relatively new field that has emerged within the area of soft real-time systems. Multimedia applications are characterised by the manipulation of continuous streams of data which have soft timeliness constraints. Examples of multimedia systems are videoconferencing, Internet telephony and digital libraries. More concretely, the term multimedia denotes: “the property of handling a variety of representation media in an integrated manner” [Blair97]. Stand-alone multimedia systems operate on a single local system. In contrast, distributed multimedia systems are concerned with a network of multimedia workstations. In general terms, media types can be classified into two large groups: discrete media and continuous media. The former represents discrete data values which lack of temporal dimensions, i.e. these do not have any timeliness constraints. In contrast, continuous media is a sequence of discrete values that have associated time properties, e.g. how often they should be produced. Throughout this thesis, those interactions involving continuous media are referred to as stream interactions. In addition, media data can be represented in either a digital or analogue format. This thesis is only concerned with the former. Digital multimedia has basically two advantages over its counterpart [Fluckiger95]. Firstly, digital media provides universal means of representing data. It does not matter whether data is text, audio or video; everything translates into a single format of a sequence of bits. As a result all data types can be managed in the same way and by the same equipment. Secondly, analogue
4
transformations impose distortions and noise whereas digital transformations are generally error-free. 1.3.2 The Need for Adaptation in Distributed Multimedia Systems Distributed multimedia systems are highly susceptible to changes in their environment. Some of the factors that introduce dynamism into distributed multimedia systems are: -
Resource sharing. Distributed multimedia applications operate on general purpose distributed computing environments, i.e. the Internet, commercial operating systems, commercial middleware, etc. These applications commonly share and compete for computing resources with other applications. As a result, these environments are characterised by being highly dynamic.
-
Mobile computing. Mobile applications have dynamic requirements due to their dynamic nature. For instance, consider a multimedia application running on a mobile computing which is initially connected to a fixed network. In this case, the application has plenty of network resources. However, as soon as the computer is transported to another place and the network connection is replaced by a wireless one, the application starts to experiment a lack of network bandwidth resources.
-
Dynamic nature of multimedia applications. Many distributed multimedia applications are inherently dynamic. For instance, the number of participants in a videoconference system may dynamically vary at any time. As a consequence, the resource requirements of such an application will inevitably fluctuate over time.
-
Variation in decompression time of frames. The CPU processing time required for decompressing MPEG video experiences variations in both a frame-to-frame and a scene-to-scene basis [Goyal96; Chu99]. The former has variations in the order of milliseconds whereas the latter may go up to the order of seconds [Goyal96].
5
In addition, the timeliness constraints of distributed multimedia systems make them deeply sensitive to dynamism. That is, unexpected variations in the environment might drastically disrupt such kind of systems. There is then a clear need to introduce adaptation in order for a distributed multimedia application to be gracefully degraded when such unexpected changes happen. 1.3.3 Resource Management in Distributed Multimedia Systems The main purpose of resource management is twofold. Firstly, it aims at achieving a high utilisation of the system resources such as CPU, memory and network resources in order to enhance the system performance. Secondly, it distributes and allocates system resources according to the application resource requirements. Sometimes there must be a trade-off between the former and the latter. For instance, hard real-time applications (where missed deadlines cannot be tolerated due to the criticality of the applications) usually over-book resources in order to support worst-case-execution times. Resource management also plays an important role in the adaptation process in terms of both resource awareness and dynamic reallocation of resources. That is, facilities should be provided that allow a system to be aware of the availability of computational resources, the management policies being used and how resources are allocated among the activities the system performs. In addition, such platforms should provide facilities to dynamically reconfigure the resources allocated and replace the management policies according to the perceived changes to the environment. An example of such a reconfiguration is a redistribution of both CPU-time and memory to the set of activities that a system performs. The role of resource management in distributed multimedia systems can be better understood within the context of Quality of Service (QoS) Management. Similarly to other real-time systems, multimedia systems need the use of QoS management to ensure that the solicited service requirements are met. A service has both functional and nonfunctional properties. The former concern those properties that establish what the service does. For instance, the functional properties of a videoconference application include the transmission and reception of video and audio data, the dynamic incorporation of new participants, etc. In contrast, non-functional properties relate to the (quantitative)
6
specification of how the service is performed. The non-functional properties of the videoconference application, for example, may include the transmission rate of the video frames, the delay variance between frames, etc. Quality of service (QoS) is concerned with non-functional properties [Blair97]. QoS management then denotes any set of activities that control the establishment and maintenance of the contracted level of QoS. The process of establishing a QoS contract involves a number of subtasks. The first one of them concerns the specification of the application’s QoS requirements. These QoS requirements are then negotiated and the QoS manager evaluates the feasibility of meeting them. For this purpose, the QoS specification is mapped to specific resource requirements. Afterwards, an admission control test phase determines whether there are enough resources to support the required level of QoS. If successful, the required resources are reserved. Otherwise, the request is turned down and a re-negotiation phase may follow consisting of the negotiation of a reduced level of QoS. Finally, QoS monitoring and adaptation may be performed in order to maintain the contracted level of QoS. As has been showed in this section, both QoS management and resource management are closely related. The latter provides important support for the former. The next section argues that the adaptation that distributed multimedia systems require is best suited at the middleware level. In addition, reflection is advocated as a means to obtain the necessary flexibility and openness that such adaptable systems demand.
1.4 Adaptive Middleware The author believes that the most adequate and natural level for applying the adaptation that distributed multimedia systems require is at the middleware level. Adaptation at the operating system level is platform-dependent and requires a deep knowledge of the internals of the operating system. In addition, unwanted changes at this level could be catastrophic as every single application running in a node could be affected. At the other extreme, some research in operating systems [Engler95] and networking [Floyd97] has advocated leaving as much flexibility and functionality to applications as possible in order to satisfy the large variety of application requirements.
7
On the other hand, adaptation at the application level imposes an extra-burden on the application developer. Besides, the adaptation mechanisms developed at this level cannot be reused since they are application specific. The level of adaptation that is required in distributed multimedia systems can only be achieved by introducing more openness into the implementation of these systems. Current middleware follows the traditional approach of the software engineering whereby the implementation details are hidden to the user. Such an encapsulation of the implementation details result in a black box which is difficult to inspect and modify. Some attempts have been made to obtain more openness in middleware, e.g. the CORBA specification defines portable interceptors [OMG01c] as a mean to add new behaviour to the invocation path. However, this kind of solutions is rather ad hoc and just covers a minimum range of adaptation possibilities. For instance, CORBA portable interceptors cannot be applied on a per object-interface basis rather than that they operate on an orbwide basis. The author believes that reflection [Smith82] provides a principled means (as opposed to ad hoc) of achieving the openness and flexibility that is required in middleware platforms. An overview of reflection and its applicability in middleware is introduced in the next section.
1.5 Reflection 1.5.1 Overview of Reflection A reflective system is a system that is able to reason about itself [Smith82]. More specifically, reflection is a means whereby a system is able to inspect and change its internals in a principled way [Maes87]. Basically, a reflective system is able to perform both self-inspection and self-adaptation. To accomplish this, a reflective system has a representation of itself. Furthermore, this representation is causally connected to its domain, i.e. any change in the domain must have an effect on the system, and vice versa. A reflective system is mainly divided into two parts: the base-level and the meta-level. The former deals with the normal aspects of the system whereas the latter regards the system’s representation. The meta-level interface is often referred to as the Meta-Object Protocol (MOP) [Kiczales91]. In addition, the process of gaining access to the meta-level
8
is called reification. Reification is the means of making explicit an aspect of the system whereas absorption is the opposite, i.e. the process in which an explicit aspect of the system is made implicit. There are two styles of reflection [Maes87]: procedural and declarative. In the former, the representation of the system is a program that it is generally written in the same language of the system. The latter uses a set of declarative statements as a representation of a system. Initially, the paradigm of reflection was used in procedural and logic languages. However, most research has been focused on object-oriented languages (OOLs) [Maes87; Watanabe88; Kiczales91; Okamura92]. One of the advantages provided by OOLs is that of a clear separation of concerns between the base-level and the meta-level, i.e. these levels can be encapsulated apart from each other by using objects and meta-objects, respectively. The meta-object of an object can be seen as a virtual machine since it interprets and executes its associated object. In addition, since meta-objects are also objects, they may have meta-objects as well. This opens the possibility of an infinite tower of reflection to exist (in theory at least). There has been some research on the use of reflection in the areas of operating systems [Yokote92; Horie97; Horie98] and distributed systems [Okamura92; McAffer96]. More recently, a growing interest has emerged in the use of reflection in the area of reflective middleware [Singhai98; Kon00a; Ledoux00; Roman01]. 1.5.2 Towards Reflective Middleware The base-level of a middleware platform concerns the programming structures of the services provided by such a platform. These services are accessed through the base-level interface. In contrast, the meta-level provides the reification of the non-functional properties of these platforms, e.g. the resource management of the objects involved in a particular service. The meta-level provides a means to inspect and modify the implementation of the middleware by accessing a well established meta-interface. For instance, the computational resources involved in a service may be reconfigured by manipulating the operations defined at the meta-level.
9
1.6 Aims This thesis investigates the issues of providing support in reflective middleware platforms for the dynamic reconfiguration of resources. As mentioned above, considerable research has been done in the reflective middleware area. However, little research covers the issue of resource management. This work is particularly focused on providing introspection (i.e. resource awareness) and adaptation (i.e. dynamic resource reallocation) capabilities to distributed multimedia systems. The resource management models are developed within the context of OpenORB [Blair01], a reflective middleware architecture. More specifically, the research has the following goals: -
To be able to understand the potential role of reflection for the resource management of multimedia middleware platforms.
-
To be able to formulate appropriate resource management models for a reflective middleware architecture.
-
To contribute more generally to the understanding of reflective middleware architectures.
The latter point refers to the relevance that the study of a particular aspect, i.e. resource management, places on the overall knowledge of reflective middleware. In addition, it should be noted that the thesis is not carrying out research in specific resource management algorithms; rather, it focuses on providing a general metaframework which can accommodate best practice in the area. Interoperability with other middleware standards is also not a primary goal since this research aims at next generation middleware. Finally, this thesis is mainly addressing distributed multimedia systems; however, the work presented here is not constrained to this area and may be extended to cover other areas of soft real-time.
1.7 Structure of the Thesis The remainder of this thesis is structured as follows. Chapter 2 initially presents investigation of the current state-of-the-art of middleware technologies, and discusses the
10
limitation of these technologies regarding flexibility and adaptation. Some of the attempts to overcome these deficiencies are mentioned and evaluated. The second part of chapter 2 then includes an examination of reflection as a technique to achieve adaptation in principled way. In particular, current reflective middleware approaches are discussed. Chapter 3 introduces a review of significant research in the area of resource management in middleware. Following this, the chapter analyses relevant standards in this area. This chapter concludes by discussing both the strengths and drawbacks of current approaches. Chapter 4 describes the resource management framework within the context of the OpenORB reflective middleware platform [Blair01]. The design and structure of this framework is explained in detail. For this purpose, both a resource model and a task model are introduced. The former offers various levels of resource abstraction whereas the latter enables the high-level analysis and design of the resources system. Chapter 5 presents software engineering techniques for setting up adaptive resource management in middleware platforms targeting distributed multimedia systems. These techniques require the use of two description languages. Xelha is an architecture description language which provides support for the specification of QoS management for distributed multimedia applications. A resource configuration description language (RCDL) then provides the definition of specific computational resources along with their management policies. Chapter 6 presents the implementation of the system’s prototype. An overview of the used technologies is mentioned. The description of the implementation is then concerned with three aspects. Firstly, the extensions made to the used technologies are presented. Secondly, the implementation of a particular instantiation of the resources framework is introduced. Finally, the development of the tool support for the description languages is presented. Chapter 7 evaluates the resource management framework by analysing the adaptation capabilities acquired by the reflective middleware platform and by testing the framework with a typical distributed multimedia application.
11
Finally, chapter 8 presents a summary of the thesis. The most significant contributions of the research reported in this thesis are highlighted along with the issues that require future work.
12
Chapter 2 Towards Adaptive Middleware 2.1 Introduction This chapter covers the current sate-of-art of middleware technologies with a special focus on adaptation issues. It is argued that the best suited class of middleware for distributed multimedia systems is that of object-oriented middleware. However, current object-oriented middleware does not provide a generic solution for achieving adaptation. Thus, reflection can be used to fulfil this issue. The chapter structure is as follows. Section 2.2 introduces the concept of middleware. A list of requirements for object-oriented multimedia middleware is presented in section 2.3. Section 2.4 introduces an overview of the major object-oriented middleware standards and technologies. The concept of reflection is then presented in section 2.5. This is followed by overview of reflection in object-oriented systems and middleware in section 2.6 and 2.7 respectively. Finally, a summary of the chapter is presented in section 2.8.
2.2 What is Middleware? There are many views of what middleware is since middleware technologies are being used in a diverse group of application domains, e.g. remote database access systems, distributed transaction systems, cooperating systems, distributed multimedia systems, etc. However, the main idea in all cases is that middleware should provide support to alleviate problems of heterogeneity and distribution. That is, middleware aims at providing facilities for distributed applications to interact in an environment with diverse hardware and operating systems. Middleware is essentially then [Emmerich00]: ”a layer between network operating systems and applications that aims to resolve heterogeneity and distribution.”
13
In the context of the ISO/OSI reference model [Day83], the middleware layer is placed between the transport layer and the application layer. The latter provides the application functionality, i.e. this layer concerns the services that the application supports. The former provides transparency for data transfer between two end systems. Thus, middleware effectively implements the session and the presentation layers of the OSI model. The session layer provides facilities for establishing, maintaining and closing connections between two or more distributed processes. The presentation layer is then responsible for the transmission of data in a common format in order to deal with heterogeneous representations. Upon the reception of data, this is translated from the common format into the platform-dependent data representation. More concretely, the session layer deals with the complexity problems introduced by distributed systems whereas the representation layer tackles heterogeneity problems. In addition, middleware provides some fundamental services, which support the construction of distributed applications. An example of such services is a naming service offering facilities for name resolution and location. Other common services, such as a security service, then provide additional support to distributed applications. 2.2.1 Types of Middleware Overview There are four major types of middleware: Remote Procedure Call (RPC)-based middleware, transaction-oriented middleware, message-oriented middleware and objectoriented middleware. There are standardisation efforts taking place for each of these categories, although their maturity is diverse. RPCs extend traditional procedure calls to a distributed paradigm where procedures located in heterogeneous distributed platforms can be called as if they were local. RPCs were invented by Birrell and Nelson [Birrel84] and then adopted by Sun Microsystems as part of the Open Network Computing (ONC) platform in the early 80s. More recently, the Open Group produced a Standard for RPCs and incorporated it as part of the Distributed Computing Environment (DCE) standard. Most of the Unix operating systems and many non-Unix systems support the DCE’s basic core of services.
14
Transaction-oriented middleware aims at interconnecting heterogeneous database systems. This type of middleware provides support for processing distributed transactions across different platforms. It offers high-performance, availability and ensures dataintegrity. For this purpose, transaction-oriented middleware implements the two-phase commit protocol [Bernstein87]. The X/Open consortium, a group of vendors now part of the Open Group, developed a distributed processing transaction model which supports portable, interoperable transaction processing applications. Example of products within this middleware category include IBM’s CICS [Hudders94] and BEA’s Tuxedo [Hall96]. Message-oriented middleware, in contrast to RPCs, do not model synchronous interactions but asynchronous communication. That is, the client does not need to be synchronised with the server as messages are first deposited in a message container, such as a queue, and then collected at any time. Messages are non-blocking, i.e. sending a message does not forces the client to wait for the reply. In addition, messages are sent with no specific receiver defined. That is, they are deposited and later collected by other elements of the messaging system. Some of the message-oriented middleware technologies available in the market are IBM’s MQSeries [Redbooks99] and Sun’s Java Message Queue [Monson00]. Finally, object-oriented middleware is based on the object-oriented paradigm and supports the remote invocation of object methods. The Common Object Request Broker Architecture (CORBA), developed by the Object Management Group, has emerged as the most widely used object-oriented middleware platform. Some other important technologies include Microsoft’s Distributed Component Object Model and Sun’s Remote Method Invocation (RMI) mechanism for Java. It is worth mentioning that object-oriented middleware has recently evolved towards a component-oriented paradigm. Notably, this paradigm allows for the large reuse of software and also introduces more reconfigurable capabilities into distributed applications. Although component standards are still in the consolidation process, they are already a major trend. Examples of these technologies include Enterprise Java Beans (EJB) [Sun01a] and the CORBA Component Model (CCM) [OMG99a].
15
2.2.2 Discussion Different types of middleware are best suited for different application domains. When considering distributed multimedia applications, the author believes that the most appropriate middleware type is object-oriented middleware. That is, transaction-oriented middleware is more adequate for distributed database systems. Message-oriented middleware does not suit well multimedia applications since this kind of applications typically requires isochronous communication. In addition, RPC-oriented middleware offers a lower-level service than that provided by object-oriented middleware. For instance, remote procedures are located by using both the host address of residence and the program number. In contrast, object-oriented middleware masks out these details and uses object references instead which are transparently generated by the middleware platform. In addition, object-oriented middleware includes the advantages of encapsulation and reusability offered by the object-oriented paradigm. As a result, the research reported in this thesis focuses on this class of middleware. However, further work is needed in current object-oriented middleware, as discussed below, to provide full support for both multimedia and resource management.
2.3 Requirements for Object-Oriented Multimedia Middleware This section presents a list of requirements that an object-oriented middleware platform needs to fulfil in order to support the demands of distributed multimedia applications. •
Must retain the benefits of an open distributed platform. Object-oriented multimedia middleware platforms should sustain their main function, i.e. to solve problems of heterogeneity and distribution. For this purpose, the properties of openness, portability and interoperability must be preserved.
•
Various levels of abstraction. Various abstraction levels are needed for representing both multimedia aspects (e.g. media types, media interaction types) and resource management issues (e.g. resources, managers). The purpose of this is to support both fine- and coarse-grained management of both multimedia aspects and resource management aspects.
16
•
Configurable. Middleware should be configurable in order to meet the requirements of the target platform. For instance, embedded systems which have scarce resources cannot support the deployment of large middleware platforms; rather they require a more minimal configuration. Regarding multimedia, media types, media type interactions and multimedia algorithms should also be able to be configured.
•
Reconfigurable. Middleware should be dynamically reconfigurable according to the new demands imposed by dynamic changes to the environment. For example, some actions may be required in order to tackle dramatic fluctuations of the network resources. Importantly, this flexibility in middleware should be achieved in a principled manner. That is, modifications to the internals of middleware should be made in a neat and structured way in order to obtain the desired reconfiguration and avoid unwanted changes. In addition, the reconfiguration mechanisms should be generic enough to accommodate a wide range of adaptation algorithms. Reconfiguration of multimedia abstractions concerns the transformation of media interactions. Such transformation involves the allocation, deallocation or replacement of both multimedia types and multimedia algorithms.
•
Evolution. Middleware should evolve over time in order to be extensible and support the inclusion of new technology. As the initial requirements change, evolution of the platform design should also be supported. In particular, multimedia systems require the evolution of media types, media interaction types and multimedia algorithms.
•
Consistency must be preserved. The introduction of dynamic changes into middleware platforms may lead to inconsistent states. In order to avoid this kind of situation, mechanisms for consistency check must be introduced into these platforms. Such mechanisms usually enforce a certain constraint over permissible actions
17
•
Good performance. Multimedia middleware platforms have a requirement for good and predictable performance due to their timeliness constraints. That is, the overhead imposed by middleware should be reduced as much as possible.
Multimedia middleware will inevitably also require a description language (or languages) for the specification of the configuration and reconfiguration aspects of the system. This introduces an additional set of requirements as presented below. •
Support for coarse- and fine-grained specifications. The language should provide semantics for the coarse-grained specification of the middleware system. Examples of coarse-grained specifications include the definition of the services configured as coarse block units without revealing implementation details. This approach aims at diminishing the overall complexity of the system configuration. Hence, the user can focus on the high-level configuration design of the system. In addition, the language should offer support for the description of fine-grained details. The aim of the lower-level description language is to map coarse-grained descriptions to finegrained details of the platform of deployment. That is, the coarsegrained description language is concerned with the high-level analysis and design of the system whereas the fine-grained description language is closely related to the implementation details of the system.
•
Separation of concerns. The language should ideally provide facilities for the separation of concerns. By doing so, the programmer is able to tackle different issues in a clearer manner. The result of this approach is that the overall complexity of the system development is diminished.
•
Expressiveness. The description language should have enough power of expressiveness for specifying both configuration and reconfiguration aspects for distributed multimedia systems.
18
•
Tool support. The description language should have associated tool support. The purpose of this is to provide facilities for the design and analysis of a system. Importantly, the tool(s) should also provide support for code system generation. Such generated code may be either lower-level code or executable programs.
The next section covers an overview of the most important object-oriented middleware technologies along with a discussion about the adaptation capabilities that they support.
2.4 Major Object-Oriented Middleware Standards and Technologies 2.4.1 Reference Model of Open Distributed Processing Overview The Reference Model of Open Distributed Processing Reference Model (RM-ODP) [ITU-T/ISO95] is a standardisation effort carried out by two international bodies, i.e. ISO and ITU-T. It is important to mention that RM-ODP is not an implementation standard. Rather, it is a meta-standard [Blair97] that defines a generic framework for guiding the development of particular standards for open distributed processing. The infrastructure for distribution defined by the standards of RM-ODP have been the basis for many current object-oriented middleware platforms. For instance, RM-ODP has greatly influenced the development of CORBA and DCOM. RM-ODP is basically characterised by the following features: •
The use of viewpoints. RM-ODP provides five different viewpoints, illustrated in figure 2.1, for the specification of distributed systems. Each viewpoint defines a particular language which encompasses a set of concepts, structures and rules that characterises the viewpoint. This approach provides a separation of concerns for the studied subject, thus alleviating the inherent complexity of specifying distributed systems. For the sake of brevity and relevance, only the computational and engineering view points are described below.
19
•
Support for selective transparency. The goal of distribution transparency is to mask out both heterogeneity and complexity problems inherent in distributed systems. Sometimes, however, it is desirable to provide programmers with facilities for the selection of a particular level of transparency. This may be the case for applications that are susceptible to variations in their environment. Such applications may require to be aware of the changes introduced to the environment.
•
A collection of functions to support the needs of a distributed system. These functions are basically services (or facilities) that fulfil the needs of both the computational and the engineering viewpoints of an RM-ODP platform. Examples of these services are the transaction and type-repository functions. The former offers support for maintaining consistency of object configurations whereas the latter allows for the management of meta-information.
The computational viewpoint of RM-ODP essentially involves the logical partitioning of a distributed system into a series of interacting entities. That is, distribution concerns such as address spaces or node location are abstracted away. This viewpoint adopts an object-oriented approach where objects within this model may have several interfaces. Not only operational interfaces but also stream and signal interfaces are supported. Importantly, stream interfaces fulfil the requirements of continuous multimedia interactions. In addition, explicit bindings are supported which potentially offer more control over the communication path between object interfaces. Finally, the engineering viewpoint of RM-ODP addresses distribution aspects which can be grouped in two parts. Firstly, regarding communication issues, channels define the elements that take place in a binding between a set of interfaces. These elements are stubs, binders, protocol objects and interceptors. Stubs provide data transformation, and hence they concern the presentation layer of the OSI model. Binders are roughly related to the tasks involved in the session layer, i.e. binders are responsible for managing bindings. Protocol objects are concerned with networking, and hence, they are related to the transport layer of the OSI model. Lastly, interceptors enable the transformation of
20
interactions. Secondly, concerning the management of resources, this viewpoint defines clusters, capsules and nodes. Clusters involve the grouping of objects whereas capsules are concerned with the management of resources involved in an address space. Nodes are related to the management of the whole resources of a physical machine. Finally, the transparency functions are defined in this model.
Enterprise viewpoint Information viewpoint Computational viewpoint Engineering viewpoint Technology viewpoint
Models the purposes and scope of an enterprise. Considers the semantics of information, the information flows and how the information is processed. Logical partitioning of a distributed system into a series of interacting entities. Addresses distribution aspects of the supporting infrastructure. Concerns the selection of suitable technology for the implementation of the system.
Figure 2.1 Viewpoints in RM-ODP Discussion Although RM-ODP is not an implementation standard, it is interesting to analyse the support it provides for the demands of distributed multimedia systems. Such analysis is valuable considering that RM-ODP functions as a guiding framework for the development of other standards. Regarding multimedia aspects, RM-ODP provides a first-class treatment to multimedia interactions by offering operational, stream and signal interfaces. In addition, RM-ODP supports explicit bindings between interacting interfaces thus offering potentially more control over the communication path. That is, explicit bindings can offer a control interface that allow for both the control of the QoS offered by the binding and the deletion of the binding. In terms of resource management, capsule managers are in charge of managing resources within an address space whereas node managers are responsible for the management of the resources of a machine.
21
Another interesting feature of RM-ODP is that provided by the type repository function which enables the management of meta-information. This opens up the possibility of supporting both multimedia information and resource management information. Importantly, interceptors allow for the adaptation of multimedia interactions. Finally, RM-ODP provides a clear separation of concerns between the basic functionality of the application from distribution aspects by placing the former in the computational model and the latter in the engineering model. 2.4.2 CORBA Overview The Common Object Request Broker (CORBA) is a standardisation effort carried out by the Object Management Group (OMG), which is a consortium of more than 800 member organisations at the time of writing. An interface definition language (IDL) is used to specify operating system and programming language independent object interfaces. The standard defines the mapping between the IDL and particular programming languages. An IDL compiler then translates IDL definitions into the native programming language constructs. In addition, the interface repository is in charge of providing descriptions of all IDL-defined interfaces at run-time. This repository also allows for this information to be dynamically stored and updated. The overall architecture of CORBA comprises four main components namely, the object request broker (ORB), the CORBAservices, the CORBAfacilities and the application objects. The ORB enables the transparent interaction of distributed objects regardless of the platform they rely on. The ORB also allows for the interaction of objects written in different languages. Such an interaction is achieved by the use of IDL. CORBAservices are a collection of system-level services that support the basic functionality of the ORB. There are a number of these services including services for locating objects, creating and moving objects, controlling concurrent access to objects and managing distributed transactions between objects. The CORBAfacilities are then additional services that support the ORB. These are more specialised services that are
22
divided into two categories namely, horizontal CORBAfacilities and vertical CORBAfacilities. Horizontal CORBAfacilities cover aspects of all application domains whereas vertical CORBAfacilities focus on a particular application domain. In addition, application objects allow for the construction of distributed end-user applications which interfaces are specified by using IDL. The elements enumerated above are the most essential features of CORBA. However, it is worth mentioning other important features that introduce more flexibility into CORBA. In respect to meta-information management, the meta object facility (MOF) [OMG99b], recently adopted by CORBA, is an extension of the IDL repository concept that allows for the management of meta-information. While the IDL repository only focuses on meta-information related to interfaces, the MOF provides a more generic meta-modelling framework. The MOF provides a powerful means for representing metainformation about any kind of system. Configuration facilities then include the Messaging specification [OMG01b] which offers facilities for the customisation of some QoS aspects of the ORB. Examples of such customisations are the level of reliability of a one-way message, request timeouts and the maximum number of hops a request may go through. In addition, resource configuration of the ORB can be achieved by the use of the Real-time specification [OMG99c]. Such a configuration includes thread pools and memory buffers. Network protocols may also be selected and their protocol properties configured. (A more in depth description and analysis of Real-time CORBA is provided in chapter 3.) In addition, the portable object adapter (POA) [OMG01a], recently adopted by the OMG, introduces more flexibility into the ORB. For instance, the threading policy may be set at POA creation time. Another important aspect of CORBA is Portable Interceptors [OMG01c]. Similar to RM-ODP, CORBA supports interceptors which enable programmers to inspect, transform and even redirect messages to a different object. Interceptors can be placed at both the client side and the server side. In addition, portable interceptors enable the customisation of the IOR (Interoperable Object Reference) at creation time whereby QoS information related to security, server thread priorities and network connections may be defined. Finally, regarding support for multimedia issues, the Control and Management of A/V Streams specification [OMG00a] defines a framework for control of out-of-band streaming data transmission. Examples of
23
the issues covered by this specification are stream topologies, stream descriptions and stream QoS. Discussion CORBA represents an important middleware standardisation effort for communication between distributed objects. This standard also provides mechanisms for introducing some openness and flexibility into the ORB. Regarding meta-information management, the type repository and especially the MOF provide means for the ORB to be selfdescriptive. As a result, some details of the internal configuration of the ORB can be introspected. Interestingly, additional behaviour may be introduced by using CORBA portable interceptors. However, there are a number of inherent restrictions in this approach. Firstly, interceptors can only be statically defined, i.e. it is not allowed to add interceptors at run-time. Secondly, interceptors can only be defined for an ORB-wide scope. This imposes a coarse-grained granularity for transforming messages, i.e. interceptors cannot be defined on a per-object method basis or even on a per-object basis. Moreover, configuration of certain aspects of the ORB can be achieved by using the POA specification, the Messaging specification and the Real-time specification. However, most of the customisations are only allowed at both compile- and load-time. That is, little or no support is provided for dynamically modifying the configuration of the ORB at runtime. 2.4.3 DCOM and .NET Overview Distributed COM (DCOM) [Microsoft00d] represents the distribution capabilities built on top of Microsoft’s component object model (COM) [Microsoft00b]. COM emerged as the result of Microsoft’s effort to overcome the limitations of object-oriented models for producing plug-and-play components, that is, binary units, possibly produced by third-parties, that may be dynamically installed or replaced without re-compiling the system. Microsoft defines a binary standard for its component model. Such a standard supports both binary encapsulation and binary compatibility. The former allows for the dynamic upgrading of components. That is, the components used by a client may evolve
24
and have their functionality changed without re-compiling the client as long as the interfaces of the original component remain the same. The latter enables components constructed in a development environment to be integrated into a different environment. As a consequence, machine code developed by third-parties can be transparently plugged into a component system. COM’s binary standard specifies the binary format of a COM interface. Such an interface is represented as a pointer to a table of function pointers. This idea was borrowed from C++’s virtual function tables (vtables). It should be noted that there are two levels of indirection in a COM interface. The rationale for this comes from the fact that object-oriented languages pass an extra parameter (usually hidden) whenever an object method is invoked. This parameter, commonly referred to as self or this, allows a method to have a reference to its object. For a COM interface to exhibit object characteristics, pointers to COM interfaces are passed as self parameters to any of the interface’s operations. An interface has an interface identifier (IID) which is unique name identifier for an interface. In addition, interfaces are accessed through interface pointers. Importantly, a COM component may support more than one interface. COM supports single interface inheritance, i.e. multiple interface inheritance is not allowed. However, it should be noted that COM+ [Box99a; Microsoft00c], an extended version of COM, does support multiple inheritance. In COM, all interfaces inherit from the Iunknown interface which defines methods for the control of the object’s lifetime. Importantly, this interface comprises the QueryInterface method which allows clients to determine whether an interface (specified by IID) is supported by an object. Notably, Microsoft provides a DCE-based IDL, referred to as MIDL, to support language independence. MIDL mappings are defined for a number of languages. The MIDL compiler generates both stubs and type libraries. A type library provides run-time information concerning the methods and their parameters an interface exposes. In addition, COM supports message filters which obtain method call information such as the interface id and the method number. Furthermore, COM+ supports interceptors [Kirtland97; Box99b] on a per-method basis. COM+ interceptors are able to introduce additional behaviour into method invocation calls. Such behaviour may be introduced before and after the invocation call takes place. Another mechanism of COM that enables 25
the configuration of method calls is custom marshalling [Box96]. This mechanism basically permits a server object to create a custom proxy on the client side. In order to create the custom proxy, both the classid of the custom proxy and its initialisation parameters are transmitted to the client side. This mechanism is usually used to pass objects by value. However, the custom proxy can be populated by any arbitrary class and, as a consequence, the initial behaviour of a server object may be modified. It is worth mentioning that DCOM has been ported to other platforms such as Unix. The initiative taken by Software AG for porting DCOM on Solaris is an example of such efforts. Interestingly, Microsoft has recently developed a new framework, called the .NET Framework [Microsoft00a; Pietrek00; Richter00a; Richter00b], that intends to improve and overcome some unsolved problems of DCOM. The Microsoft .NET framework is a platform for the development of distributed applications that provides full language interoperability and an integration of Web services. The units of reuse and deployment in this framework are referred to as assemblies. Essentially, an assembly is a collection of one or more portable files, which may be either an EXE or a DLL file. Language interoperability is achieved through the use of a common language specification (CLS) which dictates the set of rules that a compiler must support to target a common run-time language. This run-time language, referred to as Microsoft intermediate language (MSIL), is a platform-independent bytecode contained in the assemblies. MSIL is then compiled just-in-time (JIT) converting this intermediate code into machine-specific code. A common type system (CTS) is defined in order to obtain full language integration whereby a program can reuse the source code of another program written in another language. The CTS provides a set of common data types that can be used by all programming languages running on top of .NET. Finally, the assemblies contain metadata regarding the operations and the types that an assembly supports. In addition, a reflection API allows for the inspection of such meta-information. Discussion DCOM is a vendor middleware standard which provides support for the communication of distributed objects. Type libraries provide a means for metainformation management. Microsoft’s meta-data management framework is not as
26
generic as the CORBA MOF. However, the .NET framework eases the management of meta-information supported by the use of a reflection API. In addition, the Iunknown interface allows for the inspection of the interfaces of an object. DCOM also provides some mechanisms for the configuration of an ORB. Message filters enable the inspection of method invocation calls. Notably, COM+ interceptors work on a per-method basis so that the behaviour of method invocations may be altered. In addition, custom marshalling allows for the customisation of proxies in the client side. Although there have been some attempts to port DCOM to other platforms, all the tool support developed by Microsoft is tightly coupled to the Windows platform. As a consequence, DCOM is a proprietary technology rather than a true multi-platform solution [Tallman98]. Much of the same criticism said about CORBA regarding the flexibility of the ORB can also be applied to Microsoft’s technologies. In particular, the configurability features provide by both DCOM and .NET are merely focused on both compile- and load-time facilities, leaving aside mechanisms for run-time configuration. 2.4.4 Java/RMI Overview Java [Sun01b] is an object-oriented language introduced by Sun Microsystems, which is both compiled and interpreted. That is, Java compilers translate Java code into bytecode, a platform independent intermediary code. The bytecode is then interpreted by a Java Virtual Machine (JVM). Java includes a remote method invocation (RMI) API which allows for method objects to be remotely invoked. That is, a client object residing in a local JVM may invoke the method of a server object located in a remote JVM. Higher-level services are constructed on top of Java RMI, e.g. Enterprise JavaBeans [Sun01a] which offers a server-side component framework. Java only supports single inheritance for classes, but multiple-inheritance for interfaces is allowed. Object references may be registered by a naming service referred to as the RMI registry; the object references are bound to names through this service. Similar to CORBA and DCOM, stubs are used for marshalling and unmarshalling requests. Stubs are generated by a compiler, referred to as rmic, from class definitions.
27
Dynamic method invocation is achieved by the use of a reflection API, which supports the identification of the methods of an object class. Basically, the reflection API offers the means for both class and object introspection. Field values of both classes and objects may also be modified. In addition, dynamic proxies are able to intercept method calls and add pre or/and post behaviour to invocations on a per-interface (or set of interfaces) basis. Interestingly, class loaders allows for the dynamic extension of a Java application at runtime. That is, class loaders are responsible for importing bytecode into the Java execution engine. Java also allows users to define their own version of a class loader by subclassing the ClassLoader class of the Java API. In this case, a class file may be fetched from a non-standard resource such as the network. Notably, code transformation may be performed by a user-defined class loader. This fact brings in the possibility of changing the behaviour of a class at load-time. Finally, since Java programs are interpreted by a run-time system, the behaviour of a Java program may be dynamically changed by modifying the internals of the JVM. Discussion Java provides diverse facilities that support the introduction of some flexibility into a run-time system. Similar to CORBA and DCOM, Java allows for the management of meta-information. However, Java’s capabilities in this respect are much more limited than its counterparts. Java supports load-time program transformation through the use of user-defined class loaders. However, such transformation is meant to be at the bytecodelevel. As a consequence, this facility for adaptation is difficult to use and error-prone. Although dynamic changes may be introduced at run-time by modifying the internals of the JVM, this is in conflict with the standardisation of the JVM leading to non-portable solutions. Dynamic changes may also be introduced at run-time by using dynamic proxies. However, the interception process is not completely transparent in the sense that, for trapping method calls objects are not directly invoked, they are called through their associated proxies instead. 2.4.5 Analysis As has been shown above, many features of the middleware technologies introduced have been influenced by RM-ODP. Regarding openness and flexibility, the concepts of
28
interceptors and meta-information management have been extended to these middleware technologies. For instance, all object-oriented middleware technologies presented here provide an approach for the management of meta-data; however, no standard type system frameworks have been defined yet for the definition of multimedia types and resource types. Moreover, the treatment of meta-information related to multimedia and resource management is particularly limited in both Microsoft’s technologies and Java. The middleware platforms introduced above offer some facilities for configuration. Except CORBA, no support is provided by any of these middleware technologies in respect to distributed multimedia issues. Although, DCOM and Java provide little or no support for resource customisation, Real-time CORBA and Messaging CORBA offer some facilities in this respect. Most of the features supported by the discussed middleware technologies only comprise load-time mechanisms. That is, these platforms offer little support for runtime reconfiguration. In addition, other aspects such as resource management are poorly addressed. Hence, the run-time mechanisms supported lack genericity, that is, only a minimum range of adaptation possibilities are covered making these facilities rather ad hoc solutions. There is then a clear need to introduce a principled and generic approach to achieve the openness and flexibility that multimedia middleware requires. The author believes that reflection provides the means for a structured and disciplined approach to achieve such openness. The next section introduces reflection in detail followed by an examination of current reflective middleware approaches.
2.5 Reflection 2.5.1 Open Implementations A first step for making a system more flexible and adaptable is to open up the system implementation, using the paradigm of open implementation [Kiczales94; Kiczales96b; Kiczales96a]. This paradigm confronts the traditional point of view of the software engineering in which the implementation details are hidden from the user. The resultant black box approach enables the user to have a better understanding of the module functionality and enhances its ease of use. However, it also makes impossible to access
29
and modify the system’s internals. The main problem with such an approach is that a level of portability and extension feasibility in the software development is lost. By hiding the implementation details of a software system it is impossible for it to be modified when adaptation is required. The essential concept of the open implementation paradigm is expressed as follows [Rao91]: “A system with an open implementation provides (at least) two linked interfaces to its clients, a base-level interface to the system’s functionality similar to the interface of other such systems, and a meta-level interface that reveals aspects of how the base-level interfaces is implemented”. An open implementation has basically two interfaces. The first one is used for accessing the basic module’s functionality whereas the latter provides a means to access and change the module’s internals. 2.5.2 The Emergence of Reflection A more specialised case of open implementations is that of computational reflection [Smith82; Smith84]. Reflection is a means by which a system is able to inspect and change its internals in a principled way [Maes87; Maes88a; Maes88b]. That is, a reflective system is able to perform self-inspection and self-adaptation by accessing its meta-level interface. More precisely, the reflection hypothesis states that [Smith82]: “In as much as a computational process can be constructed to reason about an external world in virtue of comprising an ingredient process (interpreter) formally manipulating representations of that world, so too a computational process could be made to reason about itself in virtue of comprising an ingredient process (interpreter) formally manipulating representations of its own operations and structures”. The main idea captured by this statement is the ability of a reflective program to access, reason about and change its own computational process. Important to the notion of reflection is the concept of self-representation and causal connection as introduced by [Maes87]:
30
“A system is said to be causally connected to its domain if the internal structures and the domain they represent are linked in such a way that if one of them changes, this leads to a corresponding effect upon the other”. That is, a reflective system must provide structures for the representation of the internals of the system. The process of constructing such structures is referred to as reification. Reification is the means of making explicit an aspect of the system whereas absorption is the opposite, i.e. the process in which an explicit aspect of the system is made implicit. A reflective system is basically divided into two parts: the base-level and the meta-level. The former deals with the normal aspects of the system whereas the latter regards the system’s representation. A system with a self-representation can answer questions about itself and perform actions upon itself. The benefits introduced then by the casual connection are, in the first place, that the self-representation always provides an accurate representation of the system, and secondly, that the system is able to perform both self-inspection and self-adaptation. Another important issue about reflection that is worth being highlighted is that of completeness. Hence, a fully reflective system provides a complete representation of its internals. Systems that only present a partial representation of themselves are referred to as either partially reflective systems or systems offering reflective facilities. This kind of system provides the ability to inspect and adapt particular parts of the system. Hence, the system’s developer must anticipate a reduced number of system’s features that might need to change according with the future requirements of the system. Such a case lacks of genericity and hence only offers ad hoc solutions such as those offered by current middleware technologies as shown in previous sections of this chapter. Structural VS Behavioural Reflection Reflection is categorised into two main types. Firstly, structural reflection is the ability of a system to inspect and modify the system’s internal architecture. Hence, structural reflection allows for the reification of the constituent elements of the system along with their organisational patterns. This type of reflection relates to how a system is constructed. Examples of structural reflection are the set of operations that a system supports and the abstract data types defined within the system.
31
Secondly, behavioural reflection is the ability of a system to inspect and modify the means that govern the system’s computation. Thus, behavioural reflection allows for the reification of the mechanisms that handle the execution of the system. This type of reflection relates to how the execution of a system is realised. Examples of behavioural reflection are the mechanisms that perform the reception and acceptance of messages when the invocation of an operation takes place. Reflection Styles In addition, there are two styles of reflection, namely procedural and declarative [Maes87], which dictate how reflection is implemented. In the former the representation of the system is a program usually written in the same language as the system. In this case, the representation of the system is part of the interpretation process. The latter then provides a set of statements for representing the system. This reflection style offers a higher-level of representation than that provided by the procedural approach in terms of readability and ease of use. That is, declarative statements provide a clear view of the system’s state and are easy to manipulate when modifications are required. However, declarative reflection must additionally provide a mechanism for the interpretation of the statements. As a consequence, the causal connection is more difficult to realise in this case, i.e. such a mechanism should guarantee that the representation conforms with the actual state of the system. In contrast, causal connection is easily achieved by the procedural approach since the representation of the system is part of the representation itself. Finally, it should be noted that hybrid solutions exposing both declarative and procedural reflection are also possible.
2.6 Reflection in Object-Oriented Languages and Systems 2.6.1 Overview Initially, the paradigm of reflection was used in procedural and logic languages. However, most research has been focused on object-oriented languages (OOLs) [Maes87; Watanabe88; Kiczales91; Okamura92]. Due to the fact that the thesis is mainly focused on object-oriented middleware, the discussion about reflective languages is restricted to OOLs. The meta-level interface of an object is often referred to as Meta-Object-Protocol
32
(MOP) [Kiczales91]. One of the advantages provided by OOLs is that of a clear separation of concerns between the base-level and the meta-level, i.e. these levels can be separated from each other by using objects and meta-objects, respectively. Furthermore, since changes are performed on a meta-object basis, modifications in reflective OOLs are localised. There is then an important synergy between reflection and object-oriented languages as pointed out by [Kiczales91]: “Reflective techniques make it possible to open up a language’s implementation without revealing unnecessary implementation details or compromising portability; and object-oriented techniques allow the resulting model of the language’s implementation and behaviour to be locally and incrementally adjusted”. The scope of reflection may be classified into three broad groups. Firstly, the metaobject approach is concerned with adaptation at the object-level. The meta-object of an object can be seen as a virtual machine as it interprets and executes the object. In addition, since meta-objects are also objects, they may have meta-objects as well. This opens the possibility of an infinite tower of reflection to exist (in theory). This approach is advocated by ABCL/R [Watanabe88]. Reflective group architectures then concern the ability to modify groups of objects. In this approach several objects may be related to a meta-group. Changes done on a meta-group are spread all over the group members. The ABCL/R2 language [Matsuoka91; Masuhara92] provides facilities for meta-group management. Finally, the meta-class concept was firstly introduced by SmallTalk-80 [Goldberg83; Foote89]. In this approach, classes are objects themselves. A meta-class is then an interpreter of the class definition whereby a change to the meta-class is reflected to all instances of the class. CLOS [Kiczales91] is an example of this approach. The next sections present some of the most influential reflective OOLs and reflective systems in the research community. Special focus is placed on the resource management facilities provided by a selection of these systems. 2.6.2 Relevant Reflective OOLs and Systems Common Lisp Object System (CLOS) [Kiczales91] is one of the most influential languages in the area. This is an object-oriented extension to Lisp. Object-oriented
33
features are introduced to Common Lisp by using the following constructs: defclass for defining classes, makeinstance for creating instances of classes, defgeneric for creating generic functions and defmethod for defining methods. Notably, the language may be extended or adapted by accessing the CLOS MOP. Initial access to the meta-level of CLOS is achieved by specialising the meta-object classes associated with each of the elements of the language. More concretely, there is a meta-object class for classes (i.e. meta-classes), generic functions and methods. Interestingly, ABCL/R [Watanabe88] is an object-oriented concurrent language, which follows an active object model where objects have their own thread of execution. A meta-object in ABCL/R is an object that models the structural and behavioural aspects of an object. Meta-objects may in turn have meta-objects hereby there is a potential infinite tower of meta-objects. Such an infinite tower is constructed by following a policy of lazy creation of meta-objects whereby meta-objects are instantiated on demand. Structural aspects are represented in terms of a set of scripts (or methods), a state memory, an evaluator, a message queue and the object’s mode which may be either dormant or active. Behavioural aspects then include message arrival, message reception, message acceptance and execution of scripts. In addition, meta-objects provide special scripts which inspect and modify the structure of an object. Examples of these scripts are those for adding and deleting scripts. ABCL/R2 extends ABCL/R by introducing a reflective group architecture into the language. ABCL/R2 thus includes both the metaobject and the group-wide approach for reflection. More precisely, a hybrid architecture is provided which offers two towers of reflection: the meta-object tower and the metagroup tower. The meta-object tower mainly controls the structure of the object whereas the meta-group tower controls the object behaviour. Furthermore, groups in ABCL/R2 are used as a means of modelling coordinated resource management. In particular, the members of a group share the same resources. In addition, allocation of CPU resources is achieved by allowing a scheduler object to control the order in which base-level objects are executed according to the algorithm of the scheduler. To accomplish this, the metaobject of the evaluator is specialised so that requests sent to the evaluator are redirected to the scheduler. The meta-object of the evaluator then asks the scheduler for the next request to be executed. However, there are no means to dynamically change the
34
scheduling policy as both the kernel objects and the scheduler object are non-reifying objects, i.e. objects that cannot have meta-objects. The feature of non-reifying objects was introduced in order to improve the performance of the system. Nevertheless, ABCL/R3 [Masuhara93; Masuhara94; Masuhara96], the successor of ABCL/R2, overcomes this shortcoming allowing for the dynamic modification of the intra-node object scheduling policy. Here the scheduler object is part of the basic reflective architecture exposed by ABCL/R3 (whereas in ABCL/R2 the scheduler object is introduced as an extra element). A node manager is also introduced which is in charge of controlling where objects are created. Node managers capture load information from the scheduler and from other node managers. Notably, the node manager has a method for the replacement of the scheduler. In addition, schedulers are able to define the time quantum for the execution of objects. Finally, node managers can be customised to change their object creation policy according to the load-balancing status. Multi-model reflection was first introduced by AL-1/D [Okamura92; Okamura93; Okamura95], another object-oriented concurrent language. AL-1/D, which follows a meta-object approach, offers six meta-models. The operation model is concerned with the operational semantics of the language. In this meta-model, a base-level object is represented by a meta-object in terms of a message queue, an array of variables, a state, and a method table. The statistics model includes some statistic information about the base-level object such as CPU time, memory usage and blocking time. The distributed environmental model aims at describing the distribution issues such as the location of an object and remote host information including the CPU and communication load. The migration model then describes how an object migrates to a remote host whereas the system model reifies all the components of the AL-1/D system. In addition, the resource model provides facilities for thread scheduling and garbage collection of objects on a perobject basis. The former is in charge of managing execution environments, referred to as contexts, whereas the latter is responsible for managing memory abstractions, called segments. The scheduler may be dynamically replaced by accessing a method in the resource model, which performs the replacement operation. A similar approach can be applied to dynamically change the policy for garbage collection.
35
The OpenC++ language [Chiba95] introduces a MOP for C++. Reflection in OpenC++ takes place at compile-time. The main motivation behind OpenC++ is to allow programmers to write libraries providing language extensions. More precisely, the MOP supported by OpenC++ provides control over the compilation of the following aspects of C++: class definition, member access, virtual function invocation and object creation. The advantage of this approach is that no overhead is introduced into the run-time system; however, reflection is restricted to compile-time. Finally, the Iguana language [Gowing97] also provides a MOP for C++. Interestingly, Iguana is a compiled language, which features run-time reflection. In respect to reflective operating systems, Apeiros [Yokote89; Yokote92], formerly called Apertos, follows a concurrent object-oriented paradigm whereby objects are associated with meta-spaces. A meta-space is a set of meta-objects that reify aspects of the execution environment of one or more objects. That is, a meta-space may be shared by several base-level objects. In addition, a meta-object may be shared between different meta-spaces. A meta-hierarchy may be defined whereby the behaviour of meta-objects may also be reified by other meta-spaces. Dynamic adaptation is then achieved by migrating objects from one meta-space to another which could be defined at bootstrap or dynamically created at run-time. For instance, in order to make an object persistent, the object may be migrated to a meta-space supporting persistency. A compatibility check is performed in order to ensure that an object migrates to a compatible meta-sapce. Reflector objects interface between objects and meta-spaces providing a set of primitives such as message passing and memory management. Threads are represented by Activities meta-objects, which are created by Exec meta-objects. The latter is in charge of starting and suspending the execution of Activities. For this purpose, the Exec meta-object has a queue of Activities and provides operations for the manipulation of the queue. The Exec meta-object, however, does not provide a scheduling policy. Rather, the Exec meta-object may be used by other entities, e.g. the Real-time meta-space. Furthermore, the meta-level of Activities is represented by Context meta-objects which provide information related to the execution environment such as processor registers, memory segment for the stack, execution mode (i.e. user or system) and the state of execution (i.e. suspended, ready, or running).
36
2.6.3 Analysis Reflective languages have provided the basic foundations of reflection and have an influence on any other area where reflection is applied such as distributed systems. The languages presented here provide different granularities for reflection ranging from metaobjects through meta-groups to meta-classes. Interestingly, ABCL/R2 presents a hybrid where both meta-objects and meta-groups are supported. Notably, ABCL/R introduces means for the representation of both the structural and the behavioural aspects of an object, establishing a clear separation between them. In addition, AL-1/D introduced the multi-model reflection paradigm, which alleviates the complexity of the meta-level by partitioning it into several aspects. Resource management in reflective languages has also been investigated. ABCL/R2 provides some support for the scheduling of objects; however, no facilities are offered for the dynamic adaptation of the scheduling policy. ABCL/R3 overcomes this shortcoming by offering a more comprehensive resource management framework. However, the framework is mainly concerned with CPU resources and offers little support the management of other type of resources. Another language offering a resource management facilities is AL-1/D. The resource meta-model of this language is merely concerned with thread scheduling and garbage collection. Notably, the operating system Apeiros supports dynamic resource management by using object migration. That is, objects are migrated from one meta-space to another featuring a different resource management policy. Only coarse-grained adaptation, however, can be applied. The next section outlines most important research in the area of reflective middleware and analyses the support currently provided for distributed multimedia systems.
2.7 Reflective Middleware 2.7.1 Introduction There has been a growing interest in using reflection to achieve adaptation at the middleware level. A pioneering piece of work in this area is the CodA meta-level architecture [McAffer95; McAffer96]. CodA decomposes the meta-level into a set of fine-grained components that reify aspects such as message sending, acceptance and execution. Interestingly, CodA offers a scheduling model in which schedulers are 37
logically composed of four components: QueuingFunction, ExecutionFunction, Queue and Executor. The former two elements are the policies for managing the Queue and the Executor respectively. CodA allows for hierarchical scheduling whereby a scheduled object may be another scheduler. Objects may define, in the component reifying the execution aspect, the scheduler by which they want to be scheduled. An overview of the most relevant research in the area of reflective middleware is introduced below. Reflective middleware approaches provide a wide range of facilities for the dynamic customisation of distributed systems. However, this section argues that not enough support is provided for the dynamic reconfiguration of resources. For this purpose, some of the most relevant research on reflective middleware is reviewed. 2.7.2 FlexiNet Overview In the FlexiNet project [Hanssen97; Hayton97], researchers at APM have experimented with a reflective middleware architecture that provides a means of dynamically modifying the underlying protocol stack of the communication system. The FlexiNet ORB framework offers support for the replacement and insertion of layers in the communications protocol stack. This ORB is designed as a set of components which may be dynamically assembled. The instantiation of a binding is represented by a channel, which encapsulates the protocol layers and the required resources. Stubs have associated interface proxies that represent the binding to the (remote) object’s interface. Furthermore, proxies have a reference to a channel to carry out invocations. Interestingly, proxies are reflective since most of their semantics are defined by replaceable metaobjects. The instantiation of a binding is performed according to a policy which denotes issues such as the particular protocol to be used and resource management strategies. Moreover, meta-policies dictate which policy should be selected when bindings are created. Hence, the meta-objects associated with a proxy realise meta-policies whereas policies are implemented by specific channel configurations. The FlexiNet framework provides support for the management of a number of resources including threads, sessions and memory buffers. These resources are represented as abstract resources which are managed by one or more pools of resources. Each pool is then controlled by a
38
PoolManager. Furthermore, PoolManagers are able to control generic resources, thus, effectively de-coupling resource management policies from particular resource types. PoolManagers are mainly concerned with the management of resource reservation and resource reuse. Buffers are multi-segment abstractions of a single byte array. The layers of the protocol stack are then aware of the segment(s) they use. The main goal behind the design of buffers in FlexiNet is to make it easy for different layers in the protocol stack to insert and remove data from the buffer, without any concern about the data format used by other layers. Discussion The Flexinet approach is focused on addressing dynamic reconfiguration of the protocol stack. For this purpose, they adopt a component-oriented approach whereby the protocol stack is dynamically assembled. Their approach is, however, language-specific. Fine-grained reflection is possible within the framework by introducing before and/or after behaviour to method invocations. Coarser-grained reflection is then achieved by modifying the protocol stack of the binding between two objects. In addition, the policy governing the binding may be dynamically modified by replacing the associated metaobject of the proxy object. Such policies may include resource management strategies such as those related to invocation policies (e.g. single-threaded, thread-per-message, etc.). Interestingly, generic abstractions are provided for both resources and pool of resources. In addition, generic resources are managed by PoolManagers. However, no MOP is provided for the reallocation of resources. Finally, the bindings offered by FlexiNet do not provide explicit support for multimedia communication. 2.7.3 OpenCorba Overview The work done in OpenCorba [Ledoux97; Ledoux99; Ledoux00] follows a meta-class approach. In this system, meta-classes allow reflective computation to control the behaviour and structure of all instances of a base-level class. OpenCorba is a CORBAcompliant ORB implemented in the NeoClassTalk reflective language which is based on SmallTalk [Rivard96] but extended with a MOP. OpenCorba reifies some aspects of the
39
ORB such as the remote invocation mechanism and the IDL type checking on the server side. The remote invocation mechanism is reified as a proxy class, which is associated with a meta-class ProxyRemote. Thus, the meta-class redefines the method used for sending messages. The remote invocation is then performed according to the CORBA DII (dynamic invocation interface). The reason for using stubs based on DII for remote invocations is that such stubs are homogeneous and reusable. Dynamic adaptation is achieved by dynamically changing the meta-class of the proxy. Regarding the IDL type checking, the mechanism for such type checking is reified as a meta-class. Hence, a new mechanism for type checking may be introduced without modifying the current implementation. Discussion This approach is essentially restricted to behavioural reflection since the framework operates on the basis of the reification of proxy objects, which are similar to CORBA Portable Interceptors. There are some differences, however. OpenCorba provides a finer granularity of reflection than that offered by Portable Interceptors as proxies in OpenCorba are defined on a per-interface type basis whereas the scope of reflection of Portable Interceptors is ORB-wide. In addition, the behaviour of proxies may change dynamically by replacing the associated meta-class. However, such a replacement always has an effect on all instances of the interface type, which could be sometimes undesirable. In addition, this is a language-specific solution since this approach can only be applied when the programming language supports meta-classes. Finally, no support is provided for resource management or multimedia. 2.7.4 Quarterware Overview Researchers at the University of Illinois at Urbana-Champaign have developed Quarterware [Singhai97; Singhai98], a component architecture for middleware. This architecture provides facilities to dynamically modify the invocation, marshalling and dispatching of the ORB. Servers carrying out requests adopt any of the following policies: thread-per-message, thread-pool, thread-per-priority, and single-threaded. The
40
dispatcher then supports a scheduler, which may be dynamically replaced by another one. Two different scheduling policies are supported for dispatching requests namely, earliest deadline first (EDF) and first in first out (FIFO). In addition, the marshallers can be specialised to implement different marshalling schemes. Other aspects that are reified in the architecture of the ORB include the data transport and object references. The former enables the use of particular transport protocol such as TCP, UDP or IP-multicast. The latter masks out variations of object reference formats by providing applications with a common interface. Discussion The approach presented in Quarterware is that of a componentised middleware, hence, bringing in the flexibility and reusability features supported by the component paradigm. However, the level of reflection of this framework is coarse-grained and mainly restricted to key aspects of the ORB such as invocation, marshalling and dispatching. The treatment of resource management is not general enough since only a few aspects of it are reified. Finally, no support for multimedia issues is provided. 2.7.5 dynamicTAO and UIC Overview Further research at this institution has led to the development of dynamicTAO [Kon00a; Kon00d; Kon01], which is a CORBA-compliant reflective ORB supporting run-time distributed reconfiguration. dynamicTAO is part of the 2K project [Kon98; Kon00b] which aims at developing a distributed operating system with an integrated architecture for adaptation. The overall architecture of the 2K operating system consists of three layers. At the top level reside 2K applications. The second level is then integrated by the 2K middleware, which offers different middleware flavours and a group of distributed operating system services. Finally, the 2K kernel is concerned with different choices of operating system kernels including the 2K microkernel [Kon00c] for the system bootstrap. The implementation of dynamicTAO is an extension of the TAO ORB [Schmidt98] that allows for the dynamic customisation of the ORB. Such customisation is achieved by the use of a collection of entities known as component
41
configurators. These configurators maintain information about the dependencies between the components they manage. The DomainConfigurator is in charge of holding references to instances of the ORB and to servants running within an address space. In addition, TAOConfigurators are responsible for attaching and detaching components implementing strategies such as scheduling, concurrency, security, and monitoring. Components are implemented as dynamically loadable libraries which may be linked to the system at run-time. Importantly, the dynamic configuration service exports a CORBA IDL interface, referred to as the DynamicConfigurator interface, which is a MOP for the inspection and reconfiguration of the ORB. Monitoring is accomplished by the use of the 2K monitoring service, which is a dynamically loadable component that can be inserted into the invocation path by using request-level interceptors. Furthermore, availability of hardware resources is monitored by the 2K resource manager. dynamicTAO also addresses issues of consistency such as checking possible dependencies of a dynamically uploaded component with loaded components and checking dependencies with clients using old versions. The consistency check is performed by the 2K automatic configuration service. Furthermore, this service is in charge of negotiating the allocation of the resources required by a loadable component with the resource manager [Kon01]. Both component dependencies and component resource requirements are specified in a simple prerequisite description format. The 2K resource management service [Kon01] offers a hierarchy of resource managers whereby global resource managers are at the top whereas local resource mangers are at the bottom. The latter are managers that are present in each node of the distributed system. The former then constitutes either a cluster of local managers or a cluster of global managers. Local managers periodically send information about the state of their resources to their global managers. Local managers are also in charge of performing admission control, resource negotiation, resource reservation, and task scheduling on a single node. This is achieved with the help of a dynamic soft real-time scheduler [Nahrstedt98]. Additional research in the 2K project is considering the development of the Universal Interoperable Core (UIC) [Roman00; Roman01] which is a small, reflective ORB. This ORB, previously called LegORB, is targeting systems with scarce resources such as those 42
found in ubiquitous computing scenarios (e.g. PDAs and phones). Finally, the UIC can be specialised to adopt one or more personalities such as CORBA, Java and DCOM. This feature of the UIC allows for the interaction with diverse middleware platforms. Discussion The dynamicTAO architecture again makes use of component technology in order to achieve the desired flexibility and adaptability. However, the focus of this approach is very much on large-grained platform-wide configuration. That is, the reconfiguration capabilities of this ORB does not allow the user to perform modifications either on a per method basis or on a per-object basis. Hence, any dynamic reconfiguration has an effect on every instance within the address space of the ORB. The main focus here is then coarse-grained reconfiguration in order to maintain a high performance. Notably, the issue of consistency is addressed by performing dynamic changes according to the reified dependencies between components. It is worth noting that this system does not make use of meta-objects for the purpose of reifying aspects of the ORB. Rather, component configurators represent the meta-level entities, which provide facilities for the inspection and reconfiguration of the ORB. Interestingly, the 2K platform offers a framework for hierarchical resource management. Although the framework provides means for admission control and reservation of resources, little support is offered for the dynamic reconfiguration of resources. 2.7.6 mChaRM Overview The reflective architecture of mChaRM [Cazzola00] is based on the multi-channel reification model. Such a model reifies multi-point bindings into a logical channel which is able to intercept method calls and transform them with new semantics. The granularity of reflection is on a per-method basis. The architecture of the channel is essentially denoted by the stub of the sender, the core channel, and stub of the receivers. Stubs at both the sender and the receiver side are in charge of trapping messages and altering behaviour by performing message transformation. The default behaviour of the core channel is then responsible for forwarding the trapped messages to their correspondent
43
receiver stubs. In addition, the result of the computation of the last receiver is sent back to the caller. However, more complex behaviour may be introduced by specialising the default behaviour. Interestingly, the framework provides a MOP for the introspection of both messages and the channel. Furthermore, the MOP allows the programmer to perform message transformation. Operations for setting the behaviour of both stubs and the core channel are also defined. The reflective platform is realised in an extended version of Java, which provides means for describing the behaviour of a channel. The Java extended version is then translated into plain Java source code by the mChaRM tool. It is claimed that this approach effectively provides a global view of the communication aspects of a system whereas other approaches, such as the meta-object paradigm, only maintain a local view of the system. Discussion The mChaRM framework offers little support for the reification of structural aspects of base-level objects since the main focus of such framework is the reification of the communication aspects of a system. This approach offers a platform which supports the use of method-based interceptors in a coordinated manner through the communication path of an invocation call. Resource management plays an important role in the communication process; however, no means are presented in this framework in order to address this issue. Finally, no facilities are provided for the support of stream communication. 2.7.7 Analysis It can be seen that a lot of work has recently been carried out in the area of reflective middleware. There is a clear trend to componentise middleware since most of these systems introduce a component-oriented framework. Such an approach provides great flexibility for the dynamic replacement of components. In addition, the component approach promotes and enhances software reusability. However, component technologies are not mature enough yet. New component standards, such as EJB [Sun01a] and the CORBA component model [OMG99a], have started to emerge and will consolidate in the next few years.
44
The granularity of reflection in the frameworks introduced here ranges from finegrained adaptation to coarse-grained approaches. For instance, CodA offers an objectbased approach for reflection whereas dynamicTAO only allows ORB-wide reflection. It should be noted that those approaches providing a coarse-grained scope for reflection are generally concerned with high performance, whereas research tackling fine-grained adaptation are more concerned with investigating the range of adaptation possibilities. Some support for resource management is provided by a few approaches presented above. Nevertheless, the resource management facilities offered are by no means comprehensive enough. Frameworks that do not offer any kind of support for resource management issues are OpenCorba and mChaRM. Some others approaches provide some facilities mostly focused on thread scheduling (such as CodA and Quarterware). Regarding support for various levels of abstraction, CodA and Flexinet are the approaches that best met this requirement. As a result, evolution is also better supported by these two approaches. Notably, all the approaches provide some support for the configuration and reconfiguration of the middleware platform. In addition, the most solid approaches for resource management are those of FlexiNet and dynamicTAO. Notably, the former provides an interesting approach whereby abstractions are defined for resources, resource pools, and resource managers. This is a generic approach in which any kind of resource may be modelled. Interestingly, the resource management framework offered by dynamicTAO provides a resource management hierarchy featuring an effective approach for load-balancing. In addition, means are provided for admission control, resource negotiation, resource reservation, and user-defined thread scheduling policies. That is, resources are effectively reserved for instances within the ORB, but little support is provided for dynamically changing the amount of resources allocated to these instances. Although these two framework are resource-aware and are able to detect when a task is experiencing a lack of resources, the strategy to tackle this situation usually involves activities such as changing the sampling rate or introducing filters, but not a resource reconfiguration. Regarding consistency issues, dynamicTAO is the only approach which offers some support in this concern. Finally, all the approaches provide language support for the configuration and/or reconfiguration of the middleware platform except CodA and Flexinet. That is, the 45
CORBA-based approaches offer CORBA IDL definitions, OpenCorba also offers metaclasses for the definition of behaviour and mCharm provides Java extensions that describe the reification of communication channel. A summary of the analysis concerning reflective middleware platforms is presented in table 2.1.
Summary of Evaluation of Reflective Middleware Platforms CodA Flexinet OpenCorba Quarterware dynamicTAO Met Met Met Met of Met
Retain benefits open dist platform Various levels of abstraction Configurable Reconfigurable Evolution Consistency Performance Language support
Met
Met
Partly met
Partly met
Partly met
Partly met Partly met Met
Partly met Partly met Met
Partly met
Partly met
Partly met
Partly met
Partly met
Partly met
Partly met
Partly met
Partly met
Not met Partly met Not met
Not met
Not met
Not met
Met
Partly met Not met
Partly met
Met
Met
Partly met
Partly met
Partly met
mCharm Met Partly met Partly met Partly met Partly met Not met Partly met Partly met
Table 2.1. Summary of Evaluation of Reflective Middleware Platforms.
2.8 Summary This chapter has introduced the concept of middleware and also presented an overview of current object-oriented middleware technologies. It has been shown that these technologies only offer ad hoc solutions to obtain the required flexibility that distributed multimedia systems require. Reflection has been introduced as a principled means to achieve adaptation in middleware. Some of the most relevant research in the area of reflective middleware was also presented. It has been argued, however, that little support for distributed multimedia is provided in terms of stream communication and resource management.
46
The next chapter examines non-reflective middleware approaches for resource management. In particular, the chapter focuses on dynamic resource reconfiguration to introduce adaptation in soft-real time distributed systems.
47
Chapter 3 Resource Management in Middleware 3.1 Introduction Resource management plays a key role in the process of adapting distributed multimedia systems, as discussed in chapter 1. This chapter presents an overview of current research on resource management at the middleware level. It is shown that most of these systems focus on both resource models for the awareness of resources and application-level adaptation. However, little support is provided for both the dynamic reallocation of resources and changing management policies. Finally, some middleware standards offering facilities for resource management are presented. Again, it is shown that these standards do not offer sufficient dynamic resource management support. The remainder of this chapter is structured as follows. A list of requirements for resource management in multimedia middleware is provided in section 3.2. Section 3.3 then presents an overview of resource management support provided by a selection of middleware platforms. Section 3.4 introduces middleware standards with resource management support. Finally, section 3.5 presents a summary of the chapter.
3.2 Requirements for Resource Management in Multimedia Middleware This section presents a list of requirements that resource management in a middleware platform needs to fulfil in order to support the demands of distributed multimedia applications. It turns out that the same requirements as introduced in section 2.3 are also applicable in this context, thus providing a common framework for the evaluation of the contributions in this area. •
Must retain the benefits of an open distributed platform. Multimedia middleware with dynamic resource management
48
capabilities should maintain all the benefits provided by an open distributed platform. •
Various levels of abstraction. Resource management aspects should be represented by first-class entities in order to have access and obtain control over the system resources. Furthermore, there should be abstractions for representing different types of resources, resource
managers
along
with
their
associated
resource
management policies and resource availability information. In addition, various levels of abstraction for both resources and managers should be provided. The purpose of this is offering support for both fine-grained and coarse-grained resource management and, as a consequence, support for adaptation at different levels of granularity. •
Configurable. Resource management in multimedia middleware should be configurable in order to meet the specific requirements of the platform of deployment. Therefore, both resource configurations (i.e. allocation of resources)
and resource
management policies should be configurable. •
Reconfigurable. Resource management in multimedia middleware should be dynamically reconfigurable according to changes in the availability of resources. Thereby, such resource management systems should provide support for both run-time reallocation of system resources and
dynamic changes to the resource
management policies. •
Evolution. The resource management system should evolve over time in order to be extensible and support the inclusion of new technology. Therefore, support for the evolution of resource types and resource management policies is required.
•
Consistency must be preserved. Changes introduced in the resources system may lead to inconsistency problems. In order to
49
avoid this kind of situations there should be some mechanisms in charge of assuring the consistent state of the resources system. •
Good Performance. Resource management systems should provide good performance in order to attend the timeliness demands of multimedia systems.
Language support is also required for the specification of both resource configuration and resource reconfiguration. The requirements for the description languages are the same as introduced in section 2.3. Hence, the requirements are only listed below without any further explanation. •
Support for coarse- and fine-grained specifications.
•
Separation of concerns.
•
Suitable for distributed multimedia systems.
•
Tool support.
The next section covers an overview of some important research in the area of resource management in middleware.
3.3 Approaches to Resource Management in Middleware 3.3.1 The Global Resource Management System Overview The Global Resource Management System (GRMS) [Huang97; Huang98b; Huang98a] provides middleware mechanisms for QoS negotiation and adaptation. The GRSM offers a generic resource model where heterogeneous resource management components are modelled uniformly. Resource agents represent resource management components, which are in charge of managing both specific resources and computing nodes. The main responsibilities of resource agents include the assessment of the capacity and availability of resources, making reservation of resources, releasing resources, and executing and suspending application tasks. Such behaviour is supported by three internal components of the resource agents. Firstly, the scheduling algorithm/protocol establishes the order and/or time of application task executions. Secondly, the schedulability analyser performs an admission control test to determine whether there are enough
50
resources to process a given application task associated with QoS properties. Thirdly, the scheduling mechanism interfaces with the underlying network operating system in order to carry out execution of application task’s operations. Crucially, there is a two-level resource management hierarchy. At the top level are distributed system resource manager (DSRM) agents, which co-ordinate end-to-end resource negotiation and adaptation. The second level then includes local resource agents which model individual resources, such as CPU and network resources, within a node. Interestingly, local resource agents provide an “adapter” mechanism, which supports the incorporation of different existing or future components implementing scheduling algorithms/protocols. This is achieved by defining a particular adapter on a percomponent basis. In addition, a QoS library supports the QoS translation across the system layers. Hence, this library offers a set of mapping functions, which are defined by the software developers for a particular layer (e.g. application, middleware and network layer developers). Importantly, a distributed session is the unit of resource negotiation, allocation and scheduling. The system creates a distributed session per application program. Besides, subsessions are sessions running on an individual computing node, which encompass the set of resources, such as threads and buffer, used for execution. Resources are allocated to sessions according to QoS requests, i.e. applications may call the function ChangeMode() in order to set the desired level of QoS. A task is then a unit of resource management for a given resource agent. For instance, the list of threads belonging to a subsession is represented by a CPU task. In addition, a resource is an abstraction that represents heterogeneous resources. Essentially, a resource abstraction keeps a record of reserved and allocated resources, and is in charge of assessing the availability of resources. Finally, the resource framework provides the GRMS ripple scheduling, consisting of two major elements namely, a scheduling spanning tree and a two-phase negotiation and adaptation protocol. The former regards the execution path across multiple nodes of an application. Each QoS request, performed by an application, results in a unique spanning tree. The latter then involves two phases. The first phase performs a admission control test on the associated spanning tree. The second phase is in charge of propagating either a commit or an abort command along the spanning tree. In addition, the protocol supports 51
the shrinking of the executing sessions’ QoS, in case not enough resources are available to attend the demands of all sessions. After the QoS shrinking, low-criticality sessions may be preempted if no sufficient resources are available. Expansion of the executing sessions’ QoS, applied at the end of the negotiation phase, is also supported in order to maximise the application QoS. Discussion The framework presents abstractions for a generic representation of heterogeneous resources. This fact makes the system able to evolve. In addition, a two-level resource management system is supported, which allows for the end-to-end resource negotiation and allocation. Both coarse- and fine-grained adaptation are offered. The former is supported by the distributed session, which is the unit of resource management that encompasses all the resources required for the execution of an application. In case of resource contention, for instance, a whole application may be suspended on behalf of a higher-priority one. The latter is then supported by tasks, which are the unit of resource management of a particular resource type on a given node. Interestingly, the two-phase negotiation protocol provides support for consistency issues. In addition, the reallocation of resources is supported by the ripple scheduling algorithm, which shrinks sessions’ QoS when resources are scarce. This is an interesting approach in which sessions are the means to support resource management of coarse-grained interactions. However, the framework only targets applications that explicitly express their desire of changing the QoS mode of operation. That is, no support is provided for applications that require both to monitor the dynamic changes introduced to their environment and react accordingly upon the occurrence of such unexpected events. In addition, the resource management system is only concerned with reallocation of resources without addressing the issue of dynamic change of resource management policies. 3.3.2 The ERDoS QoS Architecture Overview The end-to-end resource management of distributed systems (ERDoS) project [Chatterjee98; Sydir98; Chatterjee99] offers a generic and comprehensive resource
52
framework. The ERDoS framework provides a middleware architecture with QoS-driven resource management capabilities. For this purpose, a QoS taxonomy is introduced defining a generic hierarchy of various QoS categories. The middleware architecture supports the management of resources such as computing, storage and communication resources. The framework also provides facilities for admission control, negotiation and graceful degradation. Notably, a distributed system is described by three models namely, the resource model, the system model and the application model, as described below. •
In the resource model, resources are modelled as abstractions that have two types of attributes. Internal attributes captures a specific set of attributes for a particular type of resource whereas external attributes concern generic attributes. Hence, the former are accessed through non-generic interfaces, while the latter are accessed by a uniform interface allowing the handling of heterogeneous resources. There are no constraints on the granularity of a resource abstraction. As a consequence, the system designer has the flexibility to choose the desired level of granularity. The resource model basically captures resource-specific information that is required by the resource management algorithms. Such algorithms are implemented by the resource manager.
•
The system model defines both the layout of the system resources and the management structure of resources. A distributed system is modelled as a graph whose nodes are subsystems or resources and the edges are the connections. The model defines a hierarchical structure whereby resources are at the bottom layer. A subsystem then includes either a set of resources or a set of subsystems governed by a single resource management scheme. Thus, this approach allows resource management to take place at different levels of granularity.
•
The application model captures information from the application level perspective into two abstractions namely, the logical application stream model (LASM) and the application invocation model (AIM). In the former, an application is represented as a directed-graph of components, with associated
53
QoS properties, which edges represent data flows. A service is then realised by a logical realisation of service (LRoS). The granularity of a service may range from that provided by a single component to that offered by the whole application. A logical unit of work (LUoW) represents a service that is executed on a single resource. An instance of a LUoW is then referred to as physical unit of work (PUoW) which models a system resource. In addition, the application invocation model captures the user’s QoS preferences, modelled by a benefit function. Such a function is a multidimensional graph that shows the benefits the user obtains by reaching a certain level of QoS for various QoS metrics. Finally, this work has also introduced some CORBA IDL extensions to capture the LASM. An associated IDL-compiler is also provided. Discussion The ERDoS QoS architecture provides support for the end-to-end resource management of distributed applications. Adaptation in this framework may be achieved by reconfiguring both resources and the application graph structure provided by LASM. The CORBA IDL extensions allow for the configuration of the LASM. The resource model enables the system designer to choose the level of granularity of an abstract resource. In addition, the system model allows for the hierarchical management of resources whereby various abstraction levels can be represented. Moreover, the system may evolve as new abstractions for resource types can be accommodated. Interestingly, the whole resource structure is captured by the system model. This feature provides a comprehensive view of the resource structure of a system. In addition, the structure of an application is represented by a directed-graph of components. Notably, a separation of concerns is achieved by separating aspects in the three different models. However, when reconfiguring the structure graph of an application, it is not possible to add new components. Instead, the structure of a graph can only be altered by replacing components. Finally, no support is provided for changing resource management policies and consistency issues are not addressed.
54
3.3.3 QuO Project Overview The Quality Object (QuO) project [Zinky97; Loyall98; Sydir98; Venegas98; Pal00] provides a framework for the specification of QoS for CORBA object interactions. Central to this framework are three components that provide essential support for the QoS-aware middleware platform. Firstly, contract objects represent operating regions and application service requirements. More concretely, contract objects specify the level of QoS required by clients, the level of QoS supported by objects, operating QoS regions, and the actions to be taken when a QoS violation occurs. A negotiated region describes a general mode of operation, e.g. the QoS desired by a client. Within a negotiated region there may be several reality regions, which define specific conditions within an operation mode, i.e. the QoS measured in the system. In addition, handler routines are invoked when transitions occur between either negotiated or reality regions. Such handler routines are in charge of informing either the client or the object when changes occur. These routines may also implement adaptation mechanisms, especially when dealing with transitions of negotiated regions. Secondly, delegate objects support adaptive behaviour upon method call and return. More concretely, delegate objects expose the same interface as clients, but contain code that checks the state of the QoS regions and may introduce adaptive behaviour. In addition, delegates can be stacked whereby each layer is associated with a different contract that represents a particular QoS aspect in the system. Thirdly, system condition objects interface to resources, mechanisms and ORBs in the system. System condition objects provide information about the current state of the system. Based on this information contract objects determine the operating region for a given method call. In addition, the state of the system is monitored in order to detect QoS violations. In such a case, the handler routines are invoked. System condition objects may also be nested and can be shared by different object contracts. The nesting feature could be useful, for example, for constructing higher-level measures from lower-level measures. QoS aspects are specified in QDL [Loyall98; Pal00], which is an extension of the CORBA IDL. Notably, various description languages are defined within QDL. A
55
contract description language (CDL) specifies QoS contracts. Hence, CDL describes the QoS required by clients, the QoS provided by objects, the operating regions along with the associated adaptive behaviour when transitions occur, and system conditions that need to be monitored. A structure description language (SDL) specifies the adaptive behaviour of delegates. For this purpose, the elements of a SDL description include the interfaces and contracts for which adaptive behaviour is being defined. Thus, pre and/or post adaptive behaviour is described on a per-method basis. A connector setup language (CSL) defines how the QuO objects are associated with the client and the object. This language aims at providing the means for the high-level configuration of QuO applications. The CSL basically defines delegates, which are implemented as connectors, with enough knowledge to communicate with the other objects they need. The CSL includes descriptions that define how objects are located and instantiated and how these objects are associated. Besides, the CSL is able to define an alternative object that a delegate may be associated with. Lastly, the resource description language (RDL), for describing available resources, is being developed. The QDL was designed by following aspect-oriented programming techniques [Kiczales97], whereby a program is decomposed into different aspects of concern. A different language is used to program each of these aspects separately. The assembly process is done by weaving all the programs by an aspect weaver. The QuO system provides a code generator, which supports such weaving and a CORBA IDL compiler. Interestingly, within their approach, the development of a distributed system involves three types of developers. The application developer is concerned about the functionality of the application whereas the QoS developer concentrates on the programming of structures that provide support for QoS. The middleware developer then focuses on distribution issues, thus, addressing the construction of appropriate middleware mechanisms. Finally, QuO is being integrated with TAO [Schmidt98; Pal00], a real-time ORB. The purpose of this integration is twofold. Firstly, it is intended to extend TAO with the adaptive mechanisms that the QuO framework supports. Secondly, TAO is being extended to provide support for higher-level specification of QoS aspects.
56
Discussion This framework provides an interesting approach to introduce QoS properties into CORBA objects. The framework also addresses the issue of separation of concerns by capturing QoS properties in different aspect languages. Definitions for both static QoS management (i.e. the desired level of QoS) and dynamic QoS management (i.e. the mechanisms to attain the contracted level of QoS) are supported by the QDL. However, resources are only accessed through system condition objects. Hence, no explicit support is provided for the representation of resources. The development of a resource description language is underway. However, the QuO platform currently provides little support for the management of resources. In addition, this approach only supports fine-grained adaptation since it merely focuses on client-object interactions. Finally, consistency issues are not addressed. 3.3.4 The Agilos Architecture Overview The Agilos (Agile QoS) architecture [Li99a; Li99b; Li00] is a control-based middleware framework that provides supports for QoS adaptations. In particular, the framework focuses on application-aware adaptation. That is, the adaptation strategies have application-specific semantics, such as the sample rate and the bits per sample of an audio connection. The framework has been developed for best-effort environments where no assurance of resource availability is provided and unexpected fluctuations on such availability may be experienced. Interestingly, the framework consists of a three-level model [Li00]. The bottom layer includes observers and adaptors, which are applicationneutral. The former are basically in charge of both monitoring resource availability and inspecting application-specific QoS values. Each observer correspond to a single type of resource. Adaptors are also resource-specific and are responsible for generating control signals upon the occurrence of variations reported by observers. The second level then includes configurators and qualProbes. Configurators are in charge of determining discrete control actions based on control signals generated by adaptors and application QoS requirements. The control model, where configurators play a key role, is based on both fuzzy logic and fuzzy control theory. Configurators consist of a fuzzy inference
57
engine and an application-specific rule base. The latter are linguistic rules that are interpreted by the inference engine. Such an engine generates actions that control the application. QualProbes are then a set of middleware QoS probing and profiling services. One of the main duties of qualProbes is to allow applications to specify some QoS preferences such as their critical performance criterion. In addition, the third layer includes the gateway [Kalter00] and negotiators. There are multiple negotiators and a centralised gateway. This layer allows a client to connect to different servers according to the client’s adaptation needs. There are negotiators in both the client and server side. The client negotiator interacts with the configurator and the gateway in order to accomplish a server switch action. Server negotiators only interact with observers and the gateway. Since configurators are passive in the server side, server negotiators do not interact with them. The reason for server configurators to be passive is that adaptation decisions are only taken by clients as server adaptation strategies may not be optimal for all clients. The gateway is then responsible for both maintaining state tables of servers and clients and selecting the most adequate server for a client’s request based on information sent by the client negotiator. Discussion This approach advocates the use of control-based middleware in order to achieve support for QoS adaptations. More concretely, the approach makes use of fuzzy control theory to determine discrete control actions. Resources are monitored by observers, which are resource-specific. Evolution is partly supported in that new resource type observers can be introduced. However, no explicit representation for resources is supported. In addition, the approach is mainly concerned with application-level adaptation, where adaptation strategies have application-specific semantics. Hence, no support is provided for neither resource configuration nor resource reconfiguration. 3.3.5 Other Research Other research involving resource management in adaptive middleware platforms includes Globus [Foster99; Foster00], which is a framework that allows for both resource reservation and application adaptation. In this architecture, heterogeneous resources are modelled by resource objects. The architecture of Globus encompasses several
58
components. The information service provides information about resource properties and resource availability. A co-reservation agent is in charge of both mapping application QoS requirements to specific resource requirements and requesting the reservation of such resources. The task of a co-allocation agent is similar but focuses on the allocation of resources. Local resource managers are responsible for attending request for allocation of resources. Adaptation is then achieved by the use of three distinct mechanisms. Firstly, sensors are in charge of monitoring both resources and the application behaviour. Secondly, decision procedures allow for the selection of an adaptation strategy. Lastly, actuators are the means to dynamically modify both resource allocations and application behaviour. Researchers at the Georgia Institute Technology have developed a framework for adaptive resource allocation (FARA) framework [Rosu98], which allows for runtime adaptation in systems with multiple applications and heterogeneous resources. The middleware platform basically mediates between clients and resource providers. The latter models either physical or logical system resources. More specifically, a resource provider may represent a set of different resources and supports the feasibility analysis for the reservation of resources. There is a proxy per client and per provider. Proxies are in charge of interfacing with the middleware platform and are also responsible for detecting resource availability and changes in application’s needs. Both the clients and providers are monitored by a detector. The negotiator is then responsible for the selection of adaptation modes. Importantly, service profiles are used for the specification of service-specific information such as resource load variation. In addition, researchers at Carnegie Mellon have developed Darwin [Chandra01], a resource management system for service-oriented networks. In contrast to common communication-oriented services, Darwin provides value-added services to manage a broader set of resources including computation and storage. The system encompasses four resource management mechanisms: xena, delegates, the H-FSC scheduler, and beagle. Interestingly, such mechanisms may be customised by applications to meet their specific demands. The xena mechanism is a resource broker, which has access to resource availability and also determines the resources that are needed to meet the application requirements. Delegates, as part of the active network paradigm 59
[Tennenhouse96], are code segments placed in routers, which are in charge of monitoring the network status and performing some dynamic resource management customisations. The H-FSC scheduler is then responsible for scheduling packets. Lastly, resource allocation is accomplished by the beagle mechanism. TAO [Schmidt98] is a high-performance real-time ORB. TAO is CORBA-compliant and has introduced several extensions to this standard in order to overcome the shortcomings of conventional ORBs regarding efficiency issues. The enhancements introduced to the ORB are the following: •
Optimised IDL stubs and skeletons. TAO’ s IDL compiler supports the generation of optimised (de)marshalling.
•
Real-time
object
adapter.
Perfect
hashing
and
active
demultiplexing techniques are used to improve the performance of the adapter. •
Run-time scheduler. TAO’s run-time scheduler support both static and dynamic scheduling.
•
Real-time ORB core. Multi-threaded, preemptive, priority-based connections are used. In addition, customised protocols can be plugged into the ORB.
•
Real-time I/O subsystem. The real-time I/O subsystem assigns priorities to real-time I/O threads in order to enforce the schedulability of the system.
•
High-speed network interface. The High-speed network interface provides support for a network interface consisting of one or more ATM port interconnect controller chips.
Notably, the scheduling service offered by TAO maximises the total utilisation and can be tailored to different application and platform characteristics. In particular, the scheduling framework can accommodate a variety of scheduling strategies, such as RMS, EDF, MLF and MUF. The structure RT_Info is defined on a per schedulable operation basis. This structure is populated for the specifications of the operations’ QoS attributes such as criticality, worse case execution time and period.
60
Finally, the Realize resource management system [Melliar-Smith98; Kalogeraki00b; Kalogeraki00a] offers a framework that supports dynamic scheduling. Notably, the framework provides tasks as schedulable entities, which may span processor boundaries. More specifically, tasks are modelled as sequences of method invocations whereby request messages carry scheduling parameters along the involved nodes. The idea of tasks in this framework is similar to distributable threads, which are introduced by the OMG’s Dynamic Scheduling proposal [OMG01d] (see section 3.3). In contrast to static systems, tasks are aperiodic and their arrival time cannot be predicted. Tasks are implementation-level entities, which have a unique id and a particular state at a given time. In addition, tasks are associated with a deadline, an importance metric, the computation time, and the laxity. The computation time is obtained by run-time monitoring functions. The laxity is the difference between the deadline and the computation time. Interestingly, tasks may include multiple threads. In addition, at the top-level of the scheduling architecture a global resource manager is defined, which maintains current system information. The resource manager includes a global scheduler in charge of distributing objects on processors based on the system information. Local schedulers are then responsible for determining the execution order of method invocations based on the laxity values. Finally, the local dispatcher obtains the next object to be executed and sets the priority of the thread that will carry out the execution. For this purpose, such priority is mapped to the specific priority scheme of the local operating system. Further research on resource management in middleware includes the Legion environment [Chapin99]. However, this work does not address in depth the issue of adaptation. Rather, this approach focuses on large-scale computing systems. In regard to resource reservation in middleware, the QualMan platform [Nahrstedt98] supports reservations for CPU, memory and network resources. Other research considers CPU reservations at the operating system-level such as the Rialto operating system [Jones95; Jones96; Jones97; Jones99] developed by Microsoft Research.
61
3.3.6 Analysis Since resource management in distributed systems is a heavily populated area we have selected the work most closely related to the approach in the thesis. Some approaches provide a framework supporting the abstract representation of resources. More specifically, explicit representation of heterogeneous resources is supported by the GRMS and the Globus architecture. Various levels of abstraction can be defined by the ERDoS platform whereas the FARA system allows for the representation of a set of different resources by a single entity. Also notable is the task approach taken by the Realize framework, which may be viewed as a representation of the processing resources of distributed interactions. In contrast, systems that do not provide direct abstractions for resources include the QuO framework, the Agilos architecture and Darwin. Some of these systems end up producing complex code, which is difficult to maintain evolve, and reuse. The causes of this complexity are twofold. Firstly, considerable complexity is introduced by tangling the functional behaviour of real-time distributed applications with non-functional aspects. Notably, the ERDoS platform and the QuO system provide some support for addressing this situation. The former allows for the separation of aspects within three distinct models whereas, in the latter, different QoS aspects are specified in aspect-specific languages. Secondly, modelling resource management for single-object interactions does not represent any problem for small applications. However, for large applications the code complexity increases considerably. This issue is only tackled by a few approaches. The GRMS supports the management of coarser-grained interactions by using distributed sessions whereby a whole application may be suspended on behalf of critical application when resources are scarce. The ERDoS framework addresses this issue by providing different levels of abstraction for resource management within the system model. Also, since the LASM model of ERDoS is recursive, reconfiguration of large-scale applications may be easily achieved. Interestingly, all approaches provide some support for evolution. In addition, not all platforms support resource configuration or reallocation of resources such as Agilos and QuO. The former mainly focus on application-level adaptation strategies whereas the latter does not provide explicit facilities for resource
62
management. Notably, consistency issues are only addressed by the GRMS. However, all the approaches meet the performance requirement. Finally, some approaches provide a description language for the specification of resource configuration and/or resource reconfiguration. That is, ERDoS offers CORBA IDL extensions, QuO features QDL, FARA provides service profiles and TAO supports an RT_Info repository. A summary of the analysis concerning middleware platforms is presented in table 3.1. Summary of Evaluation of Middleware Platforms GRMS
ERDoS
QuO
Agilos
Globus
FARA
DARWIN
TAO
Realize
Retain benefits of open dist plat
Met
Met
Met
Met
Met
Met
Met
Met
Met
Various levels of abstraction
Partly met
Met
Not met
Not met
Partly met
Partly met
Not met
Partly met
Partly met
Configurable
Partly met
Partly met
Not met
Not met
Partly met
Partly met
Partly met
Partly met
Partly met
Reconfigurable
Partly met
Partly met
Not met
Not met
Partly met
Partly met
Partly met
Partly met
Partly met
Evolution
Met
Met
Partly met
Partly met
Partly met
Partly met
Partly met
Partly met
Partly met
Consistency
Met
Not met
Not met
Not met
Not met
Not met
Not met
Not met
Not met
Performance
Met
Met
Met
Met
Met
Met
Met
Met
Met
Language support
Not met
Partly met
Partly met
Not met
Not met
Partly met
Not met
Partly met
Not met
Table 3.1. Summary of Evaluation of Middleware Platforms.
3.4 Standards for Resource Management in Middleware 3.4.1 Real-Time CORBA Overview Real-Time (RT) CORBA [OMG99c] provides facilities for resource management and offers facilities for the end-to-end predictability of operations in fixed-priority CORBA applications. RT-CORBA assumes that the underlying operating system provides support for the definition of scheduling priorities and policies. Interestingly, coarse-grained interactions are represented by activities, which may encompass several, possibly nested,
63
operation invocations. No IDL is defined for the specification of activities, however. An activity is essentially an analysis/design concept that describes a sequence of control flow that may transverse across system boundaries. Importantly, RT-CORBA allows for the configuration of processing, communication and memory resources. In the case of processing resources, this standard presents a platform independent priority scheme and defines a priority propagation mechanism whereby thread priorities are propagated across address spaces. The scheme defines CORBA priorities, which are platform independent priorities that are mapped to native system-specific priorities. There are two models for the propagation of priorities. In the server declared priority model the server dictates the priority at which it will execute requests. Priorities are set on a per-object basis in this model. In contrast, the client propagated priority model allows the clients to define the priority of operations that are executed along the path of an activity. Priorities are defined on a per-activity basis in this model. In addition, priority transforms are supported, which are implemented as “hooks” that intercept requests and are able to change the invocation priority. This may be useful, for example, to change priorities according to external factors such as the server load. The thread pool model in RT-CORBA allows for the pre-allocation of pools of threads along with specific thread attributes. Thread pools can be defined on a per-POA basis. Although, the association of a thread pool with multiple POAs is also feasible. There are two types of thread pool supported. Thread pools without lanes are characterised by the number of static threads that can be created, the maximum number of threads that can be created dynamically, and the default priority of all threads defined within the pool. The first defines the number of threads that are pre-created for the thread pool whereas the second states the number of threads that may be dynamically created when all static threads are in use and more threads are required. The third identifies the priority assigned to static threads. Thread pools with lanes are then divided into lanes whereby each lane defines a CORBA priority for static threads, the number of static threads, and maximum number of dynamic threads. In this case, dynamic threads are assigned the priority of the lane. This type of thread pool can also be configured in such a way that lanes with high priorities borrow threads from lower priority lanes. In addition, RT-CORBA introduces
64
the scheduling service, which aims at alleviating the complexity introduced by the realtime features and the chances of errors. In regard to communication resources, the standard supports the selection and configuration of protocol properties. More concretely, the desired ORB/transport protocol may be defined along with specific attributes. Server-side protocol properties are defined at POA creation time and include both the list of available protocols and the protocol configuration attributes. Client-side protocol properties include the ability of clients to select which protocols to use when they connect to objects. This feature can be used on a per-connection basis whereas settings of server-side protocol properties are only allowed on a per-object basis. In addition, an explicit binding mechanism is provided that create connections before the client invokes the server, thus saving the time for connecting at run-time. Explicit bindings support two policies. Firstly, priority-banded connections allow clients to specify priorities for each network connection and select the appropriate connection at run-time. Clients are able to define one or more priority bands when establishing an explicit binding with a server. Secondly, private connections are nonmultiplexed connections, which ensures that the connection will not be used by another two-way request until the previous request is obtained. Finally, some support for memory buffer management is achieved by configuring a thread pool for a maximum buffer size or number of requests. That is, thread pools may be optionally configured for buffering requests. In the case of configuring this buffering feature in a thread pool, requests will be queued until a thread is available. Discussion RT-CORBA offers facilities for end-to-end predictability in distributed real-time systems. Notably, the standard provides support for the management of processing resources, communication resources and memory resources. Processing resources are represented as thread pools. Communication resources may be configured by selecting an ORB/transport protocol and connections may be set up in advance with the explicit binding mechanism. However, abstractions for memory resources are not provided. Rather, memory buffering is configured within thread pools.
65
Interestingly, the standard introduces the term ‘activity’ to represent distributed interactions. Coarser-grained interactions may be represented by activities, which may exhibit nested operation invocation across system boundaries. Nevertheless, activities are only an analysis/design concept, that is, no IDL is defined for the specification of activities. Evolution is not achieved as the introduction of new resource types implies the modification of the standard. In addition, most of the facilities for resource configuration are only allowed at both compile- and load-time, leaving aside support for run-time reconfiguration. RT-CORBA is not suitable for dynamic real-time systems since the standard is only focused on fixed-priority based systems. Finally, consistency issues are not address by the standard. 3.4.2 Dynamic Scheduling Real-Time CORBA Overview The main goal of the OMG’s Dynamic Scheduling proposal [OMG01d] is to overcome the limitations imposed by RT-CORBA in terms of dynamic scheduling. That is, RT-CORBA only addresses static distributed systems whose resource requirements are known a priori. Offline analysis allows developers to predict the workload that will be imposed by this kind of systems. Thus, variations in these systems are bounded within a priori known operating modes. In contrast, dynamic distributed systems are those that are susceptible to experiencing unexpected dynamic changes. Therefore, in this type of system it is not feasible to predict the overall workload. This proposal introduces some modifications to the RT-CORBA specification and also provides some extensions to the standard. Essentially, the modifications includes deprecating the scheduling service in the RT-CORBA specification. The reason for this is that since the scheduler defined in the proposal covers fixed priority scheduling, the scheduling service is no longer needed. The contributions of the proposal include three main points. Firstly, different thread scheduling policies may be chosen by the application or system designer. The proposal provides a framework that allows for the development of portable schedulers. The proposal, however, does not address portability of schedulers at the operating system level; rather, such portability is offered at the ORB interaction level. In addition, interfaces for a small set of well known scheduling policies are defined as optional
66
compliance points. Such policies include fixed-priority scheduling, earliest deadline first (EDF), least laxity first (LLF) and maximise accrued utility (MAU). Secondly, the scheduling parameters associated with a scheduling policy may be changed at run-time. Examples of these parameters include priority, deadline, and expected execution time. Thirdly, a distributable thread is defined as a schedulable entity that may transverse object boundaries and even node boundaries. This entity replaces the concept of activity introduced in RT-CORBA. A distributable thread is basically characterised by a unique system-wide id and a set of scheduling parameters. An application may encompass many distributable threads, which execute concurrently and asynchronously by default. In addition, a distributable thread may include more than one thread whereby only one thread can be active at a time. Importantly, a distributable thread carries the scheduling parameters set by the application along the visited nodes. In addition, a distributed thread may be executed either by a single thread or multiple threads. Interestingly, a distributable thread may be partitioned into a (potentially nested) set of scheduling segments. Each scheduling segment represents a flow of control associated with particular scheduling parameters, which may span node boundaries. Scheduling segments may be useful, for example, when independently developed software components define their own scheduling segments. Finally, portable interceptors (as defined in CORBA) may be used to handle the transitions of a distributable thread between object instances. Discussion The dynamic scheduling proposal is an effort to overcome the restrictions in regard to dynamic aspects imposed by RT-CORBA. Interestingly, the thread scheduling policy of a system may be selected from a set of different policies. However, a scheduling policy can only be set before the application starts execution. That is, scheduling policies cannot be dynamically replaced at run-time. Another interesting feature of this proposal is that scheduling parameters may be modified during the operation of the system. This feature introduces more flexibility for dynamic applications to achieve adaptation. Most notably, the proposal extends the concept of activity, introduced in RT-CORBA, to an implementation entity referred to as distributable thread. A distributable thread carries its scheduling parameter across system boundaries and may encompass one or more threads.
67
However, the potential for concurrency is not exploited and only one thread may execute at a time. A distributable thread can be viewed as the representation of the processing resources of a coarse-grained distributed interaction. However, no abstractions are yet provided for other type of resources such as memory buffers. In addition, consistency and evolution aspects are not addressed. 3.4.3 UML Profile for Scheduling Overview The proposal of the OMG for a UML Profile for Scheduling [OMG00b] is based on a generic framework for modelling resources [Selic00]. A profile in the UML world is basically the specialisation of the general semantics of UML for a particular domain. Within this resource framework a resource is a generic abstraction that may denote either physical devices or logical devices. Examples of the former are processors, memory and networks, whereas the latter include buffers, queues and semaphores. A resource is viewed as a server with associated QoS attributes in charge of attending client demands. Moreover, a resource may provide one or more services. A QoS contract then captures both the client’s QoS requirements and the QoS offered by the server. A core taxonomy of resource types classifies resources into two dimensions. The first dimension relates to activeness. Active resources are capable of “spontaneous” behaviour such as processors whereas passive resources are not able to initiate an activity on their own such as buffers. The second dimension regards protection against concurrent access. A protected resource has an access control policy, which dictates the order whereby requests have access. In contrast, unprotected resources do not have control over access. However, a resource broker may control the concurrent access to a resource in order to avoid concurrency conflicts. Interestingly, a layered interpretation of the relationship between clients and resources is provided. In such a layered interpretation a distributed system is represented by a two viewpoint model. The client (application) side of this relationship is related to the logical viewpoint whereas the resource (platform) side is referred to as the engineering viewpoint. The logical viewpoint represents the logical interactions of the entities constituting a distributed system. This viewpoint abstracts away both how these entities
68
are implemented and the details of the interaction mechanisms. The engineering viewpoint then establishes how the logical viewpoint is realised. More concretely, this viewpoint describes how elements of the logical viewpoint are implemented by a specific technology. The relationship between the two models, whereby elements of the logical model are mapped to elements of the engineering model, is referred to as a realisation relationship. Importantly, the engineering model not only covers physical resources but also logical resources. Interestingly, different levels of abstraction may be represented by recursively applying the realisation relationship. At one level of abstraction, the engineering model can be viewed as a logical model and be mapped to its own engineering model. The recursion finishes when hardware resources are reached. Notably, the proposal includes an abstraction, referred to as scenario, to represent dynamic aspects such as how and when a client accesses a resource. A scenario constitutes a causally ordered set of scenario steps, which represent different activities. Activities involving interactions between clients and resources are represented by scenario events. The effects of external occurrences on the environment may also be represented as scenario events. Discussion In general terms, the proposal presents a comprehensive resource framework. Resource abstractions may represent both physical and logical resources. Interestingly, the layered interpretation offers two models for the representation of distributed systems with associated QoS properties. The logical model is related to the computational viewpoint of RM-ODP whereby the elements of a system along with their logical interactions are represented. In addition, the engineering model of the layered interpretation, which is in charge of realising the logical model, resembles both the engineering viewpoint and the technology viewpoint of RM-ODP. Notably, since the models may be applied recursively, various levels of abstraction can be represented. Evolution can easily be achieved as there are not any restrictions in the number of abstractions supported. Moreover, the approach provides support for the separation of concerns so that a complex design problem is simplified by separating logical aspects from implementation concerns. Furthermore, since the logical and the engineering model
69
are detached, the logical model may be realised on a number of different platform configurations without introducing any modifications to the logical model. Although scenarios provide flexibility for modelling dynamic aspects, it is not clear how scenarios could be used to model resource reconfigurations. The proposal is more focused on offering support for modelling the QoS requirements of real-time systems and does not address adaptation issues directly. In addition, no explicit support is provided for consistency issues. 3.4.4 Analysis Overall, there have been significant efforts to standardise resource management issues in middleware. The UML Profile for scheduling provides the most comprehensive resource framework. Within this framework, resources may be modelled at different levels of abstraction and evolution can be easily achieved. The framework also allows for the separation of concerns between logical aspects from implementation issues. Importantly, dynamic resource interactions can be modelled as well. However, no specific support is provided for the reconfiguration of resources. Interestingly, RTCORBA allows for the end-to-end predictability of activities and offers some support for resource management. The concept of activity is introduced for the analysis and design of coarser-grained distributed interactions. However, RT-CORBA does not address dynamic scheduling and is merely concerned with static real-time distributed systems. In addition, explicit representation is restricted to processing resources, which are modelled as thread pools. Importantly, the Dynamic Scheduling proposal overcomes some of the limitations of RT-CORBA. More specifically, the proposal modifies and extends RT-CORBA in order to address dynamic scheduling. Interestingly, scheduling parameters may be modified at run-time. Most notably, the distributable thread extends the idea of activities to the implementation level allowing for the run-time representation of end-to-end schedulable entities. These efforts represent important achievements in the standardisation of resource management in middleware. However, more work needs still to be done in order to provide a wider support for the dynamic reconfiguration of resources. The performance of the approaches is relative to their particular implementation and no one addresses
70
consistency issues. In general terms, the author believes that more openness and flexibility needs to be provided in order to achieve both coarser- and finer-grained resource reconfiguration in middleware systems. Finally, all the approaches provide some support for the specification of resource management. A summary of the evaluation of the standards is presented in table 3.2. Summary of Evaluation of Standards RTCORBA
Dynamic Scheduling RT-CORBA
UML Profile for Scheduling
Retain benefits open dist plat
of
Met
Met
Met
Various levels abstraction
of
Partly met
Partly met
Met
Configuratble
Partly met
Partly met
Met
Reconfigurable
Partly met
Partly met
Partly met
Evolution
Not met
Not met
Met
Consistency
Not met
Not met
Not met
Performance
Relative
Relative
Relative
Language Support
Partly met
Partly met
Partly met
Table 3.2. Summary of Evaluation of Standards.
3.5 Summary This chapter has outlined current research on resource management at the middleware level. The main goal of this chapter has not been to present an exhaustive overview on related work in the area but to provide an overview of the research most closely related to the approach in the thesis. It has been shown that even though the approaches presented here have obtained important achievements, further work is still required to introduce more support for the reconfiguration of resources. More precisely, support is required for the explicit representation of resources at different levels of abstraction, the dynamic reallocation of resources, and dynamically changing management policies. The next chapter presents the resource management framework of OpenORB, including both a resource model and a task model which, in conjunction with reflection techniques, introduce facilities for the dynamic resource reconfiguration of the middleware platform.
71
Chapter 4 The Resource Framework 4.1 Introduction This chapter presents the resource framework of the OpenORB platform [Blair01]. The resource framework basically includes both a hierarchical resource model and a task model. The former provides various levels of abstraction for resources, resource factories and resource managers. Therefore, both fine- and coarse-grained resource management are feasible within this model. The latter then models both application and middleware services in terms of task hierarchies. That is, such services are broken into tasks, which can in turn be recursively split into sub-tasks. Tasks are then associated with top-level resource abstractions. Such an association determines how both resources and resource management policies are allocated to these services. We then exploit reflection as a means of achieving a separation of concerns of the functional and non-functional behaviour (e.g. resource management). As background, the overall approach of the OpenORB architecture is described in section 4.2. The resource model and the task model are then presented in sections 4.3 and 4.4 respectively. An explanatory example of both the resource model and the task model is introduced in section 4.5. Finally, a summary of the chapter is presented in section 4.6.
4.2 Background on the OpenORB Architecture 4.2.1 Overall Approach The OpenORB framework is basically a componentised reflective middleware architecture. Reflection allows for opening up the middleware in a principled way. Complementary to this, the component technology introduces more configuration and reconfiguration capabilities into distributed applications and increases the level of reuse, as mentioned in chapter 2. Within the context of OpenORB a component is basically “a unit of composition with contractually specified interfaces and explicit context
72
dependencies only” [Szyperski98]. The component model used in the OpenORB architecture is greatly influenced by the Computational Model from RM-ODP [Blair97]. Hence, components within this model have several interfaces. Not only operational interfaces but also stream and signal interfaces are supported. Moreover, explicit bindings, which offer more control over the communication path between component interfaces, can be defined. Explicit bindings are first class entities representing the endto-end communication path between two component interfaces usually located in different address spaces. Importantly, explicit bindings allow the programmer to specify the desired level of QoS for the binding. In addition, these bindings may offer a (operational) control interface supporting operations for both inspection and adaptation. There are three different styles of explicit bindings which are in conformance with the three styles of interfaces introduced before: operational bindings, stream binding and signal bindings. Hence, interfaces are connected through the appropriate explicit binding style. Operational bindings are in charge of supporting the fairly traditional (remote) operation requests. In contrast, stream bindings provide support for continuous media interactions. Within this type of binding, streams represent one or more unidirectional transmission of flows, i.e. continuous media type. Signal bindings are then suitable for event communication. For this purpose, this type of bindings supports one-way notifications. In addition, reflection allows for the inspection and run-time reconfiguration of the middleware architecture. Importantly, reflection provides a principled approach to introduce more openness and flexibility in middleware systems. The reflective architecture is introduced in the next section. 4.2.2 Meta-Space The meta-space is structured, but not restricted, as a set of four meta-models, as shown in figure 4.1. The multi-model reflection approach was first introduced by AL-1/D [Okamura92] in order to simplify the meta-interface by maintaining a clear separation of concerns among different system aspects. Each meta-model is introduced in turn below. In the OpenORB architecture, structural aspects are modelled by both the interface and architecture meta-models. The interface meta-model allows for the inspection of all
73
interfaces offered by a given component. In addition, the type signature of a component interface may be discovered dynamically. In contrast with the previous design of OpenORB [Blair98], interfaces are immutable. That is, it is not allowed to change the internal implementation of an interface. For instance, it is not possible to introduce new methods to an interface nor change the signature of an interface. The purpose of this is to make contracts between interfaces irrevocable. As a consequence, it is assured that no incompatibilities are introduced between client interfaces and server interfaces. Evolution is achieved by introducing new components into a system with upgraded interfaces. There is an interface meta-model per component. Architecture Meta-model
Interface Meta-model
Interception Meta-model
Resources Meta-model
Meta-level interceptor
Base-level
Address Space
Figure 4.1. The Structure of the Meta-Space The architecture meta-model deals with the way a composite object is composed, i.e. how its components are inter-connected, and how these connections are manipulated. A component-graph is used for representing composite components, in which components are connected together by edges representing local bindings as described above. Moreover, open bindings [Fitzpatrick98] are an extension to explicit bindings that offer further capabilities for introspection and reconfiguration. More specifically, the internal component configuration of an explicit binding is represented by a component-graph [Hokimoto96]. This graph consists of components connected by either local bindings or
74
other explicit bindings. Local bindings are assumed to provide instantaneous and reliable communication whereby this kind of bindings is normally located in single address space or a single machine. Hence, the internal configuration of an explicit binding can be inspected by accessing the component-graph. Moreover, reconfiguration of the binding is feasible by manipulating the component-graph. There is an architectural meta-model per component, but it is also possible to obtain the architectural structure of an address space and even of the whole application which may include more than one address space. In addition, this meta-model defines a set of architectural constraints which determine the validity of component reconfigurations. For instance, introducing codec components in the communication path between two objects requires that both sides of the connection use the same compression/decompression scheme. Behavioural aspects are modelled by the interception meta-model. The interception meta-model is in charge of introducing additional behaviour to a component interface. This meta-model is realised as dynamic plugable interceptors, which enable the insertion of pre- and post-behaviour. This meta-model applies to all styles of interfaces whereby interceptors may be collocated on a per-interface basis. Examples of the use of this metamodel include the dynamic addition of support for security and accounting to a system. Finally, and of central importance to this thesis, the resource meta-model is concerned with both structural aspects and behavioural aspects. The former relates to the facilities provided for resource awareness. The structural aspects of the resources meta-model regard the abstractions for the representation of the underlying resources system and information about the relationships between these abstractions. These aspects are defined on a per address-space basis. The behavioural aspects of the resource meta-model are concerned with the resource management of components living in the same address space. More precisely, behavioural reflection models the management policies that govern the resources associated with a component. A detailed description of the resources meta-model is presented below. Further details of the overall architecture can be found in the literature. For example, detailed descriptions of the four meta-models can be found in [Blair00b; Blair00c;
75
Costa00a; Costa00b; Parlavantzas00; Saikoski00; Blair01; Costa01; Coulson01; Moreira01].
4.3 Resource Model 4.3.1 Overview The most important elements of the resource model are abstract resources, resource factories and resource managers [Blair99b; ReTINA99; Duran00a; Duran00c; Duran00d; Duran02]. Abstract resources explicitly represent system resources. In addition, there may be various levels of abstraction in which higher-level resources are constructed on top of lower-level resources. At the lowest-level are represented physical resources such as CPU, memory, and network resources. This level may contain information about the type and speed of the CPU as well as the type and speed of the physical network. Higherlevels of abstraction then include the representation of more abstract resources such as virtual memory, team of threads, network connections and more generic type of resources. In addition, abstract resources support operations that allow them to have access to both the adjacent higher- and lower-level. The recursive use of these operations allows the user to navigate through all levels of abstraction. Interestingly, abstract resources may also have access to both its factory and its manager. Importantly, virtual task machines (VTMs) are top-level resource abstractions and they may encompass several kinds of resources (e.g. CPU, memory and network resources) allocated to a particular task. Resource managers are then responsible for managing resources. A manager allows its users to share the resources it manages by either mapping or multiplexing higher-level resources on top of lower-level resources, as shown in figure 4.2. Furthermore, resource schedulers are a specialisation of managers and are in charge of managing processing resources such as threads or virtual processors (or kernel threads). For instance, thread schedulers multiplex user-level threads on top of virtual processors. Resource managers also support operations for going across the different levels of abstraction of managers. Importantly, facilities for performing both control admission test and reservation of resources are offered. In addition, managers may have access to the resources being
76
controlled. Interestingly, the management policy of a manager may be dynamically changed. It is also possible to associate additional abstract resources with a manager. Lastly, the main duty of resource factories is to create abstract resources. For this purpose, higher-level factories make use of lower-level factories to construct higher-level resources. For example, a factory of team of threads may use a thread factory in order to build a team abstraction. In addition, a factory may have access to the resources it has created. Finally, factories also support operation for accessing both higher- and lowerlevel abstractions.
Multiplexes or maps Manages
High-Level Abstract Resources
Manager Low-Level Abstract Resources
Figure 4.2. The Resource Management Framework 4.3.2 The Resource, the Factory and Manager Hierarchies The resource model consists of three complementary hierarchies corresponding to the main elements of the resource model. The resource hierarchy provides various levels of abstraction of resources. As mentioned previously, VTMs, are at the top of this hierarchy whereas at the bottom are representations of raw resources. Resource factories provide a second type of hierarchy. VTM factories are represented at the top of the hierarchy. Lower-level factories then include thread and memory buffer factories. Thirdly, we have managers hierarchies. Managers defined at the top of the hierarchy, are in charge of managing higher-level resources, e.g. VTMs, whereas managers at the bottom manage lower-level resources, e.g. processors. As an example, a particular instantiation of the framework is shown in figure 4.3 (note, however, that the framework does not prescribe any restriction in the number of abstraction levels nor the type of resources modelled). At the top-level of the resource hierarchy is placed a VTM, as shown in figure 4.3 (a), which encompasses both memory buffer and a team abstraction. The team abstraction in turn includes two or more user
77
level threads. Moreover, a user level thread is supported by one or more virtual processors (VPs), i.e. kernel level threads. At the bottom of the hierarchy are located physical resources. Similarly, a VTM factory is at the top of the factory hierarchy and uses both a memory and a team factory. The team factory is supported by both the thread and the virtual processor factory as depicted in figure 4.3 (b). Finally, the manager hierarchy is shown in figure 4.3 (c). The team scheduler and the memory manager support the VTM scheduler to suspend a VTM by temporally freeing CPU and memory resources respectively. The thread scheduler in turn allows the team scheduler to suspend its threads. Finally, the VP scheduler supports the preemption of virtual processors. Conversely, this hierarchy also provides support for resuming suspended VTMs.
VTM team
thread k
VPi
thread l
VTMFact
memory
physical memory
VPj
team Fact
memory Fact
thread Fact
VPFact
CPU
(a) A hierarchy of abstract resources
(b) A factory hierarchy
VTMSched team Sched
memory Mgr
thread Sched
VPSched
(c) A manager hierarchy
Figure 4.3. A Particular Instantiation of the Resource Meta-Model A level of abstraction in one hierarchy is directly related to a particular abstraction level in the other two hierarchies. Figure 4.4 shows an example that integrates all three hierarchies into a single hierarchy. For instance, the VTM scheduler and the VTM factory are both placed at the top-level of the hierarchy. The latter creates higher-level abstractions (i.e. VTMs) which encompass both threads and memory buffer. The former is then responsible for multiplexing VTMs on threads. VTM abstractions are also mapped to memory buffer resources.
78
VTMs creates
multiplexes and maps VTM Scheduler
manages
VTM Factory
Buffer chunks
Threads creates
maps
multiplexes Thread Scheduler
Thread Factory
Buffer Factory
manages
Buffer Manager
Virtual Processors multiplexes creates manages
CPU Scheduler
VP Factory
Physical Memory
manages
Processors
Figure 4.4. An Example Integrating the Three Hierarchies of the Resource Framework 4.3.3 The Resources Meta-Object Protocol Operations on Resources, Factories and Managers The resources MOP covering the operations on resources, factories and managers is shown in figure 4.5 (the complete MOP is given in appendix A). This figure also depicts the associated class hierarchy of the resource framework. Such a class hierarchy may be used to support a particular instantiation of the resource framework. The Common class is a mixin class for the three class hierarchies (i.e. resources, factories and managers). The interface of this class provides operations to traverse any of the hierarchies by recursively accessing either the lower- or the higher-levels. For instance, the resource hierarchy may be traversed by applying the getLL() operation at the top-level, i.e. the VTM. This
79
operation would be later applied to the lower-level resources, and so on. Both the higherlevel and the lower-level of an entity in the hierarchies may be set by accessing the operations setHL() and setLL() respectively. Access to both the manager and factory of an abstract resource can be obtained through the interface defined by the class AbstractResource. The references to the manager and factory of an abstract resource are registered by the operations setManager() and setFactory() respectively. In addition, machines are capable of performing some activity [Blair99b; ReTINA99], that is, they receive messages and process them. Thus, machines may be either abstract processing resources (e.g. threads) or physical processing resources (e.g. CPUs). In contrast, jobs [Blair99b] only refer to abstract processing resources since they inherit from the abstract resource class. Both abstract resources and jobs are created by factories as shown in figure 4.5. In addition, abstract resources are managed by managers. However, since jobs are processing resources, they are managed by schedulers instead. The
interface
of
a
job
exposes
the
operations
getSchedParam()
and
setSchedParam(). The former is in charge of accessing predefined settings. The latter is responsible for performing a control admission test. If successful, resources are reserved and the scheduling parameters are set. common getLL( ) setLL( ) getHL( ) setHL( ) Manager
Machine AbstractResource
run( )
1..*
maps myManager
resources getManager( ) setManager( ) getFactory( ) setFactory( )
Job
AbstResrcFactory 1..*
creates
resources
myFactory
newResource( ) getResources()
getPolicy( ) setPolicy( ) admit( ) reserve( ) expel( ) getResources( ) addResource( ) removeResource( )
multiplexes Scheduler
getSchedParam( ) setSchedParam( )
JobFactory creates newResource()
suspend( ) resume( ) schedule( )
Figure 4.5. UML Class Diagram of the Resource Framework Including Most of the Resources MOP
80
The class hierarchy of factories is rather simple. The AbstResrcFactory class interface exposes an operation for the creation of abstract resources. This operation is also responsible for associating the resource with a resource manager. In case of creating processing resources, a job factory is used and the scheduling parameters should be indicated. This interface also provides the operation getResources() that returns references of the resources created by the factory. Finally, in respect to the manager hierarchy class, the manager class interface exposes the operation admit() which performs an admission control test that determines whether or not there are enough resources to satisfy a resource request. In a successful case, resources may be reserved by using the operation reserve(). Reservations can then be liberated by invoking the operation expel(). Similar to factories, through the operation getResources(), resource managers are able to retrieve the references of the underlying resources they control. Such references may be included
or
removed
addResource()
and
from
a
manager’s
registry by using
removeResource()
respectively.
In
the
operations
addition,
the
management policy is obtained by accessing the operation getPolicy() whereas the operation setPolicy() allows the user to set the management policy of the manager. Moreover, the scheduler allows the user to suspend and resume an abstract processing resource by invoking the suspend() and resume() operations respectively. Lastly, the order of execution of multiplexed resources is determined by the schedule() operation. Operations on the Resources meta-object The operations introduced above are applied to particular elements of the resources meta-space. In contrast, the operations described in table 4.1 are applied to the resources meta-object. The first two operations are related to the task model which is introduced in section 4.4. The next three operations shown in this table are fairly intuitive and do not require further explanation. The operation getProxy() returns a resource server proxy whose role is to provide access to a remote capsule. This proxy is presented in the next section. In addition, the operation getServices() retrieves information about the services provided by the application. Such information includes the type of services
81
supported along with their QoS properties, tasks and the object classes in charge of implementing the service. Finally, operations are defined for acquiring and releasing the lock of the resources meta-space. This lock is used to avoid race conditions when resources are reconfigured as explained in the next section. Resources MOP (Operations on the Resources Meta-Object) Operation Signature
Description
getVtm(task_name)
Get the VTM associated with a task
getTask(vtm)
Get the task associated with a VTM
getVtmFact()
Get the VTM factory of this meta-space
getVtmSched()
Get the VTM scheduler of this meta-space
getCurrentThread()
Get the executing thread
getProxy(capsule_name) Get the proxy to the resource server located in the given capsule getServices()
Get the record of services registered in this metaspace
getLock()
Acquire the resources meta-space lock
releaseLock()
Release the resources meta-space lock
Table 4.1. Operations on the Resources Meta-Object Initial Example of Introspection and Reconfiguration As an example of resource introspection consider the VTM vtmx based on the VTM structure depicted in figure 4.3 (a). This VTM supports the execution of the component codec that is in charge of compressing audio packets in an audio binding. In order to obtain the lower-level resources of this VTM the following operations are performed: interf = interface(codec) taskRegistry = interf.get_attribute_value(codec.IN, ‘taskRegistry’) task = taskRegistry.getTask(‘encode’) resources = resources() vtmx = resources.getVtm(task) team = vtmx.getLL()[‘TEAM’] buffer = vtmx.getLL()[‘BUFFER’] communication = vtmx.getLL()[‘COMMUNICATION’]
82
threads = team.getLL()[‘TEAM’] vpi = threads[i].getLL() The first line reifies the interface meta-object concerning the component codec. The task registry of the interface IN belonging to this component is then obtained. This registry contains the mappings between the interface operations (which are task switching points) and tasks. From this registry the task associated with the operation encode is retrieved. The resources meta-object is then reified and the VTM associated with the task is accessed. The resources concerning one level of abstraction below the VTM are then obtained. These include a team of threads, memory buffer, and communication resources. Similarly, the getLL() operation is recursively applied to the team and then to a particular thread. As a result, the virtual processor that supports the execution of the team of threads is accessed. Both the scheduler and the factory of a particular thread may be then accessed as follows: threadj = threads[j] threadSchedulerj = threadj.getScheduler() threadFactoryj = threadj.getFactory() The policy of the thread scheduler is then changed from lottery scheduling to ratemonotonic as an example of resource reconfiguration: threadSchedulerj.setPolicy(‘rate-monotonic’) Suppose now that a monitor notices that the virtual processor vpi is under performing. To tackle this situation, the priority of this virtual processor is increased by changing the scheduling parameters as follows: vpi.setSchedParam(new_schedParam) Later on the application user has solicited an increase in the level of QoS. Thus, another compression scheme is used which notably improves the level of QoS but does require more network resources. A reconfiguration of the network resources is then performed as follows: connections = communication.getLL()[‘CONNECTIONS’] connectionk = connections[k] 83
connectionk.setSchedParam(new_param) The set of network connections is first obtained. Afterwards, a particular connection is accessed and its QoS parameters are changed. These parameters may include new settings for both the end-to-end delay and the throughput. Note that further examples of both resource introspection and resource reconfiguration will be presented in section 4.5. 4.3.4 Providing QoS Management Support for the Resource Model In order to provide QoS management support for the resource framework, we further introduce QoS managers, resource servers and resource server proxies, as showed in figure 4.6. Upon a service request with associated QoS properties, the QoS manager interacts with resources, factories and managers in order to satisfy the required level of QoS. For this purpose, the QoS manager is responsible for looking up the service that best matches the required level of QoS. The QoS manager is also in charge of requesting the appropriate resource managers to perform both the admission control tests and the reservation of resources when the test is successful. QoS managers may be either global or local. There is a single global QoS manager in a system whereas there is one local QoS manager per address space. The latter is only able to attend local requests. In contrast, the former is allowed to carry out requests involving the local capsule and/or remote capsules. Therefore, when a local QoS manager receives a request involving remote parties, the request is forwarded to the global QoS manager. Resource servers are in charge of receiving requests from resource server proxies located in remote capsules. The main role of resource servers is to allow remote parties to have access to the local resources, factories and managers. Hence, these servers delegate the received request to the appropriate entities. Resource server proxies are then basically communication gateways that allow access to remote resources meta-spaces. Therefore, these proxies are able to send requests for the inspection and reconfiguration of remote resources. The MOP of the QoS manager, the resource server and the resource server proxy are depicted in table 4.2. It should be noticed that the resource server may receive operation requests on resources, factories, managers and the QoS manager. For instance, when the operation getLL(vtm_id) is invoked on the resource server, it localises the
84
actual VTM associated with the identifier and delegates the operation to the VTM. Hence, the lower-level resources of the VTM are obtained. Finally, the identifiers of these resources are retrieved by the resource server and sent back to the proxy. In addition, a system of management components defined in [Blair99a; Blair00a] is used in order to support monitoring and adaptation capabilities in the resource framework. The role of management components basically involves two aspects, namely, monitoring and control [Blair99a]. The former includes event collectors, which interface with the underlying implementation, and monitors which detect QoS violations. Interestingly, monitors may be placed anywhere. As a result, not only resource elements may be monitored but also application and middleware components. Component configuration response (QoS contract) Event collector
Request (service, QoS spec)
Event collector
QoS Manager
Event collector
Resource Server
Resources
Monitor
Application
Factories Managers
Strategy Selector
Component configuration
Resource Proxy
Event collector Strategy Activator
Middleware General-Purpose OS with RT Extensions
Figure 4.6. QoS Management Support for the Resource Framework
85
Control aspects include then strategy selectors and strategy activators. It is the responsibility of strategy selectors to decide which strategy to apply upon the occurrence of a QoS violation. Strategy activators are then in charge of realising the adaptation strategy by providing the detailed implementation of this strategy. Hence, strategy activators are able to execute actions that change the value of the parameters of an operation performed by a component. Strategy activators have access to resources, factories and managers in order to perform resource reconfiguration. These activators may also have access to remote resources meta-spaces through resource server proxies. Moreover,
reconfiguration
of
both
application
and
middleware
components
configurations may be carried out by strategy activators. Finally, the assumption for the general-purpose operating system is that the ability for dispatching threads in a preemptive fashion is supported. MOP of the QoS Manager, Resource Server and Resource Server Proxy Operation Signature
Description
Operation on QoS Managers getService(serviceType, parameters, qos_spec)
Look up the service with the requested level of QoS, perform admission control test and reserve resources
Operations on Resource Servers startServing()
Get the resource server ready for receiving requests
stopServing()
Stop the resource server from receiving requests
operation([entity_id,] operation_param)
Apply a particular operation with the given parameters on the indicated entity
Operations on Resource Server Proxies connect(capsule)
Connect the proxy to the given capsule
close()
Close the current connection
operation([entity_id,] operation_param)
Forward the request of the execution of an operation to the resource server
Table 4.2. The MOP of the QoS Manager, Resource Server and Resource Server Proxy
86
Importantly, in order to assure that no race conditions take place when the admission control is performed and resources are reserved or reconfigured, both the strategy activator and the QoS managers must acquire the resources meta-space lock before carrying out any action. There is a resources lock per address-space. Hence, local QoS managers only need to acquire the local lock. The global QoS manager and the strategy activator, however, must acquire the lock of all the involved parties. Furthermore, in order to avoid potential deadlock problems, only a single strategy activator can be defined in the system. In addition, the activator must be located in the same capsule as the global QoS manager. Thus, the first in acquiring the local lock is entitled to try to obtain any required remote locks.
4.4 The Task Model 4.4.1 Overview The main feature of the task model is that it offers support for the high-level analysis and design of the system’s resource management. More precisely, the task model allows us to define both how system resources are allocated in a distributed system and the resource management policies that are used. This model also prescribes the level of quality of service for services provided by such a system. For instance, for different services of the same type, such as audio transmission, more than one service offering different level of QoS may be defined. A task is an activity performed by the system, e.g. transmitting audio over the network or compressing a video image, which has an amount of resources assigned for its execution. A task instance is then an occurrence of a task; a task may be related to one or more task instances. For example, the task of receiving incoming requests from the network may have several instances when there is a concurrent access to the server and there is a multi-threaded policy for attending requests. The task model is concerned with both application services and middleware services. Thus, we take a task-oriented approach for managing resources in which services are broken into tasks and are accommodated in a task hierarchy. Top-level tasks are directly
87
associated with the services provided by a distributed system. Lower-levels of this hierarchy include the partition of such services into smaller activities, i.e. sub-tasks. Subtasks are denoted as follows: Task.sub-task.sub-sub-task… For instance, an audio transmission task referred to as transmitAudio may be partitioned
into
two
subtasks,
namely
transmitAudio.send
and
transmitAudio.receive. The former is in charge of sending audio packets whereas the second sub-task is responsible for receiving stream data. This approach offers resource management modelling of both coarse- and fine-grained interactions. The former is achieved by defining coarse-grained tasks (i.e. tasks spanning components and address spaces boundaries) and the latter is done by using task partitioning. In addition, tasks are not necessarily disjoint and may be interconnected. For instance, a component running one task may invoke another component concerned with a different task. A distributed task then spans the boundaries of an address space and is associated with a distributed VTM. Hence, distributed tasks are split into local tasks to facilitate their management. 4.4.2 Tasks and VTMs Tasks have an associated VTM. Hence, a VTM represents a virtual machine in charge of supporting the execution of its associated task. VTMs also represent a higher-level of resource management. They are an encapsulation of the pool of resources allocated for the execution of their associated tasks. VTMs isolate the resources that a service uses to have a better control of the desired level of QoS provided by it. That is, the resources a task uses for execution are localised. Hence, it is straightforward to reconfigure the resources of a task when it is under-performing.
88
2..* Primitive VTM schedules
1..* 1 1..*
0..* 1..* Primitive Task
2..*
0,1
0..*
Composite task 1..*
0..* 0..* creates
Distributed Task 0..* 2..* 1 Address Space
1
VTMSched
1
schedules 2..* 0..*
1 VTMFactory
creates
1..*
0..*
1..* 1..* Composite VTM
Distributed VTM
Figure 4.7. UML Diagram of Relationships between Tasks and VTMs The UML model in figure 4.7 illustrates other details concerning the relationship between tasks and VTMs. There is a one-to-one mapping between a task hierarchy and a resource hierarchy. The top-level task of a task hierarchy is directly associated with a composite VTM placed at the top of the resource hierarchy. This composite VTM may encompass various local and/or remote VTMs. Tasks of this kind are composite tasks, which are constituted by a number of sub-tasks and may involve either a single or multiple operation invocation sequences. In the former case, sub-tasks are interleaved whereas in the latter case sub-tasks are disjoint. Sub-tasks that are not further partitioned are called primitive tasks and are only related to a single operation invocation sequence. The simplest case for such a sequence is that one whereby only one operation is invoked.
89
0..*
In addition, primitive tasks are only related to one address space. However, distributed tasks involve two or more address spaces. It should be noted that sub-tasks may also be composite and even distributed.
transmitAudio transmitAudio.receive VTMtx transmitAudio.receive.nodex
nodex transmitAudio.send
vtmx transmitAudio.receive.nodey
nodey nodei
associated with
VTMsend
vtmy vtmz
VTMreceive transmitAudio.receive.nodez
nodez Audio source
Audio sinks
Figure 4.8. Example of a Task Hierarchy with its Associated VTMs Similarly, VTMs not containing other VTMs as lower-level resources are named primitive VTMs. Hence, the bottom-levels of a task hierarchy consist of by primitive tasks which are associated with primitive VTMs. Primitive VTMs are then defined according to the specific platform characteristics of the node of residence. Moreover, composite VTMs are involved with more than one local task and distributed VTMs include two or more address spaces. Importantly, distributed VTMs may recursively encompass other distributed VTMs. Finally, VTM schedulers and VTM factories are defined on a peraddress space basis. As an example of the association between task hierarchies and VTMs hierarchies, consider a system in charge of providing the service of audio communication. This service is partitioned into a task hierarchy, as shown in figure 4.8. The top-level task transmitAudio is associated with the top-level resource abstraction vtmtx. This task includes the sub-tasks transmitAudio.send and transmitAudio.receive,
90
which are associated with vtmsend and vtmreceive respectively. The latter task is then further partitioned into: - transmitAudio.receive.nodex - transmitAudio.receive.nodey - transmitAudio.receive.nodez
Finally, each one of these sub-tasks is associated with a correspondent primitive VTM defined within vtmreceive. The top-level resource abstraction, i.e. vtmtx, is a distributed VTM which includes both a primitive VTM and a distributed VTM. The latter is finally integrated by primitive VTMs. 4.4.3 Task Graph Configurations A task graph is a directed graph in which an operation invocation sequence (i.e. a task) is represented in terms of components, component interfaces and component interface operations. Different from component configurations, task graphs define the specific interface operations a task path goes through. There is a great variety of the task graph configurations that can potentially exist. An example of this complexity is the fact that several tasks may be defined over the same component configuration path. Since an interface may include several operations, different tasks may run through the same interfaces by accessing different operations. Moreover, different tasks may even go across the same operations when the same component configuration is used for different purposes (e.g. marshalling video streams and marshalling audio streams). Therefore, components, interfaces, and operations may participate in more than one task at the same time. Furthermore, the transition from one task to another one is an important issue that contributes to define how task graphs are interconnected. Such transitions are carried out by task switching points. Interestingly, a task switching point corresponds to a change in the underlying resource pool to support the execution of the task that has come into play. A task switching point is essentially defined as a triplet including a component, an interface, and an exported operation. Imported operations are not used for defining these points for the sake of simplicity. It is only needed one point in the interaction path of two
91
components to define a task switch. This point could be defined in either side of the interaction, however, defining it in the exporter side is more natural as this side is in charge of attending requests.
t_y t_y
t_z
...
m_x
m_x
...
Task point definitions m_x task_n
a) single task switching point
t_x
t_i
...
t_k m_x
m_x
...
Task point definitions m_x
t_z
if t_y t_k if t_i
b) multiple task switching point
Figure 4.9. Types of Task Switching Points There are two types of task switching points as depicted in figure 4.9. A single task switching point, depicted in figure 4.9 (a), can only switch to a single task whereas a multiple task switching point may switch to two or more different tasks, as shown in figure 4.9 (b). The former maps a switching task point to a single task. As an example of a single task switching point consider a protocol stack in which each layer is associated with a different task. Hence, when going from one layer to the adjacent one a task switch takes place. In contrast, a multiple task switching point selects, from a set of tasks, the task to switch according to the current task. To accomplish this, “If” statements are used to define the possible options within a task point. As an example of a multiple-task switching point, consider a task graph of a video stream connection va which includes a filter component bound to a compressor component and these components are part of task ty and tz respectively. Similarly, there is another video stream connection vb that uses the same instances for the both the filter and the compressor, although they are associated with tasks ti and tk respectively. Thus, the compressor will switch to task tz if the filter was executed as part of task ty, otherwise it will switch to task tk.
92
4.5 An Explanatory Example of the Resource and Task Models 4.5.1 Introspection and Fine-Grained Reconfiguration As a more substantial example of resource introspection and fine-grained resource configuration consider a middleware platform in charge of providing the service of audio communication. This service takes place between capsule 1 and capsule 2. The service has associated two different levels of QoS, which are related to two different tasks, namely trasmitAu_V1 and transmitAu_V2. These tasks have the associated VTMs vtmV1 and vtmV2 respectively. In addition, each of these tasks is initially running one binding as depicted in figure 4.10. The internal configuration of each binding includes stubs for both the marshalling and unmarshalling of packets which are then connected by an UDP binding. Moreover, each of the tasks is partitioned into two subtasks: send and receive. These sub-tasks are concerned with sending and receiving audio streams respectively as shown in figure 4.11. The task transmitAu_V1.send is associated with vtmV1_send whereas the task transmitAu_V2.send
is
related
to
vtmV2_send.
Similarly,
the
tasks
transmitAu_V1.receive and trasnsmitAu_V2.receive have associated the VTMs vtmV1_receive and vtmV2_receive respectively.
transmitAu_V1
Audio Binding 1 source1
sink1 transmitAu_V2
Audio Binding 2 source2
sink2
Capsule 2
Capsule 1
Figure 4.10. Example Scenario Another binding is then requested as follows: binding = audioCommService(audioSrc.OUT, audioSink.IN, qos_spec)
The parameters passed to the request of the service are the interfaces to be bound and the desired level of QoS for that binding. The QoS manager then selects the most 93
appropriate service within the requested service type. In this case we assume that the selected task is transmitAu_V1. As a consequence the QoS manager, which happens to be located in capsule 2, identifies whether there are enough resources to provide the required level of QoS by inspecting the spare resources in the VTM associated with this task. It is noticed, however, that the VTM vtmV1_receive does not have spare threads. Since vtmV2_receive has some unused threads, one thread is borrowed from this VTM: vtmV2_receive = resources.getVtm(‘transmitAu_V2.receive’) teamV2 = vtmV2_receive.getLL()[‘TEAM’] threadsV2 = teamV2.getLL() for thr in threadsV2: if not thr.is_active(): break threadsV2.remove(thr) teamV2.setLL(threads) The resources of the task transmitAu_V1.receive are first introspected in order to obtain an available thread belonging to this task. Thus, the team of threads is obtained and then the threads contained within the team. An inactive thread is then identified and then removed from the resources of this VTM. The operation setLL() update the changes and causes the removed thread to be unregistered by the thread manager related to this VTM. Task1: transmitAu_V1 Task2: transmitAu_V1.send Task3: transmitAu_V1.receive
task 1 task 2
task 3 QoS Monitor
OUT
IN
IN
OUT
IN
udpBinding
OUT
IN
OUT
audioSrc stub
audioBinding
OUT
IN
audioSink stub
Figure 4.11. Internal Configuration of the Audio Binding 1 The process of adding this thread into the lower-level resources of vtmV2_receive is as follows: vtmV1_receive = resources.getVtm(‘transmitAu_V1.receive’) teamV1 = vtmV1_receive.getLL()[‘TEAM’] threadsV1 = teamV1.getLL() threadsV1.append(thr) teamV1.setLL(threadsv1)
94
Similar to the previous procedure, the set of threads of the VTM are obtained. The thread is then added to the team of threads by setting its lower-level resources to the updated list of threads. The setLL() function also encompasses operations that associate the moved thread with the thread manager related to this VTM. Consider then that this resource reconfiguration is not enough as more memory buffer space is also required to cover the demands of the new binding. Some memory may then be borrowed from vtmV2_receive as follows: bundleV2 = vtmV2_receive.getLL() bufferV2 = bundleV2[‘BUFFER’] fragment = bufferV2.getFragment(amount) bundleV2[‘BUFFER’] = bufferV2 vtmV2_receive.setLL(bundleV2) The bundle of resources of vtmV2_receive is obtained in which buffer resources are accessed. A logical fragment is then created and is added to vtmV1_receive as follows: bundleV1 = vtmV1_receive.getLL() bufferV1 = bundleV1[‘BUFFER’] bufferV1.addFragment(fragment) bundleV1[‘BUFFER’] = bufferV1 vtmV1_receive.setLL(bundleV1) Similarly, the buffer resources are obtained from vtmV1_receive and the fragment is then included into this buffer. Again, the operation setLL() updates the new settings. 4.5.2 Coarse-Grained Reconfiguration As an example of coarse-grained resource reconfiguration consider that after introducing more bindings the task transmitAu_V2 becomes overloaded. The system is using an EDF scheduling policy [Liu73] which optimises the use of CPU up to 100 %. However, during transient overload the algorithm clearly behaves unpredictable. The QoS manager has detected such an overload and has opted to change the policy to ratemonotonic [Liu73]. This algorithm provides a lower bound of CPU utilisation than that offered by EDF but behaves better in overload conditions [Mercer94; Stankovic95]. Thus, the following operations are performed: vtmV1_receive = resources.getVtm(‘transmitAu_V1.receive’) vtmV2_receive = resources.getVtm(‘transmitAu_V2.receive’) vtmV1_receive.setSchedParam(schedParamV1_receive) vtmV2_receive.setSchedParam(schedParamV2_receive)
95
vtmSchedcapsule2 = vtmV1_receive.getManager() vtmSchedcapsule2.setPolicy(‘rate-monotonic’) The VTMs associated with each task are first obtained. This is followed by two operations in charge of setting the appropriate scheduling parameters to the VTMs. Afterwards, the VTM scheduler is accessed and its policy is changed. Similar actions take place for changing the scheduling policy of the VTM scheduler located in capsule 1. vtmV1_send = resources.getVtm(‘transmitAu_V1.send’) vtmV2_send = resources.getVtm(‘transmitAu_V2.send’) proxy = resources.getProxy(‘capsule 1’) proxy.setSchedParam(vtmV1_send.get_id(),schedParamV1_send) proxy.setSchedParam(vtmV2_send.get_id(),schedParamV2_send) vtmSched_idcapsule1 = proxy.getManager(vtmV1_send.get_id()) proxy.setPolicy(vtmSched_idcapsule1,’rate-monotonic’) Since this scheduler is located in a different capsule, the QoS manager carries out the reconfiguration operations through the proxy. In this case, the identifiers of both the VTMs and the VTM schedulers are used instead for the look up process to be performed in the remote capsule. Consider now the case of a drastic shortage of resources due to dynamic changes to the environment of the application, one of the existing bindings may be suspended on behalf of the other. The bindings associated with the VTM with the lowest criticality would be suspended. The QoS control mechanism would proceed as follows, after finding out which is the lowest critical VTM, which happens to be vtmV2: vtmSched = vtmV2.getManager() vtmSched.suspend(vtmV2) As a result, the VTM scheduler will suspend the corresponding VTM. The operation of suspending this VTM encompasses the suspension of the local and remote VTMs, namely vtmV2_send and vtmV2_receive. This in turn involves the suspension and liberation of their underlying resources, i.e. threads, network connections and memory. A more complex example of CPU reconfiguration is discussed in chapter 7 as part of the detailed evaluation of the resources framework.
96
4.6 Summary This chapter has presented a resource framework within the context of the reflective middleware platform called OpenORB. The resource framework supports the resources meta-model of the middleware platform. This framework consists of both a resource model and a task model, which in conjunction provide a high-level approach for the management of resources. Importantly, the resource framework allows for the inspection and dynamic reconfiguration of resources at various levels of abstraction. The next chapter introduces software engineering methodologies for the configuration and dynamic reconfiguration of resources in distributed multimedia systems. More concretely, an architecture description language, referred to as Xelha, is presented for the high-level description of distributed multimedia systems. In addition, a resource configuration description language (RCDL) is introduced for the low-level description of resources.
97
Chapter 5 Engineering Adaptive Resource Management 5.1 Overview The engineering of adaptive resource management in OpenORB is achieved by the use of both an architecture description language (ADL), called Xelha [Duran00b] (pronounced “shell-ha” with a strong ‘h’ sound), and an underlying resource configuration description language (RCDL) [Duran00a].
The ADL allows for the
definition of the coarse-grained structure of such systems in terms of components and connectors along with their associated QoS properties. Importantly, the ADL provides support for the specifications of both static QoS management (i.e. desired level of QoS) and dynamic QoS management (i.e. the mechanisms to attain the contracted level of QoS). The RCDL is then concerned with the specification of lower-level computational resources together with their associated management policies. Hence, the RCDL represents the mapping of Xelha QoS definitions to specific resource requirements. Interestingly, the RCDL includes a set of aspect languages whereby different concerns of the system resource configuration are defined. Notably, both the resource model and the task model introduced in chapter 4 are captured by the Xelha and RCDL languages. The structure of the chapter is as follows. Xelha is introduced in section 5.2 in which the general characteristics of the language regarding components, connectors and interfaces are provided. In addition, the support offered for the specification of QoS management properties is presented. An explanatory example is also included. The RCDL is then introduced in section 5.3 and its various aspect languages are described. Finally, section 5.4 presents a summary of the chapter.
98
5.2 Xelha: a Resource-Aware ADL 5.2.1 Introduction Software architecture [Shaw96a; Bass99] aims at diminishing the overall complexity of software development. In this paradigm, software design focuses on a higher-level view of a system, thus abstracting away from implementation details. Within this approach, architecture description languages (ADLs) represent formal notations for describing software architectures in terms of coarse-grained components and connectors. ADLs also provide architecture configurations which define how component and connectors are interconnected. ADL tools then help to automate the development processes by offering code generation. Importantly, analysis tools allow us to formally verify a system architecture, hence detecting potential problems before starting the finedgrained development process. There has been considerable research in the area [Gorlick91; Garlan94; Gorlick94; Luckham95a; Luckham95b; Magee95; Shaw95; Binns96;
Magee96;
Medvidovic96;
Shaw96b;
Vestal96;
Allen97a;
Allen97b;
Medvidovic99; Medvidovic00]. Most research has focused on the specification of static architectures with little work in dynamic aspects. Furthermore, little attention has been paid to tackle real-time architectural issues, especially for distributed systems. This section presents the Xelha notation for the specification of distributed multimedia system architectures. Xelha basically encompasses definitions of architectural structures together with their associated QoS management properties. In common with many ADLs, the former are expressed in terms of components, connectors and interfaces, and the latter are enunciated within task definitions which include task graphs, QoS specifications and QoS management structures. The language is then derived from both the task model and the resource model introduced in chapter 4. End-to-end component interactions are associated with task graphs. Both fine- and coarse-grained resource management are feasible within this model. Xelha also includes the specification of both static QoS management and dynamic QoS management. The former concerns the definition of the desired QoS properties whereas the latter relates to the mechanisms for maintaining the level of QoS contracted.
99
Finally, Xelha uses object-oriented typing for the purposes of type-checking, architecture reusability and dynamic architecture specifications. 5.2.2 Components, Connectors and Interfaces Within the language components represent elements possibly residing in different capsules whereas connectors model component interactions. Both components and connectors may include other composite and non-composite elements. Hence, a distributed system is represented as a hierarchical composition in terms of both composite components and composite connectors. Such a hierarchical composition is similar to that offered by Darwin [Magee95] for the construction of composite components. Hence, the granularity of a component type may range from a primitive component type to a complex system configuration type. The top-level component, which is at the top of the composition hierarchy, models the whole system architecture. Def component Name( parameters ) extends ComponentType: components: ... connectors: ... interfaces: ... composition graph: ... tasks: ... services: ...
Figure 5.1 Component Specification The basic structure of a component is shown in figure 5.1. The components section defines the constituents of a composite component. This is achieved by defining both the component type and the capsule where the component is to be created. An example of how an internal component is defined is as follows: components: srcStub: SrcStub, srcCapsule interfaces: IN: SrcStubIN, ( srcStub, IN )
The component name srcStub is associated with the component type SrcStub and the capsule srcCapsule. Similarly, the connectors section specifies the internal connectors of a composite component. The external interfaces of the component are then defined in the interfaces section. This specification also defines the interface name IN. The interface name is then
100
a reference to the interface of the same name belonging to the component srcStub whereby the defined interface type is SrcStubIN. In addition, the composition graph section defines how these components are interconnected. For this purpose, in the interfaces section the involved component interfaces are associated with unique names. Following this, interface attachments are defined in the edges section. As an example consider the following composition graph: composition graph: interfaces: srcOUT: ( srcStub, OUT ) streamConnIN: ( streamConn, IN ) edges: ( OUT, streamConnIN )
The interfaces section defines the interface name srcOUT for the interface of name OUT that belongs to the component named srcStub. Similarly, the interface name streamConnIn is defined as the interface IN of the component streamConn. The edges section defines then the interfaces to be bound. The tasks and services sections then allow us to specify the QoS management properties associated with a component. A detailed explanation of both task and service specifications is introduced in the next section. It should be noted that specifications of primitive components only include the interfaces and tasks sections whereas composite components are concerned with all of them except the service section. Only the top-level component covers the service section as discussed below. Finally, the language allows us to extend component types. Hence, when sub-typing a component type, the whole structure of it is inherited (e.g. internal components, interfaces, component graph, etc). In addition, connector specifications are similar to component definitions as shown in figure 5.2. However, connector specifications additionally associate a connector style with the connector definition. There are three connector styles: operational connections, signal connections and stream connections, as defined in chapter 4, section 4.2.1. Furthermore, connector specifications separate those interfaces that are part of the interaction protocol from the interfaces that provide some control over the connector. The purpose of this is to perform some type-checking to ensure that the style of the interfaces involved in the interaction protocol conform with the style of the connector (see below).
101
In case of distributed connectors, the participating capsules are passed as parameters to the connector type.
Def connector AudioConnector_V1(string srcCapsule, string sinkCapsule) extends AudioConnector: components: srcStub: SrcStub, srcCapsule sinkStub: SinkStub, sinkCapsule connectors: streamConn: StreamConnector(srcCapsule, sinkCapsule) interfaces: interaction: IN: SrcStubIN, ( srcStub, IN ) OUT: SinkStubOUT, ( sinkStub, OUT ) control: CTRL: StreamConnCTRL, (streamConn, CTRL) composition graph: interfaces: OUT: ( srcStub, OUT ) streamConnIN: ( streamConn, IN ) streamConnOUT: ( streamConn, OUT ) IN: ( sinkStub, IN ) edges: ( OUT, streamConnIN ) ( streamConnOUT, IN ) tasks: . . .
Figure 5.2 Example of a Connector Specification Interface types are specified outside the definition of a component as shown in figure 5.3. Interfaces are associated with interaction styles which conform to the connection styles described above. Furthermore, interfaces are defined in terms of both the operations they provide and the operations they require. An interface may also be extended whereby the extended interface inherits all provided and required operation definitions that are specified by the base interface. For instance, figure 5.3 depicts the interface type specification of a component that reads from an audio device. The interface inherits from the interface AuDevInterf and includes the provided operation open() and the required operation send(). Def Interface AuDevReadInterf extends AuDevInterf: provides: boolean open(in int rate, in int channels, in int sampleWidth): requires: void send(in AudioPacket packet):
Figure 5.3. Example of an Interface Specification
102
The language also supports the specification of dynamic architectures, i.e. architectures that may experience changes at run-time. This feature allows us to specify a range of architectural types, defined within a type hierarchy, that can be instantiated as a result of accessing a service provided by a component. Thus, component and connector definitions are considered to be type definitions similar to that of a class. Component types may also be generic and, as a consequence, parameterised. The purpose of this is to introduce the ability of defining an architecture of a composite component in which each valid internal component type may be part of a sub-type hierarchy. Such an approach allows us to reuse component configuration definitions. We introduce the optional construct inst within the definition of an operation to denote that the invocation of such an operation will result in the dynamic instantiation of the component type (or any of its sub-types). For instance, consider a stream connection server in charge of instantiating stream bindings as depicted in figure 5.4. The component userInterface is connected to the interface IN of the connections server. The specification of this interface is as follows: Def Interface ConnServerInterf: provides: boolean new_connection(in string srcInterf, in string sinkInterf, in QoSspec qos): inst StreamConnection
The interface of the server exposes the operation new_connection() whose parameters are the interfaces to be bound and the required level of QoS for the binding. The invocation of the operation then results in the dynamic instantiation of the StreamConnection component type which is specified as follows:
103
Def component StreamConnection(StreamBinding bindingType, string srcCapsule, string sinkCapule, SrcOUT srcInterf, SinkIN sinkInterf): connectors: binding: bindingType(srcCapsule,sinkCapsule) composition graph: interfaces: bindingIN: ( binding, IN ) bindingOUT: ( binding, OUT ) edges: ( srcInterf, bindingIN ) ( bindingOUT, sinkInterf )
This is a parameterised component whose internal configuration includes two interfaces bound by the StreamBinding connector type. The inheritance hierarchy of this connector type is shown in figure 5.5. The hierarchy contains connectors for the transmission of both audio and video. In both cases, two different versions associated with a distinct level of QoS are offered. Therefore, diverse architectural components may be dynamically created as a result of invoking the operation new_connection().
...
IN connectionServer
userInterface
StreamConnection StreamBinding
source
The type of this interface is ConnServerInterf
sink
Capsule 1
Capsule 2 dynamically created
Figure 5.4. Dynamic System Architecture Finally, as an optional feature, the language allows components residing in the same address space to interact directly without the use of a connector. Thus, when component interactions are rather simple, such interactions may be modelled implicitly.
104
StreamBinding
AudioBinding
AudioBinding_V1
VideoBinding
AudioBinding_V2
VideoBinding_V1
VideoBinding_V2
Figure 5.5. The UML Inheritance Diagram of the StreamBinding Connector Type. 5.2.3 QoS Management Overview The ADL offers support for the specification of both the QoS properties provided by a service and the actions taken in order to attain the contracted level of QoS. The former corresponds to static QoS management aspects, which include the initial component configuration and the amount of resources required to provide the stated level of QoS [Blair00a]. The latter, in contrast, relates to dynamic QoS management aspects which in turn involves run-time monitoring and dynamic reconfiguration of both the component configuration and the configuration of resources [Blair00a]. The support that Xelha provides for both static and dynamic QoS aspects are introduced in turn below. Static QoS Management Within Xelha, static QoS management aspects are specified in terms of task graphs together with their associated QoS specifications. There is a one-to-one relationship between a task graph and a statement of QoS properties. In our model, components are represented as rounded squares whereas connectors are depicted as rounded rectangles. In addition, similar to the work defined in [Rastofer01] we employ the use case maps (UCM) notation [Buhr95; Buhr98; Amyot99] for the
105
graphical representation of task graphs. The UCM notation includes elements for representing paths, start points and end points. Paths are depicted as lines that go across components. Start points are then represented as filled circles whereas end points are depicted as bars. Figure 5.6 shows an example of a component configuration associated with a task graph. The task path of the task transmitAu starts at the interface IN of the component AudioConnector_V1 and terminates at its interface OUT. The task graph goes across the components srcStub, streamConn and sinkStub. In addition, there
are
two
subtasks
defined,
namely
transmitAu.marsahall
and
transmitAu.unmarshall. Each one of these task graphs has associated QoS properties. For instance, the end-to-end delay of task transmitAu is 20 ms. Task path Task starting point
AudioConnector_V1
Task end point
network delay = 10 ms transmitAu Ta1 = 0
IN
OUT
srcStub Tb1 = 0 transmitAu.marshall
streamConn
sinkStub Tc1 = 0
Tb2 = 5 ms
Ta2 = 20 ms
Tc2 = 5 ms transmitAu.unmarshall
Figure 5.6 Example of a Component Configuration Associated with Task Graphs More complex interactions involving concurrent tasks may be represented by UCM’s ORs/ANDs notation. Hence, OR-forks are used to depict tasks emerging from a single path segment as shown in figure 5.7 (a). Moreover, OR-joins are used to indicate tasks that share the same path segment as depicted in figure 5.7 (b).
AND-join N:1
Generic version of AND-join/fork
OR-join N:M tx if ty
OR-fork
(a) Single task switching point
tb if ta
M:1
(b) Multiple task switching point
Figure 5.7 Representation of task switching points in UCM
106
Importantly, single task switching points are represented by AND-joins, which indicate that one or more task graphs are switched into a single task graph, as shown in figure 5.7 (a). In addition, multiple task switching points are represented by a generic version of AND-fork/joins whereby multiple tasks graphs are switched into two or more task graphs, as shown in figure 5.7 (b). The obtained tasks from this task point are then represented by an OR-join since they all share the same task path segment. Def task transmitAu.marshall: swithing points: srcStub:CTRL:start if taskx capsule: “capsule 1” qos specifications: delay(srcStub:IN:read, streamConn:IN:put) = 5 throughput(srcStub:OUT:put) = 64 Def task transmitAu includes transmitAu.marshall, tansmitAu.unmarshall: importance: 5 qos specifications: delay(streamConn:IN:put, streamConn:OUT:put) = 10 packet_loss(streamConn:IN:put, streamConn:OUT:put) = 5 delay(srcStub:IN:read, sinkStub:OUT:write) = 20 jitter(srcStub:IN:read, sinkStub:OUT:write) = 1 qos management structure: ...
Figure 5.8 Task Specification Interestingly, task graph definitions include the specification of task switching points as shown in figure 5.8. Such points denote the operation that triggers the task switch and are expressed in conjunction with the associated interfaces and the components. This approach is sufficient to specify where tasks start and where they finish. “If” statements are optionally defined to determine whether a task switch should be performed according to the current task (see chapter 4, section 4.4.3). The associated capsule of the task is also specified. Composite tasks are then specified by defining the inclusion of other tasks as sub-tasks. In addition, the importance metric is used to define the criticality of a task; tasks with a high importance value have precedence over lower important tasks in case of resource contention. QoS specifications allow us to define the QoS properties associated with a task graph. These properties are expressed in terms of three main QoS categories for distributed
107
multimedia [Blair97]. Firstly, timeliness properties are concerned with the end-to-end delay of multimedia interactions and delay variations (i.e. jitter), with both measured in milliseconds. Secondly, volume properties deal with the throughput of data and are measured either in frames delivered per second or in bytes per second. Finally, reliability properties refer to the permitted percentage of loss of media frames and bit error rates. As depicted in figure 5.8, QoS specifications are defined in terms of the task end points for each QoS property. Thus, a task end point is defined as a triplet including a component, an interface and an operation. It is worth mentioning that the QoS specifications in Xelha are not restricted to the set of QoS categories presented above and can be extended to cover other areas. Services: Def service type AudioCommService: Def service AudioComm_V1: user qos: “low” Tasks: transmitAudio_V1.marshall, 20 transmitAudio_V1.unmarshall, 20 Def service AudioComm_V2: user qos: “high” Tasks: transmitAudio_V2.marshall, 10 transmitAudio_V2.unmarshall, 10 Def service type VideoCommService: Def service VideoComm_V1: user qos: “low” Tasks: transmitVideo_V1.marshall, 20 transmitVideo_V1.unmarshall, 20 Def service VideoComm_V2: user qos: “high” Tasks: transmitVideo_V2.marshall, 10 transmitVideo_V2.unmarshall, 10
Figure 5.9. Example of the Specification of the System Architecture’s Services. Finally, the services provided by a system architecture are defined within the section of services. This section applies only to top-level components and allows several types of services to be defined. A service type is basically a set of services with related semantics
108
whereby each service offers a different level of QoS. Examples of service types are an audio communication service and a video conference service. A service type may then encompass more than one service as depicted in figure 5.9. The user-level of QoS offered by each service is specified. The tasks involved in a service are also defined. Importantly, reservation of resources is defined within the specification of the top-level composite component. Resources are reserved according to the specifications defined in the tasks sub-section in terms of the task name and the maximum number of instances for the task (as shown in figure 5.9). For this purpose, the specifications can be processed by an interpreter whereby the QoS specifications of the task are translated into specific resources (e.g. amount of memory and percentage of CPU). This may be achieved by taking into account both the maximum desired number of task instances and platform specific resource requirements of the components involved. Such resource requirements can be obtained, for example, by measuring the component resource demands in a series of tests. qos management structure: collector: COLLECT: SinkStub_Collect, sinkStub, COLLECT timed automaton: automaton: Tautomaton_3 strategy activator: activator: Activator_V1 qos management graph: interfaces: automatonIN: ( automaton, IN ) automatonOUT: ( automaton, OUT ) activatorIN: ( activator, IN ) activatorOUT ( activator, OUT ) streamConnCTRL: ( streamConn, CTRL) edges: ( COLLECT, automatonIN ) ( automatonOUT, activatorIN ) ( activatorOUT, streamConnCTRL )
Figure 5.10 QoS Management Structure Specification. Dynamic QoS Management Dynamic QoS management aspects are tackled through the use of a QoS management structure consisting of management components. A task may or may not have an associated QoS management structure. That is, when a task hierarchy is defined, a QoS management structure associated with the top-level task might be enough to determine
109
the adaptation process for the whole hierarchy. However, finer-level of QoS management can be introduced by defining such adaptation structures for finer-level tasks. As introduced in chapter 4, management components provide support for monitoring and control. Monitors and strategy selectors are specified by timed automata [Rajeev94]. Timed automata (TA) are finite state-transition graphs which also include timing (and data) constraints. The main feature of TA is that they can be simulated and formally verified for correctness and reachability. In addition, several graphs can be modelled and simulated separately, and afterwards combined to a single graph [BlairL99; BlairL00]. Xelha defines QoS management structures as shown in figure 5.10. Hence, monitors and strategy selectors are TA that are modelled separately and joined together afterwards in a single automaton whose behaviour is implemented by a pre-built component which can be automatically generated by the use of an associated tool (see chapter 6). Event collectors are then represented as component operations which are responsible for observing events that occur in the component. All these operations are grouped in a single interface of the component. Finally, the strategy activator is concerned with another pre-built component that is in charge of carrying out the adaptation strategies. The component configuration of the QoS management structure is specified in the qos management graph section by defining how the management components are interconnected. As an example consider the connector type AudioConnector as depicted in figure 5.11. The internal structure of this connector includes a management structure whereby the automaton represents both the monitor and the strategy selector. The event collector is then represented by the interface COLLECT of the component sinkStub. In addition, the activator is able to receive signals from the automaton and can manipulate the stream connector by accessing its control interface. Such a QoS management structure is specified in Xelha as shown in figure 5.10. The collector is specified by indicating the interface type SinkStub_Collect followed by the component and the interface name to be monitored. The sections timed
automaton and strategy
activator define the
component types that implement the automaton and the activator respectively. Finally,
110
the composition graph section defines how the automaton and the activator are connected. Task path Task starting point
AudioConnector_V1 Task end point network delay = 10 ms transmitAu
sinkStub Ta2 = 20 ms
Ta1 = 0 Tb1 = 0 transmitAu.marshall
srcStub
streamConn Tc1 = 0
Tb2 = 5 ms
activator
Tc2 = 5 ms COLLECT transmitAu.unmarshall
automaton
Figure 5.11. Example of Connector with a QoS Management Structure. 5.2.4 A Complete Example of the Use of Xelha As an example consider a system architecture which includes a connection server in charge of dynamically establishing audio connections as shown in figure 5.12. Such a server is located in capsule 2 and is attached to a user interface component whereby a user may ask for an audio connection between the source and the sink components. The connection server is also connected to a capsule manager which is in charge of creating components within capsule 2. In addition, the connection server has access to the capsule manager residing in capsule 1 through a capsule proxy. The proxy and the capsule manager are then bound with an operational connection. capsuleMgr2
operationalConnector
capsuleProxy
capsuleMgr1
connectionServer
userInterface
AudioConnection AudioConnector_V1
source
The type of this interface is AuConnServIN
sink
Capsule 1
Capsule 2 dynamically created
Figure 5.12. Audio System Architecture. This system architecture is specified in Xelha as shown in figure 5.13. The first two sections define the internal components and connectors respectively. The composition
111
graph section then specifies how the components and connectors are interconnected. Following this, resource reservation is defined in the services section. Hence, the service AudioComm_V1 is provided with enough resources for supporting ten connections for sending audio in capsule 1. Similarly, capsule 2 is provided with support for ten connections for receiving audio.
Def component AudioSystem: components: connectionServer: ConnectionServer, “capsule 2” source: AudioSrc, “capsule 1” sink: AudioSink, “capsule 2” capsuleProxy: CapsuleProxy, “capsule 2” capsuleMgr2: CapsuleManager, “capsule 2” capsuleMgr1: capsuleManager, “capsule 1” userInterface: UserInterface, “capsule 2” connectors: operationalConnector: OperationalConnector_V1( “capsule 1”,“capsule 2”) composition graph: interfaces: uiOUT: (userInterface, OUT) connectorServIN: ( connectorServer, IN ) connectorServCAP: ( connectorServ, CAP ) capsuleMgr2IN: ( capsuleMgr2, IN ) connectorServOUT: ( connectorServer, OUT ) capsuleProxyIN: ( capsuleProxy, IN ) capsuleProxyOUT: ( capsuleProxy, OUT ) operationalConnectorIN: ( operationalConnector, IN ) operationalConnectorOUT: ( operationalConnector, OUT ) capsuleMgr1IN: ( capsuleMgr1, IN ) edges: ( uiOUT, connectorServIN ) ( connectorServCAP, capsuleMgr2IN ) ( connectorServOUT, capsuleProxyIN ) ( capsuleProxyOUT, operationalConnectorIN ) ( operationalConnectorOUT, capsuleMgr1IN ) Services: Def service type AudioCommService: Def service AudioComm_V1: Tasks: transmitAu_V1.marshall, 10 transmitAu_V1.unmarshall, 10 tasks: . . .
Figure 5.13. Audio System Architecture Specification
112
The definition of the interface IN of the component connectionServer is defined in figure 5.14. This is an operational interface which includes the operation new_connection() whose invocation results in the dynamic instantiation of the AudioConnection architectural type. This component type is depicted in figure 5.15. This specification states that the type of the connector attaching the end points is AudioConnector, and as a consequence any sub-type of it is also a valid type for the connector. Def Interface AuConnServIN: provides: boolean new_connection(in string srcInterf, in string sinkInterf, in QoSspec qos): inst AudioConnection
Figure 5.14. Interface Specification The
connector
type
that
best
matches
the
required
level
of
QoS
is
AudioConnector_V1, which was earlier depicted in figure 5.2. This connector is a sub-type of AudioConnector and encompasses two stubs components bound by a connector, as shown in figure 5.11, and is associated with task transmitAu. Furthermore,
the
sub-tasks
transmitAu.marshall
and
transmitAu.unmarshall have associated real-time annotations. For instance, the completion time for each of the two local tasks is 5 milliseconds. In addition, the maximum network delay is 10 milliseconds. As a consequence, the end-to-end delay of task transmitAu is 20 milliseconds. Def component AudioConnection(AudioConnector connectorType, string srcCapsule, string sinkCapule, SrcOUT srcInterf, SinkIN sinkInterf): connectors: auConnector: connectorType(srcCapsule,sinkCapsule) composition graph: interfaces: auConnectorIN: ( auConnector, IN ) auConnectorOUT: ( auConnector, OUT ) edges: ( srcInterf, auConnectorIN ) ( auConnectorOUT, sinkInterf )
Figure 5.15. Specification of the AudioConnection Component Type.
113
We have already seen the task specification in figure 5.8 and figure 5.10, however, to help the reader we present them both again in figure 5.16. Note that both the network delay and the packet loss are defined within the specification of the task transmitAu. The reason for this is that these QoS annotations involve both sub-tasks, i.e. sending and receiving packets from the network. Finally, the QoS management structure for the task transmitAu involves an automaton component and an activator component. The former is in charge of monitoring delays and packet losses. On the occurrence of a QoS violation, it is responsible for deciding which strategy to apply. Such a strategy is then realised by the activator component. Examples of adaptation strategies are resource reconfiguration, changing the sample rate, introducing filters, etc.
Def task transmitAu.marshall: swithing points: srcStub:CTRL:start if taskx capsule: “capsule 1” qos specifications: delay(srcStub:IN:read, streamConn:IN:put) = 5 throughput(srcStub:OUT:put) = 64 Def task transmitAu includes transmitAu.marshall, tansmitAu.unmarshall: importance: 5 qos specifications: delay(streamConn:IN:put, streamConn:OUT:put) = 10 packet_loss(streamConn:IN:put, streamConn:OUT:put) = 5 delay(srcStub:IN:read, sinkStub:OUT:write) = 20 jitter(srcStub:IN:read, sinkStub:OUT:write) = 1 qos management structure: collector: COLLECT: SinkStub_Collect, sinkStub, COLLECT timed automaton: automaton: Tautomaton_3 strategy activator: activator: Activator_V1 qos management graph: interfaces: automatonIN: ( automaton, IN ) automatonOUT: ( automaton, OUT ) activatorIN: ( activator, IN ) activatorOUT ( activator, OUT ) streamConnCTRL: ( streamConn, CTRL) edges: ( COLLECT, automatonIN ) ( automatonOUT, activatorIN ) ( activatorOUT, streamConnCTRL )
Figure 5.16. Task Specification
114
5.3 A Description Language for the Specification of Resource Management 5.3.1 Overview As mentioned earlier, a resource configuration description language (RCDL) is used to specify the resource management of the services provided by a distributed system. The language
adopts
aspect-oriented
programming
(AOP)
principles
[Kiczales97;
Kiczales01], which stress the separation of aspects in a system by programming each aspect in a different language. AOP essentially allows for the decomposition of a program into aspects that cross-cut each other. Traditional software engineering practices break down a system into modular units such as subroutines, procedures, objects, etc. However, the result of these practices is the construction of complex software in which different aspects of the system are inter-twined. It is argued that software complexity is due to this tangling of system aspects in a single program. Hence, the aspect separation makes it easier to write, read, maintain and extend programs. Aspect weavers are then in charge of composing the non-aspect and the aspect languages into a single system. Such a weaving process may be done at compile-time, at load-time and even at run-time. Important to the idea of aspect weaving is the concept of join points, which are welldefined points in the non-aspect language whereby the non-aspect language is coordinated with the aspect-languages. Examples of join points include method calls, class initialisation and access to the field of an object. Hence, aspects weavers generate join point representations of the non-aspect program whereby aspect programs are executed (or compiled) with respect to such representations. Some of the uses of join point representations include providing meta-information for the purposed of making decisions which are out of the scope of the main functionality of the system such as concurrency control, performance and error handling decisions. Another important use of these representations concerns inserting cross-cutting functionality such as adaptive behaviour.
115
5.3.2 Aspect Languages of the RCDL Introduction The RCDL is a lower-level description language which expands Xelha specifications into finer-grained aspects, including implementation details and platform specific concerns, as shown in table 5.1. Hence, Xelha definitions are mapped down into different aspects, thus, facilitating the analysis and further customisation of RCDL descriptions. More specifically, specification of the services provided by a system architecture are mapped down to service description language (SDL) descriptions which provide information about the QoS level, the task and the object class that are associated with a service. Task graph definitions in Xelha are translated to both task switch description language (TSDL) descriptions and task description language (TDL) descriptions. The former are concerned with the definitions of task switching points whereas the latter provides details about the resources assigned to tasks. Task QoS properties are further specialised by resource description language (RDL) descriptions, which define the specific resource requirements of a task instance according the characteristics of the platform of deployment. Finally, the QoS management structure is then described in the QoS management graph description language (QMGDL). Such graphs are defined on a per service type basis. This approach is similar to the QuO framework [Loyall98; Pal00] which offers a suite of aspect languages for the description of QoS requirements and adaptive behaviour. There are, however, some differences between the two approaches: (a) QuO focuses in CORBA-based systems whereas our framework targets a more general open framework. (b) QuO’s aspect languages may only specify QoS management for finegrained interactions, i.e. client-object interactions, whereas, our framework’s aspect languages offers support for both fine- and coarsegrained interactions. (c) QoS contracts in QuO are defined in terms of operating regions whereas our approach uses tasks and management objects. The former seems to be a more natural way of defining such contracts. However,
116
our approach provides support for simulation and verification. A more comprehensive description of the RCDL’s
aspect languages is
presented below.
RCDL’s Aspect languages Aspect Language
Description
Service Description Language (SDL)
Describes services in terms of the supported Level of QoS, its associated task and the object class that implements the service. Task Switch Description Language Describes the object operations that trigger (TSDL) a task switch. Task Description Language (TDL) Describes the resources that are associated with a task. Resource Description Language (RDL) Describes the resources associated with a task instance. QoS Management Graph Description Describes how management objects are Language (QMGDL) interconnected.
Table 5.1. Aspect Languages of RCDL. Service Description Language Application and middleware services are defined in SDL, also referred to as the service template, as shown in figure 5.17. Xelha specifications of service types are mapped to SDL descriptions. Within a service type, several services may be configured with each one having an associated QoS region, the task that supplies the required computational resources to provide the given level of QoS, and the (composite) object class that implements the service. The QoS region refers to the range of QoS values delineated by the minimum and maximum QoS levels offered by a service. At run-time, service types are represented as operations in a services library. The join points for this aspect language are the invocation of such operations. Hence, the activation of a join point results in the selection of the most suitable service according to the requested level of QoS.
117
Service Template: Def service type AudioCommService: Def service AudioComm_V1: user_qos: “high” qos_region: delay: 100, 120 throughput: 32, 64 jitter: -10, +10 packet_loss: 5, 8 task: transmitAudio_V1 object: AudioConnector_V1 Def service AudioComm_V2: . . . Def service type VideoCommService: . . . . . .
Figure 5.17. Example of SDL Descriptions As an example of a service type consider the definition of the service type AudioCommService as depicted in figure 5.17. The service AudioComm_V1 is defined within this service type. The user-level of QoS for the service is defined. The specification of the QoS region then includes the minimum and maximum values for the main multimedia QoS categories. The service AudioComm_V1 offers an end-to-end delay between 100 and 120 ms. The minimum supported throughput is 32 Kbits/seg whereas the maximum throughput offered is 64 Kbits/seg. The service allows a jitter between –10 and +10 ms. Lastly, the minimum and maximum percentage of packet loss supported by the service is 5% and 8% respectively. The specification of the service defines then the task transmitAudio_V1 is associated with the service. Finally, the service is implemented by the class AudioConnector_V1. It is worth mentioning that the QoS annotations defined in this section are not restricted to these QoS categories and may be extended to other domains. Task Switch Description Language The TSDL, also referred to as the object template, maps object operations to tasks as shown in figure 5.18. For this purpose, exported operations defined in Xelha are mapped to exported methods in TSDL. Similarly, imported methods in TSDL are derived from Xelha’s definitions. In addition, when two object interfaces are bound, imported methods must match the name and parameters of their related exported methods. Importantly, only exported operations may have associated tasks. Hence, task switches may only be
118
performed by server objects. The definition of task switching points offers enough expressiveness for defining the interconnection of different tasks. In addition, exported methods may be associated with multiple task switching points. To achieve this, an exported method is associated with a list of tasks. A task is selected from this list according to the current running task. For that purpose, “if” statements are introduced within the definition of an exported method in an object template as shown in figure 5.18. For instance, task f is selected if task g is the current running task that invokes the method z. The join points for this aspect language concern the invocation of object methods that are task switching points. The activation of a join point results in the selection of the appropriate task to be run.
ObjectTemplate o: Interface p: operation y: task t operation z: task f if task g task u if task v . . . Interface q: . . . . . .
Figure 5.18. Example of TSDL Descriptions It is worth mentioning that an object may be related to several tasks and that there are two cases where this may happen. The first case is when an object is shared in different object configurations. As an example consider a task graph of a video stream connection va which includes a filter object bound to a compressor object and these objects are part of task ty and tz respectively. Similarly, there is another video stream connection vb that uses the same instances for both the filter and the compressor, although they are associated with ti and tk respectively. Thus, the compressor will switch to task tz if the filter was executed as part of task ty, otherwise it will switch to task tk, as shown in figure 5.19. Task switching may be achieved by defining “if” statements. In the second case, each of the methods of an object may be associated with a different task. For instance, consider a stub object with the marshal and unmarshal methods. These methods may be associated with different tasks since they are concerned with different activities, namely sending messages and receiving messages. 119
tasks sharing same path segment
Multiple task switching point
ty
tasks sharing same path segment tz if ty tk if ti
ti
compressor
filter
Figure 5.19. Example of Object Configuration Associated with Two Tasks Task Description Language The specification of the tasks associated with a service is defined by the TDL, also called the task template. Each of these tasks is related to a VTM in the task template. There is a different TDL specification for each address space in which the associated VTMs are defined. It should be noted that the scheduling policy of the VTMs is defined within this template as shown in figure 5.20. Furthermore, a task template specifies the associated tasks, the abstract resources with their related management policies, and the importance of each VTM. A high importance value is assigned to critical tasks whereas lower importance values are assigned to tasks where contention does not have a drastic impact in the system. In addition, sub-tasks inherit importance values from their supertasks. There is also a default VTM that includes all those activities that are not represented in the resource model. That is, such activities would use the resources defined by the default VTM. The mapping of QoS values to resource parameter values may be achieved by mathematical translation or trial-and-error estimations as described in [Nahrstedt98]. As an example of the definition of abstract processing resources, consider the particular instantiation of the resource framework whereby VTMs encompass both a team and a buffer abstraction, as shown in figure 5.21. The scheduling parameters of the VTM are defined which include execution time, period and CPU usage. The team abstraction is then specified in terms of a particular number of threads. Furthermore, the definition of threads include their scheduling policy along with their thread priority. The amount of buffer allocated is also defined together with its management policy. It should be noted,
120
however, that the language is not restricted to these types of resources or the abstraction levels and can be extended to cover a different instantiation of the resource framework.
Task Template: Def VTMs: policy: scheduling policy VTM h: Task: task l Abstract resources: description of abst. resources of this vtm Importance: m VTM i: . . . . . . Default VTM: Abstract resources: description of abst. resources of this vtm Importance: n Shared Resources j: Abstract resources: description of the shared abst. resources Vtms: list of vtms sharing these resources Shared Resources k: . . .
Figure 5.20. Definitions in TDL A resource of any type may be shared between two or more VTMs as long as they live in the same address space. Allocation of shared resources is defined within the task template as shown in figure 5.20. In particular, the shared resources clause specifies both a list of the shared abstract resources and a list of the VTMs sharing these resources. This approach is useful in cases where, for performance reasons, it is necessary for tasks to share resources but still have certain resources allocated only to them. An example of such a case is a protocol stack in which each layer corresponds to a different task, as shown in figure 5.22. In this stack, each layer has a memory buffer allocated for its own use. However, it uses the same thread along the stack to avoid thread switches in order to achieve a good performance of the system.
121
Abstract resources: Def VTM: execTime: 20 period: 120 usage: 20 Def Team: num_threads: 5 Def Thread: policy: round_robin priority: 2 Def Buffer: policy: buddy_system amount: 2000 . . . . . .
Figure 5.21. Example of the Specification of Abstract Resources. Finally, the join points for this aspect language are related to the execution of the VTM that supports the execution of a task. More concretely, these join points are the invocation of task switching points. The access to a join point causes the activation of the appropriate VTM in order to support the resource demands of the task. taska
bufferw
taskb
bufferx
taskc
buffery
taskd
bufferz
request Media Access
Figure 5.22. Example of a Protocol Stack Sharing CPU Resources Resource Description Language The RDL, also called the resource template, describes the platform-dependent resource requirements for the execution of a task instance as shown in figure 5.23. Whereas the TDL defines the resources provided for the execution of a task, the RDL
122
defines the platform specific requirements for the execution of one or more object methods. Thus, a resource template concerns the specification of aspects such as the worst-case-execution time, typical execution time, execution period, amount of memory buffer and network resources. The join point for this aspect language is the invocation of a service type. Hence, the activation of a join point brings in information about the resource requirements of a task instance for the purposes of performing the admission control test and reservation of resources. Thus, whenever a service is required, an admission test is performed on the basis of the resource requirements specified by the RDL. If successful, such resources are then reserved. As an example of RDL descriptions, consider the specification of the resource requirements
for
the
execution
of
an
instance
of
the
task
transmitAudio_V1.unmarshall as depicted in figure 5.23. This task demands 10 ms of CPU time in the worse case whereas the normal operation of the task requires only 5 ms. The task also requires to be executed every 120 ms and demands 200 KB of memory for the purposes of buffering (again, the specification of resource requirements is not restricted to these two types of resources, thus, other type of resources may be included such as network bandwidth, storage resources and battery life). Resources Template: Task transmitAudio_V1.unmarshall: CPU: worse case time: 10 typical time: 5 Period: 120 Buffer: 200 . . . . . .
Figure 5.23. Example of RDL Descriptions QoS Management Graph Description Language The QMGDL is responsible for defining the QoS management structure of the system. Hence, Xelha definitions of dynamic QoS management are mapped to QMGDL descriptions. As in Xelha, monitors and strategy selectors are represented by an automaton. The strategy activator is then represented as an object. In addition, event
123
collectors are represented as object methods in charge of observing the behaviour of the object. These operations are accessed through a particular interface of the object. As shown in figure 5.24, QoS management graphs are defined either on a per service type basis or on a per service basis. The former represent a broader case in which all services within a service type follow the same pattern for the QoS management graph. In contrast, the latter represents a more specialised case whereby the QoS management structure of a service follows a different pattern from the other services defined in the service type. For instance, the QoS management of the service Audio_Comm_V3 whose service type is AudioCommService is separately defined, as shown in figure 5.24.
QoS management graph Template: Def QoS graph for AudioCommService: interfaces: If AudioComm_V1: AutomatonIN: automaton, IN_V1 If AudioComm_V2: AutomatonIN: automaton, IN_V2 CodecCOLL: codec, COLLECT CodecCtrl: codec, CTRL . . . edges: ( codecCOLL, automatonIN ) . . . Def QoS graph for AudioComm_v3: interfaces: . . . edges: . . . Def QoS graph for VideoCommService: . . .
Figure 5.24. Example of QMGDL Descriptions. Similar to Xelha, QoS management graphs are represented in terms of the interfaces to be bound and the edges. However, definition of these graphs for a service type involve the use of “if” statements in the interface section. The “if” statements are used to distinguish between the different services provided by a service type. Hence, a particular input interface is selected for both the automaton and the activator according to a specific service. For instance, in the case of the service AudioComm_V1, an interface of the interface array IN_V1 belonging to the object automaton is obtained. Different interfaces are defined for each service within a service type for the automaton to be able to determine the associated service of a given event received.
124
Finally, the join points for this aspect language are the invocation of the constructor of the class that implements a service. The activation of a join point then results in the instantiation of the associated QoS management graph. Hence, the automaton and activator are connected to the appropriate object interfaces of the service.
5.4 Summary This section has presented the engineering methodologies for the dynamic resource management of distributed multimedia applications. More concretely, Xelha was introduced as an ADL for the high-level description of component configurations together with their associated QoS properties. Both static and dynamic QoS management is feasible within the language. The former is represented in terms of task graphs with associated QoS annotations whereas the latter is modelled by management components. Although the language is mainly focused on distributed multimedia applications, Xelha is not restricted to this area and may be extended to cover other areas. In addition, RCDL was presented as a set of aspect languages for the lower-level description of resource configurations. These languages allow for the definition of service types which typically includes more than one service associated with the supported level of QoS, the related task and the object class that implements the service. In addition, the resources of tasks as well as resources of task instances can be defined. Moreover, task switching points may be defined in terms of object methods. Finally, the QoS management graph of the system is defined on per service type basis. The next chapter presents the implementation details of the resource framework, and also comments on a processing tool in charge of both interpreting Xelha specifications and weaving the different aspect languages of the RCDL.
125
Chapter 6 System Prototyping 6.1 Introduction In order to perform an evaluation of the resource framework a prototype was developed. The system prototyping consists of two parts. Firstly, a prototype of the resource framework was developed as an extension of OOPP [Andersen00a; Andersen00b], a Python implementation of the OpenORB. The resource framework prototype includes various levels of abstraction for resources, factories and managers. Some supporting mechanisms are also provided. Examples of these mechanisms are admission control tests and resource reservation services. Secondly, a tool for the interpretation of both Xelha specifications and RCDL definitions was constructed. This tool is in charge of converting Xelha specifications into definitions in the aspect languages of RCDL. The tool is also responsible for weaving the aspect languages and performing load-time resource configuration. The structure of this chapter is as follows. Section 6.2 presents an overview of the general approach for the implementation. Some background on underlying technologies is provided in section 6.3. The implementation details are then presented in section 6.4. Finally, a summary of the chapter is presented in section 6.5.
6.2 Overall Approach A prototype of the resource framework has been implemented in Python [Lutz96; van Rossun01], which is an ideal language for rapid prototyping. Similar to Java, Python modules are translated into byte-code to speed up the interpretation process. Moreover, since Python can easily be extended with C programs, Python’s applications can dramatically improve their performance by programming the most critical modules in C. In addition, the resource framework’s prototype was integrated into OOPP, as shown in figure 6.1. Hence, the OOPP has effectively been extended with resource management
126
capabilities. Importantly, the OOPP has been provided with support for both inspection and reconfiguration of resources. In addition, the OOPP prototype was extended to provide a point-to-point audio communication service. The service can be requested with a particular QoS specification. Resources are reserved according to the QoS level requirements. Adaptation mechanisms are also supported in case unexpected changes are introduced into the environment. These mechanisms involve the introduction of different compression strategies and the repartition of CPU in the system. The Python interpreter was then layered on top of GOPI [Coulson98; Coulson99] which is a micro-ORB implemented in C that offers support for distributed multimedia applications. In particular, we make use of the thread and memory management features offered by GOPI. A two-level scheduling model was implemented whereby the top-level is in charge of allocating a portion of the CPU to VTMs. Finally, the system was deployed on a cluster of ULTRA 5 Sun SPARC stations running Solaris 2.8. An overview of the technologies used is provided in the next section. Application OpenORB
Resource Framework
Python Interpreter GOPI Sun SPARC/Solaris 2.8
Figure 6.1. Implementation of the Resource Framework
6.3 Background on Technologies Used 6.3.1 Overview This section presents an overview of the technologies used in the prototyping of the system. More specifically, the main features of the OOPP are revisited. A general overview of the main characteristics of GOPI are also presented. Finally, the
127
implementation of an audio application called QoSMonAuTA [Gancedo99] is presented. QoSMonAuTA, which was previously developed by a Master’s student, has been extended with a QoS management structure for the support of resource management. 6.3.2 OOPP The OpenORB Python prototype (OOPP) [Andersen00a] is a flexible and adaptable middleware platform. The OOPP provides a number of programming structures that are in conformance with the design principles of the OperORB architecture. Hence, objects within this ORB may have several interfaces. A set of exported and imported methods are provided by the interfaces. The former are object methods that are made available through the interface whereas the latter are external methods that can be accessed through the interface. Three different styles of interfaces are supported, namely operational interfaces, stream interfaces and signal interfaces. In addition, a local binding represents the connection between two interfaces residing in the same address space. The exported methods of an interface are connected to the imported methods of the adjacent interface and vice versa, as a result of binding two interfaces. The run-time system supports some consistency check for the bindings. Hence, an error is raised in case the set of names of the interfaces to be bound do not match. The operation Component() is a wrapping mechanism for objects which are termed components after being wrapped. The mechanism allows us to associate the interfaces of an object with keys (names). The purpose of this is to allow the programmer to browse the interfaces of an object. Moreover, the interfaces of an object may be accessed even without any knowledge about the object. Interestingly, facilities are provided for creating composite objects from object-graph definitions. These graphs may represent complex object configurations. In addition, these graphs, which are represented in Python dictionaries, can state how the internal object interfaces are interconnected. Importantly, binding objects are used for connecting interfaces residing in different address spaces. Binding objects are composite components that provide control over the
128
communication path. There are three types of object bindings which are in conformance with the supported interface styles: operational bindings, stream bindings and signal bindings. It is worth mentioning that stream bindings do not provide support for any sequencing or buffering. Instead, this simple service is intended be used as a basis for constructing more complex services. The ORB platform also provides a supporting environment which includes capsules and a naming service. Each address space is controlled by a capsule. A capsule is responsible of providing services for its local objects. Remote access to capsules can be obtained through capsule proxies which basically forward requests to the remote capsule. The services provided by a capsule include the creation of components, registration of components, deletion of components, creation of local bindings and invocation of the component operations. In addition, the name server allows for the registration and lookup of component interfaces. There is only one name server in the system which can be remotely accessed through name server proxies. Finally, the platform also provides partial support for the meta-models. The reflective facilities provided by the ORB are mostly focused on the first version of OpenORB [Blair98; Blair99b]. However, some support is provided for the architecture meta-model. In particular, this meta-model allows for the inspection of the object graph of a composite object. Objects within the graph can be replaced. Addition and removal of objects to the object-graph is also supported. Further details about OOPP can be found in [Andersen01]. 6.3.3 GOPI The general object platform infrastructure (GOPI) [Coulson99] is a C-language lowlevel platform which provides support for distributed multimedia applications. GOPI was implemented as a number of independent modules. •
The base module is a collection of low-level programming libraries which include routines for the use of lists, stacks and hash tables.
•
The thread module is a thread library which supports the creation of both user- and kernel-level threads. QoS parameters, such as 129
priority and deadline, can be assigned to user-level threads. In addition, user-defined scheduling policies can be specified. •
The message module provides support for both inter-thread communication and buffer management. The communication service is built on timed semaphores and intermediary channels that are used for sending and receiving messages. In addition, the buffer management system allows the programmer to allocate and de-allocate buffer memory from a pre-allocated pool of memory.
•
The communication module provides support for the construction of multi-level protocol architectures. More concretely, application specific protocols (ASPs) can be defined on top of the transport protocol. ASP stacking allows for the construction of new protocols on top of existing ASPs.
•
The bind module provides a binding framework with QoS negotiation
capabilities
for
connecting
Irefs,
which
are
communication endpoints.
Two modules are of particular interest for the implementation of the resource system prototype, namely the thread module and the message module. The former is used to obtain thread management support whereas the latter is used for the purposes of memory buffer management. More specifically, the thread module offers application scheduler contexts (ASCs) which define a two-level scheduling model whereby user-level threads run on top of kernel threads. Hence, the approach integrates the advantages provided by each thread model. An ASC is associated with a set of user-level threads, a set of kernel-level threads, a user-level scheduling policy and QoS specifications for each user-level thread. The execution of a set of user-level threads can run on top of one or more kernel threads and is governed by a user-defined scheduling policy. A fixed-priority and an EDF scheduler are currently supported. Interestingly, multiple ASCs can co-exist, each with their own semantics and scheduling policy. It is possible to dynamically change the QoS
130
of a running thread. Moreover, the scheduler of a thread may be changed with another by migrating threads between ASCs. On the other hand, the message module provides a buffer management service in which buffers are allocated from a pre-allocated pool of memory. Allocation and deallocation of memory is efficiently achieved by using a ‘buddy system’ allocation scheme [Knuth73]. This scheme manages power-of-two sized buffers. The benefit of such a memory pool is that the overhead imposed by frequent malloc() call is avoided. Therefore, GOPI provides low-level support for CPU and memory management. 6.3.4 QoSMonAuTA The QoS Monitoring and Adaptation using Timed Automata (QoSMonAuTA) prototype consists of an audio application with QoS monitoring and adaptation facilities developed on top of OOPP. However, the adaptation facilities, which have application semantics, are not presented since they were not used for the implementation of the communication service. The basic component configuration of QoSMonAuTA is shown in figure 6.2.
StreamCtrl Binding (operational)
AudioDev (Source)
AudioStream Binding (stream) AudioStreamIn
AudioStreamOut
Buffer
AudioDev (Sink)
Figure 6.2. Component Configuration of QoSMonAuTA QoSMonAuTA is basically an application which was implemented on Windows NT and consists of an audio source that sends audio packets to a remote audio sink. The component AudioDev provides access to the audio device. Hence, this component is able to open the device for reading or writing. Specific parameters may be set when opening a device. These parameters include the sample rate, number of channels and the precision. The latter indicates the number of bytes used for storing an audio sample. In addition, operations for reading and writing data are provided. Lastly, linear PCM [Fluckiger95] is the encoding format employed.
131
The component AudioStreamIn is in charge of marshalling packets. For this purpose, the Python pickle() function is used. This component is also responsible for assigning a sequence number to each packet and a sending a timestamp which is used for determining network delays. In addition, the component provides operations in order to start and stop the transmission of packets. These operations are accessed by the sink node through the operational binding StreamCtrl. The component AudioStreamOut is then responsible for unmarshalling packets. This component is also able to detect packet losses and notify them to a QoS monitoring mechanism (not shown). This component allows for the simulation of packet loss by featuring a packet dropper mechanism. The percentage of dropped packets can be specified using the Wichmann-Hill distribution [Gentle98]. Finally, the component Buffer is a composite component which includes the components AudioBuffer and Adaptor. The AudioBuffer receives the data and asks the Adaptor to calculate the average buffering delay (i.e. playout delay). The algorithm defined in [Ramjee94] is used for calculating this delay according with the sending and arrival timestamps. The audio samples are then placed in a buffer and are sorted according to the playout time. The buffer was implemented as a linked list in a Clanguage module (the reason for using C for the implementation of the buffer is concerned with performance reasons). In addition, a periodic thread is scheduled to send the audio data of the buffer to the component AudioDev.
6.4 Implementation 6.4.1 Overview This section presents the implementation details of both the resource framework and the tool support of the description languages. More specifically, the extensions made to the GOPI’s thread module are presented along with the Python’s API of GOPI’s facilities. A two-level scheduling model constructed on top of GOPI’s thread facilities is also described. The extensions performed to the OOPP are then presented. These extensions include modifications to operational bindings and stream bindings for the purposes of enabling resource management capabilities. An audio communication service
132
was also added to the ORB. In addition, the implementation of a particular instantiation of the resource framework is presented. Finally, some prototyping details of the tool for processing both ADL specifications and RCDL descriptions are described. 6.4.2 Extensions to GOPI and Python’s Interface of GOPI Extensions to GOPI A number of extensions were made to the thread module of GOPI in order to obtain support for the object implementation of preemptive threads at the Python level. The most important functions added to the GOPI’s thread module are depicted in table 6.1. The original operation thread_spawn() of the thread module in charge of creating threads
was
partitioned
into
the
operations
thread_Create()
and
thread_Start(). The purpose of this is to introduce the possibility of defining a thread at a certain time and then starting the execution of the thread at a later time. Interestingly, the operation thread_Suspend() allows the user to temporally stop the execution of a thread. This is achieved by defining the extra field state in the data structure of a thread. This field indicates the current state of a thread. The possible states include inactive, active and suspended. The former refers to the case in which a thread has been created but its execution has not been started. In contrast, an active state indicates that a thread has started its execution. On the other hand, a thread is set to a suspended state when the operation thread_Suspend() is invoked. Important to the process of suspending a thread is the fact that the Python interpreter yields the executing thread every 10 byte-code instructions (by default), thus giving the opportunity to other threads to run. As a result, a thread will last less than 10 instructions to be suspended in the worst case (i.e. when the executing thread suspends itself). Hence, when the Python interpreter performs a thread switch the thread library obtains the next thread with an active state from the ready queue. Therefore, suspended threads are not scheduled until they are activated by invoking the operation thread_Resume().
133
Operations added to the thread module Opertation
Description
thread_Create()
Create a thread.
thread_Start()
Start the execution of a thread.
thread_Suspend() Suspend the execution of a thread. thread_Resume()
Resume the execution of a suspended thread.
thread_Set_qos()
Set the scheduling parameters of a thread.
thread_Get_qos() Get the scheduling parameters of a thread.
Table 6.1. Operations Added to the GOPI’s Thread Module. In addition, the operation thread_Set_qos() sets the scheduling parameters of a thread. This operation involves a number of actions. The new parameters of the thread are set. The thread is then removed from the ready queue and inserted again into this queue in the appropriate priority list. That is, there is an array of thread lists sorted by priority whereby the first thread in the list with the highest priority is selected. If the thread is not in the ready queue, then the thread is removed from the queue of the interpreter’s lock and inserted into the ready queue according to its new parameters. Finally, the operation thread_Get_qos() retrieves the scheduling parameters of a thread. Modifications Introduced into the Python’s Interpreter There are a number of modifications that were introduced into the Python interpreter version 1.5.1. These modifications were needed to be able to make use of some of the capabilities provided by the thread library. In particular, the abilities for suspending a thread and changing their scheduling parameters need some support from the interpreter. It is important to note that the Python interpreter is not fully thread-safe. That is, there is a central thread lock that controls the execution of threads since there is not individual thread protection for Python objects. The central lock is released and reacquired either after a determined number of byte-code instructions or when I/O operations are performed.
134
In order to implement the operation thread_Set_qos() introduced above, the central
lock
has
to
be
accessed.
For
this
purpose,
the
operation
get_interpreter_lock(), which retrieves the interpreter’s central lock, is included. There are 3 circumstances that when happening together bring the interpreter to an inconsistent state: 1. Change the priority of the running thread to a lower priority. 2. A thread switch is provoked. 3. The thread that is switched out does not release the central lock Hence, in order to maintain the interpreter in a consistent state, every thread switch must also release the central lock. For instance, both acquiring and releasing a lock produces a thread switch. However, only in the first case the central lock is released according to the original Python distribution. As a consequence, deadlock problems may arise when a lock is released. That is, after a release operation on a lock, the running thread is switched out holding the central lock. Therefore, if this thread is either suspended or its priority is lowered, no thread would be able to run since the central lock will not be released. In order to tackle this situation, the release() function of the Python thread module (Modules/threadmodule.c) was modified to support the releasing of the central lock. The operation for importing a library using import (defined in Python/import.c) was also changed. The reason is that this operation also releases a lock without liberating the interpreter’s lock. It is worth mentioning that the two-level thread model of GOPI could not be fully integrated into the Python interpreter due to the fact the interpreter is not fully threadsafe. That is, since the time for scheduling kernel threads is not controlled by the interpreter, kernel threads may be switched without releasing the central lock, thus leading to inconsistency problems. In order to solve this situation, only one kernel thread is employed. Finally, the operation PySetInterval() was included (in the file Python/ pystate.c) in order to make sure that critical operations programmed in Python, such as
135
that performed by a thread dispatcher, are not interrupted. Thus, the operation PySetInterval() can be applied on the running thread for dynamically increasing the number of its remaining byte-code instructions for yielding. Extensions to Python Extensions to Python are easily made by defining new C modules and compiling them with the Python distribution. Three new modules were included, namely the module threadtype module, the module bpooltype and the module AuBuf. The module threadtype is an interface of the GOPI’s thread library. This module provides access to the thread facilities offered by GOPI. Similarly, the module bpooltype is an interface of the GOPI’s message library. The GOPI’s buffer management facilities are accessed through this module. Lastly, the module AuBuf (which is part of QoSMonAuTA) implements the linked list used for buffering packets. However, some modifications were introduced to this module in order to enable the use of GOPI’s buffer pools instead of employing the malloc() function. The most important operations provided by the module threadtype are shown in table 6.2. The first operation creates an object representing a thread. The remaining operations are applied on a particular thread object. Some of this operations have the same semantics as those of the GOPI’s thread library and are not explained further. The operation getid() returns the identification of a thread as defined by GOPI. Interestingly, the operation changeSched() allows the user to migrate a thread from one ASC to another. The effect of this operations can also be achieved by using the last two operations one after the other. The operation expel() expels a thread from its current ASC whereas the operation admit() includes the thread into another ASC.
136
Interface of the Module typethread Operation
Description
Thread()
Create an object representing a thread.
start()
Start the execution of the thread.
suspend()
Suspend the execution of the thread.
resume()
Resume the execution of the thread.
getid()
Get the identification of the thread.
setQoS
Set the scheduling parameters of the thread.
getQoS
Get the scheduling parameters of the thread.
changeSched() Change the ASC of the thread. expel()
Expel the thread from its ASC.
admit()
Include a thread into an ASC.
Table 6.2. Operations Provided by the Module typethread. The most important operations provided by the module bpooltype are shown in table 6.3. The operation Bpool() creates an object representing a memory buffer pool. Memory buffer may be allocated from the pool by invoking the operation allocate() on the object. This operation returns a Python object representing the allocated memory. In addition, memory allocated from the pool can be released by calling the operation free(). In this case the pool obtains the memory back and is able to use it for further allocations.
Interface of the Module bpooltype Operation Description Bpool()
Create an object representing a buffer pool.
allocate()
Allocate memory buffer.
free()
Release memory buffer.
Table 6.3. Operations Provided by the Module bpooltype. Finally, the operations offered by the module AuBuf are depicted in table 6.4. The operation AuBuf_enqueue() inserts an audio packet into the linked list. For this
137
purpose, memory buffers (represented as Python objects) are passed on. Two buffer elements are passed: one is for the data structure of the new element in the list and the other is for storing the data. The operation AuBuf_get() then allows the user to retrieve the first element in the list. This operation is also in charge of releasing the memory buffer no longer used by the retrieved element. For this purpose, the C module makes an embedded Python call in order to invoke the operation free() of the Python objects representing the buffer. Lastly, the operation AuBuf_delete() releases all the memory from the linked list structure. The embedded call of free() is also employed in this case. Interface of the Module AuBuf Operation
Description
AuBuf_enqueue() Insert an audio packet in the buffer. AuBuf_get()
Get an audio packet from the buffer.
AuBuf_delete()
Releases all the memory from the buffer.
Table 6.4. Operations Provided by the Module AuBuf. The Two-level Scheduling Model A two-level scheduling model for Python was implemented on top of GOPI’s thread library as part of the resource model. More precisely, the scheduling model is employed for the scheduling of VTMs. As mentioned in chapter 4, the VTM scheduler is responsible for scheduling the processing resources of the VTMs. For this purpose, the VTM scheduler manages the thread schedulers associated with such VTMs. The VTM scheduler uses a priority scheduling structure similar to [Nahrstedt98] and extends it to a two-level scheduling structure. The two-level scheduling model operates within the scope of an address space. However, this approach can also be applied on a machine-wide scope, as shown in [Nahrstedt98], to ensure the availability of a portion of the CPU in a multi-shared environment. The VTM scheduler runs at the highest possible fixed-priority as shown in figure 6.3. Thread schedulers are then located at the second level of scheduling with the second highest priority. In addition, active threads are placed at the third highest priority whereas a sentinel thread remains on a level below. This thread is 138
required by GOPI to make sure that there is always a thread to run. Finally, non-active threads are placed in a waiting list a level below the sentinel. The VTM scheduler wakes up periodically, every 5 ms, to dispatch the next thread scheduler by un-blocking its associated thread and then returns to sleep. The thread scheduler then removes the threads located at the third level and introduces them into the waiting list at the bottom level. Following this, the thread scheduler selects one or more threads from the waiting list and places them at the third level. Afterwards, the thread scheduler blocks itself and the active threads start executing. In our current implementation, the first level of scheduling supports both rate-monotonic [Liu73] and lottery scheduling [Waldspurger94] whereas the second scheduling level uses a round-robin policy [Tanenbaum92].
Scheduling Structure Priority Thread 0 1 2 3 4
VTM Scheduler Thread Scheduler Active Threads Sentinel Waiting Threads
Figure 6.3. Priority Scheduling Structure. The rate-monotonic policy is implemented by generating a dispatch table according to both the period and the execution time of a VTM. The dispatch table defines the order of execution of VTMs. Hence, this table, which was implemented as a Python list, contains a repeatable set of time slots whereby each slot corresponds to a slice of CPU time. As an example consider the scheduling requirements shown in figure 6.4 (a). Three VTMs are scheduled whose execution times are 5 ms. The VTM vtmx is scheduled every 10 ms whereas the other two VTMs are executed every 20 ms, as shown in figure 6.4 (a). The generated table is shown in figure 6.4 (b). Each slot within the table has a time slice of 5 ms, thus, the slot group is repeated every 20 ms.
139
Scheduling Parameters of VTMs
Dispatch Table
VTM
Period
Slot No VTM
vtmx
10 ms
5 ms
0
vtmx
vtmy
20 ms
5 ms
1
vtmy
vtmz
20 ms
5 ms
2
vtmx
3
vtmz
Execution time
(a) Scheduling parameters of the VTMs
(b) Generated Dispatch Table
Figure 6.4. Example of the Generation of a Dispatch Table. The lottery scheduling policy was implemented by assigning notional lottery tickets to VTMs according to their parameter of CPU percentage usage. For instance, a VTM with a portion of 20% of CPU may be assigned 20 nominal tickets numbered from 1 to 20. Another VTM with a CPU portion of 40 % would have tickets numbered from 21 to 60; and so on until a total amount of 100 tickets are assigned. A ‘lottery’ is hold at each scheduling point by generating a random number between 1 and 100. The VTM holding the winner ticket then obtains the right to execute until the next scheduling point. Lastly, the round-robin policy is implemented directly by the thread library of GOPI and is not further described. Importantly, our resource model allows for the dynamic reconfiguration of the CPU by either changing the scheduling parameters of the processing resources or by replacing the scheduling policy (at the moment these changes are only possible at the first level of scheduling). Hence, upon the occurrence of an unexpected event causing an extra demand of CPU for a certain task, the portion of CPU assigned to each task may be dynamically repartitioned (see chapter 7 for an example). Finally, the two-level scheduling model allows for the protection of the CPU resources associated with a task. That is, changes in the CPU load of a task does not have an effect on other tasks. Furthermore, dynamic CPU reconfiguration involving a certain number of tasks does not have an impact on other tasks which do not take part in this reconfiguration.
140
6.4.3 Extensions to OOPP Support for Interceptors The OOPP has been extended with a partial implementation of the interception metamodel. Interceptors are implemented as dynamically plugable objects that may be inserted in the communication path of an object binding on a per-interface basis. The interception meta-model is used to co-ordinate dynamic object interactions with the resources meta-model. That is, the message arrivals received by well-defined object methods are intercepted either to perform a task switch or to access a memory buffer. Thus, we have implemented two types of interceptors: task interceptors and buffer interceptors. The former are in charge of performing task switches as shown in figure 6.5 (a). More specifically, this kind of interceptor updates the new task by updating a tasks registry placed in the resources meta-model, and then performs a thread switch. The callee uses the same resources as the caller’s as long as both the callee and the caller belong to the same task. Otherwise, a task switch occurs and the callee uses the resources of its associated task instead. The task associated with the exported method is obtained by inspecting the task’s registry of the related interface. Therefore, the callee carries on executing the same thread when the current task is the same as the method’s task. Otherwise, the request will be attended by the thread pool defined within the VTM supporting the execution of the method’s task. Task interceptors are only defined in the callee’s interface. The reason for this is that task switches are only defined by exported methods as mentioned in chapter 4. On the other hand, buffer interceptors are in charge of gaining access to the memory buffer resources belonging to the current task (inspected in the task registry). More concretely, the actions performed by buffer interceptors involve receiving audio packets, obtaining a memory buffer from the buffer pool associated with the current task and placing the packet in the buffer structure as shown in figure 6.5 (b). Moreover, a periodic thread is responsible for flushing the buffer structure. In contrast to task interceptors, buffer interceptors are only defined by imported methods. The reason for this is that the interception points for buffering are the operations that forward audio packets to the
141
audio device, i.e. these methods are bound to exported methods of the audio device’s interface. Finally, both types of interceptors are placed at object creation-time according to the TSDL descriptions. This is described in more detail in section 6.4.5.
2
1
1
If same task
AudioDev (Sink)
...
...
2 Obtain memory
2 If different task
vtmx
3 Insert packet
3
Resources meta-model
vtmy
Buffer structure
4 Flush buffer
Resources meta-model
(b) Buffer Interceptor
(a) Task Interceptor
Figure 6.5. Interceptors. Modification to Programming Structures Some modifications were introduced to the programming structures of OOPP. More concretely, local bindings and binding objects were changed. We first discuss local bindings. An interface is implemented as two objects called interface reference and interface object respectively as shown in figure 6.6. The interface of an object is accessed by invoking the former. When two object interfaces are connected, the interface reference is bound to the interface object of the adjacent interface as shown in figure 6.6. As a result, forwarding methods are created in the interface reference which represent imported methods. Thus, the invocation of an imported method forwards the request to the corresponding exported method of the adjacent interface. This exported method in turn forwards the message to its associated object. However, in our modified version there is only one forwarding method (called receive()) representing all the exported methods of an interface as shown in figure 6.6. This method forwards a request to an interceptor in case there is one defined, otherwise the request is forwarded to the object. In the former case, the interceptor performs some additional behaviour and then forwards
142
the request to the object. The interceptor is implemented as an object and is an attribute of the interface object. interceptor
Logical Model
y
x j
Implementation
k
interface reference imported: methoda() methodb() . . .
x
interface reference
old version
imported: methodd() methode() . . .
interface object
interface object
receive()
receive()
exported: methodd() methode() . . .
exported: methoda() methodb() . . .
j
k
if not interceptor
y
if interceptor
interceptor
Figure 6.6. New Version for Local Bindings. In addition, the most important changes concerning binding objects, i.e. open bindings and stream bindings, include the following: -
Stubs, which are internal objects in charge of marshalling and unmarshalling, inherit from the class Object. The constructor of this class is responsible for both mapping object methods to tasks and populating the interceptor of an interface (see section 6.4.5).
-
The interfaces of the stubs are created according to the new scheme defined for local bindings.
-
The thread responsible for attending requests is obtained from the resources pool of the task associated with the binding. The former version simply spawns a new thread.
143
-
After receiving a request, the connection remains open. The former version opens and closes a connection for each request. This modification was only applied to operational bindings.
Other changes introduced involve a new version for the class Composite() in charge of creating composite objects. In the former version, the internal objects had to be created beforehand. The new version is more sophisticated in that it enables the class constructor to do this task. Audio Communication Service An audio communication service was integrated into the OOPP. This service basically allows the user to request and audio connection with an associated level of QoS. The service is able to establish a point-to-point communication between two different address spaces possibly located in distinct nodes. The internal configuration of the audio binding is presented in figure 6.7.
compressor
srcStub
sinkStub
decompressor
IN
OUT streamBinding
activatorBindig
COLLECT
activator
automaton
Figure 6.7. Internal Configuration of an Audio Binding. The QoSMonAuTA prototype was modified and extended to take advantage of this service. Only the stream binding and the stubs are preserved from the previous version. The implementation of the audio device component for reading and writing audio were ported from the Windows NT platform to Solaris. This component, however, is not part of the audio binding. Instead, it is created externally. The implementation of the buffer component was also ported to Solaris. In our case, this component is implemented as a buffer interceptor which is attached to the interface OUT of the audio binding if the corresponding switching point is defined in the TSDL program. The new configuration additionally includes a pair of codecs for compressing and decompressing audio packets. There is support for three different compression strategies,
144
namely GSM, LPC10 and MELP [Spanias94; Spanias00; Spanias01]. Table 6.5 provides a comparison of these algorithms [Spanias00] in terms of the transmission rate, the MOS (mean opinion score) and the complexity. The MOS [CCITT84] is a subjective speech assessment in which rates are based on a five-point rating scale. The higher the rate the better the quality of audio obtained. In addition, the complexity is measured in millions of instructions per second (MIPS). Comparison of Compression Algorithms Algorithm Bit Rate
MOS Complexity
(Kbits/sec)
(MIPS)
GSM
13
3.7
5
MELP
2.4
3.2
30
LPC10
2.4
2.3
7
Table 6.5. Comparison of Compression Algorithms. Both compression schemes LPC10 and MELP have a throughput requirement of 2.4 Kbit/sec whereas the GSM scheme demands of 13 Kbit/sec. However, the latter requires less CPU resources and provides the highest MOS. The MELP algorithm has by far the highest complexity but offers better speech quality than LPC10. Crucially, a QoS management structure is also implemented which is in charge of performing monitoring and adaptation. The automaton is in charge of monitoring QoS violations. More specifically, the automaton detects packet losses higher than 20 %. For this purpose, the number of losses within 1000 ms is accounted. Thus the maximum number of permissible losses is calculated as follows: MaximumLosses = (Tm/Ttx) * 0.20 where Tm is the monitoring period (i.e. 1000 ms) and Ttx is the transmission period of the source. Upon detecting a QoS violation of this kind, the automaton selects an adaptation strategy which is realised by the activator. There is only one activator and automaton per address space which are shared by all audio bindings created. The activator is connected to both the coder and the decoder. For the former, an operational binding is used to establish the connection whereas for the latter a local binding is employed. The selected 145
adaptation strategy enforces the codecs to switch from GSM to the MELP algorithm as the latter provides a higher compression rate. In case there are not enough processing resources to cover the demands of the new compression scheme, a CPU reconfiguration is performed. Another adaptation strategy is defined in case the automaton is informed that not enough CPU resources are available for introducing new audio bindings. In case of using MELP, the strategy replaces it with LPC10, otherwise no reconfiguration for the codecs is performed. The latter policy requires less CPU resources, hence, some spare resources are gained. Afterwards, if not enough resources are obtained, a CPU reconfiguration follows. More details about these two adaptation strategies are presented in the next chapter. The service can be invoked as follows: audio_binding(sourceInterf, sinkInterf, qos_spec)
where the first two parameters are the interface of the audio source and the interface of the audio sink respectively. The last parameter defines the desired level of QoS. The current implementation allows the programmer to provide this parameter as a string (e.g. ‘high’ or ‘medium’) that maps to a specific QoS level. Such a mapping is defined in the SDL. The service audio_binding represents a service type which may encompass more than one service, as explained in chapter 5. Finally, new services within this service type can be defined or the existent ones can be configured without changing the code of the OOPP. This is achieved by using the SDL and its associated tool. 6.4.4 The Resource Framework A particular Instantiation of the Resource Framework A particular instantiation of the resource framework has been implemented which supports the representation of resources, resource factories and resource managers at different levels of abstraction. Regarding resources, the prototype basically models both CPU and memory buffer resources, as shown in figure 6.8. Thus, the prototype provides VTM abstractions which encompass team and buffer abstractions. In addition, a team may include several thread abstractions.
146
Common
Machine
AbstractResource
Job
Thread
2..* Team
1..*
VTM
1
1
Buffer
Figure 6.8. UML Class Diagram of Resources. Similarly, top-level resource factories are VTM factories which are in charge of creating top level resources. Team factories and buffer factories are lower-level factories that support VTM factories. In addition, the creation of teams is supported by thread factories. Figure 6.9 shows the UML diagram of the classes that implement these abstractions. Common
AbstResrcFactory
JobFactory
ThreadFactory
1
1
TeamFactory
1
1
VTMFactory
1
1
BufferFactory
Figure 6.9. UML Class Diagram of Factories.
147
Lastly, with regard to resource managers, VTM managers are supported at the toplevel management structure. Lower-level managers then include memory buffer managers and team schedulers. In addition, team schedulers are supported by thread schedulers. The team scheduler supports basic operations exposed by the class Scheduler. In addition, the thread schedulers support the round-robin policy. Furthermore, VTM schedulers support rate-monotonic and lottery scheduling, as shown in figure 6.10. This is in accordance with the two-level scheduling model presented in section 6.4.2.
Common
Manager
MemoryMgr
Scheduler
RoundRobinSched
1 TeamSched
RateMonotSched
1
LoterySched
1
1 ThreadSched
VTMSched
1..*
Figure 6.10. UML Class Diagram of Managers. Implementation of the QoS Management Support The middleware platform provides a QoS manager in charge of attending service requests. Upon the request of a service type with associated QoS specifications, the QoS manager inspects the services record to select the service that best matches the required
148
level of QoS. There then follows an admission control test phase in which the QoS manager identifies whether there are enough resources to provide the required level of QoS. For this purpose, the list of specific and platform-dependent computational resource requirements is obtained from the resources record. Example of such resource requirements includes amount of memory buffer and percentage of CPU. In the case of a distributed service, both the local and the remote resource records are involved. A resource server proxy that resides in the remote capsule is used in order for the QoS manager to communicate with remote resource managers. The interface of the resource server essentially exposes operations that delegate the actions for inspection, reservation and reconfiguration of resources to the appropriate entities (i.e. managers, abstract resources and resource factories). The resource managers associated with the service’s task are then asked for the availability of resources. These managers involve memory managers and thread schedulers. Managers are in charge of performing admission control tests. Regarding CPU resources, the admission test for the first level of scheduling when using rate-monotonic is as follows:
∑
n
i =1
Ci / Ti ≤ 1 [Liu73]
where n is the number of thread schedulers controlled by the VTM scheduler, Ci is the execution time given to the thread scheduler i and Ti is the period of the thread scheduler i. We only consider the special case where all periods are harmonic, i.e. each period is an even multiple of every period of smaller duration. Similarly, the admission test for the second level of scheduling is:
∑
m k =1
Ak / Bk ≤ Ci / Ti and Bk = Ti
where m is the number of threads controlled by the thread scheduler i, Ak is the execution time given to the thread k, Bk is the period of the thread k, and Ci and Ti are defined as in the previous formula. In the case of using lottery scheduling, the first level of scheduling applies the following admission test, which is the general form of CPU loading:
∑
n
i =1
Pi ≤ 100
149
where n is the number of thread schedulers controlled by the VTM scheduler and Pi is the percentage of CPU assigned to the thread scheduler i. Similarly, the admission test for the second scheduling level is:
∑
m k =1
Dk ≤ Pi
where m is the number of threads controlled by the thread scheduler i, Dk is the percentage of CPU assigned to the thread k and Pi is the portion of CPU assigned to the thread scheduler i. In addition, the admission control test for memory buffer request is:
∑
N i =1
buffersizei ≤ g
where g is the total amount of memory buffer, N is the total number of buffer requests and buffersizei is the required amount of buffer for the request i. Finally, if successful, the required resources are reserved by the corresponding managers. Following this the class that implements the required service is instantiated, i.e. an instance of the service’s task is created. Otherwise, the request is turned down and a re-negotiation phase may follow consisting of the negotiation of a reduced level of QoS. This re-negotiation protocol is not implemented by the resource framework; rather, this protocol concerns a higher-level aspect of the system that may be built upon such a framework. 6.4.5 The ADL Tool Overview We have implemented a tool in Python that interprets both Xelha specifications and RCDL definitions. The interpretation process of the tool has basically two phases as shown in figure 6.11.
150
Server implementation code
Predefined object classes
Object classes Captures resource model
RCDL specifications Service description language (SDL)
Functional requirements
Component Config. defs.
Static QoS Mgnt. defs.
Task defs. Non-functional requirements
ADL Tool Phase 1
Dynamic QoS Mgnt. defs.
Captures task model
Allocation of Pools of resources
Task description language (TDL)
Xelha specifications
Resource translation conforms with charact. platform of deployment
Resource description language (RDL) Task Switch description language (TSDL)
ADL Tool Phase 2
Python Interpreter
Method call interception “hooks” Component configuration instantiation
QoS mgnt. graph desc. lang. (QMGDL)
Figure 6.11. Processing Xelha Specifications. The first phase concerns the intrepretation of Xelha specifications. As a result of this interpretation process, RCDL descriptions are generated which involve various aspect programs. The second phase is then concerned with the processing of RCDL definitions and the instantiation of the resource framework. Phase 1: Processing Xelha Specifications The first phase is in charge of parsing Xelha specifications and generating both object classes in Python and lower-level descriptions of the configuration of resources in RCDL. For the generation of Python classes, both components and connectors are mapped to object classes. An example of such a class is shown in figure 6.12. Regarding the generation of RCDL descriptions, at present there is only support for the generation of TSDL programs and partial support for the generation of SDL definitions.
151
# File generated by the Tool import import import import import
lbind opbind composite component streambind
class AudioConnector_V1(composite.Composite): def __init__(self,lcap,rcap): interfaces = {’IN:("srcStub","IN"),’OUT:("sinkStub","OUT")} componentGraphSpec = { ’comps’:{ ’sinkStub’:{’factory’:component.componentFactory, ’args’:([’IN’,’CTRL’,’OUT’],SinkStub_V1_0), ’capsule’: lcap}, ’srcStub’:{’factory’:component.componentFactory, ’args’:([’IN’,’CTRL’,’OUT’],SrcStub_V1_0), ’capsule’: rcap}, ’streamConn’:{’factory’:StreamConnector_V1_0,’args’:([rcap, lcap, ’IN’,lbind.IRef(None,["put"],[]), ’CTRL1’,lbind.IRef(None,["start_serving"],[]), ’OUT’,lbind.IRef(None,[],["put"])} }, ’ifaces’:{ "OUT":("srcStub","OUT"), "streamConnIN":("streamConn","IN"), "streamConnOUT":("streamConn","OUT"), "IN":("sinkStub","IN") }, ’edges’:[ ("OUT","streamConnIN"), ("streamConnOUT","IN") ] } composite.Composite.__init__(self,interfaces,componentGraphSpec)
Figure 6.12. Generated Object Class for the AudioConnector_V1 Component Type. TSDL descriptions specify task switching points in terms of the object class, the interface and the method. The latter is associated with a task or with an “if” statement in case of a multiple task switching point. An example of a TSDL program generated by the tool is depicted in figure 6.13. Within a SDL description, component services offering QoS are represented as service type definitions in terms of the user level of QoS, the supported QoS region, the associated task and the object class that implements the service. Information about QoS regions is not provided by the tool, however, the programmer can manually define such regions. An example of a SDL program generated by the tool is shown in figure 6.14. TDL and RDL descriptions are currently hand-coded (type checking and automatic QoS specifications translation concern future work). It is important to mention that the generation of Python classes define how the objects that implement a service are interconnected. This configuration includes the QoS management structure that provides the adaptive behaviour of the system. Thus, at present no support is offered for the generation of QMGDL descriptions which define such management structure.
152
# File generated by the Tool Object Template SrcStub_V1_0: Interface CTRL: start: transmitAudio_V1_0.send.forward Object Template OpBinding_V1_0: Interface CTRL1: start_serving: transmitAudio_V1_0.send.ctrl Object Template AudioBinding_V1_0: Interface OUT: start: transmitAudio_V1_0.receive write: transmitAudio_V1_0.receive Object Template StreamBinding_V1_0: Interface CTRL1: start_serving: transmitAudio_V1_0.receive
Figure 6.13. TSDL Descriptions Generated by the Tool. The TA tool suite described in [BlairL99; BlairL00] can be used to model the timed automaton for the elaboration of the QoS management structures. This tool converts automaton graphs into FC2 files [Madelaine94]. Notably, the tool also supports the composition of TA. Therefore, the monitor and the strategy selector are defined separately and later on joined together in a single automaton. Afterwards, the automaton is translated into an FC2 file and an FC2 processor tool [Andersen00a] translates this file into Python object classes. # File generated by the Tool Service Template: Def service type AudioCommService: Def service AudioCommService_V1: user_qos: “high” qos_region: task: transmitAudio_V1 object: AudioBinding_V1 Def service AudioCommService_V2: qos_region: task: transmitAudio_V2 object: AudioBinding_V2
Figure 6.14. SDL Descriptions Generated by the Tool.
153
Phase 2: Processing RDCL definitions The second phase concerns the processing of RCDL descriptions, which takes place at load-time. As a result of this interpretation process the three hierarchies of the resource model are instantiated. The instantiation of such hierarchies involve two important issues. Firstly, the pools of resources (i.e. VTMs) for the specified services are allocated as a result of weaving the TDL program. The weaving process is performed at load-time and also involves the creation of a registry of the mapping between tasks and VTMs. This information is essential for the join point of this aspect language to select the VTM supporting the execution of its associated task. Secondly, both task interceptors and buffer interceptors are placed in the object configuration. This is performed as a consequence of weaving the TSDL aspect program. In addition, a registry of the mapping between object methods and tasks is created. The weaving of this language is carried out at run-time. More precisely, the weaving is performed at object creation-time. For this purpose, objects within the system inherit from the Object class. Every time an object is created, the constructor of the Object class asks the VTM factory, by invoking the method mapTasks()of the factory, to map tasks to the object that is being created. The mapping is accomplished on a per method basis and is placed in a registry located in the interface meta-space related to the object method. The purpose of this record is to provide a means of accessing the resources (i.e.VTMs) a method is related to. The method mapTasks() is also responsible for the creation of interceptors as an attribute of the object’s interface. In case of an exported method a task interceptor is defined. For an imported method, in contrast, a buffer interceptor is created. At present no support is provided for weaving the rest of the aspect languages. Hence, the join points for both the SDL and the RDL are manually coded. However, the information provided by these languages is processed by the tool. That is, interpretation of the RDL program populates a registry of the resource requirements demanded by task instances. This registry is placed in the resources meta-model. The information provided by the registry is used for collecting resource demands of a service when performing admission control tests.
154
Finally, the processing of SDL definitions generates a registry of the supported services. This registry provides information about the level of QoS, the task and the object class that are associated with a service. This record is inspected by the QoS manager to select the service that best matches the required level of QoS when a service type is requested. As a result, an instance of the class that implements the service is created if its associated VTM has enough resources to support this level of QoS. It is worth mentioning that all the registries mentioned above are implemented as Python dictionaries.
6.5 Summary This chapter has presented the implementation of the system’s prototype. The prototype was developed on top of available technologies. In particular, GOPI was used in order to obtain some low-level support for both thread scheduling and buffer management. In addition, the resource management system’s prototype was integrated into the OOPP. QoSMonAuTA was then used for the implementation of an audio communication service. Some extensions and modifications were introduced to all these technologies in order to accommodate a particular instantiation of the resource framework. Implementation details of a tool for the processing of both Xelha specifications and RCDL definitions were also presented. This tool basically translates Xelha specifications into definitions expressed in the various aspect languages of RCDL. Some tool support is provided for the weaving of the aspect programs. The next chapter contains the evaluation of this research. For this purpose, a quantitative and a qualitative analysis of the resource framework are presented.
155
Chapter 7 Evaluation 7.1 Introduction The work presented in this thesis covers a resource framework for the dynamic resource reconfiguration in multimedia middleware platforms. In addition, the work includes two languages for the engineering of such platforms, namely Xelha and RCDL. This chapter is concerned with an overall evaluation of the work. The methods used for the evaluation encompass both a quantitative and a qualitative analysis. The former regards an evaluation of performance-related characteristics of the Python prototype. More specifically, an analysis of the processing times and the overhead imposed by the system is presented. The latter then refers to an evaluation of the abstract architectural aspects of the system. This analysis is carried out in respect to the well-defined set of system requirements introduced in chapters 2 and 3. The structure of the chapter is as follows. Section 7.2 includes a performance analysis of the framework’s prototype. In addition, a case study is presented for the quantitative evaluation of the facilities for CPU reconfiguration. In section 7.3, a qualitative evaluation of the resource framework is carried out, which is followed by an evaluation of both the Xelha and the RCDL languages. Finally, a summary of the chapter is presented in section 7.4.
7.2 Quantitative Evaluation 7.2.1 Overview This section presents a quantitative evaluation of the system’s prototype. The overhead introduced by the resource framework is discussed, with particular emphasis on the performance penalty incurred for both inspecting and reconfiguring CPU resources. Some experiments are also carried out to determine the time required to perform a task
156
switch and the overhead imposed by the two-level scheduling model. This is then followed by presenting an evaluation of the time required for creating VTMs. In addition, a case study is introduced whereby three different scenarios are analysed. The main purpose of the case study is to determine the feasibility of the Python prototype for performing dynamic reconfiguration of CPU resources. Note that, the experiments were carried out on two networked Ultra 5 SUN SPARC stations running Solaris 2.5.8 and we employed our extended version of Python 1.5.1. 7.2.2 Evaluation of the Prototype’s Overhead Introspection The first experimental results regarding the prototype’s overhead concern the time taken to inspect the lower-level resources of a VTM. The lower-level of a local VTM is inspected as shown in figure 7.1 (a). As a result, both the team and buffer of the VTM are obtained. A deeper level of inspection then retrieves the threads included in the team. In contrast, the lower-levels of a remote VTM are obtained by accessing the proxy of the remote capsule’s resource server as depicted in figure 7.1 (b). Identifiers of the lowerlevel resources are then obtained.
team = vtm.getLL()[’TEAM’] buffer = vtm.getLL()[’BUFFER’] threads = team.getLL()
(a) Introspection of a Local VTM
proxy = resources.getProxy() dict = proxy.getLL(vtm_remote.get_id()) team_id = dict[’TEAM’] buffer_id = dict[’BUFFER’] threads_id = proxy.getLL(team_id)
(b) Introspection of a Remote VTM
Figure 7.1 Introspection of the Lower-Level Resources of a VTM The average time to do the local introspection is minimal compared to the average time required for remote introspection as shown in table 7.1. The reason the remote introspection takes much longer is that the implementation uses a Python dictionary with many entries to store the ids of the abstract resources residing in a capsule. Although this data structure allows the easy manipulation of data, the use of it is very expensive, especially when storing a considerable amount of data. The implementation of remote
157
introspection could clearly be optimised; however, it has not been the main goal of this research. Introspection Local
0.143 ms
Remote
262.190 ms
Table 7.1. Time Taken to Perform Introspection of the Lower-Level Resources of a VTM. CPU Reconfiguration Experiments were then carried out in order to calculate the time taken when a CPU reconfiguration takes place. In the case of using the rate-monotonic policy, the time required to create a new dispatch table varies according to a number of factors such as the amount of threads to be scheduled and the size of the generated table, as shown in table 7.2. CPU Reconfiguration for Rate-Monotonic Number of Threads
First Test Second Test Third Test
2 3 3
Number of Entries of Generated table 2 16 20
Unit of Execution (ms)
10 5 1
Periods (ms)
Execution Times (ms)
Time taken to create table (ms)
20 80 4,5,10
10 5,10,20 1,2,3
4.117 6.758 10.097
Table 7.2. Times Taken to Generate the Dispatch Table when Using RateMonotonic Policy The lowest time obtained corresponds to the generation of a table of two entries for two threads. The value of the unit of execution (i.e. the time the scheduler gives a thread in each turn) is 10 ms. In addition, both threads obtain 10 ms of CPU in a period of 20 ms. The second test has an increase in the number of entries for the generated table. This fact is reflected in the time taken to create the table. Finally, the third test involves three threads whereby each thread has a different period of execution: 4 ms, 5 ms and 10 ms. The corresponding execution times of these threads are 1 ms, 2 ms and 3 ms. The results show that the highest time is registered by this experiment by generating a table with 20 entries. This time is more than twice the time registered by the first test. The reason for 158
such an increase is that the implementation of the computation of the dispatch table makes use of various Python lists which impose a penalty on the performance of the system. CPU Reconfiguration for Lottery Scheduling
0.702
Time (ms)
Table 7.3. Average Time to Perform CPU Reconfiguration for Lottery Scheduling In contrast, the average time required for repartitioning the CPU when using lottery scheduling is minimal compared to the above, as shown in table 7.3. This is due to the fact that no dispatch table is generated in this case. Instead, the next thread to run is dynamically scheduled. Therefore, the time taken for the CPU reconfiguration only involves changing the setting of the new percentage of CPU allocated to each thread belonging to the second level of scheduling. The Two-Level Scheduling Model Further experiments were carried out in order to obtain the overhead imposed by the two-level scheduling model. In the first level of scheduling two different scheduling policies may be used, namely lottery scheduling and rate-monotonic. In the former, the next thread to run is dynamically scheduled as said before. The time required for this increases according to the number of threads that are scheduled as shown in table 7.4. Lottery Scheduling No Time (ms) Threads 5
0.573
Second Test
10
0.610
Third Test
20
0.828
First test
Table 7.4. Time Taken by the First Scheduling level when Using the Lottery Scheduling
159
In contrast, less time is required by a rate-monotonic scheduler as shown in table 7.5. The reason is that since no time is required to compute the schedule, only a few actions are performed by this scheduler which include obtaining the next thread from the dispatch table, unblocking this thread and going to sleep. Rate-Monotonic Time (ms)
0.156
Table 7.5. Time Taken by the First Scheduling level when Using RateMonotonic The second level of scheduling is only concerned with the round-robin policy. The time taken to schedule a thread (from a group of 5 threads) at the second level is shown in table 7.6. The experiments show that a greater overhead is imposed by this scheduling level compared to the first scheduling level with a rate-monotonic policy. The reason is that the execution of the former involves more expensive actions: the last executed threads are unscheduled by setting their priority to 4, the threads belonging to the next task are scheduled by changing their priority to 2 and the scheduler is blocked. It is worth mentioning that the overhead imposed varies according to the size of the thread group, that is, the bigger the group the more performance penalty is obtained. Round-Robin Time (ms) 1.502
Table 7.6. Time Taken by the Second Scheduling level when Using Round Robin As a result, the overall overhead imposed by the two-level scheduling model varies according to both the number of tasks, in case lottery scheduling is used at the first level, and the size of teams. From the particular measures obtained, the total overhead can vary from 1.6 ms up to 2.3 ms in case of using the rate-monotonic policy and lottery scheduling respectively.
160
Interceptors Experiments were performed in order to obtain the average times to execute both task interceptors and buffer interceptors. The overhead imposed for carrying out a task switch when a task interceptor executes, is shown in table 7.7. The performance of a task may be severely affected in the case that several switches are executed by its subtasks. As a result, the number of task switches should be maintained as low as possible. On the other hand, buffer interceptors, which have access to the buffer memory resources of the current task, have a lower performance penalty as shown in table 7.7. There is of course less danger of obtaining too much overhead from buffer interceptors since these interceptors are less likely to be used. That is, buffer interceptors are most commonly used at one end point of a communication service. Interceptors Type
Time (ms)
Task
1.110
Buffer 0.653 Table 7.7. Overhead imposed by task interceptors and buffer interceptors Creation of VTMs Experiments were carried out to determine the time taken in order to create VTMs. Some preliminary experiments included tests that measured the time taken to create both buffer and team abstractions, as shown in table 7.8. Teams are basically abstractions representing groups of threads. Creation of Abstract Resources Resource Abstraction Resource Amount Creation Time (sec) Buffer
200 KB
0.516
Team
7 Threads
4.327
VTM
Buffer+Team
4.842
Table 7.8. Time Taken to Create a VTM
161
The results obtained showed that the time taken to create a team varies depending on the number of threads the team will include. Further tests were then carried out the obtain the total amount of time required for creating VTMs, as depicted in table 7.8. The experimental results show that the required time to create a VTM is basically the addition of the time taken for both the creation of the buffer and the creation of a team. In general terms, the creation of teams and as consequence the creation of VTMs is very expensive and due to a number of factors. Abstract resources are registered when created in a Python dictionary. The key values in the dictionary are obtained from a string representation of an abstract resource. For this purpose, the Python function repr() is used which provides a string representation of an object value. The reason for the performance penalty is then that this function is particularly inefficient when creating representations of thread objects. However, VTMs are usually created at start up time, hence, not affecting the performance of the run-time system. Again, although the performance penalty could be diminished, this has not been the principal aim of the research. 7.2.3 Evaluation of the Facilities for Dynamic CPU Reconfiguration Scenario 1 This scenario considers a system running three audio connections between capsule 1 and capsule 2 as shown in figure 7.2. Two audio connections are sharing the task transmitAu_V1
whereas
only
one
connection
is
participating
in
task
transmitAu_V2. The internal configuration of each connection includes an audio compressor and a stub in the source side whereas the counterpart involves a stub and a decompressor as shown in figure 7.3. Both stubs are connected by a stream connector. Three compression schemes are supported by both the compressor and the decompressor, namely GSM, MELP and LPC10. In addition, the bindings include a QoS management structure which involves both an automaton component and an activator component. The former is in charge of monitoring packet losses. On the occurrence of a QoS violation, it is also responsible for deciding which strategy to apply. Such strategy is then realised by the activator component. We use a simplified version of the timed automata notation, which is defined in [Andersen01], for the specification of the automaton as shown in
162
figure 7.4. The edges define transitions between the states of the automaton. The automaton starts at the initial state which is represented with two circles. A transition may be triggered by either a state having a guard with a false value or an input signal. The former are denoted with test operators whereas the latter are indicated with a question mark. Edges can also have associated guards and are selected in case of a true value. Output signals, denoted with an exclamation mark, can be generated by edges. Assignment operations can also be applied by edges. Further explanation of the automaton is introduced below. Task path Task starting point Task end point transmitAu_V1 Audio Binding 1 source1
sink1
transmitAu_V1 Audio Binding 2 source2
sink2
transmitAu_V2 Audio Binding 3
Capsule 1
source3
sink3
Capsule 2
Figure 7.2. Scenario 1 The initial resource configuration is defined by the TDL specifications shown in figure 7.5. These specifications define a pool of threads for tasks transmitAu_V1 and transmitAu_V2. The TDL definitions of capsule 1 determines an execution of 10 ms every 120 ms for both tasks transmitAU_V1.send and transmitAU_V2.send, as shown in figure 7.5 (a). In addition, the task default has allocated 10 ms in a period of 20 ms. In contrast, the TDL definitions of capsule 2 prescribe the same portion of CPU for all tasks which is equivalent to 10 ms out of 40 ms, as depicted in figure 7.5 (b). The VTM scheduler uses the rate-monotonic policy by default. The unit of execution provided by the scheduler is 5 ms, however, this setting may be dynamically modified. In addition, the usage parameter indicates the required percentage of CPU and is only used when the VTM scheduler applies the lottery scheduling policy.
163
Task path Task starting point
Task end point
transmitAu
srcStub
compressor
sinkStub
decompressor sink
source transmitAu.send
streamConn
COLLECT
activator
activatorConn
transmitAu.receive
automaton
Figure 7.3 Structure of a Binding Component
codec != MELP
0
S8 admission test!
S9
codec = MELP replace MELP with LPC10! modifyReserve_taskReplace!
S7 0
test passed? test failed?
new binding failed?
cpu reconfiguration!
0
0 S10
S0
S4
S1
S5
test failed?
c := 1, t := 0 0
0
t
