RE: State Alignment and Standard Signals

Anders
 
My  *personal* view is that defining these types of standard protocols/choreographies is a good idea. However, if the team agrees to doing such protocols, then I think they should be in an Appendix to the main spec, or even a separate spec, with text that says "You don't have to use or even implement these protocols in order to be compliant with CDL, however if you want to use these semantics then use of this protocol is recommended.
 
It's all about interoperability ...
 
David

-----Original Message-----
From: Anders W. Tell [mailto:opensource@toolsmiths.se]
Sent: Sunday, July 18, 2004 5:54 AM
To: Burdett, David; public-ws-chor@w3.org
Cc: tony.fletcher@choreology.com; Robin.Milner@cl.cam.ac.uk; kohei@dcs.qmul.ac.uk; yoshida@doc.ic.ac.uk
Subject: Re: State Alignment and Standard Signals


David,

A would like to add a third type of protocol which is similar to a Business TP but comes from the business and legal world.

a: Contract formation: [propose, withdraw, revoke, accept,reject, late acceptance,...]
    This "protocol" can most likelly be build ontop of,with other data messages + ReciptACK+notice.
    What is also needed are the concepts of Dispatch and Reach-Events and a few channel characteristics.
    In UBAC-project we are going to specify this protocol and its relation to realization technologies.

b. Business Automation (BTP, (UN/CEFACT BPSS, OASIS ebBP,...))
  (rephrasing real state alignment) 

c. Acknowledgement of Receipt, Notice
  (rephrasing signal)
   IMO the early rejection message (acceptance ack signal) is really a data message since it  belong to business automation type of messages.

Note: State alignment is not nessessary condition for a data message to be legally relevant, its happens anyway.

thanks
/anders

david.burdett@commerceone.com wrote:


Tony
 
I thought it might be worthwhile putting on record the comment I made on the call on Tuesday in that I think that there are two different "state alignment" problems to be solved: "real" state alignment, and standard signals.
 
REAL STATE ALIGNMENT
The first is the problem you discuss below that there is a general requirement at various points in a choreography that each participant has a common shared understanding of the state of the other participants in terms of the messages that have (or have not) been received ... I hope I am paraphrasing/simplifying your requirement as described below.
 
STANDARD SIGNALS
The second is the problem that Anders Tell described in his email [1] that I responded to in my email [2]. Anders talks about a need that a recipient of a message "legally" accepts that he has received the message. In this case, the message is more like a signal that informs the sender of the original message what their "state" is with respect to legal acceptance of the message. There are also other signal messages that can occur, for example to indicate that a message has been received, i.e. a simple Ack, or has been "Accepted for Processing" as standards like BPSS suggest.
 
SOLVING THE PROBLEMS
To solve the problem you are suggesting, then we need to continue discussing the state alignment approaches you describe below.
 
To solve Anders problem and also the issues I think Jean-Jacques was raising, we could define some "standard" Message Content Types that have specific semantics, message flow patterns and behaviors associated with them and then recommend use of these standard types when choreography designers have a need to use them. Note that these would specify the types and not the representation of those messages in XML which could potentially be done in different ways.
 
Thoughts?
 
David
 
[1] http://lists.w3.org/Archives/Public/public-ws-chor/2004Jul/0009.html
[2] http://lists.w3.org/Archives/Public/public-ws-chor/2004Jul/0012.html

-----Original Message-----
From: public-ws-chor-request@w3.org [ mailto:public-ws-chor-request@w3.org]On Behalf Of Tony Fletcher
Sent: Tuesday, July 13, 2004 3:56 AM
To: public-ws-chor@w3.org
Cc: Robin Milner; 'Kohei Honda'; Nobuko Yoshida
Subject: Tony's nightmare - wake me up please


Dear Colleagues,
 
I hope this is a nightmare and someone can wake me up and re-assure me that everything is all right really!  I know that Nick (who could answer this concern as one of our main language designers) is on holiday for awhile now, so I have copied this message to your resident experts as well, though Steve, Gary or somebody else may well be able to answer simply.  I started writing this email a few days ago before Gary Brown's message on 'Perform' came out.  Having now had a look at that I wonder if my concern is a more extreme form of his.
 
Following discussions with Peter last week I have a major concern about how we are designing the choreography description language.
 
I am no mathematician, but my understanding is that pi-calculus describes each 'node' (a partner according to our current definitions) as a process and the allowed message sequences (I think mathematicians call these 'traces') are generated by mathematically 'composing' each node process with the others and letting the maths tell you what the various allowed message exchanges are (etc.)
 
Now I am more familiar with state machines, and I will therefore continue the discussion based on these, but I think the same principles apply to process algebras.
 
Consider a relationship between two nodes that we wish to describe.  The usual way to describe this fully suing state machines is to develop a state machine for each end and see how they interact.  Suppose one state machine has N states and the other M (N and M will be close to the same integer value but not necessarily equal).  So we have had to use N + M (approx 2*N) states to describe this relationship precisely.  However, there are altogether N*M (approx N squared) states that the system can be in.  Now depending on the whether each of our state machines are relatively simple and only have entries on the diagonal cells (or nearly so) or a very complicated with entries in most cells the number of valid, reachable states may be near to 2N or to N squared).  The answer is usually a lot more than 2N even if less than the worst case.
 
Now it is possible, in principle (I think) to have a single state machine that describes the permitted message sequences for the relationship but this is usually only attempted for very simple cases due to the state 'explosion' described above.  This single state machine has to represent all the valid states which is between N+M and N*M and usually well above N+M for any 'interesting' protocol.
 
In the current version of CDL we do not seem to be describing the process at each node then letting these interact with the others, but describing the interactions directly.  My concern is that this approach will suffer from state space explosion when one tries to include every conceivable message sequence that could happen, and that actually the current CDL may be fine for describing message sequence charts in XML (which is useful but not I thought what we were attempting to achieve) which are fine for illustrating message flows, but do not, in general, cover every possible case the protocol designer needs to allow for, but will become unwieldy / impossible to use for a complete description.
 
I hope the point is clear and that someone can answer it.
 

Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination       www.choreology.com <http://www.choreology.com/> 
 
Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
Tel: +44 (0) 1473 729537   Fax: +44 (0) 870 7390077  Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)