Middleware Models

There are two types of middleware models: logical and physical.

The logical middleware model depicts how information moves throughout the enterprise conceptually. In contrast, the physical middleware model depicts both the actual method of information movement and the technology employed.

In order to discuss the logical middleware model, we must first discuss point-to-point and many-to-many configurations, as well as synchronous versus asynchronous. Any examination of the physical middleware model requires a discussion of several messaging models.

Middleware can work in a point-to-point as well as many-to-many (including one-to-many) configuration. Each has its advantages and disadvantages.

Point-to-Point Middleware

Point-to-point middleware uses a simple pipe to allow one application to link to another application: Application A links to Application B. When Application A seeks to communicate with Application B, it simply "shouts down" the pipe using a procedure call, or message (see Figure 6.1).

Figure 6.1. Point-to-point middleware.

When compared to other types of middleware, its inability to properly bind more than two applications limits point-to-point middleware. It also lacks any facility for middle-tier processing, such as the ability to house application logic, or the ability to change messages as they flow through the pipe.

There are many examples of point-to-point middleware, including Message-Oriented Middleware (MOM) products (such as MQSeries) and RPCs (such as DCE). While it is possible to link together more than two applications using traditional point-to-point middleware, doing so is generally not a good idea. The purpose of these products is to provide point-to-point solutions, primarily involving only a source and target application. Dealing with more than two applications invites too many complexities. Linking more than two applications with point-to-point middleware requires point-to-point links between all of the applications involved (see Figure 6.2).

Figure 6.2. Point-to-point middleware does not work well with many applications.

The idea behind the point-to-point model should make it clear that it does not represent an effective application integration solution, given that most problem domains require linking many applications. Perhaps more important, in order to share information in this scenario, applications must be linked and information must be brokered through a shared, centralized server. In other words, sharing information requires a message broker, or transactional middleware.

However, as with all things, these disadvantages are somewhat offset by advantages. The great advantage of point-to-point middleware is its simplicity. Linking only one application to another frees the application integration architect and developer from dealing with the complexities of adapting to the differences between many source and target applications.

Many-to-Many Middleware

As its name implies, many-to-many middleware links many applications to many other applications. This capability makes it the best option for application integration. Being the "best option" makes it the obvious trend in middleware. In addition to this capability to link many-to-many, it is also the most powerful logical middleware model, in that it provides both flexibility and applicability to the application integration problem domain.

There are many examples of many-to-many middleware, including integration servers, transactional middleware (application servers and TP monitors), and even distributed objects. Basically, any type of middleware that can deal with more than two source or target applications at the same time is able to support this model (see Figure 6.3).

Figure 6.3. The many-to-many middleware model.

While the advantage of the point-to-point model is its simplicity, the disadvantage of the model is its complexity. Although the current generation of middleware products is becoming better at addressing the complexity of linking together so many systems, much work remains. After all, struggling with this complexity falls primarily on the shoulders of the developer.

Synchronous versus Asynchronous

As noted previously, middleware employs two types of communication mechanisms: asynchronous and synchronous.

Asynchronous middleware moves information between one or many applications in an asynchronous mode that is, the middleware software can decouple itself from the source or target applications. The applications are not dependent on other connected applications for processing. The process that allows this to occur has the application(s) place a message in a queue and then go about its business, waiting for the responses at some later time from the other application(s).

The primary advantage of the asynchronous model is that the middleware will not block the application for processing. Moreover, because the middleware is decoupled from the application, the application can always continue processing, regardless of the state of the other applications.

In contrast, synchronous middleware is tightly coupled to applications. The applications are dependent on the middleware to process one or more function calls at a remote application. As a result, the calling application must halt processing to wait for the remote application to respond. We refer to this middleware as a "blocking" type of middleware.

The disadvantage of the synchronous model rests with the coupling of the application to the middleware and the remote application. Because the application is dependent on the middleware, problems with middleware such as network or remote server problems stop the application from processing. In addition, synchronous middleware eats up bandwidth because several calls must be made across the network in support of a synchronous function call. This disadvantage, and its implications, makes it clear that the asynchronous model is the better application integration solution.

Connection-Oriented and Connectionless

Connection-oriented communication means that two parties connect, exchange messages, and then disconnect. Typically this is a synchronous process, but it can also be asynchronous. Connectionless communication means that the calling program does not enter into a connection with the target process. The receiving application simply acts on the request, responding if required.

Direct Communication

In direct communication, the middleware layer accepts the message from the calling program and passes it directly to the remote program. Either direct or queued communication is used with synchronous processing. Direct is usually synchronous in nature, and queued is usually asynchronous. Most RPC-enabled middleware uses the direct communication model.

Queued Communication

Queued communication generally requires a queue manager to place a message in a queue. The remote application then retrieves the message either shortly after it has been sent, or at any time in the future (barring time-out restrictions). If the calling application requires a response (such as a verification message or data), the information flows back through the queuing mechanism (see Figure 6.4). Most MOM products use queued communication.

Figure 6.4. Queued communication.

The advantage of the queuing communication model over direct communication rests with the fact that the remote program does not need to be active for the calling program to send a message to it. What's more, queuing communication middleware typically does not block either the calling or the remote programs from proceeding with processing.

Publish/Subscribe

Publish/subscribe (pub/sub) frees an application from the need to understand anything about the target application. All it has to do is send the information it desires to share to a destination contained within the pub/sub engine, or broker. The broker then redistributes the information to any interested applications. For example, if a financial application wishes to make all accounts receivable information available to other applications, it would inform the pub/sub engine. The engine would then make it known that this information was available, and any application could subscribe to that topic to obtain accounts receivable information.

In this scenario, the publisher is the provider of the information. Publishers supply information about a topic, but they don't need to understand anything about the applications that are interested in the information (see Figure 6.5). The subscriber is the recipient, or consumer, of the information. The publisher specifies a topic when it publishes the information. The subscriber specifies a topic that they are interested in. In this scenario, the subscriber receives only accounts receivable information.

Figure 6.5. The publish and subscribe model.

Request Response

The request response model is exactly what its name implies. A request is made to an application using request response middleware, and it responds to the request (see Figure 6.6). Examples of request and response middleware include any middleware that can facilitate a response from a request between applications, such as integration servers or application servers.

Figure 6.6. The request response model.

Fire and Forget

The fire and forget model allows the middleware user to "fire off" a message, and then "forget" about it, without worrying about who receives it, or even if the message is ever received. This is another example of an asynchronous approach. The purpose of fire and forget is to allow a source or target application to broadcast specific types of messages to multiple recipients, bypassing auditing and response features. It also allows central servers to fire off messages.