RE: Use Cases & Requirements

I think that to make run-time validation work you need three identifiers in
the headers of any message that is received which are:
1. The Choreography Definition identifier
2. The Interaction (i.e. message exchange) within  the Choreography
Definition, and
3. A Choreography Instance identifier

You can then:
1. Map the Interaction to a specific Message format although in reality you
are more likely to say that a particular Message format can support various
interactions in various choreographies
2. Map states and conditions in the choreography to data in specific Message
Formats.

As a result you could automatically validate that an individual message
received conformed to the rules of the choreography.

Thoughts?

David



-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Monday, May 19, 2003 11:39 AM
To: Jean-Jacques Dubray; 'WS Chor Public'
Subject: RE: Use Cases & Requirements



If I read your letter correctly then the validation you discuss is the same
as the "Run Time Validation" requirement I include in my paper. This
requirement means that one can confirm in an automated fashion that the
message choreography visible to a particular participant [1] is allowable by
the definition of the cDl.

The non-executable requirement [2] is intended to specify that the logic
used to decide between two mutually exclusive paths in the cDL will be
written in prose not in an executable form. As discussed at length in
section 4.3 of the paper and also touched upon in sections 4.1 and 4.2, the
removal of executable decision logic massively simplifies the cDL and allows
it to focus on the choreography and thus enhance interoperability. Those
seeking executable decision logic need to solve a number of difficult
problems, including defining a programming language and execution
environment, a problem the BPEL TC has already taken on.

By way of comparison [3] a pair of cPls might say something like:

Participant A's cPl:

Receive(B, Order)
If (Order.amount > 10000)
	OrderResponse.Status = "Wait 24 hours for approval"
      Send(B, OrderReponse)
      Receive(B, ACK)
Else
	OrderResponse.Status = "Approved"

Participant B's cPl:

If (items > 30)
	Order.amount = 15934;
else
	Order.amount = 20;
Send(A, Order)
Receive(A, OrderResponse)
If (OrderResponse.Status = "Wait 24 hours for approval")
	Send(A, Ack)

A visual representation of the cDl might look something like:

[Start State/B]
      |
    Order
      |
     \_/
[Received Order/A]
      |
 OrderResponse
      |
     \_/
[Received Order Response/B]
      |
      *--->[END]
      |
     ACK (B sends Acks to confirm A's request to delay approval)
      |
     \_/
[Received Ack/A]
      |
     \_/
    [END]

Notice that upon entering the Received Order Response state there are two
mutually exclusive paths that can be selected. Either the message
choreography can end or an Ack message can be sent to participant A. The
cPls explain exactly how this choice is made while the cDl only shows that a
choice must be made but doesn't specify how beyond a text note.

		Yaron

[1] I assume that by default any choreography is distributed such that each
participant can only validate their own behavior. E.g. they know what
messages they have sent and received and can validate those messages against
the choreography. This doesn't preclude the existence of a central
coordinator who could, in real time, detect every message sent by every
participant and so validate the entire global system's state but the
existence of this central coordinator is neither assumed nor required.

[2] Originally the 'non-executable' requirement was called the 'declarative'
requirement. Neither term particularly works. Hopefully in the official
requirements we will find a better phrase.

[3] Much thanks to Ricky Ho who pointed out to me that we really needed to
write up the sort of cPl/cDl combined example I use here. The examples used
here are inspired by his private communications with me.

> -----Original Message-----
> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
> Sent: Saturday, May 17, 2003 11:38 AM
> To: 'Yaron Y. Goland'; 'WS Chor Public'
> Subject: RE: Use Cases & Requirements
>
>
> Yaron:
>
> Thanks for taking the time to write this paper, I think it makes a very
> important and clear distinction between CPL and CDL, which fit well with
> Martin's definition of orchestration.
>
> I agree pretty much with everything you say, except for one point: you
> are talking about "prose" and "non-executable logic". I strongly
> disagree with that point.
>
> If it is true that as a global view, a CDL does not have an engine to
> ensure its execution, one of the value of a machine processable CDL is
> that each party can validate the choreography of messages based on rules
> defined in a CDL. So for me it is a requirement that the "prose" you are
> talking about be machine processable.
>
> Again, if you are a big organization, you are going to receive in the
> order of 100,000 to 1,000,000 messages per day. Having a CDL that help
> you validate whether or not you are supposed to receive any of these
> messages before you start processing them is going to save a lot of code
> within each application (not too mention that a given choreography could
> involve multiple of your applications, which would compound the
> problem).
>
> However there is catch when expressing this business logic. In order for
> each participant to "know" the state of the choreography, this business
> logic can only be expressed on the information being exchanged by any
> two parties. For instance we could not have a transition "if I approved
> your order" because the buyer has no way to know this information from
> the supplier unless you specifically exchange a message containing this
> information. This type of information becomes "prose". Interestingly
> enough, the business logic of CPL is the prose of CDL.
>
> Cheers,
>
> Jean-Jacques Dubray____________________
> Chief Architect
> Eigner  Precision Lifecycle Management
> 200 Fifth Avenue
> Waltham, MA 02451
> 781-472-6317
> jjd@eigner.com
> www.eigner.com
>
>
>
> >>-----Original Message-----
> >>From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]
> >>On Behalf Of Yaron Y. Goland
> >>Sent: Freitag, 16. Mai 2003 21:20
> >>To: WS Chor Public
> >>Subject: Use Cases & Requirements
> >>
> >>
> >>I would like to submit the following use cases and requirements for
> >>consideration by the working group -
> >>http://lists.w3.org/Archives/Public/www-archive/2003May/att-0029/chor.
> htm.
> >>
> >>Besides providing what I personally believe to be critical
> requirements
> >>for
> >>the success of the working group I also think they help to outline
> what I
> >>believe to be the fundamental differences between what I think the W3C
> >>Choreography WG should be doing and what the BPEL OASIS TC is doing.
> Of
> >>course all opinions on such differences are mine and mine alone, your
> >>mileage may vary, objects in mirror are closer than they appear.
> >>
> >>		Yaron
>
>