Comet Daily article by Jean-Francois Arcand

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Comet Daily article by Jean-Francois Arcand

ALT Mobile DEV
http://cometdaily.com/2008/02/13/new-technology-new-challenges/



I think this is a great article for many reasons. From the Web 2.0  
mash-up point of view, this paragraph is on the mark:

"... Most of the Comet actual literature (Comet Daily included
  ) focus on the client side of Comet, but new challenges are now on  
the server side: how can the push operations be efficient enough to  
deliver what Comet is meant for? Web designers must start thinking  
right from the beginning about how their applications will execute the  
push operations without too much contention. Web servers that claim to  
support Comet must offer the tools and APIs to let web designers  
efficiently deliver what Comet is all about: real time pushes..."


We ported our Dynamic Mashup Server to Grizzly for specific 5 reasons.  
The most important was the fact that it provides an API (in the form  
of Grizzlets) that provides a clean separation between our Web 2.0  
container technology and the HTTP/Comet engine. Servlets forces a web  
client centric integration design and causes seepage between server  
components.

 From reading the JRuby on Rails implementation, I think that they  
would also agree that Grizzly provides great flexibility for  
integrating alternative, non-Servlet technologies.

Another reason for selecting Grizzly was its support for accessing  
runtime statistics about the HTTP/Comet engine. As this capability  
gets flushed out-- and I get smarter about it-- we will use active  
monitoring to better control the Web 2.0 containers. Currently, our  
Web 2.0 containers primary purpose is to provide execution isolation  
for remote HTML and JavaScript. I hope to be able to add client  
statistics obtained from Grizzly to influence container use. For the  
J2EE person, perhaps the best corollary is integration between Servlet  
engines and EJB servers. Many early EJB servers has scaling problems  
since all they knew was that they had a limited number of (Servlet)  
clients. But the Servlet engines knew that they were connected to  
thousands of (browser) clients. There was no way to determine how many  
_real_ clients existed and dynamically optimize the containers.


Another great point-- as Jean-Francois says in the article: "Web  
designers must start thinking right from the beginning about how their  
applications will execute push operations..."-- is that Grizzly  
differs from many/all other Comet engines in that you can do a formal  
design for push activities. We've already started to document push wrt  
mash-up patterns and I think that push patterns will probably be  
discussed more formally rather than all those "chatty client"  
discussions.

So it's great to hear more about server issues.



--Zaid

ALT Mobile

http://altmobile.com/Home.html (web site)

http://web.mac.com/altmobile/ (official blog)




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

icon_smile.gif (240 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comet Daily article by Jean-Francois Arcand

Jeanfrancois Arcand-2
Salut,

ALT Mobile DEV wrote:

> http://cometdaily.com/2008/02/13/new-technology-new-challenges/
>
>
>
> I think this is a great article for many reasons. From the Web 2.0
> mash-up point of view, this paragraph is on the mark:
>
> "... Most of the Comet actual literature (Comet Daily included
> ------------------------------------------------------------------------
>
>  ) focus on the client side of Comet, but new challenges are now on the
> server side: how can the push operations be efficient enough to deliver
> what Comet is meant for? Web designers must start thinking right from
> the beginning about how their applications will execute the push
> operations without too much contention. Web servers that claim to
> support Comet must offer the tools and APIs to let web designers
> efficiently deliver what Comet is all about: real time pushes..."
>
>
> We ported our Dynamic Mashup Server to Grizzly for specific 5 reasons.
> The most important was the fact that it provides an API (in the form of
> Grizzlets) that provides a clean separation between our Web 2.0
> container technology and the HTTP/Comet engine. Servlets forces a web
> client centric integration design and causes seepage between server
> components.
>
>  From reading the JRuby on Rails implementation, I think that they would
> also agree that Grizzly provides great flexibility for integrating
> alternative, non-Servlet technologies.

Indeed, GlassFish v3 is using that approach, and will so do it for
PHP/CGI/FastCGI support.

>
> Another reason for selecting Grizzly was its support for accessing
> runtime statistics about the HTTP/Comet engine. As this capability gets
> flushed out-- and I get smarter about it-- we will use active monitoring
> to better control the Web 2.0 containers. Currently, our Web 2.0
> containers primary purpose is to provide execution isolation for remote
> HTML and JavaScript. I hope to be able to add client statistics obtained
> from Grizzly to influence container use. For the J2EE person, perhaps
> the best corollary is integration between Servlet engines and EJB
> servers. Many early EJB servers has scaling problems since all they knew
> was that they had a limited number of (Servlet) clients. But the Servlet
> engines knew that they were connected to thousands of (browser) clients.
> There was no way to determine how many _real_ clients existed and
> dynamically optimize the containers.
>
>
> Another great point-- as Jean-Francois says in the article: "Web
> designers must start thinking right from the beginning about how their
> applications will execute push operations..."-- is that Grizzly differs
> from many/all other Comet engines in that you can do a formal design for
> push activities. We've already started to document push wrt mash-up
> patterns and I think that push patterns will probably be discussed more
> formally rather than all those "chatty client" discussions.

:-)

>
> So it's great to hear more about server issues.

Thanks :-)

-- Jeanfrancois


>
>
>
> --Zaid
>
> ALT Mobile
>
> http://altmobile.com/Home.html (web site)
>
> http://web.mac.com/altmobile/ (official blog)
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]