Enterprise Application EJB3 Como Portal y Cliente Web Apps - Arquitectura/Diseño

Question

Como se muestra en la foto de arriba, tengo una aplicación EJB3 Empresa (archivo EAR), que actúa como un portal web y tiene 3 aplicaciones (archivos WAR) que se comunican y realizan transacciones con el mismo almacén de datos. Estas 3 aplicaciones web no son implementaciones de portlets, sino webapps normales que interactúan con el almacén de datos a través de la Capa de persistencia de la aplicación Enterprise. Estos webapps se desarrollan de forma independiente, por lo que algunos de ellos usan servicios web de la aplicación Enterprise y algunos de ellos usan EJB-Clients.

Además, hay una otra opción de reemplazar estas aplicaciones web (Web App1, Web App2 y Web App3) y el uso de aplicaciones empresariales independientes para comunicarse y realizar transacciones con la base de datos, como se muestra a continuación:

Ahora, mis preguntas son:

1) ¿Cuál es la mejor opción entre las 2 opciones enumeradas (arriba)?

2) ¿Cómo afecta cuando reemplazamos las aplicaciones web que actúan como clientes a la aplicación Enterprise, como aplicaciones empresariales independientes (archivos EAR)?

3) ¿Qué es un modelo mejor para el manejo de transacciones, la funcionalidad de SSO, la escalabilidad y otros factores?

4) ¿Hay algún otro modelo mejor?

EDITAR:

1) En el primer modelo, el cual método es una forma preferida para interactuar con el archivo EAR - webservices o archivo JAR EJB-cliente/biblioteca (interfaces y clases de utilidad)?

2) ¿Cómo difieren ambos modelos en el uso de la memoria (RAM del servidor) y el rendimiento. ¿Hay alguna diferencia considerable?

Answer 1

Como estás siendo tan abstracto, yo también lo haré. Si eliminamos todas las palabras zumbidas como "Portal", "Aplicaciones empresariales", etc. ... Lo que tenemos al final son tres aplicaciones web y una biblioteca o marco común (La aplicación empresarial).

Ver su aplicación lo más simple posible. Tienes tres desarrolladores que necesitan desarrollar tres aplicaciones web. Proporcionará un código común útil para construir sus aplicaciones. El modelo que usará dependerá del tipo de código que les proporcione.

1.- Solo proporcionará algunas utilidades y un código comercial común. Puede ser la biblioteca clasical adaptada a sus necesidades. (En entornos Java EE debe tener en cuenta cómo puede aprovechar las ventajas de la caché de persistencia de nivel 2 compartiendo una fábrica de sesiones para un solo almacén de datos)

2.- Proporcionará servicios compartidos como persistencia, caché, seguridad, auditoría , y así sucesivamente ... Necesitará una capa de servicio como primera opción. Tendrá un estado compartido, por lo que solo necesita una instancia.

3.- El caso más común es que proporcionas una API comercial y una capa de servicios a los servicios comunes.

No está indicando ningún requisito que lo obligue a utilizar una solución más compleja para su escenario.

EDIT:

RMI

Sobre si se prefiere (EJB-cliente) o servicios web. Siempre uso rmi para comunicar aplicaciones geográficamente cercanas. Su uso es simple y el protocolo es mucho más rápido que los servicios web (puede leer muchas comparaciones sobre este tema buscando el rendimiento de los servicios web de rmi en google).
Por otro lado, rmi es más sensible a la latencia de la red, requiere configuraciones de firewall especiales y está más acoplado que los servicios web. Por lo tanto, si pretendo ofrecer servicios a un tercero o conectar servidores geográficamente escasos, preferiré los servicios web o incluso DESCANSO.

Sobre la última pregunta, inicialmente no hay ninguna diferencia sobre la implementación de una o diez aplicaciones en el mismo servidor. La tarifa de despliegue será insignificante sobre la sobrecarga para el uso de la aplicación. Por supuesto, debe tomar esto como una suposición genérica. Obviamente, el tamaño y la forma en que implemente sus aplicaciones tendrá un impacto sobre el consumo de memoria y otros.

Debe tener en cuenta que estas decisiones se pueden cambiar fácilmente según lo necesite. Entonces, como dije, podría comenzar con la solución simple y si encuentra un problema al implementar sus aplicaciones, podría reestructurar sus oídos fácilmente.

Answer 2

Estoy dispuesto a estar de acuerdo con Fedox. Si no hay ninguna razón para elegir una solución sobre la otra (razón comercial, razón técnica, etc.) entonces también podría elegir la ruta de menor resistencia. En mi opinión esa sería la primera solución.

En términos generales, comience de manera simple y agregue la complejidad que necesite. Sus soluciones no tienen ningún significado sin contexto. Una aplicación de banca necesita consideraciones diferentes a un blog.

Esperanza esto ayuda

Answer 3

Hay una nueva plataforma llamada Vitria's BusinessWare, que es un proyecto muy exitoso, lo que vale millones.
Ahora veamos cómo funciona y qué hace para que podamos hacer lo mismo en teoría:
Interconecta proyectos con sus bases de datos, servicios web con sus EJBs ... etc. Desde su concepto podemos aprender lo siguiente:

1. Crear EJB frijol principal sin estado (API ), cuyo trabajo consiste en pasar mensajes de :

   • servicios web a otra web- servicios
   • de servicios web a aplicaciones web
   • aplicaciones web a otros servicios web

2. El propósito de este EJB es hacer primero las validaciones en la base de datos principal y luego pasar las llamadas a los otros módulos.

3. Sólo esta EJB tiene acceso a la base de datos para asegurar más las conexiones
4. Este EJB pondrá en cola los mensajes hasta que los módulos enviados son libres aceptar
5. Este EJB controlará todos los procesos en el PP
6. Este EJB decidirá dónde enviar los mensajes