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

["David RR Webber" <david@drrw.info>]

Anders,

All makes sense.

What I'd like to see in the specification Addendum - is a sub-heading
with each of these items - and a code fragment of how in the XML
it is support - sort-of - cheat-sheet / quick-start implementation guide...

Thanks, DW
----- Original Message ----- 
From: "Anders W. Tell" <anderst@toolsmiths.se>
To: <Monica.Martin@Sun.COM>; <dmoberg@cyclonecommerce.com>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent: Tuesday, November 18, 2003 5:15 PM
Subject: RE: [Fwd: [ebxml-bp] [ebBP] 11/13/2003: Starting List
ofCategoriestoScope ebBP 2.0]


> 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          /
> /////////////////////////////////////
>