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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [ebxml-dev] ebMS Asynchronous Binding to HTTP

In case that the initiating MSH receive both a 500 and ACK, I tend to mark the message sent successfully, as ACK is an official receipt... my $0.02 again.


Ronald van Kuijk wrote:
Hi all,

There are even other situations where this inconsitency can occur.

Suppose system B is not directly accessible, but behind a front-end
webserver lets call it system C.

req req
A -----> C -----> B

Lets now assume the 200 response of the servlet in server B is
completely send to server C and server B *could* continue with the rest
of the process, e.g. sending an ack. but.....

A C <----- B

In the not so unrealistic situation however (Apache and Bea Weblogic in
our case) it could happen that server C cannot deliver the 200 response
to server A. If the communication between server B and C is not
'transacted' e.g. because the communication is done with plain http
nothing more, server B is never notified of the error and *will* start
sending the ack.

Server A however never got the 200 response but the ack will start
comming in. Even though server B did everything 'right'.
So I agree with with Patrick that Server A should be able to handle
this, either by ignoring the ack, resending the message after a timeout
and then receiving the ack or by accepting the ack and marking the
message as sucessfully send. The former case is a situation the ebMS
specs clearly specify, if you are using reliability. In the latter case
I hope the original sending thread will not be waiting to long on a 200
response or even do a 'roll-back' or any other undefined action. So
ignoring the ack

That rises the question what does server A send to server B when it does
not want to accept or ignores the ack? A 500 wil cause the ack to be
resent after a timeout, while a 200 makes server B think the message was
sucessfully send while it was not processed at all.. nice issue for the

Again.. this situation is not hypothetical and Bea told us to adapt our
protocol to circumvent this problem. Currently we could, because we are
not fully using ebXML (yet), but what if it is a standardized protocol
that we cannot change? I do not know if other combinations have the same
problem. Apache with JBoss/Tomcat probably does not have this problem,
because they do not use http.

Patrick Yee probeerde het volgende duidelijk te maken op 25-6-2003 16:38:

Dear Kentaro and all,

Let's assume that a practical MSH should be able to handle multiple requests
at the same time. Further, let's assume the other side responds "nicely" in
the sequence just like Diagram B.

But, it is possible, e.g. under stress condition, that HTTP Request(msg) and
HTTP Request(ack) are active at the same time and being handled in parallel,
even the other side responds in the sequence of Diagram B. In most
circumstances, the MSH (or the servlet engine underneath) has no idea of
which request should be in a higher priority and should be completed first,
they are just being handled in parallel.

My point is: in this case the initiating MSH has to resolve the state
inconsistency issue anyway. So, why is it necessary for us to impose such
requirement to ebMS protocol?

So theoretically, I agree that Diagram B scenario is cleaner. But
practically, the initiating MSH should not take it for granted. Instead, it
should be more clever and deal with exceptions nicely. Just my $0.02.

Regards, -Patrick

----- Original Message ----- 
From: "Kentaro Ejima" <kenn@infoteria.co.jp>
To: <ebxml-dev@lists.ebxml.org>
Sent: Tuesday, June 24, 2003 05:24 PM
Subject: [ebxml-dev] ebMS Asynchronous Binding to HTTP


Dear experts,

I have some questions about Asynchronous Messaging
with HTTP.

Infoteria tested our MSH implementation with some of
the other implementations in asynchronous mode, and
encountered the problem that our MSH retried to send
a message though the Ack was actually received.

We have investigated the cause and found that the Ack
was sent before HTTP-Response returned. - Diagram (A)

Diagram (A)

HTTP Request(msg)

HTTP Request(Ack)
HTTP Response(Ack)

HTTP Response(msg)

On the other hand, Infoteria expected the diagram (B).

Diagram (B)
                  // Status : Sending or Re-sending
HTTP Request(msg)
HTTP Response(msg)
                  // Status : Sent and Signal-Waiting
HTTP Request(Ack)
HTTP Response(Ack)
                  // Status : Delivery Completed

Then, with (A) and (B),
the message status transition was ...

Diagram (C)
                  // Status : Sending or Re-sending
HTTP Request(msg)

HTTP Request(Ack)
HTTP Response(Ack)
                  // Status : Delivery Completed
HTTP Response(msg)
                  // Status : Sent and Signal-Waiting

In short, "Status : Delivery Completed" was overwitten
by "Status : Sent and Signal-Waiting" and it caused
retry as if Ack was not received yet, till retry
exceeded the count specified in the CPA.

My thought is, a single HTTP session MUST be treated as
an atomic unit and cannot be divided anymore, however
ebMS V2.0 specification has nothing written about that.
So, diagram (A) is invalid in this point of view. If not,
case assumption is extremely complicated. I believe it is
what as usual a protocol-stack is thought to be, and it
makes things more simple and easy.

If my understanding is right, we will implement our MSH
not to overwrite the status after "Delivery Completed"
and reject Ack session arrived before HTTP Response.
(40x error will be responded for the ACK POST session)
But if many of implementations take diagram (A), it
doesn't work well in the context of "interoperability."
In fact, 2 out of 4 cases were diagram (A).

At least, if so or not so, this kind of HTTP binding
should be mentioned in the future version of ebMS spec
or some other guidelines.

How do you think about them, all?

FYI) RosettaNet explicitly defines the HTTP binding in
case of asynchronous mode that a HTTP session of posting
a message SHOULD be returned with status of 202 Accepted.
This means a receiver should take some action "after"
the first MSG POST session is successfully completed.

Kentaro Ejima




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