W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2004

RE: CDL Challenge

From: <david.burdett@commerceone.com>
Date: Tue, 29 Jun 2004 08:55:49 -0700
Message-ID: <975D1A379F57F34995874608D9FE8C915FD984@C1SCAMSG05.commerceone.com>
To: <jeanjadu@Attachmate.com>, <distobj@acm.org>
Cc: <public-ws-chor@w3.org>

JJ

See more comments inline.

David

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
Sent: Tuesday, June 29, 2004 8:43 AM
To: Burdett, David; distobj@acm.org
Cc: public-ws-chor@w3.org
Subject: RE: CDL Challenge




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>
<DB>You are right of course. Once a message is "received" several possible states could exist over time as the message is proccessed. This could vary from it being received, through validation to processing to generate some type of business response. Any or all of these "states" could affect the choreography.</DB>

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>
<DB>I agree, but couldn't you just describe the outcome of the protocol as a state that could then be interpreted at a high level by the choreography.</DB>

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>
<DB>But isn't a protocol really a choreography in that defines the sequence of exchange of a series of messages whose success/failure has specific meaning. What's diferent about a state alignment protocol which means that you can't express it as choreography.</DB>
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 11:55:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:25 UTC