Home > Articles

Introduction to WebSphere Administration: Exploring The Differences In Versions

  • Print
  • + Share This
IBM® WebSphere® Application Server Version 5 provides enhancements to scalability, reliability, Web services, J2EETM 1.3 certification, and many other areas. This chapter explores the various differences between Version 5 and previous versions of this system.
This chapter is from the book

This chapter is from the book

This book continues the series on WebSphere® Application Server Version 5 by focusing on the details of system administration for the product. Once you have developed your J2EE application, and ensured the quality of your application through testing, you are ready to put it into production and use the information from this book to deploy, monitor, tune, and manage your application and the WebSphere Application Server Version 5 environment in which it runs.

IBM® WebSphere® Application Server (hereafter called Application Server) Version 5 provides enhancements to scalability, reliability, Web services, J2EETM 1.3 certification, and many other areas. Version 5 also provides a completely rewritten infrastructure for you to manage and administer your servers and applications. An open-standards-based management framework, JavaTM Management Extensions (JMX), is at the core of the Version 5 management capabilities. New administration tool sets built for Version 5 take advantage of this framework. You can also use the Version 5 administration tool capabilities for your own custom administration programs.

This system administration book discusses a variety of ways to use the Application Server Version 5 management features. Chapter 1 introduces the basic system administration concepts needed to understand Version 5 features. The first important concept to grasp is the new packaging structure for Application Server 5. To understand Application Server administration, you also need to familiarize yourself with the following concepts: servers, nodes and node agents, cells, and the Deployment Manager. It is important that you understand the various processes in the administrative topology and the operating environment in which they apply. Chapter 1 also introduces the four administrative tool sets that are shipped as part of the WebSphere Application Server product.

Chapter 2 completes the foundation concepts needed throughout the rest of the book by delving into the details of the Application Server process internals, distributed administration service product features, administrative security, and the structure of the product configuration files.

Chapter 3 provides a complete reference to the Application Server command-line tools. Each tool is discussed, along with the details of its command-line options.

Chapter 4 is a reference for the Administrative Console program, a sophisticated J2EE Web application that provides the graphical management console for the product. All of the various tasks exposed in the console are covered. This chapter also introduces a set of scenarios for typical administration functions that are carried over to the subsequent chapters for scripting and programmatic administration. These scenarios provide a comparison between how a function can be accomplished through the console, through scripting, and using Java programming interfaces.

Chapter 5 covers the powerful administrative scripting capabilities built into WebSphere Version 5. The wsadmin scripting program supports three operating modes, multiple languages, full extensibility, and complete access to all of the WebSphere Version 5 administration functions.

Chapter 6 delves into the details surrounding programmatic administration, such as writing your own custom management program, extending the Application Server administration system, and using the same Java administrative programming interfaces (APIs) as are used to build all of the other tools shipped with the product.

WebSphere Application Server Structure

Application Server Version 5 provides an entirely new packaging structure. Several installation images build on one another to incrementally expand the features available to you. Start with the base product installation, and then add features (e.g., extended programming model enhancements or multi-node network deployment capabilities) as you need them. The two basic packages are Base Application Server and Network Deployment.

The WebSphere Version 5 product for z/OS and OS/390 includes both packages, along with an interactive configuration wizard, called the Customization Dialog, with which the WebSphere for z/OS user can configure base application servers and add network deployment functions.

The Base Application Server Package

A Base WebSphere Application Server installation includes everything needed for a single Application Server instance. Additional server definitions can be logically grouped into nodes. A node can contain many servers, but cannot span multiple computer systems. A single computer system can have multiple nodes installed on it, each with multiple managed servers. For example, multiple nodes defined on a large multiuser enterprise server computer makes better use of the system resources, and can isolate projects from one another. Figure 1.1 depicts the base environment.

01fig01.gifFigure 1.1 Basic Application Server environment.

A limitation of this package on its own is that it does not support the coordination between Application Server instances. Administration is limited to a single server at a time. Although you can create new server definitions from the Base console, you cannot use the console that is running in one server to start, stop, or otherwise manage a different server. The Network Deployment package extends the Base Application Server with capabilities for multiprocess, multinode configuration and control.

The Network Deployment Package

A Network Deployment installation can support a network of computer systems that are configured to run collaborating instances of the Base Application Server installation. The Network Deployment package provides centralized administration and workload management for a set of nodes, referred to as a cell. A cell has a master administrative repository that stores the configuration data for all of the nodes in the cell. Figure 1.2 depicts multiple systems in a Network Deployment cell, and shows that a base server can be added to a Network Deployment cell.

01fig02.gifFigure 1.2 Network Deployment environment.

One computer system is designated as the central Deployment Manager machine onto which the Network Deployment package is installed. The central Deployment Manager program that is included in this package manages all of the nodes in the cell. Note that the same computer system that supports the Deployment Manager program can also support one or more federated Base Application Server nodes. The issue of whether or not to configure the Deployment Manager onto a separate computer system is more of a best practice concept pertinent to the subject of availability. For instance, large-scale customers such as those on z/OS enterprise servers might be unwilling to dedicate an entire logical partition (LPAR) to running the Deployment Manager alone. They might want to share system resources of that LPAR with other application server nodes. As with many aspects of Application Server Version 5, the choice of location for the Deployment Manager node and other application server nodes is one for each customer to make based on particular environment and operational policies.

To add a Base Application Server installation to the cell, run the addNode program on the base installation (the addNode program is fully described in Chapter 3 of this book). After this is completed, a separate node agent administrative server is created that serves as an intermediary between the application servers on the node and the Deployment Manager. Administrative logic that runs in the node agent keeps the configuration data for a node synchronized with the master configuration data for the cell.

Besides grouping servers into nodes, another logical grouping of servers is the cluster. A cluster can contain servers on different nodes. All of the servers in a cluster must have the identical application deployment configuration, because the purpose of a cluster is to define servers that collaborate for workload balancing and failover capabilities.

  • + Share This
  • 🔖 Save To Your Account