Overview of CPP formantion and Implementation concerns on BPSS Role.

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Implementation Assumptions in this Message:

There are three use cases for BPSS instances:

1. A Business Processing modelling tool creates, changes, and
imports/exports BPSS instances. 
[None of the following pertains to the modelling tool use case.] 

2. A CPP, CPA, or Negotiation tool accesses BPSS instances as one of the
inputs for the creation of CPPs. Likewise the BPSS instance may be
referenced during the process of forming or negotiating a CPA for
various reasons. 

3. A BP monitoring tool that can verify that actual executed message
flows conform to a path "through" the BPSS instance.

The first half of the second use case is the basis for the requirements
and constraints discussed in this message.

Here is a working list of implementation concerns from Cyclone:

[CPP formation and Role]

A CPP creator needs to be able to identify all the actions (and signals
relevant to) a party entering into a collaboration.
For example, a CPP creation tool can offer both a choice of BPSS
instance, and once that is known, a choice of roles to play during CPP
creation. The tool must then associate all the actions this role might
undertake with configuration information in delivery channels and other
binding declarations.

The CPP obtains values for ebXML Message header values for Service,
Action, Role from the BPSS instance. It also assembles its internal
mapping construct, ActionContext, the ProcessSpecification attributes,
such as uuid and href values

The CPP construction process needs clear conventions (with syntactical
tokens that realize these conventions) for:

a. Entry points (toplevel) process constructs (such as, Binary
Collaboration, OperationActivity or MultipartyCollaboration),  with
explicit declaration of Role values participating in the business
process within the start construct. 

b. Referring conventions: the current use of both names and IDs (GUIDs)
to implement reference means that BPSS traversal is ambiguous as to
which referring mechanism should be followed. In each referring context,
at most one mechanism should be actually operative and therefore only
one that needs to be chased. [This reduces both the implementation
burdens and removes the possibility of references being ambiguous by
pointing to different objects.] 

c. When a subprocess is referred to, a clear indication of what Role
value in the referring context "goes with" which value in the
referred-to process segment. Without this, the notation is ambiguous
with respect to CPP creation. When finally reaching the
BusinessTransactions, the mapping of Role to requesting or responding
role should also be unambiguous. 

d. Using Performs in all cases would be the most explicit way to
indicate the Role mappin s, but when the number of
Roles and the values of Roles don't change, the "identity" mapping may
be regarded as the default when Performs is
omitted. (That is, "buyer" maps to "buyer", "seller" to "seller".)