You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Florian MOGA <mo...@gmail.com> on 2010/07/11 19:37:01 UTC
Asynchronous Servlet Integration with SCA callbacks - progress
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
Re: Asynchronous Servlet Integration with SCA callbacks - progress
Posted by Florian MOGA <mo...@gmail.com>.
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 <an...@gmail.com> 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 <mo...@gmail.com> 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 <mo...@gmail.com>
> 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 <simonslaws@googlemail.com
> >
> >> wrote:
> >>>
> >>> On Mon, Aug 9, 2010 at 10:07 PM, Florian MOGA <mo...@gmail.com>
> 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 <mo...@gmail.com>
> >>> > 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
> >>
> >
> >
>
Re: Asynchronous Servlet Integration with SCA callbacks - progress
Posted by ant elder <an...@gmail.com>.
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 <mo...@gmail.com> 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 <mo...@gmail.com> 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 <si...@googlemail.com>
>> wrote:
>>>
>>> On Mon, Aug 9, 2010 at 10:07 PM, Florian MOGA <mo...@gmail.com> 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 <mo...@gmail.com>
>>> > 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
>>
>
>
Re: Asynchronous Servlet Integration with SCA callbacks - progress
Posted by Florian MOGA <mo...@gmail.com>.
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 <mo...@gmail.com> 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 <si...@googlemail.com>wrote:
>
>> On Mon, Aug 9, 2010 at 10:07 PM, Florian MOGA <mo...@gmail.com> 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 <mo...@gmail.com>
>> 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
>>
>
>
Re: Asynchronous Servlet Integration with SCA callbacks - progress
Posted by Florian MOGA <mo...@gmail.com>.
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 <si...@googlemail.com>wrote:
> On Mon, Aug 9, 2010 at 10:07 PM, Florian MOGA <mo...@gmail.com> 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 <mo...@gmail.com>
> 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
>
Re: Asynchronous Servlet Integration with SCA callbacks - progress
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Aug 9, 2010 at 10:07 PM, Florian MOGA <mo...@gmail.com> 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 <mo...@gmail.com> 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
Re: Asynchronous Servlet Integration with SCA callbacks - progress
Posted by Florian MOGA <mo...@gmail.com>.
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 <mo...@gmail.com> 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
>