ebxml-tp message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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.


 -----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


 The definition of persistDuration in your email looks OK.

 My point about decoupling persistence from reliable messaging was
 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.


 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


 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
 PersistDuration has passed, then the MSH that receives it MUST process it
 a duplicate message as described in sections and

 If a duplicate message is received after the PersistDuration has passed,
 then although it may be treated as a duplicate, the sender must realize
 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?


 -----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


 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

 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.




 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
 Subject:  Re: Yet more issues to resolve


 Thanks for sending these out. Some comments below.


 ian.c.jones@bt.com wrote:
 > TR&P people,
 >         Sorry this is late - the real world gets in the way
 > The following issues may now have been overtaken by events but
 we need to
 > least acknowledge this so that I can get the database of issue and
 > 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
 > and the corresponding references to SequenceNumber in later  examples,
 > DTD and the schema.
 > If this section remains, must define the exact content of the
 > 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
 > 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.
 > 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
 > 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
 > the transport destination and SenderURI may not exist -- not all senders
 > 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
 > the sending application (party), does that report also result
 in deletion
 > 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
 > as described on line 828, may be necessary to store entire original
 > or its checksum as well.
 > Proposal - This is out of scope of the TR&P if required it should be in
 > 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC