RE: [ebxml-msg] Issue for your review

[Dick Brooks <dick@systrends.com>]

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:mwang@tibco.com]
Sent: Sunday, October 20, 2002 2:27 PM
To: ebxml-msg@lists.oasis-open.org
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: chrisfer@us.ibm.com
> phone: +1 508 234 3624
>
> [1] http://www.dictionary.com/search?q=asynchronous
>
> Doug Bunting <db134722@iplanet.com> 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>