The role of middleware is to ease the task of designing, programming and managing distributed applications by providing a simple, consistent and integrated distributed programming environment. Essentially, middleware is a distributed software layer, or ‘platform’ which abstracts over the complexity and heterogeneity of the underlying distributed environment with its multitude of network technologies, machine architectures, operating systems and programming languages.
Different middleware platforms support different programming models. Perhaps the most popular model is object based middleware in which applications are structured into (potentially distributed) objects that interact via location transparent method invocation.
Prime examples of this type of middleware are the OMG's CORBA and Microsoft's Distributed COM. Both of these platforms offer an interface definition language (IDL) which is used to abstract over the fact that objects can be implemented in any suitable programming language, an object request broker which is responsible for transparently directing method invocations to the appropriate target object, and a set of services (e.g. naming, time, transactions, replication etc.) which further enhance the distributed programming environment.
Not all middleware is object based, however. Two other popular paradigms are event based middleware and message oriented middleware both of which mainly employ ‘single shot’ communications rather than the request-reply style communication found in object based middleware. Event based middleware is particularly suited to the construction of non-centralized distributed applications that must monitor and react to changes in their environment. Examples are process control, Internet news channels and stock tracking. It is claimed that event based middleware has potentially better scaling properties for such applications than object based middleware. Message oriented middleware, on the other hand, is biased toward applications in which messages need to be persistently stored and queued. Workflow and messaging applications are good examples
Middleware has emerged as an important architectural component in modern distributed systems. Its role is to offer users a high-level, platform-independent programming model (object-oriented or component-based) and to hide problems of distribution. Examples of key middleware platforms include CORBA, DCOM, .NET, and the Java-based series of technologies (RMI, Jini, and EJB).
Traditionally, organizations have deployed such platforms (with considerable success) in application domains such as banking and finance to tackle problems of heterogeneity and to support the integration of legacy systems. More recently, middleware technologies have been applied in a wider range of areas and situations, including safety-critical systems, mobile and ubiquitous computing, embedded systems, real-time systems, and the computational Grid. However, it is becoming apparent that current middleware technologies can't support such a diversity of application domains.
We argue that the main reason for this is the black-box philosophy of existing platforms. It is impossible to configure platforms to meet the needs of more specific target domains. Similarly, we can't reconfigure platforms at runtime as the underlying environmental conditions fluctuate. Equally, it is difficult to evolve such architectures in the longer term to meet new application requirements.
A community of researchers is now working on reflective middleware to overcome the limitations of the black-box approach. Reflection has been widely adopted in language design, as witnessed by the Java Core Reflection API and the meta-object protocol defined in the Common Lisp Object System. Reflection is also increasingly being applied to a variety of other areas including operating system design, concurrent languages, and distributed systems. A growing community is working on reflective middleware with the goal of providing a principled (as opposed to ad hoc) way to achieve openness (of the underlying middleware platform). Through a well-defined meta-object protocol, we can achieve the desired properties of configurability, reconfigurability, and more general support for evolution