[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] SyncReplyMode is a misnomer?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC