----- Original Message -----
Sent: Wednesday, January 02, 2002
1:48 PM
Subject: [ebxml-msg] Arvola's
SyncReply issues
Arvola,
I've snipped out a few of your comments that centre on
the SyncReply element and embedded a few comments below.
Hopefully, this will move us quickly towards resolving your
questions.
thanx,
doug
----- Original Message -----
Sent: Wednesday, 02 January 2002 12:33
Subject: Re: [ebxml-msg] Messaging Spec v1.092
...
6. Line 1412: I like to point out that a
SyncReply element is not compatible with an AckRequested element that is
targeted at the next MSH.
I'm not sure why you're of this
opinion. Why couldn't the next MSH synchronously reply with an
Acknowledgment element (after it's persisted the incoming message, of
course)?
<ac>
The From Party MSH expects a synchronous
response from the To Party MSH. On the other hand, if the
intermediary MSH returns the intermediate Acknowledgment synchronously
after it has persisted the message, and then closes the HTTP
connection (prior to forwarding the message), then how can the response
from the To Party MSH be returned synchronously to the From Party
MSH?
</ac>
12. Line 1591: I think it may be
problematical for the recipient to do duplicate elimination when no
DuplicateElimination element is present. What happens if SyncReply is
present and AckRequested is not present. If the incoming message is not
passed on to the application, should any reply be returned to the
sender?
The DuplicateElimination semantics are
described rather clearly in the specification. The answer to your
question is that the synchronous reply must contain the first
response to the duplicate message. The receiver application might
not hear about the duplicate but the will get the same answer back as
the first time.
<ac>
You are correct. I was confused by the
statement on line 1788: "A Receiving MSH node is not participating in
the reliable messaging protocol for a received message if the message
either does not contain an AckRequested element, or ..." I think there
are actually four aspects of reliable messaging behavior: (1) persisting
the sent message and retry on the part of the sender when an
Acknowledgment is not returned in time; (2) returning an Acknowledgment
message by the receiver; (3) persisting the received message to
allow duplicate elimination by the receiver; (4) automatic returning of
the first response message without forwarding the message to the
application when a duplicate message is received. (1) and (2) are
triggered by the AckRequested element. (3) and (4) are triggered by the
DuplicateElimination element, or if the receiver decides to do duplicate
elimination in spite of the absence of a DuplicateElimination element in
the incoming message. Line 1589 needs to clarify what adopting a
reliable messaging behavior really means (really (3) and (4)). In the
paragraph starting on line 1591, it will be helpful to qualify "although
elimination of duplicates is still allowed" to mean that (3) and (4) are
to be done.
</ac>
20. Line 1733 and line 1738:
These two bullet points assume that syncReplyMode in the CPA is not used
with an asynchronous communication channel. This is in conflict
with the 1.0 CPP/A spec statement quoted in item 15 above. I think this
is a minor technical issue that may require some
discussion.
Would this be resolved by (more
correctly) referencing the syncReplyMode semantics in the CPP/A 1.1
specification? If not, we still have a discrepancy between the two
specifications and that should be resolved as soon as possible.
The CPP/A 1.0 specification may have some vestiges of the "bundling"
semantics I've mentioned before (using syncReplyMode to describe which
signals may be bundled with the application response). Those
semantics apply equally to synchronous and asynchronous channels.
The current SyncReply MSH semantics are all about what signals must
appear in the synchronous response over a synchronous
channel.
It's not up to the MSH to determine how
later business responses might be bundled with business signals and
asynchronous channels are therefore not relevant. Of course, the
current description of an MSH doesn't provide a way to describe
expectations around bundling of business responses and signals with MSH
signals like the Acknowledgment element over an asynchronous
channel. 2.0 issue?
<ac>
I think the simplest solution may be to
request the CPP/A team to strike out from the 1.1 spec the
following sentence: "If the delivery channel identifies a transport
protocol that has no synchronous capabilities (such as SMTP) and the Characteristics element has a
syncReplyMode attribute with
a value other than "none", a response SHALL contain the same content as
if the transport protocol did support synchronous responses." which
contradicts the statement on line 1625: "The SyncReplyMode parameter
from the CPA is used only if the data communications protocol is
synchronous (e.g. HTTP)." We can defer the bundling issue for
asynchronous communications protocols until the 2.0 versions of the MSG
and CPP/A specs.
</ac>
...