Re: use case rationale

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.