Re: Choreography and REST

Martin Chapman wrote:
> 
>...
> 
> Maybe I have a different definition of choreography, but CORBA (and COM
> and c++ and java and c#) does have this problem. Given  the following:
> 
> Interface example {
>     void a (in x:string);
>     short b (inout y:short);
>     boolean c(out temp:long);
> };
> 
> How can anything know, and hence statically check, the correct
> invocation order(s)? 

Thank you for coming up with some demonstration code. Consider the
following decomposition which statically and explicitly enforces a
particular correct ordering of method calls:

Interface example {
  b_obj make_b(in x: string):
}

Interface b_obj {
  c_obj make_c(inout y:short);
  example back_to_example(in blah:int);
}

Interface c_obj {
  boolean doit(out temp:long);
}

This decomposition isn't just good because it removes the need for a
choreography language. Indeed, this is a minor benefit. Actually the
decomposition has many more important benefits. Most crucial, the
consumer of the service has much more flexibility about its own
composition. Because b_obj and c_obj are now first-class objects, I can
pass those to any other component anywhere on the Internet and have it
work with them. I don't have to pass a "state" as some kind of flag. To
use WS buzzwords, my relationship with that other component can be more
"loosely bound" because I have less to tell him about what's going on in
the conversation.

Some other c_obj producer could proceed like this:

Interface z_obj {
  c_obj short_cut_to_c_obj();
}

So the relationship between the object types and the choreography is
very flexible and other components brought into the mix care only about
the former and not at all about the latter.

In other words, by decomposing I have better opportunities for reuse of
the c_obj abstraction which translates in networked systems into higher
interoperability and less "glue code".

> ... Aside from unparsable comments
> and documentation (if you're lucky), there is no extra information.
> The fact that the corba community didn't address this problem doesn't
> mean to say it doesn't exist.

The CORBA community doesn't have the problem because it is so easy to
design around and in fact it is common to "solve" it merely as a side
effect of good object design. If you feel you have a concrete case where
this model does not work properly, I would be interested in seeing it.

> What you need to do is augment interface definitions with extra
> information.
> Design by contract is one example, but also there is the excellent work
> done by ANSA in the early 90s called  Path Expressions [1], which people
> are only just re-inventing  (or is that re-discovering:)

Design by contract and path expressions are different than choreography.
I would be much more enthusiastic about "design by contract for web
services" than choreography for web services.
-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.

Received on Tuesday, 13 August 2002 15:26:03 UTC