Re: Web architecture

Mark,

It seems you're raising a basic architectural point against SOAP while also
invalidating most of the web services work (since before it got that name).
SOAP and everything developed on top of it is providing a generic service
(mostly packaging and transport infrastructure for SOAP itself) to higher
layers in the application stack.  At the SOAP layer, it doesn't know whether
the payload contained will create a purchase order, update one or delete
one.  Higher layers don't know the transport SOAP will use and wouldn't know
when to describe the appropriate HTTP action.  These software design
efficiency arguments are somewhat specious and could be closed by saying
"why not?" if they didn't remove dependencies between the application
layers.  Onward...

Yes, HTTP POST is a wonderful transport for carrying XML and other payloads
to and from your application.  POST has almost always been more appropriate
for dynamic parameters from the client than GET.  Security, privacy
(visibility of sent information) and usability play a big part when systems
start getting used.  While this may not have been the original intent when
HTTP 1.0 (or 0.9) was written, it's how the web is used today.

Even without that rant, what I fail to understand is why POST is
inappropriate for outbound XML documents.  Most of the SOAP messages sent on
the outbound HTTP hop (when using that binding) actually do cause changes at
the receiving end, far beyond notations in the web server log.  They almost
never create new addressable resources at the receiver.  This seems to be
the essence of POST.  While a few trivial cases could be handled through GET
and a few parameters in the URL, trivial web services don't help the
Business Infrastructure needs where ebXML Messaging and D-AG0017 sit.

thanx,
    doug

----- Original Message -----
From: "Mark Baker" <distobj@acm.org>
To: "Krishna Sankar" <ksankar@cisco.com>
Cc: <www-ws-arch@w3.org>
Sent: Thursday, March 14, 2002 9:05 PM
Subject: Web architecture


Hi Krishna,

> Mark,
>
> I fail to understand your issue with ebXML and BTP for that
> matter. They follow SOAP over HTTP. The points you are raising are basic
> to SOAP over HTTP rather than to BTP or ebXML.

That's true.  There are BTP and ebXML specific points, but I think it's
important that the one overriding Web-services/Web architectural mismatch
be addressed before talking about them.

> Also your term "web services protocol" is a little vague. Isn't
> it SOAP/HTTP ? There is no "web services protocol" per se.

Basically anything that isn't a data format. i.e. not WSDL, etc..

> Third, what exactly is wrong ? They use HTTP POST as a transport
> mechanism, which looks Ok to me.

It's not ok if you want to conform to Web architecture.  POST is a
*method*, in the same way that getStockQuote() is a method.

Would you consider it ok if I did this?

getStockQuote( 'getWeatherReport( "OTTAWA" )' )

If not, then consider that when you do;

POST ( "getStockQuote()" )

that you are doing *exactly* the same thing.

> I will lok into the issue of BTP introdicung new application
> semantics. My first impression is "why not". But it is a WAG, I will dig
> into it and think more, in the mean time would appreciate any thoughts.

Introducing new application semantics isn't a bad thing.  But
introducing them in a Web architecture friendly way is difficult because
you're working with *existing* application semantics; those of the Web,
in this case.  These protocols I've seen all assume that they're working
with a clean slate, because they see HTTP as a transport protocol, which
it is not.

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

Received on Friday, 15 March 2002 01:32:31 UTC