No other system architecture offers a more complete and integrated solution for automatic configuration in heterogeneous, distributed systems than the one proposed in this thesis. To the best of our knowledge, our work is the first to identify the lack of an explicit representation of inter-component dependence as one of the most fundamental problems in existing computer systems.
Our architecture leverages modern technologies such as CORBA, component-based programming, and mobile agents with the results of the research in operating systems and dynamic configuration of the previous decade.
In this section, we describe previous work in related areas, explain how they influenced our research, and discuss the differences with our approach.
Our work was strongly influenced by the advances in programming languages and methodologies for software development of the last two decades. These advances include not only the concepts of reflection and aspect-oriented programming, described next, but also, object-orientation and design patterns [GHJV95].
The idea of having a ComponentConfigurator object associated with each component is similar to the concept of meta-objects present in reflective languages such as CLOS [KdRB91], OpenC++ [Chi95], Iguana [GC96], and Guaraná [OB99] and reflective systems such as Apertos [ILY95]. Meta-objects are used to modify the object model and customize all aspects of object behavior, at compile time, link time, or run time. In contrast, the intent of the component configurator is not to modify the object model, but to maintain extra information about inter-component dependence. This extra information helps the system to provide automatic configuration and fault-tolerance and offers components the possibility of reasoning about their own dependencies.
Reflective languages and environments could be used to implement the component configurator model. The management of dependencies could be carried out by meta-objects associated with the relevant components. The reflective mechanisms could then be used to instrument component creation and destruction to take care of the dependencies properly. The architecture described here does not rely on a particular reflective language or environment. We use only standard languages and architectures such as C++, Java, and CORBA.
In spite of the differences between our model and previous implementations of reflective systems, we believe that component configurators are a valuable tool for implementing high-performance reflective systems. Component configurators help realizing the following basic concepts of reflective systems.
Unlike most existing reflective systems, in our model, the component configurator is not present in the normal invocation path to the component or to the objects inside it. The configurator is not activated each time the component is invoked. Normally, the component configurator code is only executed when some meta-level operation, such as reconfiguration, is required.
Aspect-Oriented Programming (AOP) [KLM+97] is a novel programming paradigm in which different aspects of a program are coded in separate subprograms. A tool called aspect weaver is used to combine multiple aspects into a single executable program image. As noted in [Lun98], AOP can be seen as a reflection model in which each object has multiple meta-objects (its aspects).
AOP could also be used to implement the model described in this thesis. Dependence management could be coded in a separate aspect that would be inserted in the executable program by the aspect weaver. Another option would be to use AOP to implement complex component configurators. Programmers would write the code to deal with the different aspects of dependence management (such as fault-tolerance, dynamic reconfiguration, and adaptability) using AOP aspects. The weaver would then be used to generate the component configurator.
AOP is still a very recent, emerging technology. The modeling of dependencies using aspects is an open problem. It is not clear yet how to support dynamic (re)configuration of aspects. In existing AOP platforms, executables are created off-line by the aspect weaver that mixes the code of all the aspects, making dynamic replacement of a single aspect extremely difficult. A solution to this problem may reside in some of the recent research in this area [BA00].
Three major component architectures are likely to be present in the software development arena in the next few years: Enterprise JavaBeans [Ham97], ActiveX Controls [Can97,Den97], and the CORBA Component Model (CCM) [OMG99]. They all intend to provide an infrastructure to support the construction of complex applications from off-the-shelf components.
Sun Microsystem's Enterprise Java Beans specify a standard for packaging components, called JAR, and for inspecting the interfaces exported by each component (Introspection). Java beans must be completely composed of Java byte code, which limits the applicability of the model.
Jini is a set of mechanisms for managing dynamic environments based on Java. It provides protocols to allow services to join a network and discover what services are available in this network. It also defines standard service interfaces for leasing, transactions, and events [Wal98].
When a Jini server registers itself with the Jini lookup service, it stores a piece of Java byte code, called proxy, in its entry in the lookup service. When a Jini-enabled client uses the lookup service to locate the server, it receives, as a reply, a ServiceItem, which is composed by a service ID, the code for the proxy, and a set of service attributes. The proxy is then linked into the client address-space and is responsible for communication with the server. In this way, the communication between the client and the server can be customized, and optimized protocols can be adopted.
This Jini mechanism for proxy distribution can be achieved in a CORBA environment by using the Automatic Configuration Service (see Chapter 4) in conjunction with a reflective ORB such as dynamicTAO (see section 7.1). The Automatic Configuration Service would fetch the proxy code and dynamically link it, while dynamicTAO would use the TAO pluggable protocols framework [SC00] to plug the proxy code into the TAO framework.
Jini is typically limited to small-scale networks and it does not address the management of component-based applications and inter-component dependence. Due to the large memory requirements imposed by Java/Jini, this is not yet a viable alternative for most PDAs and embedded devices.
The CORBA Component Model (CCM) adopted by OMG on November, 1999, specifies a standard framework for building, packaging, and deploying CORBA components [OMG99]. Unlike our model, which focuses on prerequisites and dynamic dependencies, the CORBA Component Model concentrates on defining an XML vocabulary and an extension to the OMG IDL to support the specification of component packaging, customization, and configuration. We believe that our model and CCM complement each other and could be integrated. CCM provides a static description of component needs and interactions while our model manages the runtime dynamics.
Although CCM was already approved by OMG, publicly available ORBs do not support it yet. Once this happens, we intend to work towards the integration of the two models.
Microsoft's ActiveX Controls architecture [Can97,Den97] also provides mechanisms for packaging, dynamic instantiation, and inspection of the interfaces exported by COM components. Distributed components can communicate via DCOM, which defines a protocol based on the Distributed Computing Environment (DCE) RPC specification [Loc94]. The architecture is tailored to Microsoft operating systems and very little was done to support interoperability with other platforms. As shown in [CHY+98], implementing DCOM clients and servers is clearly more complicated than writing CORBA clients and servers. The architecture provides no support for dependence management.
OpenDoc [OHE96], promoted in the past by Apple and CI Labs, defines a compound document infrastructure based on IBM's SOM and CORBA. Its design influenced modern component architectures but it was abandoned in favor of Java Beans. Apple is now supporting CORBA, Java Beans, and ActiveX in their OpenStep environment [Don97]. OpenStep is an object-oriented software development environment that runs on top of Mach, Windows NT, Solaris, and HP-UX and provides an interface independent of the underlying operating system.
A few systems dealt with concepts similar to the prerequisites presented in section 3.2.1, thus addressing parts of the problem of dependence management.
The concept of prerequisites has its origins in the Job Control Languages of
the mid-1960s. The OS/360 operating system, deployed in a wide range of
IBM computers, used JCL [Flo71] to control the multiple jobs in its
innovative ``multiprogramming'' environment. The JOB statement, in
JCL, may have a series of keyword parameters of the form 
NAME=value
to specify certain characteristics of the job. The statement
//Little2KJob JOB TIME=(3,45) REGION=20K PRTY=5specifies that the job Little2KJob takes approximately 3 minutes and 45 seconds to run, requires approximately 20 Kbytes of memory and must be executed with priority 5. Thus, the parameters of the JOB statement can be seen as a primitive version of the ``hardware prerequisites'' portion of a SPDF specification (see section 4.2.1).
The use of the term ``prerequisites'' to refer to the dependencies of operating system objects originated in the SOS operating system [SGH+89,MGLNS94] developed at INRIA, France. In the SOS model, objects contain a list of prerequisites that must be satisfied before they are activated. Even though the idea was promising, it was not fully explored in that project. Prerequisites were only used to express that an object depends on the code implementing it and not much experimentation was carried out [SGM89,Sha98]. Besides, SOS does not include a model for dynamic management of inter-component dependence.
Modern operating systems, like Solaris, use an explicit representation of the dependencies among shared libraries to implement dynamic linking [Sun97]. A shared library contains a list of the pathnames of other libraries upon which it depends. The system tries to locate all the required libraries before executing any application code.
Our approach can be seen as an extension to that, since it uses a representation of dependencies to support dynamic loading. The difference is that our approach is able to represent dependencies among generic components (not only shared libraries) in heterogeneous, distributed environments and it uses this representation to support different kinds of (re)configurations (not only dynamic linking).
The Globus project [FK98] provides a ``computational grid'' [FK99a] integrating heterogeneous distributed resources in a single wide-area system. It supports scalable resource management based on a hierarchy of resource managers similar to those of 2K [Yam00]. But, unlike 2K, Globus is tailored to computationally-intensive applications such as large-scale simulations and teleimmersive applications.
Globus defines an extensible Resource Specification Language (RSL) that is similar to our SPDF. RSL [Glo00] allows Globus users to specify the executables they want to run as well as their resource requirements and environment characteristics.
RSL could be integrated in our system by plugging an RSLParser into our Automatic Configuration framework. A fundamental difference between Globus and our work is that we focus on component-based applications that are dynamically configured by assembling components fetched from a network repository. In Globus, on the other hand, the user specifies the application to be executed by giving the name of a single executable on the target host file system or by giving a URL from which the executable can be fetched.
Although the Globus design includes a service for managing application code (the Globus Executable Management service or GEM), the current implementation does not include it as a separate service. The name of this service, however, implies that Globus views an application as a single executable, rather than a collection of components that can be dynamically instantiated. Since Globus is one of the most important works in this area, we hope that their system evolves to incorporate support for dynamic component-based applications.
The idea of building a small system core that could be extended in different ways depending on user and application requirements was explored extensively by previous work on customizable operating systems, microkernels, and exokernels. As discussed below, this research created the basic mechanisms that enable extensions to operating systems, but it did not reach far enough to provide a real ``what you need is what you get'' model as the one described in section 3.2.
Systems like Choices [CIMR93] let administrators build a new instance of the kernel by specifying at compile or link time which mechanisms to use in the various subsystems. System developers implement a fixed set of modules from which the administrator can choose to construct a certain instance of the kernel. Different modules contain different implementations for virtual memory, file system, networking, and so on. In addition, users can choose to implement a new mechanism by writing a new system module. Unfortunately, implementing a new system module requires intimate knowledge of system internals and conventions. As a result, extending the system is not as easy as expected.
Choices contributed very significantly to the field of operating system design and construction as it showed how principles of object-orientation and design patterns can help to build efficient systems more easily. But it did not address the problems of dynamic configuration or how to express the requirements for constructing the system. The choice of which modules would compose each instance of the kernel were left to a human administrator that edited Makefiles manually.
Mach [Lop91], SPIN [B+95],
Choices [LTC96], and L4 [HHL+97], are operating systems with a
small core, called microkernel, that runs in privileged mode. A collection of user-level
processes, running on top of this small core, support services that are traditionally
provided by the kernel in monolithic systems.
Thus, administrators can configure the system by selecting different sets of
user-level services to be executed in each machine. So, even if all the
machines in a network run the same microkernel, their services can be adjusted
to the requirements of their users.
Some microkernels also provide mechanisms for modifying their
configuration dynamically by adding new modules at runtime.
Choices can, for example, dynamically load a new
module written in Java into its kernel.
The code is then run by a JAVA
interpreter that resides in the kernel.
SPIN can load modules written in the
type safe language Modula-3 and then compiled by a trusted compiler.
Synthetix [CAK+96] dynamically generates new
code that is specialized to provide improved performance for a
particular situation.
The concept of exokernels, first introduced by Engler, Kaashoek and O'Toole [EKJ95,K+97] and further extended by Ballesteros [BHK+99,BHKC99,BKC97], suggests that high-performance, configurable operating systems can be built by implementing a minimal kernel exporting only low-level hardware abstractions. In these systems, traditional operating system abstractions, such as processes and files, are implemented by user-level libraries. Each application can be linked to different libraries at runtime and, therefore, use customized system abstractions. Exokernels have one major objective: to export the hardware resources safely.
As described above, customizable operating systems, microkernels, and exokernels supported system configuration using low-level techniques for linking new modules into the operating system in kernel and user space, either statically or dynamically. However, all of them lack a high-level model for operating system configuration and reconfiguration. Although they permit the establishment of different, customized system configurations, they do not have any model for expressing the requirements of user and applications with respect to system modules. All the work is left to the system administrator, who must know about all users, all applications, and have total control over the configuration.
The model presented in this thesis is an integrated solution to the problem of configuring operating systems. Each system module, application, and user defines its requirements explicitly. The system processes all this information and configures the user environment automatically to provide exactly what is needed, no less, no more.
Previous work in operating systems have not addressed a number of problems related to fault-tolerance and dynamic reconfiguration. Using prerequisites and the ComponentConfigurator framework, this thesis shows how a system can answer the following questions.
By answering these questions, this thesis presents a framework that helps future research efforts to address the following questions.
As the complexity of software increases, the design of the overall system architecture (also known as programming in the large) becomes even more important than the choices of the individual algorithms and data structures that are used in each component (programming in the small). Software architecture is an emerging discipline in software engineering that aims to teach developers to program in the large effectively.
Many of our ideas regarding how to deal with dynamic configuration extend previous work in the field of software architecture. We now discuss some of the most important work in this area and, in Section 9.5.4, explain how our approach differs from them.
James Purtilo's group developed the Polylith system [Pur94] in which components interact with each other through software buses. The major idea behind Polylith is that it would allow programmers to implement functional aspects of components separately from their interfacing aspects. Components interface with the bus only, while Polylith provides different implementations of the bus using different communication protocols.
Polylith can be seen as one of the precursors of OMG's CORBA, helping programmers to interconnect software components written in different languages and executing them in heterogeneous environments. CORBA, in turn, can be seen as a particular implementation of the software bus concept.
Surgeon [HWP93] is a tool for building dynamically reconfigurable applications based on Polylith. Based on module specifications and application specifications, Polygen [CP91] integrates application modules and builds executable files. Surgeon pre-processes modules that are subject to dynamic reconfiguration instructing Polygen about how the modules must be packaged. At execution time, Surgeon agents, called catalysts, manage the reconfiguration process. The catalysts automate the process of updating the bindings between a module being replaced and the modules with which it communicates.
Surgeon works with a limited set of applications in which the modules do not need to participate in the reconfiguration process. As identified in their research, this implies that the modules that are safely reconfigurable using a catalyst must satisfy the following conditions.
In her PhD thesis [Hof94], Christine Hofmeister extends this work presenting a framework for dynamic reconfiguration of distributed programs with module participation [HP93]. Although this framework does not support the degree of automation that Surgeon does, it does not require that the component state be discharged. Instead, they apply a technique suggested by Herlihy and Liskov, for transmission of abstract data types [HL82]. Each module is responsible for exporting its internal state, by implementing an encode operation, and for importing state through a decode operation. In addition, programmers must carefully design application modules so that they can reach a stable state for reconfiguration. When a user requests a module reconfiguration, the module continues its execution until a stable state is achieved. The entire application need not be suspended for reconfiguration; only the affected modules are.
Aster [IB96] is an implementation of a software bus on top of CORBA. Instead of allowing components to implement and use arbitrary interfaces defined with IDL, Aster components interface with a bus written in CORBA. This bus supports only one interface which contains operations like sendBus(out msg m) and receiveBus(in msg m). In section 9.6, we describe ongoing work on supporting dynamic configuration in the Aster environment.
Sefika addressed the issue of architectural-awareness in the Choices operating system, emphasizing quantitative aspects of the interaction between objects in the Choices kernel [SC95,SSC96a]. The goal was to monitor compliance of the system with its design models [SSC96b].
The motivation of our research, however, is to extend that concept to a broader group of software systems including, not only operating system kernels, but also system libraries, distributed services, and user-level applications. Also, rather than concentrating on the quantitative aspects of the interactions, our work focuses on representing dependencies among software components to support automatic configuration, reliability, and QoS.
Architectural Description Languages (ADLs) provide a way for practitioners to define the architecture of their systems using a formal notation. Thus, they can present their architectures to other people, reason about them, and even submit the descriptions to automated tools to analyze their consistency or generate code automatically.
ADLs evolved as an extension of Module Interconnection Languages (MILs) first defined in 1975 by DeRemer and Kron [DK76]. MIL compilers were able to build static systems by combining different modules while ensuring system integrity by performing type-checking at compile-time. Early MILs posed a series of restrictions to software developers, requiring that all the modules be written in the same language, be available during system construction, and that each module describe the other modules with which it interacts [SDZ96].
The research carried out by Kramer and Magee at the Imperial College in London provided some of the most significant results in the area of ADLs and dynamic configuration. After earlier work on the Conic [MKS89] and Rex [KMSD92] projects, their most recent research is based on the Darwin ADL.
Darwin has been used in environments like Regis [MDK94] and CORBA [MTK97] to specify the overall architecture of component-based applications. A Darwin specification defines all the components of an application and the communication interactions between them. At application start time, the middleware loads all the application components and establishes the links between them.
UniCon [SG96,SDZ96] introduced the concept of Architectural Connectors, first class objects that mediate the interactions between the components of a system. Components are identified by their interfaces and connectors are identified by protocols. Applications are built as composite components specified in the UniCon ADL. A composite component specification contains three parts: (1) a list of components to be instantiated, (2) a description of the connections between the components inside the composite, and (3) a binding of the external interface of the composite with the internal configuration. Given this description, UniCon is able to build executable files and scripts that are used to instantiate the whole application.
UniCon connectors implement various communication mechanisms such as UNIX pipes, file I/O, and local and remote procedure calls. Developers may associate an expert to each connector. The expert is a piece of executable code that is capable of building the executable code for the connections and checking if a particular use of a connector is consistent. The experts are called by the UniCon compiler as the application is built.
Olan [BABR96,BBB+98] is an execution environment and an architectural description language focusing primarily on distributed applications. The ADL, called Olan Configuration Language (OCL), is an extension of Darwin that includes two new abstractions: the connectors, as in UniCon, and collections, that represent a dynamic set of objects that can be controlled as a group by the configuration language.
In Olan, applications are organized as a hierarchy of components, where each component may have a set of sub-components. A sub-component can be instantiated dynamically in three ways: (1) at the same time as the enclosing component, (2) when the first communication request reaches the sub-component, or (3) when an explicit instantiation request arrives. These explicit instantiation requests are used to build dynamic groups of components that are stored in collections. Thus, in contrast to traditional ADLs, where the architecture of the system is statically determined by the ADL description, OCL provides a little more dynamism by allowing collections of components whose contents are determined according to decisions made at runtime.
The Olan developers implemented a prototype in the Python programming language and made experiments with simple applications, like a configurable electronic mail tool. They targeted Olan towards rapid prototyping and, as a consequence, system performance was low. Other major drawbacks were the lack of a graphical interface and the lack of support for dynamic reconfiguration and dynamic replacement of components. Even with the limitations of its prototype implementation, Olan may be, today, the most complete language for representing software architectures.
Systems based on architectural connectors like UniCon [SDZ96] and ArchStudio [OT98] and systems based on software buses like Polylith [Pur94] separate issues concerning component functional behavior from component interaction. Our model goes one step further by separating inter-component communication from inter-component dependence. Connectors and software buses require that applications be programmed to a particular communication paradigm. Unlike previous work in this area, our model does not dictate a particular communication paradigm like connectors or buses. It can be used in conjunction with connectors, buses, local method invocation, CORBA, Java RMI, and other methods. As shown in our discussion about dynamicTAO (see section 7.1), the model was applied to a legacy system without requiring any modification to its functional implementation or to its inter-component communication mechanisms.
Communication and dependence are often intimately related. But, in many cases, the distinction between inter-component dependence and inter-component communication is beneficial. For example, the quality of service provided by a multimedia application is greatly influenced by the mechanisms utilized by underlying services such as virtual memory, scheduling, and memory allocation (e.g., through the new operator). The interaction between the application and these services is often implicit, i.e., no direct communication (e.g. library or system calls) takes place. Yet, if the system infrastructure allows developers to establish and manipulate dependence relationships between the application and these services, the application can be notified of substantial changes in the state and configuration of the services that may affect its performance.
Research in software architecture and dynamic configuration generally assumes that the operating system is an omnipresent, monolithic black box that can be left out of the discussion; it concentrates on the architecture of individual applications. Previous work in this field does not represent dependencies of application components towards system components, other applications, or services available in the distributed environment. Our approach differs from them in the sense that, for each component, we specify its dependencies on all the different kinds of environment components and we maintain and use these dynamic dependencies at runtime.
Approaches based on software architecture typically rely on global, centralized knowledge of application architecture. In contrast, our method is more decentralized and focuses on more direct component dependencies. We believe that, rather than conflicting with the software architecture approach, our vision complements them by reasoning about all the dependencies that may affect reliability, performance, and quality of service.
The final solution to the problem of supporting reliable automatic (re)configuration may reside on the combination of our model with recent work in ADLs and dynamic (re)configuration. This is certainly an important open research problem to be investigated in the future (see chapter 10).
Following the early work on dynamic configuration performed by Bloom and Day [BD93] and Hofmeister [HP93], a significant international community organized around the International Conference on Configurable Distributed Systems [PCS98] has been working on the difficult problem of dynamic configuration.
Oreizy, Taylor, and Rosenblum [ORT98,OT98] have identified the need for an explicit representation of the system architecture in order to support consistent, dynamic reconfiguration. In their model, components interact with each other through Connectors, which are used both for communication and for representing the dependencies among groups of components. However, because connectors are also used for group communication (for broadcasting asynchronous messages), the model does not make it clear whether two components linked by a connector really depend on each other. It is a good idea to restrict the freedom of the application developer but, in this case, they also restricted the expressiveness of the model.
Valérie Issarny at IRISA, France developed a Dynamic Reconfiguration Service for CORBA [BISZ98]. In this work, a centralized Dynamic Reconfiguration Manager (DRM) maintains a representation of the distributed system architecture, receives requests for reconfiguration, and invokes the proper distributed components to carry out the reconfiguration. Maintaining application consistency is the responsibility of the application. The infrastructure guarantees that the semantics of the RPC is kept consistent even if components are replaced on-the-fly. Ongoing work includes the integration of this Dynamic Reconfiguration Service in the Aster programming environment (see 9.5.1).
Shrivastava and Wheater [SW98] are currently working on a workflow-based model for distributed applications. In their model, a scripting language [RSW98] is used to provide high-level descriptions of workflow schemas. Schemas represent the structure of tasks in a distributed application with respect to task composition and inter-task dependencies.
The meaning of the term ``dependency'' in their work is directly related to the workflow model and differs slightly from the one we adopt. A dependency can be either
A workflow execution service coordinates the execution of the workflow and helps to guarantee that reconfigurations will be performed in a consistent way. Each task is managed by a task controller that handles workflow dependencies and helps support reconfiguration.
A task is modeled as having a set of input sets (analogous to our hooks) and a set of output sets (analogous to the clients in the component configurator model). Their workflow schemas resemble our prerequisites slightly. Their task controller resembles our component configurator.
The main difference between their model and ours is that their model mixes the representation of data flow, coordination, and inter-component dependence. Their model is suited to expressing temporal workflow dependencies among components in a certain application. It does not address the interactions between application components and system services.
However, it is important to note that, in Shrivastava and Wheater's model, users are able to specify what the requirements for application tasks must be, so that reconfigurations can be performed in a consistent way. This problem is out of the scope of our work and it could be a PhD thesis in itself. Our framework, however, gives developers the chance to write code to take care of consistency inside the component configurators.
Using the architecture for dependence management and automatic configuration presented in this thesis, we were able to implement two novel applications, the multimedia distribution system and dynamicTAO. These applications provided original contributions to the research in their respective Computer Science fields. We now discuss previous work in these fields and emphasize our contributions.
Our research on the multimedia distribution system benefits from and builds on previous work on IP-Multicast [Dee89] and the Internet MBone [Eri94,SRL96]. The MBone is a virtual network that is layered on top of the Internet to support routing of IP-Multicast packets. It is composed of islands that can directly support IP-Multicast (e.g., multicast LANs connected by multicast-capable routers), linked by virtual point-to-point links called tunnels. The system described in this article can be seen either as extending the MBone capabilities or, (since we also support IP-Multicast) as a set of tools for managing MBone broadcasts. The MBone relies on a multicast distribution engine that is hard-wired into the networking infrastructure, making it difficult to deploy new technologies for distribution. Our approach not only uses user-level entities that can be replaced easily, but it also supports dynamic reconfiguration of running systems, allowing for easy incremental evolution of the communication mechanisms with respect to QoS, security, and reliability.
Amir, McCanne and Katz developed an active service framework [AMK98] that provides support for the dynamic instantiation of server agents (or servents), providing the desired service, in a collection of distributed nodes running their host manager (HM) daemon. They used this framework to implement a Media Gateway (MeGa) service [AMZ95]. Like our Reflector, the MeGa service can be used to transcode multimedia streams. In fact, their research has focused on algorithms for efficient transcoding and down-sizing and, more recently, on adaptive bandwidth allocation algorithms [AMK97] and on the dynamic instantiation of media gateways between MBone sessions to deal with heterogeneous networks. Our research on the Reflector architecture shares some concerns with their active service framework (which has some similarities with our Automatic Configuration Service) and with their MeGa service (which could be implemented in our architecture with customized Connection classes loaded into the Reflector). Nevertheless, we also focus on providing scalable multimedia distribution using multiple communication protocols, reconfiguration of the network topology to deal with failures, and scalable code distribution and dynamic reconfiguration.
Baldi, Picco, and Risso designed a videoconference system based on active networks [BPR98]. Their proposed architecture allows clients to customize their videoconference server (or Reflector) by uploading mobile Java code. The main difference is that, in their approach, the Reflector is designed to run in active network routers while ours is designed as a user-level application to be executed on networked workstations. Our infrastructure for mobile reconfiguration agents plays the same role as the active network in their system. We chose to implement our system in C++ because our experience shows that Java is not yet ready to provide the high-performance and predictability that most QoS-sensitive applications require.
Recent research in middleware have identified a number of limitations on first-generation CORBA implementations. This has led to ORB extensions for dealing with specific aspects such as real-time [HLS97b], group communication [MS97], and fault-tolerance [Maf95]. The goal of dynamicTAO, on the other hand, is to provide a generic infrastructure in which different kinds of customizations can be performed using reflection.
Other research groups have addressed the problem of middleware customization by using different approaches. The Operating Systems group at the Friedrich-Alexander University of Erlangen-Nürnberg is developing AspectIX [HBG+98], a configurable middleware architecture based on the fragmented object model. AspectIX clients would interact with a fragment of the global object (the fragment implementation) by using an interface (the fragment interface). The global object could be configured by using ``profiles'' which in turn specify ``aspects'' that must be supported by the fragment implementations. AspectIX Aspects can be compared to dynamicTAO category implementations, the difference being that dynamicTAO implementations can be added on-the-fly. The AspectIX group plans to implement a prototype of their model where each object running within a single ORB would be able to specify its own policies and protocols. In dynamicTAO, a similar effect could be achieved by using different ORBs inside a single process and configuring each of the ORBs in a different way. In the LegORB model, on the other hand, the ORB can be configured to support either of the two approaches.
Blair and others at Lancaster University has proposed a reflective architecture for next generation middleware [BCRP98,CB99,BCCD00]. They developed a prototype using the Python interpreted language in which the programmer is able to inspect and change the implementation at runtime. The level of reflection is much higher than in dynamicTAO since, in their Python system, it is possible to add or remove methods from objects and classes dynamically and even change the class of an object at runtime. Their research has emphasized dynamic configurability through a well-defined open binding model which allows multiple reflective levels. In contrast, our research concentrates on a simpler reflective model, focusing on high performance. In our model, the reflective mechanisms are not included in the normal flow of control, they are only invoked when needed. The group is now investigating (1) an efficient implementation of their reflective architecture using lightweight components in a COM/C++ environment and (2) the use of component frameworks [PCB00] to manage the development of meta-interfaces in a robust and meaningful way.
COMERA [WL98] (COM Extensible Remote Architecture) provides a framework based on COM that allows users to modify several aspects of the communication middleware at run-time. It relies on the Custom Marshaler interface exported by COM, as well as a componentized architecture design that allows the use of user-specified components. Like in dynamicTAO, by using COMERA, system developers can customize the middleware according to application requirements.
Our work in dynamicTAO is an extension of previous work in reflective middleware carried out by Ashish Singhai in our research group. Singhai developed a prototype of a reflective ORB that could be customized at startup time by selecting policies for real-time invocation, fault-tolerance, and load balancing [SSC97]. His PhD thesis presented Quarterware, a middleware construction technique and a toolkit to help developers build customized middleware systems. Using Quarterware components, one can build communication middleware systems as diverse as MPI and Java RMI [SSC98b,Sin99].
The middleware community is starting to realize that static middleware infrastructures are not appropriate for the highly dynamic environments of the future. A trend towards more flexible middleware architectures could be observed in the recent IFIP/ACM Middleware conference [SC00] and its Workshop on Reflective Middleware [KS00].