What is new for administrators

This topic highlights what is new or changed in v6.x for users who are going to customize, administer, monitor, and tune production server environments. It also addresses administrators who are going to deploy and operate applications.

The biggest improvements and changes in system administration, monitoring, and tuning can be summarized as follows:

Changes to the default configuration
The

administrative console port number has changed. For additional information, see Using the administrative console

http://hostname:9090/admin                    // OLD ADDRESS
http://hostname:9060/ibm/console              // NEW ADDRESS

Incremental

cell upgrade for easier migration

The v6.x deployment manager can manage both v6.x and V5.x nodes. This allows the cell to be upgraded to a new release one node at a time, with minimal impact to the applications that are running within the cell.

For additional information, see New: Incremental cell upgrade.

Application deployment improvements

Deploying applications is significantly easier and more efficient. Highlights include JSR-88 support, simplified EAR file configuration, administrative support as you migrate your 5.x applications, and ability to perform fine grained application updates. When updating an application, only the portion of the application code that actually changed needs to be presented to the system. The application management logic will calculate the minimum actions that the system needs to execute in order to update the application. Under certain circumstances the update can occur without stopping any portion of the running application.

For additional information, see New: Application deployment improvements.

Enhanced administrative infrastructure, with J2EE 1.4

related changes

The J2EE 1.4 specification added several requirements for application server vendors to implement in support of administration. This revision of the J2EE specification adds requirements to support:

Java Management Extensions (JMX 1.2)
J2EE Management Specification (JSR 77)
J2EE Deployment (JSR 88)
J2EE Connector Architecture (JCA 1.5)

In addition to J2EE specification related administration features, the embedded messaging component of WAS that supports Java Messaging Service (JMS) has been redesigned to be significantly better integrated with the application server administration.

For additional information, see New: Enhanced administrative infrastructure through J2EE 1.4 related changes.

Growing set of administrative commands

Automation of administrative tasks in v6.x is made easier through the new AdminTask feature of wsadmin. Many of the more involved tasks for administration have been implemented using this new feature which supports interactive execution and combines many individual scripting commands into a single task oriented command.

A new wsadmin scripting object AdminTask is introduced in this release. Various AdminTask commands are implemented for important administrative scenarios such as server management, cluster management and resource management. AdminTask commands provide various user friendly and task oriented wsadmin commands. AdminTask commands may have multiple steps for some complicated administrative tasks similar to the wizard in the console. AdminTask commands are grouped based on their function areas.

Detailed help information for AdminTask commands and command groups is available through various AdminTask help commands. All AdminTask commands can be executed in interactive mode, which leads users step by step, interactively. At the end of execution, the corresponding AdminTask command is generated to help you learn the AdminTask command syntax.

For more information, see AdminTask object for scripted administration and Commands for the AdminTask object.

Improved installation and configuration,

with profiles

Installation of Application Servers is simplified and faster with the introduction of profiles. For administrators, configurations can be managed independently from the product binary files.

The installation program installs the binary system files that can only modified by product maintenance tools like product upgrade or PTF installer, and are not changed by end users. After installation, you run the Profile creation wizard to create profiles. Each profile is a run-time environment that includes configuration files, the default location for deployed applications, logs, and other data. All profiles on a machine share the system files, but do not change them.

The v6.x product installation program installs the binary system files that may be read-only. It also creates an initial profile, which is a run-time execution environment that includes configuration files, the default location for deployed applications, logs, and other data. All profiles on a machine can share the same system files, but do not change the system files.

For additional information, see New: Improved installation and configuration, with profiles.

Improved monitoring and performance tuning

Improve the startup speed of your applications and servers
Two new settings enable you to fine tune the startup speed of applications that are configured to start automatically when the server starts. A new starting weight setting lets you specify the order in which to start applications when the server starts. A new background application setting lets you specify whether an application must initialize fully before its server starts, or if the server can proceed without waiting for the application.
For more details, see Configuring an application.

Improvements in monitoring application flow
Request Metrics, which allows you to trace response times for individual transactions through WebSphere Application Server, provides more instrumentation, including asynchronous beans, Web Services, and messaging resources, as described in Viewing performance data from request metrics.
You can be more selective about what instrumentation is enabled. For example, if you want instrumentation data only for the Web container and JMS, select these data in the administrative console and the detailed instrumentation data are only generated for the components you select. The edge transactions are traced for the other components that are not specified for instrumentation. See Understanding the data that one can collect with request metrics for additional information.
Use filters to determine the transactions for which to record data. Request Metrics now includes filters for Web services and messaging resources, as described in Understanding the data that one can collect with request metrics.
Request Metrics now supports IPv6 addressing. If request originate from a client with IPv6 only address, filtering can be done based on the IPv6 address. Furthermore, if the server uses IPV6 addresses preferentially, the same will appear in the correlators generated by request metrics.

PMI improvements
The Performance Monitoring Infrastructure (PMI), which allows you to monitor the overall health of WebSphere Application Server, is now enabled out-of-the box. These monitoring APIs follow the J2EE 1.4 Performance Data Framework specification. Statistics can be enabled using predefined statistic sets or can be selected using the custom option. With the custom option, one can now enable and disable individual statistics. New additional PMI statistics such as messaging are provided. You also can add your own statistics using the PMI custom API.

Easier access to data about system health
The Tivoli Performance Viewer gives users graphical and chart views of the PMI data. This tool has now been integrated into the administrative console to provide an easy, accessible, lightweight monitoring solution.

Default messaging provider

Default messaging provider
The default messaging provider is installed and runs as part of WebSphere Application Server, and needs no further administration.
The default messaging provider is installed and runs as part of WebSphere Application Server, and is based on service integration technologies. The default messaging provider supports JMS 1.1 domain-independent interfaces (sometimes referred to as "unified" or "common" interfaces). This enables applications to use the same, common, interfaces for both point-to-point and publish/subscribe messaging. This also enables both point-to-point and publish/subscribe messaging within the same transaction. With JMS 1.1, this approach is recommended for new applications. The domain-specific interfaces are supported for backwards compatibility for applications developed to use domain-specific queue interfaces, as described in section 1.5 of the JMS 1.1 specification.
For more details, perform an information center search for
Using the default messaging provider

Even more administrative improvements!

System applications
System applications are J2EE enterprise applications that are central to a WAS product, such as the administrative console and file transfer application. System applications are no longer shown in the list of installed applications on the console Enterprise Applications page, to prevent users from accidentally stopping, updating or removing them.
Because system applications are an important part of a WebSphere Application Server product, system applications are deployed when the product is installed and are updated only through a product fix or upgrade. Users cannot change the metadata for system applications such as J2EE bindings or J2EE extensions. Metadata requiring a change must be updated through a product fix or upgrade.
For more information, refer to System applications.

Simplified replication configuration
There is a new type of replication domain that is based on the new high availability framework. By using data replication domains, you do not have to configure local, remote, and alternate replicators. Any replication domains that were created with a previous version of WebSphere Application Server might be multi-broker domains. Existing multi-broker domains remain functional, however, after you upgrade your deployment manager one can create only data replication domains in the administrative console. For improved performance and easier configuration, migrate any existing multi-broker domains to the new data replication domains.
For more information, refer to Migrating V6.0 servers from multi-broker replication domains to data replication domains.

High Availability Manager for eliminating single points of failure
The new high availability manager function is used to eliminate single points of failure. The high availability manager is responsible for running key services on available application servers rather than on a dedicated one (such as the deployment manager). It takes advantage of fault tolerant storage technologies such as NAS, which significantly lowers the cost and complexity of high availability configurations. It also offers hot standby and peer failover for critical services.
The high availability manager monitors the application server environment and provides peer to peer failover of application server components that are part of a core group. If an application server component fails, the high availability manager takes over the in flight and in doubt work for the failed server. This action significantly improves application server uptime. In a carefully planned environment, it can provide a 99.999% application server availability expectancy rate.
All components of an environment managed by the high availability manager are members of a core group. v6.x provides a default core group that is created when the product is installed. When new server instances are created, they are automatically added to this default core group. Additional core groups can be created. However for most environments, one core group is usually sufficient and additional core groups should not be added unless there is a specific need to do so. If your environment has more than one core group, use access point groups to enable the core groups to communicate with each other. The core groups that communicate can be in the same cell or in different cells.

Common networking service for all components
The new channel framework model provides a common networking service for all components, including IBM service integration technologies, WebSphere Secure Caching Proxy, and the high availability manager core group bridge service. This model consists of network protocol stacks or transport chains that are used for I/O operations within an Application Server environment. Transport chains consists of one or more types of channels, each of which supports a different type of I/O protocol, such as TCP, DCS or HTTP. Network ports can be shared among all of the channels within a chain. The channel framework function automatically distributes a request arriving on that port to the correct I/O protocol channel for processing.

You now can configure Web server plug-ins from the administrative console
The Web server plug-ins, that are used to forward HTTP requests from a supported Web server to an application server, can now be configured from the administrative console. Previously the configuration file for these plug-ins had to be manually edited whenever configuration changes were required.

Define administrative boundaries around server clusters
WebSphere Application Server v6.x integrates an optional feature called node groups, which define a boundary for server cluster formation. Using node groups, one can cluster resources, and applications that use those resources, into a distinct partition within a cell. During the application install process, one can enable the optional resource scope validation, which notifies you if you have assigned inaccessible Java 2 Platform, Enterprise Edition (J2EE) resources to an application.
For more information, see Node group.

New server templates for easier creation
Server management functionality is enhanced significantly in this release. This release introduces the server template functionality. Customers can create their customized server templates based on an existing server configuration and use them to create new servers. This provides customers a mechanism to propagate the server configuration within the same cell easily. Furthermore, customers can propagate the server configuration across the cell boundary by exporting a server configuration to a configuration archive then importing the archive to another cell.
For additional information, see Understanding server templates.
This release also introduces two new server types besides the existing Application Server: Generic Server and Web Server. A Web Server represents a IBM or non IBM web server, while a Generic Server type represents a generic Java or non Java server process.

Administer Web servers from the application server console
A new Web server model definition lets you manage a Web server configuration from the administrative console.

Most resource providers are available for 5.x and 6.0.x nodes
For the following J2EE resources used by applications, all functions are available for all scopes, including V5.x and 6.0.x nodes:

JDBC providers
Generic JMS providers
WebSphere embedded JMS providers
WebSphere MQ JMS providers
Mail providers
Resource environment providers
URL providers

The generic JMS provider is available for cell scope and Version 6.0.x nodes for backwards compatibility. For v6.x nodes, you are encouraged to use the WebSphere default messaging provider.
The following J2EE resources have limitations on V5.0.x nodes:

Resource adapters
The format of resource adapter configuration has been changed considerably to accommodate JCA 1.5 in J2EE 1.4. Both JCA 1.5 and JCA 1.0 resource adapters may be defined at the cell scope. However, JCA 1.5 adapters will not be available on a V5.x node. For v6.x nodes and servers, both JCA 1.5 and JCA 1.0 resources may be defined. For Version 5.x nodes and servers, only JCA 1.0 resource adapters may be defined.
WebSphere default message provider
The WebSphere Default Message Provider is new in v6.x. Its definitions may be created at the cell scope containing 6.0.x and 5.x nodes, but it will not be available on the Version 5.x nodes. Its definitions can be created on any v6.x nodes or servers, but not on a V5.x node or server.

The SOAP connector can be interoperated across 5.x and 6.0.x nodes, but RMI connector cannot
Cross release connector interopration is currently supported only by the SOAP connector. It is unsupported for RMI connector. A V5.x wsadmin client may only use the SOAP connector to connect to v6.x deployment manager. A v6.x wsadmin client may only use the SOAP connector to connect to V5.x node agent or application server.

Improve the startup speed of your applications and servers	Two new settings enable you to fine tune the startup speed of applications that are configured to start automatically when the server starts. A new starting weight setting lets you specify the order in which to start applications when the server starts. A new background application setting lets you specify whether an application must initialize fully before its server starts, or if the server can proceed without waiting for the application. For more details, see Configuring an application.

Improvements in monitoring application flow	Request Metrics, which allows you to trace response times for individual transactions through WebSphere Application Server, provides more instrumentation, including asynchronous beans, Web Services, and messaging resources, as described in Viewing performance data from request metrics. You can be more selective about what instrumentation is enabled. For example, if you want instrumentation data only for the Web container and JMS, select these data in the administrative console and the detailed instrumentation data are only generated for the components you select. The edge transactions are traced for the other components that are not specified for instrumentation. See Understanding the data that one can collect with request metrics for additional information. Use filters to determine the transactions for which to record data. Request Metrics now includes filters for Web services and messaging resources, as described in Understanding the data that one can collect with request metrics. Request Metrics now supports IPv6 addressing. If request originate from a client with IPv6 only address, filtering can be done based on the IPv6 address. Furthermore, if the server uses IPV6 addresses preferentially, the same will appear in the correlators generated by request metrics.

PMI improvements	The Performance Monitoring Infrastructure (PMI), which allows you to monitor the overall health of WebSphere Application Server, is now enabled out-of-the box. These monitoring APIs follow the J2EE 1.4 Performance Data Framework specification. Statistics can be enabled using predefined statistic sets or can be selected using the custom option. With the custom option, one can now enable and disable individual statistics. New additional PMI statistics such as messaging are provided. You also can add your own statistics using the PMI custom API.

Easier access to data about system health	The Tivoli Performance Viewer gives users graphical and chart views of the PMI data. This tool has now been integrated into the administrative console to provide an easy, accessible, lightweight monitoring solution.

System applications	System applications are J2EE enterprise applications that are central to a WAS product, such as the administrative console and file transfer application. System applications are no longer shown in the list of installed applications on the console Enterprise Applications page, to prevent users from accidentally stopping, updating or removing them. Because system applications are an important part of a WebSphere Application Server product, system applications are deployed when the product is installed and are updated only through a product fix or upgrade. Users cannot change the metadata for system applications such as J2EE bindings or J2EE extensions. Metadata requiring a change must be updated through a product fix or upgrade. For more information, refer to System applications.

Simplified replication configuration	There is a new type of replication domain that is based on the new high availability framework. By using data replication domains, you do not have to configure local, remote, and alternate replicators. Any replication domains that were created with a previous version of WebSphere Application Server might be multi-broker domains. Existing multi-broker domains remain functional, however, after you upgrade your deployment manager one can create only data replication domains in the administrative console. For improved performance and easier configuration, migrate any existing multi-broker domains to the new data replication domains. For more information, refer to Migrating V6.0 servers from multi-broker replication domains to data replication domains.

High Availability Manager for eliminating single points of failure	The new high availability manager function is used to eliminate single points of failure. The high availability manager is responsible for running key services on available application servers rather than on a dedicated one (such as the deployment manager). It takes advantage of fault tolerant storage technologies such as NAS, which significantly lowers the cost and complexity of high availability configurations. It also offers hot standby and peer failover for critical services. The high availability manager monitors the application server environment and provides peer to peer failover of application server components that are part of a core group. If an application server component fails, the high availability manager takes over the in flight and in doubt work for the failed server. This action significantly improves application server uptime. In a carefully planned environment, it can provide a 99.999% application server availability expectancy rate. All components of an environment managed by the high availability manager are members of a core group. v6.x provides a default core group that is created when the product is installed. When new server instances are created, they are automatically added to this default core group. Additional core groups can be created. However for most environments, one core group is usually sufficient and additional core groups should not be added unless there is a specific need to do so. If your environment has more than one core group, use access point groups to enable the core groups to communicate with each other. The core groups that communicate can be in the same cell or in different cells.

Common networking service for all components	The new channel framework model provides a common networking service for all components, including IBM service integration technologies, WebSphere Secure Caching Proxy, and the high availability manager core group bridge service. This model consists of network protocol stacks or transport chains that are used for I/O operations within an Application Server environment. Transport chains consists of one or more types of channels, each of which supports a different type of I/O protocol, such as TCP, DCS or HTTP. Network ports can be shared among all of the channels within a chain. The channel framework function automatically distributes a request arriving on that port to the correct I/O protocol channel for processing.

You now can configure Web server plug-ins from the administrative console	The Web server plug-ins, that are used to forward HTTP requests from a supported Web server to an application server, can now be configured from the administrative console. Previously the configuration file for these plug-ins had to be manually edited whenever configuration changes were required.

Define administrative boundaries around server clusters	WebSphere Application Server v6.x integrates an optional feature called node groups, which define a boundary for server cluster formation. Using node groups, one can cluster resources, and applications that use those resources, into a distinct partition within a cell. During the application install process, one can enable the optional resource scope validation, which notifies you if you have assigned inaccessible Java 2 Platform, Enterprise Edition (J2EE) resources to an application. For more information, see Node group.

New server templates for easier creation	Server management functionality is enhanced significantly in this release. This release introduces the server template functionality. Customers can create their customized server templates based on an existing server configuration and use them to create new servers. This provides customers a mechanism to propagate the server configuration within the same cell easily. Furthermore, customers can propagate the server configuration across the cell boundary by exporting a server configuration to a configuration archive then importing the archive to another cell. For additional information, see Understanding server templates. This release also introduces two new server types besides the existing Application Server: Generic Server and Web Server. A Web Server represents a IBM or non IBM web server, while a Generic Server type represents a generic Java or non Java server process.

Administer Web servers from the application server console	A new Web server model definition lets you manage a Web server configuration from the administrative console.

Most resource providers are available for 5.x and 6.0.x nodes	For the following J2EE resources used by applications, all functions are available for all scopes, including V5.x and 6.0.x nodes: JDBC providers Generic JMS providers WebSphere embedded JMS providers WebSphere MQ JMS providers Mail providers Resource environment providers URL providers The generic JMS provider is available for cell scope and Version 6.0.x nodes for backwards compatibility. For v6.x nodes, you are encouraged to use the WebSphere default messaging provider. The following J2EE resources have limitations on V5.0.x nodes: Resource adapters The format of resource adapter configuration has been changed considerably to accommodate JCA 1.5 in J2EE 1.4. Both JCA 1.5 and JCA 1.0 resource adapters may be defined at the cell scope. However, JCA 1.5 adapters will not be available on a V5.x node. For v6.x nodes and servers, both JCA 1.5 and JCA 1.0 resources may be defined. For Version 5.x nodes and servers, only JCA 1.0 resource adapters may be defined. WebSphere default message provider The WebSphere Default Message Provider is new in v6.x. Its definitions may be created at the cell scope containing 6.0.x and 5.x nodes, but it will not be available on the Version 5.x nodes. Its definitions can be created on any v6.x nodes or servers, but not on a V5.x node or server.

The SOAP connector can be interoperated across 5.x and 6.0.x nodes, but RMI connector cannot	Cross release connector interopration is currently supported only by the SOAP connector. It is unsupported for RMI connector. A V5.x wsadmin client may only use the SOAP connector to connect to v6.x deployment manager. A v6.x wsadmin client may only use the SOAP connector to connect to V5.x node agent or application server.