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
>     <mailto:tony.fletcher@choreology.com>     (Home: amfletcher@iee.org)
>      
>