Integration Styles and Messaging





Integration Styles and Messaging

So far, we've considered the issue of object distribution, and have shown how the most common mechanisms in Java have solved this problem. However, as we discussed at the beginning of the chapter, there are many ways to handle program-to-program communication in Java. The general problem of program-to-program communication has been a constant and ongoing source of research, development, and heartache almost since the dawn of the computer age. In particular, five different ways of program integration have risen to the forefront as the most commonly implemented solutions to this problem. Let's examine them so that we can understand the most common, and attractive, alternatives to object distribution in particular situations.

  • File transfer— This was the original means of program-to-program communication, and is still the basis of many mainframe systems. In it, each program works on a physical file (stored, perhaps, on a hard disk, a tape drive, or a stack of punched cards) and then another program will take that file as its input and produce a new file, or modify the file if the storage medium allows it. While this has proven effective for solving many problems, issues of latency and resource contention have usually made it unattractive for today's high-speed, high-volume applications.

  • Shared database— Another popular mechanism derived from the file transfer mechanism is the shared database system. In this solution, database software handles some of the resource contention issues by providing mechanisms for locking and unlocking the data appropriately, and also provides standard mechanisms for creating, deleting, searching, and updating information. However, the latency issue remains even in this solution: Before one program can use information, it must be written to a database (a physical file) by the other program. Shared databases are still a key part of the J2EE standard. It is only through shared databases that we can achieve the scalability of J2EE by allowing entity beans in different JVMs (perhaps in a cloned environment such as is possible in WAS ND) to handle transactions against the same tables simultaneously.

  • Raw data transfer— In this scheme, different programs use a mechanism like a network data transfer protocol (such as TCP/IP sockets) or a physical transfer mechanism (e.g., shared memory) to communicate information between different programs. The drawback of this popular solution is that it requires synchronous communication—each program must wait on the other to complete its request before processing a response. While it is possible to temporarily disconnect the systems, this involves adding significant complexity to the overall system, and leads to programming issues that few programmers are competent to deal with. For example, it is up to the programmer to decide how to guarantee that a message is properly sent and received; the developer must provide retry logic to handle all the cases where the network link is severed, or the request or response was lost in transmission. You might think that raw data transfer is not a part of the J2EE standard, especially since the EJB specification specifically restricts the use of Java sockets within EJBs. However, if you consider that the HTTP protocol fits this definition, you can see that this approach is still a key part of J2EE.

  • RPC— Remote Procedure Call is a way of reducing the complexity of the raw data transfer approach by wrapping the network protocols within a layer of code libraries so it appears to the calling and called programs that a normal procedure call had taken place. RPC is extremely popular, and is the basis of modern systems like CORBA, RMI, and EJB. However, the basic issues of synchronicity and guaranteed delivery still remain, which lead us to the need for yet another data transfer mechanism.

  • Messaging— Messaging is a means of providing high-speed, asynchronous, program-to-program communication with guaranteed delivery. This particular solution is often implemented as a layer of software called Message-Oriented Middleware (MOM).

As compared to the other four communication mechanisms, relatively few developers have had exposure to messaging and MOMs, and developers in general are not familiar with the idioms and peculiarities of this communication's platform. As a result, we have seen many programmers try to use messaging in an inappropriate way, or to develop systems that do not take advantage of the capabilities and strengths of messaging.

1 JMS and MOMs

A simple way to understand what a messaging system does is to consider voice mail (as well as answering machines) for phone calls. Before voice mail, when someone called, if the receiver could not answer, the caller hung up and called back later to see if the receiver would answer. With voice mail, when the receiver does not answer, the caller can leave a message; later, the receiver (at his convenience) can listen to the messages queued in his mailbox. Voice mail enables the caller to leave a message now so that the receiver can listen to it later, which is often a lot easier than trying to get the caller and the receiver on the phone at the same time. Voice mail bundles (at least part of) a phone call into a message and queues it for later; this is essentially how messaging works.

In enterprise computing, messaging makes communication between processes reliable, even when the processes and the connection between them are not.

J2EE defines a standard API for messaging. This is the JMS. There are a number of products available for embedding messaging into and between applications. One of the oldest and best-known messaging products is IBM's WebSphere MQ. WebSphere MQ implements the JMS API. WAS includes a limited version of MQ Series, called WebSphere Embedded Messaging, that allows WebSphere application servers to communicate with other WebSphere application servers, and also allows Java application clients to communicate with WebSphere servers. However, WebSphere Embedded Messaging does not support connection to other programs, such as legacy systems. For that, you should use the WebSphere MQ product, which is fully compatible with WAS.

Besides WebSphere MQ, many other products implement the JMS API, and it is possible to use these products with WAS, but the details of managing that integration are beyond the scope of this book. However, we will discuss how WebSphere EJBs interact with the JMS messaging API in Chapter 27 and show you how to take advantage of asynchronous communication with EJBs.


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows