RE: Article: Fat protocols slow Web services

I agree with you Anne , that the nature of application would truly determine
whether to use asynchronous or synchronous SOAP.
	You may choose to use synchronous messaging for transfer funds because you
want the change to be reflected ASAP. But, what about reliability .. You
will need to worry about that in the application , what if the service is
down , what if the connection is broken, what if your system crashes.  SOAP
over HTTP is not sufficient . Hence it is the underlying protocol which is
important. I think there is a sufficient need to have a reliable HTTP
protocol support.

Regards,
Ravi

--------------------------------------------------------------
import std.disclaimer;
--------------------------------------------------------------




=>-----Original Message-----
=>From: xml-dist-app-request@w3.org
=>[mailto:xml-dist-app-request@w3.org]On
=>Behalf Of Anne Thomas Manes
=>Sent: Wednesday, January 09, 2002 11:37 PM
=>To: Roger L. Costello; Xml-Dist-App@W3. Org
=>Subject: RE: Article: Fat protocols slow Web services
=>
=>
=>I take a different viewpoint. I don't like to make
=>generalizations along the
=>line of "the proper use of SOAP is to send asynchronous,
=>connectionless
=>messages". While I agree that many Web services should be
=>designed using an
=>asynchronous, connectionless architecture, I believe that SOAP can and
=>should be used however people decide to use it. SOAP is
=>simply a messaging
=>envelope. SOAP messages can be sent over a variety of
=>protocols. They can be
=>sent and consumed by pretty much any type of application.
=>
=>Making mandates about the proper use of a technology will
=>generally get
=>ignored by the general public. I remember similar arguments
=>about BTRIEVE.
=>People will use technology wherever that technology can help
=>them solve the
=>problem at hand.
=>
=>Which brings me back to the point I wanted to make: The application
=>architecture that you choose to use should be determined by
=>the requirements
=>of your application. Some applications lend themselves most
=>easily to a
=>request/response architecture, while others favor an
=>asynchronous model.
=>Sometimes you can build your application with either architecture.
=>Sometimes, though, you really need to use one and not the
=>other. (I'm not
=>going to use asynchronous messaging -- regardless of it's
=>reliability -- if
=>I'm transferring funds from one account to another.) What's
=>interesting
=>about SOAP is that it easily supports both models.
=>
=>As I see it, the biggest challenge is that a huge majority of
=>developers
=>have never developed an asynchronous application. Lot's of
=>people who are
=>playing with SOAP and .NET these days are using
=>request/response because
=>it's what's familiar (or it's the only way they know).
=>Meanwhile, all the
=>tools out there are designed to serve this majority, so the
=>tools promote
=>the use of request/response also.
=>
=>Meanwhile, I view the whole premise of this article (the
=>bloated nature of
=>XML) to be completely specious. If we can realistically think
=>about using
=>the Internet to deliver video on demand, then it's ridiculous
=>to talk about
=>the inefficiency of using XML versus a binary encoding system.
=>
=>Regards,
=>Anne
=>
=>> -----Original Message-----
=>> From: xml-dist-app-request@w3.org
=>[mailto:xml-dist-app-request@w3.org]On
=>> Behalf Of Roger L. Costello
=>> Sent: Wednesday, January 09, 2002 5:46 AM
=>> To: xml-dist-app@w3.org
=>> Subject: 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 11:20:17 UTC