----- 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>
...