Nanbor Wang	Douglas C. Schmidt	Michael Kircher
Kirthika Parameswaran
Dept. of Computer Science Washington University One Brookings Drive St. Louis, MO 63130-4899	Dept. of Electrical and Computer Science University of California 616E Engineering Tower Irvine, CA 92697	Siemens ZT Munich Germany

Contents

1. Introduction
2. Applying Adaptive and Reflective Middleware System Techniques to
   Resolve Key Design Challenges for QoS-enabled CCM Implementations
3. Current Progress and Empirical Results
4. Related Work
5. Concluding Remarks
6. References

1. Introduction

1.1 Emerging trends and challenges:

An increasely popular way to develop DRE applications is to use the standard interfaces, protocols, and services defined by distributed object computing (DOC) middleware, such as CORBA [Obj00b] or Java RMI [WRW96]. DOC middleware is software that functionally bridges the gap between application programs and the lower-level OS/network/hardware platforms so that clients can invoke operations on remote objects without concern for where objects reside [HV98]. In addition, DOC middleware shields applications from dependencies upon non-portable details of the underlying platforms.

The stringent performance requirements of DRE applications require DOC middleware that provides efficient, predictable, and scalable QoS properties (such as memory and bandwidth management, concurrency, dependability, security, and power management [GKLS99]). DOC middleware based on the CORBA specification is becoming capable of providing the communication middleware for next-generation DRE applications. For instance, recent additions to CORBA, such as Real-time CORBA [SK99] and CORBA Messaging [Obj98], specify standard interfaces and policies for defining and controlling various types of application QoS properties.

Historically, however, the standard CORBA specification has not addressed object implementation or configuration issues effectively. For example, the CORBA 2.x [Obj00b] specification did not standardize interfaces that

• Initialize and deploy services dynamically -- Thus, system developers must use ad hoc strategies to initialize and deploy their implementations; or

• Enable different service implementations to interact portably via standard interfaces -- Thus, developers must interconnect objects explicitly, which makes it hard to evolve applications to support new requirements and run-time environments.

To address these problems, therefore, the OMG adopted the CORBA Component Model (CCM) specification [BEA99]. The CCM defines a framework for generating application servers that enable developers to readily configure custom component logic. In theory, the adoption of the CCM should significantly reduce the effort required to integrate portable components that implement services and applications. Moreover, the CCM should greatly simplify the reconfiguration and replacement of existing application services by standardizing interconnections among components and interfaces.

In practice, however, the CCM standard and implementations are as immature today as the underlying CORBA standard and ORBs were three to four years ago, before they improved. For instance, CCM implementations are not yet particularly efficient, predictable, or scalable. Moreover, commercial CCM vendors are focusing on the requirements of e-commerce, workflow, report generation, and other general-purpose business applications. The middleware requirements of these applications center on functionality and interoperability, however, with little emphasis on assurance of--or control over--QoS properties. As a result, it is not yet feasible to use commercial-off-the-shelf (COTS) CCM implementations for DRE applications that possess stringent QoS requirements.

1.2 Solution approach Adaptive and Reflective Middleware Systems (ARMS):

Our prior research on CORBA middleware has explored many aspects of ORB endsystem design for DRE systems, including static [SLM97] and dynamic [GLS98] scheduling, event processing [HLS97], I/O subsystem [KSL98] and pluggable protocols [OKSO99] integration, synchronous [SMFG98] and asynchronous [AOSK99] ORB Core architectures, systematic benchmarking of multiple ORBs [GS96], and optimization principle patterns for ORB performance [POSW98]. This paper focuses on another key dimension in the ORB endsystem design space: applying adaptive and reflective middleware system (ARMS) techniques to implement QoS-enabled versions of the CCM.

• Statically, e.g., to reduce footprint, leverage capabilities that exist in specific platforms, enable functional subsetting, and minimize hardware/software infrastructure dependencies; or

• Dynamically, e.g., in response to changes in environmental conditions or requirements, such as changing component interconnection topologies; component failure or degradation; changing power-levels; changing CPU demands; changing network bandwidth and latencies; and changing priority, security, and dependability needs.

Figure 1 illustrates the key architectural focal points where ARMS techniques can be applied to improve the configurability and adaptivity of QoS-enabled CCM implementations.

• Selecting optimal QoS-aware communication mechanisms: To present a consistent programming model for application developers, CORBA hides the location of object implementations from client applications. By examining an object's location reflectively, however, a CORBA ORB can select an optimal communication mechanism automatically when it binds an object reference [Hen98]. To avoid violating the CORBA object model, this selection must occur without direct application intervention so that middleware performance and predictability can be optimized transparently. In particular, robust and automated ORB collocation support [POSW98] is necessary since the CCM encourages complex and dynamically changeable component composition relationships [Szy99].

• Managing QoS properties of components in their containers: In the CCM, the implementation of a component in a component server is managed by a container, which provides a run-time environment that offers certain services, such as security, event notification, and transactional coordination. In addition, CCM containers can manage component implementation QoS properties, such as memory and bandwidth management, concurrency, dependability, security, and power management, to support automatic dynamic QoS configuration by inspecting and adjusting a component's QoS properties. Component developers can defer certain implementation decisions until run-time by factoring QoS adaptation policies and mechanisms into containers reflectively, thereby enhancing application flexibility and QoS.

• Dynamically (re)configuring selected parts of component implementations: Many next-generation applications will run in ad hoc wireless and mobile network configurations where there may be no a priori knowledge of (1) the appropriate implementation of service components or (2) the optimal partitioning of service components onto network nodes. Therefore, components must be linked/unlinked and (re)configured dynamically to avoid wasting DRE resources. The lifecycle for linking/unlinking these components can be optimized via ARMS techniques to minimize footprint, prolong battery life, maximize extensibility, and meet key application QoS requirements using information available only at run-time.

• Dynamically tailoring the degree of concurrency in component servers: A component server can host many component implementations. Thus, it is hard to predict a priori the most effective concurrency strategy a component should use. Pre-configuring rarely-used components with a high degree of concurrency can waste DRE system resources. Conversely, too little concurrency can impede component performance, particularly if the host server has the capacity to handle many requests simultaneously. Moreover, multiple components within a component server can interfere with each other or cause starvation of certain components. Fluctuation of incoming requests further complicates server configurations since ensuring a high degree of concurrency can consume many resources. Therefore, a component server should automatically adapt its degree of concurrency among components dynamically, depending on factors like component requirements and endsystem workload.

To enhance the support of non-functional aspects of CCM implementations[SW96], we are applying ARMS techniques by defining meta-object protocols (MOP)[Zim96] at the various middleware levels mentioned above, ranging from the ORB Core up to CCM services. Applying these ARMS techniques to CORBA middleware involves the following activities:

• Identifying the behaviors we want to isolate, such as the transport mechanisms an ORB supports, from the base-objects, which are objects that implement functionality that users interact with directly;
• Defining the MOPs that model the behaviors, such as creating an abstraction modeling the common behavior of transmitting GIOP messages;
• Creating meta-objects for the MOPs that implement various behaviors, such as meta-objects that implement different ORB transport protocols. Together, these meta-objects form a meta-region and provide different behavioral implementations to their base-objects through the same MOP; and
• Implementing a ``binding switch'' meta-object that identifies and binds one of the behavioral meta-objects with a base-object, such as a meta-object that selects an efficient transport mechanism.

The vehicle for our ARMS research is TAO [SLM97], which is an open-source, CORBA-compliant ORB designed to support DRE applications with stringent QoS requirements. Figure 1 illustrates how CORBA components, features, and services are being integrated into TAO ORB endsystems.

The remainder of this paper is organized as follows: Section 2 motivates key challenges faced when designing CCM implementations that support QoS-enabled DRE applications effectively and outlines the ARMS techniques we are applying to address these challenges; Section 3 describes empirical results from our CCM-related R&D efforts to date; Section 4 compares our approach with related work; and Section 5 presents concluding remarks.

2. Applying Adaptive and Reflective Middleware System Techniques to Resolve Key Design Challenges for QoS-enabled CCM Implementations

This section describes several key research challenges that CCM developers must address to support QoS-enabled DRE applications and outlines the ARMS techniques we are applying to address these challenges in TAO.

Challenge 1: Achieving QoS-enabled Location Transparency Adaptively

Context: Location transparency is an important feature of the CORBA programming model. It allows applications to invoke operations via well-defined interfaces without concern for where the actual target components reside. It also simplifies system (re)configurations since client programs can be shielded from component placement decisions.

Problem: A straightforward strategy for implementing location transparency is to treat all operations as remote invocations that are sent via IIOP over TCP/IP. This strategy imposes unnecessary communication overhead, however, when an object resides within the same host or the same address space as the client. Thus, high-quality ORBs must determine the actual location of a target object automatically to optimize performance, while simultaneously hiding these details from programmers to preserve CORBA's transparency semantics and simplify application development.

An ORB can optimize system performance by determining the location of target objects and then selecting the communication mechanism that can implement operation invocations most efficiently. For example, when invoking an operation on a target component located on the same host or in the same process, an ORB can choose a communication mechanism, such as shared memory or virtual method calls, that is more efficient than transferring the request through the TCP/IP loopback pseudo-device. These ``collocation optimizations'' are now implemented by most CORBA ORBs [WSV99].

It is important, however, that an ORB's collocation optimizations not conflict with the QoS mechanisms provided by the underlying ORB endsystem. For example, the Real-time CORBA specification defines the following two real-time ORB endsystem QoS mechanisms [Obj99a]:

• Prioritized scheduling, which ensures that real-time applications receive sufficient resources to meet their deadlines.

• Explicitly bound communication channels, which ensure the ORB endsystem's communication infrastructure allocates sufficient bandwidth, CPU, and memory resources to satisfy DRE application QoS requirements end-to-end.

Solution Dynamic selection of optimal QoS-aware communication mechanisms: To select an appropriate communication mechanism, an ORB must apply its optimizations adaptively and reflectively at run-time. To avoid violating the transparency of CORBA's object model, however, these optimizations should be invisible to ORB applications and must respect an application's QoS policies. A suitable solution must work for all the following phases of an object's lifecycle:

• Bind-time -- Although certain collocation optimization mechanisms (such as virtual method calls or shared memory) may be faster than other communication mechanisms (such as TCP loopback or message queuing), a QoS-enabled ORB must select a communication mechanism based on application QoS requirements. For example, to minimize priority inversion, a reflective QoS-enabled collocation optimization mechanism could establish multiple connections at bind-time to partition ORB communication between client and server threads with different QoS requirements.

• Rebind-time -- In CORBA, objects can migrate from one server to another server. When an object migration occurs, a client invoking an operation on the original server will receive a LOCATION_FORWARD exception that contains a new object reference. In this case, the client ORB must rebind to the new object reference. As with the original binding, the ORB should determine the appropriate communication mechanism reflectively, taking into account the QoS characteristics of the various clients and objects involved in the migration.

• Invocation-time -- Real-time CORBA provides two priority models: client propagated priority and server declared priority [SK99]. These models enable an object reference to be invoked with different priorities. Moreover, the QoS a connection can provide may fluctuate during its lifetime. Thus, to warrant the QoS associated with the object reference, an ORB may need to examine the status of an object reference and its active connection and switch to a different communication channel if necessary.

Applying reflective collocation mechanisms in TAO: Figure 2 illustrates how TAO is designed to support QoS-enabled collocation mechanisms reflectively. We separate the message passing mechanism into a meta-region, which contains meta-objects that implement different transport methods. The Collocation Policy Control meta-object serves as the binding switch that associates the appropriate message passing mechanism with the base-object.

For instance, connections and threads are often used to differentiate QoS requirement levels and execution priorities [Obj99a]. To minimize priority inversion, however, TAO supports non-multiplexed connections for client invocations that possess different QoS requirements [SMFG98]. By using reflection, therefore, TAO can decide to use a less efficient--but more predictable--collocation mechanism after examining the effective policies associated with an object reference.

Challenge 2: Changing Component QoS Properties Adaptively

Context: Next-generation applications require better QoS support from their middleware. In CORBA-based middleware, this QoS support is provided by ORB endsystems and the networks that interconnect them [SLM97]. For instance, the CORBA 2.4 specification [Obj00b] has integrated the Real-time CORBA [Obj99a] and CORBA Messaging [Obj98] specifications to standardize how applications interact with the QoS and real-time mechanisms provided by operating systems.

Problem: Even with the adoption of Real-time CORBA and CORBA Messaging, component developers today still program applications manually to utilize real-time and/or messaging capabilities of an ORB. Unfortunately, this manual process is tedious, error-prone, and often sub-optimal because application developers must handle end-to-end [SRC84] QoS properties explicitly.

Conventional ORB endsystem QoS mechanisms are hard to program in part because they cut across [Kicz97] many aspects of functionality provided by components. For example, a multimedia application running on a platform that supports zero-copy buffer optimizations [DPC97] must interact with many OS mechanisms to acquire/release buffers, control flow rate, pace the flow, and reserve CPU/network bandwidth. Moreover, programming these complex QoS properties manually can tightly couple components to particular OS QoS mechanisms [ZBS97], which can yield sub-optimal performance when application QoS requirements change or when applications switch to different QoS mechanisms on different OS platforms and networks.

Solution Reflective management of component QoS properties by their containers: The CCM defines a container programming model that manages component implementations in a host component server by encapsulating them within a run-time environment that provides certain services, such as security, event notification, and transactional coordination. A container forms its own meta-space that associates the base-object it manages with various meta-regions that constitute the run-time environment the container provides. QoS-enabled CCM implementations factor out QoS properties from their components into another meta-region that provides the QoS management facility to the managed component.

With the separation of QoS properties, containers then can weave various run-time properties, including QoS properties, the component implementation requires together through dynamic configuration and composition of containers. At run-time, CCM containers manage component implementation QoS properties to support automatic dynamic QoS configuration via inspecting and adjusting a component's QoS properties. In DRE systems, a higher-level of federated resource managers are required to ensure QoS properties are enforced end-to-end. These federated resource managers coordinate the containers, allowing them to negotiate with each other and configure their QoS settings.

CCM containers are ideal entities to manage component QoS policies for the following two reasons:

• POA policy integration -- The Portable Object Adapter (POA) is (1) the standard ORB mechanism that forwards client requests to concrete object implementations and (2) the key policy designator in the Real-time CORBA and CORBA Messaging specifications. Each CCM container uses a dedicated POA to coordinate the policies associated with the component it manages.

• Opportunistic component integration -- Since the CCM encourages composition of unrelated objects [Szy99], a container provides a central repository that allows these unrelated implementation objects to collaborate without explicit prior knowledge of their existence or QoS properties.

Applying container-based QoS adaptability in TAO: Figure 3 illustrates the design of TAO's CCM container model.

The CCM supports deployment-time configuration of components by using XML-based files to specify how a component should be installed. In this context, a component descriptor is an XML entity that describes the capabilities and configuration requirements of components. This deployment information can be extended to deploy components using containers with different QoS properties. For example, consider a logging service component that must forward large amounts of data to a central logging repository in a timely manner. With a container implementation that supports QoS adaptation, developers can deploy the original component within this container and specify the QoS requirements to enhance the component's timeliness.

By decoupling component implementations from the QoS configuration mechanisms defined by their containers, TAO allows general-purpose components to be reused with various QoS properties in different applications without modifying their implementations. Moreover, it is easier to monitor and control the dynamic behavior of an implementation with different QoS configurations. This separation of concerns enables federated containers to collaborate with each other to configure and adapt more readily to dynamically changing QoS requirements end-to-end.

The CCM container model can also be applied on the client-side to manage the run-time environment for object references. Similar to server-side containers, client-side containers can control non-functional object reference aspects, such as QoS property management, communication channel selection, to mediate global resource management, such as concurrency and memory usage management, and to adapt applications to QoS resource changes in conjunction with server-side containers. Client-side containers can be implemented as internal ORB smart proxies [WPS01] that load the configuration for the interface automatically and provide standard interfaces to interact with a resource management meta-object on the client-side ORB.

Challenge 3: Changing Component Behavior and Resource Usage Adaptively

Context: In the CCM specification, component implementations are called executors and are packaged into so-called assembly files that can be linked dynamically. Assembly files enable the installation of components on generic component servers. In the remainder of the paper we refer to assembly files as dynamic-linked libraries (DLLs), which are the OS-provided mechanisms underlying assembly files. A component server may contain a large number of components, some of which will be used frequently and others infrequently.

In general, developers of component-based applications do not know a priori the most effective strategies for (1) implementing components or (2) collocating/distributing multiple component executors into processes and hosts. If developers commit to a particular configuration of components prematurely, however, they can impede flexibility, reduce overall system performance and functionality, and increase resource utilization unnecessarily. For example, initial component configuration decisions may prove to be suboptimal over time, such as when platform upgrades or increased workloads require the redistribution of certain components to other processes and hosts.

To avoid premature commitment to suboptimal configurations, therefore, it may be necessary to defer component configuration or implementation decisions until late in an application's lifecycle. Moreover, it may be necessary to perform component updates online, i.e., without having to modify or shut down an application obtrusively. This ``live upgrade'' capability is particularly important for mission-critical applications, such as central office telecom switches or power-grid control systems, that possess high availability requirements.

Problem: Although the number of components configured into a component server can be large, not all installed components are necessarily used simultaneously. Care must be taken, therefore, when a container chooses its DLL linking/unlinking strategy since retaining unused DLLs in an application for extended periods or time consumes limited system resources, particularly memory. Conversely, linking and unlinking DLLs upon every method invocation not only degrades system performance, but can also consume other system resources, such as battery power in mobile devices.

Solution Reflective linking/unlinking of component executors: To address the problems mentioned above, component servers should manage the lifetimes of their executor DLLs reflectively. A meta-space can be used to separate the concern of dynamic linking. The mechanism that links/unlinks component implementations is therefore separated into a meta-region. Various meta-objects that implement different linking/unlinking strategies are provided in the meta-regions and binding switch meta-objects associate the appropriate linking/unlinking meta-objects with the the container, which is a base-object from the perspective of linking/unlinking meta-objects. A higher level meta-region then provides meta-objects that implement various different lifecycle management policies and a binding switch meta-object is used to determine the appropriate lifecycle management strategy. The following two patterns are used to define the MOP to perform linking and unlinking of component executors:

• Component Configurator: This pattern decouples the implementation of services from the time when they are configured [SSRB00]. The Component Configurator pattern supports various (re)configuration strategies that component servers can use to link/unlink DLLs containing component executor implementations on-demand. For example, during the initial component configuration phase, a component server can use this pattern to (1) dynamically link its executors from DLLs that contain these components and (2) set up the interconnections specified by the components' assembly descriptors. Likewise, this pattern can also be used to unlink and then re-link component executors dynamically when an updated implementation is available.

• Evictor: This pattern describes a general strategy for limiting memory consumption [HV98]. The Evictor pattern can be used by component servers to passivate infrequently used component executors reflectively and unlink their DLLs. For instance, a component that generates authentication certificates may be needed only at the beginning of a session. After a certificate is generated, therefore, it need not be retained during the remaining secure session, so its resources can be released.

In adaptive and reflective middleware, the use of the Component Configurator and Evictor patterns must be guided by user policies and environmental conditions. For example, the Component Configurator pattern can be applied to reconfigure component implementations based on information available from CCM component descriptors, such as componentfeatures. Componentfeatures is an XML entity in a component descriptor that describes a component's capabilities and operational policies. Likewise, eviction policies should reflect common usage patterns based on periodic ORB endsystem monitoring mechanisms or resource management strategies.

Applying dynamic (re)configuration in TAO: TAO's CCM implementation supports the following features that enable dynamic (re)configuration of component executors.

• On-demand linking: On-demand linking of component interface implementations is achieved in TAO via a combination of the Component Configurator pattern [SSRB00], the ACE Service Configurator framework [SS94] that implements this pattern by dynamically linking and unlinking component executors stored in DLLs, and standard CORBA servant managers [SV98]. There are two types of servant managers supported by a standard CORBA POA: (1) ServantActivators, which activate/deactivate servants in a POA's active object map on-demand and (2) ServantLocators, which implement user-defined object demultiplexing and servant lifetime managing mechanisms on a per-invocation basis.

  TAO's CCM framework enhances containers to provide their own ServantLocators that link in the necessary component executors from DLLs on-demand, as shown in Figure 4.

  

  Figure 4: Dynamic Linking/Unlinking of Component Parts via ServantLocator

  This mechanism also detects the availability of new component implementations and switches to use these updated versions automatically. For instance, TAO's ServantLocators can detect updated DLLs containing component executors and delegate the actual work to the ACE Service Configurator framework, which links/unlinks executors on-demand. This feature helps minimize system resource usage by not linking component executors until they are accessed. In addition, TAO's CCM implementation enhances component descriptors to provide meta-data that the ACE Service Configurator can use to swap component executors dynamically. A ServantLocator can also reflect on an executor to record its resource usage.

• Eviction: TAO's CCM implementation defines a usage query interface that allows certain executor usage information (such as the executor's usage frequency and the time when an executor was access most recently) to be reflected by the Evictor and ServantLocator. Internally, TAO's CCM implementation uses an evictor mechanism that queries components' usage interfaces and applies eviction policies to determine whether to passivate a component executor and unlink its DLL. Component descriptors can also be extended to include eviction strategies or to predefine component usage patterns that provide hints to TAO's CCM evictor mechanism. The activation of TAO's evictor mechanism can be controlled via policies selected by component server developers. Eviction can then be triggered either periodically or by monitoring dynamic system resources, such as CPU load or memory usage.

Challenge 4: Reconfiguring Server Concurrency Strategies Adaptively at Run-time

Context: Many components can be installed in a component server. These components may need to use different concurrency models or run at different thread priorities. To simplify development effort, component servers--rather than application developers--should be responsible for satisfying these requirements by providing the necessary concurrency mechanisms, e.g., maintaining a pool of real-time threads or spawning new threads to serve new requests.

Problem: A component server can host many component implementations with a range of requirements. Thus, component developers should generally not hard-code concurrency strategies into component implementations. Likewise, if a component server statically configures a single concurrency strategy, it may be hard to change the degree of concurrency flexibly since the server has no a priori knowledge of (1) the types of components it will host or (2) the frequency with which components will be used in advance.

For example, a developer may expect a component server to process a large number of requests, and thus initialize the server with a large thread pool. At run-time, however, the server may receive fewer requests than developers estimated originally, or the number of simultaneous requests may fluctuate depending on the time of day. Thus, these pre-spawned threads may not be fully used and thereby waste system memory and CPU resources that could be applied to other component servers on the same host. Conversely, under-estimating the degree of concurrency in a component server may decrease system performance adversely, particularly under bursty loads.

From another perspective, components may possess different QoS requirements in a component server. For example, requests to some components may need to be processed by threads of different priorities and different priority threads may need different degrees of concurrency, such as thread-per-connection or thread pools. It is inappropriate for components to dictate the concurrency strategies a component server must use since the environment in which components run may not be foreseeable when the component is designed.

Solution Apply reflection to determine the appropriate degree of concurrency and priorities in a component server adaptively. To resolve the problems outlined above, component servers should reflectively manage the degree of concurrency needed to adapt to the system load and to the desired concurrency strategies of installed components. This behavior can be achieved by creating a meta-region that provides meta-objects with different concurrency strategies and a binding switch meta-object that associates the appropriate concurrency strategy with the base-object, i.e., the component server itself.

Applying adaptive concurrency models in TAO: In TAO's CCM implementation, this reflection mechanism can use the following meta-information to determine a suitable concurrency strategy:

• Platform descriptors, which specify the type of concurrency support a component server provides to the components it supports.
• Component concurrency descriptors, which provide hints to the concurrency control mechanisms of component servers. Components concurrency descriptors can be embedded in the component descriptors defined in CCM specification.
• System status descriptors, which contain the dynamic status of systems, such as the number of threads or the number of simultaneous requests for all components requiring the same concurrency strategy.

3. Current Progress and Empirical Results

In this section, we report the results of our ongoing efforts to enhance TAO to support the ARMS techniques described in Section 2.

Current Progress: We have added a QoS adaptation layer called the ACE QoS API (AQoSA) [SKKK00] that shields TAO from differences among the QoS interfaces on different OS platforms. AQoSA is implemented as part of the ACE layer shown in Figure 1 and provides the following capabilities to TAO:

• Support for QoS mapping that translates application-specific QoS parameters, such as flow rate, jitter, between the application-level and network-level parameters;
• Support for QoS monitoring and adaptation so DRE applications that require certain resources can adapt when insufficient resources are available at run-time;
• Support for prioritized scheduling by partitioning requests for different QoS requirement into different threads and servicing these threads through different endpoints;
• Support for initializing endpoint QoS properties, such as bandwidth reservation and flow pacing; and
• Support for portable scheduling control, which allows applications to portably specify scheduling criteria, such as threads priorities and scheduling policies.

We have also implemented a container prototype that supports the on-demand linking and eviction of component executors described in Challenge 3. We are in the process of strategizing the eviction mechanism and will integrate this with TAO's CCM component usage reflection support. The concurrency management mechanism, however, is still work-in-progress.

TAO supports two co-process collocation mechanisms [WSV99] and several other co-host optimization mechanisms via its pluggable protocols framework [OKSO99]. Currently, TAO allows reflective selection of inter-process collocation optimizations and user-selectable intra-process collocation optimizations. Upcoming versions of TAO will completely automate the collocation selection mechanism outlined in Section 2.1. The remainder of this section presents empirical results of performance comparisons of the collocation optimization mechanisms supported by TAO.

Measurement techniques: Changing the communication channels is transparent to clients and servers in TAO. The following four ORB communication mechanisms were configured using TAO's pluggable protocols framework [OKSO99] and collocation optimizations [POSW98] and then compared with TAO's default IIOP configuration in the experiments reported below:

1. SHMIOP: This transport mechanism implements a shared-memory transport that optimizes inter-process communication within a single host;

2. UIOP: This transport mechanism utilizes UNIX-domain sockets to optimize inter-process communication within a single host;

3. Thru_POA: This intra-process collocation optimization [WSV99] invokes an operation via a ``servant stub,'' which ensures the invocation conforms any POA policies configured by in the ``server'' where the target object resides;

4. Direct: This intra-process collocation optimization invokes an operation on the servant through a customized stub directly as if it were a local interface (which is a new CORBA interface type defined in the CCM specification for objects that will only be invoked locally).

We measured the performance of TAO's collocation optimization mechanisms by invoking operations that sent a sequence of 4 and 1,024 elements of longs. Both server and client ran in the same process to allow us to compare the performance gain of applying each optimization mechanism. The client and server run in separate real-time threads in the process. Changing the collocation strategy is done via command-line options and a configuration file, so it is transparent to either client or server. We can therefore obtain different results by running the same test program configured to use the different collocation strategies outlined above. The performance of IIOP is measured as a baseline for non-optimized communication.

Hardware/OS Benchmarking Platforms: The tests were conducted using a Gateway PC with two 500 Mhz Pentium-III CPUs running Microsoft Windows 2000 and an a UltraSPARC with four 300Mhz UltraSparcs running SunOS 5.7. We compiled the test on NT using Microsoft Visual Studio with Service Pack 3 and on Solaris using egcs version 2.91.60, using full compiler optimizations.

Results: Figure 6 shows (in log scale) the performance of TAO's collocation optimization mechanisms compared with the IIOP baseline. In the figure, shared-memory transport is labeled as SHMIOP and UNIX-domain transport is labeled as UIOP. The results in this figure illustrate the importance of configuring an ORB's collocation selection mechanism reflectively to take advantage of the ORB's OS platform. For example, depending on the size of the data being transferred, the performance of SHMIOP on Windows NT is 30% to 50% faster than that of IIOP. It is only marginally faster (10%) than IIOP on UNIX, however, due to the higher overhead of process-level semaphores on UNIX compared with Windows NT. Thus, UIOP outperforms actually SHMIOP on Solaris machines.

Our current implementation of SHMIOP in TAO uses the loopback localhost pseudo-device interface as a control mechanism. Thus, we notify the ORB's reactive [SSRB00] event loop via a socket on each send operation. We expect the performance of SHMIOP will improve substantially after we implement a multi-threaded version of SHMIOP that uses ``zero-copy'' shared memory buffers. TAO's current SHMIOP implementation will still be useful, however, to support single-threaded applications.

4. Related Work

CORBA is increasingly being adopted as the middleware of choice for performance-sensitive DRE systems. Thus, the need to develop highly flexible, configurable, efficient, predictable, and scalable CORBA applications has motivated research on policies and mechanisms for QoS-enabled CCM. The following work on middleware and component technologies has influenced our ARMS research on TAO.

Standard CORBA meta-programming mechanisms: A CORBA ORB provides a meta-object framework to connect clients with servers. Many meta-programming mechanisms [WPS01] have been standardized and are used at different levels of ORB endsystems to enhance the system's performance and adaptability end-to-end. For example, DII, DSI, and interface repositories provide an application with direct access to CORBA's meta-object system; the OMG's Meta-Object Facility (MOF) [Obj00a] provides a standard way to model the meta-object in IDL definitions and standardizes the MOPs for accessing these meta-information; smart proxies and CORBA portable interceptors [Obj99b] can alter object behavior selectively; pluggable transport protocols [Obj00c] control how ORBs exchange messages; and servant locators and containers direct resource management in a CORBA server.

Adapt project: The Distributed Multimedia Research Group at Lancaster University has proposed and implemented a prototype of next-generation reflective middleware [BCRP98] [CB99]. Their middleware model concentrates on dynamic composition of objects through open-binding, which (1) allows object implementations to be configured dynamically and (2) determines various aspects of object implementations, such as adding or removing methods from an object. The Adapt project model also facilitates QoS properties management and monitoring. Compared to the Adapt project, our work on TAO and CCM concentrates on identifying and using ARMS techniques to implement and improve the implementation of an existing middleware standard, whereas the Adapt project defines and implements the meta-space of a new middleware framework at a higher level.

Reflective ORBs: Kon and Campbell [KC99] demonstrate that TAO can be reconfigured at run-time by dynamically linking/unlinking certain components. Although their research provides a proof-of-concept for dynamically configurable middleware framework, they do not explore performance implications and optimizations related to CCM-based middleware. In contrast, our research on dynamic configuration concentrates on minimizing time/space overhead reflectively to support the CCM, without unduly compromising the added capabilities and flexibility of the CCM.

QuO: The Quality Objects (QuO) distributed object middleware is developed at BBN Technologies [ZBS97] by applying aspect-oriented programming (AOP) [Kicz97] techniques to adaptive applications running over wide-area networks. Like TAO, QuO is based on CORBA and supports:

1. Run-time performance tuning and configuration through the specification of operating regions, behavior alternatives, and reconfiguration strategies that allows the QuO run-time to trigger reconfiguration adaptively as system conditions change (represented by transitions between operating regions); and

2. Feedback across software and distribution boundaries based on a control loop in which client applications and server objects request levels of service and are notified of dynamic changes in service at run-time.

AspectIX: AspectIX [HBGM99] is a novel CORBA-compliant middleware architecture that uses AOP [Kicz97] to define and describe QoS requirements on a per-object basis independently from functional interfaces. Clients in AspectIX systems are allowed to set the QoS aspects of objects. Systems may adapt, report aspect changes back to clients, or reflect to clients on how to adapt. As with TAO's QoS-enabled collocation optimizations, AspectIX supports automatic selection among multiple object communication mechanisms. Likewise, AspectIX tries to isolate the QoS properties from clients and apply ARMS technologies for clients to adapt to the change. Our work, however, focuses on QoS adaptation as a deployable entity in the system to standardize and automate the server-side QoS control/adaptation issues.

JinACE: Part of the work on reflective CCM outlined in this paper originated in the JinACE project [KJP00]. JinACE is a component-based, standards-based ad hoc networking platform, design for high performance and small footprint, opening up new domains for ad hoc scenarios. It is based on a set of patterns that provide on-demand linking, activation, eviction and lookup of components representing services. JinACE, in turn, was inspired by Sun's Jini Technology [Sun99]. By examining Jini's key design features and protocols, we identified a pattern language consisting of patterns for component discovery, on-demand linking/unlinking, and dynamic activation/deactivation. One goal of JinACE is to make this pattern language available to middleware standards written in programming languages other than Java. We are planning to merge JinACE with TAO's CCM implementation.

5. Concluding Remarks

Distributed real-time and embedded (DRE) systems can benefit from middleware tools and mechanisms that allow the functional and QoS-related properties of applications to be configured and controlled automatically. Recent CORBA specifications define better support for configurability and QoS enforcement. In particular, the CORBA Component Model (CCM) [BEA99] defines standard interfaces, policies, and services for structuring, integrating, and deploying CORBA components. Likewise, the Real-time CORBA [SK99] and CORBA Messaging [Obj98] specifications address many end-to-end QoS properties. We believe, however, that these specifications will be unsuitable for an important class of QoS-enabled DRE applications unless ORB implementations apply adaptive and reflective middleware system (ARMS) techniques to automate the selection, monitoring, and coordination of key QoS properties.

CORBA has matured considerably over the past decade to become the de facto standard for DRE middleware. As CORBA gains acceptance, more features are being added into the standard. Not all features are required by all users all the time. It is important, therefore, for applications, end-users, or administrators to be able to configure just the required features into ORBs statically, as well as to dynamically reconfigure the system as requirements or operating conditions change. The increased complexity caused by additional features also imposes a burden on ORB developers to implement robust and flexible ORBs that can support a broad range of DRE application use-cases. Based upon our work and related work of others in this field, we believe that ARMS techniques provide an effective strategy for addressing these challenges systematically to meet next-generation DRE application needs[q.

Our research to date has focused on ARMS techniques that enable the automatic (1) selection of optimal QoS-aware communication mechanisms, (2) management of QoS properties of CORBA components via their containers, (3) (re)configuration of selected parts of component executors dynamically, and (4) tailoring the degree of concurrency of a component server adaptively to maximize ORB endsystem capacity. We are applying these techniques to TAO, which is our platform for implementing, optimizing, and experimenting with QoS-enabled CCM middleware for DRE applications. The source, documentation, examples, and tests for TAO are available in open-source format at www.cs.wustl.edu/~schmidt/TAO.html.

6. References