November 29, 1999

Printer ready

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

Related links from our sister publications:

InternetWeek Middleware Gets Distributed Touch InternetWeek AlliedSignal Learns From Java Mistakes

What attracts developers to JMS? For one thing, JMS is arguably much more than message-oriented middleware simply rewritten in Java. As defined in the Sun specification, JMS has a different take on messaging than most message-oriented middleware servers. Instead of requiring either queue-based, point-to-point messaging or topic-based, publish-and-subscribe messaging among applications, JMS provides similar but separate APIs for both. The advantage for independent software vendors is that they can drop a set of JMS interfaces onto their existing messaging products without having to alter them drastically. Some JMS products will provide both models.

The point-to-point domain is analogous to a typical E-mail in-box. The message sender delivers a message to a specified queue, which is accessed at some later time by a message recipient. With publish-and-subscribe, however, you create message "topics" to which clients can "subscribe." Take, for example, a trading application that lets an investor track selected stocks; the investor chooses a stock to monitor by subscribing to it. The message broker then adds that investor to a list of recipients it will notify if the price changes.

Now compare that process with the average online trading application: To be notified of a change, the investor must manually refresh the page or set up a script that refreshes the page automatically. Known as polling, this continual requesting of information happens regardless of whether there is any change in the stock price, and it can be disastrous in network-centric environments that cater to large user populations, such as the Internet.

"The network traffic wasted by polling is tremendous," Kassabgi says, "yet that's how so many business apps operate these days." To support their polling habit, these growing online trading houses are forced to continually add more and costlier hardware.

It's no surprise, therefore, to hear that startups with their eye on the Internet are turning to JMS for its publish-and-subscribe messaging capabilities. Take 5th Market Inc., a startup that is developing a Java electronic communication network, or "infomediary," for convertible securities. The as-yet-unnamed application lets trading take place in an anonymous, real-time auction format, says CIO Peter Balcarce. Trading takes place over the Internet or private networks, and orders can be contingent on the purchase or sale of other securities.

Publish-and-subscribe messaging, provided by FioranoMQ will let 5th Market scale its electronic communications network to any number of markets and traders. "JMS is a fundamental part of our barter design," Balcarce says. "It's how we get information from the client to the server and back again, whether it's over the Internet or over a private network."

Also, 5th Market takes advantage of FioranoMQ's support for traditional point-to-point messaging. Point-to-point becomes necessary, for example, when establishing a direct connection between a client placing an order and a specific server.

Because they're based on Java, JMS systems benefit from the language's inherent platform independence. Eventually, 5th Market intends to expand its product to include other financial products and trading techniques, such as equity options or swaps. "There are certain fundamental mechanisms that underlie them," Balcarce says.

It is here that the virtues of a Java approach to messaging really begin to shine through. "Our users potentially will run hundreds of different clients. I'm not interested in dictating to them what they should run," Balcarce says. "With Java, those specifics are unimportant to us."

Enterprise application integration professionals also see JMS's advantages. ChanneLinx.com Inc. is a supply-chain integration specialist and veteran of the EAI space. ChanneLinx is using SonicMQ to integrate its eLinx catalog product and WebDI transaction-processing engine.

"We needed the glue to stick these products together," says Michael Quattlebaum, ChanneLinx.com's director of research and development. "We looked at traditional messaging products, but were frustrated by implementation and integration obstacles."

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

Illustration by Matt Foster
Photo of Quattlebaum by Milton Morris

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

---