[ws-chor] 7/28/2003: Reqts 1.0 Comments

Attached are my comments to Requirements 1.0 - I understand they may be 
handled after the draft is released. :>)

Section 1.1
Consumer-user-producer-provider (see WSRP): May require clarification/further
detail
Use Case 1
Touches on composable system
Need differentiation is this is choreography composition
Is this composable services or a system that uses different services that can be
composed for performance or convenience, or both? Suggest break
out into another use case.
Use Case 2
Need to discuss the role of agents in a choreography.
Use Case 3
See comments on roles/entities in Use Case 1.
This case mirrors those described in detail in a business level book about 
ebXML by Alan Kotok and David Webber. I suggested we look at their case and 
glean from that (Chapter 3, Case 1, Go-Go Travel).
Relates to Use Case 1 and 2.  Perhaps we should look at these and discuss
rounding out a larger scenario.
Use Case 4-5
See comments to Jon Dart
Use Case 6
The interactions can be understood at an abstract level (such as the exception
or less traveled path) as well as at the application and communication transports.
In addition, part of any recovery has to do with the knowledge of the state and 
the time to perform or do we assume that the retry occurs from the last successful
event?  Then, how do we guage the time left to perform?
May relate to exception propagation Use Case 4.
Use Case 7
May relate to exception propagation Use Case 4.
Would not this be effected by business rules and the transitions to acceptable
steps within an interaction?
This touches on do we order, sequence, or do we allow many paths that 
can handle order or sequence given the context, agreement and rules applied to the
choreography?
Use Case 8
Some of the security requirements may need to be specified as outside of the scope,
i.e. related to reliable messaging.
Is contract negotiation within our defined scope? (I thought we had expressly
defined it outside of scope but an impact to our effort).
See CPP/A Negotiation work for some insight into the complexities of this.
Are they actually negotiation of the contract or the items that the supplier agrees
to accept for the request (I believe it is the latter, and is not a contract,
but a commitment for exchange of resources).
Wouldn't the contract specification be an interface to or context for the interaction
not necessarily a part of the quote and request for goods exchanged (Reference
post conditions)?
The basic flow talks about contract requirements - I would say that the contract
requirements are already specified prior to the quote. See note on CPP/A above.
Use Case 9 (was Scenario 1):
CPI does not currently adequately handle transactions and long-running transactions
without the use of other specifications outside of BPEL.
There are several levels of state: collaboration, transaction and service. This
is seen if a layered approach is used in a state machine, although the interaction
may not be message bound to show the transitions in state (may be state of the 
objects) Process != entity state.
A CDI can be executable.
Annotation seems to specify a solution to correlation or associated items.
Therefore, I think we should concentrate on those terms, rather than the use
of annotation, which is a solution that BEA has chosen to use to implement
some of these functions.
Use Case 10 (was Scenario 2): 
Again, filters are a design choice - agents could be used, the parties could maintain
a view of their shared state, etc.  Let's concentrate on the run-time validation
and not the solutions in these use cases and our requirements gathering.
Much more should be discussed regarding segmentation, as this is a part of 
multi-party collaboration which has not been adequately defined for implementation.
What characteristics are associated with long-running - if we are equating the
CPI to BPEL, we have to go further as this is outside of the current scope of
BPEL capabilities.
Business logic is not all prose, and the business rules may be held in the CDI or in
be available for the CDI to provide the execution context for the CPI.
Annotations again is an implementation decision.  The annotations are actually
a vehicle to provide a reference to external details (in this case the details
of the reliable messaging).
Please provide a distinction between the CDI and the abstract processes you
reference in the second use case for CPI.
In the future and already in the modeling world, constructs have been developed
where the choreography is not limited to processes (message exchange) but the
state of business entities.  Therefore, suggest we re-evaluate your assumption
that the behavior is only related to messages at CDI.  The business logic is
held at the CDI and potentially the CPI levels.  Note, those business rules may
be inter-dependent and not 1-1 between these two layers (orchestration and
choreography).
Use Case 11 (was Scenario 3):
What about the patterns that occur when a business analyst looks at the flow
of processes and the reusability of specific process steps that may span
multiple processes?
Tools can hide the details of what could be in CDI, and in some instances, for 
a system analyst at the CPI.  This is making assumptions about the technology
and its use without further evaluating the audience for either.
Need some mechanism to associate CPI and CDI, as well as look at the propagation aspect,
that you reference.  This unfortunately may be a binding, and a design decision.
Source Code and Interoperability
Let's talk about the domain of control, and the roles/participants in the 
scenario, as well as where start begins.
Multi-party view:
Discuss what this means, and what implications it has to an abstract choreography
definition.
Annotations
Need to understand the boundaries and interactions between the business process
(and associated activities and transactions) and the reliable messaging
under it that supports interaction. We need to be clear where responsibility falls
and the interdependencies that exist.

Reword some of the requirements to be more requirements-ease, such as: 
D-CR-056 
Isn't this really to decide the what exposed view includes?
Not limited, just choice of exposure.
D-CR-016
A choreography MUST provide a global model for presenting its interactions
from the VIEW OF ALL PARTIES AS OPPOSED TO THAT OF ONE PARTY.
D-CR-020
THE CAPABILITY MUST EXIST to store instances of choreographies.
Uncertain how to handle "able to search for such instances and to
retrieve them."  This is outside of our scope.
D-CR-026
Delete robust - subjective.
D-CR-031
Need to discuss - this is outside of our scope.
D-CR-064
"If a process detects that a choreography is not being followed correctly,
then the process SHOULD be able to use the choreography definition to
identify exactly what went wrong." 
This is not testable....Need to discuss.
D-CR-029
If we apply a 'MUST', the examples are also mandatory - is that the intent.
Suggest that examples are a separate sentence.
D-CR-059
This may be deleted given decisions about inclusion of contract negotiation (even
technical contract negotiation).
DC-CR-003
A choreography MAY have run time changes which allow the actual participants to vary. 
Should become for testability....
Participants in a choreography MAY defined during execution.
D-CR-019
Make example for C1-C2 a second sentence.
D-CR-024
Duplicate to DC-CR-003
D-CR-034
Suggest this be MAY. They may not represent a heirarchy.
D-CR-062
What is a running choreography.  Suggest we say during execution.
D-CR-050
It MUST be possible to validate a choreography definition DURING 
EXECUTION.

Note: The fact that the verification and/or validation is monitoring
and reporting is another issue or represents other requirements.
D-CR-025
Separate requirement and example. 

General
Spell and grammar checks
Separate requirements and examples.