See my comments below.
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
*************************************************************************************
christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 07/31/2001
11:56:39 AM
Sent by: Chris.Ferris@Sun.COM
To: ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org
cc:
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.
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.
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.
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.
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...
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.
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
>
>