OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RM through intermediaries


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC