RE: Consequences of SOAP GET to Web Services?

I agree the question of modeling or defining Web services as Web resources
is an important item for further investigation.  I'd have to say though that
the opposite side of the coin is equally, if not more, important -- meaning
that we ensure a sensible mapping of Web services to underlying
implementations.

I don't see Web services succeeding by following either the strict "align
with the Web" or "align with existing distributed computing technologies"
but rather by finding a happy marriage, or a happy medium.  To me that's the
main challenge, and by going too much in one direction or the other we can
just as easily fail.

Eric


-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Mark Hapner
Sent: Friday, June 14, 2002 11:14 PM
To: Mark Baker
Cc: www-ws-arch@w3.org
Subject: 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 Sunday, 16 June 2002 11:58:10 UTC