Re: Consequences of SOAP GET to Web Services?

I agree with Mark that this is a significant step ...

My reading of the TAG finding is that it unequivocally states that resources are
a fundamental element of the web. And further, that HTTP Get is a fundamental
element of the web resource model.

The TAG also concluded that the Soap 1.2 RPC HTTP binding was creating things
that were equivalent to web resources but were not properly represented as web
resources.

The XMLP WG's response to this focused mostly on the safety aspect of web
resources. Its response provides a mechanism for binding a Soap RPC safe request
as a web resource Get. This is a good thing.

Unfortunately, the XMLP response ignores the broader, and ultimately more
important,  implication of the TAG finding - that a web resource model must be a
fundamental part of a web service model.

If creators of web services and users of web services are restricted to a web
service model without an explicit web resource abstraction, they have been
robbed of a fundamental tool they need to build integratable, extendable
services.

I think this frames one of the major challenges this WG faces - the extension of
the existing web service model to include a web resource model. This web service
resource model will likely be the source of the a priori interfaces noted in
D-AR003.2[5].

XMLP's response is a step in the right direction but it is far from a full
solution. My primary concern is that enough people will think it is good enough
that it will stifle further progress.

-- Mark


Mark Baker wrote:
> 
> All,
> 
> For those of you who don't follow the TAG or the XML Protocol Working
> Group, the TAG recently said[1] that the lack of GET support in the
> default SOAP 1.2 HTTP binding was counter to Web architecture.  The
> implications of this decision, and the resulting response[2] of the XML
> Protocol Working Group, should, IMO, be studied carefully by all
> working groups in the Web Services Activity, and the Web Services
> Architecture Working Group in particular.
> 
> The first and most obvious thing that this means, is that if the
> underlying protocol is HTTP, that a SOAP developer must be aware of
> that fact.  In other words, it is counter to Web architecture to treat
> SOAP as a layer when bound to HTTP, which virtually all SOAP 1.1 based
> Web services do.
> 
> Today, for us, this means that D-AR003.1[3] is incorrect (at least what
> it's intended to mean), and should be rephrased to ensure that the Web
> services reference architecture exposes the semantics of underlying
> application protocols (or at the very least, HTTP GET).  This was also
> *roughly* the conclusion[4] of a recent discussion - with limited input
> by the WG - about this draft requirement.
> 
> This decision also highlights the value of D-AR003.2[5], the recently
> added draft requirement on an "a priori interface".  "GET" is a key
> method of this interface, as are the other HTTP methods that operate on
> resources, plus the "faults" (aka "status codes") that those methods
> return.  I discussed this here[6].
> 
> Going forward, I suggest that this decision has significant consequences
> for our work.  Primary amoungst them, I believe, is that the "assumed
> architecture" that many (most?) WG members have in mind - the one that
> looks like OMA/CORBA - does not have very much to do with Web
> architecture, and any architectural decisions that are made assuming
> that it does, will inevitably meet with objection from the TAG if we
> incorporate them into our work.
> 
> I look forward to some discussion on what other WG members thinks this
> means for us.
> 
>  [1] http://lists.w3.org/Archives/Public/xmlp-comments/2002May/0018
>  [2] http://lists.w3.org/Archives/Member/tag/2002Jun/0006 (member only)
>  [3] http://www.w3.org/2002/ws/arch/2/06/wd-wsa-reqs-20020605.html#AR003.1
>  [4] http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0443
>  [5] http://www.w3.org/2002/ws/arch/2/06/wd-wsa-reqs-20020605.html#AR003.6
>  [6] http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0302
> 
> MB
> --
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com

Received on Friday, 14 June 2002 23:14:02 UTC