Studies of Efficiency and Integrity in the OpenORB Reflective Middleware Architecture Gordon S. Blair 1 , Geoff Coulson 2 , Michael Clarke 2 and Nikos Parlavantzas 2 1 Department of Computer Science, University of Tromsø, N-9037 Tromsø, Norway (On leave from Lancaster University). E-mail: gordon@cs.uit.no 2 Distributed Multimedia Research Group, Department of Computing, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K. E-mail: {geoff, mwc, parlavan}@comp.lancs.ac.uk Abstract. Middleware has emerged as an important architectural component in modern distributed systems. However, it is now recognised that established middleware platforms such as CORBA, DCOM and .NET are not flexible enough to meet the needs of emerging distributed applications, featuring for example access to multimedia services and also support for mobile users. In particular, they are not sufficiently configurable and they do not support reconfiguration or longer-term evolution of architectures. Recently, a number of reflective middleware platforms have emerged in an attempt to overcome such problems. Considerable progress has been made, particularly in terms of support for configuration. Major problems remain however, especially in terms of performance and integrity. This paper presents a study of OpenORB v2 with emphasis on these issues. In terms of performance, the design is based on a lightweight reflective component model, based on Microsoft’s COM. It is shown that the resultant OpenORB implementation performs at least as well as commercial ORBs. In terms of integrity, the design also features the use of component frameworks offering a domain specific approach to reconfiguration management. Early experiences indicate that this is a highly promising approach for maintaining integrity of the un derlying middleware platform. Ongoing research is investigating further extensions to the platform including support for group communications. 1. Introduction Middleware has emerged as an important architectural component in modern distributed systems. The role of middleware is to offer a high-level, platform -independent programming model (e.g. object -oriented or component-based) to users, and to mask out problems of distribution. Examples of key middleware platforms include CORBA, DCOM, .NET, and the Java-based series of technologies (RMI, JINI, EJB). Traditionally, such platforms have been deployed (with considerable success) in application domains such as banking and finance as a means of tackling problems of heterogeneity, and also supporting the integration of legacy systems. However, more recently, middleware technologies have been applied in a wider range of areas including safety critical systems, embedded systems, mobile and ubiquitous systems, real-time systems, the computational GRID, etc. Unfortunately, as this diversification proceeds, it is becoming ever more apparent that the middleware technologies mentioned above are not able to support such a diversity of application domains. The main reason for this is the black -box philosophy adopted by existing platforms. In particular, existing middleware platforms offer a fixed service to their users, and it is not possible to view or alter the implementation of this service, i.e. they are closed systems . Inevitably, the platform architecture represents a compromise featuring, e.g. general-purpose protocols and associated management strategies. It is then not possible to configure platforms to meet the needs of more specific target domains. Similarly, it is not possible to reconfigure platforms at run-time as, for example, the underlying environmental conditions fluctuate. Equally, it is difficult to evolve such architectures in the longer-term to meet new application requirements. Middleware designers are aware of this problem and have responded with a number of initiatives. Focusing on CORBA for example, the OMG have introduced a series of platform specifications including Real-time CORBA [OMG01] and Minimal CORBA [OMG01]. These are however specific solutions to specific domains and are not a general solution to this problem. In addition, the Portable Interceptors specification [OMG99] enables the customisation of CORBA platforms by allowing the interception of invocations or replies via pre- or post- processing. Portable interceptors also enable the interception of IOR (Interoperable Object Reference) creation. This is a useful but limited mechanism. For example, it is not possible to add interceptors at arbitrary points in the ORB implementation. Similarly, there is no native support for structured composition or for the dynamic installation of interceptors. It could be argued that the interceptor programmer can enhance the system with such functionality, but this would inevitably result in a proprietary solution. The other notable