Following is a new feature for WebSphere Extended Deployment Version 6.0.2:
Support for WebSphere Extended Deployment 6.0.2 on WebSphere Application Server 6.0.2 and 6.1. | WebSphere Extended Deployment Version 6.0.2 is now supported on WebSphere Application Server Network Deployment Version 6.1 See Preparing WebSphere Application Server Network Deployment to install the product for more information. |
Following is a list of new features for WebSphere Extended Deployment Version 6.0.1:
New custom properties | Several new custom properties
can change the behavior of application placement in your configuration:
|
Changes to the dynamic cluster creation wizard | The displayed templates are valid for the platform that corresponds to the node group platform that is bounding your dynamic cluster. |
Changes to HTTP session rebalancing function | The HTTP session rebalancing function is different from WebSphere Extended Deployment Version 6.0. The dynamic workload manager (DWLM) performs the session rebalancing function. Integration to DWLM allows rebalancing for weight change in addition to server startup. See HTTP session rebalancing for more information. |
Interaction with the business grid controller | Several situations exist where the typical health management behavior is different for long-running applications. See Health management and grid work for more information. |
Extends the monitoring of WebSphere Extended Deployment to the database tier. | The Visualization component can now be configured to monitor the database nodes and detect performance bottlenecks in the database tier. For more information about the capabilities of the database tier optimization, see Optimizing the database tier for performance monitoring . |
Following is a list of new features for WebSphere Extended Deployment Version 6.0:
One autonomic request flow manager per cell | The previous version of WebSphere Extended Deployment had one autonomic request flow manager for each node. In Version 6.0, there is one autonomic request flow manager for each cell. To access autonomic request flow manager settings in Version 6.0, click Operational Policies > Autonomic Managers > Autonomic Request Flow Manager. |
Manage software other than WebSphere Application Server and machines that do not run a WebSphere Application Server node agent | Using WebSphere Extended Deployment for a mixed server environment, a remote agent can report node information to the autonomic request flow manager. Use generic server clusters to specify the host information for external machines. See Routing requests to external nodes with generic server clusters for more information. |
Autonomic request flow manager improvements |
|
Emergency throttling | Gateways in the autonomic request flow manager are equipped with emergency throttle controllers that can control and safeguard request dispatch rates to backend notes when overload conditions occur. These overload situations include extremely high node utilization, intermittent communication failures between ARFM controller and request scheduling gateways, and intermittent communication failures between AsyncPMI monitoring data producers and the gateways. See Configuring emergency throttle for more information. |
Work factor overrides | There is a new way to specify work factor overrides. The old way depends on a feature that is being deprecated: direct and explicit descriptions of transaction classes. See Overriding work factor estimates for more information. |
Vertical stacking | Vertical stacking improves bottleneck conditions by enabling the application placement controller to start more than one instance of the dynamic cluster on a node. See Configuring vertical stacking for more information. |
Session rebalancing | Dynamically and actively balance the distribution of HTTP sessions among application servers. See HTTP session rebalancing for more information. |
Application lazy start | If you have an environment where the ratio of the number of dynamic clusters is high and where many dynamic clusters are not accessed for long periods of time, consider enabling application lazy start. A lazy start is the activation of the first application server instance of a deactivated dynamic cluster upon arrival of an application request. You decide which applications can be deactivated, and subsequently lazily started. By temporarily deactivating idle dynamic clusters, the resources can be used by other active clusters. |
One application placement controller per cell | The previous version of WebSphere Extended Deployment had one application placement controller per node. In Version 6.0, there is one application placement controller for each cell. To access application placement controller settings in Version 6.0, click Operational Policies > Autonomic Managers > Application Placement Controller. |
IBM Enterprise Workload Manager | IBM Enterprise Workload manager can receive Application Response Measurement (ARM) calls from the on demand router. IBM Enterprise Workload Manager can use the response time information to monitor the environment both inside and outside of the WebSphere Extended Deployment domain. See Enabling the on demand router to work with IBM Enterprise Workload Manager for more information. |
Support additional health policies and reactions | See Health management for more information. |
Manage health policies with scripting | See healthpolicy.py script for more information. |
Support for new long-running applications and jobs | A long-running application is a Java 2 Platform, Enterprise Edition (J2EE) application that conforms to one of the long-running programming models. Long-running work is expressed as jobs. See Long-running applications, jobs, and job definitions for more information. |
Batch and compute-intensive programming models | Compute-intensive applications are applications that perform computationally-intensive work that does not fit comfortably into the traditional Java 2 Platform Enterprise Edition (J2EE) request / response paradigm. See The compute-intensive programming model for more information. |
Policy-driven autonomic management of long-running applications and jobs | WebSphere Extended Deployment provides a number of mechanisms that are used to submit and manage the execution of long-running jobs. See Managing Compute Grid jobs and their environment for more information. |
Policy-driven integration of long-running and transactional work | Long-running applications are packaged and deployed as Java 2 Platform Enterprise Edition (J2EE) Enterprise Archive (EAR) files. See Deploying Compute Grid applications for more information. |
Provides capabilities to the WebSphere Extended Deployment environment for managing interruption-free production application deployment. | Interruption-free means users of your application experience no loss of service when you install an application update in your environment. See the Application edition manager section for more information. |
Improves administrative error correction through configuration repository mechanisms. | The scale-out administration support delivers key functions in support of large configurations, including the high availability deployment manager and the checkpoint / restore functions. See the Configuring a high availability deployment manager environment and Configuring a checkpoint for more information. |
Provides a fabric to the WebSphere Extended Deployment environment for managing Java objects. | The ObjectGrid consists of a transactional distributed shared memory that you can scale horizontally. With ObjectGrid, you can cache hundreds of gigabytes of data in a grid that can consist of 32 bit or 64 bit machines. For more information about the capabilities of ObjectGrid, see ObjectGrid . To get started with ObjectGrid applications, see Getting started with ObjectGrid by running the sample application . |