128 IBM Enterprise Workload Manager
5.4.1 Identifying the transactions that request business functions
The first step of the design phase is to identify and classify the transactions.
It is difficult to identify all transactions in a distributed environment even if the EWLM
management domain consists only of a few servers like in our test environment. The easiest
way is to interview the application developer and ask the following questions:
? How do clients use this application?
? What type of applications access this middleware?
However, if you do not get answers to those questions you are in the same situation as we are
with our test environment. We therefore provide an example study for such a case, describing
how to identify transactions. It is, of course, dependent on your application environment.
To create transaction classes, you have to identify an edge application first since all work
requests are classified to service classes by EWLM by its edge application. It is the entry
point of your applications as described at 1.2, “EWLM concepts” on page 5. When we set up
our servers, operating systems, middleware, applications, and firewall in our environment, we
already know that the edge server of both Trade3 and Plants by WebSphere is the IBM HTTP
Server. In the next section we describe how to find an edge server if such reference
information is not available.
The overall process of identifying the transactions that request business functions involves
the following steps:
1. Identifying an edge server of the work request
2. Identifying transactions
3. Defining transaction classes
4. Mapping transaction classes to service class
Identifying an edge server of the work request
EWLM provides an application topology view which is a high-level view of the EWLM domain
from a business transaction perspective. We use this view and an EWLM sample domain
policy, Sample Banking Domain Policy, to identify the edge application of the work request.
While using this policy, all work requests we generate are classified to a default transaction
class in the domain policy because there is no transaction class suitable for our work request.
There are, by default, three transaction classes for each application respectively:
? Default - IBM DB2 Universal Database
? Default - IBM Webserving Plugin
? Default - WebSphere
These transaction classes have the same classification filter, (*) Equal (*), that matches
to a work request which does not match any other transaction class filters. For more
information on how filters work, refer to 4.2.1, “Classifying your workload” on page 88.
Tip: You can use EWLM default domain policy in this step, although we used Sample
Banking Domain Policy. If the EWLM domain does not have an active service policy, the
EWLM domain uses the default service policy, which consists of a discretionary goal for all
transactions, but you cannot use the default policy once you have deployed some policy to
your domain; it’s gone.
Chapter 5. The ITSO EWLM scenario 129
Once the work request is classified by EWLM, the Response time and Entry application
columns of the Transaction Classes monitor display some information as shown in Figure 5-4.
We can also identify the edge application using the transaction class’ application topology
view, which is automatically generated by EWLM once we have a flow of transactions.
Figure 5-4 Transaction classes monitor at the EWLM Control Center
To identify an edge application in our environment we need to follow these steps:
1. Deploy Sample Banking Domain Policy.
2. Run the workload to Trade3 and Plants by WebSphere.
3. Identify an edge server.
Deploy Sample Banking Domain Policy
To deploy Sample Banking Domain Policy:
1. Log in to the EWLM Control Center as a user who has the administrator role. In our case it
is user ewlmadm.
2. Click Domain policies on the navigation panel and select Sample Banking Domain
Policy.
3. Select Deploy from the action list and click Go.
4. Select Banking 2004 Service Policy to activate and click Deploy.
You can verify deployed domain policy and activated service policy at the bottom of the
EWLM Control Center banner area as shown in Figure 5-5.
Figure 5-5 Current domain policy and active service policy
Run the workload to Trade3 and Plants by WebSphere
To make EWLM detect a work request and classify it to transaction class, we have to run
some workload to the Trade3 and Plants by WebSphere applications. We use WebSphere
Studio Workload Simulator for z/OS and OS/390 to generate the workload.
Our workloads have the following properties:
? Total number of concurrent users is 300.
130 IBM Enterprise Workload Manager
? A user session for Trade3 includes:
– Log into and log out from Trade3
– Go to home page of Trade3
– Update account information
– Register new account to Trade3
– Buy, sell, and quote stocks
– View portfolio
? A user session for Plants by WebSphere includes:
– Log into Plants by WebSphere
– Go to each section: Flowers, Fruits & Vegetables, Trees and Accessories
– Buy some stuff from each section
– View shopping cart
– Check out and log out from Plants by WebSphere
We do not provide details on how to configure and use this product. For more information,
refer to the IBM WebSphere Studio Workload Simulator for z/OS and OS/390 home page at:
http://www.ibm.com/software/awdtools/studioworkloadsimulator/
Identify an edge server
Now we can identify an edge application using the application topology view:
1. Log in to the EWLM Control Center as the user who has monitor role. In our environment
this is user ewlmmon. However, users with administrator and operator role, like ewlmadm
and ewlmops, can also view the monitor sections.
2. Click Transaction classes on the navigation panel.
We can see that only the Default - IBM Webserving Plugin transaction class has a
response time. This represents the general classification filter for a work request whose
entry application is IBM HTTP server, as shown in Figure 5-6. If you were able to get a
response time for either the WebSphere or DB2 transaction class this would then
represent your entry application.
Figure 5-6 Transaction class which receives work request
Note: You have to run the workload longer than the interval preference specified in the
EWLM Control Center in order to detect your edge application successfully. Refer to 4.1,
“EWLM Control Center overview” on page 78 for more information.
Chapter 5. The ITSO EWLM scenario 131
We have identified our edge application and want to view the application topology of this
transaction class. We issue the following:
3. Select Default - IBM Webserving Plugin.
4. Select Application Topology from the action list and click Go.
A new browser window appears and you may see an application topology like the one we
show in Figure 5-7. This is a topology view of both Trade3 and Plants by WebSphere at this
point. The edge application is the IBM HTTP Server that marks the left side bound of the
topology. This application topology is determined by EWLM itself. All we did was run some
transactions for Trade3 and Plants by WebSphere.
Figure 5-7 Application topology of Default - IBM Webserving Plugin transaction class
If your edge server is WebSphere Application Server you see an application topology as
shown in Figure 5-8.
Figure 5-8 Application topology sample of Default - WebSphere transaction class
If your edge application is DB2, the Default - IBM DB2 Universal Database transaction class
receives work requests. The application topology looks as shown in Figure 5-9.
Figure 5-9 Application topology sample of Default - DB2 transaction class
Identifying transactions
In the previous section we provided you with a method to identify your edge application. In our
environment we found that the edge application is the IBM HTTP Server. We now attempt to
identify transactions using the IBM HTTP Server access log file in order to classify
transactions.
Note: The steps described in the following discussion may not be suitable for your Web
application. Each customer environment has unique implementations as well as
requirements. Take those needs into account when you identify transactions.
132 IBM Enterprise Workload Manager
Web applications provide business functions to customers by processing their HTTP requests
from a Web browser by invoking servlets or JSPs and returning results to the Web browser.
For example, when the client requests, the application server forwards it to an appropriate
servlet using a requested URI which might be:
/context-root/servlet-name?key1=value&key2=value2
Context root (context-root) is the root part of the URI and is unique among all Web
applications within the same application server cell or application server. Servlet name
(servlet-name) or query string (key1 or key2) often represents which business function is to
be invoked in the Web application specified by the context root. Thus we can use them to
identify transactions. They are logged in the IBM HTTP Server access log file.
We transfer the IBM HTTP Server access log file from the IBM HTTP Server (Windows) to our
Linux machine using FTP, because Linux has good text processing utilities such as grep, awk,
sed or perl and we are familiar with them. Click Start
→ Programs → Accessories →
Command Prompt and follow the sequence shown in Example 5-1.
Example 5-1 Transfer IBM HTTP Server access log file from Windows to Linux
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:Documents and Settingsuserid00>cd C:Program FilesIBM HTTP Server 2.0logs
C:Program FilesIBM HTTP Server 2.0logs>ftp ewlmdm1.itso.ibm.com
Connected to ewlmdm1.itso.ibm.com.
220 ewlmdm1.itso.ibm.com FTP server (Version wu-2.6.1-20) ready.
User (ewlmdm1.itso.ibm.com:(none)): ibmewlm
331 Password required for ibmewlm.
Password: ******
230 User ibmewlm logged in.
ftp> put access.log
200 PORT command successful.
150 Opening ASCII mode data connection for access.log.
226 Transfer complete.
ftp: 19659 bytes sent in 0.00Seconds 19659000.00Kbytes/sec.
ftp> bye
We use grep to print lines which contain a “?” character in the IBM HTTP Server access log
file in order to remove requests for static content such as HTML pages or images. We found
that both Trade3 and Plants by WebSphere seem to use the servlet name and action
parameter to determine which business function is to be invoked as shown in Example 5-2.
Example 5-2 IBM HTTP Server access log file
[root]# grep ’?’ access.log
9.12.4.54 - - [14/May/2004:14:09:49 -0400] "GET /trade/app?action=quotes&symbols
=s:754 HTTP/1.1" 200 5177
9.12.4.54 - - [14/May/2004:14:09:49 -0400] "GET /trade/app?action=buy&symbol=s:1
00&quantity=21 HTTP/1.1" 200 3057
9.12.4.54 - - [14/May/2004:14:09:49 -0400] "GET /trade/app?action=quotes&symbols
=s:835 HTTP/1.1" 200 3057
9.12.4.54 - - [14/May/2004:14:09:49 -0400] "GET /trade/app?action=portfolio HTTP
/1.1" 200 3057
9.12.4.54 - - [14/May/2004:14:09:49 -0400] "GET /trade/app?action=quotes&symbols
=s:724 HTTP/1.1" 200 5182
9.12.4.54 - - [14/May/2004:14:09:49 -0400] "GET /trade/app?action=home HTTP/1.1"
200 3057
9.12.4.54 - - [14/May/2004:14:09:50 -0400] "GET /trade/app?action=home HTTP/1.1"
200 13411
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.