[ebxml-cppa] A proposal for the interpretation of differentsynchronous reply modes in the CPP/A

[Arvola Chan <arvola@tibco.com>]

Consider a typical business transaction that includes both a
RequestingBusinessActivity and a RespondingBusinessActivity. Assume that
receipt acknowledgment signals are to be used both for the request activity
and for the response activity (i.e., their time to acknowledge receipt are
specified), but no acceptance acknowledgment signal is to be used (i.e.,
time to acknowledge acceptance is not specified for the request activity).
Furthermore, assume that the business level messages are to be exchanged
using Reliable Messaging.
For the default (fully asychronous) response mode using HTTP binding, each
such transaction includes the following 8 messages that are sent over 8
separate HTTP connections:

  1.. Reliable request message from requestor to responder
  2.. Best-effort MSH level Ack from responder to requestor (for message 1)
  3.. Reliable business level Ack from responder to requestor
  4.. Best-effort MSH level Ack from requestor to responder (for message 3)
  5.. Reliable response message from responder to requestor
  6.. Best-effort MSH level Ack from requestor to responder (for message 5)
  7.. Reliable business level Ack from requestor to responder
  8.. Best-effort MSH level Ack from responder to requestor (for message 7)
The use of synchronous reply modes can be effective for reducing the total
number of messages / HTTP connections necessary to complete the transaction.
The CPP/A spec currently recognizes the following synchronous reply modes:

  1.. signalsOnly
  2.. signalsAndResponse
  3.. responseOnly
A new synchronous response mode mshSignalsOnly is hereby proposed. The
following interpretation of these 4 synchronous reply modes is suggested:

  1.. mshSignalsOnly – The MSH level Acknowledgment (which can include an
MSH level Acknowledment element, a MSH level DeliveryReceipt element, or
both) is returned as a self-contained ebXML message in the same connection
that is used to carry the incoming message being acknowledged. Business
level signals and response messages are returned separately. If this
synchronous reply mode is used uniformly for all of the business level
messages, the above business transaction can be accomplished using 4
separate HTTP connections.
  2.. signalsOnly – The MSH level Acknowledgment (which can include an MSH
level Acknowledment element, a MSH level DeliveryReceipt element, or both),
along with the receipt acknowledgment business signal and the (optional)
acceptance acknowledgment signal are packaged into the same ebXML message
and returned in the same connection that is used to carry the incoming
message being acknowledged. The above message does not have to be sent
reliably because it is being returned synchronously. If it is not properly
received by the requester, the original request message will be retried
because the requester is using Reliable Messaging. The business response
message must be sent reliably (i.e., with retries) over a connection that is
separate from the one used for the request message. If this synchronous
reply mode is applied to both the request message and the response message,
the above business transaction can be accomplished using 2 separate HTTP
connections.
  3.. signalsAndResponse – The MSH level Acknowledgment, plus the receipt
acknowledgment business signal, plus the (optional) acceptance
acknowledgment signal, plus the business response, are all packaged into the
same ebXML message and returned in the same connection that is used to carry
the incoming request message. This effectively overrides the BPSS
specification and does away with the business level receipt acknowledgment
from the requestor to the responder to indicate successful receipt of the
response message. Because the signals and response are returned
synchronously, the embodying ebXML message does not need to be sent
reliably. There will not be any retry for this ebXML message. If the
requestor does not receive the signals and response message, it can simply
retry the request message. The entire business transaction can be
accomplished in one HTTP connection.
  4.. responseOnly – The response message is returned synchronously. This
also effectively overrides the BPSS specification and does away with the use
of business signals in the transaction altogether. No receipt
acknowledgement business signal is to be used for either the request message
or the response message. The MSH level Ack (which can include an MSH level
Acknowledment element, a MSH level DeliveryReceipt element, or both) can be
piggybacked on the business response message. As in the case of
signalsAndResponse, the response message does not need to be sent reliably
because it is being returned synchronously. Again, the entire business
transaction can be accomplished in one HTTP connection.
Because the signalsAndResponse and responseOnly synchronous reply modes do
away with the sending of the receipt acknowledgment business signal for the
response message, non repudiation of receipt for the response message cannot
be accomplished. In the case of signalsAndResponse, non repudiation of
receipt for the request message can still be supported. Both the
mshSignalsOnly and signalsOnly synchronous reply modes allow for the non
repudiation of receipt for both the request message and the response
message.

If a reliably delivered message is in error, the receiving MSH returns a
standalone MSH level error message that is sent using BestEffort only, if
synchronous reply mode is not in use. Otherwise, the standalone MSH level
error message is returned synchronously. If the incoming message has been
passed onto the receiving application and the latter determines that there
is an error, an application level error message (considered a business
signal) is returned. The quality of service used for this business signal
should be governed by the synchronous reply mode as applied to business
signals. For both the signalsAndResponse and signalsOnly modes, the business
signal is returned without an accompanying business response. For the
responseOnly synchronous reply mode, it is not immediately obvious how the
application level error message should be returned. However, for the sake of
simplicity, it is recommended that it be treated as a response message and
returned synchronously.

The above treatment of the signalsAndResponse and responseOnly synchronous
reply modes is more or less consistent with the treatment of synchronous
response in the RosettaNet Implementation Framework version 2.0.
Essentially, no receipt acknowledgment is used for the response message. In
RosettaNet’s case, there is no provision for piggybacking a business signal
on a business response message. Thus, a business signal can only be returned
synchronously if the transaction does not call for returning a response
message (in other words, the transaction has a single action rather than two
actions). If there is a response message, then no receipt acknowledgment
signal for the request message can be included in the synchronous response.
The RosettaNet Implementation Framework does not allow for non repudiation
of receipt for the response message, if synchronous reply mode is in use.

Please let me know if this proposal makes logical sense.

Thanks,
-Arvola