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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: reliable messaging

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


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

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

> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC