The concepts of middleware were developed in 1990s targeting on the heterogeneity problems, which recognize the needs for more advanced and capable supports to construct effective distributed systems integrating different reusable components and frameworks. Motivated by the network-centric paradigm, middleware takes client/server model to be its basic structure. However, through a decade R&D activities, middleware architecture has been developed to handle tasks far beyond the simple connectivity. Contemporary development with the concept of object-oriented matures the middleware architecture. With some sophisticated programming languages (such as Java and C++), and operating environments (such as POSIX and Java Virtual Machines), different vendors have provided various middlewares, such as Sun Java Remote Method Invocation (RMI), and Microsoft Distributed Component Object Model (DCOM). In general, middleware is regarded as a middle layer between the distributed application and the operating system as illustrated in Figure 1.
Figure 1: Common middleware system architecture
From history point of view, middleware first appeared as a client/server model when making its debut. For example, the Open Software Foundation's Distributed Computing Environment (OSF DCE) fully specifies its remote procedure call (RPC) protocol. An implementation of DCE RPC includes a compiler that translates an interface definition into a client stub, which marshals a procedure call and its parameters into a packet, and a server stub, which unmarshals the packet into a local server call. This concept of RPC is still widely used or at least adopted by today's middleware design. Some more details about RPC can be found in [2]. One nice framework based on RPC is the Transaction Processing (TP) monitors. The main function of a TP monitor is to coordinate the flow of requests between terminals or other devices and application programs that can process the requests. Most customers buy a complete TP system from one system vendor, who is responsible for ensuring that the complete software complement has suitable performance, reliability, usability, etc. Apparently, TP monitor framework is still a bit far from today's middleware architecture as a distributed system. It suffers a big problem of interoperability.
Message Oriented Middleware (MOM) was developed later and has been extensively studied. MOM is still a client/server infrastructure that increases the interoperability, portability, and flexibility of an application by allowing the application to be distributed over multiple heterogeneous platforms. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the application developer from the details of the various operating system and network interfaces- Application Programming Interfaces (APIs) that extend across diverse platforms and networks. MOM framework has the same problem as TP monitor that one MOM implementation is normally incompatible with other MOM implementations. Recent studies in [1] give some inside look at how to choose model and handle message passing as well as some security issues with MOM through a proposed case study. In general, MOM also comes short to satisfy the transparency requirement from the distributed system point of view.
Current state-of-art middleware architecture is designed with the concept of object-oriented (OO). The main influence comes from the maturation of OO model and language. In other words, instead of looking at data packet or message, we are now dealing with objects. The main advantage of cooperating with objects is that the concept of object gives us more flexibility and transparency. On the other hand, a range of quality of service (QoS) needs can be constructed in a more universal level because of the higher level abstraction from OO model. We have realized from our studies that the OO middleware architectures are defined rather in a bottom-up fashion. Specifically, Object Management Group (OMG)'s Common Object Request Broker Architecture (CORBA) was developed before current distributed object computing (DOC) middleware. However, CORBA is only a layer architecture/specification in DOC. DOC is developed based on recognizing additional services from some early middleware such as CORBA, RMI, and DCOM. For this reason, OMG still has some ongoing project to develop CORBAservices to provide more domain-independent middleware services. In this survey, for our understanding purpose, we take a top down process to look at the whole picture. Our description is based on the DOC layer structure as in [9]. The DOC architecture covers almost all major contemporary middlewares from different aspects and some ongoing developing issues related in this field. We also take CORBA and its related developments as our main examples to explain different layers.
Before we get into the details of DOC, it is worth to first point out some issues related with our focus in this survey. Java RMI and Microsoft DCOM are two big players that stem from OO model and language. Note that CORBA is a specification rather than an implementation (see [5] for details). OMG was formed through over 700 corporations and institutions. CORBA is the object management paradigm specified by OMG. Concurrently with CORBA, Sun developed its Java RMI, and Microsoft specified its DCOM. RMI is supported in Java language. DCOM is implemented in Microsoft .NET platform. We notice that both RMI and DCOM contain more detailed specifications on implementations than CORBA does. Another issue in terms of OO is that CORBA is purely OO model based, while RMI and DCOM somehow inherit from RPC to work in an OO fashion. On the other hand, because Sun is a major member in OMG, Java RMI and CORBA are more similar in their architectures than either of them to DCOM. We compare these three in certain level of detail at Section 3 from their specifications.
The rest of the survery is organized as follows. In the next section, we look at the DOC architecture, and describe its layer structure. Each layer is studied with some implementations available on market. Section 3 gives some comparison results from different perspectives among CORBA, RMI, and DCOM. Through the comparison, we explore their pros and cons from middleware architecture point of view. Section 4 takes a look at some design problems of today's middleware, and the future trends of middleware development. Some implementation problems are also studied with some recent proposed approaches, such as aspect-oriented programming [11] [12], horizontal decomposition [13], etc. Finally, We conclude our survey in the last section.