The point is that the MSG spec can't make assumptions on the manner in
which the message gets from the MSH to the application. There is a lot of
designer's choice in that.
One way of interpreting David's "the MSH would dispatch or pass the
file(s)/payload(s) to the application." is that there is a transactional
protocol between the application and the MSH that delivers that message to
the application. Even then, there is a lot of designer's choice. That
transactional protocol would probably be between the MSH and some
middleware element, not the "application code" as described in the BPSS
document. The only sensible event that can be used to determine if
timeToLive is exceeded is the abstract notion of the MSH notifying the
upper level that a message is ready to be processed.
However, after reading Dan Weinreb's posting, I agree with him that
timeToLive is really a parameter that determines whether a message received
from the network is too stale to deliver to the application. Therefore, as
Dan said, the event of interest is receipt of the message by the MSH.
You can't send an acknowledgment and then discard the message. That's
out-and-out lying to the From party. Using Dan's approach, everything is
fine" Receive message; check whether time to live has been exceeded;
delete message if TTL is exceeded; persist message and send acknowledgment.
I agree that system failure and recovery is irrelevant. The TTL that the
MSH deals with should be strictly related to receiving the message from the
network. If the application needs to decide whether a message is too stale
to process, that's an application design matter, not an MSH matter.
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
*************************************************************************************
David Fischer <david@drummondgroup.com> on 12/12/2001 09:36:20 AM
To: Martin W Sachs/Watson/IBM@IBMUS, david.burdett@commerceone.com
cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
The spec states a message must be persisted prior to sending an
Acknowledgment
(7.5.2 - 2b). I think Marty is suggesting the application will somehow be
checking/polling the persistent store for messages? I guess I was
expecting
some kind of an interface in which the MSH would dispatch or pass the
file(s)/payload(s) to the application. In any case, since we have not
defined
any such beastie, we cannot dictate its use.
Given these constraints, the order should be 1) receive the message, 2)
persist
the message (may or may not be in persistent store -- persistent store is
not
required by the spec), and 3) send the Acknowledgment. TTL would define
the
time by which 1 and 2 must occur. We cannot dictate when the application
will
actually "pick up" the message/payloads.
It seems quite strange that we might send an Acknowledgment and then delete
the
message prior to hand-off to the application because TTL had passed?
Actually,
we don't delete the message from persistent store until after
persistDuration,
which should be considerably longer than TTL.
I can't think of any reason to delete the message prior to passing it to
the
application. What if the application is down for a couple of days? What
if
there is a week-long power outage? There is no reason to assume the MSH
and the
application reside together (they could be half-a-world apart). When the
application becomes available, it needs to process its queue. All messages
should still be there regardless of whether TTL or persistDuration has
passed.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, December 11, 2001 6:06 PM
To: david.burdett@commerceone.com
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
Actually, what I said below is not quite true. The exception is, of
course, message ordering where depositing an out-of-order message is not
delivery to the application. So, delivery to the application is depositing
the message in the persistent store and making the application aware that
the message is there. That's it. Once the MSH has signalled that a message
is available to the applicaiton, timeToLive is no longer a factor and in
any case, the MSH cannot tell when the application finally takes notice of
the message.
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 12/11/2001
07:00 PM ---------------------------
Martin W Sachs/Watson/IBM@IBMUS on 12/11/2001 06:31:16 PM
To: "Burdett, David" <david.burdett@commerceone.com>
cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
It seems to me that we have all at least implicitly agreed that depositing
a message in the persistent store constitutes delivery to the application
(not unlike the postal service delivering a letter to a post office box).
That's the event that should be governed by time to live.
See my previous posting.
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/11/2001 06:17:24 PM
To: ebxml-msg@lists.oasis-open.org
cc:
Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
I agree with Doug
The original intent behind TimeToLive is that it should indicate the time
by
which the message should be delivered to the application. Consider the use
case where the To Party MSH stores messages which, at the end of the day,
they forward in batch to an application. If we make the semantics mean that
the message will be processed, then, as Doug says, you can't send back the
acknowledgement until the message has been passed to the app.
I think it is completely valid to:
1. Send a delivery receipt to indicate that the message has been received
by
the To Party MSH
2. Later send an error message to indicate the the To Party MSH could not
deliver the message to the App before TimeToLive expired.
A delivery receipt is just that a receipt for **delivery** it is not an
indication that the message has been processed. That can only be provided
by
the application.
David
-----Original Message-----
From: Doug Bunting [mailto:dougb62@yahoo.com]
Sent: Tuesday, December 11, 2001 11:15 AM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
Hmmm, I remember no such decision and think it isn't a particularly useful
way to define TTL. The sender couldn't care less when a receiver MSH gets
a
message, they care only about the application at the To Party.
As you comment, the underlying issue is (again) acknowledgments and their
semantics. I completely agree an acknowledgment message MUST be the last
message an MSH could initiate with reference to a received message. (Yes,
applications are free to respond to any message whenever they please -- I'm
talking only about MSH signals.) In particular, error messages (such as
"TTL expired") MUST NOT be sent after an acknowledgment message has been
sent. According to my understanding of TTL, this would mean an MSH
shouldn't send an acknowledgment until it has informed the application.
whatever,
doug
----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "Doug Bunting" <dougb62@yahoo.com>; <ebxml-msg@lists.oasis-open.org>
Sent: Tuesday, 11 December 2001 10:43
Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
No, Arvola is right.
We decided a message could be delivered from the MSH to the Application
AFTER
TTL. TTL is the time it must be delivered to the To Party MSH. If this is
not
true, then the receiver could just hold any message he didn't like until
after
TTL and then discard, regardless of any Acknowledgments. The sending of an
Acknowledgment constitutes a commitment by the MSH to deliver to the
Application
(what the Application does is undefined).
Regards,
David.
-----Original Message-----
From: Doug Bunting [mailto:dougb62@yahoo.com]
Sent: Tuesday, December 11, 2001 11:47 AM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
Arvola,
I disagree; the wording is fine as it is.
If the example you've described occurs, the To Party MSH is not operating
correctly. The TimeToLive value is intended to be the time by which
(end-to-end, application-to-application, whatever you want to call it)
delivery must be complete. That may mean the To Party MSH discards a
message after it has been persisted in some storage (but not delivered to
its application).
Going further, your previous recommendation made sense though the example
was also slightly incorrect. In that example, a message found in
persistent
store after crash recovery might (MUST) be discarded due to an expired
TimeToLive value. Of course, we can't say anything about how long it might
take an application to process a message...
thanx,
doug
----- Original Message -----
From: "Arvola Chan" <arvola@tibco.com>
To: "David Fischer" <david@drummondgroup.com>;
<ebxml-msg@lists.oasis-open.org>
Sent: Monday, 10 December 2001 17:44
Subject: Re: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
David:
The first paragraph in section 3.1.6.4 in the version 1.091 draft now
reads:
"If the TimeToLive element is present, it MUST be used to indicate the
time,
expressed in UTC, by which a message should be delivered to the To Party.
It
must conform to an XML Schema dateTime."
I think the phrase "To Party" should be replaced with "To Party MSH". The
To
Party MSH will check the incoming message to determine if its TimeToLive
has
expired. It may have to make a persistent copy of the message before
attempting to deliver it to the To Party. A crash may happen after the
message has been persisted but prior to its being delivered to the To
Party.
Therefore, it is entirely possible that the To Party only receives the
message after TimeToLive has passed.
Regards,
-Arvola
-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>; ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>
Date: Sunday, December 09, 2001 8:47 AM
Subject: RE: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
>Yes, I will remove "and processed by".
>
>David.
>
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Friday, December 07, 2001 5:49 PM
>To: ebxml-msg@lists.oasis-open.org
>Subject: [ebxml-msg] Section 3.1.6.4 TimeToLiveElement
>
>This first paragraph in this section states:
>
>"The TimeToLive element indicates the time by which a message should be
>delivered to and processed by the To Party."
>
>I don't think the above statement is correct. The message must be received
>by the To Party MSH prior to its TimeToLive. Once it has been persisted by
>the To Party MSH, it can be delivered to the To Party. If a crash occurs
>after the message has been persisted but before it can be handed over to
the
>To Party, it is possible that it may be processed by the To Party (on
crash
>recovery) even after TimeToLive has expired.
>
>-Arvola
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>