Re: Article: Fat protocols slow Web services

This is one of the major Achilles Heels of web services, and one that I've
talked about at length myself in places like the Web Services Developer
Journal. XML works very well in the context of disconnected asynchronous
messaging systems, for a number of reasons:

1) Bursty. Message systems are bursty by their very nature. The size of web
services in this context is not that much of an issue, precisely because it
can be split and routed across multiple connections without any major
performance limitation, and because although such messages may be very
large, they are also infrequent effect that they tend not to clog the pipes.

2) Secure. Performance speed is generally not an issue with messaging
systems, so the cost of encrypting/decrypting such messages doesn't
significantly impact the performance of the interactions.

3) Connectionless. You don't need to maintain a connection with
message-oriented transactions; this means that you don't have pipes sitting
(briefly) idle that are still blocking the transmission because a connection
has not been properly terminated.

4) Deferred Type Conversions. A SOAP server working in an RPC mode must
explicitly convert data from a given type into the XML encoding of that
type, and must similarly convert the encoding back into an object at
instanstiation time on the other side of the pipe, in real time. Messaging
systems defer type conversion to later dedicated queuing in processing as a
decoupled operation.

In general RPC transactions are the obverse of this - you have to maintain a
connection, you have to encrypt/decrypt, you have to perform type
conversions in real time. All of these are highly expensive operations that
limit the ability to scale such systems. Typically, distributed RPCs have
managed to minimize this by creating dedicated clients and servers across a
dedicated (and probably secure) connection, transmitting short binary
requests with binary responses, and to a certain extent raising the barriers
of developing an RPC to the point where a developer would need to have a
very clear-cut idea about what the risks and trade-offs were.

The most recent rise of XML-based RPC web services is worrisome then from a
number of standpoints. SOAP messages ARE big. The current efforts by a
number of vendors are typically expanding the relevant bytes being sent by a
factor of ten, you're adding the overhead of security and type
encoding/decoding, and they are making this technology transparent - drag
and drop the requisite Bean or COM control on your form, and you can start
writing synchronous RPCs without even knowing that you're doing it. This
means that there will be a lot of very badly written web services that, by
themselves, work fine, but overall contribute to the degradation of the
networks.

I guess the best analogy I can think of for this is to imagine that you can
buy a large-wide-bodied pickup truck for the cost of a subcompact car ...
and so can everyone around you. It initially looks great, and you can carry
a lot of stuff in it. Yet it wastes a huge amount of gas, makes it difficult
for traffic to move around it, and can often prove difficult to get into or
out of places. What's worse, as more and more people buy them up, traffic
density actually decreases, because you have fewer trucks able to fit on the
road. Finally, think about the problems inherent in RPC systems that
basically query other servers several dozens of times a second, treating the
connectionless capabilities of HTTP as if it was connected. This is
analogous to the traffic coming out of a large church's parking lot all at
the same time - things slow down at the on ramp, traffic backs up, and
pretty soon no one is going nowhere.

People express a lot of concern about broadband multimedia connections (to
the extent that network adminstrators routinely block multimedia mime-types
because of the way that it degrades performance) but with web services I
suspect that quicktime files will be the least of our worries.

-- Kurt Cagle

Received on Tuesday, 8 January 2002 16:40:54 UTC