[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: T2 Reliable Messaging w/o CPA or VIA...
Marty, Please see below. Cheers, Chris Martin W Sachs wrote: <snip/> > > The persistDuration "parameter" is a CPP/A artifact. It is not carried > within the message envelope. Nor should it, IMO. > > MWS: This is a classic example of the vagueness in the message service > spec. When I look at persistDuration, I see a definition that I have > temerity to assume is part of the XML structucture. If I back up to > section 10.2, I see that the parameter information can be in the CPA or the > message header but nothing about which goes where. To be able to parse > 10.2 (and other places also?), I need to see, for each parameter, where it > is contained. Of course the issue is muddied by the case where a parameter > is in the CPA but there is no CPA. This needs a lot of clarifying. Agreed. > > 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). > > MWS: This clearly needs a lot more explanation in the CPP-CPA > specification and > is another example of a needed consistency check that the parser can't do. Agreed. > > 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. > > MWS: The consistency check mentioned above can enforce it if it is stated > as > normative and built into the CPA tools. But, the CPP/A specification isn't specifying a tool(s), only an XML representation of the information that is a CPP/A document. Maybe what this points to is the need for a CPP/A Composition Tool specification that augments the CPP/A spec itself? Another possibility would be to express the document constraints that are non-expressable using XML Schema using some other schema language, such as RELAX-NG or Schematron. > > Nothing in the specification > says that an MSH should discard a message (or its artifacts) from > persistent > store upon the expiration of persistDuration. > > MWS: Yes there is. See the second and third paragraphs of message service > 10.2.8. > Granted it does say SHOULD... It SHOULDn't ;-) Thanks for pointing that out. > > 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. > > MWS: I wonder if persistDuration should be eliminated and > RetriesXRetryInterval > defined as the time a message must be persisted. There is still, however, > the case > where the implementation's timeout exceed RetryInterval. On the other > hand, since > the implementation knows its timeout, the rule can simply be that the > message must > be persisted long enough to perform the agreed number of retries and wait > for the > response to the final retry. Again, persistDuration is a receiver parameter, not a sender parameter. Your characterization above reflects the sender's perspective. I think that persistDuration has value above and beyond retries * retryInterval. For one, when represented in a CPP, it delcares the party's capacity to persistently store message artifacts such that reliable messaging can be effected. When negotiating a CPA, this is quite useful. Its usefulness in the CPA might be considered suspect as I would imagine that persistDuration wouldn't usually vary by party agreement. However, it could come in handy to enable an implementation to vary persistDuration by agreement... > > 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. > > MWS: I agree. > > 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). > > MWS: I agree. > > 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 > > ------------------------------------------------------------------ > 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