cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: SOAP over WebSocket
Date Tue, 29 Apr 2014 14:38:36 GMT
Hi Przemyslaw,
the http connections need no necessarily get closed after each call,
so I don't think this is a problem. But hosting an HTTP endpoint at
the client is often not possible by its own limitation or blocked by
the network infrastructure. Another disadvantage of the conventional
decoupled scenario is the overhead of processing the entire ws-addr
soap headers to just get the referencing ID.

I think it would be nice to reuse the same programming model used by
the current decoupled model but to use a simpler underlining mechanism
(just passing a referencing ID value with the message) when using the
webwsocket transport.

Your app looks very good :-)
If you need one-to-one relationship between a request and its
response, you will need to include a referencing ID in the message.

regards, aki

2014-04-29 15:21 GMT+02:00 Przemyslaw Bielicki <>:
> 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] <
>> wrote:
>> Hi Przemyslaw,
>> Andrei's blog (the one linked in his earlier reply
>> 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:
>> > Sent from the cxf-dev mailing list archive at
>> ------------------------------
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>  To start a new topic under cxf-dev, email
>> To unsubscribe from cxf-dev, click here<>
>> .
>> NAML<>
> --
> View this message in context:
> Sent from the cxf-dev mailing list archive at

View raw message