The Design and Implementation of OpenORB v2

Established middleware platforms such as CORBA and DCOM are not flexible enough to meet the needs of emerging distributed applications. This article discusses the architecture of Open ORB 2, a middleware platform based on reflection and component technology. Middleware has emerged as an important architectural component in modern distributed systems largely because it offers a high-level, platform-independent programming model that helps mask distribution problems. Examples of key middleware platforms include DCE, CORBA, DCOM, .NET, and the Java-based series of technologies, including RMI, Jini, and EJBs (for more information on these platforms, see the Middleware Platforms sidebar). Traditionally, developers have deployed such platforms in areas such as banking and finance to overcome heterogeneity and support the integration of legacy systems. More recently, however, developers have applied middleware technologies in a wider range of areas, including safety-critical, embedded, and real-time systems. It is now becoming apparent that middleware technologies cannot respond to such diverse requirements or technical challenges because of the limitations of the black-box philosophy maintained by developers of most existing middleware platforms. In particular, existing middleware platforms offer fixed services to their users; it is typically impossible to view or alter the implementation of these services. Inevitably, the architecture of this platform then represents a compromise design that features, for example, general-purpose protocols and associated management strategies. It is not possible to specialize platforms to meet the needs of more specific target domains. Other researchers in the field have also recognized these problems.1,2 Middleware designers are aware of these problems and have responded with several initiatives. The Object Management Group, focusing on CORBA, introduced a series of platform specifications that includes real-time CORBA and Minimal CORBA. But these specifications are specific solutions for specific domains, not general solutions to this problem. Modern middleware platforms also typically offer more flexibility through mechanisms such as interceptors and configurable protocol stacks. While these are important developments, they do not offer a complete solution to the problem. We believe next generation middleware platforms should be configurable, to meet the needs of a given application domain, dynamically reconfigurable, to enable the platforms to respond to changes in their environment, and evolvable, to meet the needs of changing platform design. Recently, several reflective middleware technologies have emerged in response to such requirements (see the Related Work sidebar). Reflection is a technology that has previously been deployed successfully in the design of languages and operating systems. The key to the approach is to offer a meta-interface supporting the inspection and adaptation of the underlying virtual machine. In the context of middleware, the meta-interface would support operations to discover the internal operation and structure of the middleware platform (such as the deployed protocols and management structures) and to make changes at runtime. The design of such a meta-interface is central to studies of reflection: The interface should be sufficiently general to permit unanticipated changes to the platform but should also be restricted to prevent the integrity of the system from being destroyed. This article presents the design and implementation of Open ORB, a reflective middleware platform developed at Lancaster University. Specifically, we focus on Open ORB 2, a significant redesign that builds on our experience from the first implementation.3 Note that, for simplicity, we generally refer to Open ORB 2 as simply Open ORB in the rest of this article.