Re: use case rationale

Steve Ross-Talbot wrote:

> 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.

mm1: OK.  Doesn't a CSF in map to a use case and subsequent requirements 
(even if optional)?  See http://www.w3.org/TR/wsa-reqs, Section 2.

> 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.

mm1: OK that is fine. Just checking on receipt.

> 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. 

mm1: Careful balance between what is addressed and what is open for 
address.  I specifically provided comment in response to questions about 
member participation. Would we not discuss the use cases thoroughly 
within the group where several of these questions or requirements 
clarification/expansion/change would occur. Did you wish the questions 
or suggestions to come into the meeting and not via the list? :-D

> 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 11:24:14 UTC