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. V6.1 includes numerous improvements, but a couple of features are particularly exciting for clients who use administrative scripts:
| New in V6.1! indicates new features or changes implemented at the V6.1 level. Unmarked items are V6.0 improvements that apply also to V6.1, which should interest anyone migrating to V6.1 from V5.x. |
Deprecated and removed features describes features that are being replaced or removed in this or future releases.
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 that are running within the cell. When upgrading, there is no need to export the cell configuration and recreate it in a new cell.
Deploying applications is significantly easier and more efficient. Highlights include JSR-88 support, simplified EAR file configuration, administrative support as you migrate your applications, and ability to perform fine grained application updates. When updating an application, only the portion of the application code that actually changed needs to be presented to the system. The application management logic will calculate the minimum actions that the system needs to execute in order to update the application. Under certain circumstances the update can occur without stopping any portion of the running application.
Incremental cell upgrade has implications for installing and administering applications, as well as the functionality they are able to use.
The embedded messaging component of WebSphere Application Server that supports Java Messaging Service (JMS) has been redesigned to be significantly better integrated with the application server administration.
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.
The product 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.
The product installation program installs the binary system files that may be read-only. It also creates an initial profile, which is a run-time execution environment that includes configuration files, the default location for deployed applications, logs, and other data. All profiles on a machine can share the same system files, but do not change the system files.
Performance enhancements improve your ability to monitor applications and reduce their startup time.
Easier and more integrated Web server administration and proxy improvements are among the highlights.
| Migration instructions |
Migrate the V5.x Deployment Manager to V6.1 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 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 that are 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 Object Request Broker (ORB) custom property of which you should be aware. If running a mixed release cell with V6.1 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 V6.1, you can reset the property for a performance improvement. See Object Request Broker custom properties for details about this com.ibm.websphere.ObjectIDVersionCompatibility setting. |
| 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:
|
| Administering servers |
With WebSphere Application Server 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 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. |
| 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:
Not supported:
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. 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 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:
|
| 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 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 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 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. |
| 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 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 WebSphere Application Server are described in Section 8.2 of the 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. |
| 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 administrative 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. See Assembling applications. |
| Console wizard simplifies updating deployed applications and modules | V6.1 introduces
an administrative console wizard that can update deployed applications or
modules in the following ways:
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:
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. |
| Create clustered application servers from a template |
New in V6.1! When you create new application servers as part of a cluster, their attributes are based on a stored template. Previously, when you created new application servers as part of a cluster, their attributes were copied from one of the existing application servers in the cluster. Various existing application servers might have been configured differently. See Modifying cluster member templates using scripting. |
| 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 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, and 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 application server. Now you can modify the reload behavior of applications that already have been installed See Configuring J2EE applications and Configuring 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 administrative console. See Viewing deployment descriptors. 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 | New in V6.1! With this framework,
you can extend application management by plugging into various management
functionality enabled by this feature, including application installation,
uninstallation, update, and editing functions to perform additional validation
or configuration as necessary.
|
| 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:
|
| 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. |
| 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. |
| 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:
|
| Improved integration with WebSphere MQ for z/OS |
New in V6.1! 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. For more details, see WebSphere MQ server |
| Persist data objects in a file store |
New in V6.1! Now you can choose the message store type used by the messaging engine. It can store persistent data objects either in a database (data store) or a file system (file store). Using a file store brings better performance, easier configuration and management. For more information, see File stores. |
| Enforce consistent message ordering |
New in V6.1! 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. For more details, see Strict message ordering for bus destinations. |
| 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 |
| 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 application server. |
| 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 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 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, and Ways to update application files. |
| JMX Remote application programming interface (JSR 160) |
You can develop a Java Management Extensions (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 this product or other systems. For more information, see Creating a Java Management Extensions client program using the Java Management Extensions Remote application programming interface. |
| J2EE Connector Architecture (JCA 1.5) |
V6.1 supports the J2EE Connector Architecture (JCA) V1.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. |
| 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. |
| Greater platform consistency for administrative console |
New in V6.1! The administrative console now is based on the Integrated Solutions Console (ISC) framework. The administrative console page content remains familiar to what you are used to seeing for WebSphere Application Server. |
| 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 WebSphere Application Server or non-WebSphere Application Server systems. JSR 160 compliant RMI connector clients are supported in addition to the existing WAS RMI Connector. See Creating a Java Management Extensions client program using the Java Management Extensions Remote application programming interface. |
| 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 and 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 |
New in V6.1! Command assistance in the administrative 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 administrative console. See Accessing command assistance from the administrative console. |
| Cluster wizard |
New in V6.1! 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 application servers that you manage together as a way to balance workload. See Creating clusters. |
| Scripting enhancements for configuring applications | New in V6.1! Scripting enhancements
for application configuration include:
See Deploying applications using scripting. |
| Local and connected mode |
New in V6.1! 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. See the documentation for each scripting object, available from Using the wsadmin scripting objects. |
| Changed administrative console port number | The administrative console port number
has changed.
http://hostname:9090/admin // OLD ADDRESS |
| 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. |
| 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 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 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. |
| 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. |
| 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). |
| 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:
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 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. 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. |
| 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. |
| 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. |
| 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. |
| 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. |