Thanks for your reply Guillaume, my previous scenario on which were based my questions was actually not as good as I thought in the context of trying to understand transactions/persistence in ServiceMix, so let's say that instead of an HTTP binding we have a "home made" TCP binding that receives an xml message from a TCP client and sends back an OK ACK byte sequence to the TCP client as soon as it is sure the xml message received by the TCP Binding has no chance to be lost (TCP client just post messages to ServiceMix, no request/reply), or a ERROR ACK if an error occurs while the TCP binding process the message or if it is not able to put the message on the NMR, the TCP client will not discard the xml message before receiving the OK ACK byte sequence from the TCP binding, resending the message if necessary.
TCP-Binding ---|Q1|---> Router eip ---|Q2|---> xslt ---|Q3|---> HTTP-Provider ----> External Web Service |Q| = internal JMS (ActiveMQ) queue used by the JCA flow So my assumption here is that, using the JCA flow, it would be safe for the TCP-Binding to send an OK ACK back to the TCP Client as soon as the TCP-Binding succesfully sends a MessageExchange to the Router eip i.e. if send(InOnly) succeed (no exception thrown), we have the guarantee that the messageExchange was successfully posted in |Q1|. Is that assumption true? If true, from that point, now we need to make sure that we never lose the message in |Q1|. Does the message in |Q1| will be removed from the queue after the TCP-Binding process the DONE MessageExchange from Router eip, after Router eip sends back the DONE MessageExchange to the TCP-Binding but before the TCP-Binding receives it, or after the Router eip successfully sends the MessageExchange to xslt (message posted in |Q2|) without having to wait for any DONE to be sent back to Router eip, of none of the above? And once the message is in |Q3|, when will it be removed from |Q3|? Can we have a guarantee that the MessageExchange in |Q3| will not be removed until the HTTP-Provider sends a DONE message exchange back to xslt i.e. after the call to the external web service successfully returns without any error (the external web service doesn't return any value or we don't care about the value returned)? Thanks again for helping me trying to clarify how transactions work in ServiceMix! gnodet wrote: > > First, HTTP is unreliable. This means that if something bad happen > between the time the server receives the request and the client > receives a response, the request will be lost. The only way to be > fully reliable would be to use WS-RM which has not been implemented > yet (we need to use CXF, Axis2, or implement our own for that). > And for that to work correctly, the persistent store used by the WS-RM > need to be enlisted in the same transaction used by the JCA flow to > send the exchange to the HTTP BC. > > So, while you can use the JCA flow for processing an input > HTTP message, the client may not never the response (if the > socket has been closed for example). You would need to use > an asynchronous pattern, where SMX would send the response > by sending an HTTP request. In this case, you could rollback > the transaction if the client did not answer with an HTTP 200 > status code. Again, there are always point of failures: if the > client receives the response, process it, but fail before having > answered a 200, the server would assume the request has not > been processed. So you would need duplicate message > detection. > > So, even in this case, the solution is to use a robust WS-RM > implementation with a persistent store. Or use JMS :) > > On 10/20/06, spelletier <[EMAIL PROTECTED]> wrote: >> >> In a scenario like: >> >> HTTP-Consumer ---> Content-based Router eip ----> xslt ----> >> HTTP-Provider >> -----> External Web Service >> >> If the JCA flow is used to transport the MessageExchange (with >> transaction/persistence), when e.g. HTTP-Consumer sends a MessageExchange >> to >> the Content-based Router (InOnly through send() method), the message will >> be >> put in an internal queue (through the JCA flow) and then delivered to the >> Router eip. >> >> Assuming this is true, my first question is when that message will be >> removed from the queue? After the Router eip sends a DONE reply message >> to >> the HTTP-Consumer but before the HTTP-Consumer receives it? After the >> HTTP-Consumer receives the DONE message from the Router eip? And when >> the >> Router eip will send a DONE message to the HTTP-Consumer? Sometime after >> the send() method to xslt succeeded (no exception i.e. when through the >> JCA >> flow the message is sucessfully posted in the queue between the Router >> eip >> and the xslt) or after explicitely receiving the DONE message from the >> xslt? >> >> Another related question is, if all components use the JCA flow and a JMS >> message (containing the MessageExchange) is posted in the internal queue >> between xslt and HTTP-Provider, how can we make sure that the message is >> not >> removed from the queue until the external web service returns >> successfully >> (no soap fault, assuming the web service method doesn't return any value >> or >> that we don't care about the return value)? >> >> And if the JCA flow was only used between HTTP-Consumer and the Router >> eip, >> with e.g. SEDA flow for all the remaining components from Router eip to >> external web service (let's assume for the purpose of the example that >> all >> components except HTTP-Consumer use sendSync), how can we guarantee that >> we >> don't lost the message until we have the confirmation that the call to >> the >> external web service succeeded and returned with no fault? >> >> Sorry for the long email :-), but the whole point is to try to better >> understand the different transaction/persistence scenarios using one or a >> mix of different NMR flows combined with calls to web services hosted >> outside ServiceMix. >> >> Thanks a lot! >> -- >> View this message in context: >> http://www.nabble.com/NMR-Flows-%2B-transaction-persistence-tf2476584.html#a6906622 >> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > -- View this message in context: http://www.nabble.com/NMR-Flows-%2B-transaction-persistence-tf2476584.html#a6925366 Sent from the ServiceMix - User mailing list archive at Nabble.com.
