Re: Article: Fat protocols slow Web services

Great discussion!  Let me see if I understand Kurt what you are saying
is the proper use of Web services.  You are saying that the proper use
of SOAP is to send asynchronous, connectionless messages ... similar to
how we use the postal service.  To take the postal service analogy, we
send a letter (message).  At some point the letter arrives at the
destination.  [To some extent we have control over how fast the letter
arrives - one day express, priority, first class, or regular.]  The
receiver of the letter processes it when he/she has the time.  Perhaps
the receiver may even reply.  Thus, the letter (message) has been sent
in an asynchronous, connectionless fashion.  Is this analogous to the
kind of use that you see for SOAP?  Thus, a SOAP message is sent, and at
some point the message arrives at the destination.  The receiver of the
message will process it when it has time, and then may reply with a
message. The point is that the sender is not halted processing, awaiting
a response.

Thus, the wrong use of SOAP is to expect an instantaneous/real-time
reponse to a message. 

Is this a fair summary?  

You made an interesting statement:

> Asynchronous, message oriented applications have a different design 
> and architecture from stateful, RPC oriented apps. They change the way 
> that coding is done, they change the way that applications are built, 
> and they even alter the expectations of the user base.

Interesting!  Can you elaborate upon the design and architecture of
asynchronous, message-oriented applications, and upon the expectations
of the users of such applications?

/Roger


Kurt Cagle wrote:
> 
> Joshua,
> 
> I don't disagree with your contention. RPCs over WANs in general are bad
> ideas, regardless of whether you're talking about XML, DCOM, RMI or Joe's
> handy brokering service, and over connectionless, asynchronous protocols
> like HTTP they are even worse. My contention here is that the industry is
> moving to an RPC model, though, with the emphasis on technologies like .NET,
> and it's this that gets my eye to twitching. You CAN do .NET calls that are
> message oriented and asynchronous - but that's not what most people are
> hearing; I've heard any number of people saying that they didn't even
> realize you could do asynchronous .NET calls.
> 
> Asynchronous, message oriented applications have a different design and
> architecture from stateful, RPC oriented apps. They change the way that
> coding is done, they change the way that applications are built, and they
> even alter the expectations of the user base. I think .NET is cool
> technology, but I worry that people out there are going to use VB design
> principles to build applications that will have a major negative impact on
> the web itself. If its just a matter of education, that's great, but I don't
> want to see the Internet slow to a crawl as 85% of the developer base learns
> how to build asynchronous messaging applications.
> 
> -- Kurt Cagle
> 
> ----- Original Message -----
> From: "Joshua Allen" <joshuaa@microsoft.com>
> To: "Kurt Cagle" <kurt@kurtcagle.net>; "Roger L. Costello"
> <costello@mitre.org>; <xml-dist-app@w3.org>
> Sent: Tuesday, January 08, 2002 3:56 PM
> Subject: RE: Article: Fat protocols slow Web services
> 
> > 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.
> 
> Take "XML" out of this, and everything you say is still true.
> Synchronous RPC over a WAN is rough, no matter how it is encoded.  I
> don't see any evidence at all that the RPC people wrap with XML is worse
> than the crazy things people do with RMI and DCOM.
> 
> All of the issues you mention are important for *any* synchronous RPC
> system.  Encoding is one of the least important issues in most cases, so
> if you are implying that finding a less "fat" encoding will solve the
> problems you mention, you are misleading people.

Received on Wednesday, 9 January 2002 08:46:41 UTC