Differences

This shows you the differences between two versions of the page.

--- start [2010/02/18 09:50]
+++ start [2010/09/03 11:54] (current)
frank
@@ Line 1: / Line 1: @@
+====== IBM WebSphere Wiki ======
+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//
+[[http://www.linkedin.com/in/bertuccig|{{:btn_viewmy_160x25.gif}}]]
+====== IBM WebSphere Application Server (WAS) ======
+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. {{was.png |IBM Websphere}}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.
+===== Stand-alone application servers =====
+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.
+===== Distributed application servers =====
+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.
+{{ 01.jpg|One cell - Three Server}}
+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.
+===== File synchronization =====
+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.
+===== Cells =====
+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.
+===== Nodes, node groups, and node agents =====
+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.
+===== Application server clusters =====
+\\
+\\
+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.
+{{ 04.jpg|Cluster and cluster member}}
+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__**
+===== Distributed server environments =====
+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. {{ 02.jpg|One cell - One Server}}
+  * //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.
+===== Runtime processes =====
+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''
+===== WAS Installation =====
+\\
+\\
+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.
+{{ 05.jpg|Stand-alone server installation options}}
+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.
+==== Launchpad ====
+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 ((only available on Linux and Windows))
+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
+==== Pre-Installation tasks ====
+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 ====
+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.
+==== Applications installed during installation ====
+Occurs after WebSphere Application Server is installed and an application server profile is configured.
+  - System applications
+    * adminconsole
+    * filetransfer
+  - 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.
+===== Managing Profiles  6.0.x =====
+<box 100% red left round| **WAS 6.0.x Profiles Tools**>
+\\
+Profiles should be managed through one of the tools provided:
+\\
+\\
+  * ''Profile Creation tool (**PCT**)'' : The Profile Creation Wizard is an InstallShield for Multiplatforms (ISMP) application and represents the graphical user interface of the PCT: ''**<was_root>/bin/ProfileCreator/pct.sh**''. The file name of the command that calls the Profile creation wizard varies per operating system platform.
+  * ''wasprofile'' script: Command line interface for profile management functions: ''**<was_root>/bin/wasprofile.sh**''. When creating a profile using ''wasprofile'', you need to specify one of the following templates: //default// (for application server profiles), //dmgr// (for deployment manager profiles), //managed// (for custom nodes), //cell// (for cell profiles). You must use the ''wasprofile'' command to delete a profile, for instance, because the Profile Creation Wizard does not provide a deletion function.
+The ''wasprofile'' command creates a log for every profile that it creates. The logs are in the ''**<was_root>/logs/wasprofile**'' directory. The files are named in this pattern: ''profile_name_create.log''
+</box>
+<box 50% blue left round| **Create new profiles**>
+''\\  #./wasprofile.sh -create
+\\ \\
+              -profileName profile_name \\ \\
+              -profilePath fully_qualified_profile_path \\ \\
+              -templatePath template_path \\ \\
+              -nodeName node_name \\ \\
+              -cellName cell_name \\ \\
+              -hostName host_name \\ \\
+             [-isDefault] \\ \\
+             [-startingPort starting_port | -portsFile file_path] \\ \\
+             [-debug]
+''
+</box>
+===== Managing Profiles  6.1.x =====
+<box 100% left round| **WebSphere Application Server files are split into two categories:**>
+\\
+  * //Product files//: Set of read-only static files or product binaries shared by any instances of the WebSphere Application Server product
+  * //Configuration files//: Profiles, set of user-customizable data files, files include: WebSphere configuration, installed applications, resource adapters, properties, log files.
+\\
+Profiles are sets of files that represent a WebSphere Application Server configuration. Profiles are the way that you are allowed to run more than one application server on a single installation of WebSphere product files. Benefits of profiles: Each profile uses the same product files, Simpler than multiple WebSphere installations, Less disk space, Simplifies application of product updates.
+__The //list of profiles// and their properties__ can be found in: ''**<was_root>/properties/profileregistry.xml**''
+Additional properties, such as //log levels//, can be found in: ''**<was_root>/properties/wasprofile.properties**''
+__Information about the profile__, including the ''<profile_root>'', the profile name, the node and host names, and a number of the ports with which it was configured can be found in: ''**<profile_root>/profileX/logs/AboutThisProfile.txt**''
+\\
+</box>
+<box 100% left round| **WAS 6.1.x Profiles Tools**>
+\\
+Profiles should be managed through one of the tools provided:
+\\
+\\
+  * ''Profile Management tool (**PMT**) Wizard'' : Eclipse-based GUI tool for creating profiles: ''**<was_root>/bin/ProfileManagement/pmt.sh**'' ((Replaces v6.0 Profile Creation Tool))
+  * ''manageprofiles'' script: Command line interface for profile management functions: ''**<was_root>/bin/manageprofiles.sh**''. ((V6.0 ''wasprofile'' command line tool has been enhanced and renamed to manageprofiles script in V6.1)) When creating a profile using manageprofiles, you need to specify one of the following templates: //default// (for application server profiles), //dmgr// (for deployment manager profiles), //managed// (for custom nodes), //cell// (for cell profiles).
+</box>
+\\
+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'')
+<box 54% left round red| **Example 1 - Create a Deployment Manager profile with manageprofile.sh**>
+\\
+''manageprofiles.sh -create
+\\ \\ -profileName Dmgr01
+\\ \\ -profilePath /opt/IBM/WebSphere61/AppServer/profiles/Dmgr01
+\\ \\ -templatePath /opt/IBM/WebSphere61/AppServer/profileTemplates/dmgr
+\\ \\ -nodeName srv01Node01
+\\ \\ -cellName srv01Cell01
+\\ \\ -hostname srv01
+\\ \\ -adminUserName wasadmin
+\\ \\ -adminPassword wasadmin
+\\ \\ -enableAdminSecurity true
+\\ \\ -isDefault
+\\ \\ -startingPort 50000
+\\ \\ -validatePorts
+\\ \\
+''
+</box>
+\\
+''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.
+\\
+<box 65% left round red| **Example 2 - Create an Application Server profile with manageprofile.sh**>
+\\
+''manageprofiles.sh -create
+\\ \\ -profileName profile01
+\\ \\ -profilePath /opt/IBM/WebSphere61/AppServer/profiles/profile01
+\\ \\ -templatePath /opt/IBM/WebSphere61/AppServer/profileTemplates/default
+\\ \\ -nodeName srv01Node02
+\\ \\ -cellName -srv01Cell02
+\\ \\ -hostname srv01
+\\ \\ -serverName server1
+\\ \\ -startingPort 50200*
+\\ \\ -validatePorts*
+\\ \\ [* or -portsFile /opt/IBM/WebSphere61/AppServer/portdef.props ((example of portdef.props:
+\\ WC_defaulthost=19080
+\\ WC_adminhost=19060
+\\ WC_defaulthost_secure=19443
+\\ WC_adminhost_secure=19043
+\\ BOOTSTRAP_ADDRESS=19810
+\\ SOAP_CONNECTOR_ADDRESS=18880
+\\ SAS_SSL_SERVERAUTH_LISTENER_ADDRESS=19401
+\\ CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS=19403
+\\ CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS=19402
+\\ ORB_LISTENER_ADDRESS=19100
+\\ DCS_UNICAST_ADDRESS=19353
+\\ SIB_ENDPOINT_ADDRESS=17276
+\\ SIB_ENDPOINT_SECURE_ADDRESS=17286
+\\ SIB_MQ_ENDPOINT_ADDRESS=15558
+\\ SIB_MQ_ENDPOINT_SECURE_ADDRESS=15578
+\\ SIP_DEFAULTHOST=15060
+\\ SIP_DEFAULTHOST_SECURE=15061
+))]
+\\ \\
+''
+</box>
+\\
+{{ 12.png|Add Managed Node}}
+\\
+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]
+''
+\\
+<box 100% left round red| **Example 3 - Federate Application Server Node to Deployemnt Manager cell**>
+\\
+''addNode.sh srv01 50003 -profileName profile01 -conntype SOAP -includeapps -startingport 50100''
+\\ \\
+</box>
+\\
+\\
+''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.
+\\
+===WebSphere Network Deployment profiles ===
+  * //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.
+\\
+\\
+===== Change Application Server name =====
+Suppose to work on a WAS 6.1 ND with tons of application servers.
+  * First of all stop the Deployment Manager
+  * Download [[http://bertucci.org/ConfigScripts.zip|this zip file]] or if you don't trust in me, download the file from  [[http://www.ibm.com/developerworks/websphere/library/samples/SampleScripts.html#download|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 ''server''1 to ''server2'', writing the ''changeServer.log'' file
+\\
+\\
+\\
+===== Creating a cluster =====
+  * From the WAS Admin Console, select //Servers// -> //Clusters// and click **New**
+\\
+\\
+\\
+===== WAS Ports =====
+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'' ((wasprofile for was 6.0)) 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''.
+<box 100% left round red | **Example 4 - Modifying port numbers in the serverindex.xml file with wsadmin tool**>
+''wsadmin.sh -lang jython \\ -username //your_username// -password //your_password// \\ -c "AdminTask.modifyServerPort ('//your_servername//', '[-nodeName //your_nodename// -endPointName BOOTSTRAP_ADDRESS -host //your_hostname// -port //your_new_port//]')"''
+</box>
+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.
+\\
+==== Port number settings in WebSphere Application Server ====
+**''Version 6.1 port numbers''**
+^  :2  Port name  ^  Default Value  ^^  :2 Files  ^
+^  Application Server  ^  Deployment Manager  ^
+|  Administrative Console Port (WC_adminhost)  |  9060  |  9060  |  :4 ''serverindex.xml'' and ''virtualhosts.xml''  |
+|  Administrative Console Secure Port (WC_adminhost_secure)  |  9043  |  9043  |
+|  HTTP_Transport Port (WC_defaulthost)  |  9080  |  9080  |
+|  HTTPS Transport Secure Port (WC_defaulthost_secure)  |  9443  |  9443  |
+|  Bootstrap Port (BOOTSTRAP_ADDRESS)  |  2809  |  9809  |  :21 ''serverindex.xml''  |
+|  Cell Discovery Address (CELL_DISCOVERY_ADDRESS)  |  Not applicable  |  7277  |
+|  CSIV2 Server Authentication Listener Port (CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS)  |  9403  |  9403  |
+|  CSIV2 Client Authentication Listener Port (CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS)  |  9402  |  9402  |
+|  DRS_CLIENT_ADDRESS ((Deprecation: This port is deprecated and is no longer used in the current version of WebSphere Application Server))  |  7873  |  7989  |
+|  High Availability Manager Communication Port (DCS_UNICAST_ADDRESS)  |  9353  |  9352  |
+|  Internal JMS Server Port (JMSSERVER_SECURITY_PORT)  |  5557  |  Not applicable  |
+|  MQ Transport Port (SIB_MQ_ENDPOINT_ADDRESS)  |  5558  |  Not applicable  |
+|  MQ Transport Secure Port (SIB_MQ_ENDPOINT_SECURE_ADDRESS)  |  5578  |  Not applicable  |
+|  Node Discovery Address (NODE_ DISCOVERY_ADDRESS)  |  Not applicable  |  Not applicable  |
+|  Node IPV6 Discovery Address (NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS)  |  Not applicable  |  Not applicable  |
+|  Node Multicast Discovery Address (NODE_MULTICAST_DISCOVERY_ADDRESS)  |  Not applicable  |  Not applicable  |
+|  ORB Listener Port (ORB_LISTENER_ADDRESS)  |  9100  |  9100  |
+|  Proxy Server Port (PROXY_HTTP_ADDRESS)  |  80  |  80  |
+|  Proxy Server Secure Port (PROXY_HTTPS_ADDRESS)  |  443  |  443  |
+|  SAS_SSL_SERVERAUTH_LISTENER_ADDRESS  |  9401  |  9401  |
+|  Service Integration Port (SIB_ENDPOINT_ADDRESS)  |  7276  |  7276  |
+|  Service Integration Secure Port (SIB_ENDPOINT_SECURE_ADDRESS) |  7286  |  7286  |
+|  SIP Container Port (SIP_DEFAULTHOST)  |  5060  |  Not applicable  |
+|  SIP Container Secure Port (SIP_DEFAULTHOST_SECURE)  |  5061  |  Not applicable  |
+|  SOAP Connector Port (SOAP_CONNECTOR_ADDRESS)  |  8880  |  8879  |
+|  IBM HTTP Server Port  |  80  |  Not applicable  |  ''virtualhosts.xml'', ''plugin-cfg.xml'', and ''web_server_root/conf/httpd.conf''  |
+|  IBM HTTPS Server Administration Port  |  8008  |  Not applicable  |  ''web_server_root/conf/admin.conf''  |
+''Table - Port definitions for WebSphere Application Server Version 6.1''
+To see more tables look [[port_number_settings|here]]
+\\
+\\
+===== Common command line tools =====
+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)
+\\
+===== Backup  =====
+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:
+<file># ./backupConfig.sh </file> 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.
+<file># ./restoreConfig.sh /some_path/WebSphereConfig_<date>.zip</file>
+**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.
+\\
+===== Logs =====
+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:
+\\
+<box 100%  round| **WAS logs**>
+\\
+**''<was_root>/logs/install/log.txt''** -> This file records installation status.
+**''<was_root>/logs/manageprofiles/profileX_create.log''** -> This log records creation events that occurred __when creating the profile__, profileX.
+**''<profile_root>/profileX/logs/AboutThisProfile.txt''** -> This file logs __information about the profile__, including the <profile_root>, the profile name, the node and host names, and a number of the ports with which it was configured.
+**''<profile_root>/profileX/logs/backupConfig.log''** -> This log records events that occur __when creating a backup__ of the configuration directory structure.
+**''<profile_root>/profileX/logs/ivtClient.log''** -> This logs results from the installation verification command (__ivt__).
+**''<profile_root>/profileX/logs/serverY/startServer.log''** -> This log records the __startup messages__ from the server.
+**''<profile_root>/profileX/logs/serverY/SystemErr.log''** -> This contains the __standard error output__ from the __Java virtual machine__ (JVM) running the application server. This file should be empty if the server has started correctly.
+**''<profile_root>/profileX/logs/serverY/SystemOut.log''** -> This contains the __standard output__ from the __Java virtual machine__ (JVM) running the application server. This file should contain a lot more detailed messages indicating the steps performed during startup of the server. These steps include security initialization, messaging initialization, registering resources in the JNDI namespace, EJB initialization, Web module initialization and HTTP transport initialization.
+</box>
+===== Migrate to WebSphere Application Server 6.1 =====
+=== Prepare to migrate ===
+    * 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.
+=== Install WebSphere Application Server 6.1 ===
+    * 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.
+=== Perform the migration running the Migration wizard ===
+    * Launch FirstSteps from the profile directory. {{  :image003.jpg|}}
+    * 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>.
+\\
+\\
+\\
+\\
+\\
+\\
+===== Managing Web servers with WebSphere =====
+WebSphere V6 DMgr can manage external Web servers:
+  * //IBM HTTP Server V6// (IHS) ((IBM HTTP Server V6.1 is based on Apache 2.0.47)): 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.
+=== Unmanaged Web server (not IHS) ===
+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.
+=== IHS as unmanaged node  (remote) ===
+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.
+{{ihsunm01.png  |IHS as unmanaged node  }}
+**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 administration server ===
+  * 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''
+=== Web server on a managed node (local) ===
+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.
+{{  ihsman01.png|Web server on a managed node}}
+__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.
+=== Web server custom plugin-cfg.xml ===
+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.
+===== IBM HTTP Server Installation =====
+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).
+{{10.png  |HTTP Administration Server Authentication}}
+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.
+{{  11.png|Installation Summary}}
+\\
+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 <file># ./apachectl start</file> then start the administrative server using the command <file># ./adminctl start</file>
+Check the status of the IBM HTTP Server using a browser and writing: ''http://localhost''
+\\
+\\
+\\
+===== HTTP session management =====
+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.
+<box 100% red left round| **Cookies**>
+\\ When this option is selected from the session manager pane, the plug-in will use the **JSESSIONID** to manage requests. This name is required by the Servlet 2.3 specification. The session management tracking mechanism can be performed at the application server, Web container, or the Web module level. To use the cookie JSESSIONID, __users must have their browsers set up to allow cookies__. \\ \\ The browser can be connected to any Web server and there will be no effect on the session. Cookie session identifiers survive a Web server crash and, provided persistent sessions are enabled, also survive unavailability of the application server. \\ \\ The session lifetime is governed by the cookie lifespan. By default, WebSphere defines its cookies to last until the browser is closed. It is also possible to define the maximum age of the cookie in the cookies configuration. \\ \\
+Example of a session identifier: ''JSESSIONID=0000A2MB4IJozU_VM8IffsMNfdR:v544d0o0''
+The JSESSIONID cookie can be divided into four parts:
+  * **Cache ID** (0000)
+  * **Session ID** (A2MB4IJozU_VM8IffsMNfdR)
+  * **Separator** (:)
+  * **Clone ID or Partition ID** (v544d0o0: A clone ID is the ID of a cluster member)
+If security is important, then it is possible to use cookies in an SSL environment and not have the overhead of setting up SSL session ID management
+</box>
+<box 100% orange left round| **URL rewriting**>
+\\ URL rewriting (or URL encoding) is a useful mechanism that does not require users to enable cookies in their browsers, and yet still allows WebSphere to manage sessions. \\ \\ The process of setting up URL rewriting, however, is not transparent to the Web application. __It requires a developer to include specific commands to append the session information to the end of any HTTP link that will be used from the Web browser__. The plug-in will search for any URL encoded session information about incoming requests and route them accordingly. \\ \\ Rewriting the URLs can only be done on dynamic HTML that is generated within WebSphere. Session information is lost if static HTML links are accessed, restricting the flow
+of site pages to dynamic pages only. From the first page, the user receives a session ID, and the Web site must continue using dynamic pages until the completion of the session. \\ \\ Due to the restrictions mentioned above, the only situation in which URL encoding excels over the other options is when users have not enabled cookies in their browsers. __Because it is possible to select more than one mechanism to pass session IDs__, it
+is also possible to compensate for users not using cookies. URL encoding could be enabled and then used as a fallback mechanism if the users are not accepting cookies. \\ \\
+</box>
+<box 100% blue left round| **SSL ID**>
+\\ To use the SSL ID as the session modifier, clients need to be using an SSL connection to the Web server. This connection does not need to use client certificate authentication, but simply a normal server authentication connection. This can be enabled by turning on __SSL support in the Web server__. \\ \\ The session ID is generated from the SSL session information. This is passed to the Web server and then passed on to the plug-in. If more than one Web server is being used, then affinity must be maintained to the correct Web server, since the session ID is defined by the connection between browser and Web server. Connecting to another Web server will reset the SSL connection (a new session ID is generated). \\ \\ It is possible to maintain the SSL session affinity using the ''Load Balancer'' from IBM WebSphere Edge Components.
+\\ \\
+</box>
+**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.
+===== WebSphere plug-in workload management =====
+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.
+\\
+===== Configuring IBM HTTP Server for SSL =====
+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.
+<file> LoadModule ibm_ssl_module modules/mod_ibm_ssl.so</file>
+  * Create a virtual host, then enable and configure SSL just for this virtual host.
+<file>
+SSLDisable
+Listen 0.0.0.0:443
+<VirtualHost webserver01.azz.net:443>
+SSLEnable
+KeyFile "C:/IBM/HTTPServer/conf/keys/IHS6Certificates.kdb"
+</VirtualHost>
+</file>
+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.
+===== Edge Components =====
+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.
+{{ipspr01.png  |IP sprayer horizontally scaled topology}}
+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.
+===== WAS on z/OS =====
+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__.
+{{zos_01.gif |z/OS WAS Diagram and SDSF}}
+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.
+{{zos_02.jpg|}}
+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.
+{{zos_03.jpg |z/OS ISPF home page}}
+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
+===== WebSphere Resources =====
+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''
+\\
+=== JDBC resources ===
+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//.
+{{:resadp.png  |Resource adapter in J2EE connector architecture}}
+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.
+== Configure connection pooling properties ==
+The link to connection pooling settings is found in the __Additional Properties section__ of the data source configuration window.
+{{  :conn_pool02.png|Data source connection pool properties}}
+  * **''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. \\
+\\
+===== JCA Connection Problem =====
+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.
+{{  :jca01.png|JCA Overview}}
+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 integration======
+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**.
+===== WebSphere MQ - Querying the Service Level (alias MQ Version) =====
+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.
+===== Queue Manager Cluster =====
+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(*)''
+===== Solaris MQ Installation =====
+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 -g option makes the mqm user a member of the mqm group))\\
+The WebSphere MQ software is normally installed in //mqm subdirectories// of the ''/WebSphere_MQ_inst_home''((eg. /opt)) and ''/var'' directories.\\
+To install WebSphere MQ in the ''/WebSphere_MQ_inst_home'' and ''/var'' directories on Solaris: <file>pkgadd -d /mq_cd/mq_solaris</file>
+where mq_cd is the mount point of the WebSphere MQ CD
+===== Acronyms =====
+^  Acronym  ^  Meaning  ^
+|  JCA  |  [[http://encyclopedia.thefreedictionary.com/J2EE+Connector+Architecture|J2EE Connector Architecture (Sun Microsystems, Inc.)]]  |
+|  JDBC  |  Java Data Base Connectivity  |
+|  JNDI  |  Java Naming and Directory Interface (Sun)  |
+|  DRS  |  Data Replication Service  |
+===== Glossary =====
+^ **Stateless**  | The server that processes each request does so based solely on information provided with that request itself, and not on information that it “remembers” from earlier requests. In other words, the server does not need to maintain state information between requests. |
+^ **Stateful**  | The server that processes a request __does need__ to access and maintain state information generated during the processing of an earlier request. |
+===== Credits =====
+Thank you!
+\\
+ --- //[[frank@bertucci.org|Gianfrancesco Bertucci]] //