RE: End to End RM

[David Fischer <david@drummondgroup.com>]

Title:

Sorry for the HTML but we lose too much with plain text (colors, bolding, fonts etc) I feel like I'm in the stone age.

 

David,

 

Question 1: 

If I understand you right, the end-to-end RM is to rely on IM Delivery Failure messages?  No, that won't work.  What if the Failure gets lost.  What if one IM can't do RM?  We have to have a positive Ack from end-to-end. 

 

While the IM(s) might be willing to do RM this way, the end-to-end MUST be able to do RM as if it does not know (which it probably doesn't) what the IM(s) are doing.  The end-to-end probably doesn't care if the IM(s) are doing RM at all (even though each IM might care very much). 

 

On the issue of Sender time outs and retries, their are two kinds:  1) a timeout to the first IM and 2) a timeout getting to the end.  The first is easy and obvious so we don't need to discuss it.  The second is a timeframe that is usually contractually guaranteed -- the VAN guarantees to get the message to the recipient within 3 hours or something like that (SLA).  This too is important to the sender and probably much more important than the first timeout.  There MUST be some notification/acknowledgement to the sender that the receiver MSH has received the message.  This cannot be sent by the IM since there may be multiple IMs.  It must be sent by the To Party.

 

While the Sender/Receiver may not have any idea what path or IM transport the message is taking (and they really don't need to) they must have an idea about delivery times to the end.  We MUST generate some kind of an end-to-end Ack allowing the ends to do RM.  All IM RM is meaningless to the Sender without this.  I thought this was not a problem because DeliveryReceipt was this Ack but I don't see DeliveryReceipt in section 10?  That's why I'm asking this question. 

 

PROPOSAL:

1) We need to update section 10 with end-to-end RM (deliveryReceipt or something new that is similar to Acknowledgement).

2) We need to put in the spec somewhere that ALL MessageHeaders (including Via) MUST be passed to the next hop, including the end.

 

Question 2: 

I agree that it doesn't matter if ackRequested gets changed because an Ack gets sent based upon DeliverySemantics (This was my second solution to Question 2).  Why then do we have ackRequested?  The only way it would change is if there was some kind of local CPA overriding ackRequested.  If RM is requested and an IM can do RM then it MUST, right?  Then why have this parameter?  (I see from your comments that you are considering this.)

 

Regards,

 

David.

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, August 09, 2001 11:32 AM
To: 'David Fischer'
Cc: Christopher Ferris (E-mail)
Subject: RE: End to End RM

David

 

See comments in-line.

 

David

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Wednesday, August 08, 2001 10:52 PM
To: Burdett, David
Subject: FW: End to End RM

I think I know the answers, I just want to make sure you agree.

Question 1:  To do RM end-to-end you request a DeliveryReceipt, or if RM is set you MUST generate a DeliveryReceipt from To Party to From Party.
[David B] You don't have to generate a Delivery Receipt since if an intermediary fails to deliver a message to the next MSH (or to the application if it is the To Party MSH), then the MSH must return a "Delivery Failure" error message back to the "From Party". This error message is a "negative ack". On the other hand, the Delivery Receipt is a "positive ack" in that it is proof that the message was delivered. Both are valid use cases and I don't think we should, in the spec, force use of Delivery Receipts.

 Need to change:

10.3.3 Generating an Acknowledgement Message
An Acknowledgement Message MUST be generated whenever a message is received with:

·       reliableMessagingMethod set to ebXML (the default) and
·       deliverySemantics set to OnceAndOnlyOnce

In addition a Delivery Receipt message containing the DeliveryReceipt element MUST be generated and sent to the From Party MSH by the To Party MSH but not by an Intermediate MSH.

As a minimum, these messages MUST contain a MessageData element with a RefToMessageId that contains the same value as the MessageId element in the message being acknowledged.

Need to make some other similar changes to section 10 e.g. second paragraph should be:

 

Reliability is achieved by a Receiving MSH responding to a message with a Delivery Receipt, or in the case of an Intermediate hop, with an Acknowledgment Message.

There is a problem with this since with two types of Acks, the From Party will always receive Both Acks.  In a single-hop situation BOTH will be generated by the To Party (not good)
[David B] Maybe, but if both acks are in the same message, then it is no big deal.

 while in a multi-hop situation the Ack would come from the IM and the DR would come from the To Party (very good).  I don't know how the To Party MSH would know if the message arrived via Single Hop or Multi-Hop since the Via with actor=next might not be passed to the end.
[David B] He shouldn't need to know it just follows the instructions in the message. 

 

    SOAP 1.1 Section 4.2.2

    /snip... That is, a receiptient receiving a header element MUST NOT

    forward that header element to the next application in the SOAP

    message path.  The receipient MAY insert a similar header element

    but in that case, the contract is between that application and the

    receipient of that header element.

 

The problem above can be solved by specifying somewhere in the spec that ALL ebXML headers MUST be forwarded to the next application.  I don't see that anywhere?  (Did I just miss it?) 
[David B] I think we discussed this. Chris should be able to better advise on this - I'll copy him on this email

 If we do this then the From Party can refrain from sending Acks if there is no Via (or TraceHeaderList etc.)

 

 

Question 2: There is no way to stop an IM from changing the value of AckRequested (for instance in the case of an IM hop using MQseries) and when the IM does this, it will be changed for all subsequent hops. 
[David B] Correct, but I don't think this is an issue as if you are using MQ Series you don't need the ack. If Delivery Semantics is OnceAndOnlyOnce, then any intermediary MSH which receives a message knows that they should forward the message using a reliable messaging protocol of some kind.

This is due to the actor=next on Via.  There are two possible fixes.  1) forbid any change or 2) move AckRequested out of Via.  In the first choice, if it doesn't change then why is it in Via? 
[David B] It can change as previously described.

 So the second answer is really the only answer.  AckRequested needs to go in QualityOfServiceInfo.  The question must then be asked, will AckRequested ever be different than DeliveryReceiptRequested?  Although some obscure case might be made, I doubt it.  There will however be cases where a local CPA might override this value.  Is there then any real reason to have two request parameters?  Let's just get rid of AckRequested and use DeliveryReceiptRequested for both DeliveryReceipts and Acknowledgements (change to ReceiptRequested?) and make these two types of "Acknowledgement Messages" fairly synonomous in the spec.
[David B] You can't rely on just Delivery Receipts as if there is an intermediary who stores a message before forwarding it then the From Party might time out waiting for the Delivery Receipt and assume the delivery failed when actually there are no problems at all. Because you can have different transport protocols with different timing characteristics you need to make each hop reliable so that the retry behavior can stop within a reasonable time. For example if you are using HTTP you could retryt for say 5 minutes before giving up, but if the next hop is SMTP going you might want to wait three hours. As the original sender may have no idea what transport will be used for all the hops they cannot set a reasonable time out. If they assume that some link is slow (e.g. SMTP) but the first link is HTTP then they would not trap an HTTP failure for potentially hours.

 

Question 2: Another answer might be that Acks are part of RM and they fall under section 10.3.3 which says an Ack MUST be generated if DeliverySemantics=OnceAndOnlyOnce & ReliableMessagingMethod=ebXML.  Therefore do we need AckRequested at all since we can deduce the need for an Ack based on this criteria?  Again, let's get rid of AckRequested.
[David B] This is an idea that could be worth considering. 

 

 

What do you think?

 

Regards,

 

David.

 

 

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Wednesday, August 08, 2001 9:39 PM
To: David Burdett
Cc: ebXML Msg
Subject: End to End RM


Was (RE: T2 SyncReply and ReliableMessagingMethod in QualityOfServiceInfo)


Thanks, David, that was long!

The answer to my questions is probably somewhere in there but I may have gotten
lost.

Question 1:  How do we do end-to-end RM irrespective of IM RM, i.e. how do we
request an end-to-end Ack?  Is it the DeliveryReceipt or is there something
else?

Question 2: In a multi-hop situation (more than one IM) how do we avoid having
the IM change AckRequested and thus have the wrong value for all subsequent
hops?

David Fischer
Drummond Group.


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org