W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2002

Re: Choreography and REST

From: Paul Prescod <paul@prescod.net>
Date: Mon, 12 Aug 2002 11:34:56 -0400
Message-ID: <3D57D5A0.B8037406@prescod.net>
To: Christopher B Ferris <chrisfer@us.ibm.com>, www-ws-arch@w3.org

Christopher B Ferris wrote:
> My point was that you claimed that the OMG never felt the need for
>  "choreography".
> I believe that the EDOC RFP belies your claim.


Let's define terms. Choreography is a way of describing the set of
states that a multi-message stateful conversation can go through so that
both participants know in advance what those states are.

Now on to EDOC:

"This RFP solicits proposals for a UML profile that supports the
requirements for 
driving an object-oriented design of an enterprise computing system to
implementation in an enterprise distributed computing environment using
enterprise-class component model." 

 * http://cgi.omg.org/docs/ad/99-03-10.txt

I do not see how the EDOC RFP attempts to address the "choreography
problem". It does not even mention the problem!

Further, I claim that CORBA does not have a choreography problem. Good
CORBA object design will enforce correct choreography in an explicit,
statically-checkable, design-time-available manner. With good CORBA
object design, a standard Java or C# static type checker can prevent you
from calling messages in the wrong order, because choreography is
enforced by the structure of the data and Java/C# type checkers enforce
proper data structures.

Similarly, XML and RDF schema languages can enforce proper data
structures *explicitly*, *at design time* and at runtime so choreography
is not necessary.
"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 Monday, 12 August 2002 11:37:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:36 UTC