Re: Choreography and REST

On Fri, Aug 09, 2002 at 11:24:20PM -0400, David W. Levine wrote:
> On the face of it, this flies in the face of 40 years of programming 
> evolution.
> Reuse, factoring and composition are based on notions that we can reuse
> chunks of code that perform identical tasks, and that we should actively
> strive to separate unrelated issues. (e.g. message format/content and state
> of conversation.)

I don't see what that has to do with sending different messages.

> This issue become especially cogent in negotiation and flexible choreography
> situations. If two or more web services are engaging in a classic negotiation
> pattern where they iteratively revise their negotiation stances, I may 
> expect to
> see sequences where tens, or even hundreds of identical messages are exchanged,
> differing only in the increasingly long history that led the services to 
> their current
> interaction. Likewise, if a pair of services, at some point in relationship 
> decide they need
> to undertake to follow a mutually understood choreography, I'm somewhat at 
> a loss
> to see how to approach this.

Hmm, are you talking about stateful interactions perhaps?

> >Not really.  Anybody who's written any RDF code has already done this.
> 
> 
> I'll politely observe this is a gross simplification of a rather complex 
> problem.

The problem is indeed complex, but the mechanics of the solution that
RDF provides is pretty simple.

> However, there's a key missing step. A skipped precondition, if you
> will. Before you can conclude that the REST constraints will
> produce a desirable system, you need to determine whether the
> properties from which the REST constraints were derived fully
> match the properties of the system you need.

Granted.  Based on the use cases I've seen for Web services, REST is an
*excellent* fit for *all* of them.  But others should determine this
for themselves, sure.  But ...

> I'd suggest a complementary approach. When one finds that a
> problem seems to be bending the REST constraints, go back and
> try to understand which underlying property is causing the
> problem.

This sounds good, but it's extremely tough because it presupposes an
indepth knowledge of REST.

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, 11 August 2002 10:33:22 UTC