Following my latest commit, I have some updates on the websocket binding.
I've been thinking a lot and unfortunately I can't guarantee how much time I
will be able to dedicate to Monsoon in the future and I certainly don't want
this to affect Tuscany's websocket support.
With that in mind, I decided to change the websocket binding to use embedded
Jetty instances for websocket server endpoints. Jetty has probably the best
websocket support available now in Java and it is always kept up-to-date
with the latest changes in the protocol. Jetty lead developer is actively
involved in the IETF working group. Note that the websocket protocol is
still a draft but it is now in the last call phase inside the IETF.
Jetty supports a number of draft versions in parallel (00, 01, 06, 07) so it
will adapt for what version does the browser support. I am using Chrome 12
and it works out of the box. For Firefox and Opera you would have to enable
websockets from browser configuration. Don't expect all modern browsers to
work, most of them don't have such new versions like 06 or 07 implemented
yet. However, the protocol will soon be an internet standard so browser
adoption will increase.
By upgrading the Jetty version, we'll be able to upgrade our websocket
support up to the latest changes in the protocol which is very convenient
given the fast-pase in which the protocol is evolving.
Given Servlet limitations, the websocket endpoints won't be able to share
the same port as the webapplication itself as I am not able to integrate
that with our SerlvetHost. This is currently being discussed for the
Servlet 3.1 spec (JSR 340): Add necessary support to enable WebSocket and
other protocols that do initial handshake over HTTP or work on top of HTTP
in the Servlet API by adding ability upgrade the underlying socket protocol.
Add support where possible to enable such functionality in the web container
so we can build easier to use higher level protocol support for things like
WebSockets. This was also the case when using Monsoon. The port can be
configured in the component definition.
Also, I am not aware of a reasonable up-to-date websocket client
implemenation in Java (which is kind of normal given the protocol is not a
standard yet and is still experimental) so I prefer to drop the SCA
reference support at the moment. Browser clients are supported starting with
my latest commit. Just as with the comet binding, I have developed a wrapper
over the websocket API to simulate SCA in the browser which injects service
proxies. Requests from one client to *any* websocket service as well as
responses are multiplexed via a single websocket channel to improve
scalability. Once a good client implmentation appears, it will be far easier
to add reference support comparing to the browser client support.
I am now continuing the project by adding multiple response support. I have
started to recreate the comet samples now using websockets. The autocomplete
sample now works with websockets, the others use the multiple response
support. I will add them to SVN as soon as that is implemented.
Sorry for the lengthy post, I wanted to expose the whole situation and why
this decision will ensure that Tuscany's websocket support will easily keep
up with all the changes in the protocol. Feel free to ask questions, comment
or make suggestions.
Thanks,
Florian
On Sat, Jul 9, 2011 at 8:20 AM, Florian Moga <moga....@gmail.com> wrote:
> 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
>>
>
>
