ICEfaces Asynchronous HTTP Server
ICEfaces Asynchronous HTTP Server
ICEfaces Asynchronous HTTP Server
Deployment Guide
Version 1.6
Copyright
The content in this guide is protected under copyright law even if it is not distributed with software that includes an end user license
agreement.
The content of this guide is furnished for informational use only, is subject to change without notice, and should not be construed as
a commitment by ICEsoft Technologies, Inc.
ICEsoft Technologies, Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in the informational
content contained in this guide.
Sun, Sun Microsystems, the Sun logo, Solaris and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United
States and in other countries.
All other trademarks mentioned herein are the property of their respective owners.
June 2007
About this Guide
The ICEfaces Asynchronous HTTP Server (AHS) is a deployment technology that provides enterprise-
grade scalability for asynchronous ICEfaces applications that use server-initiated rendering. This guide
provides an overview of the Asynchronous HTTP Server and specific configuration details for deploying the
server and configuring ICEfaces applications to use it.
For additional information, please visit the ICEfaces Community website: http://www.icefaces.org
Prerequisites
A complete understanding of standard ICEfaces deployment is a prerequisite for using this guide.
ICEfaces Documentation
You can find the following additional ICEfaces documentation at the ICEfaces Community website
(http://documentation.icefaces.org):
• ICEfaces Getting Started Guide — Includes information to help you configure your environment to
run sample applications and a tutorial designed to help you get started as quickly as possible using
ICEfaces technology.
• ICEfaces Developer’s Guide — Includes materials targeted for ICEfaces application developers and
includes an in-depth discussion of the ICEfaces architecture and key concepts, as well as reference
material related to markup, APIs, components, and configuration.
• ICEfaces Release Notes — Read the ICEfaces Release Notes to learn about the new features included
in the ICEfaces release.
• Asynchronous HTTP Server Release Notes — Read the Asynchronous HTTP Server Release Notes
to learn about the new features included with this release.
Copyright. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
The Asynchronous HTTP Server (AHS) is an HTTP server capable of handling long-lived asynchronous
XMLHttpRequests in a scalable fashion. In the standard Servlet model, each outstanding asynchronous
XMLHttpRequest occupies its own thread, which means that thread requirements can grow linearly with
the number of clients. The long-livedness of these requests will have significant impact on thread-level
scalability of the application. If server-initiated rendering occurs frequently, thread consumption will be
somewhat mitigated, but if server-initiated rendering occurs infrequently, large numbers of users will
cause excessive thread consumption, and the scalability of the application will be compromised. It is
strongly recommended that the Asynchronous HTTP Server be used in all ICEfaces application
deployments where asynchronous update mode is used.
Before discussing the architecture of an Asynchronous HTTP Server deployment, it is useful to review
the communication pattern that ICEfaces uses in Asynchronous mode. Asynchronous updates are
primed with a blocking request from the client. When a render occurs in the JSF lifecycle, a response is
produced and the blocking request is satisfied. When the response is received at the client, another
blocking request is generated. ICEfaces also uses non-blocking requests for user-initiated interactions
via the full or partial submit mechanism. Non-blocking requests are passed to the ICEfaces application.
In ICEfaces, the Blocking Servlet handles all of this communication. See Figure 1.
The Asynchronous HTTP Server handles thread-level scalability issues. It is designed to support single
as well as clustered application server deployments with one or more ICEfaces applications deployed
on it.
The Asynchronous HTTP Server is deployed as a separate application in the application server, and it
occupies a single port on the network. Individual ICEfaces application deployments use Java Messaging
Service (JMS) to communicate with the Asynchronous HTTP Server. Blocking requests are queued at
the Asynchronous HTTP Server on a per client basis, and as responses become available, they are
communicated to the Asynchronous HTTP Server, again via JMS. A response is matched to its associated
blocking request, the request is unblocked, and the response is returned to the client. Because it is
possible for a response to be generated prior to a request arriving, the Asynchronous HTTP Server also
queues up responses waiting for requests that it can satisfy.
The deployment architecture is fronted with an HTTP web server that filters blocking request and directs
them to the Asynchronous HTTP Server for processing. Non-blocking requests are passed directly to the
ICEfaces application possibly via an application server-specific plug-in. The web server can also be
configured to do user authentication and to use SSL for security. The basic ICEfaces enterprise
deployment infrastructure, including Asynchronous HTTP Server and front-end web server, is illustrated
in Figure 2.
This chapter describes the deployment configuration that must occur to support enterprise deployments
of ICEfaces applications with the Asynchronous HTTP Server. The basic steps include:
1. Configuring the Asynchronous HTTP Server
2. Configuring the ICEfaces Application
3. Configuring the Web Server
4. Configuring the Application Server
</init-param>
<init-param>
<param-name>com.icesoft.faces.async.server.persistent</param-name>
<param-value>true</param-value><!-- boolean -->
</init-param>
<init-param>
<param-name>com.icesoft.faces.async.server.compression</param-name>
<param-value>true</param-value><!-- boolean -->
</init-param>
<init-param>
<param-name>
com.icesoft.faces.async.server.executeQueueSize
</param-name>
<param-value>30</param-value><!-- integer -->
</init-param>
</servlet>
Note: It is critical that the port number matches the port number in the Apache HTTP
Server's configuration file, which is discussed in Routing Requests, p. 6,.
To specify the JMS Configuration properties, modify the following context parameter in the web.xml and
repackage the async-http-server.war:
<context-param>
<param-name>com.icesoft.util.net.messaging.properties</param-name>
<!-- properties file of choice -->
<param-value>weblogic.properties</param-value>
</context-param>
If the supplied properties files do not suffice, a custom properties file can be created and added to the
classpath. A JMS Provider Configuration properties file can contain the following properties:
java.naming.factory.initial
java.naming.factory.url.pkgs
java.naming.provider.url
com.icesoft.util.net.messaging.jms.topicConnectionFactoryNam
com.icesoft.util.net.messaging.jms.topicNamePrefix
Refer to the documentation for your application server for these property values. The following example
shows the property values for JBoss:
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=localhost:1099
com.icesoft.util.net.messaging.jms.topicConnectionFactoryName=ConnectionFactory
com.icesoft.util.net.messaging.jms.topicNamePrefix=topic/
<context-param>
<param-name>com.icesoft.faces.async.server</param-name>
<param-value>true</param-value>
</context-param>
2. Just as the Asynchronous HTTP Server (AHS) needs to be configured for your specific application
server, an ICEfaces application needs to be configured likewise. Refer to Configuring the JMS
Provider, p. 4, for details on configuring the application to use the JMS Provider.
3. Add the following JAR to the web application build (if not already present):
• icefaces-ahs.jar
requests to the application server. A configuration such as this is mandatory to have full support for all
mainstream Internet browsers. Refer to Figure 2 on page 2.
Note: In the code examples throughout this section, we use boldface text for variables
that should be replaced as required.
Depending on the deployment, either Apache HTTP Server 2.0.x or 2.2.x can be used as the front-end.
When the Asynchronous HTTP Server is to be deployed to a single application server or to a single node
in a cluster of application servers, both versions of Apache can be used. However, if the Asynchronous
HTTP Server is to be deployed to multiple nodes in a cluster of application servers, Apache 2.2.x is to
be used.
Routing Requests
To route all blocking requests to the Asynchronous HTTP Server and all other requests to the application
server, add the following code to the end of the Apache configuration file.
Note: The VirtualHost container is not mandatory for Apache 2.0.x; when omitted, its
directives, such as ServerAdmin, need to be omitted as well.
<VirtualHost _default_>
ServerAdmin [email protected]
DocumentRoot /var/www/html/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
TransferLog logs/host.example.com-access_log
<IfModule mod_proxy.c>
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
# The following two directives will route all blocking requests to the
# Asynchronous HTTP Server (identified by host:port).
ProxyPass /application-name/block/receive-updated-views
http://host:port/application-name/block/receive-updated-views
ProxyPassReverse /application-name/block/receive-updated-views
http://host:port/application-name/block/receive-updated-views
# The following two directives will route all other requests to the
# application server (identified by host:port).
ProxyPass /application-name
http://host:port/application-name
ProxyPassReverse /application-name
http://host:port/application-name
</IfModule>
</VirtualHost>
Note: The previous ProxyPass and ProxyPassReverse directives must appear on a single
line in your configuration file.
If multiple ICEfaces applications are deployed behind the Asynchronous HTTP Server, multiple
ProxyPass and ProxyPassReverse directives should be included, two sets for each application. If an
Apache HTTP Server plug-in is used, which is discussed in Apache HTTP Server, p. 6,, the last
ProxyPass and ProxyPassReverse set can be omitted.
Note: It is critical that the port number, mentioned in the first ProxyPass and
ProxyPassReverse set, matches the port number in the Asynchronous HTTP
Server's configuration file, which is discussed in Deploying the Asynchronous
HTTP Server, p. 3,. Evidently the port number, mentioned in the second
ProxyPass and ProxyPassReverse set, should match the port number of the
application server.
To have proxy support in the Apache HTTP Server, the mod_proxy and mod_proxy_http modules are
required. In the Apache configuration file where all modules are being loaded, add the following if not
already added:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
For more information on how to load modules into Apache HTTP Server, refer to Apache Module mod_so
which can be found at:
http://httpd.apache.org/docs/2.0/mod/mod_so.html (Apache 2.0.x)
http://httpd.apache.org/docs/2.2/mod/mod_so.html (Apache 2.2.x)
Security Considerations
Authentication
To enforce authentication of the user when accessing an ICEfaces application, add the following code
to the Apache configuration file before the added IfModule container:
<LocationMatch ^/application-name>
AuthName "ICEfaces Member-Only Access"
AuthType Basic
AuthUserFile /var/www/secrets/.members
require valid-user
</LocationMatch>
The <LocationMatch regex> container determines that every location (Request-URI), which begins with
(^) the literal string "/application-name" where the application-name is the name of the ICEfaces
application, is part of the ICEfaces Member-Only Access realm, and therefore, requires basic
authentication for every user.
JBoss 4.0
Configuration Directory
default [jboss-install-dir]/server/default/deploy/jms/
all [jboss-install-dir]/server/all/deploy-hasingleton/jms/
Note: All information on JBoss 4.0 in this section is based on the compressed archive (zip
or gz) and not the JBoss installer application.
To configure the JMS topics, add the following code to the selected jbossmq-destinations-service.xml
file:
<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=icefaces.contextEventTopic">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
<depends optional-attribute-name="SecurityManager">
jboss.mq:service=SecurityManager
</depends>
<attribute name="SecurityConf">
<security>
<role name="guest" read="true" write="true" create="true"/>
</security>
</attribute>
</mbean>
<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=icefaces.responseTopic">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
<depends optional-attribute-name="SecurityManager">
jboss.mq:service=SecurityManager
</depends>
<attribute name="SecurityConf">
<security>
<role name="guest" read="true" write="true" create="true"/>
</security>
</attribute>
</mbean>
JkWorkersFile conf/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkMount /* myworker1
3. Create a new file called workers.properties in the same directory and add the following to it:
worker.list = myworker1
worker.myworker1.port = 8009
worker.myworker1.host = localhost
worker.myworker1.type = ajp13
worker.myworker1.lbfactor = 1
The ajp13 refers to a worker inside JBoss that listens to port 8009. This example shows both the
Apache HTTP Server and JBoss running on the same machine (hence, the localhost is the hostname
of myworker1), but it is recommended to run the Apache HTTP Server and JBoss instances on
separate machines.
4. The mod_jk.conf needs to be loaded. To achieve this, add the following to Apache's configuration
file right after the LoadModule directives:
Include conf/mod_jk.conf
5. Finally, the ProxyPass and ProxyPassReverse directives that route all requests other than blocking
requests to the application server, need to be removed from the Apache configuration file.
For more information on how to install and configure Apache Tomcat's plug-in, refer to the Server
Configuration Reference for Apache Tomcat 5.0.x and Apache Tomcat Configuration Reference for
Apache Tomcat 5.5.x which can be found at:
http://tomcat.apache.org/tomcat-5.0-doc/config/ajp.html
Note: The previous ProxyPass and ProxyPass Reverse directives must appear on a single
line in your configuration file.
Clustering
This section explains how to set up a clustered deployment of JBoss Application Servers. It includes
steps for configuring the cluster, JMS and web server. The following discussion relates to a clean
installation of JBoss, and represents a simplified process for configuring JBoss for clustered
deployments of ICEfaces applications. Additional deployment-specific issues may exist. Refer to your
JBoss documentation for additional information.
This example cluster consists of two servers (nodes) as shown in the table below.
JkWorkersFile conf/workers.properties
JkLogFile /var/log/httpd/mod_jk.log
JkLogLevel info
JkMount /* loadbalancer
2. The contents of the file worker.properties, created in step 3 of the previous Apache HTTP
Server 2.0.x section, should be changed to the following:
worker.list = loadbalancer
worker.node1.port = 8009
worker.node1.host = 192.168.1.100
worker.node1.type = ajp13
worker.node1.lbfactor = 1
worker.node2.port = 8009
worker.node2.host = 192.168.1.101
worker.node2.type = ajp13
worker.node2.lbfactor = 1
worker.loadbalancer.type = lb
worker.loadbalancer.balance_workers = node1, node2
worker.loadbalancer.sticky_session = 1
Note: With Apache HTTP Server 2.0.x as the front-end, a clustered deployment of the
Asynchronous HTTP Server is not supported. However, when the Asynchronous
HTTP Server is deployed to one node in the cluster, this version of Apache can be
used. All ICEfaces applications can still be deployed to the cluster on all nodes.
# The following two directives will route all other requests to the
# application server.
ProxyPass /application-name
balancer://application-name-application-server-cluster
stickysession=JSESSIONID lbmethod=bytraffic nofailover=On
ProxyPassReverse /application-name
balancer://application-name-application-server-cluster
Note: The previous ProxyPass and ProxyPass Reverse directives must appear on a single
line in your configuration file.
2. Additionally the balance members for each balancer need to be specified right after the ProxyPass
and ProxyPassReverse directives as follows:
<Proxy balancer://application-name-application-server-cluster>
BalancerMember ajp://192.168.1.100:8009/application-name route=node1
BalancerMember ajp://192.168.1.101:8009/application-name route=node2
</Proxy>
<Proxy balancer://application-name-async-http-server-cluster>
BalancerMember http://192.168.1.100:51315/application-name
/block/receive-updated-views
BalancerMember http://192.168.1.101:51315/application-name
/block/receive-updated-views
</Proxy>
3. In order to have load balancing support, the mod_proxy_balancer module is required. In the
Apache configuration file where all modules are being loaded, add the following if not already
added:
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
<IfModule mod_weblogic.c>
WebLogicHost host
WebLogicPort port
</IfModule>
<LocationMatch ^/application-name(?!/block/receive-updated-views)>
SetHandler weblogic-handler
</LocationMatch>
The LocationMatch container is responsible for forwarding all the requests to the ICEfaces
application deployed to WebLogic with the exception of the blocking requests. To explain the regular
expression used in the LocationMatch container, the following is a breakdown:
• ^/application-name
if the location begins with (^) the literal string "/application-name", where
application-name is the name of the ICEfaces application, and
• (?!/block/receive-updated-views)
is not followed by (?!) the literal string "/block/receive-updated-views".
This regular expression ensures that the following possible locations get handled by the plug-in:
• /application-name (initial request)
• /application-name/ (initial request)
• /application-name/xmlhttp/icefaces-d2d.js (part of initial request)
• /application-name/block/receive-send-updates?<query> (synchronous request)
• /application-name/block/send-updates?<query> (UI request)
But it prevents that the following possible location gets handled by the plug-in:
• /application-name/block/receive-updated-views?<query> (asynchronous request)
3. The mod_wl_20.conf file needs to be loaded. To achieve this, add the following to Apache's
configuration file right after the LoadModule directives:
Include conf/mod_wl_20.conf
4. Finally, the ProxyPass and ProxyPassReverse directives, which route all requests other than the
blocking requests to the application server, need to be removed from the Apache configuration file.
For more information on how to install and configure WebLogic's plug-ins, refer to BEA WebLogic
Server - Using Web Server Plug-Ins with WebLogic Server, which can be found at:
http://e-docs.bea.com/wls/docs81/pdf/plugins.pdf
Clustering
This section explains how to set up a clustered deployment of WebLogic Servers. It includes steps for
configuring the cluster, JMS and the web server. The following discussion relates to a clean installation
of WebLogic Server, and represents a simplified process for configuring WebLogic for clustered
deployments of ICEfaces applications. Additional deployment-specific issues may exist. Refer to your
WebLogic documentation for additional information.
This example cluster consists of two Managed Servers and an Administration Server, which itself is not
part of the cluster, as shown in the table below.
<IfModule mod_weblogic.c>
WebLogicCluster 192.168.1.101:7001,192.168.1.102:7001
</IfModule>
<LocationMatch ^/application-name(?!/block/receive-updated-views)>
SetHandler weblogic-handler
</LocationMatch>
This section assumes that you have a working installation of WAS 6.0.2, IBM HTTP Server (IHS), and
the Web Server Plug-In for WAS where you can successfully deploy web applications. For complete
details on installing and configuring WebSphere Application Server (WAS), see IBM's official
documentation for WAS 6.0.x at:
http://www.ibm.com/software/webservers/appserv/was/library/library60.html
There are several different JMS (Java Message Service) options available to run with WAS. The most
common solution and the simplest one to configure is the Default messaging provider based on the
System Integration Bus (SIB). To configure the JMS topics, follow these steps:
2. Ensure that the WebSphere plug-in module is loaded and that the plug-in configuration file is loaded
from the correct location. This information will depend on what platform you are running on as well
as the topology of your servers. Typically this will have been done already when you installed the
plug-in for IHS.
LoadModule was_ap20_module /opt/IBM/WebSphere/Plugins/bin/mod_was_ap20_http.so
WebSpherePluginConfig <path-to-plugin-config>/plugin-cfg.xml
3. Add the following lines to engage the rewrite engine and add a rewrite rule that redirects all
blocking requests to the Asynchronous HTTP Server. The [P] flag at the end tells Apache to forward
the re-written request to the Proxy directive. Replace the host:port entry with the host and port of
the Asynchronous HTTP Server (e.g., myhost.com:51315)
RewriteEngine on
RewriteRule ^/(.*)/block/receive-updated-views(.*)
http://host:port/block/receive-updated-views$2 [P]
Note: The RewriteRule directive must appear on a single line in your configuration file.
Note: The ProxyPass and ProxyPassReverse settings outlined in the Apache HTTP Server
section are not required when running with WAS.
<IfModule mod_proxy.c>
ProxyRequests On
ProxyVia Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
</IfModule>
Clustering
Note: In the steps that follow, node, cell, and host names must be modified as required
to match your environment.
cd /home/icesoft/WAS-ND-V6/WAS/
./install -options /home/icesoft/WAS-ND-V6/WAS/responsefile.nd.ice.txt -silent
The default location for the installed files varies by platform. On Linux, the standard location for the
installed files is /opt/IBM/WebSphere/AppServer.
When running on a standalone WAS server, you can take advantage of the built in database
(Cloudscape) that comes with WAS. For a messaging engine to work in a cluster, you must install
a separate database. This is solely a WebSphere clustering requirement as the JMS messaging used
by ICEfaces does not require the messages to be persisted. Out of the box, WAS supports a number
of common database configurations. To avoid problems with databases that are not officially
supported, we chose DB2.
cd /opt/IBM/WebSphere/AppServer/profiles/managedServer2/bin/
./addNode.sh admin.com
At this point, the Deployment Manager should be running as well as the node agents on the managed
servers so you can centrally administrate the individual servers from the Deployment Manager console.
Using the console, we create a cluster and add application server instances to the newly created cluster.
Create a DataSource
1. In the tree on the left panel, navigate to Resources > JDBC Providers.
2. Make sure you are creating the resource in the proper scope (cluster). To set the scope of the
resource definition to cluster:
a. Click Browse Clusters.
b. Click the radio button beside the correct cluster then click OK.
3. Click New.
4. For the General Properties, select the items that apply to your environment. For ours, we chose:
Step 1: Select the database type -> DB2
Step 2: Select the provider type -> DB2 Universal JDBC Driver Provider
Step 3: Select the implementation type -> Connection pool data source
5. Click Next.
6. With DB2, the default settings on this page should be sufficient. If you are using another database,
you may need to adjust one or more of the entries. The Class path and Native library path values
can use environment variables. Ensure that the variables are properly set. They can be found by
navigating to Environment -> WebSphere Variables.
7. When you have made all the necessary adjustments, click Apply.
8. Under Additional Properties, click the Data sources link.
9. Click New.
10. Adjust the General Properties:
a. Under Component-managed authentication alias, choose the security alias you created in the
previous section (e.g., deployMgrNode/db2Alias).
b. Provide the database name that you created in the Install the Database section.
c. Provide the host name (or IP address) of the server that the database is running on.
Note: Make a note of the JNDI name as you will need this information later.
With DB2, the default is something like jdbc/DB2 Universal Driver Provider.
11. Provide the port number on which the database is configured to accept remote connections.
12. Click OK.
13. A Messages box at the top of the screen will prompt you to save your changes to the master
configuration. Click the Save link.
14. In the next panel, click Save. When it is done saving, click OK.
15. Test the configuration using the Test Connection button.
Now we can create the bus and add the cluster to it. We'll be going through some of the same steps
as in the non-clustered configuration.
5. Select the Service Integration Bus (e.g., ClusterBus) you created previously by choosing it from the
drop-down list under Bus name.
6. Click OK.
7. To add one more topic, repeat steps 3 – 5 using the value icefaces.responseTopic in place of
icefaces.contextEventTopic for all the values in step 4.
8. A Messages box at the top of the screen will prompt you to save your changes to the master
configuration. Click the Save link.
9. In the next panel, click Save. When it is done saving, click OK.
JMS should now be properly configured to support ICEfaces applications running with the Asynchronous
Server.
Deploying
Once the cluster is fully configured, you can deploy your ICEfaces application. Ensure you review
Deploying the Asynchronous HTTP Server, p. 3, and Configuring the ICEfaces Application,
p. 5, before deploying your own application. As outlined in those sections, you'll need to configure the
context-param named com.icesoft.util.net.messaging.properties in the web.xml file of both the async-
http-server.war and your application war. For running in clustered mode in WebSphere, the parameter
should be set to websphere_ha.properties.
Using the Administration console, deploying to a cluster is the same process as deploying to a single,
standalone node.
A P
architecture 1 ProxyPass 7
Enterprise Production Suite 2 ProxyPassReverse 7
Asynchronous HTTP Server, deploying 3
authentication 7
S
C Secure Sockets Layer 8
security 7
clustering 11, 15, 22 SSL. See Secure Sockets Layer.
configuration files, JBoss 9
configuration property files 4
configuring W
ICEfaces 5
JMS 9, 12, 14 web server plug-ins 10, 12, 14, 18, 20
configuring a web server 5 WebLogic Server 8.1 14
WebSphere Application Server 6.0.2 19
D
deployment architecture 1
I
ICEfaces configuration 5
J
JBoss 4.0 9
JMS
configuration 9, 12, 14
JMS Provider, configuring 4