Arvola
You
have spotted one of the inconsistencies that, in my opinion, needs to be fixed.
It arose because there were two different views on the relationship between the
CPA spec and the ebMS spec. This really boiled down to whether the CPA was
always required or optional. I will say now that I was always firmly in the
latter camp and think that the CPA should be optional. The main reason for this
was that if the CPA is required, then you cannot just send a message to someone,
you have to negotiate the CPA first and how you do this has not been
specified.
You
are also right that there are issues around using the reliable messaging spec
over multiple hops which need to be resolved.
However the spec does need to be clarified in my
opinion to make it clear the the CPA is optional. Removal of this inconistency
(and a few others) is one of the things that I will suggest at the ebMS meeting
tomorrow and Wednesday.
Thanks
for your comments.
David
PS
Most specifications seem to go through some type of revision after they are
published ... ;)
Section 10.2 in the ebMS spec describes the
reliable messaging parameters:
deliverySemantics, mshTimeAccuracy, TimeToLive, reliableMessagingMethod, ackRequested, retries, retryInterval,
persistDuration. Only deliverySemantics,
TimeToLive, reliableMessagingMethod, ackRequested can be found in Appendix A (ebXML SOAP Extension Elements
Schema); retries, retryInterval, and
persistDuration can only be found in Appendix D
of the ebCPP spec.
I find the statement on line 1695 "This parameter information can be specified in the CPA or
in the MessageHeader (section 8.4.2)."
imprecise in the following sense:
- mshTimeAccuracy is neither in the MessageHeader
nor in the CPA.
- TimeToLive is not mentioned anywhere in the CPA.
It is not clear how the sending MSH should pick a value for this
parameter.
- The sub-sections describing retries,
retryInterval, and persistDuration do not clearly indicate that these
parameters are to be obtained from the CPA. Furthermore, their spellings do
not match those in the CPA (case difference). It will be helpful to specify
how elements in the MessageHeader can be used to look up these values from
the CPA. The CPAId alone is not sufficient. The Service and Action elements
will also have to be used to locate the relevant DocExchange, ebXMLBinding,
and ReliableMessaging elements from the CPA.
It is not clear if the current Reliable Messaging
specification works over multiple hops. Line 1774 prescribes that a
TraceHeader be created in accordance with Section 8.5.2. The latter section
however does not say anything about how to determine the next intermediary, in
those cases where one or more intermediaries are to be involved. The
descriptions on lines 1825 and 1829 on how to populate the From and To element
in the Acknowledgement Message also do not clearly explain the circumstances
under which sub-elements under the last TraceHeader in the incoming message
are to be used.
I also find the following issues with
Section 10.3.2 on Receiving Message Behavior:
- Line 1783 uses the URI http://www.ebxml.org/namespaces/messageService/MessageAcknowledgement.
This is not consistent with the URI specified on line 1823:
uri:www.ebxml.org/messageService.
- Steps 2.d)i) on line 1800 and 2.d)ii) on line
1802 are confusing. The phrase "and resend it" on line 1800 should be struck
out. Otherwise, the message would be resent twice.
- Step 2.c) omits the crucial action of passing on
the message which has been found not to be a duplicate to the
application.
- Step 2.d)iii) is incomplete. The action to be
taken when syncReply is set to True and the CPA indicates no application
response is included is left unspecified. I believe in this case an
Acknowledgement Message should be generated and returned
synchronously.
Under Section 10.3.5 Duplicate Message Handling,
I find the description of an "identical message" puzzling. Why is it
possible for a duplicate "identical" message to have an additional
TraceHeader? Is the sending MSH required to append another TraceHeader when it
resends a message because an Acknowledgement Message has not been received in
time? Or is it required to update the Timestamp in the TraceHeader
to reflect the time of retransmission?
Thanks,
-Arvola
TIBCO Software (on loan to
RosettaNet)
+1-650-846-5046 (US-Pacific)
|