What is new for administrators

What is new for administrators

+
Search Tips | Advanced Search

New features...

Command assistance in the console that maps administrative activities to wsadmin scripting commands.

An integrated development environment is provided for script development, as part of the Application Server Toolkit.

Incremental cell upgrade for easier migration
The V6.1.x deployment manager can manage both V6.1.x and V6.0.x nodes. This allows the cell to be upgraded to a new release one node at a time, with minimal impact to the applications running within the cell. When upgrading, there is no need to export the cell configuration and recreate it in a new cell.

More standard application deployment and management
Highlights include...

JSR-88 support
simplified EAR file configuration
administrative support as you migrate applications
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.

Deployment into mixed environments
Incremental cell upgrade has implications for installing and administering applications, as well as the functionality they are able to use.

Improved resource management
The embedded messaging component of WAS that supports JMS has been redesigned to be significantly better integrated with the appserver administration.

Enhanced administrative infrastructure
The J2EE 1.4 specification added several requirements for appserver 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)
JMX Remote application programming interface (JSR 160)
J2EE Connector Architecture (JCA 1.5)

Improved administrative clients
Features have been added to the console, scripting, and programmatic clients for administering the application serving environment.
See What is new for security specialists for improvements to administrative roles.

Improved installation and configuration
WAS directory structure and use of profiles separates the binary system files from the installation-specific configuration information, leading to easier installation, maintenance, and configuration management. Installation is simplified and faster with the introduction of profiles. Configurations can be managed independently from the product binary files.
The installation program installs the binary system files that can only be modified by product maintenance tools like product upgrade or PTF installer. After installation, you run the Profile Management tool 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.
WAS 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.

Improved monitoring and performance tuning
Performance enhancements improve your ability to monitor applications and reduce their startup time.

HTTP, edge, and application serving capability
Easier and more integrated Web server administration and proxy improvements are among the highlights.

Migration instructions

The ND node must always be at the highest release and fix level within a cell, to allow it to manage all nodes in the cell. In V6.1, the deployment manager has the capability to manage both V6.1 and V5.x nodes. This allows a cell to be upgraded to a new release one node at a time, with minimal impact to the applications running within the cell.

Improve performance after completing mixed cell upgrade

If your cluster members in a mixed release cell include V6.1 clusters and older versions from 5.0 through 5.1.0, there is an ORB custom property which you should be aware
com.ibm.websphere.ObjectIDVersionCompatibility

In appropriate cases, the migration program automatically sets a custom property for the ORB on the 6.0.x deployment manager, node agent, and servers in the cluster. After migrating the entire cell to V6.1, you can reset the property for a performance improvement.
If running a mixed release cell with V6.1 and V5.1.1 servers, you can disregard this note.

V5.x nodes can be added and removed from V6.1 cells through indirect means

A V5.x node cannot be added to a V6.1 cell. However, the same result can be obtained by first upgrading the node to V6.1 before adding the node to the V6.1 cell. A V5.x node in a V6.1 cell cannot be removed from the cell. The same result can be obtained in either of the following ways:

Upgrade node to 6.0.x, followed by removeNode, or
Uninstall the node, followed by cleanupNode on the dmgr

Administering servers

With WAS V6.1, you can now upgrade a portion of the nodes in a cell, while leaving others at the older release level. This means that, for a period of time, you may be administering servers that are at the current release and servers running the newer release in the same cell. Note that in this mixed environment, there are some restrictions on what you can do with servers at the older release level.
There also are restrictions on creating clusters and cluster members.

Existing 5.x servers and clusters can expanded with some restrictions

A pre-existing mixed cell environment is one whose deployment manager profile is created prior to V6.0.2
A newly created mixed cell environment is one whose deployment manager profile is created only after applying the V6.0.2 PTF or later.
For a pre-existing mixed cell environment, the default server templates that create a V5.x server are not available. Administrators must create a new V5.x server template from an existing V5.x server. You can use this template to create a new V5.x appserver, or a first cluster member for a new cluster.
Supported scenarios...

Existing 5.x appservers and JMS servers will continue to work.
Removing a server at any version level.
Adding a new 6.0.x member to a cluster, if the cluster already contains a 6.0.x member.
Adding a new 5.x member to a cluster if the cluster already contains a 5.x member.
Creating a new cluster, with 5.x server as first cluster member.
Converting a 5.x server to a cluster.
Creating a new 5.x appserver.

Not supported...

Creating new 5.x JMS server.
Adding a new 6.x member to a cluster, if the cluster does not already contain a 6.x member.
Adding a new 5.x member to a cluster, if the cluster does not already contain a 5.x member.

V6.1 JMS function does not require a JMS server. See the messaging section for details.

Nodes know their version and capabilities
Information about a node, such as operating system platform and product features, is maintained in the configuration repository in the form of properties. As product features are installed on a node, new property settings are added.
An administrator can query a node's capabilities.

6.0.x configuration files are transformed for consumption by 5.x nodes

The WAS master configuration repository stores configuration documents for all the nodes in the cell. Configuration files stored in V6.1 format are transformed into V5.x format for consumption by V5.x nodes in the cell.
For additional information, see Configuration documents.

Create backup configurations after upgrading nodes to V6.1

Suppose you create a backup configuration for a node, using the backupConfig tool. After upgrading the node, you cannot use the restoreConfig command to restore the configuration.
It is recommended that backups be created after upgrade so that they can be used to restore the upgraded nodes.

You can use 6.0.x administration to modify 5.x and 6.0.x applications

All applications may be updated via reinstallation, editing, or remapping modules to new targets. When remapping a module, the new target for a V6.1 module may not be a V5.x target. When editing an application from a V6.1 client, all editing functions are available for all versions of applications. When editing a V6.1 application from an V5.x client, the following functions are not available:

Map Message Destination References to Enterprise Beans
Binding J2CObjects to JNDI name
Binding J2CActivation to Destination JNDI name

Administrative clients display only relevant settings, and settings are validated against the node version

When displaying the properties for a node, node agent, or server, the console is aware of the version of the node on which the object resides, and will only display those properties that are valid for that version.
The wsadmin scripting client is also aware of the version of node on which a configuration object resides. An exception is thrown if you attempt to view or modify a property that is not valid for the version. A warning is logged if you attempt to show or modify a property that has been deprecated.

JDBC Provider and DataSource templates provided are at the 6.0.x level

A set of JDBC Provider and DataSource templates are provided for simplifying the creation of data access objects for database vendors supported by WAS. These templates are used when creating JDBC Provider and DataSource objects from the console, or from wsadmin using the createUsingTemplate command. The templates available are based on the version of your deployment manager. Not all templates available in the V6.1 template file are supported on older node levels. When creating new JDBC Providers and DataSources on V5.x nodes, ensure that the template you are using is supported on the WAS release level of your node.

Ensure you do not persist config IDs in your scripts

Due to changes in the allowed format for ObjectName, the config ID in V6.1 now contains '|", whereas in V5.x ':' is used. This change is reflected in the output for wsadmin clients. For example, this is the output from a V5.x client:
 wsadmin>  $AdminConfig list Cell
DefaultCellNetwork
   (cells/DefaultCellNetwork:cell.xml#Cell_1)
This is the output from a V6.1 client:
wsadmin>  $AdminConfig list Cell
DefaultCellNetwork     
   (cells/DefaultCellNetwork|cell.xml#Cell_1)
The delimiter change is not a problem because config IDs are generated dynamically. However, you should not persist a config ID.
When a V5.x client passes a config ID containing ':', it is automatically transformed into a config ID containing '|' by the JMX run time for upwards compatibility. Similarly, a reverse transformation is performed for backwards compatibility.

Be aware of deprecated or invalid attributes

A type may be enhanced in V6.1 to contain more attributes compared to V5.x. The "$AdminConfig attributes type" command is not version specific. It lists all attributes available in V6.1 for the type, even though the new attributes may not be used on a V5.x node.

JMX administrative programs are interoperable across V5.x and V6.1

V6.1 implements JMX 1.2, while V5.x implements JMX 1.1. Due to the evolution of the JMX specification, the serialization format for JMX objects, such as...
javax.management.ObjectName

...differs between the two specifications.
The V6.1 JMX run time has been enhanced to be aware of the version of the client with which it is communicating. It makes appropriate transformations on these incompatible serialized formats so as to allow the different version run times to communicate with each other. This makes it possible for a V5.x administrative client can call a V6.1 deployment manager, node, or server. Similarly, a V6.1 administrative client can call a V5.x node or server.
Instances of JMX classes new in V6.1 cannot be passed back into V5.x. Problems usually are signaled by a particular exception. Also, note that you might see different exceptions from your V6.1 and V5.x administrative programs.
For additional information, see Java Management Extensions interoperability.

Easier, more standard application deployment and management

Specify external class dependencies within J2EE application itself Installed optional packages enable applications to use the classes in .jar files without having to include them explicitly in a class path. An installed optional package declares one or more shared library .jar files in an application's manifest file. When the application is installed on a server or cluster, the classes represented by the shared libraries are loaded in the application's class loader, making the classes available to the application.
Installed optional packages expand the existing shared library capabilities of an appserver. Prior to V6.1, an administrator was required to associate a shared library to an application or server. Installed optional packages enable an administrator to declare a dependency in an application's manifest file to a shared library, with installed optional package elements listed in the manifest file, and automatically associate the application to the shared library. During application installation, the shared library ,jar file is added to the class path of the application class loader.
Installed optional packages used by WAS are described in Section 8.2 of the J2EE specification, V1.4
WAS supports using the manifest file manifest.mf in shared library .jar files and application .ear files. WAS does not support the Java 2 Platform Standard Edition specification for installed optional packages.
Installed Optional Package semantics used in the J2SE specification primarily serve the applet environment. WAS ignores applet-specific tags within manifest files.
Class Loader Viewer is added Class loaders find and load class files. For a deployed application to run properly, the class loaders that affect the application and its modules must be configured so that the application can find the files and resources that it needs. Diagnosing problems with class loaders can be complicated and time-consuming. To help you diagnose and fix problems more quickly, V6.0.2 and later provides the console Class Loader Viewer. Use the Class Loader Viewer to examine class loaders and the classes loaded by each class loader.
Simplified EAR file configuration In the past, users deployed an application and set up its required configuration in two separate steps. In this release, the companion Application Server Toolkit (AST) enables you to define the required configuration -- such as a data source -- as a part of the application. At deployment, you can choose to process the embedded configuration data, which automatically sets up the required configuration for the application.
Console wizard simplifies updating deployed applications and modules V6.1 introduces an console wizard that can update deployed applications or modules in the following ways:

Replace an entire application (.ear file)
Replace, add, or remove a single module (.war, EJB .jar, or connector .rar file)
Replace, add, or remove a single file
Replace, add and/or remove multiple files by uploading a compressed file

If the application is updated while it is running, WAS automatically stops the application or only its affected components as required, updates the application logic and restarts the stopped application or its components.
Previous versions of WAS only supported replacement of an entire application and always stopped and restarted the entire application for any change.
See...

Updating J2EE applications
Preparing for application update settings
Ways to update application files
Commands for the AdminApp object

Easier updates to applications deployed on clusters A new action, Rollout Update, sequentially updates an application installed on multiple cluster members across a cluster. After you update an application's files or configuration, use the rollout update option on the console enterprise applications page to install the application's updated files or configuration on all cluster members of a cluster on which the application is installed.
Rollout Update does the following for each cluster member in sequence:

Saves the updated application configuration
Stops all cluster members on a given node
Updates the application on the node by synchronizing the configuration
Restarts the stopped cluster members on that node

Use Rollout Update if the application is deployed on one or more clusters spread across multiple nodes. This action reduces the amount of time that any single cluster member is unavailable to serve requests to the smallest interval possible. Pending IIOP transactions will complete before a cluster member stops; in-flight HTTP and JMS transactions might be lost while the cluster member is stopping. For an appserver without clusters, use Update and then save and synchronize the node instead. For a standalone appserver, simply update and save.
See...

Enterprise application collection
Updating J2EE applications

Create clustered appservers from a template New in V6.1! When you create new appservers as part of a cluster, their attributes are based on a stored template. Previously, when you created new appservers as part of a cluster, their attributes were copied from one of the existing appservers in the cluster. Various existing appservers might have been configured differently.
JSR-88 deployment support You can install J2EE modules on an appserver provided by WAS using JSR-88, which defines standard APIs to enable deployment of J2EE applications and standalone modules to J2EE product platforms. WAS is a J2EE 1.4 specification-compliant platform that implements the JSR-88 APIs.
JSR-88 defines a contract between a tool provider and a platform that enables tools from multiple vendors to configure, deploy and manage applications on any J2EE product platform. The tool provider typically supplies software tools and an integrated development environment for developing and assembly of J2EE application modules. The J2EE platform provides application management functions that deploy, undeploy, start, stop, and otherwise manage J2EE applications.
The J2EE Deployment Specification V1.1 is part of the J2EE 1.4 Application Server Developer Release.
See also...

Install J2EE modules with JSR-88
Customize modules using DConfigBeans
Ways to update application files

More flexibility in when you modify application configurations New in V6.1! Now you can modify some deployment descriptor properties as you install the application onto the appserver. Now you can modify the reload behavior of applications that already have been installed
See...

Configure J2EE applications
Configure the use of class loaders by an application

Easier expansion of application files into installation directories New in V6.1! A new deployment option enables application deployers to specify access permissions for files within the application EAR file, making it easier to expand them in the installation directory as needed. As a security override, a node level attribute lets you define the most lenient file permission specified in the installation destination.
Ability to view deployed applications New in V6.1! After an application or module is installed on a server, you can view its deployment descriptor in the console.
You can obtain the inventory of contents in a deployed application. The information can be extracted from a deployed application using management APIs and displayed in the administrative clients.
Framework for managing deployable artifacts Provides additional validation or configuration of...

application installation
uninstallation
update
editing

...using...

J2EE (EAR, EJB-Jar, WAR, RAR), SAR
OSGI
Shared libraries
SI
Handlers, including Web services and channel framework

Applying maintenance is easier and more efficient A single installation of Update Installer for WebSphere Software V6.1 can be used to install maintenance to the following WebSphere software products:

IBM WAS V6.x
IBM WAS ND V6.x
IBM WAS - Express V6.x
IBM Application Client for WAS V6.x
Web server plug-ins for WAS V6.x
IBM WebSphere Extended Deployment V5.1.x
IBM HTTP Server V6.x
IBM WebSphere Process Server V6.0.x
IBM WebSphere Enterprise Service Bus V6.0.1.x

System applications System applications are J2EE enterprise applications that are central to a WAS product, such as the 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 WAS 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.

Deployment into mixed environments

Applications installed on 5.x nodes can be installed on 6.0.x nodes
A V5.x compatible application, one that can be installed on a V5.x installation, can be installed on any server or cluster. The client that initiates the installation may be either from a V5.x environment, or a V6.1 environment.
See Installable J2EE module versions.
Applications using new 6.0.x function are not supported on 5.x nodes
V6.1 applications can only be installed on V6.1 servers, or clusters containing only V6.1 servers. The installation must be initiated from within a V6.1 environment, such as the wsadmin client invoked within the V6.1 installation.
A V6.1 application is one that conforms to certain criteria, as described in Installable J2EE module versions.
You can use 6.0.x administration to modify 5.x and 6.0.x applications
All applications may be updated by reinstallation, editing, or remapping modules to new targets. When remapping a module, the new target for a V6.1 module may not be a V5.x target. When editing an application from a V6.1 client, all editing functions are available for all versions of applications. When editing a V6.1 application from a V5.x client, the functions that are provided exclusively by the V6.1 runtime are not available. They include:

Map Message Destination References to Enterprise Beans

Binding J2CObjects to JNDI name

Binding J2CActivation to Destination JNDI name

Improved resource management

Improved integration with WebSphere MQ for z/OS You can now add a WebSphere MQ for z/OS queue manager or queue sharing group as a member of a service integration bus, instead of linking to it as a foreign bus. This capability enables service integration applications to exchange messages with a WebSphere MQ messaging network.
Persist data objects in a file store Now you can choose the message store type used by the messaging engine as persistent data objects either in...

database (data store)
file system (file store)

Use a file store brings better performance, easier configuration and management.
Enforce consistent message ordering A destination can be configured so that all messages sent by the same producer to the destination are delivered in the order they were produced.
Default messaging provider The default messaging provider is installed and runs as part of WAS, and needs no further administration. It 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), which 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.
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 6.0 deployment manager. A 6.0 wsadmin client may only use the SOAP connector to connect to V5.x node agent or appserver.

Enhanced administrative infrastructure

Java Management Extensions (JMX 1.2) See Use administrative programs (JMX)
J2EE Management Specification (JSR 77) The management layer of the JMX architecture uses an implementation of the distributed services specification (JSR-077), which is not yet part of the J2EE specification. The management layer defines how external management applications can interact with the underlying layers in terms of protocols, APIs, and so on.
J2EE Deployment (JSR 88) You can install J2EE modules on an appserver provided by WAS using the J2EE Deployment API Specification (JSR-88). JSR-88 defines standard APIs to enable deployment of J2EE applications and standalone modules to J2EE product platforms. WAS is a J2EE 1.4 specification-compliant platform that implements the JSR-88 APIs.
JSR-88 defines a contract between a tool provider and a platform that enables tools from multiple vendors to configure, deploy and manage applications on any J2EE product platform. The tool provider typically supplies software tools and an integrated development environment for developing and assembly of J2EE application modules. The J2EE platform provides application management functions that deploy, undeploy, start, stop, and otherwise manage J2EE applications.
You can read about JSR-88 and APIs used to manage applications at...
http://java.sun.com/j2ee/tools/deployment/

The J2EE Deployment Specification V1.1 is available at...
http://java.sun.com/j2ee/tools/deployment/reference/docs/index.html

...as part of the J2EE 1.4 Application Server Developer Release.
See also...

Installing J2EE modules with JSR-88
Customizing modules using DConfigBeans
Ways to update application files

JMX Remote application programming interface (JSR 160) You can develop a JMX client program that is compliant with JMX Remote application programming interface (JSR 160). After you have a working JMX client program, you can use it to manage WAS or other systems.
J2EE Connector Architecture (JCA 1.5)
V6.1 supports the JCA V1.5 specification, which provides new features such as the inbound resource adapter.
Improved integration of embedded messaging

Improved administrative clients

Growing set of administrative commands Automation of administrative tasks is made easier through the AdminTask scripting object 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.
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.
Improved help with administrative commands 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.
Greater platform consistency for console New in V6.1! The console now is based on the Integrated Solutions Console (ISC) framework. The console page content remains familiar to what you are used to seeing for WAS.
JSR 160 support
New in V6.1! You can develop and build a JMX client program that is compliant with JMX Remote application programming interface (JSR 160). JSR 160 defines how JMX clients communicate with JMX servers. After you have a working JMX client program, you can use it to manage WAS or non-WAS systems. JSR 160 compliant RMI connector clients are supported in addition to the existing WAS RMI Connector.
JMX interoperability
New in V6.1! JMX interoperability is supported between 6.1 and back level nodes at V5.x or at Version 6.0.2 and later. Interoperability with V6.0.0 or 6.0.1 nodes is not supported. V6.0 supports JMX 1.2, while V5.x supports JMX 1.1. Interoperability between V6.1 or 6.0.2 nodes with 5.x nodes is supported only with the SOAP connector.
Improved wsadmin tracing configuration
New in V6.1! You can configure the wsadmin client side log file and audit each wsadmin session. The wsadmin.properties file includes new properties for specifying to append to a trace file and to name a default scripting interface.
See...

Tracing operations with the wsadmin tool
Administrative properties for scripting

wsadmin no longer case sensitive
New in V6.1! Commands and parameters for the wsadmin tool are not case sensitive. That is, wsadmin will an accept any of these arguments: –-tracefile, -traceFile, -traceFile, or tRaCEFile. wsadmin also infers the scripting language by looking at the suffix of the script file you specified on the command line.
Simplified administration Command assistance in the console maps your administrative activities to wsadmin scripting commands, so that you can capture your console knowledge and apply it to wsadmin. Using command assistance, you can view wsadmin scripting commands in the Jython language for the last action run in the console.
Cluster wizard A wizard guides you through the creation of clusters and cluster members. As part of the cluster member processing, a copy of the first cluster member that you create is stored as part of the cluster data and becomes the template for all additional cluster members that you create.
A cluster is a set of appservers that you manage together as a way to balance workload.
Scripting enhancements for configuring applications Scripting enhancements for application configuration include:

You can explicitly target an application module to multiple target servers and clusters, such as targeting an application to an appserver and to a Web server.

There is more flexibility in specifying step parameters, due to new wildcard usage that keeps you from having to know the details of application structure or deployment targets when manipulating bindings and deployment information. We needn’t know all of the step parameters and can specify only those that are required to configure the application artifact. You can specify data for multiple rows in a step, using a pattern such as .*war*

You now can add to or remove from the set of existing deployment targets rather without replacing them.

See Deploying applications using scripting.
Local and connected mode The administrative commands can be available in connected or local mode. The set of available administrative commands is determined when you start a scripting client in connected or local mode.
Changed console port number The console port number has changed.
http://hostname:9090/admin // OLD ADDRESS

See Use the console.

Improved installation and configuration

Administrators must now address commands to particular profiles
System administrators of multiple Application Server instances on a single machine should note the following change. System administration commands are now profile-specific. In previous releases, commands were executed from the bin directory of the product installation root. Now commands must be executed from a particular profile/bin directory. For example, use the -profileName parameter to identify which Application Server to start.
For various ways to address profiles, see Creating a deployment manager profile.
Profiles can be exported
You can propagate the configuration from one profile to another by exporting a profile to a configuration archive and importing it to another profile. This mechanism works between profiles of the same installation or different installations. A restriction is that this mechanism only works for an unfederated profile.
For more information, see Work with server configuration files.
Upgrade profiles individually
Profiles sharing the same system files may be upgraded (or rolled back) individually. Because the V6.1 binary images are installed at a different location, it is possible to upgrade each version 5 profile individually.
Directory structure changes
Files pertaining to a particular appserver runtime environment are in a directory path containing the word profiles, as well as the particular profile name.
Note also that the product installation root has changed to include IBM, as described in What is new for installers.

Improved monitoring and performance tuning

Improve the startup speed of 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 Configure J2EE applications.
Improvements in monitoring application flow Request Metrics, which allows you to trace response times for individual transactions through WAS, provides more instrumentation, including asynchronous beans, Web Services, and messaging resources, as described in Request metrics performance data.
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 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 Data you can collect with request metrics for additional information.
You can 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 Data you can collect with request metrics.
Request Metrics now supports IPv6 addressing. If requests 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 WAS, 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, you 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.
See Performance Monitoring Infrastructure (PMI).
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 console to provide an easy, accessible, lightweight monitoring solution.
Instrumentation improvements for monitoring and autonomic efforts New in V6.1! WebSphere Performance Monitoring Infrastructure (PMI) and Request Metrics help you answer questions such as:

What performance area should I focus on?

Is there too much time being spent on any given area?

How do I determine if response times for transactions are meeting my goals?

How can I validate my service level agreements are being met?

These features have been enhanced further. Performance Monitoring Infrastructure (PMI) now provides new counters for per-process CPU data and PMI data at the Struts/Tiles level for greater granularity. It also includes new transactional data for J2C and naming. Request Metrics provides new instrumentation for J2C, naming, JDBC, EJB, servlet, and JMS resources.

HTTP, edge, and application serving capability

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 appservers rather than on a dedicated one. 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 appserver environment and provides peer to peer failover of appserver components that are part of a core group. If an appserver component fails, the high availability manager takes over the in flight and in doubt work for the failed server. This action significantly improves appserver uptime. In a carefully planned environment, it can provide a 99.999% appserver availability expectancy rate.
All components of an environment managed by the high availability manager are members of a core group. V6.1 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.
Improved proxy server monitoring capabilities
New in V6.1! The proxy is instrumented for Application Response Measurement (ARM) so that supported autonomic managers can provide monitoring of web traffic flowing end-to-end through the various intermediaries in the enterprise.
See Monitor the proxy server with PMI.
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 consist 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.
See Core group transports.
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 you can create only data replication domains in the 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 servers from multi-broker replication domains to data replication domains.
Define administrative boundaries around server clusters
WAS integrates an optional feature called node groups, which define a boundary for server cluster formation.
Use node groups, you can cluster resources, and applications that use those resources, into a distinct partition within a cell. During the application install process, you 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 Creating server templates.
Administer Web servers from the appserver console
A Web server model definition lets you manage a Web server configuration from the console.
Easier and more integrated Web server administration New in V6.1! For easier initial configuration:

A more end-to-end IBM HTTP Server graphical installation interface helps you recognize and complete configuration steps that follow the installation.

Installing the plug-in that enables IBM HTTP Server to communicate with appservers now is part of installing IBM HTTP Server.

An IBM HTTP Server can be created on a standalone node and managed the same as a Web server on an unmanaged node. This means you can later federate the node containing the Web server and administer IBM HTTP Server through the node agent.

For easier configuration and administration:

A Web server configuration now is included in profile configuration, including the default profile.

You can modify the Web server definition to change to or from IBM HTTP Server without having to delete the definition and create a new one.

WAS console changes make it easier create and manage a key file with the IBM HTTP Server SSL configuration. However, note that changes the keyfile directory configuration in the administrative console will not automatically update the KEYFILE directive in the IBM HTTP Server configuration file.

In addition to improving IBM HTTP Server administration, limited support for administering Web servers other than IBM HTTP Server has been introduced into the console.

The Web servers collection page in the console has been improved to reduce misunderstandings and ease problem determination.

Web server installation root will be kept in variable.xml, including configuration file, log file, execution path, and working directory.

Scripts (bat or shell) are available for starting and stopping IBM HTTP Server.

Configure Web server plug-ins from the console
The Web server plug-ins that are used to forward HTTP requests from a supported Web server to an appserver now can be configured from the console. Previously the configuration file for these plug-ins had to be manually edited whenever configuration changes were required.
User space load balancer for Linux
New in V6.1! Administrators can load balance both IPv4 and IPv6 traffic with the new IPv6 support. The IPv6 support for the load balancer introduces a new install image that can be deployed by the administrator to route IPv4 and IPv6 traffic to servers in the clusters configured. The support is limited to the MAC based packet forwarding solution of the load balancer.
Improved name space configuration
New in V6.1! Indirect JNDI bindings and foreign cell bindings are improved. The indirect JNDI configured binding function now can be configured with an arbitrary initial context factory rather than always using the WebSphere initial context factory. The foreign cell bindings within the deployment manager now enable you to specify multiple bootstrap addresses.

Related concepts

Specify external class dependencies within J2EE application itself	Installed optional packages enable applications to use the classes in .jar files without having to include them explicitly in a class path. An installed optional package declares one or more shared library .jar files in an application's manifest file. When the application is installed on a server or cluster, the classes represented by the shared libraries are loaded in the application's class loader, making the classes available to the application. Installed optional packages expand the existing shared library capabilities of an appserver. Prior to V6.1, an administrator was required to associate a shared library to an application or server. Installed optional packages enable an administrator to declare a dependency in an application's manifest file to a shared library, with installed optional package elements listed in the manifest file, and automatically associate the application to the shared library. During application installation, the shared library ,jar file is added to the class path of the application class loader. Installed optional packages used by WAS are described in Section 8.2 of the J2EE specification, V1.4 WAS supports using the manifest file manifest.mf in shared library .jar files and application .ear files. WAS does not support the Java 2 Platform Standard Edition specification for installed optional packages. Installed Optional Package semantics used in the J2SE specification primarily serve the applet environment. WAS ignores applet-specific tags within manifest files.
Class Loader Viewer is added	Class loaders find and load class files. For a deployed application to run properly, the class loaders that affect the application and its modules must be configured so that the application can find the files and resources that it needs. Diagnosing problems with class loaders can be complicated and time-consuming. To help you diagnose and fix problems more quickly, V6.0.2 and later provides the console Class Loader Viewer. Use the Class Loader Viewer to examine class loaders and the classes loaded by each class loader.
Simplified EAR file configuration	In the past, users deployed an application and set up its required configuration in two separate steps. In this release, the companion Application Server Toolkit (AST) enables you to define the required configuration -- such as a data source -- as a part of the application. At deployment, you can choose to process the embedded configuration data, which automatically sets up the required configuration for the application.
Console wizard simplifies updating deployed applications and modules	V6.1 introduces an console wizard that can update deployed applications or modules in the following ways: Replace an entire application (.ear file) Replace, add, or remove a single module (.war, EJB .jar, or connector .rar file) Replace, add, or remove a single file Replace, add and/or remove multiple files by uploading a compressed file If the application is updated while it is running, WAS automatically stops the application or only its affected components as required, updates the application logic and restarts the stopped application or its components. Previous versions of WAS only supported replacement of an entire application and always stopped and restarted the entire application for any change. See... Updating J2EE applications Preparing for application update settings Ways to update application files Commands for the AdminApp object
Easier updates to applications deployed on clusters	A new action, Rollout Update, sequentially updates an application installed on multiple cluster members across a cluster. After you update an application's files or configuration, use the rollout update option on the console enterprise applications page to install the application's updated files or configuration on all cluster members of a cluster on which the application is installed. Rollout Update does the following for each cluster member in sequence: Saves the updated application configuration Stops all cluster members on a given node Updates the application on the node by synchronizing the configuration Restarts the stopped cluster members on that node Use Rollout Update if the application is deployed on one or more clusters spread across multiple nodes. This action reduces the amount of time that any single cluster member is unavailable to serve requests to the smallest interval possible. Pending IIOP transactions will complete before a cluster member stops; in-flight HTTP and JMS transactions might be lost while the cluster member is stopping. For an appserver without clusters, use Update and then save and synchronize the node instead. For a standalone appserver, simply update and save. See... Enterprise application collection Updating J2EE applications
Create clustered appservers from a template	New in V6.1! When you create new appservers as part of a cluster, their attributes are based on a stored template. Previously, when you created new appservers as part of a cluster, their attributes were copied from one of the existing appservers in the cluster. Various existing appservers might have been configured differently.
JSR-88 deployment support	You can install J2EE modules on an appserver provided by WAS using JSR-88, which defines standard APIs to enable deployment of J2EE applications and standalone modules to J2EE product platforms. WAS is a J2EE 1.4 specification-compliant platform that implements the JSR-88 APIs. JSR-88 defines a contract between a tool provider and a platform that enables tools from multiple vendors to configure, deploy and manage applications on any J2EE product platform. The tool provider typically supplies software tools and an integrated development environment for developing and assembly of J2EE application modules. The J2EE platform provides application management functions that deploy, undeploy, start, stop, and otherwise manage J2EE applications. The J2EE Deployment Specification V1.1 is part of the J2EE 1.4 Application Server Developer Release. See also... Install J2EE modules with JSR-88 Customize modules using DConfigBeans Ways to update application files
More flexibility in when you modify application configurations	New in V6.1! Now you can modify some deployment descriptor properties as you install the application onto the appserver. Now you can modify the reload behavior of applications that already have been installed See... Configure J2EE applications Configure the use of class loaders by an application
Easier expansion of application files into installation directories	New in V6.1! A new deployment option enables application deployers to specify access permissions for files within the application EAR file, making it easier to expand them in the installation directory as needed. As a security override, a node level attribute lets you define the most lenient file permission specified in the installation destination.
Ability to view deployed applications	New in V6.1! After an application or module is installed on a server, you can view its deployment descriptor in the console. You can obtain the inventory of contents in a deployed application. The information can be extracted from a deployed application using management APIs and displayed in the administrative clients.
Framework for managing deployable artifacts	Provides additional validation or configuration of... application installation uninstallation update editing ...using... J2EE (EAR, EJB-Jar, WAR, RAR), SAR OSGI Shared libraries SI Handlers, including Web services and channel framework
Applying maintenance is easier and more efficient	A single installation of Update Installer for WebSphere Software V6.1 can be used to install maintenance to the following WebSphere software products: IBM WAS V6.x IBM WAS ND V6.x IBM WAS - Express V6.x IBM Application Client for WAS V6.x Web server plug-ins for WAS V6.x IBM WebSphere Extended Deployment V5.1.x IBM HTTP Server V6.x IBM WebSphere Process Server V6.0.x IBM WebSphere Enterprise Service Bus V6.0.1.x
System applications	System applications are J2EE enterprise applications that are central to a WAS product, such as the 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 WAS 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.

Improved integration with WebSphere MQ for z/OS	You can now add a WebSphere MQ for z/OS queue manager or queue sharing group as a member of a service integration bus, instead of linking to it as a foreign bus. This capability enables service integration applications to exchange messages with a WebSphere MQ messaging network.
Persist data objects in a file store	Now you can choose the message store type used by the messaging engine as persistent data objects either in... database (data store) file system (file store) Use a file store brings better performance, easier configuration and management.
Enforce consistent message ordering	A destination can be configured so that all messages sent by the same producer to the destination are delivered in the order they were produced.
Default messaging provider	The default messaging provider is installed and runs as part of WAS, and needs no further administration. It 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), which 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.
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 6.0 deployment manager. A 6.0 wsadmin client may only use the SOAP connector to connect to V5.x node agent or appserver.

Java Management Extensions (JMX 1.2)	See Use administrative programs (JMX)
J2EE Management Specification (JSR 77)	The management layer of the JMX architecture uses an implementation of the distributed services specification (JSR-077), which is not yet part of the J2EE specification. The management layer defines how external management applications can interact with the underlying layers in terms of protocols, APIs, and so on.
J2EE Deployment (JSR 88)	You can install J2EE modules on an appserver provided by WAS using the J2EE Deployment API Specification (JSR-88). JSR-88 defines standard APIs to enable deployment of J2EE applications and standalone modules to J2EE product platforms. WAS is a J2EE 1.4 specification-compliant platform that implements the JSR-88 APIs. JSR-88 defines a contract between a tool provider and a platform that enables tools from multiple vendors to configure, deploy and manage applications on any J2EE product platform. The tool provider typically supplies software tools and an integrated development environment for developing and assembly of J2EE application modules. The J2EE platform provides application management functions that deploy, undeploy, start, stop, and otherwise manage J2EE applications. You can read about JSR-88 and APIs used to manage applications at... http://java.sun.com/j2ee/tools/deployment/ The J2EE Deployment Specification V1.1 is available at... http://java.sun.com/j2ee/tools/deployment/reference/docs/index.html ...as part of the J2EE 1.4 Application Server Developer Release. See also... Installing J2EE modules with JSR-88 Customizing modules using DConfigBeans Ways to update application files
JMX Remote application programming interface (JSR 160)	You can develop a JMX client program that is compliant with JMX Remote application programming interface (JSR 160). After you have a working JMX client program, you can use it to manage WAS or other systems.
J2EE Connector Architecture (JCA 1.5)	V6.1 supports the JCA V1.5 specification, which provides new features such as the inbound resource adapter.
Improved integration of embedded messaging

Growing set of administrative commands	Automation of administrative tasks is made easier through the AdminTask scripting object 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. 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.
Improved help with administrative commands	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.
Greater platform consistency for console	New in V6.1! The console now is based on the Integrated Solutions Console (ISC) framework. The console page content remains familiar to what you are used to seeing for WAS.
JSR 160 support	New in V6.1! You can develop and build a JMX client program that is compliant with JMX Remote application programming interface (JSR 160). JSR 160 defines how JMX clients communicate with JMX servers. After you have a working JMX client program, you can use it to manage WAS or non-WAS systems. JSR 160 compliant RMI connector clients are supported in addition to the existing WAS RMI Connector.
JMX interoperability	New in V6.1! JMX interoperability is supported between 6.1 and back level nodes at V5.x or at Version 6.0.2 and later. Interoperability with V6.0.0 or 6.0.1 nodes is not supported. V6.0 supports JMX 1.2, while V5.x supports JMX 1.1. Interoperability between V6.1 or 6.0.2 nodes with 5.x nodes is supported only with the SOAP connector.
Improved wsadmin tracing configuration	New in V6.1! You can configure the wsadmin client side log file and audit each wsadmin session. The wsadmin.properties file includes new properties for specifying to append to a trace file and to name a default scripting interface. See... Tracing operations with the wsadmin tool Administrative properties for scripting
wsadmin no longer case sensitive	New in V6.1! Commands and parameters for the wsadmin tool are not case sensitive. That is, wsadmin will an accept any of these arguments: –-tracefile, -traceFile, -traceFile, or tRaCEFile. wsadmin also infers the scripting language by looking at the suffix of the script file you specified on the command line.
Simplified administration	Command assistance in the console maps your administrative activities to wsadmin scripting commands, so that you can capture your console knowledge and apply it to wsadmin. Using command assistance, you can view wsadmin scripting commands in the Jython language for the last action run in the console.
Cluster wizard	A wizard guides you through the creation of clusters and cluster members. As part of the cluster member processing, a copy of the first cluster member that you create is stored as part of the cluster data and becomes the template for all additional cluster members that you create. A cluster is a set of appservers that you manage together as a way to balance workload.
Scripting enhancements for configuring applications	Scripting enhancements for application configuration include: You can explicitly target an application module to multiple target servers and clusters, such as targeting an application to an appserver and to a Web server. There is more flexibility in specifying step parameters, due to new wildcard usage that keeps you from having to know the details of application structure or deployment targets when manipulating bindings and deployment information. We needn’t know all of the step parameters and can specify only those that are required to configure the application artifact. You can specify data for multiple rows in a step, using a pattern such as .war You now can add to or remove from the set of existing deployment targets rather without replacing them. See Deploying applications using scripting.
Local and connected mode	The administrative commands can be available in connected or local mode. The set of available administrative commands is determined when you start a scripting client in connected or local mode.
Changed console port number	The console port number has changed. http://hostname:9090/admin // OLD ADDRESS See Use the console.

Administrators must now address commands to particular profiles	System administrators of multiple Application Server instances on a single machine should note the following change. System administration commands are now profile-specific. In previous releases, commands were executed from the bin directory of the product installation root. Now commands must be executed from a particular profile/bin directory. For example, use the -profileName parameter to identify which Application Server to start. For various ways to address profiles, see Creating a deployment manager profile.
Profiles can be exported	You can propagate the configuration from one profile to another by exporting a profile to a configuration archive and importing it to another profile. This mechanism works between profiles of the same installation or different installations. A restriction is that this mechanism only works for an unfederated profile. For more information, see Work with server configuration files.
Upgrade profiles individually	Profiles sharing the same system files may be upgraded (or rolled back) individually. Because the V6.1 binary images are installed at a different location, it is possible to upgrade each version 5 profile individually.
Directory structure changes	Files pertaining to a particular appserver runtime environment are in a directory path containing the word profiles, as well as the particular profile name. Note also that the product installation root has changed to include IBM, as described in What is new for installers.

Improve the startup speed of 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 Configure J2EE applications.
Improvements in monitoring application flow	Request Metrics, which allows you to trace response times for individual transactions through WAS, provides more instrumentation, including asynchronous beans, Web Services, and messaging resources, as described in Request metrics performance data. 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 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 Data you can collect with request metrics for additional information. You can 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 Data you can collect with request metrics. Request Metrics now supports IPv6 addressing. If requests 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 WAS, 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, you 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. See Performance Monitoring Infrastructure (PMI).
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 console to provide an easy, accessible, lightweight monitoring solution.
Instrumentation improvements for monitoring and autonomic efforts	New in V6.1! WebSphere Performance Monitoring Infrastructure (PMI) and Request Metrics help you answer questions such as: What performance area should I focus on? Is there too much time being spent on any given area? How do I determine if response times for transactions are meeting my goals? How can I validate my service level agreements are being met? These features have been enhanced further. Performance Monitoring Infrastructure (PMI) now provides new counters for per-process CPU data and PMI data at the Struts/Tiles level for greater granularity. It also includes new transactional data for J2C and naming. Request Metrics provides new instrumentation for J2C, naming, JDBC, EJB, servlet, and JMS resources.

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 appservers rather than on a dedicated one. 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 appserver environment and provides peer to peer failover of appserver components that are part of a core group. If an appserver component fails, the high availability manager takes over the in flight and in doubt work for the failed server. This action significantly improves appserver uptime. In a carefully planned environment, it can provide a 99.999% appserver availability expectancy rate. All components of an environment managed by the high availability manager are members of a core group. V6.1 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.
Improved proxy server monitoring capabilities	New in V6.1! The proxy is instrumented for Application Response Measurement (ARM) so that supported autonomic managers can provide monitoring of web traffic flowing end-to-end through the various intermediaries in the enterprise. See Monitor the proxy server with PMI.
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 consist 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. See Core group transports.
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 you can create only data replication domains in the 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 servers from multi-broker replication domains to data replication domains.
Define administrative boundaries around server clusters	WAS integrates an optional feature called node groups, which define a boundary for server cluster formation. Use node groups, you can cluster resources, and applications that use those resources, into a distinct partition within a cell. During the application install process, you 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 Creating server templates.
Administer Web servers from the appserver console	A Web server model definition lets you manage a Web server configuration from the console.
Easier and more integrated Web server administration	New in V6.1! For easier initial configuration: A more end-to-end IBM HTTP Server graphical installation interface helps you recognize and complete configuration steps that follow the installation. Installing the plug-in that enables IBM HTTP Server to communicate with appservers now is part of installing IBM HTTP Server. An IBM HTTP Server can be created on a standalone node and managed the same as a Web server on an unmanaged node. This means you can later federate the node containing the Web server and administer IBM HTTP Server through the node agent. For easier configuration and administration: A Web server configuration now is included in profile configuration, including the default profile. You can modify the Web server definition to change to or from IBM HTTP Server without having to delete the definition and create a new one. WAS console changes make it easier create and manage a key file with the IBM HTTP Server SSL configuration. However, note that changes the keyfile directory configuration in the administrative console will not automatically update the KEYFILE directive in the IBM HTTP Server configuration file. In addition to improving IBM HTTP Server administration, limited support for administering Web servers other than IBM HTTP Server has been introduced into the console. The Web servers collection page in the console has been improved to reduce misunderstandings and ease problem determination. Web server installation root will be kept in variable.xml, including configuration file, log file, execution path, and working directory. Scripts (bat or shell) are available for starting and stopping IBM HTTP Server.
Configure Web server plug-ins from the console	The Web server plug-ins that are used to forward HTTP requests from a supported Web server to an appserver now can be configured from the console. Previously the configuration file for these plug-ins had to be manually edited whenever configuration changes were required.
User space load balancer for Linux	New in V6.1! Administrators can load balance both IPv4 and IPv6 traffic with the new IPv6 support. The IPv6 support for the load balancer introduces a new install image that can be deployed by the administrator to route IPv4 and IPv6 traffic to servers in the clusters configured. The support is limited to the MAC based packet forwarding solution of the load balancer.
Improved name space configuration	New in V6.1! Indirect JNDI bindings and foreign cell bindings are improved. The indirect JNDI configured binding function now can be configured with an arbitrary initial context factory rather than always using the WebSphere initial context factory. The foreign cell bindings within the deployment manager now enable you to specify multiple bootstrap addresses.