Re: CDL Challenge

In particular can we look at my last comments about defns.

As a community at large it would be good to agree on some
and as a W3C working group it would be good to do likewise.

Cheers

Steve T

On 29 Jun 2004, at 16:43, Jean-Jacques Dubray wrote:

>
>
>
> Here's an explanation of how CDL could "support" state alignment.
>
> Firstly CDL supports the idea that each of the roles involved in a
> choroegraphy are a) stateful, i.e. they are aware of their own state,
> <JJ>This is great, new and forward thinking</JJ>
>
> and b) their state is changed by either: the role sending or receiving 
> a
> message, or some other event internal to the role, e.g a timeout.
> <JJ>This is incorrect, state can only change after a message can be /
> has been correctly processed not just received. This is only true for
> the protocol states not the choreography states.</JJ>
>
<SRT>
JJ you are correct and I think this is what David means. When a role 
receives
it is somewhat implicit that the application playing that role has 
received and
understand the message sent to it.
</SRT>
> This means that in CDL you could define a very small choreography that
> described the state alignment protocol you describe below. This would
> require that you define:
> 1. The messages - the business message, the receipt signal message and
> the acknowledgement signal message.
> 2. The states at the sender and receiver which arose from sending 
> and/or
> receiving those messages.
> <JJ>The only issue is that protocol exceptions are part of the
> choreography definition so you cannot have a complete independence
> between the choreography and protocol. You need to say, if I get a NAK
> here, the choreography continues this way, otherwise, it continues this
> way, ...</JJ>
<SRT>
If the CDL description model NAK or ACK explicitly then you are correct.
If it is implied by binding in some protocol for message delivery then 
it
is simply a badly modeled CDL description.
At a high level CDL is a language for describing a business level 
protocol
that is multi-party. I think this is something that Nick has always 
stated.
</SRT>

>
> You could then "Perform" the "State Alignment Protocol", passing the
> details of the business message a paramter, as part of a real protocol
> such as a purchasing protocol with a Send PO, PO response etc, where
> each perform would mean that the state alignment protocol would be
> followed. As part of the perform, state information would be returned
> that provided details of the outcome of the perform, e.g. whether or 
> not
> the receipt signal was received before a timeout.
>
> So basically, CDL allows a state alignment protocol to be defined but
> does not require that one is used.
> <JJ>I disagree</JJ>
<SRT>
Can we go back a couple of steps here. What exactly do we mean by a 
state alignment
protocol vs some communication protocol vs some coordination protocol. 
Time for
robust defns.
</SRT>
> The reason is that you will not always want or need state alignment
> depending non what you want to do.
> <JJ>I agree, further there is not just "one" protocol</JJ>
> For example, if you are doing a query, e.g. stock availability, and it
> does not work then you can just do the query again.
>
> Hope this helps.
> <JJ>Thanks</JJ>
>
> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jean-Jacques Dubray
> Sent: Thursday, June 24, 2004 7:32 AM
> To: Mark Baker
> Cc: WS-Choreography List
> Subject: RE: CDL Challenge
>
>
>
> Mark:
>
> I apologize I don't have such an extensive historical perspective.
>
> Is this why REST talks about State without talking about State
> Alignment?
>
> I am wondering how State Alignment works over the web with web
> technologies I have the feeling that this might not be implemented
> properly by application developers all the time. I cannot tell you the
> peace of mind it gives me when I receive an email with a subject like
> "Your order..." (I don't even look at it...).
>
> Anyways, reading your response lead me to believe that I might want to
> explain one more time state alignment in BPSS (which is a business
> document exchange choreography standard).
>
> 1) RM tells you only that a message got to its receiver safely (and in
> the right sequence if necessary)
>
> 2) However, it is not because I got a message that I will be able to
> understand its content, it is not because I can understand it that I
> will act on it.
>
> 3) Therefore BPSS has 2 signals:
> 	a) a receipt signal that says that the message I received
> matches the agreement that we have (this message was the one I was
> expected as defined in the collaboration, and it had the right message
> format if specified).
> 	b) an acknowledgement signal that is returned when the message
> was successfully processed by the receiving application, system, ...
> whatever (you don't want to expose this kind of detail to the other
> party in general)
>
> I content that state alignment requires at least the acceptance
> acknowledgement. The receipt ack is rather used for non repudiation and
> is not part of the state alignment question per se but helps provide
> feedback about what might have gone wrong. If you get a negative
> receipt, you know you may not have sent the right thing based on the
> agreement you had with this party.
>
> The acceptance ack is often called a non-substantive response. It does
> not mean yes or no to a request, it simply means that the receiver of
> the request was able to process the request (it did not get lost
> internally).
>
> Is the BPSS state alignment protocol perfect? No, I can give you an
> example where it fails. Should we make it more robust, absolutely.
>
> I am concerned that since WS-CDL (or REST for that matter) speaks about
> state and state alignment but does not offer anyways to guaranty state
> alignment, this remains an issue. If the states are RM states (sent /
> received) I would content that's completely useless, this is because RM
> gives that for free, no need to make them explicit at the choreography
> level. If the states have business semantics associated to them (Order
> Processed) I am wondering how this information can be "signaled" back 
> to
> guarantee state alignment.
>
> JJ-
>
>
> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Thursday, June 24, 2004 5:45 AM
> To: Jean-Jacques Dubray
> Cc: WS-Choreography List
> Subject: Re: CDL Challenge
>
> On Wed, Jun 23, 2004 at 10:20:56PM -0700, Jean-Jacques Dubray wrote:
>> If you or someone from the WS-CDL team have some time, I would really
> be
>> interested to understand how WS-CDL can claim state alignment without
> a
>> state alignment protocol. I have details ebXML BPSS state alignment
>> protocol: http://www.ebpml.org/state.htm
>
> "The web services gurus are at least 2 light years away from
> understanding the problem. ebXML solved it in 2001 and RosettaNet 
> before
> it in 1999."
>
> and Internet gurus solved it in 1970; some of the first application
> protocols were state alignment (aka state transfer) protocols.
>
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>
>   Seeking work on large scale application/data integration projects
>   and/or the enabling infrastructure for same.

Received on Tuesday, 29 June 2004 12:01:17 UTC