WebSphere Application Server Network Deployment, Version 6.0.x   Operating Systems: AIX, HP-UX, Linux, Solaris, Windows
             [TIP: Focusing the table of contents and search results]

What is new for administrators

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

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

Deprecated and removed features describes features that are being replaced or removed in this or future releases.

Incremental cell upgrade for easier migration

Migration instructions

Migrate the V5.x Deployment Manager to Version 6.0.x before migrating the base nodes that comprise the cell. The Network Deployment 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 Version 6.0.x, the deployment manager has the capability to manage both Version 6.0.x and Version 5.x nodes. This allows a 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.

See Migrating from Network Deployment Version 5.x to a Version 6.0.x deployment manager for a description of incremental migration of a deployment manager. See Migrating a Version 5.x managed node to a Version 6.0.x managed node for a description of incremental migration of a managed node.

Improve performance after completing mixed cell upgrade

If your cluster members in a mixed release cell include Version 6.0.x clusters and older versions from 5.0 through 5.1.0, there is an Object Request Broker (ORB) custom property of which you should be aware. If running a mixed release cell with Version 6.0.x and V5.1.1 servers, you can disregard this note.

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 Version 6.0.x, you can reset the property for a performance improvement.

See Object Request Broker custom properties for details about this com.ibm.websphere.ObjectIDVersionCompatibility setting.

See Migrating a Version 5.x managed node to a Version 6.0.x managed node for additional guidance.

Version 5.x nodes can be added and removed from Version 6.0.x cells through indirect means

A Version 5.x node cannot be added to a Version 6.0.x cell. However, the same result can be obtained by first upgrading the node to Version 6.0.x before adding the node to the Version 6.0.x cell.

A Version 5.x node in a Version 6.0.x 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 WebSphere Application Server Version 6.0.x, 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 that are 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. For details, see Creating application servers .

There also are restrictions on creating clusters and cluster members.

For details, see Creating clusters .

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

Restrictions: There is a distinction between a pre-existing mixed cell environment and a newly created mixed cell environment. 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 you need to 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 application server, or a first cluster member for a new cluster.

Supported scenarios:
  • Existing 5.x application servers 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 application server.
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.

Version 6.0.x 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. For more information, see Managed object metadata .

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

The Websphere Application Server master configuration repository stores configuration documents for all the nodes in the cell. Configuration files stored in Version 6.0.x format are transformed into Version 5.x format for consumption by Version 5.x nodes in the cell.

For additional information, see Configuration documents .

Create backup configurations after upgrading nodes to Version 6.0.x

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 Version 6.0.x module may not be a Version 5.x target.

When editing an application from a Version 6.0.x client, all editing functions are available for all versions of applications. When editing a Version 6.0.x application from an Version 5.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 administrative 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 WebSphere Application Server. These templates are used when creating JDBC Provider and DataSource objects from the administrative 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 Version 6.0.x template file are supported on older node levels. When creating new JDBC Providers and DataSources on Version 5.x nodes, ensure that the template you are using is supported on the WebSphere Application Server 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 Version 6.0.x now contains '|", whereas in Version 5.x ':' is used. This change is reflected in the output for wsadmin clients.

For example, this is the output from a Version 5.x client:
wsadmin>  $AdminConfig list Cell
DefaultCellNetwork
   (cells/DefaultCellNetwork:cell.xml#Cell_1)
This is the output from a Version 6.0.x 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 Version 5.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 Version 6.0.x to contain more attributes compared to Version 5.x. The "$AdminConfig attributes type" command is not version specific. It lists all attributes available in Version 6.0.x for the type, even though the new attributes may not be used on a Version 5.x node.

JMX administrative programs are interoperable across Version 5.x and Version 6.0.x

Version 6.0.x implements JMX 1.2, while Version 5.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 Version 6.0.x 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 Version 5.x administrative client can call a Version 6.0.x deployment manager, node, or server. Similarly, a Version 6.0.x administrative client can call a Version 5.x node or server.

Instances of JMX classes new in Version 6.0.x cannot be passed back into Version 5.x. Problems usually are signaled by a particular exception. Also, note that you might see different exceptions from your Version 6.0.x and Version 5.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 application server. Prior to Version 6.0.x, 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 WebSphere Application Server are described in Section 8.2 of the Java 2 Platform, Enterprise Edition (J2EE) specification, Version 1.4 at http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf.

WebSphere Application Server supports using the manifest file manifest.mf in shared library .jar files and application .ear files. WebSphere Application Server does not support the Java 2 Platform Standard Edition (J2SE) specification for installed optional packages.

Installed Optional Package semantics used in the J2SE specification (http://java.sun.com/j2se/1.3/docs/guide/extensions/spec.html) primarily serve the applet environment. The product ignores applet-specific tags within manifest files.

See Installed optional packages .

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, Version 6.0.2 and later provides the administrative console Class Loader Viewer. Use the Class Loader Viewer to examine class loaders and the classes loaded by each class loader.
[Version 6.0.2] Restriction: The Class Loader Viewer is not available on the J9 Java virtual machine, which includes the AMD 64-bit platforms.

See Troubleshooting class loaders .

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.

See Assembling applications .

Console wizard simplifies updating deployed applications and modules
Version 6.0.x introduces an administrative 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, WebSphere Application Server 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 WebSphere Application Server 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 , and 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 administrative 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 application server without clusters, use Update and then save and synchronize the node instead. For a standalone application server, simply update and save.

See Enterprise application collection and Updating J2EE applications .

JSR-88 deployment support

You can install J2EE modules on an application server provided by WebSphere Application Server 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. WebSphere Application Server 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 Version 1.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 , and Ways to update application files .

System applications

System applications are J2EE enterprise applications that are central to a WebSphere Application Server 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 .

Deployment into mixed environments

Applications installed on 5.x nodes can be installed on 6.0.x nodes

A Version 5.x compatible application, one that can be installed on a Version 5.x installation, can be installed on any server or cluster. The client that initiates the installation may be either from a Version 5.x environment, or a Version 6.0.x environment.

See Installable J2EE module versions .

Applications using new 6.0.x function are not supported on 5.x nodes

Version 6.0.x applications can only be installed on Version 6.0.x servers, or clusters containing only Version 6.0.x servers. The installation must be initiated from within a Version 6.0.x environment, such as the wsadmin client invoked within the Version 6.0.x installation.

A Version 6.0.x 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 Version 6.0.x module may not be a Version 5.x target. When editing an application from a Version 6.0.x client, all editing functions are available for all versions of applications.

When editing a Version 6.0.x application from a Version 5.x client, the functions that are provided exclusively by the Version 6.0.x 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

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
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 Version 5.x and 6.0 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 6.0 nodes for backwards compatibility. For 6.0 nodes, you are encouraged to use the WebSphere default messaging provider.

The following J2EE resources have limitations on Version 5.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 Version 5.x node. For 6.0 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 6.0. 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 6.0 nodes or servers, but not on a Version 5.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 Version 5.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 Version 5.x node agent or application server.

Enhanced administrative infrastructure

Java Management Extensions (JMX 1.2)

For migration information, see Java Management Extensions V1.0 to Java Management Extensions V1.2 migration .

J2EE Management Specification (JSR 77)

The management layer of the Java Management Extensions (JMX) architecture uses an implementation of the distributed services specification (JSR-077), which is not yet part of the Java 2 platform, Enterprise Edition (J2EE) specification. The management layer defines how external management applications can interact with the underlying layers in terms of protocols, APIs, and so on. For more information, see Java Management Extensions (JMX) .

J2EE Deployment (JSR 88)

You can install J2EE modules on an application server provided by WebSphere Application Server 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. WebSphere Application Server 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 Version 1.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 , and Ways to update application files .

J2EE Connector Architecture (JCA 1.5)

Version 6.0.x supports the J2EE Connector Architecture (JCA) Version 1.5 specification, which provides new features such as the inbound resource adapter.

For more information, see Resource adapters .

Improved integration of embedded messaging

For information about embedded messaging and other messaging options, see Learning about messaging with WebSphere Application Server .

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.

For more information, see Commands for the AdminTask object .

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.

Changed administrative console port number
The administrative console port number has changed.
http://hostname:9090/admin        // OLD ADDRESS
http://hostname:9060/ibm/console  // NEW ADDRESS

See Using the administrative 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 Working with server configuration files .

Upgrade profiles individually

Profiles sharing the same system files may be upgraded (or rolled back) individually. Because the Version 6.0.x 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 application server 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 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 J2EE applications .

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 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 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 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 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, 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 administrative console to provide an easy, accessible, lightweight monitoring solution.

See Monitoring performance with Tivoli Performance Viewer (TPV) .

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 application servers 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 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. Version 6.0.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 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 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 servers from multi-broker replication domains to data replication domains .

Define administrative boundaries around server clusters

The product integrates an optional feature called node groups, which define a boundary for server cluster formation. Using 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 .

Two new server types are Generic Server and Web Server. A Web Server represents an 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 Web server model definition lets you manage a Web server configuration from the administrative console.

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 now can be configured from the administrative console. Previously the configuration file for these plug-ins had to be manually edited whenever configuration changes were required.




Related concepts
What is new in this release
Concept topic    

Terms of Use | Feedback

Last updated: Mar 8, 2007 8:14:28 PM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/welc_newadministrator.html

© Copyright IBM Corporation 2003, 2006. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)