TOC PREV NEXT INDEX













WebSphere Application Server 6.0.2

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:

Login to the Admin Console
1. From your web browser, login to the WAS console (for example, http://localhost:9060/ibm/console/). By default there is no security so you should be able to login using any name.
Create the Service Integration Bus
1. In the tree on the left panel, navigate to Service Integration > Buses.
2. Click New.
3. Enter the information for the Bus. You will need to provide a name (e.g,. ICEfacesBus). To make the initial configuration easier, you may also want to turn off security by de-selecting the Secure check box. You can enable security later once you have everything running.
4. A Messages box at the top of the screen will prompt you to save your changes to the master configuration. Click the Save link.
5. In the next panel, click Save. When it is done saving, click OK.
Add the JMS Topic Connection Factory
1. In the tree on the left panel, navigate to Resources > JMS Providers > Default messaging.
2. In the Default messaging provider Configuration panel, under Connection Factories, click the JMS topic connection factory link.
3. Click New.
4. Supply the following information for the connection factory:
Name=ConnectionFactory
JNDI name=jms/ConnectionFactory
5. Select the Service Integration Bus you created previously by choosing it from the drop-down list under Bus name.
6. A Messages box at the top of the screen will prompt you to save your changes to the master configuration. Click the Save link.
7. In the next panel, click Save. When it is done saving, click OK.
Add the JMS Topics
1. In the tree on the left panel, navigate to Resources > JMS Providers > Default messaging.
2. In the Default messaging provider Configuration panel, under Connection Factories, click the JMS topic link.
3. Click New.
4. Supply the following information for the topic:
Name=icefaces.contextEventTopic
JNDI name=jms/icefaces.contextEventTopic
Topic name=icefaces.contextEventTopic
5. Select the Service Integration Bus you created previously by choosing it from the drop-down list under Bus name.
6. To add one more topic, repeat steps 3 and 4 using the value "icefaces.responseTopic" for the Name in step 4.
7. A Messages box at the top of the screen will prompt you to save your changes to the master configuration. Click the Save link.
8. 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.

Web Server and Web Server Plug-Ins

IBM provides an option to install and use a custom version of the Apache web server, known as IBM HTTP Server (IHS). It also provides a custom Apache plug-in to support efficient communication between IHS and WAS. Although WAS can run with a standalone Apache configuration as well, the IBM HTTP Server provides tighter administrative integration with WAS. Official documentation for IHS 6.0.x can be found at:

http://www.ibm.com/software/webservers/httpservers/library/

To get ICEfaces with Asynchronous HTTP Server working with IHS and WAS requires that we include additional configuration information to IHS.

You can modify the IHS configuration in one of two ways. You can use the WAS administration application or you can modify it manually. The default location of the configuration file varies by platform so you'll need to consult the documentation to determine where it is. On Linux, the default installation location of the web server's configuration file is /opt/IBMIHS/conf/httpd.conf. Whether you do it manually or use the administration tool, you'll need to modify the configuration file in the following way:

1. Ensure that the rewrite and proxy modules are loaded. If they are commented out, uncomment them.
LoadModule proxy_module modules/mod_proxy.so
 
LoadModule rewrite_module modules/mod_rewrite.so
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.
4. Enable the proxy.
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>
Deploying ICEfaces Applications

Once WebSphere is fully configured, you can deploy your ICEfaces application. Ensure you review Deploying the Asynchronous HTTP Server and Configuring the ICEfaces Application before deploying your own application. As outlined in those sections, you will 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 non-clustered mode in WebSphere, the parameter should be set to websphere.properties.

You can deploy the Asynchronous Server (async-http-server.war) and your application separately via the Administration console. However, since we have more than one piece to deploy, it is more convenient to use an .ear file that contains all the necessary pieces of your application (which could also include other things like EJBs).

Clustering
Installing and Configuring the Cluster

You can run ICEfaces applications in a WebSphere Application Server Network Deployment (WAS ND) 6.0.2 cluster. Installing and configuring a WAS ND cluster can be somewhat daunting in that there are a number of different cluster architectures to choose from and a great deal of documentation to wade through. Given that, ICEsoft is providing this high-level summary of what we did to get our test cluster up and running. This summary is in no way intended to replace the official IBM documentation. To keep things simple, we do not include any security configuration. You'll need to adjust to suit your own security policies.

For our example, we're going to assume our cluster consists of four machines running in the following clustered architecture. You can run with fewer machines and with different configurations to suit your available resources.
IP Address
Server Name
Description
192.168.1.100
admin
Administration Server,
IBM HTTP Server (IHS), and WebSphere Plug-Ins
192.168.1.101
managed1
Managed Application Server
192.168.1.102
managed2
Managed Application Server
192.168.1.103
database
DB2 Server

The following instructions assume:

Note: In the steps that follow, node, cell, and host names must be modified as required to match your environment.
Install the Core WAS Files
1. Install the Core WAS ND files on the admin, managed1, and managed2 nodes. You can use the supplied GUI installer or shell script. Refer to IBM's documentation on running the installer of your choice. For example, on our machines we used the script and a custom response file to do the installation:
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.
Install the Database
1. Using the documentation provided by the vendor, install and start a database instance on the database node.
2. Configure a name/password that has enough privileges to create a schema and tables. Note the database name, user name, and password as you will need them later.
Create the Profiles
1. On the admin server, create a Deployment Manager profile:
cd /opt/IBM/WebSphere/AppServer/bin
 

 
./wasprofile.sh -create -profileName deployMgrProfile -profilePath 
/opt/IBM/WebSphere/AppServer/profiles/deployMgr -templatePath 
/opt/IBM/WebSphere/AppServer/profileTemplates/dmgr -nodeName adminNode -cellName 
mgrCell -hostName admin.com
2. Start the Deployment Manager:
cd /opt/IBM/WebSphere/AppServer/profiles/deployMgr/bin/
 
./startManager.sh
3. On the managed1 server, create a Managed Server profile:
cd /opt/IBM/WebSphere/AppServer/bin
 
./wasprofile.sh -create -profileName managedServer1 -profilePath 
/opt/IBM/WebSphere/AppServer/profiles/managedServer1 -templatePath 
/opt/IBM/WebSphere/AppServer/profileTemplates/managed -nodeName managedNode1 -
cellName managed1Cell -hostName managed1.com -dmgrHost admin.com
4. Federate and start the node:
cd /opt/IBM/WebSphere/AppServer/profiles/managedServer1/bin/
 
./addNode.sh admin.com
5. Create the same type of profile on the managed2 server:
cd /opt/IBM/WebSphere/AppServer/bin
 
./wasprofile.sh -create -profileName managedServer2 -profilePath 
/opt/IBM/WebSphere/AppServer/profiles/managedServer2 -templatePath 
/opt/IBM/WebSphere/AppServer/profileTemplates/managed -nodeName managedNode2 -
cellName managed2Cell -hostName managed2.com -dmgrHost admin.com
6. Federate and start the node:
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.

Login to the Admin Console
1. From your web browser, login to the WAS console (for example, http://localhost:9060/ibm/console/). By default there is no security so you should be able to log in using any name.
Create the Cluster and Server Instances
1. Create a new cluster and add managed server instances to the managed nodes:
a. In the tree on the left panel, navigate to Servers Clusters.
b. Click New.
c. Enter the information for the Cluster. You will need to provide a name (e.g., IceCluster) in the Cluster name field. Click Next.
d. On the Create cluster members page, enter managed1Member into the Member name field and select the managed1Node from the Select node list, and then click Apply. This creates a new application server instance for this cluster.
e. Enter managed2Member into the Member name field and select the managed2Node from the Select node list, and then click Apply. This creates another server instance in the other node and includes it in this cluster.
f. Click Next.
g. Click Finish.
2. A Messages box at the top of the screen will prompt you to save your changes to the master configuration. Click the Save link.
3. In the next panel, click Save.
Create a Security Alias
1. In the tree on the left panel, navigate to Security > Global security.
2. Under Authentication, click JAAS Configuration to expand the tree.
3. Click on J2C Authentication data.
4. Click New.
5. Enter an alias for the security configuration, and then supply the user name and password required to access the database.
6. Click OK.
7. Click the Save link near the top of the page.
8. Ensure that Synchronize changes with Nodes is checked, and then click Save.
9. When the changes have finished synchronizing, click OK.
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.

Create the Service Integration Bus
1. In the tree on the left panel, navigate to Service Integration > Buses.
2. Click New.
3. Enter the information for the Bus. You will need to provide a name (e.g., ClusterBus). To make the initial configuration easier, you may also want to turn off security by de-selecting the Secure check box. You can enable security later once you have everything running.
4. Click OK.
5. A Messages box at the top of the screen will prompt you to save your changes to the master configuration. Click the Save link.
6. In the next panel, click Save. When it is done saving, click OK.
Add the Cluster to the Service Integration Bus (SIB)
1. In the tree on the left panel, navigate to Service Integration > Buses.
2. Click on the bus that you created.
3. Under the topology heading, click Bus members.
4. Click Add.
5. Select the Cluster radio button and choose the cluster you created from the list.
6. Enter the JNDI name of the data source you created earlier. For example, the one we created was:
jdbc/DB2 Universal JDBC Driver DataSource
7. Click Next and then click Finish.
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.

Adding the cluster to the SIB automatically creates a bus-wide messaging engine. We need to ensure that the general properties are set correctly for the messaging engine to use the database.

Adjust the Messaging Engine Properties
1. In the tree on the left panel, navigate to Service Integration > Buses.
2. Click on the bus you created (e.g., ClusterBus).
3. Under Topology, click Messaging engines.
4. Click the name of the messaging engine. This name is generated and will look like clusterName.000-busName.
5. Under Additional Properties, click the Data store link.
6. Set the Authentication alias to the security alias we created earlier.
7. Adjust the Schema value so that it matches your database configuration.
8. Ensure the Create tables check box is enabled.
9. Click OK.
10. A Messages box at the top of the screen will prompt you to save your changes to the master configuration. Click the Save link.
11. In the next panel, click Save. When it is done saving, click OK.
Add the JMS Topic Connection Factory
1. In the tree on the left panel, navigate to Resources > JMS Providers > Default messaging.
2. In the Default messaging provider Configuration panel, under Connection Factories, click the JMS topic connection factory link.
3. 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.
4. Click New.
5. Supply the following information for the connection factory:
Name=ConnectionFactory
JNDI name=jms/ConnectionFactory
6. Select the Service Integration Bus (e.g., ClusterBus) you created previously by choosing it from the drop-down list under Bus name.
7. Click OK.
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.
Add the JMS Topics
1. In the tree on the left panel, navigate to Resources > JMS Providers > Default messaging.
2. In the Default messaging provider Configuration panel, under Destinations, click the JMS topic link.
3. Click New.
4. Supply the following information for the topic:
Name=icefaces.contextEventTopic
JNDI name=jms/icefaces.contextEventTopic
Topic name=icefaces.contextEventTopic
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.

Web Server and Web Server Plug-Ins

ICEfaces supports running applications in a WebSphere cluster. However, due to the way the WebSphere plug-in works, it is not currently possible to run multiple Asynchronous Servers for load-balancing and fail-over purposes. Instead, you'll have a single active Asynchronous Server designated to handle all the asynchronous request traffic. So the configuration of the web server and the web server plug-ins is the same as it is for non-clustered WebSphere installations (see Web Server and Web Server Plug-Ins).

Deploying

Once the cluster is fully configured, you can deploy your ICEfaces application. Ensure you review Deploying the Asynchronous HTTP Server and Configuring the ICEfaces Application 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.


Copyright 2005-2007. ICEsoft Technologies, Inc.
http://www.icesoft.com
TOC PREV NEXT INDEX