The Web Services Advisor
(To receive this column in your inbox,
click Edit your Profile and subscribe.).
Continued from Part
If Web services are to be anything but a technological sidenote, the industry needs a reliable way to send messages over unreliable networks like the Internet. Without reliable messaging, Web services simply can't function. But with reliable messaging, Web services can become a rock-solid way to automate business processes and run services remotely.
In this second part of a two-part article, we'll look at two competing proposals for a reliable messaging standard: WS-Reliable Messaging from Microsoft, BEA, IBM and Tibco and WS-Reliability from Sun, Sonic, Fujitsu, Hitachi, NEC and others.
How are they similar?
Before we look at how the standards differ, let's look at their similarities -- which go beyond mere names. Obviously, both proposals aim to ensure reliable messaging. Both agree that reliable messaging does not necessarily guarantee that the message actually makes it from Point A to Point B. According to Ronald Schmelzer, Senior Analyst of ZapThink, the key is that "both ends of the transaction recognize the same state" of the message. For example, both points should agree whether or not the message was received in its entirety.
John Kiger, director of product marketing for BEA, notes that reliable messaging standards revolve largely around "quality of service for message delivery," for example, specifying the delivery of a message at least once, more than once, or exactly once. There are specifications in the standards for the number of retries to attempt sending a message before stopping sending and for once-and-only once delivery of messages. This is so that you don't send credit card information twice, for example.
Both proposals address XML messages sent over SOAP and both use message headers as the way to handle reliable messaging.
But while both standards address the same issues, they do so in different, incompatible ways. A Web service built specifically to use WS-Reliable Messaging will not be able to talk to one built specifically to use WS-Reliability.
Where are the proposals today?
The WS-Reliability proposal from Sun, Sonic, Fujitsu, Hitachi, NEC and others has been with the OASIS standards-setting body for a little over a year and the most recent version of the proposal was released on April 19. (For the latest version, check here.) It builds on the work of previous protocols, notably ebXML (Electronic Business using eXtensible Markup Language).
WS-Reliable Messaging from Microsoft, BEA, IBM and Tibco is being developed by the companies themselves rather than a standards body. (For information about the specification, look here).
It's beyond the scope of this column to address the technical differences between the specifications and as you might guess, there's much disagreement over which is superior. But generally, backers of WS-Reliability claim that their proposal is an open one and is being established by a standards body rather than by individual companies. The very nature of this process, they claim, makes it superior to WS-Reliable Messaging because in an open process overseen by a standards body, the eventual standard will be set by a community, rather than a small group of companies. According to the backers, that means a more solid standard.
WS-Reliable Messaging proponents think their standard will do the most to advance Web services overall, as well as address reliable messaging. They emphasize that the proposal is from companies that were most responsible for pushing the entire Web services architecture and therefore has the best chance to flourish in the marketplace. They also claim that it is more foreward-looking and does a better job of integrating with the entire suite of Web services standards and protocols, including security and authentication standards.
What does the future hold?
So once again, the industry is faced with dueling, incompatible standards and this helps no one. Companies and vendors may be faced with deciding which camp to support, or may have to find a way to support both simultaneously, which can be time-consuming and difficult.
For example, BEA plans to make its products compatible with any messaging standard, including proprietary ones as well as WS-Reliability and WS-Reliable Messaging. But not all companies can do that. As long as there are competing standards, reliable messaging will not be in widespread use.
Not everyone believes that having competing standards is a bad thing, though. In fact, BEA's Kiger believes that it's a sign of the industry's health.
"It's natural in an industry driven by innovation that an initial approach to solving a problem would involve multiple competing proposals," he says. In that way, he believes, the eventual winning proposal will be made stronger by the competition.
So what will be the ultimate outcome and who will decide which will win?
"The ultimate resolution is the marketplace and industry negotiations," Kiger concludes. In his view, even though the process may be a painful one, the two competing standards will eventually lead to a better, more widely accepted standard.
The only issue is how long that will take, and right now it's anyone's guess.
For related Articles and Commentary:
About the Author
Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. He can be reached at email@example.com.
This was first published in April 2004