OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-msg] Comments on SyncReply


I suggest rephrasing (1) as:

If syncReply is set to true and if the CPA indicates an application
response is included, then it must be the case that the application
has not finished processing the earlier copy of the same message.
Therefore, wait for the response from the application and then
return that response synchronously over the same connection that
was used for the retransmission.

If you take a look at the minutes for the 10/22 call

you will see that the resolution for issue 9 is recorded as:

"CPPA team will be asked to include a mshSignalsOnly sync reply

In other words, the sender should set syncReply to true if the CPA
indicates a syncReplyMode other than "none". If the receiver sees
syncReply=true and the CPA indicates mshSignalsOnly, then it
will return only the Ack synchronously. If the CPA indicates
signalsOnly, signalsAndResponse, or responseOnly, then the
MSH must wait for the corresponding application response before
returning that response (along with the Ack) synchronously.

For better alignment between MSG and CPPA, I propose that we
replace the syncReply boolean attribute with the same
syncReplyMode attribute used in the CPP/A.


-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>
Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Tuesday, November 06, 2001 7:40 AM
Subject: [ebxml-msg] Comments on SyncReply


You said this statement is incorrect in section 7.5.5:

(1)     if syncReply is set to true and if the CPA indicates an application
response is included, ignore the received message (i.e. no message was
in response to the received message, or the processing of the earlier
message is
not yet complete)

I agree, but I don't know how to change this.  I think the Receiver should
ahead and bundle the 'HTTP 200 OK' together with any MSH signals (Acks,
Pongs, StatusResponse, DeliveryReceipt) and send these back immediately
waiting for Business Responses.  The channel should then be left open
for Business Signals/Replies.

IMO, SyncReply simply changes the role of each party concerning closing the
connection.  If SyncReply=false, then the sender is responsible for closing
connection.  If SyncReply=true, then the Receiver is responsible for closing
connection.  The receiver MUST be able to handle the case where
but there is no Response to send back.  I have serious doubts about the
of holding connections for Business Responses since in many cases there will
human intervention required.  There is perhaps a good use case for holding
connection for Business Signals.  IMO, MSH signals should be sent with the

What shall we do?


David Fischer
Drummond Group.

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC