...
Current Status
Short summary
- the The code resides in rt/transport/http-websocket and it enables cxf services to be invoked over websockets.
- it It supports both the embedded mode and the servlet container mode. The former can be used in the standalone setup that uses an embedded jetty server and the latter can be used in the container setup that uses the servlet container provided by the container.
- some Some test cases are located in systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/websocket and there systests/jaxws/src/test/java/org/apache/cxf/systest/jaxws/websocket. There is also a browser based demo at distribution/src/main/release/samples/jax_rs/websocket.
- it requires several Several additional libraries are required to enable this feature depending on the usage. Concretely, it will require jetty-websocket is required for the embedded standalone mode (i.e., the endpoint is given with the host and port part as in address="ws://host:port/path"). For the servlet mode (i.e., the endpoint is given using a relative path (i.e., address="/path"), it will requires either require jetty-websocket to use jetty or require atmosphere-runtime and a specific websocket implementation such as jetty-websocket or tomcat-websocket to use that specific container's websocket capability.
Usage Patterns
We have the following message exchange patterns to use this websocket transport for cxf service invocation.
...
- if the client and the service want to explicitly exchange a sequence of requests and responses, they are responsible in passing some id and ref-id in the exchanged message's headers so that each response can be correlated to its request.
- for correlating requests and their responses that are send back asynchronously, the request message may include the RequestId header and the corresponding response may set this value in its ResponseId header.
- asynchronous web service calls that are performed using a decoupled endpoint using the http transport can be performed using the websocket transport without using a decoupled endpoint.
Open questions
- the content-length header is not used to determine the length of the message, as the message end can be determined for a websocket message using other means (i.e., either its length when used a block-mode or the fragment's indicator). So it is not clear whether we can filter out the content-length.
- the referencing mechanism is needed for correlating requests and their responses that are sent back asynchronously or even continuously. This means we need to add something like message-id in the request and message-ref-id in the response headers.the protocol format needs to be clarified (see above regarding the protocol format used currently) and possibly to several variations binding variations.
...
Currently, strings are converted into utf-8 bytes and sent using the byte transfer mode of websocket. We could add the native string/text transfer as websocket supports it. However, this should be allowed only when the entity body is absent or of string/text.
- add message-ref-id part 1
see above "open question".
- add message-ref-id part 2
we might want to link this mechanism to cxf's current decoupled request/response correlation.
- add some more browser based sample client applications
we can add some js examples or update the logbrowser sample. There is a browser based demo in the samples collection (see above). This demo uses the current default binding which is not _javascript_ friendly. To support browser based applications, we need different bindings.
...
- supporting a direct output stream connection from the client application to the service application. Currently, from the service application to the client, a direct output stream can be kept open after the initial call from the client to the service takes place. Thus, the service can continue to push data directly to the client over this output stream. Similarly, it would be interesting to establish a direct output stream from the client to the service so that the client can continue to push data directly to the service.
- use a websocket instead of a decoupled endpoint to receive decoupled responses
