RE: CDL Challenge

>>>Nick any comments from you and/or David?<<<

A few ... ;)

The real question we need to answer is what should be the "primitives" in CDL. For example all of the following *could be*:
1. A "one-way" fire & forget message
2. A "request-response" where a message is sent and a response should be received
3. A "one-way reliable message" where a message is sent and resent until an acknowledgement is received
4. A "state-alignment protocol", e.g. a la BPSS which include signals to inform the sender of the state of processing of the message.
5. A "reliable state-alignment protocol" which could be a combination of 3 and 4 where each of the messages in the state-alignment protocol were sent using a one-way reliable messaging protocol.

The benefit of having a range of primitives is that it should simplify the definition of a choreography in that some of the "tricky stuff" around how to do, for example, state alignment, would already be defined.

The disadvantage of having several primitives are primarily around: deciding which ones to include, knowing that we have included the ones we "need" to, and allowing additional primitives to be added over time.

In an earlier response to JJ, I suggested that the state-alignment protocol could be defined using CDL which really means that I, personally, would probably want to draw the line on "primitives" at no 3 but I' open to persuasion.

My main rationale for not including state alignment was that for the first three, the semantics are the same even if the technology used is different. For example you could realize reliable messaging using a MOM transport, WS Reliability or even WS Reliable Messaging. However the resulting state would be the same. However I don't think the same applies to state-alignment protocols, although I may be wrong, as there are several different semantics that could be associated with sending a message.

Thoughts?

David

-----Original Message-----
From: Steve Ross-Talbot [mailto:steve@enigmatec.net]
Sent: Wednesday, June 30, 2004 2:40 AM
To: Jean-Jacques Dubray
Cc: distobj@acm.org; Burdett, David; public-ws-chor@w3.org
Subject: Re: CDL Challenge


JJ,

Thanks for your defns. This at least enables us all to be on the same
page even if it isn't the page we want to be on.

Of course your ideal world scenario is the correct approach. But in the 
absence,
again as you point out, we need to bind to something that ensures 
communications
happen and, if so desired, that state is aligned and global knowledge 
maintained.

You say "I don't see the logic behind not supporting a 'state alignment'
communication protocol". When you use the word "supporting" do you
mean "binding to" or do you mean "enabling the definition of" such a
protocol. If it is the former then I certainly would agree with you. 
The latter,
which I don't think you mean, would not be a good idea.

Examining this notion of "binding to" and thinking further ahead...
If a CDL description describes the observable interaction between 
multiple
parties then we need to have some way of stating the assumptions we 
make.

For example, when we describe such interaction in the pi-calculus there
are some assumptions that are made such as synchronous communication
and guaranteed delivery. That is we do not take account of failed 
communication
within the calculus itself. It can of course be modeled (see Banana 
Calculus).
But then again the pi-calculus is very well documented and the 
assumptions
are made clear. With CDL this is less so.

The sort of assumptions I am thinking about are the capabilities 
required by
a CDL globally or with respect to a specific interaction. We might for 
example
wish to indicate that interaction to deliver pricing information can be 
different
to orders, such  that orders needs to be guaranteed to succeed/fail and 
prices,
well if you miss one price update it probably will not harm you too 
much.

These sorts of assumptions can include a wide range of assumed 
capabilities.
It would leave the CDL description fairly clean in terms of what it 
describes and
enable the description to indicate what it requires of the rest of the 
Web Services
stack.

I think all of this could well live in some sort of "policy" statement 
that describes
security, coordination protocols, messaging protocols and so on. What 
we would
need to be able to to do though is "bind-to" specific places in the CDL 
description
and not just present a top-level policy statement.

Is this broadly what you have in mind too?

Nick any comments from you and/or David?

Group perhaps?

Cheers

Steve T

On 29 Jun 2004, at 17:24, Jean-Jacques Dubray wrote:

>
> A state alignment protocol is in my views a feature of communication
> protocol (i.e. it is part of the communication stack), just like RM is
> another.
>
> A coordination protocol is using various communications protocols to
> achieve its goals. A distributed transaction is a coordinated protocol.
> A distributed transaction is not a communication protocol, it requires
> some features to be supported by the underlying communications
> protocols. In a distributed transaction, the parties involved don't 
> just
> "communicate" they perform a "unit of work". We should really separate
> semantically communication from coordination (of course a communication
> with guaranteed state alignment can be viewed as a "unit of work" but
> please let's not confuse everything).
>
> So
> a choreography of message exchanges can pertain
> - to "communication" only
> - to "units of work" only
>
> "Communication" failures & successes may change the outcome of the unit
> of work. Some units of work could not be implemented by underlying
> communication mechanisms and is required to understand some of the
> states associated to the communications features.
>
> I think it would be a mistake to force people to specify both at the
> same level. It would lead to very poor re-use and abysmal
> interoperability (with a large number of proprietary ways to add
> features to existing communication protocols).
>
> Features that can be implemented at the communication level: reliable
> messaging, non-repudiation, state alignment, ...
>
> If we lived in an ideal standards world, there will be an OASIS TC
> working on WS-SA and WS-NR specification and WS-CDL would just have to
> specify a binding to these communication protocol features (and 
> states).
> Unfortunately this is not the case, the standards world is far from
> ideal. Since "state" is such a core concept of WS-CDL, I don't see the
> logic behind not supporting a "state alignment" communication protocol.
>
> JJ-
>
> -----Original Message-----
> From: Steve Ross-Talbot [mailto:steve@enigmatec.net]
> Sent: Tuesday, June 29, 2004 9:01 AM
> To: Jean-Jacques Dubray
> Cc: distobj@acm.org; david.burdett@commerceone.com;
> public-ws-chor@w3.org
> Subject: 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 Thursday, 1 July 2004 12:40:59 UTC