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
<<attachment: winmail.dat>>