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

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.