Date: Fri, 15 Feb 2008 01:09:08 -0500
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)
(image/gif attachment: icon_smile.gif)