FW: Requirements vs. Model

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