[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2 Reliable Messaging w/o CPA or VIA...
The persistDuration "parameter" is a CPP/A artifact. It is not carried within the message envelope. Nor should it, IMO. The purpose of this parameter, as I understand it, is to allow each party to declare its persistence capabilities such that the negotiation (or calculation of) the retries/retryInterval parameters that are to be used for resending unacknowledged messages are acceptable to the receiving party. That is to say that if the intended recipient can only keep messages (or their artifacts as the case may be) for 5 minutes, then a computed value for (retries * retryInterval) that exceeds 5 minutes MAY present problems for the intended recipient since it cannot be guaranteed that it will have any record of the message being resent or its response message(s). In practice, when negotiating a CPA, the parties should (but who can force them?) ensure that the computed value of the sender's retries * retryInterval not exceed the intended recipient's persistDuration. Nothing in the specification says that an MSH should discard a message (or its artifacts) from persistent store upon the expiration of persistDuration. In fact, that would probably be a bad idea. I prefer to think of persistDuration as being the MINIMUM amount of time that a party can guarantee that it will preserve a message (or its artifacts) in persistent storage. This would help eliminate any potential problem with edge cases that compute retries and retryInterval to be some function of persistDuration (a practice I would recommend avoiding!) In practice, persistDuration should exceed retries * retryInterval by a wide margin. As for persistDuration being applied to messages being sent, I would like to think that it has nothing to do with the sending MSH's behavior at all. The specification doesn't (correctly, IMO) say anything about persistDuration applying to messages being sent and their persistence. Maybe it could be made clearer to the reader that this parameter applies EXCLUSIVELY to messages received. Note that this parameter applies ONLY to the persistence related to reliable messaging. It should not be interpreted to mean anything "application" specific (such as persistence related to auditing, non-repudiation or some other function). Cheers, Chris Martin W Sachs wrote: > > David, > > The short answer is that persistDuration should be in either the header or > the CPA but probably not in both places. In the header means that the > message sender always controls persistDuration. In the CPA, > persistDuration should mean that both parties have agreed on a single > value. However persistDuration is in the delivery channel which denotes > receive properties, so there is still the possibility of a mismatch. The > CPPA team may wish to prescribe agreement between the two Parties, which > may mean that has to be the same in all delivery channels. > > The real question, however, is what is the value of persistDuration and why > is it needed along side the Retries/RetryInterval pair? > > 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 > ************************************************************************************* > > "Burdett, David" <david.burdett@commerceone.com> on 07/30/2001 06:58:28 PM > > To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-msg@lists.oasis-open.org > cc: "'David Fischer'" <david@drummondgroup.com> > Subject: RE: T2 Reliable Messaging w/o CPA or VIA... > > If persistDuration is in the header (instead of the CPA), what does it > mean? > Does it mean that the recipient should persist the message for the duration > specified? Or should it be ignored and the recipient rely by whatever they > put in their CPP. It is more flexible if it the length of time the message > is persisted as the recipient could always flag an error if it considers > the > value too long. > > David > > -----Original Message----- > From: Martin W Sachs [mailto:mwsachs@us.ibm.com] > Sent: Monday, July 30, 2001 3:48 PM > To: ebxml-msg@lists.oasis-open.org > Cc: 'David Fischer'; Burdett, David > Subject: RE: T2 Reliable Messaging w/o CPA or VIA... > > Regarding persistDuration, the message service spec (line 1758-59) states > "If a message cannot be sent successfully before persistDuration has > passed, then the Sending MSH should report a delivery failure." Lines > 1756-1757 also place some responsibility on the sending MSH. > > The above statements mean that the persistDuration also applies to the > sending MSH and must be in the header. Or it could mean that it has to be > in the CPA (or whatever you want to use instead of a CPA), where it in fact > is, so that both parties agree on the value. > > 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 > **************************************************************************** > > ********* > > ---------------------- Forwarded by Martin W Sachs/Watson/IBM on 07/30/2001 > 06:38 PM --------------------------- > > "Burdett, David" <david.burdett@commerceone.com> on 07/30/2001 03:29:50 PM > > To: "'David Fischer'" <david@drummondgroup.com> > cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> > Subject: RE: T2 Reliable Messaging w/o CPA or VIA... > > David > > Let's take of these in turn ... > > mshTimeAccuracy > >>>This is the accuracy to which a recipient of a message claims to keep > their internal system clocks. This should probably be part of a CPP and > not vary from message to message therefore it does not need to be in the > MessageHeader > > reliableMessagingMethod > >>>This needs to be in the Via since it can vary on each hop of a > multi-hop message. I suppose though that, if you are not doing multi-hop > then it forces use of the Via element. I think we could either: > 1. Put reliableMessagingMethod in the main MessageHeader with the copy in > the Via element over-riding it, or > 2. Change the definition of the Via element to suggest that it to be used > when there is no intermediary > Thoughts? > > ackRequested > >>>This is in Via for the same reason as for reliableMessagingMethod - it > can vary from hop-to-hop > > retries& retryInterval > >>>These are both parameters that apply to the sender of a message and > over which the receiver of message can have no effective control. There is > therefore no need for them to be in the header. They should however be in > the CPP for the sender > > persistDuration > >>>PersistDuration only applies to the recipient of a message as it > specifies the minimum time the recipient will keep a message. The sender > cannot (should not?) control this, therefore there is no need for it to go > in the header. > > I'd appreciate your thoughts. > > David > -----Original Message----- > From: David Fischer [mailto:david@drummondgroup.com] > Sent: Monday, July 23, 2001 7:07 PM > To: Burdett, David > Cc: ebXML Msg > Subject: T2 Reliable Messaging w/o CPA or VIA... > > Section 10.2 (line 1695) says: > > This parameter information can be specified in the CPA or in the > MessageHeader > > But I can't find anywhere in the MessageHeader to set the following > parameters: > > mshTimeAccuracy > reliableMessagingMethod > ackRequested > retries > retryInterval > persistDuration > > This seems like a formidable problem when doing reliable messaging > (ackRequested) without an intermediary (no Via). If we put this > information back in the MessageHeader, why is it also in the Via? This > was in the MessageHeader in v0.91 but it was taken out... probably > shouldn't have been. > > Regards, > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC