Re: [ebxml-bp] ActionItem: Potential Expressive Shortcomings in Roleinformation within current BPSS approach

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

Dale, some comments here...

Premise: ... it is not clear how we track the association of occupants 
with Roles through a collaboration.

The BPSS associates the roles of the binary collaboration within the 
collaboration or business transaction activity where the roles become 
explicit. In addition,
in the collaboration activity, the inner collaboration and its roles are 
bound to the parent collaboration [1]. Roles are also assigned to the 
initiatingRole and respondingRole [2]. I agree this could be more 
expressive and flexibility/adaptability should be improved, although we 
do have underlying semantics from which to work.

Action: Need more expressive semantics to describe how role reversal 
takes place.

ActionGroup: Multi-party collaboration
Action: Assess the tradeoffs of MPC with coordination vs. MPC as a 
function of binary collaborations. Binary collaboration is important to 
BPSS and relevant to business, so we have to weigh carefully what 
options we consider or pursue. At this time, it appears that the first 
case may be relevant to web services, although how to effectively handle 
MPC in choreography, at least as it relates to WS-CDL (W3C WS-Chor), has 
not been defined and is clearly an area of challenge. As for a business 
collaboration, legal business parameters may dictate that the binaries 
exist as a function to enable MPC. If accepted as a working premise, may 
need to notify ebXML architecture. Multi-party collaboration, that is 
not decomposed to binaries, requires a coordination service as JJ Dubray 
indicated.

Action: Need to indicate how many occupants there are to a role.
We may not know this until runtime and dynamically. This could may 
require further coordination with CPA, or, in the case of web services, 
may be handed off to the executable business process and choreography. 
However, as indicated in our charter, we need to address how we assist 
in defining and driving those other capabilities so: (1) the business 
semantics are understood, (2) legal or binding agreements are understood 
and used, and (3) the integrity of the business collaboration is 
maintained. [3]

Action: Publish and subscribe vs. multi-cast [4].
Implications of unknown number of bidders that may be handled as a 
function of time with a maximum number of participants. At least some 
boundary must be established in order to monitor and complete the 
activity required.

[1] Section 5.12.4.1 Key Semantics of Binary Collaboration
[2] Same
[3] More capabilities may be required later with the development of UBAC.
[4] Or what Webber called 'outcomes.'

Dale Moberg wrote:

>
>   BPSS and Business Process Role
>
> /*Current Shortcomings*/
>
> Role information currently provides type or classification information 
> about the relata in a business process. In other words, given a 
> relation such as “buys” or “sells,” the things in the relation have a 
> type of “buyer” or “seller.” Other ebXML specifications, such as CPPA 
> and Messaging, tie in to the BPSS instance and use the BPSS values for 
> Role both in CPPs and CPAs as well as within the actual ebXML Message 
> header. The To, From, Service, Action and Role values provide basic 
> metainformation descriptions for relating events concerning the 
> documents being exchanged in ebXML messages to the states entered by 
> the concrete business process session.
>
> The UMM has used role as a label for a navigation link and in a 
> concept of AuthorizedRole. Previously there has been some discussion 
> how or whether the BPSS role concept adheres to or deviates from UMM 
> usage. That discussion has, in my opinion, been largely fruitless. 
> Therefore, the shortcomings that I wish to discuss do not derive from 
> prior discussions of BPSS and UMM “semantics”. Thus I here assume that 
> the semantics of Role values derives from being a type/classification 
> of relata in business processes, which is the widespread and ordinary 
> business language usage, and which I described in the first paragraph.
>
> There are several sources of inadequacy in the current approach to 
> capturing Role information which I will discuss under separate 
> headings: polyadicity, cardinality, and compositionality.
>
>
>       Polyadicity
>
> Polyadicity is the property of how many relata are in a relation. The 
> current treatment of business process deals with only abstracted 
> business relations. For example, in a concrete selling relation such 
> as “selling,” there are typically more kinds of things being related 
> than just a buyer and a seller. There is a product or service being 
> purchased and there is some arrangement made for something to be 
> received in exchange for the product or service (a payment, for 
> example). [Otherwise we might have a hard time distinguishing 
> “selling” from “giving”.] UMM inspired business process models so far 
> do not capture cleanly these richer business process relational 
> descriptions, but that is not necessarily a shortcoming. We can regard 
> the four place selling relation (buyer, seller, product, payment) as 
> the basis for a two place selling relation (buyer, seller) with the 
> product and payment assumed to exist, but remaining unidentified.[In 
> logic this would be done by existentially quantifying over the product 
> and payment relata.] In other words, expressive incompleteness of our 
> current model need not always be a shortcoming but may merely be an 
> indication of a certain “level of abstraction.”
>
> However, for some time it has been thought that there needs to be a 
> distinction between multiparty (greater than two) and binary (two) 
> business relations (the relations being viewed as things in their own 
> right, called collaborations). For example, an escrow business process 
> might exist between three parties, a seller, buyer, and the escrow 
> agent. A buyer might arrange with an escrow service to hold its 
> payment until the delivery of a product, and the seller might wait to 
> ship until the escrow service notified it of having received the 
> payment. There might therefore be a more complicated selling relation 
> involving three relata, each with a distinctive business role. It is 
> then the number of /types of /business agents involved that motivates 
> introducing multitparty relations with greater than two roles.
>
> There is a theorem of logic (more accurately, model-based 
> representation theory) that shows that any n-place relation can be 
> defined in terms of 2-place relations. This theorem (deriving from 
> Quine) is unquestioned extensionally speaking, but is a perennial 
> philosophical favorite for endless debates over whether “something” is 
> lost “intensionally viewed.” Though I personally would be happy to 
> restrict BPSS to binary collaborations, I could agree that multiparty 
> collaborations might be cognitively more natural for some analysts 
> describing a process. If these multiparty collaborations then “expand” 
> into collaborations involving at most 2 parties, the connections with 
> CPPA and Messaging remain as they now are. However, for multiparty 
> collaborations that are not, in some sense, composed from (or based 
> upon) 2 party collaborations, there will be currently be no ebXML 
> implementation for the underlying message and document exchanges that 
> implement them. ebXML Messaging and CPPAs are currently 2-party 
> restricted, and will remain so, probably well past the version 3 level.
>
> At any rate, if we are to “expand” multiparty collaborations into 
> binary ones, we need to be able to indicate connections between 
> subsets of the roles in a multiparty collaboration and the roles in 
> the underlying binary collaborations. I think one shortcoming of 
> current BPSS is that expressing the connections between Roles in one 
> “segment” of a business process and Roles in another segment is 
> basically absent, or at least not powerful enough to keep track of 
> what needs tracking.
>
>
>       Compositionality
>
> The crux of the shortcoming over Role that we currently have is that 
> our working models identify the role of a Business process segment 
> (for example, a CollaborationActivity or a 
> BusinessTransactionActivity) but does not represent the occupant of 
> the role. Therefore, there is no clear way of indicating the 
> connection that the occupant of Role1 in Segment1 is the occupant of 
> Role5 in Segment5. Roles are currently captured technically just as 
> attributes (toRole, fromRole) on the BP segment, and while we can 
> reference Roles by nameIds, it is not clear how we track the 
> association of occupants with Roles through a collaboration.
>
> Bob Haugen and others have previously shown this limitation by 
> considering the case where occupants reverse roles. If we want to 
> compose a distributorship collaborative business process from a pair 
> of buyer-seller relations, logically we need to keep track that the 
> distributor is a seller to the retailer, but a buyer from the 
> manufacturer. That is, the occupant of the initial seller role can be 
> the occupant of the buyer role later on.
>
> Therefore, the current notation is insufficiently expressive to 
> indicate that the occupant of a role in one BP segment is the same as 
> the occupant of (the same or different) role in another BP segment. I 
> think that if we can agree upon what we need to do, we can then work 
> out a suitable XML way to capture this expressive requirement.
>
> I am going to wait to see first if there is agreement on at least 
> needing to augment the expressive apparatus of BPSS before getting 
> into XML syntax matters. However, I would note that the abstract 
> Performs constuct that was deprecated in version 1.1 does part of what 
> is needed to increase the expressive power. I think I would agree that 
> the current notation (where something called a BusinessPartnerRole has 
> a Performs EII) is confusing.
>
> However, I would prefer to introduce more globally the cast of 
> participants in the BP, and then reference them as needed to tie them 
> to Roles within a given BP segment. So we would have an Association 
> within a BusinessTransactionActivity or within a CollaborationActivity 
> that abstractly connected one of the participant player with a Role
>
> So in other words we would have something like
>
> Cast: a, b, c (as needed).
>
> RetailerOrdersfrom Distributer:
>
> RoleAssociation(a-ref, roleid-to-buyer)
>
> RoleAssociation(b-ref, roleid-to-seller)
>
> DistributerOrdersfromManufacturer:
>
> RoleAssociation(b-ref, role-idref-to-buyer)
>
> RoleAssociation(c-ref, role-idref-to-seller)
>
>
>       Cardinality
>
> Finally, and less critically, there is at present no indication of how 
> many occupants there are for a role, or that occupants are entering or 
> exiting.
>
> For example, in a request-for-quote business process, we can imagine 
> that there is the role of shopper (quote-seeker)and the role of bidder 
> (quote-offerer). However, it might be useful to be able to annotate 
> somehow to indicate that initially there are say up to 100 bidders, 
> but that later on, one (or five) of those bidders gets the PO. It is 
> not that there are new roles involved or that the role association 
> connections are not expressible, but rather that the numbers of 
> players in a role goes from some large number in one role to a smaller 
> number in a connected role later.
>
> There are several other possible use cases where we might want to 
> express cardinality restrictions on role occupants. I propose that 
> this also be an area investigated as we make changes to the Role 
> schema apparatus.
>
=================================================================================================================