[ebxml-cppa] Re: [ebxml-msg] SyncReplyMode is a misnomer?

[Prasad Yendluri <pyendluri@webmethods.com>]

Arvola (et al),

The SyncReplyMode was designed to specify what should be returned synchronously,
on the same transport level connection as the original request. Bundling of
multiple entities into the same request is NOT what it defines. David B and I
went back and forth on this numerous times and I thought we resolved it in
Vienna once and for all. Somehow I am not surprised that this debate surfaces
again. How to bundle (package) things together is a totally different issue from
what is delivered synchronously. The spec already specifies how to pack
different entities into a message. There is no need to add yet another parameter
to specify what should be packed together in the returned message, unless it has
a need to do so, which happens to be the case for (transport level) synchronous
replies.

Chris Ferris and I worked with the CPA team to incorporate the relevant aspects
into the CPA spec. Synchronous replies on transports like HTTP is what this
designed for. I guess the understanding there is based on that.

Regards, Prasad

-------- Original Message --------
Subject: [ebxml-msg] SyncReplyMode is a misnomer?
Date: Mon, 22 Oct 2001 13:39:10 -0700
From: Arvola Chan <arvola@tibco.com>
To: ebxml-cppa@lists.oasis-open.org
CC: ebxml-msg@lists.oasis-open.org

During this morning's ebxml-msg conference call, we discussed issues related
to the synchronous reply model, and how the MSG and CPP/A specs need to be
harmonized.

A number of participants opined that the syncReplyMode attribute is really
describing the bundling of business signals with business response into the
same ebXML message and has nothing to do with the transport characteristics
(whether a synchronous channel is used). If so, the values signalsOnly,
signalsAndResponse, and ResponseOnly ought to apply to the SMTP binding as
well. If this is the case, then syncReplyMode is a minomer, and the CPP/A
team ought to come up with a different name to convey the fact that this
parameter applies to both synchronous and asynchronous delivery channels.

I pointed out that the CPP/A team is probably assuming that a synchronous
delivery channel (with an HTTP-like binding) is used when syncReplyMode is
not set to "None", because we have been talking about the need to know the
signing certificates for both the initiator and the responder for a delivery
channel when syncReplyMode is other than "None". However, if that's the
interpretation for syncReplyMode, then should there also be a way to
describe in the CPA that an SMTP transport is to be used, and yet signals
and response are to be packaged together?

In general, I have been advocating that a syncReplyMode of
signalsAndResponse and responseOnly should be interpreted as overriding some
BPSS parameters related to the use of business signals and non repudiation
of receipt. In either case, (a syncReplyMode of signalsAndResponse or
responseOnly), the initiator would not be returning a business level receipt
acknowledgment signal for the response (which otherwise would have to come
back on a separate channel because the responder is expected to close the
connection once the response is returned). If we do allow for the CPA  to
override the business process specification, then we may also want to ask if
such overriding is meaningful, regardless of the synchronous/asynchronous
characteristics of the delivery channel.

Regards,
-Arvola