Re: CDL Challenge

I have to give regards for the next month, since I am taking off in a bit for my vacation.


BTW, I really think that this thread is very usefull and I am looking forward into our discussions
regarding these areas in our next F2F as is scheduled per your agenda.


Regards,

Nick

Steve Ross-Talbot wrote:

> 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 Saturday, 3 July 2004 13:29:10 UTC