Re: T2 Reliable Messaging w/o CPA or VIA...

[christopher ferris <chris.ferris@east.sun.com>]

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