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

["Anders W. Tell" <anderst@toolsmiths.se>]

Since I was referenced so Ill jump in the discussion again.

Ill adresss the same issue slightly differently with a number of separate 
statements for easy critical review :)

- A BPSS is a specification which by itself doesnt mean anything.

- A BPSS may be reused so it must not be bound to any real world partner.

- A signature in a BPSS specification document most likelly dont mean anything
else than "Im the author of the BPSS". (authenticity of origin?) The author is
not liably for any use of the BPSS.

- A PartnerType in a (communicative) behavior specification such as BPSS is
place holder for a Partner that may/could "use/instantiate/enact" the BPSS at
some point in time.

- A PartnerType may be associated with constraints indicating that only real
world partners that satisfy certain conditions may use be bound to the
PartnerType during the enactment (at some point in the future).

- A real life partner uses/instantiates/enacts a BPSS and *in the enactment act
the partner binds himself to a PartnerType* and assumes a specified role. Doing
so a number of business rules/contexts apply from various business scopes
(governing business level-UBAC, from TPA, from BPSS, from technical level CPPA
and the enactment itself).

- A CPPA may further restrict the real life partners when they enact/instantiate
BPSS behavior by associating the enactment with governing technical rules. A
CPPA does not imply that a BPSS ever will be enacted.

- UBAC: In a contract a Partner may express an "attitude" towards a behavior
specification such as BPSS. An "obligation" attitude means that the partner
thinks the BPSS is a correctly specified and the partner will use it when
appropriate.

- UBAC: In a contract a Partner may express an obligation towards a "prescribed"
behaviour. A prescribed behavior is an expression that indicates that a
behavior will be/must be enacted in the future under some constraints. An
example is that a ServiceOriented BPSS must only be enacted/instantiated during
office hours 8.00 -17.00 and only 5 times otherwise extra service (support)
invocations/enactment must be purshased. Another example is that a delivery
must be performed only once and culminate before a certain time.

- Advanced UBAC:: A contractual commitment may be viewed as a partner with an
obligation attitude towards an objective to reach a certain state-of-affair
(fullfillment condition) by enacting prescibed behaviour (possibly using BPSS
to communicate success or failure).


Hope it provided some further understanding of the problem domain and fuel for
the discussion.


/anders

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.




--
/////////////////////////////////////
/ Business Collaboration Toolsmiths /
/ website: <www.toolsmiths.se>      /
/ email: <anderst@toolsmiths.se>    /
/ phone: +46 8 545 885 87           /
/ mobile: +46 70 546 66 03          /
/////////////////////////////////////