GSoC status

[Florian Moga <mo...@gmail.com>]

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

Re: GSoC status

[Florian Moga <mo...@gmail.com>]

As you might have noticed from the commits list, the implementation of the
websocket binding [1] is now completed. Feel free to check the 4 samples [2]
that demonstrate various features of the binding. Readmes describe the
samples functionality as well as some implementation details of the binding.
Functionally, they are basically the comet samples in order to demonstrate
similarities and differences between technologies.

The websocket binding has currently been moved to trunk in order to catch
the 2.0-Beta3 release hoping that this would encourage community feedback.

Thank you,

Florian

[1]
http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-websocket/

[2]
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/samples/learning-more/binding-websocket/

On Sun, Jul 24, 2011 at 5:16 PM, Florian Moga <mo...@gmail.com> wrote:

> 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 <mo...@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 <mo...@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
>>>
>>
>>
>

Re: GSoC status

[Florian Moga <mo...@gmail.com>]

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 <mo...@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 <mo...@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
>>
>
>

Re: GSoC status

[Florian Moga <mo...@gmail.com>]

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 <mo...@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
>