----- Original Message -----
Sent: Sunday, January 04, 2004 2:42
AM
Subject: 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.