I hope this small diagram is self-explanatory http://postimg.org/image/blg7dk2o7/
On Tue, Apr 29, 2014 at 3:20 PM, Przemyslaw Bielicki <[email protected]>wrote: > 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] < > [email protected]> 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 >> [email protected] >> 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-tp5742556p5743418.html Sent from the cxf-dev mailing list archive at Nabble.com.
