[ebxml-cppa] BPSS & CPP/A alignment issue: synchronous vs asynchronousflow of control

[Arvola Chan <arvola@tibco.com>]

BPSS is based on the metamodel behind the UN/CEFACT Modeling Methodology (UMM) defined in the N090R9.1 specification. Recently, Paul Levine also posted chapters for N090R10 at http://www.ebtwg.org/projects/documentation/bioreference/.

 

In both versions (Chapter9_Metamodel.pdf in N090R9.1 and Chapter8_Metamodel.pdf in N090R10), it is stated:

 

A business transaction specifies either a synchronous or asynchronous flow of control between two activities. The business transaction is a unit of work. All of the interactions in a business transaction must succeed or the transaction must be rolled back to a defined state before the transaction was initiated.

 

There are two business signals that can be asynchronously returned to the initiator of the business transaction: a business signal to verify proper receipt of a business document request and a business signal to non-substantively confirm the acceptance of a requesting business document for business processing.

 

If any of the time out parameters are exceeded, a time out exception must be thrown. If the retryCount property on the responding business activity is greater than zero then the business transaction must be re-initiated (or a notification of failed business control – possibly revoking a contractual offer – must be sent). All business signals and business documents returned after the transaction was initiated and up until the time out exception must be discarded. The recurrence property specifies the number of times a business transaction must be initiated. If the recurrent property value is 3 then the business transaction can be initiated a total of 4 times (the first initiation plus 3 retries). The time to perform property specifies the time to perform a single business transaction.

However, BPSS 1.01 captures neither the synchronous/asynchronous nature nor the retryCount property of a business transaction, thereby posing alignment issues with CPP/A. In BPSS, timeToAcknowledgeReceipt is specified at the level of RequestingBusinessActivity and RespondingBusinessActivity while timeToPerform is specified at the level of BusinessTransactionActivity. In practice, timing characteristics (especially timeToPerform) are often very different between synchronous and asynchronous transactions. For example, RosettaNet PIP 2A9 specifies a synchronous timeToPerform of 5 minutes with a retryCount of 0, and an asynchronous timeToPerform of 24 hours with a retryCount of 3.

 

At the CPP/A level, it is allowable to specify a syncReplyMode with possible values None, signalsOnly, signalsAndResponse, and responseOnly. However, if a BusinessTransaction has been designed to be asynchronous (with corresponding timing parameters) and yet not declarable as being asynchronous, then any attempt at the CPP/A level to specify the use of a synchronous delivery channel may end up with timing parameters that are quite inappropriate for synchronous interactions.

 

Since the 1.1 CPP/A spec will not have the capability to explicity override BPSS timing parameters, it seems more appropriate to capture the synchronous reply and retryCount parameters at the BPSS level and have CPP/A derive those parameters from the corresponding business process specifications. I think BPSS should allow a BusinessTransactionActivity to be declared as synchronously only, asynchronous only, or both.

 

Another issue with leaving sync reply mode not being specified at the BPSS level is that it becomes unclear whether its specification at the CPP/A level constitutes overriding of related BPSS specified timing parameters. It seems reasonable to interpret the modes signalsAndResponse and responseOnly as requiring that the entire transaction be completed synchronously. That would imply no receipt acknowledgment is used in either direction in the case of responseOnly, and no receipt acknowledgment for the response is returned by the transaction initiator to the transaction responder in either mode (and thus overriding of the timeToAcknowledgeReceipt parameter). However, this might also conflict with any non repudiation of receipt requirement associated with the BusinessRequestActivity and the BusinessResponseActivity. Either the BPSS spec or the CPP/A spec, or both, should clarify the expected behavior when such conflicts arise (i.e., non repudiation of receipt is required and yet no receipt acknowledgment signal is used).

 

Thanks,

-Arvola