Re: Web Service Architecture Usage Scenarios editors copy available

On Thu, May 02, 2002 at 03:20:17PM -0400, Christopher Ferris wrote:
> <Hat xmlns:wsawg="http://w3.org/2002/ws/arch" type="wsawg:chair" mode="off">
> 
> Some comments.
> 
> Mark Baker wrote:
> 
> <snip/>
>  > binding.  Also, the company symbol would be removed from the body and
>  > reflected in the URI that the PUT was invoked upon, for example;
> 
> I'm not sure that I agree with this. URIs are meant to be opaque. They
> identify a resource, but they don't necessarily themselves carry
> any semantic quality beyond the scheme and authority. Thus, the
> example you cite below, while suggestive of carrying some meaning
> (that the URI identifes a resource that is the stock quote for
> a firm called "BigCo") could just as easily have been:
> 
> 	http://example.com/foo/bar
> or
> 	http://example.com/hsfakfuwli324oyhll

I agree 100%.  When I chose a URI, I was acting in the role of the URI
publisher, not as a URI consumer.  I could have given the latter URI,
but chose to go with something more typical.  Either would work though,
but perhaps using yours would help illustrate this better.

> Sure, the authority knows to map this URI to the resource that
> happens to be BigCo's current stock quote, but that doesn't help
> the holder of the URI without some additional, external help.
> In addition, absent the clue that the URI might provide, the
> representation on its own is meaningless if all it is is the
> quoted price.

To be clearer, we could say that the client has already been provided
that URI by somebody, and that they know what it identifies by the
context in which it was discovered (or by some other knowledge
accumulated in their journeys) not by any knowledge of the structure of
the URI itself.

> Consider that HTML pages have metadata such as <title/> as part
> of the resource representation, why wouldn't the StockQuote include
> 	<r:Symbol>BigCo</r:Symbol>
> ?

It could, so long as the URI also identifies it.  The URI must also be
authoritative.

>  >   http://example.org/stockquotes/BigCo/
>  >
>  > 2.4.*; these are RPC examples, which are necessarily inconsistent with
>  > Web architecture.  I suggest removing them.
> 
> I disagree. People have been doing RPC equivalent things with
> the Web since its inception. The world has not come to a screeching
> halt as a result.  I'll grant that it is possibly sub-optimal
> use of the Web, but the infrastructure doesn't preclude such
> usage, nor for that matter does the architecture. There's a
> reason that the HTTP RFC says things like SHOULD when it
> discusses use of GET and POST.
>
> "You can lead a horse to water..."
> 
> Don't misunderstand, I'm sympathetic to what you are saying, but
> also recognize that it is an imperfect world in which we live
> and we cannot preclude that people will use technologies in
> ways that might seem inconsistent with their design.

I don't disagree, but our charter states that we must cleanly integrate
with Web architecture.  RPC, while "doable" on the Web, cannot be done
in a manner that cleanly integrates with its architecture.

Besides, it's not like there's things that you can do with RPC that
can't be done within the constraints of Web architecture.  So given
that, and our charter directive, I see no need for us to support any
use of SOAP that includes a method in the envelope.

>  > 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.
> 
> I think that rather than remove the use case, having it compared/contrasted
> with a GET binding use case, such that the benefits can be established, etc.
> would be a possibly better approach.

I agree that doing this would be useful, but not in the use cases.

In the examples in the use cases, I believe we should stick to examples
that are consistent with Web architecture.

>  > 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.
> 
> </Hat>
> 
> Please do propose a use case/scenario that describes this.
> 
> <Hat xmlns:wsawg="http://w3.org/2002/ws/arch" type="wsawg:chair" mode="off">

Sure.

MONITOR http://example.org/stockquote/BigCo HTTP/1.1
Host: example.org
Reply-To: http://foo.example.org/BigCoWatch
[blank line]
<monitor xmlns="http://example.org/2001/06/subscribe">
      <Notify>PRICE</Notify>
      <Notify>VOLUME</Notify>
      <Notify>TIMESTAMP</Notify>
      <When>
        <Price range="GreaterThan">100</Price>
      </When>
</monitor>

response;

HTTP/1.1 201 Created
Location: http://example.org/monitors/23434234

At least that's the solution that my company has had deployed for the
last year or so, modulo the syntax for the monitor body; ours is a bit
more complex, as it includes an optional filter rules language.

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 16:27:08 UTC