As middleware has been around for some time, different types have been developed for different applications. The traditional types of middleware have been used for enterprise application integration since the mid 1990s.
Message-oriented middleware (MOM), is specifically built for distributed application development, according to the MOM consortium, which was formed in mid-1993 with the goal of creating standards for messaging middleware.
If a distributed application can tolerate a certain level of time-independent responses, MOM provides the easiest path for creating enterprise and interenterprise distributed systems. MOM also helps create nomadic client/server systems that can accumulate outgoing transactions in queues and do a bulk upload when a connection can be established with an office server.
MOM allows general purpose messages to be exchanged in a client/server system using message queues. Applications communicate over networks by putting messages in queues and getting messages from queues (Figure 2). MOM hides all the underlying communications from applications and typically provides a simple high level API to its services commands.
Figure 2: Two-Way Message Queuing
MOM's messaging and queuing allow clients and servers to communicate across a network without being linked by a private, dedicated, logical connection. The clients and servers can run at different times. Messaging does not impose any constraints on an application's structure: If no response is required, none is sent.
In 1991, the X/Open XTP group published the Distributed Transaction Processing Reference Model (DTPM), which achieved wide acceptance in the industry. The primary purpose of this model is to define the components of a transaction-based system and to locate the interfaces between them. The 1991 model defined three components: application programs, transaction managers, and resource managers (Figure 3).
Figure 3: X/Open XTP DTPM Model - 1991
A resource manager is any piece of software that manages shared resources, for example, a database manager, a persistent queue, or a transactional file system, and allows the updates to its resources to be externally coordinated via a two-phase commit protocol.
A transaction manager is the component that coordinates and controls the resource managers. The transaction manager and resource manager communicate via X/Open's XA interface published in 1991.
TPMs provide a high degree of transactional performance for classic client/server distributed applications, where synchronous communication between the client and server is essential.
In recent years, with the advent of Java, use of component-based systems, and prevalence of XML as an integration language, different types of middleware have evolved.
Components are blobs of intelligence that can live anywhere on a network. They are packaged as binary components that remote clients can access via method invocations. The language and compiler used to create server objects are totally transparent to clients. Clients do not need to know where the distributed component resides or what OS it executes on. It can be in the same process or on a machine that sits across an intergalactic network. In addition, clients do not need to know how the server object is implemented. For example, a server object could be implemented as a set of C++ classes, or it could be implemented with a million lines of existing COBOL code—the client does not know the difference. What the client needs to know is the interface its server object publishes. This interface serves as a binding contract between clients and servers.
The terminology used in components is similar to that used in object-oriented technologies.
A method describes one of the behaviors of a component. A collection of methods is called an interface, which is the main contract between the software component and the client.
A blob of software can support more than one interface. Thus, a component can be regarded as a collection of interfaces supported by some blob of software. This collection of interfaces is called the component type. An instance of a component is a particular instantiation of that component. However, we have to consider what is meant by an instance. As the code for all components is shared between all instances of the component, as is the method mapping to the component methods, the only item unique to an instance is the state. Thus, we define an instance state to be that unique information that an instance needs to keep. In distributed component systems, it was an obvious abstraction to move the client and component software into different processes that could then be distributed on different machines. To permit the communication between the client process and the component process, a surrogate or proxy to each process is used. Thus, the client process contains an instance surrogate with which it communicates. This passes the message to the client surrogate in the component instance component, which passes it to the component instance. Thus, the communication is complete.
As one of the main functions of middleware is application integration, it is not surprising that XML was proposed as a middleware standard. One of these proposed middleware products XMIDDLE (Mascolo, Capra, & Emmerich, 2001) has the following use of XML: XML documents can be semantically associated to trees. The data located on the client systems is formatted as XML trees. The applications on the client devices are enabled to manipulate the XML information through the Document Object Model (DOM) (Apparao, 1998) API, which provides primitives for traversing, adding, and deleting nodes to an XML tree. By its use of XML, XMIDDLE can implement the session and presentation layers on top of standard network protocols, such as UDP or TCP.
However, there are disadvantages and advantages in using XML-based middleware. Some of these are as follows:
Each vendor looks at XML in a different way (a common information exchange mechanism, a database storage format, a format to get metadata under control).
The exchange of XML information generally requires reformatting twice (coming from the source system moved to the target system) and one mapping (different XML objects).
XML does not provide a good database format for medium-to-large data sets. There is a large overhead in information access.
The semantic interpretation of what the data represents is outside the scope of XML.
The movement of text-based documents can prove extremely inefficient but is always possible.
XML is good at providing a format for messaging and protocols.
XML makes sense, because the data is easy to process by the target and the EAI systems.
For these reasons, XML is most commonly considered an Enterprise Application Integration (EAI) tool, rather than middleware, per se.
Java has been in effective use for some seven years now, and with the prolific use of it in application development, it is not surprising that there are many Java-based middleware technologies. Many of these conform to the previous middleware types only in the Java programming language. There is no doubt that despite its somewhat humble start, Java is now mature enough to be of benefit to EAI. It possesses the three necessary criteria of availability, stability, and usability. The Java standards that can be regarded as system interconnectivity are database-oriented (JDBC), interprocess (RMI), message-oriented (JMS) transaction processing (JTS). Of these, the Java Message Server, as it is extensively used in wireless middleware applications and products, will be described in more detail later.