IBM WebSphere Application Server V7 builds on top of the robust V6 implementation with important new features and enhancements, including many in the area of system administration. WebSphere Application Server administration is based on the JMX standard initially adopted in V5 and enhanced in subsequent releases. The main focus areas for the system administration feature set in V7 include ease of administration, scalability, and administrative automation. This series of articles offers a comprehensive view of system administration enhancements in WebSphere Application Server V7. This first article provides an overview of the major new system management features in V7. Subsequent articles will take a closer look at the details of specific individual features.
These articles assume familiarity with the WebSphere Application Server system management infrastructure, and focus primarily on managing the WebSphere topology. See Resources for more information.
This article provides an overview of these system administration features:
- Administrative agent
- Flexible management
- Business-level applications
- Properties-based configuration
- Java EE 5 deployment
- Fine-grained administrative authorization in administrative console
- Scripting enhancements
- Mixed version management
- Run time provisioning
If you use WebSphere Application Server (âbaseâ edition) or WebSphere Application Server - Express through Version 6.1, you are probably familiar with the concept of a standalone application server. As a self-contained entity, a standalone application server provides the platform on which applications run in an isolated environment. A standalone application server also houses all the necessary administration services for managing and configuring the server.
This standalone model, while useful, presents a set of challenges in terms of manageability. The first is the lack of complete lifecycle management capability. While users might log on to the application server remotely to manage applications or configure the server, they cannot remotely stop and restart the server. Second, users who run multiple standalone application servers on the same machine do not have a way to manage them together (and they might not have a need for a centrally managed topology, which is provided by WebSphere Application Server Network Deployment). Furthermore, with multiple standalone servers comes the cost of duplicate administration services in every server, which adds to the memory requirements as well as initialization time.
WebSphere Application Server V7 introduces a new optional management server, called the administrative agent (or admin agent), to address such challenges in these ways:
- Multiple standalone application servers can be registered with a single admin agent; once registered, the application servers are monitored and controlled via that one admin agent.
- The admin agent becomes the central point of entry for administering multiple standalone application servers on the same machine. This is especially significant for users that manage topologies containing a large number of standalone application servers on a single machine.
- The administrative services of the registered servers are consolidated into the admin agent, thus reducing the memory footprint from previously duplicated services.
- Management functions performed by the admin agent remain isolated between registered application servers, enabling the user to direct operations to a specific server within the set of servers being managed.
The admin agent is designed as an option to complement the WebSphere Application Server base topology, in which the standalone application server continues to serve the application requests. Only administrative services from the server are consolidated into the admin agent. For every WebSphere Application Server base profile registered with the admin agent, an administrative subsystem is created within the admin agent to represent the new administrative entry point for that profile.
Figure 1. Administrative agent
An administrator can connect to either the administrative subsystem in the admin agent or to the application server in the WebSphere Application Server base profile, as before, for managing the server. In latter case, the registered application server forwards the requests for administrative operations to the admin agent.
Unlike a node in a WebSphere Application Server Network Deployment cell, the configuration repository of a WebSphere Application Server base profile that is registered with an admin agent is not federated into a master repository. The administration services in the admin agent modify the configuration of the various registered base profiles directly. This also means the admin agent can only manage WebSphere Application Server base profiles running on the same machine.
WebSphere Application Server V7 introduces a new style of administration called flexible management, designed to facilitate administration of a large number of WebSphere Application Server base edition and Network Deployment topologies that might be geographically distributed. This new administration model, which is meant to complement the existing Network Deployment and base edition server topologies, introduces an asynchronous job queuing mechanism for invoking administrative operations.
In a WebSphere Application Server Network Deployment topology, a single deployment manager server is the administration entry point for a set of WebSphere Application Server nodes that it manages. The deployment manager maintains a master configuration repository that contains configuration information for all the managed nodes. Configuration changes can only be made in the master configuration repository and are subsequently synchronized with managed nodes. This model relies on tightly coupled reliable communication links between the deployment manager and its managed nodes. It is possible that such a communication model could pose challenges, as the Network Deployment topology is scaled up to have a large number of nodes that span across distant geographical locations and networks.
The flexible management model introduced in V7 addresses these scalability requirements with the introduction of the job manager. A single job manager can manage a large number of WebSphere Application Server base edition and Network Deployment topologies registered with it as managed nodes. In this model, rather than invoking administrative operations directly against standalone servers and deployment managers, they are instead submitted as administrative jobs to the job manager. These administrative jobs are then fetched by the managed nodes at predefined intervals. In V7, a job manager supports configuration and control (start/stop) operations for servers, clusters, and applications, as well as execution wsadmin scripts as administrative jobs.
The job submission process can be customized by specifying job activation or expiration time, recurring execution pattern, notification via e-mail upon job completion, and so on.
Figure 2. Flexible management
This new flexible administration model provides a number of benefits:
- The job manager is designed to complement the Network Deployment and base edition topologies. Existing nodes do not need to be reconfigured. A single job manager can manage hundreds of nodes and a given node can be managed by multiple job managers. unlike ownership of a managed node by the deployment manager in a Network Deployment topology.
- The topologies managed by a job manager maintain their autonomy, including their security configuration, and thus they can be directly managed using existing administrative processes, such as scripts or the administrative console.
- This model enables coordinated management actions across multiple managed nodes defined as a group.
- The asynchronous job submission model facilitates the management of nodes that are geographically dispersed and reachable only through low-bandwidth, high-latency networks.
Being an application server platform, WebSphere Application Server facilitates deployment, management, and operational support for applications. In WebSphere Application Server, an enterprise application is a configuration artifact created by installing a single Java EE EAR file. Thus, the definition of an application in WebSphere Application Server is very closely tied to the Java™ EE programming and packaging model. There are situations where this one-to-one correspondence between a Java EE package and an enterprise application definition could be inadequate. An application that serves a specific business purpose might typically consist of many related packages, including Java EE EAR files and library JAR files that Java EE components use. WebSphere Application Server V7 introduces a new concept called business-level applications for managing application artifacts independent of packaging or programming models.
A business-level application (BLA) is an application administration model that is intended to capture the entire definition of an application, as it makes sense to the business. BLA architecture defines an application composition that uses application contents (physical binaries) to run the application business logic. It does not represent or contain application binaries, and hence does not enforce a specific packaging or programming model. It is intended to provide a clean separation between the management of application binaries and the configuration of application contents to run in a specific target environment. Figure 3 shows a sample BLA composition.
Figure 3. Business-level application composition
In WebSphere Application Server V7, a BLA composition can consist of one or more Java EE EAR files and shared libraries that the Java EE applications depend on. A BLA definition provides operational semantics for its constituent parts. For example, a start operation invoked on a BLA results in starting all the enterprise applications and shared libraries defined in the BLA. Additionally, BLA architecture supports recursive composition by reference, facilitating hierarchical assembly of BLAs and individual deployed artifacts. This mechanism enables a BLA to be defined for a specific business purpose while letting it be included in many other compositions in its entirety in order to serve a broader purpose.
A BLA definition separates application binaries from their configuration within a specific deployed instance, thus facilitating reuse of application binaries across multiple application definitions. A single EAR file or a library JAR can be configured multiple times to be made part of one or more BLAs.
Through its extensible model of deployment, BLA architecture provides an important enhancement to WebSphere application deployment: shared library management. Enterprise applications in WebSphere Application Server often depend on external utility JARs that are shared by multiple applications. Previous versions of WebSphere Application Server did not include support for deploying and managing these shared library archives. Users needed to transfer library packages to the WebSphere nodes where they were used by applications running on that node. With the advent of BLAs, WebSphere Application Server manages and distributes shared library JARs just as it manages Java EE applications, greatly reducing the number of artifacts that administrators have to manage independently in the context of WebSphere applications.
Starting with WebSphere Application Server V5, WebSphere configuration parameters are stored in a set of configuration documents, most of which are in XML format. The contents of these documents are complex configuration objects that can be manipulated using administrative tools, such as wsadmin scripting or the administrative console. Administrators often prefer automating their administrative tasks using wsadmin scripting, which involves writing and testing complex Jacl or Jython script fragments. While the wsadmin scripting interface offers a comprehensive set of capabilities for WebSphere administration, it is common for only a small number of administrators in an enterprise to be conversant with it. As a result, administrators often build higher level frameworks that accept inputs in simpler formats so that users of these frameworks can avoid advanced wsadmin scripting components. A common example of this configuration model is the usage of the properties file. WebSphere Application Server administrators often write complex wsadmin scripts that read their input parameters from a properties file, or output their WebSphere configuration in a properties file. Developers or other administrators find it much easier to create, read, or manipulate these properties file that can in turn be fed to wsadmin-based automation frameworks.
WebSphere Application Server V7 provides an important administration feature called properties-based configuration, which simplifies the experience of automating administration. With this feature, administrators can extract a WebSphere configuration into a properties file that lists configuration parameters in a simple <property=value> format. The simple format of the extracted configuration makes it easy to read and manipulate. The properties file can also be fed back to WebSphere administration in order to apply its contents to an existing configuration.
The properties-based configuration feature is exposed via a set of administrative commands that can be executed through wsadmin scripting. Key features of properties-based configuration include:
- Ability to create or delete configuration artifacts, and to read or manipulate an existing configuration.
- Preview mode, whereby a report is generated indicating how data from a properties file will be applied to a WebSphere configuration without actually changing the configuration.
- Variable support, which enables values in the properties file to be defined as variables that can be resolved when the properties file is applied, thus facilitating reuse of a given properties file across multiple configurations.
Java EE 5 deployment
WebSphere Application Server V7 is a Java EE 5 compliant application server. It supports the deployment and management of Java EE 5 application artifacts, in addition to applications that comply with previous versions of the Java EE specification. Java EE 5 greatly simplifies the application development and deployment model by introducing annotation support in various specifications, including EJB 3.0 and Servlet 2.5. It also makes XML-based deployment descriptors optional for application packages. WebSphere Application Server administrative interfaces, such as the administrative console, scripting, and the JMX-based Java API set, have been enhanced in WebSphere Application Server V7 to accept Java EE 5 packages for deployment.
During Java EE application deployment, an administrator typically provides vendor-specific information about components and component references that are defined in the Java EE application deployment descriptors. In WebSphere Application Server, this information is commonly referred to as application bindings. In Java enterprise applications prior to Java EE 5, these WebSphere-specific bindings are stored in the application EAR file in .xmi files that require IBM-supplied programs to manipulate. Beginning with WebSphere Application Server V7, bindings for Java EE 5 applications are stored in XML and the schema for these binding documents are located in the $WAS_HOME/properties/schemas directory (WAS_HOME is the library containing WebSphere product files). Therefore, administrators can use either WebSphere-supplied programs, like the administrative console, or an XML editor of their choosing to generate and package application binding documents with Java EE 5 applications.
The WebSphere Application Server V7 runtime has been enhanced to choose smart defaults for various configuration parameters in Java EE 5 application bindings, thus making them optional during the deployment process. For instance, if a Java Naming and Directory Interface (JNDI) name is not specified for an Enterprise JavaBean™ (EJB) home during application deployment, then the application server chooses a default JNDI name when the EJB application is started. Choosing such defaults greatly reduces the amount of information that administrators must supply when installing applications.
For EJB 3.0 applications, it is not required to generate EJB client stubs during or prior to deployment. The necessary client stubs are generated and propagated dynamically when EJB methods are invoked by application clients.
Fine-grained administrative authorization in administrative console
WebSphere Application Server supports the definition of roles that authorize administrators to perform certain administrative operations. WebSphere Application Server V6.1 introduced a fine-grained model for administrative authorization, whereby an administrator can be granted authorization to manage only a subset of the WebSphere Application Server topology, such as one or more servers, clusters, applications, or nodes. This fine-grained administration capability was exposed via the wsadmin scripting interface.
In WebSphere Application Server V7, the administrative console has been enhanced to adapt to fine-grained administrative authorization. Various UI panels, action buttons, and links are displayed, depending on the privileges owned by the user logged into the console. For example, if the administrator is not authorized for the operator role to start or stop an application server, then the start and stop buttons will not be displayed in the administratorâs application server view on the console.
An important aspect of WebSphere administration is automating administrative operations. The wsadmin scripting interface introduced in Version 5 provides an extensive automation framework for managing WebSphere topologies using Jacl and Jython scripting languages. Both these scripting languages are supported in Version 7. In Version 7, wsadmin scripting offers many enhancements focused primarily on ease-of-use. One such enhancement is the introduction of the script library.
There is much to learn to use the rich set of capabilities offered through wsadmin scripting effectively. Several articles on WebSphere Application Server scripting have provided much information on the wsadmin feature set. However, administrators often prefer to work with existing scripts that either demonstrate best practices or work in various WebSphere configurations. WebSphere Application Server V7 ships with an extensive library of Jython scripts for automating common administrative operations. The library includes scripts for:
- Server management: Create/delete/start/stop servers or clusters, manipulate common server configuration properties.
- Security configuration: Create and manage users and groups, manage authorization groups.
- Resource configuration: Create and manage JDBC, J2C, JMS provides, and resources.
- Application management: Install and manage Java EE applications and business-level applications.
You can use these scripts as-is, or you can copy script fragments into your existing automation framework.
Mixed version management
In a WebSphere Application Server V7 Network Deployment topology, the deployment manager can manage WebSphere Application Server V7, V6.x, and V5.1.x nodes. The mixed version management feature was introduced in Version 6 and has now been enhanced to accommodate Version 7 nodes in a mixed version WebSphere topology. Additionally, the deployment manager in Version 7 can also manage nodes enhanced with Version 6.1 feature packs. This enables a WebSphere Application Server cell to be upgraded one node at a time, with minimal impact to the applications running on other nodes in the cell. Figure 4 shows a WebSphere cell that manages nodes at different versions and capabilities.
Figure 4. Mixed version management
Mixed version management begins with migrating the deployment manager profile to Version 7. The deployment manager must always be the first profile to be migrated to Version 7 and it must always be at highest release, fix, and feature level of any node within a cell so that it can manage all nodes in the cell regardless of their release level. Once the deployment manager has been upgraded to Version 7, all the nodes in the cell can stay unchanged at whatever release level they supported prior to the deployment manager upgrade. Individual nodes can be upgraded to Version 7 any time after the deployment manager has been upgraded.
Administrative tools, such as the administrative console or wsadmin scripting, have been enhanced to expose only those configuration parameters that are appropriate for a given version of a WebSphere node. This adapt-a-view model of administration was introduced in Version 6 and has been enhanced to accommodate Version 7 configuration. A cluster of application servers can contain members running any of the supported versions of WebSphere Application Server. Additionally, numerous validation checks have been put in place to ensure that you do not accidentally configure an application server or deploy applications in an environment where they can not be run. For example, a Java EE 5 application cannot be installed on a server or a cluster that runs a version of WebSphere Application Server prior to Version 7. An error is thrown if the administrator attempts to do so. Conversely, a new member running WebSphere Application Server V6 or V5 cannot be added to a cluster that already has a Java EE 5 application installed on it.
An existing mixed version management restriction that does not allow adding Version 5 nodes to a Version 6 deployment manager also applies to a Version 7 deployment manager.
Run time provisioning
WebSphere Application Server users are always looking for ways to run the application server even more efficiently by reducing the server startup time, as well as reducing memory consumed by the application server. In Version 6.1, the application server was re-architected by being divided into a set of run time components that together make up the application server. WebSphere Application Server V7 enhances the server run time componentization model to include dynamic run time provisioning by allowing only a subset of run time components to start when the application server starts up. The list of run time components needed by an application server is primarily influenced by the applications running on that server.
The application deployment process in WebSphere Application Server V7 has been enhanced to record dependencies between application components and run time components. When the application server starts up, it accumulates all the run time components that any application installed on that server requires and only starts those components that are necessary. For instance, if no application running on a given application server contains EJB modules, then the EJB container services are not started. This dynamic run time provisioning model helps improve startup time as well as memory consumption of the application server.
The dynamic provisioning feature in WebSphere Application Server V7 is turned off by default. To turn it on, select the Start components as needed checkbox in the application server detail view.
WebSphere Application Server V7 builds value on top of the JMX-based foundation put in place and enhanced by earlier versions of WebSphere Application Server. This article provided an overview of new system administration features introduced in this new version. Future articles in this series will explore individual system management capabilities in-depth. For example, future articles will cover:
- Administrative agent and flexible management topologies.
- How to set up and manage new administrative topologies.
- Business-level applications.
- Properties-based configuration.
- wsadmin scripting enhancements.
- WebSphere Application Server V7 Information Center
- Whatâs new in WebSphere Application Server V7
- System management for WebSphere Application Server V6, Part 1: Overview of system management enhancements
- IBM developerWorks WebSphere Application Server zone