Application Libraries - Part III Deployment and Versioning
By Aseembajaj-Oracle on Nov 20, 2008
(Migrated from Rob Woollen's blog on dev2dev with his permission. This entry was originally posted on August 22, 2005 02:40 PM)
Library Deployment / Undeployment
Application libraries use the same deployment and distribution machinery as "regular" applications so users are not forced to learn a new set of commands. A library is deployed with either the WebLogic Administration Console, the weblogic.Deployer command-line, the wldeploy ant task, WLST scripting, or the programmatic deployment APIs. Library deployment distributes the files to the target servers and registers itself with the target server's library manager. When an application references a library, the library manager is consulted to ensure the library exists and the correct version is "linked" with the application.
After library deployment, one or more applications may be deployed which reference the library. As was discussed earlier in this series, each referencing application imports its own library copy. The purpose of libraries is to change the packaging of J2EE applications not their semantics.
Libraries may also be undeployed to unregister them and remove their files. Undeploying the library is only possible if there are no deployed applications current referencing it. An attempt to undeploy a library which is still being used will be refused with an error message instructing the user which applications are still referencing it.
Versioning Use Cases
product documentation provides a lot of background on libraries and their versoning support. Instead of duplicating that effort here, I thought I'd cover a few common use cases, and how they can be solved with library versioning along with some examples.
A library may include a standard java manifest file which supplies version information. The
product documentation covers this topic in depth, but the main idea is each manifest may optionally include a specification-version and an implementation-version.
An application includes a library with an entry in its weblogic-application.xml. The entry may optionally specify a specification-version and implementation-version. If a version is not specified, the server defaults to using the latest deployed library version. When a version is specified it indicates the app wants that version or later. The exact-match flag indicates that a later version is not acceptable and only the exact specified version will be used.
The rules are relatively straightforward, but some quick examples will probably help.
Assume the server currently has 2 versions of the DAO-LIB library deployed:
Note for convenvience, I will abbreviate spec-version of x and impl-version of y as (x/y).
Application library References
Now consider which library is used when applications are deployed with the following DAO-LIB references:
|Name||Specification-Version||Implementation-Version||Exact-Match||Which library is used?||Why?|
|DAO-LIB||Not specified||Not specified||Not specified||3/1||No spec-version was specified so latest is used.|
|DAO-LIB||2||Not specified||Not specified||3/1||App is requesting spec-version >=2. 3/1 is the highest >= 2|
|DAO-LIB||2||Not specified||True||2/3||Exact-Match requires only library with spec-version 2 to match|
|DAO-LIB||4||Not specified||Not specified||None||Deployment fails since no app has spec-version >= 4|
|DAO-LIB||2||4||Not specified||None||Deployment fails since no app has impl-version >= 4|
It is good practice for each library to include a specification-version and implementation-version. Both versions should be decimals or dewey decimals (eg major.minor.patch) rather than arbitray strings (this makes them comparable.) The specification-version should change when any of the interfaces or conventions change incompatability (basically anytime a referencing application would have to change or recompile.) The implementation-version can be a build number.
Most referencing applications should specify a specification-version and exact-match=true but not specify an implementation-version. This allows the admin to use a newer library build with the latest bug fixes without updating all the referencing application EARs.
- Integrating Library Bug Fixes
- Multiple applications using different library versions
- Zero downtime upgrade of library applications
In this scenario the admin receives a new, compatible version of the library with some bug fixes. The library would have changed its implementation-version but not its specification-version. The new library build can be deployed to the server. The application should have specified only a spec-version in its descriptor and when it is redeployed it will automatically pick up the latest library with the bug fixes.
In this scenario there are multiple, incompatabile versions of the library being used by different applications. This might occur if an application has not been tested, certified, or updated with the latest library, but another application requires new library functionality. This can be accomplished by deploying the incompatabile libraries with different specification-versions. The referencing applications should specify their required version and set exact-match. This ensures each application will in parallel find their appropriate library version.
Application upgrade without downtime is worthy of its own future blog entry. The product documentation covers the background information on this topic. In the library scenario, the first step would be to deploy the new library version. Since libraries only distribute code and register themselves, this won't interrupt any existing applications. Next, the new application can be deployed alongside the existing application version. If the library has changed as well, the updated application can specify exactly what version of the library it requires.
I hope these blog entries have shown you the flexiblity that libraries now offer in WLS 9. There are many more innovative features in WLS 9 that I'll try to cover in the next few weeks.