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