Re: Definition of Choreography

David Orchard wrote:
> Bob,
> 
> This is a classic religious argument.  In the same way there are religious
> battles over big-endian vs little-endian, strongly-typed vs weakly-typed,
> interpreted vs compiled, etc., there will be battles of "condition based" vs
> "explicit ordering".

Actually, I don't think that any of these are religious battles. I think 
that there are times and places for all of these techniques. Hardly 
anyone thinks that we should use strongly-typed languages embedded in 
web pages or interpreted languages for database engines. That's why we 
have to come back to use cases.

> ...  While it is certainly true that condition based can
> meet all the ordering requirements, there is an issue around usability.  For
> example, I think coding up JSPs (explicit ordering) is about twice as easy
> as XSLT (mostly condition based).

I hope you realize that

  a) that is at best a VERY ROUGH analogy
  b) I don't think that XSLT and JSP are better than each other. I think 
that XSLT fits some problem domains better and JSP fits others.

Now if there are problems that choreography languages are better for, 
all we need to do is describe them.

> ...  And I also have a metric that every time
> you double the complexity, you lose 90% of the developers.  

I strongly agree. So that's why I'm wondering how is:

preconditions + postconditions + state machines

better (simpler, faster, in ANY WAY BETTER) than

preconditions + postconditions

I don't get it.

 >... This is the
> major reason why I'm not a big fan of condition based pipelines for xml or
> web service processing models.  It's only pretty advanced developers that
> use ANT and Makefiles, as yet another example.  

Now I see part of the communication problem. You are thinking of the 
choreography language as being the specification for how to describe the 
implementation of processes. "If X, do Y. Then do Z."

But many of us are thinking that that is purely an internal matter and 
the choreography language merely expresses the external preconditions, 
postconditions and state transitions. "You can invoke this operation if 
and only if you are in state A and provide datum B. The decision of 
whether to invoke this operation or another one is entirely up to you."

 > ... I tend to think this is a
> major reason why lisp and prolog didn't conquer the world compared to C,
> C++, Java, VB.  Just debugging prolog is about 10 times as hard!  Don't get
> me wrong, I think that the condition based is a great tool, but it has to be
> acknowledged that there are certain types of users that we want to target
> and understand their capabilities.

The choreography languages ALREADY support preconditions and 
postconditions. Therefore we are talking strictly about simplifying 
them, not making them more complicated. We're talking about stripping 
out the parts that are not necessary for describing the data on the wire:

  a) the internal decisions and business logic of one of the nodes

  b) the ordering of the messages

  Paul Prescod

Received on Saturday, 19 October 2002 20:48:40 UTC