ebBP 3/31/2005: Comment re: Multi-Party (wd10-schema 2/22)

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

Question from Sacha Schlegel raised re: multi-party collaboration and 
status visibility in Tuesday's call. Discussion summary:

    * All complex business transactions can allow you to get the state
      information without being actively involved. This is supported by
      Status Visibility, for BTA or  CBTA within a CBTA.
    * A business process will be documented in the ebBP instance and
      maps to CPPA. The conversationID should allow you to pair
      interactions. This allows a link between message traffic and a
      process instance at runtime. At design time, the Process
      Specification and roles are defined (and should occur in the
      process instance).
    * In the future and in a future version, coordination capabilities
      may involve a third-party (coordination) player, rather than a
      community of peers.
    * Historicall, multi-party has been and continues to be a complex
      area that may only be partially understood and defined in many
      circles.

Dale, please review annotation change. Comments or any 
additions/suggestions welcome. Thanks.
=========================================================================================================
Section 4.5.1
[add at end of section on Business Collaboration]
Business Collaboration between more than two abstract partners or 
top-level roles (i.e. multiparty collaboration) may be conducted in many 
presumed ways, including using coordination or as a community of peers. 
Functions to support multiparty collaboration may include status 
visibility, state alignment, identity, business constraints, etc. 
Business requirements are being gathered to gain more understanding of 
and define constructs for complementary functionality to support this 
type of Business Collaboration in addition to capabilities in this 
technical specification.

-------------------------
Section 4.6.7.1
[re: CBTA and status visibility]

[1] Change from:
When status visibility is desired, a simple scenario is provided: A 
Buyer and Seller may be parties to the business collaboration. 

[1] Change to:
When status visibility is desired for a ComplexBTA, a simple scenario is 
provided: A Buyer and Seller may be parties to the business collaboration. 

[2] Change from:
In the v2.0 technical specification, the nesting for status visibility 
and transitions is unbounded while more business requirements are gathered.

[2] Change to:
In the v2.0 technical specification, the nesting for status visibility 
and transitions in a ComplexBTA is unbounded. More business requirements 
are being gathered to determine the need and use of status visibility in 
other activities such a Business Collaboration (multi-party) and the 
utility of administrative monitoring.

-------------------------
BPSS schema
Change from:

    </xsd:element>
    <xsd:element name="*StatusVisibility*">
    <xsd:annotation>
      <xsd:documentation>Information (which can be aggregated) returned
    by the subparties of an embedded Business Transaction Activity for
    visibility purposes to the cBTA. For example, a subparty (requester
    in an embedded BTA that is responder in cBTA) returns aggregated
    supplier information to the cBTA prior to the responder issuing an
    order response. The Status Visibility element specifies which status
    values and which Document Envelope events of the embedded processes
    are considered, if any, when returning the status value to the
    context of the cBTA. If no status values or DocumentEnvelope events
    can be monitored, then both BusinessDocumentList and
    SubstateVisibility are omitted. Note, this element was added in
    v2.0.</xsd:documentation>
      </xsd:annotation>
    .......
    </xsd:element>

Change to:

    </xsd:element>
    <xsd:element name="*StatusVisibility*">
    <xsd:annotation>
      <xsd:documentation>Information (which can be aggregated) returned
    by the subparties of an embedded Business Transaction Activity or
    ComplexBTA for visibility purposes to the outermost ComplexBTA. For
    example, a subparty (requester in an embedded BTA that is responder
    in ComplexBTA) returns aggregated supplier information to the
    ComplexBTA prior to the responder issuing an order response. The
    Status Visibility element specifies which status values and which
    Document Envelope events of the embedded processes are considered,
    if any, when returning the status value to the context of the
    ComplexBTA. If no status values or DocumentEnvelope events can be
    monitored, then both BusinessDocumentList and SubstateVisibility are
    omitted. Note, this element was added in v2.0.</xsd:documentation>
      </xsd:annotation>
    .......
    </xsd:element>

=========================================================================================================