Thank you for the detailed explanation.
Related to the earlier question, I have one more question reg. the semantics
of the choreography.
eBPSS states that the RequestingRole within the BusinessTransaction
is the arbiter to decide whether the Transaction failed or succeeded. For
Failures the spec gives unambiguous resolution. The requestingRole rolls
back the transaction and sends a notification of failure in a separate
transaction if it fails and respondingRole rolls back the transaction and
just sends an exception signal.
However, the spec does not seem to explicitly specify how success of
a transaction is communicated to the responding role. Does the requestingRole
send some sort of success message to the respondingRole? How does the respondingRole
know the transaction succeeded? Is this left to implementors of ebXML?
The reason this question is related to the earlier one is that, had
we assumed that initiating role and responding role do not get to become
requesters as well as responders, then the responder need not know the
success of business transaction. Within the Binary Collaboration, the responder
is a mere listener to request messages and it is the requesting role that
is responsible for the transition to business states on success.
But since initiating and responding roles can become requesters as
well as responders within the binary collaboration, how to address the
<BusinessTransactionActivity name="Place Order Activity">
<BusinessTransactionActivity name="In between Activity">
<BusinessTransactionActivity name="Send Invoice Activity">
The Success of "Place Order Activity" business transaction is
decided by the role "buyer". And hence he can transition to next business
state "In between Activity" as again the "buyer" is the requesting role.
However on success of "In between Activity", it is the "seller" who has
to initiate the next transaction. And the spec does not specify how the
"seller" gets notified for the success of earlier transaction "In between
Jean-Jacques Dubray wrote:
the BPSS team acknowledged that this was a bit confusing and we are fixing
this in the next release of BPSS.
and Responding roles are just here to identify the two roles of the collaboration
(e.g. buyer and seller) and to identify which role will “initiate” the
collaboration, namely send the first message. The definition of these roles
does not impact their ability to participate in individual transactions
as either the fromRole or toRole. This is completely independent. This
is actually one of the great strength of the BPSS model: as the it does
not take the point of view of anyone (like an API could do). You express
a collaboration as an execution of business transactions between two roles.
Any of the two roles can initiate a business transaction.
contrast, a business transaction definition should not have any specific
role. You could use buyer and seller in a business transaction definition
but it is better to use abstract roles such as initiator and responder.
It is only the usage of a business transaction in a collaboration (aka
a business transaction activity) which specifies the specific roles that
executes that particular business transaction.
Nandini Ektare [mailto:email@example.com]
Monday, April 08, 2002 11:42 AM
[ebxml-dev] <BinaryCollaboration> in eBPSS
have a question specific to the BinaryCollaboration element in ebXML BPSS.
BinaryCollaboration element describes the business activities and choreography
of these activites.
Each Business Transaction
Activity has fromAuthorizedRole and toAuthorizedRole.
is the use of InitiatingRole and RespondingRole in the business collaboration?
it mean that during a binary collaboration the requestor role cannot become
responder role in the next business activity?
For e.g. is the Binary collaboration
name ="Product Purchase" timeToPerform="P5D">
name="Place Order Activity">
name="Send Invoice Activity">