Application edition manager concepts
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. 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.
An application edition is a unique deployment of a particular application. In the WebSphere Application Server administrative environment, an application edition is an application 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 refers to a deployed application that has no associated edition information.
- 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 exists when multiple editions of the same application are active and started simultaneously. Concurrently active editions can provide one set of users 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 the edition, and not want all users to have access to the edition. With concurrent activation, you must 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.
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. Unmanaged web applications are supported with the exception that not all capability is available due to their nature as applications of assisted lifecycle management.
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. In other words, users of the application experience no loss of service during the application upgrade.
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:
- Fencing a server from receiving new requests.
- Quiescing requests for the application in a particular server.
- Stopping the currently active edition.
- Starting the new edition.
- Resuming the flow of requests to the edition.
When you perform a rollout to an edition across an application server cluster, you complete the following activities across the set of the servers that are in that cluster:
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 in the administrative console. 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 in the process of 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 2.0, all application requests are served by edition 2.0 when edition 2.0 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 2.0. The following example is a diagram of a group rollout.
Figure 2. Group 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 2.0, 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:
Edition validation and compatibility
The 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.
Some application changes are transparent, while other application changes are seen by the end user. 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 an upgrade that is compatible with previous versions. 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. We 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.
Subtopics: