W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

Re: D-AG0017 - Business Infrastructure

From: Mark Baker <distobj@acm.org>
Date: Thu, 14 Mar 2002 23:36:39 -0500 (EST)
Message-Id: <200203150436.XAA13406@markbaker.ca>
To: RogerCutler@chevrontexaco.com ("Cutler, Roger (RogerCutler)")
Cc: www-ws-arch@w3.org
> Note that some of these issues are being addressed, at least to some degree,
> in the OASIS ebXML Messaging Services TC
> (http://www.oasis-open.org/committees/ebxml-msg/
> <http://www.oasis-open.org/committees/ebxml-msg/> ).  There may be some
> questions, however, about whether this work conforms to the W3C vision of
> web architecture (Mark Baker has indicated this but has not specified
> exactly what the issues are) or of completeness.

I don't recall commenting on ebXML messaging, but since you're asking,
yes, it has some major issues too.  Not as many as, say, BTP (since BTP
introduces new application semantics), but still quite a few.

The common issue with virtually all Web services protocol specs out
there today is that they tunnel over POST.  That is, they ignore the
meaning of POST that HTTP assigns, and instead place their own
meaning over top.  That none of these specifications use PUT or GET
is a *major* architectural issue, as GET, PUT, and POST form a kind
of "complete triumvirate" of state transfer operations, capable of
representing any distributed hypermedia state change (or state
inspection, ala GET - plus you need deletion, with DELETE).

To be Web architecture friendly, you have to use POST, even with SOAP,
to *mean* POST.  A side effect of this, is that using SOAP with HTTP and
the default binding in a Web architecture friendly way, requires that
you still use HTTP (and not SOAP - gasp! 8-) for doing GET and PUT to
the same URIs you were POSTing to.

For example, you might POST a SOAP message containing an XML vCard to
http://mysite.org/addressBook in order to add an entry.  Then to view
the address book with the new entry, you just do a GET on it.  A PUT on
the address book would overwrite what was there before, and DELETE
would remove it.

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Thursday, 14 March 2002 23:32:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:55 UTC