RE: [ebxml-msg] reliable messaging

[ian.c.jones@bt.com]

Marty,

	a similar point was raised at our meeting last week.  It is on or
list of things to do with an initial errata warning that the reliable
"guarantee" is not as strong as we currently state.  Thanks for giving us
such a concise use-case to base our discussion on.  As both you and Chris
point out some use of a status message may be useful and this was also
discussed, as usual we were concerned about the Ack of Ack and similar "how
many responses are needed" type of issues.

	We are always open for any suggestions especially if they offer us a
practical solution.

Ian Jones
Chair OASIS ebXML Messaging Services TC 

Tel:   +44 (0)29 2072 4063
Fax:   +44 (0)29 2072 4137  
Email: ian.c.jones@bt.com

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: 14 October 2002 16:46
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] reliable messaging






It has been pointed out to me that ebXML reliable messaging is not reliable
under system failure.  At least one person who mentioned it considers ebXML
messaging to be broken as a result.  Here is a scenario:

Party A send a message reliably to Party B.

Party B's MSH receives and persists the message.

Party B's MSH attempts to send the reliable-messaging acknowledgment but
Party B's system goes down before the acknowledgment gets on the wire.

Party A exhausts its retries and concludes that the message was not
delivered.

Party B eventually comes up and the destination application processes the
persisted message as prescribed in the MSG specification.

Parties A and B are now out of sync with respect to that transaction and do
not know they are out of sync. Party A believes that the transaction
failed. Party B has in fact processed the message that it received from
Party A. Reliable messaging has failed to deliver on its promise.

The solution to this problem is not trivial and the MSG team needs to give
it a lot of thought.  At a minimum, the following are needed in the spec:

1.  Both parties to the message exchange MUST persist enough state to allow
recovery and getting back in sync. Specific state variables must  be
prescribed.  They are at least those variables needed to restore the state
of the transaction and conversation after system recovery, such as the
conversation ID, CPA Id, service, action, and perhaps other parts of the
message header.

2. Timeouts and retries, as prescribed in the MSG spec, are not sufficient
to cover system failures since the failure could last a very long time.
Instead, if the party that sent the message doesn't receive a reply in a
reasonable time, it must be able to send a status query to the other party
and keep requesting status periodically until it receives a response.  The
status query protocol must be defined in the MSG specification. If the
appropriate state information is persisted at both ends, when party B comes
up, it will receive and respond properly to the status query.  The timeouts
could be retained in the spec but their main use would be to signal the
"attached human" to make a phone call.

The MSG team should consider this a work item for version 3. Should the
team not wish to solve this problem, at the very least, a caveat should be
added to the MSG specification that messaging reliability under conditions
of system failure is outside the scope of the MSG team.

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 subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>