FYI connection multiplexing has been implemented. You can notice in the logs
of SalutesWebSocketBindingTest that there are two requests made for the
server at 127.0.0.1:5555 and only one websocket handshake meaning the
connection is reused.
On Fri, Jul 8, 2011 at 4:32 PM, Florian Moga <moga....@gmail.com> wrote:
> Hi,
>
> With one week to mid-term, here is a summary of my progress on the
> websocket binding. As you might have noticed, a functional websocket binding
> can already be found in the contrib/ area. Along with the runtime code, you
> can find two tests demonstrating the following:
> 1. services with the same uri specified for binding.websocket will be
> served by the same server so the runtime will start as many servers as many
> _distinct_ uris there are in the domain. Services are exposed as resources
> of a websocket server at the componentName/serviceName/operationName path.
> 2. data conversion is handled automatically by the binding using JSON to
> send data over the wire
>
> In the mean time, I have also looked into the Tuscany async support. Thank
> you Simon Laws for walking me through it. I've exprimented with it on the
> comet binding and came to the conclusion that it doesn't fit my needs for
> now. The main reasons were the impact it has on the service definitions and
> the fact that the AsyncResponseInvoker supports a single response being
> returned while the main benefit of both the comet and websocket bindings
> is the ability to do server push so multiple responses may be received from
> the server. I would consider moving to the async support if something
> similar to the CallbackInvoker described by Mike here [1] would be
> available.
>
> To sum up, based on the proposal it seems like I am ahead of schedule with
> 2 points from the second coding period completed.
>
> Next steps include connection multiplexing, multiple response support and
> support for browser clients.
>
> At the moment, the binding works in the traditional way, when a request
> comes in, a websocket is created, the request is sent, the response is
> received, the websocket is closed. I'd like to experiment with opening a
> persistent websocket for *all* websocket services with the same uri and make
> all the communication through that. This facilitates multiple response
> support but needs to send additional metadata back and forth (like message
> id, operation). This will be achieved using another layer of JSON
> serialization with the following format:
>
> {
> "message_id" : "12342354",
> "operation" : "component/service/operation",
> "payload" : "<JSON array of operation parameters>"
> }
>
> This nested serialization is done in order to be able to determine the
> exact Java types for parameters before doing the actual deserialization from
> JSON to Java objects.
>
> Regarding browser clients, I will look for browsers that are implementing
> the v6 websocket draft to start testing with them and start building a
> javascript toolkit similar to the comet one. If I won't be able to find any
> (although major vendors were planning to support it) I will continue to
> start building compliance tests for Monsoon and do some interoperability
> testing with Jetty (which has up-to-date websocket support).
>
> Feel free to ask questions, make suggestions or to leave comments.
>
> Thanks,
>
> Florian
>
> [1] http://markmail.org/message/ry55k6scs62u346d
>
