Re: CDL Challenge

I think WS-CDL has the correct approach, that is, the desired semantics 
for state alignment can be defined in terms of the language primitives. 
  There are many ways of achieving state alignment and the choice will 
depend on the robustness and scalability requirements, number of 
participants, quality of the network and other issues.  That said, 
there are no pre-defined state alignment protocols in the WS-CDL spec 
or associated documentation and this is a deficiency.  Perhaps a to-do 
item?

Ciao,

AndyB

On 25/06/2004, at 7:17 AM, <david.burdett@commerceone.com> wrote:

>
> JJ
>
> 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, 
> 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.
>
> 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.
>
> 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. The reason is that you will not 
> always want or need state alignment depending non what you want to do. 
> 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.
>
> David
>
> -----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 Thursday, 24 June 2004 20:05:40 UTC