Managing An SOA Environment With Tivoli Redp4318

Front cover
Managing an SOA Environment with Tivoli

Discusses SOA performance and availability management Describes mediation scenarios with ESB and message broker Integrates ITCAM and other Tivoli solutions
Budi Darmawan Pradeep Nambiar Prem Lall Ravinder Gummadavelli
ibm.com/redbooks
Redpaper
International Technical Support Organization Managing an SOA Environment with Tivoli April 2008
REDP-4318-00
Note: Before using this information and the product it supports, read the information in Notices on page vii.
First Edition (April 2008) This edition applies to:

IBM Tivoli Composite Application Manager for WebSphere V6.1, 5724-L62 IBM Tivoli Composite Application Manager for Web Resources V6.2, 5724-S32 IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 FP2, 5724-L99 IBM Tivoli Composite Application Manager for Response Time V6.2, 5724-C04 IBM Tivoli Composite Application Manager for SOA V6.1 FP2, 5724-M07 IBM Tivoli OMEGAMON XE for Messaging V6.1 WebSphere Enterprise Service Bus and WebSphere Process Server V6.1 WebSphere Message Broker V6.0 WebSphere Services Registry and Repository V6.0.2
Copyright International Business Machines Corporation 2008. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this paper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Chapter 1. Introduction to SOA management. . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Introduction to SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 SOA application principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 SOA constructs and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 SOA governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.1 Web Services life cycle governance . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.2 Web Services life cycle management . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 SOA management considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6 Users of SOA management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.6.1 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.6.2 Middleware or application subject matter expert . . . . . . . . . . . . . . . . 11 1.6.3 Performance analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.6.4 System administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.6.5 Enterprise system management architect . . . . . . . . . . . . . . . . . . . . . 14 1.6.6 Web Services application developer . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.6.7 Business executives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.7 Management needs for the SOA environment . . . . . . . . . . . . . . . . . . . . . 16 1.7.1 Web Services metric data collection . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.7.2 Web Services troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.7.3 Displaying data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.7.4 Mediation management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Chapter 2. Tivoli application management products . . . . . . . . . . . . . . . . . 19 2.1 ITCAM for SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.1 Product features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.2 Product components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 ITCAM for WebSphere and ITCAM for J2EE . . . . . . . . . . . . . . . . . . . . . . 26 2.2.1 Architecture and interconnection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.2 The managing server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3 J2EE and WebSphere data collectors . . . . . . . . . . . . . . . . . . . . . . . 30 2.2.4 Tivoli Enterprise Monitoring Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Copyright IBM Corp. 2008. All rights reserved.
iii
2.3 ITCAM for Response Time Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.1 The management server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3.2 Store and forward agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.3.3 Management agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3.4 Tivoli Enterprise Monitoring Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.4 OMEGAMON XE for Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.4.1 WebSphere MQ configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.4.2 WebSphere MQ monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4.3 WebSphere Message Broker monitoring . . . . . . . . . . . . . . . . . . . . . 46 Chapter 3. Basic SOA and Web Services management. . . . . . . . . . . . . . . 49 3.1 Basic monitoring concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.2 Performance metric of Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3 Generating events and alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.4 Managing Web Services response time . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.4.1 Execution environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.4.2 Creating Rational Performance Tester script . . . . . . . . . . . . . . . . . . 56 3.4.3 Defining Web Response Monitor policies . . . . . . . . . . . . . . . . . . . . . 59 3.4.4 Reports generated from the policies . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.4.5 Tivoli Enterprise Portal workspaces . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.5 Debugging performance of Web Services. . . . . . . . . . . . . . . . . . . . . . . . . 69 3.6 Understanding Web Services calling pattern . . . . . . . . . . . . . . . . . . . . . . 74 3.6.1 Turning on the content logging for a Web Service . . . . . . . . . . . . . . 74 3.6.2 Using the Log Assembler tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.7 Working with Web Services filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.8 Web Services life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Chapter 4. Advanced SOA management . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.1 Mediation and SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.2 Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.3 Maintaining Web Services continuity. . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.3.1 Register TraderDBServices in the registry . . . . . . . . . . . . . . . . . . . 106 4.3.2 Developing managed SCA mediation with ITCAM for SOA . . . . . . 110 4.3.3 Deploying the mediation application . . . . . . . . . . . . . . . . . . . . . . . . 126 4.3.4 Verifying the service invocation with mediation. . . . . . . . . . . . . . . . 132 4.4 Service monitoring automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 4.4.1 Automation principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 4.4.2 Update service metadata utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 4.4.3 ITCAM for WebSphere and ITCAM for Web Resources situations. 139 4.4.4 ITCAM for SOA situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.4.5 Verifying situation automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 4.5 Using managed message logger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 4.5.1 Viewing the message data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
iv
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Chapter 5. Managing an SOA application in a business context . . . . . . 159 5.1 Solution overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 5.2 Tivoli EIF probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 5.3 Defining situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 5.4 Designing business services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 5.5 Defining service level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 5.6 Getting the business status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Appendix A. The Trader application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Portal interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Front-end J2EE Web application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Java desktop application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Back-end implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Back-end J2EE servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 WebSphere Enterprise Service Bus mediation . . . . . . . . . . . . . . . . . . . . . 190 WebSphere Message Broker mediation . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Runtime environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Appendix B. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 System requirements for downloading the Web material . . . . . . . . . . . . . 198 How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Contents
vi
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
vii
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks (logo) z/OS Alerts AIX Cloudscape CICS DataPower DB2 ETE IBM IMS MQSeries MVS OMEGAMON OS/400 Rational Redbooks RACF Tivoli Enterprise Console Tivoli WebSphere
The following terms are trademarks of other companies: SAP NetWeaver, SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries. Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or its affiliates. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. Enterprise JavaBeans, EJB, Java, JavaBeans, JDBC, JMX, JNI, JRE, JVM, J2EE, Solaris, Sun, Sun Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Internet Explorer, Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
viii
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.
ix
Budi Darmawan is a project leader at the International Technical Support Organization, Austin Center. He writes extensively and teaches IBM classes worldwide on all areas of Tivoli and systems management. Before joining the ITSO eight years ago, Budi worked in IBM Indonesia services as a technical lead and solution architect. His current interests are Java programming, availability management, business service management, and z/OS management. Pradeep Nambiar is a Worldwide Technical Evangelist in the IBM Tivoli Business Automation Sales Enablement group. He has over 19 years experience in the IT industry in various areas ranging from graphics systems, networked graphics, IBM Component Broker/WebSphere Application Server system management, business application architecture, design, and development. He is an IBM Certified SOA Solution Designer, IBM Certified WebSphere Enterprise Developer, and IBM Certified Solution Developer in XML and Related Technologies. His current focus is on application management and the automation family of products, including SOA management from IBM Tivoli. He is based in Austin, TX. Prem Lall is a Software Engineer currently assigned to the ITCAM for SOA project where he specializes in the field of Web Services management. He has had over 15 years experience in the IT field. During his 11 years at IBM, he has helped design and implement a variety of software products. He has expertise in front-end, middleware, and back-end development with an emphasis on e-commerce. Among other things, he created end-to-end online banking solutions for IBM clients in the Integrion consortium, he has been part of the WebSphere Application Server development team, and helped create an extensive SOA-based e-File application for the IRS that is currently used by numerous businesses across the country. He holds a Masters of Science Degree in Pure and Applied Mathematics from California State University, Northridge, CA. He also worked as an Actuary, and he has worked in the Atmospheric Physics Division of the NASA Goddard Space Flight Center. Ravinder Gummadavelli is a Software Engineer with IBM Systems Technology Group, in the USA. He has over 10 years of experience in the IT Systems Design and Development field. He holds a Masters in Technology degree in Electrical Engineering from REC, Warangal, India, and a Masters of Science degree in Electrical Engineering from Auburn University, Auburn, AL. His areas of expertise include Systems Design, Development, and SOA. His current interests include SOA and IBM Virtualization offerings. Thanks to the following people for their contributions to this project: Karen Durston, Mark Anderson, Jayne Regan IBM Software Group
Become a published author

Join us for a two- to six-week residency program! Help write a book dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You will have the opportunity to team with IBM technical professionals, IBM Business Partners, and Clients. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you will develop a network of contacts in IBM development labs and increase your productivity and marketability. Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us! We want our papers to be as helpful as possible. Send us your comments about this paper or other IBM Redbooks publications in one of the following ways: Use the online Contact us review IBM Redbooks publications form found at: ibm.com/redbooks Send your comments in an e-mail to: redbooks@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400
Preface
xi
xii
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
1.1 Introduction to SOA

A service-oriented architecture (SOA) is an architecture that describes a system that is composed of discrete services that interact with clients and accomplish various tasks. Each service contains operations that perform a small unit of work that corresponds to a high level definition of a given task. These services can perform simple tasks, such as accessing data from a database and returning data to a client, or can be part of a workflow that represents a more complex task. A service usually either provides information or facilitates a way to modify it in a certain way. Although Web Services technology is commonly used to implement an SOA, it is not required; in other words, a service does not have to use Web Services constructs or technology. However, most SOAs rely on the standards, practices, and tools that are available with Web Services. Regard SOA as an approach to build distributed systems that deliver application functionality as Web Services to user applications. Properly used, SOA principles can provide a framework for matching business needs with realistic solutions. Web Services is the programmatical interface to a capability that complies with standard protocols, providing the interface technology and delivering platform independency and loose coupling of the transport. SOA is potentially wider in its scope of governing the policies, rules, and common services that enable logical service bus structure for use by authorized consumers internal and external to the enterprise regardless of implementation technology. Also, SOA enables the design and quality of service that can be reused and that conforms to functional and nonfunctional service level agreements (SLAs). Web Services are the foundational interoperability technology, and SOA is the application of the interoperability that implies considerable change in business and IT practices. This magnitude of business and technology change requires a certain level of management in order to successfully reap the benefits from the investment that has been made for the change. In this chapter, we look into the SOA structure and the management requirements that lead to the need for this paper to define the SOA system management environment.
1.2 SOA application principles

You can deploy an SOA-based application incrementally and slowly integrate it into an existing environment. Developers have designed SOA scenarios to be
used together or adopted incrementally. There are several well-known SOA patterns, including: Service creation Service connectivity Interaction and collaboration services Business Process Management Information as a service You can apply the SOA design, governance, security, and management across all of these scenarios. Applications in a typical silo architecture build their functionality on top of an existing application stack. In an SOA-based environment, the logical boundary between Web Services consumer and provider is defined by a business function, not by application boundaries (typical for silo architectures): Separation of Web Services interface from its implementation One of the most important aspects of SOA is that it separates a Web Services implementation from its interface. A meta-language, such as Web Services Definition Language (WSDL), can be very helpful, because it describes a business interface that a Web Services provider can expose to a client application and other Web Services while concealing the Web Services implementation. A WSDL document acts as a server-side descriptor that defines the Web Services operations and the messages they use so the client will know how to invoke the Web Service. Web Services consumers view a Web Services simply as an endpoint that supports a particular request format or contract. Web Services consumers are not concerned with how the Web Services executes their requests; they only expect that it will do so according to the defined interface. Implementations can use anything from Java 2 Platform, Enterprise Edition (J2EE) entities to older code running in a mainframe environment. Loose coupling The exposed interface is purposely loosely coupled from the Web Services provider so that implementations can be modified or even replaced (swapped in and out as desired in a plug and play manner), which increases the ability to reuse existing function. Reuse promotes increased performance, reliability, and Quality of Service (QoS), because a common interface can be exposed to many clients regardless of what is underneath. Reusable components do not have to be retested as often as well. Individual Web Services are also loosely coupled, having little or no dependencies upon each other. Web Services must also be stateless (information or state are not preserved from one request to another).
Chapter 1. Introduction to SOA management
Business impact Client applications in an SOA do not contain business logic; they consume Web Services instead. Therefore, they become much smaller and easier to implement. A shorter time-to-market for new products is an important result for business development. SOA principles in general can help form a stronger connection between the business needs that define the architecture and the software and information systems that implement it. Web Services can be created according to an abstract model that conforms to the needs of the business. If done correctly, an abstraction can drive the concrete very effectively.
1.3 SOA constructs and components

Standards have been developed to ensure Web Services technologies conform to common principles. Support for Web Services interoperability, Web Services security, sending attachments using Web Services, and Web Services Management have been defined by organizations, such as W3C, OASIS, and so on. Standards help ensure that Web Services products sold by different software vendors conform to common agreed upon expectations. For example, a user must be able to expect that a Web Services client written using Microsoft .Net can invoke a Web Services written using Apache Axis deployed on the WebSphere Application Server without any complications if these tools conform to Web Services standards. With the advent of application server technology, Web Services can be distributed across many machines and environments, making it easier to perform scalability, clustering, and load balancing across your enterprise (SOA can ease the transition away from existing systems towards modern application servers and middleware). For example, COBOL and C++ applications that use messaging software, such as IBM MQSeries, can be phased out in favor of Java applications that use SOAP/Java Message Service (JMS) and message-driven beans (MDBs). SOA-related constructs, such as enterprise service buses (ESBs), business processes, and so on, can add further structure and flexibility to your architecture by providing routing, mediation, and flow management functions. Just as you can hide implementations from a client, transport/protocol layers and message formats can be similarly concealed by the inclusion of an enterprise service bus. SOAP/Java Message Service (JMS), SOAP/HTTP, Remote Method Invocation (RMI)/Internet Inter-ORB Protocol (IIOP), XML/MQSeries, local Java calls, and so on are all supported and transparent to the user. Often, people implement an enterprise service bus by technologies that are found in certain
middleware/infrastructure products, for example, WebSphere Enterprise Service Bus, DataPower, WebSphere Message Broker, and so on. You can combine discrete Web Services into composite business processes to accomplish more complex business objectives. As part of a business process, individual Web Services can be viewed as activities within a workflow. This facilitates the creation of a business process that can be described by a meta-language called Business Process Execution Language (BPEL). Business Process Execution Language is similar to Web Services Definition Language (WSDL) in that it provides a static definition of a Business Process. Just as with Web Services, the potential for reuse is quite high after these Business Process definitions are created. In recent years, a new method has been introduced to model Web Services in an SOA called the Service Component Architecture (SCA). SCA components are designed to separate implementation details from any business logic so that you can put together an integrated application without knowing its implementation details and make each component interoperate with any other SCA component. Issues, such as security, transactions, and so forth, are resolved in a seamless manner across SCA components. SCA components are often used in business process modeling, because they provide a great deal of flexibility. A mediation is a special type of SCA module. You can insert mediations between loosely coupled Web Services. Introducing mediations between Web Services provides added function for processing messages that are being passed between these Web Services. Mediations intercept and modify messages that are passed between existing Web Services and clients that want to use those Web Services. Mediations are ideal for deployment in an environment that contains an enterprise service bus, because they can reroute and examine Web Services traffic.
1.4 SOA governance

It is important to consider both governance and management requirements when planning an SOA.
SOA governance is an extension of IT governance that focuses on the life cycle of Web Services and composite applications in an organizations SOA. SOA governance is related to establishing policies within the context of the activities and constructs associated with SOA that are similar to those that exist for managing and controlling other aspects of IT.
Initially, the concept of SOA governance was applied narrowly to the development and use of Web Services (validating Web Services adherence with specific standards or managing Web Services in the SOA runtime environment). Today, SOA governance spans SOA architecture, as well as the governance of Web Services, across the entire implementation life cycle. Architecture governance and Web Services-level life cycle governance are the two of the main components of SOA governance. For the purposes of this discussion, we will concentrate mainly on the latter.
1.4.1 Web Services life cycle governance

The goal of Web Services life cycle governance is to define: Decision rights for the development, deployment, and management of new Web Services Monitoring and reporting processes for capturing and communicating governance results There are four phases of the Web Services life cycle: Modeling: This phase involves incorporating business requirements and objectives into your business design so that the design becomes a specification of business processes that achieve goals and consider assumptions. Assembly: This phase centers around the information systems that will be used to assemble the business design. Typically, an enterprise architect working with a business analyst can convert the business design into a set of business process definitions that are composed of activities. The required Web Services are derived from the activity definitions and business processes from the business process definitions. Deployment: This phase involves creating the environment that will host composite Web Service-based applications and then deploying those applications there. This phase includes identifying resource dependencies for the application, as well as operational conditions, requirements, and constraints that impact the successful deployment and running of the applications. Management: This phase addresses the maintenance of the operational environment and the policies that govern the deployed applications. This phase includes monitoring the performance of Web Services requests and responses and developing a recovery strategy for failures (detecting and quarantining failures and logging them, rerouting traffic around failures and recovering work affected by them, correcting problems and restoring the state
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.
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.
These metrics include: Service response time Service request message size Service faults Real-time service performance metrics Application server health where the service is deployed Health of dependent components, such as database, messaging resources, and so on Service performance metrics for historical purposes Service request and response message data These metrics help measure service level agreements (SLAs) for applications. You can use these metrics to debug performance bottlenecks in applications. You can also use these metrics to automatically take corrective actions or initiate failover steps to maintain service availability when the primary service provider goes down or is not performing to meet the SLAs. IBM Tivoli Composite Application Manager (ITCAM) for SOA and other ITCAM offerings provide all the necessary metrics to keep the applications in an SOA environment healthy and resilient.
1.6 Users of SOA management

There are several types of users that use SOA management and need to interact with the SOA-based environment. In this section, we discuss the access patterns and the needs of those users in relation to SOA management. With any management software, a number of various personnel can be potential users. You can have multiple user roles, and each role can be defined in part by the users current job responsibilities. For example, an application developer and a performance tester most likely are interested in viewing varying pieces of information at different times and thus might use the same console to view different information. Depending on their responsibilities, they might even have different levels of access to various views. Ultimately, the roles and responsibilities that are defined for various users will depend greatly on how a company defines their architecture and how they want to manage it.
These are possible user roles for SOA management. The primary users are likely to be common to most organizations. There can also be secondary and provisional users as well: Note: We consider the user roles for managing the performance and the availability of an SOA-based application. We do not include security management and its roles in this paper. Primary users: These users are the most common in most organizations. They have a critical need to use the SOA management tools for their day-to-day jobs: Operator Middleware and application subject matter expert Secondary users: These users have supportive roles that require occasional access to the SOA management tools. Although the tools are not a necessity for them to perform their work, the tools greatly enhance their productivity: Performance analyst System administrator Web Services application developer Provisional users: These users also need access to SOA management only as the need arises. These roles use SOA management rarely, and the tools do not perform a critical role: Enterprise system management architect Business manager or executive
1.6.1 Operator
An operator or system operator is the first level of IT support personnel that might detect system, application, or performance problems. The operator or system operator job is directly related to ensuring the health of the IT environment and attaining the appropriate service level for IT operation. The primary interaction for an operator with the SOA management environment relates to: Monitoring for potential problems and correcting them Ensuring that they adhere to the system SLA Providing initial troubleshooting of a problem, and, if possible, fixing it Escalating a problem to the next level of support or subject matter expert for resolution if necessary
10
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
11
application beyond just the SOA interface and into the component level or a breakdown of the transaction. Subject matter experts on the application or the middleware perform these in-depth diagnostics from several sources, such as: Investigating the Web Services flow from one application server to another Rerouting and modifying mediation and the Web Services flow Collecting response time breakdowns using correlation tracking Performing a method trace for the J2EE application The subject matter experts on an application or the middleware perform these functions by using a combination of ITCAM solutions, such as: ITCAM for SOA ITCAM for WebSphere and ITCAM for J2EE ITCAM for Response Time Tracking
1.6.3 Performance analyst

A performance analyst inspects reports about availability and response time for various applications, including applications deployed in an SOA environment. If the metrics indicate that a threshold is close to being reached, the performance analyst consults a trend analysis of how the application has been performing over time. The conclusion can indicate a sudden spike in activity or a increasing trend over time, which might mean you need to expand your capacity. The performance analyst collects this information from various data sources from the monitoring system historical data. The Tivoli solution in the IBM Tivoli Monitoring environment is based on Tivoli Data Warehouse. The Tivoli Data Warehouse collects historical data from various Tivoli Enterprise Monitoring Agents. This data can be reported and analyzed by using the reporting tools that report into a DB2 database.
1.6.4 System administrator

The system administrator is a user with administrative privileges that performs the day-to-day tasks of maintaining the management system. The system administrator tasks include granting access to users, implementing a monitoring solution, extending the monitoring solution by using a standard procedure, and so on.
12
The system administrator has the authority to modify the system, such as installing a new feature or a patch to the monitoring system, thus, allowing interaction with the management of the SOA solution. The system administrator can install, configure, and maintain all the tools that a subject matter expert needs. A system administrator can also configure, start, and stop agent processes, or perhaps even reconfigure the entire monitoring environment. System administrator interactions include: Managing situations, workspaces, and actions in Tivoli Enterprise Portal that are related to the SOA application Administering users, such as Tivoli Enterprise Portal users. Using the Administer Users window for setting authorities to specific features, specifying access to applications, and specifying access to Navigator views. Selecting the features in Tivoli Enterprise Portal to provide access to each user and to set the specific permissions granted to each user (see Figure 1-2 on page 14)
13
Figure 1-2 Administer user dialog
1.6.5 Enterprise system management architect

The system management architect interacts with the business side of the company and is familiar with the companys business processes. An architect must understand the model for the SOA-based application, including Web Services, SCA, and business process choreography to model the architecture of the business. The architect observes as the model is built and then implemented into system management. The architect must oversee the system management implementation based on the business model and ensure that the management model is kept up-to-date. The architect must review the rollout of the new application and the change of the mediation rule to ensure that the monitoring model is still current and meaningful.
14
The architect utilizes the WebSphere Services Registry and Repository to manage the Web Services life cycle and can use the discovery through Tivoli Common Object Repository to monitor new services and the new model. You can do this by displaying the ITCAM for SOA Services Overview view to see the difference between which Web Services have been observed and which Web Services are registered. If you notice that certain observed Web Services are not registered, then you can update the registry.
1.6.6 Web Services application developer

The application developers are responsible for coding Web Services applications. After the developers Web Services are deployed, the developers must be available to fix problems. Depending on the severity of the problem, the developers usually have a small amount of time in which to complete the fix, and then they run tests to verify that the problem has been resolved. A typical scenario is a new mediation that needs to be added to manage traffic for an existing Web Service, because the system performance has been unexpectedly affected. The system management tools can assist the developer to identify the potential bottlenecks and performance problems in test system. The developers need to use the tools to test fixes for possible performance bottlenecks before the fixes go into production. After the build with the fix is installed, the developers observe whether the performance problem has been alleviated.
1.6.7 Business executives

The business executives care about their business processes and the applications that support the business. The management solution must allow the business executives to see the application health based on either the SOA performance or another metric. The business executives need an interface with minimum technical detail. The business executives need a simple but meaningful view of the business process health and possibly the SLA attainment.
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 Services life cycle (see section on 1.4.2, Web Services life cycle management on page 7).
1.7.1 Web Services metric data collection

You can collect metrics throughout the life of a Web Service. These metrics are usually numeric information that you can use to indicate or calculate the health and performance of Web Services. You can collect these metrics by using a polling process or instrumenting the application to report the metrics. Metrics that are collected at the Web Services operation level include average response time, average message size, number of messages, number of faults,
16
and so on. The metrics can provide valuable information about SOA and Web Services. You need to be able to view real-time data, as well as historical data, corresponding to a specific time interval. You can collect metric data by using a management API, such as Java API for XML-Remote Procedure Call (JAX-RPC) handlers, which make Web Services into manageable resources. Data collection using the JAX-RPC handler happens when when either of the following events occurs: A client application invokes a Web service, which is referred to as a
client-side interception.
The Web Services request is received by the hosting application server, which is referred to as a server-side interception. The data can be stored in log files for later analysis, sent to a management server, or loaded into a repository.
1.7.2 Web Services troubleshooting

Troubleshooting Web Services includes monitoring the health of the infrastructure that supports the Web Services, such as the underlying middleware. Think of Web Services as manageable resources in the system management environment. In this way, you can determine whether policies are being enforced in SOA and whether SLAs are achieved or not. Data on throughput, availability, workload, transactions, and so on can be gathered to help you determine if your current topology is optimal, given the demands placed on your enterprise. Business processes are managed indirectly in that the Web Services that make up the business processes are managed resources. You might also consider a SOA management standard, such as Web Services Distributed Management (WSDM) from Oasis. See: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
1.7.3 Displaying data

You must be able to display Web Services entities, such as the deployed server, operation, namespace, relationship, and other attributes, to users. You can present this information in a tabular or graphical form, and you need to provide drill-down capability for the user to see details about the Web Service. A user must also be able to define events and alerts to monitor an SOA application. These alerts allows users to be notified when a certain condition
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
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
19
2.1 ITCAM for SOA

in this section, we describe IBM Tivoli Composite Application Manager (ITCAM) for SOA V6.1. We discuss: Product features on page 20 Product components on page 21
2.1.1 Product features

ITCAM for SOA manages service-oriented architecture (SOA). It can monitor, manage, and control the Web Services layer of the IT architecture, while drilling down to the application or resource layer to identify the source of bottlenecks or failures and to pinpoint services that take the most time or use the most resources. ITCAM for SOA: Provides service monitoring views in Tivoli Enterprise Portal. ITCAM for SOA workspaces consist of data collector-based workspaces: Performance Summary: Shows the response time information for Web Services calls as viewed from the client or the server Message Summary: Shows the message statistics, including the volume and size of message information Fault Summary: Shows failure analysis for Web Services calls Other workspaces for each agent are: Service Management Agent Environment: Provides a summary of the Web Services metrics for all data collectors Service Management Agent: Shows the agent configuration summary, data collectors, monitoring profiles, and filters Mediation Configuration: Shows configuration entries for mediation on Service Component Architecture (SCA) Message arrival: Shows the message arrival rate and events based on the message arrival critical situation Leverages Tivoli Enterprise Portal situations to check thresholds. ITCAM for SOA provides predefined situations that you need to tailor. The predefined situations concern: Number of messages received by a service within a time window Size of the messages Provides basic mediation support with the ability to filter or reject Web Services call messages from a particular client or service. It can log request and response messages for analysis.
20
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
ITCAM for SOA Monitoring agent Application Server Web Services Data handler or collector extension log
configuration Data collector adapter Tivoli Enterprise Monitoring Agent
Tivoli Enterprise Management Server
Tivoli Enterprise Portal Server
Figure 2-1 ITCAM for SOA structure
The monitoring agent data collector is implemented as a JAX-RPC handler or service extension that is installed into the application servers that host the monitored Web Services. The handler is given control when either of the following events occurs: A client application invokes a Web service, which is referred to as a
client-side interception.
The Web Services request is received by the hosting application server, which is referred to as a server-side interception. The monitoring agent records and collects monitored information into one or more local log files. The information is then transferred to Tivoli Enterprise Monitoring Server and can be archived into a historical database for later retrieval with IBM Web Services Navigator. ITCAM for SOA V6.1 focuses on the SOAP engine of IBM WebSphere Application Server, WebSphere Service Integration Bus, Microsoft .NET Framework, and BEA WebLogic. The Web Services data collector supports both Java 2 Platform, Enterprise Edition (J2EE) application client and server container environments, because JAX-RPC handlers are supported only by these environments. The Web Services must be compliant with JSR-109 specifications. To ensure the proper operation of the JAX-RPC handler, verify that the client applications are written according to the conventions at the following location: http://www.jcp.org/aboutJava/communityprocess/final/jsr109/
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
Tivoli Enterprise Monitoring Agent
Web Services Navigator
Log Assembler Combined metric log
Figure 2-2 Web Services Navigator
The Web Services Navigator is a log-browsing tool intended for offline analysis of SOA Web Services. The Web Services Navigator provides four primary views: Statistic tables: Message statistics Per-message statistics, including requestor, provider, send/receive time, and message size Invocation statistics Response time, network delay, message size, and more for each Web Services invocation Transaction statistics Statistics for aggregated transactions, including elapsed time, number of faults, number of machines that this transaction involves, and number of invocations comprising this transaction
24
Pattern invocation statistics Statistics for discovered patterns, including operation names, number of occurrences, response times, and message sizes Note: To see the message content from the ITCAM for SOA metric log: 1. Set a monitor control higher than none for any or all of the Web Services being monitored. 2. Include the subsequent xxxx.content.log when running Log Assembler. Service topology view This view is a graphical representation of the monitored Web Services that displays aggregated information and details about the relationships between Web Services. Transaction flows view The transaction flows view displays Universal Markup Language (UML) style sequence diagrams. The transaction flow shows a chronological view of each transaction, the flow between the various Web Services over time, and the topology and statistics for each transaction. You can zoom in on the view to see the details of individual transactions. Flow pattern view The flow pattern view is a visual representation of the aggregated pattern of transactions represented in the log file. The view also represents each pattern as a distinct sequence of Web Services calls and displays the frequency of each pattern.
Managing SCA mediation

WebSphere Process Server and WebSphere Enterprise Service Bus introduce a new way to model services in an SOA, which is called the Service Component Architecture (SCA). SCA is designed to separate business logic from its implementation so that you can focus on assembling an integrated application without knowing implementation details. There is a special type of SCA component, which is called a mediation. In an SOA, where services are loosely coupled rather than connected directly to each other, mediations can be inserted between the services, where they can intercept and process messages that are passed between the services. Mediations can process these messages and take appropriate actions, such as reroute, log, or transform a message, or create a notification or an event. IBM Tivoli Composite Application Manager for SOA provides the ability to dynamically enable and disable the deployed mediation functions. This facility is
25
available for applications in the WebSphere Enterprise Service Bus or WebSphere Process Server runtime environment. The invocation is provided in a new workspace in Tivoli Enterprise Portal called the Mediation Configuration workspace. The actions are: ConfigureMediation_610 DeletePrimitiveProperty_610
2.2 ITCAM for WebSphere and ITCAM for J2EE

The IBM Tivoli application management solution for J2EE application servers comes in the form of ITCAM for WebSphere and ITCAM for J2EE. These two products share the same managing server. ITCAM for WebSphere and ITCAM for J2EE observe and report on the health of J2EE-based applications. They track the progress of applications as they traverse through J2EE application servers, middleware adapters and transports, and database calls, and on to back-end systems, such as CICS or IMS, to extract business data or to invoke mainframe business processes. Tracking applications produces request traces, where the events in a requests 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 applications parts that deserve attention for runtime improvement studies and code optimizations. ITCAM for WebSphere manages and monitors WebSphere-based application servers, while ITCAM for J2EE manages and monitors the following J2EE containers: JBoss Tomcat SAP NetWeaver BEA WebLogic Server Oracle Application Server Apache Web Server Sun Java System Web Server Microsoft IIS WebSphere Application Server CE ITCAM for WebSphere and ITCAM for J2EE do not need modification of any J2EE or mainframe application code. The data collectors use the following principal data sources: Java Virtual Machine Tool Interface (JVMTI) interfaces
26
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.
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
Application servers with Data collectors
e ris nt rp te ge Tivoli Enterprise En ng A li i Management Server vo or Ti onit M and
Tivoli Enterprise Portal Server
Web Servers
Figure 2-3 ITCAM for WebSphere and ITCAM for J2EE architecture
The application monitor consists of two major parts: the managing server and the data collectors. A data collector agent runs on each monitored application server, whether J2EE, CICS, or IMS, and communicates essential operational data to the managing server. Unique sampling algorithms maintain low CPU and network processing while providing application-specific performance information. The managing server consists of several Java-based components that provide the environment to collect and present management data.
2.2.2 The managing server

ITCAM for WebSphere and ITCAM for J2EE use one common managing server that controls and coordinates data collectors for J2EE, CICS, and IMS servers
28
that run applications. The difference between ITCAM for J2EE and ITCAM for WebSphere is the platform support for the data collectors. These data collectors can run independently. The managing server uses the following software: Managing server database (DB2 UDB or Oracle on Sun Solaris) for the relational data repository WebSphere Application Server to run the visualization engine Web console application An optional Web server, such as IBM HTTP Server The managing server overseer components, which are a set of Java-based processes The overseer components are the controlling logic for the managing server. For the overseer components:
Kernels control the managing server. There are always two copies of the
kernels running on an ITCAM for WebSphere and ITCAM for J2EE managing server for redundancy and failover. The kernels register components as they join the managing server, periodically renew connections and registrations with components and data collectors, and collect server and component availability information.
Publishing servers receive application and system event data from the data collectors, gather and compute request-level information about performance metrics such as response times, and implement the trap monitoring and alerts features. Archive agents receive monitoring data from the publish servers and store the
monitoring data in the repositories of ITCAM for WebSphere and ITCAM for J2EE. The global publishing server collects information from the publish servers and correlates all parts and pieces of multiserver requests, such as requests from J2EE servers to execute CICS or IMS programs. The message dispatcher is a conduit for messages from ITCAM for WebSphere and ITCAM for J2EE using e-mail and Simple Network Management Protocol (SNMP) facilities.
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
Global Publish Server (SAM)
Publish Server (PS) Message Dispatcher (MD) Archive Agent (AA)
Publish traffic
Kernel (KL)
Provide services on: - Lookup - Registration - Recovery - Configuration
Visualization Engine
Provide services on: -Administration -Availability -Problem Determination -Performance Management
OCTIGATE
database
Figure 2-4 Kernel components
At the managing server, monitoring data is prepared for real-time displays within the monitoring console and is inserted into the OCTIGATE data repository. These are extremely resource-intensive operations. Having this processing in the managing server isolates this from other the application servers, thus reducing the footprints of ITCAM for WebSphere and ITCAM for J2EE in the monitored systems. This design also helps keep the data collectors processing at levels low enough for 24x7 production system monitoring. Data from the data collectors is collected by the publishing server and then stored in the OCTIGATE database by the archive agent. The visualization engine reads the database to present data through the Web console, and snapshot information, such as lock analysis and in-flight transactions, is retrieved directly from the data collectors.
2.2.3 J2EE and WebSphere data collectors

The data collectors run inside the application servers. They use native system services, and they are tailored for the particular environments where they
30
execute. The data collectors for z/OS systems are written to take advantage of services on z/OS, such as MVS Cross-Memory Services and address space fencing, which are not available on distributed systems. Data collectors are configured as a multithreaded process. They consist of the following agents: Command agent The command agent collects requests from other components for information about Enterprise Java Bean (EJB) invocations, database connection pools, thread pools, stack traces, memory analyses, and heap dumps. Event agent The event agent provides data to the publish servers according to polling frequencies. This data includes system initialization data, application request-level data, and application method-level data. Secondary collector The optional secondary collector provides support for displaying data in Tivoli Enterprise Portal for collecting WebSphere Application Server and other J2EE application server performance metrics. This component communicates with Tivoli Enterprise Monitoring Agent using a TCP/IP port. Collectively, these agents and other data collector routines unleash the probes, package the monitoring data into Java formats for the managing server, and deliver the data to the managing server. The data collectors send the probes into the application servers to analyze the applications performance. The probes collect monitoring data and feed it to transport routines that in turn route the data to the managing server. The managing server processes it for display in the Web console and for storage in the OCTIGATE repository, which relieves the processing burden of ITCAM for WebSphere and ITCAM for J2EE from the application servers as much as possible. The data collectors and probes are not designed to analyze or interpret data, but to collect it and route it as quickly as possible to the managing server where the analysis is performed. The data sources that are employed by ITCAM for WebSphere and ITCAM for J2EE are: Java Virtual Machine Tools Interface (JVMTI) garbage collection data, method trace, stack trace, CPU time, and heap dump Java Management Extensions (JMX) system resources System Management Facilities (SMF) system resources (z/OS only) PMI system resources (WebSphere only)
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
bcm
Custom Service am
Publish data
KYN
To TEMS
Figure 2-5 J2EE data collector structure
2.2.4 Tivoli Enterprise Monitoring Agent

The ITCAM for WebSphere and ITCAM for J2EE Tivoli Enterprise Monitoring Agent can forward monitoring information to Tivoli Enterprise Monitoring Server for monitoring using Tivoli Enterprise Portal. There is an additional component at Version 6.1, Tivoli Enterprise Monitoring Agent for Web Servers. Web server monitoring no longer uses the managing servers 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
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.
FIREWALL
Tivoli Enterprise Management Agent
RTT management agent
FIREWALL
RTT Management server
RTT Store and forward agent
RTT Store and forward agent
Figure 2-6 ITCAM for Response Time Tracking components
Basically, ITCAM for Response Time Tracking is controlled from the management server. The management server provides a centralized repository of policy, configuration, and data for the ITCAM for Response Time Tracking environment. The rest of ITCAM for Response Time Tracking consists of the management agents. The management agents perform performance and response-time data collection on behalf of the management server. The agent can perform response time collection from an application server or perform robotic simulation of a transaction for measuring response time. The management agent functions as a single agent that can have different monitoring components deployed on it to perform various functions. The management server and management agent typically operate in an unrestricted port environment. When there is a firewall between them, they restrict the port usage to communicate. The firewall requirement typically requests that they use a single communication port to talk back and forth. This is where the store and forward agent comes in. It bundles the management
33
communication between the management server and management agent to use a single port to pass through the firewall. The store and forward agent can be cascaded, so in this sense, there can be a chain of store and forward agents to pass through multiple layers of firewalls. A special management agent resides on z/OS machines. The management agent on z/OS machines has the transaction server component activated to receive performance information from the CICS and IMS data collector. In ITCAM for Response Time Tracking V6.1, information from the management server can be forwarded to Tivoli Enterprise Monitoring Server for display in Tivoli Enterprise Portal. Use the Tivoli Enterprise Monitoring Agent for ITCAM for Response Time Tracking to have this capability. We discuss the components of ITCAM for Response Time Tracking in the following sections: The management server on page 34 Store and forward agent on page 36 Management agents on page 37 Tivoli Enterprise Monitoring Agent on page 41
2.3.1 The management server

The ITCAM for Response Time Tracking management server consists of a J2EE enterprise application that accesses a DB2 repository using JDBC. The management server runs on WebSphere Application Server. The application server can be installed on a stand-alone WebSphere Application Server or on a clustered environment. Figure 2-7 shows a stand-alone management server.
Management server
WebSphere Application Server
DB2
Figure 2-7 Stand-alone management server
34
Figure 2-8 shows the clustered management server. It consists of WebSphere Edge Server for load balancing, the management server on several clustered WebSphere Application Server Node Deployment systems, and the database installed on a separate database server.
WebSphere Node Deployment Cluster
WebSphere Application Server WebSphere Edge Server WebSphere Application Server
DB2
Figure 2-8 Clustered management server
Clustered management server benefits include: Separating the servers reduces the processing burden of a single machine. Clustered management server allows failover for failure in WebSphere Application Server, so the other management server in the cluster can take over the work. Some disadvantages are: Additional communication traffic between machines More difficult setup; refer to IBM Tivoli Composite Application Manager for Response Time Tracking V6.0: Installing a Management Server in a WebSphere Cluster Environment, SC32-1804, for installation instructions Overall, regardless of the management server types, the management server provides the following functions: Managing management agents and their deployed components; management agents must sign in to the management server and retrieve all required policies when it is started initially
35
Storing policies for management agent operation, including discovery policies, listening policies, and playback policies, which are maintained using the Web interface or the new command-line interface Managing a schedule repository; note that the management agent performs the schedule application Performing data collection from various management agents and storing them in its repository. Maintaining users and roles for accessing the Web interface Serving the Web interface
2.3.2 Store and forward agent

The store and forward agent acts as an intermediary between the management server and the management agent. Figure 2-9 shows its overall processing.
RTT Management server
1976
Store and Forward agent

Caching Proxy
80
9081
RTT Management agent
Figure 2-9 Store and forward agent
This agent consolidates communication from and to management agents and uses a single port to communicate to the upstream component. The store and forward agent can be cascaded. It uses IBM WebSphere Caching Proxy, which is part of WebSphere Edge Server V2.0. The caching proxy optimizes the connection with the management server. The default port, to which the management agent must connect, is 9446 for Secure Sockets Layer (SSL) or 80 for non-SSL. You can have multiple store and forward agents chained to get to the management server through multiple layers of firewalls. Figure 2-10 on page 37 shows this concept.
36
Management Server
Store and forward agent
80
Store and forward agent
80
Management agent
Figure 2-10 Multiple store and forward agents
2.3.3 Management agents

The management agent runs in a Java virtual machine on the managed server. It typically performs the following functions: Starting and stopping the management components Collecting monitoring and schedule information from the management server Informing the management components about what to perform Caching response time data in the temporary directory Uploading response time data as requested by the management server, either at regular collection time or on demand The management agent behavior is based on the Application Response Measurement (ARM) specification. The management component monitors measure response time and report the times using the ARM specification to the ARM agent process (tapmagent executable). The ARM agent process stores response time information on physical disk. The management agent uploads the response time information to the management server at the regular interval. There is a slight difference between the distributed management agent architecture and the z/OS-based management agent.
37
Distributed management agent

Conceptually, Figure 2-11 illustrates the processing of the management agent.
ARM agent QoS Apache reverse proxy Management agent Web Response Monitor
STI client
Generic Window
Client Application Tracker
J2EE monitoring component
Figure 2-11 Management agent
The existing management components are: The Generic Window component allows investigation of a Windows-based application to use with Rational Robot application, which enables the Robot to interact with a native Windows application, a Java application, or a browser-based application. You can only deploy this Generic Window component on a Windows system.
Synthetic Transaction Investigator (STI) simulates user interaction with a Web browser. STI transactions are recorded in advance using the STI recorder application. The STI component can be deployed only on a Windows system. Quality of Service (QoS) runs in an Apache Web server proxy that tracks the response time for a user. It inserts a small Java script for HTML code to reply back to QoS and indicate the overall user response time. Figure 2-12 on page 39 outlines the QoS processing.
38
User with Web browser
QoS Apache reverse proxy
Back-end Web server
Back-end processing time Overall response time
Page render time
Round-trip time
Figure 2-12 QoS processing
J2EE instrumentation component runs as JVMPI instrumentation for a J2EE-compliant Web application server, such as WebSphere Application Server or BEA WebLogic. It monitors certain WebSphere classes to collect information about servlets and Web Services calls. It also collects response time information for Java Database Connectivity (JDBC) connections and J2EE Connector architecture (J2C) accesses. ARM agent, historically called Tivoli Application Performance Manager, is implemented as the executable tapmagent. Web Response Monitor (WRM) measures the performance of Web-based applications, provides response time and other performance data, and tracks navigation paths and usage behavior.
Mainframe management agent

For z/OS-based systems, ITCAM for CICS Transactions and ITCAM for IMS Transactions data collectors can send transaction start and transaction end events to the management agent running on the same z/OS system as the CICS and IMS started task. These start and stop events for CICS and IMS transactions are translated into ARM start and ARM stop calls by a component called the transaction server. These data collectors allow IMS and CICS transactions to be shown as part of the distributed transaction or as a stand-alone transaction running on z/OS. Figure 2-13 on page 40 shows the z/OS-based management agent structure.
39
ARM agent ITCAM for CICS Transactions Management agent

Transaction Server
ITCAM for IMS Transactions
J2EE monitoring component
Figure 2-13 Mainframe management agent
Note: The transaction server component is activated by default in all platforms that we installed. Only the z/OS management agent can use this feature. You can see which components are started from the configuration file tmtp_sc.xml. The components of the management agent in z/OS are: Management agent The management agent is responsible for communication with the ITCAM for Response Time Tracking management server and collecting ARM-related activities on behalf of CICS and IMS. The ARM engine or tapmagent is part of the management agent; it enables you to integrate any other ARM-instrumented application with ITCAM for Response Time Tracking.
CICS data collector The CICS data collector monitors transaction response times within CICS regions. It gives you information about how long it took to run the transaction in the monitored CICS region. If your CICS transaction flows through several CICS regions, installing CICS data collectors in every region involved enables you to track the complete transaction flow. IMS data collector 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
The IMS data collectors and CICS data collectors report to the transaction server portion of the ITCAM for Response Time Tracking management agent on the z/OS machine on which they execute.
2.3.4 Tivoli Enterprise Monitoring Agent

The agent for Tivoli Enterprise Monitoring Server for ITCAM for Response Time Tracking is provided as a separate installable feature. Figure 2-14 shows the connectivity of the Tivoli Enterprise Monitoring Agent for ITCAM for Response Time Tracking.
ITCAM for RTT Management server WebSphere Application Server DB2
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
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
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
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
The SET EVENTQOUT command identifies the output queues where queue manager event information, channel event information, performance event information, configuration event, command event information, and logger event information will be copied. After WebSphere MQ monitoring has read an event message from an event queue, it deletes the message to ensure that it is processed only once. If another application running at your site requires access to event messages, you can define an output queue where these messages are copied and point the other application to that queue. If no SET EVENTQOUT command applies to a queue manager, the event information is discarded after being processed. The PERFORM INCLUDE command points to an external file containing customization commands. To execute the commands in this file, specify PERFORM INCLUDE in your startup file. The PERFORM STARTMON command initiates monitoring of WebSphere MQ objects, specifies the sampling interval for collecting WebSphere MQ data, and specifies whether or not historical data will be collected. The PERFORM STARTMON command is required. The SET AGENT command enables you to specify the middle qualifier used in the managed system name. On distributed platforms, if this value is not specified, no value is used. On z/OS, if this value is not specified, the host name is used. If you specify this value, it is used only in the managed system names of subnodes. For example, to avoid confusion and to allow multiple WebSphere MQ Monitoring Agents, instead of issuing the default agent startup command IRAMAN KMQAGENT START (to start a node named host name: MQIRA), you can issue the modified agent startup command IRAMAN KMQAGENT START agentid (to start a node named agentid: MQIRA). Here are several reasons to use the SET AGENT command: On distributed platforms, if your site has multiple queue managers with the same name running on different nodes, you need to specify the node name for each queue manager to uniquely identify them. Use SET AGENT to group and identify queue manager names by something other than the host name and queue manager name. Use SET AGENT to allow multiple agents connected to the same Conversational Monitor System (CMS) to monitor the same queue manager. The SET APPL (z/OS only) command identifies the WebSphere MQ-based z/OS applications, CICS transactions, and IMS programs that must be monitored for application debugging information and application statistics.
45
The SET MQIMONITOR (z/OS only) command is supported on z/OS only. The SET MQIMONITOR command activates monitoring for the applications that you specified using the SET APPL command. You must specify the SET MQIMONITOR command to turn on monitoring. Use the SET MQIMONITOR command together with the SET APPL command to activate the application debugging and application statistics features. The SET QSG (z/OS only) command specifies which queue-sharing groups the WebSphere MQ Monitoring Agent on z/OS monitors and which queue managers the agent uses to collect queue-sharing group data. At any given time, for a particular queue-sharing group, this monitoring product uses only one queue manager to gather data. If that queue manager becomes unavailable, data gathering fails over to another queue manager. The SET QSG command is optional. If not specified, the default behavior of the agent is to monitor all queue-sharing groups that are associated with monitored queue managers. You might use a SET QSG command to specify: That no queue-sharing groups will be monitored That a particular queue-sharing group will not be monitored That a particular queue manager must not be used to collect queue-sharing group data
2.4.3 WebSphere Message Broker monitoring

WebSphere Message Broker Monitoring Agents collect data from WebSphere Message Brokers. The data is presented in charts and tables that you can examine to monitor the performance of your WebSphere Business Integration systems. The agents also evaluate the data to detect when specified values meet criteria that you have defined and trigger alerts or programmed actions in response. In addition, WebSphere Message Broker monitoring provides a CandleMonitor node. Inserted into message flows, the CandleMonitor node collects statistics about message flow and subflow performance. It also provides a mechanism for generating user-defined events within a message flow (Figure 2-16 on page 47).
46
Figure 2-16 CandleMonitor node
47
48
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
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
WebSphere Application Server TraderClientWeb
srv107
WebSphere Process Server TraderDBAvailabilityMediati onApp WSRR
lima
DB2 Universal Database TRADERDB
khartoum
WebSphere Application Server TraderDBServices
Figure 3-1 Application environment
The application has a client component, which goes through Enterprise Service Bus mediation, which calls the server component using Web Services and accesses a database in the back end.
50
3.2 Performance metric of Web Services

The workspaces of ITCAM for SOA in the Tivoli Enterprise Portal are arranged to show Web Services calls by servers. Figure 3-2 shows this structure. The Web Services calls are typically identified by the following attributes: Frequency Response time Message length
Figure 3-2 Primary workspace for ITCAM for SOA
The workspace in Figure 3-2 displays the primary metrics that are collected by ITCAM for SOA. It shows all active Web Services calls in the duration. In our Trader application, we have three Web modules, each one accessing DB2,
Chapter 3. Basic SOA and Web Services management
51
CICS, and IMS. Each Web module serves four Web Services calls: getCompanies, getQuote, buy, and sell. Figure 3-3 shows a performance summary display. The detailed information of the Web Services call performance is shown in a table. The average response time by operation summary chart is on the upper right.
Figure 3-3 Performance Summary
52
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
53
From a different branch, the message arrival rate is shown in Figure 3-5. This shows the activity of the server in general.
Figure 3-5 Message Arrival rate
3.3 Generating events and alerts

Events and alerts are created based on the situation. In the simplest case for an SOA-based application, the situation can be checked against Web Services response time, message rate, and overall message size. These measurement metrics are collected from ITCAM for SOA. Here, we demonstrate the creation of a situation based on several of these metrics. Start from the Tivoli Enterprise Portal: 1. Open the create situation dialog using . 2. Select the Service Metrics or Service Inventory attribute group. The Service Metrics attribute group contains individual invocation of services, while Service Inventory contains an aggregated statistic. Most installations do not collect Service Metrics attributes.
54
3. Select the attributes against which you want to measure and specify the threshold. 4. Set the monitoring intervals and save the situation. 5. Monitor the attribute values when the situation fires. In a general SOA-based environment, you might need to monitor the following typical metrics in order to assure the application health: ITCAM for WebSphere: Application server status Request rate Request response time ITCAM for Response Time Tracking: Application response time from the robotic application Client response time tracker definition Web response time information ITCAM for SOA: Message rate Response time Message size
3.4 Managing Web Services response time

You can correlate the Web Services processing response time to the overall users response time. The Web Services processing response time is typically collected from the Web Services component of the ITCAM for Response Time Tracking. In this section, we discuss the usage of ITCAM for Response Time Tracking to monitor the response time of an SOA-based application. ITCAM for Response Time Tracking has methods of collecting response time information, such as a robotic simulation or HTTP traffic monitoring. In this section, we discuss the ITCAM for Response Time Tracking monitoring using the Rational Performance Tester and Web Response Monitoring. We also use the Java 2 Platform, Enterprise Edition (J2EE) component to monitor the application servers on which the SOA application runs. We divide this discussion into: Execution environment on page 56
55
Creating Rational Performance Tester script on page 56 Defining Web Response Monitor policies on page 59 Reports generated from the policies on page 63 Tivoli Enterprise Portal workspaces on page 64
3.4.1 Execution environment

Figure 3-6 shows our ITCAM for Response Time Tracking execution environment.
perth
WebSphere Application Server TraderDBServices J2EE
laredo
WebSphere Application Server TraderClientWeb J2EE
srv107
WebSphere Process Server TraderDBAvailabilityMediati onApp WSRR J2EE
lima
DB2 Universal Database TRADERDB
khartoum
WebSphere Application Server TraderDBServices J2EE
ARM
gruene
Rational Performance Tester RPT
srv106
ITCAM for Response Time Tracking Management server
Figure 3-6 ITCAM for Response Time Tracking environment
We monitor this application by using the components deployed on the monitoring agents. Depending on how detailed you need the performance information, you can use either one of these methods. You can collect the ordinary interaction from users by using the Web Response Monitor components. Use the Rational Performance Tester to collect a representative interaction, and then you can use the Rational Performance Tester interaction to establish an average performance baseline.
3.4.2 Creating Rational Performance Tester script

We describe the Rational Performance Tester record procedure with the Trader application.
56
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
57
3. We record the Trader application transaction using Microsoft Internet Explorer. Close the Internet Explorer browser. The script is available to edit, as shown in Figure 3-8. Note: We only use the Rational Performance Tester HTTP script for Microsoft Internet Explorer. For more information about Rational Performance Tester usage, refer to the online help of Rational Performance Tester.
Figure 3-8 Created transaction script by Rational Performance Tester
58
4. To use the Rational Performance Tester script on the management server, export the recorded transaction to the management server using the RTT plug-ins. Right-click the script name in the test navigator panel and select Export, select ITCAM Response Time Tracking as the export destination, and click Next. Enter the management server information, as shown in Figure 3-9. Click Next.
Figure 3-9 Export the recorded transaction by Rational Performance Tester
3.4.3 Defining Web Response Monitor policies

The definition of the Web Response Monitor policy is divided into discovery and then monitoring. You cannot just create a new listening monitor.
Web Response Monitor discovery

We deployed the Web Response Monitor. It runs within the IBM HTTP Server, V1.3.26.1. We did not configure a separate Web server for the Web Response Monitor.
59
To monitor with the Web Response Monitor, you need to create the discovery to determine what transactions are in the Web server. To configure the Web Response Monitor discovery: 1. Select Configuration Discovery. Choose Web Response Monitor from the drop-down list box, as shown in Figure 3-10, and click Create New.
Figure 3-10 Web Response Monitor Discovery
60
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
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
To create the Web Response Monitor listening monitor, select the URL of the discovered Web transaction and choose Create Listening Monitor From from the menu. Click Go. Configure the WRM settings for the listening monitor as shown in Figure 3-13.
Figure 3-13 Web Response Monitor listening monitor settings
3.4.4 Reports generated from the policies

We discuss the reports in two sections, because the reports show different perspectives. The Rational Performance Tester reports define a reference baseline of a specific performance metric. The Web Response Monitor collects
63
user response time experience in a distributed application environment. Figure 3-14 shows a sample topology.
Figure 3-14 Sample topology information
3.4.5 Tivoli Enterprise Portal workspaces

In this section, we demonstrate the type of information from Web Services that you can gather from Tivoli Enterprise Portal when running Tivoli Enterprise Monitoring Agent for ITCAM for Response Time Tracking. We customized the logical view for ITCAM for Response Time Tracking. Figure 3-15 on page 65 shows the agent status and message.
64
Figure 3-15 Response Time Tracking portal workspace
65
Select the Response Time Tracking Agent Policy Groups, which opens the primary interface for ITCAM for Response Time Tracking, as shown in Figure 3-16. The policy groups summary shows the defined reporting groups in ITCAM for Response Time Tracking. To view the detailed reporting group information, click the icon to the left of the TraderWeb reporting group.
Figure 3-16 Response Time Tracking Agent Policy Groups
66
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 monitors status, click the icon by the policy name.
Figure 3-17 Policy Status for Policy Group
67
In Figure 3-18, Tivoli Enterprise Portal shows STI_QoS_TraderWeb, the Synthetic Transaction Investigator (STI) robotic monitors status. For more detailed status, click the icon . This icon links to the related workspace.
Figure 3-18 STI_QoS_TraderWeb Robotic Monitor Status
68
Tivoli Enterprise Portal provides historical data by configuring and starting historical data collection. For more information about the historical data collection settings, refer to IBM Tivoli Monitoring documentation. Figure 3-19 shows an example of the agent availability historical data over the last eight hours.
Figure 3-19 Display the agent availability historical data in Tivoli Enterprise Portal
3.5 Debugging performance of Web Services

You can trace the performance of Web Services by using ITCAM for WebSphere. The interface allows you to diagnose the problem in-depth on a J2EE-based application. The monitoring for ITCAM for WebSphere is performed on different levels. Because we assume that you are running the monitoring for
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
Figure 3-21 Decomposition chart
5. The ListCompanyServlet flow view is shown in Figure 3-22 on page 72. The request detail is shown in monitoring level 2. The flow view provides the easiest view to quickly show problems for a small number of components. The shaded rows are the rows that exceed the threshold that is specified at the top of the page. You can change this threshold dynamically.
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
Figure 3-23 Web Services provider flow view
73
8. The flow view in Figure 3-23 on page 73 shows more components, because the Web Services provider actually performs an inquiry function. Again shown in monitoring level 2, the Web Services provider flow indicates the major components of the transaction. The transaction runs Java Naming and Directory Interface (JNDI), Enterprise Java Bean (EJB), and Java Database Connectivity (JDBC) calls. 9. You can go back to the Web Services requestor by using the correlation link shown in the arrows.
3.6 Understanding Web Services calling pattern

The Web Services calling patterns can be established by the trace of the Web Services calls. The calls can be logged into log files, and these log files can be analyzed using the Web Services Navigator. We explain the process to run Web Services Navigator in: Turning on the content logging for a Web Service on page 74 Using the Log Assembler tool on page 78
3.6.1 Turning on the content logging for a Web Service

The following procedure illustrates the steps involved in turning on the content logging for Web Services: 1. In Tivoli Enterprise Portal, use the navigation tree and select Enterprise <OS> <machine> Service Management Agent Environment D4:: <agent> Performance Summary. See Figure 3-24.
Figure 3-24 Services inventory list
74
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.
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
Figure 3-28 Action ran successfully
6. Verify that the directory /opt/IBM/ITM/li6243/KD4/logs or the directory \IBM\ITM\TMAITM6\KD4\logs contains the *.content.log files and the *.metric.log files. After collecting the content for a period of time, you can turn the monitoring off by running the same DelMntrCntrl (or UpdMntrCntrl) to stop the content logging. Content logging generates additional processing and takes up disk space. Again, the result of the action needs to be 0. You can check the current monitor setting in the Service Management agent workspace in the Data Collector Monitor Control Configuration query shown in Figure 3-29.
Figure 3-29 Refresh workspace
77
3.6.2 Using the Log Assembler tool

With the Log Assembler tool, you can specify the nature of the transactions that you want to analyze. You perform the data collection by using the monitor control action. The monitor control actions are: AddMntrCntrl: Adding a new control UpdMntrCntrl: Updating an existing control DelMntrCntrl: Deleting an existing control By default, each data collector has a global definition of no monitor control logging for all Web Services calls. You can specify individual control by: Service port namespace Service port Operation namespace Operation Note: Two important items: The ports here are not TCP/IP ports; these service ports are port definitions in the wsdl file. A monitoring control definition exists with all attributes set as wildcards (*). You must use UpdMntrCntrl to change this from wildcards. We decided to add monitor control for an individual service port for our Web Services: TraderDBServices, TraderIMSServices, and TraderCICSServices. Figure 3-30 shows the action invocation for TraderIMSServices.
Figure 3-30 Monitor control action
78
The resulting control can be seen in the Services Management Agent workspace. Figure 3-31 shows the monitor list.
Figure 3-31 Monitor list
This monitor control specification generates the metric log and content log files in the $ITMhome\TMAITM6\KD4\logs: The content log is stored for each data collector. Each content log file can be up to 500 MB in size. The file name of the content log is in the format of: KD4.<env>..<cell>.<node>.<server>.content.log There are multiple metric log files. The metric logs are stored in either the KD4.DCA.CACHE or KD4.DCA.CACHE\archive subdirectory of the logs directory. These files have the name of: KD4.<env>..<cell>.<node>.<server>.metric.log.<timestamp> You must select the appropriate content logs and metric logs and collect them to the machine on which you install the Web Services Navigator. The Log Assembler tool is installed with the Web Services Navigator. The Log Assembler processes and merges each metric log, while retrieving the message content from the content log file. The result is then a single merged metric log file from multiple servers (each server has its own message contents attached).
79
The easiest way to process these logs is by using a batch file, because the file names are long and you have to invoke the command multiple times. In our tests, we invoke 108 Web Services calls within three minutes on two application servers. This gave us 28 metric log files and two content log files. Figure 3-32 shows our log files.
Figure 3-32 Log files
80
We use the batch file in Example 3-1 to process these log files.
Example 3-1 Running Log Assembler
SET TOOLPATH="C:\IBM\ITCAM for SOA 6.1.0\Tools" SET LOGAJAR=com.ibm.websightView.LogAssembler.jar cd \soalogs for %%i in (*.ClientSvc.metric.log.*) do %toolpath%\_jvm\jre\bin\java -cp %toolpath%\lib\%logajar%;%toolpath%\lib\jlog.jar -jar %toolpath%\lib\%logajar% 0 a soa.Merged.log C:\soalogs\%%i C:\soalogs\KD4.1..PERTHCell01.PERTHNode01.ClientSvc.content.log for %%i in (*.ServerSvc.metric.log.*) do %toolpath%\_jvm\jre\bin\java -cp %toolpath%\lib\%logajar%;%toolpath%\lib\jlog.jar -jar %toolpath%\lib\%logajar% 0 a soa.Merged.log C:\soalogs\%%i C:\soalogs\KD4.1..PERTHCell01.PERTHNode01.ServerSvc.content.log Note that from Example 3-1: The Log Assembler must be invoked separately for each server. The metric log for ClientSvc must be processed with the content log for ClientSvc; you cannot combine the processing. The Log Assembler uses two JAR files: the LogAssembler.jar and jlog.jar. The arguments of the command are: logging level processing target log file name metric log file name content log files 0, 1, or 2; nonzero values generate a lot of output o or a; represents overwrite or append to the log files The merged log file name The metric log that you want processed The content log files for a single server
81
We are now ready to import the log file into Web Services Navigator: 1. First, we need an empty project (or an existing one) to store the imported log file definitions. Select File New Project. Then, we choose a simple project (Simple Project) and then we enter the project name to create a simple project (Figure 3-33).
Figure 3-33 Creating a project
82
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.
83
We have the Service Topology view of the merge log shown in Figure 3-35.
Figure 3-35 Service Topology
In Figure 3-35, the figure shows the calling pattern of the Web Services. The green boxes indicate the service name and the operations are listed within it. The arrows indicate service calls with numbers showing the number of invocations. You can also summarize the calls based on the service name instead of the operation name by collapsing the boxes, as shown in Figure 3-36.
Figure 3-36 Operation summary
84
Figure 3-37 shows the transaction flows. It shows the time line of the Web Services calling sequences. The busy chart shows all 108 Web Services calls that we made.
Figure 3-37 Transaction flows
85
Hovering the cursor over any of those lines provides the call details of the Web service. Selecting the service shows yellow highlighting and displays the details in the bottom pane (Figure 3-38).
Figure 3-38 Message Content
86
The flow pattern summarizes the transaction flows in Figure 3-37 on page 85 and collapses any similar invocation pattern. A pattern can be identified by the requestor, provider, service name, and operation name. Figure 3-39 shows the flow pattern.
Figure 3-39 Flow Patterns
3.7 Working with Web Services filtering

Web Services calls can be rejected by ITCAM for SOA. This capability is provided as part of the default action of ITCAM for SOA. These actions can be invoked manually or triggered by a situation. This section demonstrates invoking the action manually to reject a certain Web Services call.
87
It makes sense to invoke the filtering action from the Message Arrival table or from the Message Summary table when you see a lot of unexpected messages flowing through the system. You can invoke the action by using the context menu, as shown in Figure 3-40.
Figure 3-40 Invoking an action
We invoke the addFltrCntrl action. This action requires a set of parameters, as shown in Figure 3-41. Depending on where you initiate the action, you can get prefilled data for these arguments.
Figure 3-41 Action parameters
88
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
89
The rejected Web Services calls show up as faults in the fault summary list. Figure 3-43 shows the Fault Details list.
Figure 3-43 Rejected Web Services call faults
You can remove the filter using the DelFltrCntrl action, as shown in Figure 3-44. This is invoked from the filter list table in Figure 3-42 on page 89 directly, which is why the arguments are automatically already filled in.
Figure 3-44 Removing a filter
3.8 Web Services life cycle

You must install WebSphere Service Registry and Repository Discovery Library Adapter on the server where WebSphere Service Registry and Repository is
90
installed. The Discovery Library Adapter is supplied from ITCAM for SOA under the installation image KD4/DLA/ as WSRRV600_DLA.zip and WSRRV600_DLA_fixpack.zip. We unzip both files under the /opt/IBM/WSRRV6_DLA path. Note: To use the Discovery Library Adapter with WebSphere Service Registry and Repository V6.0.2, you have to copy sdo-int.jar from <WSRR-home> to <WAS-home>/classes and restart the WebSphere Application Server that hosts WebSphere Service Registry and Repository. To use the Discovery Library Adapter with WebSphere Service Registry and Repository V6.0.2, from the /opt/IBM/WSRRV6_DLA/bin directory, edit the WSRR_DLA.config.properties and DLA_FileTransfer.properties: 1. In WSRR_DLA.config.properties, you must at least customize the parameters in Example 3-2. This file specifies how to communicate with the WebSphere Service Registry and Repository API.
Example 3-2 Access to WebSphere Service Registry and Repository
com.ibm.management.soa.dla.wsrr.address=laredo com.ibm.management.soa.dla.wsrr.port=2809 com.ibm.management.soa.dla.wsrr.domainName=itsc.austin.ibm.com com.ibm.management.soa.dla.wsrr.websphereSecurityEnabled=false com.ibm.management.soa.dla.wsrr.securityEnabled=false com.ibm.management.soa.dla.wsrr.userid= com.ibm.management.soa.dla.wsrr.password= 2. In DLA_FileTransfer.properties, you must specify the host on which the Tivoli Common Object Repository is installed and the path to store the IdML books. These parameters are shown in Example 3-3. The ftp password will be encoded after the first invocation of the file transfer program.
Example 3-3 File transfer properties
com.ibm.management.soa.dla.filetransfer.host=peoria.itsc.austin.ibm.com com.ibm.management.soa.dla.filetransfer.targetDir=/opt/IBM/WSRRV6_DLA/s taging com.ibm.management.soa.dla.filetransfer.stagingDir=../staging com.ibm.management.soa.dla.filetransfer.fileFilter=*.xml com.ibm.management.soa.dla.filetransfer.securityEnabled=true com.ibm.management.soa.dla.filetransfer.userid=root com.ibm.management.soa.dla.filetransfer.password=****** com.ibm.management.soa.dla.filetransfer.password.encoded=aXRzMGcwMGQ=
91
3. The logging option for both the discovery and file transfer that we use is shown in Example 3-4. The option allows us to understand the processing better.
Example 3-4 Logging option
com.ibm.management.soa.dla.wsrr.log.logFileName=WSRRDLALog.log com.ibm.management.soa.dla.wsrr.log.logFileDir=../logs com.ibm.management.soa.dla.wsrr.log.loggingLevel=DEBUG_MAX com.ibm.management.soa.dla.wsrr.log.logFileSize=2000000 com.ibm.management.soa.dla.wsrr.log.logFileCount=3 com.ibm.management.soa.dla.wsrr.log.enableLogging=true com.ibm.management.soa.dla.wsrr.log.logToFile=true com.ibm.management.soa.dla.wsrr.log.logToConsole=true 4. We run the discover using the command ./WSRR_DLA.sh -r to create a refresh XML data book. Figure 3-45 shows the execution of this command. [root@laredo bin]# ./WSRR_DLA.sh -r 2007-07-06 15:32:21.793-05:00 [main] KD4SR0017I The discovery library adapter is starting its discovery process. 2007-07-06 15:32:28.982-05:00 [P=941820:O=0:CT] KD4SR0010I The discovery library adapter book: WSRRv600.laredo.itsc.austin.ibm.com.2007-07-06T20.32.25.659Z.refresh .xml was generated and stored into the following directory: ../staging/. 2007-07-06 15:32:29.020-05:00 [P=941820:O=0:CT] KD4SR0018I The discovery library adapter is exiting its discovery process. 2007-07-06 15:32:29.591-05:00 [main] KD4FT0020I The file transfer process is starting. KERBEROS_V4 rejected as an authentication type 2007-07-06 15:32:31.347-05:00 [main] KD4FT0009I The file: ../staging/WSRRv600.laredo.itsc.austin.ibm.com.2007-07-06T20.32.25.6 59Z.refresh.xml was successfully transferred to host: peoria.itsc.austin.ibm.com 2007-07-06 15:32:31.930-05:00 [main] KD4FT0021I The file transfer process is ending.
Figure 3-45 Running the Discovery Library Adapter
5. You load the discovery book by running the bulk load script: /opt/IBM/ITM/li6243/cq/Products/KD4/tcore/bin/loadidml.sh -f
92
You can add the ITCAM for SOA view to the view list in the Tivoli Enterprise Portal. From Tivoli Enterprise Portal, click the Administer Users icon in the tool bar. The Administer Users pop-up window is shown in Figure 3-46.
Figure 3-46 Administer Users: Navigator Views
Click Apply and then click OK to add the ITCAM for SOA view to the drop-down list of the views. The following steps work with the ITCAM for SOA view: 1. The resulting display in Tivoli Enterprise Portal for selecting SOA view is shown in Figure 3-47 on page 94. Click on the View drop-down list and select the ITCAM for SOA view.
93
Figure 3-47 Select ITCAM for SOA view
2. The workspace lists the Web Services that have been loaded from the loadidml command. See Figure 3-48.
Figure 3-48 Services Management: Services Overview
94
3. From the Services Overview table shown in Figure 3-48 on page 94, the data from WebSphere Service Registry and Repository is indicated with a check in the check box in the Registered column. Right-click an entry and select View Service Detail. The topology of the Web Services is shown in Figure 3-49. The Topology view discovers and displays the Service, Service Port, and the operations that are provided by the service.
Figure 3-49 Topology view of the selected service
4. If you hover the mouse over a object icon, that objects parameters are displayed.
95
Figure 3-50 Move the mouse pointer over the object to view the objects 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
Figure 3-51 Services overview with observed and registered Web Services
Select Service Detail from an observed service to get into the detailed view of the service as shown in Figure 3-52 on page 98. The service port topology view displays the service port details discovered by the Discover Library Adapter, the service operations, and the Application servers that provide the service.
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
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
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
Service Instance 1
Enterprise Service Bus (ESB)
Service Consumer
Service Instance 2
Figure 4-1 Services in an SOA
Service Instance 1 and Service Instance 2 shown in Figure 4-1 have the same service interface; however, they might share the same implementation or a different implementation. The service consumer is bound to the service provider either directly or by using logic that we refer to as mediation. The target service endpoint can be bound at deployment time or at run time. Enterprise Service Bus enables you to insert mediation logic between the service consumer and the service provider. Mediations can look at the service request data to make certain decisions or can refer to an external component, such as database or a service registry, to help execute mediation logic that affects the service request flow within an Enterprise Service Bus. As an example, consider mediation logic that uses a service registry component that is used to query and retrieve a choice of target service endpoints to which the service requestor can be routed based on certain criteria, such as quality of service and service availability. From a system management perspective, mediation enables us to monitor service invocations, perform on demand logging of service requests and response data, observe service executions, and reconcile discovered services with known services in a service registry. In addition to monitoring service data, the ability to control service requests based on operational data provides for a number of use case scenarios that offer tremendous value to any enterprise building its applications in an SOA environment.
Chapter 4. Advanced SOA management
101
4.2 Enterprise Service Bus

IBM offers three enterprise service bus technologies: WebSphere DataPower Integration Appliance WebSphere DataPower is an XML appliance, which is capable of processing XML at wire speed, is optimized to process SOAP messages, and can also transform and route SOAP messages, providing functions of a service bus. WebSphere Enterprise Service Bus WebSphere Enterprise Service Bus is built on WebSphere Application Server and offers Java 2 Platform, Enterprise Edition (J2EE) standards-based connectivity for an SOA environment. WebSphere Enterprise Service Bus uses Service Component Architecture (SCA) to model service connectivity. The Service Component Architecture is based on SCA modules, each of which consists of one or more SCA components. WebSphere Enterprise Service Bus provides runtime environments for SCA modules that deal with mediation or message flow logic within the enterprise service bus. WebSphere Message Broker WebSphere Message Broker provides universal connectivity and transformations in heterogeneous environments. ITCAM for SOA supports monitoring all these Enterprise Service Bus technologies. The current version of ITCAM for SOA also supports advanced capabilities to control service request flows in WebSphere Enterprise Service Bus. For this chapter, we focus on the WebSphere Enterprise Service Bus and how it integrates with ITCAM for SOA. WebSphere Enterprise Service Bus is built on WebSphere Application Server Network Deployment. In addition to the standard J2EE-based application environment, it offers a number of mediation primitives that help building mediation flows. The mediation primitives are used to build mediation flows and are deployed as mediation modules. The mediation modules are themselves SCA modules. The mediation flows help connect the service consumer and service provider without needing to know the implementation details of the service provider. The mediation flows are created by using WebSphere Integration Developer Integrated Development Environment. WebSphere Integration Developer is an Eclipse-based development environment that is used to create SCA application and mediation flows. It provides a palette of customizable pre-built objects called mediation primitives that can be used to intercept and control the service request and response message flows, such as Logger, Message Filter, XSL Transformation, Message Element Setter, Database Lookup, and Endpoint
102
Lookup. You can create the mediation flow application by using a drag and drop interface with minimal or no programming. Note: WebSphere Process Server is an application server for executing business processes. It is built on J2EE standards and also uses the WebSphere Enterprise Service Bus technology for service bus and mediation capabilities. All discussions about WebSphere Enterprise Service Bus also apply to WebSphere Process Server. For more information about WebSphere Enterprise Service Bus, refer to Getting Started with WebSphere Enterprise Service Bus, SG24-7212, at: http://www.redbooks.ibm.com/abstracts/sg247212.html?Open ITCAM for SOA extends the following mediation primitives, which are called managed mediation primitives: Managed XSL Transformation conditionally transforms a message as it flows through the ESB. Managed Message Filter conditionally selects a service endpoint. Managed Message Logger conditionally logs service request message data. Managed Message Fail conditionally fails a message and generates a service fault. Each of these managed mediations can be enabled and disabled at run time from the operations environment using Tivoli Enterprise Portal either manually using a Take Action menu entry or by using a predefined situation to perform an action. Operational control of service requests and response flows in the WebSphere Enterprise Service Bus has a number of useful applications: Operationally control on demand logging of messages for auditing purposes. Dynamically route service requests to alternate service if the primary service provider or a dependent resource, such as a queue manager, database, network, or storage, fails. Monitor the runtime quality of a service and update the service quality properties in a service registry, such as WebSphere Service Registry and Repository. You can then use this during the service assembly phase to determine if a given service will meet the application requirements. Exploit the runtime service performance and service information to enhance the SOA governance process. Introduce, in a controlled way, a new implementation of a service into an SOA environment by temporarily routing service requests to an alternate service.
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 users perspective, you can base the SLA on the application user interface response time. In an SOA environment, the user application user interface can, in turn, depend on a service implementation that has additional dependencies on resources, such as message queues, a database, and so on. It is important that you monitor the application user interface response times, service response times for individual services, and health of dependent components in order to keep the application performance to the desired service level. When service performance degrades or the service is temporarily unavailable, you are often required to have a contingency plan for failover to an alternate service instance. We use one of the Trader application services, TraderDBServices, to see how we can monitor and manage the application server and service using ITCAM for SOA and ITCAM for Web Resources (or ITCAM for WebSphere) to ensure that the service remains available. We deploy the same service on two servers. We will monitor the servers and the response times for the service on the deployed instances and update the service registry that will be used to query the best available service at run time. We use a mediation flow in WebSphere Enterprise Service Bus as a front end to the deployed services. We will develop the mediation flow using WebSphere Integration Developer using the TraderDBServices Web Services Description Language (WSDL). We will also use WebSphere Service Registry and
104
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
Managed Logger Select best available service Health Monitoring using ITCAM
srv107:9081
TraderDBServices 1
perth:9082
TraderWebClient
perth:9081
TraderDBServices 2
khartoum:9082
WebSphere Service Registry & Repository

laredo:9080
Update Service Quality and Server Health
Enable / Disable Logging from Operations
IBM Tivoli Monitoring

peoria
Situation And Take Actions
Figure 4-2 Example of maintaining service continuity using ESB, WSRR, and ITCAM
105
In the next section, we describe the steps required to implement the service continuity solution described in the previous section. We describe the steps required to implement the solution in: Register TraderDBServices in the registry on page 106 Developing managed SCA mediation with ITCAM for SOA on page 110 Deploying the mediation application on page 126
4.3.1 Register TraderDBServices in the registry

in this section, we describe the steps for loading the TraderDBServices in WebSphere Service Registry and Repository. Note: We do not describe the installation of WebSphere Registry and Repository in this chapter. For installation and basic usage, refer to the WebSphere Service Registry and Repository Handbook, SG24-7386, at the following Web site: http://www.redbooks.ibm.com/abstracts/sg247386.html After deploying TraderDBServices to WebSphere Application Servers, we load the WSDL files into WebSphere Service Registry and Repository. The deployed WSDL files can be obtained from the WebSphere administration console. The published WSDL for the deployed services will contain the actual service endpoint address. The steps are: 1. Extract the WSDL file for each of the application servers hosting the Web Services provider: a. Go to to WebSphere administration console using the URL: http://<dmgrhost>:9060/ibm/console b. Navigate to the Enterprise Application TradeDBEAR Publish WSDL files. See Figure 4-3 on page 107. Right-click and save the.zip file. c. Open the.zip file to extract the TraderDBServices.wsdl file.
106
Figure 4-3 Publishing WSDL from WebSphere
2. WebSphere Service Registry and Repository console in laredo can be accessed using the URL http://laredo:9080/ServiceRegistry. 3. Navigate to Service Documents Load Documents. Browse to the previously extracted WSDL documents and follow the steps to load the WSDL document into WebSphere Service Registry and Repository.
Figure 4-4 Load WSDL into Service Registry
107
Note: There are other alternatives for representing the WSDL documents in WebSphere Service Registry and Repository. The WSDL for TraderDBServices can be split into port type interface definitions and port physical binding address files. This approach can reduce part of the duplication of the WSDL data in WebSphere Service Registry and Repository. However, today this involves creating the WSDL files manually instead of using the WSDL files retrieved from the deployed applications in WebSphere Application Server directly. 4. To verify that all WSDL documents have been loaded in WebSphere Service Registry and Repository, navigate to Service Documents WSDL Documents. Verify that the WSDL documents are shown similar to Figure 4-5.
Figure 4-5 TraderDBServices WSDL instances
5. We add service metadata (user-defined properties) to the service definitions. These properties are used for selecting Web Services destinations from the
108
mediation. These properties can be updated manually using the console or programmatically using the WebSphere Service Registry and Repository API. 6. Navigate to Service Metadata Ports. You will notice that there are several TraderDBServices entry. The entries represent each of the loaded instances from the WSDL files. To easily distinguish these instances during our navigation, we add a description string to indicate the server to which the port belongs. See Figure 4-6.
Figure 4-6 Add a description to the port to distinguish each instance of the service
7. For each of the ports, click the port instance, then click Custom Properties, and click New to add properties and value shown in Table 4-1.
Table 4-1 Custom properties Property name serviceServerStatus serviceResponseTime Initial property value down good Valid property values up or down good or bad
8. The resulting custom properties list is shown in Figure 4-7 on page 110.
109
Figure 4-7 Service metadata: Custom Properties for port instances on srv177
Now, the setup in WebSphere Service Registry and Repository is done. You can also define the Web Services life cycle as deployed so that the Web Services life cycle is discovered by the Discovery Library Adapter.
4.3.2 Developing managed SCA mediation with ITCAM for SOA

We turn our effort now to WebSphere Integration Developer. We wanted to create a mediation module that can be managed using ITCAM for SOA-managed SCA mediation for TraderDBServices. First, we have to set up our development environment: The installation of WebSphere Integration Developer is provided in: http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp?t opic=/com.ibm.wbit.help.nav.doc/topics/installmigrate.html We set up ITCAM for SOA-managed SCA mediation tools to WebSphere Integration Developer. The installation is provided in the KD4/Tools directory of the ITCAM for SOA tools CD. The instructions are available from: http://publib.boulder.ibm.com/infocenter/tivihelp/v3r1/index.jsp?top ic=/com.ibm.itcamsoa.doc/kd4nvmst31.htm
110
Mediation development uses the following terminology: Interface Reference Import The interface is the mediation flow definition of how an external client can connect and run the mediation flow. The reference is the mediation flow definition for how it calls Web Services providers. 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. 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. The logic of the mediation maps the exported call interface into the reference call to the imported Web Services. Wiring is the process of defining links between components of the mediation.
Export
Mediation flow
Wiring
We create a mediation flow for TraderDBServices that can be used to ensure service availability in an SOA environment: 1. We first create a library project in WebSphere Integration Developer. Create a new library using the menu File New Other and select Library. Call the library project TraderDBServicesLibrary. The new project is shown in Figure 4-8.
Figure 4-8 Create TraderDBServicesLibrary project
2. Import TraderDBServices.wsdl into WebSphere Integration Developer. Right-click Interfaces and select Import. In the ensuing dialog box, select WSDL/Interfaces. Select TraderDBServices.wsdl, and see Figure 4-9 on page 112.
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
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.
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
Figure 4-12 Add the mediation flow into the assembly editor
5. We need to define the service interface for invoking the mediation flow. This is the interface that is used by the service consumer: a. Add an interface using the icon. Select TraderDBServices for the interface selection. See Figure 4-13.
Figure 4-13 Add interface
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
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.
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
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
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. 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.
Properties
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
Figure 4-22 Wire each interface operation with the TraderDBServicesPartner
10.We must define the mediation flow for each of the wires in Figure 4-22. We only illustrate the modification for the buy operation: a. Click on the wire that connects the buy operation, which will update the mediation flow editor canvas. The mediation flow editor has a palette of mediation primitives on the left that can be used to create the mediation flow. The palette also contains the managed mediation primitives installed by the ITCAM for SOA tools package. See Figure 4-23.
Figure 4-23 ITCAM for SOA managed mediation primitives
b. We will use two mediation primitives: Managed Message Logger from the ITCAM for SOA tools package
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
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.
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
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.
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
Figure 4-32 Export mediation module
2. Before we deploy the mediation module, we need to perform the following steps to prepare the server to enable ITCAM for SOA runtime mediation support. With the Process Server stopped, perform the following steps: a. Go to the ITCAM for SOA directory, such as: /opt/IBM/ITM/li6243/d4/KD4/bin b. Enable WebSphere data collector for ITCAM for SOA using the command, such as: ./KD4configDC.sh -enable -env 1 /opt/IBM/WebSphere/AppServer c. Configure WebSphere Process Server data collector for ITCAM for SOA: ./KD4configDC.sh -enable -env 9 /opt/IBM/WebSphere/AppServer
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
Figure 4-33 Install TraderDBServicesAvailabilityMediationApp.ear
4. Next, get the service endpoint of the mediation application by inspecting the published WSDL file. Navigate to Enterprise Application TraderDBServicesAvailabiltyMediationApp Publish WSDL files. See Figure 4-34 on page 130.
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
Figure 4-36 Verify the service endpoint for TraderDBServicesAvailabilityMediationApp
7. We must now define a default connection to the WebSphere Service Registry and Repository. From the WebSphere Process Server Administrative console, navigate to Service Integration WSRR definition and click New. Define the registry as shown in Figure 4-37. We called our registry TraderWSRR.
Figure 4-37 WSRR definition
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
Figure 4-38 Service metadata TraderDBServices port on perth
4. Save the properties. 5. Similarly for TraderDBServices in khartoum, set the property values for serviceServerStatus to down and serviceResponseTime to bad. 6. Now, invoke the service using the TraderClientWeb. The interface is shown in Figure 4-39 on page 134.
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
Figure 4-40 Failed server call
9. As a test, we set both perth and khartoum to be unavailable from WebSphere Services Registry and Repository. The test results shows that the Web Services failure is returned similar to Figure 4-40. The availability solution so far has demonstrated how easy it is to use a mediation with a service registry in an SOA environment to achieve service routing by just flipping the property values associated with a service instance. In order to make this function really useful, we must be able to update the service metadata automatically. We define how to update the service metadata automatically in 4.4, Service monitoring automation on page 136. We demonstrate the use of IBM Tivoli Monitoring solution to automate this task.
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
Figure 4-41 Tivoli Enterprise Portal navigation tree for khartoum and perth
4.4.1 Automation principles

Automation is automatic monitoring of a situation or predefined problem condition using monitored resources or attributes. When a certain situation or problem condition becomes true, a predefined action or command can be executed.
IBM Tivoli Monitoring also offers a simple to use situation editor and workflow editor that can be used to create custom situations, correlate multiple situations, and define a custom command. IBM Tivoli Monitoring, through Tivoli Enterprise Portal, provides a single view of the entire IT infrastructure. It offers a rich set of monitored data attributes from the monitored environments. All ITCAM offerings plug into the ITM infrastructure and offer hundreds of monitored data attributes, predefined actions, and predefined situations. The power to combine and correlate situations and monitored data across various monitored environments using multiple monitoring products, such as ITCAM for SOA, ITCAM for Web Resources, ITCAM for WebSphere, ITCAM for J2EE, OMEGAMON XE for Messaging, and IBM Tivoli OMEGAMON, offers tremendous benefit to IT operations.
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
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 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 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. 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.
add
update
remove
A sample cURL invocation is shown in Example 4-1.

Example 4-1 Sample cURL invocation
curl -d \ "bsrURI=d4f935d4-4cbd-4d85.9380.0678680680cb&\ update=name1=value1,name2=value2"\ http://laredo:9080/UpdateServiceMetadataInWSRRWebClient/UpdateWSRRPrope rties
4.4.3 ITCAM for WebSphere and ITCAM for Web Resources situations
ITCAM for WebSphere (and ITCAM for Web Resources) provide a number of predefined situations and monitored attributes. To explore predefined situations, use Tivoli Enterprise Portal and click the Situations icon as shown in Figure 4-42 on page 140.
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 WASWebApplicationError
140
Note: For more information about the situations and other monitored attributes, refer to the Web site: http://www-1.ibm.com/support/docview.wss?uid=swg27009086 ITCAM for Web Resources 6.2 adds four new situations to the previous list that give additional monitoring control of WebSphere Application Server from an application perspective. They are: WASAppDiscovered WASAppHealthGood WasAppHealthFair WASAppHealthBad For a non-WebSphere environment, the corresponding names are: J2EEAppDiscovered J2EEAppHealthGood J2EEAppHealthFair J2EEAppHealthBad For our scenario, we create four new situations that are based on Application Server Status attributes. We want to monitor the WebSphere Application Server ServerSvc on perth and khartoum where we have deployed the TraderDBServices. The situations are listed in Table 4-2 on page 142 with information about the necessary actions to take.
141
Table 4-2 Situation lists Situation name Perth_ServerSvc_Up Monitoring Monitors when WebSphere Server ServerSvc on perth is up Action Updates the service metadata property serviceServerStatus for WSDL port TraderDBServices associated with perth with value = up in WebSphere Service Registry and Repository Updates the service metadata property serviceServerStatus for WSDL port TraderDBServices associated with perth with value = down in WebSphere Service Registry and Repository Updates the service metadata property serviceServerStatus for WSDL port TraderDBServices associated with khartoum with value = up in WebSphere Service Registry and Repository Updates the service metadata property serviceServerStatus for WSDL port TraderDBServices associated with khartoum with value = down in WebSphere Service Registry and Repository
Perth_ServerSvc_Dn
Monitors when WebSphere Server ServerSvc on perth is down
Khartoum_ServerSvc_Up
Monitors when WebSphere Server ServerSvc on khartoum is up
Khartoum_ServerSvc_Dn
Monitors when WebSphere Server ServerSvc on khartoum is down
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
Figure 4-43 Create a situation for WebSphere Agent
2. In the situation Editor dialog window, select Create New. This option opens a dialog window. Specify the name of the situation as Perth_ServerSvc_Up. Provide an optional description and click OK to continue. See Figure 4-44.
Figure 4-44 New Situation: Perth_ServerSvc_Up
3. Select Attribute Comparison for the Condition Type and select Application Server Status for the Attribute Group. Select Server Name, Status,
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
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.
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
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.
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
Table 4-3 ITCAM for SOA situations Situation name Perth_TrdrDBSvcResponse_Good Monitoring Monitors service port name TraderDBServices and namespace http://services.db2.tra der.j2ee.itso and average elapsed round-trip time is less than 5000 milliseconds Monitors service port name TraderDBServices and namespace http://services.db2.tra der.j2ee.itso and situation ResponseTImeCritical_61 0 is true on server ServerSvc in node perth.itsc.austin.ibm.com Monitors service port name TraderDBServices and namespace http://services.db2.tra der.j2ee.itso and average elapsed round-trip time is less than 5000 milliseconds on server ServerSvc in node khartoum.itsc.ausitn.ibm.c om Monitors service port name TraderDBServices and namespace http://services.db2.tra der.j2ee.itso and situation ResponseTImeCritical_61 0 is true on server ServerSvc in node khartoum.itsc.austin.ibm.c om Action Updates the service metadata property serviceResponseTime for WSDL port TraderDBServices associated with perth.itsc.austin.ibm.com with value of good in WebSphere Service Registry and Repository Updates the service metadata property serviceResponseTime for WSDL port TraderDBServices associated with perth.itsc.austin.ibm.com with value of bad in WebSphere Service Registry and Repository
Perth_TrdrDBSvcResponse_Bad
Khartoum_TrdrDBSvcResponse_Good
Updates the service metadata property serviceResponseTime for WSDL port TraderDBServices associated with khartoum.itsc.austin.ibm.com with value of good in WebSphere Service Registry and Repository
Khartoum_TrdrDBSvcResponse_Bad
Updates the service metadata property serviceResponseTime for WSDL port TraderDBServices associated with khartoum.itsc.austin.ibm.com with value of bad in WebSphere Service Registry and Repository
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
Table 4-4 Attribute selection Attribute name Service Port Name Service Port Namespace Average Elapsed Message Round Trip Time Interval Status Attribute value TraderDBServices http://services.db2.trader.j2ee.itso 5000 milliseconds Complete
Figure 4-51 Situation Perth_TrdrDBSvcResponse_Good attribute comparison
4. Next, click the Action tab. Select Execute the Action at the Managing System (TEMS). We use the same action scheme as the ITCAM for WebSphere situation in 4.4.3, ITCAM for WebSphere and ITCAM for Web Resources situations on page 139.
151
The action command that we use is: /root/automationScripts/Perth_TrdrDBSvcResponse_Good > /root/automationScripts/logs/Perth_TrdrDBSvcResponse_Good_&{Services _Inventory_610.Interval_End_Time} 2>&1 The situation action dialog is shown in Figure 4-52.
Figure 4-52 Command for situation Perth_TrdrDBSvcResponse_Good
And the Perth_TrdrDBSvcResponse_Good script is shown in Example 4-3.

Example 4-3 Perth_TrdrDBSvcResponse_Good
#!/bin/ksh # Take Action for situation - Perth_TrdrDBSvcResponse_Good echo Setting serviceResponseTime to good for TraderDBServices WSDL port in WSRR /usr/bin/curl -d "bsrURI=WSRR--7797c588.ec8a0705.304b9735.65a4f365-5dad-4d77.9045.19da30 19455e&update=serviceResponseTime=good" http://laredo:9080/UpdateServiceMetadataInWSRRWebClient/UpdateWSRRPrope rties 5. The situation Perth_TrdrDBSvcResponse_Bad uses the predefined situation called ResponseTimeCritical_610. This situation monitors for a bad service response time. Use the situation editor to create the situation, and for this
152
situation, select Condition Type as Situation Comparison and select ResponseTimeCritical_610 as the situation to compare. See Figure 4-53.
Figure 4-53 Select Situation Comparison ResponseTimeCritical_610 for Condition Type
6. Add an additional condition to match Service Port Name and Service Port Namespace. Set the values for these as you did in the previous situation. Set the ResponseTimeCritical_610 to true. See Figure 4-54 on page 154.
153
Figure 4-54 Perth_TrdrDBSvcResponse_Bad situation attribute comparison
7. Use the same method for specifying the action and the script. 8. Define the similar situations for the khartoum server.
4.4.5 Verifying situation automation

To verify that the situation works, we check the custom properties in WebSphere Service Registry and Repository for perth. The status is up. Then, we bring down the WebSphere Application Server ServerSvc in perth using the command: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/stopServer.sh ServerSvc The automation occurs as the situation fires in IBM Tivoli Monitoring as indicated in the Tivoli Enterprise Portal. Now, checking at the WebSphere Service Registry
154
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
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
Figure 4-56 CView utility to view cloudspace data
5. Use the menu File Open and then Browse for the directory: /opt/ibm/WebSphere/AppServer/profiles/ProcSrv01/databases/EsbLogMedD B 6. Navigate to Tables MSGLOG. Click the Data tab. You will see the service message data. See Figure 4-57 on page 158.
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
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
159
5.1 Solution overview

The business management solution involves implementing Tivoli Business Service Manager V4.0 to manage an SOA-based application. Tivoli Business Service Manager allows the status of an IT resource to affect an abstract entity based on an impending problem and also provides a representation of service level attainment. Figure 5-1 sows the Tivoli Business Service Manager solution.
Tivoli Enterprise Console
C
CCMDB Relational databases

Data fetcher ESDA
Discovery Library Books

xml files
IBM Tivoli Monitoring OMEGAMON ITCAM
NetView
XML Toolkit Tivoli Service Level Advisor

JDBC
Optional components
Tivoli EIF probe
TBSM processes
SLA events
TBSM postgreSQL
Netcool GUI Foundation

TBSM Console
TBSM Server Netcool Webtop

launch user data
Netcool OMNIbus TBSM ObjectServer

events
user data
license
Tivoli Enterprise Portal
Netcool Security Manager
Netcool License Server
Figure 5-1 Tivoli Business Service Manager solution
The Tivoli Business Service Manager solution that is shown in Figure 5-1 processes events from an Netcool/Omnibus object server. For our purposes in managing an SOA-based application, these events are generated by IBM Tivoli Composite Application Management products that are sent through IBM Tivoli Monitoring.
160
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 Ack Agent Alert Group Alert Key Class Identifier Content No ITM_Services_Inventory_610: attribute group of the situation ITM_Services_Inventory_610: attribute group of the situation ResponseTimeCritical_610: situation name TME10tecad 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 tme10tecad probe on srv179.itsc.austin.ibm.com D4:b7a17fb3:srv107-server1: agent id D4:b7a17fb3:srv107-server1: agent id nobody Critical ResponseTimeCritical_610[(Avg_Elapsed_Time>10000 AND Interval_status=Complete) ON 270d6997d0bd943395ee8fb09d5bd5d1 ON (Avg_Elapsed_Time = <value>) Normal ITM Problem
Manager Node NodeAlias Owner Severity Summary
Suppr_Escl Type
Chapter 5. Managing an SOA application in a business context
161
Field BSM_ClassName BSM_Identity ITMDisplayItem ITMEventData ITMHostname ITMIntType ITMResetFlag ITMStatus ITMTime TECDate TECDateReception TECEventHandle TECFQHostname TECHostname TECRepeatCount TECServerHandle TECStatus
Content N/A D4:b7a17fb3:srv107-server1 270d6997d0bd943395ee8fb09d5bd5d1 ~ peoria.itsc.austin.ibm.com U N/A Y <ts> <date> N/A N/A srv107.itsc.austin.ibm.com srv107.itsc.austin.ibm.com 0 N/A 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
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 BSM_WAS_Down Agent WebSphere agent Subscriber *WAS Condition WebSphereApplication Server/Status = Disconnected WebSphereApplication Server/Status = Connected N/A N/A N/A N/A
BSM_WAS_Up
WebSphere agent
*WAS
BSM_SOA_MsgRate_Bad BSM_SOA_MsgRate_OK BSM_SOA_Resp_Bad BSM_SOA_Resp_OK
SOA agent SOA agent SOA agent SOA agent
*KD4 *KD4 *KD4 *KD4
Figure 5-2 on page 164 shows an example of an ITCAM for SOA event.
163
Figure 5-2 Sample event in Omnibus
5.4 Designing business services

We wanted to illustrate the Trader application in a meaningful business context. We depict this representation of the application in Figure 5-3 on page 165.
164
Application
Application_Component
Application_Server
Web_Services_Operation
Figure 5-3 Business service structure
To achieve this structure, we define the following service templates: Application This template represents an application aggregate. This object always must have an autodiscovery of Trader in our environment: Incoming status rule: None Auto population rule: Always create an instance called Trader Child aggregation rules: Any child of type Application_Component Application_Component This template represents a component within an application. For an SOA-based application, we define a specific Services Provider, Service Consumer, and Service Bus: Incoming status rule: None Auto population rule: Create an instance depending on the child type Child aggregation rules: Bad when any Application_Server status went bad Bad when 50% of the Web_Services_Operation objects went bad
Application_Server This template represents the application server resources that are being used by the application. It can be a WebSphere Application Server or WebSphere Message Broker: Incoming status rule: Provided by ITCAM for WebSphere
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
Figure 5-4 Initial Tivoli Business Service Manager window
2. Change to the Service Administration view and click Go. 3. Creating the Application template: a. In the left navigation tree, select the Templates tab. Click the icon to create a new service template. The new template dialog is shown in Figure 5-5 on page 168.
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
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.
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
Figure 5-8 Incoming status rule
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
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.
173
Figure 5-11 Defining an auto population rule for the Application_Server template
5.5 Defining service level

We can now define service level monitoring with Tivoli Business Service Manager.
174
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 Warning Application Application_Component Application_Server Web_Services_Operation 1 minute 1 minute 5 minutes 5 minutes Violation 5 minutes 5 minutes 10 minutes 10 minutes Cumulative Warning 5 minutes 5 minutes 15 minutes 15 minutes Violation 10 minutes 10 minutes 30 minutes 30 minutes Incident Warning 10 5 3 3 Violation 15 10 5 5
5.6 Getting the business status

The observed result of Tivoli Business Service Manager definitions is in the terms of service instance objects and its reports. When you are logged in to Tivoli Business Service Manager Web console as a user, you are presented with a desktop interface. This interface allows you to see and manage business service status. From the initial login for our Trader application, you see the view that is shown in Figure 5-12 on page 176. This view represents the Trader application and its components.
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
Figure 5-13 Service level impacted for buy in perth
In the event that the SCA mediation in srv107 is down, this triggers a major outage on the Application_Server object and generates an outage call (red) all the way up to the Trader application. See Figure 5-14 on page 178.
177
Figure 5-14 Outage of the mediation server
178
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
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 IMS
Trader CICS
Trader DB2
Trader Tomcat
Trader Server applications
Trader Java client
Trader Web Client
Trader Portal Client
Figure A-1 The Trader application
You can view the Trader application as a three layer or three tier structure: The Trader application has three types of front-end interfaces: a native Java client, a Web interface, and a portal-based interface. Each interface has the ability to connect to the server application that provides the business logic. The connection to the server applications is based on Web Services calls. The server applications are differentiated based on their various access methods to the underlying data or the platform on which it resides. These are Java 2 Platform, Enterprise Edition (J2EE)-based applications that serve as Web Services providers.
180
The back-end data storage can be IMS, CICS on z/OS, or a DB2 database. The DB2 database can reside on z/OS or a distributed server. In our environment, we deploy the DB2 database in a distributed environment. We discuss the components in the following sections: Portal interface on page 181 Front-end J2EE Web application on page 183 Java desktop application on page 186
Portal interface
The Trader portal interface consists of three portlets that communicate with each other. Figure A-2 shows the portal client.
Figure A-2 The Trader portal client
Appendix A. The Trader application
181
The Trader client portlet is the main portlet that lets you query the available companies. If you request a quote for the company, the quote information is shown in the Trader quote portlet. The Trader quote portlet allows you to buy or sell stocks of the currently displayed company. The Trader message portlet just collects and displays the messages from the application. The Trader client portlet requires you to specify the host and port of the back-end server to which you are connected. This requirement means that you are only allowed to connect to the servers that reside on the same J2EE servers. This requirement introduces the need to have a Web Services mediation to pool all the connections, and then the mediation can connect to the appropriate Web Services provider. The connections in the Service Component Architecture (SCA) column are used to connect to a WebSphere Enterprise Service Bus mediation, and the connections in the MQ column are used to connect to a WebSphere Message Broker mediation. The portal application is distributed as a single Web archive file, which is called TraderPortletClient1.war.
182
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
183
Figure A-4 List Company page
GetQuotesServlet (Figure A-5 on page 185): Invokes the back-end GetQuote Web Services
184
Figure A-5 Quotes window
BuySellServlet: Invokes either the Buy or Sell Web Services LogoutServlet: Clears up the session bean We provides three type of enterprise application archive (ear) files for the client interface: TraderClientEAR: This ear file runs the TraderClientWeb application that provides the basic Trader application functionality. TraderClientMemEAR: This ear file runs the TraderClientMem application that has a memory leak in the logic for testing a memory leak situation. TraderClientLckEAR: This ear file runs the TraderClientLck application that has a lock problem injected for testing a deadlock situation.
185
Java desktop application

We also developed the desktop application from the Web Services client wizard from WebSphere Studio Application Development. It consists of the following Java classes: TraderClientLogin.java: JDialog extension that provides the initial parameter (Figure A-6)
Figure A-6 Login dialog
TraderClientMain.java: Main JApplet that provides the list of companies (Figure A-7)
Figure A-7 Company listing
186
TraderClientQuote.java: Company quote window that allows the invocation of buying or selling stock (Figure A-8)
Figure A-8 Quote window
Back-end implementation
The back-end systems consists of two entities: the company and the customer. The company has the quotes definitions, and the customer database has the customers name and the customers stock ownership. Figure A-9 on page 188 shows the conceptual data structure.
187
COMPANY
Company Name Stock price Price history 7 days Commission
CUSTOMER
Customer Name Company name Stock owned
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
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.
189
WebSphere Enterprise Service Bus mediation

The WebSphere Enterprise Service Bus mediation that we use is simple mediation logic that queries the WebSphere Services Registry and Repository (WSRR) server for the location of the service and invokes them. This mediation allows the injection of logic to identify which Web Services servers are available and to redirect the call if necessary. The mediation is deployed in four modules: TraderDBMediation TraderCICSMediation TraderIMSMediation TraderTomcatMediation The WebSphere Enterprise Service Bus mediation implementation for the Trader application is shown in Figure A-10.
WebSphere ESB
TraderTomcatMediationWeb/ sca/TraderTomcatServices TraderIMSMediationWeb/sca/ TraderIMSServices TraderDBMediationWeb/sca/ TraderDBServices TraderCICSMediationWeb/sca/ TraderCICSServices TraderTomcatServices/ services/TraderTomcatServices
Check endpoint
TraderIMSServices/services/ TraderIMSServices TraderDBServices/services/ TraderDBServices TraderCICSServices/services/ TraderCICSServices
WebSphere Service Registry & Repository
Figure A-10 Trader mediation with WebSphere ESB
All of those mediations have similar logic as shown in Figure A-11 on page 191.
190
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
191
group for processing the Web Services calls. Figure A-12 shows the conceptual structure of the broker.
WebSphere Message Broker traderBroker

Execution Group TraderEGrp TraderMQ.bar
TraderTomcatServices/ services/TraderTomcatServices TraderIMSServices/services/ TraderIMSServices TraderDBServices/services/ TraderDBServices TraderCICSServices/services/ TraderCICSServices SIBDB
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
Figure A-13 Message flow implementation
Software requirements
We discuss the software that is required to run the Trader application here. We divide the discussion into: Runtime environment on page 193 Development environment on page 195
Runtime environment
We use the following software for running the Trader components. Other versions of the software products that we use might be acceptable. Figure A-14 on page 194 shows the detailed configuration of our Trader application.
193
CICS TS 3.1 CICS Transaction Gateway V6 TRADERBL TRADERPL
IMS V9 IMS Connect for Java V9 TRADERBL
DB2 UDB V8.2 FP15 TRADER TRADTOMC
WebSphere Application Server ND V6.1 TraderCICSSvc.ear TraderDBSvc.ear TraderIMSSvc.ear Apache Tomcat V5.5.20 TraderTomcatWeb.ear
WebSphere Message Broker V6.0.0.2 WebSphere MQ V6 TraderMQ.bar
WebSphere Process Server V6.0.2 WebSphere Application Server ND V6.0.2.17 Trader*Mediation.ear
WebSphere Services Registry Repository V6.0.2 WebSphere Application Server ND V6.0.2.17 *.wsdl
WebSphere Application Server ND V6.1 TraderClient.ear TraderClientMem.ear TraderClientLck.ear Java client TraderClient.jar
WebSphere Portal Server V6.0 WebSphere Application Server ND V6.0.2.17 TraderPortletClient1
Figure A-14 Trader application detail
The detailed components are: Trader Java client (TraderClient.jar) TraderPortletClient1.war TraderClient.ear, TraderClientMem.ear, and TraderClientLck.ear
194
TraderCICSMediation.ear, TraderIMSMediation.ear, TraderDBMediation.ear, and TraderTomcatMediation.ear TraderMQ.bar TraderDBSvc.ear, TraderCICSSvc.ear, and TraderIMSSvc.ear TraderTomcatServices.war DB2 databases Trader IMS Trader CICS
Development environment
We use various development tools for developing the Trader application. You might need to use these tools to customize or change the Trader information to suit your needs. The development software products that we use are: Rational Application Development V7: This product is a general purpose programming environment that is based on Eclipse. We use this tool for developing the J2EE applications, the portal application, and the Java client. WebSphere Integration Developer V6.0.2: This product is the tool for defining mediation and process modelling for WebSphere Enterprise Service Bus and WebSphere Process Server. This product is based on Eclipse too. We use WebSphere Integration Developer for developing the Mediation modules to deploy to WebSphere Enterprise Service Bus. WebSphere Message Broker Toolkit V6.0.2: This product contains the tools for administering and developing applications for WebSphere Message Broker. This tool is based on Eclipse too. If you install this product on the same machine as WebSphere Integration Developer, it will use the same Eclipse environment. We specifically use different workspace directories for WebSphere Integration Developer and WebSphere Message Broker Toolkit to prevent any conflicts that the products might cause. COBOL compiler for IMS and CICS programs in z/OS. Also, we use various IMS and CICS compilers to translate the necessary definitions in IMS and CICS.
195
196
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.
197
Using the Web material

The additional Web material that accompanies this paper includes the following files: File name REDP4318.zip Description Zipped samples
The file consists of the following files: TraderClient.ear TraderDBSvc.ear trader.tar.gz Client Web application Server Web application Tar gzip file of DB2 tables for db2move command
TraderDBServicesAvailabilityMediationApp.ear Mediation module UpdateServicesMetadataInWSRRWebClientEAR_60.ear Sample WSRR access Web application
System requirements for downloading the Web material

The Web material can be used for any system that is supported to run WebSphere Enterprise Service Bus application with WebSphere Services Registry and Repository. The temporary space for the zip file and its content is 10 MB.
How to use the Web material

Create a subdirectory (folder) on your workstation, and unzip the contents of the Web material zip file into this folder.
198
Abbreviations and acronyms

APF API ARM ASM BCM CAT CD-ROM CICS CLI CPU DASD EJB ESB ETE FFDC FMID GLUE GUI HFS HTML HTTP HTTPS IBM IMS IPL ISM Authorized Program Facility Application Programming Interface Application Response Measurement Application Service Monitor Byte Code Modification Client Application Tracker Compact Disk - Read-Only Memory Customer Information Control System Command Line Interface Central Processing Unit Direct Access Storage Device Enterprise JavaBeans Enterprise Service Bus End-to-End First Failure Data Capture Function Modification Identifier Global User Exit Graphical User Interface Hierarchical File System Hypertext Markup Language Hypertext Transfer Protocol HTTP Secure International Business Machine Corporation Information Management System Initial Program Load Internet Service Monitoring LDAP MSC MVS OTMA PCB PDF PLT PMI J2C J2EE JAR JAX-RPC JCL JDBC JES2 JMX JNI JRE JVM JVMPI JVMTI ITCAM ITIL ITSO IBM Tivoli Composite Application Monitor Information Technology Infrastructure Library International Technical Support Organization Java 2 Connector Java 2, Enterprise Edition Java Archive Java API for XML-based Remote Procedure Call Job Control Language Java Database Connectivity Job Entry Subsystem 2 Java Management Extension Java Native Interface Java Runtime Environment Java Virtual Machine Java Virtual Machine Profiler Interface Java Virtual Machine Tool Interface Lightweight Directory Access Protocol Multiple Systems Coupling Multiple Virtual Storage Open Transaction Manager Access Program Control Block Portable Document Format Program List Table Performance Management Interface
199
RACF RMI RTE SCA SMF SMP/E SNMP SOA SQL SSH SSL SSM STI SYSPLEX TCP/IP TRUE TSO UDB UML URI URL WLM WRM WSDL XML
Resource Access Control Facility Remote Method Invocation Runtime Environment Service Component Architecture System Measurement Facility System Modification Program/Extended Simple Network Management Protocol Service-oriented architecture Structured Query Language Secure Shell Secure Sockets Layer System Service Monitor Synthetic Transaction Investigator System Complex Transmission Control Protocol/Internet Protocol Transaction User Exit Time Sharing Option Universal Database Universal Markup Language Universal Resource Identifier Universal Resource Locator Workload Manager Web Response Monitor Web Services Definition Language Extensible Markup Language
200
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
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 Administrators Guide, SC32-1905 IBM Tivoli Composite Application Manager for Response Time Tracking V6.1 Administrators 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 Operators Guide, SC32-9508
202
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 Users Guide, SC32-9507 IBM Tivoli Composite Application Manager for WebSphere: Installing and Configuring the Tivoli Enterprise Monitoring Agent, SC32-1801 IBM Tivoli Composite Application Manager for WebSphere: Tivoli Enterprise Monitoring Agent Problem Determination Guide, SC32-1800 IBM Tivoli Composite Application Manager for SOA publications: Configuring IBM Tivoli Composite Application Manager for SOA on z/OS, SC32-9493 IBM Tivoli Composite Application Manager for SOA Installation and Users Guide, GC32-9492 IBM Tivoli Composite Application Manager for SOA Program Directory, GI11-4087 IBM Tivoli Composite Application Manager for SOA Release Notes, GI11-4096 IBM Tivoli Composite Application Manager for SOA: Installing and Troubleshooting IBM Web Services Navigator, GC32-9494 IBM Tivoli Composite Application Manager for Response Time publications: IBM Tivoli Composite Application Manager for Client Response Time Users Guide Version 6.2, SC23-6332 IBM Tivoli Composite Application Manager for Web Response Time Users Guide Version 6.2, SC23-6333 IBM Tivoli Composite Application Manager for Robotic Response Time Users Guide Version 6.2, SC23-6334 IBM Tivoli Composite Application Manager for User Response Time Dashboard Users Guide Version 6.2, SC23-6335 IBM Tivoli Composite Application Manager for Response Time Problem Determination Guide Version 6.2, GI11-8061 IBM Tivoli Composite Application Manager for Web Resources publications: IBM Tivoli Composite Application Manager for Web Resources: J2EE Data Collector Installation Guide, GC23-6179 IBM Tivoli Composite Application Manager for Web Resources: WebSphere Distributed Data Collector Installation Guide, GC23-6180
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 Administrators 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 Users 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 Users Guide, SC32-9459 Introducing IBM Tivoli Monitoring, GI11-4071
204
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/
205
IBM Tivoli Monitoring Workspace Package for IBM Tivoli Composite Application Manager for Internet Service Monitoring http://catalog.lotus.com/topal?NavCode=1TW10TM31 Technote FAQ Is there a relatively easy way to estimate the amount of disk space needed for your database? http://www.ibm.com/support/docview.wss?rs=2344&context=SS3PGL&dc=DB5 20&q1=database&uid=swg21250907&loc=en_US&cs=utf-8&lang=en Open Group Web site for Application Response Management (ARM) http://www.opengroup.org/arm Microsoft link for InstallShield error http://support.microsoft.com/default.aspx?scid=kb;en-us;295278 Microsoft Windows Services for UNIX http://www.microsoft.com/technet/interopmigration/unix/sfu/default.mspx Java specification for JAX-RPC: JSR-000109 Implementing Enterprise Web Services http://www.jcp.org/aboutJava/communityprocess/final/jsr109/ BEA WebLogic interceptor information http://e-docs.bea.com/wls/docs81/webserv/interceptors.html Eclipse Web site http://www.eclipse.org
How to get IBM Redbooks publications

You can search for, view, or download IBM Redbooks publications, Redpapers, Technotes, draft publications and additional materials, as well as order hardcopy IBM Redbooks publications, at this Web site: ibm.com/redbooks
Help from IBM

IBM Support and downloads ibm.com/support
206
IBM Global Services ibm.com/services
207
208
Index
A
application server 27 archive agent 29 attribute 51 Web Services Navigator flow pattern view 25
G
global publishing server 29
B
back-end system 187 BCM 32 Byte Code Modification See BCM
I
IBM HTTP Server 29 IMS 28, 45 TRADERBL 188 IMS data collector 40 ITCAM for Response Time Tracking components 33 management agent 37 management server 34 store and forward agent 36 Tivoli Enterprise Monitoring Agent 41 ITCAM for SOA 23 action 87 components 21 data collector 22 features 20 filters 87 metrics 51 server-side interception 23 Tivoli Enterprise Monitoring Agent 22 viewer 22 workspace 20 ITCAM for WebSphere data collector 30 database 30 managing server 28
C
CandleMonitor 46 CICS 28, 45 TRADERBL 188 TRADERPL 188 CICS data collector 40 client-side interception 23 commands tapmagent 39 cross-memory services 31 CSMI 188
D
data collector 28 CICS 28 IMS 28 J2EE 28 database connection pools 27 DB2 UDB 29 Defined View 43 discover feature 43
E
EJB 27 EJB usage 27 Enterprise JavaBeans See EJB
J
J2EE 28 J2EE application server 27 Java API for XML-based Remote Procedure Call See JAX-RPC Java Virtual Machine Tool Interface See JVMTI JAX-RPC 2122 JAX-RPC handler 23
F
flow pattern view
209
JVM 37 JVM thread pools 27 JVMTI 26
publishing servers 29
Q
queue manager 4344 configuration event queue 44 like-named parameters 44 node name 45 queue-sharing group 46
K
kernels 29
M
managed system name 45 management agent 40 ARM agent 39 difference 37 generic window component 38 ITCAM for Response Time Tracking 37 J2EE instrumentation 39 mainframe 39 Quality of Service 38 management server 34 clustered 35 managing server 2728 archive agent 29 global publishing server 29 kernels 29 message dispatcher 29 publishing servers 29 Mediation Configuration 20 message arrival 20 message dispatcher 29 metrics 51 monitoring file 43
R
Redbooks Web site 206 Contact us xi
S
SCA 21, 25 server-side interception 23 Service Component Architecture See SCA service extension 23 Service Management Agent 20 Service Management Agent Environment 20 service topology view 25 service-oriented architecture See SOA SET AGENT 45 SET APPL 45 SET CHANNEL 44 SET EVENTLOG 44 SET EVENTQIN 44 SET EVENTQOUT 45 SET GROUP 44 SET MANAGER 44 SET MQIMONITOR 46 SET QACCESS 44 SET QSG 46 SET QSG command 46 SET QUEUE 44 Simple Network Management Protocol See SNMP SNMP 29 SOA 20 SOAP 2123 STI 38 store and forward agent 36 Sun Solaris 29 Synthetic Transaction Investigator See STI
N
namelists 42
O
OCTIGATE database 30 Oracle 29 OS/400 monitors 44
P
PERFORM INCLUDE 45 PERFORM STARTMON 45 Performance Management Interface See PMI PMI 27 primary workspace 51
210
T
tapmagent 3940 TRAD 188 Trader BuySellServlet 185 company database 187 customer database 187 GetQuotesServlet 184 ListCompanyServlet 183 login.html 183 LogoutServlet 185 TraderClientLogin 186 TraderClientMain 186 TraderClientQuote 187 TRADERBL 188 TRADERPL 188 transaction flows view 25
Z
z/OS monitors 44
U
UML 25 Universal Markup Language See UML Universal Markup Language (UML) 25 UNIX 44
W
Web Response Monitor See WRM Web Services Definition Language See WSDL Web Services Navigator 22, 24 service topology view 25 transaction flows view 25 WebSphere Application Server Node Deployment 35 WebSphere Caching Proxy 36 WebSphere Edge Server 35 WebSphere MQ application 44 data 43 monitoring agent 46 object 45 OMEGAMON Monitoring Agent 44 WebSphere MQ-based z/OS applications 45 workspace 20 WRM 39 WSDL 2122
Index
211
212
Back cover

Discusses SOA performance and availability management
Service-oriented architecture (SOA) is a major new trend for application architecture. It allows you to build applications as components as defined using a Web Services Description Language (WSDL) file. You can implement applications in different servers, even different platforms. You can modify application components Describes mediation and workflow logic easily in execution, allowing a flexible application structure. Implementation of the client and the server scenarios with ESB side is also masked by the use of enterprise service bus, which and message broker allows a different server implementation to be provided without the need to modify the client, or, different clients can use the same Integrates ITCAM server implementation.
Redpaper
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
and other Tivoli solutions
The highly flexible and distributed nature of SOA-based applications is its primary strength and the source of its appeal. However, when a problem arises, this flexible nature also causes a greater problem in pinpointing the source of problem. SOA also requires a disciplined management effort to ensure that operational changes do not disrupt overall availability. The IBM Tivoli Composite Application Manager (ITCAM) family of products directly assists services specialists who implement and manage distributed applications. We illustrate the management needs for SOA-based applications and demonstrate how Tivoli products can address these application environment needs. The overall solution that we use includes ITCAM for SOA, ITCAM for WebSphere, ITCAM for Response Time Tracking, OMEGAMON XE for Messaging, and Tivoli Business Service Manager.
For more information: ibm.com/redbooks
REDP-4318-00

Managing An SOA Environment With Tivoli Redp4318

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Managing An SOA Environment With Tivoli Redp4318

Uploaded by

Copyright:

Available Formats

Front cover

Managing an SOA Environment with Tivoli

Budi Darmawan Pradeep Nambiar Prem Lall Ravinder Gummadavelli

First Edition (April 2008) This edition applies to:

Copyright IBM Corp. 2008. All rights reserved.

Managing an SOA Environment with Tivoli

Managing an SOA Environment with Tivoli

Copyright IBM Corp. 2008. All rights reserved.

Managing an SOA Environment with Tivoli

The team that wrote this paper

Copyright IBM Corp. 2008. All rights reserved.

Managing an SOA Environment with Tivoli

Become a published author

Managing an SOA Environment with Tivoli

Introduction to SOA management

Copyright IBM Corp. 2008. All rights reserved.

1.1 Introduction to SOA

1.2 SOA application principles

Managing an SOA Environment with Tivoli

Chapter 1. Introduction to SOA management

1.3 SOA constructs and components

Managing an SOA Environment with Tivoli

1.4 SOA governance

Chapter 1. Introduction to SOA management

1.4.1 Web Services life cycle governance

Managing an SOA Environment with Tivoli

1.4.2 Web Services life cycle management

1.5 SOA management considerations

Chapter 1. Introduction to SOA management

Managing an SOA Environment with Tivoli

1.6 Users of SOA management

Chapter 1. Introduction to SOA management

Managing an SOA Environment with Tivoli

Figure 1-1 Situation event console

1.6.2 Middleware or application subject matter expert

Chapter 1. Introduction to SOA management

1.6.3 Performance analyst

1.6.4 System administrator

Managing an SOA Environment with Tivoli

Chapter 1. Introduction to SOA management

Figure 1-2 Administer user dialog

1.6.5 Enterprise system management architect

Managing an SOA Environment with Tivoli

1.6.6 Web Services application developer

1.6.7 Business executives

Chapter 1. Introduction to SOA management

1.7 Management needs for the SOA environment

1.7.1 Web Services metric data collection

Managing an SOA Environment with Tivoli

1.7.2 Web Services troubleshooting

1.7.3 Displaying data

Chapter 1. Introduction to SOA management

1.7.4 Mediation management

Managing an SOA Environment with Tivoli

Tivoli application management products

Copyright IBM Corp. 2008. All rights reserved.

2.1 ITCAM for SOA

2.1.1 Product features

Managing an SOA Environment with Tivoli

2.1.2 Product components

Chapter 2. Tivoli application management products

Monitoring agent data collector