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: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net