RE: [Fwd: [ebxml-bp] [ebBP] 11/13/2003: Starting List of CategoriestoScope ebBP 2.0]

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

OK, then I think this is more interesting than I initially realized. I
will cc the list to express my opinion, and possibly be corrected. Sorry
for dropping off early.

Monica explained:

"You have a partner that is a 
specification (like a partner type loosely speaking) and when business 
rules or agreements (and their parameters) may be applied to it, you 
have a partner instance (in the modeling sense)."

By adding this partner instance, BPSS adds new "things" to its component
model, namely it adds:

An object of (serving as a placeholder (bound variable) for) a partner
type, with UBAC properties if desired. (Several bound variables of a
type may, of course, exist. I assume that we never "coalesce" these
variables (assert their identity) as we move through the process.)

Association of these objects with Roles, where a change in the
association from one binary collaboration to another may model/describe
role reversal etc. (These Roles are the same old things renamed
AuthorizedRoles. I still think we fix the semantics of Role to always be
such that "buyer" and "seller" are examples thereof.)

Thus the variable of type PartnerType (which is really what will be
bound to the PartyId(s) of the CPA) can be used to find all the roles
assumed by a given player in a full choreography.

I hope this is a correct interpretation because I think it a significant
improvement in clarity, and also is in better alignment with lower
levels. And BPSS will certainly now easily handle the reversal use case
as well as indefinite variations. CPPA will need to add some textual
changes to explain the improved alignment but I suspect the TC would
welcome these.


Dale Moberg

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Tuesday, November 18, 2003 7:25 AM
To: Dale Moberg
Subject: Re: [Fwd: [ebxml-bp] [ebBP] 11/13/2003: Starting List of
CategoriestoScope ebBP 2.0]


Dale Moberg wrote:

>   * Business partner and roles: Authorized roles, role reversal,
>
> ==>    interchangeability of roles based on business rules or business
>     agreements (precursor to UBAC [Universal Business Agreements and
>     Contracts])
>
>I am not certain I understand this too well. Is this a generalization 
>of the role reversal (Bob Haugen use case) somehow? Or something else 
>entirely?
>
>
>Dale
>  
>
mm1: This was actually what Anders discussed yesterday in the call (I 
believe you had dropped off by then). You have a partner that is a 
specification (like a partner type loosely speaking) and when business 
rules or agreements (and their parameters) may be applied to it, you 
have a partner instance (in the modeling sense). 

Here were my unedited notes on that discussion yesterday:

Tell: Looking at specifications and the difference between a 
specification and the partner,
where the partner is bound to a business collaboration.
This is missing from the UMM.
Martin: Yes the model is missing the binding to a specific role.
Webber: This maps to the CPP/A.
===The context to role - in the CPP/A - put in URL that points to an XML

that provides
the correct context. When you select a BPSS, and engage with a trading 
partner, the context
parameters are exposed for use.===
This is important for role reversal in CPP/A negotiation.
Tell: In UBAC, we will provide some clarification between prescribed 
specification and behavior.
Commit ourselves to a specification and the usage of a specification. 
Add context binding.
Webber: Suggests how to look at linking and switching of choice points 
for business entities, object flow and state.
Nagahashi: How does this relate to BPSS? In BPSS, we need a more robust 
decision
description.
Webber: BCM only talks about control flow.