Designing Adaptive Middleware for Reuse Richard Staehli
Frank Eliassen
Sten Amundsen
Simula Research Laboratory P.O. Box 134 N-1325 Lysaker, Norway
Simula Research Laboratory P.O. Box 134 N-1325 Lysaker, Norway
Simula Research Laboratory P.O. Box 134 N-1325 Lysaker, Norway
[email protected]
[email protected]
[email protected]
ABSTRACT Today’s software component technology does not support safe deployment of real-time and multimedia applications. We propose platform managed deployment configuration and dynamic adaptation to enable component middleware to exploit adaptive components. An example of a remote video binding shows how alternate configurations are compared using error prediction functions to select the best for the current deployment environment. Categories and Subject Descriptors: D.2.11 [SOFTWARE ENGINEERING]: Software Architectures; D.2.13 [ SOFTWARE ENGINEERING]: Reusable Software–[Reuse models]; D.4.7 [OPERATING SYSTEMS]: Organization and Design–[Distributed systems]; General Terms: Design. Keywords: QoS management adaptive reflective component middleware MDA.
1.
INTRODUCTION
Component middleware and adaptive middleware are both intended to increase software reuse. While an adaptive software implementation may be used in a wider range of conditions it is still often designed for a particular application or range of operating conditions. In contrast, the promise of component technology is that software implementing a standard interface type may be reused in any application requiring that type. Unfortunately, even a black box component with the correct type will perform unacceptably if its internal implementation assumptions do not match the deployment environment and application QoS requirements [9]. For example, the amount of compression in a digital video encoder depends on assumptions of the relative scarcity of processing CPU power versus network bandwidth. The value of reuse for avoiding the high cost of reengineering has been well documented for real-time and multimedia systems [18], yet today’s software component technology does not support such applications. Research has
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. RAM ’04, Tuesday October 19, 2004, Toronto, Ontario, Canada. Copyright 2004 ACM 1-58113-833-4/04/0010 ...$5.00.
shown many principled approaches to adaptation [14] [5], but we are not aware of component middleware that can discover adaptive software components and configure them where they are appropriate. If component middleware is to exploit adaptive components, one of the hard problems that must be solved is to maintain a separation between application requirements and environment dependent implementation decisions. Without this separation, an application can not be reused, i.e. deployed, in an environment where the implementation decisions are inappropriate. In this paper we propose platform managed deployment configuration and dynamic adaptation as a solution to the problem of separating application requirements from environment-dependent implementation decisions. Under this approach application components are specified by type, including QoS requirements for that component. Alternative component implementations and configuration alternatives that make assumptions of the deployment environment are packaged separately, to be discovered and configured as knowledge of the runtime environment and QoS requirements become available. The problem of discovering all possible implementations and configurations of a type, comparing the expected quality of each and returning the best for a given quality specification, is likely to be a difficult or even intractable problem for many common cases. Our proposed solution to this is that the middleware platform provides hooks where domain specific QoS management components can be attached. We refer to such components as implementation planners. This approach allows for integrating better QoS management algorithms as they are developed, supporting multiple specialized implementation planners, and invoking the appropriate planner algorithm in the appripriate context. A problem of software components, is that their QoS properties are generally not known without knowledge about the deployment environment. We propose a general solution to this problem by associating a function with each component alternative that can be used to predict QoS properties. These functions encode the developer‘s knowledge about the service provided by the component and how resource dependencies may influence its performance. With such an architecture, complex QoS-sensitive applications may be specified and reliably deployed over a wide range of platform configurations and environmental conditions. The above solutions have been developed as parts of the QuA component platform. The next section provides an overview of the QuA architecture concepts and terms used in this paper. In Section 3 we describe how QuA selects a dis-
tributed video player configuration based on QoS attributes estimated from the current deployment environment. Section 4 extends the example to suggest how QuA might configure the player to adapt dynamically to changes in network bandwidth. Section 5 discusses related work and Section 6 presents our conclusions and future work.
2.
QUA CONCEPTS AND TERMS
Our guiding vision in designing the QuA architecture is of a clean separation between logical and physical layers of programming. Application domain experts should specify logical properties, platform experts should provide the physical implementation components, and QoS experts should provide specialized platform services for domain-specific QoS management. This division of responsibility is a recurring theme in software development literature [12]. The value of this model of computing can be measured by reduced timeto-market and lower costs for production and maintenance of applications. QuA has been designed as a minimalist research component architecture with support for QoS-sensitive applications. The QuA architecture is a distributed platform consisting of a set of networked capsules. Each capsule provides a runtime environment for local core QuA objects and platform managed objects. The minimal QuA core enables it to be deployed on a wide range of computers. Default QuA core services include instantiation, inspection and reconfiguration of application and platform services. Reflection is realized through the QuAMOP interface, and is reachable from all objects and components in a capsule. The core services enable additional middleware system services (like remote protocols, transaction control and security) to be added for a particular installation. An application designer specifies which component types to include, how these components should be interconnected (bindings), and the required QoS. The QuA platform is responsible for locating and instantiating implementations of the specified QuA types, as well as for interconnecting them. A QuA type defines the service type name and the functional services in the form of operation signatures and semantic descriptions. QuA does not prescribe a particular service type definition language. The component model of QuA distinguishes between a blueprint and a component. We use the term blueprint for a persistent, immutable, value encoding how to implement a component type. We reserve the term component for the runtime objects manufactured from blueprints in compliance with a component standard. It is these components that are composed to realize application functionality. Pluggable platform services referred to as implementation planners are responsible for all implementation choices affecting QoS. This includes reasoning about which implementations conform to QoS requirements, and how end-to-end QoS depends on the composition of sub-service QoS. Fundamental to our approach of QoS-driven component selection is the notion of an implementation plan. An implementation plan is a data structure associating functional and extra-functional properties (i.e. service type and QoS) with an implementation (i.e. blueprints). The plan contains the information neccessary to manufacture or otherwise provide the implementation. A developer may create alternative implementation plans for a service type, where each implementation may have different QoS-properties and re-
source dependencies. Implementation planning becomes recursive when a plan has resource dependencies. For each dependency an implementation planner must evaluate alternative subplans for the dependency service type. The subplans represent alternative configurations of the service instance. This allows existing implementation planners to discover and use new technology. Implementation plans are published using a broker service provided by the QuA platform. As shown in Figure 1, the instantiate QuAMOP operation is used to acquire a service by QuA type and quality requirements. QuA invokes the implementation planner associated with the current client thread to find an implementation plan. The implementation planner uses the QuA broker to discover alternate implementation plans for a type and selects a suitable plan based on quality. QuA then executes the plan and returns the QuA name1 of the instance. find plan instantiate( type, quality ) Client
QuAMOP
instanceName
ImplementationPlanner
execute
Plan
instantiate/identify Component or Composition
Figure 1: Instantiation by type and quality specification. We define a composition to be a set of components enabled to communicate. A composition is specified by describing the components that participate, and the bindings between them. A QuA binding is a capability held by one object to send messages to another. The QuA operation bind creates a capability like any other service in QuA, by specifying its type and quality in a QuA instantiate operation. When binding to a remote object, the capability is a local proxy that encapsulates the remote communication. A plan contains an error prediction function to predict QoS properties of an implementation as a function of both design tradeoffs and subplan QoS. For example, computation delay is a function of both algorithm tradeoffs between speed and memory use and of the subplan for which CPU to use. Error is a loss of quality compared to ideal service behavior, where the ideal service behavior is that obtained when a service executes completely and correctly on an infinitely fast platform with unlimited resources. An error prediction is an array of real numbers corresponding to the quality-loss dimensions of an error model [15]. The quality argument to a QuA instantiate request specifies a utility function [15]. The implementation planner uses this utility function to compare the predicted error of alternative implementations and to find the implementation with highest utility. QuA does not mandate any particular set of error models, but instead permits any number of error models to be defined for different domains. The same implementation plan may be advertised with multiple error models, so that reuse is not restricted to one QoS-modeling domain. 1
A QuA name is similar to a URL.
3.
DEPLOYMENT CONFIGURATION
In this section we use a video streaming system to show how the QuA platform discovers alternative application configurations and selects the best configuration for the current deployment environment. The system is intended for mobile users with laptops and personal digital assistants (PDA) (see Figure 2). The QuA middleware platform is installed on the terminals and the server. The video server is located on the Internet, and the terminals are connected to either a local area network (LAN) or a wireless LAN (WLAN). Videos are stored in MPEG-2 format, but may be transcoded to the H.263 format. The H.263 encoding is designed for transport over low-bandwidth networks, while MPEG-2 format preserves the quality of the stored video, but requires more network bandwidth.
WLAN Internet LAN
Video streaming server
Figure 2: Heterogeneous application deployment environment. The application is composed of three component types: an MPEGSource, an RGBDisplay, and a VideoBinding to connect the source to the display. The MPEGSource and the RGBDisplay are implemented by existing local components on the server and client machines respectively, so the implementation of the VideoBinding must be distributed over both. In this example, the application is deployed in a WLAN environment where available bandwidth is only a tenth of that required for the full MPEG stream. The application initialization code calls the QuAMOP instantiate operation, specifying the VideoBinding type and quality requirements. The quality specification includes both an assumption of input properties derived from the VideoSource and a utility function [15] as described at the end of this section. The instantiate operation invokes an implementation planner to discover and select from alternative implementations for the VideoBinding. It finds the two plans illustrated in Figure 3. The first is composed of a NetPipe that transports data across the network and writes to a buffer. On the client machine, an MPEG decoder reads from the buffer and writes to the display. In the second configuration, a transcoder converts from MPEG to H.263 encoding and writes to a NetPipe. On the client, an H263 decoder reads from the buffer and writes to the display. The decoders in both plans are active, i.e. they read frame data from the buffer only when it is time to display it and discard frame data that arrive too late. Each component type in the two alternative plans for the VideoBinding may itself have alternative implementation plans provided by independent developers through the QuA implementation broker. For each implementation plan, a useful prediction of error in the timing and value of the component outputs may be predicted from properties of the component input messages, design properties and error estimates for sub components.
MPEG-H263
NetPipe
Buffer
MPEGDecoder
NetPipe
Buffer
H263Decoder
A
B
means A calls B
Figure 3: Alternative VideoBinding configurations.
Table 1 shows the notation we use for specifying error prediction functions. While video systems experts are concerned with many error dimensions, to keep this example simple, we choose to model only three for the VideoBinding service type: delay, frame period, and image noise. The ideal implementation of the VideoBinding decodes the encoded MPEG video with no delay and no loss. This means that if the MPEG stream is input to the VideoBinding at the correct rate, it should be displayed at the correct rate. To simplify the presentation, we ignore inter-frame dependencies in the MPEG encoding. VideoBinding V input properties error model NetPipe N input properties error model Buffer B error model MPEGDecoder M D configuration error model MPEG-H263 M H configuration error model H263Decoder HD configuration error model WLAN W input properties configuration error model
period pi , size si , resolution ri delay d, period p, noise n bandwidth bwi delay d, loss probability l write delay dw , read delay dr schedule delay sc delay d period pc , size sc , resolution rc delay d schedule delay sc delay d bandwidth bwi capacity cc , meas. latency tc delay d, loss probability l
Table 1: Error prediction variables. For the VideoBinding error model, we define delay as the median value of the time between frame data input and decoded frame output, frame period as the median time between output frames, and image noise as the median difference between actual and ideal RGB values divided by the RGB value range. For image noise, the median is computed over every pixel in every output frame assuming a normative 640x480 pixel video image. Ideally, delay would be zero, the frame period would be equal to the input frame period and image noise would be zero. We define error models for the the alternative VideoBinding implementation component types in a similar way. The ideal service behavior for the NetPipe is to output the same frame data as input, without delay. For this service, we model only delay and loss probability, where delay is the median time between frame data input and output, and loss
probability is the fraction of input frames that were not output. The ideal service for the Buffer is to respond to frame data write and read requests in a first in first out (FIFO) manner, without loss or delay. Since we do not anticipate lossy behavior in this component, the error model consists of only write delay and read delay. The MPEGDecoder is a periodic task whose schedule is configured to allow some jitter in the NetPipe, reading frame data from the buffer only after the expected arrival time. The ideal behavior for this type then is to read frame data on schedule from the buffer and to decode and output the result without loss or delay. The configuration of the MPEGDecoder schedule contributes to end-to-end delay in the video binding, but the choice of this delay value is a tradeoff made when configuring the component. The error model for the MPEGDecoder consists only of delay, defined as the median time to decode a frame. The H263Decoder is configured with a periodic schedule and has an error model identical to that for the MPEGDecoder. The MPEG-H263 transcoder may be configured with a frame period (reciprocal of frame rate) and resolution (pixels per image) for the transcoded video output. The ideal service for this type is to convert frame data to an H263 encoding with the configured frame period, size and resolution, and with minimal loss of information and no delay. Since we anticipate minimal loss of information, the error model consists only of delay, defined as the median time to transcode a frame. 0
1 0 1 V.d M D.sc + B.dr + M D.d @ V.p A = @ A V.pi /(1 − N.l) V.n 0
(1)
For this example, we define the error prediction function for the MPEGDecoder plan as shown in Equation 1. In this equation, the schedule delay M D.sc of the MPEGDecoder masks jitter in the NetPipe output. The frame period V.p equals the input frame period plus the increase due to frames lost in the NetPipe. The image noise V.n is zero, since the decoder is expected to accurately decode all frame data received. It is important to note that this error prediction function need not be accurate to provide a useful comparison with other implementations. 0
1 0 1 V.d HD.sc + B.dr + HD.d @ V.p A = @ A M H.pc /(1 − N.l) V.n (V.ri − M H.rc )/16V.ri
(2)
The error prediction function for the H263Decoder plan is shown in Equation 2. It is similar to that for the MPEGDecoder except that the best case frame period is the configured frame period of the transcoder M H.pc and image noise is increased by lowering the configured resolution M H.r. To evaluate these error prediction functions, an implementation planner must know the input properties for the VideoBinding, and the component configurations and error predictions. The VideoBinding input properties shown in Table 2 derive from the video source and are communicated in the instantiate request. The component configuration is discovered through recursive service planning and the component error predictions come from evaluating the error prediction functions asso-
ciated with the resulting plans. The recursion ends either when a plan has no dependencies or when a service planner applies a heuristic to select a plan without full evaluation. We describe here only the most important case of recursive planning and error prediction for the NetPipe. From the values shown in Table 2, the input bandwidth for the NetPipe is V.si /V.pi or 1.2 M bytes/sec for the MPEG stream and M H.sc /M H.pc or 0.12 M bytes/sec for the H263 stream. Only one implementation plan is found for the NetPipe and this plan depends on a network link between server and client. Another recursive implementation planner invocation finds a single plan to use the WLAN for the network link. The error prediction function for the network link plan shown in Equation 3 depends on input bandwidth and on recent measurements of link latency W.tc and capacity W.cc from Table 2. When bandwidth exceeds capacity, the excess packets are all lost so the error prediction for the MPEG stream is W.d = 100 ms and W.l = 0.9. For the H263 stream the error prediction is W.d = 100 ms and W.l = 0.1. The error prediction for the NetPipe is the same as that for its component WLAN link. „
W.d W.l
«
„ =
W.tc max(0.1, (W.bwi − W.cc )/W.bwi )
« (3)
V.pi = 33 ms V.si = 40 k bytes V.ri = 300 k pixels W.cc = 120 k bytes/sec W.tc = 100 ms N.d = 100 ms (MPEG) N.l = 0.9 (H263) N.l = 0.1 B.dw = B.dr = 1 ms M D.sc = 3 ∗ N.d M D.d = 50 ms M H.sc = 8 k bytes M H.pc = 66 ms M H.rc = 80 k pixels M H.d = 5 ms HD.sc = 3 ∗ N.d + M H.d HD.d = 10 ms Table 2: Error prediction inputs for low bandwidth network connection. Table 2 shows the values needed to evaluate the error prediction functions for the MPEG and H263 configurations in the WLAN environment. For the NetPipe component, both loss probability values from the recursive planning described above are shown. Given these values, the error prediction for the MPEG configuration from Equation 1 is V.d = 351ms, V.p = 330ms, and V.n = 0. The error prediction for the H263 configuration from Equation 2 is V.d = 316ms, V.p = 73ms, and V.n = 0.09. √ 2 2 2 utility = e− (V.d/1000ms) +(V.p/200ms) +(V.n/0.2)
(4)
Equation 4 shows the utility function from the VideoBinding instantiate request. This function treats the error vector as the position of the service in a QoS behavioral space, where each error dimension is normalized by an value corresponding to severe loss of utility. Utility is 1 if there is no
error and decays exponentially with increasing magnitude of the normalized error vector. For the MPEG configuration the utility computed is approximately 0.19 and for the H263 configuration it is 0.52. This computation allows the implementation planner to select the H263 configuration for this low-bandwidth network deployment.
maintain service continuity by planning the new configuration before suspending any part of the current implementation, while in other cases it may be more important to free resources of the old configuration before planning. By leaving this responsibility to the adaptation manager in an adaptive implementation, QuA can support many policies.
4.
5.
DYNAMIC ADAPTATION
One approach to dynamic adaptation in QuA is to encapsulate the adaptive behavior in a component framework. Figure 4 shows a framework derived from our collaboration with the FAMOUS project [8]. The VideoBinding configuration from the last section is shown as an example of the target for adaptation. A monitor detects threshold change events in resource availability and signals an adaptation manager. The adaptation manager is responsible for maintaining the state of the running service during reconfiguration and for invoking planning and reconfiguration actions. On the QuA platform, resource managers advertise resource availability through the QuA implementation broker and a monitor may discover changes in resource availability by polling the broker. An adaptation manager may invoke an implementation planner via the QuAMOP to select a better configuration plan for the current environment. The QuAMOP will also support structural reflection on a running service for reconfiguration [3]. monitor
MPEG-H263
adaptation manager adaptation target NetPipe Buffer
H263Decoder
Figure 4: An adaptive implementation of the VideoBinding. To illustrate this approach, assume that the monitor shown in Figure 4 is configured to signal the adaptation manager when available bandwidth in the network link doubles. When the client moves to an area with better WLAN bandwidth or competing traffic decreases to free more bandwidth, the adaptation manager is notified to reconfigure the VideoBinding. The adaptation manager advertises the current VideoBinding components via the QuA broker so that they may be reused in replanning. The adaptation manager then invokes the implementation planner to find a better configuration for the current environment. In this example, the result is a plan identical to the current configuration except that the MPEG-H263 transcoder is reconfigured to double its frame rate. The execution of this plan simply resets M H.pc to 33 ms. We chose this example to suggest that dynamic adaptation in QuA can be very lightweight. We believe the same approach can also result in plans that replace many or all of the components of an implementation. Hallsteinsen, et al. observe that a dynamic reconfiguration solution should be able to suspend the current configuration, snapshot the service state, release resources, plan and instantiate a new configuration, restore state from the snapshot, and resume. It appears that different applications may require different policies for the order of these actions. For example, in some cases it may be most important to
RELATED WORK
Commercial component middleware technologies like EJB [16] lack APIs for adding QoS-adaptation mechanisms. The OpenORB 2 [3] component architecture addresses this by introducing component frameworks (CF) as building blocks. Each CF has a set of policies and rules that may support adaptation. QuA adds QoS-specification and implementation planning as integral parts of a higher-level component middleware platform. Others are extending the EJB container with QoS support in the form of new container components and interfaces for QoS negotiation and adaptation [7]. Their approach involves adding network reservation to Java RMI. OpenORB employs reflection for run-time reconfiguring of CFs [6]. Meta-models of the underlying structure (at the base-level) are causally connected to components, i.e. changes to the meta-model causes corresponding changes at the base-level. One OpenORB implementation [1], introduces dynamic QoS-management components that adapt the application according to predefined strategies. These strategies are described in the formal language of timed automata and may be packaged in a component type. We believe QuA resource monitors may be implemented this way. DynamicTAO adds reflection to CORBA, allowing inspection and reconfiguration of the ORB [10]. There are hooks for strategies that the ORB uses to implement middleware services, and these may be replaced at run-time. To use the QoS-support in the ORB, the application must use the given APIs. Reflective middleware has also been applied to mobile computing, such as in CARISMA [4]. Policies coded in eXtensible Markup Language (XML) create an application profile, and different policies deliver different QoS and consume different amounts of system resources. When an application detects changes in the context it can, via reflection, add or change policies in its profile. In case of a conflict, the middleware performs a ”closed-bid” action. CARISMA, like other reflective middleware prototypes, requires application code to manage QoS. QuA, on the other hand, captures the QoS-properties of the implementation plans in the error prediction functions, enabling the platform to manage QoSdriven implementation planning. Schantz, et al., describe patterns for reuse of QoS management mechanisms in the QuO CORBA middleware, but say that integration with a component model is future work [14]. In [13] a QoS compiler is presented that translates userperceived QoS levels to a run-time ”script” corresponding to our implementation planning concept. It is assumed that application developers can provide a QoS-specification with knowledge of system-level QoS representations. This approach appears to yield an application that can only be deployed with the particular set of QoS-management services understood by the application developer. Another approach [17] addresses QoS-awareness by capturing non-functional properties in a QoS-model, specifying service compositions as task graphs. It selects services based on QoS criteria, and employs an adaptive execution engine that re-plans the com-
position of services. Their ontologies and implementations of local and global implementation planning using integer programming, are designed for Web-services. Hence, system resource management is merely assumed, while QuA uses this as the foundation for predicting and maintaining QoS. Kramp and Koster describe a technique for specifying protocol stack configurations that combine declarative and procedural aspects [11]. They propose blueprints that may contain alternative configurations similar to alternative plans in QuA. Also like QuA plans, the alternate configurations may be incomplete with declared dependence on subcomponent types. Black, et al., propose Infopipes as a component model for multimedia distribution and processing [2]. We use their NetPipe abstraction in Section 3. They identify component interface polarity (push versus pull), data transmission, transformation, and storage as distinguishing characteristics of Infopipe component types. Control interfaces are also defined that allow adaptive behavior in Infopipe compositions.
6.
[7]
[8]
[9]
[10]
CONCLUSIONS AND FUTURE WORK
We have described how the QuA architecture enables adaptive behavior to be packaged as reusable components. The main contribution is our composition model that specifies components by type and quality requirements; and our definition of error prediction functions that allow independently developed implementation plans to be brokered and compared by quality. The example of a video streaming application demonstrates how QuA implementation planning can adapt the configuration of an application to the environment at deployment time and to the dynamic system conditions at runtime. At the time of submission, we have prototyped the QuA platform in both Smalltalk and Java and have demonstrated service planning by type. Work on a demonstration of the use of error predictions as described in this paper is ongoing. We are also collaborating with the FAMOUS project to investigate context-aware adaptive component frameworks [8].
7.
[6]
[11]
[12]
[13]
[14]
REFERENCES
[1] Anders Andersen. OOPP: Reflective Middleware Platform including Quality of Service Management. PhD thesis, Department of Computer Science, University of Tromsø, February 2002. [2] Andrew P. Black, Jie Huang, Rainer Koster, Jonathan Walpole, and Calton Pu. Infopipes: an abstraction for multimedia streaming. Multimedia Syst., 8(5):406–419, 2002. [3] Gordon S. Blair, Geoff Coulson, Anders Andersen, Lynne Blair, Michael Clarke, Fabio Costa, Hector Duran-Limon, Tom Fitzpatrick, Lee Johnston, Rui Moreira, Nikos Parlavantzas, and Katia Saikoski. The design and implementation of Open ORB 2. IEEE DSOnline, 2(6), 2001. [4] L. Capra, W. Emmerich, and C. Mascolo. CARISMA: Context-aware reflective middleware system for mobile applications. IEEE Transactions on software engineering, 29(10):929–945, 2003. [5] Shanwei Cen, Calton Pu, Richard Staehli, Crispin Cowan, and Jonathan Walpole. Demonstrating the effect of software feedback on a distributed real-time
[15]
[16] [17]
[18]
MPEG video audio player. In Proceedings ACM Multimedia, pages 239–240, 1995. G. Coulson, G. S. Blair, M. Clarke, and N. Parlavantzas. The design of a configurable and reconfigurable middleware platform. ACM Distributed Computing Journal, 15(2):109–126, 2002. M.A. de Miguel, Jos F. Ruiz, and Marisol Garca-Valls. QoS-aware component frameworks. In Proceedings of the 10th International Workshop on Quality of Service - IWQoS 2002, pages 161–169. IEEE Communications Society, May 2002. Svein Hallsteinsen, Jacqueline Floch, and Erlend Stav. A middleware centric approach to building self adapting systems. submitted to Software Engineering and Middleware (SEM2004), September 2004. Gregor Kiczales. Beyond the black box: open implementation. IEEE Software, 13(1):8–11, January 1996. F. Kon, M. Roman, L. Ping, J. Mao, T. Yamane, L.C. Magalhaes, and R.H. Campbell. Monitoring, security, and dynamic configuration with the dynamicTAO reflective ORB. In Proc. Middleware 2000, pages 121–143, April 2002. T. Kramp and R. Koster. Descriptive-procedural configuration of communication bindings. In Proceedings of the International Conference on Multimedia and Expo (ICME). IEEE, August 2000. J. P. Loyall, R. E. Schantz, J. A. Zinky, and D. E. Bakken. Specifying and measuring quality of service in distributed object systems. In Proceedings of the First International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC ’98), pages 20–22, Kyoto, Japan, 1998. Klara Nahrstedt, Dongyan Xu, Duangdao Wichadakul, and Baochun Li. QoS-aware middleware for ubiquitous computing. IEEE Communications Magazine, 39(11):140–148, November 2001. R. Schantz, J. Loyall, M. Atighetchi, and P. Pal. Packaging quality of service control behaviors for reuse. In Proceedings of ISORC 2002, The 5th IEEE International Symposium on Object-Oriented Real-time distributed Computing, Washington, DC, 2002. Richard Staehli, Frank Eliassen, Jan Øyvind Aagedal, and Gordon Blair. Quality of service semantics for component-based systems. In Proc. 2nd Intl. Workshop on Reflective and Adaptive Middleware (located with ACM/IFIP/USENIX Middleware 2003), Rio De Janeiro, Brazil, 2003. Sun. Enterprise Java Beans (TM) Specification, version: 2.1, 2002. http://java.sun.com/products/ejb/. L. Zeng, B. Benatallah, A.H.H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang. QoS-aware middleware for web service composition. IEEE Transactions on software engineering, 30(5):311–327, 2004. J. A. Zinky, D. E. Bakken, and R. E. Schantz. Architectural support for quality of service for CORBA objects. Theory and Practice of Object Systems, 3, 1997.
