cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Przemyslaw Bielicki <pbieli...@gmail.com>
Subject Re: SOAP over WebSocket
Date Tue, 29 Apr 2014 13:21:16 GMT
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+s547215n5743415h18@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+s547215n569328h21@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.

Mime
View raw message