A wiki is a collection of web pages designed to enable anyone who accesses it to contribute or modify content, using a simplified markup language. Wikis are often used to create collaborative websites and to power community websites. For example, the collaborative encyclopedia Wikipedia is one of the best known wikis. This is a wiki about IBM WebSphere. If you are interested in, please consider to register and collaborate. If you are a registered user just login to edit contents.

Thank you, Gianfrancesco Bertucci

IBM WebSphere Application Server (WAS) functions as Web middleware, it provides a framework for a link between the HTTP requests and the business data. WAS is available on a wide range of platforms and in multiple packages to meet specific business needs. The application server is the key component of WAS, providing the runtime environment for applications. Clients access these applications through standard interfaces and APIs. The applications have access to a wide variety of external sources such as back-end systems, databases, Web services, and messaging resources that can be used to process the client requests.

WAS is based on the concept of cells, nodes, and servers. While all of these elements are present in each configuration, cells and nodes do not play an important role until you take advantage of the features provided with Network Deployment. The application server is the primary runtime component in all configurations and is where an application executes. All WebSphere Application Server configurations can have one or more application servers. In the Express and Base configurations, each application server functions as a separate entity. There is no workload distribution or central administration among application servers. With Network Deployment, you can build a distributed server environment consisting of multiple application servers maintained from a central administration point. In a distributed server environment, you can cluster application servers for workload distribution.

WAS supports asynchronous messaging through the use of a JMS provider and its related messaging system. It is suitable for messaging among application servers and for providing messaging capability between WebSphere Application Server and an existing WebSphere MQ backbone.

WAS provides authentication and authorization capabilities to secure administrative functions and applications, including the operating system user registry, LDAP registry (for example, IBM Tivoli® Directory Server), custom registries, file-based registries, or federated repositories. In addition to the default authentication and authorization capabilities, you have the option of using an external Java Authorization Contract for Containers (JACC)-compliant authorization provider for application security. The IBM Tivoli Access Manager client embedded in WebSphere Application Server is JACC-compliant and can be used to secure your WebSphere Application Server-managed resources. This client technology is designed to be used with the Tivoli Access Manager server (shipped with Network Deployment).

WebSphere Application Server Network Deployment includes the Caching Proxy and Load Balancer Edge Components for use in highly available, high volume environments. Using Edge components can reduce Web server congestion, increase content availability, and improve Web server performance.

Runtime environments are built by creating profiles. Each profile contains files specific to that runtime such as logs and configuration files. Profiles can be created during or after installation, or both. After creating the profiles, use the WebSphere administrative tools for further configuration and administration. Each profile is stored in a unique directory path selected at profile creation time. The default is for the profiles to be stored in a subdirectory of the installation directory, but they can be located anywhere. All profiles share the product binaries.

All packages support a single stand-alone server environment. With a stand-alone configuration, each application server acts as a unique entity. An application server runs one or more J2EE applications and provides the services required to run those applications. Each stand-alone server is created by defining an application server profile. Multiple stand-alone application servers can exist on a machine, either through independent installations of the WebSphere Application Server code or by creating multiple application server profiles within one installation. However, WebSphere Application Server does not provide centralized management or administration for multiple stand-alone application servers. Stand-alone application servers do not provide workload management or failover capabilities.

With Network Deployment, you can build a distributed server configuration to enable central administration, workload management, and failover. In this environment, you integrate one or more application servers into a cell that is managed by a deployment manager. The application servers can reside on the same machine as the deployment manager or on multiple separate machines. Administration and management is handled centrally from the administration interfaces by the deployment manager.

With a distributed server configuration, you can create multiple application servers to run unique sets of applications and then manage those applications from a central location. However, more importantly, you can cluster application servers to allow for workload management and failover capabilities. Applications that you install in the cluster are replicated across the application servers. When one server fails, another server in the cluster continues processing. Workload is distributed among Web and EJB containers in a cluster using a weighted round-robin scheme.

A distributed server configuration can be created in one of three ways:

• Create a deployment manager profile to define the deployment manager. Then, create one or more custom node profiles. The nodes defined by each custom profile can be federated into the cell managed by the deployment manager during profile creation or later manually. The custom nodes can exist on the deployment manager machine or on multiple separate machines. Application servers can then be created using the administrative tools, for example, the administrative console. The method is useful when you will be creating multiple nodes, multiple application servers on a node, or clusters.

• Create a deployment manager profile to define the deployment manager. Then, create one or more application server profiles and federate these profiles into the cell managed by the deployment manager. This process adds both nodes and application servers into the cell. The application server profiles can exist on the deployment manager machine or on multiple separate machines. This method is useful in development or small configurations. Creating an application server profile gives you the option of having the sample applications installed on the server. When you federate the server and node to the cell, any installed applications can be carried into the cell with the server.

• Create a cell profile. This actually creates two profiles, a deployment manager profile and a federated application server profile. Both reside on the same machine. This is useful in a development or test environment.

The administrative console and wsadmin are the two ways that the environment is administered. However, take note that these tools talk to the deployment manager and NOT to the application servers directly. The communication of these commands flows from the tools to the deployment manager to the node agents, to the application servers. This allows administration of multiple nodes (each possibly containing multiple application servers) from a single focal point (the deployment manager).

There is ONE main repository for the configuration files within a cell, and those are associated with the deployment manager. All updates to the configuration files should go through the deployment manager. You should be very careful in connecting to an application server directly with wsadmin or the administrative console as any changes that are made to the configuration files are only temporary, they will be overwritten with the configuration files from the MASTER files.

Deployment manager contains the master configuration, Node agents synchronize their files with the master copy (automatically and/or manually). During synchronization node agent asks for changes to master configuration and new or updated files are copied to the node.

A cell is a grouping of nodes into a single administrative domain. In the Base and Express configurations, a cell contains one node and that node contains one server. In a distributed server configuration, a cell can consist of multiple nodes, which are all administered from a single point (the deployment manager). The configuration and application files for all nodes in the cell are centralized into a master configuration repository. This centralized repository is managed by the deployment manager and synchronized with local copies that are held on each of the nodes. It is possible to have a cell made up of nodes on mixed platforms. This is referred to as a heterogeneous cell.

A node is a grouping of application servers. Each node is managed by a single node agent process. Nodes are generally associated with a physical machine. It is possible to have multiple nodes on a single machine but nodes cannot span machines. In a stand-alone application server configuration, there is only one node. With Network Deployment, you can configure a distributed server environment consisting of multiple nodes that are managed from one central administration server. In distributed server configurations, each node has a node agent that works with the deployment manager to manage administration processes. The node agent is created when you add (federate) a stand-alone node to a cell. The node agent is a very important process that allows for communication of administrative information (commands and configuration files) to reach the applications servers. A node group is a grouping of nodes within a cell that have similar capabilities.

A managed node is a node that contains a node agent, an unmanaged node is a node in the cell without a node agent (enables the rest of the environment to be aware of the node, useful for defining HTTP servers as part of the topology)

The deployment manager (DMgr) process manages the node agents. Holds the configuration repository for the entire management domain, called a cell and application files. Within a cell, the administrative console runs inside the DMgr. The administrative console and wsadmin are still the two ways that the environment is administered. However, take note that these tools now talk to the deployment manager and NOT to the application servers directly.

With Network Deployment, you can use application server clustering to enhance workload distribution. A cluster is a logical collection of application server processes that provides workload balancing and high availability.

Application servers that belong to a cluster are members of that cluster and must all have identical application components deployed on them. Other than the applications configured to run on them, cluster members do not have to share any other configuration data. For example, one cluster member might be running on a large multiprocessor server while another member of that same cluster might be running on a small mobile computer. The server configuration settings for each of these two cluster members is very different, except in the area of the application components that are assigned to them. In that area of configuration, they are identical.

The members of a cluster can be located on a single node (vertical cluster), across multiple nodes (horizontal cluster), or on a combination of the two. A cluster can span machine and can span across operating systems with one exception. A cluster cannot span z/OS and non-z/OS platforms. When you install, update, or delete an application, the updates are automatically distributed to all members in the cluster. A rollout update option enables you to update and restart the application servers on each node, one node at a time, providing continuous availability of the application.

A cell can have zero or more clusters and all cluster members that are part of the cluster must belong to the same cell. Network Deployment is required for clustering. All cluster members can reside on the same machine. This topology is known as vertical scaling. Cluster members can also be spread across different machines. In this topology, each machine has a node in the cell holding a cluster member. This topology is known as horizontal scaling.

The figure on the rigth shows a cluster that has four cluster members. Those cluster members belong to two different nodes (but they still serve the same J2EE application). On each node, there is also an application server that is in the same cell but is not part of the cluster (not a cluster member). Therefore, not all the application servers in the node have to be part of the cluster.

Creation of a cluster:

• Can use an existing server to become the first cluster member.
• Additional cluster members are created from templates

Network Deployment enables you to build distributed server environments consisting of multiple application servers maintained from a central administrative point. Application servers can be clustered for workload management and high availability.

• Single cell configurations: A cell in a distributed server environment is a network of multiple nodes. Each node can contain one or more application servers. The cell contains one deployment manager that manages the nodes and servers in the cell. A node agent in the node is the contact point for the deployment manager during cell administration.

• Multiple cells configurations: Several nodes can be created on a machine. Those nodes can belong to the same cell or spread across multiple cells. Additionally, these cells can reside entirely within one server or be sprayed among two or more servers.

* Mixed node versions in a cell: WebSphere Application Server V6.1, V6, and V5 nodes can be part of the same cell. This requires that the deployment manager be at V6.1. You can upgrade a portion of the nodes in a cell, while leaving others at the earlier release level. Therefore, you might be managing servers that are running multiple release levels in the same cell.

In this section, we discuss how WebSphere processes execute in runtime. The executable processes include deployment managers, node agents, and the application server. Cells, nodes, and clusters are administrative concepts and not executable components.

On distributed platforms, WebSphere Application Server is built using a single process model where the entire server runs on a single Java virtual machine (JVM™) process. Each process appears as a Java process. For example, when you start a deployment manager on Windows, a java.exe process will be visible in the Windows Task Manager. Starting a node agent starts a second java.exe process,and each application server started will be seen as a java.exe process.

To find the processes on an AIX 5L or Linux system, use the following command: ps -ef | grep java

You can install WebSphere Application Server several times on the same machine in different directories. Those installations are independent from each other. This configuration facilitates fix management. If a fix is applied on a particular installation, it only affects that specific WebSphere Application Server installation, leaving the remaining installations on that machine unaffected.

When you have a single installation of WebSphere Application Server, you can create multiple application server profiles. In this case, all profiles share the same product binaries. When fixes are installed, they affect all profiles. Each profile has its own user data.

The same logic holds true for Network Deployment installations. You can install the product several times on the same machine (multiple installs), each one for administering different cells. Or, you can install Network Deployment once and then create multiple profiles so that each profile is used to administer a different cell.

The WebSphere Application Server installation process simply lays down a set of core product files required for the run time processes. After installation, you need to create one or more profiles that define the run time to have a functional system. The core product files are shared among the run time components defined by these profiles.

With Base and Express, you can only have stand-alone application servers. Each application server is defined within a single cell and node. The administration console is hosted within the application server and can only connect to that application server. No central management of multiple application servers is possible. An application server profile defines this environment. You can also create stand-alone application servers with the Network Deployment package with the future intent of federating that server into a cell for central management.

With the Network Deployment package, you have the option of defining multiple application servers with central management capabilities. The administration domain is the cell, consisting of one or more nodes. Each node contains one or more application servers and a node agent that provides an administration point management by the deployment manager.

The launchpad application is available on the product CD and on downloaded installation images. The launchpad is the recommended method of installing components that are on the product CD. It represents a single point of reference for installing the entire application server environment. Welcome page contains fastpath links to launch installation wizard for installable components:

• WebSphere Application Server Network Deployment
• IBM HTTP Server
• Web server plug-ins
• WebSphere Application Server Clients
• Application Server Toolkit ¹⁾

The launchpad can install the tools component in the primary packet of discs. The launchpad on the separate Application Server Toolkit disc can launch the installation of the tool on Windows and Linux (Intel) systems.

Launchpad:

• Checks prerequisites
• Looks for a previous WebSphere Application Server installation for adding features or installing new binaries
• Looks for a previous V6.x installation to upgrade
• Prompts you to start profile creation wizard

Make sure TCP/IP networking is correctly configured:

• Host name of node should be in DNS or local hosts file
• Host name of node should remain fixed
• DHCP not supported

Uninstall is dependent on the InstallShield Multi Platform (ISMP) uninstaller. It is located in the WebSphere directory tree under the _uninst directory. Always use the uninstaller to remove WebSphere components. Cannot custom uninstall parts of WebSphere installation. All the components are removed. Silent uninstallation is supported.

Occurs after WebSphere Application Server is installed and an application server profile is configured.

1. System applications
   • adminconsole
   • filetransfer
2. Other Applications
   • Default application
   • Installation verification test (Ivt)
   • Query
   • Samples

Notes: A system application is a J2EE enterprise application that is central to a WebSphere Application Server product. Because a system application is an important part of a WebSphere Application Server product, a system application is deployed when the product is installed and is updated only through a product fix or upgrade. System applications are not shown in the list of installed applications on the console Enterprise Applications page, or through wsadmin and Java application programming interfaces, to prevent users from accidentally stopping, updating or removing the system applications.

The Profile Management Tool lets you create a deployment manager profile, an application server profile, or a custom profile. A profile consists of files that define the runtime environment. Each environment has its own administrative interface. A custom profile is an exception. A custom profile is an empty node that you can federate into a deployment manager cell and customize. No default server processes or applications are created for a custom profile. Each deployment manager or application server profile has its own First steps console. The location of the command to launch the First steps console is within the set of files in the profile.

Be careful when using the Profile Management Tool. It is possible that it will preload a default host name by adding the default DNS suffix to the short machine name. This can cause problems if other profiles used only the short host name. It does not matter which form is used (shortname or fully qualified name), as long as the name is used consistently.

The manageprofiles script can:

• Create a new stand-alone application server profile (manageprofiles –create -profileName -profilePath -templatePath -nodeName -cellName - hostname)
• List all profiles (manageprofiles –listProfiles)
• Delete a profile (manageprofiles –delete –profileName)

Example 1 shows how to create a Deployment Manager profile with security enabled and specifying the starting port number (50000) for generating and assigning all ports for the profile. Port values are assigned sequentially from the -startingPort value, omitting those ports that are already in use. The system recognizes and resolves ports that are currently in use and determines the port assignments to avoid port conflicts.

Note: Do not use the -startingPort parameter if you are using the managed profile template.

Example 2 shows how to create an Application Server profile (with name profile01) specifying the starting port number (50200) for generating and assigning all ports for the profile. Port values are assigned sequentially from the -startingPort value, omitting those ports that are already in use. The system recognizes and resolves ports that are currently in use and determines the port assignments to avoid port conflicts.

After creating the two profiles above you can federate the Application Server to the Deployment Manager from the DM Admin Console using the addNode function and specifying the nodeagent starting port number (eg 50100).

On the Deployment Manager Admin Console go to System administration → Nodes, then click on Add Node and select Managed Node then next.

You'll se a page with a form like the one on the image below. The standalone Application Server process must be running in order to federate it to the DM Cell. The JMX connector port field must be filled with the SOAP port of the Application Server you want to federate.

If security is enabled at the node you are adding or at the Deployment Manager, you must put username and password, then include application/buses and then define the starting port of the nodeagent.

Otherwise instead of the Add Node from the Deployment Manager Admin Console it's possible to use the script addNode.sh from the bin directory of the profile you want to federate.

See the command syntax:

addNode dmgr_host [dmgr_port] [-profileName profilename]
[-conntype type] [-includeapps] [-startingport portnumber]
[-portprops qualified_filename] [-nodeagentshortname name]
[-nodegroupname name] [-includebuses name]
[-registerservice] [-serviceusername name] [-servicepassword password]
[-coregroupname name] [-noagent] [-statusport port] [-quiet] [-nowait]
[-logfile filename] [-replacelog] [-trace] [-username uid]
[-password pwd] [-localusername localuid]
[-localpassword localpwd] [-help]

Example 3 shows how to federate the Application Server to the Deployment Manager cell. srv01 is the dmgr_host, 5003 is the Deployment Manager SOAP connection port, 50100 is the nodeagent starting port.

• Application Server Profile: Create different instances of a stand-alone node, each stand-alone node has 1 application server. Cell directory is overwritten upon federation.

• Deployment Manager Profile: Create different instances of DMgr, each DMgr has its onw cell.

• Custom Profile: Creates a managed node which, by default, is federated into a cell. Creates a node agent, but no application servers.

• Cell Profile: Creates both a deployment manager and a federated node.

Suppose to work on a WAS 6.1 ND with tons of application servers.

• First of all stop the Deployment Manager
• Download this zip file or if you don't trust in me, download the file from IBM Technical library
• Copy all unzipped files into the bin directory of the DM Profile
• Open a unix/dos shell and go to the bin dir said before.
• Execute the script:

ws_ant.sh changeServerName -buildfile exportImport.xml -logfile changeServer.log -DoldServerName=server1 -DnewServerName=server2 -DnodeName=NodeName

The script will change the Application Server name from server1 to server2, writing the changeServer.log file

• From the WAS Admin Console, select Servers → Clusters and click New

When you install WebSphere Application Server, the default instance is created with the default port values. When you create a WebSphere Application Server instance with the manageprofiles ⁵⁾ script, you can specify different port values.

You can perform one of the following actions to change port settings after installation:

• Use the updatePorts.ant script to change port settings
• Use wsadmin scripting tool to change the values.

Each profile template has its own updatePorts.ant script.

The updatePorts.ant script for application server profiles is in the app_server_root/profileTemplates/template_name/actions directory. To use the script, you have to identify which profile to update. To avoid trouble you should only run this script if the profile is unfederated and if the configuration is the same structure as it was when the profile was created. For example, this script is ideal for changing ports for an unfederated application server profile after you created the profile but before you altered its configuration.

For all other situations, use the wsadmin scripting tool to modify the serverindex.xml.

PS Execute wsadmin.[sh/bat] from bin directory of AS profile.

Example 4 shows how to modify the BOOTSTRAP_ADDRESS attribute of an application server when security is enabled.

Version 6.1 port numbers

Table - Port definitions for WebSphere Application Server Version 6.1

To see more tables look here

Tools in bin directory

• versionInfo: displays installed product versions
• startServer: starts a server
• stopServer: stops a server
• serverStatus: displays server status

WebSphere commands are profile aware. There is a -profileName option on many WebSphere V6.x commands or you can issue the commands from the appropriate <profile_root>\<profile>\bin directory. If no profile is used, the default profile is assumed (can be only one default profile).

Examples:

• # ./startServer.sh server1 -profileName profile1
• # ./startManager -profileName DMgr
• # ./stopServer server1 (assumes default profile)

The backupConfig command is a utility to back up the configuration of your profile to a file. When the backupConfig commands runs it first stops the application server before creating the backup file. To run the utility enter:

# ./backupConfig.sh 

from <profile_root>/profile_name/bin directory. As the backup process starts, the administrator is asked for a user ID and password if administrative security is enabled. The command creates a backup file called WebSphereConfig_<date>.zip using the current date and place it in the <profile_root>\profile1\bin directory.

To restore the configuration directory structure at a later time you can use the restoreConfig command from <profile_root>/profile_name/bin directory . You will need to specify the name of the backup file that was created after running the backupConfig command.

The command restores the entire <profile_root>/<profilename>/config directory.

# ./restoreConfig.sh /some_path/WebSphereConfig_<date>.zip

Note: By default, all servers on the node are stopped before the backup is made so that partially synchronized information is not saved. The -nostop option tells the command not to stop the servers before backing up the configuration.

A number of log files are created during the installation and profile creation process. It is useful to check these files to verify that the installation completed successfully:

• Before starting the migration procedure using the command line tools, it is important to track down the names of all nodes in the V5 or V6 cell, in addition to the cell name. These values are used when creating V6.1 profiles for each node in the cell.
• Backup your WebSphere Application Server environments before attempting any migration.
• Leave your previous version of WebSphere Application Server intact. This helps to enables the rollback of the environment to the previous version, if desired or necessary.

• The installation process for V6.1 has changed from the process used in V5. One important change is that migration has been decoupled from the installer. A Migration wizard (for distributed operating systems only) will guide you through the migration after you have installed V6.1
• When creating a profile for migrating from a previous release, certain values must match between the previous version and the new version. Specifically, when migrating a deployment manager to V6.1, the cell name value of the V6.1 profile must match the cell name from V5 or V6; when migrating to a V6.1 federated node, the node name of the V6.1 profile must match the node name from the previous version’s federated node, and so on.
• For a Network Deployment migration, profiles must be migrated in this specific sequence: Deployment Manager profile, Custom profile, Application server profile.
• A profile does not need to exist prior to running the Migration wizard. However, if you plan to use the migration command line tools, then you will need to create profiles for your environment.

• Launch FirstSteps from the profile directory.
• Select Migration wizard to begin the migration process.
• After the Welcome panel displays, select the prior version of WebSphere Application Server you want to migrate from a list of detected versions. It is important that you make sure the location of the previous version is correct by verifying the location displayed in the Installation root directory of the previous version field. If the previous version you want to migrate is not detected by the wizard, use this field to specify its location after first checking Specify the installation location if your existing product is not listed.
• Select which profile in the previous version you want to migrate (For V6, you can select which profile you want to migrate, but remember that the deployment manager must always be migrated before the federated nodes).
• If you have defined one or more profile, such as a V6.1 deployment manager and a V6.1 node profile on the same system, you must select the profile to be used as your target profile (Figure 5). If you have not already created a V6.1 profile, the Migration wizard can create one for you if you select <Create new profile>.

WebSphere V6 DMgr can manage external Web servers:

• IBM HTTP Server V6 (IHS) ⁷⁾: No node agent needed, Deployment manager can distribute plugin-cfg.xml files to Web server machines, can be started and stopped, can edit the httpd.conf, the DMgr communicates with the IBM HTTP Server admin process that runs on the node with the IBM HTTP Server server.
• Other Web servers: Node agent needed or not, can have plugin-cfg.xml files automatically distributed to them, can be started and stopped, node agent receives commands from DMgr to administer the Web server, Plugin-cfg.xml file is propagated through the file synchronization service and lives under the config directory.

Managed nodes use a node agent to control the Web server. Unmanaged nodes use the IBM HTTP Server Admin Service instead of node agent to control the Web server.

On WAS 6.1 there is no Web-based console for IBM HTTP Server as there was in previous versions. You must either manually make updates to the httpd.conf file, or use the WebSphere administrative console.

Allows WebSphere system administrator to create custom plug-in files for a specific Web Server and manually ftp/copy the plug-in configuration file from the DMgr machine to the Web server. Web server is registered as unmanaged node in WebSphere configuration. This scenario is common for Web servers installed outside your firewall or in a DMZ where no WebSphere Application Server exists. The implication with this scenario is that all management of the Web server has to happen manually (outside the control of WebSphere) and there is no way to start and stop the Web server from with the WebSphere administration tools.

WebSphere V6 and IBM HTTP Server have special enhancements. IHS admin process provides administrative functions for IBM HTTP Server within WebSphere. Provides ability to start, stop IBM HTTP Server, make configuration changes to httpd.conf and automatically push the plug-in configuration file to IBM HTTP Server machine. Does not need node agent on the Web server machine. IBM HTTP Server can be managed completely from the Deployment Manager (DMgr). The DMgr communicates with the IBM HTTP Server admin process that runs on the node with the IBM HTTP Server server.

Note: On UNIX platforms the userid under which the IHS admin process runs must have write permissions to the plugin-cfg.xml file. By default, at IBM HTTP Server installation, the plugin-config.xml file is owned by root, and only root has write access to it. This will cause a failure with propagation of the plugin-cfg.xml file when run from the administration tools.

The previous user interface to administer IBM HTTP Server no longer exists. You must either manually make updates to the httpd.conf file, or use the WebSphere administrative console.

• IBM HTTP Server (IHS) administration server runs as a separate instance of IBM HTTP Server.
• IHS admin configuration file is admin.conf
• The default port for the IHS admin server is 8008.
• IHS admin authentication password file (admin.passwd) is initially blank, which prohibits access to IBM HTTP Server administration.

To update IBM HTTP Server admin password file:

# htpasswd -cm ..\conf\admin.passwd <user_name>

To start and stop the administration server:

# <ihs_root>/bin/adminctl start/stop

Install a Web server on a managed node, Create a Web server definition within the DMgr, Node agent receives commands from DMgr to administer the Web server, Plugin-cfg.xml file is propagated through the file synchronization service and lives under the config directory. The Web server is managed via the deployment manager through the node agent. This provides ability to start, stop the Web server and automatically push the plug-in configuration file to the Web server from the DMgr.

This can be used when the Web server is on the same machine where WebSphere Application Server is installed. This is a common scenario for behind a firewall where a WebSphere node can be installed. It may be undesirable to use this configuration, since access to the node agent in a DMZ could compromise security.

The Web server plug-in allows the Web server to route requests to the application server even when they are physically separated. It uses an XML configuration file (plugin-cfg.xml) that contains settings that describe how to handle and pass on requests to the WebSphere Application Server(s). Be aware that in this case, the plugin-cfg.xml configuration file is generated on the machine where the application server is installed so it has to be moved, each time it is regenerated, from the machine where the application server resides to the machine where the Web server and the plug-in module are installed.

Plug-in is a separate installation. Typical plug-in installation action are: Installs the plug-in binaries for the Web server & Updates the Web server configuration file (Specifies the loading of the plug-in module, Specifies the location of plug-in configuration file: plugin-cfg.xml).

To use a Web server other than IBM HTTP Server Version 6.1, install and configure the Web server before or after installing the WebSphere Application Server product, but before installing the Web server plug-ins for WebSphere Application Server. After installing the Web server and the Application Server, install the appropriate Web server plug-in for a supported, installed Web server. No further configuration is required for most Web servers.

Web server definitions are created to allow the mapping of J2EE enterprise applications to specific Web servers. Mapping the applications to specific Web servers will cause the custom plugin-cfg.xml files for only those Web servers to include the information for those applications. It can be done through the administrative console or using the script generated during the installation of the plug-in:

configure<Web_server_name>.sh in <plugin_root>\bin.

Just as modules for an enterprise application need to be mapped to one or more application servers, they also need to be mapped to one or more Web servers. plugin-cfg.xml files can be generic to a cell (using the command line script <was_root>\bin\GenPluginCfg.sh) or custom to Web server (using the administrative console, need to map applications to Web servers, can customize each Web server’s plug-in settings). plugin-cfg.xml files are automatically generated and propagated. This behavior is the default, but can be changed.

Invoke the WebSphere Application Server Launchpad. On the Welcome panel click Launch the installation wizard for IBM HTTP Server. You'll be asked to define the ports of the HTTP Server: http and http administration port, (default values are 80 and 8008).

After a while a user ID and password can be configured for the HTTP Administration Server authentication. This ID is used later to allow the WebSphere Application Server to administratively control the HTTP server (user and encrypted password are stored on conf/admin.passwd file).

On UNIX systems you'll be asked to create a local operating system user and Group ID that will be used to run the IHS administration server and own the plug-in configuration files.

Select both Setup IBM HTTP administration server to administer IBM HTTP Server and Create a unique user ID and group for IBM HTTP Server administration.

Next step allows the WebSphere plug-in to be installed silently after the HTTP server installation. In order to do this, the Web server definition and application server host name need to be specified.

Now it's time to start IHS processes: From a command line enter ps -ef | grep httpd. If no httpd processes are running navigate to <ihs_root>/bin and execute

# ./apachectl start

then start the administrative server using the command

# ./adminctl start

Check the status of the IBM HTTP Server using a browser and writing: http://localhost

One of the other important functions that the plug-in provides, in addition to failover and workload management, is the ability to manage HTTP sessions.

In many Web applications, users move through the site based on a series of selections on pages they visit. Where the user goes next, and what the application displays as the user's next page (or next choice) may depend on what the user has chosen previously from the site.

In order to do this, a Web application needs a mechanism to hold the user's state information over a period of time. However, HTTP alone does not recognize or maintain a user's state. HTTP treats each user request as a discrete, independent and stateless interaction.

The Java servlet specification proposes a mechanism for servlet applications to maintain a user’s state information across multiple user hits. This mechanism, known as a session, allows a Web application developer to maintain all user state information at the host, while exchanging only minimal information with a user’s HTTP browser (mostly only session identification data).

Since the Servlet 2.3 specification, as implemented by WebSphere Application Server V5.0 and higher, only a single cluster member may control/access a given session at a time. After a session has been created, all following requests need to go to the same application server that created the session. This session affinity is provided by the plug-in.

If this application server is unavailable when the plug-in attempts to connect to it, the plug-in will choose another cluster member and attempt a connection. Once a connection to a cluster member is successful, the session manager will decide what to do with the session. The cluster member will find that it does not have the session cached locally and thus will create a new session.

To avoid the creation of a new session, a distributed session can be used to access sessions from other application servers.

There are two mechanisms to configure distributed sessions in WebSphere Application Server V6:

• Database persistence (Session state is persisted to a database shared between the clustered application servers)
• Memory-to-memory replication, based on DRS (Data Replication Services), a feature that has been much simplified in WebSphere Application Server V6. It provides in-memory replication of session state between clustered application servers.

In a clustered environment, there is more than one application server that can serve the client request. Therefore, the plug-in needs to read a request and be able to identify which cluster member should handle it.

Session identifiers are used to do this; they allow the plug-in to pick the correct cluster member and the Web container to retrieve the current session object.

There are three methods of identifying a user’s session to the application server. They are: Cookies, URL rewriting or SSL ID. This is a setting that can also be configured at the application server level, at the enterprise application level or at the Web module level.

Session configuration settings are found in the Administrative Console in several different places. You need to set the General Properties for session management first, then you define the Distributed environment settings.

In the General Properties configuration you define settings such as the Session tracking mechanism (Cookies, URL rewriting or SSL ID) and the Session timeout. In WebSphere Application Server V6, session management can be defined at the following levels:

• Application server level

This is the default level. Session management configuration at this level is applied to all Web modules within the server. On WAS 6.0 to define session management at the this level, select:

Servers → Application servers → <AppServer_Name> → Web Container Settings → Session management.

Otherwise on WAS 6.1 go to:

Servers → Application servers → <AppServer_Name> → Session management

• Application level

Configuration at this level is applied to all Web modules within the application. To override the inherited configuration (from the application server level) select:

Applications → Enterprise Applications → <Application_Name> → Session management

and check the Override session management option and click Apply.

• Web module level

Configuration at this level is applied only to the Web module. To override the inherited configuration (from the Application level), select:

Applications → Enterprise Applications → <Application_Name> → Web modules → <Module _Name> → Session Management,

check the Override session management option and click Apply.

The Distributed session settings define whether to use a database or memory-to-memory replication (the default is not to use distributed sessions) as well as tuning parameters (the write frequency). Distributed sessions are also configured for the same three levels (Server, Application and Web module) as the General Properties.

This section describes how the plug-in routes requests to the correct Web containers and how the plug-in is configured. Understanding how the plug-in makes these decisions is key to understanding how WebSphere workload manages Web requests.

Users asks for the page http://url_webserver:port/snoop from their browser. The request is routed to the Web server over the Internet.

• The Web server immediately passes the request to the plug-in. All requests go to the plug-in first.
• The plug-in then starts by looking at all Route definitions in the plugin-cfg.xml. For each Route, it searches through its configuration to find if there is any match to the virtual host url_webserver:port and URI /snoop. If it finds the first match then it decides that WebSphere will handle the request. If there is no match, WebSphere will not handle the request.
  The plug-in takes the request and separates the host name and port pair and URI. It starts by looking at all the defined Routes. It gets a Route and then searches for a virtual host match to url_webserver1 and port in that Route. It matches that host name and port in the VirtualHost block.
  The plug-in then tries to match the URI /snoop in the current Route. It searches its configuration for a URI mapping that matches the requested URI in the UriGroup block.
• Once the VirtualHostGroup and UriGroup are found, it sets a score depending on the number of characters in the URI and virtual host.
• The plug-in continues to the next Route and searches through virtual hosts and URI’s setting scores for matches with any URI and virtual host match. The Route that has the highest score is chosen and the ServerCluster is set.
• The plug-in now checks the request to see if any session identification has been passed to the server.
• The plug-in chooses a cluster member to manage the request.
• A server is chosen to handle the request. If there is a session identifier and a CloneID associated with it, the plug-in will choose a server based on the CloneID.
• This cluster member has two transports associated with it: HTTP and HTTPS are defined. Because this request is HTTP, the cluster member uses the HTTP transport definition.
• A stream is a persistent connection to the Web container. Since HTTP 1.1 is used for persistent connections between the plug-in and Web container, it is possible to maintain a connection (stream) over a number of requests. In our example, no previous connection has been created from the plug-in to the Web container, so a new stream is created. However, if a stream is already established, the plug-in uses the existing stream.
• The request is sent to the cluster member and successfully processed. The plug-in passes the response on to the Web server, which in turn passes it back to the user’s browser.

Perform the following steps to configure IBM HTTP Server for SSL:

• Open the httpd.conf file, which is the configuration file for IBM HTTP Server. You find the file under the <IHS_root>\conf directory
• Add the ibm_ssl_module definition to the end of the LoadModule list.

 LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

• Create a virtual host, then enable and configure SSL just for this virtual host.

SSLDisable
Listen 0.0.0.0:443

<VirtualHost webserver01.azz.net:443>
SSLEnable
KeyFile "C:/IBM/HTTPServer/conf/keys/IHS6Certificates.kdb"
</VirtualHost>

This is the most basic SSL setup, but there are other SSL directives that you can use to set the SSL configuration more specifically to your requirements.

• The directives that this book uses for configuration are explained here:
  • The directive Listen 0.0.0.0:443, which is placed into global definition scope, makes the IBM HTTP Server listen on port 443 as well.
  • The directive VirtualHost starts the virtual host stanza. Make sure you specify a TCP resolvable hostname or Internet Protocol (IP) here.
  • The directive SSLEnable enables SSL for this virtual host only.
  • The directive KeyFile defines where the key database file is located.

WebSphere Application Server Network Deployment package contains the following Edge Component functionality:

• Load balancer
• Caching proxy

Load balancer is responsible for balancing the load across multiple servers, Caching proxy’s purpose is to reduce network congestion.

Load balancing is performed at the Web server plug-in level based on a round-robin algorithm and with consideration of session state.

The Load Balancer, part of the WebSphere Edge Components, can be configured to create a cluster of Web servers and add it to a cluster of application servers. Load balancing products can be used to distribute HTTP requests among Web servers that are running on multiple physical machines.

The Dispatcher component of Load Balancer is an IP sprayer that performs intelligent load balancing among Web servers based on server availability and workload capacity as the main selection criteria to distribute the requests.

The Load Balancer Node sprays Web client requests to the Web servers. The Load Balancer is configured in cascade. The primary Load Balancer communicates to his backup (in standby status) through a heartbeat to perform failover, if needed, and thus eliminates the Load Balancer Node as a single point of failure. Both Web servers perform load balancing and failover between the application servers (cluster members) through the Web server plug-in.

WebSphere Application Server ND V6.1 on z/OS is implemented as a set of started tasks. Some of the processes initiated by these tasks are exclusive to the z/OS platform. Next figure shows a diagram of WebSphere Application Server Network Deployment (ND) V6.1 and an SDSF (the z/OS process viewer) screen capture of a running environment. When you log on to the z/OS environment, you can interact with the system via a command line interface (TSO), a panel interface (ISPF), and via UNIX System Services interfaces.

However not all z/OS resources are accessible via UNIX System Services, so becoming familiar with TSO and ISPF is important. Most z/OS systems have a logon profile that takes you to the ISPF panels after logon. If you do not see the z/OS Primary Option Menu, enter “ISPF” from the TSO interface and press the Enter key.

We are now in search of the SDSF panel to display the started tasks. SDSF is the interface to see the running processes, similar to issuing a ps –ef command in a UNIX environment except that SDSF will also show you finished processes. the z/OS administrator can customize the ISPF panel hierarchy, so the SDSF panel in your z/OS system may not be exactly where we show it in this article. When you have a logon to the z/OS system you should explore the different option hierarchies in your ISPF menus. In our system the SDSF panel is off option 13, then in the z/OS Applications panel (Figure 3) off option 14. Rather than navigating across two panels, when you know where different applications are found in your ISPF environment you can also take a short cut and enter =13.14 from the Command prompt or the Option prompt of any ISPF panel.

You could now enter the DA command in the COMMAND INPUT prompt to see the started tasks, however, you may have to look through several processes before locating the WebSphere Application Server V6.1 started tasks. Since the names of the WebSphere Application Server started tasks for this implementation begin with the characters A5, you can enter the pre A5* filter command in the COMMAND INPUT prompt. This filter tells SDSF to only look for started tasks with names beginning with A5. You can now enter the DA command in the COMMAND INPUT

Resource providers are a class of objects that provide resources needed by running Java applications, and J2EE applications in particular. For example, if an application requires database access through a data source, you would need to install a JDBC data source provider and then configure a data source to be used by your application.

Application server resource providers:

• JDBC resources
• JCA resources
• JavaMail resources
• URL providers
• Resource environment providers
• Resource authentication

The JDBC API provides a programming interface for data access of relational databases from the Java programming language. JDBC is the recommended way of getting a connection to a database, and the only way if you are looking to use connection pooling and distributed transactions.

The following database platforms are supported for JDBC: DB2 family, Oracle, Sybase, Informix, SQL Server, Cloudscape / Derby (test and development only).

A data source represents a real-world data source, such as a relational database. When a data source object has been registered with a JNDI naming service, an application can retrieve it from the naming service and use it to make a connection to the data source it represents. Once a data source has been registered with an application server’s JNDI name space, application programmers can use it to make a connection to the data source it represents.

When installing an application that contains modules with JDBC resource references, the resources defined by the deployment descriptor of the module need to be bound to the JNDI name of the resources.

The connection will usually be a pooled connection. In other words, once the application closes the connection, the connection is returned to a connection pool, rather than being destroyed.

When an application uses a data source, the data source uses the JCA connector architecture to get to the relational database.

The following steps are involved in creating a data source: Create a JDBC provider and Create a data source. The JDBC provider gives the classpath of the data source implementation class and the supporting classes for database connectivity. This is vendor-specific. The JDBC data source encapsulates the database-specific connection settings.

The link to connection pooling settings is found in the Additional Properties section of the data source configuration window.

• Connection Timeout

Specify the interval, in seconds, after which a connection request times out and a ConnectionWaitTimeoutException is thrown. This can occur when the pool is at its maximum (Max Connections) and all of the connections are in use by other applications for the duration of the wait.

For example, if Connection Timeout is set to 300 and the maximum number of connections is reached, the Pool Manager waits for 300 seconds for an available physical connection. If a physical connection is not available within this time, the Pool Manager throws a ConnectionWaitTimeoutException.

Tip: If Connection Timeout is set to 0, the pool manager waits as long as necessary until a connection is allocated.

• Max Connections

Specify the maximum number of physical connections that can be created in this pool. These are the physical connections to the back-end database. Once this number is reached, no new physical connections are created and the requester waits until a physical connection that is currently in use is returned to the pool, or a ConnectionWaitTimeoutException is thrown.

For example, if Max Connections is set to 5, and there are five physical connections in use, the Pool Manager waits for the amount of time specified in Connection Timeout for a physical connection to become free. If, after that time, there are still no free connections, the Pool Manager throws a ConnectionWaitTimeoutException to the application.

• Min Connections

Specify the minimum number of physical connections to be maintained. Until this number is reached, the pool maintenance thread does not discard any physical connections. However, no attempt is made to bring the number of connections up to this number. For example, if Min Connections is set to 3, and one physical connection is created, that connection is not discarded by the Unused Timeout thread. By the same token, the thread does not automatically create two additional physical connections to reach the Min Connections setting.

• Reap Time

Specify the interval, in seconds, between runs of the pool maintenance thread. For example, if Reap Time is set to 60, the pool maintenance thread runs every 60 seconds. The Reap Time interval affects the accuracy of the Unused Timeout and Aged Timeout settings. The smaller the interval you set, the greater the accuracy. When the pool maintenance thread runs, it discards any connections that have been unused for longer than the time value specified in Unused Timeout, until it reaches the number of connections specified in Min Connections. The pool maintenance thread also discards any connections that remain active longer than the time value specified in Aged Timeout.

The Reap Time interval also affects performance. Smaller intervals mean that the pool maintenance thread runs more often and degrades performance.

• Unused Timeout

Specify the interval in seconds after which an unused or idle connection is discarded. For example, if the unused timeout value is set to 120, and the pool maintenance thread is enabled (Reap Time is not 0), any physical connection that remains unused for two minutes is discarded.

Tip: Set the Unused Timeout value higher than the Reap Timeout value for optimal performance. Unused physical connections are only discarded if the current number of connections not in use exceeds the Min Connections setting.

• Aged Timeout

Specify the interval in seconds before a physical connection is discarded, regardless of recent usage activity. Setting Aged Timeout to 0 allows active physical connections to remain in the pool indefinitely. For example, if the Aged Timeout value is set to 1200, and the Reap Time value is not 0, any physical connection that remains in existence for 1200 seconds (20 minutes) is discarded from the pool. Note that accuracy of this timeout, as well as performance, is affected by the Reap Time value.

Tip: Set the Aged Timeout value higher than the Reap Timeout value for optimal performance

• Purge Policy

Specify how to purge connections when a stale connection or fatal connection error is detected. Valid values are EntirePool and FailingConnectionOnly. If you choose EntirePool, all physical connections in the pool are destroyed when a stale connection is detected. If you choose FailingConnectionOnly, the pool attempts to destroy only the stale connection. The other connections remain in the pool.

IBM® WebSphere® Application Server V6 provides implementation and support for the new J2EE™ Connector Architecture (JCA) specification V1.5 as part of the J2EE 1.4 platform. Issues that are caused by JCA components or JCA connection configuration errors can appear as one or more of the following initial symptoms:

• A JDBC call returns incorrect data to the application
• An application cannot connect to or access a database or EIS
• WebSphere error messages with the prefixes DSRA, WSCL, J2CA, WTRN, CONM, or SQLException or with database error codes

The JCA specification provides a standard mechanism that allows modern J2EE applications to connect and use heterogeneous resources from various existing enterprise information systems (EIS) as well as modern relational database systems.

JCA involves four main components:

• Application server
• Application component
• Resource adapter
• EIS

Based on the JCA specification, an EIS vendor can develop a standard resource adapter (RA) for its EIS to plug into any application sever that supports JCA. A resource adapter runs within the address space of an application server, while the EIS itself runs in a separate address space. For example, a DB2 database (EIS) and WebSphere Application Server each run in a separate machine. An application component is able to access the EIS through the resource adapter.

The relationships between the four major components can be described as follows:

• The connections between the application component and the resource adapter are provided through some form of client API. The client API can either be specific to a particular type of resource adapter, for example JDBC for relational data base, or a standard common client interface (CCI). The JCA recommends, but does not require, that a resource adapter implement the CCI. WebSphere Application Server V6 provides a relational resource adapter (RRA) that has an implementation for both the CCI and the traditional JDBC interfaces.

• The resource adapter and application server implement system contracts to provide the common mechanisms for connection, transaction, and security management.

• The Connections between the resource adapter and the EIS are specific to each EIS. Thus, JCA does not impose any requirement on this proprietary relationship. For example, an RRA for a relational database accesses the resources through a JDBC driver that is supported by the database.

WebSphere MQ is the most popular system for messaging across multiple platforms, including Windows, Linux, IBM mainframe and Unix. WebSphere MQ is available on a large number of platforms and operating systems. It offers a fast, robust, and scalable messaging solution that assures once, and once only, delivery of messages to queue destinations that are hosted by queue managers.

WebSphere Application Server supports asynchronous messaging based on the Java Message Service (JMS) programming interface and the use of a JMS provider and its related messaging system. WebSphere MQ and WebSphere Application Server messaging are complementary technologies that are tightly integrated to provide for various messaging topologies.

The WebSphere MQ JMS provider is the JMS API implementation with WebSphere MQ (with queue managers, for example) implementing the real destinations for the JMS interface. WebSphere MQ can coexist on the same host as a WebSphere Application Server V6 messaging engine.

There are two parts to message queueing:

• Messages are collections of binary or character (for instance ASCII or EBCDIC) data that have some meaning to a participating program. As in other communications protocols, storage, routing, and delivery information is added to the message before transmission and stripped from the message prior to delivery to the receiving application.

• Message queues are objects that store messages in an application.

A Queue Manager is a Websphere MQ pre-requisite and system service that provides a logical container for the message queue and is responsible for transferring data to other queue managers via message channels.

Don’t forget that on WebSphere MQ for z/OS, queue-manager names are limited to 4 characters.

After an update to the initial installation, the version indicates the service level to which the product has been updated. Prior to applying any service the version is 6.0.0.0. As service is applied the last two digits will be updated, for example to 6.0.0.1 or 6.0.2.1. To view the version, do one of the following:

* Use the dspmqver command. At a command prompt, enter the following command: dspmqver. The resulting messages include the WebSphere® MQ version number, which shows the service level.

• Locate the file Readme in the appropriate language subfolder of the WebSphere MQ program files folder (default c:\Program Files\IBM\WebSphere MQ\PTF), then open it using a suitable text editor. The file contains the service level and details of the maintenance applied.

In any cluster you need to nominate at least one queue manager, or preferably two, to hold full repositories.

On each queue manager that is to hold a full repository, you need to alter the queue-manager definition, using the ALTER QMGR command and specifying the REPOS attribute:

ALTER QMGR REPOS(INVENTORY)

On every queue manager in a cluster you need to define a cluster-receiver channel on which the queue manager can receive messages. This definition defines the queue manager’s connection name and the CLUSTER keyword has the effect of advertising the queue manager’s availability to receive messages from other queue managers in the cluster. The queue manager’s connection name is stored in the repositories, where other queue managers can refer to it

DEFINE CHANNEL(TO.CATANZARO) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME(CATANZARO.CHSTORE.COM) CLUSTER(INVENTORY) DESCR(’TCP Cluster-receiver channel for queue manager CATANZARO’)

In this example the channel name is TO.CATANZARO, and the connection name (CONNAME) is the network address of the machine the queue manager resides on, which is CATANZARO.CHSTORE.COM. (The network address can be entered either as an alphanumeric DNS hostname, or as a dotted-decimal IP address.) Do not allow the CONNAME to specify a generic name.

On every queue manager in a cluster you need to define one cluster-sender channel on which the queue manager can send messages to one of the full repository queue managers. In this case there are only two queue managers, both of which hold full repositories. They must each have a CLUSSDR definition that points to the CLUSRCVR channel defined at the other queue manager. Note that the channel names given on the CLUSSDR definitions must match those on the corresponding CLUSRCVR definitions.

DEFINE CHANNEL(TO.ROME) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME(ROME.CHSTORE.COM) CLUSTER(INVENTORY) DESCR(’TCP Cluster-sender channel from CATANZARO to repository at ROME’)

Define the INVENTQ queue on the ROME queue manager, specifying the CLUSTER keyword.

DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)

From the ROME queue manager, issue the command:

dis clusqmgr(*)

To install Websphere MQ on Solaris, first of all, create the WebSphere MQ group, mqm, with the groupadd command: groupadd mqm
Then create the WebSphere MQ user account, mqm, with the useradd command: useradd -g mqm mqm⁸⁾
The WebSphere MQ software is normally installed in mqm subdirectories of the /WebSphere_MQ_inst_home⁹⁾ and /var directories.
To install WebSphere MQ in the /WebSphere_MQ_inst_home and /var directories on Solaris:

pkgadd -d /mq_cd/mq_solaris

where mq_cd is the mount point of the WebSphere MQ CD

Thank you!

— Gianfrancesco Bertucci