Fielding on SOAP

For those of you not on www-tag, Roy Fielding just made a comment about
SOAP and HTTP that the tunnelists might be interested in.

Forwarded message:
> From www-tag-request@w3.org  Wed Mar 20 19:23:49 2002
> Resent-Date: Wed, 20 Mar 2002 19:16:53 -0500 (EST)
> Resent-Message-Id: <200203210016.TAA04135@www19.w3.org>
> Date: Wed, 20 Mar 2002 16:13:05 -0800
> From: "Roy T. Fielding" <fielding@apache.org>
> To: David Orchard <david.orchard@bea.com>
> Cc: www-tag@w3.org
> Message-ID: <20020320161305.A2012@waka.wakasoft.com>
> References: <20020318224929.A8708@waka.wakasoft.com> <042701c1cfd6$45573a60$420ba8c0@beasys.com>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> In-Reply-To: <042701c1cfd6$45573a60$420ba8c0@beasys.com>
> User-Agent: Mutt/1.3.20i
> Subject: Re: section 1, intro, for review
> Resent-From: www-tag@w3.org
> X-Mailing-List: <www-tag@w3.org> archive/latest/640
> X-Loop: www-tag@w3.org
> Sender: www-tag-request@w3.org
> Resent-Sender: www-tag-request@w3.org
> Precedence: list
> List-Id: <www-tag.w3.org>
> List-Help: <http://www.w3.org/Mail/>
> List-Unsubscribe: <mailto:www-tag-request@w3.org?subject=unsubscribe>
> 
> On Tue, Mar 19, 2002 at 10:12:52PM -0800, David Orchard wrote:
> > Roy,
> > 
> > I'd like to understand your rant a bit more.  This shouldn't be interpreted
> > as agreement, just me seeking understanding.  I think you are saying that if
> > people want to create object-specific interfaces using URIs, XML, HTTP, then
> > they shouldn't call it anything to do with the web.  More like "XML Internet
> > Services" or something like that.  That the notion of a shared information
> > space with well-defined interfaces is core to the web.  Not usage of URIs,
> > HTTP, Markup.  Those are helpful and interesting and good practice and ....
> > but not core to the web.
> 
> It is also core to HTTP.  SOAP is not HTTP compliant because it ships
> actions with the content that contradict the application semantics described
> in the control data of an HTTP message.  That breaks intermediares.
> 
> SOAP over something like BEEP does not suffer from that problem and I would
> call that an XML service on the Internet.
> 
> > Further, attempts to put object interfaces onto the web - like
> > CORBA/DCOM/RMI - failed because they didn't use well-defined interfaces.
> 
> You mean objects interfaces on the Internet, right?
> 
> No, they had very well defined interfaces.  Exceptionally well.  Defined
> so well that they made an application exceedingly fragile to version drift
> and differences between ORBs.  Hence, they did not survive multiple
> organizational boundaries when deployed as application infrastructure.
> 
> > Their "failure" has nothing to do with complexity,
> 
> Complexity was due to object-specific interfaces.
> 
> > lack of implementations,
> 
> They far outnumbered Web implementations at the time.
> 
> > too early to market, binary formats, bootstrap problems, no buy-in across a
> > big enough community or other issues.  I think that this implies that if
> > CORBA/DCOM/RMI had used HTTP PUT/POST/DELETE/GET in a RESTful style, they
> > would have had a much better chance of success.  You said this was the
> > lesson to learn from their failures.
> 
> I think so, yes.  The money placed on CORBA and DCOM, separately, dwarfs
> that spent on the Web.  But CORBA/DCOM/RMI are all distributed object
> architectures, so it wouldn't have made any sense for them to be REST-like.
> REST doesn't use strong typing and focuses on data streams rather than
> parameter values.  They are different beasts.  The point is that we lose
> the properties that makes the Web work when we introduce strong typing,
> object-specific interfaces, etc.
> 
> > Expressed a different way, the web succeeded because it was loosely coupled.
> > The use of well defined interfaces is the essensial element in this loose
> > coupling.  The use of well-defined interfaces allows clients and servers to
> > communicate without knowing the specifics of the resource.  Putting an
> > object interface onto a URI effectively tightly couples the sender/reciever
> > in a way that should never be considered part of the web.  The problem with
> > a non well-defined interface is that the client now has to discover the
> > interface (or whether it's changed) and create/change the sending messages.
> > With well-defined interfaces, the components can talk to each other without
> > this discovery/interface compilation step, which will scale/adapt/perform/be
> > more reliable, etc.
> 
> The difference between well-defined object-specific interfaces and defined
> uniform interfaces is that the latter scales better with intermediaries
> and with unanticipated forms of client.
> 
> ....Roy
> 


-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Wednesday, 20 March 2002 21:15:31 UTC