Active6 years, 2 months ago

DaveDave

chebetoschebetos

IBM ® WebSphere ®
Front cover
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide End-to-end planning for WebSphere Application Server V8.5.5 WebSphere concepts and best practices Addresses distributed and z/OS platforms
Fabio Albertoni Jan Bajerski Davide Barillari Libor Cada Susan Hanson Guo Liang Huang Rispna Jain
ibm.com/redbooks
Gabriel Knepper Mendes Catalin Mierlea Shishir Narain Sergio Pinto Jennifer Ricciuti Carla Sadtler Christian Steege
International Technical Support Organization WebSphere Application Server V8.5 Concepts, Planning, and Design Guide August 2013
SG24-8022-01
Note: Before using this information and the product it supports, read the information in “Notices” on page xvii.
Second Edition (August 2013) This edition applies to Version 8, Release 5, Modification 5 of WebSphere Application Server. Note: This book is based on a pre-GA version of a product and may not apply when the product becomes generally available. We recommend that you consult the product documentation or follow-on versions of this redbook for more current information.
© Copyright International Business Machines Corporation 2012, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii Stay connected to IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii Chapter 1. Introduction to WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Application server infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 WebSphere Application Server packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.1 WebSphere Application Server Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.2 WebSphere Application Server (Base) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.3 WebSphere Application Server Network Deployment. . . . . . . . . . . . . . . . . . . . . . . 4 1.2.4 WebSphere Application Server for z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.5 WebSphere Application Server for Developers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.6 WebSphere Application Server Hypervisor Edition. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.7 WebSphere Application Server Liberty Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.8 WebSphere Application Server Community Edition . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3 WebSphere Application Server profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.1 Full WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2 Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.3 Profile capability comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Programming model support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5 Managing WebSphere Application Server environments . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.2 Administration in a full profile environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.3 Administration in a Liberty profile environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.6 Intelligent management features (full profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.6.1 Enabling Intelligent Management in the web server plug-in . . . . . . . . . . . . . . . . . 12 1.6.2 Support for both full and assisted lifecycle servers . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7 Clustering application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.1 Clustering application servers in the full profile. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.7.2 Clustering application servers in the Liberty profile. . . . . . . . . . . . . . . . . . . . . . . . 14 1.8 Securing applications and administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.8.1 Securing the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.9 Interoperability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.9.1 Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.9.2 Messaging, connectivity, and transaction management . . . . . . . . . . . . . . . . . . . . 17 1.9.3 Mapping services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.9.4 Application client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.10 Application development and deployment tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.10.1 IBM Assembly and Deploy Tools for WebSphere Administration . . . . . . . . . . . . 19 1.10.2 Rational Application Developer for WebSphere Software V9 . . . . . . . . . . . . . . . 19 1.10.3 WebSphere Application Server Developer Tools for Eclipse . . . . . . . . . . . . . . . 20 1.10.4 Enhancements to the tools for V8.5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.11 Advanced tools and extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.11.1 WebSphere Customization Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 © Copyright IBM Corp. 2012, 2013. All rights reserved.
iii
1.11.2 Web 2.0 and Mobile Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.11.3 Liberty Extensions System Programming Interface (SPI) . . . . . . . . . . . . . . . . . . 21
iv
Chapter 2. Integration with other products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 IBM Tivoli Access Manager for e-business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Features of Tivoli Access Manager for e-business . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 IBM Tivoli Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Features of Tivoli Directory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Security, networking, and topology considerations . . . . . . . . . . . . . . . . . . . . . . . . 2.3 IBM WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Features of IBM WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Connecting the full profile to WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Connecting the Liberty profile to WebSphere MQ. . . . . . . . . . . . . . . . . . . . . . . . . 2.4 IBM WebSphere Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Features of IBM WebSphere Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 IBM WebSphere DataPower Appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 DataPower appliance models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 IBM DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Features of IBM DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 IBM Tivoli Composite Application Manager for WebSphere . . . . . . . . . . . . . . . . . . . . . 2.7.1 Features of ITCAM for WebSphere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.3 Architecture of ITCAM for WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 IBM WebSphere Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.1 Features of WebSphere Portal Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 IBM Tivoli Workload Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.1 Features of Tivoli Workload Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10 IBM WebSphere eXtreme Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10.1 Features of WebSphere eXtreme Scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10.2 Integration with WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . .
23 24 24 24 27 27 28 28 29 29 29 30 32 32 32 33 34 34 37 37 38 38 39 39 39 40 41 41 42 42 42 43 44 44 45
Chapter 3. An overview of the full profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Core concepts of WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Containers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.5 Nodes, node agents, and node groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.6 Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.7 Deployment manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Additional concepts for WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Administrative agent in a stand-alone application server environment . . . . . . . . . 3.2.2 Job manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Web servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Web server plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47 48 48 52 53 57 60 62 63 64 64 65 66 69
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
3.2.5 Proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.6 Generic servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7 The centralized installation manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.8 Intelligent runtime provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.9 Intelligent Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.10 Batch processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Server configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Single cell configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Flexible management configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Security types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Service integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Default messaging provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Service integration bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.3 Web Services Gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Clusters and high availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Vertical cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Horizontal cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 Mixed cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.4 Mixed-node versions in a cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.5 Dynamic cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.6 Cluster workload management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.7 High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.8 Core groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Run times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1 Distributed platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69 71 72 74 74 75 75 75 77 79 80 81 82 83 83 83 84 85 86 86 87 88 88 88 90 90 91 91 91
Chapter 4. An overview of the Liberty profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 4.1 Introduction to the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 4.1.1 The Liberty profile architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.1.2 The Liberty profile feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.2 Installing the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.3 Configuring the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.3.1 Liberty profile configuration characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.3.2 Simplified configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 4.3.3 Flexible configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.3.4 Dynamic configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.4 Administering the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.4.1 Administering the Liberty profile configuration files. . . . . . . . . . . . . . . . . . . . . . . 102 4.4.2 Configuring the Liberty profile with a web server plug-in . . . . . . . . . . . . . . . . . . 102 4.4.3 Capturing the debug information for a Liberty profile server . . . . . . . . . . . . . . . . 102 4.4.4 Packaging a Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.4.5 Administering Liberty servers in a collective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 4.4.6 Clustering Liberty servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.4.7 Administering a Liberty profile on z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.5 Developing and deploying a Liberty profile application . . . . . . . . . . . . . . . . . . . . . . . . 107 4.6 The Liberty profile application security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.6.1 Authentication and authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.6.2 Security features for programming models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.6.3 Administrative security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Contents
v
vi
4.7 The Liberty profile deployment topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Example topology 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.2 Example topology 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.3 Example topology 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.4 Example topology 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.5 Example topology 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.6 Example topology 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Binary logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.2 Timed operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.3 Performance monitoring using MBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.4 Using the OSGi console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
109 111 111 112 112 113 113 114 115 115 116 118
Chapter 5. Intelligent Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Introduction to Intelligent Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Virtualization, autonomic, and cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Autonomic computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Intelligent routing and dynamic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Key components of dynamic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Autonomic managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Dynamic workload management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Request flow prioritization by using service policies . . . . . . . . . . . . . . . . . . . . . . 5.4.2 Enabling dynamic clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Health management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Health policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 Health controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.3 Planning for health monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Application edition management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Key features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.4 Maintenance modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 Performance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Workload management with dynamic clusters . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.2 Overload protection monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8 Planning for hosting dynamic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.1 Topology considerations for the ODR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8.2 Monitoring dynamic operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119 120 121 121 124 127 127 128 131 132 133 133 134 134 137 137 138 138 139 140 143 144 144 145 145 146 147
Chapter 6. WebSphere Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Overview of WebSphere Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 WebSphere Batch key features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Main concepts of batch processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3 Application server run time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 WebSphere Batch programming models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Transactional batch programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Compute-intensive programming model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 WebSphere Batch components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Job scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Batch container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.3 xJCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
149 150 150 151 154 154 155 156 157 158 158 159
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
6.3.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.5 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.6 Batch database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.7 Batch toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Batch workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5 New features in WebSphere Application Server V8.5 for WebSphere Batch . . . . . . . 6.5.1 Parallel batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.2 Enterprise integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.3 Cobol support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.4 CommandRunner utility job step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
162 163 164 164 165 167 167 169 171 171
Chapter 7. Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Infrastructure planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Environment planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2 High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3 Load balancing and failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.5 Infrastructures using a Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Sizing the infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Sizing static infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Sizing dynamic infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.1 Environment analysis for monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 Performance and fault tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.3 Alerting and problem resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.1 Risk analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.2 Recovery strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.3 Backup plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.4 Recovery plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.5 Update and test process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7 Cloud infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.1 Public cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.2 Private cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
173 174 175 176 177 179 180 181 182 182 183 183 184 184 186 186 186 186 187 187 187 188 189 189 189 189
Chapter 8. Topologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Load balancers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 Reverse proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3 Domain and protocol firewall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.4 Web servers and WebSphere Application Server plug-in . . . . . . . . . . . . . . . . . . 8.1.5 On-demand routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.6 Application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.7 Directory and security services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.8 Messaging infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.9 Data layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Topology selection criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
191 192 192 192 194 194 195 195 196 196 196 196 197 197 200
Contents
vii
viii
8.2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.7 Manageability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.8 Application deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.9 Summary of topology selection criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Topologies in detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Stand-alone server topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Multiple stand-alone servers topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 Liberty profiles managed by a job manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.4 Vertical scaling topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.5 Horizontal scaling topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.6 Horizontal scaling topology with an IP sprayer . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.7 Reverse proxy topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.8 Topology with redundancy of multiple components . . . . . . . . . . . . . . . . . . . . . . 8.3.9 Heterogeneous cell topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.10 Multi-cell topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.11 Advanced topology using an administrative agent . . . . . . . . . . . . . . . . . . . . . . 8.3.12 Multi-cell star topology using Intelligent Management . . . . . . . . . . . . . . . . . . . 8.3.13 Intelligent Management enabled in the web server plug-in. . . . . . . . . . . . . . . . 8.3.14 Advanced topology using a job manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.15 Liberty profile server cluster topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
200 202 202 204 205 207 209 209 212 214 218 221 223 226 230 235 236 239 242 245 247 250
Chapter 9. Installation planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Installation features in WebSphere Application Server V8.5.5 . . . . . . . . . . . . . . . . . . 9.2 Selecting a topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Selecting hardware and operating systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4 Planning for disk space and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5 Naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6 IBM Installation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6.1 Benefits of Installation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6.2 Installation Manager repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7 Planning for WebSphere Application Server full profile . . . . . . . . . . . . . . . . . . . . . . . 9.7.1 File systems and directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.2 Single installation or multiple installations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.3 Installation method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.4 Installing updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.5 Profile creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.6 Naming convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.7 TCP/IP port assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.8 Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.9 IBM Support Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8 Planning for the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8.1 Java prerequisite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8.2 Installation method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8.3 Considerations for upgrading Liberty profile V8.5 to V8.5.5 . . . . . . . . . . . . . . . . 9.9 WebSphere Customization Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.10 Planning for Edge Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.10.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.10.2 Configuring the Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.10.3 Configuring the Caching Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.11 Planning for the DMZ secure proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.12 Planning for the HTTP server and plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
253 254 255 255 256 257 258 258 259 262 263 264 266 268 268 279 281 282 283 284 284 284 285 286 287 288 289 289 290 290
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
9.12.1 Web Server Plug-ins Configuration Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.12.2 Stand-alone server environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.12.3 Distributed server environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.13 IBM Support Assistant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.14 Installation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.15 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
291 292 296 300 301 301
Chapter 10. Performance, scalability, and high availability . . . . . . . . . . . . . . . . . . . . 10.1 Performance, scalability, and high availability features in WebSphere Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1 Default garbage policy gencon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 JVM garbage policy: Balanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.3 JVM garbage policy: Metronome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.4 High Performance Extensible Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.5 Disabling WebSphere MQ functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.6 Java Persistence API L2 cache provided by the dynamic cache provider . . . . 10.1.7 Collecting Java memory dumps and core files . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.8 Enabling request-level granularity of reliability, availability, and serviceability . 10.1.9 Resource workload routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.10 External high availability framework for service integration . . . . . . . . . . . . . . 10.1.11 High availability for a WebSphere MQ link . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 Scaling overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.2 Scaling the infrastructure components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.2 Application design issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.3 Establishing requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.4 Tips for setting up the test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.5 Load factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.6 Tuning approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.7 Production system tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.8 Application tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.9 WebSphere environment tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.10 System tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 WebSphere Application Server performance tools . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.1 WebSphere Performance Monitoring Infrastructure . . . . . . . . . . . . . . . . . . . . . 10.4.2 IBM Tivoli Performance Viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.3 WebSphere Application Server performance advisors . . . . . . . . . . . . . . . . . . . 10.4.4 Request metrics in WebSphere Application Server . . . . . . . . . . . . . . . . . . . . . 10.4.5 IBM Monitoring and Diagnostic Tools for Java . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.6 IBM Support Assistant Data Collector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.7 IBM HTTP Server monitoring page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 Workload management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.1 HTTP servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.2 DMZ proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.3 Application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.4 Clustering application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.5 Dynamic clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.6 Dynamic application placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.7 On-demand router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.8 Dynamic workload management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5.9 Scheduling tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
303 304 304 304 304 305 305 305 305 306 306 306 306 307 307 308 310 310 311 312 312 313 314 316 316 316 320 320 321 323 323 325 327 327 328 328 329 330 330 331 333 334 334 334 335
Contents
ix
10.6 High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.2 Hardware high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.3 Process high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.4 Data availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.5 Clustering and failover techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.6 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.6.7 WebSphere Application Server high availability features . . . . . . . . . . . . . . . . . 10.7 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7.1 Edge caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7.2 Dynamic caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.7.3 Data caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8 Session management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.8.2 Session support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.9 Data replication service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.10 Highly available deployment manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.11 Whole-system Analysis of Idle Time Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.12 Checklist for performance, scalability, and high availability . . . . . . . . . . . . . . . . . . 10.13 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
335 335 336 337 337 338 339 339 344 345 346 347 348 348 349 352 352 354 356 357
Chapter 11. Application development and deployment . . . . . . . . . . . . . . . . . . . . . . . 359 11.1 Application development and deployment features in WebSphere Application Server V8.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 11.2 Recently supported programming models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 11.2.1 Service Component Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 11.2.2 OSGi applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 11.2.3 Business-level applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 11.2.4 Session Initiation Protocol applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 11.2.5 Communications enabled applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 11.3 End-to-end lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 11.3.1 The Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 11.4 Development and deployment tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 11.4.1 IBM Assembly and Deploy Tools for WebSphere Administration . . . . . . . . . . . 372 11.4.2 WebSphere Application Server Developer Tools for Eclipse . . . . . . . . . . . . . . 372 11.4.3 Rational Application Developer for WebSphere Software V9 . . . . . . . . . . . . . . 373 11.4.4 IBM WebSphere Application Server for Developers . . . . . . . . . . . . . . . . . . . . . 374 11.4.5 Monitored directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 11.4.6 Which tools to use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 11.5 Naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 11.5.1 Naming for applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 11.5.2 Naming for resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378 11.5.3 Naming resources in the Liberty profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 11.6 Source code management and collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 11.6.1 IBM Rational ClearCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 11.6.2 Concurrent Versions System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 11.6.3 Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 11.6.4 Rational Team Concert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 11.6.5 Choosing the correct tools to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 11.7 Automated build process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 11.7.1 Apache Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 11.7.2 Apache Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 11.7.3 Rational Build Forge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
x
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
11.8 Automated deployment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8.1 Application deployment in the Liberty profile. . . . . . . . . . . . . . . . . . . . . . . . . . . 11.9 Automated functional tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.10 Test environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.10.1 Development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.10.2 Integration test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.10.3 System test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.10.4 Acceptance test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.11 Managing application configuration settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.11.1 Classifying configuration settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.11.2 Managing the configuration settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.12 Planning for application upgrades in production . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.13 Mapping applications to application servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.14 Planning checklist for applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.15 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
386 386 387 388 389 390 391 391 392 392 393 396 397 398 398
Chapter 12. System management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1 System management features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Administrative security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Administration facilities of WebSphere Application Server . . . . . . . . . . . . . . . . . . . . 12.3.1 The administrative console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.2 WebSphere scripting client (wsadmin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.3 Task automation with Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.4 Administrative programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.5 Command-line tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.6 Administrative agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.7 Job manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.8 Monitored directory deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4 Automation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5 Configuration planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5.1 Configuration repository location and synchronization . . . . . . . . . . . . . . . . . . . 12.5.2 Configuring application and application server start behaviors. . . . . . . . . . . . . 12.5.3 Custom application configuration templates . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5.4 Planning for resource scope use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.6 Repository checkpoints service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.7 Change management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.7.1 Application update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.7.2 Changes in topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.7.3 Centralized installation manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8 Serviceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8.1 Log and traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8.2 Fix management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8.3 Backing up and restoring the configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8.4 MustGather documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8.5 IBM Support Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8.6 WebSphere Application Server Information Center . . . . . . . . . . . . . . . . . . . . . 12.9 Cross-component trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.10 Planning checklist for system management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
399 400 401 402 402 403 403 404 404 408 409 410 412 413 413 413 414 414 416 418 418 419 420 422 423 428 429 429 429 430 430 431
Chapter 13. Messaging and service integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.1 Messaging overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Full profile messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.1 Service integration technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
433 434 434 434
Contents
xi
xii
13.2.2 Messaging and service integration enhancements full profile in V8.5 . . . . . . . 13.2.3 Enhanced resiliency for the service integration bus . . . . . . . . . . . . . . . . . . . . . 13.2.4 Messaging options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.5 Messaging topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.6 Security and reliability of messaging features. . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.7 Planning checklist for messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3 Liberty profile messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.1 Liberty embedded JMS messaging provider. . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.2 Service integration bus messaging provider . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.3 WebSphere MQ messaging provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4 Service mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.1 Service mapping overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.2 Service maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
440 443 448 457 465 467 468 469 470 472 473 473 475
Chapter 14. Web services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1 Overview of web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2 Considerations when using web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.1 Business issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.2 Technical issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3 Web services architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.1 Components of the architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.2 How to use this architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4 Support for web services in WebSphere Application Server. . . . . . . . . . . . . . . . . . . 14.4.1 Supported standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.2 Service integration bus (full profile). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.3 UDDI registries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.4 Web services gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4.6 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.5 RESTful web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.5.1 Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.5.2 Key Ajax technologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.5.3 Support for RESTful web services in WebSphere Application Server . . . . . . . 14.6 Planning checklist for web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.7 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
481 482 483 483 483 484 484 486 492 492 492 493 493 494 494 495 495 496 497 498 498
Chapter 15. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1 New security features in WebSphere Application Server V8.5 . . . . . . . . . . . . . . . . . 15.1.1 Audit changes in configuration repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.2 SAML Web SSO Post binding profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.3 Security standards support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.4 Enhanced security in the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2 Security in WebSphere Application Server full profile . . . . . . . . . . . . . . . . . . . . . . . . 15.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.1 Lightweight Third-Party Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.2 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.3 Rivest-Shamir-Adleman algorithm token authentication . . . . . . . . . . . . . . . . . . 15.3.4 Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.5 Simple and Protected GSSAPI Negotiation Mechanism. . . . . . . . . . . . . . . . . . 15.3.6 Java Authentication and Authorization Service. . . . . . . . . . . . . . . . . . . . . . . . . 15.3.7 Java Authentication Service Provider Interface . . . . . . . . . . . . . . . . . . . . . . . . 15.3.8 Trust associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.9 Web Services Security SAML Token Profile . . . . . . . . . . . . . . . . . . . . . . . . . . .
499 500 500 500 502 503 503 506 507 508 509 509 510 510 511 511 511
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
15.4 User registries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.4.1 Local operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.4.2 Stand-alone Lightweight Directory Access Protocol . . . . . . . . . . . . . . . . . . . . . 15.4.3 Custom registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.4.4 Federated repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.5 User roles in WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.6 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.6.1 Administrative security roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.6.2 Application security roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.7 Internal and external trusted relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.7.1 Secure communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.7.2 SSL in cell management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.7.3 External trusted relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.8 Security trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.9 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.10 Securing the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.10.1 SSL configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.10.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.10.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.11 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
512 513 513 514 515 515 516 516 519 522 523 524 525 525 525 528 529 529 530 530
Chapter 16. WebSphere Application Server for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . 16.1 WebSphere Application Server structure on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.1 Value of WebSphere Application Server for z/OS. . . . . . . . . . . . . . . . . . . . . . . 16.1.2 Benefits of using WebSphere Application Server for z/OS . . . . . . . . . . . . . . . . 16.1.3 Common concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.4 The location service daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.5 Structure of an application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.6 Runtime processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.7 Workload management for WebSphere Application Server for z/OS . . . . . . . . 16.1.8 WebSphere Application Server on z/OS and 64-bit mode . . . . . . . . . . . . . . . . 16.1.9 XCF support for WebSphere high availability manager . . . . . . . . . . . . . . . . . . 16.1.10 z/OS Fast Response Cache Accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.11 Thread Hang Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2 Functions in WebSphere Application Server for z/OS V8.5 . . . . . . . . . . . . . . . . . . . 16.2.1 WebSphere optimized local adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.2 Resource workload routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.3 High Performance Extensible Logging and Cross Component Trace. . . . . . . . 16.2.4 Distributed identity mapping using SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3 Installing WebSphere Application Server for z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.1 Installation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.2 Installation considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.3 Function modification identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.4 Install repositories with SMP/E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.5 Copy repositories from media (DVD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.6 Creating a product image with Installation Manager for z/OS. . . . . . . . . . . . . . 16.3.7 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4 System programmer considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.1 WebSphere Application Server settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.2 Java virtual machine settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.3 Basic WLM classifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.4 Address space identifier reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.5 Deprecated features WebSphere Application Server for z/OS . . . . . . . . . . . . .
531 532 532 533 534 534 535 537 539 542 544 545 547 548 548 550 554 554 556 556 557 559 560 560 560 561 564 564 565 567 568 568
Contents
xiii
xiv
16.4.6 Jacl stabilized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4.7 Application profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.5 Planning checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.6 Intelligent Management and WebSphere Batch on z/OS . . . . . . . . . . . . . . . . . . . . . 16.6.1 Intelligent Management on z/OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.6.2 WebSphere Batch on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.7 The Liberty profile on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.7.1 Architecture of Liberty profile on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.7.2 Unique features of the Liberty profile on z/OS . . . . . . . . . . . . . . . . . . . . . . . . . 16.7.3 Collectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.8 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
568 568 569 570 570 570 572 572 573 574 574
Chapter 17. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.1 Migration features in WebSphere Application Server V8.5 . . . . . . . . . . . . . . . . . . . . 17.1.1 Configuration Migration Management Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.1.2 Cross platform migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.1.3 Enhanced z/OS Migration Management Tool . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Migration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.3 Migration plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.4 Application development migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5 Infrastructure migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.1 Coexistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.2 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.3 Mixed-version-cell support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.4 Configuration Migration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.5 Properties files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.6 Product configuration migration scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5.7 Scripts migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6 Migration considerations for WebSphere Application Server for z/OS . . . . . . . . . . . 17.6.1 Migration and coexistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6.2 General considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6.3 Overview of the migration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6.4 z/OS Migration Management Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6.5 Migration Management Tool script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6.6 Migration jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.6.7 Migration considerations for 64-bit mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
577 578 578 578 578 578 579 580 581 581 581 582 582 584 584 590 590 590 591 592 592 599 601 602
Appendix A. Sample topology walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topology review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing Load Balancer (Server A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the HTTP servers (Servers B and C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a deployment manager (Server D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the application servers (Servers D and E) . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling the WebSphere configuration service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying the applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing the topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Normal functioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . One web server down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
605 606 607 608 608 609 609 610 611 611 612 612 613 614 614 616
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
One Websphere Application Server node down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617 Appendix B. Sample topology using the job manager and a Liberty profile. . . . . . . 619 Sample topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 Installing the HTTP server on Server A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620 Installing the WebSphere job manager on Server B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621 Installing the Liberty profiles, servers, and applications on servers B, C, and D . . . . . . . . 622 Install a Java Runtime Environment on Servers B, C, and D . . . . . . . . . . . . . . . . . . . . 622 Create a compressed file that contains the servers and applications . . . . . . . . . . . . . . 622 Deploy the Liberty profiles by using the job manager . . . . . . . . . . . . . . . . . . . . . . . . . . 622 Generating a common plug-in configuration for the Liberty profiles and deploying it to the HTTP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629 Appendix C. Sample topology for maintenance and troubleshooting using the Liberty profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631 Sample topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632 Configuring the Liberty profile as a web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632 Creating a pattern for REST connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633 Creating a pattern for JDBC troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634 Including a new feature in default configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635 Appendix D. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Locating the web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the web material. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Downloading and extracting the web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
637 637 637 637
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
639 639 639 640 642
Contents
xv
xvi
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
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 grant 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 websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites 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. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2012, 2013. All rights reserved.
xvii
Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: AIX® alphaWorks® BladeCenter® Build Forge® CICS® ClearCase® ClearCase MultiSite® ClearQuest® CloudBurst® Cognos® DataPower® DB2® developerWorks® Domino® Global Technology Services® GPFS™ IBM® IBM SmartCloud®
IMS™ InfoSphere® Jazz™ Language Environment® Lotus® MVS™ Parallel Sysplex® Passport Advantage® PowerHA® PR/SM™ Processor Resource/Systems Manager™ PureApplication™ pureQuery® pureScale® pureXML® RACF® Rational®
Rational Rose® Rational Team Concert™ Redbooks® Redbooks (logo) ® RequisitePro® Resource Measurement Facility™ RMF™ Sametime® System i® System z® Tivoli® VTAM® WebSphere® z/OS® z/VM® zEnterprise® zSeries®
The following terms are trademarks of other companies: Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, or service names may be trademarks or service marks of others.
xviii
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Preface This IBM® Redbooks® publication provides information about the concepts, planning, and design of IBM WebSphere® Application Server V8.5 environments. The target audience of this book is IT architects and consultants who want more information about the planning and design of application-serving environments, from small to large, and complex implementations. This book addresses the packaging and features in WebSphere Application Server, and highlights the most common implementation topologies. It provides information about planning for specific tasks and components that conform to the WebSphere Application Server environment. Also in this book are planning guidelines for Websphere Application Server and Websphere Application Server Network Deployment on distributed platforms. It also includes guidelines for WebSphere Application Server for IBM z/OS®. This book contains information about migration considerations when moving from previous releases. This book has been updated with the new features introduced with WebSphere Application Server V8.5.5.
Authors This book was produced by a team of specialists from around the world working at the International Technical Support Organization, Raleigh Center. Fabio Albertoni is a Senior IT Specialist working in Integrated Technology Delivery SSO in Hortolandia, Brazil. He has sixteen years of experience in the IT and banking industries. He has spent the last twelve years developing and implementing integrated solutions using WebSphere Application Server and MQ Series. He holds a degree in Data Processing from FATEC University of Ourinhos, and a Master’s degree in Computer Engineering from Instituto de Pesquisas Tecnologicas of Sao Paulo, Brazil. Jan Bajerski is WebSphere Connectivity IT Specialist in Software Group Community of Practice in CEE region, and has been working in the IT industry for 11 years. Previously, he worked in IBM Software Services for WebSphere in Poland, supporting customers in implementing solutions using WebSphere Application Server, WebSphere MQ, and WebSphere Message Broker. He has a BSc degree from Warsaw University of Technology (Poland). Davide Barillari is a Certified IT Specialist working for IBM Global Technology Services® in Italy. He joined IBM in 1996, and worked for three years with IBM Education as a z/OS instructor. He has 12 years of experience in the IBM Technical Support, with a deep knowledge of IBM zSeries® architecture and distributed environments. His main areas of expertise are infrastructure design, implementation, maintenance, and debugging of the WebSphere environment. Davide is an IBM Certified Solution Developer as well an IBM Certified System Administrator for WebSphere Application Server, WebSphere Process Server, and SOA Solutions. Since 2011, he has been a Certified Solution Architect for Cloud Computing. He is accredited at the Senior level in the Product Services Profession, and is also Certified as Level 1 experienced IT Specialist by IBM Profession Office AITS. Davide is
© Copyright IBM Corp. 2012, 2013. All rights reserved.
xix
currently providing consulting services at customer sites in the banking sector on WebSphere Application Server for z/OS. Libor Cada is an IT Specialist working in Integrated Delivery Center SSO, in Brno, Czech Republic. He has eight years of experience in the IT and banking industries on mainframe IBM System z® and Linux on System z environments. He previously held the position of z/OS database and data communication (DB/DC) systems programmer for IBM CICS®, IBM DB2®, WebSphere MQ, and IBM IMS™ products. He currently supports clients from multiple locations in his role of WebSphere Application Server and z/OS certified System Programmer. Susan Hanson is a member of the WebSphere Application Server foundation development team. She has 22 years of experience in developing and delivering IBM software products across the WebSphere and IBM Tivoli® brands. Her current focus products are WebSphere Application Server, WebSphere Virtual Enterprise, and WebSphere eXtreme Scale. She focuses on release management, project management, and development process transformation. She also works part-time in the ITSO Redbooks organization as a project leader focused on the Growth Market Unit (GMU) areas. She is also part of the ITSO strategy team focused on enabling Industries and GMU. She holds a Bachelor’s degree in Computer Science from East Carolina University and a Master's degree in Computer Information Systems from The University of Phoenix. She is based in Research Triangle Park, North Carolina, and is temporarily working and residing in Shanghai, China. Guo Liang Huang is an experienced technical support engineer who is working for IBM WebSphere AIM group in the China Lab. He has five years of expertise in supporting IBM WebSphere Process Server. He has over 11 years of experience in developing, testing, and supporting software products. Guoliang holds Bachelor’s degrees in Computer Science from the Central South University of China. He also has expertise in SOA. Rispna Jain is a Technical Software Deployment Manager for the WebSphere suite of products in IBM Global Technology Services, and works with clients in North America. She has seven years of experience on WebSphere Application Server product development at IBM Software Group in various roles such as development, Level 3 support, and test. Rispna has also been a technical speaker for WebSphere Application Server related topics at various WebSphere conferences. She is an IBM Certified SOA associate and holds a Master of Technology degree in Computer Science. Gabriel Knepper Mendes is an IT Specialist for IBM ITS Delivery in Brazil. He has eighteen years as an IT professional working as a volunteer in many Open Source projects, like One Laptop per Child, and professionally with IBM partners. He joined IBM in 2011, starting as part of the Accelerated Value Program (AVP) team in a large banking customer in Brazil with a focus on IBM WebSphere brand products, such as WebSphere Application Server, IBM HTTP Server and others. He holds a Bachelor’s degree from Universidade do Sul de Santa Catarina – UNISUL, and a Master in Business Administration focused in Project Management from Fundação Getúlio Vargas – FGV. He is IBM Certified System Administrator on WebSphere Application Server Network Deployment from version 6.1 until version 8.0. Catalin Mierlea is a Middleware Software Specialist in IBM Romania. Catalin joined IBM in March, 2012, and has 10 years of experience in IT. His areas of expertise include WebSphere products, SOA, and software architecture. He specializes in the WebSphere Application Server, WebSphere Portal Server, WebSphere Process Server, and WebSphere Business Process Manager. Catalin has a Bachelor’s degree of Science in Automation Control and Computers, a Master’s of Science in Integrated Informatics Systems, and certifications in the IBM WebSphere products and in several Microsoft and Oracle complementary technologies. He has extensive industry knowledge and hands-on project experience in the banking sector.
xx
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Shishir Narain is an Open Group certified Master IT Specialist with deep skills in IBM middleware products. He works in IBM Software Services for WebSphere at India Software Lab, Gurgaon. He has 13 years of experience in developing solutions for multiple clients. He has led several end-to-end IT implementations based on SOA. He holds a Master of Technology degree from Indian Institute of Technology, Kanpur. Sergio Pinto is an IT Specialist working for Integrated Technology Delivery, Server Systems Operations, in Brazil. He has worked for IBM for 17 years. His areas of expertise include support in WebSphere Application Server for z/OS, and in WebSphere MQ and WebSphere Message Broker on distributed and z/OS environments. He holds a bachelor degree in business administration and accounting from Instituto Católico de Minas Gerais, Brazil. Jennifer Ricciuti is a Course Developer and Instructor in WebSphere Education. She has 15 years of experience in developing and delivering education courses on various WebSphere products, including WebSphere Application Server, WebSphere Process Server, WebSphere eXtreme Scale, and IBM Business Process Manager Advanced. Her areas of expertise include course design, development, and delivery. She holds a Bachelor’s degree in Computer Science from Point Park University. She works and resides in Pittsburgh, Pennsylvania. Carla Sadtler is a Consulting IT Specialist at the ITSO, Raleigh Center. She writes extensively about WebSphere products and solutions. Before she joined the ITSO in 1985, Carla worked in the Raleigh branch office as a Program Support Representative, supporting IBM MVS™ customers. She has a degree in Mathematics from the University of North Carolina at Greensboro. Christian Steege is an IT Architect within IBM Software Group Services for WebSphere in Zurich, Switzerland. He has more than 10 years experience in designing infrastructures and applications for IBM WebSphere Application Server, IBM WebSphere Business Process Management, IBM WebSphere Portal, and IBM WebSphere MQ. He implemented many of these infrastructures and applications at variety of Swiss IBM customers. Christian holds a Master’s degree in Information Management from the University of St. Gallen, Switzerland. Thanks to the following people for their contributions to this project: Deana Coble Tamikia Lee Linda Robinson Stephen Smith Margaret Ticknor Debbie Willmschen International Technical Support Organization, Raleigh Center Erik Altman Donald C. Bagwell Soloman J Barghouthi Michael Cheng Eric M Covener Dana Duffield David Follis Jeremy Hughes Chunlong Liang Jeff Mierzejewski Bill O’Donnell Gary Picher Brain Pulito
Preface
xxi
Sajan Sankaran Keith B Smith Christopher Vignola IBM US James Naish Alasdair Nottingham Rob Phippen IBM UK Yee-Kang Chang King Lam Ilene Seelemann Sam Wong Felix Wong IBM Canada Lohitashwa Thyagaraj IBM India Thanks as well to the teams who wrote these books: 0002 WebSphere Application Server V6.1: Planning and Design, SG24-7305 0002 WebSphere Application Server V7: Concepts, Planning and Design, SG24-7708 0002 IBM WebSphere Application Server V8 Concepts, Planning, and Design Guide, SG24-7957
Now you can become a published author, too! Here’s an opportunity to spotlight your skills, grow your career, and become a published author—all at the same time! Join an ITSO residency project and help write a book in your area of expertise, while honing your experience using leading-edge technologies. Your efforts will help to increase product acceptance and customer satisfaction, as you expand your network of technical contacts and relationships. Residencies run from two to six weeks in length, and you can participate either in person or as a remote resident working from your home base. 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 books to be as helpful as possible. Send us your comments about this book or other IBM Redbooks publications in one of the following ways: 0002 Use the online Contact us review Redbooks form found at: ibm.com/redbooks 0002 Send your comments in an email to: [email protected] 0002 Mail your comments to: xxii
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400
Stay connected to IBM Redbooks publications 0002 Find us on Facebook: http://www.facebook.com/IBMRedbooks 0002 Follow us on Twitter: http://twitter.com/ibmredbooks 0002 Look for us on LinkedIn: http://www.linkedin.com/groups?home=&gid=2130806 0002 Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks weekly newsletter: https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm 0002 Stay current on recent Redbooks publications with RSS Feeds: http://www.redbooks.ibm.com/rss.html
Preface
xxiii
xxiv
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
1
Chapter 1.
Introduction to WebSphere Application Server IBM WebSphere Application Server is the leading software foundation for service-oriented architecture (SOA) applications and services for your enterprise. With IBM WebSphere Application Server, you can build business-critical enterprise applications and solutions, and combine them with innovative new functions. The WebSphere Application Server family includes and supports a range of products that helps you develop and serve your business applications. You can use these products to build, deploy, and manage dynamic websites and other more complex solutions productively and effectively. This chapter introduces WebSphere Application Server V8.5 and V8.5.5 for distributed platforms and z/OS, and highlights other IBM software products that are related to WebSphere Application Server. This chapter includes the following sections: 0002 0002 0002 0002 0002 0002 0002 0002 0002 0002 0002
Application server infrastructure WebSphere Application Server packaging WebSphere Application Server profiles Programming model support Managing WebSphere Application Server environments Intelligent management features (full profile) Clustering application servers Securing applications and administration Interoperability Application development and deployment tools Advanced tools and extensions
© Copyright IBM Corp. 2012, 2013. All rights reserved.
1
1.1 Application server infrastructure WebSphere Application Server provides the environment to implement your middleware solutions. The core component is the application server runtime environment, which provides the infrastructure for executing the applications that run your business. An application server provides a set of services that business applications can use, and it serves as a platform to develop and deploy these applications. As business needs evolve, new technology standards become available. Since 1998, WebSphere Application Server has grown and adapted itself to new technologies and to new standards. It provides an innovative and cutting-edge environment so that you can design fully integrated, standards-based solutions. WebSphere Application Server is a key SOA building block, providing the role of the business application services (circled in Figure 1-1) in the SOA reference architecture.
Business services Supports enterprise business process and goals through businesses functional service
Development services Integrated environment for design and creation of solution assets
Interaction services
Process services
Information services
Enables collaboration between people, processes & information
Orchestrate and automate business processes
Manages diverse data and content in a unified manner
Management services Manage and secure services, applications & resources
Partner services
Business Application services
Connect with trading partners
Application Servers Build on a robust, services environment
Access services Facilitate interactions with existing information and application assets
Apps & Info assets
Enterprise Service Bus
Infrastructure services Optimizes throughput, availability and utilization
Figure 1-1 Position of business application services in an SOA reference architecture
From an SOA perspective, you can perform the following functions with WebSphere Application Server: 0002 0002 0002 0002 0002
Build and deploy reusable application services quickly and easily Run services in a secure, scalable, highly available environment Connect software assets and extend their reach Manage applications effortlessly Grow as your needs evolve, reusing core skills and assets
1.2 WebSphere Application Server packaging WebSphere Application Server is available on a range of platforms and in multiple packages to meet specific business needs. By providing the application server that is required to run specific applications, it also serves as the base for other WebSphere products and many other IBM software products. In addition to the application server component, each package contains an appropriate combination of complementary products, for example, IBM HTTP
2
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Server, IBM Assembly and Deploy Tools for WebSphere Administration, Edge Components, and other products. Because different application scenarios require different levels of application server capabilities, WebSphere Application Server is available in multiple packaging options. Although these options share a common foundation, each provides unique benefits to meet the needs of applications and the infrastructure that supports them. At least one WebSphere Application Server product fulfills the requirements of any particular project and its supporting infrastructure. As your business grows, the WebSphere Application Server family provides a migration path to more complex configurations. The following packages are available: 0002 0002 0002 0002 0002 0002 0002 0002
WebSphere Application Server Express WebSphere Application Server Base WebSphere Application Server Network Deployment WebSphere Application Server for z/OS WebSphere Application Server for Developers WebSphere Application Server Hypervisor Edition WebSphere Application Server Liberty Core WebSphere Application Server Community Edition
Figure 1-2 summarizes various WebSphere Application Server packaging options.
WebSphere Application Server for Developers Tools Edition +Liberty Profile
+WebSphere eXtreme Scale
Enables efficient development of innovative apps that will run on WebSphere Application Server in production. Available as a no-charge edition for the developer desktop and includes Eclipse adapters. Provide WebSphere Application Server and WebSphere Application Server Developer Tools editions as freely available for developer desktops and supported under production runtime licenses.
WebSphere Application Server Network Deployment
WebSphere Application Server Hypervisor Edition +Liberty Profile
+Intelligent Mgmt
Optimized to instantly run in VMware, PowerVM, zVM, and other server virtualization environments.
Tools Edition +Intelligent Mgmt
WebSphere Application Server for z/OS
+Liberty Profile +WebSphere eXtreme Scale
Delivers near-continuous availability, with advanced performance and intelligent management capabilities, for mission-critical applications. Full entitlement to eXtreme Scale.
+Liberty Profile +Intelligent Mgmt
+WebSphere eXtreme Scale
Takes full advantage of the z/OS Sysplex to deliver a highly secure, reliable, and resource efficient server experience. Entitlement to eXtreme Scale z/OS client.
WebSphere Application Server Tools Edition +Liberty Profile
+WebSphere eXtreme Scale
Provides secure, high performance transaction engines for moderately sized configurations with web tier clustering and failover across up to five application server profiles. Includes entitlement to eXtreme Scale for session caching and DynaCache.
WebSphere Application Server Express
WebSphere Application Server Liberty Core Liberty Profile Only (Web Profile)
WebSphere Application Server Community Edition
+Liberty Profile
A lightweight and low-cost Liberty profile based offering (not full-profile WebSphere Application Server), providing the capabilities to rapidly build and deliver web apps that do not require the full Java EE stack.
A low-cost, ready-to-go solution to build dynamic web sites and apps, including both Liberty and fullprofile WebSphere Application Server.
An open source-based small footprint foundation with no up-front acquisition costs.
Figure 1-2 WebSphere Application Server editions
Chapter 1. Introduction to WebSphere Application Server
3
In Figure 1-2 on page 3, you see the following differentiators among the packages, among others: 0002 Liberty profile: In addition to the full profile of WebSphere Application Server that offers a full range of programming and runtime options, a lightweight server called the Liberty profile is included with each package. In addition, a web profile only Liberty profile is available as a stand-alone package. 0002 Intelligent Management: This feature enables the run time to dynamically scale to meet service level agreements, and provides enhanced resiliency capabilities. 0002 WebSphere eXtreme Scale: This product provides elastic caching capabilities, consistent application and transaction response times, and linear scaling and fault tolerance features for data. 0002 Tools Edition: The Tools Editions are bundles of a WebSphere Application Server runtime and development tools. For more information about the Tools Editions, see: http://www-01.ibm.com/software/webservers/appserv/was/tools/ There are more differences in the licensing terms, features, and products included with each package.
1.2.1 WebSphere Application Server Express The WebSphere Application Server Express package provides a strong and affordable application server that is based on standards. It is a ready-to-go application foundation for single server, small scale deployments of dynamic web applications. When your business must grow, this package is easily integrated with more advanced versions of the WebSphere Application Server family. This package is also referred to as the Express package. For more information about WebSphere Application Server Express, see: http://www.ibm.com/software/webservers/appserv/express/
1.2.2 WebSphere Application Server (Base) The WebSphere Application Server package is the next level of server infrastructure in the WebSphere Application Server family. Although the WebSphere Application Server package is functionally equivalent to WebSphere Application Server Express (single-server environment), this package differs in packaging and licensing. This package is ideal for lightweight application solutions where cost and simplicity are key. This package is also referred to as the Base package. The Tools Edition bundle of this package includes WebSphere Application Server for production use and an unlimited number of licenses of IBM Rational® Application Developer and WebSphere Application Server Developer Tools for Eclipse for application development against the run time that is included in the bundle. For more information about the WebSphere Application Server (Base) package, see: http://www.ibm.com/software/webservers/appserv/was/
1.2.3 WebSphere Application Server Network Deployment WebSphere Application Server Network Deployment provides enterprises with advanced performance, management, and high availability for mission critical applications. It extends the base package of WebSphere Application Server to include key features that tend to be 4
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
more important in larger enterprises. In these environments, applications tend to service a larger client base, and more elaborate performance and high availability requirements are in place. These features include various functions for high availability and high scalability to ensure responsiveness to your application requests. This package is also referred to as the Network Deployment package. The Tools Edition bundle of this package includes WebSphere Application Server Network Deployment for production use, and an unlimited number of licenses of Rational Application Developer and WebSphere Application Server Developer Tools for Eclipse for application development against the run time included in the bundle. For more information about WebSphere Application Server Network Deployment, see: http://www.ibm.com/software/webservers/appserv/was/network/
1.2.4 WebSphere Application Server for z/OS IBM WebSphere Application Server for z/OS provides the same functions as Websphere Application Server Network Deployment, but adds key functions that use IBM z/OS qualities of service. You can use the z/OS qualities of service to optimize performance and provide continuous availability for mission-critical applications. WebSphere Application Server for z/OS includes capabilities to deliver business objectives that can help contain or reduce costs for business critical applications while also using the full capabilities of the z/OS platform. For more information about WebSphere Application Server for z/OS, see: http://www.ibm.com/software/webservers/appserv/zos_os390/
1.2.5 WebSphere Application Server for Developers The WebSphere Application Server for Developers package is functionally equivalent to the Base and Express packages, but it is licensed for development use only. It provides simplified and no-charge access to enable developers to build and test in the same environment that ultimately supports their applications. WebSphere Application Server for Developers is an easy-to-use development environment to build and test applications for customers who are not using IBM Rational Application Developer as their integrated development environment (IDE) for developing and testing their applications. The Tools Edition bundle of this package includes WebSphere Application Server for Developers and WebSphere Application Server Developer Tools for Eclipse. This bundle is for single user, development use only. For more information about WebSphere Application Server for Developers, see: http://www.ibm.com/software/webservers/appserv/developer/index.html
1.2.6 WebSphere Application Server Hypervisor Edition The WebSphere Application Server Hypervisor Edition is a self-contained virtual machine image that contains a guest operating system and WebSphere Application Server Network Deployment Version. You can run the virtual image on VMware ESX or ESXi hypervisors.
Chapter 1. Introduction to WebSphere Application Server
5
1.2.7 WebSphere Application Server Liberty Core New with V8.5.5, WebSphere Application Server Liberty Core is a lightweight and low-cost run time that provides the capabilities to rapidly build and deliver web applications that do not require the full Java EE stack. Liberty core is a production-ready run time that provides support for most of the features included with the Liberty profile that is included with the other WebSphere Application Server packages.
1.2.8 WebSphere Application Server Community Edition WebSphere Application Server Community Edition is a lightweight, Java EE application server. It offers the IBM distribution of Apache Geronimo, with broader platform support and enhanced documentation. WebSphere Application Server Community Edition is available at no charge. In Figure 1-2 on page 3, this edition is shown in a lighter print because it is not built on the same code base as the other WebSphere Application Server editions.
1.3 WebSphere Application Server profiles Beginning with V8.5, WebSphere Application Server provides two runtime profiles. Every WebSphere Application Server package includes both profile types.
1.3.1 Full WebSphere Application Server The run time that is traditionally available with the WebSphere Application Server packages is referred to as the full profile. The application serving run time (application server) provided with this profile is composed of a wide spectrum of runtime components that are always available when the server is started. The full profile provides support for Java Platform Enterprise Edition 6 (Java EE 6) and Enterprise OSGi technologies. In addition to the application servers, the full profile supports the creation of generic server definitions to configure other servers or processes needed to support the application server environment. More capabilities, such as clustering application servers for load balancing and high availability, vary depending on the WebSphere Application Server package.
1.3.2 Liberty profile In addition to the full profile, a new Liberty profile is included with each package, and with V8.5.5, it is also available as a stand-alone offering, called WebSphere Application Server Liberty Core. The Liberty profile is a simplified and lightweight run time for web applications. The small footprint and low resource usage, along with simplified configuration, makes the Liberty profile a good option for developers, and low resource test and production environments. It can be used to build and run web applications that do not require the full Java EE environment of traditional enterprise application server profiles. Any application that runs on the Liberty profile also runs on the full profile. The application-serving environment is configured with the correct level of capabilities that are required for the individual applications. You can use the Liberty profile to specify only those features required for the applications that are deployed, reducing the memory footprint 6
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
and increasing performance. The Liberty profile has a simplified installation and uses an easy-to-configure XML configuration file format. The Liberty profile is optimized for use in both development and production environments. Within the development environment, the Liberty profile supports the same systems as the base application server, plus Mac OS X operating system and Ubuntu. Enterprise qualities of service, such as security and transaction integrity, are enabled as required.
1.3.3 Profile capability comparison Table 1-1 provides information on the capabilities that are found in each profile for each edition. Table 1-1 Comparison of capabilities across WebSphere Application Server offerings Capability
Liberty Core
Express Liberty profile
Base Full profile
Liberty profile
Network Deployment / z/OS Full profile
Liberty
Full profile
Administration tools Administrative console
X X
X X
X
X
Optional provisioning and management through Network Deployment job manager
X
X
Collective Membership (1) and Management (2)
X(1)
X(1)
IBM HTTP Server routing (# of servers allowed)
2
2
2
25
25
Unltd
Unltd
Load balancing and failover with clusters (# of servers allowed)
2
2
2
5
5
Unltd
Unltd
X(1)
X
X
X(1,2)
Load balancing and high availability
Intelligent Management (dynamic cluster, Edition Management, Health Policy)
X
Installation options IBM Installation Manager install
X
X
Archive install option
X
X
X
X
X
X
X
X
X
External caching options WebSphere eXtreme Scale entitlement - container JVMs for distributed cache scenarios
Unltd (a)
Unltd (a)
Unltd (b)
Unltd (b)
Edge of Network Services
X
X
Liberty z/OS extensions
(z/OS)
Legend: a) HTTP Session Management and DynaCache only and b) WXS Client on z/OS only
Chapter 1. Introduction to WebSphere Application Server
7
1.4 Programming model support WebSphere Application Server supports a wide variety of programming models that provide flexibility and improve developer productivity. The following programming models are included: 0002 0002 0002 0002 0002 0002 0002 0002
Java EE 6 OSGi applications Web 2.0 Mobile WebSphere Batch XML Service Component Architecture (SCA) Communications Enabled Applications (CEA) Session Initiation Protocol (SIP)
Java is the technology that powers the WebSphere Application Server products. Over the years, many software vendors have collaborated on a set of server-side application programming technologies that help build web accessible, distributed, platform-neutral applications. These technologies are collectively branded as the Java Platform, Enterprise Edition (Java EE). They build on the foundation of the Java Platform, Standard Edition (Java SE). The Java EE platform provides specifications for developing multitier enterprise applications with Java. It consists of application technologies for defining business logic and accessing enterprise resources. These resources include databases, enterprise resource planning (ERP) systems, messaging systems, internal and external business services, and email servers. Java EE provides the following benefits: 0002 An architecture-driven application development approach that reduces maintenance costs and allows for construction of an IT infrastructure that can grow to accommodate new services. 0002 Application development standards, tools, and predefined rules improve productivity, and accelerate and shorten development cycles. 0002 Packaging, deployment, and management standards for enterprise applications facilitate systems and operations management. 0002 Industry-standard technologies allow clients to select among platforms, development tools, and middleware to power applications. 0002 Platform independence gives flexibility to create a single application and run it on multiple platforms, providing true portability to enterprise applications. 0002 Embedded support for Internet and web technologies allows applications to bring services and content to a wider range of users. It does not require proprietary integration. For more information about the Java EE specifications, see: http://www.oracle.com/technetwork/java/javaee/overview/index.html WebSphere Application Server provides the runtime environment for applications that conform to the Java Platform, Enterprise Edition 1.2, 1.3, 1.4, Java EE 5, and Java EE 6 specifications. Java EE 6 support adds the ability to start the Java compiler from within the Java virtual machine (JVM). It includes scripts with the ability to access application programming interfaces (APIs) within the JVM. By continuing to support previous levels of the Java specifications in addition to adding support for the new standards, WebSphere
8
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Application Server provides stability and reduced costs. It also provides the infrastructure to add the latest technologies into business applications. WebSphere Application Server provides optional support for the IBM WebSphere SDK Java Technology Edition Version 7.0. This IBM software development kit (SDK) provides a full-function SDK for Java that is compliant with Java SE 7 APIs. With IBM WebSphere SDK Java Technology Edition V7.0, you can develop and deploy Java applications at the Java 7 API level. It continues the “write once, run anywhere” Java paradigm at the Java API level. The SDK contains the Java Runtime Environment and other tools that enable developers to create Java applications. Table 1-2 shows the Java EE 6 technology support for the full profile, the Liberty profile shipped with the base, Express, and Network Deployment editions, and Liberty Core. Table 1-2 Java EE 6 technology support in WebSphere Application Server V8.5.5 Technology
Specification reference
Full profile
Liberty profile
Liberty Core
Java Platform, Enterprise Edition 6 (Java EE 6)
JSR 316
X
Java Platform, Enterprise Edition 6 Web Profile
JSR 316
X
X (8.5.5)
X
Java API for RESTful Web Services (JAX-RS) 1.1
JSR 311
X
X
X
Java APIs for WSDL 1.2
JSR 110
X
X
X
Implementing Enterprise Web Services 1.3
JSR 109
X
X (8.5.5)
Java API for XML-Based Web Services (JAX-WS) 2.2
JSR 224
X
X (8.5.5)
Java Architecture for XML Binding (JAXB) 2.2
JSR 222
X
X (8.5.5)
Web Services Metadata for the Java Platform
JSR 181
X
X (8.5.5)
Java API for XML-based RPC (JAX-RPC) 1.1
JSR 101
X
Java APIs for XML Messaging 1.3
JSR 67
X
Java API for XML Registries (JAXR) 1.0
JSR 93
X
SOAP with Attachments API for Java (SAAJ) 1.3
JSR 67
X
X (8.5.5)
Java Servlet 3.0
JSR 315
X
X
X
JavaServer Faces 2.0
JSR 314
X
X
X
JavaServer Pages 2.2/Expression Language 2.2
JSR 245
X
X
X
Express Language (EL) 2.2
JSR 245
X
X
X
Managed Beans 1.0
JSR 316
X
X
X
Standard Tag Library for JavaServer Pages (JSTL) 1.2
JSR 52
X
X
X
Debugging Support for Other Languages 1.0
JSR 45
X
X
X
Contexts and Dependency Injection for Java (Web Beans 1.0)
JSR 299
X
X (8.5.5)
X (8.5.5)
Dependency Injection for Java 1.0
JSR 330
X
X (8.5.5)
X (8.5.5)
Web services technologies
Web application technologies
Enterprise application technologies
Chapter 1. Introduction to WebSphere Application Server
9
Bean Validation 1.0
JSR 303
X
X
X
Enterprise JavaBeans 3.1
JSR 318
X
X (8.5.5) EJB Lite
X (8.5.5) EJB Lite
Interceptors 1.1
JSR 318
X
X (8.5.5)
Java EE Connector Architecture 1.6
JSR 322
X
Java Persistence 2.0
JSR 317
X
X
X
Common Annotations for the Java Platform 1.1
JSR 250
X
X
X
Java Message Service API 1.1
JSR 914
X
X (8.5.5)
Java Transaction API (JTA) 1.1
JSR 907
X
X
X
JavaMail 1.4
JSR 919
X
Java Authentication Service Provider Interface for Containers
JSR 196
X
Java Authorization Contract for Containers 1.3
JSR 115
X
Java EE Application Deployment 1.2
JSR 88
X
J2EE Management 1.1
JSR 77
X
Java API for XML Processing (JAXP) 1.3
JSR 206
X
X
X
Java Database Connectivity 4.0
JSR 221
X
X
X
Java Management Extensions (JMX) 2.0
JSR 255
X
X
X
JavaBeans Activation Framework (JAF) 1.1
JSR 925
X
X
X
Streaming API for XML (StAX) 1.0
JSR 173
X
X
X
Management and security technologies
Java EE-related specifications in Java SE
1.5 Managing WebSphere Application Server environments WebSphere Application Server has several topology management options to meet your demands. You can create basic scenarios with single application server environments, or multiple application servers that are administered from a single point of control. Furthermore, you can extend your environment as needs change. These application servers can be clustered to provide scalable and highly available environments.
1.5.1 Installation WebSphere Application Server uses IBM Installation Manager to manage the installation of the product. The IBM Installation Manager is a single installation tool that loads and installs product components from a structured collection of files known as a repository. IBM Installation Manager uses remote or local software repositories to install, modify, or update IBM software products, including WebSphere Application Server. Using the live repository, you can get an up-to-date list of available maintenance for your installed features and select exactly what maintenance to install. The Packaging Utility also allows you to create a central repository that is used for maintenance within the enterprise. This repository allows for greater administrative control and greater consistency across the installed users’ community.
10
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
In V8.5 the Liberty profile is in the same Installation Manager package as the full profile. New in V8.5.5, the Liberty profile is a separate Installation Manager package. Making the Liberty profile available as a separate installation package creates a smaller repository for installation. In a full profile environment, the centralized installation manager provides the capability to perform centralized installations and apply maintenance to remote endpoints. It can be used to consolidate and simplify the steps that are required to run installations and to apply maintenance on systems. You can use the centralized installation manager to install Installation Manager instances, update Installation Manager with a repository, and manage Installation Manager offerings. These activities can be done with the administrative console or the wsadmin tool. They are available from the job manager and deployment manager in distributed and z/OS environments. In a Liberty profile environment, installation can be done by using the Installation Manager, or a simplified installation can be performed by extracting an archive file. For z/OS, archive installation can be achieved by first installing Liberty using the IBM Installation Manager, then using the server packaging tool to produce a pax file.
1.5.2 Administration in a full profile environment The full profile has several key management features that allow you to set up, deploy, and maintain your application environments. These management features help you to build advanced and large-scale topologies, and reduce management and maintenance complexity. Every application server is managed from a set of administrative tools that include commands, scripts, and an administrative console. In a topology with stand-alone application servers, you can administer stand-alone server instances individually. You can also centralize administration for multiple stand-alone server instances on a single system by using an administrative agent. In a distributed topology, you can administer multiple application servers by using a deployment manager. A job manager allows you to remotely manage multiple administrative agents, deployment managers, stand-alone application servers, and Liberty profile runtime environments. Using the job manager, you can asynchronously submit and administer jobs to these servers and administrative agents. The jobs can manage applications, modify production configuration, start and stop applications, and distribute files.
1.5.3 Administration in a Liberty profile environment Liberty servers are administered by using line commands or from the WebSphere developer tools. On a z/OS platform, you can use IBM MVS operator commands to start, stop, or modify the Liberty profile. Liberty servers can also be accessed from JMX clients, such as using the jConsole tool provided in the Java SDK to monitor data. Liberty servers can be administered individually, from a job manager, or (new in V8.5.5) by a collective controller as part of a collective. Liberty collectives provide a common management domain for Liberty servers. This new structure has been added to the administration options for Liberty in V8.5.5 for operational efficiency and convenience, and to introduce high availability features. The collective controller provides operational access to all servers in the collective. This includes operations to start and stop servers, start administrative operations, and run file transfer in support of configuration changes and application installation. All Liberty profiles can be members of a collective, but only Network Deployment and WebSphere Application Server for z/OS provide the support that is needed to create a collective controller. Chapter 1. Introduction to WebSphere Application Server
11
Both the Job manager and the collective controller provide agent-less management of Liberty servers. You can use either tool to create, update, and remove servers, and to update server configurations and applications. The collective controller, like the job manager, allows you to monitor server status, but you do not have to submit a job. The new collective controller also allows you to cluster Liberty servers for high availability and scalability.
1.6 Intelligent management features (full profile) Intelligent Management features extend the quality of service that is provided by your middleware environment. Configurable operational policies govern the performance and health of your applications. Total cost of ownership is decreased through server consolidation and less administrative effort, and you experience lower response times and increased availability. In short, you experience the benefits of an autonomic middleware environment, which is self-configuring, self-protecting, self-healing, and self optimizing. A key component of the Intelligent Management is the on demand router (ODR). The ODR is an intelligent Java based HTTP proxy server and SIP proxy server. It is built on the WebSphere run time, and can manage the flow of requests into both WebSphere and non-WebSphere environments. The ODR is asynchronous, high performing, scalable, and can be clustered for high availability. Intelligent Management includes the following primary features: 0002 Intelligent routing improves business results by ensuring that priority is given to business critical applications. Requests to applications are prioritized and routed based on administrator-defined rules. 0002 Health management allows you to specify conditions to automatically watch for and corrective actions to take when the conditions are observed. You can monitor the status of your application servers, sense problem areas, and then respond to these problem areas before an outage occurs. The health monitoring and management subsystem continuously monitors the operation of servers against user-defined health policies. It detects functional degradation that is related to user application malfunctions. 0002 Application edition management allows you to roll out new versions of applications without experiencing downtime for a maintenance window. You can manage interruption-free production application deployments by using this feature. You can also validate a new edition of an application in your production environment without affecting users, and upgrade your applications without creating outages. You can also run multiple editions of a single application concurrently, directing different users to different editions. 0002 Performance management provides a self-optimizing middleware infrastructure. Dynamic clusters automatically scale up and down the number of running cluster members as needed to meet response time goals for users. You can take advantage of overload protection to limit the rate at which the on-demand router forwards traffic to application servers. Doing so helps prevent heap exhaustion, processor exhaustion, or both from occurring. You can use all of these capabilities together to extend quality of service through autonomic computing. These capabilities are called dynamic operations, which are the core functions that provide application infrastructure virtualization.
1.6.1 Enabling Intelligent Management in the web server plug-in (New in V8.5.5) Before V8.5.5, the ODR could be implemented only as a separate server placed in the topology between the web server and the application servers. Requests that 12
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
arrive at the Web server are forwarded to the ODR by the WebSphere web server plug-in. The ODR then sends the request to the appropriate server in a dynamic cluster based on current workload conditions and service policies. With V8.5.5, the ODR function can be implemented in the web server plug-in, eliminating the additional ODR tier and simplifying the topology. This new web server plug-in option is available only for IBM HTTP Server and Apache web servers. The web server plug-in provides most of the same features available in the ODR. The plug-in connects to a REST service in each cell to dynamically gather routing information.
1.6.2 Support for both full and assisted lifecycle servers The Intelligent Management feature provides full support for those servers that are known as complete lifecycle servers. This term includes any server that the WebSphere Application Server environment can instantiate, or create. These server types include WebSphere Application Server types such as application servers, generic servers, web servers, and proxy servers. The Intelligent Management function also provides support for a range of middleware servers. The term assisted lifecycle server refers to servers that you define to WebSphere Application Server by using templates to create representations of the servers in the administrative console. However, these servers still exist within the administrative domain of their respective middleware system. You add them as generic servers to the deployment manager capabilities. You can control the servers operationally, monitor and view server health and performance, and configure the administrative console to display log files and configuration files for these servers. This support includes the following middleware servers: 0002 0002 0002 0002 0002 0002 0002
Apache Tomcat (deprecated feature) JBoss Application Server (deprecated feature) Custom HTTP servers BEA WebLogic Server (deprecated feature) WebSphere Application Server Community Edition Apache HTTP Server External WebSphere application server (deprecated feature)
1.7 Clustering application servers Multiple application servers can be clustered so that they are managed as a single entity. An application is installed across the application servers in the cluster. If one application server becomes unavailable, the requests for the application can continue to be served by the remaining application servers in the cluster. Clustering application servers is key to the concept of workload management, scalability, and resiliency.
1.7.1 Clustering application servers in the full profile Application servers can be clustered by using static clustering or dynamic clustering (using the intelligent management features). Requests for applications are shared across one or more application servers, where each server is running a copy of the application. A static cluster is a collection of servers that are managed together to provide both workload balancing and high availability. Clusters are created with a specific number of application servers. An identical set of applications run on each application server in the cluster. A plug-in in the web server balances incoming requests across the application servers. Requests are
Chapter 1. Introduction to WebSphere Application Server
13
automatically routed to the running servers in the event of a failure. The servers that are members of a cluster can be on the same system or on different systems. WebSphere Application Server Network Deployment or WebSphere Application Server for z/OS is required for clustering. Note that the Workload Manager (WLM) for WebSphere Application Server for z/OS works differently from the Workload Manager for distributed platforms. With z/OS, the workload management structure for incoming requests is handled by the workload management subsystem features of z/OS. You can define business-oriented rules that classify incoming requests and assign SLA types of performance goals. This definition is done on transaction-level granularity, compared to server-level granularity with distributed workload management. The system then assigns resources automatically in terms of processor, memory, and I/O to try to achieve these goals. A dynamic cluster is an application deployment target that can expand and contract depending on the workload in the environment. Dynamic clusters work with autonomic managers, including the application placement controller and the dynamic workload manager, to maximize the use of computing resources. A dynamic cluster uses weights and workload management. This management is used to balance the workloads of its cluster members dynamically, and is based on performance information that is collected from the cluster members. Dynamic workload management is a feature of the ODR that applies the same principles as workload management, such as routing based on a weight system, to establish a prioritized routing system. With dynamic workload management, the system can dynamically modify the weights to stay current with the business goals, as compared to manually setting static weights in workload management. It also balances requests across the available nodes to regulate response times.
1.7.2 Clustering application servers in the Liberty profile (New in V8.5.5) Liberty servers that are members of a collective can be configured into a server cluster for high availability and scalability. The cluster can be treated as a single object in the collective, simplifying the operational management of the servers in the cluster. The members of the cluster can be configured individually, or can share a configuration. A web server plug-in is used to distribute work across the servers in the cluster.
1.8 Securing applications and administration WebSphere Application Server provides a security infrastructure and mechanisms to protect sensitive resources and to address enterprise end-to-end security requirements. You can secure the environment at various levels, from the physical security of the location where the server hardware is, to the security within the application itself. WebSphere Application Server security in the full profile includes JVM security, Java 2 security, Java EE security API, CSIv2 security, and WebSphere security. SSL is used to secure communication within the WebSphere Application Server environment and to external components. Auditing capabilities are available to confirm the effectiveness of the security configuration and identify vulnerabilities. WebSphere security domains provide the flexibility to use several security configurations within a single WebSphere Application Server cell. WebSphere Application Server provides authentication and authorization capabilities to secure administrative functions and applications. A user registry contains information about 14
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
users and groups so that security-related functions, including authentication and authorization, can be performed. WebSphere Application Server supports the following types of user registries: 0002 Local operating system, such as the IBM Resource Access Control Facility (IBM RACF®) on z/OS 0002 Stand-alone Lightweight Directory Access Protocol (LDAP) (for example, IBM Tivoli Directory Server) 0002 Federated repository (a combination of a file-based registry and one or more LDAP servers in a single realm) 0002 Custom registry In addition to the default authentication and authorization capabilities, WebSphere Application Server has support for Java Authorization Contract for Containers (JACC) 1.1. This support gives you the option of using an external JACC-compliant authorization provider for application security. The IBM Tivoli Access Manager client that is embedded in WebSphere Application Server is JACC-compliant, and can be used to secure your WebSphere Application Server-managed resources. WebSphere Application Server V8.5 enhancements to security for the full profile include the following security management and auditing improvements: 0002 Single sign-on (SSO) provides an API so that developers can run downstream SSO without storing and sending user credentials. 0002 You can create multiple security domains within a single WebSphere Application Server cell. Each security domain can have its own user population (and underlying repository). Additionally, the application domain can be separated from the administrative domain. 0002 Security auditing records the generation of WebSphere Application Server administrative actions. These actions can include security configuration changes, key and certificate management, access control policy changes, and system resources management. With this feature, you can hold administrative users accountable for configuration and runtime changes. 0002 Extra enhancements in WebSphere Application Server V 8.5 enable you to track changes that are made to the application server configuration by using checkpoints made through the extended repository service. A full checkpoint is a complete copy of the entire configuration repository. A delta checkpoint is a subset snapshot of the configuration repository that is made when you change a product configuration. Use checkpoint data to restore the configuration repository to a prior state. To determine changes in the configuration, extract data from a delta checkpoint to obtain the before and after versions of the files that were saved. 0002 With the Auditing service provider setting, the WebSphere Application Server administrator can configure the behavior of the audit files when they reach maximum capacity. 0002 With the DMZ Secure Proxy, a proxy server that is hardened for DMZ topologies, you can have a more secure out-of-box proxy implementation outside the firewall. 0002 Fine-grained administration security can now be enforced through the administration console. You can restrict access based on the role of the administrator at the cell, node, cluster, or application level, offering fine-grained control over administrator scope. This capability is valuable in large-cell implementations where multiple administrators are responsible for subsets of the application portfolio that is running on the cell.
Chapter 1. Introduction to WebSphere Application Server
15
1.8.1 Securing the Liberty profile The Liberty profile provides support for securing the server runtime environment and web applications by using user registries, authentication, and authorization. For secure communication between the client and the server, you can enable SSL for the Liberty profile. V8.5.5 introduced more enhancements to the security features for the Liberty profile. V8.5.0.2 added new enhancements to security, including the sync-to-OS-thread feature for z/OS and support for OAuth2.0. In V8.5.5, the support for user registries has been extended. In addition to the existing support of an LDAP server for authentication, V8.5.5 now supports federated LDAP registries. With the new extension capabilities of the Liberty profile, you can use custom user registries. New support capabilities have also been added to support the new programming models, including Enterprise JavaBeans (EJBs) and web services. A new utility has been added to support Advanced Encryption Standard (AES) encryption for passwords that are stored in the server.xml file.
1.9 Interoperability The expanded integration support in WebSphere Application Server simplifies interoperability in mixed environments.
1.9.1 Web services Web services allow for the definition of functions or services within an enterprise. These definitions can be accessed by using industry standard protocols (such as HTTP and XML) that are already in use today. These protocols allow for easy integration of both intra-business and inter-business applications, which can lead to increased productivity, expense reduction, and quicker time to market. Web services are also the key elements of service-oriented architecture (SOA), which provides reuse of existing service components and more flexibility so you can address changing opportunities.
Web services support in full profile WebSphere Application Server V8.5 full profile includes support for the following web services and web services security standards: 0002 0002 0002 0002 0002 0002 0002 0002 0002 0002 0002 0002
16
Web Services Interoperability Organization (WS-I) Basic Profile 1.2 and 2.0 WS-I Reliable Secure Profile JAX-WS 2.2 JAX-RS 1.1 Java Architecture for XML binding (JAXB) 2.2 SOAP 1.2 SOAP Message Transmission Optimization Mechanism (MTOM) 1.0 XML-binary Optimized Packaging (XOP) Web Services Reliable Messaging (WS-RM) 1.1 Web Services Addressing (WS-Addressing) 1.0 Web Services Secure Conversation (WS-SC) 1.0 Web Services Policy 1.5
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
WebSphere Application Server supports the Web Services for Remote Portlets (WSRP) standard. By using this standard, portals can provide portlets, applications, and content as WSRP services. Other portals can integrate the WSRP services as remote portlets for their users. A portlet container, such as WebSphere Portal, can use these services as remote portlets.
Web services support in Liberty profile (New in V8.5.5) Liberty provides both client and server functions for SOAP-based Web Services. The following APIs are supported, among others: 0002 0002 0002 0002
JAX-WS 2.2 JAXB 2.2 Web Services for EE 1.3 POJO and EJB-based web services
The following JDK bundled APIs are also available: 0002 SAAJ 0002 JAXP 0002 StAX The SOAP/HTTP and WS-Security protocols are supported Web services can be secured without WS-Security by using basic authentication along with web application transport constraints. With WS-Security, a default keystore and truststore contain the keys for authentication and encryption. The following WS-Security policies are available: 0002 Username Token Profile 1.1 0002 X.509 Token Profile 1.1 0002 WS-I Basic Security Profile 1.1 More support for developing web services has been added to the WebSphere Application Server Developer Tools for Eclipse. This support includes a wizard for top-down WSDL-to-Java generation, for bottom up POJO web service development, and a wizard to simplify adding policies to WSDL. Not all features are supported in all editions. See Table 1-2 on page 9 for a list of the web services technologies that are supported by each edition.
1.9.2 Messaging, connectivity, and transaction management WebSphere Application Server supports asynchronous messaging by using a Java Message Service (JMS) provider and its related messaging system.
Full profile support WebSphere Application Server includes a fully integrated JMS 1.1 provider that is called the default messaging provider. The default messaging provider complements and extends WebSphere MQ and the application server. It is suitable for messaging among application servers, and for providing messaging capability between WebSphere Application Server and an existing WebSphere MQ backbone. WebSphere Application Server also supports your existing WebSphere MQ system as a JMS provider, and third-party messaging providers. WebSphere Application Server also supports Java EE Connector Architecture (JCA) 1.5 resource adapters, which provide connectivity between application servers and enterprise information systems (EISs). WebSphere Application Server V8.5 comes with Java
Chapter 1. Introduction to WebSphere Application Server
17
Transaction API (JTA) 1.1 specification support, which provides standard Java interfaces for transaction management.
Liberty profile support (New in V8.5.5) The Liberty profile that is shipped with the base, Express, Network Deployment, and z/OS editions supports JMS API 1.1. This support includes support for the following messaging providers: 0002 A new lightweight single server message provider is included with the Liberty profile run time for development and testing of messaging applications. 0002 Liberty profile now supports configuring WebSphere MQ as the messaging provider, which allows Liberty applications to interact with the WebSphere MQ network. 0002 The JMS support in Liberty is fully interoperable with the service integration bus in the full profile. The JMS client in Liberty can access the service integration bus and the full profile JMS client can access messaging providers that run in Liberty. JMS support is not included in Liberty Core.
1.9.3 Mapping services (New in V8.5.5) The use of services depends on the ability of the service client to locate and communicate with the service provider. Changes to either the location of the service or to the interface can impact the applications that use the service. The new service mapping feature is designed to shield applications from minor changes in the services they use. This feature gives administrators the ability to define a mapping service that can intercept service client invocations that are bound for a particular service. The mapping service can determine which service location the message should be routed to, which operation on the service provider should be started, and how the fields in the client and server messages should be mapped to each other. Administrators can control to which service interactions the service mapping applies. To implement this function, a service map is created by using a graphical interface in Rational Application Developer, and then deployed to WebSphere Application Server. The administrator then creates a mapping service using the deployed service map. The administrator can also configure a mapping service to publish JMS publish/subscribe events for each service request and response. A JMS topic subscriber can be created to use these events and, additionally, the IBM Integration Bus product has built-in support for using and processing these events.
1.9.4 Application client With WebSphere Application Server, you can run client applications that communicate with a WebSphere Application Server by installing the application client component on the system on which the client applications run. This component provides a stand-alone client runtime environment for your client applications. It also enables your client to run applications in a Java EE environment that is compatible with EJB. The Application Client for WebSphere Application Server consists of the following client components: 0002 Java EE application client application This component uses services that are provided by the Java EE Client Container.
18
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
0002 Thin application client application This component does not use services that are provided by the Java EE Client Container, and includes a JVM API. 0002 Applet application client application With this component, users can access enterprise beans in the WebSphere Application Server through a Java applet in an HTML document. 0002 ActiveX to EJB Bridge application client application This component uses the Java Native Interface (JNI) architecture to programmatically access the JVM API (Microsoft Windows only).
1.10 Application development and deployment tools WebSphere Application Server applications can be developed using various tools. Three of particular interest are covered in this section. WebSphere developer tools: This section introduces several tools for use with WebSphere Application Server. Two of these tools, Rational Application Developer for WebSphere Software and WebSphere Application Server Developer Tools for Eclipse, provide many of the same developer features. The process to use these features is the same regardless of the tool. A reference to “WebSphere developer tools” in this book refers to either of these products.
1.10.1 IBM Assembly and Deploy Tools for WebSphere Administration WebSphere Application Server includes an application assembly and deployment tool, called IBM Assembly and Deploy Tools for WebSphere Administration. This tool replaces the previously available IBM Rational Application Developer Assembly and Deploy. IBM Assembly and Deploy Tools for WebSphere Administration is targeted for the assembly and deployment of applications, and provides the following capabilities: 0002 Import and validate applications. 0002 Edit deployment descriptors and binding files. 0002 Edit enterprise archive (EAR)-level configuration (enhanced EAR). 0002 Create and debug Jython and wsadmin scripts. 0002 Deploy EJB and web services. 0002 Deploy applications to local or remote WebSphere Application Server V8.5 runtime environments. 0002 Debug applications on WebSphere Application Server. For more information about IBM Assembly and Deploy Tools for WebSphere Administration, see Chapter 11, “Application development and deployment” on page 359.
1.10.2 Rational Application Developer for WebSphere Software V9 IBM Rational Application Developer for WebSphere Software V9 provides a development environment for building applications that run on WebSphere Application Server. This tool supports all Java EE artifacts that are supported by WebSphere Application Server. These Chapter 1. Introduction to WebSphere Application Server
19
artifacts include servlets, JavaServer Pages (JSP), JavaServer Faces (JSF), Enterprise JavaBeans (EJB), Extensible Markup Language (XML), SIP, Portlet, and web services. It also includes integration with the Open Services Gateway initiative (OSGi) programming model. The workbench contains wizards and editors that help build standards-compliant, business-critical Java EE, Web 2.0, and service-oriented architecture applications. Code quality tools help teams find and correct problems before they escalate into expensive problems. Rational Application Developer for WebSphere Software can be used to develop applications for both the full profile and the Liberty profile. For more information about Rational Application Developer for WebSphere Software V9, see: http://www.ibm.com/software/awdtools/developer/application/
1.10.3 WebSphere Application Server Developer Tools for Eclipse The IBM WebSphere Application Server Developer Tools for Eclipse V8.5.5 provides a development environment for developing, assembling, and deploying Java EE, OSGi, Web 2.0 and Mobile applications. It supports multiple versions of WebSphere Application Server. When combined with Eclipse SDK and Eclipse Web Tools Platform, WebSphere Application Server Developer Tools for Eclipse provides a lightweight environment for developing Java EE applications. WebSphere Application Server Developer Tools for Eclipse is a no-charge edition for the developer desktop and includes Eclipse adapters. With V8.5.5, WebSphere Application Server and WebSphere Application Server Developer Tools for Eclipse editions are provided free for developer desktops and supported under production runtime licenses. While not as rich in features as Rational Application Developer for WebSphere Software, this tool is an attractive option for developers who are using the Liberty profile and the full profile. For more information about WebSphere Application Server Developer Tools for Eclipse and access to the tool, see: https://www.ibm.com/developerworks/community/blogs/wasdev/entry/downloads_final_re leases?lang=en
1.10.4 Enhancements to the tools for V8.5.5 Enhancements have also been made to Rational Application Developer 9.0 and WebSphere Application Server Developer Tools for Eclipse in support of the new 8.5.5 capabilities: 0002 Support for developing JAX-WS web services for the Liberty server, new EJB support, and more templates to support WS-Security X.509 token profile 0002 Support for targeting and installing user-defined Liberty features 0002 Enhancements to Maven integration, most notably OSGi with EJB and JPA project conversion 0002 Enhancements to the web and mobile web development tools that include jQuery and Dojo support 0002 Improvements to EJB and CDI development tools, including the new beans.xml deployment descriptor editor 0002 New editor for configuring the server's dynamic cache mechanism for caching servlets, JSPs, web services, and commands 0002 Support of multiple versions of WebSphere Application Server
20
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
0002 SCA tools enhancements that include improved integration of web services bindings 0002 Code quality and productivity enhancements with sample-based profiling capabilities from integration with The IBM Monitoring and Diagnostic Tools for Java - Health Center 0002 Updates to Java EE Connector Architecture tools that include new adapters for IBM CICS, IBM IMS, and WebSphere.
1.11 Advanced tools and extensions This section provides information about Websphere Application Server tool and extension enhancements.
1.11.1 WebSphere Customization Toolbox The WebSphere Customization Toolbox for WebSphere Application Server includes the following tools for managing, configuring, and migrating various parts of the WebSphere Application Server environment: 0002 The Web Server Plug-ins Configuration Tool allows you to configure web server plug-ins. 0002 The Profile Management Tool for z/OS allows you to generate jobs and instructions for creating profiles for WebSphere Application Server for z/OS from a Windows or Linux system based on Intel. 0002 The z/OS Migration Management Tool allows you to generate definitions to migrate WebSphere Application Server for z/OS profiles from a Windows or Linux system based on Intel.
1.11.2 Web 2.0 and Mobile Toolkit The WebSphere Application Server Web 2.0 and Mobile Toolkit simplifies the addition of Asynchronous JavaScript and XML (Ajax) rich desktop and mobile user interfaces and Representational State Transfer (REST) web services to Java web applications. Web 2.0 capabilities, such as Ajax and REST, help application developers create more connected, interactive applications that result in higher customer satisfaction, user productivity, and enhanced decision making. New mobile Ajax components enable developers to create mobile web applications that run on devices such as smartphones and tablets.
1.11.3 Liberty Extensions System Programming Interface (SPI) You can use the Liberty Extensions System Programming Interface (SPI) to extend the Liberty profile with custom features by using OSGi bundles, including web application bundles. For example, you can extend the OSGi applications programming model by adding new annotations or custom configurations. Or, you can provide a custom user registry. This support can be used to integrate third-party function into the Liberty runtime and development tools. The product extensions consist of a set of directories and files that are made known to Liberty by a properties file. Independent products can require a Liberty installation and then register with Liberty by using the properties file. Users who create features can install them in a built-in extension for convenience. This built-in extension can also be used by products that embed a Liberty install and service.
Chapter 1. Introduction to WebSphere Application Server
21
The SPI supports the full lifecycle of packaging, installation, and uninstallation. The SPI includes plug points that you can implement as features, services for run time, and instrumentation for monitoring and problem determination. The SPI contains the following plug points: 0002 0002 0002 0002
Custom user registry Trust Association Interceptor Cache provider Webcontainer extension
The SPI contains the following services: 0002 0002 0002 0002 0002 0002 0002
File Monitor Application container services Classloaders Publish information to Atlas repository Metatype helpers for processing advanced configuration Location service to access local resources Trace and FFDC
The SPI supports the following instrumentation: 0002 Entry and exit trace 0002 Monitoring 0002 Timed operations
22
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
2
Chapter 2.
Integration with other products WebSphere Application Server works closely with other IBM products to provide a fully integrated solution. This chapter introduces products that provide enhanced security and messaging options, and that provide broad integration features. This chapter includes the following sections: 0002 0002 0002 0002 0002 0002 0002 0002 0002 0002
IBM Tivoli Access Manager for e-business IBM Tivoli Directory Server IBM WebSphere MQ IBM WebSphere Adapters IBM WebSphere DataPower Appliances IBM DB2 IBM Tivoli Composite Application Manager for WebSphere IBM WebSphere Portal Server IBM Tivoli Workload Scheduler IBM WebSphere eXtreme Scale
© Copyright IBM Corp. 2012, 2013. All rights reserved.
23
2.1 IBM Tivoli Access Manager for e-business IBM Tivoli Access Manager for e-business provides a holistic security solution at the enterprise level. This section provides information about the integration of Tivoli Access Manager for e-business with WebSphere Application Server.
2.1.1 Features of Tivoli Access Manager for e-business Tivoli Access Manager provides the following features: 0002 Defines and manages centralized authentication, access, and audit policies for a broad range of business initiatives. 0002 Establishes a new audit and reporting service that collects audit data from multiple enforcement points, and from other platforms and security applications. 0002 Enables flexible single sign-on (SSO) to web-based applications that span multiple sites or domains with a range of SSO options. These options can eliminate help-desk calls and other security problems that are associated with multiple passwords 0002 Uses a common security policy model with the Tivoli Access Manager family of products to extend support to other resources. 0002 Manages and secures business environments from existing hardware (mainframe, PCs, servers) and operating system platforms, including Windows, Linux, IBM AIX®, Solaris, and HP-UX. 0002 Provides a modular authorization architecture that separates security code from application code. 0002 Automatically authenticates Microsoft Windows users with their Windows credentials in WebSphere if they are connected to a Microsoft Active Directory. 0002 Allows integration with Tivoli Identity Manager, which supports administering large numbers of user accounts in enterprise environments. In summary, Tivoli Access Manager provides centralized authentication and authorization services to different products. Applications delegate authentication and authorization decisions to Tivoli Access Manager. For more information about Tivoli Access Manager for e-business, see: http://www-01.ibm.com/software/tivoli/products/access-mgr-productline/
2.1.2 Integration with WebSphere Application Server WebSphere Application Server provides its own security infrastructure. This infrastructure consists of mechanisms that are specific to WebSphere Application Server, many that use open security technology standards. This security technology is widely proven, and the software can integrate with other enterprise technologies. For more information about WebSphere Application Server’s security infrastructure, see Chapter 15, “Security” on page 499. The WebSphere Application Server security infrastructure is adequate for many situations and circumstances. However, integrating WebSphere Application Server with Tivoli Access Manager allows for end-to-end integration of application security for the entire enterprise.
24
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Using this approach at the enterprise level provides the following advantages: 0002 Reduced risk through a consistent services-based security architecture 0002 Lower administration costs through centralized administration and fewer security subsystems 0002 Reduced application development costs because developers do not have to develop customized security subsystems 0002 Built in, centralized, and configured handling of business concerns, such as privacy requirements
WebSEAL The WebSEAL server is a resource manager in the Tivoli Access Manager architecture that you can use to manage and protect web content resources. WebSEAL works as a reverse HTTP/HTTPS proxy server in front of the web servers or application servers. It connects to the policy server for the access control list (ACL) as shown in Figure 2-1. Because it handles the HTTP/HTTPS protocol, WebSEAL is independent of the web server or application server implementation. With this feature, you can authenticate and authorize clients in a distributed, multivendor integrated environment.
Secure Domain 1. Request WebSEAL
5. Authorized operation
Protected Resources
6. Response Client
2. Request for authorization (authAPI)
4. Authorization decision (authAPI) Authorization Service
3. Authorization check Authorization policy
Figure 2-1 WebSEAL as a proxy in WebSphere integration
Repositories In addition to WebSphere Application Server security, Tivoli Access Manager requires a user repository. It supports different repositories, such as IBM Tivoli Directory Server and Microsoft Active Directory. You can configure Tivoli Access Manager to use the same user repository as WebSphere Application Server, so that you can share user identities with both Tivoli Access Manager and WebSphere Application Server.
Tivoli Access Manager policy server The Tivoli Access Manager policy server maintains the master authorization policy database. This database contains the security policy information for all resources and the credentials information of all participants in the secure domain, both users and servers. The authorization database is replicated across all local authorization servers.
Tivoli Access Manager for WebSphere component The Tivoli Access Manager server is bundled with WebSphere Application Server Network Deployment.
Chapter 2. Integration with other products
25
The Tivoli Access Manager client is embedded in WebSphere Application Server. You can configure the client by using the scripting and GUI management facilities of WebSphere Application Server. For more information about configuring the embedded Tivoli Access Manager client, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.doc/ae/t sec_enable_TAM.html All communication between the Tivoli Access Manager clients and the Tivoli Access Manager server is run through the Java Authorization Contract for Containers (JACC) application programming interface (API). Tivoli Access Manager further integrates with WebSphere Application Server by supporting the special subjects AllAuthenticated and Everyone. AllAuthenticated and Everyone are subjects that are specific to WebSphere Application Server. The AllAuthenticated subject allows access to a resource for users who are authenticated, regardless of the repository user groups to which those users might belong. The Everyone subject allows access to a resource for all users regardless of whether they are authenticated. Figure 2-2 shows the integration interfaces between WebSphere Application Server and Tivoli Access Manager.
WebSphere Application Server V8.5 Access Manager for WebSphere component JACC provider contract
TAI
GSO credential mapping
JACC management
Access Manager Java Runtime component PDJAdmin (management)
PDPerm (authorization)
PDPrincipal (authentication)
Local ACL DB replica
Access Manager policy server
User registry
AM authorization server
Master ACL DB
ACL DB replica
Access Manager server
Figure 2-2 Integration of WebSphere Application Server with Tivoli Access Manager
26
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Further advantages of using Tivoli Access Manager In addition to the enterprise-level advantages, using Tivoli Access Manager at the application server level has the following advantages: 0002 Supports accounts and password policies 0002 Supports dynamic changes to the authorization table without having to restart applications
Security, networking, and topology considerations A Lightweight Directory Access Protocol (LDAP) server contains sensitive data in terms of authentication, authorization, and privacy. The Tivoli Access Manager server manages this data. Therefore, the servers belong to the data layer of the network. Consider enabling Secure Sockets Layer (SSL) configuration options between the databases so that data is encrypted. Legal considerations: Storage on IT systems of certain data types, such as personally identifiable data in the European Union, can be subject to legal or regulatory issues. Consult your legal department before you deploy such information about your systems. These considerations vary by geographical area and industry.
2.2 IBM Tivoli Directory Server In today’s highly connected world, directory servers are the foundation of authentication systems for internal and external user populations in the corporate infrastructure. Tivoli Directory Server provides a high-performance LDAP identity infrastructure that can handle millions of entries. It is built to serve as the identity data foundation for web applications and identity management initiatives. This section provides information about the integration of Tivoli Directory Server with WebSphere Application Server.
2.2.1 Features of Tivoli Directory Server A directory is a data structure that enables the lookup of names and associated attributes arranged in a hierarchical tree structure. In the context of enterprise application servers, this structure enables applications to perform these functions: 0002 Look up a user principal 0002 Determine the attributes that the user has 0002 Determine the groups of which the user is a member You can then make decisions about authentication and authorization by using this information. Remember: LDAP is the name of the protocol that is used between a directory server and a client, which in this case is WebSphere Application Server. Often the directory server is called the LDAP server. LDAP is still a protocol, although the authentication happens by using the Lightweight Third Party Authentication (LTPA) mechanism. The LDAP carries data between WebSphere Application Server and the directory server as part of the authentication mechanism. LDAP is a fast and simple way to query and maintain user entities in a hierarchical data structure. It has advantages over using databases as a user repository in terms of speed, Chapter 2. Integration with other products
27
simplicity, and standardized models or schemas for defining data. Standard schemas have standard hierarchies of objects, such as objects that represent a person in an organization. These objects, in turn, have attributes such as a user ID and common name. The schema can have custom objects added to it, meaning that your directory is extensible and customizable. Generally, LDAP is chosen over a custom database repository of users for these reasons. LDAP implementations (such as Tivoli Directory Server) use database engines in the background. However, these engines are optimized for passive lookup performance (through indexing techniques). LDAP implementation optimizations are based on the assumption that data changes relatively infrequently, and the directory is primarily for looking up data rather than updating data. For more information about Tivoli Directory Server, see: http://www.ibm.com/software/tivoli/products/directory-server/
2.2.2 Integration with WebSphere Application Server You can enable security in WebSphere Application Server to manage users and to assign specific roles to them. When using the Tivoli Directory Server, you select either a stand-alone LDAP registry or a federated registry. With a stand-alone registry, WebSphere Application Server can connect to one directory server at a time. Thus, you can have only one LDAP server in your environment, or you can set up a failover cluster of the LDAP servers. The failover is managed by WebSphere Application Server. If you use a federated repository, choose from the following repository solutions that are based on LDAP: 0002 Single LDAP (full LDAP tree) 0002 Subtree of an LDAP (used only when a group in LDAP needs access to WebSphere Application Server) 0002 Multiple LDAPs (uses a unique user ID through all the LDAP trees)
2.2.3 Security, networking, and topology considerations Because the LDAP server contains sensitive data in terms of authentication, authorization, and privacy, the LDAP server belongs to the data layer of the network. Consider enabling SSL options in the WebSphere Application Server security configuration. Enabling these options ensures that the data is encrypted during transport between the application server layer and the data layer. Remember: When LDAP is used with the SSL protocol, it is often called LDAPS.
Legal considerations: Storage on IT systems of certain data types, such as personally identifiable data in the European Union, can be subject to legal or regulatory issues. Consult your legal department before you deploy such information about your systems. These considerations vary by geographical region and industry. For a list of supported directory servers for WebSphere Application Server, see System Requirements for WebSphere Application Server Base and Network Deployment V8.5 at: http://www-01.ibm.com/support/docview.wss?uid=swg27006921
28
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
When you reach this web page, select the operating system and LDAP repository type (federated or stand-alone) that you want to use.
2.3 IBM WebSphere MQ WebSphere MQ is an IBM middleware product that provides asynchronous messaging technology for application-to-application communication rather than application-to-user and user interface communication. This section provides information about the integration of WebSphere MQ with WebSphere Application Server.
2.3.1 Features of IBM WebSphere MQ WebSphere MQ is available on many platforms and operating systems. It offers a fast, robust, and scalable messaging solution. WebSphere MQ assures one-time-only delivery of messages to queue destinations that are hosted by queue managers. This messaging solution has APIs in C, Java, COBOL, and other languages that allow applications to construct, send, and receive messages. With the advent of Java Message Service (JMS), generic, portable client applications can be written to interface with proprietary messaging systems such as WebSphere MQ. The integration of WebSphere Application Server with WebSphere MQ over time is influenced by this dichotomy of generic JMS and proprietary WebSphere MQ access approaches. For more information about WebSphere MQ, see: http://www.ibm.com/software/integration/wmq/
2.3.2 Integration with WebSphere Application Server WebSphere Application Server messaging is a general term for a group of components that provide the messaging function for applications. WebSphere MQ and WebSphere Application Server messaging are complementary technologies that are tightly integrated to provide for various messaging topologies. WebSphere Application Server supports asynchronous messaging based on the JMS programming interface and the use of a JMS provider and its related messaging system. JMS providers must conform to the JMS specification version 1.1. For more information about messaging with WebSphere Application Server and new features for WebSphere MQ connectivity, see the Websphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.doc/ae/c mj_jmsp_wmq.html
Full profile support In the full profile, you can use the following JMS providers: 0002 The default messaging provider 0002 WebSphere MQ 0002 Third-party JMS providers The default messaging provider is the JMS API implementation for messaging (such as connection factories and JMS destinations). The concrete destinations (queues and topic
Chapter 2. Integration with other products
29
spaces) behind the default messaging provider interface are implemented in a service integration bus. A service integration bus (bus) consists of one or more bus members, which can be application servers or clusters. Each bus member has one messaging engine (more, in the case of clusters) that manages connections to the bus and messages. A bus can connect to other buses and to WebSphere MQ. Similarly, the WebSphere MQ JMS provider is the JMS API implementation with WebSphere MQ (with queue managers, for example) implementing the real destinations for the JMS interface. WebSphere MQ can coexist on the same host as a WebSphere Application Server messaging engine. Whether to use the default messaging provider, the direct WebSphere MQ messaging provider, or a combination depends on several factors. No set of questions can lead you directly to the decision. However, consider the following guidelines: 0002 In general, the default messaging provider is a good choice when you require messaging between WebSphere Application Server and an existing WebSphere MQ backbone and its applications. 0002 The WebSphere MQ messaging provider is a good choice in the following circumstances: – You are currently using a WebSphere MQ messaging provider and want to continue using it. – You require access to heterogeneous, non-JMS enterprise information systems (EIS). – You require access to WebSphere MQ clustering. Using a topology that combines WebSphere MQ and the default messaging provider is beneficial. This combination provides tight integration between WebSphere and the default messaging provider (clustering), and the additional flexibility of WebSphere MQ.
Liberty profile support (New in V8.5.5) The Liberty profile that is shipped with the base, Express, Network Deployment, and z/OS editions supports Java messaging support (JMS) API 1.1. The Liberty profile includes a single server message provider for development and testing of messaging applications, and is interoperable with the service integration bus in the full profile. The messaging support also supports configuring WebSphere MQ as the messaging provider, which allows Liberty applications to interact with the WebSphere MQ network.
2.3.3 Connecting the full profile to WebSphere MQ If both WebSphere Application Server and WebSphere MQ exist in your environment, you can use the following options: 0002 Use the default messaging provider 0002 Use the WebSphere MQ provider 0002 Use a mixture of the default and the WebSphere MQ messaging provider Both providers can transfer messages between application servers by using the WebSphere MQ infrastructure. For more information, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.zseries.doc /ae/tmj_jmsp_mixed.html
30
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
If you decide to use a topology that includes both WebSphere MQ and the default messaging provider, the following methods can allow interaction between them: 0002 Extend the WebSphere MQ and bus networks by defining a WebSphere MQ link on a messaging engine in a WebSphere Application Server that connects the bus to a WebSphere MQ queue manager. WebSphere MQ perceives the connected bus as a queue manager. The bus perceives the WebSphere MQ network as another bus. WebSphere MQ applications can send messages to queue destinations on the bus. Default messaging applications can send messages to WebSphere MQ queues without being aware of the mixed topology. Similar to WebSphere MQ queue manager networks, this method can be used to send messages from one messaging network to the other. Considerations: Keep in mind the following considerations: 0002 WebSphere MQ to bus connections are supported only over TCP/IP. 0002 A bus cannot be a member of a WebSphere MQ cluster. Figure 2-3 shows a sample integration for WebSphere Application Server and WebSphere MQ.
JMS application
Messaging engine
MQ channel MQ link
WMQ application
WMQ application
WebSphere MQ queue manager
WebSphere MQ queue manager
Protocol Web services
WebSphere Application Server V8.5
Figure 2-3 WebSphere Application Server integration with WebSphere MQ
0002 Integrate specific WebSphere MQ resources into a bus for direct, synchronous access from default messaging applications that are running in WebSphere Application Servers. Represent a queue manager or queue sharing group as a WebSphere MQ server in the WebSphere Application Server cell. Then, add it to a bus as a bus member. Tip: A WebSphere MQ shared queue group is a collection of queues that can be accessed by one or more queue managers. Each queue manager that is a member of the shared queue group has access to any of the shared queues. WebSphere MQ queues on queue managers, and queue sharing groups that run on z/OS, can be accessed in this way from any WebSphere Application Server that is a member of the bus. Only the following configurations can be accessed from a bus in this way: – WebSphere MQ (distributed platforms) Version 7 or later queue managers – Queue sharing groups that run on z/OS Version 6 or later The WebSphere MQ server does not depend on any one designated messaging engine. Therefore, this type of connectivity to WebSphere MQ can tolerate the failure of any message engine if another is available on the bus. This configuration increases robustness and availability. This method can be used for both sending and consuming messages from WebSphere MQ queues.
Chapter 2. Integration with other products
31
When a default messaging application sends a message to a WebSphere MQ queue, the message is immediately added to that queue. If the WebSphere MQ queue manager is not available, the message is not stored by the bus for later transmission to WebSphere MQ. When a WebSphere Application Server application receives a message from a WebSphere MQ queue, it receives the message directly from the queue. For more information about the messaging features of the full profile, see Chapter 13, “Messaging and service integration” on page 433.
2.3.4 Connecting the Liberty profile to WebSphere MQ (New in V8.5.5) The Liberty profile supports messaging and provides an option to use the WebSphere MQ client to connect to WebSphere MQ. For more information about the messaging features of the Liberty profile, see 13.3, “Liberty profile messaging” on page 468.
2.4 IBM WebSphere Adapters A resource adapter is a system-level software driver that a Java application uses to connect to an EIS. A resource adapter plugs into an application client, and provides connectivity between the EIS and the enterprise application. Exception: This topic is not relevant to the WebSphere MQ resource adapter. For more information about the WebSphere MQ resource adapter, see the Websphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.base.doc /ae/tmj_wmqra_maint.html This section provides information about the integration of WebSphere Adapters with WebSphere Application Server.
2.4.1 Features of IBM WebSphere Adapters IBM WebSphere Adapters provide a set of generic technology and business application adapters with wizards that quickly and easily enable connections to enterprise information systems (EIS). These systems include existing enterprise applications, enterprise resource planning (ERP) systems, human resource (HR) systems, customer relationship management (CRM) systems, and supply chain systems. WebSphere Adapters can also be used to integrate those systems to the following products: 0002 IBM business process management (BPM) products 0002 IBM enterprise service bus (ESB) implementations 0002 Application server solutions in a service-oriented architecture (SOA) WebSphere Adapters implement the Java EE Connector Architecture (JCA) and Enterprise Metadata Discovery specifications. This configuration provides a simple and quick integration experience with graphical discovery tools without needing to write code. WebSphere Application Server supports JCA versions 1.0, 1.5, and 1.6, including more configuration features for JCA 1.5 and JCA 1.6.
32
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
WebSphere Adapters include the following types of adapters: 0002 Technology adapters The following adapters deliver file and database connectivity solutions: – – – – – – –
Enterprise Content Management (ECM) Email File Transfer Protocol (FTP) Flat Files IBM i Java Database Connectivity (JDBC) IBM Lotus® Domino®
0002 IBM WebSphere Adapters for System z provide connectivity options for mainframe transactions: – – – – – –
CICS Transaction Gateway IMS SOA Integration Suite IMS Connect IMS TM IBM InfoSphere® Classic Federation Server for z/OS CICS Transaction Server for z/OS V4.1
0002 The following adapters integrate enterprise business application suites: – – – – –
JD Edwards EnterpriseOne Oracle E-Business Suite PeopleSoft Enterprise SAP Software Siebel Business Applications
IBM provides the WebSphere Adapter Toolkit at no additional cost so that customers and IBM Business Partners can develop custom JCA adapters to meet their unique business needs. WebSphere Adapter Toolkit integrates with IBM Rational Application Developer environment, which provides an integrated development and WebSphere test environment. For more information about the WebSphere Adapter Toolkit, see: http://www.ibm.com/software/integration/wbiadapters/toolkit/ For more information about IBM WebSphere Adapters, see: http://www.ibm.com/software/integration/wbiadapters/
2.4.2 Integration with WebSphere Application Server WebSphere Adapters plug into WebSphere Application Server and provide bidirectional connectivity between enterprise applications (or Java EE components), WebSphere Application Server, and EIS.
Chapter 2. Integration with other products
33
Figure 2-4 shows the relationship between WebSphere Application Server and a WebSphere Adapter.
WebSphere Application Server Enterprise Application or Java EE component
WebSphere Adapter Enterprise Information System
Figure 2-4 WebSphere Adapter integration with WebSphere Application Server
2.5 IBM WebSphere DataPower Appliances IBM WebSphere DataPower® Appliances simplify, govern, and optimize the delivery of services and applications, and enhance the security of XML and IT services. They extend the capabilities of an infrastructure by providing a multitude of functions. The capabilities of the WebSphere DataPower Appliances span service-oriented architecture (SOA) connectivity, business-to-business (B2B) connectivity, advanced application caching, rapid integration with cloud-based systems, and more. DataPower Appliances are rack-mountable hardware devices or blade servers that mount in an IBM BladeCenter® chassis. This section provides information about the integration of WebSphere DataPower Appliances with WebSphere Application Server.
2.5.1 DataPower appliance models The WebSphere DataPower Appliance family contains the following models. Each appliance has its own characteristics and fits different business needs. 0002 WebSphere DataPower Service Gateway XG45 Appliance The WebSphere DataPower Service Gateway XG45 is a network appliance that is built for web services deployments, governance, light integrations, and hardened security. The XG45 provides protection against XML vulnerabilities by acting as an XML proxy. It runs XML well-formed checks, buffer overrun checks, XML schema validation, XML filtering, and XDoS protection. XG45 also includes many essential security functions beyond those of an XML firewall. These functions include web services access control authentication, authorization, and auditing (AAA), XML Encryption and Digital Signature, WS-Security, and content-based routing. For more information about the DataPower XG45, see: http://www.ibm.com/software/integration/datapower/XG45/ 0002 WebSphere DataPower Integration Appliance XI52 IBM WebSphere DataPower Integration Appliance XI52 is a hardware ESB, delivering common message transformation, integration, and routing functions in a network device. These functions cut operational costs and improve performance. By making on-demand data integration part of the shared SOA infrastructure, the XI52 is one of the few nondisruptive technologies for application integration. For more information about the DataPower XI52, see: http://www.ibm.com/software/integration/datapower/xi52/ 34
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
0002 WebSphere DataPower Integration Appliance XI50B and XI50z IBM WebSphere DataPower Integration Blade XI50B, and the WebSphere DataPower Integration XI50z for IBM zEnterprise® are hardware ESBs. WebSphere DataPower Integration Blade XI50B provides all the same functions as the XI52, but is available in a blade form-factor. The WebSphere DataPower Integration XI50z for zEnterprise is also similar in function to the XI52, but is designed for System z environments. For more information about the DataPower XI50, see: http://www.ibm.com/software/integration/datapower/xi50/ 0002 WebSphere DataPower B2B Appliance XB62 IBM WebSphere DataPower B2B Appliance XB62 delivers secure trading partner data integration tracking, routing, and security functions in a network device. This cuts operational costs and improves performance. The XB62 is a nondisruptive technology that can extend your existing B2B implementations and internal integration infrastructure. This function delivers rapid return on investment and reduces total cost of ownership. For more information about the DataPower XB62, see: http://www.ibm.com/software/integration/datapower/b2b_xb60/ 0002 WebSphere DataPower XC10 Appliance IBM WebSphere DataPower XC10 V2 is a purpose-built, easy-to-use appliance that is designed for simplified deployment and hardened security. This deployment is run in the caching tier of your enterprise application infrastructure. XC10 V2 incorporates a large 240 GB cache into the DataPower line of appliances from IBM. It adds elastic caching functions that enable business critical applications to scale cost effectively with consistent performance. WebSphere DataPower XC10 V2 is designed for drop-in use in various application environments. These environments include WebSphere Application Server V6.1, V7.0, V8.0, and V8.5, and other WebSphere family products. With these environments, it can deliver a cost-effective, distributed caching solution in support of jndiName='DefaultDatasource'>
For a list of configuration elements, their subelements, and the attributes that are supported in the server.xml file, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.mult iplatform.doc/autodita/rwlp_metatype_4ic.html
100
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
4.3.3 Flexible configuration You can use the Liberty profile configuration at any level of granularity, from a single file to several files. Several servers can point to a remote XML file for common shareable configuration. This flexible configuration can be achieved by using shareable configuration snippets in the server.xml file, as illustrated in Example 4-6. Example 4-6 Example of using shareable configuration snippets
...
4.3.4 Dynamic configuration In a Liberty profile configuration, the features of the profile provide the configuration default values. Thus, user-specified configuration is kept to a minimum. Any property can be overridden in a user-specific server configuration, and any changes that are made to the configuration are dynamically injected into the contributing feature immediately. There is no need to restart the server. This dynamic configuration provides greater operational productivity to developers as they build the capabilities of an application, modify classes, add resources, and fix problems. The code and configuration changes that developers make can be reflected immediately in the test environment. Figure 4-3 depicts this dynamic configuration. Optional includes Kernel Bundle more.xml
Configuration defaults Configuration metadata
evenmore.xml
Feature Bundle
Configuration defaults Configuration metadata
extra.xml
server.xml Merges user configuration over defaults
Reads default configuration from bundles
Injects merged configuration into bundles
OSGi configuration admin service
Figure 4-3 Flexible and dynamic configuration
Chapter 4. An overview of the Liberty profile
101
4.4 Administering the Liberty profile In WebSphere Application Server V8.5, you can easily administer the Liberty profile configuration files, configure the Liberty profile with web server plug-ins, and capture the Liberty profile server status. You can also package a Liberty profile server configuration with the applications that it runs for distribution to colleagues or for installation on other systems. This section provides information about administering the Liberty profile.
4.4.1 Administering the Liberty profile configuration files A Liberty profile server configuration consists of the following files: 0002 A server.xml file 0002 A bootstrap.properties file 0002 Any optional files that are included by these two main configuration files There is no administrative console for the Liberty profile. However, administrators and developers can use the WebSphere developer tools or a text editor to edit the configuration files. The server.xml file is the primary configuration file for the server. You can edit this file in a text editor. Alternatively, you can use the editor that is part of the WebSphere developer tools to edit the file. The bootstrap.properties file specifies properties that need to be available before the main configuration is processed. The server.env file can be used for specifying environment variables and jvm.options file can be used to customize JVM options. For more information about how to configure the Liberty profile runtime environment, see the WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ba se-dist&topic=twlp_setup_env
4.4.2 Configuring the Liberty profile with a web server plug-in With WebSphere Application Server V8.5, you can configure a web server plug-in for the Liberty profile. When the web server receives an HTTP request for dynamic resources, the request is forwarded to the Liberty profile. The WebSphere Customization Toolbox (WCT) can be used to configure the web server plug-in for single and clustered Liberty servers. The web server plug-in configuration file that describes the servers and applications for routing is generated by using the generateClusterPluginConfig operation of the ClusterManager MBean. The MBean can be access from the jConsole and the WebSphere developer tools. For more information about how to configure the Liberty profile with a web server plug-in, see the WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ba se-dist&topic=twlp_admin_webserver_plugin
4.4.3 Capturing the debug information for a Liberty profile server WebSphere Application Server V8.5 provides the server dump command for problem diagnosis for a Liberty profile server. The file that is generated by this command contains
102
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
server configuration, log information, and details of the deployed applications in the work area directory. A running server usually includes the following information: 0002 0002 0002 0002
State of each OSGi bundle in the server Wiring information for each OSGi bundle in the server A component list that is managed by the Service Component Runtime (SCR) Detailed information about each component from SCR
For more information, see the WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd -zos&topic=twlp_setup_dump_server
4.4.4 Packaging a Liberty profile Because a Liberty profile server is lightweight, it can be packaged easily with applications in a compressed file. This package can be stored, distributed to colleagues, and used to deploy the application to a different location or to another system. It can even be embedded in the product distribution. For more information about how to package the Liberty profile, see the WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd -zos&topic=twlp_setup_package_server
4.4.5 Administering Liberty servers in a collective (New in V8.5.5) You can administer multiple Liberty profiles by using collectives. The collective is a group of Liberty servers in a single management domain. A collective is made of at least one collective controller and one or more members. The role of the collective controller is to provide a single administrative point for MBeans routing, cluster management, and file transfer. Configuring a collective requires defining the appropriate features in the server.xml file for each server and running a few command-line tasks. All Liberty profile servers can be a member of a collective, but the collective controller is only available with WebSphere Application Server Network Deployment and WebSphere Application Server for z/OS. The collective requires at least one Liberty server with the collectiveController-1.0 feature enabled. This server is the collective controller. A Liberty server with collectiveMember-1.0 feature enabled is called a collective member. There can be more than one controller in a collective. A collective member can join more than one controller for failover and workload balancing reasons, but the member communicates with only one controller at a time. The communication between the member and the controller is done over the IBM JMX Rest Controller with MBean operations. Communication between controllers and members is always authenticated and protected with SSL. A controller is a managed server because of the collectiveController-1.0 feature, and does not need the collectiveMember-1.0 feature. When you have a collective with more than one controller, the set of controllers is called a replica set. There can be only one replica set per collective, and all controllers must be part of it. In a replica set, each controller replicates its data to the other controllers, thus providing high availability and data protection.
Chapter 4. An overview of the Liberty profile
103
A Liberty profile collective can be administered by using the command prompt or the Java Management Extension (JMX) MBean Liberty connection. To administer a Liberty profile from the command prompt, generally, use the server command with the ws-server.jar library. For collective specific functions, you must use the collective command with the ws-collectiveutil.jar. This command can be used to perform the following actions: 0002 Create the collective controller configuration 0002 Join the server to the collective controlled by the designated controller 0002 Replicate the target controller so the server can be added to the collective as another server 0002 Remove the server from the collective 0002 Register a host with the collective 0002 Update the authentication information for a host that has been registered with the collective 0002 Unregister a host and all of its associated servers from the collective 0002 Print help information Configuring servers in a collective requires the following steps: 1. Create a Liberty server that will act as a controller. 2. Create the collective configuration by using the collective create command and adding the required information in the server.xml file of the server. 3. Start the controller server. 4. Create a Liberty server that will act as a member. 5. Join the member to the controller by using the collective join command and adding the required information in the server.xml file of the server. 6. Start the member server. For more information about the collective feature, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.doc/ ae/tagt_wlp_server_management.html
Host computer registration with a Liberty collective When a Liberty server is joined to a collective, the associated host system is automatically registered with the collective controller. You can also register more hosts to the collective controller, including those with no WebSphere Application Server product installed. Registering a host allows the collective to access applications, command files, and other resources on the host. The collective registerHost, collective updateHost, and collective unregisterHost commands are used to register a host computer with a Liberty collective controller, update the host information, and unregister a host.
File transfer in a Liberty collective The Liberty collective feature provides the FileService and FileTransfer MBeans that can be used to perform file actions on Liberty servers within a collective. These actions might include updating the server.xml file, bootstrap.properties file, and installing applications. By establishing a remote JMX connection to a controller and using the RoutingContext MBean, you can direct FileService and FileTransfer MBeans calls to any server in the 104
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
collective. The FileTransfer MBean can be used to perform operations on Liberty controllers, Liberty members, and host computers that are registered with the Liberty collective. The FileService MBean can be used only on Liberty profiles and not on host computers. The FileService MBean can be used to perform the following operations: 0002 0002 0002 0002
getMetaData getDirectoryEntries createArchive expandArchive
The FileTransfer MBean can be used to perform the following operations: 0002 downloadFile 0002 uploadFile 0002 deleteFile For more information about the file transfer in a Liberty collective, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.doc/ ae/cwlp_collective_file_transfer.html
Liberty collective security considerations Liberty collective security addresses the administrative domain and the collective repository data.
Administrative domain security The administrative domain security consists of user domain and server domain security. 0002 The user domain security is based on Java role-based security for the Administrator role. Therefore, for a user from the configured user registry to access the collective administration, it must be mapped to the Administrator role. 0002 The server domain security is based on SSL certificate authentication. Communication between servers in the same collective is secured through SSL certificate authentication. Communication between servers in a collective requires SSL authentication to be supported which is ensured by using a clientAuthenticationSupported=”true” specification in the server.xml file. Each server in a collective has its own identity that is composed of its host name, user directory, and server name. Each server in a collective has two keystores that are named by default serverIdentity.jks and collectiveTrust.jks that contain the SSL certificates needed to declare its own identity and securely establish a communication within the collective. To establish an HTTPS inbound connection, each server has two more keystores that are named by default key.jks and trust.jks. The Liberty collective controller keystores contain the following certificates: 0002 In the default serverIdentity.jks keystore, the controller certificate and the controllerRoot certificate 0002 In the default collectiveTrust.jks keystore, the controllerRoot certificate and the memberRoot certificate 0002 In the default key.jks keystore, the server certificate for the controller and the controllerRoot certificate 0002 In the default trust.jks keystore, the memberRoot certificate and the controllerRoot certificate
Chapter 4. An overview of the Liberty profile
105
The Liberty collective member keystores contain the following certificates: 0002 In the default serverIdentity.jks keystore, the member certificate and the memberRoot certificate 0002 In the default collectiveTrust.jks keystore, the controllerRoot certificate 0002 In the default key.jks keystore, the server certificate for the member and the memberRoot certificate 0002 In the default trust.jks keystore, the controllerRoot certificate
Collective repository data security Collective repository data security policy refers to access to the collective repository contents. The security policy for collective repository data uses three nodes named sys.host.auth.info, sys.jmx.auth.info, and sys.nologin. These nodes are located under the repository namespace of a server or host. The sys.host.auth.info and sys.jmx.auth.info nodes are not accessible through the MBean to prevent disclosure of system credentials. Therefore, accessing the data that is stored at these nodes results in a null response. A collective member is restricted to modifying only its own information in the repository. Authenticated administrative users have unrestricted access to information in the repository except as noted above. Authenticated administrative users are all users granted the Administrative role. For more information about collective security, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.doc/ ae/cwlp_collective_sec.html
4.4.6 Clustering Liberty servers (New in V8.5.5) Liberty profile servers that are part of a collective can be clustered for availability and scalability. A Liberty profile server that is already configured into a collective can join a cluster by enabling the clusterMember-1.0 feature in the server.xml file and configuring the cluster name. All members that have the clusterMember-1.0 feature enabled and specify the same cluster name are members of that cluster. The collectiveController-1.0 feature supports several operations on Liberty server clusters through the ClusterManager MBean: 0002 0002 0002 0002 0002 0002 0002
listClusterNames listMembers getStatus getClusterName startCluster stopCluster generateClusterPluginConfig
To set up a Liberty profile servers cluster, perform the following steps: 1. Create a collective of at least two members and a controller. 2. Add the clusterMember-1.0 feature to the server.xml configuration files of the members. 3. Optionally, configure a cluster name that must be unique in the collective.
106
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
4. To access applications that run on the cluster from a web server, install and configure the WebSphere web server plug-in on the web server system. Then generate the plug-in configuration file. For more information about the cluster feature, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.doc/ ae/cwlp_server_clusters.html
4.4.7 Administering a Liberty profile on z/OS WebSphere Application Server V8.5 provides features for administering a Liberty profile on a z/OS platform. You can use IBM MVS operator commands to start, stop, or modify the Liberty profile. For more information, see the WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd -zos&topic=twlp_admin_zos
4.5 Developing and deploying a Liberty profile application A Liberty profile supports web applications, OSGi applications, and Java Persistence API. Associated services, such as transaction and security, are supported for these application types and for Java Persistence API. With its lightweight and easy installation, and quick to use features, the Liberty profile provides a convenient and capable platform for developing and testing web and OSGi applications. This platform is beneficial when you are developing an application to run on the WebSphere Application Server full profile. Any application that runs on the Liberty profile will also run on the full profile. Liberty profile provides the following options to deploy an application: 0002 Dropping the application into a previously defined “drop-ins” directory You can use the “drop-ins” directory for applications that do not require extra configuration, such as security role mapping. 0002 Adding an application entry to the server configuration file For applications that are not in a “drop-ins” directory, you can specify the location of the application as an entry in the server configuration file. The location of the server configuration file can be either a file system path or a URL. You can use the WebSphere developer tools that are supported by WebSphere Application Server V8.5 to develop and deploy applications to a Liberty profile. For more information, see Chapter 11, “Application development and deployment” on page 359. For Liberty collective clusters where an application is deployed on multiple members, you can use a few strategies to manage both the cluster configuration and the applications: 0002 Shared configuration strategy where the configuration and applications that are common to all cluster members are stored in a shared location. In this scenario, the appropriate statements are included in the server.xml file for each cluster member that point to the shared configuration files.
Chapter 4. An overview of the Liberty profile
107
0002 Non-shared configuration strategy where each cluster member has its own configuration files and applications. Any updates that are made to the cluster configuration or applications must be pushed to each cluster member. 0002 File transfer through the Liberty collective controller strategy where a combination of RoutingContext, FileTransfer, and FileService MBeans operations can be used to perform updates to both configuration files and applications of each cluster member.
4.6 The Liberty profile application security The Liberty profile provides support for securing the server runtime environment and web applications. The appSecurity-2.0 feature provides support for user registries, authentication, and authorization. The supported user registry types are basic user registry and LDAP user registry. For secure communication between the client and the server, you can enable SSL for the Liberty profile. A minimal or detailed configuration can be done by adding the ssl-1.0 server feature to the server configuration file. The Liberty profile server also provides various plug points that extend the security infrastructure. (New in V8.5.5) There are several security configuration examples on the wasdev.net website for reference when you are configuring security for your applications on the Liberty profile: https://www.ibm.com/developerworks/mydeveloperworks/blogs/wasdev/entry/snippets?la ng=en
4.6.1 Authentication and authorization For authenticating users, the Liberty profile supports the following configurations: 0002 A basic user registry that defines user and group information for authentication to the Liberty profile 0002 A Lightweight Directory Access Protocol (LDAP) server for authentication 0002 SAF registry (z/OS) 0002 (New in V8.5.5) Federated LDAP registries, where two or more LDAP registries are defined so that the operations, such as a search for a user, are run on all the registries. 0002 (New in V8.5.5) Custom user registries that are installed as an extension to Liberty 0002 Integration with a third-party security service by using trust association interceptors (TAIs). A TAI is used to validate HTTP requests between a third-party security server and a Liberty profile server. The TAI can be called before or after single sign-on (SSO). 0002 SSO, so that web users can authenticate once when accessing the Liberty profile resources such as HTML, JSP files, and servlets. Users can also authenticate once when accessing resources in multiple Liberty profile servers that share Lightweight Third Party Authentication (LTPA) keys 0002 A custom Java Authentication and Authorization Service (JAAS) login module to make more authentication decisions or to make finer-grained authorization decisions inside an application
108
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
To configure authorization for an application, you can add authorization tables to the application. The server then reads the deployment descriptor of the application to determine whether the user or group has the privilege to access the resource. (New in V8.5.0.2) Authorization to resources by using the OAuth 2.0 protocol is supported. OAuth is an open standard for delegated authorization. With the OAuth authorization framework, a user can grant a third-party application access to their information stored with another HTTP service without sharing their access permissions or the full extent of their data. (New in V8.5.0.2) The sync-to-OS-thread feature for z/OS allows the synchronization of a Java thread identity (or JAAS subject) with the OS thread identity during the current Java EE application request. If you do not choose this option, the OS thread identity value is the same as the servant identity value.
4.6.2 Security features for programming models Liberty profile security provides protection for web resources. In V8.5.5, security features have been added to support the new programming models that are included in the Liberty profile: Security support is available for web applications using Servlet 3.0 and (new in V8.5.5) for EJBs when the ejbLite-3.1 feature is present. (New in V8.5.5) Web Services security is supported at the transport layer and at the message level. Transport-level security is based on SSL or Transport Layer Security (TLS), and is used to protect HTTP message contents point to point. Message level security is based on WS-Security.
4.6.3 Administrative security (New in V8.5.5) The server.xml file that defines a Liberty server is composed of configuration elements. These elements can require a user ID and password for access to the feature defined. The Liberty profile provides a utility to support Advanced Encryption Standard (AES) encryption for passwords that are stored in the server.xml file. JMX clients connecting to a Liberty profile have two options. The client can use the local connector, which is protected by the policy that is implemented by the software development kit (SDK) in use. Currently that policy requires that the client runs on the same host as the Liberty profile, and under the same user ID. Clients that want to connect to a remote Liberty profile use the Representational State Transfer (REST) connector. Remote access through the REST connector is protected by a single administrator role and the use of SSL. For more information, see 15.10, “Securing the Liberty profile” on page 528.
4.7 The Liberty profile deployment topologies The Liberty profile is designed to support different ways of preparing a compressed file for deployment. The simplest method is to store all resources in a compressed file. However, resources can be stored as read-only for sharing in some environments. If deployed on a single host, multiple servers can use the shared resources on that host. If deployed to a shared disk, servers on multiple hosts can share the resources.
Chapter 4. An overview of the Liberty profile
109
A Liberty deployment can include the following types of resources: 0002 Project The project is used optionally as a container for resources. Related resources can be grouped under the same project for ease of management and to avoid name conflicts with resources from other projects. 0002 Run time (WebSphere Liberty profile) The run time includes the bin, lib, and lafiles binary files. 0002 Liberty_server The Liberty_server directory contains the following server definitions: – A self-contained directory that includes the server.env file, the jvm.options file, the server.xml file, and other configuration files and working directories. – A template directory that contains just the server.xml file and other configuration files. This directory allows one set of configuration files to be standardized and referred to from multiple server instances. – A localized directory that contains only the server.env file, the jvm.options file, the working directory, and a pointer to a template directory. The localization directory contains only host-specific information: • • • •
Host name The location of the SDK A pointer to the server template directory The location of the application or applications
0002 Application_binary The Application_binary is an archive or a directory that contains the application. This archive or directory might or might not be deployed to a Liberty profile server. 0002 SDK The Java software development kit is used to run the Liberty profile servers. A Liberty profile image is an archive file that contains one or more types of resources of the Liberty profile environment, depending on the topology that is deployed. You can extract them manually or can use an extraction tool to deploy the file to one or more systems. Alternatively, you can use the job manager to deploy these images. In WebSphere Application Server V8.5, the job manager can be used to perform these functions: 0002 Package the Liberty profile runtime environments, configurations, and applications 0002 Distribute and deploy a Liberty profile server and applications 0002 Start embedded profile packages For more information about managing the Liberty profile with a job manager, see 8.3.3, “Liberty profiles managed by a job manager” on page 214.
110
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
4.7.1 Example topology 1 Figure 4-4 illustrates a self-contained topology in which the compressed file contains the following resources: 0002 0002 0002 0002
A Liberty profile run time, which is shown as WLP in Figure 4-4 on page 111 An SDK A Liberty profile server An application
WLP
SDK Deploy Server
Application
Figure 4-4 Self-contained topology 1
4.7.2 Example topology 2 Figure 4-5 illustrates a self-contained topology in which the compressed file contains the following components: 0002 A Liberty profile run time 0002 A Liberty profile server 0002 An application The SDK is preinstalled on each host.
WLP
Server
Deploy
Application
SDK
Figure 4-5 Self-contained topology 2
Chapter 4. An overview of the Liberty profile
111
4.7.3 Example topology 3 Figure 4-6 illustrates a shared topology that involves installation of multiple compressed files. The Liberty profile server and the application are contained within each compressed file. The SDK and WebSphere Liberty profile, however, are preinstalled and shared by different servers.
Server1
Application1 Deploy Server2
WLP SDK
Application2
Figure 4-6 Shared topology 1
4.7.4 Example topology 4 Figure 4-7 illustrates a shared topology where each compressed file contains only the Liberty profile server definition. Applications are pre-deployed as read-only and shared across different servers. The Liberty profile and SDK are preinstalled and shared by different servers.
Server1
App Server2
Deploy WLP SDK
Server3
Figure 4-7 Shared topology 2
112
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
4.7.5 Example topology 5 Figure 4-8 illustrates a shared topology where each compressed file contains only the Liberty profile server definition. Shared artifacts are placed on shared disks and accessed by multiple servers. This topology has a single point of failure, and therefore is not recommended for a production environment.
WLP1 Server1
WLP2 SDK1
Server2
Deploy
SDK2 SDK3
Server3
App1 App2
Figure 4-8 Shared topology 3
For more information, see Appendix B, “Sample topology using the job manager and a Liberty profile” on page 619.
4.7.6 Example topology 6 Figure 4-9 on page 114 illustrates a Liberty collective topology where two controllers are configured in a replica set, and the two collective members are configured in a cluster. An application can be pushed to the Liberty members through the Liberty controller by using a remote JMX connection and the RoutingContext, FileService, and FileTransfer MBeans. The same procedure can be applied for the configuration files. The collective controller replica set provides a way for the clients and members to access the same repository data through multiple controllers. If one controller is down, the other controller in the replica set can be used to run operations to the collective. The Liberty cluster ensures a high availability application-serving environment. Each cluster member can be configured to one or more failover controllers of the replica set.
Chapter 4. An overview of the Liberty profile
113
Figure 4-9 Liberty collective topology
4.8 Troubleshooting Similar to the WebSphere Application Server V8.5 full profile, the Liberty profile provides the base implementations for logs, traces, and first-failure data capture (FFDC). You can control the logging service through either the server configuration file or through the bootstrap.properties file. Logging properties in the bootstrap.properties file take effect before the server configuration files are processed. This process is useful for problem determination during early server start or configuration processing. If you set different logging properties in the bootstrap.properties file and the server configuration file, the server configuration file takes precedence by default. This behavior can be overridden by specifying an override.bootstrap.properties property with a false value in the server configuration file. Remember: The server configuration can be changed dynamically (that is, configuration changes can take effect while the server is running). However, changes to the bootstrap.properties file take effect only on a server restart. You can set logging properties in the server configuration file by using WebSphere developer tools or by adding a logging component to the server configuration file (Example 4-7). Example 4-7 Trace specification in server configuration file
114
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
For more information about the trace and logging feature in the Liberty profile, see the WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ba se-dist&topic=rwlp_logging
4.8.1 Binary logging (New in V8.5.5) The Liberty profile includes a binary logging feature that is based on the WebSphere Application Server full profile HPEL implementation. Binary logging provides a convenient mechanism for storing and accessing log, trace, System.err, and System.out entries that are produced by applications. It is an alternative to the default log and trace facility, which provides the JVM logs and diagnostic trace files that are usually named messages.log and trace.log. Binary logging is designed to perform better than the commonly used text logs. All data that are generated by the application server are stored in a repository and only formatted in a human readable form when required. Binary logging stores data in large blocks, which is more efficient than storing the same amount of data in smaller blocks. By default an 8 KB buffer of data is created in memory before it is written to disk. The buffer is written to disk when the buffer fills, or every 10 seconds, whichever is first. Binary logging is enabled in the bootstrap.properties file, which is read by the Liberty profile only during the server startup process. Example 4-8 shows the basic configuration that is required to enable the binary logging feature. Example 4-8 Enabling Binary Logging in bootstrap.properties file.
# Enable Binary Logging HPEL in bootstrap.properties websphere.log.provider=binaryLogging-1.0 For more information about the binary logging feature in the Liberty profile, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.mult iplatform.doc/ae/cwlp_HPELOverview.html
4.8.2 Timed operations (New in V8.5.5) The timed operations feature enables a measurement system to help locate bottlenecks in database access. When enabled, the timed operations feature periodically creates a report in the application server log that details which operations took longest to run. If you run the server dump command, the timed operation feature generates a report that contains information about all operations it has tracked. You can use the information listed in these reports to decide whether anything is running slower or faster than you expect. The timed operations feature also generates a report to the logs, containing the ten longest JDBC timed operations. The frequency and enablement of this report is configurable in the server.xml file, with a default of once per day. It is possible also disable the generation of report to logs or change the frequency of the report. When a memory dump of the entire server is necessary, the server dump command produces a full report of all timed operations in the messages.log file. The report is grouped by type, and sorted and classified inside each group by the duration each operation took.
Chapter 4. An overview of the Liberty profile
115
To get more detailed information about timed operations, include the change to the logging traceSpecification setting shown in Example 4-9. Example 4-9 Timed Operations configuration example
timedOperations-1.0 For more information about the timed operations feature in the Liberty profile, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.mult iplatform.doc/ae/cwlp_timeop.html
4.8.3 Performance monitoring using MBeans To help diagnose the runtime environment, the Liberty profile provides a list of MBeans and their corresponding management interfaces. This feature allows you to manipulate and monitor a Liberty server by using JMX directly, or using a tool like jConsole. For more information about the MBeans provided with the Liberty profile, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.mult iplatform.doc/ae/twlp_admin_mbeans.html
JMX monitoring using jConsole locally A simple way to access the MBeans in a Liberty profile is to open a jConsole locally and access the JVM that is running the server. When jConsole starts, select Local Process and then select the ws-server.jar server process from the menu. For information about accessing MBeans using jConsole, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.mult iplatform.doc/ae/twlp_admin_localconnector.html
JMX monitoring remotely using the REST connector You can also access the MBeans in a Liberty server remotely by using the REST connector over a secured HTTP connection.
116
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Enabling this feature requires the following basic steps: 1. Enable the restConnector-1.0 feature in server.xml. 2. Enable SSL by using a self-signed certificate or an external certificate. 3. Enable the basic security or an LDAP authentication. 4. Remotely access the server by using the restConnector.jar file and the keystore that contains the certificates of the remote server. A basic example is provided in Example 4-10. Example 4-10 Minimal configuration to enable restConnector feature.
restConnector-1.0 On the client side, you need a keystore that contains the keys that are required to create an SSL channel between the two systems. You also need the connector responsible for converting the JMX calls in REST. This connector is part of the Liberty profile and is available in ${wlp.install.dir}/clients/restConnector.jar. The syntax of the jConsole call from the command line, using an SSL connection, is shown in Example 4-11. Example 4-11 jConsole parameters to use a REST connector in a Linux environment
jconsole -J-Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar: /opt/IBM/WebSphere/LibertyND/clients/restConnector.jar -J-Djavax.net.ssl.trustStore=/home/user/key.jks -J-Djavax.net.ssl.trustStorePassword=mypassword -J-Djavax.net.ssl.trustStoreType=jks -J-Dcom.ibm.ws.jmx.connector.client.disableURLHostnameVerification=true After jConsole is open, a connection string is required to connect to the remote Liberty profile server using an HTTPs channel. Select Remote Process, enter the connection string, and enter a user ID and password that is defined in server.xml. In Example 4-12, the string that is shown can be used to create a connection to a remote system at IP address 10.0.0.2 using the HTTPs port 9443. Example 4-12 Connection string required for the remote connection
service:jmx:rest://10.0.0.2:9443/IBMJMXConnectorREST
Chapter 4. An overview of the Liberty profile
117
For more information about the REST connector feature in the Liberty profile, see the WebSphere Application Server V8.5 Information Center at: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.nd.mult iplatform.doc/ae/twlp_admin_restconnector.html For more information, see Appendix C, “Sample topology for maintenance and troubleshooting using the Liberty profile” on page 631.
4.8.4 Using the OSGi console The Liberty profile uses the Eclipse Equinox implementation of the OSGi core specification. Eclipse Equinox currently provides an OSGi console that can be used to aid with debugging. This console is not available by default, but can be enabled by configuring a port for it. For more information about the Eclipse OSGi console, see the following developerWorks topic: http://www.ibm.com/developerworks/library/os-ecl-osgiconsole/
118
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
5
Chapter 5.
Intelligent Management Intelligent Management provides a virtualized infrastructure that redefines the traditional concepts of Java Platform, Enterprise Edition (Java EE) resources and applications, and their relationships. This application infrastructure virtualization allows the product to automate operations in an optimal manner, increasing the quality of service. By introducing an automated operating environment with workload management, you can reduce total cost of ownership by performing more work using less hardware. The Intelligent Management features are only available in the full profile of WebSphere Application Server Network Deployment and WebSphere Application Server for z/OS. This chapter includes the following sections: 0002 0002 0002 0002 0002 0002 0002 0002
Introduction to Intelligent Management Virtualization, autonomic, and cloud computing Intelligent routing and dynamic operations Dynamic workload management Health management Application edition management Performance management Planning for hosting dynamic operations
© Copyright IBM Corp. 2012, 2013. All rights reserved.
119
5.1 Introduction to Intelligent Management Intelligent Management is the integration of WebSphere Virtual Enterprise into WebSphere Application Server Network Deployment. The Intelligent Management function includes the following key features: 0002 Improved application performance and response times to meet service level agreements 0002 Increased application availability and minimized administration costs 0002 Interruption-free maintenance upgrades Intelligent Management extends the quality of service that is provided by your middleware environment. Configurable operational policies govern the performance and health of your applications. Total cost of ownership is decreased through server consolidation and less administrative effort, and you experience lower response times and increased availability. In short, you experience the benefits of an autonomic middleware environment, which is self-configuring, self-protecting, self-healing, and self optimizing. A key component of the Intelligent Management is the on-demand router (ODR). The ODR is a proxy server based on Java that proxies both the HTTP and SIP protocols. SIP is not supported on the z/OS operating system. The ODR supports health, application edition, and performance management features. It can manage both WebSphere and non-WebSphere environments. The ODR can queue requests for less important applications so that requests from more important applications are handled quickly. Intelligent Management includes the following primary features: 0002 Intelligent routing improves business results by ensuring priority is given to business critical applications. Requests to applications are prioritized and routed based on administrator-defined rules. 0002 Health management allows you to specify conditions to automatically watch for and corrective actions to take when the conditions are observed. You can monitor the status of your application servers, sense problem areas, and then respond to these problem areas before an outage occurs. The health monitoring and management subsystem continuously monitors the operation of servers against user-defined health policies. It detects functional degradation that is related to user application malfunctions. 0002 Application edition management allows you to roll out new versions of applications without experiencing downtime for a maintenance window. You can manage interruption-free production application deployments by using this feature. You can also validate a new edition of an application in your production environment without affecting users, and upgrade your applications without incurring outages to your users. You can also run multiple editions of a single application concurrently, directing different users to different editions. 0002 Performance management provides a self-optimizing middleware infrastructure. Dynamic clusters automatically scale up and down the number of running cluster members as needed to meet response time goals for users. You can take advantage of overload protection to limit the rate at which the ODR forwards traffic to application servers. Doing so helps prevent heap exhaustion, processor exhaustion, or both from occurring. All of these capabilities together allow you to extend qualities of service through autonomic computing. These capabilities are called dynamic operations, which are the core functions that provide application infrastructure virtualization. The Intelligent Management function also provides support for a range of middleware servers. Middleware servers are all servers in the middleware tier that provide the infrastructure for applications or their data. 120
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Middleware server support includes the following servers: 0002 0002 0002 0002
Apache HTTP Server Apache Geronimo Server External WebSphere application servers WebSphere Application Server Community Edition
The term Complete lifecycle server includes any server that the environment can instantiate, or create. These server types include WebSphere Application Server types such as application servers, generic servers, web servers, and proxy servers. The term assisted lifecycle server refers to servers that you define to WebSphere Application Server by using templates to create representations of the servers in the administrative console. However, these servers still exist within the administrative domain of their respective middleware platform. You add them as generic servers to the deployment manager capabilities. You can control the servers operationally, monitor and view server health and performance, and configure the administrative console to display log files and configuration files for these servers.
5.2 Virtualization, autonomic, and cloud computing With Intelligent Management, virtualization, autonomic computing, and cloud computing are integrated into the single architectural model of WebSphere Application Server V8.5.5. The following sections describe these concepts.
5.2.1 Virtualization This section describes the following concepts of virtualization: 0002 Application infrastructure virtualization 0002 Server virtualization
Application infrastructure virtualization Typically, Java applications and resources are statically bound to a specific server. They often experience increases in load that last a short time. The most costly time for an application to become unavailable is during a period of high demand. Therefore, you must build IT infrastructures to accommodate these peaks. Normally, when systems experience normal load, a large percentage of computing capacity goes unused, making inefficient use of IT investments. By configuring application infrastructure virtualization in WebSphere Application Server with the Intelligent Management function, resources are pooled. This pool accommodates the fluctuations of workload in the environment, increasing the quality of service. You effectively break the bond between applications and the physical infrastructure on which they are hosted. Workloads are then dynamically placed and spread across a pool of application server resources, which allows the infrastructure to adapt and respond to business needs. Requests are prioritized and intelligently routed to respond to the most critical applications and users. The static relationships of an application with the server to which it is deployed is replaced with a dynamic relationship. This relationship has looser coupling of applications or resources and server instances. Instead of statically binding applications to servers or clusters, you deploy applications to dynamic clusters. These clusters are application deployment targets that can expand and contract, depending on the workload in the environment.
Chapter 5. Intelligent Management
121
After you deploy applications to dynamic clusters, the placement of the applications is determined by the operational policies that you define. Autonomic managers control the placement of the server instances and how workload is routed to each application. If workload increases for a specific application, the number of server instances for the dynamic cluster that is hosting the application can increase. The application can also use available resources from other applications that are not experiencing increased workload. Virtualization provides the following benefits: 0002 Improved management of software and applications Management processes become more repeatable and less error-prone by using automated services and operational policies. 0002 Allocation of software resources Dynamic reallocation of resources can occur based on shifting distributions of load among applications. 0002 Increased number of applications More applications can run in a virtualized application environment than in a static configuration. 0002 Reduced configuration complexity Loosened coupling between applications and the application server instances reduces the overall complexity and provides for a better, more usable environment. You deploy an application to a dynamic cluster that has a node group or a specified membership policy. A membership policy determines which nodes belong to the cluster. You do not deploy your applications to specific application servers. Instead, the application placement controller starts application server instances for the dynamic cluster based on the settings that you chose for the dynamic cluster. Tip: The Intelligent Management function reacts to an increase in workload by starting an extra application server. Extra application servers can start on the nodes that are selected by the dynamic cluster membership policy to handle more requests for the application.
122
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Figure 5-1 illustrates how the workload increases for a specific application. The number of server instances for the dynamic cluster that is hosting the application can increase by using available resources from other applications. In this example, New Application Server 3 contributes bandwidth to satisfy higher workload requests. The ODR manages this dynamic cluster growth and sends requests to the new server.
Node Agent
WebSphere Application Server Node Agent Node2
WebSphere Application Server Node1 Application Server 1
Application Server 2 NEW Application Server 3
Dynamic Cluster
On Demand Router
WebSphere Application Server Cell
Figure 5-1 Reaction to workload increase
Server virtualization You can combine the advantages that infrastructure virtualization provides with the advantages of hardware virtualization by using both in the same infrastructure. The hardware virtualization capabilities are provided by the physical hardware on which Websphere Application Server is hosted. Using server virtualization, you can share server resources across the virtual servers or logical partitions, as illustrated in Figure 5-2. Server virtualization environments can run in a shared processor mode. When you use shared processor mode, the physical processors are pooled and shared between the servers or logical partitions that are running on the physical computer.
WebSphere Application Server Node1
WebSphere Application Server Node2
Application Servers
Application Servers
Node Agent
Node Agent
Virtual Server 1
Virtual Server 2
Shared Processor Pool
Physical Processor 1
Physical Processor 2
Physical Processor …
Physical Processor n
Physical Server
Figure 5-2 Pool of shared processor that is used by virtual servers
Chapter 5. Intelligent Management
123
Hardware virtualization is not dependent on Intelligent Management, but Intelligent Management can take advantage of hardware virtualization. Server virtualization provides the following benefits: 0002 Reduced amount of hardware in the environment You can run multiple nodes on the same physical hardware. 0002 Improved hardware management You can more easily manage the environment because you have fewer physical computers and can use the server Virtualization software to manage images. 0002 High availability of hardware By configuring server failover, the physical hardware can be highly available. When one server fails, it can be replaced by another server. 0002 Dynamic allocation of hardware The physical resources, such as processors and memory, on hosting computers can be shared among the virtual servers in the environment and dynamically allocated as needed. Because the resources are allocated dynamically, restarting the servers is not necessary. 0002 Shared storage Multiple virtual servers or logical partitions can share physical storage. You do not need a physical hard disk drive for each virtual machine or LPAR. For more information about virtualization, see the following YouTube video: http://www.youtube.com/watch?v=IJM4GIfemT8
5.2.2 Autonomic computing Autonomic computing refers to the self-managing characteristics of distributed computing resources that adapt to unpredictable changes while hiding intrinsic complexity from operators and users. Autonomic computing has evolved into a set of capabilities that are built into many IBM products. Websphere Application Server now includes autonomic computing functions. Using Intelligent Management features, you can create a self-managing environment that serves applications. Intelligent Management can help you overcome the complexity of systems management and reduce the barrier that complexity poses to further growth. An autonomic system makes decisions on its own, using high-level policies. It constantly checks and optimizes the status of the system, and automatically adapts it to changing conditions. An autonomic computing framework can be composed of autonomic components that interact with each other. An autonomic component can be modeled in terms of two main control loops: Local and global. It can include sensors (for self-monitoring), effectors (for self-adjustment), knowledge, and a planner or adapter for using policies that are based on self-awareness and environmental awareness. In a self-managing autonomic system, the human operator takes on a new role. Instead of controlling the system directly, the human operator defines general policies and rules that guide the self-management process. For this self-management process, IBM defines the following functional areas: 0002 Self-configuration: Automatic configuration of components 0002 Self-healing: Automatic discovery and correction of faults
124
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
0002 Self-optimization: Automatic monitoring and control of resources to ensure the optimal functioning concerning the defined requirements 0002 Self-protection: Proactive identification and protection from overload conditions Figure 5-4 illustrates how WebSphere Application Server provides an autonomic system.
Self-configuring
Self-healing
WebSphere Application Server Cell DMGR Node Agents
Application Servers
Autonomic Managers (APC, ARFM and so forth)
Self-optimizing
Self-protecting
Figure 5-3 Websphere Application Server view as an autonomic system
As a comparative example of an autonomic function, consider the human central nervous system. In the human central nervous system, autonomic controls use motor neurons to send indirect messages to organs at a subconscious level. These messages regulate temperature, breathing, and heart rate without conscious thought. In a computing environment, a network of organized computing components provides what you need, when you need it, without a conscious mental or physical effort. Autonomic computing is a comprehensive approach that you can use to build automated IT infrastructures that require minimal intervention. This evolutionary path to autonomic computing is represented by the following levels: 0002 The basic level represents the starting point where a significant number of IT systems are today. Each element of the system is managed independently by systems administrators who set up the element, monitor it, and enhance it as needed. 0002 At the managed level, systems management technologies are used to collect information from disparate systems into one consolidated view. This process reduces the time that it takes for the administrator to collect and synthesize information. 0002 At the predictive level, new technologies are introduced that provide correlation among several elements of the system. The system itself can begin to recognize patterns, predict the optimal configuration, and provide advice on what course of action the administrator needs to take. As these technologies improve, people become more comfortable with the advice and predictive power of the system.
Chapter 5. Intelligent Management
125
0002 The adaptive level is reached when systems go beyond providing advice on actions and automatically take corrective actions based on what is happening in the system. 0002 Finally, the full autonomic level is attained when the system operation is governed by business policies and objectives. Users interact with the system only to monitor the business processes or alter the objectives. WebSphere, if configured with all its core components and its core functions as a full autonomic system, can be considered an autonomic element in a context called computerized ecosystem. It is also considered an artificial neural network (ANN). In this adaptive system, autonomic elements are groups of interconnected nodes that interact with all other autonomic elements without any human intervention. Figure 5-4 shows a system of fully autonomic level elements that are interacting with each other without human intervention by using their autonomic managers.
Analyze
Plan
Autonomic managers KNOWLEDGE to manage, know, tune, adapt, and prevent
Monitor
Execute
Managed element Knowledge
Knowledge
Knowledge
Knowledge
Figure 5-4 Representation of a computerized ecosystem with fully autonomic elements
126
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
5.2.3 Cloud computing Virtualization and autonomic computing are steps toward cloud computing. By building a virtualization foundation, you put the secure, scalable, and efficient system in place on which to build a cloud. From an entry-private cloud, you can deploy advanced cloud functions, including full lifecycle management, automated provisioning, metering, and management capabilities. The cloud service model defines the following services: 0002 Infrastructure as a service (IaaS) IaaS integrates basic services such as virtual servers, data storage, and databases into one platform to deploy applications. IaaS is a web-based service that provisions standard server, storage, network equipment, and software. It uses an automated self-service model. The IaaS model frees resources that would otherwise house, run, and maintain equipment and software. An IaaS approach is ideal for resource-intensive activities such as development, testing, and other dynamic workloads. 0002 Platform as a service (PaaS) PaaS enables developers to build and deploy web applications on a hosted infrastructure. It also allows them to take advantage of the seemingly infinite compute resources of a cloud infrastructure. 0002 Software as a service (SaaS) SaaS provides network-based access to commercially available software. It can lead to increased speed of software development, faster adoption of software, fewer support requirements, and ease in implementation and upgrades. For more information about cloud computing, see: http://www.ibm.com/cloud-computing/us/en You can also subscribe to the IBM Cloud YouTube channel for latest videos: http://www.youtube.com/user/IBMCloud
5.3 Intelligent routing and dynamic operations Loss of availability translates into lost business, which means lost opportunity and lost revenue. To avoid this problem, the dynamic operations environment is a fluid environment that enables applications to be available continuously through these processes: 0002 0002 0002 0002 0002
Application virtualization Virtualization of WebSphere resources Provisioning of WebSphere applications Prioritization and scheduling of applications Integration with overall dynamic operations environment infrastructure management
The dynamic operations environment consists of autonomic managers whose purpose is to maximize utilization by using defined business goals. You can monitor performance metrics, analyze the monitored data, offer a plan for running actions, and run these actions in response to the flow of work. Dynamic operations allow an application environment to scale as needed by virtualizing WebSphere resources and by using a goals-directed infrastructure. Thus, you can increase the speed at which your company can adapt to business demands.
Chapter 5. Intelligent Management
127
In traditional WebSphere Application Server environments, applications are deployed directly to servers or a static cluster of servers that are running on specific hardware systems (nodes). When the server starts, the application starts. A peak load on one system cannot take advantage of resources that are sitting idle on another system. With Intelligent Management, applications are mapped to dynamic clusters that are spread throughout hardware pools. Each node in the dynamic cluster can run on one or more instances of an application server. The server can be started to accommodate the demand for that application, which is called dynamic application placement.
5.3.1 Key components of dynamic operations This section provides information about the key components of dynamic operations.
Operational policies An operational policy is a business or performance objective that supports specific goals for specific requests. Operational policies include service and health policies. Service policies are addressed in the next section. For more information about health policies, see 5.5, “Health management” on page 134.
Service policies Imagine an environment with several applications where all client requests are given the same priority. This configuration makes it difficult to manage the system and provide the resources where they are most needed. One solution is to install critical applications in a separate system to enhance their performance. However, this configuration might not make the most efficient use of resources. A better solution is to use Intelligent Management capabilities to define service policies, and to categorize and prioritize work requests. You can use service policies to designate performance goals and the business importance of applications. With service policies, you can classify, prioritize, and intelligently route workload. You can also adjust resources if needed to consistently achieve service policies. Service policies are a technical implementation of service level agreements (SLAs) in place between the business area and the IT area that is running their applications. Service policy definitions include the following key items: 0002 The importance portion is used in times of resource contention to identify the most important work in the system and to give it higher priority. The options for importance vary from lowest to highest. Administrators who know the relative importance of applications can create realistic performance goals. 0002 The goal portion of the service policy defines how incoming work is evaluated and managed. It detects whether the work is meeting its assigned service policy levels. Service policies can have the following goals: – Discretionary – Average response time – Response time percentile Specifying the goal portion of the service policy is optional. If you do not specify any goals, only the importance portion is used.
Node groups A node group is a set of systems (nodes) that can host one or more applications. There can be more than one node group within an Intelligent Management cell. An application is placed into a node group, and is optimized based on service policies. Before you define node groups, 128
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
you need to know the systems that you want to include in the environment. That is, are all systems identical in terms of resources? Does an application need to be deployed on a specific set of systems because of its prerequisites?
Dynamic clusters A dynamic cluster is a server cluster that uses weights and workload management to balance the workloads of its cluster members dynamically. It balances based on performance information that is collected from the cluster members. Dynamic clusters expand to respond to workload demand and user-defined service goals and policies. Dynamic clusters consist of a number of servers that can stop or start in response to changing workload. When you define a dynamic cluster, you define nodes that host application servers within that dynamic cluster. The member nodes can be designated, or be defined by rules. The latter is only possible with application servers with full lifecycle support. When membership is rules-based, any new nodes added to the cell that meet the rule criteria are automatically added to the dynamic cluster. Application servers are defined automatically on the membership nodes according to properties set in the dynamic cluster. Dynamic clusters are similar to the server clusters that you can create with WebSphere Application Server Network Deployment, but key differences exist that make dynamic clusters much more robust. For complete lifecycle management servers, the product controls the creation and deletion of server instances, and can start and stop servers. For assisted lifecycle management servers, the product can control the state of servers by stopping and starting servers from a pool of predefined server instances. Tip: You can use dynamic cluster isolation to isolate applications from other applications that are deployed in the cell. For example, you might create a dynamic cluster isolation configuration to isolate the critical applications that an external customer uses from internal applications that can tolerate some instability.
The on-demand router The on-demand router (ODR) is an intelligent Java-based HTTP proxy server and Session Initiation Protocol (SIP) proxy server that is built on the WebSphere run time. The ODR is asynchronous, high performance, and scalable. It can be clustered for high availability. The ODR handles the queuing and dispatching of requests according to operational policy. An ODR can be defined and started before any service policies are defined. Operational policies can be defined before the appearance of the work to which they apply. However, if policies are not defined, the early work is handled by the default policies. The ODR uses session affinity to route work requests. After a session is established on a server, later work requests for the same session go to the original server. This configuration maximizes cache usage and reduces queries to resources. The ODR accepts incoming requests, and distributes these requests to the system in an intelligent manner according to configured business goals. This process depends on the characterization of requests so that the relative business importance of each request can be compared.
Web server plug-in enabled for Intelligent Management In versions before V8.5.5, the ODR is implemented as a server process. This option still exists in V8.5.5, and as an alternative, you can enable an Apache or IBM HTTP Server for Intelligent Management through the web server plug-in. Moving the ODR function to the web server plug-in can provide a gain in performance and decreased latency because there is one less “hop” in the topology.
Chapter 5. Intelligent Management
129
Web server plug-in support for Intelligent Management: Not every ODR server feature is implemented in the web server plug-in. It does not support load balancing or failover across cells, there is no processor or memory load protection, and it does not queue or reorder requests based on service policies. Also, it does not support a highly available deployment manager topology. Figure 5-5 illustrates how the ODR, in this case a web server plug-in with Intelligent Management enabled, dynamically distributes traffic between application servers in two different dynamic clusters. An equal amount of work can flow into the ODR. However, after the work is categorized, prioritized, and queued, a larger volume of work can be given a higher priority to be processed. A smaller volume of less important work might be sent to application servers or even wait in the queue until the application servers are able to serve the requests.
WebSphere Application Server Node2
WebSphere Application Server Node1
Application Servers
Application Servers Node Agent
Node Agent
Virtual Server 2
Virtual Server 1
Dynamic Cluster A
On Demand Router (ODR) Web Server + Web server plug-in with Intelligent Management enabled
Dynamic Cluster B
Physical Server
WebSphere Application Server Node3
WebSphere Application Server Node4
Application Servers
Application Servers
Node Agent
Node Agent
Virtual Server 3
Virtual Server 4
Physical Server
Figure 5-5 ODR routing concepts
When Intelligent Management is enabled in the web server plug-in, the plug-in connects to a REST service to dynamically gather routing information for one or more WebSphere cells. A REST-based control connection is used to check the components’ availability, and the WebSphere plug-in fails over when needed. The REST-based service runs in the deployment manager and node agents.
130
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
High availability deployment manager topology Configuring a high availability deployment manager function in an Intelligent Management topology provides a hot-standby model for availability. With this support, you can define two or more deployment managers and start them in the same cell. One deployment manager is active, called the primary deployment manager. This deployment manager hosts the administrative function of the cell. The other deployment manager or managers are backup managers in standby mode. When in standby mode, you cannot use the deployment manager to perform administrative functions. If the active manager is stopped or fails, a standby manager takes over and is designated the new active deployment manager. The benefit of the highly available deployment manager function is that it eliminates the deployment manager as a single point of failure (SPOF) for cell administration. This SPOF is important in environments that have significant reliance on automated operations, including application deployment and server monitoring. Web server plug-in support for Intelligent Management: The high availability deployment manager topology is only supported using on-demand router servers. It is not supported by using the web server plug-in with Intelligent Management enabled. For more information, see 10.10, “Highly available deployment manager” on page 352.
5.3.2 Autonomic managers With Intelligent Management, you can introduce autonomic capabilities into your infrastructure at your own pace. Autonomic capabilities are delivered in a set of components that are known as autonomic managers. Autonomic managers monitor performance and health statistics through a series of sensors, and optimize system performance and run traffic shaping. The Intelligent Management includes the following autonomic managers as part of the dynamic operation functionality: 0002 0002 0002 0002
Autonomic request flow manager Dynamic workload controller The application placement controller The on-demand configuration manager
Autonomic request flow manager Traffic shaping is managed by the autonomic request flow manager (ARFM). The ARFM classifies incoming requests and monitors the performance of service classes on a continual basis. It contains the following components that prioritize incoming requests: 0002 A controller per target cell, which is the cell to which an ARFM gateway directly sends work. This controller is a process that runs in any node agent, ODR, or deployment manager. 0002 A gateway per combination of protocol family, proxy process, and deployment target. A gateway runs in its proxy process. For HTTP and SIP, the proxy processes are the ODRs. For Java Message Service (JMS) and Internet Inter-ORB Protocol (IIOP), the proxy processes are the WebSphere Application Server application servers. 0002 A work factor estimator per target cell, which is a high availability (HA) managed process that can run in any node agent, ODR, or deployment manager. ARFM controls the order of requests into the application server tier and the rate of request flows. Using classification and the defined service goals, the ARFM decides how and when to Chapter 5. Intelligent Management
131
dispatch HTTP requests to the next tier. The ARFM also decides when IIOP and JMS requests are run at the application server tier, even though these requests are not routed through the ODR. For IIOP requests, only stand-alone Enterprise JavaBeans (EJB) clients are supported. JMS support is only for message-driven beans. An ODR contains the ARFM. The ARFM prioritizes inbound traffic according to service policy configuration and protects downstream servers from being overloaded. Traffic is managed to achieve the best balanced performance results, considering the configured service policies and the offered load. For an inbound User Datagram Protocol (UDP) or SIP message, the ODR can route the message to another ODR. That router can then check for and handle UDP retransmissions.
Dynamic workload controller The dynamic workload controller dynamically adjusts server weights to even out and minimize response times across the cluster. There is one dynamic workload controller per cluster. The dynamic workload controller maintains a list of active server instances for each dynamic cluster, and assigns each a routing weight according to observed performance trends. Requests are then routed to candidate server instances to balance workloads on the nodes within a dynamic cluster based on a weighted least outstanding requests algorithm.
The application placement controller The application placement controller is responsible for the management of an application’s location within a node group. A single application placement controller exists in the cell and is hosted in the deployment manager or in a node agent process. The application placement controller starts and stops application server instances to manage HTTP, SIP, JMS, and IIOP traffic. The application placement controller can dynamically address periods of intense workflow that would otherwise require the manual intervention of a system administrator.
The on-demand configuration manager The on-demand configuration manager maintains cell topology information and keeps the ARFM and other controllers aware of its environment. It tracks updates in cell topology and state, including the following changes: 0002 0002 0002 0002
Applications installed and removed Servers started and stopped Nodes added and removed Classification updates
The on-demand configuration component allows the ODR to sense its environment. The ODR dynamically configures the routing rules at run time to allow the ODR to accurately route traffic to those application servers.
5.4 Dynamic workload management Dynamic workload management is a feature of the ODR. It applies the same principles as Workload Manager (WLM), such as routing based on a weight system, which establishes a prioritized routing system. The dynamic workload controller autonomically sets the routing weights in WLM. With workload management, you manually set static weights in the administrative console. The system can dynamically modify these weights to stay current with the business goals.
132
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
The dynamic workload controller can be disabled. If you intend to use the automatic operating modes for the components of dynamic operations, do not set static WLM weights. Doing so prevents the on-demand function of the product from working properly. The dynamic workload controller also applies to IIOP traffic if the following conditions apply: 0002 The client is using the WebSphere Application Server Java Development Kit (JDK) and Object Request Broker (ORB) 0002 The “prefer local” flag is not set for the application
5.4.1 Request flow prioritization by using service policies ARFM controls the flow of requests for HTTP and SIP traffic through the ODR, and for IIOP and message-driven bean traffic from within an application server. It uses a concurrency -based or a rate-based algorithm that results in a more consistent loading and protecting of application server resources by ARFM. Remember: A service policy is a user-defined categorization that is assigned to potential work as an attribute that is read by the ARFM. You can use a service policy to classify requests based on request attributes. These attributes included the Uniform Resource Identifier (URI), the client name and address, HTTP headers, query parameters, cookies, time of day, and so on. By configuring service policies, you apply varying levels of importance to the actual work. You can use multiple service policies to deliver differentiated services to different categories of requests. Service policy work classes are used to group requests or messages into a group or class of work. Each request belongs to exactly one work class. Each work class contains zero or more rules that are evaluated for each request that is associated with the work class. Each rule contains an associated service policy that is used if the rule matches. If no rule is matched, the default service policy that is associated with the work class is used. The service policy that is associated with the request or message is then used to govern if and for how long a request is queued. This determination is based on the current demand and resource usage of the target application servers. After you define service policies and associated different service policies through configuration of work classes, you can categorize and prioritize work.
5.4.2 Enabling dynamic clusters Dynamic clusters work with autonomic managers, including the application placement controller and the dynamic workload controller, to maximize the use of computing resources. Dynamic clusters are required to achieve the server consolidation benefits that are offered by the Intelligent Management features. With the Intelligent Management function, you can define performance goals and bind them to specific subsets of the incoming traffic. The ODR and associated autonomic managers support business goals in times of high load. They do so by making workload management decisions about the work that is being sent through the ODR. Not all the work in a configuration is equally important. The ODR can support this concept by forwarding different flows of requests more or less quickly to achieve the best balanced result and maintain the quality of service.
Chapter 5. Intelligent Management
133
5.5 Health management You can use the health management feature to monitor the status of application servers. You can use this monitoring to sense and respond to problem areas before an outage occurs. You can manage the health of an environment with a policy-driven approach that enables specific actions to occur when monitored criteria is met. For example, when memory usage exceeds a percentage of the heap size for a specified time, health actions can run to correct the situation. Health monitoring can help you with both unexpected issues and unanticipated problems in your environment. It can help you bypass problems that would otherwise disrupt operations and affect performance. Consider the Intelligent Management health management feature if you want the following capabilities: 0002 Automatically detect and handle application health problems without requiring administrator time and intervention 0002 Intelligently handle heath issues in a way that maintains continuous availability 0002 Requires administrator approval before an autonomic action is run 0002 Treats different applications in different ways, because not all of applications have the same health policies The health management feature consists of the following components: 0002 Health policies 0002 Health controller
5.5.1 Health policies With health management, you define health policies. A health policy works like a service policy, except that the health policy provides a health goal for the environment. Each health policy consists of a condition, one or more actions, and a target set of processes. Health policies are designed to identify potential problems, and take corrective action when an event occurs. You can define health policies for common or custom server health conditions. These policies can monitor the system at the cell, dynamic cluster, static cluster, or application server or node level. Intelligent Management comes with predefined health conditions, such as excessive memory usage and excessive request or response times, for use in building a health policy. Health management includes the following standard policies: 0002 Monitor when the heap usage goes above a threshold, or a memory leak is detected, or when the percentage of time that is spent in garbage collections goes above a threshold 0002 Monitor when a server reaches a certain age or services a certain number of requests 0002 Monitor the percentage of timeout requests or the average response time Tip: You can build a custom health policy by using a custom expression to define the condition. Custom conditions are built based on metrics that are gathered at the ODR or server, Performance Monitoring Infrastructure (PMI) metrics, MBean operations, and attributes. A few examples include hung thread detection, and database connection pool exhaustion or slow down.
134
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
When a health policy violation is detected, an action plan can be put into effect automatically. Actions to be taken when a monitored condition is detected are designed to bypass the problem and help in diagnosis. You can select the following predefined actions: 0002 0002 0002 0002 0002
Notifying an administrator Sending a Simple Network Management Protocol (SNMP) trap Restarting a server Putting a server into maintenance mode Generating Java cores or heap memory dumps for use in diagnosing the problem
You can also define a custom action to be taken. Actions can be taken automatically, or you can have them occur in supervised mode. Supervised mode requires an operator to confirm the action.
Heath conditions Health conditions define the variables that you want to monitor in your environment. Several categories of health conditions are predefined. You can also create a health policy that defines a custom condition when the predefined health conditions do not fit your needs. The following predefined health conditions are available: 0002 Age-based Triggers when members associated with this policy reach a certain age value. You can use the age-based condition on all server types. 0002 Excessive request timeout Triggers when requests that are directed to an associated member timeout, and the percentage of timeouts exceed the specified value. You can use the excessive request timeout condition on all server types. 0002 Excessive response time Triggers when the members that are associated with this detection-based policy have an average response time for requests that exceed a certain amount of time. You can use the excessive response time condition on all server types. 0002 Excessive memory usage Triggers when the members associated with this detection-based policy use more memory than a percentage of the maximum heap size for a certain amount of time. 0002 Excessive garbage collection Triggers when the Java virtual machine (JVM) spends more than a configured percentage of time when running garbage collections. 0002 Memory leak Looks for consistent downward trends in free memory that are available to a server in the Java heap. The detection level setting determines when these trends are detected. The slower detection level setting requires the most historical data. The normal and faster detection level settings require the same amount of historical data. However, the faster setting allows analysis before the Java heap expands to its maximum configured size. This setting provides earlier detection capability, but it is also more prone to false positives. This condition supports heap memory dumps in addition to server restarts as reactions. 0002 Storm drain Detects situations where requests are shifted toward a faulty cluster member that advertises low response times. This condition is triggered when there is a significant drop
Chapter 5. Intelligent Management
135
in the average response time. The drop in response time, along with a detected increase in dynamic weights for a cluster member, is detected by the ODR. 0002 Workload Triggers when the members that are associated with this policy serve a user-defined number of requests. You can use the workload condition on all server types.
Heath actions Depending on the configuration of the health policy, different health actions are run if a policy breach is detected: 0002 Restarting the application server When a server is a member of a dynamic cluster, another instance of the dynamic cluster is started. This instance serves user requests before the server that triggered the policy breach is shut down. This process allows WebSphere to handle potential issues with the least amount of impact to its consumers. 0002 Taking a thread memory dump (JavaCore) Three JavaCores are generated for this action. The option to take thread memory dumps is only supported for application servers that run in IBM JVMs. 0002 Putting a server into maintenance mode Maintenance mode is used to run diagnostic actions, maintenance, or tuning on a node or server without disrupting incoming traffic. Putting a server into maintenance mode allows the remaining requests on the server to be processed. Any requests that have an open session on the server are routed to the server until the session ends or times out. After all requests are completed, the server is moved to maintenance mode. Any new requests are routed to servers that are not in maintenance mode. 0002 Putting a server into maintenance mode and breaking HTTP and SIP affinity The same process as the previous action occurs, but the HTTP and SIP session affinity to the server is broken. 0002 Taking a server out of maintenance mode After the server reaches a healthy state, it can be reinstated to serve requests. For example, if a server exceeds a memory threshold, putting it in maintenance mode gives it a chance to recover. It can free up memory through garbage collection while no new requests are being sent to it. After heap usage is back below the threshold, the server can be taken out of maintenance mode. 0002 Creating a custom action With a custom action, you define an executable file or Java code to run when the health condition occurs. A custom action must be created before you can use it in a health policy. Remember: All actions are available for all health policies.
Reaction mode The health management feature functions in a reaction mode that defines the level of user-interaction when the health condition determines corrective action is needed: 0002 Automatic mode When the reaction mode on the policy is set to automatic, the health management system acts when a health policy violation is detected. The data is logged, and the defined reaction is run automatically.
136
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
0002 Supervised mode The health management system creates a runtime task that proposes one or more reactions. The recommendations on actions are sent to the administrator who can then approve or deny them. If the administrator follows the recommendations, the only action that is required is clicking a button to run the actions.
5.5.2 Health controller The health controller is an autonomic manager that constantly monitors the defined health policies. When a condition specified by a health policy is not met in the environment, the health controller assures that the configured actions are taken to correct the problem. To use health monitoring, you must make sure that the health controller is enabled. After you configure and enable the health controller, it runs as part of the cell. There is one controller per cell. The health controller is a highly available controller that runs in the deployment manager or a node agent process. If the active process fails, the health controller can become active on another node agent or deployment manager process. You can use the runtime topology in the administrative console to learn which process hosts the health controller. You can disable or enable health management by using the health controller. If the health controller is disabled, no health policy monitoring occurs. You can also apply limits to the frequency that the server restarts or prohibit restarts during certain periods.
5.5.3 Planning for health monitoring Health management is not meant to replace the testing and benchmarking phases of the application development lifecycle. However, if the system has stability problems or you are unsure about the stability of an application, consider applying policies to the application. These policies are especially useful in the following health conditions: 0002 0002 0002 0002
Excessive request timeout Excessive response time Excessive memory usage Excessive garbage collection
In addition, give particular consideration to the custom PMI health conditions and actions that are listed in Table 5-1. Table 5-1 Suggested actions for PMI custom health conditions PMI module
PMI metric
Sample expression
Suggested actions
Thread pool module
Concurrently hung threads
PMIMetric_FromLastInterv al$threadPoolModule$conc urrentlyHungThreads > 3L
Take thread dump files and then restart server
Process module
Process total memory (KB)
PMIMetric_FromLastInterv al$xdProcessModule$proce ssTotalMemory > 2048L
Restart server
Connection pool module
Average wait time (milliseconds)
PMIMetric_FromLastInterv al$connectionPoolModule$ avgWaitTime > 5000L
Start custom action or notify administrator of database issues
Chapter 5. Intelligent Management
137
5.6 Application edition management Companies commonly have a build and deployment process that is used while an application moves from development to production. A source control system is normally used to store the application source code and related artifacts. These library systems are typically designed to store multiple versions of these parts. The concept of an application version is established in the context of software libraries and build processes. With the Intelligent Management function, you can store these application versions in the system management repository and deploy them as needed. While source control systems typically store the source code, the system management repository stores the compiled code. You need both. Using application edition management, you can validate a new edition of an application in your production environment. This process does not affect users, so you can upgrade your applications without causing outages for your users. You can also run multiple editions of a single application concurrently, directing different users to different editions. The application edition management feature also provides an application versioning model that supports multiple deployments of the same application in a cell. You can choose which edition to activate on a cluster, so you can roll out an application update or revert to a previous level. Consider the Intelligent Management application edition management feature if you want the following capabilities: 0002 Incur no downtime when you update applications or the environment. 0002 Run multiple versions of applications concurrently. 0002 Verify that a new version of an application runs in production before you direct user traffic to the application. 0002 Reduce infrastructure costs and decrease outages in the production environment. 0002 Update an operating system or WebSphere environment easily without incurring downtime to the environment. 0002 You can use the application edition manager feature if you are using WebSphere Batch and want to perform a rollout to batch applications.
5.6.1 Key features The application edition manager provides an application versioning model that supports multiple deployments of the same application in an Intelligent Management cell. The application edition manager interacts with the ODR, dynamic workload manager, and application placement manager. This integration ensures predictable application behavior when you apply application updates. You get a smooth transition from one application edition to another while the system continues to manage your application performance goals. The application edition manager’s edition control center in the administrative console provides control over the application update and rollout process. This process includes edition activation across the application servers to which your application is deployed. Scripting APIs enable the integration of edition management functions with automated application deployment. The application edition manager provides support for interruption-free application upgrades only for applications that are accessed through the ODR by way of HTTP or HTTPS. Service 138
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
continuity during application upgrade is not assured for inter-application access unless the inter-application access is accomplished by way of HTTP or HTTPS through another ODR layer.
5.6.2 Terminology The application edition manager feature includes the terminology that is described in the following sections.
Application editions An application edition represents a unique instance of an application in the environment. An application edition encompasses both application versions and deployment bindings. An application edition is an application that is uniquely identified by the combination of an application name and an edition name.
Edition names and descriptions With application edition manager, you can install multiple editions of the same application. Each edition is identified with an application edition name and description. The edition name is a field in which you can specify a value to uniquely identify one application edition from other editions of the same application. Create a version number scheme for naming editions that is meaningful in your environment. Multiple editions of the same application have the same application name but different edition names. When you deploy an application, you can also specify an edition description next to the edition name, which gives you the ability to store more information.
Non-destructive update The existing application installation and update functions in Network Deployment are destructive. That is, they replace the old instance of the application with a new instance. Installing an application edition is non-destructive. You can install any number of application editions and keep them in the system management repository.
State Each application edition that is deployed has a state that identifies the status of the application edition. Each application edition must be in one of the following states or modes: 0002 Active 0002 Inactive 0002 Validation Because the application edition changes from one state to another, various actions occur, such as installing, validating, activating, running a rollout, deactivating, and uninstalling. After installing a new edition of an application, the new edition is only activated if there is not already an active edition deployed to the same cluster. For each application and deployment target combination, there can be at most one edition in active mode and one edition in validation mode. An edition that is in the inactive state is not started when an application server starts.
Chapter 5. Intelligent Management
139
5.6.3 Concepts The application edition management feature provides the following capabilities: 0002 Rollout indicates policies that allow you to switch from one edition to another edition with no loss of service. 0002 Concurrent activation where multiple editions can be concurrently active for an extended period. 0002 A validation mode to send selective traffic to verify the correct operation.
Rollout Rollout activation activates one edition in place of another, ensuring an interruption-free update in the process. Thus, all application requests are serviced during the rollout and none are lost. This process ensures continuous application operation from the perspective of the customers of that application. To do so, the application edition manager carefully coordinates the activation of the edition and the routing of requests to the application. During rollout, you make the following choices: 0002 Soft or hard rollout A soft rollout stops and starts only the application, whereas a hard rollout stops and starts the application server. You might consider a hard rollout if an application must reload native code. 0002 Atomic or group rollout An atomic rollout ensures that two editions do not service requests at the same time, whereas a group rollout does not ensure this. The atomic rollout can queue requests briefly in the ODR to ensure atomicity. A group rollout does not queue requests. 0002 Drainage interval The drainage interval is the maximum amount of time that the application edition manager waits for sessions to expire before stopping an application server. During this interval, no new sessions are established on the application server, but requests with affinity continue to be routed to the application server. If all sessions expire before the completion of the drainage interval, the application server is stopped and the rollout continues. Therefore, this interval is the maximum time to wait, but the actual time might be much shorter, depending on the active session count. Replacement of one edition with another in a production environment requires certain discipline in the evolution of the application. Because edition replacement happens while application users are potentially accessing the previous application edition, the new edition must be compatible with earlier versions. Thus, the new edition cannot add or change any existing application interfaces, including essential behavior. New interfaces can be added. In addition, existing interfaces can be algorithmically corrected and, in some cases, even extended and remain compatible with existing application users.
140
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Figure 5-6 shows an example of a group rollout scenario. In the diagram, a dynamic cluster is created that consists of three servers. You first must divide the cluster into groups, which tells the application edition manager how many servers to update at the same time. Performing a rollout to a group results in the servers in each group being upgraded to the new edition at the same time. Each server in the group is quiesced, stopped, and reset.
Quiesce and stop
Edition 2.0
Restart
Edition 1.0
Application requests
On-demand routers
Edition 1.0 Dynamic cluster
Figure 5-6 Rollout policies
As the rollout is run in Figure 5-6, one server in the cluster is moved from Edition 1.0 to Edition 2.0. During this time, the server does not receive user requests that are directed from the ODR, and the server is stopped. All application requests are sent to the servers that are running Edition 1.0. After the server that is running Edition 2.0 is available, application requests are directed by the ODR to that server. Any servers that are still running Edition 1.0 do not serve requests until the edition is updated to Edition 2.0.
Concurrent activation Concurrent activation enables you to activate the same edition on different servers or clusters. To use multiple editions concurrently, you must distinguish user requests from one another so that the requests are sent to the application server that hosts the appropriate edition. For example, if you introduce a new edition of an application, you might want only a select group of users to test the edition. When multiple editions of the same application are concurrently available to users, the ODR needs information to differentiate between the active editions. Based on that information, it then intelligently routes the request to the intended edition. You must configure a routing policy that tells the ODR to which edition to route a request. The routing policy is stored as part of the application metadata.
Chapter 5. Intelligent Management
141
Figure 5-7 shows an example of concurrently active editions. Two clusters host different application editions. The ODR uses the routing policies to determine where to deliver user requests when multiple editions of an application are activated.
Routing policy
Cluster 1
Edition 1.0
On-demand routers
Edition 2.0
Legends: Edition 1.0 requests Edition 2.0 requests
Cluster 2
Figure 5-7 Concurrent activation
Validation mode Validation activation is a special form of concurrent activation. It activates an edition on a clone of its original deployment target. The clone is created on activation of the edition. After the validation rollout to the original deployment target, the clone is removed automatically. This action allows you to perform final pre-production testing of an application edition in the actual production environment with a selected set of users. To run a validation mode scenario, the actual deployment target is cloned. The target edition is then activated on the cloned environment. Routing policies are used to tell the ODR how to divert selected user requests to the new edition.
142
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Figure 5-8 shows an example of the validation mode.
Routing policy
Dynamic cluster DC1
Edition 1.0
Clone
On-demand routers
Edition 2.0
Legends: Edition 1.0 requests Edition 2.0 requests
Dynamic cluster DC1-validation
Figure 5-8 Validation mode
5.6.4 Maintenance modes Periodic product maintenance is important to keep your system environment working correctly, and to avoid trouble caused by known issues. At some point in time, you might have a problem with a server and need to run diagnostic tests to troubleshoot a specific application server. These situations can lead to the disruption of client requests to servers in your environment. Using the Intelligent Management feature, you can maintain the environment without disrupting traffic to the production environment. You can use it to administratively put a server or node in the cell into maintenance mode. In a normal mode, the ODR sends requests to application servers. Using maintenance mode, you can stop routing from the ODR to the nodes or servers that are placed into maintenance mode. This action maintains these nodes or servers with minimum disruption to your environment. The Application Placement Controller also excludes the node or server from automatic application placement. Maintenance mode is only recognized by the ODR. However, the heath controller also uses the server maintenance mode as an action that is taken when a health policy is breached.
Node maintenance mode You can put a node into maintenance mode when you need to apply operating system fixes or run WebSphere maintenance. When a node is in maintenance mode, only traffic with affinity to servers on the node is routed to the server by the ODR. A maintenance immediate stop mode can be set that immediately stops the servers on the node.
Chapter 5. Intelligent Management
143
Server maintenance mode You can put a server into maintenance mode when you need to perform server level problem determination. When an application server is placed into maintenance mode, you can indicate one of these modes: 0002 Allow all traffic to the server 0002 Allow only traffic with affinity 0002 Allow no traffic during the maintenance period The maintenance immediate stop mode is also available that immediately stops the application server. Each of the maintenance modes for nodes and servers can be enabled by using the administrative console or through wsadmin scripting.
5.7 Performance management The performance management feature provides dynamic cluster capabilities and overload control. With dynamic clusters, you can automatically scale up and down the number of running cluster members as needed to meet response time goals for your users. You can use overload protection to limit the rate at which the ODR forwards traffic to application servers. Doing so helps prevent heap exhaustion, processor exhaustion, or both from occurring. Consider the Intelligent Management performance management feature if you want the following capabilities: 0002 Associate service policies with your applications and have WebSphere efficiently manage these goals 0002 Decrease administrative effort that is required to monitor and diagnose performance issues 0002 Minimize the number of JVMs and virtual machines that run to reduce processor usage that is incurred by idle or lightly used JVMs or virtual machines 0002 Protect your middleware infrastructure against overload
5.7.1 Workload management with dynamic clusters A dynamic cluster is a virtual cluster of application servers that hosts an application. These application servers are on groups of nodes that are indicated by using the node group function. The membership policy is compared against the nodes in your cell and servers are created for the dynamic cluster by using nodes that match the policy. When new nodes are added to your environment, they are added automatically to the dynamic cluster if they match the defined membership policy. When configuring a dynamic cluster, you can use the following settings: 0002 Minimum number of cluster instances where you can select to have one or more servers started at all times. You can also stop all servers in times of inactivity. 0002 Maximum number of cluster instances where you can limit the number of servers that can start. 0002 Vertical stacking of instances on a node where you can indicate whether you want to allow more than one server instance to be started on the same node. 0002 Isolation requirements where you can indicate whether a cluster member can run on the same node as cluster members from a different dynamic cluster.
144
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Lazy application start The lazy application start feature optimizes server resource allocation during times of inactivity. The smallest size for a dynamic cluster is zero, implying that an application can be configured for execution but not running in any application server instances. When a request for that application is received by the ODR, an application server for that application is automatically started on any node in the dynamic cluster. A custom error page can be returned with a meta refresh tag to provide feedback to the user while waiting for the application to start. A typical environment where the lazy application start feature is beneficial has these characteristics: 0002 The ratio of the number of dynamic clusters to the number of servers is high. 0002 Some dynamic clusters are not accessed for long periods of time. In this environment, hibernating idle dynamic clusters temporarily (stopping all server instances) releases valuable resources to be used by active dynamic clusters.
Vertical stacking Using vertical stacking, you can have more than one application server instance in a dynamic cluster on the same node. The benefit of this capability is better hardware usage if a processor and memory are not used fully with a single application server on a node. Use vertical stacking only when a single application server instance cannot consume the full processor resources of a node.
5.7.2 Overload protection monitor Overload protection is a feature that monitors the memory and processor usage of a server. It then regulates the rate at which traffic is sent to an application server to prevent memory and processor overload. Memory overload protection is disabled by default. To enable it requires the configuration of the autonomic request flow manager. For a dynamic cluster, you can indicate a maximum heap usage percentage that protects against out-of-memory errors. For processor overload protection, you can indicate a maximum processor percentage that protects against various failures that might occur when a processor is consumed. A rejection policy can be set that prevents a processor from being overloaded. The policy works by rejecting incoming HTTP or SIP messages that are not part of existing sessions for HTTP or SIP traffic.
5.8 Planning for hosting dynamic operations Planning a production environment for dynamic operations is different from planning a static environment. In a static environment, you use dedicated servers for each application. To size the servers, look at your applications, the requirements, and the expected load during peak time. Your production environment must be prepared for the load during this possibly short period, meaning that during non-peak hours servers can be underused. In general, most companies have more than one critical application, and the second application can have its peak load at a different time of the day. In a static environment, the servers that host the first application cannot be used for the peak load of the second application. Therefore, the quality of service suffers or you must purchase more or larger systems to ensure the quality of service.
Chapter 5. Intelligent Management
145
Use the following questions to gather the information that is required to set up an environment for dynamic operations: 0002 What applications do you want to include? This list of applications affects the number of dynamic clusters. 0002 What are your critical applications? The critical applications affect the allocation of applications to dynamic clusters and the assignment of service policies. 0002 Are there applications that should not run on the same system? If so, these applications must be in different isolation groups. 0002 Which applications have the same load requirement and can share server configuration? These applications can be in the same dynamic cluster. 0002 Which servers or hardware do you want to include? In a heterogeneous environment, consider using multiple node groups, depending on the hardware type. 0002 Do all servers have the same resources available, such as network drivers, database connections, external drives, and extra software? Because every application can be started on every node in a node group, you must have all resources available on each node. Take this list of available resources into consideration because it might increase license costs and require more hardware resources on each system. Based on this information, plan your node groups, dynamic clusters, and service policies.
5.8.1 Topology considerations for the ODR When planning an Intelligent Management configuration, many of the planning considerations are focused on the ODR. It has the following primary functions: 0002 Request routing 0002 Intelligent routing based on a sense and response mechanism from back-end servers 0002 Classification of incoming requests based on rules that are defined by the business owner Thus, it is important to ensure that the ODR is scalable and highly available. Important: The ODR introduces an extra and critical processing layer to the server network topology. Because it is central to the functioning of the Intelligent Management environment, the ODR tier must not cause a processor bottleneck. Any performance issues with the ODR can affect the entire WebSphere Application Server environment. Therefore, the administrators and architects who plan the topology must ensure the high availability of ODRs. Factors that affect ODR performance include the number of supported clients, message size, secure sockets layer (SSL) implementation, and type of hardware. The number of ODRs to place in an environment and whether to use the ODR servers or enable Intelligent Management in the web server plug-in depends on the enterprise and infrastructure. Generally, you need at least two ODRs to provide high availability. An ODR must balance workload between the servers within same cell and core group as the ODR. Placing the ODR in the web server plug-in can enhance performance, but it moves the ODR function to the DMZ and not all features are supported. Various factors come into play when you determine whether to use more ODRs. Consider the number of clients that are served, the number of applications, the types and size of sessions, and security factors. As the number of clients increases, more processor usage is required to tracking all the clients. Therefore, have a close estimation of clients that access the environment, and evaluate the performance levels of the current set of ODRs. Consider
146
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
adding more ODRs if the client base is increasing because of a business activity such as a promotional offer. You can create a dynamic cluster of ODR servers. A cluster allows the application placement controller to select the best node on which to start the minimum number of ODRs. If an ODR stops for any reason, the application placement controller starts a new instance. Remember: A dynamic cluster of ODRs allows you to scale higher than the minimum number of clusters when needed. The prerequisite is that you must set the following cell custom property: Name: APC.predictor Value: CPU This setting causes the application placement controller to operate based on processor usage alone rather than input that it receives from the ODR. For information about sizing the number of ODRs, see: https://www.ibm.com/developerworks/wikis/display/xdoo/Best+practices+for+managi ng+the+on+demand+router?showComments=false>
5.8.2 Monitoring dynamic operations The Intelligent Management function allows you to monitor runtime operations from the administrative console. Real-time reporting shows alerts that indicate anomalies with the runtime environment. You can view the status of the cell that is based in ODRs, core groups, core components (autonomic managers), and nodes. Through this visualization feature, you can log historical performance metrics. The enhanced charting in the administrative console provides advanced charting and graphics, and customizable reports. You can build and save customized reports for dynamic viewing. To build these reports, select the type of component you want to monitor. You can select ODRs, application servers, nodes, dynamic clusters, and service policies. Next, select a specific instance of the component type to monitor. Then, select the data metric to use from a wide selection, including metrics such as average response time, throughput, and processor usage. These reports can help you ensure that you are meeting service level goals and can help you identify potential problems in the early stages. You can also use IBM Tivoli Composite Application Manager for WebSphere to retrieve and view application-specific metric information from a WebSphere environment. For more information, see 2.7, “IBM Tivoli Composite Application Manager for WebSphere” on page 39.
Chapter 5. Intelligent Management
147
148
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
6
Chapter 6.
WebSphere Batch This chapter addresses the concepts of WebSphere Batch that were introduced with IBM WebSphere Application Server V8.5. WebSphere Batch is a mature component that delivers batch processing capabilities and provides a comprehensive execution environment for Java batch processing and unified batch architecture. It answers the need to provide efficient batch processing that can run in parallel by running Java batch inside WebSphere Application Server. WebSphere Batch is only available in the full profile. This chapter includes the following sections: 0002 0002 0002 0002 0002
Overview of WebSphere Batch WebSphere Batch programming models WebSphere Batch components Batch workflow New features in WebSphere Application Server V8.5 for WebSphere Batch
© Copyright IBM Corp. 2012, 2013. All rights reserved.
149
6.1 Overview of WebSphere Batch Batch processing is a mission critical workload for the enterprise that can increase workload efficiency. The following are examples of tasks that are carried out with batch processing: 0002 Reporting on accounts for end of day, month, or year 0002 Bulk account processing for credit scores and for assessing interest 0002 Reconciling banking activities Many enterprises depend on batch processing. Online transactional processing (OLTP) systems have evolved over time, and application servers, such as WebSphere Application Server, serve as the foundation for this evolution. Standards for web services and other OLTP technologies have emerged. Programming models such as Java Platform, Enterprise Edition (Java EE) have been standardized. And service-oriented architecture (SOA) has been pursued. Throughout this evolution, however, batch systems are often overlooked. WebSphere Batch provides a batch technology that is optimized for Java that ensures enterprises remain agile, scalable, and cost efficient. The WebSphere Batch function was delivered in WebSphere Application Server V7 as the Modern Batch Feature Pack. With WebSphere Application Server V8.5, it is now enhanced and fully integrated. The integration of WebSphere Batch provides advanced batch management functions without having to purchase an add-on product.
6.1.1 WebSphere Batch key features WebSphere Application Server V8.5 adds efficiency and operational features through WebSphere Batch. WebSphere Batch includes the following key features: 0002 A unified batch architecture that provides a consistent programming model and consistent operational model for multiple platforms 0002 A comprehensive batch solution that allows for end-to-end development tools and execution infrastructure and enterprise integration to compliment the overall system The integration of WebSphere Batch provides implicit components to manage the following Compute Grid and Virtual Enterprise based functions: 0002 Comprehensive development and management tools for building and deploying batch applications that are based on Java 0002 A resilient, highly available, secure, and scalable run time with container-managed services for batch applications 0002 A platform that supports 24x7 batch and OLTP processing and parallel computing on highly virtualized and cloud-based run times 0002 Integration capability with existing infrastructure processes, such as enterprise schedulers, and archiving and auditing technologies that are typically deployed in an enterprise batch solution 0002 Integration capability with the overall SOA strategy of reuse by enabling services to be shared across multiple domains, such as batch, OLTP, and real time
150
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
0002 High-performance batch on the mainframe by integrating with z/OS. This function uses workload management and performance optimizations gained by running close to the application data 0002 Platform and batch applications that allow the location of the application data to dictate its deployment platform
6.1.2 Main concepts of batch processing Long-running workloads or applications typically require more resources and different types of support than the standard lightweight, transactional work typical of Java EE applications. Long-running work can take hours or even days to complete, and can use large amounts of memory or processing power while it runs. WebSphere Application Server V8.5 with WebSphere Batch provides an environment that supports long-running applications. This environment provides the capability to deploy different types of applications to different nodes within a WebSphere cell. It can also balance the work based on policy information. The submission of a long-running workload, also known as a job, is asynchronous from the workload that is run. When long-running work begins, state information must be persisted to a highly available data store. Administrators need the ability to monitor and manage long-running work. Also, the environment must be able to schedule and prioritize the work based on service policy information that is set by the user. WebSphere Batch components support the following types of long-running workloads or jobs: 0002 Batch applications A typical batch application does large amounts of work based on repetitive tasks. A batch application must provide the logic for a single unit of work. The container provides the support to run the job with transactions. It can also checkpoint and restart the application as required. For example, a typical batch application processes many records. Each record can represent a unit of work. The application provides the logic to process a single record. The environment in turn manages the process of repeatedly starting the application task for processing each record until processing is complete. 0002 Compute-intensive applications
Compute-intensive applications run work that requires large amounts of system resources, in particular processor capacity and memory. In this case, the application provides all the logic for completing the work, including acquiring the resources. The WebSphere Batch environment makes sure that the application is appropriately situated within the environment. OLTP provides a request/response model where the duration of the processing is relatively short and the tasks are typically transactional in nature. In this model, the application server run time enforces timeouts for the workload. In contrast, batch processing is a submit/work/result set model where the duration of the processing is a function of the tasks to be completed. In some cases with batch processing, the tasks can require hours or even days to complete. In this model, the work tasks are typically transactional in nature and involve multi-step processes.
Chapter 6. WebSphere Batch
151
Figure 6-1 shows the differences between these two processing models.
Online Transaction Processing
Batch Processing (or Long Running)
Request Submit Work on Record Response
Response
Figure 6-1 Processing models
Figure 6-2 illustrates how batch job submitters are not burdened with the details of the batch platform. Instead, they interact with a job management tier and view the remainder of the platform as a cloud. Job submitters submit batch job definitions to the job management tier. These definitions reference the business logic to be run, the parameters that describe the input and output data locations, and any job-specific qualities of service. Job submitters can also submit operational commands such as stop, start, cancel, or restart on their job instances. Job submitter
Batch
Lifecycle commands or invoke job with parameters Batch management and processing
Job status and logs
Figure 6-2 Batch management from a job submitter perspective
Batch job definitions can be stored in a job repository, which enables you to manage the lifecycle of the job definitions. Starting batch jobs that are stored in the repository is synonymous to making a remote-procedure call in other distributed computing paradigms. The name of the job and instance-specific parameters are passed to the system for execution. The output of the job execution, which is typically archived for auditing purposes, can be streamed back to the job submitter.
152
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Figure 6-3 shows the process that happens inside this cloud and WebSphere Application Server to manage batch operations. Administrator
Dispatch policies Job-specific QoS
Job submitter
WebSphere Application Server Batch Services
Job submitter
BATCH container Batch dispatcher Batch
Batch repository
Job submitter
Batch
Batch
Figure 6-3 Batch infrastructure in WebSphere Application Server
WebSphere Batch is composed of the following primary components: 0002 The job dispatcher tier manages the execution of batch jobs for a collection of resources. 0002 The batch container tier runs the jobs themselves. Administrators define policies that influence how batch jobs are run. These policies, coupled with autonomics that are built into the infrastructure, serve as the foundation for the cloud-enabled batch. Administrators can perform the following tasks (as depicted in Figure 6-3): 0002 Define policies that govern how jobs are run. The lifecycles of these policies can be managed through standard lifecycle management technologies. You can have a lifecycle that is independent of the applications. 0002 Configure dispatch policies that influence where batch jobs are run. For example, a dispatch policy can be defined where all jobs of a certain type must run in a 64-bit Java virtual machine (JVM). 0002 Configure partitioning policies that define how batch jobs are broken into parallel processing elements. These policies typically match how the data that is used by the batch applications is partitioned. Dispatch policies can be defined with the parallel portioning policies to create a highly parallel solution withs transaction manager – The resource manager It also allows for use of DB2 for z/OS JDBDC type 2 Native-API driver, which can speed up back-end database interactions. Transaction feature requires an angel process and a functional RRS subsystem to run. 0002 zosWlm-1.0 This feature provides access to z/OS native WLM services. It allows classification of HTTP requests based on host, port, method, and resource in the server.xml. This classification includes transaction class that is mapped to service and report class by WLM. A response enclave is created and joined for each classified request. A collection name can be associated with classifying work requests by use of zosWorkloadManager configuration element.
Chapter 16. WebSphere Application Server for z/OS
573
For a complete list of features that are supported by Liberty profile, see the following website: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd -zos&topic=twlp_setup_feat For more information about development-related resources with news and samples for download, visit: http://www.wasdev.net
16.7.3 Collectives (New in V8.5.5) With IBM WebSphere Application Server Liberty Network Deployment V8.5.5 and WebSphere Application Server Liberty for z/OS V8.5.5, you can use the collectiveController-1.0 feature that allows you to build Liberty collectives. Liberty collectives are made of controllers and members. Collective controllers are Liberty servers that allow you to manage multiple Liberty servers that joined that collective. The Liberty servers that join a collective are called collective members. Liberty collective members can be configured in clusters by using the clusterMember-1.0 feature. You can use the ClusterManager MBean of the collective controller to generate the Liberty server cluster plug-in configuration. Liberty collective controllers can be configured in a replica set for high availability and data protection reasons. This way, each controller replicates its data to the other collective controllers in the replica set.
16.8 Resources This section includes links and references to extra material to provide deeper insight on the workings of z/OS with the WebSphere Application Server for z/OS. For information about planning and system considerations that are required to build a heterogeneous cell, see the WebSphere for z/OS—Heterogeneous Cells white paper at: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100644 This paper focuses on WebSphere Application Server V6.1, but the basic concepts are still valid for V8.5. For a comprehensive overview of IBM Installation Manager for z/OS and its use with WebSphere Application Server for z/OS, see: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102014 Benefits of collocation of the application layer with the data layer on z/OS are addressed in the white paper The Value of Co-Location, Document ID WP101476: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101476 For more information about WebSphere configuration tools, including the z/OS Profile Management Tool and the z/OS Migration Management Tool, see the following websites: 0002 WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was -nd-zos&topic=tins_installation_wct_gui
574
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
0002 WebSphere Application Server for z/OS V7.0 - Introducing the WCT for z/OS, Document ID PRS3357 http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS3357 0002 WebSphere for z/OS Version 7 - Configuration Planning Spreadsheet, Document ID PRS3341 http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS3341 0002 Introducing the IBM Support Assistant for WebSphere on z/OS, Document ID WP101575 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101575 For deeper insight into the Java options and functions that are used by WebSphere Application Server V8.5, see the following websites: 0002 IBM Java 6.0 Diagnostics Guide http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp 0002 Java technology, IBM style: Garbage collection policies, Part 1 http://www.ibm.com/developerworks/java/library/j-ibmjava2/index.html 0002 Java technology, IBM style: Garbage collection policies, Part 2 http://www.ibm.com/developerworks/java/library/j-ibmjava3/ For a comprehensive look into application development of Java applications, see the following IBM Redbooks publications: 0002 Java Stand-alone Applications on z/OS, Volume I, SG24-7177 0002 Java Stand-alone Applications on z/OS Volume II, SG24-7291 Various tools are available to ease the daily life of developers and system programmers. The following tools are available at no charge: 0002 IBM Support Assistant This tool, together with some plug-ins, provides an easy way to check for configuration changes and a central repository for configuration values. In addition, you can use it to create graphical overviews of your environment. To download this tool, go to the IBM Support Portal at: http://www.ibm.com/software/awdtools/isa/support/ 0002 JinsightLive for IBM System z To download this application profiling tool, see: http://www.ibm.com/systems/z/os/zos/features/unix/tools/jinsightlive.html 0002 Eclipse Test and Performance Tools Platform (TPTP) To download this profiling tool plug-in for the well-known Eclipse project, go to the Eclipse website at: http://www.eclipse.org/tptp/
Chapter 16. WebSphere Application Server for z/OS
575
576
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
17
Chapter 17.
Migration This chapter addresses migration considerations for moving to WebSphere Application Server V8.5 or V8.5.5 from a prior version of WebSphere Application Server. The term “v8.5” in this chapter refers to V8.5 and all releases of V8.5. This chapter includes the following sections: 0002 0002 0002 0002 0002 0002
Migration features in WebSphere Application Server V8.5 Migration overview Migration plan Application development migration considerations Infrastructure migration considerations Migration considerations for WebSphere Application Server for z/OS
Moving from WebSphere Application Server V8.5 to V8.5.5 does not require migration tools. It is done by using the Update option in the Installation Manager. If you have the Liberty profile installed in V8.5, see 9.8.3, “Considerations for upgrading Liberty profile V8.5 to V8.5.5” on page 285.
© Copyright IBM Corp. 2012, 2013. All rights reserved.
577
17.1 Migration features in WebSphere Application Server V8.5 WebSphere Application Server V8.5 provides features that support migration from older versions. This section highlights these features.
17.1.1 Configuration Migration Management Tool The Eclipse-based graphical wizard is called the Configuration Migration Management Tool. This tool supports the migration of all management profiles of WebSphere Application Server, including admin agent and job manager. It also provides the option to run the generated Migration jobs as 64 bit. The tool highlights the potential changes because of the migration. It can also generate the commands that are run by the graphical wizard to create migration scripts.
17.1.2 Cross platform migrations With WebSphere Application Server V8.5, you can migrate a node from one system to another, even if they have different operating systems (except for IBM i and z/OS). The createRemoteMigrJar tool creates a compressed file from the WebSphere V8.5 binary files. These files are able to run the migration backup command in a system that does not have WebSphere Application Server V8.5 installed.
17.1.3 Enhanced z/OS Migration Management Tool The Websphere Application Server V8.5 z/OS Migration Management Tool supports the migration of all management profiles of WebSphere Application Server, including admin agent and job manager. It also supports 64-bit migration on z/OS.
17.2 Migration overview Migration is the action of moving from an existing release to a newer release. A WebSphere Application Server migration is more than just applying a new product version. It is a project. A WebSphere Application Server migration impacts the following components of your infrastructure: 0002 Applications 0002 Middleware 0002 Operating systems For information about the removed, deprecated, and new features of WebSphere Application Server V8.5, see the following websites: 0002 http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphe re.base.doc%2Fae%2Fwelc6topnew.html 0002 http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphe re.base.doc%2Fae%2Frmig_deprecationlist.html Reviewing this information can provide a better understanding of the areas that are impacted by migration.
578
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
17.3 Migration plan You must create a migration plan to perform a migration from your existing environment to the new version of WebSphere Application Server. This plan covers the following core steps. Keep in mind that each migration is unique and might need to be adjusted. 1. Project assessment Create a migration team and review all aspects of the migration, such as education, hardware, application, testing, and risk factors. 2. Project planning Define a complete migration plan, from day one to the actual production migration, based on the assessments of step 1. 3. Skill development Plan for an education period to address new product features, tools, and the development standards in WebSphere Application Server V8.5. 4. Setup of development environment, application migration, unit test Test your applications in the new environment for compatibility and possible code modification. 5. Setup, migration, and test of extra runtime environments In parallel with the application migration process, iteratively migrate all of your other environments except the production environment, and create a migration path. 6. Testing Plan a functional, technical, and performance test campaign to validate your migration. 7. Production environment migration Before migrating, prepare a rollback plan. Follow your migration procedure to update your production environment. 8. Lessons learned session Following the migration, review the project outcome and processes that were used with the entire migration team to improve the migration process.
Chapter 17. Migration
579
Figure 17-1 illustrates the steps that you might take in performing a migration.
As sess ment
Planning
S kills Development Development environment Environment
Runtime R untime Environment environment
Code migration
R untime migration
Unit t est
Test sys tems
Test
Production Review results
Figure 17-1 Migration path
For more information about WebSphere Application Server migration, see Knowledge Collection: Migration planning for WebSphere Application Server at: http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg27008724
17.4 Application development migration considerations This section provides a general overview of considerations to make when migrating applications between WebSphere Application Server versions. WebSphere Application Server V8.5 supports Java Platform, Enterprise Edition 6 (Java EE 6). Consider the following points: 0002 Although newer Java Platform, Enterprise Edition versions support older versions, some minor exceptions might exist. 0002 Identify the deprecated application programming interfaces (APIs) and determine whether any of these APIs are used in your existing applications. 0002 Understand the new WebSphere Application Server V8.5 and V8.5.5 features. For more information about deprecated APIs, see the Websphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ba se-dist&topic=cmig_apispec
580
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
See also the deprecated API list for the Java platform at: http://download.oracle.com/javase/6/docs/api/deprecated-list.html or http://download.oracle.com/javase/7/docs/api/deprecated-list.html For more information about how to migrate specific application components such as web services, EJB, OSGi, and asynchronous beans, see the WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ba se-dist&topic=welcome_migrating IBM provides a separate tool called WebSphere Application Migration Tool that is based on Rational Software. With this tool, you can quickly analyze your applications and highlight the parts that are not compatible, such as deprecated APIs.
17.5 Infrastructure migration considerations This section addresses topics to consider when migrating from an existing environment to WebSphere Application Server V8.5.
17.5.1 Coexistence WebSphere Application Server V8.5 can be installed and configured to coexist with other WebSphere Application Server V8, V7, and V6.1 installations on the same system simultaneously without any conflict. Consider the following factors before you start such a migration: 0002 The hardware and software of the system must be supported by all versions of Websphere Application Server that you plan to coexist. 0002 Each installation of WebSphere Application Server requires extra system resources. 0002 Plan for unique ports for every installed version of WebSphere Application Server.
17.5.2 Interoperability WebSphere Application Server V8.5 is generally interoperable with WebSphere Application Server V8, V7, and V6.1. This interoperability means that different versions of WebSphere Application Server can exchange data and communicate. Requirements exist for some functions that depend on the WebSphere version. For more information, see the WebSphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ba se-dist&topic=welcome_migrating
Chapter 17. Migration
581
17.5.3 Mixed-version-cell support To ease the incremental upgrade of your environment, WebSphere Application Server V8.5 supports mixed-cells with nodes from V8, V7, and V6.1. A cell can contain nodes from different versions of WebSphere Application Server and different platforms. The version of your deployment manager must be at the highest level you use in your cell. Although running in a mixed-cell configuration is supported, this situation is to be considered transitional and for a limited time. In the end, all your nodes should be at the same level for best results.
17.5.4 Configuration Migration Tools WebSphere Application Server V8.5 provides Configuration Migration Tools to perform a migration. With Configuration Migration Tools, you can perform these tasks: 0002 Migrate configurations, including the topology, customizations, and applications, while still running your old environment. The tools support the migration of V6.1, V7, and V8 security features, which include enhanced Secure Sockets Layer (SSL), security audit, Kerberos, and multidomain security. 0002 Migrate the applications from the old version to the new version without changing them. The tools support the migration of the business-level applications. 0002 Migrate one profile at a time because the process is iterative. 0002 Perform cross-platform migration (for distributed platforms only). 0002 Migrate V7 and V8 job manager and administrative agent profiles. Figure 17-2 illustrates the migration process.
V6.1 V7 V8.0 profile Node 1
Server 1
Server 2
V8.5 profile Configuration migration process
Node 1
Server 1
Figure 17-2 Migration process
582
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Server 2
The Configuration Migration Tools are available on the following platforms with the indicated features: 0002 Distributed – Configuration Migration Management Tool This tool provides a graphical interface that you can use to run all the migration steps (Figure 17-3). The tool is based on the migration commands listed after the figure.
Figure 17-3 Configuration Migration Management Tool
– The createRemoteMigrJar tool This tool creates a compressed file from the WebSphere Application Server V8.5 binary files. The compressed file contains the necessary files for running the migration backup command in a remote system that does not have WebSphere Application Server V8.5 installed. You use this tool when you want to perform a migration from one system to another. The compressed file that is created contains specific code that makes it operating system dependent. – Migration commands •
The WASPreUpgrade command saves the configuration of the old installed version into a migration-specific backup directory.
•
The WASPostUpgrade command applies the old version of the configuration to the new version by copying, replacing, merging, and deleting profile data.
•
The clientUpgrade command migrates previous versions of the client to the new version.
0002 IBM i Migration commands: – WASPreUpgrade – WASPostUpgrade – clientUpgrade For more information about these commands, see the Websphere Application Server V8.5 Information Center at: http://publib.boulder.ibm.com/infocenter/wasinfo/v8r5/index.jsp 0002 z/OS z/OS Migration Management Tool For more information, see the Websphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was -nd-zos&topic=tmig_admin
Chapter 17. Migration
583
17.5.5 Properties files The wsadmin tool provides a set of commands that you can use to export portions of the application server profile into properties files. You also can modify your cell by importing these properties files, enabling you to transfer parts of a cell configuration to a newly created cell. For more information about the properties file based configuration, see the Websphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-ba se-dist&topic=txml_property_configuration
17.5.6 Product configuration migration scenarios This section describes these product configuration migration scenarios: 0002 0002 0002 0002 0002 0002 0002 0002
Manual Stand-alone environment with the Configuration Migration Tools Multinode environment with all-node upgrade and Configuration Migration Tools Multinode environment migration with mixed-node and the Configuration Migration Tools Fine-grained approach for a stand-alone environment Administrative agent environment with the Configuration Migration Tools Job manager environment with the Configuration Migration Tools Cross-platform migration
For more information and complete migration scenarios, see the following resources: 0002 The Websphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was -base-dist&topic=welcome_migrating 0002 WebSphere Application Server V7 Migration Guide, REDP-4635 The scenarios in this paper are available only for distributed platforms and IBM i. For z/OS migration, see 17.6, “Migration considerations for WebSphere Application Server for z/OS” on page 590. Considerations: Before migrating, consider the following tips: 0002 Migrate one profile at a time. 0002 Migrate from a clean and functional profile to a clean profile. 0002 Back up all data before migrating. 0002 Always migrate the highest level profile first. 0002 The job manager can manage only servers at the same release or earlier. 0002 The administrative agent can register only Base application servers at the same release level and on the same system. 0002 The deployment manager can manage nodes only at the same release or earlier.
584
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Manual With the manual migration scenario, you start with a new WebSphere Application Server V8.5 environment and import all configurations and applications. Ideally, use scripts to run this import. Because of the risk of human error, re-creating it manually by using the administrative console can be risky. You must migrate all of your environments. The manual approach provides the following advantages and disadvantages: 0002 Advantages – All of the migration tasks can be performed independently from the running environment. – The granularity of the migration is under the control of the project team. – All of the scripts are yours. You have full control over the migration and do not need to depend on WebSphere tools. – You can reuse the scripts for a disaster recovery. 0002 Disadvantages – Creation and continuous maintenance of these scripts can require considerable effort and be expensive. These scripts must be valid for the new WebSphere version. – Every change in the environment must be scripted. – It is easy to forget some configurations. You can migrate the entire topology with the manual approach.
Stand-alone environment with the Configuration Migration Tools You can migrate your complete stand-alone environment at the same time by using the Configuration Migration Tools that are provided by WebSphere Application Server. Use the following procedure to perform this migration. 1. Back up the previous version of the profile with the migration tools. 2. Install WebSphere Application Server V8.5, and create a profile. 3. Import the profile configuration with the migration tools. The schema in Figure 17-4 illustrates this migration.
V6.1, V7 or V8.0 profile
Create a new V8.5 profile
WASPreUpgrade command
V8.5 profile
backup files
Backup of the configurations applications resource
WASPostUpgrade command
Migrated V8.5 profile
Figure 17-4 Automated migration approach
Chapter 17. Migration
585
This approach provides the following advantages and considerations: 0002 Advantages – There is no need for self-written scripts. All migration is done by using the WebSphere Application Server migration tools. – All of the information in the current configuration is imported to WebSphere Application Server V8.5. 0002 Considerations – All applications that will be migrated must be ready at the same time. – This approach works only if you keep the same topology.
Multinode environment with all-node upgrade and Configuration Migration Tools You can migrate your complete environment at the same time by using the migration tools that are provided by WebSphere Application Server. This approach is useful if you are not redesigning your environment. If you do not want to migrate your entire environment at the same time, see “Multinode environment migration with mixed-node and the Configuration Migration Tools” on page 586. To perform this migration, complete these steps: 1. Back up the previous version of the deployment manager (dmgr) profile with the migration tools. 2. Install WebSphere Application Server V8.5, and create a deployment manager profile. 3. Import the deployment manager configuration with the migration tools. When the configuration is imported, you are now in a mixed-cell environment. The deployment manager profile is in V8.5, and the nodes are in the older version. 4. Finish the procedure by migrating all the nodes, one by one, using the same migration tools. This approach provides the following advantages and considerations: 0002 Advantages – There is no need for self-written scripts. All migration is done by using the WebSphere Application Server migration tools. – All of the information in the current configuration is imported to WebSphere Application Server V8.5. 0002 Considerations – All applications that are being migrated must be ready at the same time. – This approach works only if you keep the same topology.
Multinode environment migration with mixed-node and the Configuration Migration Tools You can perform node-by-node migration of your environment by using the migration tools that are provided by WebSphere Application Server. This approach is useful if you are not redesigning your environment. In this approach, you do not need to migrate all of your nodes at the same time.
586
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
To perform this migration, complete these steps: 1. Back up the previous version of the deployment manager (dmgr) profile with the migration tools. 2. Install WebSphere Application Server V8.5, and create a deployment manager profile. 3. Import the deployment manager configuration with the migration tools. When imported, you are now in a mixed-cell environment with the deployment manager profile in V8.5, and the nodes in the older version. 4. Decide whether to migrate your nodes independently of one another. All nodes must be migrated as a part of the project. Running in a mixed-cell configuration is considered a transitional state. This approach provides the following advantages and considerations: 0002 Advantages – There is no need for self-written scripts. All migration is done by using the WebSphere Application Server migration tools. – This approach is flexible. Therefore, you can migrate your nodes iteratively without any time consideration. – All of the information of the current configuration is imported to WebSphere Application Server V8.5. 0002 Consideration – This approach works only if you keep the same topology.
Fine-grained approach for a stand-alone environment With the fine-grained approach, you can migrate portions of the configuration by using the Configuration Migration Tools and the properties files commands (Figure 17-5 on page 588). To perform this migration, complete these steps: 1. Install WebSphere Application Server V8.5, and create a temporary profile. 2. Back up the previous version of the profile with the migration tools. 3. Import the configuration with the migration tools into a temporary profile. You do not need any applications in the temporary profiles. Nevertheless, you must rebuild your applications using the WebSphere Application Server V8.5 classes to be able to install them in final profiles. An import command option is available to specify that applications are built without installing them in the temporary profiles. 4. Create the final profile. 5. Using the extract properties files command, extract the temporary profile configuration. 6. Using the apply properties files command, import the temporary profile configuration into the final profile. 7. Install the applications that were created in step 3 into the final profile.
Chapter 17. Migration
587
Figure 17-5 illustrates the flow of the fine-grained migration approach.
V6.1, V7 or V8.0 profile
WASPreUpgrade
Create a new V8.5 temporary profile
command
Backup files
Backup of the configurations applications resource
Properties files export command V8.5 temporary profile
Configuration files Install the applications
Create a new V8.5 final profile
V8.5 profile
Properties files import command
Migrated V8.5 profile
Figure 17-5 Fine-grained migration approach
The fine-grained approach has the following advantages and considerations: 0002 Advantages – There is no need for self-written scripts. All migration is done by using the WebSphere Application Server migration tools and properties file commands. – You can choose which information from the current configuration to import into WebSphere Application Server V8.5. 0002 Consideration – The migration requires considerable preparation. You can also perform this migration approach on a multinode federated environment.
Administrative agent environment with the Configuration Migration Tools To migrate an administrative agent environment, complete these steps: 1. Verify that no jobs are currently running, and back up the previous version of the administrative agent profile with the migration tools. 2. Install WebSphere Application Server V8.5, and create an Administrative Agent profile. 3. Import the administrative agent configuration with the migration tools. 4. After the configuration is imported and the new administrative agent is running, migrate all the registered base application servers one by one. This approach is explained in “Stand-alone environment with the Configuration Migration Tools” on page 585. You must use specific parameters with the WASPreUpgrade and WASPostUpgrade commands.
588
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Job manager environment with the Configuration Migration Tools To migrate a job manager environment, complete these steps: 1. Back up the previous version of the job manager profile by using the migration tools. 2. Stop the job manager. 3. Install WebSphere Application Server V8.5, and create a job manager profile. 4. Import the job manager configuration by using the migration tools. 5. After the configuration is imported and the new job manager is running, migrate all the registered servers one by one. This process is explained in “Multinode environment with all-node upgrade and Configuration Migration Tools” on page 586. Also, see “Job manager environment with the Configuration Migration Tools” on page 589.
Cross-platform migration In this approach, you migrate from a stand-alone WebSphere Application Server V6.1, V7, or V8 instance installed on Linux to WebSphere Application Server V8.5 installed on Windows. To perform this migration, complete these steps: 1. Install WebSphere Application Server V8.5 on the Linux system to generate the compressed file that contains the migration tools. 2. Extract the compressed file in the Linux system where WebSphere Application Server V6.1, V7, or V8 is installed. 3. Back up the previous version of the profile by using the migration tools that are provided in the compressed file. 4. Install WebSphere Application Server V8.5 on the Windows system, and create a profile. 5. Import the profile configuration by using the migration tools.
Chapter 17. Migration
589
Figure 17-6 illustrates the flow of a cross-platform migration.
Install V8.5 binaries
V8.5 Installation binaries on Linux
createRemoteMigrJar
Migration Zip file
command
The zip file contains the necessary files for running the migration backup command.
Transfer to the new machine
V6.1, V7 or V8.0 profile on Linux
WASPreUpgrade command
Configuration files
Transfer to the new machine
Create a new V8.5 profile
V8.5 profile on Windows
WASPostUpgrade command
Migrated V8.5 profile on a new machine and a new OS
Figure 17-6 Cross-platform migration
17.5.7 Scripts migration Since the release of WebSphere Application Server V5.1, two scripting languages for WebSphere Application Server are available: Java TCL (Jacl) and Jython. Jacl is declared stabilized since WebSphere Application Server V7, meaning that it will not be removed but there will be no further development for it. Therefore, do not migrate your existing Jacl scripts to Jython. Instead, create your scripts by using Jython.
17.6 Migration considerations for WebSphere Application Server for z/OS This section concentrates on the topics that you must consider when you migrate an existing WebSphere Application Server for z/OS to V8.5.
17.6.1 Migration and coexistence Before attempting a migration, you must meet coexistence and prerequisite conditions. The earliest release level of Websphere Application Server that can be directly migrated to Websphere Application Server V8.5 is V6.1. Prior releases must be migrated by using a two-step migration. The first step is to migrate to a version that is supported by the migration tools. Then, in the second step, you migrate to V8.5.
590
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Table 17-1 shows the minimum requirements for the supported releases. Table 17-1 WebSphere Application Server for z/OS releases for direct migration Current release
Target release
Minimum level
V6.1
V8.5
V6.1.0
V7.0
V8.5
V7.0.0
V8.0
V8.5
V8.0.0
Keep in mind that the deployment manager must always be at the latest version level. For example, when migrating to V8.5, the deployment manager must be at V8.5. With mixed versions in a cell, you can minimize application downtime during migration because you can migrate one node at a time. If you have applications that run in a clustered environment, those applications can typically continue to run while the migration of one node takes place. Requirement: You must migrate the job manager to WebSphere Application Server V8.5 before migrating deployment managers or administrative agents that have servers registered to it.
17.6.2 General considerations Before going into the migration process in more detail, keep in mind the following considerations when you perform a migration: 0002 Use the same procedure names. – Before updating the StartedTasks procedures for V8.5, save your current procedures in case you must fall back to the previous level. – If you choose to use different procedure names, update the RACF STARTED class profiles. You can find sample Resource Access Control Facility (RACF) commands to accomplish this task in the migration instructions that are provided. 0002 Automation changes might also be required when you change procedure names. 0002 Use a separate file system (HFS or ZFS) for each V8.5 node. This configuration might require new procedure names if you used a shared file system in previous versions. 0002 Review the guidance for migrating, coexisting, and interoperating in the Websphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was -nd-zos&topic=migration_concepts 0002 Premigration considerations are also an important point to review. For more information, see: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was -nd-zos&topic=cmig_pre
Chapter 17. Migration
591
17.6.3 Overview of the migration process The product code of WebSphere Application Server for z/OS V8.5 is brought into the system by using System Modification Program/Extended (SMP/E) or in an IBM Installation Manager repository format. The code is installed by IBM Installation Manager for z/OS. The migration is then run by using a three-step approach: Remember: The migration is always performed on a node basis. In the Network Deployment configuration, you must always start with the deployment manager node. 1. Back up the old environment to have a fallback option. 2. Create and transfer the job control language (JCL) jobs that are needed during the actual migration (CNTL and DATA data sets). 3. Run the JCL jobs to perform the migration. To create the JCL, use the z/OS Migration Management Tool or the zmmt.sh script. Both techniques are addressed in the following sections. Other migration actions might be in place depending on extra products that are installed in the environment.
17.6.4 z/OS Migration Management Tool This section describes the z/OS Migration Management Tool that is used during the migration process on z/OS.
Overview The z/OS Migration Management Tool is an Eclipse-based application that is available in WebSphere Customization Toolbox V8.5. This tool is used to create the JCL jobs for the migration. It uses Migration Definitions, a construct that contains all the data that is necessary to migrate a WebSphere Application Server for z/OS node from V6.1 (and later) to V8.5. It contains the Migration Instructions that are personalized for each Migration Definition. It can be used to transfer the JCL to the z/OS target system, if that system has a File Transfer Protocol (FTP) server. z/OS Migration Management Tool is intended for use by system programmers or administrators who are familiar with the z/OS target system on which the migrated V8.5 nodes will run.
592
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Figure 17-7 shows a high-level overview of the migration process using z/OS Migration Management Tool.
Select type of node to migrate: • Stand-alone application server • Deployment manager • Federated node • Administrative agent • Job manager
Configure node: • HLQ of datasets • Mount point (HFS or zFS) • Procedures names • Other variables
Process migration: • Generate JCL jobs • Generate scripts • Transfer to z/OS or local directory
JCL procs
Transfer jobs/scripts to z/OS
1. Create backup 2. Execute jobs
Export jobs/scripts to local directory
Figure 17-7 Migration process with z/OS Migration Management Tool
Installing the z/OS Migration Management Toolbox The z/OS Migration Management Tool is available for Windows and Linux technology-based workstations. It is included in the Supplementary Material package. You can also download the WebSphere Customization Toolbox package from the IBM Installation Manager. For information about how to install Installation Manager, see 9.6, “IBM Installation Manager” on page 258. The WebSphere Customization Toolbox includes the z/OS Migration Management Tool, the z/OS Profile Management Tool, and the Web Server Plug-in Configuration Tool. If WebSphere Customization Toolbox is not installed on your system, complete these steps: 1. Update the IBM Installation Manager with your preferred repository location. 2. Go to the main window of Installation Manager, and click Install. For the tool to access the IBM online repository, a user ID and password are required. 3. When you see the packages that can be installed, select WebSphere Customization Toolbox and click Next. 4. Read and accept the license agreement. 5. Identify the directory on your local file system in which you want to install the packages.
Chapter 17. Migration
593
6. Select the tools from the WebSphere Customization Toolbox for installation as shown in Figure 17-8. 7. After the installation process, you can see the packages that were installed.
Figure 17-8 Selecting the WebSphere Customization Toolbox components to install
To access WebSphere Customization Toolbox, complete these steps: 1. On a Windows operating system, click Start Programs  IBM WebSphere  WebSphere Customization Toolbox V8.5. 2. Click WebSphere Customization Toolbox to start the program.
594
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
3. Click z/OS Migration Management Tool to open the WebSphere Customization Toolbox V8.5 perspective as shown in Figure 17-9.
Figure 17-9 z/OS Migration Management Tool
Creating a migration definition To create a migration definition, complete these steps: 1. Complete the configuration worksheet in the Websphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was -nd-zos&topic=tmig_zmmt_depmanwrk 2. Start the z/OS Migration Management Tool. 3. Specify a location where you want Migration Definition files to be stored on your workstation, or add another migration location to the Migration Locations table: a. Click Add on the right side of the window. b. Enter the path name of the location where you want to store the migration data. The migration location directory must be empty when you create a migration location. c. Enter a name to be associated with the table entry.
Chapter 17. Migration
595
d. Select the version of WebSphere Application Server to which you are migrating. e. Click Finish. 4. Select the migration location that you created, and click Migrate as shown in Figure 17-10.
Figure 17-10 Migration process
596
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
5. In the Migration Node Type Selection window shown in Figure 17-11, select the type of node migration and click Next.
Figure 17-11 Migration Node Type Selection window
6. In the multi-panel window that opens, complete the fields by using the values that you entered for the variables on the configuration worksheet. Click Back and Next as necessary. Considerations: 0002 The z/OS Migration Management Tool has a help file that is accessible by hovering the mouse over a field. 0002 In the Migration Process Options window, a Migration Definition identifier is shown. You might want to write down this number. This identifier is used to separate the output of individual node migrations. The identifier is also the name of the subdirectory where the JCL is saved on your workstation.
Chapter 17. Migration
597
7. After you successfully enter all of the necessary information for this type of Migration Definition, in the Migration Summary window, click Create. Doing so builds the Migration Definition on your workstation. 8. Check the definition type, location, and name information in the Migration Creation Summary window, then click Finish. You will find a directory structure that populates the path that was specified to store the Migration Definitions. For the next steps, upload the migration jobs by using the z/OS Migration Management Tool, as explained in the following section. For help regarding the z/OS Migration Management Tool, see the Websphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd -zos&topic=tmig_zmmt_usemmt
Creating migration jobs To create migration jobs, complete these steps: 1. To create the JCL jobs and scripts, select the definitions that you created under Migration Definitions and click Process, as shown in Figure 17-12.
Figure 17-12 Processing the migration definition
598
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
2. Select the type of processing for the migration definition and click Next. – If you choose to upload to the target z/OS system, you must provide the host name or IP address, user ID, and password. The JCL and the scripts are then transferred to the z/OS system into the CNTL and DATA data sets named in the migration definition. The z/OS Migration Management Tool presumes that the data sets are preallocated. For CNTL and DATA data sets to be allocated during the transfer, select Allocate target z/OS data sets and specify the appropriate Volume and Unit fields. – If you choose to export to a local directory, the JCLs and scripts are generated on your local system. 3. Click Finish. For detailed migration instructions, select a Migration Definition and then click the Migration Instruction tab. You can also find the instructions in the file system of your workstation in the BBOMxINS member. The path is displayed on the Migration Instruction tab. The instructions reflect the variables that were entered in the Migration Definition windows.
17.6.5 Migration Management Tool script This section provides information about the z/OS Migration Management Tool script (zmmt.sh). It is used to create the JCL needed for a node migration.
Overview You can create the migration jobs on z/OS by using the shell script zmmt.sh. This script is in the bin directory of the product image (default /usr/lpp/zWebSphere/V8R5/bin). The script creates the CNTL and DATA data sets and the corresponding JCL that is needed to perform the migration. You need a response file as input. This response file contains information about the node construction. Requirement: Use the z/OS Migration Management Tool to build the response file. Make sure that any changes brought with new PTFs to the response file are used. You can achieve that by using the latest version of the WebSphere Customization toolbox. Do not copy the response files values directly from the z/OS Migration Management tool Migration Response File tab. Use the generated text file named YourMigrationDefinitionName .responseFile. This file is in a subdirectory of the profiles directory in your Migration Location.
The script Example 17-1 shows how to run the script in the z/OS UNIX System Services environment. Example 17-1 Migration management command
./zmmt.sh -workspace /xxx -transfer -allocate -responseFile /xxx/YourMigrationDefinitionName.responseFile You can use the following parameters to run the script: 0002 -responseFile Specifies the path to your response file. This file can be encoded in ASCII or EBCDIC. The shipped samples use ASCII. Some examples are in the /usr/lpp/zWebSphere/V8R5/zOS-config/zpmt/samples directory.
Chapter 17. Migration
599
0002 -profilePath The fully qualified path name to an existing set of generated jobs. You cannot use this parameter with the -responseFile parameter. 0002 -workspace Specifies the Eclipse workspace directory. 0002 -transfer Copies generated jobs from a z/OS UNIX System Services file system to a pair of partitioned data sets. The zmmt.sh script first writes the customization jobs to a z/OS UNIX System Services file system. 0002 -allocate Attempts to allocate the target data sets. This script runs the following tasks: 0002 Generates the migration jobs to the location specified by profilePath in the response file. 0002 Allocates the target CNTL and DATA data sets by using the high-level qualifier that is specified by target HLQ in the response file. 0002 Transfers the jobs from the file system to the CNTL and DATA data sets.
Runtime considerations When you are using the zmmt.sh script to create the migration JCL, keep in mind the following points: 0002 The script is run in the osgi command shell. Tip: An osgi command shell is an execution environment that is used for remote management of Java applications and components. It is based on the OSGI open standard. Because the script takes a relatively long time to run, it might look as though nothing is happening. Eventually the script writes messages like those in Example 17-2. Example 17-2 osgi messages when issuing the zmmt.sh script
osgi> Customization definition successfully written to /tmp/ZDMgr01 Attempting to allocate dataset: CUI.WAS85M.CNTL Allocation successful. Attempting to allocate dataset: CUI.WAS85M.DATA Allocation successful. Copying CNTL files to CUI.WAS85M.CNTL... Copy successful. Copying DATA files to CUI.WAS85M.DATA... Copy successful. 0002 If you need to rerun the command, delete the profilePath directory. If the directory still exists, the osgi shell shows an error message as shown in Example 17-3. Example 17-3 zmmt.sh script error message
osgi> The following validation errors were present with the command line arguments: profilePath: The profile path is not valid.
600
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
17.6.6 Migration jobs Migration jobs are created by using the z/OS Migration Management Tool or the zmmt.sh script. This section provides a brief overview of these jobs. Attention: Read the BBOMxINS module on the hlq.CNTL data set. It contains the tasks that you must complete before you start the migration process, and explains each job that you must perform.
Overview Multiple jobs are created by the z/OS Migration Management Tool. Table 17-2 shows an overview of the jobs that are used for the migration. Jobs are relative to the node that must be processed. Check the detailed migration manual that is created during the JCL build step for the necessary user authorities. Table 17-2 WebSphere Application Server for z/OS V8.5 migration jobs Job namea
Job run
BBOMxZFS or BBOMxHFS
Allocates hierarchical file system (HFS) or zSeries file system (zFS)
BBOMxCP
Copies tailored JCLs to PROCLIB
BBOWMG1x
Clear transaction logs (for XA connectors only).
BBOWMG2x
Disable Peer Restart and Recovery mode (XA only).
BBOWxPRO
Creates a target profile in the new release.
BBOWxPRE
Creates a backup of the source profile.
BBOWxPOS
Migrates the backup profile into the new profile.
Alternatively BBOWMG3x
Runs BBOWxPRO, BBOWxPRE, and BBOWxPOS in a single step.
a. The value for x in the job names listed depends on the profile that you are migrating.
BBOWMG3x job The BBOWMG3x job runs the actual migration. This job takes the longest time to run. The following tasks are included in the job: 1. Create a working directory (/tmp/migrate/nnnnn). A working directory in the /tmp directory is used to do much of the processing. The nnnnn is a unique number that is generated during the creation of your migration jobs. For normal migration, the space that is used in the /tmp directory is small. However, if you enable tracing, the space demand can become higher. Make sure that you have enough free space in the /tmp directory. 2. WRCONFIG: Copy the dialog generated variables to the HFS. 3. WRRESP: Create a profile creation response file from the dialog generated variables. 4. MKCONFIG: Gather information, such as the cell name and server name, from the existing configuration. 5. VERIFY: Verify the variables that are generated from the dialog. This step attempts to check that the information provided so that the migration does not fail because of bad input parameters. 6. CRHOME: Create a V8.5 WAS_HOME structure.
Chapter 17. Migration
601
7. CRPROF: Create a V8.5 profile for the node that is being migrated. 8. PREUPGRD: Back up the files in the file system in preparation for migration. 9. UPGRADE: Run WASPostUpgrade to perform the migration (serverindex.xml renamed to serverindex.xml__disabled). This step is where the actual migration occurs, and takes the longest to complete. 10.FINISHUP: Run Config2Native, and update file permissions and attributes.
Troubleshooting for the BBOWMG3x job Because a migration is complex, errors can occur. The main source for errors is the BBOWMG3x job, which was described in the previous section. Here are some troubleshooting tips: 0002 If the BBOWMG3x job fails, check the output for errors: – /tmp/migrate/nnnnn/BBOWMG3x.out written to JOBLOG – /tmp/migrate/nnnnn/BBOWMG3x.err written to JOBLOG – /tmp/migrate/nnnnn/logs directory can contain log files, with a name such as the WAS*Upgrade*timestamp.log file. 0002 If you need more information, enable traces. The trace states are disabled by default. Be aware that ‘xxxx.DATA(BBOWMxEV)’ must be updated to enable tracing: – – – –
TraceState=enabled profileTrace=enabled preUpGradeTrace=enabled postUpGradeTrace=enabled
0002 If the job fails in the VERIFY step, it is likely that an error was made when specifying the information to use to create the jobs. Correct the information and rerun the job. 0002 If the job fails after the VERIFY step, delete the WAS_HOME directory. This directory is created during the failed run Delete the directory before rerunning the job. Check whether the original configuration for the serverindex.xml file has been renamed to serverindex.xml_disabled. The job failure is a signal that the configuration has already been migrated and to stop you from inadvertently migrating the node again. To change the default setting during the configuration phase, select Disable previous deployment manager in the Server Customization (Part 2) window. This window is a part of the z/OS Migration Management Tool. Alternatively, set the keepDMGREnabled parameter to true in the response file. Tip: The BBOWMG3x job can cause error conditions, such as an abend 522, because it runs for a long time. TIME=NOLIMIT on the JCL job card can avoid the problem. The BBOWMG1x and BBOWMG2x jobs are only necessary if you have any XA connectors defined in your configuration. They do not apply to the deployment manager node migration.
17.6.7 Migration considerations for 64-bit mode Websphere Application Server V8.5 runs in 64-bit mode by default and 31-bit runtime mode is deprecated. Keep in mind the considerations that are highlighted in this section.
Application considerations For code written in pure Java, the general experience is that no changes are necessary to the code for it to run in a 64-bit application server. If the application uses the Java Native Interface 602
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
(JNI) to call a native program, it must be a 64-bit program. Typically, these native programs are code that is written in C, C++, or perhaps an IBM Language Environment compliant assembler. This point is important to verify when you are using in-house applications that use older native programs. For more information about how to convert applications to run in 64-bit mode, see the following resources: 0002 C/C++ Code Considerations With 64-bit WebSphere Application Server for z/OS (WP101095): http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101095 0002 Language Environment Programming Guide for 64-bit Virtual Addressing Mode, SA22-7569-06 http://publibz.boulder.ibm.com/epubs/pdf/ceeam160.pdf
Larger heap sizes for applications Use of the 64-bit addressing mode does not mean that the sizes for the various heaps must be increased. In general, identify minimum and maximum heap sizes with a verbose garbage collection analysis. With this technique, you can identify values that reduce the garbage collection processor usage, saving processor time. Consider running a verbose garbage collection analysis regularly, especially if the number of users or the number of transactions have changed. Explanation: In general, the structure of WebSphere Application Server for z/OS reduces the maximum heap size compared to those used by distributed platforms. For more information, see 16.1.6, “Runtime processes” on page 537.
Chapter 17. Migration
603
604
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
A
Appendix A.
Sample topology walkthrough This appendix explores a complex topology and provides general guidance for setting it up. This appendix includes the following sections: 0002 0002 0002 0002 0002 0002 0002
Topology review Sample topology Installation Deploying the applications Configuring security Testing the topology Summary
© Copyright IBM Corp. 2012, 2013. All rights reserved.
605
Topology review Figure A-1 illustrates one of the most common (and complex) topologies implemented in real scenarios. This configuration was provided by customers and IBM teams who are responsible for the implementation of WebSphere environments. This topology provides great resiliency because all points of failure are eliminated. It also takes advantage of almost all the components included in the WebSphere Application Server Network Deployment package. Client Network (10.20.0.0/24
DMZ Network (10.20.10.0/24
Application Network (10.20.20.0/24
Backend Network (10.20.30.0/24
App2Node
Node agent Application server clusters HTTP1
Load balancer backup
Caching proxy Caching proxy backup
Load balancer backup
Load balancer for caching proxy
lb1
EJB1a
Web cont.
EJB cont. DB
Load balancer for HTTP servers
lb2 cproxy
IBM HTTP server
Web1a
Web1b
EJB1b
Web cont.
EJB cont.
Database server 1 App data
HTTP2 App1Node IBM HTTP server
Web2
EJB2
Web cont.
EJB cont.
Cluster cluster.itso.ibm.com Node agent DM Deployment manager Admin console
Figure A-1 Complex topology
This topology includes the following elements: 0002 A load balancer to direct incoming requests to the caching proxy, and a second load balancer to manage the workload across the HTTP servers. Load Balancer is included in the WebSphere Application Server Edge Component. Load Balancer distributes incoming client requests across servers, balancing workload and providing high availability by routing around unavailable servers. A backup server is configured for each primary Load Balancer to provide high availability. 0002 A Caching Proxy with a backup server in passive mode for high availability. Caching Proxy is included in WebSphere Application Server Edge Components. Cacheable content includes static web pages and JavaServer Pages (JSP) with dynamically generated but infrequently changed fragments. The Caching Proxy can
606
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
satisfy subsequent requests for the same content by delivering it directly from the local cache. This process is much quicker than retrieving it again from the content host. 0002 Two IBM HTTP Server Web servers configured in a cluster Incoming requests for static content are served by the web server. Requests for dynamic content are forwarded to the appropriate application server by the web server plug-in. 0002 A dedicated server to host the deployment manager The deployment manager is required for administration, but is not critical to the runtime execution of applications. Having a separate server for the deployment manager instead of placing it in on one of the node’s servers leaves more resources available for the application servers. Also, if a problem occurs with the node server, the administration of the other nodes is still possible. Additionally, the deployment manager has a master copy of the configuration that must be backed up regularly. 0002 Two clusters that consist of three application servers Each cluster spans two systems. In this topology, one cluster contains application servers that provide the web container functions of the applications (servlets and JSP). The second cluster contains the Enterprise JavaBeans (EJB) container functions. Whether you choose to use clusters is a matter of careful consideration. Although using clusters provides failover and workload management capabilities for web and EJB containers, it can also affect performance. 0002 A dedicated database server that runs the database.
Advantages This topology has the following benefits: 0002 High availability and failover support The redundancy of the different elements eliminates single points of failure (SPOFs) and provides hardware and software failure isolation. 0002 Optimized resource use Vertical scaling provides the benefit for each Java virtual machine (JVM) to use a portion of the system’s processor and memory. More JVMs can be created to take advantage of the available resources. 0002 Workload management In this topology, workload management is done by the Load Balancer, which distributes work among the web servers. In addition, the WebSphere Plug-Ins load balance work across the application servers. 0002 Improved throughput and response time Multiple systems serve client requests without competing for resources, and the resources on the servers are optimally used. 0002 Scalability With this type of topology, you can add more JVMs if necessary. As more nodes or more web servers are added, the loader balancer distributes the load across the members added to the original topology as well.
Appendix A. Sample topology walkthrough
607
Disadvantages This topology has the following disadvantages: 0002 Complex administration Several different systems must be administered, configured, and maintained. Consider the costs of such administrations in relation to the benefits of increased performance, higher throughput, and greater reliability. 0002 Increased cost More hardware, and, therefore more licenses, are required, which increases overall costs.
Sample topology This section presents a simplified topology that is derived from the one illustrated in Figure A-1 on page 606. This sample topology demonstrates the necessary steps to implement the main elements of the complex topology as explained in “Topology review” on page 606. Figure A-2 shows the topology that is implemented in this section.
Server D w1.itso.ral .i bm.com Ser ver B Depl oyment manager
h1.i tso.ral .i bm.com IB M HTT P server webser ver1
A ppli cati on server AS1
A ppli cati on server EJBServ er 1
Clu ster ASCluste r
Clu ster E JBClust er
Server A l b.itso.ral.ib m.com Load balancer bc.itso.ral.ib m.com
Se rve r E Ser ver C h2.i tso.ral .i bm.com IB M HTT P server webser ver2
w2.itso.ral .i bm.com A ppli cati on server AS2
A ppli cati on server EJBServ er 2
Se rve r F l dap.itso.ral.ib m.com IB M Tivoli Di rectory Server
Figure A-2 Sample topology
608
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
This topology has the following characteristics: 0002 The topology allows for the deployment of the BeenThere sample application that is included in the material that is available for download for this book. For more information, see Appendix D, “Additional material” on page 637. The BeenThere sample application demonstrates the workload management and clustering capabilities of Websphere Application Server. Because its responses contain the application servers where requests are processed, you can test load balancing and availability with this application. 0002 It is common to have the administrative or application security integrated with a Lightweight Directory Access Protocol (LDAP) repository in production environments. Because of this integration, another element is added to the sample topology: The IBM Tivoli Directory Server offering for an LDAP server. 0002 A Load Balancer is installed to demonstrate its workload management capabilities for sending requests to the web servers. Because there is no backup server for the load balancer, this element is a SPOF, which is not a critical issue for this sample topology. 0002 No database is installed because, for testing purposes of this topology, it is not necessary to query data from a database.
Installation This section explains the main steps for installing each component. All elements are installed with the Installation Manager. Tip: If the servers where the installation is going to occur do not have an Internet connection, use local repositories. To prevent Installation Manager from searching for the packages over the Internet, clear the remote repositories by clicking File  Preferences.
Installing Load Balancer (Server A) The Load Balancer component runs in Server A, and is used to distribute traffic between the two web servers. To install Load Balancer, complete these steps: 1. Install Load Balancer: a. Install the Installation Manager, accepting the default values. b. Start the Installation Manager, and select the Install option. c. From Installation Packages, select IBM WebSphere Edge Components: Load Balancer for IPv4 and IPv6, and click Next. d. Go through the remaining windows, accepting the default options for each one. 2. Configure the load balanced cluster: a. Verify that the load balancer service, IBMDisp(ULB), is started. b. Run the lbadmin command. c. Right-click Dispatcher Connect to Host. d. Right-click Dispatcher Start Configuration Wizard.
Appendix A. Sample topology walkthrough
609
e. Following the wizard panels, create a cluster with the new web cluster IP address, and add the two web servers in it. This new IP address is the public address that clients must use to access the BeenThere application. It is a different IP address from the system addresses. f. Right-click Host and select Start Manager to configure the Advisor. g. Right-click Manager and select Advisor. Then, monitor the HTTP protocol. This action detects when a web server is down and stops sending requests to that server. 3. Configure loopback adapters in web servers: a. Add a loopback adapter interface in both HTTP server systems (Servers B and C). Installing this interface is necessary in Windows platforms only. b. Configure the cluster address and the corresponding subnet mask in the loop back adapters.
Installing the HTTP servers (Servers B and C) Both Servers B and C run a web server that directs the incoming requests to one of the application servers. To install the HTTP servers, complete these steps on both servers: 1. Install the Installation Manager. 2. Install the IBM HTTP Server: a. Start the Installation Manager, and select the Install option. b. From Installation Packages, select IBM HTTP Server for WebSphere Application Server and click Next. c. In the wizard panels, select the default options, and complete the installation. d. Start the server by clicking Start Programs  IBM HTTP Server for WebSphere Software V8.5  Start HTTP Server. 3. Install the WebSphere Plug-in: a. Start the Installation Manager, and select the Install option. b. From Installation Packages, select Web Server Plug-ins for IBM WebSphere Application Server, and click Next. c. In the wizard panels, select the default options, and complete the installation. 4. Install the WebSphere Customization Toolbox: a. Start the Installation Manager, and select the Install option. b. From Installation Packages, select WebSphere Customization Toolbox, and click Next. c. Click to clear the Profile Management Tool (z/OS only) and z/OS Migration Management Tool options. d. In the other wizard panels, select the default options, and complete the installation. e. Start the WebSphere Customization Toolbox. f. Add a WebSphere Plug-in Runtime Location. Use the plugin_root path as the location. g. Create a WebSphere plug-in configuration for IBM HTTP Server.
610
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Creating a deployment manager (Server D) Server D hosts the deployment manager that is used to administer the servers, applications, and resources in the WebSphere Application Server cell. To build this node, complete these steps: 1. Install WebSphere Application Server Network Deployment: a. Install IBM Installation Manager. b. From Installation Packages, select IBM WebSphere Application Server Network Deployment. c. Navigate through the panels in the installation wizard, selecting the default options. d. Leave the option to start the Profile Management Tool selected, and click Finish. 2. Create a deployment manager profile: a. Click Create. b. Create a management profile of type deployment manager with the default options. 3. Start the deployment manager by clicking Start Programs  IBM WebSphere  Websphere Application Server Network Deployment V8.5  Profiles  Dmgr01  Start the deployment manager.
Creating the application servers (Servers D and E) Server D and E host the two application server clusters that are needed for the BeenThere application. The process to install and build the WebSphere Application Server components is the same for each application server node. To create the application servers, complete these steps: 1. Install WebSphere Application Server Network Deployment: a. Install IBM Installation Manager. b. From the Installation Packages, select IBM WebSphere Application Server Network Deployment. c. Navigate through the panels in the installation wizard, selecting the default options. 2. Create a custom profile for the node: a. Start the Profile Management Tool, and select Custom Profile. b. Follow the prompts, accepting the defaults, including the federation of the node to the cell as part of the process. The deployment manager must be installed and running during this process. 3. Create the application server clusters: a. Log on to the administrative console. b. Click Servers  Clusters  WebSphere application server clusters.
Appendix A. Sample topology walkthrough
611
c. Add the two new clusters with the names and member weights that are shown in Table A-1. Table A-1 Cluster names and weights Cluster name
Member name
Weights
ASCluster
AS1
2
AS2
3
EJBServer1
1
EJBServer2
3
MyEJBCluster
The chosen weights are the weights indicated in the BeenThere application installation instructions, and are intended to illustrate the workload management capabilities of the product.
Enabling the WebSphere configuration service According to the application installation instructions, the WebSphere configuration service must be enabled for the application to read WebSphere Application Server configuration files to obtain environment information. To enable the WebSphere configuration service, complete these steps: 1. Log on to the administrative console. 2. For both application servers from the ASCluster, complete the following steps: a. Click Servers  Application Servers  server_name  Server Infrastructure  Administration  Administration Services  Custom Properties. b. Create a property called com.ibm.websphere.management.enableConfigMBean with a value of true.
Deploying the applications For the deployment of the application, the new monitored directories feature is used. To deploy the applications, complete these steps: 1. Enable the monitored directory: a. Log on to the administrative console. b. Click Applications  Global Deployment Settings. c. Select the Monitor directory to automatically deploy applications option. d. Leave the default values, and then click Apply. e. Restart the deployment manager. f. Create a directory, called ASCluster, in the dmgr_profile_path/monitoredDeployableApps/clusters path. 2. Deploy the BeenThere application: a. Make sure that ASCluster is running. b. Copy the BeenThere enterprise archive (EAR) file into the ASCluster directory.
612
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
c. After 5 seconds, log on to the administrative console. Then, click Applications  Application Types  WebSphere Enterprise Applications. The BeenThere application should be listed with the status of starting. 3. Map the EJB module to the MyEJBCluster cluster: a. Click BeenThere  Manage Modules. b. Select the check box for the BeenThereEJB module and the MyEJBCluster row under Cluster and Servers. Then, click Apply. Explanation: You can also use a property file to deploy the web archive (WAR) module to the ASCluster and the EJB module to the MyEJBCluster automatically. However, for simplicity, the administrative console was used in this example. To create the property file and use it to deploy the modules, see the Websphere Application Server V8.5 Information Center at: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product= was-base-dist&topic=trun_app_install_dragdrop 4. Generate a new plug-in for the IBM HTTP Servers: a. Click Environment Update global Web server plug-in configuration. b. Click OK to update the plug-in file. c. Copy the new plug-in file to webserver1 and webserver2. The default target directory is C:Program FilesIBMWebSpherePluginsconfigyour_web_server.
Configuring security Many of the production environments in today’s organizations manage their users in LDAP directories. This section describes the necessary steps to connect the WebSphere Application Server security with IBM Tivoli Directory Server. Because the profile for the deployment manager was already created with security enabled, complete these steps: 1. Change the administrative user registry: a. Log on to the administrative console. b. Click Security  Global Security. c. Under the User account repository, select Standalone LDAP registry, and click Configure. d. Enter the corresponding information for the following fields: • • • • • • •
Primary administrative user name Type of LDAP server (in this case IBM Tivoli Directory Server) Host Port Base distinguished name (DN) Bind distinguished name (DN) Bind password
e. Click Test Connection to make sure that the communication with the LDAP server has no problems. f. Click OK, and save the changes.
Appendix A. Sample topology walkthrough
613
g. Make sure that the stand-alone LDAP registry is selected under User account repository. Click Set as current, and then click Apply to validate all the entered settings. If no errors are shown, save the changes. Tip: If you receive the following error, verify that the user filter is correct in the user registry settings: Validation failed: SECJ7716E: Primary administrative user Id does not exist in the registry. 2. In the Global security panel, select Enable application security. 3. Assign administrative roles. The user account that is being used to log on to the BeenThere application needs an administrative role. Otherwise, the application will not work because the application must get the node name from Websphere Application Server. Therefore, the user role is not enough. To assign this role to the user, complete these steps: a. Click Global security Administrative user roles. b. Click Add. c. Search for the user that is going to be used with the application, and assign that user the monitor role. d. Click OK and save the changes. 4. Assign application roles. This application has a role (administrator) that must be assigned to the user. To assign application roles, complete these steps: a. Click Applications  Application types  WebSphere enterprise applications. b. Select BeenThere, and click Security role to user / group mapping. c. Map the user from the LDAP repository to the administrator role. d. Click OK, and save the changes. 5. Stop all the processes in the cell, and start the deployment manager, node agents, and application servers in the order listed.
Testing the topology Because the tests were intended to demonstrate the clustering, load balancing, and high availability capabilities of the sample topology, the environment was challenged in different conditions. For each test case described in this section, the following address was entered in the web browser: http://bc.itso.ral.ibm.com/wlm/BeenThere?weights=false&count=4
Normal functioning In this test, every component was up and running to show the load balancing features in Websphere Application Server. Because this is the first test, the window shown in Figure A-3 on page 615 opens. Enter the credentials of the user stored in the LDAP repository and click OK.
614
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Figure A-3 Authentication dialog box
Figure A-4 shows the response from the application. The request was processed by the servlet on node w2Node1. Three of the four iterations were processed by EJBServer2 and the other one by EJBServer1. This distribution of the requests to the EJB servers is because of the weights that were configured when those servers were created (Table A-1 on page 612).
Figure A-4 Response from the BeenThere application
Appendix A. Sample topology walkthrough
615
Remember: If the EJBServer is the same for the four iterations, but alternates between EJBServer1 and EJBServer2 after refreshing the page several times, the work load management is working. The prefer local feature in the MyEJBCluster is enabled by default, which causes all enterprise bean requests to be routed to the client host. You can disable this feature, restart the MyEJBCluster, and test again to see how the requests are load balanced according to the configured weights. Keep in mind that the prefer local feature improves performance and must remain enabled in production environments.
One web server down In this test, webserver1 was stopped. Load Balancer detected this situation. In the Advisor Status window (Figure A-5), a value of -1 in the load column for the h1.itso.ral.ibm.com server indicates that it is not available.
Figure A-5 Advisor Status window
Because of the load balancing mechanism, this environment was still working, and new requests to the system received the correct responses. From a user point of view, the environment behavior did not change.
616
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
One Websphere Application Server node down In the last of the test scenarios, the servers at w2.itso.ral.ibm.com were stopped. The system still responded to requests, which were all processed by w1.itso.ral.ibm.com (Figure A-6).
Figure A-6 All responses from EJBServer1
Summary This appendix highlighted a commonly used complex topology. It provided a simplified version of this topology and used it to illustrate the installation of the different components. The scenario demonstrated its response to the challenges. Finally, this appendix highlighted the administration capabilities that can be done by running jobs from the deployment manager. These jobs include collecting files, creating profiles, and discovering installed resources on the job targets.
Appendix A. Sample topology walkthrough
617
618
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
B
Appendix B.
Sample topology using the job manager and a Liberty profile This appendix shows how to set up a topology with the job manager and the Liberty profile. The topology was introduced in 8.3.3, “Liberty profiles managed by a job manager” on page 214. This appendix contains the following sections: 0002 0002 0002 0002 0002
Sample topology Installing the HTTP server on Server A Installing the WebSphere job manager on Server B Installing the Liberty profiles, servers, and applications on servers B, C, and D Generating a common plug-in configuration for the Liberty profiles and deploying it to the HTTP server
© Copyright IBM Corp. 2012, 2013. All rights reserved.
619
Sample topology This simple topology uses only one HTTP server. A setup with two HTTP servers and a load balancer is also possible, and removes the single point of failure (SPOF) at the HTTP Server level. This sample topology uses one job manager and three Liberty profiles on different nodes, as shown in Figure B-1. Remember: The process that is described in this appendix is an example and shows one of many options you have when you create a Liberty profiles with a job manager.
Server B saw209RHEL1.itso.ral.ibm.com
Job Manager
Liberty profile server liberty2
Server A saw209-ms2008sys2.itso.ral.ibm.com
Server C saw209RHEL2.itso.ral.ibm.com
IBM HTTP server webserver
Liberty profile server liberty1
Server D saw209-ms2008sys1.itso.ral.ibm.com
Liberty profile server liberty2
Figure B-1 Sample topology with Liberty profiles
Installing the HTTP server on Server A To install the HTTP Server on System A, complete these steps: 1. Install the Installation Manager. 2. Install the IBM HTTP Server: a. Start the Installation Manager, and select the Install option. b. From Installation Packages, select IBM HTTP Server for WebSphere Application Server, and click Next.
620
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
c. In the wizard panels, select the default options, and complete the installation. d. Start the server from Start Programs  IBM HTTP Server for WebSphere Software V8.5  Start HTTP Server. 3. Install the WebSphere Plug-in: a. Start the Installation Manager, and select the Install option. b. From Installation Packages, select Web Server Plug-ins for IBM WebSphere Application Server, and click Next. c. In the wizard panels, select the default options, and complete the installation. 4. Install the WebSphere Customization Toolbox: a. Start the Installation Manager, and select the Install option. b. From Installation Packages, select WebSphere Customization Toolbox, and click Next. c. Clear the Profile Management Tool (z/OS only) and z/OS Migration Management Tool options. d. In the other wizard panels, select the default options, and complete the installation. e. Start the WebSphere Customization Toolbox. f. Add a WebSphere Plug-in Runtime Location. Use the plugin_root path as the location. 5. Create a WebSphere plug-in configuration for IBM HTTP Server.
Installing the WebSphere job manager on Server B The WebSphere job manager needs a WebSphere Application Server Network Deployment installation. To build this node, complete these steps: 1. Install WebSphere Application Server Network Deployment: a. Install IBM Installation Manager. b. From Installation Packages, select IBM WebSphere Application Server Network Deployment. c. Go through the panels in the installation wizard, selecting the default options. d. Start the Profile Management Tool, and click Finish. 2. Create a job manager profile: Open a terminal and navigate to the bin subdirectory of the application server directory. If you installed the application server in /opt/IBM, navigate to /opt/IBM/AppServer/bin. Enter the following command: ./manageprofiles.sh -create -profileName JobMgr -templatePath /opt/IBM/AppServer/profileTemplates/management -nodeName saw209RHEL1JobMgr -cellName JobMgrCell -hostName saw209RHEL1 -serverName jobmgr -adminUserName admin -adminPassword ******* -enableAdminSecurity true -isDefault -serverType JOB_MANAGER 3. Start the job manager by entering: ./startServer.sh jobmgr 4. Call the job manager from a web browser: http://saw209RHEL1:9960/admin Appendix B. Sample topology using the job manager and a Liberty profile
621
The IP Port might be different. You can find the ports for your profile in the AboutThisProfile.txt file, which is in the AppServer/profiles/JobMgr/logs directory.
Installing the Liberty profiles, servers, and applications on servers B, C, and D You can install the Liberty profiles, servers, and applications by using the job manager. When this installation starts, there is no need for any WebSphere code on the systems on which the Liberty profiles run. However, if you do not include the JRE in the compressed file, make sure that a Java runtime environment (JRE) is installed on these systems.
Install a Java Runtime Environment on Servers B, C, and D The minimum supported levels are IBM JDK 626 SR 6 or Oracle Java 6 SR 26. Higher levels (including Java 7) are supported but might have restrictions. After you install a supported JRE, make sure that the jre/bin directory is in one of these locations: 0002 The JAVA_HOME 0002 The PATH variable for the administrative user that you used to install the Liberty profile
Create a compressed file that contains the servers and applications You can download an archive file that contains the WebSphere Liberty profile at: http://wasdev.net You can use any extraction tool to create a package file of the server directory (/wlp/usr/servers) within the compressed file. The name of the directory is the name of your server. The directory that you create must contain the server server.xml configuration file. The server directory contains an apps subdirectory that contains all applications you want to deploy as web archive (WAR) or enterprise archive (EAR) files. Alternatively, you can also use the package command to package a server.
Deploy the Liberty profiles by using the job manager To deploy a Liberty profile, log on to the job manager and complete these steps: 1. Create a target entry for the host: a. Click Jobs  Targets, then click New Host. b. Enter the host name and select the operating system. c. Enter the name and the password of a user with administrative rights on the target system. d. Enter a variable called WLP_WORKING_DIR. The value of this variable is an existing directory on the target host. Job manager creates the wlp subdirectory in the WLP_WORKING_DIR directory and installs the Liberty profile there.
622
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Figure B-2 shows where to enter the data to create this target.
Figure B-2 Creating the job manager target
Appendix B. Sample topology using the job manager and a Liberty profile
623
2. Deploy the prepared compressed file. Deploy the compressed file that you created in “Create a compressed file that contains the servers and applications” on page 622 to the target host. Click Jobs  Submit, and select Install Liberty profile server resources as shown in Figure B-3. Click Next.
Figure B-3 Deploying the Liberty profile, step 1
3. Select the target host and enter user name and password of a user with administrative rights as shown in Figure B-4. Click Next.
Figure B-4 Deploying the Liberty profile, step 2
624
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
4. Specify the compressed file on the job manager host as shown in Figure B-5. You can also specify a URL where the file can be retrieved by using HTTP or FTP.
Figure B-5 Deploying the Liberty profile, step 3
5. Click Next and accept the default values. The job is run immediately. 6. Click Next again, and review the settings. If the values are correct, click Finish. To view the finished job, click Jobs  Status as shown in Figure B-6.
Figure B-6 Job status when deployment finishes successfully
Appendix B. Sample topology using the job manager and a Liberty profile
625
After the deployment completes, check the directories on the target host. Figure B-7, shows where the run time, the server configuration, and the applications are deployed.
Figure B-7 Directories the job manager created on the target host
626
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
You can see the resources on the new host if you click Jobs  Target resources on the Job manager as displayed in Figure B-8.
Figure B-8 Job manager resources
7. Start the Liberty profile server: a. Click Jobs  Submit and then Start Liberty profile server as shown in Figure B-9.
Figure B-9 Starting the Liberty profile server, step 1
b. Select Next then select the target host as shown in Figure B-4 on page 624.
Appendix B. Sample topology using the job manager and a Liberty profile
627
c. Click Next again and then click Find to find the target resource name of this server. Select the server name and press OK. The server to be started is displayed in the text box as shown in Figure B-10.
Figure B-10 Starting the Liberty profile server, step 2
8. Click Next twice, and then click Finish. To check the status of the job, click Jobs  Status. When the job finishes successfully, the status view looks like Figure B-11.
Figure B-11 Starting the Liberty profile server, step 3
You can check the console.log file on the target server usr/servers/servername/logs subdirectory of the Liberty profile directory, as shown in Figure B-12. Launching liberty2 (wlp-1.0.0.20120307-0807/websphere-kernel_1.0.0) on IBM J9 VM, version jvmwi3260sr9-20110203_74623 [AUDIT ] CWWKE0001I: The server liberty2 has been launched. [AUDIT ] J2CA8000I: The jdbcDriver db2JDBCDriver is available. [AUDIT ] CWWKZ0058I: Monitoring dropins for applications. [AUDIT ] CWWKT0016I: Web application available (default_host): http://saw209-ms2008-sys1.itso.ral.ibm.com:9080/WebCustomerCredit/* [AUDIT ] CWWKZ0001I: Application WebCustomerCredit started in 2.762 seconds. [AUDIT ] CWWKF0011I: The server liberty2 is ready to run a smarter planet. Figure B-12 Liberty log file entries
628
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Generating a common plug-in configuration for the Liberty profiles and deploying it to the HTTP server Using job manager, you can create a common plug-in configuration for the Liberty profiles. This configuration enables the HTTP server to run load balancing and failover for the applications that are running on the Liberty profiles. This plug-in configuration is copied to the HTTP server.
Appendix B. Sample topology using the job manager and a Liberty profile
629
630
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
C
Appendix C.
Sample topology for maintenance and troubleshooting using the Liberty profile This appendix shows how to set up a topology with Liberty profile servers that includes considerations for maintenance and troubleshooting tools. The features that are used in this topology were introduced in 4.8, “Troubleshooting” on page 114. This appendix contains the following sections: 0002 0002 0002 0002 0002
Sample topology Configuring the Liberty profile as a web server Creating a pattern for REST connectivity Creating a pattern for JDBC troubleshooting Including a new feature in default configuration
© Copyright IBM Corp. 2012, 2013. All rights reserved.
631
Sample topology The topology shown in Figure C-1 uses a Liberty profile as an HTTP server to store configuration files and keystores. When a Liberty profile requires maintenance or troubleshooting activities, this configuration can be used to eliminate the need for a reboot or server restart.
Se rver Ma inte na nc e
Syste m A
WLP – Port 8 0
WLP Serv er 1
m ain ten an ce .xm l
WLP Se rver 2
KeySt or e. jks
WLP Se rver 3
re stCo nn ec tor .ja r
Port 80 HTTP
WLP Serv er 4
Syste m B WLP Serv er 5 JC onsole Machine
P ort 9443 HTTPs Key Stor e. jks
r es tCo nn ect or .jar
WLP Ser ver 6 WLP Ser ver 7 WLP Serv er 8
Figure C-1 Maintenance and troubleshooting diagram
In Figure C-1, the system labeled Server Maintenance is running a Liberty profile server that provides static files for the Liberty servers on System A and System B. The Liberty servers access the files on the maintenance server through a URL in the same manner that they would access files on a web server. This topology works equally well using a web server. Files on the maintenance server include server configuration XML files that can be included in the server configuration for the servers on System A and System B. The maintenance server also holds files such as key stores and restConnector.jar that are needed for these configurations. Remember: The process that is described in this appendix is a suggestion and exemplifies one of many options you have when you create the Liberty profiles.
Configuring the Liberty profile as a web server The technique that is used to configure the Liberty profile server as a web server involves creating an empty directory with .war in the name. You then publish the .war file in the Liberty profile server as a WAR application with the static files inside this directory. In this example, the following directory was created: usr/servers/servermaintenance/staticfiles.war
632
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Example C-1 shows the server configuration for this. Example C-1 Server configuration defining the staticfiles.war application location
jsp-2.2 The directory created in the file system to be published in Example C-1 is created under the liberty profile root configuration directory as shown in Example C-2. Example C-2 File system contents
# ls -l drwxr-xr-x. 2 root root 4096 Apr 19 12:28 apps -rw-r--r--. 1 root root 19 Apr 20 14:25 bootstrap.properties drwxr-xr-x. 2 root root 4096 Apr 23 08:15 dropins -rw-r--r--. 1 root root 0 Apr 23 07:42 index.html drwxr-xr-x. 3 root root 4096 Apr 23 08:12 logs -rw-r--r--. 1 root root 385 Apr 23 08:15 server.xml drwxr-xr-x. 2 root root 4096 Apr 23 08:17 staticfiles.war drwxr-xr-x. 5 root root 4096 Apr 23 08:12 workarea # ls -l staticfiles.war/ -rw-r--r--. 1 root root 2186 Apr 11 19:02 key.jks -rw-r--r--. 1 root root 491 Apr 15 09:32 remoteconfig.xml -rw-r--r--. 1 root root 206600 Apr 23 07:46 restConnector.jar [[email protected] server1]#
The files are available to the servers by using the complete URL. For example, remoteconfig.xml is available at http://ip_address/maintenance/remoteconfig.xml.
Creating a pattern for REST connectivity The first configuration pattern that is stored in the maintenance server, called remoteconfig.xml, enables the REST connector in order to provide access to MBeans in the server without restarting the Liberty profile server. The remoteconfig.xml file is shown in Example C-3. Example C-3 Example of a pattern to provide a REST connection
monitor-1.0 restConnector-1.0 Appendix C. Sample topology for maintenance and troubleshooting using the Liberty profile
633
ssl-1.0 To enable the REST connection to a Liberty profile server by using this pattern, complete these steps: 1. Copy key.jks from the web server to the Liberty root directory: /usr/servers/server_name/resources/security/key.jks 2. Add the following line to in the Liberty profile server server.xml file: Tip: The feature optional=”false” allows the included resource to be skipped if it cannot be found. These steps load the configuration in the server to be monitored without restarting the server. To disable the feature, delete the line or comment it out by using the tags . The client is the system that connects to the server by using jConsole and the REST connector. Configure the client by completing these steps: 1. Copy key.jks and restConnector.jar from the web server to the client system. 2. Open jConsole using the parameters shown in Example C-4. Change the keystore password and the location of the keystore and the restConnector.jar. Example C-4 Command-line parameters to use restConsole.jar connector
jconsole -J-Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar:/tmp/r estConnector.jar -J-Djavax.net.ssl.trustStore=/tmp/key.jks -J-Djavax.net.ssl.trustStorePassword=mypassword -J-Djavax.net.ssl.trustStoreType=jks -J-Dcom.ibm.ws.jmx.connector.client.disableURLHostnameVerification=true
Creating a pattern for JDBC troubleshooting A new feature called Timed Operation has been added to the Liberty profile in V8.5.5 to help troubleshoot problems with JDBC connections. This feature can be used to determine the
634
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
typical time for each JDBC request and watch for patterns of poor performance. The feature issues warnings when requests start repeatedly taking longer than expected. In Example C-5, an XML file contains the configuration that is required to enable this feature. The configuration starts the timed operations feature, which generates a report on an hourly basis with a limit of 20000 SQL queries. The report files that are generated by this configuration are created with a 50 mb size maximum, and a maximum of 10 log files are kept. To keep this data out of the usual log directory, the files are created in /tmp/wtp followed by the original path of the instance with the names MessagesTimedOperations.log and TraceTimedOperations.log. The trace specification was set to “finest” to capture more information. Example C-5 timedtrace.xml example
timedOperations-1.0
To include this configuration in a server that needs the JDBC operations to be monitored, include the following line in the server.xml file as shown in Example C-6. Example C-6 Configuration to enable timedtrace.xml pattern in server.xml.
Including a new feature in default configuration The Liberty profile stores the structure to be used when a new server is created in the root directory /templates/servers/defaultServer. Every change that occurs in this directory, including files and directory structure, is replicated when a new server is created using the command bin/server create. The technique that is illustrated in this section can be used to customize the Liberty profiles of new servers.
Appendix C. Sample topology for maintenance and troubleshooting using the Liberty profile
635
For example, you can include a keystore in the default configuration to avoid the manual inclusion every time you create a server. You can do so by adding the keystore in the default structure: 1. Create a resources/security directory in the defaultServer directory. 2. Copy the keystore to the resources/security directory. To verify that the configuration works, create a server by using the bin/server create newserver command. You should see the resources/security/keystore file included in the server directory structure usr/servers/newserver. Tip: This technique can be used to create a customized bootstrap.properties file that is used in every new server created. This technique is useful if you want to enable all servers to use binary logging at server creation.
636
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
D
Appendix D.
Additional material This book refers to additional material that can be downloaded from the Internet as described in the following sections.
Locating the web material The web material associated with this book is available in softcopy on the Internet from the IBM Redbooks web server at: ftp://www.redbooks.ibm.com/redbooks/SG248022 Alternatively, you can go to the IBM Redbooks website at: ibm.com/redbooks Select the Additional materials and open the directory that corresponds with the IBM Redbooks form number, SG248022.
Using the web material The additional web material that accompanies this book includes the following files: File name SG248022.zip
Description Compressed code samples
Downloading and extracting the web material Create a subdirectory (folder) on your workstation, and extract the contents of the web material .zip file into this folder.
© Copyright IBM Corp. 2012, 2013. All rights reserved.
637
638
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this book.
IBM Redbooks The following IBM Redbooks publications provide additional information about the topic in this document. Note that some publications referenced in this list might be available in softcopy only. 0002 IBM Tivoli Composite Application Manager Family Installation, Configuration, and Basic Usage, SG24-7151 0002 IBM WebSphere Application Server V8 Concepts, Planning, and Design Guide, SG24-7957 0002 Java Stand-alone Applications on z/OS, Volume I, SG24-7177 0002 Java Stand-alone Applications on z/OS Volume II, SG24-7291 0002 Patterns: SOA Foundation Service Creation Scenario, SG24-7240 0002 Rational Application Developer for WebSphere Software V8 Programming Guide, SG24-7835 0002 Solution Deployment Guide for IBM Tivoli Composite Application Manager for WebSphere, SG24-7293 0002 System Programmer's Guide to: Workload Manager, SG24-6472 0002 Web Services Handbook for WebSphere Application Server 6.1, SG24-7257 0002 WebSphere Application Server V7 Migration Guide, REDP-4635 0002 WebSphere Application Server V7.0 Security Guide, SG24-7660 You can search for, view, download, or order these documents and other Redbooks, Redpapers, Web Docs, draft and additional materials, at the following website: ibm.com/redbooks
Other publications These publications are also relevant as further information sources: 0002 Language Environment Programming Guide for 64-bit Virtual Addressing Mode, SA22-7569 0002 z/OS MVS Initialization and Tuning Reference, SA22-7592 0002 z/OS MVS System Management Facilities (SMF), SA22-7630 0002 z/OS UNIX System Services Planning Guide, GA22-7800
© Copyright IBM Corp. 2012, 2013. All rights reserved.
639
Online resources These websites are also relevant as further information sources: 0002 Websphere Application Server V8.5 Information Center http://publib.boulder.ibm.com/infocenter/wasinfo/v8r5/index.jsp 0002 Java EE 6 specifications http://jcp.org/en/jsr/detail?id=316 0002 The WebSphere Application Server V8 Information Center http://publib.boulder.ibm.com/infocenter/wasinfo/v8r5/index.jsp 0002 Tivoli Directory Server http://www.ibm.com/software/tivoli/products/directory-server/ 0002 IBM Tivoli Workload Scheduler http://www.ibm.com/software/tivoli/products/scheduler/ 0002 WebSphere MQ http://www.ibm.com/software/integration/wmq/ 0002 IBM WebSphere Adapters http://www.ibm.com/software/integration/wbiadapters/ 0002 Information about the DataPower appliances http://www.ibm.com/software/integration/datapower/ 0002 IBM DB2 database software http://www.ibm.com/db2/ 0002 DB2 pureScale product page http://www.ibm.com/software/data/db2/linux-unix-windows/editions-features-pures cale.html 0002 What is DB2 pureScale? Going to extremes on scale and availability for DB2 article http://www.ibm.com/developerworks/data/library/dmmag/DBMag_2010_Issue1/DBMag_Is sue109_pureScale/ 0002 Integrating WebSphere Extreme Scale and WebSphere Application Server for Caching HTTP Sessions: http://www.ibm.com/developerworks/websphere/library/techarticles/1112_shenoy/11 12_shenoy.html?ca=drs0002 WebSphere Application Server—Express V8.5 http://www.ibm.com/software/webservers/appserv/express/ 0002 WebSphere Application Server V8.5 http://www.ibm.com/software/webservers/appserv/was/ 0002 WebSphere Application Server for Developers V8.5 http://www.ibm.com/software/webservers/appserv/developer/index.html 0002 WebSphere Application Server Network Deployment V8.5 http://www.ibm.com/software/webservers/appserv/was/network/
640
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
0002 WebSphere Application Server for z/OS V8.5 http://www.ibm.com/software/webservers/appserv/zos_os390/ 0002 WebSphere Application Server Community Edition http://www.ibm.com/software/webservers/appserv/community/ 0002 WebSphere eXtreme Scale http://www.ibm.com/software/webservers/appserv/extremescale/ 0002 Rational Application Developer for WebSphere Software V8 http://www.ibm.com/software/awdtools/developer/application/ 0002 WebSphere Portal Server - Enterprise portal software product page http://www.ibm.com/software/genservers/portal/server/index.html 0002 Integrating WebSphere Extreme Scale and WebSphere Application Server for Caching HTTP Sessions http://www.ibm.com/developerworks/websphere/library/techarticles/1112_shenoy/11 12_shenoy.html?ca=drs0002 JSR 154, 53, and 315 (Java Servlet 3.0 specification) http://jcp.org/en/jsr/detail?id=315 0002 JSR 318 (EJB 3.1 specification) http://jcp.org/en/jsr/detail?id=318 0002 Portlet 2.0 on the Java Community Process website http://jcp.org/en/jsr/detail?id=286 0002 JSR 289 SIP Servlet API 1.1 Specification http://jcp.org/en/jsr/detail?id=289 0002 RFC 3261 SIP Session Initiation Protocol http://www.ietf.org/rfc/rfc3261.txt 0002 Developing enterprise OSGi applications for WebSphere Application Server http://www.ibm.com/developerworks/websphere/techjournal/1007_robinson/1007_robi nson.html 0002 IBM Education Assistance for online presentation about developing modular and dynamic OSGi applications http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.was_ v8/was/8.0/ProgramingModel/WASV8_OSGi_part1/player.html 0002 Best practices for working with OSGi applications http://www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_char ters.html 0002 Supported specifications for OSGi applications, visit the OSGi Service Platform Release 4 http://www.osgi.org/Release4/HomePage 0002 Cloud computing http://www.ibm.com/cloud-computing/us/en 0002 Subscribe to the IBM Cloud YouTube channel for latest videos: http://www.youtube.com/user/IBMCloud
Related publications
641
0002 Virtualization overview, YouTube video http://www.youtube.com/watch?v=IJM4GIfemT8 0002 On demand router hardware sizing requirements https://www.ibm.com/developerworks/wikis/display/xdoo/Best+practices+for+managi ng+the+on+demand+router?showComments=false> 0002 IBM Systems Workload Estimator page at: http://www.ibm.com/systems/support/tools/estimator/index.html 0002 Information on rPerf http://www.ibm.com/systems/power/hardware/notices/rperf.html 0002 Information on SPEC http://www.spec.org/benchmarks.html 0002 Information on TPC http://www.tpc.org/information/benchmarks.asp 0002 IBM SmartCloud Enterprise as a way to access secure WebSphere environments: http://www.ibm.com/services/us/igs/cloud-development/ 0002 Amazon Elastic Compute Cloud provides WebSphere Application Server images: http://aws.amazon.com/ec2/ 0002 IBM Workload Deployer: http://www.ibm.com/software/webservers/workload-deployer 0002 Using virtual image templates to deploy WebSphere Application Server: http://www.ibm.com/developerworks/websphere/techjournal/0705_willenborg/0705_wi llenborg.html 0002 IBM white paper WebSphere for z/OS -- Heterogeneous Cells: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100644
Help from IBM IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services
642
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
(1.0” spine) 0.875”1.498” 460 788 pages
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide
Back cover
®
WebSphere Application Server V8.5 Concepts, Planning, and Design Guide ®
End-to-end planning for WebSphere Application Server V8.5.5 WebSphere concepts and best practices Addresses distributed and z/OS platforms
This IBM Redbooks publication provides information about the concepts, planning, and design of IBM WebSphere Application Server V8.5 environments. The target audience of this book is IT architects and consultants who want more information about the planning and design of application-serving environments, from small to large, and complex implementations. This book addresses the packaging and features in WebSphere Application Server, and highlights the most common implementation topologies. It provides information about planning for specific tasks and components that conform to the WebSphere Application Server environment. Also in this book are planning guidelines for Websphere Application Server and Websphere Application Server Network Deployment on distributed platforms. It also includes guidelines for WebSphere Application Server for IBM z/OS. This book contains information about migration considerations when moving from previous releases. This book has been updated with the new features introduced with WebSphere Application Server V8.5.5.
INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.
For more information: ibm.com/redbooks SG24-8022-01
ISBN 0738438464