This service has been designed for dynamic redeployment of applications, without any application downtime and without users' sessions being lost:
-
Deployment of a new version of an application does not require the undeployment of any previous version.
-
Users that were on a previous version keep on using that version as long as their session on that version is active (for example, as long as they have not finished buying items on the previous version of the online trade web site). This guarantees that no user data will be lost, and that if there is any problem with the new version the old version is still available instantly.
-
New versions of the application can be deployed using various strategies, for instance allow testing of the new version by a small community to ensure its readiness for production.
The versioning service achieves this by adding virtual contexts to all services that provide support for versioning. To use the versioning service:
-
Enable the versioning service in
jonas.properties -
Define the Implementation-Version attribute in your deployable file's (whether
war,jarorear)MANIFEST. Note that:-
ANT, Maven as well as most IDEs can set any
MANIFESTattribute automatically. -
If the archive that will be deployed is an
ear, the Implementation-Version defined in theMANIFESTof the ear will be used for all archives theearcontains.
-
When the versioning service is enabled, application resources (web pages, EJBs, etc.) are accessed the following way:
-
Each versioned application has a user (virtual) address. Each version of an application is renamed and bound to that virtual address. Each bound version has a policy (that can be changed in time in order to manage the deployment strategy):
-
Private: Can only be accessed by clients that satisfy some prerequisites; for example belong to a certain IP address group or provide a certain credential.
-
Reserved: Not accessible using the virtual address, therefore can only be accessed directly (using the versioned address).
-
Disabled: Only accessible by clients that have been using this version in the past (until their session expires). This guarantees that users will not lose their session data during a redeployment.
-
Default: Version accessed by all clients that don't fit in any other policy.
-
-
A user can access the application resource indirectly (using the virtual address) or directly (using the versioned address).
-
If the user tries to access the application resource indirectly (using the virtual address), the versioning system:
-
First checks if that user is defined as a user that can access a version of the application with the Private access policy. If that is the case, the user is routed to that private version of the application.
-
Then checks if that user already has a session in a version of the application with the Disabled access policy. If that is the case, the user is routed to that disabled version of the application.
-
If neither of these cases are true, routes the user to the version of the application with the Default access policy. If the application does not define any default version, the user will see "resource not found" message.
-
This can be schematized as follows:
 |
The current limitations of the versioning service are:
-
Only the Tomcat Web Container supports the versioning service. That support is fully functional, recognition of users is based on the session ID (via cookie or GET).
-
Both EJB2 and EJB3s support the versioning service. That support is fully functional, EJB lookups in the same EAR always redirect to the same version.
-
Web Service support for the versioning service is in design phase.
-
The Private context policy has not been implemented.
As this service allows seamless and interruptionless upgrade and test
of all applications, it is strongly recommended for all applications to
refer version identifiers in their manifest files. Remember that ANT, Maven
as well as most IDEs can set any MANIFEST attribute
automatically.
We will now detail the way versioning works by creating two versions
of the Java EE 5 Sample Application in the
JOnAS examples
folder: version 1.0.0 and version 1.0.1. Since the application is an EAR, we
only need to refer the version identifier in the EAR file.
When the first version of the EAR is deployed:
-
The application gets deployed on the URI /javaee5-earsample-version1.0.0.
-
The virtual URI /javaee5-earsample is created.
-
The real URI /javaee5-earsample-version1.0.0 gets bound to the virtual URI /javaee5-earsample.
Therefore, when a user accesses the /javaee5-earsample URI, the content seen is the same as the one on /javaee5-earsample-version1.0.0.
We now deploy the second version of the application, version 1.0.1, via the JOnAS Web Admin panel. When the second version is deployed, it is bound to the virtual URI as Reserved (this is the default policy and can be modified via JMX at any time). This means that the only way of accessing the 1.0.1 version of the application is to type as URI /javaee5-earsample-version1.0.1. All visitors of /javaee5-earsample will still access the version 1.0.0.
 |
To change the access policies of each version of the virtual URI (the only URI end users are expected to access), go to the list of Web Containers in the JOnAS Web Admin panel. If you set the version 1.0.0 as Disabled and the version 1.0.1 as Default:
-
The user that was on /javaee5-earsample when the default version was 1.0.0 will stay on version 1.0.0 until her/his session expires (i.e. the browser window is closed).
-
Any user that connects to /javaee5-earsample for the first time will visit version 1.0.1.
When the first version of the EAR is deployed:
-
All EJBs that register on the JNDI directory register with a prefixed name, which is their original name prefixed by javaee5_earsample_version1.0.0/. For example, the myStateless bean gets registered as javaee5_earsample_version1.0.0/myStateless.
-
For each EJB, the original JNDI name is also registered and points exactly to the same JNDI link.
Therefore, when a user looks up for the myStateless bean, the reference received is the same as the one received when javaee5_earsample_version1.0.0/myStateless is looked up.
The behaviours of the Web and EJB services when the version 1.0.1 is deployed are similar, except for one very important point: when multiple applications are packaged together, the only versions of the applications they've been tested against are the versions inside the same EAR. Therefore, blindly accessing the Default version of the EJBs could have unexpected results. This is why the concept of versioned EJB clients has been created:
-
All EJB clients in a versioned EAR automatically become versioned EJB clients. Their target version is the version of the host EAR, which implies that intra-EAR accesses are always done to the same version.
-
External EJB clients can also specify the versions for the EJB they need to access.
-
Non-versioned external EJB clients will access the Private, Reserved, Disabled or Default versions as usual.
This can be schematized as follows:
 |
As with the versioned Web Applications, to change the access policies of each version of the virtual JNDI container (which knows the JNDI names end users are expected to access), go to the list of EJB Containers in the JOnAS Web Admin panel. If you set the version 1.0.0 as Disabled and the version 1.0.1 as Default:
-
All clients that know about the versioned JNDI names (remember that this will always be the case in a versioned EAR application) will always access the version they specify.
-
References to myStateless obtained before this operation will stay on version 1.0.0.
-
Any user that looks up myStateless for the first time will get a reference to version 1.0.1.