InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

November 29, 1999

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

Illustration by Matt Foster

Related links from our sister publications:

InternetWeek Middleware Gets Distributed Touch

InternetWeek AlliedSignal Learns From Java Mistakes
Startup Socketware Inc. is building Accucast, an outbound E-mail marketing service and package. Accucast is designed to deliver 100,000 to 1 million personalized E-mails, so confirmation that Accucast's messages have been sent by the Simple Mail Transfer Protocol servers is critically important. So Socketware turned to FioranoMQ.

"From the get-go, we knew we wanted to go with a pure Java solution. MQSeries looked like it was more expensive than any Java solution out there, not to mention the fact that with JMS, there were no platform issues," says Andrew McConnell, Socketware's chief technology officer. "With JMS, we were able to reduce the risk of investing in messaging technology."

Indeed, smaller companies may have a hard time getting a salesperson from a big vendor even to call them back. "In our experience, small companies can't even get pricing information from [a company the size of] IBM," says Atul Saini, president of Fiorano Software.

And while non-Java solutions tend to display slightly better performance than JMS implementations, many developers say the extra speed isn't worth the additional cost. "It's true, you get slightly better performance out of other message-oriented middleware," says 5th Market's Balcarce, "but it doesn't justify the order of magnitude price differential."

In fact, compared with Java Remote Method Invocation, JMS can provide superior performance in certain situations. According to Saini, as more clients connect to an RMI server, it soon become overloaded. But with a message server based on JMS, as more clients connect to the system, it simply spawns off additional service processors--clients in and of themselves--to balance the server load.

Andrew McConnell Photo by Mark Escher Certainly, to hear the vendors speak of it, JMS's future is bright. Whereas messaging has traditionally been relegated to enterprise application integration tasks, Saini sees Java going much further.

Given the functionality it delivers, JMS is also relatively lightweight--so much so that the notion of a JMS client residing on handheld devices is not out of the question. An embedded JMS client would enable the not-so-futuristic concept of executing trades over a cell phone. "With enough memory, anything is possible," says Bluestone's Bickel.

Analysts are a bit more reserved. "There's definitely a market for JMS products," says Colin Mahoney of the Yankee Group. But whether JMS is really an all-purpose technology that can take the place of traditional message-broker products remains to be seen. "It probably won't be a fit for every application. It really depends on how well point-to-point is implemented."

Programmers, meanwhile, are grounded in the hard realities of coding. According to Ivan Zhidov, lead developer at 5th Market, the best thing a developer can do is to learn the JMS specification to see whether it's the right technology for your project. Once you've determined it is the technology you want, investigate your vendor to see if its implementation is everything you need it to be.

For example, Zhidov says that some JMS products he examined only offered publish and subscribe, whereas his application required point-to-point support as well. And while most agree that message servers benefit from such features as load balancing, fault tolerance, error and advisory notification, administration, and security, these features are not defined by the JMS specification. It's up to vendors to incorporate these features into their products, and up to the customer to make sure they're there.

return to page 1, 2, 3