[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-msg] RE: Public usage scenario documents
Tony,
In other words, you are saying: ignore ebXML reliable messaging and use
BTP. Even if a consensus agrees with you, the MSG spec needs at least a
surgeon general's warning that reliable messaging may fail to be reliable
under system-failure conditions.
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
*************************************************************************************
"Tony Fletcher"
<tony.fletcher@chor To: Martin W Sachs/Watson/IBM@IBMUS, "Cutler, Roger \(RogerCutler\)"
eology.com> <RogerCutler@chevrontexaco.com>
cc: "Christopher Ferris" <chris.ferris@sun.com>, "'Duane Nickull'"
05/28/2002 04:55 AM <duane@xmlglobal.com>, "eBTWG List" <ebtwg@lists.ebtwg.org>, "'bhaugen'"
<linkage@interaccess.com>, "Randy Clark" <Randy.Clark@bakerhughes.com>,
"Cutler, Roger \(RogerCutler\)" <RogerCutler@chevrontexaco.com>,
<ebxml-msg@lists.oasis-open.org>
Subject: RE: Public usage scenario documents
Dear Roger, Marty, Duane and others,
Another possibility is to use the Business Transaction Protocol (BTP - now
an OASIS Technical Committee specification) to 'wrap' the messaging (then
can use straight forward ebXML messaging - do not really need reliable
messaging but could be used as belt and braces). My understanding is that
using BTP around an application message can give each side assurance that
the message was received, or both sides know that something went wrong. Of
course, you do not get something for nothing. The BTP engines on both
sides
must be implemented correctly and each side has to take a persistent log so
that the loss of the last message problem Roger raises is detected and can
be recovered from. BTP engines will be available as packages that can be
easily 'slotted' into systems.
Best Regards Tony
A M Fletcher
Choreology Ltd., 13 Austin Friars, London EC2N 2JX UK
Tel: +44 (0) 20 76701787 Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com <mailto:tony.fletcher@choreology.com>
(Home: amfletcher@iee.org)
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: 27 May 2002 21:07
To: Cutler, Roger (RogerCutler)
Cc: Christopher Ferris; 'Duane Nickull'; eBTWG List; 'bhaugen'; Randy
Clark; Cutler, Roger (RogerCutler); ebxml-msg@lists.oasis-open.org
Subject: RE: Public usage scenario documents
Roger,
I agree with your comment about reliable messaging. This characteristic
was pointed out to me recently by a colleague in IBM. A more succinct way
of stating it is that ebXML reliable messaging is not reliable under system
failure. The possibility you mention can arise as follows:
Party A send a message reliably to Party B.
Party B's MSH receives and persists the message.
Party B's MSH attempt 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, if Party B saved enough state
information, 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.
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:
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.
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. 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.
See the IBM HTTPR 1.1 specification for an example.
The MSG team should consider this a major work item for version 3.
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
****************************************************************************
*********
"Cutler, Roger
(RogerCutler)" To: "'Duane
Nickull'" <duane@xmlglobal.com>, "Cutler, Roger
<RogerCutler@chevron (RogerCutler)"
<RogerCutler@chevrontexaco.com>
texaco.com> cc: "'bhaugen'"
<linkage@interaccess.com>, eBTWG List
<ebtwg@lists.ebtwg.org>,
Randy Clark <Randy.Clark@bakerhughes.com>,
05/27/2002 12:13 PM Christopher Ferris
<chris.ferris@sun.com>
Subject: RE: Public
usage
scenario documents
Thanks for the kind words. I agree that what I am trying to do needs a lot
more work, but I am uncertain that I am capable of providing that on my
own.
That is, I'm saying I could use some help here.
I also agree that the ebXML reliable messaging spec is a good thing, as far
as it goes.
As I see it, however, there are unfortunately possibilities other than the
two you document that are undocumented in the spec. For example, the
message I send may actually be delivered but I am unaware of it. That is,
I
can think that the message transmission was unsuccessful but the recipient
thinks that the transmission was successful and goes ahead based on that
assumption. In some situations this could be quite undesirable. If one
follows these scenarios far enough I think one may be able to reach some
rather disturbing questions about whether one side of the communication can
trick the other side in certain ways. I believe that these possibilities,
if they are real, should be clearly documented.
It seems to me that the spec would be greatly improved if it made a more
clear effort to define an objective that is achievable. Unfortunately,
there are things that are not possible in the context of asynchronous
messaging, basically because the last person to say "goodbye" never can
know
that the "goodbye" got through. On some level it's never possible to get
around that. I believe, however, that with more care it is possible to
state an achievable objective (involving high degrees of confidence, not
certainty) and to define strategies outside the scope of the messaging
mechanism itself to provide higher levels of certainty -- for example,
periodic scheduled reconciliation (where the fact that the mechanism is
scheduled introduces a new factor).
That's not to say the ebXML spec is not valuable, but I don't think it's
really fully baked. Moreover, I seem to recall that there was a HUGE
document of unanswered issues (many of them, it seemed to me, resulting
from
misunderstandings) that has not, to my knowledge, been worked through.
Given the situation I outline, it seems to me -- this is just my personal
opinion here -- that the W3C would be highly unlikely to use the ebXML
reliable messaging spec as a building block or otherwise to endorse it. I
view this as a considerable potential problem, because reliable messaging
is
really important and it would be really nice if everybody were agreeing on
how to achieve it, or at least if there were some reasonable convergence.
On another topic -- Hi, Randy. How did you get on this email thread
address
list? Is this some hat you wear that I didn't know about?
-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Sunday, May 26, 2002 10:12 AM
To: Cutler, Roger (RogerCutler)
Cc: 'bhaugen'; eBTWG List; Randy Clark; Christopher Ferris
Subject: Re: Public usage scenario documents
Roger:
What you describe as your work is associating ebXML with Business
Relevance,
something I personally thank you for. This effort needs more such work.
As to your comment about reliable messaging, it is very implementable and
can be tested for. Reliable messaging means that I can tel my Message
Handler Service (MHS) to send a message to another party and know that it
will either:
1) deliver the message within the parameters I instructed it once and once
only, or
2) fail to deliver the message and inform me of such.
It is a very powerful mechanism that SOAP 1.1 did not have to the degree
needed by business (once again Business Relevance).
Duane Nickull
"Cutler, Roger (RogerCutler)" wrote:
>
> I'd like to get some input and help from ebXML. And I have mentioned
> ebXML in previous conference calls -- not disparagingly but with a
> certain feeling of confusion.
>
> However, we should bear in mind that the objectives are different. I
> am not trying to get into business requirements per se, but only as
> they drive the technical infrastructure requirements. This is a
> rather delicate balance, and I'm not sure I know exactly how to do it,
> but some things are clearly business process and outside the scope of
> this working group. The idea, however, is to try to check whether the
> business process requirements put any unexpected burdens on the
> technical infrastructure, hopefully without getting all wound up in
> the business process issues themselves.
>
> As an example of this balance, in the latest draft of this usage case
> I have a discussion in which I try to convince myself (and hopefully
> the reader) that unique ID and ordering of messages is "in scope" (so
> that one can request all the messages after message A12KFN or all
> after Mar 23), but that sequencing (message 24 is not accepted until
> 23 is received, or "we know we're missing a message because we have 22
> and 24 but not 23") is "out of scope" because it seems to belong at
> the business process level. I'm not sure I'm really right about this
> particular call -- I'm just trying to illustrate the character of the
> issue.
>
> Although it is not exactly the subject of the note I am responding to,
> I might also mention that I am kind of bemused by the ebXML reliable
> messaging spec -- in that I don't know exactly what to make of it. On
> the one hand, it is as far as it goes a reasonable piece of work, but
> on the other it seems to me to be fairly obviously flawed -- and
> apparently static. Is this going to get re-done? Extended or fixed?
> By whom?
>
--
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC