Opciones para comunicarse entre WAR en el mismo EAR

Question

¿Qué opciones tiene para comunicarse entre los WAR en un EAR? Tenemos varios WAR que proporcionan diferentes servicios web implementados dentro de un EAR. Para sus tareas, necesitan comunicarse con los otros WAR. Por supuesto, podrían comunicarse utilizando servicios web. ¿Qué otras opciones, quizás más eficientes, existen?

EDITAR: El motivo de la comunicación es que los módulos utilizan algunas funciones compartidas, y queremos ubicar esta funcionalidad en un solo lugar, ya que requiere una cantidad significativa de recursos. Además, esto requiere comunicación sincrónica.

Answer 1

En primer lugar, debe tener claro qué es lo que está compartiendo. Debe diferenciar entre el servicio y una biblioteca. La biblioteca le permite compartir la funcionalidad común, esto es lo que logra cuando utiliza la biblioteca log4j, por ejemplo. En ese caso, configura log4j en cada proyecto que lo está usando. Por otro lado, podría tener el servicio de registro centralizado que tiene su propia configuración de registro y le permite administrar esto en un solo lugar. En este caso, debe compartir el servicio.

Puede compartir la biblioteca colocando el recipiente dentro de cada guerra o dentro de la oreja. Puede compartir el servicio siendo el cliente de servicio. Entonces, sus servicios web pueden usar otro servicio. En ese caso, un servicio web es un cliente de otro, logrando la composición del servicio (un patrón común en el desarrollo empresarial)

Si tanto el servicio cliente como el servicio residen en el mismo oído, entonces puede evitar algunos gastos indirectos llamando al servicio "directamente", por ejemplo, utilizando la función de contexto principal de Spring: http://springtips.blogspot.com/2007/06/using-shared-parent-application-context.html , pero aconsejaría que no se acople el servicio porque perderá diferentes beneficios que tener servicio en primer lugar proporciona la gobernanza, la capacidad de gestión, etc.

Answer 2

Dos cosas vienen a la mente

1. Hay JMS para enviar señales.
2. EJB podría registrar información compartida.
3. Un jar de lib en el directorio lib de EAR.

Si solo necesita métodos compartidos, 3 es lo que desea. Pero sus puntos de edición me dicen que tiene una funcionalidad compartida que opera en datos compartidos. Por ejemplo, tiene registros de usuario a los que ambos WAR acceden y actualizan. Si es así, quieres un EJB.

Answer 3

¿Por qué no poner las clases comunes en un JAR y trabajar con ellas directamente? ¿O un peso un poco más pesado hace que las clases comunes tengan frijoles de sesión?

Answer 4

Dado que su edición parece implicar que las comunicaciones no son realmente necesarias entre WARS, pero ambas necesitan acceder a los mismos recursos compartidos. La solución más simple sería poner los frascos para este recurso en el EAR y agregar la dependencia para esos frascos a ambos proyectos web para que usen el recurso compartido.

Si hay un código de estado en ambos proyectos web que necesita actualizarse, entonces su única opción es realizar una llamada al servlet para el proyecto web (suponiendo que el código de estado está contenido en el proyecto web).

Solo recuerde que el recurso compartido debe ser seguro para la tarea.

Pregunta similar here.