1/5/2004: Late Binding ....

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Webber: .....It's going to take some careful wording to get this all 
tied down neatly.
We start from the binary collaboration and how that is defined by the 
CPA, and
that context parameters and outcomes are known.  Then on to multi-party -
where one party has to own the process - and create agreements with the
participants.  Then - the owner will manage the controlling BPSS - that
may involve sub-BPSS interactions.  Each participant in a sub-BPSS will
know what their outcomes are - and have a CPA.  Overall - only the owner
of the master BPSS will know what that does - and they could have dynamic
runtime branching - but even they will want that locked to a pre-determined
path - it will not self-modify!  The control mechanisms are versioning and
locked registry artifacts.  So if anything changes - the BPSS should
treat that as a Fail condition - and react accordingly.

mm1: David, the one-party control/view is part of BPEL rather than BPSS.
I agree that the most relevant and known (pre-determined) paths will be 
defined
to allow those to be used. We do need to speak further about the boundaries
of BPSS and CPA, and we do have a work item to do so. This is particularly
relevant as we broaden the BPSS functionality. Let's stay focused on 
BPSS; we
have ample participation to ensure we can attain loose coupling with CPA and
ebMS.