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 use 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. Unmanaged web applications are supported with the exception that not all capability is available 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. 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.
2.0, or the name can be descriptive, such as
- 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.
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.
- 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
all application requests are served by 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
following example is a diagram of a group rollout.
An atomic rollout ensures that all application requests are served by a consistent
edition, for example, either edition
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 rollout 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 or delays any request that arrives for this
application. When the rollout is complete, both halves of the cluster are 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. 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.