Ventajas y desventajas de usar biblioteca compartida frente a EAR totalmente encapsulado

Question

Nuestro equipo crea y posee un marco de servicios web. Otros equipos que realmente construyen los servicios web usan nuestro marco para algunas funcionalidades comunes. Hay dos opciones para empaquetar el EAR. La opción 1 es tener todos los marcos jar incorporados en el EAR. La opción 2 es configurar una biblioteca compartida en el servidor de aplicaciones y hacer que todas las aplicaciones utilicen la biblioteca. Tenemos potencial de desplegar hasta 100 EARS, que usarán este marco. ¿Cuáles son algunos de los pros y los contras de este enfoque en términos de construcción, capacidad de gestión y desarrollo? Estamos usando websphere.

Answer 1

La desventaja básica es el consumo de memoria frente a la gestión de versiones.

Si empaqueta bibliotecas en un EAR, cada aplicación creará sus propias instancias de clase, consumirá una cierta cantidad de permgen (o equivalente) y ocupará espacio dinámico para datos estáticos.

Si almacena una biblioteca en el directorio lib de la aplicación, solo habrá una instancia de cada clase. Sin embargo, significa que cada una de las aplicaciones que usan esa biblioteca debe usar la misma versión y (a menos que se garantice la compatibilidad con versiones anteriores) debe actualizarse al mismo tiempo.

Dado que está hablando de 100 EAR, el problema de la administración de la versión probablemente sea grande. A menos que su biblioteca sea absolutamente enorme (y supongo que se está ejecutando en un servidor de 64 bits con mucha memoria, por lo que es GRANDE), o nunca va a cambiar (poco probable), sugiero que se empaque con la oreja

Answer 2

Sugeriría también empacar con el EAR. Ad kdgregory señaló administrar cientos de programas y la cantidad de pruebas implícitas por las actualizaciones se vuelve desalentadora; Además, debe usar un sistema de control de versiones para administrar las instancias de sus binarios que los clientes deben consumir.

Answer 3

En lugar de poner los archivos jar comunes en lib/app, en su lugar puede utilizar la función de biblioteca compartida de WebSphere. Esto permite asignar diferentes versiones de la misma biblioteca compartida a diferentes aplicaciones, lo que permite cierta flexibilidad para las versiones msnsging.

Los diversos enfoques para compartir tienden a generar algunas complejidades; es necesario estudiar detenidamente los cargadores de clases involucrados.

Mi preferencia sería permanecer simple-vainilla, empacar todo en el EAR. Esto es simple, directamente Java EE. Cada aplicación puede elegir su propia tasa de adopción de versión de framework.

Consulte el artículo de Keys Botzum sobre el embalaje common code.

Answer 4

Otra cosa a tener en cuenta es que si desea compartir instancias de objetos entre EAR, p. utilizando el dynacache websphere, las clases para esos objetos deberán cargarse desde las bibliotecas compartidas. (de lo contrario, aunque puedan ser de la misma clase/versión, serán cargados por diferentes cargadores de clases y no serán compatibles)

Normalmente utilizo el enfoque de "empaquetar todo en OREJA", pero luego hago excepciones para cosas que deben compartirse, y poner esas clases en un JAR compartido especial.

Answer 5

Estoy de acuerdo con (casi) todo lo que se escribió sobre este tema antes: a menos que tenga una muy buena razón para no hacerlo, continúe y empaquete todas las bibliotecas en el EAR y disfrute el beneficio de EAR independientes y autosuficientes.

Sin embargo, tenga en cuenta que si su biblioteca de terceros utiliza áreas estáticas para la inicialización, entonces es posible que desee empaquetarlo en el EAR después de todo. Un claro ejemplo es Log4J. Log4J se inicializa solo una vez por cargador de clases. Por lo tanto, si desea tener una configuración diferente de Log4J por EAR, entonces no tiene más remedio que colocar el archivo Log4J JAR con cada EAR. De lo contrario, Log4J JAR se cargará con un cargador de clases que es común a todos sus EAR, se cargará solo (e inicializará sus propias áreas estáticas) una vez, y esa configuración tendrá efecto para todas las aplicaciones que usen Log4J.