Re: GSoC status
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 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 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: and only one websocket handshake meaning the >> connection is reused. >> >> On Fri, Jul 8, 2011 at 4:32 PM, Florian Moga 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 foll
Re: GSoC status
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 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: and only one websocket handshake meaning the > connection is reused. > > On Fri, Jul 8, 2011 at 4:32 PM, Florian Moga 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 serve
Re: GSoC status
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: and only one websocket handshake meaning the connection is reused. On Fri, Jul 8, 2011 at 4:32 PM, Florian Moga 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" : "" > } > > 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 >
GSoC status
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" : "" } 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