Application edition manager concepts
Versions and editions
The terms version and edition distinguish between what occurs in the development and build environment from what occurs in the 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 WAS 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 | Deployed application with no associated edition information. |
| Edition activation | When an edition is first installed, the edition is in the inactive state. We can start the edition only when it is in the active state. The transition from inactive to active is known as activation. |
| Concurrent activation | Multiple editions of the same application are active and started simultaneously. Can provide one set of users access to one edition and other users with access to another. For example, if we introduce a new edition of an application, we 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, we 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. |
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.
Deprecated feature: Assisted and Complete Lifecycle servers have been deprecated in WebSphere Application Server v9.0. Migrate WebSphere Liberty servers to a Liberty Collective configuration. There is no recommended migration action for other server types.depfeat
Concurrently active editions
Rollouts
Rollouts replace the active edition with a new edition. For interruption-free application upgrades, rollouts to an edition include...
- 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.
Group rollout
To perform a rollout to a target cluster, we 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 we 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 we 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.
Atomic rollout
Perform 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.
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 we 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.
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, we can use the upgraded application without changing how we 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 the deployment environment. Incompatible changes require careful planning to manage the impact to existing users.
Subtopics
- Application edition manager
- Intelligent Management: application edition manager custom properties
- Intelligent Management: application edition manager states
- Operational environment
- Edition compatibility