Overview comments from Steve RT

Dear Dave/Nick,

apologies for the delay in getting to the overview. I am jotting down 
thoughts as they come and as I go through the document.

Section 1:
"Information Driven. Choreographies describe how participants that take 
part in  choreographies maintain where they are in the choreography by 
recording the state  changes caused by exchanges of information and 
their reactions to them"

and

"Information Alignment. Choreographies allow the participants that take 
part in  choreographies to communicate and synchronize their states and 
the information  they share"

I'm worried about the former because it may require execution semantics 
on a choreography rather than just descriptive behaviour.
I'm also worried about the former because of what it might imply or 
impose on the latter (obviously from the previous comment).

If we require state to be held then suddelny execution of a 
choreography becomes mandated. Can this be inferred and controlled in a 
peer-to-peer environment for the necessary participants such that the 
maintenance of such state is their responsibility? If so how do you see 
a domain of control (i.e. one comapnies boundary) exercising this 
responsibility and how does it get this information from a choreography 
description?

Section 2.1:

You say that an abstract choreogrphy should be able to:

"Where the messages in the choreography should be sent e.g. to a URL"

Should this say URI rather than URL and can this be bound at runtime or 
is it a static URL/URI? I'm think that it should be URI rather than URL 
so that the granularity can be as fine as it needs be and I'm thinking 
that the binding should be dynamic to enable dynamic participation.

You also say that it deal with:

"How the messages are to be secured"

What does secured mean (sounds like a security issue to me ;-)).

Section 2.2:

I guess this is bound to be raised but the issue surround the use of 
XPath applied to message content:

"Rules that express, as far as possible, the conditions that are used 
to control the  sequence of exchange of information,that reference data 
in the messages"

The question is why would we need to dive into this level of detail. If 
we look at a list then we could say that a well behaved list is one in 
which the end of the list can be determined by some observation. In a 
badly behaved list this may not be the case. But I cannot say in all 
honesty that I can think of critical cases in which the former is true 
and the latter is not. Hence I cannot see why we need to move into this 
realm and then become turing complete (with all of the consequences 
that ensue).

Of course you might make the computable distinction that an abstract 
choreography is not executable being a specification and a portable 
choreography being executable. Not sure where that leaves "concrete 
choreographies" though.

That's it for now. I shall of course continue ....

Cheers

Steve T

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.

Received on Wednesday, 17 December 2003 08:57:32 UTC