• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Managing an soa environment with tivoli redp4318
 

Managing an soa environment with tivoli redp4318

on

  • 829 views

 

Statistics

Views

Total Views
829
Views on SlideShare
829
Embed Views
0

Actions

Likes
0
Downloads
14
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Managing an soa environment with tivoli redp4318 Managing an soa environment with tivoli redp4318 Document Transcript

    • 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
    • International Technical Support OrganizationManaging an SOA Environment with TivoliApril 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 ADPSchedule 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156iv Managing an SOA Environment with Tivoli
    • 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
    • vi Managing an SOA Environment with Tivoli
    • 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
    • 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® 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 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
    • 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 Groupx 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.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
    • 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 be2 Managing an SOA Environment with Tivoli
    • 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 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 certain4 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 state6 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 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
    • 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 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
    • 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
    • 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 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=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
    • 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 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
    • 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 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
    • 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
    • – 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
    • 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 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) interfaces26 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 e ris nt rp te ge Tivoli Enterprise En ng A li i Application servers with vo or Ti onit Management Server Data collectors 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 servers28 Managing an SOA Environment with Tivoli
    • that run applications. The difference between ITCAM for J2EE and ITCAM forWebSphere is the platform support for the data collectors. These data collectorscan 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 processesThe overseer components are the controlling logic for the managing server. Forthe 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. Figure 2-4 shows the conceptual relationship among the components. Snapshot traffic Publish traffic Global Publish Server (SAM) Publish Server (PS) Kernel (KL) Visualization Engine Provide services on: Provide services on: Message Dispatcher - Lookup -Administration (MD) - Registration -Availability - Recovery -Problem Determination Archive Agent (AA) - Configuration -Performance Management OCTIGATE databaseFigure 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 they30 Managing an SOA Environment with Tivoli
    • execute. The data collectors for z/OS systems are written to take advantage ofservices on z/OS, such as MVS™ Cross-Memory Services and address spacefencing, which are not available on distributed systems.Data collectors are configured as a multithreaded process. They consist of thefollowing 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, anddeliver the data to the managing server.The data collectors send the probes into the application servers to analyze theapplications’ performance. The probes collect monitoring data and feed it totransport routines that in turn route the data to the managing server. Themanaging server processes it for display in the Web console and for storage inthe OCTIGATE repository, which relieves the processing burden of ITCAM forWebSphere and ITCAM for J2EE from the application servers as much aspossible. The data collectors and probes are not designed to analyze or interpretdata, but to collect it and route it as quickly as possible to the managing serverwhere the analysis is performed.The data sources that are employed by ITCAM for WebSphere and ITCAM forJ2EE 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 PMI Custom Service bcm Publish data am KYN Tivoli Enterprise To TEMS Monitoring Agent Figure 2-5 J2EE data collector structure2.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. Figure 2-6 shows the ITCAM for Response Time Tracking components. RTT RTT RTT RTT Management Store and Store and management server forward agent forward agent agent FIREWALL FIREWALL RTT RTT RTT RTT Tivoli management management management management Enterprise agent agent agent agent Management AgentFigure 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 412.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 server34 Managing an SOA Environment with Tivoli
    • Figure 2-8 shows the clustered management server. It consists of WebSphereEdge Server for load balancing, the management server on several clusteredWebSphere Application Server Node Deployment systems, and the databaseinstalled on a separate database server. WebSphere Node Deployment Cluster WebSphere Application Server WebSphere Edge Server DB2 WebSphere Application ServerFigure 2-8 Clustered management serverClustered 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 instructionsOverall, regardless of the management server types, the management serverprovides 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 interface2.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. 1976 Store and Forward RTT RTT agent Management 80 Management Caching server 9081 Proxy 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
    • Store and Store and Management Management forward 80 forward 80 Server agent agent agent Figure 2-10 Multiple store and forward agents2.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 Web Management reverse Response agent proxy Monitor Client J2EE Generic STI client Application monitoring Window Tracker 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 QoS Back-end Web server browser Apache reverse proxy Back-end processing time Overall response time Page render Round-trip time timeFigure 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 agentFor z/OS-based systems, ITCAM for CICS Transactions and ITCAM for IMSTransactions data collectors can send transaction start and transaction endevents to the management agent running on the same z/OS system as the CICSand IMS started task. These start and stop events for CICS and IMS transactionsare translated into ARM start and ARM stop calls by a component called thetransaction server. These data collectors allow IMS and CICS transactions to beshown as part of the distributed transaction or as a stand-alone transactionrunning on z/OS. Figure 2-13 on page 40 shows the z/OS-based managementagent structure. Chapter 2. Tivoli application management products 39
    • ARM agent ITCAM for ITCAM for Management CICS IMS agent Transactions Transactions Transaction Server 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 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.40 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. Tivoli Enterprise ITCAM for RTT Management Server 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 queuemanager event information, channel event information, performance eventinformation, configuration event, command event information, and loggerevent information will be copied. After WebSphere MQ monitoring has readan event message from an event queue, it deletes the message to ensure thatit is processed only once. If another application running at your site requiresaccess to event messages, you can define an output queue where thesemessages are copied and point the other application to that queue. If no SETEVENTQOUT command applies to a queue manager, the event information isdiscarded after being processed.The PERFORM INCLUDE command points to an external file containingcustomization commands. To execute the commands in this file, specifyPERFORM INCLUDE in your startup file.The PERFORM STARTMON command initiates monitoring of WebSphereMQ objects, specifies the sampling interval for collecting WebSphere MQdata, and specifies whether or not historical data will be collected. ThePERFORM STARTMON command is required.The SET AGENT command enables you to specify the middle qualifier usedin the managed system name. On distributed platforms, if this value is notspecified, no value is used. On z/OS, if this value is not specified, the hostname is used. If you specify this value, it is used only in the managed systemnames of subnodes. For example, to avoid confusion and to allow multipleWebSphere MQ Monitoring Agents, instead of issuing the default agentstartup command IRAMAN KMQAGENT START (to start a node named hostname: MQIRA), you can issue the modified agent startup command IRAMANKMQAGENT START agentid (to start a node named agentid: MQIRA). Hereare 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-basedz/OS applications, CICS transactions, and IMS programs that must bemonitored 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 data2.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 WebSphere Application Server TraderDBServices laredo srv107 lima WebSphere Process Server WebSphere Application TraderDBAvailabilityMediati DB2 Universal Database Server onApp TRADERDB TraderClientWeb WSRR khartoum WebSphere Application Server TraderDBServicesFigure 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 lengthFigure 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 Summary52 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 rate3.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 size3.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 643.4.1 Execution environment Figure 3-6 shows our ITCAM for Response Time Tracking execution environment. perth WebSphere Application Server srv107 TraderDBServices laredo J2EE lima WebSphere Process Server WebSphere Application TraderDBAvailabilityMediati DB2 Universal Database Server onApp TRADERDB TraderClientWeb WSRR khartoum J2EE J2EE ARM WebSphere Application Server TraderDBServices J2EE gruene srv106 Rational Performance ITCAM for Response Time Tester Tracking RPT Management serverFigure 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 Tester58 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 Tester3.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 Discovery60 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 settings3.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 information3.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 Groups66 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 Status68 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 Portal3.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 chart5. 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 783.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 list74 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 IBMITMTMAITM6KD4logs 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 action78 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 $ITMhomeTMAITM6KD4logs: 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.CACHEarchive 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 files80 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 AssemblerSET TOOLPATH="C:IBMITCAM for SOA 6.1.0Tools"SET LOGAJAR=com.ibm.websightView.LogAssembler.jarcd soalogsfor %%i in (*.ClientSvc.metric.log.*) do %toolpath%_jvmjrebinjava-cp %toolpath%lib%logajar%;%toolpath%libjlog.jar -jar%toolpath%lib%logajar% 0 a soa.Merged.log C:soalogs%%iC:soalogsKD4.1..PERTHCell01.PERTHNode01.ClientSvc.content.logfor %%i in (*.ServerSvc.metric.log.*) do %toolpath%_jvmjrebinjava-cp %toolpath%lib%logajar%;%toolpath%libjlog.jar -jar%toolpath%lib%logajar% 0 a soa.Merged.log C:soalogs%%iC:soalogsKD4.1..PERTHCell01.PERTHNode01.ServerSvc.content.logNote 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 0, 1, or 2; nonzero values generate a lot of output processing o or a; represents overwrite or append to the log files target log file name The merged log file name metric log file name The metric log that you want processed content log files 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 project82 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 summary84 Managing an SOA Environment with Tivoli
    • Figure 3-37 shows the transaction flows. It shows the time line of the WebServices calling sequences. The busy chart shows all 108 Web Services callsthat 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 Content86 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 Patterns3.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 parameters88 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 filter3.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 is90 Managing an SOA Environment with Tivoli
    • installed. The Discovery Library Adapter is supplied from ITCAM for SOA underthe installation image KD4/DLA/ as WSRRV600_DLA.zip andWSRRV600_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 andRepository V6.0.2, from the /opt/IBM/WSRRV6_DLA/bin directory, edit theWSRR_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 Repositorycom.ibm.management.soa.dla.wsrr.address=laredocom.ibm.management.soa.dla.wsrr.port=2809com.ibm.management.soa.dla.wsrr.domainName=itsc.austin.ibm.comcom.ibm.management.soa.dla.wsrr.websphereSecurityEnabled=falsecom.ibm.management.soa.dla.wsrr.securityEnabled=falsecom.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 propertiescom.ibm.management.soa.dla.filetransfer.host=peoria.itsc.austin.ibm.comcom.ibm.management.soa.dla.filetransfer.targetDir=/opt/IBM/WSRRV6_DLA/stagingcom.ibm.management.soa.dla.filetransfer.stagingDir=../stagingcom.ibm.management.soa.dla.filetransfer.fileFilter=*.xmlcom.ibm.management.soa.dla.filetransfer.securityEnabled=truecom.ibm.management.soa.dla.filetransfer.userid=rootcom.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 -f92 Managing an SOA Environment with Tivoli
    • You can add the ITCAM for SOA view to the view list in the Tivoli EnterprisePortal. From Tivoli Enterprise Portal, click the Administer Users icon in thetool bar. The Administer Users pop-up window is shown in Figure 3-46.Figure 3-46 Administer Users: Navigator ViewsClick Apply and then click OK to add the ITCAM for SOA view to the drop-downlist 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 Overview94 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 service4. 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 ServicesSelect Service Detail from an observed service to get into the detailed view ofthe service as shown in Figure 3-52 on page 98. The service port topology viewdisplays the service port details discovered by the Discover Library Adapter, theservice 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
    • Service Instance 1 Enterprise Service Bus (ESB) Service Consumer Service Instance 2Figure 4-1 Services in an SOAService Instance 1 and Service Instance 2 shown in Figure 4-1 have the sameservice interface; however, they might share the same implementation or adifferent implementation. The service consumer is bound to the service providereither directly or by using logic that we refer to as mediation. The target serviceendpoint can be bound at deployment time or at run time.Enterprise Service Bus enables you to insert mediation logic between the serviceconsumer and the service provider. Mediations can look at the service requestdata to make certain decisions or can refer to an external component, such asdatabase or a service registry, to help execute mediation logic that affects theservice request flow within an Enterprise Service Bus. As an example, considermediation logic that uses a service registry component that is used to query andretrieve a choice of target service endpoints to which the service requestor canbe routed based on certain criteria, such as quality of service and serviceavailability.From a system management perspective, mediation enables us to monitorservice invocations, perform on demand logging of service requests andresponse data, observe service executions, and reconcile discovered serviceswith known services in a service registry. In addition to monitoring service data,the ability to control service requests based on operational data provides for anumber of use case scenarios that offer tremendous value to any enterprisebuilding 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 Endpoint102 Managing an SOA Environment with Tivoli
    • Lookup. You can create the mediation flow application by using a drag and dropinterface 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?OpenITCAM for SOA extends the following mediation primitives, which are calledmanaged 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 timefrom the operations environment using Tivoli Enterprise Portal either manuallyusing a Take Action menu entry or by using a predefined situation to perform anaction.Operational control of service requests and response flows in the WebSphereEnterprise 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 and104 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 Managed Select best Logger available service TraderWebClient Health Monitoring perth:9081 using ITCAM TraderDBServices 2 srv107:9081 khartoum:9082 WebSphere Service Registry & Repository Update Service Quality laredo:9080 and Server Health Situation IBM Tivoli And Monitoring Take Actions Enable / Disable Logging peoria from OperationsFigure 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 1264.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 WebSphere2. 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 the108 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 service7. 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 bad8. 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.htm110 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 ensureservice 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 project2. 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 editor5. 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 TraderDBServicesPartner10.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 module2. 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.ear4. 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 TraderDBServicesAvailabilityMediationApp7. 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 perth4. 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 call9. 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 amediation with a service registry in an SOA environment to achieve servicerouting 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 servicemetadata automatically. We define how to update the service metadataautomatically in 4.4, “Service monitoring automation” on page 136. Wedemonstrate 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 perth4.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 This argument is a required argument that identifies the specific document metadata as the target of the invocation.138 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 rties4.4.3 ITCAM for WebSphere and ITCAM for Web Resourcessituations 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: WASNotConnected WASContainerTransactionRollback WASDBConnectionPoolThreadTimeout WASError WASHighCPUPercentUsed WASHighGCTimePercent WASOutofHeapSpace WASServletsJSPsError WASThreadPoolPercentMaxed WASWebApplicationError140 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=swg27009086ITCAM for Web Resources 6.2 adds four new situations to the previous list thatgive additional monitoring control of WebSphere Application Server from anapplication perspective. They are: WASAppDiscovered WASAppHealthGood WasAppHealthFair WASAppHealthBadFor a non-WebSphere environment, the corresponding names are: J2EEAppDiscovered J2EEAppHealthGood J2EEAppHealthFair J2EEAppHealthBadFor our scenario, we create four new situations that are based on ApplicationServer Status attributes. We want to monitor the WebSphere Application Server -ServerSvc on perth and khartoum where we have deployed theTraderDBServices.The situations are listed in Table 4-2 on page 142 with information about thenecessary 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 - Updates the service metadata ServerSvc on perth is up 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 - Updates the service metadata ServerSvc on perth is down 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 - Updates the service metadata ServerSvc on khartoum is up 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 - Updates the service metadata ServerSvc on khartoum is down 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 Agent2. 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_Up3. 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 Updates the service metadata name TraderDBServices property serviceResponseTime and namespace for WSDL port http://services.db2.tra TraderDBServices associated der.j2ee.itso and with perth.itsc.austin.ibm.com average elapsed with value of good in WebSphere round-trip time is less than Service Registry and Repository 5000 milliseconds Perth_TrdrDBSvcResponse_Bad Monitors service port Updates the service metadata name TraderDBServices property serviceResponseTime and namespace for WSDL port http://services.db2.tra TraderDBServices associated der.j2ee.itso and with perth.itsc.austin.ibm.com situation with value of bad in WebSphere ResponseTImeCritical_61 Service Registry and Repository 0 is true on server ServerSvc in node perth.itsc.austin.ibm.com Khartoum_TrdrDBSvcResponse_Good Monitors service port Updates the service metadata name TraderDBServices property serviceResponseTime and namespace for WSDL port http://services.db2.tra TraderDBServices associated der.j2ee.itso and with average elapsed khartoum.itsc.austin.ibm.com round-trip time is less than with value of good in WebSphere 5000 milliseconds on Service Registry and Repository server ServerSvc in node khartoum.itsc.ausitn.ibm.c om Khartoum_TrdrDBSvcResponse_Bad Monitors service port Updates the service metadata name TraderDBServices property serviceResponseTime and namespace for WSDL port http://services.db2.tra TraderDBServices associated der.j2ee.itso and with situation khartoum.itsc.austin.ibm.com ResponseTImeCritical_61 with value of bad in WebSphere 0 is true on server Service Registry and Repository ServerSvc in node khartoum.itsc.austin.ibm.c om 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 5000 milliseconds Time Interval Status CompleteFigure 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 this152 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 Type6. 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 Registry154 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 data5. Use the menu File → Open and then Browse for the directory: /opt/ibm/WebSphere/AppServer/profiles/ProcSrv01/databases/EsbLogMedD B6. 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 IBM Tivoli NetView CCMDB Console Monitoring OMEGAMON C Relational Discovery Library ITCAM databases Books Data fetcher xml files ESDA Optional Tivoli EIF probe XML Toolkit components Tivoli Service Level Advisor JDBC TBSM processes SLA events TBSM postgreSQL Netcool GUI Foundation Netcool OMNIbus TBSM Console TBSM ObjectServer TBSM Server events Netcool Webtop launch user data user data license Tivoli Enterprise Portal Netcool Security Manager Netcool License ServerFigure 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 Omnibus5.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_OperationFigure 5-3 Business service structureTo 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 window2. 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 template5.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 10 15 minutes Application_Component 1 minute 5 minutes 5 minutes 10 5 10 minutes Application_Server 5 minutes 10 15 30 3 5 minutes minutes minutes Web_Services_Operation 5 minutes 10 15 30 3 5 minutes minutes minutes5.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 perthIn the event that the SCA mediation in srv107 is down, this triggers a majoroutage on the Application_Server object and generates an outage call (red) allthe 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 server178 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 DB2 Trader Trader Trader Trader IMS CICS DB2 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 186Portal 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 Services184 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 beanWe provides three type of enterprise application archive (ear) files for the clientinterface: 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 listing186 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 windowBack-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 Customer Name Stock price Company name Price history 7 days Stock owned Commission List company 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/ TraderTomcatServices/ sca/TraderTomcatServices services/TraderTomcatServices TraderIMSMediationWeb/sca/ TraderIMSServices/services/ TraderIMSServices Check TraderIMSServices TraderDBMediationWeb/sca/ endpoint TraderDBServices/services/ TraderDBServices TraderDBServices TraderCICSMediationWeb/sca/ TraderCICSServices/services/ TraderCICSServices TraderCICSServices WebSphere Service Registry & RepositoryFigure 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 SIBDB TraderEGrp 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 implementationSoftware 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 195Runtime 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 IMS V9 DB2 UDB V8.2 FP15 Gateway V6 IMS Connect for Java V9 TRADER TRADERBL TRADERBL TRADTOMC TRADERPL WebSphere Application Server ND V6.1 Apache Tomcat V5.5.20 TraderCICSSvc.ear TraderTomcatWeb.ear TraderDBSvc.ear TraderIMSSvc.ear WebSphere Services WebSphere Process WebSphere Message Registry Repository Server V6.0.2 Broker V6.0.0.2 V6.0.2 WebSphere Application WebSphere MQ V6 WebSphere Application Server ND V6.0.2.17 Server ND V6.0.2.17 TraderMQ.bar Trader*Mediation.ear *.wsdl WebSphere Application WebSphere Portal Server Server ND V6.1 V6.0 Java client WebSphere Application TraderClient.ear TraderClient.jar Server ND V6.0.2.17 TraderClientMem.ear TraderClientLck.ear TraderPortletClient1 Figure A-14 Trader application detail The detailed components are: Trader Java client (TraderClient.jar) TraderPortletClient1.war TraderClient.ear, TraderClientMem.ear, and TraderClientLck.ear194 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 CICSDevelopment 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 Description REDP4318.zip 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 applicationSystem 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 acronymsAPF Authorized Program Facility ITCAM IBM Tivoli CompositeAPI Application Programming Application Monitor Interface ITIL® Information TechnologyARM Application Response Infrastructure Library Measurement ITSO International TechnicalASM Application Service Monitor Support OrganizationBCM Byte Code Modification J2C Java 2 ConnectorCAT Client Application Tracker J2EE Java 2, Enterprise EditionCD-ROM Compact Disk - Read-Only JAR Java Archive Memory JAX-RPC Java API for XML-basedCICS Customer Information Control Remote Procedure Call System JCL Job Control LanguageCLI Command Line Interface JDBC Java Database ConnectivityCPU Central Processing Unit JES2 Job Entry Subsystem 2DASD Direct Access Storage Device JMX Java Management ExtensionEJB Enterprise JavaBeans™ JNI™ Java Native InterfaceESB Enterprise Service Bus JRE™ Java Runtime EnvironmentETE™ End-to-End JVM Java Virtual MachineFFDC First Failure Data Capture JVMPI Java Virtual Machine ProfilerFMID Function Modification Interface Identifier JVMTI Java Virtual Machine ToolGLUE Global User Exit InterfaceGUI Graphical User Interface LDAP Lightweight Directory Access ProtocolHFS Hierarchical File System MSC Multiple Systems CouplingHTML Hypertext Markup Language MVS Multiple Virtual StorageHTTP Hypertext Transfer Protocol OTMA Open Transaction ManagerHTTPS HTTP Secure AccessIBM International Business PCB Program Control Block Machine Corporation PDF Portable Document FormatIMS Information Management System PLT Program List TableIPL Initial Program Load PMI Performance Management InterfaceISM Internet Service Monitoring© Copyright IBM Corp. 2008. All rights reserved. 199
    • RACF® Resource Access Control FacilityRMI Remote Method InvocationRTE Runtime EnvironmentSCA Service Component ArchitectureSMF System Measurement FacilitySMP/E System Modification Program/ExtendedSNMP Simple Network Management ProtocolSOA Service-oriented architectureSQL Structured Query LanguageSSH Secure ShellSSL Secure Sockets LayerSSM System Service MonitorSTI Synthetic Transaction InvestigatorSYSPLEX System ComplexTCP/IP Transmission Control Protocol/Internet ProtocolTRUE Transaction User ExitTSO Time Sharing OptionUDB Universal DatabaseUML Universal Markup LanguageURI Universal Resource IdentifierURL Universal Resource LocatorWLM Workload ManagerWRM Web Response MonitorWSDL Web Services Definition LanguageXML Extensible Markup Language200 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-9508202 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-1800IBM 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-9494IBM 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-8061IBM 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-4071204 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.orgHow 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/redbooksHelp from IBM IBM Support and downloads ibm.com/support206 Managing an SOA Environment with Tivoli
    • IBM Global Servicesibm.com/services Related publications 207
    • 208 Managing an SOA Environment with Tivoli
    • Index Web Services NavigatorA flow pattern view 25application server 27archive agent 29attribute 51 G global publishing server 29Bback-end system 187 IBCM 32 IBM HTTP Server 29Byte Code Modification IMS 28, 45 See BCM TRADERBL 188 IMS data collector 40 ITCAM for Response Time TrackingC components 33CandleMonitor 46 management agent 37CICS 28, 45 management server 34 TRADERBL 188 store and forward agent 36 TRADERPL 188 Tivoli Enterprise Monitoring Agent 41CICS data collector 40 ITCAM for SOA 23client-side interception 23 action 87commands components 21 tapmagent 39 data collector 22cross-memory services 31 features 20CSMI 188 filters 87 metrics 51D server-side interception 23data collector 28 Tivoli Enterprise Monitoring Agent 22 CICS 28 viewer 22 IMS 28 workspace 20 J2EE 28 ITCAM for WebSpheredatabase connection pools 27 data collector 30DB2 UDB 29 database 30Defined View 43 managing server 28discover feature 43 JE J2EE 28EJB 27 J2EE application server 27EJB usage 27 Java API for XML-based Remote Procedure CallEnterprise JavaBeans See JAX-RPC See EJB Java Virtual Machine Tool Interface See JVMTI JAX-RPC 21–22F JAX-RPC handler 23flow pattern view© Copyright IBM Corp. 2008. All rights reserved. 209
    • JVM 37 publishing servers 29JVM thread pools 27JVMTI 26 Q queue manager 43–44K configuration event queue 44kernels 29 like-named parameters 44 node name 45 queue-sharing group 46Mmanaged system name 45 Rmanagement agent 40 Redbooks Web site 206 ARM agent 39 Contact us xi difference 37 generic window component 38 ITCAM for Response Time Tracking 37 S SCA 21, 25 J2EE instrumentation 39 server-side interception 23 mainframe 39 Service Component Architecture Quality of Service 38 See SCAmanagement server 34 service extension 23 clustered 35 Service Management Agent 20managing server 27–28 Service Management Agent Environment 20 archive agent 29 service topology view 25 global publishing server 29 service-oriented architecture kernels 29 See SOA message dispatcher 29 SET AGENT 45 publishing servers 29 SET APPL 45Mediation Configuration 20 SET CHANNEL 44message arrival 20 SET EVENTLOG 44message dispatcher 29 SET EVENTQIN 44metrics 51 SET EVENTQOUT 45monitoring file 43 SET GROUP 44 SET MANAGER 44N SET MQIMONITOR 46namelists 42 SET QACCESS 44 SET QSG 46 SET QSG command 46O SET QUEUE 44OCTIGATE database 30 Simple Network Management ProtocolOracle 29 See SNMPOS/400 monitors 44 SNMP 29 SOA 20P SOAP 21–23PERFORM INCLUDE 45 STI 38PERFORM STARTMON 45 store and forward agent 36Performance Management Interface Sun Solaris 29 See PMI Synthetic Transaction InvestigatorPMI 27 See STIprimary workspace 51210 Managing an SOA Environment with Tivoli
    • T Ztapmagent 39–40 z/OS monitors 44TRAD 188Trader BuySellServlet 185 company database 187 customer database 187 GetQuotesServlet 184 ListCompanyServlet 183 login.html 183 LogoutServlet 185 TraderClientLogin 186 TraderClientMain 186 TraderClientQuote 187TRADERBL 188TRADERPL 188transaction flows view 25UUML 25Universal Markup Language See UMLUniversal Markup Language (UML) 25UNIX 44WWeb Response Monitor See WRMWeb Services Definition Language See WSDLWeb Services Navigator 22, 24 service topology view 25 transaction flows view 25WebSphere Application Server Node Deployment35WebSphere Caching Proxy 36WebSphere Edge Server 35WebSphere MQ application 44 data 43 monitoring agent 46 object 45 OMEGAMON Monitoring Agent 44WebSphere MQ-based z/OS applications 45workspace 20WRM 39WSDL 21–22 Index 211
    • 212 Managing an SOA Environment with Tivoli
    • Back cover ®Managing an SOAEnvironment withTivoli Redpaper ™Discusses SOA Service-oriented architecture (SOA) is a major new trend forperformance and application architecture. It allows you to build applications as INTERNATIONALavailability components as defined using a Web Services Description Language TECHNICALmanagement (WSDL) file. You can implement applications in different servers, SUPPORT even different platforms. You can modify application components ORGANIZATIONDescribes mediation and workflow logic easily in execution, allowing a flexible application structure. Implementation of the client and the serverscenarios with ESB side is also masked by the use of enterprise service bus, whichand message broker allows a different server implementation to be provided without the BUILDING TECHNICAL need to modify the client, or, different clients can use the same INFORMATION BASED ONIntegrates ITCAM PRACTICAL EXPERIENCE server implementation.and other Tivoli The highly flexible and distributed nature of SOA-based applicationssolutions IBM Redbooks are developed by is its primary strength and the source of its appeal. However, when the IBM International Technical a problem arises, this flexible nature also causes a greater problem Support Organization. Experts in pinpointing the source of problem. SOA also requires a from IBM, Customers and disciplined management effort to ensure that operational changes Partners from around the world do not disrupt overall availability. create timely technical information based on realistic The IBM Tivoli Composite Application Manager (ITCAM) family of scenarios. Specific products directly assists services specialists who implement and recommendations are provided manage distributed applications. We illustrate the management to help you implement IT needs for SOA-based applications and demonstrate how Tivoli solutions more effectively in your environment. 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. For more information: ibm.com/redbooks REDP-4318-00