RE: [ebxml-bp] ActionItem: Potential Expressive Shortcomings in Role information within current BPSS approach

[Jean-Jacques Dubray <jeanjadu@Attachmate.com>]

Title: RE: [ebxml-bp] ActionItem: Potential Expressive Shortcomings in Role information within current BPSS approach

Dale:

I agree with your analysis. I would like to add two comments:

1) on the cardinality section, I don't think that there are any ways to express in BPSS a collaboration that involve an arbitrary number of bidders (almost like a pub/sub mechanism). We can of course express in a BPSS what would be the collaboration between the shopper and ONE bidder, but there is no way to express and monitor ONE collaboration between the shopper and all the bidders.

2) With respect to the multiparty collaboration concept. IMO, if we go that way, we will have to modify the architecture of ebXML. The beauty of binary business transactions (and therefore collaboration) is that they do not require coordination.

However, as soon as we enter a n-participant relationship we need to define a coordination service that all participant can turn to, to figure out the state of the multiparty collaboration. This is the classical case where C can only talk to A if B has talked to A first. How does C knows when it can talk? I am supportive of your proposal, but I think we should also talk at the ebXML architecture level, not just at the modeling level.

Happy new year !

Jean-Jacques

-----Original Message-----
From: Dale Moberg
To: ebXML BP
Sent: 1/2/04 10:13 AM
Subject: [ebxml-bp] ActionItem: Potential Expressive Shortcomings in Role information within current BPSS approach

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.