ICEfaces provides comprehensiveAjax Push
capabilities for JSF applications, and the Push Server
automatically configures your run time environment for simple and
effective deployment of applications and portlets under a single domain
name. The Push Server manages a single Ajax Push blocking
connection with the client browser and shares that connection between
the deployed applications. It also utilizes native Asychronous
Request Processing (ARP) capabilities to provide single node
scalability to Ajax Push deployments. A basic deployment of the
the Push Server is
illustrated below, and shows how a single blocking connection is shared
between multiple ICEfaces applications, multiple views onto the same
application, and portal pages with multiple ICEfaces portlets.
Zero Configuration
You simply need to deploy and run the Push Server as a
standalone web application, and at startup your ICEfaces applications
will automatically detect and utilize it to manage the blocking connections
associated with Ajax Push. There is no other configuration
required to make it work.
Browser Connection Limits Be Gone
The primary purpose of the Push Server is to eliminate the
browser connection limit associated with a single web domain.
Each ICEfaces application, application view, or portlet requires a
blocking connection for the long polling mechanism used at the heart of
Ajax Push, but if each page in the browser maintained its own blocking
connection, the browser connection limit would be rapidly exceeded as
new page views were opened. The ICfaces Ajax Bridge performs
connection sharing in the client browser, and the Push Server
manages that single blocking connection at the server, sharing it
between the deployed ICEfaces applications and portlets.
Regardless of the number of deployed applications, and the number of
page views onto those applications, only two connections are required,
so the browser connection limit will never be exceeded.
Native Asynchronous Request Processing
Because Ajax Push requires a blocking connection per client session, and because threads are consumed for each of these connections during the entire request/response lifecyle, the mechanism suffers from a thread scalability issue under the standard Servlet model. Various application servers overcome this deficiency in the Servlet specification by augmenting the web container with an ARP mechanism capable of freeing up threads for the duration of the blocking period. When configured to do so, the Push Server automatically detects and utilizes the native ARP mechanism in the application server, to provide a thread scalable implementation for Ajax Push in a single node deployment. The following open source application servers are supported:
Tomcat/JBoss - APR provided through Comet Processor
GlassFish - ARP provided through Grizzly
Jetty - ARP provided through Continuations
For other commercial application servers, you will need to upgrade to
theEnterprise Push Server
to
take advantage of their
respective ARP mechanisms.
Need An Enterprise-strength Deployment?
The Push Server provides simple and effective Ajax Push
support in a single node deployment. If your enterprise requires
a more scalable clustered deployment with failover support, you will
need to upgrade to theEnterprise
Push Server
. It provides the
same features as the Push Server, but fully supports clustered
deployments with failover. It also provides complete integration
with commercial application servers like WebSphere and WebLogic.
