Hi Simon, Thanks for your feedback. I was going to ask Ant if the extensions guide page would be a good place to publish the documentation for the binding :) Good to be confirmed. I'll also check with Ant on the modifications needed for moving to trunk, but it will take one or two weeks more to get done all the enhancements I would like to implement. Maybe I'll be able to catch the 2.x release :)
Florian On Tue, Aug 10, 2010 at 10:44 AM, Simon Laws <[email protected]>wrote: > On Mon, Aug 9, 2010 at 10:07 PM, Florian MOGA <[email protected]> wrote: > > 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: > >> > >> the browser client (javascript) > >> the servlet > >> 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 > > > > Florian > > Thanks for the excellent write up. I haven't tried out the code yet > but it sounds like you've made pretty good progress. The first thing > that comes to mind is I was wondering if you could distill this > information into a write up up for our 2.x extensions guide [1]. We > could mark binding.commit at "work in progress" or as "still in > contribution" but firstly it would be good to have some docs in the > site. Of course it would be good to think about getting this into > trunk proper also. > > [1] > http://tuscany.apache.org/documentation-2x/sca-java-extensions-guide.html > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com >
