Hi, In the last few days I've been able to implement the generation of proxies for the comet services in the scdl, add passing parameters for methods through JSON. I've added the generated javascript toolkit and it's dependent libraries under a namespace called SCA. So now, calling a comet service can be done like this:
*SCA.CometComponentContext.HumidityService.getHumidity(location, updateHum); * * * *avoiding this way any conflicts that could occur if jQuery would be imported again. * Today I revised the Apache headers to be in place, completed all the javadoc, updated the unit test in order to be ran automatically by surefire. To get a taste of how things work, check out the comet-webapp sample in the contrib/samples folder. This being said, the project is completed. It's been a pleasure working on this and I would like to thank Ant for the great mentoring. See you around, Florian On Sat, Aug 14, 2010 at 2:01 PM, ant elder <[email protected]> wrote: > 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 > >> > > > > >
