[
Lists Home |
Date Index |
Thread Index
]
Doesn't this depend on what a web service is doing? IOW,
load balancing between the service and the requestor of
a service is a bit like design of the enterprise itself;
how much work gets done at a desk by one individual vs
how much work is done by their group, how much by their
organization and so on. My problem is that so far, the
web service examples I've seen discussed are trvial
(eg, a calendar) at one end of the spectrum, and at the
other, almost equivalent to a request for a document
(eg, a coarse transaction such as sending a Request for
Proposal). At the fine grained end, it seems one would
rather replicate onto the client rather than force a
server solution. At the coarse end, one only cares
that the document requested comes back in a reusable
and expected format.
So perhaps the question is, when should one RPC/SOAP
vs replication? It brings up the topic of how one
should architect for web services not at the level
of SOAP, but the actual decomposition of services.
len
-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]
At 10:51 PM 08/01/02 -0500, Gavin Thomas Nicol wrote:
>> "there's an evil little secret about Web services that most vendors
>> don't talk about. Web services' protocols are very fat, and that means
>> that Web services interactions over the network will be slow and eat up
>> a large chunk of bandwidth"
>
>This is pretty well known.
I think this assertion is content-free. What you care about is
the performance of the whole system. What proportion of that
performance is due to the delays in pumping the RPC messages
back and forth, and which proportion is consumed by business
logic at the endpoints of the transaction? When somebody
does some quantitative work showing that in a significant
real-world application, the number is high enough to be a
problem worth addressing, then it's worth addressing.
This kind of thinking goes on all over the place. I call it
the "junior-engineer-deciding-to-code-it-in-assembler-to-make-
it-faster-without-measuring-first" fallacy. -Tim
|
