Pros and Cons of using shared library vs fully encapsulated EAR

Question

Our team builds and owns a webservices framework. Other teams which actually build the webservices use our framework for some common functionality. There are two options to package the EAR. Option 1 is to have all the framework jars built into the EAR. Option 2 is to configure a shared library in the application server and make all applications use the library. We have potential of upto 100 EARS being deployed, that will use this framework. What are some pros and cons off this approach in terms of build,manageability and development. We are using websphere.

Answer 1

The basic tradeoff is memory consumption versus version management.

If you package libraries in an EAR, then each application will create its own class instances, consuming some amount of permgen (or equivalent) as well as taking up heap space for static data.

If you store a library in the application lib directory, then there will only be one instance of each class. However, it means that each of the applications using that library must use the same version, and (unless backwards compatibility is ensured) must upgrade at the same time.

Given that you're talking about 100 EARs, the version management issue is probably going to be big. Unless your library as absolutely huge (and I'm going to assume that you're running on a 64 bit server with lots of memory, so make that HUGE), or is never going to change (unlikely), I'd suggest packaging with the EAR.

Answer 2

I would suggest packaging with the EAR as well. Ad kdgregory pointed out managing hundreds of programs and the amount of testing implied by upgrades becomes daunting; futhermore you should use a version control system to manage instances of your binaries for the clients to consume.

Answer 3

Rather than putting the common jars into lib/app you can instead use WebSphere's shared library facility. This does permit different versions of the same shared library to be assigned to different applications, hence enabling some flexibility for msnsging versions.

The various sharing approaches tend to lead some complexities, you need to study carefully the classloaders involved.

My preference would be to stay plain-vanilla, package everything in the EAR. This is simple, straight JEE. Each app can choose its own rate of framework version adoption.

Refer to Keys Botzum's article on packaging common code.

Answer 4

Another thing to note is that if you want to share object instances between EARs, e.g. using the websphere dynacache, the classes for those objects will need to be loaded from shared libraries. (otherwise, even though they may be the same class/version, they will be loaded by different classloaders and not compatible)

I usually go with the plain-vanilla "package everything in EAR" approach as well, but then make exceptions for stuff that needs to be shared, and put those classes into a special shared JAR.