principales - ¿Cuál es la mejor forma de compartir instancias de objetos comerciales entre aplicaciones web Java usando JBoss y Spring?
como hacer una pagina web en eclipse (9)
Actualmente tenemos una aplicación web que carga un contexto de aplicación Spring que crea una instancia de una pila de objetos comerciales, objetos DAO e Hibernate. Nos gustaría compartir esta pila con otra aplicación web, para evitar tener múltiples instancias de los mismos objetos.
Hemos analizado varios enfoques; exponer los objetos usando JMX o JNDI, o usando EJB3.
Los diferentes enfoques tienen sus problemas, y estamos buscando un método ligero.
¿Alguna sugerencia sobre cómo resolver esto?
Editar: recibí comentarios que me pedían que explicara un poco, así que aquí va:
El principal problema que queremos resolver es que queremos tener solo una instancia de Hibernate. Esto se debe a problemas con la invalidación de la memoria caché de segundo nivel de Hibernate cuando se ejecutan varias aplicaciones cliente que trabajan con la misma fuente de datos. Además, la pila de negocios / DAO / Hibernate está creciendo bastante grande, por lo que no duplicarlo tiene más sentido.
En primer lugar, tratamos de ver cómo la capa de negocios por sí sola podría estar expuesta a otras aplicaciones web, y Spring ofrece la envoltura de JMX al precio de una pequeña cantidad de XML. Sin embargo, no pudimos vincular las entidades JMX al árbol JNDI, por lo que no pudimos buscar los objetos desde las aplicaciones web.
Luego intentamos unir la capa de negocios directamente a JNDI. Aunque Spring no ofreció ningún método para esto, usar JNDITemplate para vincularlos también era trivial. Pero esto dio lugar a varios problemas nuevos: 1) El administrador de seguridad niega el acceso al cargador de clases RMI, por lo que el cliente falló una vez que tratamos de invocar métodos en el recurso JNDI. 2) Una vez que se resolvieron los problemas de seguridad, JBoss lanzó IllegalArgumentException: object no es una instancia de declaración de clase. Un poco de lectura revela que necesitamos implementaciones de stub para los recursos JNDI, pero esto parece una gran molestia (¿quizás Spring nos puede ayudar?)
Todavía no hemos analizado demasiado a EJB, pero después de los primeros dos intentos me pregunto si lo que estamos tratando de lograr es posible.
Para resumir lo que estamos tratando de lograr: una instancia de JBoss, varias aplicaciones web que utilizan una pila de objetos comerciales encima de la capa DAO e Hibernate.
Atentamente,
Nils
Eche un vistazo a JBossCache . Le permite compartir / replicar fácilmente mapas de datos entre varias instancias de JVM (el mismo cuadro o diferente). Es fácil de usar y tiene muchas opciones de protocolo de nivel de cable (TCP, UDP Multicast, etc.).
No estoy seguro de lo que estás tratando de resolver; al final del día, cada jvm tendrá instancias replicadas de los objetos, o talones que representen objetos existentes en otro servidor (lógico).
Podría configurar un tercer servidor de "lógica de negocios" que tenga una API remota a la que puedan llamar sus dos aplicaciones web. La solución típica es usar EJB, pero creo que la primavera tiene opciones remotas integradas en su pila.
La otra opción es usar alguna forma de arquitectura de memoria caché compartida ... que sincronizará los cambios de objetos entre los servidores, pero aún tiene dos conjuntos de instancias.
Terracota podría ser una buena opción aquí (revelación: soy un desarrollador de Terracota). Terracota agrupa de forma transparente objetos Java en el nivel JVM y se integra con Spring e Hibernate. Es gratis y de código abierto.
Como dijo, el problema de más de una aplicación web cliente que utiliza un caché L2 es mantener esas cachés sincronizadas. Con Terracotta puedes agrupar un solo caché Hibernate L2. Cada nodo de cliente trabaja con su copia de ese caché agrupado, y Terracotta lo mantiene sincronizado. Este enlace explica más.
En cuanto a sus objetos comerciales, puede usar la integración de Spring de Terracotta para agrupar sus beans: cada aplicación web puede compartir instancias de beans en clúster, y Terracotta mantiene el estado agrupado sincronizado de forma transparente.
En realidad, si desea una solución liviana y no necesita transacciones o agrupamiento, use la compatibilidad con Spring para RMI. Permite exponer Spring beans de forma remota utilizando anotaciones simples en las últimas versiones. Ver http://static.springframework.org/spring/docs/2.0.x/reference/remoting.html .
Gracias por tus respuestas hasta ahora. Todavía no estamos del todo allí, pero hemos intentado algunas cosas ahora y vemos las cosas más claramente. Aquí hay una breve actualización:
La solución que parece ser la más viable es EJB. Sin embargo, esto requerirá una cierta cantidad de cambios en nuestro código, por lo que no vamos a implementar completamente esa solución en este momento. Estoy casi sorprendido de que no hayamos podido encontrar alguna función de Spring para ayudarnos aquí.
También probamos la ruta JNDI, que finaliza con la necesidad de stubs para todas las interfaces compartidas. Esto se siente como una molestia, teniendo en cuenta que todo está en el mismo servidor de todos modos.
Ayer, tuvimos un pequeño avance con JMX. Aunque definitivamente JMX no está diseñado para este tipo de uso, hemos demostrado que se puede hacer, sin cambios de código y con una cantidad mínima de XML (un gran agradecimiento a Spring para MBeanExporter y MBeanProxyFactoryBean). Los principales inconvenientes de este método son el rendimiento y el hecho de que nuestras clases de dominio se deben compartir a través de la carpeta server / lib de JBoss. Es decir, tenemos que eliminar algunas dependencias de nuestros WAR y moverlas a server / lib, de lo contrario obtenemos ClassCastException cuando la capa empresarial devuelve objetos de nuestro propio modelo de dominio. Entiendo completamente por qué sucede esto, pero no es ideal para lo que estamos tratando de lograr.
Pensé que era hora de una pequeña actualización, porque lo que parece ser la mejor solución llevará algún tiempo implementarlo. Publicaré nuestros hallazgos aquí una vez que hayamos hecho ese trabajo.
Debería echarle un vistazo a la Aplicación web de referencia de Terracotta - Examinador. Tiene la mayoría de los componentes que está buscando, tiene Hibernate, JPA y Spring con un back-end MySQL.
Ha sido preajustado para escalar hasta 16 nodos, 20k usuarios concurrentes.
Compruébelo aquí: http://reference.terracotta.org/examinator
¿Qué pasa con SpringContext? Mira este artículo:
http://springtips.blogspot.com/2007/06/using-shared-parent-application-context.html
Spring tiene un punto de integración que podría interesarle: nterceptor de inyección EJB 3 . Esto le permite acceder a los granos de primavera desde los EJB.
¿Las aplicaciones web están implementadas en el mismo servidor?
No puedo hablar para Spring, pero es sencillo mover su lógica de negocios al nivel EJB usando Session Beans.
La organización de la aplicación es directa. La lógica entra en beans de sesión, y estos beans de sesión se agrupan en un solo jar como un artefacto de Java EE con un archivo ejb-jar.xml (en EJB3, esto probablemente estará prácticamente vacío).
A continuación, agrupe las clases de entidad en un archivo jar separado.
A continuación, creará cada aplicación web en su propio archivo WAR.
Finalmente, todas las jarras y las guerras están agrupadas en un EEE de Java EE, con el archivo application.xml asociado (de nuevo, esto probablemente será bastante mínimo, simplemente enumerando los frascos en el EAR).
Este EAR se implementa al por mayor en el servidor de la aplicación.
Cada WAR es efectivamente independiente: sus propias sesiones, sus propias rutas de contexto, etc. Pero comparten el back end de EJB común, por lo que solo tiene un único caché de segundo nivel.
También utiliza referencias locales y semántica de llamadas para hablar con los EJB ya que están en el mismo servidor. No hay necesidad de llamadas remotas aquí.
Creo que esto resuelve bastante bien el problema que está teniendo, y es bastante sencillo en Java EE 5 con EJB 3.
Además, todavía puede usar Spring para gran parte de su trabajo, según tengo entendido, pero no soy una persona de Spring, así que no puedo hablar sobre los detalles.