November 29, 1999

Printer ready

Java Messaging Ensures Data Delivery
When it absolutely, positively has to get there, a jms server may be the answer

By Alexandra Barrett

Related links from our sister publications:

InternetWeek Middleware Gets Distributed Touch InternetWeek AlliedSignal Learns From Java Mistakes

here the transmission of business data is concerned, keeping your fingers crossed and hoping for the best just isn't good enough. If a company has gone to the trouble of linking its distributed systems so those systems can communicate, it's a safe bet that the data actually has to get where it was meant to go. Unfortunately, communications can and do break down, and while communication failure should never jeopardize data integrity in a well-designed system, repeated rollbacks take their toll in time, system load, and user patience.

When application developers can't afford "maybe" for an answer, one technology they turn to is messaging, usually in the form of message-oriented middleware. Messaging is relatively easy to implement and gives developers a straightforward guarantee that data transmitted between two processes was in fact sent and received, and in the order in which the messages were intended.

The idea behind messaging is simple: Between two or more distributed programs that need to communicate, you install an intermediary to which these processes send data in the form of discrete, one-way packages of information. Rather than letting the processes communicate directly, the intermediary stores these information packages--messages--and forwards them to the proper destination at the proper time. The intermediary, the message broker, is responsible for ensuring that the messages are indeed sent and received.

This is called asynchronous communication, because while the processes are communicating, they aren't doing it in real time. Contrast asynchronous messaging with other distributed programming models, such as Microsoft's Distributed Component Object Model, Corba, Java Remote Method Invocation, or remote procedure calls. These models let one process simultaneously and directly send and receive data to and from another process.

One of asynchronous messaging's main advantages is that in the event of application, system, or network failure, communication between applications is not compromised, it's simply postponed. The message broker will try to send the message until it receives confirmation from the destination process that the message has arrived.

This is especially important in today's networked world, where notebook PCs or handheld devices frequently go offline or the network itself becomes unavailable. Compare this with old standby remote procedure calls, where communication fails completely if one of the services becomes unavailable.

"The gorgeous thing about messaging is that it is so fundamentally simple," says George Kassabgi, VP of marketing and sales for Progress Software Corp. "I believe it is possible to successfully explain messaging to a 12-year-old."

Developers involved in application integration have been quick to latch onto the simplicity of messaging. Venerable message-oriented middleware products such as IBM's MQSeries have long been a staple of enterprise application integration projects.

Until recently, however, Java developers have not had a portable application programming interface for message-based communications, nor have independent software vendors had a standard Java messaging specification to work to. Fortunately for them, Sun Microsystems in mid-1998 rolled out the Java Message Service to fulfill those needs. The company is including JMS in its Java 2, Enterprise Edition, platform, which it plans to launch officially next week at the Java Business Conference in New York.

Increasingly, developers are favoring products based on the JMS API in lieu of more tried-and-true messaging fare. JMS has inspired a number of messaging products, including SonicMQ from Progress Software, FioranoMQ by Fiorano Software, and Sun's Java Message Queue, set to be released by year's end.

Java application server vendors are also building JMS compatibility into their products as part of their efforts to attain Java 2, Enterprise Edition, compliance. These vendors include BEA Systems Inc. and Bluestone Software Inc.

continued...page 2, 3, 4

Illustration by Matt Foster

Back to This Week's Issue
Send Us Your Feedback
Top of the Page

---