Redbooks Paper
Dan LaDore
Edson Manoel
Provisioning J2EE Applications with
IBM Tivoli Intelligent Orchestrator
and IBM WebSphere Application
Server Network Deployment
Introduction
This IBM® Redpaper presents a simplified customer environment in which we
demonstrate a case study for provisioning servers to a Java™ 2 Platform,
Enterprise Edition (J2EE™) application cluster environment for use by
customers.
This paper focuses on the tasks required for planning, implementing, and
configuring all components of IBM Tivoli® Intelligent Orchestrator for dynamic
provisioning of J2EE applications to servers in an IBM WebSphere® Application
Server clustered environment controlled by IBM WebSphere Application Server
Network Deployment. We discuss the following topics:
򐂰 Scenario overview
򐂰 Scenario implementation overview
򐂰 Prerequisite automation packages verification
© Copyright IBM Corp. 2005. All rights reserved.
ibm.com/redbooks
1
򐂰 Data center modeling
򐂰 Workflow design and development
򐂰 Automation package assembly and installation
򐂰 Scenario execution
Scenario overview
In our scenario, we demonstrate the methods and requirements for integrating a
complete J2EE application environment into IBM Tivoli Intelligent Orchestrator.
We show the ability to use Tivoli Intelligent Orchestrator to manage this
environment from both an infrastructure and application point of view. We
demonstrate in detail the ability of Tivoli Intelligent Orchestrator to perform
provisioning operations to add and remove configured servers to an existing
application cluster in real-time as defined by application and server performance
requirements. We show all the required configuration settings and definitions
required in Tivoli Intelligent Orchestrator to enable such provisioning operations.
Our fictitious customer is running a J2EE application on WebSphere Application
Server Version 5.1.1 in a clustered environment originally configured with
WebSphere Application Server Network Deployment manager. The application
also uses IBM DB2® for a back-end database. The customer wants to provision
new servers into, and remove unneeded servers out of, the existing J2EE
application cluster as needed in the customer’s data center, in which Tivoli
Intelligent Orchestrator has already been deployed.
The sample J2EE application used in this paper models an online stock
brokerage application. This is the core business of our fictitious customer. The
infrastructure for the application has been deployed. Figure 1 depicts the
application infrastructure.
2
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Figure 1 Application infrastructure
Our intent
In this paper, we show all the steps to integrate the J2EE application to Tivoli
Intelligent Orchestrator, deploy the node and application into the cluster, remove
the node from the cluster when no longer needed, and appropriately update the
data center model to reflect in real-time the availability of resources.
At a high level, Figure 2 shows the operations performed when executing a
provisioning operation.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
3
Figure 2 J2EE application provisioning
In Figure 2:
1. The application workload reaches the predetermined utilization threshold.
2. Tivoli Intelligent Orchestrator decides to provision a new server to the
application tier.
3. The Cluster.AddServer logical operation begins.
4. The ID of an available server or servers is retrieved from the associated
resource pool. Cluster management operations begin at this point. Workflows
must issue commands and tasks to prepare the server or servers. Such tasks
include obtaining the WebSphere Application Server Network Deployment
server information, adding the servers to the proper WebSphere cell and
cluster, and so on.
4
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
5. Tivoli Intelligent Orchestrator prepares to install software by checking for the
server template associated with the application tier. The server template
provides network, storage, and software associations through software stacks
for the application tier to be provisioned on the selected server or servers.
The software stack contains one or more software module entries and might
contain other software stacks as well. A software module will provide a
software product definition that contains software installables definitions for
the product. The software installable indicates the location of the file
repository for the installable files. For our scenario, we present these
definitions in “Data center modeling” on page 12.
6. Software installations are performed as required. This process requires the
proper workflows be assigned to enable the logical operations to occur.
7. Template compliance is checked.
8. The server is allocated to the application tier.
For our scenario, we use a J2EE application created by the IBM WebSphere
Development Team for performance benchmarking to demonstrate the actions
we just described. The next section describes the Trade3 application used in our
scenario.
Main architecture of the Trade3 application
This section describes the main architecture of the Trade3 application. For our
case study scenario, Trade3 is already installed on WebSphere Application
Server V5.1.1 in an application cluster originally configured using WebSphere
Application Server Network Deployment manager.
The IBM WebSphere performance benchmark application Trade3 provides a
suite of IBM-developed workloads for characterizing the performance of a
WebSphere installation. The workloads consist of an end-to-end Web application
and a full set of primitives. The applications are a collection of Java classes, Java
servlets, JavaServer Pages (JSP), and Enterprise JavaBeans built to open J2EE
APIs.
This sample application provides a real-world scenario for its implementation
design, usage of J2EE 1.3, including the EJB™ 2.0 component architecture,
message-driven beans, transactions (1-phase, 2-phase commit), and Web
services (SOAP, WSDL, and UDDI).
For additional information concerning the application and to download the code
and complete installation documentation, refer to:
http://www.ibm.com/software/webservers/appserv/benchmark3.html
Figure 3 shows the basic architecture of the Trade3 application.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
5
Figure 3 Trade3 application architecture
As with any application, installing Trade3 in a clustered environment is a different
process from the stand-alone installation. This document assumes that the
installer has acquired such knowledge and skills and has previously configured
the application to function as in this scenario by completing the following major
steps:
1. Create the clusters, and add nodes and servers to them using the
WebSphere Application Server Network Deployment administrative functions.
2. Create the applications database infrastructure.
3. Create JDBC™ resources for either each node or for the cell.
4. Define Java Message Service (JMS) resources for each node.
5. Install the Trade3 application to the cluster.
Existing IT infrastructure
To demonstrate the provisioning operations performed by Tivoli Intelligent
Orchestrator in this scenario, we make the following assumptions:
򐂰 A functional environment for Tivoli Intelligent Orchestrator V3.1 is up and
running with Fix Pack 1 applied.
򐂰 A functional WebSphere Application Server V5.1.1 controlled by WebSphere
Application Server Network Deployment is up and running with Cumulative
Fix 5 installed and has an application cluster defined. We also assume that
the Trade3 application has been deployed to that application cluster within the
WebSphere Application Server environment.
6
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Figure 4 shows the infrastructure used in this scenario. It serves as the starting
point for us to create a Tivoli Intelligent Orchestrator environment capable of
automatically provisioning resources for the sample J2EE application. For our
scenario, this includes a WebSphere Application Server V5.1.1 application
cluster running Trade3.
Figure 4 Pre-integration infrastructure
Application environment overview
Our scenario uses IBM WebSphere Application Server Version 5.1.1 with
Cumulative Fix 5 on the Microsoft® Windows® Server 2003 platform.
WebSphere Application Server Network Deployment manages multiple nodes
and uses IBM HTTP Server as the front end for client access. The application
cluster has no modifications beyond what is required for the Trade3 application
installation. The Trade3 application currently operates in an application cluster on
two nodes. In addition, Trade3 uses an IBM DB2 database back end running on
Microsoft Windows Server 2003, which has been integrated as a JDBC provider
in WebSphere Application Server. Trade3 also requires JMS configurations in
WebSphere Application Server to function, which are explained completely in the
installation documentation for Trade3.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
7
Tivoli Intelligent Orchestrator environment overview
Our scenario uses Tivoli Intelligent Orchestrator in a two-server deployment
configuration. In this environment, one server acts as the provisioning server,
running Tivoli Intelligent Orchestrator Version 3.1 with Fix Pack 1, WebSphere
Application Server V5.1, with Fix Pack 1 and Cumulative Fix Pack 3, IBM DB2
Universal Database™ (UDB) Enterprise Server Edition Version 8.2 with Fix Pack
7 and Hot Fix 13832, and IBM Tivoli Directory Server Version 5.2 client.
The second server acts as the directory server node running IBM DB2 Universal
Database Enterprise Server Edition Version 8.2 with Fix Pack 7 and Hot Fix
13832 and the IBM Tivoli Directory Server Version 5.2 server and client.
For deployments in which the services for the Tivoli Intelligent Orchestrator
environment reside on two machines, the minimum hardware requirements are:
򐂰 2.8 GHz Intel® Pentium® 4 processor or equivalent
򐂰 Minimum of 4 GB of free RAM
򐂰 20 GB of disk space
Because our installation has been implemented on the Microsoft Windows
Server 2003 operating system, there are some additional requirements to make
the management environment function correctly, such as Cygwin to enable
secure communication between the management server and managed servers
and devices and IBM Tivoli Intelligent Orchestrator V3.1 Fix Pack 1 to provide
updates to Tivoli Intelligent Orchestrator and existing automation packages
required for this scenario.
As we stated earlier, we assume that Tivoli Intelligent Orchestrator has been
deployed and has a functioning data center model (DCM) configured. Later in
this paper, we describe in detail the steps required to add the entire application
infrastructure to the existing DCM, including defining the customer, applications,
clusters, software definitions for products, dedicated servers, and configuration
templates for servers and software definitions. We also include defining the
resource pools to support the provisioning process in Tivoli Intelligent
Orchestrator.
For additional information about Tivoli Intelligent Orchestrator, refer to the Tivoli
Intelligent Orchestrator V3.1 Information Center at:
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?toc=/com.i
bm.tivoli.tio.doc/tio_nav.xml
8
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Scenario implementation overview
The goal of this paper is to implement an environment similar to that shown in
Figure 5.
Figure 5 Provisioning infrastructure
In order to achieve a fully integrated provisioning environment, you need to
complete the following tasks:
1. Install and verify the latest level of all required prerequisite automation
packages in the Tivoli Intelligent Orchestrator environment.
2. Completely integrate the Trade3 application environment into the existing
Tivoli Intelligent Orchestrator data center model.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
9
3. Develop and test the workflows to carry on the provisioning operations of our
Trade3 application cluster using any of the Tivoli Intelligent Orchestrator V3.1
provided workflows development environments: workflow composer and the
Automation Package Development Environment (APDE).
4. Create an automation package that includes all workflows, device drivers,
scripts, configuration templates for server and software definitions, our
sample application installable module, and other DCM sample definitions.
This automation package must be installed in our Tivoli Intelligent
Orchestrator environment.
The following sections provide details about each of these tasks.
Prerequisite automation packages verification
Automation packages provide an avenue for Tivoli Intelligent Orchestrator to
access different software and hardware platforms. An automation package is a
logical grouping of scripts, JAR files, and other files used for a specific device
driver. After an automation package has been installed, Tivoli Intelligent
Orchestrator has the framework installed for manipulating the behavior of any
entity that can be defined within the data center model, for example, a piece of
hardware, software, or a custom object or objects. Automation packages are
stored in the %TIO_HOME%\drivers directory.
In this section, we provide the steps to install and verify the installation of the
required automation packages for our case study scenario. As per the
architecture of our sample J2EE application, the following automation packages
are required:
򐂰 IBM Automation Package for WebSphere Application Server
This automation package contains the components for installing, configuring,
and troubleshooting the WebSphere Application Server product. For Tivoli
Intelligent Orchestrator, this automation package is named
IBM-WebSphere-App-Server.
򐂰 IBM Automation Package for IBM DB2
This automation package captures the workflows and other components
necessary to install, uninstall, configure, and manage the IBM DB2 database
product. For Tivoli Intelligent Orchestrator, this automation package is named
DB2.
For our case study environment, these automation packages provide, among
other things, templates that will be used for our software definitions, which in turn
will be used to create the software stacks used to install the sample application
environment on the servers during the provisioning operation.
10
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Later in this paper, we explain how we create and install the Trade3 automation
package, which provides workflows, logical operations, and additional
configuration templates used for our TRADE3 software definition, and, ultimately,
the software stack to enable configuration and installation of the Trade3
application onto a server selected from the assigned resource pool.
Both prerequisite automation packages previously described are shipped with
Tivoli Intelligent Orchestrator V3.1. We applied the Tivoli Intelligent Orchestrator
Version 3.1 Fix Pack 1 on our management server, which provided the required
updates to these automation packages as part of the update.
To verify the existence and status of an automation package, use the automation
package manager tc-driver-manager command. For example, the following
command can be run from a terminal session on your server to verify the status
of the IBM Automation Package for WebSphere Application Server:
%TIO_HOME%\ tools\tc-driver-manager getDriverStatus
IBM-WebSphere-App-Server
This returns a simple value of installed or not-installed, as shown in
Example 1.
You can use the same command to verify the installation of the IBM Automation
Package for IBM DB2. Both are required for our Trade3 application scenario. If
the automation package is installed and Tivoli Intelligent Orchestrator Version 3.1
Fix Pack 1 applied, no further configuration is required in this area.
Example 1 Verifying the automation package installation
C:\IBM\tivoli\thinkcontrol\tools>tc-driver-manager.cmd getDriverStatus
IBM-WebSphere-App-Server
2005-08-19 13:49:09,281 INFO COPTDM001I TCDrivermanager was started.
2005-08-19 13:49:09,641 INFO COPTDM004I Config directory:
"file:C:\IBM\tivoli\thinkcontrol\config/".
2005-08-19 13:49:09,656 INFO COPTDM004I Config directory:
"file:C:\IBM\tivoli\thinkcontrol\config/".
2005-08-19 13:49:09,703 INFO COPTDM002I Driver directory: "Driver directory:
"C:\IBM\tivoli\thinkcontrol/drivers/".".
2005-08-19 13:49:13,172 INFO COPTDM005I TCDrivermanager was stopped.
installed
Ensure that you have the latest versions of the automation packages. You can
download them from the On Demand Automation Catalog Web site at:
http://www.ibm.com/software/ondemandcatalog/automation
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
11
At the time of writing this paper, both IBM Automation Package for WebSphere
Application Server and IBM Automation Package for IBM DB2 were at level
3.1.0.1.1354.65, which includes the Tivoli Intelligent Orchestrator Version 3.1 Fix
Pack 1 updates.
The On Demand Automation Catalog main page supports fast-path navigation
directly to the needed automation package. For example, the navigation code for
IBM Automation Package for WebSphere Application Server is 1TW10101Y, and
for IBM Automation Package for IBM DB2, the navigation code is 1TW10101P.
Automation packages are installed using the
%TIO_HOME%\tools\tc-driver-manager.cmd installDriver <packageName>
command. After this completes successfully, use the getDriverStatus option to
check the status again, verifying that your installation completed correctly.
There are also other files included with the automation package, such as
configuration templates, workflows, Jacl files, and documentation. It is good
practice to verify the existence of these as well after the automation package has
been installed and passed verification as an additional validation step.
At this point, no more configuration is required to the automation packages until
later in this paper when we describe how to use the prerequisite package
components for our DCM customization and workflows development for the
Trade3 automation package for our scenario.
Data center modeling
The data center model (DCM) is a repository of all physical and logical resources
that are managed by Tivoli Intelligent Orchestrator. Managed resources can be
servers, switches, applications, customers, software, and other related
equipment. It keeps track of changes made by workflows to the hardware and
software configuration and keeps the model in sync with the real-world hardware
and software assets that are associated with it.
The DCM also stores information needed for the management of resource pools
and clusters, such as server IDs, size of resource pools, number of active and
inactive servers and server priorities, and the associated templates.
The DCM information is stored in a central database controlled by Tivoli
Intelligent Orchestrator. It contains information regarding a real-life data center.
Tivoli Intelligent Orchestrator communicates directly with all components of the
data center based on the definitions in the DCM.
12
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
DCM entries can be built using an XML file and imported into the DCM database
using tools supplied with the software. To customize the existing DCM to enable
Tivoli Intelligent Orchestrator to interact and provision the Trade3 application, we
provide the following solution-specific DCM definitions:
򐂰 Customer, application, and application tiers
򐂰 Resource pool and spare servers
򐂰 Server templates for both resource pool and application tiers
򐂰 Software definitions, software installables, and software configuration
templates
򐂰 Software stacks
򐂰 Service access points
򐂰 The Tivoli Intelligent Orchestrator server itself
Note: In this paper, there are many references to the terms software definition
and software module. For our purposes, we are referring to the same Tivoli
Intelligent Orchestrator object. If you use the Tivoli Intelligent Orchestrator
GUI, you will notice the objects identified as software definitions. If you look in
the data center model XML file, you will see the objects referred to as software
modules.
Because this case study scenario assumes a preexisting DCM, definitions for
service access points and the Tivoli Intelligent Orchestrator server itself are
reused and are not shown here.
After the previous list of objects is integrated correctly into the data center model,
we use these definitions in support of the logical operations provided by the
Trade3 automation package to provision servers to the Trade3 application cluster.
Figure 6 illustrates the relationships that exist among the previously-listed objects
defined within the data center model.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
13
Resource Pool Data Center Model
Relationship
Application Tier Data Center Model
Relationship
Resource
Pool
Software
Repository
(installables)
Software
Repository
(installables)
Software
Installation
Application
Tier
Software
Repository
(installables)
Software
Installation
Server
Template
Software
Installation
Software
Repository
(installables)
Software
Installation
Server
Template
Software
Stack 2
Software Module 2A
Template Types:
Installation
Instance
Application-Data
Configuration
Place Holder
Foreign Config
Feature
Software
Stack 1
Software Module 1A
Template Types:
Installation
Instance
Application-Data
Configuration
Place Holder
Foreign Config
Feature
Software Module 2B
Software Module 1B
Template Types:
Installation
Instance
Application-Data
Configuration
Place Holder
Foreign Config
Feature
Template Types:
Installation
Instance
Application-Data
Configuration
Place Holder
Foreign Config
Feature
Figure 6 Data center model object relationships
Based on Figure 4 on page 7, we need to create entities in the DCM that will
represent our application topology. According to the guidelines presented in
Figure 6, we need to define a customer and an application. This application
contains three tiers that will also be defined in the DCM. For the example
presented in this paper, we are only concerned with the tier in which our sample
application runs: the Web Application Server tier. Later, we define a server
template and associate that server template with the Web Application Server tier.
The server template will identify the required software for the application. This is
accomplished by defining a software stack, adding software modules to the
stack, and associating the software stack to the server template.
14
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
In addition to software module definition for the Trade3 application itself, software
modules for WebSphere Application Server and DB2 Universal Database will be
defined because they are requirements for our sample J2EE application. They
will be assigned to the software stack definition of our application tier server
template. Each software module definition will have configuration templates that
contain the attributes used to install and configure the software. The software
modules will also have an installation defined pointing to the location of the
software installables.
In addition, we need to define a server template for the resource pool for our
scenario. In the same fashion as we described earlier, the template is used to
ensure that the servers in this resource pool have WebSphere Application Server
and DB2 Universal Database installed. This means that they require only the
installation and configuration of Trade3 when provisioned to our application tier.
Figure 7 illustrates our goal for our application tier definition.
Figure 7 Trade3 DCM object relationships
The following sections provide details about the DCM definitions for our case
study scenario.
Customers, applications, and application tier definitions
Tivoli Intelligent Orchestrator requires that certain objects defined to the DCM to
enable management of the environment and to enable provisioning. The DCM
maintains information about relationships between the different definitions when
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
15
added to configurations or objects, so the proper information will be used
whenever a provisioning operation is initiated.
Customers
In Tivoli Intelligent Orchestrator, a customer is defined as an organization that is
associated with one or more applications managed by your data center.
For our scenario, we performed a single customer definition in our data center,
called SalesCustomer. This customer definition is used to host the managed
application and the three application tiers. We describe these in the following
sections.
Applications
In Tivoli Intelligent Orchestrator, applications consist of groups of servers that run
the different levels of the application. For example, the three layers of the Trade3
application run HTTP, the Web application, and database services. The
applications’ priority can be set to help influence decisions concerning
orchestration.
In our scenario, we defined one application, called Trade3. The application
contains three tiers, discussed in the following section.
Application tiers
In Tivoli Intelligent Orchestrator, application tiers are groups of managed servers
that run the separate tiers, or levels, of an application. An application tier can
contain both dedicated servers assigned specifically to the tier or overflow
servers provisioned from a resource pool.
The application tier definitions we create for our scenario are used to integrate an
existing application (Trade3) into our data center model. In this case, we define
three application tier entries in the DCM to support each of the three tiers in our
Trade3 application. These tier definitions contain dedicated servers at the time
they are created, because we are mirroring the preexisting application
infrastructure.
The application tires for our case study scenario are:
򐂰 Trade3 Web Servers
򐂰 Trade3 DB Servers
򐂰 Trade3 WebAPPL Servers, which is the focus of our scenario
Example 2 shows the XML used for our data center model customer, application,
and application tier definitions. You will notice in the XML that the application tiers
are referenced as clusters. This is the only place this occurs.
16
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
In the following example, the &win-saps entry is a pointer to the service access
point definitions, which are in a different section of our XML file for organizational
purposes only.
Example 2 Customer, application, and application tier definitions
<customer name="SalesCustomer">
<application name="Trade3" priority="1" locale="en_US">
<cluster name="Trade3 Web Servers" min-servers="1" max-servers="9"
managed="true" is-device-model="Simulator" locale="en_US">
<with-load-balancer name="Load Balancer 1"/>
<server name="TradeWebSrv01" locale="en_US">
<nic connected-to-switch="CISCO1" connected-to-module="fa0"
connected-to-port="9" management="true">
<network-interface name="Local Area Connection"
ipaddress="9.3.5.244" netmask="255.255.255.0" />
</nic>
&win-saps;
</server>
</cluster>
<cluster name="Trade3 WebAPPL Servers" min-servers="1" max-servers="9"
pool="WAS51 Pool" managed="true" is-device-model="Simulator"
locale="en_US">
<with-load-balancer name="Load Balancer 1"/>
<server name="prov002" locale="en_US">
<nic managed="false" connected-to-switch="CISCO1"
connected-to-module="fa0" connected-to-port="10">
<network-interface name="Management" ipaddress="9.3.5.32"
netmask="255.255.255.0" management="true"/>
</nic>
&win-saps;
</server>
<server name="prov003" locale="en_US">
<nic managed="false" connected-to-switch="CISCO1"
connected-to-module="fa0" connected-to-port="4">
<network-interface name="Management" ipaddress="9.3.5.22"
netmask="255.255.255.0" management="true"/>
</nic>
&win-saps;
</server>
</cluster>
<cluster name="Trade3 DB Servers" min-servers="1" max-servers="2"
managed="false" is-device-model="Simulator" locale="en_US">
<with-load-balancer name="Load Balancer 1"/>
<server name="TradeDBSrv01" locale="en_US">
<nic connected-to-switch="CISCO1" connected-to-module="fa0"
connected-to-port="11" management="true">
<network-interface name="Local Area Connection"
ipaddress="9.3.5.242" netmask="255.255.255.0" />
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
17
</nic>
&win-saps;
</server>
</cluster>
<objective-analyzer
</application>
</customer>
type-name="TIO capacity-on-demand"/>
Later in this paper, we define a server template and software definitions. We then
associate these definitions with the Trade3 WebAPPL Servers application tier so
that the correct software and configuration settings are applied to the servers that
will eventually get provisioned to this tier of the application.
Resource pool definitions
Resource pools are a core part of any provisioning operation. A resource pool is
a group of unallocated servers assigned to a specific application tier or tiers.
When it is deemed necessary, either manually or by the Workload Manager,
applications can receive the resources they need by allocating one or more of the
available servers to the application tier in need. This causes Tivoli Intelligent
Orchestrator to update the status of those resources allocated in the DCM,
preventing them from being used elsewhere. When the workload monitor or
another process decides they are no longer needed, they can be deprovisioned
and returned to the resource pool to be used again.
For our scenario, we define the resource pool as a pool of physical servers that
are available for deployment into our Trade3 WebAPPL Servers application tier.
Example 3 shows the XML we used to define the WAS51 Pool to our data center
model.
Example 3 Resource pool definition
<spare-pool name="WAS51 Pool" os-type="windows" locale="en_US">
<server name="prov004" locale="en_US">
<nic managed="false" connected-to-switch="CISCO1"
connected-to-module="fa0" connected-to-port="5">
<network-interface name="Management" ipaddress="9.3.5.24"
netmask="255.255.255.0" management="true"/>
</nic>
&win-saps;
</server>
<server name="prov005" locale="en_US">
<nic managed="false" connected-to-switch="CISCO1"
connected-to-module="fa0" connected-to-port="6">
<network-interface name="Management" ipaddress="9.3.5.25"
netmask="255.255.255.0" management="true"/>
</nic>
18
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
&win-saps;
</server>
<server name="prov006" locale="en_US">
<nic managed="false" connected-to-switch="CISCO1"
connected-to-module="fa0" connected-to-port="7">
<network-interface name="Management" ipaddress="9.3.5.222"
netmask="255.255.255.0" management="true"/>
</nic>
&win-saps;
</server>
<server name="prov007" locale="en_US">
<nic managed="false" connected-to-switch="CISCO1"
connected-to-module="fa0" connected-to-port="8">
<network-interface name="Management" ipaddress="9.3.5.31"
netmask="255.255.255.0" management="true"/>
</nic>
&win-saps;
</server>
</spare-pool>
Later, the servers in the WAS51 Pool resource pool are associated with a server
template that has a software stack associated with it. This software stack
contains two software modules, or definitions: WebSphere Application Server,
and IBM DB2 for Windows. This ensures that the servers have already been
prepared, based on that template, with the required basic software for our Trade3
application. This allows for much faster deployment when the need arises, but
also keeps the resource pool generic enough to allow the servers to be used for
many different situations.
Software definitions
Software definitions are used in the DCM to identify basic information about a
piece of software, for example, operating systems, software patches, and
software products. This is known as a software module in the DCM XML file. You
can then associate one or more installable files with the software definition.
These installables will contain information about where in the software repository
the correct installation files are stored. In cases where multiple installable files
are configured, it is necessary to define adequate requirements to ensure that
Tivoli Intelligent Orchestrator selects the correct installable file for deployment.
You can also include more granular information, called requirements, including
dependencies and options, such as operating system family and version, to
ensure that deployment will occur on adequate hardware for the particular
module.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
19
Software definitions also allow the definition of configuration templates, which
provide information needed to install and configure software. Configuration
templates can contain many parameters for both the installation and for the
runtime of the product. Configuration templates enable a hierarchical definition.
Child templates can be defined under a parent resource template to add
additional features, such as the ability to start and stop instances of installed
software.
The name of the software definitions used in our scenario for the Trade3
application are:
򐂰
򐂰
򐂰
򐂰
DB2 for Windows
IBM WebSphere Application Server Network Deployment
IBM WebSphere Application Server
TRADE3
DB2 for Windows
IBM DB2 is used as the back-end database for our Trade3 application. We use
Version 8.2 for our scenario, with one main server and clients connecting using
the DB2 client software on the other machines.
In Figure 8, you will see the software definition we added to our DCM to use with
our Trade3 scenario. The bottom section contains the configuration template
information. Notice the main, or parent, template and the child templates below it.
In Tivoli Intelligent Orchestrator, the parent template for software definitions must
be of the installation type.
20
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Figure 8 DB2 for Windows Software Definition and Configuration Template
IBM WebSphere Application Server Network Deployment
software definition
IBM WebSphere Application Server Network Deployment was used to build the
application cluster Trade3 originally. This was not executed with Tivoli Intelligent
Orchestrator. However, for the future deployment of nodes to and from that
existing application cluster, the WebSphere Application Server Network
Deployment commands will be used by the workflows that perform these tasks.
The workflows need to collect information about the WebSphere Application
Server Network Deployment software installation defined in the DCM, such as
installation path and location of the Jacl scripts.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
21
Figure 9 shows our case study scenario software definition for IBM WebSphere
Application Server Network Deployment and its required installation
configuration template.
Figure 9 Network Deployment Software Definition and Configuration Template
IBM WebSphere Application Server software definition
IBM WebSphere Application Server is required for our scenario, because it is the
engine for running our J2EE application, Trade3. This is the definition for the
WebSphere Application Server software that will be deployed to all subsequent
nodes provisioned to our Trade3 application cluster. The configuration template
for this product contains information to enable workflows to collect information
about the WebSphere Application Server installation on those servers and other
information specific to the Trade3 application cluster itself, such as the host
name, SOAP port, and management port of the WebSphere Application Server
Network Deployment server.
Figure 10 shows our case study scenario software definition for IBM WebSphere
Application Server and its required installation configuration template.
22
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Figure 10 IBM WebSphere Application Server Software Definition and Configuration Template
TRADE3 software definition
The Trade3 application is the core of our scenario. It is the J2EE application we
deployed to our application cluster, and this software definition identifies the
product that will be deployed to all other servers provisioned to this application
cluster. As shown in Figure 11, you can see the two different versions of the
software available for deployment in the Installable Files section. This definition is
useful for future use, in case we need to add a new servers running the Linux®
operating system to the resource pool assigned to the application tier
representing the Web application servers for the Trade3 application.
Also, all of the information required to successfully deploy this application is
defined in the installation Configuration Templates section. Specifically, we
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
23
defined configuration parameters for the existing Trade3 application cluster. For
example, we define database configuration information such as the database
server host name, port number, and instance owner. We also provide JDBC
configuration attributes such as the location of the JDBC driver and the name of
the data source.
Another important piece of configuration information is the location of the Jacl
scripts for the provisioning tasks. These scripts will be used by a series of
wsadmin command calls during the workflows executions.
Figure 11 TRADE3 Software Definition and Configuration Template
Later in this paper, we create an automation package that provides operations for
manipulating this software. After the automation package is installed on the Tivoli
Intelligent Orchestrator server, it defines a new device driver that must be
associated to this software definition. The device driver will implement a logical
operation and workflow implementation for installing this software product on
target servers.
24
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Software stacks
A software stack is a grouped set of software, organized in the correct installation
order. Tivoli Intelligent Orchestrator uses software stacks to install multiple
products, patches, or even other stacks onto servers to prepare them for
provisioning into production.
Each module, when included in a software stack, will have a cloned version of the
original software configuration template defined in the software stack entry in the
DCM. This enables additional customization of the software in relation only to the
particular stack with which you are currently concerned. Because the cloned
configuration template and the original configuration template have unique IDs in
the DCM, changes made to one will not be reflected in the other. In other words,
changing attributes in the configuration template of the software stack does not
change the configuration template defined in the software module definition.
For our scenario, we defined two software stacks to support our sample
application environment:
򐂰 A software stack to be associated to the server template for our resource pool
(WAS51 Pool resource pool) so that it is in a ready state for faster deployment
into a J2EE environment by having most of the requisite software installed for
our particular scenario
򐂰 A second software stack, named Trade3_Software_Stack, to be associated to
the server template of our application tier (Trade3 WebAPPL Servers
application tier) to provide the proper software for the installation and
configuration of the Trade3 application
Figure 12 shows the software stack definition and associated software required
for Trade3, along with the iterator installable. The iterator is a function in Tivoli
Intelligent Orchestrator that allows multiple pieces of software to be installed by
“looping” through the list of modules in the stack. This is the reason that the
objects need to be added to the stack in the correct installation order. The iterator
is only required when multiple modules have been associated with a software
stack.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
25
Figure 12 The Trade3 Software Stack
After we create our software stack for Trade3 and associate the required software
to it, we see the configuration template for the software stack that Tivoli Intelligent
Orchestrator creates by cloning the parent templates originally created for the
software definition. At this time, if required, these templates can be customized to
reflect the needs of this particular stack.
However, if a required parameter is altered or added to the configuration
template for a software definition after it has been added to a software stack,
changes made in the original configuration template will not be present on the
cloned template for the software associated to the stack. It is important to
remember this as you move forward creating software stacks for your particular
environment, because changes to these parent templates will require you to
remove and then add again the affected software definition to your previously
created software stacks if you want the changes to exist in them as well.
In Figure 13, part of the configuration template for our Trade3 software stack is
shown. All of the listed parameters were acquired in the cloning of the template
from the parent software definition we created. Notice that the names of the
configuration templates listed all have numbers appended to the names,
26
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
indicating that they are clones of the original. This is where the configurations for
each software stack can be edited without impacting any parent or other software
stack using a clone of the same parent.
Figure 13 Cloned Configuration Template for Trade3 software stack
Define server templates
Server templates are used in Tivoli Intelligent Orchestrator to provide software,
storage, and network information to the manager so that after servers are
associated with a template for a resource pool or application tier, the software
applications and software configurations provided by the template will be
preinstalled and configured as defined by the template, putting the server in the
desired state for provisioning based on the location of the server.
For our Trade3 scenario, we defined two server templates:
򐂰 A server template for the application tier Trade3 WebAPPL Servers of the
Trade3 application. This server template has the Trade3_Software_Stack
software stack defined in the previous section associated to it.
򐂰 A second server template for the WAS51 Pool resource pool.
The server template shown in Figure 14 shows the Trade3_Server_Template
defined in the data center model. Under Software Definition, you will see how we
associated the Trade3_Software_Stack to the template, confirming that any
server brought into the application tier will have the modules and configurations
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
27
defined by that software stack applied to them. Notice also that if required, routes
and network information can be provided here as well. Storage templates can
also be associated here if required.
Figure 14 Trade3 Server Template
Also in Figure 14, on the Workflows tab, we associate the device driver for the
provisioning operations. This device driver will be part of an automation package
created exclusively for our case study scenario. The following sections of this
paper concentrate on the development of this automation package.
Workflow design and development
Workflows are a key component for provisioning. They can be used for gathering
information about an instance, installation, a piece of hardware, or any other
object defined to the DCM that will be acted upon. A workflow can then use this
information to perform defined tasks. Workflows are simple, structured programs
with a number of constructs to manage data center components. They can be
very complex and long, in which a workflow executes many other workflows to
perform the desired operation, or they can be as simple as one command to
check the status of a machine with a ping. It is critical that workflows be planned,
defined, and structured correctly to ensure that provisioning can occur in support
of a predefined working process.
28
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Note: It is not our intention to teach you how to develop workflows in this
paper. This is beyond the scope of this paper. For more information about
developing workflows, refer to IBM Tivoli Provisioning Manager 3.1.0
Workflow Developer's Guide, GC32-1662.
For our scenario, there are a number of workflows required to fully integrate our
J2EE application into Tivoli Intelligent Orchestrator to enable provisioning. Some
workflows will gather required information from the data center model, such as
server IDs, resource template IDs, and configuration parameters from software
definitions. Others workflows will use this information to perform logical
operations or execute commands, for example, interfacing with the WebSphere
Application Server wsadmin command, executing IBM DB2 commands to catalog
database information, and using some generic UNIX® system commands, such
as the wget command.
The chart in Table 1 lists the workflows used in our scenario and describes the
function performed by each one. These workflows are part of an automation
package for Trade3 we create and install later in the paper.
Table 1 Workflows developed for Trade3 application
Workflow
Description
_T3_Install_Ping_NDM
Verifies that the WebSphere Application Server
Network Deployment manager is functioning before
installation begins.
_T3_Install_Collect_Trade3DB_Attributes
Gets the required attributes related to database
settings from the configuration template for the Trade3
software definition.
_T3_Install_DB2Catalog
Catalogs the database on the target machine.
_T3_Install_Get_NDM_Server_Attributes
Gets the required server attributes from the
configuration template defined for the WebSphere
Application Server Network Deployment software
definition.
_T3_Install_Get_NDM_Software_Attributes
Gets the required software attributes from the
configuration template defined for the WebSphere
Application Server Network Deployment software
definition.
_T3_Install_AddNodetoCell
Adds the new node to the existing WebSphere
Application Server cell.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
29
Workflow
Description
_T3_Install_Execute_Wsadmin
Provides the bridge from Tivoli Intelligent Orchestrator
to the WebSphere Application Server wsadmin
command.
_T3_Install_Get_Trade3_Attributes
Gets the required software attributes from the
configuration template defined for the Trade3 software
definition.
_T3_Install_AddNodetoWASCluster
Adds the new node to the Trade3 application cluster.
_T3_Install_JDBCResourcetoWAS
Adds the JDBC resource to WebSphere Application
Server for Trade3.
_T3_Install_AddJMSResourcetoWAS
Adds the JMS resource configuration in WebSphere
Application Server for the new node.
_T3_Install_Collect_Trade3Stack_TemplateIDs
Collects the IDs of the configuration templates defined
for Trade3_Software_Stack.
_T3_Install_Restart_Node
Restarts the new node manager to activate the new
settings.
_T3_Install_Start_AppServer
Starts the WebSphere Application Server on which the
Trade3 application runs after all the installation steps
are complete.
_T3_Install_Ping_Trade3
Verifies that the Trade3 application is active after the
installation is complete.
_T3_Install_Complete_Process
Executes the entire provisioning process of the Trade3
application into the existing application cluster.
_T3_Uninstall_Remove_Node
Removes the node from the WebSphere Application
Server application cluster during deprovisioning.
_T3_Uninstall_Remove_DB2Catalog
Removes the database node and database catalog
information during the deprovision process.
_T3_Uninstall_Complete_Process
Executes all of the _T3_Uninstall workflows in the
correct order to deprovision a node from the
WebSphere Application Server cluster.
Getting access to the target server
From the list in Table 1, it is obvious that in order to install the Trade3 application,
we need to perform certain operations on the target server itself. Among these
are copying files and executing commands. In order to gain access to the target
server, a service access point (SAP) has to be defined for the target server. This
SAP defines the credentials to be used for specific protocols used to facilitate the
various types of actions performed against the target system.
30
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
As part of the preparation of the servers in the resource pool (WAS51 Pool
resource pool in our environment) supporting our Trade3 application, default
credentials have been defined in the service access point for each server.
In the following sections, we describe the functions of the workflows defined in
Table 1 in greater detail and the relationships between them.
The _T3_Install_Ping_NDM workflow
This workflow verifies that the WebSphere Application Server Network
Deployment server is started prior to beginning the process of deploying a new
server to the application cluster.
The main operations of this workflow are:
1. Gathers data.
2. Sets up the command to be executed.
3. Executes the wget command to verify that the WebSphere Application Server
Network Deployment administrative console is active.
The _T3_Install_Collect_Trade3DB_Attributes workflow
This workflow acquires the information needed to successfully catalog the
database on the target server in preparation for the Trade3 application
installation.
This workflow is called from the following workflow:
򐂰 _T3_Install_DB2Catalog
The main operation is:
򐂰 Creates an array and inserts the required DCM information into it, based on
the supplied software resource template ID.
The _T3_Install_DB2Catalog workflow
This workflow creates the local database catalog on the new server for use as a
JDBC resource in WebSphere Application Server.
The main operations are:
1. Gathers data from the configuration templates.
2. Prepares the commands to be executed.
3. Executes the command to locally catalog the database server node and
database on the target server.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
31
The _T3_Install_Get_NDM_Server_Attributes workflow
This workflow gathers required information about the WebSphere Application
Server Network Deployment server managing the existing Trade3 application
cluster.
This workflow is called from:
򐂰 _T3_Install_AddNodetoCell
򐂰 _T3_Install_AddNodetoWASCluster
򐂰 _T3_Install_JDBCResourcetoWAS
򐂰 _T3_Install_AddJMSResourcetoWAS
򐂰 _T3_Install_Ping_NDM
The main operations are:
1. Queries the supplied configuration template ID for the WebSphere Application
Server Network Deployment server’s name.
2. Uses that information to acquire the server ID with the DCMQuery command.
The _T3_Install_Get_NDM_Software_Attributes workflow
This workflow gathers information about the software running on the WebSphere
Application Server Network Deployment server managing the existing Trade3
application cluster.
This workflow is called from:
򐂰 _T3_Install_AddNodetoCell
򐂰 _T3_Install_Ping_NDM
The main operation is:
򐂰 Gathers information about the software running on the WebSphere
Application Server Network Deployment server.
The _T3_Install_AddNodetoCell workflow
This workflow adds the new server being provisioned to the WebSphere cell
containing the Trade3 application cluster.
The main operations are:
1. Gathers data through the _T3_Install_Get_NDM_Software_Attributes and
_T3_Install_Get_NDM_Server_Attributes workflows to format the command
to add the new server to the existing cell.
2. Executes the command to add the new server to the existing cell.
32
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
The _T3_Install_Execute_Wsadmin workflow
This workflow provides the interface from Tivoli Intelligent Orchestrator to
WebSphere Application Server.
We created this workflow by modifying the workflow
IBMWAS_Execute_Wsadmin, which is provided by the WebSphere Application
Server automation package. We simplified and adapted the
IBMWAS_Execute_Wsadmin workflow to run on a Windows environment.
This workflow is called from:
򐂰 _T3_Install_AddNodetoWASCluster
򐂰 _T3_Install_JDBCResourcetoWAS
򐂰 _T3_Install_AddJMSResourcetoWAS
The main operations are:
1. Gathers required information to execute the wsadmin command. This includes
arguments for the wsadmin command such as Jacl scripts.
2. Executes the wsadmin command using acquired arguments.
The _T3_Install_Get_Trade3_Attributes workflow
This workflow gathers required installation parameters for the Trade3 application
from a configuration template.
This workflow is called from:
򐂰 _T3_Install_AddNodetoWASCluster
򐂰 _T3_Install_JDBCResourcetoWAS
򐂰 _T3_Install_AddJMSResourcetoWAS
򐂰 _T3_Install_Ping_Trade3
The main operations are:
1. Gathers data.
2. Creates an array and inserts information into the array to be used for the
Trade3 application installation and configuration.
The _T3_Install_AddNodetoWASCluster workflow
This workflow uses the information acquired by the NDM attribute workflows
described earlier to add the new machine being provisioned to the existing
Trade3 application cluster.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
33
The main operations are:
1. Gathers data.
2. Prepares the command and arguments that will be used to add the node to
the existing Trade3 application cluster.
3. Executes the AddNode command to add the node to the cluster.
The _T3_Install_JDBCResourcetoWAS workflow
This workflow configures a JDBC resource for use by the new server being
provisioned. If the JDBC resources have been defined at a cell level during the
original installation of the Trade3 application cluster, this step might not be
necessary.
The main operations are:
1. Gathers data.
2. Prepares arguments for the wsadmin command.
3. Calls the _T3_Install_Execute_Wsadmin workflow and provides the
arguments to add the JDBC resource on the target server.
The _T3_Install_AddJMSResourcetoWAS workflow
This workflow adds JMS services required for Trade3 to the WebSphere
configuration.
The main operations are:
1. Gathers data.
2. Prepares arguments for the wsadmin command.
3. Calls the _T3_Install_Execute_Wsadmin workflow and provides the
arguments to add the JMS resource on the target server.
The _T3_Install_Collect_Trade3Stack_TemplateIDs workflow
This workflow gathers the IDs of the configuration templates defined for the
Trade3_Software_Stack software stack.
The main operations are:
1. Performs a DCMQuery command to obtain an array containing all the cloned
configuration template IDs for the software stack.
2. Collects the IDs of the configuration templates of interest to the particular
operation.
34
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
The _T3_Install_Restart_Node workflow
This workflow restarts the node manager on the server being provisioned to
ensure that all the configuration changes made are available to the Trade3
application.
The main operations are:
1. Using the device ID of the new server, runs a simple command to stop the
node agent.
2. Using the same device ID, runs a command to start the node agent.
The _T3_Install_Start_AppServer workflow
This workflow ensures that the IBM WebSphere application server on which the
Trade3 application runs is started after the deployment completes.
The main operations are:
1. Gathers data.
2. Prepares the startServer command arguments.
3. Executes the WebSphere Application Server startServer command.
The _T3_Install_Ping_Trade3 workflow
This workflow verifies that the Trade3 application is up and running after the
deployment is complete and the application server has been started.
The main operations are:
1. Gathers data.
2. Prepares arguments for the command to be executed.
3. Executes a wget command with arguments to verify the Trade3 operation on
the new server.
4. Executes the wget command to verify that the Trade3 application is running
and its URL is active.
The _T3_Install_Complete_Process workflow
This workflow provides the framework for the entire provisioning process of the
Trade3 application into the existing application cluster.
This workflow implements the SoftwareInstallable.Install logical operation.
The main operations are:
1. Gathers data.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
35
2. Calls other workflows in the proper order to complete the provisioning
operation.
The _T3_Uninstall_Remove_Node workflow
This workflow removes the provisioned WebSphere Application Server node
from the Trade3 application cluster when it is no longer needed.
This workflow is called from:
򐂰 T3 Uninstall Complete Process
The main operations are:
1. Gathers data.
2. Prepares arguments.
3. Executes the removeNode command on the provisioned server to remove the
node from the cluster of which it is a member.
The _T3_Uninstall_Remove_DB2Catalog workflow
This workflow removes the database node and database catalog settings from
the target server during the deprovisioning operation.
This workflow is called from:
򐂰 _T3_Uninstall_Complete_Process
The main operations are:
1. Gathers data.
2. Prepares arguments for the commands to be executed.
3. Executes the commands on the target server to remove the database and
node catalog to clean up during the deprovisioning process.
The _T3_Uninstall_Complete_Process workflow
This workflow combines the operations of both of the other uninstall workflows so
that no interaction is required to complete the process.
The main operations are:
1. Gathers data.
2. Calls other workflows in the proper order to complete the deprovisioning
operation.
36
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Automation package assembly and installation
The current implementation of an automation package contains the binaries and
metadata information that is related to specific objects in the DCM. In this
scenario, these objects represent the entire infrastructure defined for the Trade3
application cluster in our DCM. In this section, we present the required tasks to
create an automation package for the provisioning and deprovisioning of Trade3
in our environment.
As per the IBM Tivoli Provisioning Manager 3.1.0 Workflow Developer's Guide,
GC32-1662, guidelines, the following activities must be completed before
creating the automation package for our Trade3 application:
1. Define the processes for installing the software and any other operations that
are required for provisioning and deprovisioning the application.
2. Create the software definition, installable file, and the file repository that
stores the software package in the DCM.
3. Create the workflows for the identified procedures.
4. Determine the device models.
5. Create the automation package.
At this stage in our scenario, we already performed steps 1, 2, and 3, as
described in earlier sections.
The automation package has to provide a new device model for the Trade3
application. We named our device model ITSO_Trade3_Web_Application and
chose to define this new device model under the Software Products device
model category. The ITSO_Trade3_Web_Application device model implements
the SoftwareInstallable.Install logical operation.
Now, we are ready to create the automation package. To accomplish this task,
we use the Automation Package Development Environment (APDE), a plug-in for
Eclipse. To view the instructions for installing the APDE, see the Tivoli Intelligent
Orchestrator Information Center at:
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?toc=/com.i
bm.tivoli.tio.doc/tio_nav.xml
After the APDE is installed, you can follow the instructions for creating a new
project. When the project has been created, you can add workflows to the project
either by creating them within the APDE, or by importing them from files you have
saved somewhere else if you have created them previously using a text editor or
the Tivoli Intelligent Orchestrator workflow composer.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
37
After all of the required files for your automation package are present within the
project and tested, you can build your automation package file. You begin this
process by right-clicking the build.xml file in your project, selecting Run, and
then selecting the second Ant Build from the menu. After the Modify attributes
and launch window opens, as shown in Figure 15, you can select the required
options and attributes, and then click Run to build the automation package file.
Figure 15 also shows the APDE with our workflows for the Trade3 scenario prior
to building the automation package file.
Figure 15 Automation Package Development Environment
In Figure 16, we show the APDE workspace post-Ant Build process. You can
now see that in the left pane at the bottom of our project we have an automation
package for Trade3, named ITSO_TRADE3_310.tcdriver.
38
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
The automation package file now can be installed onto a working Tivoli Intelligent
Orchestrator server for use. In the right pane of Figure 16, we show a portion of
the manifest file created by the Ant Build process. This file identifies all the
requirements and characteristics of the automation package. It lists the scripts,
workflows, and any other files you need to include with the installation of the
package and the final destination of the files. It also includes the device model
definitions that need to be implemented by this package.
Figure 16 Automation Package Development Environment with ITSO_TRADE3_310 driver built
This automation package file can be installed either using the APDE or using the
automation package manager, described in “Prerequisite automation packages
verification” on page 10.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
39
Scenario execution
In this section, we show an execution of a provisioning operation of a server to
the Trade3 application cluster described in “Scenario overview” on page 2. This
is done in accordance to our scenario implementation description shown in “Our
intent” on page 3.
During our initial setup and configuration, we created entries in our data center
model for our J2EE application, which we describe in “Data center modeling” on
page 12. One of the steps we completed was the definition of the Trade3
application. This application contains three tiers, one of which is the Trade3 Web
APPL Servers application tier, the focus of this scenario. This application tier has
a simulator device model associated with it from the initial setup. After the
automation package is completed and installed, we have to change the device
model association for our application tier to be the one used to perform the
operations that provision the server to the application tier and implement the
Cluster.AddServer logical operation. Also, the workflows that perform the
installation of the Trade3 application must be associated to this application tier.
In this section, we provide information and screen captures that document the
process to provision a server into the Trade3 application tier.
As mentioned in “Software definitions” on page 19, we also changed the
TRADE3 software definition by associating the device driver
ITSO_Trade3_Web_Application to the software installable definitions of the
Trade3 software module, as shown in Figure 17. This association enables Tivoli
Intelligent Orchestrator to perform installations of Trade3 software using the
SoftwareInstallable.Install logical operation implemented by the
_T3_Install_Complete_Process workflow.
Figure 17 shows a device driver association to the Trade for Windows software
installable definition of the TRADE3 software definition.
Figure 17 Device driver association
Figure 18 shows the Trade3 WebAPPL Servers tier. The tier is shown in its
original state, without any provisioning operation being performed. It contains
40
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
only the two original dedicated servers, as shown in “Scenario overview” on
page 2.
Notice the locks on the icons and the lack of resource pool identifiers, confirming
their status as dedicated to this particular tier.
Figure 18 Trade3 Application Tier before provisioning action
Figure 19 shows the members of the TradeCluster defined in the WebSphere
Application Server cluster. You can see the cluster called TradeCluster and its
members before any provisioning operations have occurred. It shows the two
original members of the cluster configured during the initial installation of the
clustered Trade3 application environment.
Figure 19 WebSphere TradeCluster members before provisioning operation
Figure 20 shows the WAS51 Pool resource pool, also in its original
preprovisioning state. These are the servers that have been made available to
our J2EE application server tier for provisioning.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
41
Figure 20 The WAS51 Resource Pool
The provisioning operation of a server into the Trade3 application cluster begins
when the cluster workload reaches a predetermined utilization threshold.
As Tivoli Intelligent Orchestrator identifies the server or servers to be provisioned
from the defined resource pool to the respective application tier, Tivoli Intelligent
Orchestrator starts the execution of workflows associated to the device driver
assigned to the application tier. In our environment, these include the workflows
developed for provisioning Trade3 into our WebSphere Application Server
application cluster.
It is important to notice that all operations executed by these workflows are
based on information gathered from the DCM, such as software module
definitions, software configuration templates, and software installation definitions.
The provisioning of the Trade3 application is triggered by the
_T3_Install_Complete_Process workflow. This workflow starts by executing
cluster verification tasks such as the verification of an active WebSphere
Application Server Network Deployment manager executing the
_T3_Install_Ping_NDM workflow.
During the provisioning process, the _T3_Install_Complete_Process workflow
executes several operations, including access to the database for the Trade3
application. This is accomplished by cataloging the proper node and database
using the _T3_Install_DB2Catalog workflow. Example 4, shows the both the
node and the database catalog that now exist on our target server, prov004.
42
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Example 4 DB2 catalogs created by the workflow for Trade3
C:\IBM\SQLLIB\BIN>db2 list database directory
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias
Database name
Node name
Database release level
Comment
Directory entry type
Catalog database partition number
Alternate server hostname
Alternate server port number
=
=
=
=
=
=
=
=
=
TRADE3DB
TRADE3DB
PROV003
a.00
Remote
-1
C:\IBM\SQLLIB\BIN>db2 list node directory
Node Directory
Number of entries in the directory = 1
Node 1 entry:
Node name
Comment
Directory entry type
Protocol
Hostname
Service name
=
=
=
=
=
=
PROV003
LOCAL
TCPIP
prov003
50000
Our provisioning operation proceeds by preparing the target server to become
part of the Trade3 application cluster. This is performed by two workflows:
򐂰 The _T3_Install_AddNodetoCell workflow runs the addNode command on the
target server, allowing the target server to be part of the WebSphere
Application Server controlled cell.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
43
򐂰 The _T3_Install_AddNodetoWASCluster workflow executes the wsadmin
command to add the target server to the Trade3 application cluster controlled
by the WebSphere Application Server Network Deployment manager. After
the target server is added to the Trade3 application cluster, all the software for
the cluster is also installed on the target server by WebSphere Application
Server Network Deployment, which includes the Trade3 J2EE application.
Figure 21 shows the WebSphere Application Server administrative console
again, after the provisioning operations performed by the
_T3_Install_AddNodetoCell and _T3_Install_AddNodetoWASCluster workflows
have completed. Notice the additional member now present in the TradeCluster
configuration.
Figure 21 WebSphere TradeCluster members post-provisioning operation
The next step of the provisioning process is to define the JMS resource
configuration in WebSphere Application Server for the target server. This is
accomplished by the _T3_Install_AddJMSResourcetoWAS workflow.
After completing all the configuration for both WebSphere Application Server on
the target server and WebSphere Application Server Network Deployment
manager, the node and application server running on the target server are
restarted using the _T3_Install_Restart_Node and _T3_Install_Start_AppServer
workflows, respectively.
The last step of our provisioning process is to perform a verification of the status
of the Trade3 application on the new server. The _T3_Install_PingTrade3
workflow issues a wget command against the URL of the target server on which
Trade3 is supposed to be available. If you receive a positive response, the
provisioning operation completed successfully.
After the provisioning operations complete, the Trade3 WebAPPL Servers
application tier will have an additional server or servers added to it. In Figure 22,
44
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
we show the application tier for the Trade3 application after the provisioning
operations have completed. You can now see that the server prov004 has been
allocated to the application tier.
Figure 22 Trade3 WebAPPL Servers tier with provisioned server
Tivoli Intelligent Orchestrator also performs a verification on the software
installed in the provisioned server against the server template defined for the
application tier, in this case, the template Trade3_Server_Template. Figure 23
shows the result of the verification, displaying the provisioned server software
resources in compliance with the server template after the provisioning
operation.
Figure 23 Software compliance verification
At this point, no further action is necessary. The Trade3 application cluster now
has an additional server configured and available to assist with the additional
load as it is needed. This change has been recorded by both WebSphere
Application Server Network Deployment and Tivoli Intelligent Orchestrator, and
the information is presented by both correctly in real time.
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
45
When the need no longer exists, or when we decide the application tier is no
longer required, the server can be deprovisioned using the workflows that we
described in Table 1 and “Workflow design and development” on page 28. In this
case, the target server will then be returned to the respective resource pool,
where it can used again when the need arises.
46
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.
Edson Manoel is a Certified IT Specialist at IBM working in the ITSO, Austin
Center, in the systems management area. Prior to joining the ITSO, Edson
worked in the IBM Software Group, Tivoli Systems, and in IBM Brazil Global
Services Organization. He was involved in numerous projects in designing and
implementing systems management solutions for IBM clients and Business
Partners. Edson holds a Bachelor of Science degree in applied mathematics
from Universidade de Sao Paulo, Brazil.
Dan LaDore is a Systems and Network Administrator on the WebAhead team,
which is under the CIO. He has been helping WebAhead spread advanced
Internet technology throughout IBM for more than six years. Dan is responsible
for maintaining the infrastructure in the WebAhead lab in Southbury, CT. A large
part of this includes supporting and monitoring WebAhead’s many applications. It
also includes designing, building, and supporting an infrastructure that keeps the
WebAhead lab up to date technologically, including all server and network
hardware and software. Before moving to the WebAhead lab, Dan’s job was to
provide support to the Internet2 community for IBM. This included infrastructure
and demo support, and working with the IBM loaner program to provide
equipment to the universities and facilities with which IBM collaborated. Dan was
also responsible for planning demonstrations of IBM technologies at multiple
Internet2-centric trade shows and meetings.
Thanks to the following people for their contributions to this project:
Morten Moeller
ITSO Project Leader, Austin Center
Theo Winkelmann
WW Orchestration and Provisioning Technical Evangelist
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
47
Additional material
This Redpaper refers to additional material that can be downloaded from the
Internet as described here.
Locating the Web material
The Web material associated with this Redpaper is available in softcopy on the
Internet from the IBM Redbooks™ Web server. Point your Web browser to:
ftp://www.redbooks.ibm.com/redbooks/REDP4097
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with
the Redpaper form number, REDP4097
Using the Web material
The additional Web material that accompanies this Redpaper includes the
following file:
File name
REDP4097.zip
Description
Zipped source code and executable files developed for
the examples described in the sections of this Redpaper.
System requirements for downloading the Web material
The following software configuration is required:
򐂰
򐂰
򐂰
򐂰
IBM Tivoli Intelligent Orchestrator V3.1 with Fix Pack 1 installed
IBM WebSphere Application Server V5.1
IBM DB2 Universal Database Enterprise Server Edition V8.2
IBM WebSphere Application Server Network Deployment V5.1
How to use the Web material
Create a subdirectory (folder) on your workstation, and unzip the contents of the
Web material ZIP file into this folder.
The resulting directory will contain the automation package created during the
development of this Redpaper. Follow the instructions provided in the
corresponding sections.
48
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright IBM Corp. 2005. All rights reserved.
49
Send us your comments in one of the following ways:
򐂰 Use the online Contact us review redbook form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. JN9B Building 905, 11501 Burnet Road
Austin, Texas 78758-3493 U.S.A.
®
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
DB2®
DB2 Universal Database™
IBM®
ibm.com®
Redbooks™
Redbooks (logo)
Tivoli®
WebSphere®
™
The following terms are trademarks of other companies:
EJB, Java, JDBC, J2EE, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.
Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
Intel, Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks
of Intel Corporation or its subsidiaries in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
50
Provisioning J2EE Applications with IBM Tivoli Intelligent Orchestrator