12/1/2003: Business Partner Roles - Role Reversal/MultipleRequest/Responses for a Given Role

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

For today's call, everyone, this is just a START on a discussion about 
business partners, roles and how they may affect BPSS. This is by no 
means complete nor a definitive summary. I'd like to 'throw' some of the 
ideas out there to get the discussion going. Please try to review so we 
can begin to discuss on today's call. I've already asked some of the 
team to review and begin to think about this Work Item. We will continue 
our discussion next week when Dale Moberg is available for the call (air 
flight today).

Thanks.


In previous discussions, the business partner and the role specified in UMM are of a partner that can play multiple roles and that participates 
in transaction activities.  In a Binary Collaboration, a role of a business partner and an authorized role are identical. The partner, 
partner type, and authorized role are defined in BRV and BTV respectively. However, in the context of the business collaboration and 
supporting business transaction activities, more may be required.

Inputs from UBAC indicate that a partner type may be chosen for a business collaboration for a real-world partner who binds the partner 
type to the role in the business transaction, whereby specific business or legal context is also seemingly bound. There the PartnerType is a 
placeholder for a partner, when the BPSS is instantiated.  The CPPA may restrict the real-world partner's behavior.  In the context of what is 
evolving in UBAC, a Partner may be obliged to prescribed behavior [1].  How and to what extent these are addressed lies with the ebBP TC.

Currently, in looking at BPSS, a binary collaboration is defined between two roles (buyer and seller, for example). A business transaction 
activity will then bind the abstract roles of the business transaction to the concrete roles of the collaboration (initiator-> buyer, etc., for 
example). A business collaboration is a set of Business Transactions between business partners. Each partner plays one or more roles in the 
collaboration.

In the CPA negotiation, two new requirements functions were identified:

  1. Role reversal within a binary compound collaboration:  The same applies for why the CPA negotiation was defined using two binary
     collaborations. The initiator and receiver can reverse during the collaboration (for offers and counter offers). There was no way to
     represent the state transition in the BPSS in its  current form.
     To alleviate the issue, different transactions were used to make it clear who initiated the counter offer process.
  2. Multiple requests applied to a final transaction by one role: The CPA negotiation team handled the different role names by putting
     them in different business transactions of duplicative names (for parties in a binary business collaboration).  For example, for a
     final document as final part of the negotiation - there could be multiple requests applied to a final transaction. This cannot be
     handled currently in BPSS.

In the protocol,  it may be important to define the number of a roles of which a partner can be bound.[2]

For this discussion, we need to address multiple Work Items around roles:

  1. Role reversal within a compound binary collaboration, between two or more partners [3]
  2. Extent to which the authorized role and partner type affect or are understood by BPSS
         * Are these items understood and/or prescriptive, broadly or as it relates to a legal obligation?
  3.  What effect do more explicit roles have on BPSS (in the areas of portability or reuse, for example)? [4]
  4.  How does multi-party collaboration affect any of the above assumptions? [5]
  5.  When we begin to look at providing the mechanism to direct (not create) service behavior, what other assumptions must be made
     regarding roles?
  6. What other changes may be required for binary collaboration, business transaction or business transaction activity to support
     these requirements?

Initial *potential requirements* and recommendations:

   * Provide the capability to identify role reversal in a compound binary collaboration
          o When a compound binary collaboration occurs (inner and outer collaboration), specify a mechanism to identify the change
           in roles that does not necessitate the duplication of business transaction activities to accommodate role
           reversal. This should maintain the relationship between the inner and outer collaboration but allow flexibility in how
           roles are used to support process definition. For MPC, this assumes that the reversal is not limited to two roles. 
           Potential specification update: May require specification changes that restrict one partner from playing both roles in
           a collaboration or within a business transaction activity. Currently, in BPSS [6], the technical specification
           indicates the inner and outer collaboration roles are the same.
   * Provide the capability to allow multiple requests or responses within a business transaction for each role [7].
         o Consider attribute at the business transaction activity level.


[1] UBAC, Tell, November 2003.
[2] Tell proposal, June 2003.
[3] CPPA Negotiation team, November 2003.
[4] Tell re: Categories for 2.0 (see email archives)
[5] BusinessPartnerRole, Performs and Role = MPC
[6] ebXML BPSS v1.1