Re: Article: Fat protocols slow Web services

Champion, Mike wrote:
 >
 > Yes! My point -- a real question, not a rhetorical one -- is whether
 >  the HTTP/XML/RPC works anywhere near as well in real applications
 > over the wild internet as it does over a tame intranet.

I think that if we're comparing Web Services to Browser Queries then WS
will allow more client-side processing and presentation, and lead to
thinner, text-only messages and shorter response times.


 > The larger issue is whether web services (over the wild world web)
 > can, as a general rule, continue to build on the synchronous/RPC
 > paradigm that has scaled reasonably well from single machines to
 > local area networks to enterprise networks.

[can't say much about this point]

 > Another non-rhetorical question: Do the Microsoft .NET tools that
 > those Visual Basic programmers will be migrating to really assume
 > an underlying synchronousness or can they transparently handle, for
 >  example, an underlying SMTP transport? I would guess that they
 > can, but you may have to write code rather than relying on the GUI
 > and the wizards to do it auto-magically?
 >
I'm sure that SOAP in .NET beta 2 doesn't support SMTP. Funnily enough 
there is support for async, but at the app level rather than at the 
protocol level: if you generate a proxy local client from/for a service, 
you get both  sync and async methods for calling the service.

Another area where application-level async will appear as an issue is in 
web services choreography - both IBM and Microsoft have proposed 
languages for composing multi-WS transactions, though I haven't checked 
that they both allow the specification of parallel as well as sequential 
execution of sub-queries.

Francis.

Received on Thursday, 10 January 2002 10:12:00 UTC