transcript
- 1. Front coverManaging an SOAEnvironment withTivoliDiscusses
SOA performance andavailability managementDescribes mediation
scenarioswith ESB and message brokerIntegrates ITCAM andother
Tivoli solutions Budi Darmawan Pradeep Nambiar Prem Lall Ravinder
Gummadavelliibm.com/redbooks Redpaper
- 2. International Technical Support OrganizationManaging an SOA
Environment with TivoliApril 2008 REDP-4318-00
- 3. 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 ADPSchedule Contract with IBM
Corp.
- 4. 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
- 5. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 156iv Managing an SOA Environment with Tivoli
- 6. 4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 158Chapter 5.
Managing an SOA application in a business context . . . . . .
1595.1 Solution overview . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 1605.2 Tivoli EIF probe .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 1615.3 Defining situations . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1625.4 Designing business services . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 1645.5 Defining service level .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 1745.6 Getting the business status . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 175Appendix A. The
Trader application . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 179Application 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 . . . . . . . . . . . . . . . .
. . . . . . . . . . 191Software requirements . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Runtime environment . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 193 Development environment . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
195Appendix B. Additional material . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 197Locating the Web material . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . 197Using the Web material . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 198 System requirements
for downloading the Web material . . . . . . . . . . . . . 198 How
to use the Web material . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 198Abbreviations and acronyms . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Related
publications . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 201IBM Redbooks publications . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
201Other publications . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . 202Online resources . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . 205How to get IBM Redbooks publications . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 206Help from IBM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 206Index . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 209 Contents v
- 7. vi Managing an SOA Environment with Tivoli
- 8. NoticesThis 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. Consultyour 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 IBMproduct, program, or service may
be used. Any functionally equivalent product, program, or service
thatdoes not infringe any IBM intellectual property right may be
used instead. However, it is the usersresponsibility 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 licenseinquiries, 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 suchprovisions are
inconsistent with local law: INTERNATIONAL BUSINESS MACHINES
CORPORATIONPROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF
ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow
disclaimerof 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 madeto the information herein; these
changes will be incorporated in new editions of the publication.
IBM maymake improvements and/or changes in the product(s) and/or
the program(s) described in this publication atany time without
notice.Any references in this information to non-IBM Web sites are
provided for convenience only and do not in anymanner serve as an
endorsement of those Web sites. The materials at those Web sites
are not part of thematerials 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
withoutincurring any obligation to you.Information concerning
non-IBM products was obtained from the suppliers of those products,
their publishedannouncements or other publicly available sources.
IBM has not tested those products and cannot confirmthe accuracy of
performance, compatibility or any other claims related to non-IBM
products. Questions onthe 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 themas 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 businessenterprise is
entirely coincidental.COPYRIGHT LICENSE:This information contains
sample application programs in source language, which illustrate
programmingtechniques on various operating platforms. You may copy,
modify, and distribute these sample programs inany form without
payment to IBM, for the purposes of developing, using, marketing or
distributing applicationprograms conforming to the application
programming interface for the operating platform for which
thesample 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
- 9. TrademarksThe following terms are trademarks of the
International Business Machines Corporation in the United
States,other countries, or both: Redbooks (logo) DB2 OS/400 z/OS
ETE Rational Alerts IBM Redbooks AIX IMS RACF Cloudscape MQSeries
Tivoli Enterprise Console CICS MVS Tivoli DataPower OMEGAMON
WebSphereThe following terms are trademarks of other companies:SAP
NetWeaver, SAP, and SAP logos are trademarks or registered
trademarks of SAP AG in Germany andin several other
countries.Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are
registered trademarks of Oracle Corporationand/or its
affiliates.ITIL is a registered trademark, and a registered
community trademark of the Office of GovernmentCommerce, 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, othercountries, or
both.Internet Explorer, Microsoft, Windows, and the Windows logo
are trademarks of Microsoft Corporation in theUnited 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
- 10. 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
- 11. 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 Groupx Managing an
SOA Environment with Tivoli
- 12. 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.htmlComments 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
- 13. xii Managing an SOA Environment with Tivoli
- 14. 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
- 15. 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 be2
Managing an SOA Environment with Tivoli
- 16. used together or adopted incrementally. There are several
well-known SOApatterns, including: Service creation Service
connectivity Interaction and collaboration services Business
Process Management Information as a serviceYou can apply the SOA
design, governance, security, and management acrossall of these
scenarios.Applications in a typical silo architecture build their
functionality on top of anexisting application stack. In an
SOA-based environment, the logical boundarybetween 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 Services
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 Services implementation. A WSDL document acts as
a server-side descriptor that defines the Web Services 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
- 17. 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 certain4 Managing an SOA Environment
with Tivoli
- 18. 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 organizations 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
- 19. 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 state6
Managing an SOA Environment with Tivoli
- 20. 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
- 21. 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
- 22. 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 users 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
- 23. 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 executive1.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 necessary10
Managing an SOA Environment with Tivoli
- 24. 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
- 25. 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 Tracking1.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
- 26. The system administrator has the authority to modify the
system, such asinstalling a new feature or a patch to the
monitoring system, thus, allowinginteraction with the management of
the SOA solution.The system administrator can install, configure,
and maintain all the tools that asubject matter expert needs. A
system administrator can also configure, start,and stop agent
processes, or perhaps even reconfigure the entire
monitoringenvironment.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
- 27. Figure 1-2 Administer user dialog1.6.5 Enterprise system
management architect The system management architect interacts with
the business side of the company and is familiar with the companys
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
- 28. 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 developers 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
- 29. 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 Services 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
- 30. 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=wsdm1.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
- 31. 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
- 32. 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
- 33. 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 212.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
- 34. 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
- 35. 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
- 36. ITCAM for SOA Monitoring agent Application Server
configuration Web Services handler or Data Data collector Tivoli
Enterprise extension collector adapter Monitoring Agent log Tivoli
Enterprise Management Server Tivoli Enterprise Portal ServerFigure
2-1 ITCAM for SOA structureThe monitoring agent data collector is
implemented as a JAX-RPC handler orservice extension that is
installed into the application servers that host themonitored Web
Services. The handler is given control when either of thefollowing
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 ormore local log files. The
information is then transferred to Tivoli EnterpriseMonitoring
Server and can be archived into a historical database for
laterretrieval with IBM Web Services Navigator.ITCAM for SOA V6.1
focuses on the SOAP engine of IBM WebSphereApplication Server,
WebSphere Service Integration Bus, Microsoft .NETFramework, and BEA
WebLogic.The Web Services data collector supports both Java 2
Platform, EnterpriseEdition (J2EE) application client and server
container environments, becauseJAX-RPC handlers are supported only
by these environments. The WebServices must be compliant with
JSR-109 specifications.To ensure the proper operation of the
JAX-RPC handler, verify that the clientapplications 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
- 37. 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 TDW warehouse Metric Tivoli Enterprise log Data
Monitoring Agent collector Web Services Navigator Metric log Data
collector Log Assembler Combined metric log Metric log Data
collector 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 transaction24
Managing an SOA Environment with Tivoli
- 38. 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 mediationWebSphere Process
Server and WebSphere Enterprise Service Bus introduce anew way to
model services in an SOA, which is called the Service
ComponentArchitecture (SCA). SCA is designed to separate business
logic from itsimplementation so that you can focus on assembling an
integrated applicationwithout knowing implementation details.There
is a special type of SCA component, which is called a mediation. In
anSOA, where services are loosely coupled rather than connected
directly to eachother, mediations can be inserted between the
services, where they canintercept and process messages that are
passed between the services.Mediations can process these messages
and take appropriate actions, such asreroute, log, or transform a
message, or create a notification or an event.IBM Tivoli Composite
Application Manager for SOA provides the ability todynamically
enable and disable the deployed mediation functions. This facility
is Chapter 2. Tivoli application management products 25
- 39. 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_6102.2 ITCAM
for WebSphere and ITCAM for J2EE The IBM Tivoli application
management solution for J2EE applicatio