You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Przemyslaw Bielicki <pb...@gmail.com> on 2014/04/08 09:47:19 UTC
SOAP over WebSocket
Hi,
does CXF support WebSockets as a transport? I need to support multiplexed
SOAP and WebSocket protocol looks perfect as a starting point. It is
bidirectional and full duplex.
By multiplexing I mean that the client can send messages without waiting
for the response, and the responses may be sent back in the different order
that they were sent (I will use message / conversation ID, to identify the
request and response)
I looked for the information in the mailing list history, but it's still
not clear for me if you support WebSocket out-of-the box[1] or I need to
implement my own transport[2] (that could be a nice contribution to CXF?
Many thanks,
Przemyslaw
[1] http://cxf.apache.org/docs/websocket.html
[2] http://cxf.apache.org/docs/custom-transport.html
Re: SOAP over WebSocket
Posted by Przemyslaw Bielicki <pb...@gmail.com>.
Ordering is not needed at all. Correlation ID is enough as I expect that some
requests will take more time that another and it's OK.
Anyway, thanks a lot for your inputs!
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-over-WebSocket-tp5742556p5745365.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SOAP over WebSocket
Posted by Aki Yoshida <el...@gmail.com>.
I think there is a gap between mux and what you will need for doing
async request-response calls.
With mux, you can have multiple websockets layered on a single socket
connection.
With that, you can queue requests and response multiplexed over a single socket.
But this still won't give you a request-response correlation for those
requests and responses that are exchanged asynchronously (unless you
add some restriction like the ordering of the messages).
regards, aki
2014-06-17 15:10 GMT+02:00 Przemyslaw Bielicki <pb...@gmail.com>:
> Yes, you need some kind of correlation Id in your SOAP message (ideally in
> the header part)
>
> But, I just learned that there is already existing subprotocol extension for
> websocket called MUX whose goal is to multiplex multiple ws connections over
> single TCP conection. In this case we have multiplexing on lower OSI layer
> e.g. implementation
> http://maven-repository.com/artifact/org.eclipse.jetty.websocket/websocket-mux-extension
>
> I'm going to play withit and compare. Single TCP connection to handle
> multiple clients is a great solution and it normally scaleas much better
> than one connection per client.
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/SOAP-over-WebSocket-tp5742556p5745269.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SOAP over WebSocket
Posted by Przemyslaw Bielicki <pb...@gmail.com>.
Yes, you need some kind of correlation Id in your SOAP message (ideally in
the header part)
But, I just learned that there is already existing subprotocol extension for
websocket called MUX whose goal is to multiplex multiple ws connections over
single TCP conection. In this case we have multiplexing on lower OSI layer
e.g. implementation
http://maven-repository.com/artifact/org.eclipse.jetty.websocket/websocket-mux-extension
I'm going to play withit and compare. Single TCP connection to handle
multiple clients is a great solution and it normally scaleas much better
than one connection per client.
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-over-WebSocket-tp5742556p5745269.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SOAP over WebSocket
Posted by Aki Yoshida <el...@gmail.com>.
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 <pb...@gmail.com>:
> 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.
Re: SOAP over WebSocket
Posted by Przemyslaw Bielicki <pb...@gmail.com>.
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.
Re: SOAP over WebSocket
Posted by Przemyslaw Bielicki <pb...@gmail.com>.
I hope this small diagram is self-explanatory
http://postimg.org/image/blg7dk2o7/
On Tue, Apr 29, 2014 at 3:20 PM, Przemyslaw Bielicki <pb...@gmail.com>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] <
> 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-tp5742556p5743418.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SOAP over WebSocket
Posted by Aki Yoshida <el...@gmail.com>.
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 <pb...@gmail.com>:
> 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.
Re: SOAP over WebSocket
Posted by Przemyslaw Bielicki <pb...@gmail.com>.
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.
Re: SOAP over WebSocket
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 08/04/14 18:01, Aki Yoshida wrote:
> Hi Przemyslaw,
> I am not sure if your multiplex case needs websockets or the normal
> asynchronous soap invocation over http is suitable.
>
> Regarding the current websocket support in cxf, it is supported out of
> the box in the current 3.0.0-SNAPSHOT for some scenarios and this part
> is documented in the wiki page you found. There are still many things
> to do, so some behavior may change incompatibly in the future.
>
> Our focus was so far on the server side, in particular for jaxrs
> scenarios, to push data continuously to the client over the socket.
> That means, the service can push data asynchronously to the client
> after the initial call is made and the socket is opened .
>
> We don't have a similar capability in the other direction as there is
> no output stream of some sort that allows the client to keep writing
> to the socket directly..
>
Yes, unless the client is a browser :-)
Cheers, Sergey
> You can find some samples in the systests/jasrs as the unit test cases
> and also a browser based demo in the sample collection. (the projects
> paths are mentioned in the wiki page).
>
> The current implementation only supports one particular biding (i.e.,
> the way in which the cxf message is bound to the websocke's wire), we
> are making this part customizable and provide some other bindings
> (e.g., microsoft soap over websocket).
>
> Any feedback and possible contribution is welcome.
>
> regards, aki
>
> 2014-04-08 9:47 GMT+02:00 Przemyslaw Bielicki <pb...@gmail.com>:
>> Hi,
>>
>> does CXF support WebSockets as a transport? I need to support multiplexed
>> SOAP and WebSocket protocol looks perfect as a starting point. It is
>> bidirectional and full duplex.
>> By multiplexing I mean that the client can send messages without waiting
>> for the response, and the responses may be sent back in the different order
>> that they were sent (I will use message / conversation ID, to identify the
>> request and response)
>>
>> I looked for the information in the mailing list history, but it's still
>> not clear for me if you support WebSocket out-of-the box[1] or I need to
>> implement my own transport[2] (that could be a nice contribution to CXF?
>>
>> Many thanks,
>> Przemyslaw
>>
>> [1] http://cxf.apache.org/docs/websocket.html
>> [2] http://cxf.apache.org/docs/custom-transport.html
Re: SOAP over WebSocket
Posted by Aki Yoshida <el...@gmail.com>.
Hi Przemyslaw,
I am not sure if your multiplex case needs websockets or the normal
asynchronous soap invocation over http is suitable.
Regarding the current websocket support in cxf, it is supported out of
the box in the current 3.0.0-SNAPSHOT for some scenarios and this part
is documented in the wiki page you found. There are still many things
to do, so some behavior may change incompatibly in the future.
Our focus was so far on the server side, in particular for jaxrs
scenarios, to push data continuously to the client over the socket.
That means, the service can push data asynchronously to the client
after the initial call is made and the socket is opened .
We don't have a similar capability in the other direction as there is
no output stream of some sort that allows the client to keep writing
to the socket directly..
You can find some samples in the systests/jasrs as the unit test cases
and also a browser based demo in the sample collection. (the projects
paths are mentioned in the wiki page).
The current implementation only supports one particular biding (i.e.,
the way in which the cxf message is bound to the websocke's wire), we
are making this part customizable and provide some other bindings
(e.g., microsoft soap over websocket).
Any feedback and possible contribution is welcome.
regards, aki
2014-04-08 9:47 GMT+02:00 Przemyslaw Bielicki <pb...@gmail.com>:
> Hi,
>
> does CXF support WebSockets as a transport? I need to support multiplexed
> SOAP and WebSocket protocol looks perfect as a starting point. It is
> bidirectional and full duplex.
> By multiplexing I mean that the client can send messages without waiting
> for the response, and the responses may be sent back in the different order
> that they were sent (I will use message / conversation ID, to identify the
> request and response)
>
> I looked for the information in the mailing list history, but it's still
> not clear for me if you support WebSocket out-of-the box[1] or I need to
> implement my own transport[2] (that could be a nice contribution to CXF?
>
> Many thanks,
> Przemyslaw
>
> [1] http://cxf.apache.org/docs/websocket.html
> [2] http://cxf.apache.org/docs/custom-transport.html
RE: SOAP over WebSocket
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
I do not see a link to your sequence diagram, was it forgotten?
From my perspective you can evaluate WS-Addressing decoupled responses for your case. They works very similar to JMS, but using SOAP HTTP + WSA.
See details in my blog: http://ashakirin-cxf-async.blogspot.de/ and on CXF page: https://cxf.apache.org/docs/ws-addressing.html.
Regards,
Andrei.
From: Przemyslaw Bielicki [mailto:pbielicki@gmail.com]
Sent: Mittwoch, 9. April 2014 09:30
To: dev@cxf.apache.org
Subject: Re: SOAP over WebSocket
to make my question more clear I made a simplistic and simplified sequence diagram.
pls let me know if this is supported in CXF? it is very similar to JMS where you can receive requests and send responses asynchronously and in any order.
if it's not supported, is it possible to implement it with current CXF architecture (mainly, dispatching client requests to business logic)?
On Tue, Apr 8, 2014 at 9:47 AM, Przemyslaw Bielicki <pb...@gmail.com>> wrote:
Hi,
does CXF support WebSockets as a transport? I need to support multiplexed SOAP and WebSocket protocol looks perfect as a starting point. It is bidirectional and full duplex.
By multiplexing I mean that the client can send messages without waiting for the response, and the responses may be sent back in the different order that they were sent (I will use message / conversation ID, to identify the request and response)
I looked for the information in the mailing list history, but it's still not clear for me if you support WebSocket out-of-the box[1] or I need to implement my own transport[2] (that could be a nice contribution to CXF?
Many thanks,
Przemyslaw
[1] http://cxf.apache.org/docs/websocket.html
[2] http://cxf.apache.org/docs/custom-transport.html
Re: SOAP over WebSocket
Posted by Przemyslaw Bielicki <pb...@gmail.com>.
https://github.com/pbielicki/soap-websocket-cxf
I tested soap-websocket-webapp in both Wildfly 8.0.1-SNAPSHOT and Tomcat
8.0.3 (for Tomcat you need to add extra dependency of commons-logging). You
need to start ActiveMQ on the same machine on default port 61616.
You can use soap-websocket-client to shoot messages.
The only thing I'm not able to achieve yet is to have multiple consumers
consuming SOAP requests for Hello and Calculator services. Any idea how to
configure this?
Przemyslaw
--
View this message in context: http://cxf.547215.n5.nabble.com/SOAP-over-WebSocket-tp5742556p5743410.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: SOAP over WebSocket
Posted by Przemyslaw Bielicki <pb...@gmail.com>.
I attached the picture but mailing list swallowed it. There you go
http://s29.postimg.org/xbqcwzpzb/cxf_websocket.png
I'm finishing a POC I will share with you in the coming days.
9 kwi 2014 09:30 "Przemyslaw Bielicki" <pb...@gmail.com> napisał(a):
> to make my question more clear I made a simplistic and simplified sequence
> diagram.
>
> pls let me know if this is supported in CXF? it is very similar to JMS
> where you can receive requests and send responses asynchronously and in any
> order.
> if it's not supported, is it possible to implement it with current CXF
> architecture (mainly, dispatching client requests to business logic)?
>
>
> On Tue, Apr 8, 2014 at 9:47 AM, Przemyslaw Bielicki <pb...@gmail.com>wrote:
>
>> Hi,
>>
>> does CXF support WebSockets as a transport? I need to support multiplexed
>> SOAP and WebSocket protocol looks perfect as a starting point. It is
>> bidirectional and full duplex.
>> By multiplexing I mean that the client can send messages without waiting
>> for the response, and the responses may be sent back in the different order
>> that they were sent (I will use message / conversation ID, to identify the
>> request and response)
>>
>> I looked for the information in the mailing list history, but it's still
>> not clear for me if you support WebSocket out-of-the box[1] or I need to
>> implement my own transport[2] (that could be a nice contribution to CXF?
>>
>> Many thanks,
>> Przemyslaw
>>
>> [1] http://cxf.apache.org/docs/websocket.html
>> [2] http://cxf.apache.org/docs/custom-transport.html
>>
>
>
Re: SOAP over WebSocket
Posted by Przemyslaw Bielicki <pb...@gmail.com>.
to make my question more clear I made a simplistic and simplified sequence
diagram.
pls let me know if this is supported in CXF? it is very similar to JMS
where you can receive requests and send responses asynchronously and in any
order.
if it's not supported, is it possible to implement it with current CXF
architecture (mainly, dispatching client requests to business logic)?
On Tue, Apr 8, 2014 at 9:47 AM, Przemyslaw Bielicki <pb...@gmail.com>wrote:
> Hi,
>
> does CXF support WebSockets as a transport? I need to support multiplexed
> SOAP and WebSocket protocol looks perfect as a starting point. It is
> bidirectional and full duplex.
> By multiplexing I mean that the client can send messages without waiting
> for the response, and the responses may be sent back in the different order
> that they were sent (I will use message / conversation ID, to identify the
> request and response)
>
> I looked for the information in the mailing list history, but it's still
> not clear for me if you support WebSocket out-of-the box[1] or I need to
> implement my own transport[2] (that could be a nice contribution to CXF?
>
> Many thanks,
> Przemyslaw
>
> [1] http://cxf.apache.org/docs/websocket.html
> [2] http://cxf.apache.org/docs/custom-transport.html
>