Title: Re: [ebxml-msg] Issue for your review
Michael,
I was
involved in a project to develop a reliable MSH within the Energy
industry. Reliability was accomplished by implementing the following
logic.
The
receiving MSH issues an Acknowledgement to the sender after both of the
following are performed:
1. the message was persisted to mass storage
2. the
to/from party id's are validated
If,
for some reason, the sender doesn't receive the ACK, it assumes a failure to
deliver and will retry sending the original message.
In the
case of a "lost ACK"; the receiving MSH, upon receiving a message
containing a Message-ID which has been previously "acknowledged", responds
with an Acknowledgement. Hopefully, this ACK will be received by the
sender. The process continues until someone on the sending end determines
there is a problem receiving/processing ACK's.
Dick Brooks
Systrends, Inc
7855 South River Parkway, Suite
111
Tempe, Arizona 85284
Web: www.systrends.com <http://www.systrends.com>
Phone:480.756.6777,Mobile:602-684-1484,eFax:240-352-0714
-----Original Message-----
From: Michael Wang
[mailto:]
Sent: Sunday, October 20, 2002 2:27
PM
To:
Subject: Re:
[ebxml-msg] Issue for your review
I think we all agree that the sender needs to be able to
handle
messages that are out of sequence. Let's
set that aside.
To me what needs to be clarified by the specification is
what
is meant by
"delivered"/"dispatched"/"handed-off"/"made available"
between layers.
Let's examine Doug's scenario of receiving MSH making
message
available to the application before sending
MSH ack. Let's
also assume the MSH and
application are completely different
applications and
their communication mechanism is HTTP.
At what point can the receiving MSH determines that the
received
message is "made available" to the
application and start to send
the MSH ack?
Should it be at the point of getting a HTTP 2xx response?
or
when the MSH feels it has sent the message but
without getting
a 2xx? I would think it is the
former.
If we take the later route (which seems to be what people
are
saying) then the receiving MSH may get a HTTP 500
AFTER it has
sent the MSH ack back. Now the
sender side thinks the receiver
has got the message
but in fact receiver side does not have it!??
My original point is that MSH should not violate the rules of
the
transport by ignoring the information it
provides. MSH should
not continue to the next
task until the "dispatched"/"made available"/
"delivered" rules are satisfied.
Without this clarified I do not know how to interpret the
following
statements made in the 2.0 spec.
2116 If an AckRequested element is present (not an
Acknowledgment Message)
then
generate an
2117 Acknowledgment Message in response
(this may be as part of another
message). The Receiving MSH
2118 MUST NOT send an Acknowledgment Message until the message has
been
persisted or delivered
to the
2119 Next MSH.
Regards,
-mw
Christopher B Ferris wrote:
>
> I think that it is safest to state that the
sender can have no expectation that
> it will
receive the HTTP 2xx response before the receipt of any
acknowledgement.
>
> By
its very definition[1], asynchronous means:
>
> Lack of temporal concurrence; absence of
synchronism.
>
> The
sending of an asynchronous message need not complete, from the sender's
> perspective, before the recipient sends the
acknowledgment.
>
>
Cheers,
>
> Christopher
Ferris
> Architect, Emerging e-business Industry
Architecture
> email:
> phone: +1 508 234 3624
>
> [1] http://www.dictionary.com/search?q=asynchronous
>
> Doug Bunting
<> wrote on 10/18/2002 05:06:17 PM:
>
> > Dave,
> >
> > An excellent description of
how very little we say in the Messaging
> >
specification can completely control the observed ordering of responses seen
at
> > the originating server. Your
example describes a real world issue resulting
>
> from a clear separation of concerns between the ebXML and transport
layers.
> >
> >
The other case I was attempting to describe earlier involved separating
concerns
> > between the application and ebXML
layers. I had misread or forgotten the
> >
original issue description and thought we were discussing a SyncReply /
> > syncReplyMode="mshSignalsOnly" / AckRequested
case. What I was describing in an
> >
earlier email is an indeterminate ordering of business and MSH signals
or
> > responses in this case. The MSH
MUST make the incoming message available to the
>
> application prior to returning (via the HTTP 200 reply if using that
transfer
> > protocol) an Acknowledgment
message. The MSH has no control over how quickly
> > the application operates so business signals or responses may
arrive at the
> > originating server before the
Acknowledgement message. We could try to force
> > that MSH to prevent outgoing messages including a
RefToMessageID pointing to the
> > one it's
working on but we can't guarantee the same MSH will even be used for
> > the outgoing message or close all of the race
conditions. And, so...
> >
> > In both cases, we need to describe the issue so
originating servers do not
> > depend upon
particular orderings rather than increasing the complexity of the
> > receiving server to (slightly) lessen the chances
for ordering to follow
> > less-than-obvious
patterns.
> >
> >
thanx,
> > doug
> >
> > Dave Elliot
wrote:
> > ...
>
>
> > > Here's another real world
problem. Suppose the Responder behaves as you
> > > suggest and does not send an async EbXML Ack until the
transport layer
> > > of the inbound message
has wrapped up. So in effect you have this
>
> > sequence: The Responder sends HTTP 202 and then immediately
sends the
> > > EbXML Ack over a different
DeliveryChannel (possibily different
> > >
transport protocol).
> > >
> > > Now let us suppose that the EbXML Ack delivery protocol
is faster to
> > > send and to
unmarshall/process than HTTP. This means that the ebXML Ack
> > > would arrive up at the Sender's EbXML Layer
before the Sender's HTTP
> > > transport was
able to confirm to its EbXML Layer that the original
> > > message was even sent.
> >
>
> > > Which illustrates that even if you
were to mandate the transport/ebXML
> > >
layer sequence that the Responder must follow, the sequence may still
> > > occasionally/randomly appear different to the
Requester. That's why I
> > > don't
think it is safe to mandate that kind of thing.
>
> >
> > > Best Regards,
> > >
> > > Dave
Elliot
> > > XML Global Technologies
> > >
> > >
----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist
use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >
> >
----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the
subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
