I would like to expand on Dale Moberg's prior suggestion that an IM should
send an ACK only after it receives an ACK from upstream.
Configuration: A----------B-----------C------------D
All hops are ebXML.
All intermediaries are forwarders and do not have higher level application
functions.
Rules for forwarding intermediaries:
The message from A to D goes through B to C to D.
B and C do not acknowledge when they forward the message.
D persists the message.
D sends an ACK to C. Upon receiving D's ACK, C sends an ACK to B. Upon
receiving C's ACK, B sends an ACK to A.
Each ACK carries the message ID of the original message and also carries
D's Party ID.
Result: A gets only one ACK. Because of chain of ACKs described above, A
now knows that the message was persisted at D. More precisely:
The ACK from D to C acknowledges that D persisted the message
The ACK from C to B acknowledges that C received D's ACK.
The ACK from B to A acknowledges that B received C's ACK.
Thus the knowledge that D persisted the message was relayed to A.
Regarding retries and delivery failure notification:
Retries are handled just like point to point (single hop). B and C do
not test for duplicates since they are only forwarding nodes. The test
for duplicates is always (only) at D.
If a message does not get to D, A receives no ACK.
If a newtwork failure occurs on the B-C or C-D link, A receives no
ACK.
If a network failure occurs between A and B, A detects it directly.
Because of the above (2-4) delivery failure notification can always be
generated by the A MSH. There is no need to send A a delivery failure
notification from B, C, or D. Hence DFN is always reliable since it
is wholly inside A.
If A nd B do any processing of the message payload, they are NOT
intermediaries. Each is an endpoint with respect to the node to its left
(above). This is just like a supply chain configuration. A and B have a
business relationship, B and C have a business relationship, and C and D
have a business relationship. These relationships are expressed as three
separate CPAs (real or virtual). Each of the hops in the above picture is
point to point between adjacent nodes, from an ebXML messaging viewpoint. I
imagine that a marketplace would be similar.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************