WebSphere Extended Deployment, Version 6.0.x
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


Edition manager concepts

With the application edition manager, you can manage different versions and editions of your application. This topic describes the difference between application edition manager versions and editions, the methods of upgrading your application, and edition validation and compatibility.

Versions and editions

A version is a successive generation of an interface, function, implementation, or entire application, and so forth. Version is a development and build concept. An edition is a successive deployment generation, for example the deployment of a particular set of versioned artifacts. Edition is a deployment and operational concept. These terms distinguish between what occurs in your development and build environment from what occurs in your deployment and operational environment.

Application continuous availability

Many business applications require constant availability. The standard for application availability asserts that applications are deployed on application server clusters. The redundancy of a cluster is essential to provide continuous availability.

Interruption-free application upgrade

Interruption-free application upgrade refers to the ability to upgrade while maintaining application continuous availability. Users of the application experience no loss of service during the application upgrade.

Application edition

An application edition is a unique deployment of a particular application. In the WebSphere Application Server administrative environment, an application edition is an application that is uniquely identified by the combination of an application name and an edition name. Multiple editions of the same application have the same application name, but different edition names. The edition name can be numeric, such as 1.0 or 2.0, or it can be descriptive, such as first edition or blue edition.

Base edition

Base edition refers to a deployed application that has no associated edition information. For example, applications that are installed before you add the edition manager support to your WebSphere Extended Deployment cell display in the edition manager as base editions.

Edition activation

Edition activation distinguishes between two states in which an application edition might exist. When an edition is first installed, it is in the inactive state. An inactive edition cannot be started. An explicit action is required to place an edition in the active state. An edition in the active state can be started. The transition from inactive to active is known as activation.

Concurrent activation

Concurrent activation is when multiple editions of the same application are active and started simultaneously. Concurrently active editions can provide some users with access to one edition and other users with access to another. For example, if you introduce a new edition of an application, you might want a select group of users to test it, but not want all users to have access to it. With concurrent activation, you must establish a routing policy to distinguish which users have access to an edition. A routing policy prevents ambiguity and determines which edition receives control. Following is an example diagram of concurrent activation.

Routing policy

WebSphere Extended Deployment provides routing policies for applications. A routing policy is stored as part of an application's configuration metadata. With a routing policy you can express rules that instruct the on demand router (ODR) to send particular application requests to one edition or another based on a set of criteria. You can use various criteria that specify which requests are sent to a particular application edition. This makes it possible to send requests from certain users to one edition and requests from other users to another edition.

Edition rollout

Edition rollout refers to deploying and activating an application edition across a server cluster. To provide interruption-free application upgrades, application rollout includes quiescing requests for the application in a particular server, fencing that server from receiving new requests, stopping the currently active edition, starting the new edition, and resuming the flow of requests to the edition. Edition rollout across a server cluster performs these activities across the set of the servers that are in that cluster.

Group rollout

With Group rollout, the target cluster is divided into groups for roll out. Group rollout is effective when the cluster is large. You define a group size, which specifies the number of nodes to process at a time. Group rollout results in the servers in each group being upgraded to the new edition at the same time. Each server in the group is quiesced, drained, stopped, and reset. Only one group can be rolled out at a time with the administrative console. Alternatively, you can use scripts to roll out multiple groups. When any member in the new edition becomes available, all requests are routed to the new edition.

As the edition rollout occurs, some servers in the cluster move from the old edition to the new edition, some servers are making the transition, and other servers have not started the transition. All application requests are sent to any server that has an active, running instance of the latest edition of the requested application. For example, when you roll out from edition 1.0 to 1.1, the moment that edition 1.1 becomes available on a server, all application requests are served by edition 1.1. Any servers that are still running edition 1.0 do not serve requests until this server is updated to edition 1.1.

Following is an example diagram of group rollout.

Group rollout diagram

Atomic rollout

The atomic rollout option replaces an edition on half of the cluster at a time to serve all user requests with a consistent edition of the application. At any point in time, all user requests are served by either the old or the new edition; user requests are never served by either edition.

Atomic rollout ensures that all application requests are served by a consistent edition, for example, either edition 1.0 or 1.1, but not by both. The currently available edition is taken offline in half of the servers that comprise the cluster. In those servers, the new edition is activated and started, but those servers are held offline until the next step completes. The next step is to take the currently active edition offline in the remaining servers. At this point, no server has an instance of either edition available to serve application requests. At this moment in time, the ODR temporarily queues any request that arrives for this application. After the application is fully offline, the first half of the cluster is brought back online. The second half of the cluster transitions from the previous edition to the next edition and is brought back online.

Following is an example diagram of atomic rollout.

Atomic rollout diagram

Edition validation

Edition validation refers to a special case of concurrent activation, where an edition's assigned deployment target, for example, a dynamic cluster, is cloned and the edition is made ready to be started on the cloned deployment target. The cloned deployment target is known as a validation target. Routing rules must be used to designate which application requests are sent to the edition undergoing validation. When an edition is in the validation, it is in validation mode.

Validation mode ensures that a new edition of an application functions in its production environment without taking the currently available edition offline. Typically, a test load is sent to an edition in validation mode to confirm that aspects of the application environment and setup, such as connectivity and database access, work as expected. When an edition validation mode is rolled out, the rollout occurs on the deployment target on which the edition was originally installed. This causes the edition to exit validation mode. Upon exit from validation mode, the validation target is deleted.

Following is an example diagram of validation.

Validation diagram

Edition compatibility

Some application changes are transparent to users and others are not. When an application upgrade delivers at least the same application programming interfaces as the last change did and no semantic change to essential behavior, that application edition is a backward compatible upgrade. Existing users can use the upgraded application without changing how they use it, and should not see a difference between the current and former editions.

An application upgrade that requires existing users to change how they use the application is an incompatible upgrade. At times you might need to drop former function, or change interfaces, for example, to improve maintainability or other factors, and might introduce incompatible changes to your deployment environment. Incompatible changes require careful planning to manage the impact to existing users.




Related concepts
Application edition manager
Related tasks
Application edition management tutorial
Related reference
Edition manager states
Concept topic    

Terms of Use | Feedback

Last updated: Nov 30, 2007 4:01:31 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/appedition/cxappedcon.html