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
