OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Interesting XML-DIST-APP thread

[ 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.


-----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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS