Selecting a Communication Method - How to be a Successful Technical Architect for J2EE Applications

Asynchronous Communication

Asynchronous communication is typically implemented via messaging technologies, known in the Java world as JMS. You can also use asynchronous communication for broadcasts, commonly known as publish/subscribe capability. That is, you can send a message to any number of applications that care to listen. The message content is usually informational rather than some type of processing instruction.

Depending on your messaging vendor, messaging can be platform independent. Most of my clients use IBM's MQ/Series. MQ has client interfaces for most platforms and would be a viable choice for communicating between a Windows .Net application and a J2EE application, for example.

Messaging technologies have very loose coupling. Applications can generally make any technology change the way they want to without affecting messaging interfaces, as long as they continue to support the message transmission protocol and format. For example, you could convert one of the applications from COBOL to Java without requiring any changes to other message senders or receivers.

Synchronous Communication

Although you can implement synchronous communication with messaging, it is more common to implement it using Web services: RMI/EJB, CORBA, or HTTP. If you use messaging for synchronous communication, it is generally point-to-point, not any type of broadcast. Synchronous communication is generally configured to generate an error if the external application is not available and structured to require a response. You can think of synchronous communication as an external call. Web services are just different ways to structure that call.

Using messaging in a synchronous fashion confuses some people, but it is common in the healthcare industry. I've also seen it used in utility companies as well. Consider the following example of how a purchasing system uses synchronous messaging to obtain available credit information from an accounting application:

1. The purchasing system creates an XML document containing instructions to return the amount of credit available to a specific customer.

2. The purchasing system sends this XML document as a message to a specific queue monitored by the accounting application.

3. The purchasing system waits for a response from the accounting application.

4. The accounting application receives the message, parses the XML text, and obtains the needed credit information.

5. The accounting application creates an XML document with the credit information and responds to the message received, incorporating the XML text in the response.

6. The purchasing system receives the response, parses the XML document created by the accounting application, and continues processing.

Increasingly, Web services are being used for synchronous communication. The primary advantages of Web services are (1) they are platform independent to the point that the external application platform is not relevant, and (2) they are more loosely coupled than CORBA or RMI/EJB calls. Web services are a good choice for synchronously communicating with non-Java applications (such as .Net applications).

Using HTTP to communicate with another application has similar advantages and disadvantages to using Web services because they both use HTTP. HTTP communication does require that you adopt some type of application protocol because it doesn't natively use SOAP.

To understand the concept of using HTTP as a communication method, consider the following example of a purchasing application using HTTP to request information from an inventory management system:

1. The purchasing application issues an HTTP request (using java.net.URL) to the inventory application requesting current inventory levels for an item (e.g., laundry detergent).

2. A servlet in the inventory management system receives the request and initiates processing.

3. The inventory management system examines its database and determines the quantity of the requested item available at all warehouses.

4. The inventory management system constructs an XML document containing the quantity information.

5. The servlet in the inventory management system returns the XML document to the caller in the same way it would return HTML to a browser.

6. The purchasing application receives the XML document, parses it, and continues processing using the inventory information received.

In this example, the XML format used must have the same design as XML used with messaging technologies.

CORBA allows external calls to applications written on any platform that supports CORBA. In this sense, CORBA is more platform independent than is RMI/EJB but less independent than Web services or HTTP. CORBA is also slightly more mature than Web services or RMI/EJB.

Both RMI services and J2EE enterprise beans are restricted to Java applications. This tight coupling between applications can create deployment difficulties because both applications need to use compatible versions of common classes to avoid marshalling errors.

All types of synchronous communication require an error-processing strategy if the external application is unavailable or a transaction cannot be processed properly. Your options are either to produce an error or to develop a mechanism within your own application to retry later. I prefer the latter when possible because, although this does introduce complexity into the application, the administrative overhead dealing with outages is too high otherwise.

Comparing the Two Methods

Let's look at some examples of each method. If you send a synchronous message or call another application, giving it an instruction to do something for a customer, your application waits for that transmission to occur before continuing processing. Consequently, your application will know when there is a communication failure. If a response is expected, your application will know when processing errors occur with the request. Unfortunately, because your application is waiting for the communication and possibly a response, there is a portion of application performance you don't control.

If you sent the same message asynchronously, your application would not wait for the communication. Because the communication physically happens after an application initiates it, it often appears faster than synchronous communication. And asynchronous communication is more fault tolerant. If the target application is temporarily down, the message will be delivered automatically when that application comes back up, with no manual intervention. The disadvantage is that asynchronous communication cannot detect processing errors and does not know when your transaction will be physically processed.

Table 4.1 summarizes the features of each method.

Common Mistakes

Using databases and file systems as "message brokers." This error-prone strategy consists of writing a row in a database table (or file in a file system) with the contents of a message. The second part to the strategy is writing an agent that "polls" the database (or file system) for new messages to arrive, reads and processes the message content, and then deletes the row or file.

In essence, this strategy is akin to writing your own messaging system. It is typically a frequent source of bugs. Why reinvent the wheel? Choose one of the existing forms of communication and concentrate on business logic, not low-level communication programming.

Using an asynchronous communication method, such as messaging, when a response is required. With this strategy, your application sends an asynchronous message to another application and waits for a return message from that application.

Using asynchronous communication when responses are required puts you in the position of programming an algorithm to wait for a response. How long do you wait? If you wait too long, you could be holding up a user. If you don't wait long enough, you could mistakenly report an error. This is akin to two blindfolded people trying to find each other in a vacuum.

As asynchronous messaging requires messaging software, using asynchronous communication when a response is required adds components and complexity to the application. Although messaging technologies are robust and stable, synchronous communication methods are less vulnerable to unplanned outages.