RE: Burdett ML gap/fit analysis - first cut

Jon

See comments below.

David

-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Wednesday, July 30, 2003 9:56 AM
To: Burdett David
Cc: 'public-ws-chor@w3.org '
Subject: Re: Burdett ML gap/fit analysis - first cut


Burdett, David wrote:
> Jon
> 
> Some comments in-line below.

> <DB>Start and end states belong to the choreography as a whole rather than
to a process within the choreography. The rules also say that states must be
unique, so, according to the spec, two processes could not have the same
start and end states. However parallelism is possible if two (or more)
processes or interactions have a "precondition" that are the same. In this
case both processes/interactions should start at the same time. Similarly,
you can synchronize parallel processe/interactions by specifying a compound
pre-condition such as "Process1Complete AND Process2Complete" where each
state marks the completion of a process. Note that you could just have
easily written, if you wanted to, "Process1Complete OR
Process2Complete"</DB>

I can see how this would work, but it's a pretty indirect mechanism for 
specifying parallelism. Maybe parallelism should be more of a 
first-class construct.
<DB2>There are two ways that I can think of specifying dependencies, one is
described above. The other is to use specific constructs where, instead you
make explicit the structure and dependencies, for example ...
<Sequence>
  <Parallel>
     <Interaction FromRole='Buyer' ToRole='Seller"
MessageFamily="ShippingData"</Interaction>
     <Interaction FromRole='Buyer' ToRole='Shipper"
MessageFamily="ShippingData"</Interaction>
  </Parallel>
  <Selection
    <Condition>SellerShippingResponseRecvd AND
ShipperShippingResponseRecvd</Condition>
      <Sequence>
      ...
      </Sequence>
    <Condition>SellerShippingResponseTimeout AND
ShipperShippingResponseTimeout</Condition>
      <Sequence>
      <Sequence>
      ...
      </Sequence>
  </Selection>
</Sequence>
  
I can see benefits in both approaches. I think the first one is more
directly aligned with the state machine as what happens is directly related
to the current state of one of the roles. The example above though, is more
procedural. BPEL, for example includes both approaches. What are other
folk's views on the alternative approaches? 
</DB2>

> decision points - currently, the only indication that a process is a
> decision point is that it has >1 transition out of it. Should allow
> specification of decision logic? This has been discussed previously -
> could be a big issue.
> <DB>The current spec currently defines decisions using the 
> "Preconditions" element on a process or ineraction. This means that if a 
> process can have multiple different final states, then each state can be 
> separately checked for and an appropriate action taken.</DB>

The spec says a precondition "contains a Boolean expression consisting 
of a combination of States that must be true". IMO one of the open 
issues is whether the preconditions should be able to encode decisions 
based on message contents, or on some variable set in the choreography 
(e.g. an iteration count).
<DB2> There is no doubt that preconditions will often, at some point, need
to be bound to the message content that is used to determine if that
precondition exists. However implementing a decision may also depend on some
private data held by one of the roles which cannot be referenced directly.
Also a choreography should be able to work with multiple different message
formats therefore including a reference to single message format directly
into the choreography could be problematical. To solve this I think you need
to have a choreography definition that identifies a the different states
that a role can have. Each implementation can then decide how that state
maps (or is bound) to the data in the message formats and internal data it
uses.
</DB2>

--Jon

Received on Wednesday, 30 July 2003 14:02:14 UTC