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.