RE: reliable messaging

[Martin W Sachs <mwsachs@us.ibm.com>]

Jim,

My explanations below.  As you see, your comments are right on the mark and
mostly I just say that I agree with them.

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



"HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com> on 08/06/2001 05:27:48
PM

To:   ebxml-msg@lists.oasis-open.org
cc:
Subject:  RE: reliable messaging



Marty, see comments below, basically asking for crispness in defining the
problem...

jim



> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Sunday, August 05, 2001 1:30 PM
> To: ebxml-msg@lists.oasis-open.org
> Cc: cferris@xroads.East.Sun.COM
> Subject: reliable messaging
>
>
> I would like to simplify the discussion regarding where the message is
> reliably delivered to.  I recently realized that by
> delivering the message
> to the persistent store at the upper boundary of the message
> service, the
> message service is fulfilling its committment to deliver the
> message to the
> application.  The middleware above the application is really a set of
> services which act on behalf of the application.  The
> persistent store at
> the upper boundary of the message store is probably the last
> place that the
> message exists as the character string that was sent over
> the wire. At
> that point, the message is parsed and converted to a DOM tree or other
> object structure that the application-specific code will
> process.  This
> means that delivery of the message reliably to the
> application is entirely
> within the scope of the message service.

More precisely, "...within the scope of the ToParty's Message Service
Handler." In other words, the ToParty's application (or services supporting
the application!) needs to get the message payload to the application, and
in that sense, the MSH at the far end participates. It's too broad to say
that the "message service" participates.

MWS:  What you say sounds fine.  I was trying to argue that delivery of the
message to the From Party application does not involve interfaces above the
top
of the MSH and hence can be defined within the message service
specification.
Your words indicate that you agree.

>
> As to delivery failure notification, the question is, what is the
> "application" that the notification has to be reliably
> delivered to?  The
> answer is that it is the intelligence which cares about a response and
> which has to perform application-level recovery if the
> application-level
> response does not arrive.  Delivery of the delivery failure
> notification
> indeed involves layers of function outside the scope of the
> message service
> specification. However, the message service specification
> still has the
> responsibility of stating that the the delivery failure
> notification SHALL
> be delivered to the application.  A non-normative note can
> explain that his
> involves function that is outside the scope of the message
> service and that
> delivery may be accomplished by any appropriate method such
> as API function
> or by placing the notification where it can be polled by the
> application.

Again, specifics are needed. The obligation is on the FromParty's MSH to
tell the FromParty that the payload did not reach the pervasive store at
the
ToParty's MSH.

MWS:  Correct and the obligation must be stated as a SHALL, not a SHOULD.
A given application can choose to ignore the delivery-failure notification,
though if it is using reliable messaging, it really needs that
notification.

Whether the payload really got out of the ToParty's MSH's
pervasive store to the target application is not a subject for this MSH
interaction, IMO.

MWS:  Again you are right.  Delivery to the persistent store at the To
party's
MSH is tantamount to delivery to the To application as I tried to explain.

Of course, we haven't clearly defined the Service
Interface used by the FromParty's MSH to tell the FromParty about this
reliable messaging failure, but that's on the agenda for next work.

MWS: If you can define that interface for version 1.1, that's great. I have
been arguing that changing SHOULD to SHALL is essential for version 1.1
while defining the interface can probably wait for Version 2.0.

>
> 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
> **************************************************************
> ***********************
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
>

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org