RE: Requirements: Decision Points Requirement Proposals

 

>>The strong argument *for* a separate layer, is to enable run-time
>>validation
>>that a choreography definition is being correctly followed. However
you
>>will
>>still have ad hoc correlation going on.
>>
>>Really it's the same argument as to why do you need a MessageId in a
SOAP
>>message if there is an OrderNo, for example, in the SOAP body which is
>>also
>>unique.
>>
>>It really is a question of the architectural layering that you want to
>>apply. Having a separate layer allows a lot of very useful common
>>processing
>>that reduces the burden on the application.

[JJ] And one more time, on the message format too.





>>
>>David
>>
>>-----Original Message-----
>>From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
>>Sent: Tuesday, June 10, 2003 5:48 PM
>>To: Assaf Arkin; Burdett, David
>>Cc: 'Yaron Y. Goland'; 'WS Chor Public'
>>Subject: Re: Requirements: Decision Points Requirement Proposals
>>
>>
>>Assaf:
>>
>>> The question is, can we assume we're always going to use a
standardized
>>> mechanism, and can we agree on which mechanism it is?*
>>
>>This question realy relates to do we assume that web services that
>>participate in a web service choreography require a specific software
>>layer.
>>If yes, then it probably would not be too hard to deal with
correlation at
>>the protocol level. On the contrary, if we assume that any services
could
>>participate in a choreography, we would then need ad hoc correlation
>>mechanisms.
>>
>>I guess we should have a requirement around that topic as well.
>>
>>JJ-
>>
>>>
>>> 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 Tuesday, 10 June 2003 15:45:58 UTC