RE: [ws-chor] 7/28/2003: Reqts 1.0 Comments

RE: [ws-chor] 7/28/2003: Reqts 1.0 CommentsActually, I'm not clear on your
use case. I have a strong suspicion about it but it would be better if I
responded to what you are saying rather than what I think you are saying.
Could you please provide a choreography example of your use case including
the use of the XPath predicate? Preferably in the form of a little activity
diagram? E.g.


(foo)---Message1--->(bar)---Message2--->(blah)
                                         |
                                 Message 3
                                         |
                                       \_/
                                      (ick)

The use case you described leaves too much room for me to misunderstand.

    Thanks,
            Yaron

  -----Original Message-----
  From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
  Sent: Sunday, August 17, 2003 1:14 PM
  To: ygoland@bea.com; public-ws-chor@w3.org
  Cc: martin.chapman@oracle.com; steve@enigmatec.net
  Subject: RE: [ws-chor] 7/28/2003: Reqts 1.0 Comments


  Yaron:

  I guess that we will probably still argue on that one in a couple of
years, but let's assume for a moment that the goal of the ws-chor is to
provide a definition language that let two web service describe exactly and
precisely what will be the sequence and ordering or messages that they will
exchange to achieve a common goal.

  How could you disagree with the fact that in order to infer what would
happen next in a choreography (at run-time) the web services might have to
look at the content of the message.

  Say I have a purchare order choreography. The first operation involves
sending a processOrder message and receiving an orderStatus response. The
orderStatus document has an attribute called "accepted" of type boolean.

  If we want the collaboration to continue one way or another base on the
value of this attribute how do we specify it? Could you give a concrete
example? It is clear that how the decision was made to accept or reject an
order has nothing to do with the choreography.

  That being said, I really like David's idea to layer the specification in
a way that choreography definitions are abstract (so we could have in this
case and isOrderAccepted decision element as part of the abstract
choregraphy def.) and bound to implementation(s) (so this decision element
could be bound to an XPAth predicate "//@accepted = 'true'")

  Jean-Jacques
  tel: 425-649-6584
  Cell: 508-333-7634



  -----Original Message-----
  From: Yaron Goland [mailto:ygoland@bea.com]
  Sent: Tuesday, August 12, 2003 1:55 PM
  To: public-ws-chor@w3.org
  Subject: RE: [ws-chor] 7/28/2003: Reqts 1.0 Comments




  The key terms are 'machine processable' and 'control logic'.

  The directed graph describing the legal combinations of message sequences
is something that clearly should be machine processable. My own scenarios
require that the graph be machine processeable otherwise it would be
impossible to fulfill requirements like being able to generate a language
skeleton and being able to validate real time messaging behavior and its
compliance to the graph's definition.

  Where I think the real confusion is coming is from the term 'control
logic'. What I specifically mean is that when a web service has an option
for which message it can send next then the logic the web service uses to
choose must not be expressed in the choreography definition.

  To use one of our own examples a traveler sends a travel agent a request
to book a trip. The choreography says that the travel agent can either
respond immediate with 'trip booked' or they can respond with 'request
received but booking info will be sent later.' The choreography would only
specify that the travel agent has a choice of which message to send but will
not provide any actual control logic that would specify how the choice is
made.

                  Yaron

  > -----Original Message-----
  > From: public-ws-chor-request@w3.org
  > [mailto:public-ws-chor-request@w3.org]On Behalf Of Assaf Arkin
  > Sent: Tuesday, July 29, 2003 6:37 PM
  > To: jdart@tibco.com
  > Cc: Monica Martin; Daniel_Austin@grainger.com; public-ws-chor@w3.org
  > Subject: Re: [ws-chor] 7/28/2003: Reqts 1.0 Comments
  >
  >
  >
  > Jon Dart wrote:
  >
  > >
  > > More problematic is the proposal to use prose annotation to
  > replace or
  > > to abstract away some constructs. Specifically, the proposal to
  > > "remove control logic from the cDI .. the cDI programmers
  > would have
  > > to annotate the logic with human readable statements in order to
  > > explain their intent." (3.2.3.6). IMO this is not something
  > on which
  > > we have consensus (at least not yet). In fact I think it is
  > possibly
  > > in conflict with some of the other requirements, such as
  > D-CR-035 and
  > > D-CR-038.
  >
  > Agreed. If it really boils down to being a description language that
  > is not machine processable, then can't we just use UML?
  >
  > arkin
  >
  > >
  > > --Jon
  > >
  >
  >
  >
  >