RE: Web Service Architecture Usage Scenarios editors copy available

I find this message fairly irregular.  Mark does not speak for the TAG and
the TAG has not even proposed a finding on the relationship between SOAP
1.2, web architecture, and HTTP.   Let me say again, the body that owns the
web architecture has issued no finding that supports Mark's proposals.  The
TAG has certainly not said things like RPC is not web-friendly.  In fact, I
am personally examining RPC as part of TAG work.

Further, each of the fragments listed is a sample, and does not constrain
any new Working Groups.

I do appreciate the time that Mark has taken to review the material, and
offered constructive suggestions.  All the other goals, scenarios,
requirements would be well served with such championing.

However, as one of our main deliverables is quickly delivering charters,
when reviewing the usage scenarios, I think we should be determining things
like:
1. What (high priority) usage scenarios or aspects of existing scenarios are
we missing?
2. What (high priority) requirements are we missing?
3. What requirements/non-requirements do we agree/disagree on?
4. What reasonable candidate technologies are we missing?

There is a better time than present for this, it's later.  This has the
potential to consume a great deal of time, and not result in any new wg
charters.

Cheers,
Dave

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Thursday, May 02, 2002 10:30 AM
> To: David Orchard
> Cc: www-ws-arch@w3.org; www-ws-desc@w3.org
> Subject: Re: Web Service Architecture Usage Scenarios editors copy
> available
>
>
> [redirects set to www-ws-arch]
>
> Wow, thanks for this David and editors.  Very high quality.
>
> It's good to see lots of example SOAP message there, because it makes
> it easier for me to point out examples that are inconsistent with Web
> architecture.  I know I won't be the most popular guy around for doing
> this, but IMO, there's no better time than the present for addressing
> this key part of our charter.
>
> I'll go through them individually, and correct them where I can.
>
> 2.1.2; this is Web architecture unfriendly, because "StockPriceUpdate"
> is a function, rather than a resource representation or data
> object, and
> therefore violates the semantics of any transfer protocol over which
> that message is carried (not just HTTP).
>
> A Web architecture friendly example would be;
>
> <?xml version="1.0" ?>
> <env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
>   <env:Body>
>     <r:StockPrice xmlns:r="http://example.org/2001/06/quotes">
>       <r:Price>34.5</r:Price>
>     </r:StockPrice>
>   </env:Body>
> </env:Envelope>
>
> the notion of "Update" would be reflected, in the case of the use of
> HTTP, by using the PUT method.  Of course, this would require
> a SOAP PUT
> binding.  Also, the company symbol would be removed from the body and
> reflected in the URI that the PUT was invoked upon, for example;
>
>   http://example.org/stockquotes/BigCo/
>
> 2.4.*; these are RPC examples, which are necessarily inconsistent with
> Web architecture.  I suggest removing them.
>
> 2.10.2; as for 2.1.2, these examples violate Web architecture by
> specifying a function in the SOAP body.  As this method is a retrieval
> method, presumably without side effect, they should be using HTTP GET.
> We could either remove them, or if we want to identify the need for a
> SOAP GET binding, we could defer to it for what the example would
> look like.
>
> 2.15.2; even though the details of these messages are not important to
> the example, I believe that all examples should be Web architecture
> friendly.  Perhaps replace it with my corrected example from 2.1.2
> above.
>
> 2.25.2; as for the other examples, "StockNotificationSubscription" is
> a function name, and therefore not Web architecture friendly.  There
> are at least two possible ways to implement this
> functionality in a Web
> architecture friendly manner; if you're interested, I can let
> you know.
>
> The other examples are great.  Many include no body, only headers, and
> those appear fine to me.  I did check them to make sure that they
> weren't stateful; none appeared to be.
>
> Thanks again.
>
> MB
> --
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
>

Received on Thursday, 2 May 2002 15:33:15 UTC