[ebbp] 2/27/2004: [RSD] Nested Collaboration Summary

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

OASIS.ebBP.WI26-NestedCollaborationsAndRoles;
Topic|Referring,Roles,Reusability;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00214.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00218.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00242.html;
Point|Collaboration summary;

mm1@
||Attachment: Moberg initial summary on roles: 
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00214.html
||Attachment: Moberg summary on three options: 
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00218.html
||Attachment: Moberg summary update on roles: 
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00242.html

Points to consider:

    * Main containers (elements) for complex flow control include
      BinaryCollaboration, MultipartyCollaboration, and possibly
      CollaborationActivity. BinaryCollaborations and
      MultipartyCollaborations can basically have very similar content
      models except that the number of "locally declared Roles" willdiffer.
          o Provide local and global Role definitions.
          o All bindings use Performs elements. Adding global Roles to
            indicate BusinessPartnerType supports Tell's recommendation.
            Performs allows assocation of local and referenced Roles.
            This supports reusability. The locally "visible" Roles are
            analogous to the actual parameters in the call, and the
            declared Role values in a flow container declaration are
            analogous to the formal parameters.
          o An attribute on Performs has been suggested to indicate the
            initiating role.
    * Options to support MPC:
          o Indicate a Fork over two business transactions: Could lead
            to deadlock, non-deterministic and may impact capability to
            monitor.
          o Interpolate a business transaction: Impacts reusability.
          o Syntax to indicate dependencies: Nest a BTA element inside
            another to indicate that the included BTA must complete
            before the first BTA completes. Or, add an attribute in the
            Performs binding.


Potential requirements:

    * Must support CPPA and BPSS alignment where the CPPA can track the
      Role in one flow container or business tranaction down ot the
      primitive collaboration patterns (such as a Notification,
      Request-Response, etc.).  The CPPA should be capable of
      identifying the BPSS BusinessTransactions that a given party will
      support, and also select from the global view of BPSS the Role
      perspective of one participant (party) (for a CPP).
    * Multi-party collaboration association should support reusability.
    * The initiating role should be indicated in an activity.
    * Support alternate mechanisms for transactional entry [Reference
      manual entry/Roberts case; Distributor case/Haugen-Fletcher and
      Multi-party/Yunker].
    * BinaryCollaborations can be referenced by arbitrary containing
      constructs.
    * BinaryCollaborations can occur at top-level.
    * Roles can be switched between a /from/ or /to/ mode within
      BinaryCollaboration
      This implies that /from/ or /to/ status is marked in the
      binding/reference construct, and not statically in the construct
      referenced.  This differs from previous versions. Forward
      compatibility could be attained through XSLT transformations.
    * BusinessTransaction and all its specializations are the primitive
      flows.
    * BinaryCollaboration and Multiparty Collaboration are distinguished
      primarily by the number of Roles considered within a construct.
      Logically they are specializations of an abstract collaboration.

Open items:

    * New approach takes on a forward reference. The Success and Failure
      states also have references pointing back. Moberg has suggested we
      use Performs here also.
    * Determine how to mark the top-level flow constructs (use a Start
      state?) is another pending item.
    * A final issue is whether we should dispense with
      CollaborationActivity in Referencing BinaryCollaborations.
      Minimally, the CollaborationActivities should allow reference
      either a MultipartyCollaboration or BinaryCollaboration.

Pre-current draft:.....................
source <xsd:element name="CollaborationActivity">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="BusinessActivity">
<xsd:sequence>
<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="binaryCollaboration" type="xsd:string" use="required"/>
<xsd:attribute name="binaryCollaborationIDREF" type="GUIDREF"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>

I encourage everyone to comment on this so we can formalize our thoughts 
in looking to finalize proposals and move toward voting on this as one 
of the important items. Martin Roberts has already started to work on 
this for the schema, so NOW is the time to comment. We will be 
discussing this next week via email in anticipation of our meeting 8 
March 2004. Thanks.

@mm1