Re: use case rationale

Monica,

I'm not sure where to start in response to your email. So rather than  
try to I shall confine myself to two point only.

Firtsly, your comment "There is no explanation about the generation of  
the abstract BPEL from the CDL definition". I'm not sure what  
explanation you are seeking. It is clearly a use of a choreography  
description and we have talked much about it (Yaron's usecase). I see  
this belonging to CSF land and not use case land per-se. That is it is  
not a requirement that can be mapped to a language feature. As far as  
how this may be done in practice your guess is as good as mine at this  
point. It is the desirability that is important not the how.

Secondly, we did receive your spreadsheet comments. We spent two very  
full days going through the requirements document, the editors  
spreadsheet and the instructions from the last F2F. Alas we simply did  
not have time.

I think I might have said in a pervious email that we have also to take  
into account other usecases as well as your comments in the  
spreadsheet. But as I am sure you can appreciate this all takes time  
and resource.

Cheers

Steve T

On Tuesday, November 11, 2003, at 02:47  pm, Monica J. Martin wrote:

> Steve Ross-Talbot wrote:
>
>> Gentlepeople,
>>
>> I enclose the use case rationale that guided the editors in their  
>> efforts last week.
>>
>> I don't claim that we got it all right but we certainly got most  
>> things. One example were
>> work still needs to be done is Alastair Barros's use case which did  
>> not feature in the
>> document. Also Monica's EAI use case. We will need to put these two  
>> (and others)
>> on the agenda as soon as we can so that we can cover all that we need  
>> to.
>
> mm1: See comments related to combined Use Case 1 and 2 provided  
> yesterday for today's discussion. Thanks.
>
>>
>> I would say that this omission should not prevent us from publishing  
>> as soon as possible.
>>
>> Cheers
>>
>> Steve T
>>
>>
>> ---------------------------------------------------------------------- 
>> --
>>
>>
>>
>>
>>   Use Case
>>
>> 	
>>
>> *Requirements/Comments*
>>
>>
>>   UC-001
>>
>> 	
>>
>>    1. Composition (parallel and sequence)
>>
>> *UC-002*
>>
>> 	
>>
>> No different to UC-001
>>
>> *UC-003*
>>
>> 	
>>
>> Base for new UC-001
>>
>> *UC-004*
>>
>> 	
>>
>> 2.    Failure to comply exception MAY be generated by a choreography  
>> instance.  (this might have been in UC-011).
>>
>> 3.    Conditional paths
>>
>> 4.    Nesting and composition
>>
>> 5.    Sequence
>>
>> 6.    Termination of a choreography
>>
>> *UC-005*
>>
>> 	
>>
>> 7.    A CDL shall support the description of application exceptions
>>
>>    8. A CDL shall support the description of WSDl faults.
>>
>> *UC-006*
>>
>> 	
>>
>>    9. A CDL shall facilitate the demarcation of observable
>>       transactional behaviour.
>>
>> *UC-007*
>>
>> 	
>>
>> None (that is no language features could be gleaned from this use  
>> case)
>>
>> *UC-008*
>>
>> 	
>>
>> Base for new UC-002
>>
>> *UC-009*
>>
>> 	
>>
>> 10. There MUST be no control statements in the CDL (i.e. IF, WHILE,  
>> ... etc)
>>
>> 11. There MUST be a mechanism for adding annotation or comments to a  
>> choreography description.
>>
>> 12. A CDL must support the description of a multi-party global model.
>>
>>   13. A CDL must facilitate hierarchical decomposition to enable
>>       choreography descriptions to reference each other and to support
>>       some notion of abstraction to make descriptions easier to
>>       understand.
>>
>> *UC-010*
>>
>> 	
>>
>> 14. There should be a binding mechanism to enable a choreography to  
>> bind to differing QoS as applied to messaging and to differing  
>> correlation mechanisms.
>>
>>   15. A CDL should be able to participate in the generation of a CPL
>>       (usage rather than requirement).
>>
>> *UC-011*
>>
>> 	
>>
>> 16. A CDL should be able to be used to generate suitable test message  
>> for a CPL or such-like (usage not a requirement)
>>
>> 17. Static verification through bi-simulation (V2)
>>
>>
>> ---------------------------------------------------------------------- 
>> --
>>
>> This email is confidential and may be protected by legal privilege.  
>> If you are not the intended recipient,  please do not copy or  
>> disclose its content but  delete the email and contact the sender  
>> immediately. Whilst we run antivirus software on all internet emails  
>> we are not liable for any loss or damage. The recipient is advised to  
>> run their own antivirus software.
>>
>
> WS-Choreography Updated Use Cases
>
> Use Case 1
> Variation 1
> For annotations on the description, will be these be standardized to  
> encourage interoperability?
> These seem familiar to me; there is another JCP related to a similar  
> approach. Could you explain?
> In that, this use case uses the concepts of external processes,  
> subprocesses or composition
> (that is similar to the discussion in WS-BPEL), we need to  
> differentiate between a subprocess
> and composition. This may affect what is exposed and the interface to  
> it.
> Variation 2
> Are all callable choreographies hierarchical (where a return is  
> expected) or that there
> could be a choreography that is called, may or may not return, and  
> executes in parallel or
> concurrently. This exposes the need to further define dependencies  
> between choreographies.
> For example, in the travel agent case you created, a travel agency may  
> use the information
> compiled from the customer choices for developing patterns of behavior  
> and developing
> marketing materials. There is no explict return to the trip booking  
> choreography and its
> corresponding set of processes. They are therefore parallel in nature.  
> They are not
> necessarily dependent processes (For example, the customer opts out of  
> providing their
> information during the process). There is no explicit return. They  
> operate in parallel.
> The booking process does not wait for the other marketing related one.
> Need to differentiate composition from transactional behavior.  This  
> is unclear in the use
> case.  Perhaps this should be approached with Burdett's concept of  
> domains of control.
> For example, you may have one domain of control that allows only one  
> entry point to a
> set of composed services that actually represent a choreography with  
> many small choreographies
> within in (supporting your hierarchical concept).  However, you then  
> too could have
> a series of choreographies that may be related, are not necessarily  
> hiearchical, which
> expose multiple interfaces and require loose coordination (I tend to  
> think of this as
> nearing the concept of transaction).  Note, our working definition:  
> This is a business
> transaction (with business semantics) even though the latter  
> (business) is not within
> the scope of CDL.  The Choreology presentation definitions are also  
> included for this
> discussion. I've *** where CDL may be focused.
>
> An economic interaction, which may, or may not, be atomic in nature.
> A Business Transaction is subject to, and a part of, a business  
> relationship.
>
> Choreology definition from WS-BPEL:
> A business transaction alters the state of a business relationship...
> ...by coordinating / synchronizing changes in the state of the parties  
> to the relationship.
>
> I don't believe the submittals by Choreology talk at length about the  
> multiple levels
> that transactions can occur, and this is important to bounding our  
> scope.
>
> Local transactions	
>   Single general-purpose resource (DBMS, MQ)
>    ACID only
>    Atomic only
>    Data-level access
> ***Distributed transactions***
>   Multiple general-purpose resource (DBMS, MQ)
>    ACID only
>    Atomic only
>    Data-level access
>    Requires XA
> Business transactions
>    Above plus special-purpose applications or business services
>     Drop less ACID
>     Atomic/Cohesive
>     Service access
>     XA not required
>
> Variation 3
> Differentiate error from exception. An exception does not necessarily  
> infer that the
> choreography terminates. It may exhibit a different behavior.
> When you speak of composition of choreographies (+1 choreographies),  
> you will have the condition
> of exceptions that occur, with error messages returned.  Note this  
> subtle difference
> in the comment for Variation 2, where an exception can be a less  
> traveled path.  A decision
> is made whether or not it is substantive or not (technically and at  
> the business level,
> with the latter outside of the scope of CDL).  When a response is  
> returned, or error
> values raised, an evaluation occurs (i.e. an error).
> See some simple definitions at:  
> http://www.cs.pdx.edu/~apt/cs558/lecture4_4up.pdf,
> and a good brief  
> http://www.cs.wright.edu/~tkprasad/courses/cs480/L10Exception.pdf.
> Variation 4
> When you describe run-time validation, need to differentiate this to  
> WS-BPEL abstract processes
> and how this interoperates.  (Perhaps through the multi-service global  
> vs. one service
> view).
> On faults, see previous comments about exceptions and errors.  This  
> does not appear to answer
> the question about returning errors or exception conditions to another  
> choreography if
> they are composed.
> Variation 5
> The underlying binding may affect the assumptions at the abstract  
> level.  These QOS
> attributes will be typically be held in the collaboration that wraps  
> the choreography
> definition. This should be acknowledged, because you are very much  
> getting into the business
> semantics. Although there could be QOS (functional) related to the  
> services expressed
> in the choreography. We need to differentiate what we are targeting.
> Was not the binding out of scope - what elicited this change?
> When you speak of instantiation of a choreography definition by a  
> participant, how do
> you differentiate that from WS-BPEL?  Does not that participant have a  
> global or shared
> view, not his view?
>
> Use Case 2
> Quote request
> Section 1.1.1.1: Does this supercede an auction type case - we need to  
> talk about visibility
> and what is actually observable in the choreography, i.e. the  
> broadcast of the quote
> request, multiple responses, with a set of rules that dictates what  
> orders are actually
> placed. This may be handled in the scenario provided but I am unsure.  
> Some of this
> gets into the visbility afforded to the participants which is not  
> specifically addressed.
> Section 1.1.2
> Number 2,3 appear to be flight scenario requirements, Use Case 1,  
> although I am not sure
> where they fall.
> Variation 1
> Sounds good as a sales tool scenario but does not explain the business  
> case or the requirements
> held here. There is no explanation about the generation of the  
> abstract BPEL from the CDL
> definition.
> Need to address concurrent paths. See my comments in Use Case 1.
> What about partial orders which is a real case in a manufacturing  
> scenario.
>
> Should we have a map from the original set of requiremetns to
> the core set of requirements from the combined use cases?
>
> This was the just of my request made 11/4 on the requirements matrix  
> that was distributed.
> Which brings up if you did get my comments for requirements matrix  
> against my original two use cases on 11/4?
> Finally, I do not see the influence of business rules on what paths  
> are taken in these cases,
> perhaps you can give me some detail on how they have been included  
> (and if not, an
> explanation).
> Thanks.
>
> This email is confidential and may be protected by legal privilege. If  
> you are not the intended recipient,  please do not copy or disclose  
> its content but  delete the email and contact the sender immediately.  
> Whilst we run antivirus software on all internet emails we are not  
> liable for any loss or damage. The recipient is advised to run their  
> own antivirus software.

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.

Received on Tuesday, 11 November 2003 10:46:10 UTC