Application edition manager concepts
By knowing the difference between application edition manager versions and editions, the methods of deploying and upgrading your application, and edition validation and compatibility, you can fully utilize the application edition manager to manage your application deployments.
Unmanaged Web applications can be defined with an edition. However, a rollout cannot be performed on them nor can they be placed into validation mode. They are supported except that not all capability is available to them due to their nature as applications of assisted lifecycle management.
Versions and editions
The terms version and edition distinguish between what occurs in your development and build environment from what occurs in your deployment and operational environment. A version is a successive generation of an interface, function, implementation, or entire application, and so forth. Vis 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.
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 the name 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 application edition manager support to WebSphere XD cell are displayed in the application 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, the edition is in the inactive state. You can start the edition only when it is in the active state. The transition from inactive to active is known as activation.
Concurrent activation
Concurrent activation exists 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, then you might want a select group of users to test the edition, and not want all users to have access to the edition. With concurrent activation, establish a routing policy to distinguish which users have access to an edition. A routing policy is stored as part of the configuration metadata for an application. Also, a routing policy prevents ambiguity and determines which edition receives control. The following example is a diagram of concurrently active editions.
Figure 1. Concurrently
active editions
Application upgrade and deployment
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 refers to the ability to upgrade while maintaining application continuous availability. Users of the application experience no loss of service during the application upgrade.
Edition rollout When you perform a rollout to an edition, you replace an active edition with a new edition. To provide interruption-free application upgrades, performing a rollout to an edition includes the following items:
- 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.
- Resuming the flow of requests to the edition.
Group rollout
To perform a rollout to a target cluster, you can divide the cluster into groups, and define a group size, which specifies the number of nodes to process at a time. Performing a rollout to a group results in the servers in each group being upgraded to the new edition at the same time. Each server in the group is quiesced, stopped, and reset. A rollout can be performed on only one group at a time with the administrative console. Alternatively, you can use scripts to perform a rollout on multiple groups. When any member in the new edition becomes available, all requests are routed to the new edition.
As you perform a rollout to the edition, some servers in the cluster move from the previous 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 perform a rollout from edition 1.0 to 1.1, all application requests are served by edition 1.1 when edition 1.1 becomes available on a server. Any servers that are still running edition 1.0 do not serve requests until this server is updated to edition 1.1. The following example is a diagram of a group rollout.
Figure 2. Group
rollout
Atomic rollout
Performing an atomic rollout to an edition replaces an edition on half of the cluster at a time to serve all user requests with a consistent edition of the application. All user requests are served by either the previous or the new edition; user requests are never served by both editions.
An 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 from 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. 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. The following example is a diagram of an atomic rollout.
Figure 3. Atomic rollout
Edition validation and compatibility
Edition validation
Edition validation refers to a special case of concurrent activation, where an assigned deployment target of the edition, 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 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 you perform a rollout to an edition validation mode, the operation occurs on the deployment target on which the edition was originally installed. Performing a rollout causes the edition to exit validation mode. When validation completes, the validation target is deleted. The following example is a diagram of edition validation.
Figure 4. Edition validation
Some application changes are transparent 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. As an existing user, you can use the upgraded application without changing how you use it and without recognizing 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. 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 reference
Application edition manager states