Revised Definitions for PersistDuration

["Burdett, David" <david.burdett@commerceone.com>]

Marty

I agree that the wording I used in my reply was somewhat "loose" in its
meaning. However, as became clear in this mornings TRP conference call,
there is a need to separate "persistDuration" for reliable messaging
purposes from the "persistDuration" that is used for legal or other business
process related reasons. So how about the following as a replacement
definition/explanation for persistDuration ...

>>>
Replacement text for section 10.6.5.2 Persist Duration

PersistDuration is the minimum length of time, expressed as a [XMLSchema]
timeDuration, that data from a Message that is sent reliably, is kept in
Persistent Storage by a MSH that receives that message.

In order to support the filtering of duplicate messages, a Receiving MSH
MUST, as a minimum, save the MessageId in persistent storage. It is also
RECOMMENDED that the following are kept in Persistent Storage:
* the complete message, at least until, the information in the message has
been passed to the application or other process that needs to process it
* the time the message was receieved, so that the information can be used to
generate the response to a Message Status Request (see section xxx)

PersistDuration is specified in the CPA.

A MSH SHOULD NOT resend a message with the same MessageId to a receiving MSH
if the elapsed time indicated by PersistDuration has passed since the
message was first sent as the receiving MSH will probably not treat it as a
duplicate.

If a message cannot be sent successfully before PersistDuration has passed,
then the MSH should report a delivery failure (see section xx).

Note that implementations may determine that a message is persisted for
longer than the time specified in PersistDuration, for example in order to
meet legal requirements or the needs of a business process. This information
is recorded separately within the CPA.
<<<

Note that the above does not talk about how long a sending MSH should
persist a message. To explain this I suggest that the following text is
added to the end of section 10.2.1.1 Sending Message Behavior ...

>>>A sending MSH MUST keep any messages that have been sent reliably in
persistent storage until an acknowledgement message from the To Party's
receiving MSH has been received.<<<

David

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Thursday, January 04, 2001 7:06 AM
To: Burdett, David
Cc: 'Stefano POGLIANI'; ebxml-transport@lists.ebxml.org;
ebxml-tp@lists.ebxml.org
Subject: RE: Yet more issues to resolve



David,

I almost agree with your suggestion in your second paragraph.  However "
until the sender knows that the sent message has arrived" isn't precise
enough.  The term "sender" doesn't seem to be a defined term.  Two
different readers may interpret the word differently. At a minimum, it
should say "sending business process". However, persistence must be at
least until the message has arrived in the domain of the receiving business
process and probably until it has has been processed to the point where the
business process can persist the result and send the business-level
response.  Note also that the sender of a business-level response has no
business-process way of knowing that the response has been processed to
completion since there are only low-level acknowledgements to a response.

The message service spec should not get into the above details since they
are really out of TRP's scope.  That's why I proposed saying nothing about
discarding persisted messages and including a non-normative statement that
it is up to the busines process to determine when the persisted message can
be discarded.

Addition of a persistDuration parameter to the CPA should be very helpful
to the collaborating businesses, though it might be  good to augment it
with a persistSemantics indicator. The tag might look like this:

   <persistUntil persistDuration="..." persistSemantics="..." />

   persistSemantics:

     timed (this would go with persistDuration)
     businessResponseSent (not applicable to business responses)
     businessTransactionCompleted
     businessSignalReceived (low-level acknowledgement defined by BP model;
     could be used with business responses)
     messageService (persistence ends when the message service is through
     with the message)

   Since some of these are only applicable to requests and others are
   mainly used with business responses, the CPP-CPA spec probably has to
   allow the persistence parameters to be defined per service, per business
   transaction, and per message definition.

   The CPP-CPA specification should include discussion of the time-to-live
   and duplicate-detection issues in the discussion of "timed".

I'm putting this in my collection of things to be added to the CPP-CPA spec
in a later iteration.

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 01/03/2001 08:51:46 PM

To:   "'Stefano POGLIANI'" <stefano.pogliani@sun.com>, Martin W
      Sachs/Watson/IBM@IBMUS
cc:   ebxml-transport@lists.ebxml.org, ebxml-tp@lists.ebxml.org
Subject:  RE: Yet more issues to resolve



Stefano

Version 0.91 of the spec has the concept of a "persistDuration" parameter
that would be in the CPA/CPP that identifies the number of days a message
that is sent persistently should be kept by the receiving MSH.

The spec is not specific about how long messages that are sent are
persisted. However this should be as I think you are saying, until the
sender knows that the sent message has arrived since an acknowledgement
message has been returned.

Does this make sense?

David

-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Wednesday, January 03, 2001 3:29 PM
To: Martin W Sachs; Burdett, David
Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
Subject: RE: Yet more issues to resolve


Marty, David,

a little clarification w.r.t. "I also don't like the idea of placing a
restriction on the MSH to persist a message until the transaction is
complete, ..."

I think that an option would be to allow the MSH to be "controlled" by
outside w.r.t. this part and by defining a "default behaviour". "Not saying
anything" (as mentioned by Marty) would mean, IMHO, that the "default
behaviour" is to remove the message as soon as it reliably reaches the
target MSH.
Giving the option to "control from outside" would allow the layer between
the MSH and the real application to take care (if it will be capable) of a
more sophisticated behaviour.

/Stefano


» -----Original Message-----
» From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» Sent: Saturday, December 30, 2000 2:23 AM
» To: Burdett, David
» Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
» Subject: RE: Yet more issues to resolve
»
»
»
» David,
»
» The definition of persistDuration in your email looks OK.
»
» My point about decoupling persistence from reliable messaging was
» a CPA/CPP
» point, not a MSH point.  I am simply suggesting that two parties
» might have
» reasons to come to agreement on persistence that have nothing to do with
» the MSH in addition to its use with RM.
»
» Regarding "I also don't like the idea of placing a restriction on the MSH
» to persist a message until the transaction is complete, ..."  I don't
like
» placing that restriction either.  I was asking for the opposite - that
the
» MSH specification should not say anything which either prescribes or
» suggests that a message can be deleted from the persistent store
» as soon as
» it reliably reaches the destination MSH.  Earlier versions of the RM
» specification included such words.
»
» 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 12/27/2000 11:20:24
AM
»
» To:   Martin W Sachs/Watson/IBM@IBMUS
» cc:   ebxml-transport@lists.ebxml.org, ebxml-tp@lists.ebxml.org
» Subject:  RE: Yet more issues to resolve
»
»
»
» Marty
»
» In version 0.9a of the spec, a parameter called "pesistDuration"
» is defined
» that is described as follows:
»
» "PersistDuration is the minimum length of time in days that a Message
that
» is sent reliably is kept in Persistent Storage by a MSH. The
» value used for
» PersistDuration is an implementation decision although it MUST be greater
» than the value of the TimeToLive parameter for any message that is sent.
»
» If a duplicate message (i.e. with the same MessageId) is received before
» the
» PersistDuration has passed, then the MSH that receives it MUST process it
» as
» a duplicate message as described in sections 10.2.1.1 and 10.2.1.2.
»
» If a duplicate message is received after the PersistDuration has passed,
» then although it may be treated as a duplicate, the sender must realize
» that
» it will probably be treated by the MSH as if the message were a
» new message
» that had not been received before."
»
» So as it stands, the persistDuration only applies to Relilable Messaging
» behavior which I think is right. I know that there are other, e.g. legal,
» reasons why a messages might be persisted beyond this time. However from
a
» MSH perspective, I think we can only specify the behavior of the MSH and
» nothing else.
»
» I also don't like the idea of placing a restriction on the MSH to
» persist a
» message until the transaction is complete, since the MSH will
» probably need
» to be told by the application that the transaction is complete and it's
» possible that some backend systems will not be able to easily do this.
»
» Do you think the existing definition is OK?
»
» David
»
» -----Original Message-----
» From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» Sent: Tuesday, December 19, 2000 9:56 AM
» To: Christopher Ferris
» Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
» Subject: Re: Yet more issues to resolve
»
»
»
» Chris,
»
» Regarding issue 19:  I agree that there should be nothing in the TRP spec
» about how long a message must be persisted since higher layers are
» involved.  Perhaps the messaging spec should say that persistence must be
» at least until the reliable messaging procedure has been
» completed for that
» message transmission.  I suggest a non-normative note explaining the
» issues.
»
» In my opinion, at the higher levels, persistence should be at least until
» the business transaction is concluded.  Persistence beyond that
» is probably
» not a matter that has to be agreed to.  It is probably an internal matter
» for each party.
»
» If the persistence element will be in your upcoming CPP/CPA DTD, please
» supply some explanatory text with it.  I suggest not coupling the
» persistence element in the CPA to reliable messaging.  While it is
» essential to reliable messaging, it is also something that might be
needed
» without ebXML Reliable Messaging.  For example, if the parties use a
» transport that is reliable in and of itself, they would probably not want
» to invoke ebXML Reliable Messaging on top of it but they might want to
» specify something about persistence.
»
» 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>@east.sun.com on 12/19/2000
» 12:23:17 PM
»
» Sent by:  Chris.Ferris@east.sun.com
»
»
» To:   ebxml-transport@lists.ebxml.org
» cc:
» Subject:  Re: Yet more issues to resolve
»
»
»
» Ian,
»
» Thanks for sending these out. Some comments below.
»
» Cheers,
»
» Chris
» ian.c.jones@bt.com wrote:
» >
» > TR&P people,
» >
» >         Sorry this is late - the real world gets in the way
» occasionally.
» >
» > The following issues may now have been overtaken by events but
» we need to
» at
» > least acknowledge this so that I can get the database of issue and
» changes
» > update by the New Year.
» >
» > ####
» > Issue 15
» > Title - RM Info
» > Detail - 7.9.4  - RM Info: why isn't this in routing header?
» >
» > Proposal -  Move to Routing Header
» > Resolution -
» > Response By - December 21
»
» I have to disagree with this. The ReliableMessagingInfo
» element applies to the message, not to a particular hop
» along the way. Note that David has crafted a revised section
» on RM in the draft we've been collaborating on which we
» hope to get to the list today (although, we recognise that
» it still needs work).
»
» >
» > ####
» > Issue 16
» > Title - TPAInfo
» > Detail - Add new section containing all TPA(CPA) information
» >
» > Proposal - see above
» > Resolution -
» > Response By -
»
» This one I'm not sure I understand. I thought that we agreed
» in Tokyo to flatten the TPAInfo section by moving all of
» the child elements to be direct decendants of Header.
»
» What information was missing from TPAInfo anyway? I'm not
» clear on what the proposal really suggests.
»
» >
» > ####
» > Issue 17
» > Title - Sequence number
» > Detail - 7.10 SequenceNumber as defined adds little or no value over
the
» > MessageID element required in MessageData.  Recommend removing this
» section
» > and the corresponding references to SequenceNumber in later  examples,
» the
» > DTD and the schema.
» > If this section remains, must define the exact content of the
» SequenceNumber
» > element when the numeric value is greater than 999.  Is the next value
» > "1000" or "1,000"?  Is the text for the maximum value  "999999999" or
» > "999,999,999" or are both allowed (and equivalent)?  Side note: Numeric
» > formats vary by locale and a comma is not always the thousands
» > If this section remains, "long time" should be defined.  At least,
refer
» to
» > a TPA which makes this concrete for a specific trading relationship or
» > mention later text on this subject (if any).
» >
» > Proposal -
» > Resolution -
» > Response By -
»
» Since we're going to spec the schema using XMLSchema, we can
» be more precise in the typing of elements and attributes.
» I agree that the spec needs to be tightened up for this
» particular element.
»
» I'll have to review David's revision of RM to see what that
» has to offer.
»
» >
» > ####
» > Issue 18
» > Title - URI definitions in RM
» > Detail - 7.10 - SenderURI, ReceiverURI and ErrorURI are not
» defined.  Are
» > they identifiers or service locations?  From later discussion in this
» > document, it appears that ErrorURI is a service location at which error
» > responses may be received.  The other two aren't discussed much.
» However,
» > I'd recommend they be defined similarly to the PartyId elements in the
» > Header (i.e. the parties participating in the current leg of the
» journey).
» > That requires adding a context attribute to SenderURI and
» ReceiverURI and
» > (potentially) renaming the elements.  Alternatively, SenderURI and
» > ReceiverURI may somehow identify the service location used in this
» > particular leg (this is probably redundant information for ReceiverURI
» with
» > the transport destination and SenderURI may not exist -- not all
senders
» are
» > reachable in return).
» >
» > Proposal -
» > Resolution -
» > Response By -
»
» I assume that the subject refers to URI elements in RoutingHeader
» not RM. Agree that these need to be more precisely defined.
» As to defining them similarly to the PartyId element...
» I had actually proposed to David in our discussions that
» instead of defining different elements, that we re-use
» To and From but with precise wording that the PartyId
» MUST be an URL form of URI (e.g. something addressable).
»
» This also brings to mind a security issue (possibly) as
» if an intermediate signs a header (with the added RoutingHeader
» element) then it MAY be important to be able to identify
» the intermediary with the specific RoutingHeader. I hadn't
» thought of this before, but it MAY be important to consider.
»
» >
» > ####
» > Issue 19
» > Title - Persistent storage
» > Detail - 7.11 - "Persistent storage" actually lasts how long?  Is the
» > original message deleted by the Messaging Service immediately after
» > receiving an acknowledgement?  In the case of an error, which
» is reported
» to
» > the sending application (party), does that report also result
» in deletion
» of
» > the original message from the persistent storage?
» > What information does the Receiver store persistently in this step?
» > Recommend storing the MessageID of the original message and the entire
» > response document.  To check for "exactly the same as the original
» message"
» > as described on line 828, may be necessary to store entire original
» message
» > or its checksum as well.
» >
» > Proposal - This is out of scope of the TR&P if required it should be in
» the
» > CPP/CPA
» > Resolution -
» > Response By -
»
» David has added a section on persistence in his RM draft
» proposal. It doesn't get into "how long" as this is correctly
» identified as being something that the parties MUST agree
» upon and have reflected in the CPA. A new element is being added
» to the CPA for this purpose (e.g. to capture the persistenceDuration
» with which a message is to be archived).
»
» >
» > Ian Jones
» > E-Commerce Engineer
» >
» >
»
»
»
»
»
»
»
»