March 2005 (Vol. 6, No. 3) 1541-4922/05/$26.00 © 2005 IEEE Published by the IEEE Computer Society Toward Nex-Generation Middleware?
A large range of application domains, from real-time embedded systems to grid-computing applications, now require distribution. This trend implies definitions of new or tailored distribution mechanisms dedicated to specific applications and puts a strain on current middleware architectures and development. Crisis and paradox in distributed-systems development Let's define a distribution model as a set of mechanisms to handle distribution—for example, distributed object computing, Remote Procedure Call, and message passing. Middleware specifications such as CORBA or Java Message Service propose the API and protocols to support these models. (For example, CORBA supports distributed object computing, and Java Message Service supports message passing.) Middleware implementations provide the circuitry to build and deploy applications. Because of the increasing number of application domains requiring distribution and the consequent increase in distributed-systems requirements, users might need to extend or restrict a distribution model. Besides, a specific application might require mechanisms such as object persistence, transactional request processing, or light-weight runtimes. Middleware aims to unify and ease the development of an application on top of as general a distribution model as possible. But, in the middleware area, one size doesn't fit all. For example, most applications require only a subset of middleware services; developers should consider lighter, adapted implementations of a distribution model (see www.zeroc.com/iceVsCorba.html for a comparison between the Internet Communications Engine and CORBA). Consequently, middleware requires a partial redesign to match the exact application requirements. We call this the middleware crisis. Distributed applications are becoming increasingly complex, and the reuse of existing distributed components is necessary to reduce development costs. Components might be either legacy components or commercial off-the-shelf (COTS) components. Assembling these components regardless of their distribution models is difficult. Moreover, the multiplication of distribution models doesn't help because components might then come from heterogeneous middleware. Middleware intends to separate an application from variations in hardware and operating systems. This new interoperability problem coming from middleware itself is now a serious industrial issue. We call this the middleware paradox. Next-generation middleware should be versatile enough to instantiate the exact required mechanisms of different distribution models. Middleware components that depend on a specific distribution model should be limited to application-level components or to protocol-level components. Many middleware components should remain unchanged from one instantiation to another. Making middleware versatile In our experience, four main properties characterize middleware versatility: Toward solving the middleware problem Owing to the middleware paradox, middleware design faces a problem similar to that of compiler design or processor architecture in the 1980s. Compiler theory faced a complexity issue owing to the multiplication of programming languages and processor architectures. To solve that problem, most compilers now come with a flexible architecture separating the compilation steps. A front end analyzes source code and interacts, using intermediate representations, with a back end that assembles machine code. Processor design was facing growing instruction sets and thus overly complex implementation. To solve the problem, RISC (reduced-instruction-set computing) processors now come with canonical instruction sets. The saved silicon surface lets a chip include more memory or dedicated coprocessor units. The middleware community must propose a solution similar to those we just described. An approach to handling middleware complexity should define a novel architecture based on a set of canonical middleware components. Figure 1 illustrates one possible architecture. Figure 1. Overview of a middleware architecture. Middleware offers two interfaces. The upper interface implements the distribution model and is used by the application components. The lower interface consists of communication management and enables interactions with remote nodes. So, the middleware could rely on a core set of fundamental components that handle more sophisticated components such as those implementing the application and protocol interfaces. This coarse-grain level supports both genericity and interoperability: The middleware core is classically organized around a scheduler that manages all the middleware components. At this fine-grain level, configuration and quality confidence are easier to achieve: Researchers around the world have been experimenting with all the principles we've presented here. One of the first experiments, Quarterware, 6 defines a set of design patterns that, once specialized and assembled, implement CORBA , remote method invocation, or message passing interface distribution models. Artix (www.iona.com/products/artix) is a commercial product that intends to make interoperable numerous existing systems, representing multiple generations of architecture and technology. PolyORB (http://polyorb.objectweb.org/) is free software that tackles behavioral and architectural modeling issues. We think that such research is becoming one of the main trends in the middleware community. References
| ||||||||||||||||||||||||||||||||||||||||||||
DOWNLOAD PDF 
Configurability lets you adapt an infrastructure to an application's real needs. A classical approach consists of defining an architecture in which loosely coupled components are separately configurable. The designer inserts properties into, or withdraws them from, the targeted middleware. 
