New: Application deployment improvements

New: Application deployment improvements

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

Console wizard simplifies updating deploying applications and modules
v6.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 applications, Preparing for application update settings, and Ways to update application files.

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
This action updates an application on multiple cluster members while providing continuous availability of the application.
See Enterprise application collection and Updating applications.

JSR-88 deployment support
We can install J2EE modules on an application server 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. 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.

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.x environment.
See Installable module versions.

Applications using new 6.0.x function are not supported on 5.x nodes
v6.x applications can only be installed on v6.x servers, or clusters containing only v6.x servers. The installation must be initiated from within a v6.x environment, such as the wsadmin client invoked within the v6.x installation.
A v6.x application is one that conforms to certain criteria, as described in Installable module versions.

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.x module may not be a V5.x target. When editing an application from a v6.x client, all editing functions are available for all versions of applications.
When editing a v6.x application from a V5.x client, the functions that are provided exclusively by WebSphere 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

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.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 WAS are described in Section 8.2 of the Java 2 Platform, Enterprise Edition (J2EE) specification, V1.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. WAS ignores applet-specific tags within manifest files.
See Installed optional packages.

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, one can choose to process the embedded configuration data, which automatically sets up the required configuration for the application.
See Assembling applications.

See Also

What is new in this release

Console wizard simplifies updating deploying applications and modules	v6.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 applications, Preparing for application update settings, and Ways to update application files.

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 This action updates an application on multiple cluster members while providing continuous availability of the application. See Enterprise application collection and Updating applications.

JSR-88 deployment support	We can install J2EE modules on an application server 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. 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.

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.x environment. See Installable module versions.

Applications using new 6.0.x function are not supported on 5.x nodes	v6.x applications can only be installed on v6.x servers, or clusters containing only v6.x servers. The installation must be initiated from within a v6.x environment, such as the wsadmin client invoked within the v6.x installation. A v6.x application is one that conforms to certain criteria, as described in Installable module versions.

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.x module may not be a V5.x target. When editing an application from a v6.x client, all editing functions are available for all versions of applications. When editing a v6.x application from a V5.x client, the functions that are provided exclusively by WebSphere 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

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.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 WAS are described in Section 8.2 of the Java 2 Platform, Enterprise Edition (J2EE) specification, V1.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. WAS ignores applet-specific tags within manifest files. See Installed optional packages.

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, one can choose to process the embedded configuration data, which automatically sets up the required configuration for the application. See Assembling applications.