I've just had tried out what you've got going in the comet-webapp sample, its looking great. Being able to do cometComponentContext.c1.TemperatureService.getTemperatureCelsius(updateTempC) is i think really excellent.
...ant On Sat, Aug 14, 2010 at 2:16 AM, Florian MOGA <[email protected]> wrote: > Hi, > A few comments on my latest commits. The changes I made consist in using one > single servlet for all the comet service methods found in a scdl. I then use > Jersey RESTful Web Services capabilities to dispatch the request to the > correspondingly endpoint and operation. This has been done with a > combination of the singleton and abstract factory pattern and it was needed > due to the two http connection limit which is present in all the browsers > (except chrome). Now all the comet services defined in a scdl are served > through the same http connection as opposed to one servlet per service > method (operation) which would've hit the two http connection limit. > I also had to change the sample application so that it uses multiple > services defined in various ways (one/multiple services per component, > one/multiple methods per service). The latest commit also includes a > hardcoded mock for the proxies which will be injected in the javascript on > the client side as well as the layer of abstraction over atmosphere jquery > plugin. > I am now proceeding with generating the proxies and adding a similar > singleton servlet to serve that and adding json parameters to method calls. > For this, I've decided to use Gson [0] as it hasn't been used with Tuscany > before and to see how it works and eventually give us more alternatives in > this direction. > Florian > [0] http://code.google.com/p/google-gson/ > > > On Tue, Aug 10, 2010 at 11:59 AM, Florian MOGA <[email protected]> wrote: >> >> 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 >> > >
