Re: WSA constraints

On Wed, Dec 18, 2002 at 08:23:03AM -0700, Champion, Mike wrote:
> > For example, there's an implicit requirement that Web 
> > services will work
> > between companies, which requires the property of "visibility" (unlike
> > working within companies, which doesn't).  We need to identify which
> > constraints of the WSA induce this property.
> > 
> 
> I think this is reasonable, but don't follow completely.  The way I envision
> it, the REST constraints might identify a "bootstrappable" (maybe what you
> mean by "visible") way for Web service providers and consumers to do
> business in a very loosely coupled way.

Yes, I think we're in synch there.  "late/dynamic binding", etc..

>  Of course, that meets some of our
> requirements, but doesn't describe the most typical scenarios in which Web
> services are actually used today.  Thus, we could/should document the REST
> constraints as one aspect of the WSA, with appropriate language about it MAY
> be the optimal approach when its assumptions are met.

Excellent!  I'm happy to start there.

A next step would be to document WSA constraints, right?  The last
time I proposed this[1], I suggested the following constraints as a
starting point;

- layered
- client/server
- XML messages

There was some initial objection to the first two, but I believe I
addressed those concerns.  The third was suggested by DaveO.

> > But I'd like to defer this until we've documented some constraints.
> 
> Perhaps, but induction of what you're proposing from examples would help
> too.

Sure.  Using the lightbulb example from my "REST Compared" presentation
[2], I can reliably coordinate the following tasks with a remote
lightbulb;

1) determining the state of the lightbulb; invoke GET until I get a
response

2) turning the lightbulb on or off; invoke PUT until I get a successful
response

That's a very simple example, as it doesn't use POST, which is the tough
method to deal with because it's not idempotent.  But it's a good start
to describe how tasks can be coordinated, even though individual GET and
PUT messages could be lost.

 [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/thread.html#133
 [2] http://www.markbaker.ca/2002/08/Rest/

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis