[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Interesting XML-DIST-APP thread

• To: 'Tim Bray' <tbray@t...>, Gavin Thomas Nicol <gtn@r...>, xml-dev@l...
• Subject: RE: Interesting XML-DIST-APP thread
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Wed, 9 Jan 2002 15:58:45 -0600

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@t...]

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

• Follow-Ups:
  • Re: Interesting XML-DIST-APP thread
    • From: Gavin Thomas Nicol <gtn@r...>

• Prev by Date: Re: [ANN] XML Limerick Competition
• Next by Date: Re: Interesting XML-DIST-APP thread
• Previous by thread: RE: A thought on XLink in PIs for processing directives
• Next by thread: Re: Interesting XML-DIST-APP thread
• Index(es):
  • Date
  • Thread