12/7/2003: Updated Summary for Role Reversal - Partners and Roles

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

Updated summary for Monday's discussion. This is a work in progress, is 
by no means complete and is in line with this category of Work Items.  
See everyone Monday.

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.  The 
CPA negotiation team handled the different role names by putting
    them in different binary collaborations and business transactions of 
duplicative names.
    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:  For 
example, for a
    final document as final part of the negotiation. The CPPA 
negotiation team has found there could be multiple requests applied to a 
final transaction, and
    multiple associated structured documents. 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? Does this vary between design and runtime? [7] [8]

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.
  * Provide the capability to attach a role to a business activity 
either at design time or for late binding.

[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
[7] Enactment and impacts of late binding, Tell, 1 December 2003-Work 
Item 46

The BPSS shows a binary collaboration, the servic agreement show a few 
"legal provision" regarding the usage,enactment of a
collaborative behavior, conduct defined in BPSS. The runtime part 
"happens / occurs" ad hoc in the real world.
The BC and BT are defined using provided interfaces and the BCA, BTA are 
binding specifications with required interfaces. Start
of top level binding happens through enactment with the authorized 
role(s) chosen by initiator. Role reversal should be
implementable through switching the binding lines in any BTA.

The binding mechansim is generic and extendable (more parameters could 
be dynamic as opposed to statically defined in BPSS).
Default value may be defined in parameter if binding info is not 
provided. It is important though to keep in mind that the
initiator may only provide bindings that the other parties agrees to. So 
that the initiator must only be allowed to provide
parameters in a highly deterministic manor.

The Service agreememnt may also be used to express that only the 
permitted transactions may be executed in combination with
specific authorized roles.

[8] Potentially related Work Items in this area are: 23, 25, 28, 46 and 55.