Types of Middleware

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.

Distributed Transaction-Processing Monitors

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 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.