Hi, GSoC is approaching to it's end this year so here's an update on my project. I've implemented the servlets 3.0 integration under the name of 'comet binding'. This would allow exposing services which can then be called by javascript from the client browser. What this binding brings new is the ability to receive the responses from the server by http streaming or long pooling. The scdl is available for services and has the classical form:
*<service ...>* * <tuscany:binding.comet/>* *</service>* * * The two implementations I made for this binding (which can be found in contrib/modules) are based on the Atmosphere Framework which helps achieving http streaming and long pooling cross-container and cross-browser. This means that if an application is deployed in a container having servlet 3.0 capabilities, it will use this API. If not, it will try and use the vendor specific asynchronous APIs from the pre-Servlet 3.0 era (like Grizzly for Glassfish, Continuous for Jetty, etc). If the container doesn't support any of those it will finally use blocking I/O. The latest implementation I've committed also uses Jersey RESTful Web Services integrated with Atmosphere which in combination with the Atmosphere jQuery plugin brings the capability of specifying what transport to be used at runtime (when the js call is made). You can check this out with the stock comet sample which can be found in contrib/samples. It simulates a stock monitor for which you can manually choose the transport and then the responses of ajax requests will come back correspondingly. Using a tool like Firebug or Chrome Developer Tools you can see nicely how the connection stays open throughout the communication in http streaming and how each time a new connection is persisted in long pooling. As for concurrent use of the application different browsers need to be used because multiple tabs in the same browser have the same session id for the same application and also browsers are undergone by the two http connection limit [0] which determines a browser-specific behavior. As for this week, being the last one from GSoC, I will continue implementing a wrapper over the js client similar to the one available for impl.widget and the possibility of passing parameters through json. I'm really pleased of how the integration came out and that I was able to bring these new technologies to Tuscany. I hope you find this a useful contribution. I will continue to keep you updated on the enhancements I'm bringing to this project and the future coding I'll be doing on Tuscany. Thanks, Florian [0] http://www.openajax.org/runtime/wiki/The_Two_HTTP_Connection_Limit_Issue On Sun, Jul 11, 2010 at 8:37 PM, Florian MOGA <[email protected]> wrote: > Hi, > > Here is a summary of the progress I've done on this project as most of > the communication was going on through IRC chat or IM due to the > increased efficiency of exchanging ideas. > > You can find the async-servlet-sca sample in the contrib area. It simulates > the features that will be available after the completion of the project, > this meaning HTTP streaming. To run it, you need Tomcat 7 or Glassfish which > support Servlet 3. This composite consists of 3 components: > > 1. the browser client (javascript) > 2. the servlet > 3. a java component > > During the research I've done, I ran into some limitations: > > - The Servlet 3.0 API offers asynchronous communication by delaying the > commit of the response, multiple responses can be sent by flushing the > response. Tried achieving real time updating in the browser with jquery and > dojo on the javascript side but they are waiting for the response commit > before interpreting the response. This can make 'one request - one > response' > async communication easy to achieve, but this is already available in > Tuscany with impl.widget or dwr. In order to bring something new to > Tuscany, > I continued my research and the only way of identifying and executing > multiple uncommitted responses for one request would be script injection > (returning the response as script tags into html). This is actually the > mechanism behind JSONP but again I can't use any existing JSONP library > (due > to the response commit phase). However, script injection seems to me like a > good option and I'm up to implementing JSONP (or something similar) through > uncommitted responses (one script tag for each flushed response) > - There have been multiple discussions going on for how to model the > scdl. First of all, we needed to establish if the servlet will be > transparent in the composite definition. This is limited for now as > impl.web > currently doesn't expose services and callbacks would be needed for 'one > request - multiple responses' communication. Due to the fact that I don't > posses so much experience in developing extensions for Tuscany and I can't > estimate how big are the changes needed in impl.web to support callbacks, > we've decided that I can model the browser <-> servlet async communication > in an sca way in the gsoc timeframe (about one month left). Meanwhile, if > somebody is available to make the necessary changes to impl.web I might be > able to make the servlet to be transparent in the configuration in the gsoc > timeframe. If not, I will continue after gsoc in developing this too. I > find > both types of communication useful: browser - servlet (for low level > communication), browser - component through a transparent servlet (for any > kind of communication). > > At the beginning of this week, I'll settle down with Ant a final version > for the scdl in the browser-servlet communication (this covers the gsoc > project) and I'll post a sample on this thread on how it will look like. > Meanwhile, I'm available for comments, questions or clarifications (sorry > for the long post). > > Thanks, > > Florian >
