- From: <david.burdett@commerceone.com>
- Date: Sun, 29 Feb 2004 10:13:02 -0800
- To: <public-ws-chor@w3.org>
Here's an email that includes questions from Greg about the differences between the Model Overview document and the requriements. David -----Original Message----- From: member-ws-chor-editors-request@w3.org [mailto:member-ws-chor-editors-request@w3.org]On Behalf Of Steve Ross-Talbot Sent: Friday, February 27, 2004 11:21 PM To: Burdett, David Cc: member-ws-chor-editors@w3.org; nickolas.kavantzas@oracle.com; GRitzinger@novell.com Subject: Re: Requirements vs. Model It would be good to bring this to the wider membership's attention so that wider discussion can take place. Cheers Steve T On 27 Feb 2004, at 19:31, <david.burdett@commerceone.com> wrote: > > Greg > > Comments inline below. > > David > > -----Original Message----- > From: Greg Ritzinger [mailto:GRitzinger@novell.com] > Sent: Friday, February 27, 2004 10:31 AM > To: Burdett, David; nickolas.kavantzas@oracle.com > Cc: member-ws-chor-editors@w3.org > Subject: Requirements vs. Model > > > Dave/Nick, > > I read the latest requirements draft, trying to be mindful of the CDL > model while doing so. I noted some topics below that were discussed in > the requirements that I saw no direct support of in the model. Keep in > mind that I could be just misunderstanding some of the model document, > if so we can discuss. > > repeat activity > <DB>This is covered through setting the "enabling condition" and > "repeat condition" attributes on a work unit. This means the work unit > is to be followed once the "enabling condition" becomes true. > Normally, once the Work Unit has completed it is not repeated. However > if the "repeat condition" is true, then the it effectively "resets" > the "enabling condition" so that if it becomes true again, then the > Work Unit is repeated.</DB> > > timeouts > <DB>I agree that this is not specifically included although I "think" > you could define variables to handle it, although it would probably be > a good idea to have an explicit way of handling it.</DB> > > transaction demarcation > <DB>This has been discussed a bit on the calls. Currently the spec > assumes that you can, if you want to, make a choreography > "transactional" by including a transaction block in its definition. > The semantics of the transaction block are defined as the work unit > that you follow when you want to "reverse" the effect of an original > following of the choreography. Tony Fletcher, however was more keen on > having explicit elements of the language to demarcate the start and > end of a transaction.</DB> > > definition of exceptions and wsdl faults > <DB>Generally exceptions and WSDL faults are handled as conditions or > states that control "choice" elements and Work Units (see repeat > activity comment earlier)</DB> > > QoS > <DB>In the spec QoS is identified as a requirement arising from the > need to bind different methods of sending messages to the same basic > choreography. The model handles this in the following way: > * Firstly, the choreography would be defined using variables that > represent message types, channels etc, at the abstract level by > setting the "abstraction level" attribute of the variable definition > to the appropriate level > * Secondly, when the choreography was being used, the abstract > definition of the variable would be "replaced" by a "concrete" > definition which specified the actual message structure, transport, > etc that was used which could vary depending on the type of connection > used. > What the model is unclear on is the mechanism you would use to > "replace" an abstract variable by a concrete equivalent. > <DB> > > correlation mechanism > <DB>Agreed this is not included. However there are several different > ways in which correllation could be done.</DB> > > expressing different message types > <DB>Different message types could be defined by defining message types > originally as abstract and then replacing them by concrete definitions > as described for QoS.</DB> > > extension of a base choreography > <DB>Currently the only way to extend a base choreography is by > defining a new choreography that includes the old choreography as sub > choreography that is performed. For example the new choreography > could: > * Perform the original base choreography > * Follow the perform by the additional interactions that were required. > The benefit of a perform is that you could have interactions before > the perform or after so it is more flexible than a simple extension. > However I'm not sure that this is enough as you might want to insert > an additional interaction into the middle of an existing > choreography.</DB> > > Regards, > > -------------------------------------------------------------- > Greg Ritzinger > Phone 203.225.1822 > Novell, Inc., the leading provider of Net Business Solutions. > www.novell.com
Received on Sunday, 29 February 2004 13:14:29 UTC