Re: Requirements: Decision Points Requirement Proposals

Life would be much simpler if correlation was handled transparently and 
was part of the protocol. For example, if you had services that all 
support WS-Addressing you coud use endpoint references to establish a 
session between the services that would take care of the simple case. 
There would be no need to write any correlation logic in the definition.

The downside - this would only work with services that can support the 
proper use of addressing. Failing to do that, you would want to support 
the manner in which some services correlate information. You then need 
to know what information they use for correlation so you can send it 
back to them. If the service says "you have to send me this identifier 
so I know what you are talking about", you need to obey that rule. A 
rule like that is definitely external - it binds the other services more 
than it binds the receiver itself - and so belongs in the choreography.

The question is, can we assume we're always going to use a standardized 
mechanism, and can we agree on which mechanism it is?*

arkin


Burdett, David wrote:

> JJ
> I agree with you that correlation is not a topic we have discussed. I, 
> like you prefer a choreography instance id as it simplifies the 
> choreography definition and is indpendent of the detail of the message 
> content. However it does mean that there can then be inconsistencies 
> between the choreography instance id and some id inside the message 
> content e.g. an order no.
> David
>
>     -----Original Message-----
>     *From:* Jean-Jacques Dubray [mailto:jjd@eigner.com]
>     *Sent:* Monday, June 09, 2003 2:22 AM
>     *To:* 'Burdett, David'; 'Yaron Y. Goland'; 'WS Chor Public'
>     *Subject:* RE: Requirements: Decision Points Requirement Proposals
>
>     "The WS-Chor choreography definition MUST provide mechanisms by
>     which the execution of one choreography definition is dependent on
>     the execution of the instance of some other choreography
>     definition". The use case for this is where you want to execute a
>     choreography that determines the current state of processing of
>     some earlier choreography. The "query" choreography can only
>     validly be executed if there is some earlier instance of the a
>     choreography that can be referenced.
>
>     */[JJ] I would treat the “query/admin” problem as an independent
>     problem like you seem to suggest in the following points. However,
>     I can see the advantages of your proposal above in
>     Multi-party-collaborations. This will save us from complex
>     correlation schemes./*
>
>     */This is another area of requirements that I think we did not
>     touch: correlation. There are two possible approaches: an explicit
>     correlation mechanism based on the document contents, and a
>     choreography protocol which envelope contains a choreography
>     instance ID. I personally favor the choreography protocol as it
>     works in all cases and simplifies the choreography definition. /*
>
>     The following couple of requirements are ones that have been
>     discussed much earlier on the list however I am not sure that we
>     really want to do them, at least not initially, but I do think
>     they are worth discussing ...
>
>     "The WS Choreography specification MUST provide standardized,
>     reusable choreography definitions that allow one role to determine
>     another roles state of processing of a choreography instance, no
>     matter what choreography definition was being followed."
>
>     "The WS Choreography specification MUST provide standardized,
>     reusable choreography definitions that allow one role to request
>     another role to restart the processing of a "stalled" choreography
>     instance, no matter what choreography definition was being
>     followed." This could simply be a request to resend some earlier
>     message that got lost.
>
>     The rationale for both of these is that querying the status of a
>     choreography and re-starting a choreography will be common
>     requirements for many (but not all) choreographies and therefore
>     having a standard way of doing these functions will make
>     choreographies easier to design and develop.
>
>     As stated earlier, more comments inline below.
>
>     David
>
>     -----Original Message-----
>     From: Yaron Y. Goland [mailto:ygoland@bea.com]
>     Sent: Wednesday, June 04, 2003 4:28 PM
>     To: WS Chor Public
>     Subject: Requirements: Decision Points Requirement Proposals
>
>     I propose the following requirements be added to the requirements
>     document:
>
>     The WS-Chor choreography description format MUST provide
>     mechanisms to
>     enable a choreography to specify that a process in a particular
>     role MUST
>     send zero, one or more messages from a statically defined set of
>     messages in
>     parallel, serial or any combination of the two.
>     <DB> A couple of comments:
>     1. I think a role that MUST send zero messages doesn't work as if
>     the role MUST send zero messages, then why is it in the choreography.
>
>     2. Why do you use the term "description format" instead of the
>     simpler "definition' because, aren't the properties you seek a
>     characteristic of the definition rather than the format of the
>     definition.
>
>     3. The first sentence is circular as it says ... "The WS-Chor
>     choreography description format MUST enable a choreography ..."
>     without specifying what a choreography is.
>
>     4. I think you mean when you say a "statically defined set of
>     messages" that the actual messages definitions that can be sent
>     are finite in number and from a proscribed list. There has been a
>     lot of discussion on the idea of variability in the detailed
>     message content which means that limiting a choreography to
>     specific message formats will inhibit choreography reuse. Instead
>     I thinkt that we should refer to "Message Types" or "Message
>     Families" rather than "messages".
>
>     5. This requirement is also very similar to the next so my
>     alternative is described below
>     </DB>
>
>     The WS-Chor choreography description format MUST be able to describe
>     decision points where a process in a particular role MAY send
>     zero, one or
>     more messages from a statically defined set of messages in
>     parallel, serial
>     or any combination of the two.
>     <DB>So how about the following requirement that combines the
>     previous two and takes into account the comments I made ...
>
>     "The WS-Chor choreography definition MUST provide mechanisms that
>     define the sequence in which one or more messages types are
>     exchanged between two or more roles either in parallel, serially
>     or any combination of the two, together with the conditions that
>     cause those messages to be sent."</DB>
>
>     The WS-Chor choreography description format MUST be able to
>     describe who is
>     to receive a message by referencing their role.
>     <DB>I would add the sender to this definition to give ... "The WS
>     Choreography definition MUST be able to describe who the sender of
>     a message is and who the receiver should be by referencing their
>     role." The rationale for this is that what you do with a message
>     may well depend on the role of the sender ... assuming that the
>     same message can be sent by different roles.</DB>
>
>     The WS-Chor choreography description format MUST make it possible
>     to specify
>     a role's binding to an actual web service instance either
>     statically, when a
>     web service using that choreography is deployed, or dynamically at
>     run time.
>
>     The WS-Chor choreography description format MUST provide
>     mechanisms to allow
>     messages to be sent to a particular member of a set of web
>     services in the
>     same role.
>     [Ed Note: What I'm very inelegantly trying to capture is the idea
>     that if
>     you are running an auction service and you just found out that one
>     of the
>     bidders isn't qualified to bid you need a way to say things like
>     "I'm now
>     going to send out an unsolicited 'get lost you dead beat' message
>     to one web
>     service that is in the role of bidder." This could then trigger a
>     whole set
>     of messages back and forth between the auction service and the
>     dead beat
>     bidder, the choreography needs some way to capture the fact that
>     you are
>     still talking to the same member of the role group.]
>     <DB>This example introduces the idea of a role group, which I
>     don't *think* we need. If we take this use case, then you can
>     actually consider it as an internal "business process" problem,
>     for example:
>
>     The auctioneer has a business process that consists of a set of
>     separate individual identical choreographies between the
>     auctioneer and the bidder where each choreography instance would
>     take the following form ...
>
>     AUCTIONEER BIDDER
>     Bid Invite ------->
>     Either ...
>     Get Lost --------->
>     ... or ...
>     <--------------- Bid
>     ... etc ...
>     The fact that there are several bidders involved is something that
>     only the auctioneer needs to be concerned of.
>
>     This means that this is really a business process (e.g. BPEL )
>     problem rather than a choreography problem especially as the
>     auctioneer is in complete control of what goes on. For example,
>     the auctioneer could treat all the interactions as being part of
>     one choreography by using the same identifier for the correlation
>     of all the messages irrespective of the bidder.
>
>     Now there may be a use case where you really do the need the
>     variability, but I can't think of one. On the other hand, if we
>     can avoid this variability, then it will simplify the
>     specification we need to write significantly.
>
>     </DB>
>
>     The WS-Chor choreography description format MUST NOT require that
>     the logic
>     used by a sender in a decision point to decide how to act be
>     exposed in the
>     choreography.
>     <DB>There's a corollary, I think, that says something like ...
>     "The WS-Chor choreography definition MUST enable the results of
>     decisions made by one role that affect the behavior of another
>     role to be communicated to the other role." This is really about
>     the transmission of relevant state information between roles.</DB>
>
>     The WS-Chor choreography description format MUST enable the
>     annotation of
>     all actions with human readable descriptions.
>     <DB>I agree but would go further and replace the last phrase with
>     "... with clear semantic definitions." Something might be human
>     readable but that does not mean it explains the purpose well.</DB>
>
>     The WS-Chor choreography description format MUST provide an abstract
>     mechanism where by the logic used to make a decision at a decision
>     point can
>     be expressed through reference to a WSBPEL abstract or executable
>     process or
>     similar machine readable logic.
>     <DB>I don't have an alternative definition, but this pre-supposes
>     a binding to WSBPEL that we might (or might not) want to make
>     unless and until we collectively (i.e. WSBPEL and WSCHOR) work out
>     what the goals and relationships of each activity will be.</DB>
>
>     The WS-Chor choreography description format base specification
>     MUST NOT
>     specify bindings for the abstract mechanism used to reference machine
>     readable logic, rather extension specifications on top of the base
>     specification MUST be used.
>     <DB>As a general comment, we could do with developing definitions
>     of various terms, e.g. "decision point", "base specification"
>     which although quite intuitive, could be open to
>     miss-interpretation.</DB>
>
>     I would appreciate it if objections to these requirements were
>     stated in the
>     form of alternate proposals. It's easy to say why something is
>     wrong, it's a
>     lot harder to spend the time to specify what is right.
>
>     Yaron
>

Received on Monday, 9 June 2003 15:05:34 UTC