WebLogic Server

(Migrated from Rob Woollen's blog on dev2dev with his permission. This entry was originally posted on August 01, 2005 01:47 PM)

Application libraries are a new feature in WLS 9 and one which I helped design and implement so I thought it a natural choice for a blog entry. The product documentation gives extensive information about libraries and specifics on their usage. The purpose of this blog is not to replace product documentation but to highlight new features and to give you insight not only in how the feature works but why we made certain design choices.

Like many of the best features, application libraries were developed directly from customer feedback that delivering applications as a single EAR file was too limiting. Applications often contained components deliverd from different organizations and shared common services. Delivering these components together as a single build proved difficult to manage and upgrade. Developers had no idea how many groups were using a specific version of their components, and it was difficult to tease apart shared services from custom application code.

Application libraries bring ideas like shared libraries or DLLs to the J2EE world. They allow an application to be composed of core application code "linked" with libraries of separately packaged J2EE components. Libraries allow each organization to manage their own deliverable and packaging without requiring a single unified EAR.

For instance, an online banking application might be composed of a security framework, data access code, and presentation logic. To keep things simple, let's say the security code is delivered by a separate organization (obviously security is very important in banking) and the other components are specific to this application. The security developers now merely deliver their components as a standard J2EE EAR file. The online banking application adds an entry to their weblogic-application.xml to express a dependency on the security library, and the WebLogic Server treats these 2 separate files as if they were a single merged EAR file. Since they are separate files on disk, it is much easier for the production team to upgrade the security library or determine who is using a particular version of the library. (We'll discuss a lot more detail here in parts II and III of this series.)

Application libraries are an extremely powerful and useful feature, and I'll cover them in detail over several blog entries. For those of you that want to read ahead, I'd suggest the product documentation or even downloading WLS 9 and trying out libraries.

In Part II, I'll give more details about library semantics, their relation to J2EE Optional Packages, and using library-based applications on older WLS releases or other J2EE servers.

In Part III, I'll cover deploying libraries, versioning, and upgrading library applications with zero downtime.