RE: CDL Challenge

JJ

Having read your reply to my earlier email, your reply to Steve's below and Anders' comment about the need for "Acknowledge of Recipt" signal, it seems that the bottom line is that one way or another we need to either:

1.	Describe how to use some existing state alignment protocol *within* CDL, or
2.	Define how to do state alignment *in* CDL

Either way, I think that the arrival (or non-arrival) of "signal" messages can affect the future direction that a choreography takes, therefore at a minimum, there needs to be ways setting state variable within CDL that record the effect of these events.

I also buy JJs arguments around the need for interoperability, and Steve's ideas for "binding" different protocols although allowing flexibility through binding can make it harder to realize interoperability.

That said we could achieve interoperability around state alignment in a number of different ways, for example:

*	Information Types. This involves defining informationTypes and associated values that have well defined semantics that recognize the states that can arise from state alignment, for example we could define an informationType with a name such as tns:AlignmentState, that could then have values such as: messageSent, messageReceived, messageAckSent, messageAckReceived. That has the specific meanings that I think JJ and Anders are looking for. We could then include a variable of that information type in a "record" statement.
*	Behavior Definition. This would require that we define how these state variables should be used when defining an Interaction. In essence this would define a "pattern" for using an interaction that implied that signals of differing types would need to be "exchanged". This could be specified by extending the Action attribute on an exchange element beyond Request & Respond to include "Acknowedlgement of Receipt" as Anders is looking for.
*	Formalized Behaviors. This involves the idea of creating "standard" patterns by, for example, including an attribute on the Interaction such as ... pattern="tns:stateAlignmentTypeA" ... which would imply that the interaction was to work in the particular way defined in the "State Alignment Type A" pattern whatever that was ...
*	Signal Definition. This would specify the structure and format of signals. It could include:

*	The messageContantTypes that should be used for the signals required to achieve state alignment
*	Bindings to abstract WSDL defintions for various versions of SOAP, etc - although I am not sure this is such a good idea.

If we follow Steve's approach of "binding" different protocols then all I think we need to do is define the Information Types, and have some way of specifying the "pattern" to use. The usage of the pattern would then imply a binding to a specific state alignment protocol.

On the other hand if we go down the approach of defining our own behaviours, standardizing them and defining the signals, then it's more work, but should lead to more interoperability ... if they are widely adopted ;). 

But this would require us to define both the "patterns" and the "signals" ... any volunteers ... JJ ... Anders? I know I don't have the requiste knowledge ;)

Thoughts

David

-----Original Message-----
From: Jean-Jacques Dubray [  <mailto:jeanjadu@Attachmate.com> mailto:jeanjadu@Attachmate.com]
Sent: Monday, July 05, 2004 4:38 PM
To: Steve Ross-Talbot
Cc: distobj@acm.org; Burdett, David; public-ws-chor@w3.org
Subject: RE: CDL Challenge


Steve:

This was my first 4th of July in the Seattle area and it was quite
spectacular to see the number of boats on lake Washington and Sammamish
watching the fireworks.

I am not necessarily suggesting to make a state alignment protocol part
of WS-CDL, but rather create an abstract protocol capability in WS-CDL,
so that various protocols can be specified using this abstract protocol
capability (if WSDL part II allows to do so, then forget about that). I
would then suggest creating aside from WS-CDL a description of a state
alignment protocol to promote interoperability at that very important
level. What is critical in the abstract protocol specification is to
allow for CDs to understand the states at the protocol level such that
choreographies can depend on it.

In BPSS, the BTP has two signals which can roughly be attributed to
non-repudiation and state alignment. I am not suggesting to copy the
BTP.

Please note that protocol problem is non trivial and creating a solution
which does not have an explicit state alignment protocol will make
WS-CDL vastly incomplete (how can you comply to a choreography if both
sides have a different understanding of where they are at).

As I said, I am just trying to understand if this is going to be part of
1.0 or post 1.0?

JJ-

-----Original Message-----
From: Steve Ross-Talbot [  <mailto:steve@enigmatec.net> mailto:steve@enigmatec.net]
Sent: Monday, July 05, 2004 12:28 PM
To: Jean-Jacques Dubray
Cc: distobj@acm.org; david.burdett@commerceone.com;
public-ws-chor@w3.org
Subject: Re: CDL Challenge

Hi JJ,

Hope you had a good 4th July break. We of course celebrate the 3rd July
as it was the last time we owned the USA.

See comments inlined ....

Cheers

Steve T


On 5 Jul 2004, at 19:54, Jean-Jacques Dubray wrote:

>
>
> 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.
> <JJ>We agree that ideal would be "binding to". In the lack thereof, I
> would suggest to fall back on defining. I curious whether someone has
> an
> opinion on if we can use WSDL MEP (part 2) extension mechanisms to
> specify such a protocol? I spoke briefly with Jean-Jacques Moreau who
> gave me some tips about how that works, since it did not appear
clearly
> on the spec itself. I am not sure I can specify something like an MEP
> with concrete messages like signals.</JJ>
>
<SRT>
I think it ought to be possible to describe the observable interaction
inherent in an MEP
but of course it may not be useful if it doesn't bind at the right
level. Certainly it is not our
intention to do so but to leverage things higher up. But you never know
how a CDL
description might be used. What is nice about having one with no
specific binding is that
you can use it in your tool or by hand as you like. Binding is then a
mechanism by which
you manifest the CDL description into something that is rather than can
be used.
</SRT>
>
> 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.
> <JJ>Hum... are you faced with the classical "theory and practice"
> dilemma? </JJ>

<SRT>
Don't believe so. I think one of the nice things about academic
research, pi or petri
or anything in between, is that they do tend to make clear their
assumptions either
explicitly or implicitly by reference to other work. What we have to do
is use the
same rigor for CDL.
</SRT>
>
>
> 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.
> <JJ>Yes, this sounds like the right place to do, again, which state
> alignment protocol do we bind to?</JJ>
>
<SRT>
What state alignment protocol would you suggest?
</SRT>
> JJ-
>
> 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> 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> 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> 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> 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> http://www.markbaker.ca
>>>
>>>   Seeking work on large scale application/data integration projects
>>>   and/or the enabling infrastructure for same.