InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

November 29, 1999

Java Messaging Ensures Data Delivery
continued...page 3 of 4

Illustration by Matt Foster

Related links from our sister publications:

InternetWeek Middleware Gets Distributed Touch

InternetWeek AlliedSignal Learns From Java Mistakes
"Then, Sun announced JMS," he recalls. Acting on an existing relationship with Progress Software, ChanneLinx.com agreed to take part in the SonicMQ alpha and beta tests. Within a day, it had a proof-of-concept application in place. "Very quickly, JMS began to change our entire outlook as to what was possible in terms of integration," Quattlebaum says.

Developers who have traditionally done a lot of integration work but don't consider themselves in the integration business are especially pleased by the advent of Java and JMS.

PE Biosystems in Foster City, Calif., develops instruments and analysis software for DNA sequencing, which is used by scientists working on the Human Genome Project. Milt Ratcliff, engineering manager, has devised an architecture based on JMS, Enterprise JavaBeans, and ObjectSpace Workflow that links PE Biosystems' instruments, workstations, and databases. As instruments process samples, they send status information via publish-and-subscribe messages to interested software applications.

"The significance of using Java-based technologies has been far less time spent programming," Ratcliff says. "Prior to Java, this type of project would have been possible, but not feasible." As an example, Ratcliff cites a previous C++ project. About 40% of its 1.3 million lines of code was dedicated to managing the infrastructure now handled by Enterprise JavaBeans, JMS, and Workflow, Ratcliff says, and the platform was not as capable as the ones he is now working on. "Now we can concentrate our talents on doing analysis, not infrastructure."

Another reason to use JMS messaging is the tight integration with Extensible Markup Language parsers some vendors offer.

Many attempts at establishing wide-scale business-to-business relationships have failed. At the heart of the failure has been the difficulty many companies have in complying with one another's data formats. With XML, however, there is no worrying about whether the data you transmit adheres to your business partner's conventions, because the data is self-descriptive. Not only does an XML document contain data--price or due date, for example--but it also contains information about how the data is formatted. Assuming the client machine can parse the XML document, you can start doing business electronically without ever having been introduced to one another's data formatting conventions.

"People have discovered that when you have a loosely coupled application, the appropriate thing to do is to send an XML document back and forth," says Bob Bickel, senior VP of Bluestone Software. "We are concerned mainly with, what is that XML document? But then you also have to address how to get that document across the wire."

Says Progress Software's Kassabgi, "XML doesn't have legs. You still need a transport mechanism to deliver the XML content, which can be either HTTP or messaging."

ChanneLinx.com's Quattlebaum can attest to the advantages of using XML for integration. "We used to have to write to native APIs; now we encode our data using XML, and it takes care of itself." And by transmitting XML via SonicMQ rather than over vanilla HTTP, ChanneLinx derives the added benefit of knowing the data did in fact get where it was heading; HTTP provides no such guarantee.

Technical benefits aside, a recurring JMS theme is the price/performance advantage it wields over competitive messaging technologies. For smaller companies in particular, traditional message brokers such as MQSeries remain largely out of reach.

continued...page 4
return to page 1, 2