Front cover
Managing an SOA
Environment with
Tivoli
Discusses SOA performance and
availability management
Describes mediation scenarios
with ESB and message broker
Integrates ITCAM and
other Tivoli solutions
Budi Darmawan
Pradeep Nambiar
Prem Lall
Ravinder Gummadavelli
ibm.com/redbooks
Redpaper
International Technical Support Organization
Managing an SOA Environment with Tivoli
April 2008
REDP-4318-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page vii.
First Edition (April 2008)
This edition applies to:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
IBM Tivoli Composite Application Manager for WebSphere V6.1, 5724-L62
IBM Tivoli Composite Application Manager for Web Resources V6.2, 5724-S32
IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 FP2, 5724-L99
IBM Tivoli Composite Application Manager for Response Time V6.2, 5724-C04
IBM Tivoli Composite Application Manager for SOA V6.1 FP2, 5724-M07
IBM Tivoli OMEGAMON XE for Messaging V6.1
WebSphere Enterprise Service Bus and WebSphere Process Server V6.1
WebSphere Message Broker V6.0
WebSphere Services Registry and Repository V6.0.2
© Copyright International Business Machines Corporation 2008. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this paper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1. Introduction to SOA management. . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Introduction to SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 SOA application principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 SOA constructs and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 SOA governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Web Services life cycle governance . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Web Services life cycle management . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 SOA management considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Users of SOA management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.1 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6.2 Middleware or application subject matter expert . . . . . . . . . . . . . . . . 11
1.6.3 Performance analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.4 System administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.5 Enterprise system management architect . . . . . . . . . . . . . . . . . . . . . 14
1.6.6 Web Services application developer . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6.7 Business executives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.7 Management needs for the SOA environment . . . . . . . . . . . . . . . . . . . . . 16
1.7.1 Web Services metric data collection . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.7.2 Web Services troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7.3 Displaying data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7.4 Mediation management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 2. Tivoli application management products . . . . . . . . . . . . . . . . . 19
2.1 ITCAM for SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Product features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Product components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 ITCAM for WebSphere and ITCAM for J2EE . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Architecture and interconnection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.2 The managing server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3 J2EE and WebSphere data collectors . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.4 Tivoli Enterprise Monitoring Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 32
© Copyright IBM Corp. 2008. All rights reserved.
iii
2.3 ITCAM for Response Time Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 The management server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.2 Store and forward agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.3 Management agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.4 Tivoli Enterprise Monitoring Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4 OMEGAMON XE for Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.1 WebSphere MQ configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.2 WebSphere MQ monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4.3 WebSphere Message Broker monitoring . . . . . . . . . . . . . . . . . . . . . 46
Chapter 3. Basic SOA and Web Services management. . . . . . . . . . . . . . . 49
3.1 Basic monitoring concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Performance metric of Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3 Generating events and alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4 Managing Web Services response time . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.1 Execution environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.2 Creating Rational Performance Tester script . . . . . . . . . . . . . . . . . . 56
3.4.3 Defining Web Response Monitor policies . . . . . . . . . . . . . . . . . . . . . 59
3.4.4 Reports generated from the policies . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.5 Tivoli Enterprise Portal workspaces . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.5 Debugging performance of Web Services. . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6 Understanding Web Services calling pattern . . . . . . . . . . . . . . . . . . . . . . 74
3.6.1 Turning on the content logging for a Web Service . . . . . . . . . . . . . . 74
3.6.2 Using the Log Assembler tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.7 Working with Web Services filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.8 Web Services life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Chapter 4. Advanced SOA management . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.1 Mediation and SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.2 Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.3 Maintaining Web Services continuity. . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.3.1 Register TraderDBServices in the registry . . . . . . . . . . . . . . . . . . . 106
4.3.2 Developing managed SCA mediation with ITCAM for SOA . . . . . . 110
4.3.3 Deploying the mediation application . . . . . . . . . . . . . . . . . . . . . . . . 126
4.3.4 Verifying the service invocation with mediation. . . . . . . . . . . . . . . . 132
4.4 Service monitoring automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.4.1 Automation principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.4.2 Update service metadata utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.4.3 ITCAM for WebSphere and ITCAM for Web Resources situations. 139
4.4.4 ITCAM for SOA situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.4.5 Verifying situation automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
4.5 Using managed message logger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
4.5.1 Viewing the message data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
iv
Managing an SOA Environment with Tivoli
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Chapter 5. Managing an SOA application in a business context . . . . . . 159
5.1 Solution overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
5.2 Tivoli EIF probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.3 Defining situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
5.4 Designing business services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.5 Defining service level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
5.6 Getting the business status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Appendix A. The Trader application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Portal interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Front-end J2EE Web application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Java desktop application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Back-end implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Back-end J2EE servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
WebSphere Enterprise Service Bus mediation . . . . . . . . . . . . . . . . . . . . . 190
WebSphere Message Broker mediation . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Runtime environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Appendix B. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
System requirements for downloading the Web material . . . . . . . . . . . . . 198
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Contents
v
vi
Managing an SOA Environment with Tivoli
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 illustrate 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.
© Copyright IBM Corp. 2008. All rights reserved.
vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
z/OS®
Alerts®
AIX®
Cloudscape®
CICS®
DataPower®
®
DB2®
ETE™
IBM®
IMS™
MQSeries®
MVS™
OMEGAMON®
OS/400®
Rational®
Redbooks®
RACF®
Tivoli Enterprise Console®
Tivoli®
WebSphere®
The following terms are trademarks of other companies:
SAP NetWeaver, SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and
in several other countries.
Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation
and/or its affiliates.
ITIL is a registered trademark, and a registered community trademark of the Office of Government
Commerce, and is registered in the U.S. Patent and Trademark Office.
Enterprise JavaBeans, EJB, Java, JavaBeans, JDBC, JMX, JNI, JRE, JVM, J2EE, Solaris, Sun, Sun Java,
and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Internet Explorer, Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation 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.
viii
Managing an SOA Environment with Tivoli
Preface
Service-oriented architecture (SOA) is a major new trend for application
architecture. It allows you to build applications as components as defined by
using a Web Services Description Language (WSDL) file. You can implement
applications on multiple servers, even on multiple platforms. You can easily
modify application components and workflow logic in execution by allowing a
flexible application structure. The use of enterprise service bus (ESB) masks
the implementation of the client side and the server side. ESB allows you to
implement different servers without needing to modifying the client. Or, multiple
clients can use the same server implementation.
The highly flexible and distributed nature of SOA-based applications is its
primary strength and the source of its appeal. However, when problems arise,
this flexible nature also causes a greater challenge in pinpointing the source of a
problem. SOA also requires a disciplined management effort to ensure that
operational changes do not disrupt overall system availability.
The IBM® Tivoli® Composite Application Manager (ITCAM) family of products is
designed to assist you in managing distributed applications, including
SOA-based applications. However, the overall management of a complete SOA
management solution requires the use of several tools that work together. Each
tool addresses a different aspect of the application.
This paper illustrates the management needs for SOA-based applications and
demonstrates how Tivoli products can address your application environment
needs. The overall solution that we use includes ITCAM for SOA, ITCAM for
WebSphere®, ITCAM for Response Time Tracking, OMEGAMON® XE for
Messaging, and the Tivoli Business Service Manager solution to address various
needs in SOA-based application management.
The intended audience for this IBM Redpaper publication cis any services
specialist who implements a performance management solution for an
SOA-based environment.
The team that wrote this paper
This paper was produced by a team of specialists from around the world working
at the International Technical Support Organization, Austin Center.
© Copyright IBM Corp. 2008. All rights reserved.
ix
Budi Darmawan is a project leader at the International Technical Support
Organization, Austin Center. He writes extensively and teaches IBM classes
worldwide on all areas of Tivoli and systems management. Before joining the
ITSO eight years ago, Budi worked in IBM Indonesia services as a technical lead
and solution architect. His current interests are Java™ programming, availability
management, business service management, and z/OS® management.
Pradeep Nambiar is a Worldwide Technical Evangelist in the IBM Tivoli
Business Automation Sales Enablement group. He has over 19 years experience
in the IT industry in various areas ranging from graphics systems, networked
graphics, IBM Component Broker/WebSphere Application Server system
management, business application architecture, design, and development. He is
an IBM Certified SOA Solution Designer, IBM Certified WebSphere Enterprise
Developer, and IBM Certified Solution Developer in XML and Related
Technologies. His current focus is on application management and the
automation family of products, including SOA management from IBM Tivoli.
He is based in Austin, TX.
Prem Lall is a Software Engineer currently assigned to the ITCAM for SOA
project where he specializes in the field of Web Services management. He has
had over 15 years experience in the IT field. During his 11 years at IBM, he has
helped design and implement a variety of software products. He has expertise in
front-end, middleware, and back-end development with an emphasis on
e-commerce. Among other things, he created end-to-end online banking
solutions for IBM clients in the Integrion consortium, he has been part of the
WebSphere Application Server development team, and helped create an
extensive SOA-based e-File application for the IRS that is currently used by
numerous businesses across the country. He holds a Masters of Science Degree
in Pure and Applied Mathematics from California State University, Northridge,
CA. He also worked as an Actuary, and he has worked in the Atmospheric
Physics Division of the NASA Goddard Space Flight Center.
Ravinder Gummadavelli is a Software Engineer with IBM Systems Technology
Group, in the USA. He has over 10 years of experience in the IT Systems Design
and Development field. He holds a Masters in Technology degree in Electrical
Engineering from REC, Warangal, India, and a Masters of Science degree in
Electrical Engineering from Auburn University, Auburn, AL. His areas of
expertise include Systems Design, Development, and SOA. His current interests
include SOA and IBM Virtualization offerings.
Thanks to the following people for their contributions to this project:
Karen Durston, Mark Anderson, Jayne Regan
IBM Software Group
x
Managing an SOA Environment with Tivoli
Become a published author
Join us for a two- to six-week residency program! Help write a book dealing with
specific products or solutions, while getting hands-on experience with
leading-edge technologies. You will have the opportunity to team with IBM
technical professionals, IBM Business Partners, and Clients.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you will develop a network of contacts in IBM development labs and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about
this paper or other IBM Redbooks® publications in one of the following ways:
򐂰 Use the online Contact us review IBM Redbooks publications form found at:
ibm.com/redbooks
򐂰 Send your comments in an e-mail to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Preface
xi
xii
Managing an SOA Environment with Tivoli
1
Chapter 1.
Introduction to SOA
management
In this chapter, we explain service-oriented architecture (SOA) and walk you
through managing an SOA environment. We divide this discussion into:
򐂰 “Introduction to SOA” on page 2
򐂰 “SOA application principles” on page 2
򐂰 “SOA constructs and components” on page 4
򐂰 “SOA governance” on page 5
򐂰 “SOA management considerations” on page 7
򐂰 “Users of SOA management” on page 9
򐂰 “Management needs for the SOA environment” on page 16
© Copyright IBM Corp. 2008. All rights reserved.
1
1.1 Introduction to SOA
A service-oriented architecture (SOA) is an architecture that describes a system
that is composed of discrete services that interact with clients and accomplish
various tasks. Each service contains operations that perform a small unit of work
that corresponds to a high level definition of a given task. These services can
perform simple tasks, such as accessing data from a database and returning
data to a client, or can be part of a workflow that represents a more complex
task. A service usually either provides information or facilitates a way to modify it
in a certain way.
Although Web Services technology is commonly used to implement an SOA, it is
not required; in other words, a service does not have to use Web Services
constructs or technology. However, most SOAs rely on the standards, practices,
and tools that are available with Web Services.
Regard SOA as an approach to build distributed systems that deliver application
functionality as Web Services to user applications. Properly used, SOA principles
can provide a framework for matching business needs with realistic solutions.
Web Services is the programmatical interface to a capability that complies with
standard protocols, providing the interface technology and delivering platform
independency and loose coupling of the transport. SOA is potentially wider in its
scope of governing the policies, rules, and common services that enable logical
service bus structure for use by authorized consumers internal and external to
the enterprise regardless of implementation technology. Also, SOA enables the
design and quality of service that can be reused and that conforms to functional
and nonfunctional service level agreements (SLAs). Web Services are the
foundational interoperability technology, and SOA is the application of the
interoperability that implies considerable change in business and IT practices.
This magnitude of business and technology change requires a certain level of
management in order to successfully reap the benefits from the investment that
has been made for the change.
In this chapter, we look into the SOA structure and the management
requirements that lead to the need for this paper to define the SOA system
management environment.
1.2 SOA application principles
You can deploy an SOA-based application incrementally and slowly integrate it
into an existing environment. Developers have designed SOA scenarios to be
2
Managing an SOA Environment with Tivoli
used together or adopted incrementally. There are several well-known SOA
patterns, including:
򐂰
򐂰
򐂰
򐂰
򐂰
Service creation
Service connectivity
Interaction and collaboration services
Business Process Management
Information as a service
You can apply the SOA design, governance, security, and management across
all of these scenarios.
Applications in a typical silo architecture build their functionality on top of an
existing application stack. In an SOA-based environment, the logical boundary
between Web Services consumer and provider is defined by a business function,
not by application boundaries (typical for silo architectures):
򐂰 Separation of Web Services interface from its implementation
One of the most important aspects of SOA is that it separates a Web
Service’s implementation from its interface. A meta-language, such as Web
Services Definition Language (WSDL), can be very helpful, because it
describes a business interface that a Web Services provider can expose to a
client application and other Web Services while concealing the Web Service’s
implementation. A WSDL document acts as a server-side descriptor that
defines the Web Service’s operations and the messages they use so the
client will know how to invoke the Web Service. Web Services consumers
view a Web Services simply as an endpoint that supports a particular request
format or contract. Web Services consumers are not concerned with how the
Web Services executes their requests; they only expect that it will do so
according to the defined interface. Implementations can use anything from
Java 2 Platform, Enterprise Edition (J2EE™) entities to older code running in
a mainframe environment.
򐂰 Loose coupling
The exposed interface is purposely “loosely coupled” from the Web Services
provider so that implementations can be modified or even replaced (swapped
in and out as desired in a plug and play manner), which increases the ability
to reuse existing function. Reuse promotes increased performance, reliability,
and Quality of Service (QoS), because a common interface can be exposed
to many clients regardless of what is underneath. Reusable components do
not have to be retested as often as well. Individual Web Services are also
loosely coupled, having little or no dependencies upon each other. Web
Services must also be stateless (information or state are not preserved from
one request to another).
Chapter 1. Introduction to SOA management
3
򐂰 Business impact
Client applications in an SOA do not contain business logic; they consume
Web Services instead. Therefore, they become much smaller and easier to
implement. A shorter time-to-market for new products is an important result
for business development. SOA principles in general can help form a stronger
connection between the business needs that define the architecture and the
software and information systems that implement it. Web Services can be
created according to an abstract model that conforms to the needs of the
business. If done correctly, an abstraction can drive the concrete very
effectively.
1.3 SOA constructs and components
Standards have been developed to ensure Web Services technologies conform
to common principles. Support for Web Services interoperability, Web Services
security, sending attachments using Web Services, and Web Services
Management have been defined by organizations, such as W3C, OASIS, and so
on. Standards help ensure that Web Services products sold by different software
vendors conform to common agreed upon expectations. For example, a user
must be able to expect that a Web Services client written using Microsoft® .Net
can invoke a Web Services written using Apache Axis deployed on the
WebSphere Application Server without any complications if these tools conform
to Web Services standards.
With the advent of application server technology, Web Services can be
distributed across many machines and environments, making it easier to perform
scalability, clustering, and load balancing across your enterprise (SOA can ease
the transition away from existing systems towards modern application servers
and middleware). For example, COBOL and C++ applications that use
messaging software, such as IBM MQSeries®, can be phased out in favor of
Java applications that use SOAP/Java Message Service (JMS) and
message-driven beans (MDBs).
SOA-related constructs, such as enterprise service buses (ESBs), business
processes, and so on, can add further structure and flexibility to your architecture
by providing routing, mediation, and flow management functions. Just as you can
hide implementations from a client, transport/protocol layers and message
formats can be similarly concealed by the inclusion of an enterprise service bus.
SOAP/Java Message Service (JMS), SOAP/HTTP, Remote Method Invocation
(RMI)/Internet Inter-ORB Protocol (IIOP), XML/MQSeries, local Java calls, and
so on are all supported and transparent to the user. Often, people implement an
enterprise service bus by technologies that are found in certain
4
Managing an SOA Environment with Tivoli
middleware/infrastructure products, for example, WebSphere Enterprise Service
Bus, DataPower®, WebSphere Message Broker, and so on.
You can combine discrete Web Services into composite business processes to
accomplish more complex business objectives. As part of a business process,
individual Web Services can be viewed as activities within a workflow. This
facilitates the creation of a business process that can be described by a
meta-language called Business Process Execution Language (BPEL). Business
Process Execution Language is similar to Web Services Definition Language
(WSDL) in that it provides a static definition of a Business Process. Just as with
Web Services, the potential for reuse is quite high after these Business Process
definitions are created.
In recent years, a new method has been introduced to model Web Services in an
SOA called the Service Component Architecture (SCA). SCA components are
designed to separate implementation details from any business logic so that you
can put together an integrated application without knowing its implementation
details and make each component interoperate with any other SCA component.
Issues, such as security, transactions, and so forth, are resolved in a seamless
manner across SCA components. SCA components are often used in business
process modeling, because they provide a great deal of flexibility.
A mediation is a special type of SCA module. You can insert mediations between
loosely coupled Web Services. Introducing mediations between Web Services
provides added function for processing messages that are being passed
between these Web Services. Mediations intercept and modify messages that
are passed between existing Web Services and clients that want to use those
Web Services. Mediations are ideal for deployment in an environment that
contains an enterprise service bus, because they can reroute and examine Web
Services traffic.
1.4 SOA governance
It is important to consider both governance and management requirements when
planning an SOA.
SOA governance is an extension of IT governance that focuses on the life cycle
of Web Services and composite applications in an organization’s SOA. SOA
governance is related to establishing policies within the context of the activities
and constructs associated with SOA that are similar to those that exist for
managing and controlling other aspects of IT.
Chapter 1. Introduction to SOA management
5
Initially, the concept of SOA governance was applied narrowly to the
development and use of Web Services (validating Web Services adherence with
specific standards or managing Web Services in the SOA runtime environment).
Today, SOA governance spans SOA architecture, as well as the governance of
Web Services, across the entire implementation life cycle. Architecture
governance and Web Services-level life cycle governance are the two of the
main components of SOA governance. For the purposes of this discussion, we
will concentrate mainly on the latter.
1.4.1 Web Services life cycle governance
The goal of Web Services life cycle governance is to define:
򐂰 Decision rights for the development, deployment, and management of new
Web Services
򐂰 Monitoring and reporting processes for capturing and communicating
governance results
There are four phases of the Web Services life cycle:
򐂰 Modeling: This phase involves incorporating business requirements and
objectives into your business design so that the design becomes a
specification of business processes that achieve goals and consider
assumptions.
򐂰 Assembly: This phase centers around the information systems that will be
used to assemble the business design. Typically, an enterprise architect
working with a business analyst can convert the business design into a set
of business process definitions that are composed of activities. The required
Web Services are derived from the activity definitions and business
processes from the business process definitions.
򐂰 Deployment: This phase involves creating the environment that will host
composite Web Service-based applications and then deploying those
applications there. This phase includes identifying resource dependencies
for the application, as well as operational conditions, requirements, and
constraints that impact the successful deployment and running of the
applications.
򐂰 Management: This phase addresses the maintenance of the operational
environment and the policies that govern the deployed applications. This
phase includes monitoring the performance of Web Services requests and
responses and developing a recovery strategy for failures (detecting and
quarantining failures and logging them, rerouting traffic around failures and
recovering work affected by them, correcting problems and restoring the state
6
Managing an SOA Environment with Tivoli
of the system). The Management phase also includes tuning the operational
environment to conform to changes in the business design.
Because SOA applications are so loosely coupled, they introduce new
governance challenges. But with the proper standards, practices, and processes
in place, businesses can reap the full benefit of service orientation. Effective SOA
governance helps business and IT teams better identify how to achieve most
business goals. It also empowers employees by clearly defining their roles and
responsibilities.
1.4.2 Web Services life cycle management
After you implement the SOA governance framework, you use it in the model,
assemble, deploy, and manage phases within the SOA life cycle. With respect to
the operational aspects of implementing SOA governance, Web Services life
cycle management addresses how Web Services will be developed, deployed,
and managed.
Web Services life cycle management focuses on the development and
deployment of Web Services, while SOA governance supplies the decision
rights, processes, and policies for those activities. After a Web Services is
deployed, there must be management strategies in place to control and monitor
the Web Service. Web Services life cycle management is subject to the business
design created within the governance stage that ensures that reuse and cost
reduction are achieved.
1.5 SOA management considerations
Implementing SOA-based applications introduces new IT management
challenges. Because Web Services development tools make it easy to create
services within the SOA framework, there is a danger that services can
proliferate and become uncontrollable within the SOA enterprise, if the growth is
not managed properly. When systems are composed of multiple independent
business processes, the relationships between these processes and the
applications executing in the IT layer are not always obvious. For example,
consider verifying the correctness of a workflow in a system or locating a
performance bottleneck. While these actions are difficult in smaller systems and
might become impractical to manage as the size and complexity increases in
larger systems.
Simply stated, SOA management includes solutions and software for managing
and monitoring composite applications and the infrastructure that supports it
across the entire architecture.
Chapter 1. Introduction to SOA management
7
Considerations associated with managing an SOA environment include:
򐂰 SOA management is needed on the following scenarios:
– Defining your Web Services in a way that they can be easily managed as
resources (Service Creation)
– Defining how Web Services relate to each other (Service Connectivity and
Interaction)
– How to manage your Web Services within their deployment environment
(Governance/Management)
򐂰 The information that is needed from the management system:
– Capturing data that can be used to evaluate whether nonfunctional and
quality of service requirements as defined by business needs are
supported (reliability, scalability, cost, and so on)
– Defining which Web Services/Activities to group into Business
Processes/Workflows to accomplish a business goal (Collaboration
Services)
– Define service level agreements based on data that can be easily
monitored (average response time, maximum message size, and so on)
– Using standards whose enforcement can be monitored
– Evaluating whether your Web Services are secure (Security)
򐂰 The management environment itself must be properly evaluated.
Considerations about the management technology are:
– How to display Monitored and Registered information to users (using a
console, such as the Tivoli Enterprise Portal (TEP) or the Tivoli Enterprise
Console® (TEC)
– What technology and products to use to monitor various resources
(examples include Simple Network Management Protocol (SNMP), Java
Management Extensions (JMX™), Java API for XML-Based RPC
(JAX-RPC), Java API for XML-Based Web Services (JAX-WS), and so on)
– How can you manage infrastructure that employs tiers and clustering.
Ensuring that both Web Services providers and consumers can be
monitored. Also, resolving how to display interactions if only certain things
are managed (how do you display unmanaged clients and Web Services
that are part of the same flow)
– What are some of the various user types that you will need monitor and
administer your applications (administrators, operators, and so on)
There are number of metrics that you must monitor for a holistic application
health view in an SOA environment.
8
Managing an SOA Environment with Tivoli
These metrics include:
򐂰 Service response time
򐂰 Service request message size
򐂰 Service faults
򐂰 Real-time service performance metrics
򐂰 Application server health where the service is deployed
򐂰 Health of dependent components, such as database, messaging resources,
and so on
򐂰 Service performance metrics for historical purposes
򐂰 Service request and response message data
These metrics help measure service level agreements (SLAs) for applications.
You can use these metrics to debug performance bottlenecks in applications.
You can also use these metrics to automatically take corrective actions or initiate
failover steps to maintain service availability when the primary service provider
goes down or is not performing to meet the SLAs.
IBM Tivoli Composite Application Manager (ITCAM) for SOA and other ITCAM
offerings provide all the necessary metrics to keep the applications in an SOA
environment healthy and resilient.
1.6 Users of SOA management
There are several types of users that use SOA management and need to interact
with the SOA-based environment. In this section, we discuss the access patterns
and the needs of those users in relation to SOA management.
With any management software, a number of various personnel can be potential
users. You can have multiple user roles, and each role can be defined in part by
the user’s current job responsibilities. For example, an application developer and
a performance tester most likely are interested in viewing varying pieces of
information at different times and thus might use the same console to view
different information. Depending on their responsibilities, they might even have
different levels of access to various views. Ultimately, the roles and
responsibilities that are defined for various users will depend greatly on how a
company defines their architecture and how they want to manage it.
Chapter 1. Introduction to SOA management
9
These are possible user roles for SOA management. The primary users are likely
to be common to most organizations. There can also be secondary and
provisional users as well:
Note: We consider the user roles for managing the performance and the
availability of an SOA-based application. We do not include security
management and its roles in this paper.
򐂰 Primary users: These users are the most common in most organizations.
They have a critical need to use the SOA management tools for their
day-to-day jobs:
– Operator
– Middleware and application subject matter expert
򐂰 Secondary users: These users have supportive roles that require occasional
access to the SOA management tools. Although the tools are not a necessity
for them to perform their work, the tools greatly enhance their productivity:
– Performance analyst
– System administrator
– Web Services application developer
򐂰 Provisional users: These users also need access to SOA management only
as the need arises. These roles use SOA management rarely, and the tools
do not perform a critical role:
– Enterprise system management architect
– Business manager or executive
1.6.1 Operator
An operator or system operator is the first level of IT support personnel that might
detect system, application, or performance problems. The operator or system
operator job is directly related to ensuring the health of the IT environment and
attaining the appropriate service level for IT operation.
The primary interaction for an operator with the SOA management environment
relates to:
򐂰 Monitoring for potential problems and correcting them
򐂰 Ensuring that they adhere to the system SLA
򐂰 Providing initial troubleshooting of a problem, and, if possible, fixing it
򐂰 Escalating a problem to the next level of support or subject matter expert for
resolution if necessary
10
Managing an SOA Environment with Tivoli
To accomplish these objectives, an operator can perform monitoring by using
system management tools. The tools can provide views that the operator can
use to detect color-coded conditions or troublesome values in a measurement.
The tools can also provide automatic monitoring that generates events or alerts
for the operator to address. In most environments, the operator must rely on
alerts and events that happen on the environment instead of trying to navigate
the tools to uncover problems.
Using the Tivoli tools, IBM Tivoli Monitoring provides a facility for the operator to
get alerts and navigate views in order to problems in the Tivoli Enterprise Portal.
An alert might be sent to Tivoli Enterprise Portal to signal that a problem has
occurred. On other occasions, uncovering the problem might require
investigation by the operator. In either case, an operator must examine metric
data to see if the operator can make a preliminary diagnosis of the problem.
Event monitoring is represented by situations.
ITCAM provides situations that come predefined (ready to use) or that can be
modified by using the situation editor. Breaching an SLA can fire a situation to
alert the operator of the problem. The situation event console displays
information about these situations. Figure 1-1 shows the situation event console.
Figure 1-1 Situation event console
An operator can also look at the results of queries that are performed against
Tivoli Enterprise Monitoring Agent. These queries can be either predefined or
created by using the Tivoli Enterprise Portal query editor. The system or product
administrator loads the predefined queries into the Tivoli Enterprise Portal
Server. An administrator will often use the query editor to define and create
queries for display on the Tivoli Enterprise Portal.
1.6.2 Middleware or application subject matter expert
The subject matter experts on the application or the middleware perform the
in-depth problem determination. They might respond to problems that were
initially uncovered by an operator. For a composite application and specifically
for the SOA-based application, they must be able to see and trace the
Chapter 1. Introduction to SOA management
11
application beyond just the SOA interface and into the component level or a
breakdown of the transaction.
Subject matter experts on the application or the middleware perform these
in-depth diagnostics from several sources, such as:
򐂰 Investigating the Web Services flow from one application server to another
򐂰 Rerouting and modifying mediation and the Web Services flow
򐂰 Collecting response time breakdowns using correlation tracking
򐂰 Performing a method trace for the J2EE application
The subject matter experts on an application or the middleware perform these
functions by using a combination of ITCAM solutions, such as:
򐂰 ITCAM for SOA
򐂰 ITCAM for WebSphere and ITCAM for J2EE
򐂰 ITCAM for Response Time Tracking
1.6.3 Performance analyst
A performance analyst inspects reports about availability and response time for
various applications, including applications deployed in an SOA environment. If
the metrics indicate that a threshold is close to being reached, the performance
analyst consults a trend analysis of how the application has been performing
over time.
The conclusion can indicate a sudden spike in activity or a increasing trend over
time, which might mean you need to expand your capacity. The performance
analyst collects this information from various data sources from the monitoring
system historical data.
The Tivoli solution in the IBM Tivoli Monitoring environment is based on Tivoli
Data Warehouse. The Tivoli Data Warehouse collects historical data from
various Tivoli Enterprise Monitoring Agents. This data can be reported and
analyzed by using the reporting tools that report into a DB2® database.
1.6.4 System administrator
The system administrator is a user with administrative privileges that performs
the day-to-day tasks of maintaining the management system. The system
administrator tasks include granting access to users, implementing a monitoring
solution, extending the monitoring solution by using a standard procedure, and
so on.
12
Managing an SOA Environment with Tivoli
The system administrator has the authority to modify the system, such as
installing a new feature or a patch to the monitoring system, thus, allowing
interaction with the management of the SOA solution.
The system administrator can install, configure, and maintain all the tools that a
subject matter expert needs. A system administrator can also configure, start,
and stop agent processes, or perhaps even reconfigure the entire monitoring
environment.
System administrator interactions include:
򐂰 Managing situations, workspaces, and actions in Tivoli Enterprise Portal that
are related to the SOA application
򐂰 Administering users, such as Tivoli Enterprise Portal users. Using the
Administer Users window for setting authorities to specific features,
specifying access to applications, and specifying access to Navigator views.
Selecting the features in Tivoli Enterprise Portal to provide access to each
user and to set the specific permissions granted to each user (see Figure 1-2
on page 14)
Chapter 1. Introduction to SOA management
13
Figure 1-2 Administer user dialog
1.6.5 Enterprise system management architect
The system management architect interacts with the business side of the
company and is familiar with the company’s business processes. An architect
must understand the model for the SOA-based application, including Web
Services, SCA, and business process choreography to model the architecture of
the business.
The architect observes as the model is built and then implemented into system
management. The architect must oversee the system management
implementation based on the business model and ensure that the management
model is kept up-to-date. The architect must review the rollout of the new
application and the change of the mediation rule to ensure that the monitoring
model is still current and meaningful.
14
Managing an SOA Environment with Tivoli
The architect utilizes the WebSphere Services Registry and Repository to
manage the Web Services life cycle and can use the discovery through Tivoli
Common Object Repository to monitor new services and the new model. You
can do this by displaying the ITCAM for SOA Services Overview view to see the
difference between which Web Services have been observed and which Web
Services are registered. If you notice that certain observed Web Services are not
registered, then you can update the registry.
1.6.6 Web Services application developer
The application developers are responsible for coding Web Services
applications. After the developer’s Web Services are deployed, the developers
must be available to fix problems. Depending on the severity of the problem, the
developers usually have a small amount of time in which to complete the fix, and
then they run tests to verify that the problem has been resolved. A typical
scenario is a new mediation that needs to be added to manage traffic for an
existing Web Service, because the system performance has been unexpectedly
affected.
The system management tools can assist the developer to identify the potential
bottlenecks and performance problems in test system. The developers need to
use the tools to test fixes for possible performance bottlenecks before the fixes
go into production. After the build with the fix is installed, the developers observe
whether the performance problem has been alleviated.
1.6.7 Business executives
The business executives care about their business processes and the
applications that support the business. The management solution must allow the
business executives to see the application health based on either the SOA
performance or another metric.
The business executives need an interface with minimum technical detail. The
business executives need a simple but meaningful view of the business process
health and possibly the SLA attainment.
Chapter 1. Introduction to SOA management
15
1.7 Management needs for the SOA environment
Based on the user roles and the users’ needs in 1.6, “Users of SOA
management” on page 9, the management needs for the SOA environment are:
򐂰 Understanding the current performance of the SOA application in real time in
order to proactively identify any potential outage and problem
򐂰 Collecting historical trends of SOA performance
򐂰 Building structure about the calling pattern of the Web Services
򐂰 Understanding the structure and life cycle of Web Services
򐂰 Performing “deep dives” and diagnoses on the SOA-based application
򐂰 Modifying the routing and data analysis of the SOA Web Services calls
򐂰 Showing the business impact of Web Services call performance problems or
outages
򐂰 Managing security of the SOA-based application. We do not discuss security
management in this paper. See Understanding SOA Security Design and
Implementation, SG24-7310.
In a production environment, it is vital to have sufficient information for the
management system as long as collecting this information does not adversely
affect the managed environment.
To manage an SOA-based application, you need to have information about the
Web Services contained within it and the environment on which they are
deployed. You can observe data on Web Services by monitoring it or from static
definitions, such as WSDL documents that define a Web Service. Data on
Services, ports, and operations is exposed, as well as details about the server
(deployment environment) upon which the data runs (application servers, such
as WebSphere Application Server, WebLogic, JBoss, DataPower, and so on). As
with other software components, you must gather information throughout the
Web Service’s life cycle (see section on 1.4.2, “Web Services life cycle
management” on page 7).
1.7.1 Web Services metric data collection
You can collect metrics throughout the life of a Web Service. These metrics are
usually numeric information that you can use to indicate or calculate the health
and performance of Web Services. You can collect these metrics by using a
polling process or instrumenting the application to report the metrics.
Metrics that are collected at the Web Services operation level include average
response time, average message size, number of messages, number of faults,
16
Managing an SOA Environment with Tivoli
and so on. The metrics can provide valuable information about SOA and Web
Services. You need to be able to view real-time data, as well as historical data,
corresponding to a specific time interval.
You can collect metric data by using a management API, such as Java API for
XML-Remote Procedure Call (JAX-RPC) handlers, which make Web Services
into manageable resources. Data collection using the JAX-RPC handler happens
when when either of the following events occurs:
򐂰 A client application invokes a Web service, which is referred to as a
client-side interception.
򐂰 The Web Services request is received by the hosting application server,
which is referred to as a server-side interception.
The data can be stored in log files for later analysis, sent to a management
server, or loaded into a repository.
1.7.2 Web Services troubleshooting
Troubleshooting Web Services includes monitoring the health of the
infrastructure that supports the Web Services, such as the underlying
middleware. Think of Web Services as manageable resources in the system
management environment.
In this way, you can determine whether policies are being enforced in SOA and
whether SLAs are achieved or not. Data on throughput, availability, workload,
transactions, and so on can be gathered to help you determine if your current
topology is optimal, given the demands placed on your enterprise. Business
processes are managed indirectly in that the Web Services that make up the
business processes are managed resources.
You might also consider a SOA management standard, such as Web Services
Distributed Management (WSDM) from Oasis. See:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
1.7.3 Displaying data
You must be able to display Web Services entities, such as the deployed server,
operation, namespace, relationship, and other attributes, to users. You can
present this information in a tabular or graphical form, and you need to provide
drill-down capability for the user to see details about the Web Service.
A user must also be able to define events and alerts to monitor an SOA
application. These alerts allows users to be notified when a certain condition
Chapter 1. Introduction to SOA management
17
occurs. Alerts® allows the user to not have to monitor a particular view all the
time.
1.7.4 Mediation management
Mediation is a special type of SCA module. You can insert mediations between
loosely coupled Web Services. Introducing mediations between Web Services
provides added function for processing messages that are being passed
between these Web Services. Mediations intercept and modify messages that
are passed between existing Web Services and clients that want to use those
Web Services. Managing mediations includes the ability to filter mediations or
reroute Web Services calls based on monitoring metrics. You can perform this
function on a mediation platform, such as WebSphere Enterprise Service Bus or
WebSphere Message Broker.
18
Managing an SOA Environment with Tivoli
2
Chapter 2.
Tivoli application
management products
in this chapter, we provide an overview of the various Tivoli solutions that you
can use to manage a service-oriented architecture (SOA) environment. Tivoli has
a set of solutions to manage composite application. In a way, you can regard
SOA as a special composite application environment. We discuss:
򐂰 “ITCAM for SOA” on page 20
򐂰 “ITCAM for WebSphere and ITCAM for J2EE” on page 26
򐂰 “ITCAM for Response Time Tracking” on page 33
򐂰 “OMEGAMON XE for Messaging” on page 41
© Copyright IBM Corp. 2008. All rights reserved.
19
2.1 ITCAM for SOA
in this section, we describe IBM Tivoli Composite Application Manager (ITCAM)
for SOA V6.1. We discuss:
򐂰 “Product features” on page 20
򐂰 “Product components” on page 21
2.1.1 Product features
ITCAM for SOA manages service-oriented architecture (SOA). It can monitor,
manage, and control the Web Services layer of the IT architecture, while drilling
down to the application or resource layer to identify the source of bottlenecks or
failures and to pinpoint services that take the most time or use the most
resources. ITCAM for SOA:
򐂰 Provides service monitoring views in Tivoli Enterprise Portal. ITCAM for SOA
workspaces consist of data collector-based workspaces:
– Performance Summary: Shows the response time information for Web
Services calls as viewed from the client or the server
– Message Summary: Shows the message statistics, including the volume
and size of message information
– Fault Summary: Shows failure analysis for Web Services calls
򐂰 Other workspaces for each agent are:
– Service Management Agent Environment: Provides a summary of the
Web Services metrics for all data collectors
– Service Management Agent: Shows the agent configuration summary,
data collectors, monitoring profiles, and filters
– Mediation Configuration: Shows configuration entries for mediation on
Service Component Architecture (SCA)
– Message arrival: Shows the message arrival rate and events based on the
message arrival critical situation
򐂰 Leverages Tivoli Enterprise Portal situations to check thresholds. ITCAM for
SOA provides predefined situations that you need to tailor. The predefined
situations concern:
– Number of messages received by a service within a time window
– Size of the messages
򐂰 Provides basic mediation support with the ability to filter or reject Web
Services call messages from a particular client or service. It can log request
and response messages for analysis.
20
Managing an SOA Environment with Tivoli
򐂰 Offers heterogeneous platform coverage:
– Support for IBM WebSphere Application Server, CICS® Transaction
Server, Microsoft .NET, JBoss, BEA WebLogic, and other SOA clients and
servers
– Target IBM Enterprise Service Bus platforms: WebSphere Application
Server Versions 5.x and 6.x and WebSphere Business Integration Server
Foundation V5.1.1
򐂰 Displays a list of services and operations that are monitored in the
environment
򐂰 Leverages Tivoli Enterprise Portal workflow and policy editor for
threshold-triggered action sequences
򐂰 Offers the ability to include services-layer views in Tivoli Enterprise Portal
The context-rich views and inter-workspace linkages in Tivoli Enterprise Portal
enables users to drill down to IT resources to identify Web Services bottlenecks
and failures. By providing built-in and extensible alerts, situations, and workflows,
users can create powerful automated mediation scenarios using the Tivoli
Enterprise Portal.
The service metrics, alerts, and automation workflows that are provided by
ITCAM for SOA and other Tivoli products can be displayed in Tivoli Enterprise
Portal with the cross-workspace linkages to provide a rich and multilayered
source of information. This information can help to reduce the time and skills that
are required for problem root-cause analysis and resolution.
ITCAM for SOA includes the Web Services Navigator, a plug-in to IBM Rational®
Application Development and other Eclipse-based tools. It provides a deep
understanding of the service flow, patterns, and relationships for developers and
architects. The Web Services Navigator uses data from the IBM Tivoli
Monitoring V6.1 Tivoli Data Warehouse or from the ITCAM for SOA log files
using the Log Assembler tool.
In Version 6.1, IBM Tivoli Composite Application Manager for SOA contains a
new component for mediation service management based on SCA. It enables
you to modify several of the mediation service settings dynamically. Mediation is
a facility that sits between Web Services requester and Web Services provider
that allows manipulation of Web Services messages, includes format translation,
filtering, and enrichment.
2.1.2 Product components
ITCAM for SOA manages Web Services. Web Services can be viewed as a
remote processing facility that is defined through the use of Web Services
Chapter 2. Tivoli application management products
21
Definition Language (WSDL). Usual access uses SOAP over HTTP. Internally,
Web Services are implemented using the Java API for XML-based Remote
Procedure Call (JAX-RPC). ITCAM for SOA installs itself as the JAX-RPC
handler to capture and manage Web Services calls.
ITCAM for SOA consists of these logical components:
򐂰 Web Services data collector that acts as the JAX-RPC handler and intercepts
Web Services calls to collect statistical information and write to a log file.
򐂰 Tivoli Enterprise Monitoring Agent that collects information from all of the data
collectors on a machine and forwards them to Tivoli Enterprise Monitoring
Server. We discuss the data collectors and Tivoli Enterprise Monitoring Agent
in “Monitoring agent data collector” on page 22.
򐂰 An Eclipsed-based viewer that processes log files that are generated by the
Web Services data collector. It generates visual representations of various
characteristics of monitored Web Services. See “IBM Web Services
Navigator” on page 24.
򐂰 Mediation SCA tools that enable partial monitoring of SCA within WebSphere
Enterprise Service Bus. See “Managing SCA mediation” on page 25.
Monitoring agent data collector
ITCAM for SOA works with several application server environments:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
IBM WebSphere Application Server V5.1.0.5 with PQ89492, V6.0, and V6.1
IBM WebSphere Business Integration V5.1.1.1
IBM WebSphere Process Server V6.0.1
IBM WebSphere Enterprise Service Bus V6.0.1
IBM CICS Transaction Server V3.1 and later
BEA WebLogic Server V8.1.4
Microsoft .NET V1.1 with Service Pack 1 and V2.0
JBoss V4.03
WebSphere Community Edition V1.0 and its service packs
SAP® NetWeaver V6.40 with Service Pack 9 or later service packs
IBM WebSphere DataPower SOA Appliance Firmware V3.5.0.5 or later
Figure 2-1 on page 23 shows the ITCAM for SOA data collection conceptual
architecture.
22
Managing an SOA Environment with Tivoli
ITCAM for SOA
Monitoring agent
Application Server
configuration
Web Services
Data
handler or
collector
extension
Data collector
adapter
Tivoli Enterprise
Monitoring Agent
log
Tivoli Enterprise
Management Server
Tivoli Enterprise Portal
Server
Figure 2-1 ITCAM for SOA structure
The monitoring agent data collector is implemented as a JAX-RPC handler or
service extension that is installed into the application servers that host the
monitored Web Services. The handler is given control when either of the
following events occurs:
򐂰 A client application invokes a Web service, which is referred to as a
client-side interception.
򐂰 The Web Services request is received by the hosting application server,
which is referred to as a server-side interception.
The monitoring agent records and collects monitored information into one or
more local log files. The information is then transferred to Tivoli Enterprise
Monitoring Server and can be archived into a historical database for later
retrieval with IBM Web Services Navigator.
ITCAM for SOA V6.1 focuses on the SOAP engine of IBM WebSphere
Application Server, WebSphere Service Integration Bus, Microsoft .NET
Framework, and BEA WebLogic.
The Web Services data collector supports both Java 2 Platform, Enterprise
Edition (J2EE) application client and server container environments, because
JAX-RPC handlers are supported only by these environments. The Web
Services must be compliant with JSR-109 specifications.
To ensure the proper operation of the JAX-RPC handler, verify that the client
applications are written according to the conventions at the following location:
http://www.jcp.org/aboutJava/communityprocess/final/jsr109/
Chapter 2. Tivoli application management products
23
IBM Web Services Navigator
IBM Web Services Navigator is an Eclipsed-based tool that is used to visualize
Web Services in an SOA environment. It provides a graphical display of:
򐂰 Web Services transaction flows
򐂰 Service topology
򐂰 Flow patterns
Figure 2-2 illustrates Web Services Navigator concepts.
Metric
log
Data
collector
Metric
log
Data
collector
TDW
warehouse
Tivoli Enterprise
Monitoring Agent
Metric
log
Data
collector
Web Services
Navigator
Log Assembler
Metric
log
Data
collector
Combined
metric log
Figure 2-2 Web Services Navigator
The Web Services Navigator is a log-browsing tool intended for offline analysis of
SOA Web Services. The Web Services Navigator provides four primary views:
򐂰 Statistic tables:
– Message statistics
Per-message statistics, including requestor, provider, send/receive time,
and message size
– Invocation statistics
Response time, network delay, message size, and more for each Web
Services invocation
– Transaction statistics
Statistics for aggregated transactions, including elapsed time, number of
faults, number of machines that this transaction involves, and number of
invocations comprising this transaction
24
Managing an SOA Environment with Tivoli
– Pattern invocation statistics
Statistics for discovered patterns, including operation names, number of
occurrences, response times, and message sizes
Note: To see the message content from the ITCAM for SOA metric log:
1. Set a monitor control higher than “none” for any or all of the Web
Services being monitored.
2. Include the subsequent xxxx.content.log when running Log Assembler.
򐂰 Service topology view
This view is a graphical representation of the monitored Web Services that
displays aggregated information and details about the relationships between
Web Services.
򐂰 Transaction flows view
The transaction flows view displays Universal Markup Language (UML) style
sequence diagrams. The transaction flow shows a chronological view of each
transaction, the flow between the various Web Services over time, and the
topology and statistics for each transaction. You can zoom in on the view to
see the details of individual transactions.
򐂰 Flow pattern view
The flow pattern view is a visual representation of the aggregated pattern of
transactions represented in the log file. The view also represents each pattern
as a distinct sequence of Web Services calls and displays the frequency of
each pattern.
Managing SCA mediation
WebSphere Process Server and WebSphere Enterprise Service Bus introduce a
new way to model services in an SOA, which is called the Service Component
Architecture (SCA). SCA is designed to separate business logic from its
implementation so that you can focus on assembling an integrated application
without knowing implementation details.
There is a special type of SCA component, which is called a mediation. In an
SOA, where services are loosely coupled rather than connected directly to each
other, mediations can be inserted between the services, where they can
intercept and process messages that are passed between the services.
Mediations can process these messages and take appropriate actions, such as
reroute, log, or transform a message, or create a notification or an event.
IBM Tivoli Composite Application Manager for SOA provides the ability to
dynamically enable and disable the deployed mediation functions. This facility is
Chapter 2. Tivoli application management products
25
available for applications in the WebSphere Enterprise Service Bus or
WebSphere Process Server runtime environment. The invocation is provided in a
new workspace in Tivoli Enterprise Portal called the Mediation Configuration
workspace. The actions are:
򐂰 ConfigureMediation_610
򐂰 DeletePrimitiveProperty_610
2.2 ITCAM for WebSphere and ITCAM for J2EE
The IBM Tivoli application management solution for J2EE application servers
comes in the form of ITCAM for WebSphere and ITCAM for J2EE. These two
products share the same managing server. ITCAM for WebSphere and ITCAM
for J2EE observe and report on the health of J2EE-based applications. They
track the progress of applications as they traverse through J2EE application
servers, middleware adapters and transports, and database calls, and on to
back-end systems, such as CICS or IMS™, to extract business data or to invoke
mainframe business processes.
Tracking applications produces request traces, where the events in a request’s
life are recorded and stored in a monitoring repository database. ITCAM for
WebSphere and ITCAM for J2EE capture the CPU and the elapsed internal
times when events are called and when they are exited, measuring as far down
as the CPU times consumed and the elapsed internal times charged to individual
methods in J2EE classes. The methods or events taking the most time are
marked as an application’s parts that deserve attention for runtime improvement
studies and code optimizations.
ITCAM for WebSphere manages and monitors WebSphere-based application
servers, while ITCAM for J2EE manages and monitors the following J2EE
containers:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
JBoss
Tomcat
SAP NetWeaver®
BEA WebLogic Server
Oracle® Application Server
Apache Web Server
Sun™ Java™ System Web Server
Microsoft IIS
WebSphere Application Server CE
ITCAM for WebSphere and ITCAM for J2EE do not need modification of any
J2EE or mainframe application code. The data collectors use the following
principal data sources: Java Virtual Machine Tool Interface (JVMTI) interfaces
26
Managing an SOA Environment with Tivoli
and primitives. ITCAM for WebSphere also uses WebSphere Performance
Management Interface (PMI) and z/OS System Measurement Facility (SMF)
120 records. The monitoring data is collected and analyzed to offer a wealth
of information about the health of J2EE applications and their servers.
These products collect and report many system-level performance metrics about
J2EE application servers. The status of the servers and their resources
(particularly at vital checkpoints, such as CPU utilization), memory usage, and
the status of internal components, such as database connection pools, JVM™
thread pools, EJB™ usage, and request processing statistics, can be extremely
important in locating real-time problems with J2EE applications. ITCAM for
WebSphere and ITCAM for J2EE bring attention to these critical indicators with
real-time, graphical displays of their values and their trends over spans of time.
2.2.1 Architecture and interconnection
ITCAM for WebSphere and ITCAM for J2EE are distributed performance
monitoring applications for application servers. The components are connected
through TCP/IP communication. The central component of ITCAM for
WebSphere and ITCAM for J2EE, the managing server, is its heart and brain. It
collects and displays various performance information from application servers.
Chapter 2. Tivoli application management products
27
The application servers run the data collector, which is a collecting agent that
runs in the application server and sends monitoring information to the managing
server. These data collectors operate independently of each other. Figure 2-3
shows the overall architecture of ITCAM for WebSphere and ITCAM for J2EE.
Browser interface
ITCAM for WebSphere
ITCAM for J2EE
Managing Server
I
Tivoli Enterprise
Monitoring Agent
Application servers with
Data collectors
ise
pr ent
er
Tivoli Enterprise
nt g Ag
E
li in
Management
Server
vo itor
i
T on
M
and
Tivoli Enterprise
Portal Server
Web Servers
Figure 2-3 ITCAM for WebSphere and ITCAM for J2EE architecture
The application monitor consists of two major parts: the managing server and the
data collectors. A data collector agent runs on each monitored application server,
whether J2EE, CICS, or IMS, and communicates essential operational data to
the managing server. Unique sampling algorithms maintain low CPU and
network processing while providing application-specific performance information.
The managing server consists of several Java-based components that provide
the environment to collect and present management data.
2.2.2 The managing server
ITCAM for WebSphere and ITCAM for J2EE use one common managing server
that controls and coordinates data collectors for J2EE, CICS, and IMS servers
28
Managing an SOA Environment with Tivoli
that run applications. The difference between ITCAM for J2EE and ITCAM for
WebSphere is the platform support for the data collectors. These data collectors
can run independently.
The managing server uses the following software:
򐂰 Managing server database (DB2 UDB or Oracle on Sun Solaris™) for the
relational data repository
򐂰 WebSphere Application Server to run the visualization engine Web console
application
򐂰 An optional Web server, such as IBM HTTP Server
򐂰 The managing server overseer components, which are a set of Java-based
processes
The overseer components are the controlling logic for the managing server. For
the overseer components:
򐂰 Kernels control the managing server. There are always two copies of the
kernels running on an ITCAM for WebSphere and ITCAM for J2EE managing
server for redundancy and failover. The kernels register components as they
join the managing server, periodically renew connections and registrations
with components and data collectors, and collect server and component
availability information.
򐂰 Publishing servers receive application and system event data from the data
collectors, gather and compute request-level information about performance
metrics such as response times, and implement the trap monitoring and alerts
features.
򐂰 Archive agents receive monitoring data from the publish servers and store the
monitoring data in the repositories of ITCAM for WebSphere and ITCAM for
J2EE.
򐂰 The global publishing server collects information from the publish servers
and correlates all parts and pieces of multiserver requests, such as requests
from J2EE servers to execute CICS or IMS programs.
򐂰 The message dispatcher is a conduit for messages from ITCAM for
WebSphere and ITCAM for J2EE using e-mail and Simple Network
Management Protocol (SNMP) facilities.
Chapter 2. Tivoli application management products
29
򐂰 The visualization engine is a Web-based GUI with access to graphics, ITCAM
for WebSphere and ITCAM for J2EE performance reports, real-time views of
different slices of monitoring data, and ITCAM for WebSphere and ITCAM for
J2EE internal commands and event-driven functions. The visualization
engine runs on a WebSphere Application Server.
Publish traffic
Snapshot traffic
Figure 2-4 shows the conceptual relationship among the components.
Global Publish
Server (SAM)
Publish Server (PS)
Message Dispatcher
(MD)
Archive Agent (AA)
Kernel (KL)
Provide services on:
- Lookup
- Registration
- Recovery
- Configuration
Visualization Engine
Provide services on:
-Administration
-Availability
-Problem Determination
-Performance Management
OCTIGATE
database
Figure 2-4 Kernel components
At the managing server, monitoring data is prepared for real-time displays within
the monitoring console and is inserted into the OCTIGATE data repository.
These are extremely resource-intensive operations. Having this processing in
the managing server isolates this from other the application servers, thus
reducing the footprints of ITCAM for WebSphere and ITCAM for J2EE in the
monitored systems. This design also helps keep the data collectors’ processing
at levels low enough for 24x7 production system monitoring.
Data from the data collectors is collected by the publishing server and then
stored in the OCTIGATE database by the archive agent. The visualization engine
reads the database to present data through the Web console, and snapshot
information, such as lock analysis and in-flight transactions, is retrieved directly
from the data collectors.
2.2.3 J2EE and WebSphere data collectors
The data collectors run inside the application servers. They use native system
services, and they are tailored for the particular environments where they
30
Managing an SOA Environment with Tivoli
execute. The data collectors for z/OS systems are written to take advantage of
services on z/OS, such as MVS™ Cross-Memory Services and address space
fencing, which are not available on distributed systems.
Data collectors are configured as a multithreaded process. They consist of the
following agents:
򐂰 Command agent
The command agent collects requests from other components for information
about Enterprise Java Bean (EJB) invocations, database connection pools,
thread pools, stack traces, memory analyses, and heap dumps.
򐂰 Event agent
The event agent provides data to the publish servers according to polling
frequencies. This data includes system initialization data, application
request-level data, and application method-level data.
򐂰 Secondary collector
The optional secondary collector provides support for displaying data in Tivoli
Enterprise Portal for collecting WebSphere Application Server and other
J2EE application server performance metrics. This component communicates
with Tivoli Enterprise Monitoring Agent using a TCP/IP port.
Collectively, these agents and other data collector routines unleash the probes,
package the monitoring data into Java formats for the managing server, and
deliver the data to the managing server.
The data collectors send the probes into the application servers to analyze the
applications’ performance. The probes collect monitoring data and feed it to
transport routines that in turn route the data to the managing server. The
managing server processes it for display in the Web console and for storage in
the OCTIGATE repository, which relieves the processing burden of ITCAM for
WebSphere and ITCAM for J2EE from the application servers as much as
possible. The data collectors and probes are not designed to analyze or interpret
data, but to collect it and route it as quickly as possible to the managing server
where the analysis is performed.
The data sources that are employed by ITCAM for WebSphere and ITCAM for
J2EE are:
򐂰 Java Virtual Machine Tools Interface (JVMTI) garbage collection data,
method trace, stack trace, CPU time, and heap dump
򐂰 Java Management Extensions (JMX) system resources
򐂰 System Management Facilities (SMF) system resources (z/OS only)
򐂰 PMI system resources (WebSphere only)
Chapter 2. Tivoli application management products
31
򐂰 OS services, platform CPU, and its environment
򐂰 Byte Code Modification (BCM) instrumentation of some classes
The data collector in the J2EE server runs as a custom service called am in a
distributed architecture and “-” for z/OS architecture. Figure 2-5 shows the
conceptual data collector structure of the distributed WebSphere data collector.
WebSphere
JVMTI
JMX
Custom Service
am
Publish data
KYN
bcm
PMI
Tivoli Enterprise
Monitoring Agent
To TEMS
Figure 2-5 J2EE data collector structure
2.2.4 Tivoli Enterprise Monitoring Agent
The ITCAM for WebSphere and ITCAM for J2EE Tivoli Enterprise Monitoring
Agent can forward monitoring information to Tivoli Enterprise Monitoring Server
for monitoring using Tivoli Enterprise Portal. There is an additional component at
Version 6.1, Tivoli Enterprise Monitoring Agent for Web Servers. Web server
monitoring no longer uses the managing server’s polling agent, but uses Tivoli
Enterprise Monitoring Agent for Web Servers instead.
The existing Tivoli Enterprise Monitoring Agent for WebSphere and J2EE
provides application server performance information, while the new Tivoli
Enterprise Monitoring Agent for Web Servers displays Web server performance
information.
32
Managing an SOA Environment with Tivoli
2.3 ITCAM for Response Time Tracking
ITCAM for Response Time Tracking Version 6.1 is an evolution from IBM Tivoli
Monitoring for Transaction Performance V5.3. It inherits the major components
and functions of IBM Tivoli Monitoring for Transaction Performance V5.3.
Tivoli
Enterprise
Management
Agent
RTT
Store and
forward agent
RTT
management
agent
RTT
management
agent
FIREWALL
RTT
Management
server
FIREWALL
Figure 2-6 shows the ITCAM for Response Time Tracking components.
RTT
Store and
forward agent
RTT
management
agent
RTT
management
agent
RTT
management
agent
Figure 2-6 ITCAM for Response Time Tracking components
Basically, ITCAM for Response Time Tracking is controlled from the
management server. The management server provides a centralized repository
of policy, configuration, and data for the ITCAM for Response Time Tracking
environment.
The rest of ITCAM for Response Time Tracking consists of the management
agents. The management agents perform performance and response-time data
collection on behalf of the management server. The agent can perform response
time collection from an application server or perform robotic simulation of a
transaction for measuring response time. The management agent functions as a
single agent that can have different monitoring components deployed on it to
perform various functions.
The management server and management agent typically operate in an
unrestricted port environment. When there is a firewall between them, they
restrict the port usage to communicate. The firewall requirement typically
requests that they use a single communication port to talk back and forth. This
is where the store and forward agent comes in. It bundles the management
Chapter 2. Tivoli application management products
33
communication between the management server and management agent to use
a single port to pass through the firewall. The store and forward agent can be
cascaded, so in this sense, there can be a chain of store and forward agents to
pass through multiple layers of firewalls.
A special management agent resides on z/OS machines. The management
agent on z/OS machines has the transaction server component activated to
receive performance information from the CICS and IMS data collector.
In ITCAM for Response Time Tracking V6.1, information from the management
server can be forwarded to Tivoli Enterprise Monitoring Server for display in
Tivoli Enterprise Portal. Use the Tivoli Enterprise Monitoring Agent for ITCAM for
Response Time Tracking to have this capability.
We discuss the components of ITCAM for Response Time Tracking in the
following sections:
򐂰
򐂰
򐂰
򐂰
“The management server” on page 34
“Store and forward agent” on page 36
“Management agents” on page 37
“Tivoli Enterprise Monitoring Agent” on page 41
2.3.1 The management server
The ITCAM for Response Time Tracking management server consists of a J2EE
enterprise application that accesses a DB2 repository using JDBC™. The
management server runs on WebSphere Application Server. The application
server can be installed on a stand-alone WebSphere Application Server or on a
clustered environment. Figure 2-7 shows a stand-alone management server.
Management server
WebSphere
Application Server
DB2
Figure 2-7 Stand-alone management server
34
Managing an SOA Environment with Tivoli
Figure 2-8 shows the clustered management server. It consists of WebSphere
Edge Server for load balancing, the management server on several clustered
WebSphere Application Server Node Deployment systems, and the database
installed on a separate database server.
WebSphere Node
Deployment Cluster
WebSphere
Application Server
WebSphere Edge
Server
DB2
WebSphere
Application Server
Figure 2-8 Clustered management server
Clustered management server benefits include:
򐂰 Separating the servers reduces the processing burden of a single machine.
򐂰 Clustered management server allows failover for failure in WebSphere
Application Server, so the other management server in the cluster can take
over the work.
Some disadvantages are:
򐂰 Additional communication traffic between machines
򐂰 More difficult setup; refer to IBM Tivoli Composite Application Manager for
Response Time Tracking V6.0: Installing a Management Server in a
WebSphere Cluster Environment, SC32-1804, for installation instructions
Overall, regardless of the management server types, the management server
provides the following functions:
򐂰 Managing management agents and their deployed components;
management agents must sign in to the management server and retrieve all
required policies when it is started initially
Chapter 2. Tivoli application management products
35
򐂰 Storing policies for management agent operation, including discovery
policies, listening policies, and playback policies, which are maintained using
the Web interface or the new command-line interface
򐂰 Managing a schedule repository; note that the management agent performs
the schedule application
򐂰 Performing data collection from various management agents and storing
them in its repository.
򐂰 Maintaining users and roles for accessing the Web interface
򐂰 Serving the Web interface
2.3.2 Store and forward agent
The store and forward agent acts as an intermediary between the management
server and the management agent. Figure 2-9 shows its overall processing.
RTT
Management
server
1976
Store and Forward
agent
9081
Caching
Proxy
80
RTT
Management
agent
Figure 2-9 Store and forward agent
This agent consolidates communication from and to management agents and
uses a single port to communicate to the upstream component. The store and
forward agent can be cascaded. It uses IBM WebSphere Caching Proxy, which is
part of WebSphere Edge Server V2.0. The caching proxy optimizes the
connection with the management server.
The default port, to which the management agent must connect, is 9446 for
Secure Sockets Layer (SSL) or 80 for non-SSL.
You can have multiple store and forward agents chained to get to the
management server through multiple layers of firewalls. Figure 2-10 on page 37
shows this concept.
36
Managing an SOA Environment with Tivoli
Management
Server
Store and
forward
agent
80
Store and
forward
agent
80
Management
agent
Figure 2-10 Multiple store and forward agents
2.3.3 Management agents
The management agent runs in a Java virtual machine on the managed server. It
typically performs the following functions:
򐂰 Starting and stopping the management components
򐂰 Collecting monitoring and schedule information from the management server
򐂰 Informing the management components about what to perform
򐂰 Caching response time data in the temporary directory
򐂰 Uploading response time data as requested by the management server,
either at regular collection time or on demand
The management agent behavior is based on the Application Response
Measurement (ARM) specification. The management component monitors
measure response time and report the times using the ARM specification to the
ARM agent process (tapmagent executable). The ARM agent process stores
response time information on physical disk. The management agent uploads the
response time information to the management server at the regular interval.
There is a slight difference between the distributed management agent
architecture and the z/OS-based management agent.
Chapter 2. Tivoli application management products
37
Distributed management agent
Conceptually, Figure 2-11 illustrates the processing of the management agent.
ARM agent
QoS Apache
reverse
proxy
STI client
Management
agent
Generic
Window
Client
Application
Tracker
Web
Response
Monitor
J2EE
monitoring
component
Figure 2-11 Management agent
The existing management components are:
򐂰 The Generic Window component allows investigation of a Windows®-based
application to use with Rational Robot application, which enables the Robot to
interact with a native Windows application, a Java application, or a
browser-based application. You can only deploy this Generic Window
component on a Windows system.
򐂰 Synthetic Transaction Investigator (STI) simulates user interaction with a
Web browser. STI transactions are recorded in advance using the STI
recorder application. The STI component can be deployed only on a Windows
system.
򐂰 Quality of Service (QoS) runs in an Apache Web server proxy that tracks the
response time for a user. It inserts a small Java script for HTML code to reply
back to QoS and indicate the overall user response time. Figure 2-12 on
page 39 outlines the QoS processing.
38
Managing an SOA Environment with Tivoli
User with Web
browser
QoS
Apache reverse proxy
Back-end Web server
Back-end
processing
time
Overall
response time
Page
render
time
Round-trip
time
Figure 2-12 QoS processing
򐂰 J2EE instrumentation component runs as JVMPI instrumentation for a
J2EE-compliant Web application server, such as WebSphere Application
Server or BEA WebLogic. It monitors certain WebSphere classes to collect
information about servlets and Web Services calls. It also collects response
time information for Java Database Connectivity (JDBC) connections and
J2EE Connector architecture (J2C) accesses.
򐂰 ARM agent, historically called Tivoli Application Performance Manager, is
implemented as the executable tapmagent.
򐂰 Web Response Monitor (WRM) measures the performance of Web-based
applications, provides response time and other performance data, and tracks
navigation paths and usage behavior.
Mainframe management agent
For z/OS-based systems, ITCAM for CICS Transactions and ITCAM for IMS
Transactions data collectors can send transaction start and transaction end
events to the management agent running on the same z/OS system as the CICS
and IMS started task. These start and stop events for CICS and IMS transactions
are translated into ARM start and ARM stop calls by a component called the
transaction server. These data collectors allow IMS and CICS transactions to be
shown as part of the distributed transaction or as a stand-alone transaction
running on z/OS. Figure 2-13 on page 40 shows the z/OS-based management
agent structure.
Chapter 2. Tivoli application management products
39
ARM agent
ITCAM for
CICS
Transactions
Management
agent
Transaction Server
ITCAM for
IMS
Transactions
J2EE
monitoring
component
Figure 2-13 Mainframe management agent
Note: The transaction server component is activated by default in all platforms
that we installed. Only the z/OS management agent can use this feature. You
can see which components are started from the configuration file tmtp_sc.xml.
The components of the management agent in z/OS are:
Management agent
The management agent is responsible for communication
with the ITCAM for Response Time Tracking
management server and collecting ARM-related activities
on behalf of CICS and IMS. The ARM engine or
tapmagent is part of the management agent; it enables
you to integrate any other ARM-instrumented application
with ITCAM for Response Time Tracking.
CICS data collector The CICS data collector monitors transaction response
times within CICS regions. It gives you information about
how long it took to run the transaction in the monitored
CICS region. If your CICS transaction flows through
several CICS regions, installing CICS data collectors in
every region involved enables you to track the complete
transaction flow.
IMS data collector
40
The IMS data collector monitors transaction response
times within IMS regions. This function means that you
get information about how long it took to execute the
single transaction in the monitored IMS region. If your IMS
transaction spans multiple IMS regions, you can monitor
the complete transaction flow by installing the IMS data
collectors in the regions that are involved.
Managing an SOA Environment with Tivoli
The IMS data collectors and CICS data collectors report to the transaction server
portion of the ITCAM for Response Time Tracking management agent on the
z/OS machine on which they execute.
2.3.4 Tivoli Enterprise Monitoring Agent
The agent for Tivoli Enterprise Monitoring Server for ITCAM for Response Time
Tracking is provided as a separate installable feature. Figure 2-14 shows the
connectivity of the Tivoli Enterprise Monitoring Agent for ITCAM for Response
Time Tracking.
ITCAM for RTT
Management server
Tivoli Enterprise
Management Server
WebSphere
Application Server
DB2
Tivoli Enterprise
Management Server
Tivoli Enterprise
Management Agent
Figure 2-14 Tivoli Enterprise Monitoring Agent
The ITCAM for Response Time Tracking agent is assigned the code KT2. The
Tivoli Enterprise Monitoring Agent components must be installed in Tivoli
Enterprise Monitoring Server, Tivoli Enterprise Portal Server, and Tivoli
Enterprise Portal.
ITCAM for Response Time Tracking provides a workspace that is dynamically
linked based on the policy groups that are available on the management server.
2.4 OMEGAMON XE for Messaging
IBM Tivoli OMEGAMON XE for Messaging Version 6.0 is the new name for, and
follow-on version to, IBM Tivoli OMEGAMON XE for WebSphere Business
Integration V1.1.0. OMEGAMON XE for Messaging incorporates a number of
new product features that we discuss throughout this book. OMEGAMON XE for
Chapter 2. Tivoli application management products
41
Messaging takes advantage of the features offered by IBM Tivoli
Monitoring V6.1.
IBM Tivoli OMEGAMON XE for Messaging helps to manage and configure your
WebSphere MQ, Message Broker, and InterChange Server environments.
These solutions provide the most comprehensive suite of tools to manage the
performance, connectivity, and configuration of your environment. These tools
enable you to gain an understanding of your environment and determine when
your applications do not perform properly. You will then be able to take corrective
action to alleviate these problems.
IBM Tivoli Performance and Availability Management products provide the
central nervous system for complicated business landscapes: They constantly
gather information about hardware, software, and network devices, and, in many
cases, cure problems before they actually occur. IBM Tivoli availability products
monitor business at the component, business system, and enterprise levels. This
technology identifies critical problems, as well as misleading symptoms, and then
either notifies support staff with the appropriate response, or automatically cures
the problems, which decreases operating costs and improves staff efficiency.
The predefined capabilities of IBM Tivoli OMEGAMON XE for Messaging provide
auto-discovery and monitoring of these complex environments, providing rapid
time to value, ease of use, and improved product quality. Additionally, IBM Tivoli
OMEGAMON XE for Messaging identifies common problems and automates
corrective actions by monitoring key WebSphere MQ, WebSphere Message
Broker, and WebSphere InterChange Server metrics. It sends event notification
and provides data collection for real-time and historical data analysis, thus
reducing administrative costs and maximizing return on investment with
increased efficiency of the IT staff.
2.4.1 WebSphere MQ configuration
It is difficult to get a sense of your configuration structure when your view of it
consists only of configuration definitions. To help you understand the structure of
your configuration, WebSphere MQ Configuration provides a representation of
your WebSphere MQ configuration called the Defined View. Defined objects in
this view represent current or potential WebSphere MQ resources (queue
managers, channels, queues, processes, namelists, and so on), all under the
management of WebSphere MQ Configuration. Figure 2-15 on page 43 shows
an example of the Defined View.
42
Managing an SOA Environment with Tivoli
Figure 2-15 The Defined View
You can use the Discover feature to quickly and easily build defined objects that
represent your actual WebSphere MQ configuration. You can also use the
Defined View to safely validate changes to your configuration before applying
them to your actual WebSphere MQ configuration.
2.4.2 WebSphere MQ monitoring
WebSphere MQ monitoring enables you to set a wide range of monitoring
options that can be changed to suit the needs of your environment. For example,
you can define which queue managers, queues, and channels you want
monitored, specify the time interval for collecting WebSphere MQ data, manage
the disposal of event messages from an event queue, or specify whether or not
you want to collect historical monitoring data and how long you want to have that
data available. Monitoring options are set by defining certain commands and
parameters in a special command file that we refer to as the monitoring file (the
actual name of the file varies slightly by operating system platform). When you
start the WebSphere MQ agent, the commands and parameter values in the
monitoring file are read and executed. You do not create the monitoring file; it is
supplied with your product and is preconfigured with a set of default commands
Chapter 2. Tivoli application management products
43
and parameter values. As supplied, the WebSphere MQ Monitoring Agent for
WebSphere MQ on z/OS monitors all queues and channels for all queue
managers and all WebSphere MQ applications. As supplied, the WebSphere MQ
Monitoring Agent for WebSphere MQ on Hewlett-Packard (HP) NonStop Kernel
(formerly known as Tandem), UNIX/Linux®, Microsoft Windows, and IBM
OS/400® monitors all queues and channels on a single default queue manager.
You can change these default options as well as any others. The list of
monitoring options available are:
򐂰 The SET GROUP command defines a group of queue managers that have
common monitoring characteristics. Within the group, you can override
like-named parameters for specific queue managers using the SET
MANAGER command. At least one SET GROUP command is required.
򐂰 The SET MANAGER command specifies queue managers to be monitored.
򐂰 The SET QACCESS command specifies a set of queues that have specified
message manipulation rights in the group level or the manager level.
򐂰 The SET QUEUE command specifies the queues to be monitored.
WebSphere MQ monitoring always monitors the dead-letter queue. To
monitor other system or application queues, specify them with the SET
QUEUE command.
򐂰 The SET CHANNEL command specifies the channels to be monitored.
򐂰 The SET EVENTLOG command specifies the size, location, and other
attributes of the event log. This command applies to all platforms except
z/OS.
򐂰 The SET EVENTQIN command identifies the queue manager event queue,
channel event queue, performance event queue, configuration event queue,
command event queue, and logger event queue for a queue manager or
group of queue managers. If no SET EVENTQIN command applies to a
queue manager, the following default WebSphere MQ names are used:
– SYSTEM.ADMIN.QMGR.EVENTS
– SYSTEM.ADMIN.CHANNEL.EVENTS
– SYSTEM.ADMIN.PERFM.EVENTS
– SYSTEM.ADMIN.CONFIG.EVENT (Configuration events are present on
WebSphere MQ for z/OS Version 5.3 and later only.)
– SYSTEM.ADMIN.COMMAND.EVENT (Command events are present on
WebSphere MQ for z/OS Version 6.0 and later only.)
– SYSTEM.ADMIN.LOGGER.EVENT (Logger events are present on
WebSphere for Distributed Platforms Version 6.0 and later only.)
44
Managing an SOA Environment with Tivoli
򐂰 The SET EVENTQOUT command identifies the output queues where queue
manager event information, channel event information, performance event
information, configuration event, command event information, and logger
event information will be copied. After WebSphere MQ monitoring has read
an event message from an event queue, it deletes the message to ensure that
it is processed only once. If another application running at your site requires
access to event messages, you can define an output queue where these
messages are copied and point the other application to that queue. If no SET
EVENTQOUT command applies to a queue manager, the event information is
discarded after being processed.
򐂰 The PERFORM INCLUDE command points to an external file containing
customization commands. To execute the commands in this file, specify
PERFORM INCLUDE in your startup file.
򐂰 The PERFORM STARTMON command initiates monitoring of WebSphere
MQ objects, specifies the sampling interval for collecting WebSphere MQ
data, and specifies whether or not historical data will be collected. The
PERFORM STARTMON command is required.
򐂰 The SET AGENT command enables you to specify the middle qualifier used
in the managed system name. On distributed platforms, if this value is not
specified, no value is used. On z/OS, if this value is not specified, the host
name is used. If you specify this value, it is used only in the managed system
names of subnodes. For example, to avoid confusion and to allow multiple
WebSphere MQ Monitoring Agents, instead of issuing the default agent
startup command IRAMAN KMQAGENT START (to start a node named host
name: MQIRA), you can issue the modified agent startup command IRAMAN
KMQAGENT START agentid (to start a node named agentid: MQIRA). Here
are several reasons to use the SET AGENT command:
– On distributed platforms, if your site has multiple queue managers with the
same name running on different nodes, you need to specify the node
name for each queue manager to uniquely identify them.
– Use SET AGENT to group and identify queue manager names by
something other than the host name and queue manager name.
– Use SET AGENT to allow multiple agents connected to the same
Conversational Monitor System (CMS) to monitor the same queue
manager.
򐂰 The SET APPL (z/OS only) command identifies the WebSphere MQ-based
z/OS applications, CICS transactions, and IMS programs that must be
monitored for application debugging information and application statistics.
Chapter 2. Tivoli application management products
45
򐂰 The SET MQIMONITOR (z/OS only) command is supported on z/OS only.
The SET MQIMONITOR command activates monitoring for the applications
that you specified using the SET APPL command. You must specify the SET
MQIMONITOR command to turn on monitoring. Use the SET MQIMONITOR
command together with the SET APPL command to activate the application
debugging and application statistics features.
򐂰 The SET QSG (z/OS only) command specifies which queue-sharing groups
the WebSphere MQ Monitoring Agent on z/OS monitors and which queue
managers the agent uses to collect queue-sharing group data. At any given
time, for a particular queue-sharing group, this monitoring product uses only
one queue manager to gather data. If that queue manager becomes
unavailable, data gathering “fails over” to another queue manager. The SET
QSG command is optional. If not specified, the default behavior of the agent
is to monitor all queue-sharing groups that are associated with monitored
queue managers. You might use a SET QSG command to specify:
– That no queue-sharing groups will be monitored
– That a particular queue-sharing group will not be monitored
– That a particular queue manager must not be used to collect
queue-sharing group data
2.4.3 WebSphere Message Broker monitoring
WebSphere Message Broker Monitoring Agents collect data from WebSphere
Message Brokers. The data is presented in charts and tables that you can
examine to monitor the performance of your WebSphere Business Integration
systems. The agents also evaluate the data to detect when specified values
meet criteria that you have defined and trigger alerts or programmed actions in
response.
In addition, WebSphere Message Broker monitoring provides a CandleMonitor
node. Inserted into message flows, the CandleMonitor node collects statistics
about message flow and subflow performance. It also provides a mechanism for
generating user-defined events within a message flow (Figure 2-16 on page 47).
46
Managing an SOA Environment with Tivoli
Figure 2-16 CandleMonitor node
Chapter 2. Tivoli application management products
47
48
Managing an SOA Environment with Tivoli
3
Chapter 3.
Basic SOA and Web
Services management
In this chapter, we show basic metrics and ways that you can manage
service-oriented architecture (SOA) and Web Services in general. We divide this
discussion into:
򐂰 “Basic monitoring concepts” on page 50
򐂰 “Performance metric of Web Services” on page 51
򐂰 “Generating events and alerts” on page 54
򐂰 “Managing Web Services response time” on page 55
򐂰 “Debugging performance of Web Services” on page 69
򐂰 “Understanding Web Services calling pattern” on page 74
򐂰 “Working with Web Services filtering” on page 87
򐂰 “Web Services life cycle” on page 90
© Copyright IBM Corp. 2008. All rights reserved.
49
3.1 Basic monitoring concepts
In this chapter, we discuss the basic monitoring functions for Web Services. You
use the monitoring methods discussed in this chapter to manage an SOA-based
application. Because these functions are used by the primary users of SOA
management, these functions are critical in Web Services management. The
discussion in this chapter applies to generic Web Services management with or
without mediation.
We demonstrate this management on our setup of a Trader application that is
described in Appendix A, “The Trader application” on page 179. The
management information comes primarily from IBM Tivoli Composite Application
Manager (ITCAM) for Response Time Tracking, ITCAM for SOA, and ITCAM for
WebSphere. The interfaces are the Web console of the products or Tivoli
Enterprise Portal.
Figure 3-1shows the application environment that is discussed in this chapter.
perth
srv107
laredo
WebSphere Application
Server
TraderClientWeb
WebSphere Process Server
TraderDBAvailabilityMediati
onApp
WSRR
WebSphere Application
Server
TraderDBServices
lima
DB2 Universal Database
TRADERDB
khartoum
WebSphere Application
Server
TraderDBServices
Figure 3-1 Application environment
The application has a client component, which goes through Enterprise Service
Bus mediation, which calls the server component using Web Services and
accesses a database in the back end.
50
Managing an SOA Environment with Tivoli
3.2 Performance metric of Web Services
The workspaces of ITCAM for SOA in the Tivoli Enterprise Portal are arranged to
show Web Services calls by servers. Figure 3-2 shows this structure. The Web
Services calls are typically identified by the following attributes:
򐂰 Frequency
򐂰 Response time
򐂰 Message length
Figure 3-2 Primary workspace for ITCAM for SOA
The workspace in Figure 3-2 displays the primary metrics that are collected by
ITCAM for SOA. It shows all active Web Services calls in the duration. In our
Trader application, we have three Web modules, each one accessing DB2,
Chapter 3. Basic SOA and Web Services management
51
CICS, and IMS. Each Web module serves four Web Services calls:
getCompanies, getQuote, buy, and sell.
Figure 3-3 shows a performance summary display. The detailed information of
the Web Services call performance is shown in a table. The average response
time by operation summary chart is on the upper right.
Figure 3-3 Performance Summary
52
Managing an SOA Environment with Tivoli
The message summary page shows the message statistics (Figure 3-4). This is
typically useful to assess the network capacity requirement for the Web Services,
because it shows both the length and the number of messages for the server.
Figure 3-4 Message Summary
Chapter 3. Basic SOA and Web Services management
53
From a different branch, the message arrival rate is shown in Figure 3-5. This
shows the activity of the server in general.
Figure 3-5 Message Arrival rate
3.3 Generating events and alerts
Events and alerts are created based on the situation. In the simplest case for an
SOA-based application, the situation can be checked against Web Services
response time, message rate, and overall message size. These measurement
metrics are collected from ITCAM for SOA.
Here, we demonstrate the creation of a situation based on several of these
metrics. Start from the Tivoli Enterprise Portal:
1. Open the create situation dialog using
.
2. Select the Service Metrics or Service Inventory attribute group. The Service
Metrics attribute group contains individual invocation of services, while
Service Inventory contains an aggregated statistic. Most installations do not
collect Service Metrics attributes.
54
Managing an SOA Environment with Tivoli
3. Select the attributes against which you want to measure and specify the
threshold.
4. Set the monitoring intervals and save the situation.
5. Monitor the attribute values when the situation fires.
In a general SOA-based environment, you might need to monitor the following
typical metrics in order to assure the application health:
򐂰 ITCAM for WebSphere:
– Application server status
– Request rate
– Request response time
򐂰 ITCAM for Response Time Tracking:
– Application response time from the robotic application
– Client response time tracker definition
– Web response time information
򐂰 ITCAM for SOA:
– Message rate
– Response time
– Message size
3.4 Managing Web Services response time
You can correlate the Web Services processing response time to the overall
users’ response time. The Web Services processing response time is typically
collected from the Web Services component of the ITCAM for Response Time
Tracking. In this section, we discuss the usage of ITCAM for Response Time
Tracking to monitor the response time of an SOA-based application.
ITCAM for Response Time Tracking has methods of collecting response time
information, such as a robotic simulation or HTTP traffic monitoring. In this
section, we discuss the ITCAM for Response Time Tracking monitoring using the
Rational Performance Tester and Web Response Monitoring. We also use the
Java 2 Platform, Enterprise Edition (J2EE) component to monitor the application
servers on which the SOA application runs.
We divide this discussion into:
򐂰 “Execution environment” on page 56
Chapter 3. Basic SOA and Web Services management
55
򐂰
򐂰
򐂰
򐂰
“Creating Rational Performance Tester script” on page 56
“Defining Web Response Monitor policies” on page 59
“Reports generated from the policies” on page 63
“Tivoli Enterprise Portal workspaces” on page 64
3.4.1 Execution environment
Figure 3-6 shows our ITCAM for Response Time Tracking execution
environment.
perth
WebSphere Application
Server
TraderDBServices
J2EE
srv107
laredo
WebSphere Application
Server
TraderClientWeb
J2EE
WebSphere Process Server
TraderDBAvailabilityMediati
onApp
WSRR
J2EE
lima
DB2 Universal Database
TRADERDB
khartoum
ARM
WebSphere Application
Server
TraderDBServices
J2EE
gruene
srv106
Rational Performance
Tester
ITCAM for Response Time
Tracking
Management server
RPT
Figure 3-6 ITCAM for Response Time Tracking environment
We monitor this application by using the components deployed on the monitoring
agents. Depending on how detailed you need the performance information, you
can use either one of these methods.
You can collect the ordinary interaction from users by using the Web Response
Monitor components. Use the Rational Performance Tester to collect a
representative interaction, and then you can use the Rational Performance Tester
interaction to establish an average performance baseline.
3.4.2 Creating Rational Performance Tester script
We describe the Rational Performance Tester record procedure with the Trader
application.
56
Managing an SOA Environment with Tivoli
Perform the following steps:
1. On the Rational Performance Tester installed machine, click Start → All
Programs → RPT → IBM Rational Performance Tester → IBM Rational
Performance Tester. Enter the project file location.
2. Click the File → New → Test From Recording. Then, click Create Test
From New Recording and HTTP Test, open the Create New Test From
Recording Dialog. Define the project name and recording file name, and then
click Finish, as shown in Figure 3-7.
Figure 3-7 Starting Record Rational Performance Tester http script
Chapter 3. Basic SOA and Web Services management
57
3. We record the Trader application transaction using Microsoft Internet
Explorer®. Close the Internet Explorer browser. The script is available to edit,
as shown in Figure 3-8.
Note: We only use the Rational Performance Tester HTTP script for
Microsoft Internet Explorer. For more information about Rational
Performance Tester usage, refer to the online help of Rational Performance
Tester.
Figure 3-8 Created transaction script by Rational Performance Tester
58
Managing an SOA Environment with Tivoli
4. To use the Rational Performance Tester script on the management server,
export the recorded transaction to the management server using the RTT
plug-ins. Right-click the script name in the test navigator panel and select
Export, select ITCAM Response Time Tracking as the export destination,
and click Next. Enter the management server information, as shown in
Figure 3-9. Click Next.
Figure 3-9 Export the recorded transaction by Rational Performance Tester
3.4.3 Defining Web Response Monitor policies
The definition of the Web Response Monitor policy is divided into discovery and
then monitoring. You cannot just create a new listening monitor.
Web Response Monitor discovery
We deployed the Web Response Monitor. It runs within the IBM HTTP Server,
V1.3.26.1. We did not configure a separate Web server for the Web Response
Monitor.
Chapter 3. Basic SOA and Web Services management
59
To monitor with the Web Response Monitor, you need to create the discovery to
determine what transactions are in the Web server.
To configure the Web Response Monitor discovery:
1. Select Configuration → Discovery. Choose Web Response Monitor from
the drop-down list box, as shown in Figure 3-10, and click Create New.
Figure 3-10 Web Response Monitor Discovery
60
Managing an SOA Environment with Tivoli
2. Enter the WRM settings to discover the transaction in the Web server and
click Next. Figure 3-11 shows the WRM discovery settings.
Figure 3-11 Web Response Monitor Discovery settings
Chapter 3. Basic SOA and Web Services management
61
3. After the discovery monitor configuration, we generated the Trader
application. After capturing several transactions, you get the discovered
transactions, as shown in Figure 3-12.
Figure 3-12 Discovered Web transactions by the Web Response Monitor
Web Response Monitor listening monitor
From the discovered Web transactions shown in Figure 3-12, we define the
listening monitor.
62
Managing an SOA Environment with Tivoli
To create the Web Response Monitor listening monitor, select the URL of the
discovered Web transaction and choose Create Listening Monitor From from
the menu. Click Go. Configure the WRM settings for the listening monitor as
shown in Figure 3-13.
Figure 3-13 Web Response Monitor listening monitor settings
3.4.4 Reports generated from the policies
We discuss the reports in two sections, because the reports show different
perspectives. The Rational Performance Tester reports define a reference
baseline of a specific performance metric. The Web Response Monitor collects
Chapter 3. Basic SOA and Web Services management
63
user response time experience in a distributed application environment.
Figure 3-14 shows a sample topology.
Figure 3-14 Sample topology information
3.4.5 Tivoli Enterprise Portal workspaces
In this section, we demonstrate the type of information from Web Services that
you can gather from Tivoli Enterprise Portal when running Tivoli Enterprise
Monitoring Agent for ITCAM for Response Time Tracking.
We customized the logical view for ITCAM for Response Time Tracking.
Figure 3-15 on page 65 shows the agent status and message.
64
Managing an SOA Environment with Tivoli
Figure 3-15 Response Time Tracking portal workspace
Chapter 3. Basic SOA and Web Services management
65
Select the Response Time Tracking Agent Policy Groups, which opens the
primary interface for ITCAM for Response Time Tracking, as shown in
Figure 3-16. The policy groups summary shows the defined reporting groups in
ITCAM for Response Time Tracking. To view the detailed reporting group
information, click the icon
to the left of the TraderWeb reporting group.
Figure 3-16 Response Time Tracking Agent Policy Groups
66
Managing an SOA Environment with Tivoli
It links to the reporting group TraderWeb under the monitor summary, as shown
in Figure 3-17. You can see the monitor status of the reporting group TraderWeb.
To check each monitor’s status, click the icon
by the policy name.
Figure 3-17 Policy Status for Policy Group
Chapter 3. Basic SOA and Web Services management
67
In Figure 3-18, Tivoli Enterprise Portal shows STI_QoS_TraderWeb, the
Synthetic Transaction Investigator (STI) robotic monitors status. For more
detailed status, click the icon
. This icon links to the related workspace.
Figure 3-18 STI_QoS_TraderWeb Robotic Monitor Status
68
Managing an SOA Environment with Tivoli
Tivoli Enterprise Portal provides historical data by configuring and starting
historical data collection. For more information about the historical data collection
settings, refer to IBM Tivoli Monitoring documentation. Figure 3-19 shows an
example of the agent availability historical data over the last eight hours.
Figure 3-19 Display the agent availability historical data in Tivoli Enterprise Portal
3.5 Debugging performance of Web Services
You can trace the performance of Web Services by using ITCAM for
WebSphere. The interface allows you to diagnose the problem in-depth on a
J2EE-based application. The monitoring for ITCAM for WebSphere is performed
on different levels. Because we assume that you are running the monitoring for
Chapter 3. Basic SOA and Web Services management
69
ITCAM for WebSphere in order to debug a problem on a production system, we
suggest that you run at level 2. Monitoring level 3 generates significant overhead
that you might not want on your production system.
You can analyze the performance of Web Services by using a set of
Performance Analysis reports for your investigation. Follow these steps to
investigate the performance:
1. Go to Performance Analysis → Application Reports →
Request/Transaction.
2. You can change the reporting options to identify the appropriate time ranges
and servers that you want to investigate in order to meet your needs. We
recommend that you start from the application servers that are closest to the
users that are the Web Services requestors.
3. From the bar chart in Figure 3-20, select the appropriate bar that you want to
investigate to go to the decomposition chart. We choose the decomposition
chart that shows the transaction by different request names.
Figure 3-20 Bar chart
4. Select the servlet request that you want to investigate from the decomposition
chart in Figure 3-21 on page 71. We investigate the ListCompanyServlet.
70
Managing an SOA Environment with Tivoli
Figure 3-21 Decomposition chart
5. The ListCompanyServlet flow view is shown in Figure 3-22 on page 72. The
request detail is shown in monitoring level 2. The flow view provides the
easiest view to quickly show problems for a small number of components.
The shaded rows are the rows that exceed the threshold that is specified at
the top of the page. You can change this threshold dynamically.
Chapter 3. Basic SOA and Web Services management
71
Figure 3-22 Requestor report detail
6. The link arrow in the center of Figure 3-22 shows the invocation flow to
another request on a different application server. The invocation is indicated
as invoked from a Web Services client process. We follow the link to the Web
Services invocation request.
7. The Web Services provider flow view is shown in Figure 3-23 on page 73.
72
Managing an SOA Environment with Tivoli
Figure 3-23 Web Services provider flow view
Chapter 3. Basic SOA and Web Services management
73
8. The flow view in Figure 3-23 on page 73 shows more components, because
the Web Services provider actually performs an inquiry function. Again shown
in monitoring level 2, the Web Services provider flow indicates the major
components of the transaction. The transaction runs Java Naming and
Directory Interface (JNDI), Enterprise Java Bean (EJB), and Java Database
Connectivity (JDBC) calls.
9. You can go back to the Web Services requestor by using the correlation link
shown in the arrows.
3.6 Understanding Web Services calling pattern
The Web Services calling patterns can be established by the trace of the Web
Services calls. The calls can be logged into log files, and these log files can be
analyzed using the Web Services Navigator. We explain the process to run Web
Services Navigator in:
򐂰 “Turning on the content logging for a Web Service” on page 74
򐂰 “Using the Log Assembler tool” on page 78
3.6.1 Turning on the content logging for a Web Service
The following procedure illustrates the steps involved in turning on the content
logging for Web Services:
1. In Tivoli Enterprise Portal, use the navigation tree and select Enterprise →
<OS> → <machine> → Service Management Agent Environment → D4::
<agent> → Performance Summary. See Figure 3-24.
Figure 3-24 Services inventory list
74
Managing an SOA Environment with Tivoli
2. From the bottom Services Inventory query that lists the Web Services and the
associated operations, run Take Action → Select as shown in Figure 3-25.
Figure 3-25 Select a service on which to take action
3. Running the action, select AddMntrCntrl_610 from the drop-down list box to
add a monitoring control for certain services. See Figure 3-26 on page 76.
The parameters for the commands target a specific Web Service. You can
also perform an UpdMntrCntrl to modify the default settings for all Web
Services calls. Select the logging level:
(Services_Inventory_610.DataCollectorMessageLoggingLevel) to Full to
monitor the Web Services transactions into the log. Click OK to save the
arguments.
Chapter 3. Basic SOA and Web Services management
75
Figure 3-26 Select a action to take
4. In the resulting Web Services action window, select the target agent or
destination system. The default agent from which you invoke the command is
preselected. See Figure 3-27. Click OK.
Figure 3-27 Run the action on the agent
5. After the action runs successfully (return code:0), you will get a message
similar to Figure 3-28 on page 77. Click OK.
76
Managing an SOA Environment with Tivoli
Figure 3-28 Action ran successfully
6. Verify that the directory /opt/IBM/ITM/li6243/KD4/logs or the directory
\IBM\ITM\TMAITM6\KD4\logs contains the *.content.log files and the
*.metric.log files.
After collecting the content for a period of time, you can turn the monitoring off by
running the same DelMntrCntrl (or UpdMntrCntrl) to stop the content logging.
Content logging generates additional processing and takes up disk space. Again,
the result of the action needs to be 0.
You can check the current monitor setting in the Service Management agent
workspace in the Data Collector Monitor Control Configuration query shown in
Figure 3-29.
Figure 3-29 Refresh workspace
Chapter 3. Basic SOA and Web Services management
77
3.6.2 Using the Log Assembler tool
With the Log Assembler tool, you can specify the nature of the transactions that
you want to analyze. You perform the data collection by using the monitor control
action. The monitor control actions are:
򐂰 AddMntrCntrl: Adding a new control
򐂰 UpdMntrCntrl: Updating an existing control
򐂰 DelMntrCntrl: Deleting an existing control
By default, each data collector has a global definition of no monitor control
logging for all Web Services calls. You can specify individual control by:
򐂰
򐂰
򐂰
򐂰
Service port namespace
Service port
Operation namespace
Operation
Note: Two important items:
򐂰 The ports here are not TCP/IP ports; these service ports are port
definitions in the wsdl file.
򐂰 A monitoring control definition exists with all attributes set as wildcards (*).
You must use UpdMntrCntrl to change this from wildcards.
We decided to add monitor control for an individual service port for our Web
Services: TraderDBServices, TraderIMSServices, and TraderCICSServices.
Figure 3-30 shows the action invocation for TraderIMSServices.
Figure 3-30 Monitor control action
78
Managing an SOA Environment with Tivoli
The resulting control can be seen in the Services Management Agent
workspace. Figure 3-31 shows the monitor list.
Figure 3-31 Monitor list
This monitor control specification generates the metric log and content log files in
the $ITMhome\TMAITM6\KD4\logs:
򐂰 The content log is stored for each data collector. Each content log file can be
up to 500 MB in size. The file name of the content log is in the format of:
KD4.<env>..<cell>.<node>.<server>.content.log
򐂰 There are multiple metric log files. The metric logs are stored in either the
KD4.DCA.CACHE or KD4.DCA.CACHE\archive subdirectory of the logs
directory. These files have the name of:
KD4.<env>..<cell>.<node>.<server>.metric.log.<timestamp>
You must select the appropriate content logs and metric logs and collect them to
the machine on which you install the Web Services Navigator. The Log
Assembler tool is installed with the Web Services Navigator. The Log Assembler
processes and merges each metric log, while retrieving the message content
from the content log file. The result is then a single merged metric log file from
multiple servers (each server has its own message contents attached).
Chapter 3. Basic SOA and Web Services management
79
The easiest way to process these logs is by using a batch file, because the file
names are long and you have to invoke the command multiple times. In our tests,
we invoke 108 Web Services calls within three minutes on two application
servers. This gave us 28 metric log files and two content log files. Figure 3-32
shows our log files.
Figure 3-32 Log files
80
Managing an SOA Environment with Tivoli
We use the batch file in Example 3-1 to process these log files.
Example 3-1 Running Log Assembler
SET TOOLPATH="C:\IBM\ITCAM for SOA 6.1.0\Tools"
SET LOGAJAR=com.ibm.websightView.LogAssembler.jar
cd \soalogs
for %%i in (*.ClientSvc.metric.log.*) do %toolpath%\_jvm\jre\bin\java
-cp %toolpath%\lib\%logajar%;%toolpath%\lib\jlog.jar -jar
%toolpath%\lib\%logajar% 0 a soa.Merged.log C:\soalogs\%%i
C:\soalogs\KD4.1..PERTHCell01.PERTHNode01.ClientSvc.content.log
for %%i in (*.ServerSvc.metric.log.*) do %toolpath%\_jvm\jre\bin\java
-cp %toolpath%\lib\%logajar%;%toolpath%\lib\jlog.jar -jar
%toolpath%\lib\%logajar% 0 a soa.Merged.log C:\soalogs\%%i
C:\soalogs\KD4.1..PERTHCell01.PERTHNode01.ServerSvc.content.log
Note that from Example 3-1:
򐂰 The Log Assembler must be invoked separately for each server. The metric
log for ClientSvc must be processed with the content log for ClientSvc; you
cannot combine the processing.
򐂰 The Log Assembler uses two JAR files: the LogAssembler.jar and jlog.jar.
򐂰 The arguments of the command are:
logging level
processing
target log file name
metric log file name
content log files
0, 1, or 2; nonzero values generate a lot of output
o or a; represents overwrite or append to the log files
The merged log file name
The metric log that you want processed
The content log files for a single server
Chapter 3. Basic SOA and Web Services management
81
We are now ready to import the log file into Web Services Navigator:
1. First, we need an empty project (or an existing one) to store the imported log
file definitions. Select File → New → Project. Then, we choose a simple
project (Simple → Project) and then we enter the project name to create a
simple project (Figure 3-33).
Figure 3-33 Creating a project
82
Managing an SOA Environment with Tivoli
2. We then import the log file. Select File → Import and select from the file
system the merged log from the Log Assembler tool. Figure 3-34 shows the
import process.
Figure 3-34 Importing log files
In Figure 3-34, note that we experimented with the log files. We have
individual server log files and the merged log files. The individual server log
files do not generate a full picture of the Web Services calls. The following
discussion covers the merged log file only.
Chapter 3. Basic SOA and Web Services management
83
We have the Service Topology view of the merge log shown in Figure 3-35.
Figure 3-35 Service Topology
In Figure 3-35, the figure shows the calling pattern of the Web Services. The
green boxes indicate the service name and the operations are listed within it. The
arrows indicate service calls with numbers showing the number of invocations.
You can also summarize the calls based on the service name instead of the
operation name by collapsing the boxes, as shown in Figure 3-36.
Figure 3-36 Operation summary
84
Managing an SOA Environment with Tivoli
Figure 3-37 shows the transaction flows. It shows the time line of the Web
Services calling sequences. The busy chart shows all 108 Web Services calls
that we made.
Figure 3-37 Transaction flows
Chapter 3. Basic SOA and Web Services management
85
Hovering the cursor over any of those lines provides the call details of the Web
service. Selecting the service shows yellow highlighting and displays the details
in the bottom pane (Figure 3-38).
Figure 3-38 Message Content
86
Managing an SOA Environment with Tivoli
The flow pattern summarizes the transaction flows in Figure 3-37 on page 85 and
collapses any similar invocation pattern. A pattern can be identified by the
requestor, provider, service name, and operation name. Figure 3-39 shows the
flow pattern.
Figure 3-39 Flow Patterns
3.7 Working with Web Services filtering
Web Services calls can be rejected by ITCAM for SOA. This capability is
provided as part of the default action of ITCAM for SOA. These actions can be
invoked manually or triggered by a situation.
This section demonstrates invoking the action manually to reject a certain Web
Services call.
Chapter 3. Basic SOA and Web Services management
87
It makes sense to invoke the filtering action from the Message Arrival table or
from the Message Summary table when you see a lot of unexpected messages
flowing through the system. You can invoke the action by using the context
menu, as shown in Figure 3-40.
Figure 3-40 Invoking an action
We invoke the addFltrCntrl action. This action requires a set of parameters, as
shown in Figure 3-41. Depending on where you initiate the action, you can get
prefilled data for these arguments.
Figure 3-41 Action parameters
88
Managing an SOA Environment with Tivoli
After the action has been completed, you can see the effective setting in the
Services Management Agent workspace, as shown in Figure 3-42.
Figure 3-42 Rejected Web Services call
Chapter 3. Basic SOA and Web Services management
89
The rejected Web Services calls show up as faults in the fault summary list.
Figure 3-43 shows the Fault Details list.
Figure 3-43 Rejected Web Services call faults
You can remove the filter using the DelFltrCntrl action, as shown in Figure 3-44.
This is invoked from the filter list table in Figure 3-42 on page 89 directly, which is
why the arguments are automatically already filled in.
Figure 3-44 Removing a filter
3.8 Web Services life cycle
You must install WebSphere Service Registry and Repository Discovery Library
Adapter on the server where WebSphere Service Registry and Repository is
90
Managing an SOA Environment with Tivoli
installed. The Discovery Library Adapter is supplied from ITCAM for SOA under
the installation image KD4/DLA/ as WSRRV600_DLA.zip and
WSRRV600_DLA_fixpack.zip. We unzip both files under the
/opt/IBM/WSRRV6_DLA path.
Note: To use the Discovery Library Adapter with WebSphere Service Registry
and Repository V6.0.2, you have to copy sdo-int.jar from <WSRR-home> to
<WAS-home>/classes and restart the WebSphere Application Server that
hosts WebSphere Service Registry and Repository.
To use the Discovery Library Adapter with WebSphere Service Registry and
Repository V6.0.2, from the /opt/IBM/WSRRV6_DLA/bin directory, edit the
WSRR_DLA.config.properties and DLA_FileTransfer.properties:
1. In WSRR_DLA.config.properties, you must at least customize the parameters
in Example 3-2. This file specifies how to communicate with the WebSphere
Service Registry and Repository API.
Example 3-2 Access to WebSphere Service Registry and Repository
com.ibm.management.soa.dla.wsrr.address=laredo
com.ibm.management.soa.dla.wsrr.port=2809
com.ibm.management.soa.dla.wsrr.domainName=itsc.austin.ibm.com
com.ibm.management.soa.dla.wsrr.websphereSecurityEnabled=false
com.ibm.management.soa.dla.wsrr.securityEnabled=false
com.ibm.management.soa.dla.wsrr.userid=
com.ibm.management.soa.dla.wsrr.password=
2. In DLA_FileTransfer.properties, you must specify the host on which the Tivoli
Common Object Repository is installed and the path to store the IdML books.
These parameters are shown in Example 3-3. The ftp password will be
encoded after the first invocation of the file transfer program.
Example 3-3 File transfer properties
com.ibm.management.soa.dla.filetransfer.host=peoria.itsc.austin.ibm.com
com.ibm.management.soa.dla.filetransfer.targetDir=/opt/IBM/WSRRV6_DLA/s
taging
com.ibm.management.soa.dla.filetransfer.stagingDir=../staging
com.ibm.management.soa.dla.filetransfer.fileFilter=*.xml
com.ibm.management.soa.dla.filetransfer.securityEnabled=true
com.ibm.management.soa.dla.filetransfer.userid=root
com.ibm.management.soa.dla.filetransfer.password=******
com.ibm.management.soa.dla.filetransfer.password.encoded=aXRzMGcwMGQ=
Chapter 3. Basic SOA and Web Services management
91
3. The logging option for both the discovery and file transfer that we use is
shown in Example 3-4. The option allows us to understand the processing
better.
Example 3-4 Logging option
com.ibm.management.soa.dla.wsrr.log.logFileName=WSRRDLALog.log
com.ibm.management.soa.dla.wsrr.log.logFileDir=../logs
com.ibm.management.soa.dla.wsrr.log.loggingLevel=DEBUG_MAX
com.ibm.management.soa.dla.wsrr.log.logFileSize=2000000
com.ibm.management.soa.dla.wsrr.log.logFileCount=3
com.ibm.management.soa.dla.wsrr.log.enableLogging=true
com.ibm.management.soa.dla.wsrr.log.logToFile=true
com.ibm.management.soa.dla.wsrr.log.logToConsole=true
4. We run the discover using the command ./WSRR_DLA.sh -r to create a
refresh XML data book. Figure 3-45 shows the execution of this command.
[root@laredo bin]# ./WSRR_DLA.sh -r
2007-07-06 15:32:21.793-05:00 [main] KD4SR0017I The discovery
library adapter is starting its discovery process.
2007-07-06 15:32:28.982-05:00 [P=941820:O=0:CT] KD4SR0010I The
discovery library adapter book:
WSRRv600.laredo.itsc.austin.ibm.com.2007-07-06T20.32.25.659Z.refresh
.xml was generated and stored into the following directory:
../staging/.
2007-07-06 15:32:29.020-05:00 [P=941820:O=0:CT] KD4SR0018I The
discovery library adapter is exiting its discovery process.
2007-07-06 15:32:29.591-05:00 [main] KD4FT0020I The file transfer
process is starting.
KERBEROS_V4 rejected as an authentication type
2007-07-06 15:32:31.347-05:00 [main] KD4FT0009I The file:
../staging/WSRRv600.laredo.itsc.austin.ibm.com.2007-07-06T20.32.25.6
59Z.refresh.xml was successfully transferred to host:
peoria.itsc.austin.ibm.com
2007-07-06 15:32:31.930-05:00 [main] KD4FT0021I The file transfer
process is ending.
Figure 3-45 Running the Discovery Library Adapter
5. You load the discovery book by running the bulk load script:
/opt/IBM/ITM/li6243/cq/Products/KD4/tcore/bin/loadidml.sh -f
92
Managing an SOA Environment with Tivoli
You can add the ITCAM for SOA view to the view list in the Tivoli Enterprise
Portal. From Tivoli Enterprise Portal, click the Administer Users icon
in the
tool bar. The Administer Users pop-up window is shown in Figure 3-46.
Figure 3-46 Administer Users: Navigator Views
Click Apply and then click OK to add the ITCAM for SOA view to the drop-down
list of the views.
The following steps work with the ITCAM for SOA view:
1. The resulting display in Tivoli Enterprise Portal for selecting SOA view is
shown in Figure 3-47 on page 94. Click on the View drop-down list and select
the ITCAM for SOA view.
Chapter 3. Basic SOA and Web Services management
93
Figure 3-47 Select ITCAM for SOA view
2. The workspace lists the Web Services that have been loaded from the
loadidml command. See Figure 3-48.
Figure 3-48 Services Management: Services Overview
94
Managing an SOA Environment with Tivoli
3. From the Services Overview table shown in Figure 3-48 on page 94, the data
from WebSphere Service Registry and Repository is indicated with a check in
the check box in the Registered column. Right-click an entry and select View
Service Detail. The topology of the Web Services is shown in Figure 3-49.
The Topology view discovers and displays the Service, Service Port, and the
operations that are provided by the service.
Figure 3-49 Topology view of the selected service
4. If you hover the mouse over a object icon, that object’s parameters are
displayed.
Chapter 3. Basic SOA and Web Services management
95
Figure 3-50 Move the mouse pointer over the object to view the object’s properties
ITCAM for SOA Discovery Library must be installed on the machine where
ITCAM for SOA is running. Extract the file ITCAMSOA61_DLA.zip from the
ITCAM for SOA installation disk under KD4/DLA. We extract this file to
/opt/IBM/ITCAMSOA61_DLA.
We edit the KD4DiscoveryLibraryAdapter.properties and
DLAFileTransfer.properties. This property file is similar to the
WSRR_DLA.config.properties.
Load the IdML file. Figure 3-51 on page 97 displays the data discovered by the
ITCAM for SOA Discovery Library Adapter. The table displays both the Web
Services registered with the WebSphere Service Registry and Repository and
the Web Services that are being observed by ITCAM for SOA.
96
Managing an SOA Environment with Tivoli
Figure 3-51 Services overview with observed and registered Web Services
Select Service Detail from an observed service to get into the detailed view of
the service as shown in Figure 3-52 on page 98. The service port topology view
displays the service port details discovered by the Discover Library Adapter, the
service operations, and the Application servers that provide the service.
Chapter 3. Basic SOA and Web Services management
97
Figure 3-52 Topology view showing the servers that provide the service
Move the mouse pointer over the objects in the topology view to view the
properties associated with each object as discovered by the Discovery Library
Adapter. Figure 3-52 displays the properties associated with one of the
Application Servers providing the Trader IMS Service.
98
Managing an SOA Environment with Tivoli
4
Chapter 4.
Advanced SOA management
In this chapter, we explore more of the service-oriented architecture (SOA)
management and delve into managing SOA with the mediation layer to achieve
Web Services failover and balanced load. We discuss the following topics:
򐂰 “Mediation and SOA” on page 100
򐂰 “Enterprise Service Bus” on page 102
򐂰 “Maintaining Web Services continuity” on page 104
򐂰 “Service monitoring automation” on page 136
򐂰 “Using managed message logger” on page 155
򐂰 “Summary” on page 158
© Copyright IBM Corp. 2008. All rights reserved.
99
4.1 Mediation and SOA
SOA provides us with the flexibility to build composite applications using
reusable services in more standardized ways using standard transport protocols.
Flexibility, however, also brings in new challenges of managing the services in a
vastly distributed environment that spans multiple tiers and operating
environments. A single service can find itself being consumed by a number of
applications or business processes. Gaining insight to the service execution from
a runtime perspective, as well as from a service life cycle perspective, is equally
important. Consider that for SOA:
򐂰 Services can be developed in various application and operating system
environments.
򐂰 J2EE application servers, such as WebSphere, BEA WebLogic, and SAP
Netweaver, are supported.
򐂰 A service might span multiple tiers, including IMS or CICS, on the mainframe.
򐂰 Multiple operating system environments, such as Windows, AIX®, Linux,
.NET, z/OS, and so on, are supported.
Management solutions must be able to address the diverse operating
environment of an SOA.
In this chapter, we explore how we can use multiple IBM Tivoli offerings to
manage and maintain services in an SOA environment. We explore automation
capabilities from IBM Tivoli Monitoring and IBM Tivoli Composite Application
Manager (ITCAM). We also discuss the integration features of ITCAM with the
enterprise service bus technologies, such as WebSphere Enterprise Service Bus
and WebSphere Message Broker. We also include the service registry in
WebSphere Service Registry and Repository (WSRR) integration in our
scenario. The objective is to keep services in an SOA environment healthy and
resilient.
Enterprise Service Bus (ESB) plays an important role in SOA. It decouples the
service consumer from the service provider. It can be thought of as a flexible
communication environment that connects the service consumer and service
provider. ESB makes it possible to introduce additional application or operational
logic transparently without changing the service consumer or service provider.
Figure 4-1 on page 101 shows the enterprise service bus concept.
100
Managing an SOA Environment with Tivoli
Enterprise Service Bus
(ESB)
Service Consumer
Service Instance 1
Service Instance 2
Figure 4-1 Services in an SOA
Service Instance 1 and Service Instance 2 shown in Figure 4-1 have the same
service interface; however, they might share the same implementation or a
different implementation. The service consumer is bound to the service provider
either directly or by using logic that we refer to as mediation. The target service
endpoint can be bound at deployment time or at run time.
Enterprise Service Bus enables you to insert mediation logic between the service
consumer and the service provider. Mediations can look at the service request
data to make certain decisions or can refer to an external component, such as
database or a service registry, to help execute mediation logic that affects the
service request flow within an Enterprise Service Bus. As an example, consider
mediation logic that uses a service registry component that is used to query and
retrieve a choice of target service endpoints to which the service requestor can
be routed based on certain criteria, such as quality of service and service
availability.
From a system management perspective, mediation enables us to monitor
service invocations, perform on demand logging of service requests and
response data, observe service executions, and reconcile discovered services
with known services in a service registry. In addition to monitoring service data,
the ability to control service requests based on operational data provides for a
number of use case scenarios that offer tremendous value to any enterprise
building its applications in an SOA environment.
Chapter 4. Advanced SOA management
101
4.2 Enterprise Service Bus
IBM offers three enterprise service bus technologies:
򐂰 WebSphere DataPower Integration Appliance
WebSphere DataPower is an XML appliance, which is capable of processing
XML at wire speed, is optimized to process SOAP messages, and can also
transform and route SOAP messages, providing functions of a service bus.
򐂰 WebSphere Enterprise Service Bus
WebSphere Enterprise Service Bus is built on WebSphere Application Server
and offers Java 2 Platform, Enterprise Edition (J2EE) standards-based
connectivity for an SOA environment. WebSphere Enterprise Service Bus
uses Service Component Architecture (SCA) to model service connectivity.
The Service Component Architecture is based on SCA modules, each of
which consists of one or more SCA components. WebSphere Enterprise
Service Bus provides runtime environments for SCA modules that deal with
mediation or message flow logic within the enterprise service bus.
򐂰 WebSphere Message Broker
WebSphere Message Broker provides universal connectivity and
transformations in heterogeneous environments.
ITCAM for SOA supports monitoring all these Enterprise Service Bus
technologies. The current version of ITCAM for SOA also supports advanced
capabilities to control service request flows in WebSphere Enterprise Service
Bus.
For this chapter, we focus on the WebSphere Enterprise Service Bus and how it
integrates with ITCAM for SOA. WebSphere Enterprise Service Bus is built on
WebSphere Application Server Network Deployment. In addition to the standard
J2EE-based application environment, it offers a number of mediation primitives
that help building mediation flows. The mediation primitives are used to build
mediation flows and are deployed as mediation modules. The mediation modules
are themselves SCA modules. The mediation flows help connect the service
consumer and service provider without needing to know the implementation
details of the service provider.
The mediation flows are created by using WebSphere Integration Developer
Integrated Development Environment. WebSphere Integration Developer is an
Eclipse-based development environment that is used to create SCA application
and mediation flows. It provides a palette of customizable pre-built objects called
mediation primitives that can be used to intercept and control the service request
and response message flows, such as Logger, Message Filter, XSL
Transformation, Message Element Setter, Database Lookup, and Endpoint
102
Managing an SOA Environment with Tivoli
Lookup. You can create the mediation flow application by using a drag and drop
interface with minimal or no programming.
Note: WebSphere Process Server is an application server for executing
business processes. It is built on J2EE standards and also uses the
WebSphere Enterprise Service Bus technology for service bus and mediation
capabilities. All discussions about WebSphere Enterprise Service Bus also
apply to WebSphere Process Server. For more information about WebSphere
Enterprise Service Bus, refer to Getting Started with WebSphere Enterprise
Service Bus, SG24-7212, at:
http://www.redbooks.ibm.com/abstracts/sg247212.html?Open
ITCAM for SOA extends the following mediation primitives, which are called
managed mediation primitives:
򐂰 Managed XSL Transformation conditionally transforms a message as it flows
through the ESB.
򐂰 Managed Message Filter conditionally selects a service endpoint.
򐂰 Managed Message Logger conditionally logs service request message data.
򐂰 Managed Message Fail conditionally fails a message and generates a service
fault.
Each of these managed mediations can be enabled and disabled at run time
from the operations environment using Tivoli Enterprise Portal either manually
using a Take Action menu entry or by using a predefined situation to perform an
action.
Operational control of service requests and response flows in the WebSphere
Enterprise Service Bus has a number of useful applications:
򐂰 Operationally control on demand logging of messages for auditing purposes.
򐂰 Dynamically route service requests to alternate service if the primary service
provider or a dependent resource, such as a queue manager, database,
network, or storage, fails.
򐂰 Monitor the runtime quality of a service and update the service quality
properties in a service registry, such as WebSphere Service Registry and
Repository. You can then use this during the service assembly phase to
determine if a given service will meet the application requirements.
򐂰 Exploit the runtime service performance and service information to enhance
the SOA governance process.
򐂰 Introduce, in a controlled way, a new implementation of a service into an SOA
environment by temporarily routing service requests to an alternate service.
Chapter 4. Advanced SOA management
103
򐂰 Monitor for denial of service attacks, force service requests with certain
characteristics (such as originating IP address or a message data signature),
and force a service fault.
򐂰 Apply message transformations to route service flows or affect service
behavior only when certain operational thresholds are violated.
The managed mediation capability of ITCAM for SOA is made available in the
WebSphere Integration Developer environment using the ITCAM for SOA tools
package, which installs a plug-in for managed mediation primitives into
WebSphere Integration Developer (WID). The plug-in provides a palette of
managed mediation primitives that you can select and drop into message flows
just like other mediation primitives provided by WebSphere Enterprise Service
Bus.
4.3 Maintaining Web Services continuity
Ensuring that a service is available to meet the agreed upon service level
agreements (SLAs) is a common nonfunctional requirement for enterprise
applications. You can create the SLAs at different levels. For example, from a
user’s perspective, you can base the SLA on the application user interface
response time. In an SOA environment, the user application user interface can,
in turn, depend on a service implementation that has additional dependencies on
resources, such as message queues, a database, and so on. It is important that
you monitor the application user interface response times, service response
times for individual services, and health of dependent components in order to
keep the application performance to the desired service level.
When service performance degrades or the service is temporarily unavailable,
you are often required to have a contingency plan for failover to an alternate
service instance.
We use one of the Trader application services, TraderDBServices, to see how
we can monitor and manage the application server and service using ITCAM for
SOA and ITCAM for Web Resources (or ITCAM for WebSphere) to ensure that
the service remains available. We deploy the same service on two servers. We
will monitor the servers and the response times for the service on the deployed
instances and update the service registry that will be used to query the best
available service at run time.
We use a mediation flow in WebSphere Enterprise Service Bus as a front end to
the deployed services. We will develop the mediation flow using WebSphere
Integration Developer using the TraderDBServices Web Services Description
Language (WSDL). We will also use WebSphere Service Registry and
104
Managing an SOA Environment with Tivoli
Repository to store the service WSDL files for deployed service instances. Each
of the WSDL documents will also contain additional service metadata
(user-defined properties) that will store the status of the server where the service
is deployed and the service quality that is derived from the service response
time. The quality of the service will be used to select the best alternate service
when the primary service fails.
The TraderDBServices are deployed on perth:9082 and khartoum:9082. We will
use the WebSphere Process Server (that includes the WebSphere Enterprise
Service Bus capability) on srv107:9081 as our mediation server where we will
deploy the service mediation message flow.
We use the WebSphere Service Registry and Repository deployed on
laredo:9080 as our service registry. It contains additional service metadata that
will be updated by the monitored situation action from IBM Tivoli Monitoring. The
situations will be defined using the monitored attributes from ITCAM for Web
Resources (or WebSphere) and ITCAM for SOA. We will also introduce a
managed message logger that can be controlled from the operations
environment using Tivoli Enterprise Portal to enable and disable message
logging. The control can also be automated if required. The overview of the
solution is shown in Figure 4-2.
WebSphere Enterprise Service Bus /
WebSphere Process Server
TraderDBServices 1
perth:9082
TraderWebClient
Managed
Logger
Select best
available service
Health Monitoring
using ITCAM
perth:9081
srv107:9081
TraderDBServices 2
khartoum:9082
WebSphere Service
Registry & Repository
laredo:9080
Enable / Disable Logging
from Operations
Update Service Quality
and Server Health
IBM Tivoli
Monitoring
Situation
And
Take Actions
peoria
Figure 4-2 Example of maintaining service continuity using ESB, WSRR, and ITCAM
Chapter 4. Advanced SOA management
105
In the next section, we describe the steps required to implement the service
continuity solution described in the previous section. We describe the steps
required to implement the solution in:
򐂰 “Register TraderDBServices in the registry” on page 106
򐂰 “Developing managed SCA mediation with ITCAM for SOA” on page 110
򐂰 “Deploying the mediation application” on page 126
4.3.1 Register TraderDBServices in the registry
in this section, we describe the steps for loading the TraderDBServices in
WebSphere Service Registry and Repository.
Note: We do not describe the installation of WebSphere Registry and
Repository in this chapter. For installation and basic usage, refer to the
WebSphere Service Registry and Repository Handbook, SG24-7386, at the
following Web site:
http://www.redbooks.ibm.com/abstracts/sg247386.html
After deploying TraderDBServices to WebSphere Application Servers, we load
the WSDL files into WebSphere Service Registry and Repository. The deployed
WSDL files can be obtained from the WebSphere administration console. The
published WSDL for the deployed services will contain the actual service
endpoint address. The steps are:
1. Extract the WSDL file for each of the application servers hosting the Web
Services provider:
a. Go to to WebSphere administration console using the URL:
http://<dmgrhost>:9060/ibm/console
b. Navigate to the Enterprise Application → TradeDBEAR → Publish
WSDL files. See Figure 4-3 on page 107. Right-click and save the.zip file.
c. Open the.zip file to extract the TraderDBServices.wsdl file.
106
Managing an SOA Environment with Tivoli
Figure 4-3 Publishing WSDL from WebSphere
2. WebSphere Service Registry and Repository console in laredo can be
accessed using the URL http://laredo:9080/ServiceRegistry.
3. Navigate to Service Documents → Load Documents. Browse to the
previously extracted WSDL documents and follow the steps to load the
WSDL document into WebSphere Service Registry and Repository.
Figure 4-4 Load WSDL into Service Registry
Chapter 4. Advanced SOA management
107
Note: There are other alternatives for representing the WSDL documents in
WebSphere Service Registry and Repository. The WSDL for
TraderDBServices can be split into port type interface definitions and port
physical binding address files. This approach can reduce part of the
duplication of the WSDL data in WebSphere Service Registry and Repository.
However, today this involves creating the WSDL files manually instead of
using the WSDL files retrieved from the deployed applications in WebSphere
Application Server directly.
4. To verify that all WSDL documents have been loaded in WebSphere Service
Registry and Repository, navigate to Service Documents → WSDL
Documents. Verify that the WSDL documents are shown similar to
Figure 4-5.
Figure 4-5 TraderDBServices WSDL instances
5. We add service metadata (user-defined properties) to the service definitions.
These properties are used for selecting Web Services destinations from the
108
Managing an SOA Environment with Tivoli
mediation. These properties can be updated manually using the console or
programmatically using the WebSphere Service Registry and Repository API.
6. Navigate to Service Metadata → Ports. You will notice that there are several
TraderDBServices entry. The entries represent each of the loaded instances
from the WSDL files. To easily distinguish these instances during our
navigation, we add a description string to indicate the server to which the port
belongs. See Figure 4-6.
Figure 4-6 Add a description to the port to distinguish each instance of the service
7. For each of the ports, click the port instance, then click Custom Properties,
and click New to add properties and value shown in Table 4-1.
Table 4-1 Custom properties
Property name
Initial property value
Valid property values
serviceServerStatus
down
up or down
serviceResponseTime
good
good or bad
8. The resulting custom properties list is shown in Figure 4-7 on page 110.
Chapter 4. Advanced SOA management
109
Figure 4-7 Service metadata: Custom Properties for port instances on srv177
Now, the setup in WebSphere Service Registry and Repository is done. You can
also define the Web Services life cycle as deployed so that the Web Services life
cycle is discovered by the Discovery Library Adapter.
4.3.2 Developing managed SCA mediation with ITCAM for SOA
We turn our effort now to WebSphere Integration Developer. We wanted to create
a mediation module that can be managed using ITCAM for SOA-managed SCA
mediation for TraderDBServices.
First, we have to set up our development environment:
򐂰 The installation of WebSphere Integration Developer is provided in:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp?t
opic=/com.ibm.wbit.help.nav.doc/topics/installmigrate.html
򐂰 We set up ITCAM for SOA-managed SCA mediation tools to WebSphere
Integration Developer. The installation is provided in the KD4/Tools directory
of the ITCAM for SOA tools CD. The instructions are available from:
http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?top
ic=/com.ibm.itcamsoa.doc/kd4nvmst31.htm
110
Managing an SOA Environment with Tivoli
Mediation development uses the following terminology:
Interface
The interface is the mediation flow definition of how an
external client can connect and run the mediation flow.
Reference
The reference is the mediation flow definition for how it
calls Web Services providers.
Import
The Web Services definition is imported into the
mediation module that can be called from the mediation
module; the import connects to the reference of the
mediation flow. The import represents the output of the
mediation module.
Export
The Web Services definition of the mediation flow from
the specified interface can be exported so that a Web
Services client can call. The export represents the input to
the mediation module.
Mediation flow
The logic of the mediation maps the exported call
interface into the reference call to the imported Web
Services.
Wiring
Wiring is the process of defining links between
components of the mediation.
We create a mediation flow for TraderDBServices that can be used to ensure
service availability in an SOA environment:
1. We first create a library project in WebSphere Integration Developer. Create a
new library using the menu File → New → Other and select Library. Call the
library project TraderDBServicesLibrary. The new project is shown in
Figure 4-8.
Figure 4-8 Create TraderDBServicesLibrary project
2. Import TraderDBServices.wsdl into WebSphere Integration Developer.
Right-click Interfaces and select Import. In the ensuing dialog box, select
WSDL/Interfaces. Select TraderDBServices.wsdl, and see Figure 4-9 on
page 112.
Chapter 4. Advanced SOA management
111
Figure 4-9 Import TraderDBServices
3. We create the mediation module that will be used to maintain service
availability by selecting the best available service from two deployed service
locations. This module includes the managed message logger primitive that
can be used to provide on demand message logging from the IT operations
environment:
a. Select File → New → Other and choose Mediation Module. See
Figure 4-10 on page 113.
112
Managing an SOA Environment with Tivoli
Figure 4-10 New mediation module
b. Specify TraderDBServicesAvailabilityMediationApp as the module
name and select the target runtime environment. For our case, we will
deploy on WebSphere Process Server, and, therefore, we select
WebSphere Process Server. As long as the mediation module is limited to
using mediation primitives only and does not use the WebSphere Process
Server-specific elements, it can be deployed on a WebSphere Enterprise
Service Bus as well.
c. Include the library project TraderDBServicesLibrary.
4. Define a mediation flow for TraderDBServicesAvailabilityMediationApp:
a. Right-click the Mediation Logic and select New → Mediation Flow. See
Figure 4-11 on page 114. Call the mediation flow
TraderDBServicesAvailabilityMediationFlow.
Chapter 4. Advanced SOA management
113
Figure 4-11 Create TraderDBServicesAvailabilityMediationFlow
b. Next, double-click Assembly Diagram to open the assembly diagram
editor. It usually opens with a default mediation flow component.
Right-click and delete the mediation component. Click and drag the
TraderDBServicesAvailabilityMediationFlow component that we just
created in the previous step. See Figure 4-12 on page 115.
114
Managing an SOA Environment with Tivoli
Figure 4-12 Add the mediation flow into the assembly editor
5. We need to define the service interface for invoking the mediation flow. This is
the interface that is used by the service consumer:
a. Add an interface using the
icon. Select TraderDBServices for the
interface selection. See Figure 4-13.
Figure 4-13 Add interface
Chapter 4. Advanced SOA management
115
b. We also need to associate an Export with the interface that will define the
service endpoint URL for the TraderDBServices from the mediation server.
From the palette on the left, click the Export icon and drop it into the
assembly editor as shown in Figure 4-14.
c. Rename the default name Export1 to TraderDBServicesMediationExport.
Figure 4-14 Add Export
d. Wire the export to the interface in the mediation flow by dragging the wire
from the export element to the mediation flow component. When
connecting, click OK to the prompt that asks for confirmation to associate
the same interface to the export. See Figure 4-15.
Figure 4-15 Wiring
6. Add the reference and import the Web Services definition to the mediation
flow component. The reference is used to connect the mediation flow to the
service that will be invoked by the mediation flow:
116
Managing an SOA Environment with Tivoli
a. Right-click the mediation component and select Add → Reference. In the
dialog box, select the interface for the reference, which is
TraderDBServices. Also, we need to specify the reference name. Specify
the reference name as TraderDBServicesPartner. See Figure 4-16.
Figure 4-16 Add reference: TraderDBServicesPartner
b. Drop an Import element from the palette and name it
TraderDBServicesImport; see Figure 4-17 on page 118. Wire the import to
the reference, and accept the prompt to associate a matching interface
from the reference to the import.
Chapter 4. Advanced SOA management
117
Figure 4-17 Select Import from the palette
7. We can now generate a skeleton mediation code automatically:
a. Right-click the mediation flow and select Regenerate Implementation as
shown in Figure 4-18. Click OK when prompted. This action regenerates
the mediation flow component implementation with references and the
interface definition from the assembly diagram.
Figure 4-18 Regenerate Implementation
b. You will notice that there is a blue exclamation mark (!) on the
TraderDBServicesImport element, because we have not specified the type
of binding that we want to associate with the import. Right-click and select
Generate Binding → Web Services Binding. From the dialog which
prompts for a service port, select Use an existing Web service port and
browse for the TraderDBServices port as shown in Figure 4-19 on
page 119.
118
Managing an SOA Environment with Tivoli
Figure 4-19 Generate Web service binding for TraderDBServicesImport
c. Repeat the process for the TraderDBServicesMediationExport export
element. Right-click and select Generate Binding → Web Services
Binding. For export, it will prompt for a soap/http or soap/jms binding
choice. Select soap/http as shown in Figure 4-20.
Figure 4-20 Export binding
Chapter 4. Advanced SOA management
119
8. The interface, reference, import, and export definitions have been generated.
Now, double-click the mediation flow component, which will open the
operation connection editor as shown in Figure 4-21. The mediation flow
definition consists of:
Operation connections
The operation connections are the mapping of
operations from the interface to the reference
definitions. The interface operation must be wired
to the reference operation.
Mediation flow
The mediation flow is the mediation logic for each
wired connection where we can define the operation
and components. Note that there are two tabs for the
flow: the request flow and the response flow.
Properties
The property view at the bottom shows detailed
properties for each selected object. This view is
typically used for modifying the property of the
operation component shown in the mediation flow.
Figure 4-21 Mediation Flow Editor with interface, operations, and references
9. For each operation, click the interface and wire it to the
TraderDBServicesPartner as shown in Figure 4-22 on page 121.
120
Managing an SOA Environment with Tivoli
Figure 4-22 Wire each interface operation with the TraderDBServicesPartner
10.We must define the mediation flow for each of the wires in Figure 4-22. We
only illustrate the modification for the buy operation:
a. Click on the wire that connects the buy operation, which will update the
mediation flow editor canvas. The mediation flow editor has a palette of
mediation primitives on the left that can be used to create the mediation
flow. The palette also contains the managed mediation primitives installed
by the ITCAM for SOA tools package. See Figure 4-23.
Figure 4-23 ITCAM for SOA managed mediation primitives
b. We will use two mediation primitives:
•
Managed Message Logger from the ITCAM for SOA tools package
Chapter 4. Advanced SOA management
121
•
Endpoint Lookup to query WebSphere Service Registry and
Repository to obtain a service endpoint based on a set of properties
From the managed mediation primitives palette, select Managed
Message Logger and drop it into the mediation flow editor.
c. Rename the primitive to BuyLogger. Wire the Buy:Input terminal to
BuyLogger.
d. Select Endpoint Lookup primitive and drop it into the mediation flow
editor. Rename the primitive to BuyLookup.
e. Wire the BuyLogger output terminal to the input terminal BuyLookup.
f. BuyLookup has three output terminals. The first terminal is called the
match terminal. Wire this terminal to TraderDBServicesPartner input
terminal. The service request message flows to this terminal if the query to
WebSphere Service Registry and Repository is successful. We will define
the properties to query the service endpoint later in this section.
g. The second terminal is the noMatch terminal. We create a Fail primitive
that raise service fault. The noMatch terminal is wired to the Fail terminal.
h. The mediation flow for buy operation needs to look like Figure 4-24.
Figure 4-24 TraderDBServices buy operation mediation flow
11.The operation primitives properties can be set in the Properties dialog in the
bottom part of the workspace. Right-click the operation primitives and select
Show in Properties:
122
Managing an SOA Environment with Tivoli
– The current detailed properties for BuyLogger are shown in Figure 4-25.
You will notice that this primitive is enabled. You can clear the Enabled
check box to disable the logger function of this primitive.
Figure 4-25 Managed logger properties
– The Endpoint Lookup mediation primitive is part of the WebSphere
Enterprise Service Bus and the WebSphere Process Server run time. This
primitive is used to dynamically query WebSphere Service Registry and
Repository to retrieve one or more endpoints based on a given set of
properties for the service port. We had defined serviceServerStatus and
serviceResponseTime properties for our service, which we will now query:
•
•
The serviceServerStatus is up
The serviceResponseTime is good
The Endpoint Lookup detailed properties are shown in Figure 4-26. Use
the Name of TraderDBServices and the Namespace of
http://services.db2.trader.j2ee.itso.
Figure 4-26 Port Type and Namespace for the service query to WSRR
Click Advanced on the Properties tab to define properties to match the
service quality to the service selection. Use Add to add the property name
and the value that we want to match. See Figure 4-27 on page 124.
Chapter 4. Advanced SOA management
123
Figure 4-27 TraderDBServicesBuyLookup Properties
12.So far we have wired the request flow. We also need to wire back the
response flow. Click on the Response:buy tab beneath the mediation flow
editor to open the response flow. Wire the response as shown in Figure 4-28.
Figure 4-28 Wire buy response flow
13.Repeat the procedure for the remaining operations of TraderDBServices. Be
sure to wire both the request and response flows:
– The getQuote request flow is wired as shown in Figure 4-29 on page 125.
124
Managing an SOA Environment with Tivoli
Figure 4-29 getQuote request flow
– The sell request flow is wired as shown in Figure 4-30.
Figure 4-30 sell request flow
– The getCompanies request flow is wired as shown in Figure 4-31 on
page 126.
Chapter 4. Advanced SOA management
125
Figure 4-31 getCompanies request flow
Ensure that each of the lookup primitives is set to match the Port Type name
of TraderDBServices and the Namespace of
http://services.db2.trader.j2ee.itso. And, the user-defined properties in
the Advanced tab must be set to match the properties serviceServerStatus
with value of up and serviceResponseTime with value of good.
4.3.3 Deploying the mediation application
We have completed the creation of the simple mediation flow application for our
scenario. This mediation application must be exported for deployment to our
application environment:
1. From the WebSphere Integration Developer workbench, select File →
Export. Export the application as Integration Module. The exported module
must be in the form of an Enterprise Archive (EAR) file and specify the target
directory. See Figure 4-32 on page 127.
126
Managing an SOA Environment with Tivoli
Figure 4-32 Export mediation module
2. Before we deploy the mediation module, we need to perform the following
steps to prepare the server to enable ITCAM for SOA runtime mediation
support. With the Process Server stopped, perform the following steps:
a. Go to the ITCAM for SOA directory, such as:
/opt/IBM/ITM/li6243/d4/KD4/bin
b. Enable WebSphere data collector for ITCAM for SOA using the command,
such as:
./KD4configDC.sh -enable -env 1 /opt/IBM/WebSphere/AppServer
c. Configure WebSphere Process Server data collector for ITCAM for SOA:
./KD4configDC.sh -enable -env 9 /opt/IBM/WebSphere/AppServer
Chapter 4. Advanced SOA management
127
d. Enable runtime mediation support:
./KD4configMediationInstall.sh -enable
/opt/IBM/WebSphere/AppServer
e. Start WebSphere Process Server again and you can deploy the runtime
mediation support:
Note: The KD4configMediationDeploy.sh will not run if there is an
active managed mediation on the application server. Therefore, it is
preferable to deploy this runtime mediation support before the
mediation logic. However, in case the managed mediation is already
installed, you can stop the managed mediation application using the
WebSphere administration console before running this command.
./KD4configMediationDeploy.sh -enable
/opt/IBM/WebSphere/AppServer/profiles/ProcSrv01 srv107Node01
server1
3. Access the WebSphere Process Server administration console using the URL
http://srv107.itsc.austin.ibm.com:9060/ibm/console to deploy the
TraderDBServicesAvailabilityMediationApp.ear that we exported in step 1 on
page 126. The process is similar to deploying a standard WebSphere
enterprise application. See Figure 4-33 on page 129. Accept all defaults
during the installation of the mediation application EAR file.
128
Managing an SOA Environment with Tivoli
Figure 4-33 Install TraderDBServicesAvailabilityMediationApp.ear
4. Next, get the service endpoint of the mediation application by inspecting the
published WSDL file. Navigate to Enterprise Application →
TraderDBServicesAvailabiltyMediationApp → Publish WSDL files. See
Figure 4-34 on page 130.
Chapter 4. Advanced SOA management
129
Figure 4-34 Get WSDL to inspect the service endpoint for the mediation application
5. Download the generated zip file and extract the WSDL file. The endpoint
address is listed in the <wsdl:port> section. The definition in our environment
is shown in Figure 4-35.
Figure 4-35 Service endpoint for TraderDBServicesAvailabilityMediationApp
6. Verify the service endpoint of the mediation by accessing the URL from
Figure 4-35 in a Web browser. The resulting page needs to be similar to
Figure 4-36 on page 131.
130
Managing an SOA Environment with Tivoli
Figure 4-36 Verify the service endpoint for TraderDBServicesAvailabilityMediationApp
7. We must now define a default connection to the WebSphere Service Registry
and Repository. From the WebSphere Process Server Administrative console,
navigate to Service Integration → WSRR definition and click New. Define
the registry as shown in Figure 4-37. We called our registry TraderWSRR.
Figure 4-37 WSRR definition
Chapter 4. Advanced SOA management
131
8. After the application is installed, save it to the master configuration. You must
restart the WebSphere Process Server.
4.3.4 Verifying the service invocation with mediation
The previously mentioned endpoint is used by the TraderClientWeb to invoke the
TraderDBServicesAvailabilityMediationApp module, which then routes the
service request to the best available service provider after querying the
WebSphere Service Registry and Repository.
To verify the service flow, we can use the WebSphere Service Registry and
Repository console to manually update the service metadata for the
TraderDBServices deployed on either perth or khartoum to affect its connection.
We can verify this service flow by stopping one of the servers. For example, we
can stop the khartoum server, which means that only service to perth runs a
successful call. We first set the custom property in the WebSphere Services
Registry and Repository:
1. Access WebSphere Service Registry and Repository Web interface using the
URL: http://laredo:9080/ServiceRegistry
2. Navigate to Service Metadata → Ports. Select TraderDBServices for perth
and open the Custom Properties link.
3. In the Custom Properties, update the property values serviceServerStatus to
up and serviceResponseTime to good. See Figure 4-38 on page 133.
132
Managing an SOA Environment with Tivoli
Figure 4-38 Service metadata TraderDBServices port on perth
4. Save the properties.
5. Similarly for TraderDBServices in khartoum, set the property values for
serviceServerStatus to down and serviceResponseTime to bad.
6. Now, invoke the service using the TraderClientWeb. The interface is shown in
Figure 4-39 on page 134.
Chapter 4. Advanced SOA management
133
Figure 4-39 TraderClient Web invokes the TraderDBServicesAvailabilityMediationExport
7. The call is successful, because perth is up. Click GO, and we get the list of
companies.
8. We reversed the custom property values for perth and khartoum and tried
again. The result is shown in Figure 4-40 on page 135. The Web Services
server in khartoum is unavailable.
134
Managing an SOA Environment with Tivoli
Figure 4-40 Failed server call
9. As a test, we set both perth and khartoum to be unavailable from WebSphere
Services Registry and Repository. The test results shows that the Web
Services failure is returned similar to Figure 4-40.
The availability solution so far has demonstrated how easy it is to use a
mediation with a service registry in an SOA environment to achieve service
routing by just flipping the property values associated with a service instance.
In order to make this function really useful, we must be able to update the service
metadata automatically. We define how to update the service metadata
automatically in 4.4, “Service monitoring automation” on page 136. We
demonstrate the use of IBM Tivoli Monitoring solution to automate this task.
Chapter 4. Advanced SOA management
135
4.4 Service monitoring automation
For our scenario, we have two instances of TraderDBServices that we want to
monitor. We also want to update the service metadata based on the current
operational condition of the servers and services.
The monitoring attributes in which we are interested are the status of the server
where the service is deployed and an average service response time metric for
the TraderDBService operations:
򐂰 We use ITCAM for WebSphere or ITCAM for Web Resources to monitor for
the Web Services provider and take an automatic action to update the
associated service metadata property serviceServerStatus with value of up or
down in WebSphere Service Registry and Repository.
򐂰 ITCAM for SOA can be used to monitor the service response time metrics and
take an automatic action to update the associated property
serviceResponseTime as good or bad.
Note: Our scenario uses two simple properties to demonstrate the monitoring
and management capability. This concept can be easily extended to more
sophisticated monitoring and management automation that can include other
critical resources in the environment on which the service or application
depends. For example, a service or dependent application might require
certain performance metrics of the MQ messaging infrastructure or the DB2
database. IBM Tivoli Monitoring and IBM Tivoli Composite Application
Management product families provide hundreds of monitored attributes that
can address virtually any monitoring requirement.
Both of the WebSphere Application Servers where TraderDBServices are
deployed have been configured for monitoring by ITCAM for WebSphere and
ITCAM for SOA. The monitoring data can be seen in Tivoli Enterprise Portal as
shown in Figure 4-41 on page 137.
136
Managing an SOA Environment with Tivoli
Figure 4-41 Tivoli Enterprise Portal navigation tree for khartoum and perth
4.4.1 Automation principles
Automation is automatic monitoring of a situation or predefined problem
condition using monitored resources or attributes. When a certain situation or
problem condition becomes true, a predefined action or command can be
executed.
IBM Tivoli Monitoring also offers a simple to use situation editor and workflow
editor that can be used to create custom situations, correlate multiple situations,
and define a custom command.
IBM Tivoli Monitoring, through Tivoli Enterprise Portal, provides a single view of
the entire IT infrastructure. It offers a rich set of monitored data attributes from
the monitored environments. All ITCAM offerings plug into the ITM infrastructure
and offer hundreds of monitored data attributes, predefined actions, and
predefined situations.
The power to combine and correlate situations and monitored data across
various monitored environments using multiple monitoring products, such as
ITCAM for SOA, ITCAM for Web Resources, ITCAM for WebSphere, ITCAM for
J2EE, OMEGAMON XE for Messaging, and IBM Tivoli OMEGAMON, offers
tremendous benefit to IT operations.
Chapter 4. Advanced SOA management
137
4.4.2 Update service metadata utility
IBM Tivoli monitoring and ITCAM provide the foundation to create situations and
take automatic actions.
The update WebSphere Service Registry and Repository is done using a simple
Web client utility that uses the published WebSphere Service Registry and
Repository Web Services API. The utility takes the object identifier of the desired
WSDL port and the property name and value to update.
We install a new application, UpdateServiceMetadataInWSRRWebClientEAR in
the same server as WebSphere Service Registry and Repository. The utility is
called using a command line URL invoker called cURL.
Note: The cURL is a free software product that is available for Linux and that
can be downloaded from:
http://curl.haxx.se/
You can use alternative command line interfaces or a custom Java Web
Services client application instead of cURL.
cURL enables us to invoke a URL to perform automation. In our environment, all
automation is performed from our IBM Tivoli Monitoring server, peoria. The
automation can be executed either on the same server as IBM Tivoli Monitoring
Server or on the monitored system.
The source code and binary for the WebSphere Service Registry and Repository
update utility is included with this Redpaper. For instructions to download it, go to
Appendix B, “Additional material” on page 197.
The UpdateServiceMetadataInWSRRWebClientEAR contains a servlet that can
be invoked using either the GET or POST method. The servlet is accessible from
the URL path:
http://host:port/UpdateServiceMetadataInWSRRWebClient/UpdateWSRRPropert
ies
This servlet takes the following arguments:
bsrURI
138
This argument is a required argument that identifies the
specific document metadata as the target of the
invocation.
Managing an SOA Environment with Tivoli
endpoint
This argument is an optional argument that specifies the
endpoint URL for the WSRR Web Service. A sample URL
looks like:
http://<wsrrhostname>:<port>/WSRRCoreSDO/services/W
SRRCoreSDOPort
add
This argument specifies a set of name and value pairs for
adding a property with a specified value. This argument
takes the format of:
<name1>=<value1>,<name2>=<value2>, and so on
update
This argument specifies the set of name and value pairs
for updating a property. This argument takes the format
of: <name1>=<value1>,<name2>=<value2>, and so on
If the property to be updated is not present, it will be
added.
remove
This argument specifies the property or properties to be
deleted. This argument takes the format of:
<name1>,<name2>, and so on
If the property to be removed is not available, it is ignored.
A sample cURL invocation is shown in Example 4-1.
Example 4-1 Sample cURL invocation
curl -d \
"bsrURI=d4f935d4-4cbd-4d85.9380.0678680680cb&”\
“update=name1=value1,name2=value2"\
http://laredo:9080/UpdateServiceMetadataInWSRRWebClient/UpdateWSRRPrope
rties
4.4.3 ITCAM for WebSphere and ITCAM for Web Resources
situations
ITCAM for WebSphere (and ITCAM for Web Resources) provide a number of
predefined situations and monitored attributes. To explore predefined situations,
use Tivoli Enterprise Portal and click the Situations icon as shown in
Figure 4-42 on page 140.
Chapter 4. Advanced SOA management
139
Figure 4-42 ITCAM for WebSphere predefined situations
Some of the predefined situations offered by ITCAM for WebSphere are:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
140
WASNotConnected
WASContainerTransactionRollback
WASDBConnectionPoolThreadTimeout
WASError
WASHighCPUPercentUsed
WASHighGCTimePercent
WASOutofHeapSpace
WASServletsJSPsError
WASThreadPoolPercentMaxed
WASWebApplicationError
Managing an SOA Environment with Tivoli
Note: For more information about the situations and other monitored
attributes, refer to the Web site:
http://www-1.ibm.com/support/docview.wss?uid=swg27009086
ITCAM for Web Resources 6.2 adds four new situations to the previous list that
give additional monitoring control of WebSphere Application Server from an
application perspective. They are:
򐂰
򐂰
򐂰
򐂰
WASAppDiscovered
WASAppHealthGood
WasAppHealthFair
WASAppHealthBad
For a non-WebSphere environment, the corresponding names are:
򐂰
򐂰
򐂰
򐂰
J2EEAppDiscovered
J2EEAppHealthGood
J2EEAppHealthFair
J2EEAppHealthBad
For our scenario, we create four new situations that are based on Application
Server Status attributes. We want to monitor the WebSphere Application Server ServerSvc on perth and khartoum where we have deployed the
TraderDBServices.
The situations are listed in Table 4-2 on page 142 with information about the
necessary actions to take.
Chapter 4. Advanced SOA management
141
Table 4-2 Situation lists
Situation name
Monitoring
Action
Perth_ServerSvc_Up
Monitors when WebSphere Server ServerSvc on perth is up
Updates the service metadata
property serviceServerStatus for
WSDL port TraderDBServices
associated with perth with value = up
in WebSphere Service Registry and
Repository
Perth_ServerSvc_Dn
Monitors when WebSphere Server ServerSvc on perth is down
Updates the service metadata
property serviceServerStatus for
WSDL port TraderDBServices
associated with perth with value =
down in WebSphere Service
Registry and Repository
Khartoum_ServerSvc_Up
Monitors when WebSphere Server ServerSvc on khartoum is up
Updates the service metadata
property serviceServerStatus for
WSDL port TraderDBServices
associated with khartoum with value
= up in WebSphere Service Registry
and Repository
Khartoum_ServerSvc_Dn
Monitors when WebSphere Server ServerSvc on khartoum is down
Updates the service metadata
property serviceServerStatus for
WSDL port TraderDBServices
associated with khartoum with value
= down in WebSphere Service
Registry and Repository
Follow these steps to create the situation Perth_ServerSvc_Up; creating other
situations uses similar steps:
1. Using Tivoli Enterprise Portal, navigate to perth.itsc.austin.ibm.com node and
right-click WebSphere Agent - Primary and invoke Situations.
142
Managing an SOA Environment with Tivoli
Figure 4-43 Create a situation for WebSphere Agent
2. In the situation Editor dialog window, select Create New. This option opens a
dialog window. Specify the name of the situation as Perth_ServerSvc_Up.
Provide an optional description and click OK to continue. See Figure 4-44.
Figure 4-44 New Situation: Perth_ServerSvc_Up
3. Select Attribute Comparison for the Condition Type and select Application
Server Status for the Attribute Group. Select Server Name, Status,
Chapter 4. Advanced SOA management
143
WASCellName, and WASNodeName for the Attribute Items to compare and
click OK. See Figure 4-45.
Figure 4-45 Attribute to monitor for Perth_ServerSvc_Up situation
4. The next dialog lets us define the WebSphere application server - ServerSvc
attribute comparison where we will define the Server Name as
AppSrv01$ServerSvc, Status as Connected, CellName as perthCell01, and
Node as perthNode01. Also, update the sampling interval rate to 30 seconds
and the visual state to Informational as shown in Figure 4-46 on page 145.
Click OK.
144
Managing an SOA Environment with Tivoli
Figure 4-46 Perth_ServerSvc_Up attribute comparison
5. Next, click the Action tab to define the command, which will be executed
when this situation becomes true.
6. We will put all our scripts in the /root/automationScripts directory on peoria.
We will also log the output of the scripts in the /root/automationScripts/logs
directory. We will name the scripts to correspond to the situation name. The
output is logged using the situation name and a situation occurrence time
stamp string appended to the log file name. The time stamp parameter can be
substituted by using the Attribute Substitution button and selecting the
Sample Date and Time attribute. The command to execute when this
situation fires is:
/root/automationScripts/Perth_ServerSvc_Up >
/root/automationScripts/logs/Perth_ServerSvc_Up_&{Application_Server
_Status.Sample_Date_and_Time} 2>&1
See Figure 4-47 on page 146.
Chapter 4. Advanced SOA management
145
Figure 4-47 Perth_ServerSvc_Up action command definition
7. Click OK to save.
8. The script Perth_ServerSvc_Up content is shown in Example 4-2.
Example 4-2 Perth_ServerSvc_Up script
#!/bin/ksh
#Take Action script for situation - Perth_ServerSvc_Up
echo Setting serviceServerStatus to up for TraderDBServices WSDL port
in WSRR
/usr/bin/curl -d
"bsrURI=WSRR--7797c588.ec8a0705.304b9735.65a4f365-5dad-4d77.9045.19da30
19455e&update=serviceServerStatus=up"
http://laredo:9080/UpdateServiceMetadataInWSRRWebClient/UpdateWSRRPrope
rties
9. The service metadata update utility uses the bsrURI that is an identifier of the
object that we want to update in WebSphere Service Registry and
Repository. You can retrieve the value of bsrURI for the object in WebSphere
Service Registry and Repository using the service registry console as shown
in Figure 4-48 on page 147.
146
Managing an SOA Environment with Tivoli
Figure 4-48 Retrieving bsrURI for the service metadata object
Follow the steps that we used earlier to create the other situations and the
corresponding action scripts.
4.4.4 ITCAM for SOA situations
In this section, we discuss several of the situations and monitored attributes that
are provided by ITCAM for SOA.
Navigate to the Situation icon on the Tivoli Enterprise Portal menu bar. The
ITCAM for SOA situations are listed under Services Management Agent and
Services Management Agent Environment as shown in Figure 4-49 on
page 148.
Chapter 4. Advanced SOA management
147
Figure 4-49 ITCAM for SOA situations
For our scenario, we create four new situations that are based on the Service
Inventory 610 attributes group. We want to monitor response time metrics for
TraderDBServices deployed on ServerSvc on perth and khartoum. We will define
a criteria to determine when a response time is good or bad. We list the
situations in Table 4-3 on page 149 with the information about which attributes
we are monitoring and what actions we need to take.
148
Managing an SOA Environment with Tivoli
Table 4-3 ITCAM for SOA situations
Situation name
Monitoring
Action
Perth_TrdrDBSvcResponse_Good
Monitors service port
name TraderDBServices
and namespace
http://services.db2.tra
der.j2ee.itso and
average elapsed
round-trip time is less than
5000 milliseconds
Updates the service metadata
property serviceResponseTime
for WSDL port
TraderDBServices associated
with perth.itsc.austin.ibm.com
with value of good in WebSphere
Service Registry and Repository
Perth_TrdrDBSvcResponse_Bad
Monitors service port
name TraderDBServices
and namespace
http://services.db2.tra
der.j2ee.itso and
situation
ResponseTImeCritical_61
0 is true on server
ServerSvc in node
perth.itsc.austin.ibm.com
Updates the service metadata
property serviceResponseTime
for WSDL port
TraderDBServices associated
with perth.itsc.austin.ibm.com
with value of bad in WebSphere
Service Registry and Repository
Khartoum_TrdrDBSvcResponse_Good
Monitors service port
name TraderDBServices
and namespace
http://services.db2.tra
der.j2ee.itso and
average elapsed
round-trip time is less than
5000 milliseconds on
server ServerSvc in node
khartoum.itsc.ausitn.ibm.c
om
Updates the service metadata
property serviceResponseTime
for WSDL port
TraderDBServices associated
with
khartoum.itsc.austin.ibm.com
with value of good in WebSphere
Service Registry and Repository
Khartoum_TrdrDBSvcResponse_Bad
Monitors service port
name TraderDBServices
and namespace
http://services.db2.tra
der.j2ee.itso and
situation
ResponseTImeCritical_61
0 is true on server
ServerSvc in node
khartoum.itsc.austin.ibm.c
om
Updates the service metadata
property serviceResponseTime
for WSDL port
TraderDBServices associated
with
khartoum.itsc.austin.ibm.com
with value of bad in WebSphere
Service Registry and Repository
Chapter 4. Advanced SOA management
149
We used the following steps to create the Perth_TrdrDBSvcResponse_Good
situation:
1. Navigate to the node perth.itsc.austin.ibm.com in Tivoli Enterprise Portal.
Create a new situation. Specify the situation name as
Perth_TrdrDBSvcResponse_Good.
2. Select Services Inventory 610 for the Attribute Group and select the Service
Port Name, Service Port Namespace, Average Elapsed Message Round
Trip Time, and Interval Status attribute items. Click OK. See Figure 4-50.
Figure 4-50 Attribute group and attribute items for Perth_TrdrDBSvcResponse_Good
3. Specify the attribute values as shown in Table 4-4 on page 151.
150
Managing an SOA Environment with Tivoli
Table 4-4 Attribute selection
Attribute name
Attribute value
Service Port Name
TraderDBServices
Service Port Namespace
http://services.db2.trader.j2ee.itso
Average Elapsed Message Round Trip
Time
5000 milliseconds
Interval Status
Complete
Figure 4-51 Situation Perth_TrdrDBSvcResponse_Good attribute comparison
4. Next, click the Action tab. Select Execute the Action at the Managing
System (TEMS). We use the same action scheme as the ITCAM for
WebSphere situation in 4.4.3, “ITCAM for WebSphere and ITCAM for Web
Resources situations” on page 139.
Chapter 4. Advanced SOA management
151
The action command that we use is:
/root/automationScripts/Perth_TrdrDBSvcResponse_Good >
/root/automationScripts/logs/Perth_TrdrDBSvcResponse_Good_&{Services
_Inventory_610.Interval_End_Time} 2>&1
The situation action dialog is shown in Figure 4-52.
Figure 4-52 Command for situation Perth_TrdrDBSvcResponse_Good
And the Perth_TrdrDBSvcResponse_Good script is shown in Example 4-3.
Example 4-3 Perth_TrdrDBSvcResponse_Good
#!/bin/ksh
# Take Action for situation - Perth_TrdrDBSvcResponse_Good
echo Setting serviceResponseTime to good for TraderDBServices WSDL port
in WSRR
/usr/bin/curl -d
"bsrURI=WSRR--7797c588.ec8a0705.304b9735.65a4f365-5dad-4d77.9045.19da30
19455e&update=serviceResponseTime=good"
http://laredo:9080/UpdateServiceMetadataInWSRRWebClient/UpdateWSRRPrope
rties
5. The situation Perth_TrdrDBSvcResponse_Bad uses the predefined situation
called ResponseTimeCritical_610. This situation monitors for a bad service
response time. Use the situation editor to create the situation, and for this
152
Managing an SOA Environment with Tivoli
situation, select Condition Type as Situation Comparison and select
ResponseTimeCritical_610 as the situation to compare. See Figure 4-53.
Figure 4-53 Select Situation Comparison ResponseTimeCritical_610 for Condition Type
6. Add an additional condition to match Service Port Name and Service Port
Namespace. Set the values for these as you did in the previous situation. Set
the ResponseTimeCritical_610 to true. See Figure 4-54 on page 154.
Chapter 4. Advanced SOA management
153
Figure 4-54 Perth_TrdrDBSvcResponse_Bad situation attribute comparison
7. Use the same method for specifying the action and the script.
8. Define the similar situations for the khartoum server.
4.4.5 Verifying situation automation
To verify that the situation works, we check the custom properties in WebSphere
Service Registry and Repository for perth. The status is up. Then, we bring down
the WebSphere Application Server ServerSvc in perth using the command:
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/stopServer.sh
ServerSvc
The automation occurs as the situation fires in IBM Tivoli Monitoring as indicated
in the Tivoli Enterprise Portal. Now, checking at the WebSphere Service Registry
154
Managing an SOA Environment with Tivoli
and Repository, we see that in Figure 4-55, the serviceServerStatus is filled with
the value down.
Figure 4-55 The serviceServerStatus in WSRR shows as down for perth
We can ensure that access from the TraderClientWeb is not affected at all,
because all requests are being routed to khartoum.
We bring ServerSvc in perth back up. This triggers the Perth_ServerSvc_Up
situation. This can be verified in the situation console. This situation will also
update the serviceServerStatus property to up for the TraderDBServices WSDL
port service metadata.
You can also simulate a long or high response time by modifying the threshold of
the situation and testing the automation.
4.5 Using managed message logger
The managed message logger primitives that we use in the message flows are
discovered by ITCAM for SOA and displayed in Tivoli Enterprise Portal. In our
environment, they can be accessed by navigating to Enterprise → Linux
Chapter 4. Advanced SOA management
155
Systems → srv107.itsc.austin.ibm.com → Service Management Agent →
Mediation Configuration.
From the displayed list, select one of the loggers, such as BuyLogger,
right-click, and select Take Action → ConfigureMediation_601. You will notice
the property Enabled, which can checked or not. Click OK to save. This will
configure the mediation at run time.
4.5.1 Viewing the message data
The WebSphere Process Server by default is set up to use Cloudscape®
database. The database for message logger is automatically created by
WebSphere Process Server. You can use the CView utility to view the logged
message data. In order to access the cloudscape message log database file, we
must stop the mediation server that also is currently using this file:
1. Stop the mediation server (WebSphere Process Server).
2. Start a terminal window.
3. On srv107, change the directory to:
/opt/IBM/WebSphere/AppServer/cloudscape/bin/embedded
4. Run ./cview.sh to start the cloudscape database viewing utility, as shown in
Figure 4-56 on page 157.
156
Managing an SOA Environment with Tivoli
Figure 4-56 CView utility to view cloudspace data
5. Use the menu File → Open and then Browse for the directory:
/opt/ibm/WebSphere/AppServer/profiles/ProcSrv01/databases/EsbLogMedD
B
6. Navigate to Tables → MSGLOG. Click the Data tab. You will see the service
message data. See Figure 4-57 on page 158.
Chapter 4. Advanced SOA management
157
Figure 4-57 Message log table
Important: In a production environment, you must use DB2 or an enterprise
strength database in order to use the database utilities. Using DB2 allows
multiple accesses to the log tables without needing to stop the process server.
4.6 Summary
In this chapter, we demonstrated the capabilities of IBM Tivoli Monitoring and the
ITCAM suite of products to monitor and manage the application server and
services to maintain service availability in an SOA environment.
Integration with WebSphere Enterprise Service Bus and WebSphere Service
Registry and Repository was shown along with the ease of adding a
management layer in the WebSphere Enterprise Service Bus without actually
changing the service provider and the service consumer. We explored the
automation capabilities of IBM Tivoli Monitoring along with predefined and
custom situation and monitored attributes that you can easily combine to create
automation for an SOA-based application and services.
158
Managing an SOA Environment with Tivoli
5
Chapter 5.
Managing an SOA
application in a business
context
In this chapter, we discuss the implication of managing an SOA-based
environment in a business context. We discuss:
򐂰 “Solution overview” on page 160
򐂰 “Tivoli EIF probe” on page 161
򐂰 “Defining situations” on page 162
򐂰 “Designing business services” on page 164
򐂰 “Defining service level” on page 174
򐂰 “Getting the business status” on page 175
© Copyright IBM Corp. 2008. All rights reserved.
159
5.1 Solution overview
The business management solution involves implementing Tivoli Business
Service Manager V4.0 to manage an SOA-based application. Tivoli Business
Service Manager allows the status of an IT resource to affect an abstract entity
based on an impending problem and also provides a representation of service
level attainment.
Figure 5-1 sows the Tivoli Business Service Manager solution.
Tivoli Enterprise
Console
CCMDB
Relational
databases
Data fetcher
ESDA
C
Discovery Library
Books
NetView
xml files
Optional
components
XML Toolkit
Tivoli Service
Level Advisor
IBM Tivoli
Monitoring
OMEGAMON
ITCAM
Tivoli EIF probe
JDBC
TBSM processes
SLA events
TBSM
postgreSQL
Netcool GUI Foundation
Netcool OMNIbus
TBSM ObjectServer
TBSM Console
TBSM Server
events
Netcool Webtop
launch
user data
Tivoli Enterprise
Portal
Netcool Security Manager
user data
license
Netcool License Server
Figure 5-1 Tivoli Business Service Manager solution
The Tivoli Business Service Manager solution that is shown in Figure 5-1
processes events from an Netcool/Omnibus object server. For our purposes in
managing an SOA-based application, these events are generated by IBM Tivoli
Composite Application Management products that are sent through IBM Tivoli
Monitoring.
160
Managing an SOA Environment with Tivoli
IBM Tivoli Monitoring events are received by Netcool/Omnibus through the
TEC/EIF probe component. The TEC/EIF probe component is a Java-based
process that receives TEC events and inserts these events into Omnibus.
For more information about Tivoli Business Service Manager processing, refer to
IBM Tivoli Business Service Manager V4.1, REDP-4288.
5.2 Tivoli EIF probe
The Tivoli EIF probe provides a mechanism to transfer events from IBM Tivoli
Monitoring (ITM) to Tivoli Business Service Manager. Events are mapped as
shown in Table 5-1.
Table 5-1 Field mapping for ITM situation
Field
Content
Ack
No
Agent
ITM_Services_Inventory_610: attribute group of the situation
Alert Group
ITM_Services_Inventory_610: attribute group of the situation
Alert Key
ResponseTimeCritical_610: situation name
Class
TME10tecad
Identifier
ResponseTimeCritical_610:D4:b7a17fb3:srv107-server1:270d6997d0bd943395
ee8fb09d5bd5d1:ITM_Services_Inventory_610
Multiple identifier, including situation name, agent name, situation event id, and
attribute group
Manager
tme10tecad probe on srv179.itsc.austin.ibm.com
Node
D4:b7a17fb3:srv107-server1: agent id
NodeAlias
D4:b7a17fb3:srv107-server1: agent id
Owner
nobody
Severity
Critical
Summary
ResponseTimeCritical_610[(Avg_Elapsed_Time>10000 AND
Interval_status=Complete) ON 270d6997d0bd943395ee8fb09d5bd5d1 ON
(Avg_Elapsed_Time = <value>)
Suppr_Escl
Normal
Type
ITM Problem
Chapter 5. Managing an SOA application in a business context
161
Field
Content
BSM_ClassName
N/A
BSM_Identity
D4:b7a17fb3:srv107-server1
ITMDisplayItem
270d6997d0bd943395ee8fb09d5bd5d1
ITMEventData
~
ITMHostname
peoria.itsc.austin.ibm.com
ITMIntType
U
ITMResetFlag
N/A
ITMStatus
Y
ITMTime
<ts>
TECDate
<date>
TECDateReception
N/A
TECEventHandle
N/A
TECFQHostname
srv107.itsc.austin.ibm.com
TECHostname
srv107.itsc.austin.ibm.com
TECRepeatCount
0
TECServerHandle
N/A
TECStatus
N/A
The mapping of situation-based event information into Omnibus events shown in
Table 5-1 on page 161 is important for defining rules in Tivoli Business Service
Manager. The rules govern how objects are displayed in Tivoli Business Service
Manager and how status affects the business in Tivoli Business Service
Manager.
5.3 Defining situations
We start by defining situations that generate events. The situations definition
must adhere to these guidelines:
򐂰 Situations that affect resource status, that is, situations that generate alerts
for the incoming status rules, must have a reset pair to clear or close the
situation alert condition.
162
Managing an SOA Environment with Tivoli
򐂰 You can define additional situations to generate harmless events that can be
triggered for creating service instance objects. You can run these harmless
events as frequently as daily to ensure that you create all discovered
resource as needed.
Note: Tivoli Business Service Manager does not have a mechanism for an
event-based service instance object to be removed when the actual
resource object no longer exists.
򐂰 Situation forwarding to Tivoli Enterprise Console must be active and working.
Based on these premises, we define situations as listed in Table 5-2.
Table 5-2 Situation definitions
Situation name
Agent
Subscriber
Condition
BSM_WAS_Down
WebSphere agent
*WAS
WebSphereApplication
Server/Status =
Disconnected
BSM_WAS_Up
WebSphere agent
*WAS
WebSphereApplication
Server/Status =
Connected
BSM_SOA_MsgRate_Bad
SOA agent
*KD4
N/A
BSM_SOA_MsgRate_OK
SOA agent
*KD4
N/A
BSM_SOA_Resp_Bad
SOA agent
*KD4
N/A
BSM_SOA_Resp_OK
SOA agent
*KD4
N/A
Figure 5-2 on page 164 shows an example of an ITCAM for SOA event.
Chapter 5. Managing an SOA application in a business context
163
Figure 5-2 Sample event in Omnibus
5.4 Designing business services
We wanted to illustrate the Trader application in a meaningful business context.
We depict this representation of the application in Figure 5-3 on page 165.
164
Managing an SOA Environment with Tivoli
Application
Application_Component
Application_Server
Web_Services_Operation
Figure 5-3 Business service structure
To achieve this structure, we define the following service templates:
򐂰 Application
This template represents an application aggregate. This object always must
have an autodiscovery of Trader in our environment:
– Incoming status rule: None
– Auto population rule: Always create an instance called Trader
– Child aggregation rules: Any child of type Application_Component
򐂰 Application_Component
This template represents a component within an application. For an
SOA-based application, we define a specific Services Provider, Service
Consumer, and Service Bus:
– Incoming status rule: None
– Auto population rule: Create an instance depending on the child type
– Child aggregation rules:
•
Bad when any Application_Server status went bad
•
Bad when 50% of the Web_Services_Operation objects went bad
򐂰 Application_Server
This template represents the application server resources that are being used
by the application. It can be a WebSphere Application Server or WebSphere
Message Broker:
– Incoming status rule: Provided by ITCAM for WebSphere
Chapter 5. Managing an SOA application in a business context
165
– Auto population rule: Collect from event hostname - profile - server
– Child aggregation rule: Bad when more than 33% of the
Web_Services_Operation objects went bad
򐂰 Web_Services_Operation
This template represents the Web Services operations as dictated by ITCAM
for SOA monitoring function. The monitoring provides statistics related to
Web Services on a specific application server.
– Incoming status rule: Provided by ITCAM for SOA
– Auto population rule: Collect from event hostname - profile - server - WS operation
– Child aggregation rules: None
The following procedure defines the templates:
1. Log on to the Tivoli Business Service Manager console at
http://<tbsm>:8080. We use a default Tivoli Business Service Manager
installation with the user ID of admin, and the password is netcool. See
Figure 5-4 on page 167.
166
Managing an SOA Environment with Tivoli
Figure 5-4 Initial Tivoli Business Service Manager window
2. Change to the Service Administration view and click Go.
3. Creating the Application template:
a. In the left navigation tree, select the Templates tab. Click the
icon to
create a new service template. The new template dialog is shown in
Figure 5-5 on page 168.
Chapter 5. Managing an SOA application in a business context
167
Figure 5-5 New template for an application
b. We decide that the Application template will have only a single instance,
which is called Trader. We do not create any incoming status rule.
c. Save the Application template by clicking the disk (
)icon
4. Now, we create the Application_Component, Application_Server, and
Web_Services_Operation templates similarly to the Application template.
You have to select the new template icon every time.
5. Set the dependency of the templates:
a. Select the Application_Component template and click the Children rule
icon
.
b. Define the child by selecting the Any child rule for
Web_Services_Operation. See Figure 5-6 on page 169.
168
Managing an SOA Environment with Tivoli
Figure 5-6 Adding any child rule
c. Click OK and add another rule for Application_Server.
d. Click the
icon to save the template changes.
e. Perform the same action for Application templates to create the hierarchy
that is shown in Figure 5-7 on page 170.
Chapter 5. Managing an SOA application in a business context
169
Figure 5-7 Template hierarchy
6. Define the incoming status rule for collecting information from IBM Tivoli
Monitoring situations:
– For the Web_Services_Operation level, define an incoming status rule
from the icon
. The incoming status rule has the following definitions:
•
•
•
Discriminator of Default Class(0)
Instance name fields of Node and AlertKey
Selected filter fields of AlertGroup and Severity
See the definition in Figure 5-8 on page 171.
170
Managing an SOA Environment with Tivoli
Figure 5-8 Incoming status rule
Chapter 5. Managing an SOA application in a business context
171
– For the Application_Server level, the incoming status rule is defined with:
•
•
•
Discriminator of Class(0)
Instance name fields of Node and AlertKey
Selected filter fields of AlertGroup and Severity
7. Defining auto population rules. The auto population rule for
Web_Services_Operation template is created by:
a. Clicking on the new auto population icon
b. Defining the auto population rule for Web_Services_Operation; see
Figure 5-9.
Figure 5-9 Auto population rule
c. Then, moving up the hierarchy, define the Application_Server,
Application_Component, and Application objects as shown in Figure 5-10
on page 173.
172
Managing an SOA Environment with Tivoli
Figure 5-10 Auto population rule
d. Also, create a new auto population rule for the Application_Server
template as shown in Figure 5-11 on page 174.
Chapter 5. Managing an SOA application in a business context
173
Figure 5-11 Defining an auto population rule for the Application_Server template
5.5 Defining service level
We can now define service level monitoring with Tivoli Business Service
Manager.
174
Managing an SOA Environment with Tivoli
There are three types of service level definitions, which are:
򐂰 Duration-based: This type defines how long the resource is unavailable. The
service level breach is based on the length of single unavailability.
򐂰 Cumulative duration-based: This type defines the overall unavailable time
within a time span, for example, the service level is defined from the total
unavailability over a month.
򐂰 Incident-based: This type is defined as the total number of unavailability
incidents over a time span.
You can define either one or all of these service level definition types for the
Service Template. We choose to implement the service level based on Table 5-3.
Table 5-3 Service level definitions
Object
Duration
Cumulative
Incident
Warning
Violation
Warning
Violation
Warning
Violation
Application
1 minute
5 minutes
5 minutes
10
minutes
10
15
Application_Component
1 minute
5 minutes
5 minutes
10
minutes
5
10
Application_Server
5 minutes
10
minutes
15
minutes
30
minutes
3
5
Web_Services_Operation
5 minutes
10
minutes
15
minutes
30
minutes
3
5
5.6 Getting the business status
The observed result of Tivoli Business Service Manager definitions is in the
terms of service instance objects and its reports. When you are logged in to Tivoli
Business Service Manager Web console as a user, you are presented with a
desktop interface. This interface allows you to see and manage business service
status.
From the initial login for our Trader application, you see the view that is shown in
Figure 5-12 on page 176. This view represents the Trader application and its
components.
Chapter 5. Managing an SOA application in a business context
175
Figure 5-12 Trader application
In Figure 5-12, all of the states are good (green). When an operation is
degraded, such as the response time of the buy operation in perth slows down,
the buy object will become red. The outage is eventually affecting the duration
service level as shown in Figure 5-13 on page 177 (shown in yellow). This
outage, however, has not affected the Trader application itself, because an
alternative option for using the khartoum server is still available.
176
Managing an SOA Environment with Tivoli
Figure 5-13 Service level impacted for buy in perth
In the event that the SCA mediation in srv107 is down, this triggers a major
outage on the Application_Server object and generates an outage call (red) all
the way up to the Trader application. See Figure 5-14 on page 178.
Chapter 5. Managing an SOA application in a business context
177
Figure 5-14 Outage of the mediation server
178
Managing an SOA Environment with Tivoli
A
Appendix A.
The Trader application
In this chapter, we explain the Trader application. We divide the discussion into:
򐂰 “Application components” on page 180
򐂰 “Software requirements” on page 193
© Copyright IBM Corp. 2008. All rights reserved.
179
Application components
The Trader application is a multi-component composite application that runs on
heterogeneous platforms and execution environments. It is a simple stock
trading application that allows the user to list the companies, get a quote, and
trade stocks of the listed companies. Figure A-1 shows the Trader application
conceptual interfaces.
IMS
CICS
Trader
IMS
Trader
CICS
DB2
Trader
DB2
Trader
Tomcat
Trader Server applications
Trader Java client
Trader Web Client
Trader Portal Client
Figure A-1 The Trader application
You can view the Trader application as a three layer or three tier structure:
򐂰 The Trader application has three types of front-end interfaces: a native Java
client, a Web interface, and a portal-based interface. Each interface has the
ability to connect to the server application that provides the business logic.
The connection to the server applications is based on Web Services calls.
򐂰 The server applications are differentiated based on their various access
methods to the underlying data or the platform on which it resides. These are
Java 2 Platform, Enterprise Edition (J2EE)-based applications that serve as
Web Services providers.
180
Managing an SOA Environment with Tivoli
򐂰 The back-end data storage can be IMS, CICS on z/OS, or a DB2 database.
The DB2 database can reside on z/OS or a distributed server. In our
environment, we deploy the DB2 database in a distributed environment.
We discuss the components in the following sections:
򐂰 “Portal interface” on page 181
򐂰 “Front-end J2EE Web application” on page 183
򐂰 “Java desktop application” on page 186
Portal interface
The Trader portal interface consists of three portlets that communicate with each
other. Figure A-2 shows the portal client.
Figure A-2 The Trader portal client
Appendix A. The Trader application
181
The Trader client portlet is the main portlet that lets you query the available
companies. If you request a quote for the company, the quote information is
shown in the Trader quote portlet. The Trader quote portlet allows you to buy or
sell stocks of the currently displayed company. The Trader message portlet just
collects and displays the messages from the application.
The Trader client portlet requires you to specify the host and port of the back-end
server to which you are connected. This requirement means that you are only
allowed to connect to the servers that reside on the same J2EE servers. This
requirement introduces the need to have a Web Services mediation to pool all
the connections, and then the mediation can connect to the appropriate Web
Services provider.
The connections in the Service Component Architecture (SCA) column are used
to connect to a WebSphere Enterprise Service Bus mediation, and the
connections in the MQ column are used to connect to a WebSphere Message
Broker mediation.
The portal application is distributed as a single Web archive file, which is called
TraderPortletClient1.war.
182
Managing an SOA Environment with Tivoli
Front-end J2EE Web application
We developed the front-end Web application using the Web Services client
wizard, the Trader*Services projects. The application consists of:
򐂰 Initial login page in login.html (Figure A-3)
Figure A-3 Login page
Note: The DB2, IMS, and CICS radio buttons that are shown in Figure A-3 are
not normally available to a user. We include them in our sample application
purely to highlight the possible back-end systems. Similarly, a typical
application does not select a target host, but we show selecting a host here as
part of our lab environment.
򐂰 ListCompanyServlet (Figure A-4 on page 184): Invokes the back-end
ListCompany Web Services
Appendix A. The Trader application
183
Figure A-4 List Company page
򐂰 GetQuotesServlet (Figure A-5 on page 185): Invokes the back-end GetQuote
Web Services
184
Managing an SOA Environment with Tivoli
Figure A-5 Quotes window
򐂰 BuySellServlet: Invokes either the Buy or Sell Web Services
򐂰 LogoutServlet: Clears up the session bean
We provides three type of enterprise application archive (ear) files for the client
interface:
򐂰 TraderClientEAR: This ear file runs the TraderClientWeb application that
provides the basic Trader application functionality.
򐂰 TraderClientMemEAR: This ear file runs the TraderClientMem application
that has a memory leak in the logic for testing a memory leak situation.
򐂰 TraderClientLckEAR: This ear file runs the TraderClientLck application that
has a lock problem injected for testing a deadlock situation.
Appendix A. The Trader application
185
Java desktop application
We also developed the desktop application from the Web Services client wizard
from WebSphere Studio Application Development. It consists of the following
Java classes:
򐂰 TraderClientLogin.java: JDialog extension that provides the initial parameter
(Figure A-6)
Figure A-6 Login dialog
򐂰 TraderClientMain.java: Main JApplet that provides the list of companies
(Figure A-7)
Figure A-7 Company listing
186
Managing an SOA Environment with Tivoli
򐂰 TraderClientQuote.java: Company quote window that allows the invocation of
buying or selling stock (Figure A-8)
Figure A-8 Quote window
Back-end implementation
The back-end systems consists of two entities: the company and the customer.
The company has the quotes definitions, and the customer database has the
customer’s name and the customer’s stock ownership. Figure A-9 on page 188
shows the conceptual data structure.
Appendix A. The Trader application
187
COMPANY
CUSTOMER
Company Name
Stock price
Price history 7 days
Commission
List company
Customer Name
Company name
Stock owned
GetQuote
Buy/Sell Stock
Figure A-9 Entity diagram
The back-end system is implemented in the following platforms:
򐂰 IMS: Implemented in a single IMS transaction called TRADERBL
򐂰 CICS: Implemented in a single CICS transaction called TRADERBL
򐂰 DB2: Implemented as two tables: the customer table and the company table
IMS implementation
A single transaction called TRADERBL represents the IMS implementation. This
transaction, which is written in COBOL, reads the message that contains the
appropriate command and arguments. The TRADERBL transaction accesses
two databases: company and customer.
CICS implementation
The CICS implementation consists of two programs:
򐂰 TRADERPL: The presentation logic for a 3270 interface that can be invoked
using the TRAD transaction
򐂰 TRADERBL: The business logic for the Trader application that will be invoked
from either the TRAD transaction or from a distributed CSMI transaction.
Uses two databases: CUSTFILE and COMPFILE
DB2 implementation
The DB2 implementation is represented in two tables: the CUSTOMER table and
the COMPANY table.
188
Managing an SOA Environment with Tivoli
Back-end J2EE servers
The back-end J2EE servers run on a WebSphere server for IMS, DB2, and CICS
access and on an Apache Tomcat server for DB2 access.
WebSphere-based Web Services
The following modules are deployed into the WebSphere-based Web Services
server:
򐂰 TraderDBServices.ear: This program accesses DB2 data. It consists of the
following modules:
– TraderDBWeb: Direct front end for the Trader DB, which is useful for
validating that the Trader DB application is running
– TraderDBServices: Web module that provides Web Services provider
implementation
– Trader_DB: Contains the database access module
򐂰 TraderIMSServices.ear: This program accesses the IMS server using the IMS
Connect for Java J2EE Connector architecture (J2C) connection. It consists
of the following modules:
– TraderIMSWeb: Direct front end for the Trader IMS, which is useful for
validating that the Trader IMS application is running
– TraderIMSServices: Web module that provides Web Services provider
implementation
– TraderIMSEJB and TraderIMSEJB2: EJB implementations for accessing
the J2C interface
򐂰 TraderCICSServices.ear: This program accesses the CICS server using the
CICS Transaction Gateway J2C connection. It consists of the following
modules:
– TraderCICSWeb: Direct front end for the Trader CICS, which is useful for
validating that the Trader CICS application is running
– TraderCICSServices: Web module that provides Web Services provider
implementation
– TraderCICSEJB and TraderCICSEJB2: EJB implementations for
accessing the J2C interface
Apache Tomcat server
The Tomcat server runs the TraderTomcat Web application that acts as the Web
Services provider. The Web Services are implemented as JDBC calls to a DB2
database. We used a different DB2 database from the TraderDB application to
show a different set of companies.
Appendix A. The Trader application
189
WebSphere Enterprise Service Bus mediation
The WebSphere Enterprise Service Bus mediation that we use is simple
mediation logic that queries the WebSphere Services Registry and Repository
(WSRR) server for the location of the service and invokes them. This mediation
allows the injection of logic to identify which Web Services servers are available
and to redirect the call if necessary.
The mediation is deployed in four modules:
򐂰
򐂰
򐂰
򐂰
TraderDBMediation
TraderCICSMediation
TraderIMSMediation
TraderTomcatMediation
The WebSphere Enterprise Service Bus mediation implementation for the Trader
application is shown in Figure A-10.
WebSphere ESB
TraderTomcatMediationWeb/
sca/TraderTomcatServices
TraderIMSMediationWeb/sca/
TraderIMSServices
TraderDBMediationWeb/sca/
TraderDBServices
TraderTomcatServices/
services/TraderTomcatServices
Check
endpoint
TraderCICSMediationWeb/sca/
TraderCICSServices
TraderIMSServices/services/
TraderIMSServices
TraderDBServices/services/
TraderDBServices
TraderCICSServices/services/
TraderCICSServices
WebSphere Service
Registry &
Repository
Figure A-10 Trader mediation with WebSphere ESB
All of those mediations have similar logic as shown in Figure A-11 on page 191.
190
Managing an SOA Environment with Tivoli
Figure A-11 Mediation logic
Figure A-11 only shows the request logic. It uses the Endpoint lookup mediation
to query based on the port, namespace, and version. We add another field,
which is called active, that we can turn on or off based on which Web Services
provider we want to activate.
WebSphere Message Broker mediation
The message broker implementation currently uses a hard-coded target. Further
enhancement is possible to connect WebSphere Message Broker to WebSphere
Services Registry and Repository in order to query for the Web Services
endpoint. We did not do this in this project.
The broker logic uses four message flow definitions that are stored in a Broker
archive (bar) file. The bar file is then deployed to the Message Broker execution
Appendix A. The Trader application
191
group for processing the Web Services calls. Figure A-12 shows the conceptual
structure of the broker.
WebSphere Message Broker
traderBroker
Execution Group
TraderEGrp
SIBDB
TraderMQ.bar
TraderTomcatServices/
services/TraderTomcatServices
TraderIMSServices/services/
TraderIMSServices
TraderDBServices/services/
TraderDBServices
TraderCICSServices/services/
TraderCICSServices
MQ
WebSphere Message Broker
configMgr
Figure A-12 Broker structure
The message flow logic uses:
򐂰 An HTTP input node gets the Web Services requests.
򐂰 The input node forwards the request to the HTTP request node that actually
performs the Web Services call. The endpoint address is hardcoded here.
򐂰 The HTTP reply node sends the result back to the requester.
Figure A-13 on page 193 shows the message flow implementation.
192
Managing an SOA Environment with Tivoli
Figure A-13 Message flow implementation
Software requirements
We discuss the software that is required to run the Trader application here. We
divide the discussion into:
򐂰 “Runtime environment” on page 193
򐂰 “Development environment” on page 195
Runtime environment
We use the following software for running the Trader components. Other versions
of the software products that we use might be acceptable.
Figure A-14 on page 194 shows the detailed configuration of our Trader
application.
Appendix A. The Trader application
193
CICS TS 3.1
CICS Transaction
Gateway V6
IMS V9
IMS Connect for Java V9
TRADERBL
TRADERPL
TRADERBL
DB2 UDB V8.2 FP15
TRADER
TRADTOMC
WebSphere Application
Server ND V6.1
Apache Tomcat V5.5.20
TraderTomcatWeb.ear
TraderCICSSvc.ear
TraderDBSvc.ear
TraderIMSSvc.ear
WebSphere Message
Broker V6.0.0.2
WebSphere MQ V6
TraderMQ.bar
WebSphere Process
Server V6.0.2
WebSphere Application
Server ND V6.0.2.17
Trader*Mediation.ear
WebSphere Application
Server ND V6.1
TraderClient.ear
TraderClientMem.ear
TraderClientLck.ear
Java client
TraderClient.jar
WebSphere Services
Registry Repository
V6.0.2
WebSphere Application
Server ND V6.0.2.17
*.wsdl
WebSphere Portal Server
V6.0
WebSphere Application
Server ND V6.0.2.17
TraderPortletClient1
Figure A-14 Trader application detail
The detailed components are:
򐂰 Trader Java client (TraderClient.jar)
򐂰 TraderPortletClient1.war
򐂰 TraderClient.ear, TraderClientMem.ear, and TraderClientLck.ear
194
Managing an SOA Environment with Tivoli
򐂰 TraderCICSMediation.ear, TraderIMSMediation.ear, TraderDBMediation.ear,
and TraderTomcatMediation.ear
򐂰 TraderMQ.bar
򐂰 TraderDBSvc.ear, TraderCICSSvc.ear, and TraderIMSSvc.ear
򐂰 TraderTomcatServices.war
򐂰 DB2 databases
򐂰 Trader IMS
򐂰 Trader CICS
Development environment
We use various development tools for developing the Trader application. You
might need to use these tools to customize or change the Trader information to
suit your needs. The development software products that we use are:
򐂰 Rational Application Development V7: This product is a general purpose
programming environment that is based on Eclipse. We use this tool for
developing the J2EE applications, the portal application, and the Java client.
򐂰 WebSphere Integration Developer V6.0.2: This product is the tool for defining
mediation and process modelling for WebSphere Enterprise Service Bus and
WebSphere Process Server. This product is based on Eclipse too. We use
WebSphere Integration Developer for developing the Mediation modules to
deploy to WebSphere Enterprise Service Bus.
򐂰 WebSphere Message Broker Toolkit V6.0.2: This product contains the tools
for administering and developing applications for WebSphere Message
Broker. This tool is based on Eclipse too. If you install this product on the
same machine as WebSphere Integration Developer, it will use the same
Eclipse environment. We specifically use different workspace directories for
WebSphere Integration Developer and WebSphere Message Broker Toolkit
to prevent any conflicts that the products might cause.
򐂰 COBOL compiler for IMS and CICS programs in z/OS. Also, we use various
IMS and CICS compilers to translate the necessary definitions in IMS and
CICS.
Appendix A. The Trader application
195
196
Managing an SOA Environment with Tivoli
B
Appendix B.
Additional material
This paper refers to additional material that you can download from the Internet
as described next.
Locating the Web material
The Web material associated with this paper is available in softcopy on the
Internet from the IBM Redbooks Web server. Point your Web browser at:
ftp://www.redbooks.ibm.com/redbooks/REDP4318
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 IBM Redpaper form number, REDP4318.
© Copyright IBM Corp. 2008. All rights reserved.
197
Using the Web material
The additional Web material that accompanies this paper includes the following
files:
File name
REDP4318.zip
Description
Zipped samples
The file consists of the following files:
TraderClient.ear
Client Web application
TraderDBSvc.ear
Server Web application
trader.tar.gz
Tar gzip file of DB2 tables for db2move command
TraderDBServicesAvailabilityMediationApp.ear
Mediation module
UpdateServicesMetadataInWSRRWebClientEAR_60.ear
Sample WSRR access Web application
System requirements for downloading the Web material
The Web material can be used for any system that is supported to run
WebSphere Enterprise Service Bus application with WebSphere Services
Registry and Repository. The temporary space for the zip file and its content is
10 MB.
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.
198
Managing an SOA Environment with Tivoli
Abbreviations and acronyms
APF
Authorized Program Facility
ITCAM
API
Application Programming
Interface
IBM Tivoli Composite
Application Monitor
ITIL®
ARM
Application Response
Measurement
Information Technology
Infrastructure Library
ITSO
ASM
Application Service Monitor
International Technical
Support Organization
BCM
Byte Code Modification
J2C
Java 2 Connector
CAT
Client Application Tracker
J2EE
Java 2, Enterprise Edition
CD-ROM
Compact Disk - Read-Only
Memory
JAR
Java Archive
JAX-RPC
Customer Information Control
System
Java API for XML-based
Remote Procedure Call
JCL
Job Control Language
CLI
Command Line Interface
JDBC
Java Database Connectivity
CPU
Central Processing Unit
JES2
Job Entry Subsystem 2
DASD
Direct Access Storage Device
JMX
Java Management Extension
EJB
Enterprise JavaBeans™
JNI™
Java Native Interface
ESB
Enterprise Service Bus
JRE™
Java Runtime Environment
ETE™
End-to-End
JVM
Java Virtual Machine
FFDC
First Failure Data Capture
JVMPI
FMID
Function Modification
Identifier
Java Virtual Machine Profiler
Interface
JVMTI
GLUE
Global User Exit
Java Virtual Machine Tool
Interface
GUI
Graphical User Interface
LDAP
HFS
Hierarchical File System
Lightweight Directory Access
Protocol
HTML
Hypertext Markup Language
MSC
Multiple Systems Coupling
HTTP
Hypertext Transfer Protocol
MVS
Multiple Virtual Storage
HTTPS
HTTP Secure
OTMA
Open Transaction Manager
Access
IBM
International Business
Machine Corporation
PCB
Program Control Block
IMS
Information Management
System
PDF
Portable Document Format
PLT
Program List Table
IPL
Initial Program Load
PMI
ISM
Internet Service Monitoring
Performance Management
Interface
CICS
© Copyright IBM Corp. 2008. All rights reserved.
199
RACF®
Resource Access Control
Facility
RMI
Remote Method Invocation
RTE
Runtime Environment
SCA
Service Component
Architecture
SMF
System Measurement Facility
SMP/E
System Modification
Program/Extended
SNMP
Simple Network Management
Protocol
SOA
Service-oriented architecture
SQL
Structured Query Language
SSH
Secure Shell
SSL
Secure Sockets Layer
SSM
System Service Monitor
STI
Synthetic Transaction
Investigator
SYSPLEX
System Complex
TCP/IP
Transmission Control
Protocol/Internet Protocol
TRUE
Transaction User Exit
TSO
Time Sharing Option
UDB
Universal Database
UML
Universal Markup Language
URI
Universal Resource Identifier
URL
Universal Resource Locator
WLM
Workload Manager
WRM
Web Response Monitor
WSDL
Web Services Definition
Language
XML
Extensible Markup Language
200
Managing an SOA Environment with Tivoli
Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this paper.
IBM Redbooks publications
For information about ordering these publications, see “How to get IBM
Redbooks publications” on page 206. Note that several of the documents
referenced here might be available in softcopy only:
򐂰 IBM Tivoli Composite Application Manager Family Installation Configuration
and Basic Usage, SG24-7151
򐂰 Deployment Guide Series: IBM Tivoli Composite Application Manager for
WebSphere V6.0, SG24-7252
򐂰 Getting Started with IBM Tivoli Monitoring 6.1 on Distributed Environments,
SG24-7143
򐂰 IBM Tivoli OMEGAMON XE V3.1.0 Deep Dive on z/OS, SG24-7155
򐂰 Implementing OMEGAMON XE for Messaging V6.0, SG24-7357
򐂰 Installing WebSphere Studio Application Monitor V3.1, SG24-6491
򐂰 Large-Scale Implementation of IBM Tivoli Composite Application Manager,
REDP-4162
򐂰 Migrating to Netcool/Precision for IP Networks - Best Practices for Migrating
from IBM Tivoli NetView, SG24-7375
򐂰 Solution Deployment Guide for IBM Tivoli Composite Application Manager for
WebSphere, SG24-7293
򐂰 Unveil Your e-business Transaction Performance with IBM TMTP 5.1,
SG24-6912
򐂰 WebSphere Studio Application Monitor V3.2 Advanced Usage Guide,
SG24-6764
򐂰 Understanding SOA Security Design and Implementation, SG24-7310
򐂰 IBM Tivoli Business Service Manager V4.1, REDP-4288
© Copyright IBM Corp. 2008. All rights reserved.
201
Other publications
These publications are also relevant as further information sources:
򐂰 IBM Tivoli Composite Application Manager for Response Time Tracking
publications:
– IBM Tivoli Composite Application Manager for Response Time Tracking
Administrator’s Guide, SC32-1905
– IBM Tivoli Composite Application Manager for Response Time Tracking
V6.1 Administrator’s Guide, SC32-9483
– IBM Tivoli Composite Application Manager for Response Time Tracking
V6.1 Checking Performance and Availability, SC32-9484
– IBM Tivoli Composite Application Manager for Response Time Tracking
V6.1 Command Reference Guide, SC32-9485
– IBM Tivoli Composite Application Manager for Response Time Tracking
V6.1 Prerequisites, SC32-9486
– IBM Tivoli Composite Application Manager for Response Time Tracking
V6.1 Problem Determination Guide, SC32-9513
– IBM Tivoli Composite Application Manager for Response Time Tracking
V6.1 Program Directory for z/OS, GI11-4099
– IBM Tivoli Composite Application Manager for Response Time Tracking
V6.1: Installing a Management Server in a WebSphere Cluster
Environment, SC32-1804
– IBM Tivoli Composite Application Manager for Response Time Tracking
V6.1 Installation and Configuration Guide, GC32-9482
– IBM Tivoli Composite Application Manager for Response Time Tracking:
Installation and Configuration Guide, GC32-1907
򐂰 IBM Tivoli Composite Application Manager for CICS and IMS transaction
publications:
– IBM Tivoli Composite Application Manager for CICS Transactions V6.1
Product Guide, SC32-9510
– IBM Tivoli Composite Application Manager for IMS Transactions V6.1
Product Guide, SC32-9511
򐂰 IBM Tivoli Composite Application Manager for WebSphere publications:
– IBM Tivoli Composite Application Manager for WebSphere Installation and
Customization Guide, GC32-9506
– IBM Tivoli Composite Application Manager for WebSphere Operator’s
Guide, SC32-9508
202
Managing an SOA Environment with Tivoli
– IBM Tivoli Composite Application Manager for WebSphere Problem
Determination Guide, SC32-9509
– IBM Tivoli Composite Application Manager for WebSphere Usage Guide,
GC32-1934
– IBM Tivoli Composite Application Manager for WebSphere User’s Guide,
SC32-9507
– IBM Tivoli Composite Application Manager for WebSphere: Installing and
Configuring the Tivoli Enterprise Monitoring Agent, SC32-1801
– IBM Tivoli Composite Application Manager for WebSphere: Tivoli
Enterprise Monitoring Agent Problem Determination Guide, SC32-1800
򐂰 IBM Tivoli Composite Application Manager for SOA publications:
– Configuring IBM Tivoli Composite Application Manager for SOA on z/OS,
SC32-9493
– IBM Tivoli Composite Application Manager for SOA Installation and User’s
Guide, GC32-9492
– IBM Tivoli Composite Application Manager for SOA Program Directory,
GI11-4087
– IBM Tivoli Composite Application Manager for SOA Release Notes,
GI11-4096
– IBM Tivoli Composite Application Manager for SOA: Installing and
Troubleshooting IBM Web Services Navigator, GC32-9494
򐂰 IBM Tivoli Composite Application Manager for Response Time publications:
– IBM Tivoli Composite Application Manager for Client Response Time
User’s Guide Version 6.2, SC23-6332
– IBM Tivoli Composite Application Manager for Web Response Time
User’s Guide Version 6.2, SC23-6333
– IBM Tivoli Composite Application Manager for Robotic Response Time
User’s Guide Version 6.2, SC23-6334
– IBM Tivoli Composite Application Manager for User Response Time
Dashboard User’s Guide Version 6.2, SC23-6335
– IBM Tivoli Composite Application Manager for Response Time Problem
Determination Guide Version 6.2, GI11-8061
򐂰 IBM Tivoli Composite Application Manager for Web Resources publications:
– IBM Tivoli Composite Application Manager for Web Resources: J2EE Data
Collector Installation Guide, GC23-6179
– IBM Tivoli Composite Application Manager for Web Resources:
WebSphere Distributed Data Collector Installation Guide, GC23-6180
Related publications
203
– IBM Tivoli Composite Application Manager for Web Resources: J2EE
Agent Installation Guide, GC23-6181
– IBM Tivoli Composite Application Manager for Web Resources:
WebSphere Agent Installation Guide, GC23-6182
– IBM Tivoli Composite Application Manager for Web Resources: Web
Servers Agent Installation Guide, GC23-6183
– IBM Tivoli Composite Application Manager for Web Resources:
Community Edition Data Collector Installation Guide, GC23-6184
– IBM Tivoli Composite Application Manager for Web Resources: Quick
Start Guide, GC23-6185
– IBM Tivoli Composite Application Manager for Web Resources: J2EE
Agent Problem Determination Guide, GI11-8160
– IBM Tivoli Composite Application Manager for Web Resources:
WebSphere Agent Problem Determination Guide, GI11-8161
– IBM Tivoli Composite Application Manager for Web Resources: Web
Servers Agent Problem Determination Guide, GI11-8162
򐂰 IBM Tivoli Monitoring publications
– Exploring IBM Tivoli Monitoring, SC32-1803
– IBM Tivoli Monitoring Administrator’s Guide, SC32-9408
– IBM Tivoli Monitoring: Configuring IBM Tivoli Enterprise Monitoring Server
on z/OS, SC32-9463
– IBM Tivoli Monitoring Installation and Setup Guide, GC32-9407
– IBM Tivoli Monitoring Problem Determination Guide, GC32-9458
– IBM Tivoli Monitoring User’s Guide, SC32-9409
– IBM Tivoli Monitoring: Upgrading from Tivoli Distributed Monitoring,
GC32-9462
– IBM Tivoli Universal Agent API and Command Programming Reference
Guide, SC32-9461
– IBM Tivoli Monitoring Universal Agent User’s Guide, SC32-9459
– Introducing IBM Tivoli Monitoring, GI11-4071
204
Managing an SOA Environment with Tivoli
Online resources
These Web sites are also relevant as further information sources:
򐂰 IBM Tivoli
http://www.ibm.com/tivoli
򐂰 System requirements and prerequisites for IBM Tivoli Composite Application
Manager for Response Time Tracking, Version 6.1
http://publib.boulder.ibm.com/tividd/td/ITCAMRTT/prereq61/en_US/HTML
/Version61.html
򐂰 Prerequisites for Data Collectors and Monitoring Agents for IBM Tivoli
Composite Application Manager for WebSphere 6.1
http://publib.boulder.ibm.com/tividd/td/ITCAMWAS/prereq61/en_US/HTML
/itcam6.html
򐂰 IBM Tivoli Composite Application Manager for Response Time Tracking
product page
http://www.ibm.com/software/tivoli/products/composite-application-mg
r-rtt/
򐂰 IBM Tivoli Composite Application Manager for WebSphere product page
http://www.ibm.com/software/tivoli/products/composite-application-mg
r-websphere/
򐂰 IBM Tivoli Composite Application Manager for SOA product page
http://www.ibm.com/software/tivoli/products/composite-application-mg
r-soa/
򐂰 IBM Tivoli Composite Application Manager for J2EE product page
http://www.ibm.com/software/tivoli/products/composite-application-mg
r-itcam-j2ee/
򐂰 IBM Tivoli Composite Application Manager for Internet Service Monitoring
product page
http://www.ibm.com/software/tivoli/products/composite-application-mg
r-ism/
򐂰 DB2 UDB Version 8 Fix Packs and clients
http://www.ibm.com/software/data/db2/udb/support/downloadv8.html
򐂰 ITCAM for Response Time Tracking Fix Pack 1
http://www3.software.ibm.com/ibmdl/pub/software/tivoli_support/patches/
Related publications
205
򐂰 IBM Tivoli Monitoring Workspace Package for IBM Tivoli Composite
Application Manager for Internet Service Monitoring
http://catalog.lotus.com/topal?NavCode=1TW10TM31
򐂰 Technote FAQ “Is there a relatively easy way to estimate the amount of disk
space needed for your database?”
http://www.ibm.com/support/docview.wss?rs=2344&context=SS3PGL&dc=DB5
20&q1=database&uid=swg21250907&loc=en_US&cs=utf-8&lang=en
򐂰 Open Group Web site for Application Response Management (ARM)
http://www.opengroup.org/arm
򐂰 Microsoft link for InstallShield error
http://support.microsoft.com/default.aspx?scid=kb;en-us;295278
򐂰 Microsoft Windows Services for UNIX®
http://www.microsoft.com/technet/interopmigration/unix/sfu/default.mspx
򐂰 Java specification for JAX-RPC: JSR-000109 Implementing Enterprise Web
Services
http://www.jcp.org/aboutJava/communityprocess/final/jsr109/
򐂰 BEA WebLogic interceptor information
http://e-docs.bea.com/wls/docs81/webserv/interceptors.html
򐂰 Eclipse Web site
http://www.eclipse.org
How to get IBM Redbooks publications
You can search for, view, or download IBM Redbooks publications, Redpapers,
Technotes, draft publications and additional materials, as well as order hardcopy
IBM Redbooks publications, at this Web site:
ibm.com/redbooks
Help from IBM
IBM Support and downloads
ibm.com/support
206
Managing an SOA Environment with Tivoli
IBM Global Services
ibm.com/services
Related publications
207
208
Managing an SOA Environment with Tivoli
Index
Web Services Navigator
flow pattern view 25
A
application server 27
archive agent 29
attribute 51
G
global publishing server 29
B
back-end system 187
BCM 32
Byte Code Modification
See BCM
C
CandleMonitor 46
CICS 28, 45
TRADERBL 188
TRADERPL 188
CICS data collector 40
client-side interception 23
commands
tapmagent 39
cross-memory services 31
CSMI 188
D
data collector 28
CICS 28
IMS 28
J2EE 28
database connection pools 27
DB2 UDB 29
Defined View 43
discover feature 43
E
EJB 27
EJB usage 27
Enterprise JavaBeans
See EJB
F
flow pattern view
© Copyright IBM Corp. 2008. All rights reserved.
I
IBM HTTP Server 29
IMS 28, 45
TRADERBL 188
IMS data collector 40
ITCAM for Response Time Tracking
components 33
management agent 37
management server 34
store and forward agent 36
Tivoli Enterprise Monitoring Agent 41
ITCAM for SOA 23
action 87
components 21
data collector 22
features 20
filters 87
metrics 51
server-side interception 23
Tivoli Enterprise Monitoring Agent 22
viewer 22
workspace 20
ITCAM for WebSphere
data collector 30
database 30
managing server 28
J
J2EE 28
J2EE application server 27
Java API for XML-based Remote Procedure Call
See JAX-RPC
Java Virtual Machine Tool Interface
See JVMTI
JAX-RPC 21–22
JAX-RPC handler 23
209
JVM 37
JVM thread pools 27
JVMTI 26
K
kernels 29
M
managed system
name 45
management agent 40
ARM agent 39
difference 37
generic window component 38
ITCAM for Response Time Tracking 37
J2EE instrumentation 39
mainframe 39
Quality of Service 38
management server 34
clustered 35
managing server 27–28
archive agent 29
global publishing server 29
kernels 29
message dispatcher 29
publishing servers 29
Mediation Configuration 20
message arrival 20
message dispatcher 29
metrics 51
monitoring file 43
N
namelists 42
O
OCTIGATE database 30
Oracle 29
OS/400 monitors 44
P
PERFORM INCLUDE 45
PERFORM STARTMON 45
Performance Management Interface
See PMI
PMI 27
primary workspace 51
210
Managing an SOA Environment with Tivoli
publishing servers 29
Q
queue manager 43–44
configuration event queue 44
like-named parameters 44
node name 45
queue-sharing group 46
R
Redbooks Web site 206
Contact us xi
S
SCA 21, 25
server-side interception 23
Service Component Architecture
See SCA
service extension 23
Service Management Agent 20
Service Management Agent Environment 20
service topology view 25
service-oriented architecture
See SOA
SET AGENT 45
SET APPL 45
SET CHANNEL 44
SET EVENTLOG 44
SET EVENTQIN 44
SET EVENTQOUT 45
SET GROUP 44
SET MANAGER 44
SET MQIMONITOR 46
SET QACCESS 44
SET QSG 46
SET QSG command 46
SET QUEUE 44
Simple Network Management Protocol
See SNMP
SNMP 29
SOA 20
SOAP 21–23
STI 38
store and forward agent 36
Sun Solaris 29
Synthetic Transaction Investigator
See STI
T
Z
tapmagent 39–40
TRAD 188
Trader
BuySellServlet 185
company database 187
customer database 187
GetQuotesServlet 184
ListCompanyServlet 183
login.html 183
LogoutServlet 185
TraderClientLogin 186
TraderClientMain 186
TraderClientQuote 187
TRADERBL 188
TRADERPL 188
transaction flows view 25
z/OS monitors 44
U
UML 25
Universal Markup Language
See UML
Universal Markup Language (UML) 25
UNIX 44
W
Web Response Monitor
See WRM
Web Services Definition Language
See WSDL
Web Services Navigator 22, 24
service topology view 25
transaction flows view 25
WebSphere Application Server Node Deployment
35
WebSphere Caching Proxy 36
WebSphere Edge Server 35
WebSphere MQ
application 44
data 43
monitoring agent 46
object 45
OMEGAMON Monitoring Agent 44
WebSphere MQ-based z/OS applications 45
workspace 20
WRM 39
WSDL 21–22
Index
211
212
Managing an SOA Environment with Tivoli
Back cover
Managing an SOA
Environment with
Tivoli
Discusses SOA
performance and
availability
management
Service-oriented architecture (SOA) is a major new trend for
application architecture. It allows you to build applications as
components as defined using a Web Services Description Language
(WSDL) file. You can implement applications in different servers,
even different platforms. You can modify application components
Describes mediation and workflow logic easily in execution, allowing a flexible
application structure. Implementation of the client and the server
scenarios with ESB
side is also masked by the use of enterprise service bus, which
and message broker allows a different server implementation to be provided without the
need to modify the client, or, different clients can use the same
Integrates ITCAM
server implementation.
and other Tivoli
solutions
The highly flexible and distributed nature of SOA-based applications
is its primary strength and the source of its appeal. However, when
a problem arises, this flexible nature also causes a greater problem
in pinpointing the source of problem. SOA also requires a
disciplined management effort to ensure that operational changes
do not disrupt overall availability.
The IBM Tivoli Composite Application Manager (ITCAM) family of
products directly assists services specialists who implement and
manage distributed applications. We illustrate the management
needs for SOA-based applications and demonstrate how Tivoli
products can address these application environment needs. The
overall solution that we use includes ITCAM for SOA, ITCAM for
WebSphere, ITCAM for Response Time Tracking, OMEGAMON XE
for Messaging, and Tivoli Business Service Manager.
REDP-4318-00
®
Redpaper
™
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks