Types of Middleware

The evolution of middleware is changing many of the identifying features that had once made categorizing middleware such a straightforward task. For example, many MOM products now perform publish and subscribe tasks, provide transactional features, and host application logic. The challenge of appropriately categorizing such a product should be plainly evident.

However, even as we acknowledge the difficulty in categorizing middleware, we note that several types of middleware continue to solve particular types of problems. For the purposes of our application integration discussion, we will describe RPCs, MOM, distributed objects, database-oriented middleware, transactional middleware (including TP monitors and application servers), and integration servers (see Figure 6.7).

Figure 6.7. There are many types of middleware, each solving its own set of problems.

RPCs

RPCs are the oldest type of middleware. They are also the easiest to understand and use. They provide developers with the ability to invoke a function within one program and have that function execute within another program on a remote machine (see Figure 6.8). To the developer, the function executes locally. The fact that it is actually carried out on a remote computer is hidden.

Figure 6.8. RPCs allow local function calls to execute on remote computers.

RPCs are synchronous (see the discussion of synchronous functions in the section "Synchronous versus Asynchronous" above). In order to carry out an RPC, the RPC must stop the execution of the program. This quality is what defines RPCs as "blocking middleware." They also require more bandwidth than other types of middleware products because carrying out a remote procedure call requires so much "overhead."

Over the years, RPCs have become a commodity product. For example, most UNIX systems ship RPC development libraries and tools as part of the base operating system. The best known type of RPC is the Distributed Computing Environment (DCE) from the Open Software Foundation (OSF), now the Open Group.

DCE provides a very sophisticated distributed RPC mechanism with many layers of services (such as security, directory, and the ability to maintain integrity between applications). Performance has been a problem with DCE, although the DCE RPC performs as fast as any other RPC. Until quite recently, it worked faster than most implementations of Internet Inter-ORB Protocol (IIOP). The problems are that the DCE directory (Cell Directory Service, or CDS) is not scalable, and administration of a DCE environment can be real ugly. Moreover, for DCE to be effective, it really needs to be deployed everywhere. Very few firms were willing to make a total commitment to DCE.

Despite their simplicity, most RPCs are not well-performing middleware products. To function well, RPCs demand a tremendous level of processing power. Furthermore, many exchanges must take place across a network to carry out a request. As a result, they "suck the life" from a network or a computer system. A typical RPC may require 24 distinct steps to complete requests in addition to several calls across the network. This level of performance limits the benefits of making RPC calls across slower networks, such as the Internet.

RPCs require 10,000 to 15,000 instructions to process a remote request. That's several hundred times the cost of a local procedure call (a simple function call). As is the case with DCE, the RPC software must also make requests to security services to control access to remote applications. Calls to naming services and translation services may be required, as well. All of this inevitably adds to the already-bloated overhead of RPCs.

As we've noted, the advantage of RPCs is simplicity of the mechanism and the programming. However, when this simplicity is weighed against RPCs' huge performance cost and inability to scale well (unless combined with other middleware mechanisms, such as a TP monitor or message-queuing middleware) it doesn't seem to be such a tremendous benefit.

RPCs are bundled into so many products and technologies that it's difficult to know when they are in use. For example, CORBA-compliant distributed objects are nothing more than an additional layer on top of an RPC. As a result, they rely on synchronous connections to communicate object-to-object (although they now deploy messaging and transaction services as part of the standard). This additional layer translates directly to additional overhead when processing a request between two or more distributed objects.

This structure is the reason distributed objects, although architecturally elegant, generally don't scale, or provide good performance. The Object Management Group (OMG), the consortium of vendors that created CORBA, along with CORBA vendors, are working to solve the performance problem.

Message-Oriented Middleware

RPCs' shortcomings resulted in the creation of MOM to address those shortcomings by the use of messaging. Traditional MOM is queuing software that uses messages byte-sized units of information that move between applications as a mechanism to move information from point to point.

Because MOM uses the notion of messages to communicate between applications, direct coupling with the middleware mechanism and the application is not required. MOM products rely on an asynchronous paradigm.

The asynchronous model allows the application to function independently, that is, to continue processing after making a middleware service request. The message is dispatched to a queue manager, which ascertains that the message is delivered to its final destination. Messages returning to the calling application are handled when the calling application finds the time (see Figure 6.9).

Figure 6.9. Message-oriented middleware does not stop the application from processing.

Unlike the synchronous paradigm, the asynchronous paradigm does not block the application from processing. Although this model is more complex than the synchronous model, it is more convenient for developers and users. In addition, MOM can ensure delivery of a message from one application to the next for several sophisticated mechanisms, such as message persistence.

Developers find that MOM's use of messages is relatively easy to manage. Messages have a structure (a schema) and content (data). It is possible to think of them as little, one-record databases that move between applications through message-passing mechanisms.

There are two models supported by MOM: point-to-point and message queuing (MQ) the second being our primary focus here.

MQ has a number of performance advantages over standard RPCs. MQ lets each participating program proceed at its own pace, without interruption from the middleware layer. As a result, the calling program can post a message to the queue and then "get on with its life." If a response is required, it can get it from the queue later. MQ allows programs to broadcast the same message to many remote programs without having to wait for the remote programs to be up and running.

Because MQ software (e.g., IBM's MQSeries, or Microsoft's MSMQ) manages the distribution of messages from one program to the next (although the program is responsible for putting and pulling messages from the queue), the queue manager can optimize performance by such methods as prioritization, load balancing, and thread pooling.

There is little danger of messages being lost during a network or system failure. Most MQ software allows messages to be declared as persistent or stored to disk during a commit at certain intervals. This ensures recovery from such situations.

Distributed Objects

Distributed objects are classified as middleware because they facilitate interapplication communication. However, they are also mechanisms for application development (in an example of the "middleware paradox"), providing enabling technology for enterprise, or enterprise-wide method sharing. In fact, distributed objects are small application programs that use standard interfaces and protocols to communicate with one another (see Figure 6.10). For example, developers may create a CORBA-compliant distributed object that runs on a UNIX server, and another CORBA-compliant distributed object that runs on an NT server. Because both objects are created using a standard (in this case, CORBA), and both objects use a standard communication protocol (in this case, IIOP), then the objects should be able to exchange information and carry out application functions by invoking each other's methods.

Figure 6.10. Using distributed objects.

There are two types of distributed objects on the market today: CORBA and Component Object Model (COM). CORBA, created by the OMG in 1991, is more a standard than a technology. It provides specifications that outline the rules that developers should follow when creating a CORBA-compliant distributed object. CORBA is heterogeneous, with CORBA-compliant distributed objects available on most platforms.

COM is a Microsoft-promoted distributed object standard. Like CORBA, COM provides "the rules of the road" for developers who create COM-enabled distributed objects. These rules include interface standards and communication protocols. While there are COM-enabled objects on non-Windows platforms, COM must be considered native to the Windows operating environment, and therefore homogeneous in nature.

Database-Oriented Middleware

Database-oriented middleware is any middleware that facilitates communication with a database, whether from an application or between databases. Developers typically use database-oriented middleware as a mechanism to extract information from either local or remote databases. For example, in order to extract information residing within an Oracle database, the developer may invoke database-oriented middleware to log onto the database, request information, and process the information that has been extracted from the database (see Figure 6.11).

Figure 6.11. Database-oriented middleware.

Database-oriented middleware works with two basic database types: Call-Level Interfaces (CLIs) and native database middleware.

While CLIs are common APIs that span several types of databases, providing access to any number of databases through a well-defined common interface, most often we find them working with relational databases. Such is the case with Microsoft's Open Database Connectivity (ODBC). ODBC exposes a single interface in order to facilitate access to a database. It then uses drivers to accommodate differences between the databases. ODBC also provides simultaneous, multiple-database access to the same interface in the ODBC architecture, a driver manager can load and unload drivers to facilitate communication between the different databases (e.g., Oracle, Informix, and DB2).

JavaSoft's JDBC is another example of a CLI. JDBC is an interface standard that uses a single set of Java methods to facilitate access to multiple databases. JDBC is very much like ODBC, providing access to any number of databases, and it works from any Java application: applet, servlet, JSP, Enterprise JavaBean (EJB), or standalone application.

Transaction-Oriented Middleware

Transactional middleware, such as TP monitors and application servers, does a commendable job of coordinating information movement and method sharing between many different resources. However, while the transactional paradigm they employ provides an excellent mechanism for method sharing, it is not as effective as simple information sharing the primary goal of application integration. For example, transactional middleware tends to create a tightly coupled application integration solution, while messaging solutions tend to be more cohesive in nature. In addition, in order to take advantage of transactional middleware, the source and target applications have to be changed.

TP Monitors

In truth, TP monitors are first-generation application servers as well as transactional middleware products. They provide a mechanism to facilitate the communication between two or more applications (see Figure 6.12), as well as a location for application logic. Examples of TP monitors include Tuxedo from BEA Systems, MTS from Microsoft, and CICS from IBM. These products have a long, successful history and continue to process billions of transactions a day.

Figure 6.12. TP monitor.

TP monitors (and application servers) are based on the concept of a transaction a unit of work with a beginning and an end. The reasoning here is that if the application logic is encapsulated within a transaction, then the transaction either completes or is rolled back completely. If the transaction has been updating remote resources, such as databases and queues, then they, too, will be rolled back if a problem occurs.

Transactions have the advantage of being able to break an application into smaller portions and then invoke those transactions to carry out the bidding of the user, or another connected system. Because transactions are small units of work, they are easily managed and processed within the TP monitor environment. By sharing the processing of these transactions among other connected TP monitors, TP monitors provide enhanced scalability. They can also perform scalability "tricks," such as threading and database connection pooling.

There are two major services performed by the TP monitor. On the one side, a TP monitor provides services that guarantee the integrity of transactions (a transaction service). On the other side, a TP monitor provides resource management and run-time management services (an application service). The two services are orthogonal.

TP monitors provide connectors to resources such as databases, other applications, and queues. These connectors are typically low-level connectors that require some sophisticated application development in order to communicate with these various resources. Once connected, these resources are integrated into the transaction and leveraged as part of the transaction. As a result, they can also recover if a failure occurs.

TP monitors are unequaled when it comes to supporting a high transaction processing load and many clients. They take advantage of queued input buffers to protect against peaks in the workload. If the load increases, the engine is able to press on without a loss in response time. TP monitors can also use priority scheduling to prioritize messages and support server threads, thus saving on the overhead of heavyweight processes. Finally, the load-balancing mechanisms of TP monitors guarantee that no single process takes on an excessive load.

By taking advantage of these features, an application can provide performance as well as availability and scalability.

TP monitors provide queuing, routing, and messaging features, all of which enable distributed application developers to bypass the TP monitor's transactional features. As a result, priorities can be assigned to classes of messages, letting the higher-priority messages receive server resources first.

TP monitors' greatest performance value is in their load-balancing feature, which allows them to respond gracefully to a barrage of transactions. A perfect example of this advantage is end-of-the-month processing. As demand increases, the transaction manager launches more server processes to handle the load even as it kills processes that are no longer required. In addition, the manager can spread the processing load among the processes as the transaction requests occur.