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