By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The Web Services Advisor
(To receive this column in your inbox,
click Edit your Profile and subscribe.).
The very nature of Web services is that the technology communicates across unreliable networks such as the Internet, or between partner networks, which may or may not be reliable. Yet without some way of ensuring that messages are received properly -- or a notification that they weren't -- Web services simply can't function.
So what's the solution? Reliable messaging -- a technology that can make Web services a rock-solid way to automate business processes and run services remotely.
In this first part of a two-part column, we'll look at what reliable messaging is, and why it's important. In the next part, we'll look at the standards war that's currently raging around the technology.
Why is it important?
Why does it matter whether messages can be sent and received reliably? Web services is based on XML messages being sent and received. The most useful Web services will often be those that are the most complex and that rely on many messages being sent and received in a very specific order. That's the way that complex transactions can be built, after all. But what do we mean by messages?
For example, take a simple financial transaction built using a Web service in which a bank customer wants to make a payment from his account. For that simple transaction a series of messages has to be sent and received and in a specific order. The message for making the payment has to be sent and received after a message is sent checking the amount of money in the customer's account.
Now magnify that simple transaction many-fold for most enterprises because complex transactions require far more messages to be sent and received. The messages will be much more intricate and may have very complex dependencies on one another, so that certain processes can't be kicked off until certain previous messages have been sent and acknowledged. Entire complex transactions can fail because a simple message didn't get through. And while it may sound simple to guarantee reliability, it's much more difficult than you might expect.
"Human beings are smart enough to know when something that was supposed to happen didn't succeed, but computers aren't as good at doing that," says Ronald Schmelzer, Senior Analyst of ZapThink. "And with Web services, when you're doing multi-step processing, there are a lot of reasons that things can fail, like a server going down or being too slow, a clogged database, or the Internet being too slow. So you need a way to guarantee reliability."
If that reliability can't be guaranteed, Web services simply won't be used. Dwight Davis, Vice President and Practice Director with Summit Strategies, explains that "Web services are being used to exchange information within companies, and with supply chain partners and for everything from financial transactions to inventory management. Companies can't go very far down the path of doing all this if there isn't reliability."
The problem with protocols
The basic technology behind Web services is XML messages being sent via the SOAP protocol over HTTP. But "there is nothing in SOAP or HTTP that guarantees you that a message is delivered, or that allows a recipient to tell you he's received the message," notes John Kiger, director of product marketing for BEA.
Making reliable messaging more difficult is that messages are sent not just over the notoriously unreliable Internet, but also between partners that use entirely different networking infrastructures.
In the past, companies have relied on proprietary messaging infrastructures to connect applications with one another, Kiger says. But he adds, "The market would much prefer what Web services promises -- a messaging paradigm based on open standards, not proprietary implementations."
And old idea comes back
ZapThink's Schmelzer notes that the idea of reliable messaging is nothing new -- "it has been around since the days of EDI."
But "there are many different ways of handling reliability," he adds. "With Web services, the onus for reliability is put on the document, as it flows across many systems and protocols." The message header can be used to store information that can be used to guarantee reliability, he says.
He adds that reliability does not necessarily mean a guarantee that the message actually made it through, but rather that "both ends of the transaction recognize the same state" of the message, for example, that it did or didn't get through correctly. So there are reliable messaging specifications around things such as the number of retries to attempt sending a message before quitting; once-and-only delivery of messages, so that you don't send credit card information twice, for example; acknowledgement of messages and many others.
The war over standards
For all this to work, there needs to be a single, overriding reliable messaging standard. But this is the Web services world we're talking about, which makes the Balkans look like a unified region. So naturally there are two competing proposals:
- WS-Reliable Messaging, from Microsoft, BEA, IBM and Tibco
- WS-Reliability from Sun, Sonic, Fujitsu, Hitachi, NEC and others.
As you have no doubt guessed, adherents to each of the proposals tout its superiority over the other. So where are both of these proposals today? How are they the same and how do they differ? That's what we'll look at in my next column, so stay tuned.
Continues in Part Two
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 firstname.lastname@example.org.