Yes, this is what would be nice to have as a solution with two HTTP connections is really bad. Not only your client needs to understand HTTP (acts as a server), but also a HTTP connection is closed after 202 response! This is huge waste of resources, especially if you have use cases with 1000 - 3000 transactions per second.
Anyway, what I did with websockets and JMS seems to be the best solution for me as I can decouple websocket frontend from SOAP backends. I can have e.g. two instances of FE and hundreds of BEs. So, these two components could scale independently (FE usually has much less work to do compared to BE, so usually you need an order of magnitude less instances of it) Thanks for your inputs On Tue, Apr 29, 2014 at 3:16 PM, Aki Yoshida-3 [via CXF] < ml-node+s547215n5743415...@n5.nabble.com> wrote: > Hi Przemyslaw, > Andrei's blog (the one linked in his earlier reply > http://ashakirin-cxf-async.blogspot.de/) has some examples about > asynchronous soap calls over HTTP. But the limitation of this approach > is that you will need two separate HTTP connections: one from the > client to the service and the other from the service to the client > (the so called decoupled endpoint). > > If you can have these two connections, a conventional one shot request > and response interaction (I mean each invocation results in one > request and one response transferred at some time, not necessarily > synchronously) works fine with this decoupled endpoint approach. > > If you use a websocket, you can run these two logical connections over > a single websocket. > > And this is what is meant but the bottom entry in the todo list of the > cxf websocket wiki page, namely to utilizing the websocket connection > instead of opening a separate HTTP back connection for those decoupled > scenarios. I think this probably will work with some minor > modification in the current code. We need a dedicated decoupled URI > name to indicate back conduit associated with the socket at the server > side. > > regards, aki > > 2014-04-29 9:21 GMT+02:00 Przemyslaw Bielicki <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5743415&i=0>>: > > > > Hi Aki, > > > > Btw. what do you call asynchronous SOAP over HTTP? How do you get a > response > > when it's ready? > > > > For me, HTTP is out of question as it's synchronous protocol, whatever > > tricks you make after :) > > My multiplex needs is a real bidirectional, full-duplex protocol. > > > > Cheers, > > Przemyslaw > > > > > > > > -- > > View this message in context: > http://cxf.547215.n5.nabble.com/SOAP-over-WebSocket-tp5742556p5743400.html > > Sent from the cxf-dev mailing list archive at Nabble.com. > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://cxf.547215.n5.nabble.com/SOAP-over-WebSocket-tp5742556p5743415.html > To start a new topic under cxf-dev, email > ml-node+s547215n569328...@n5.nabble.com > To unsubscribe from cxf-dev, click > here<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=569328&code=cGJpZWxpY2tpQGdtYWlsLmNvbXw1NjkzMjh8LTE4NTc0NjM0MDM=> > . > NAML<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://cxf.547215.n5.nabble.com/SOAP-over-WebSocket-tp5742556p5743416.html Sent from the cxf-dev mailing list archive at Nabble.com.
