On Wednesday, April 25, 2012 04:38:12 PM Aki Yoshida wrote: > Hi Dan, > > I think the robust property makes sense for the server side but not > for the client side. The problem of the HTTP transport with oneway is > that the client doesn't know if the message reaches the target service > and that no component is taking the responsibility of making the > service receiving the message behind that oneway asynchronous > boundary. > > In the robust mode, the HTTP client will not get an HTTP 202 response > if something goes wrong at the server side. So if it does not receive > an HTTP 202 response, it can at least choose to resend the message > until it receives an HTTP202 response (this resend could potentially > lead to a duplicate invocation of the service but this can be filtered > out if each message carries a unique identifier). > > In contrast, in the JMS case, the server (or the queue) is taking the > responsibility of making the service receives the message once the > message is placed in the queue. So, if the client can send out a > message to the queue, it can assume that he doesn't need to worry > about the message (or there is nothing he can do).
For kicks, I did check the SOAP/JMS spec... It's actually a bit more "interesting" when it comes to One-Way operations. It specifically states that " For JMS messages sent to a Queue destination this MEP results in a SOAP message which will be received by zero or one receiver". Note the "Zero" in there. This is slight different than with HTTP in that with HTTP, you at least get the 202 to state the service did get a message. Something to keep in mind when using JMS clients. :-) -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
