Arquitectura - Múltiples aplicaciones web que funcionan en los mismos datos

Question

que estoy pidiendo una arquitectura adecuada para la siguiente aplicación web de Java:

El objetivo es construir varias aplicaciones web que funcionan todos en los mismos datos. Supongamos un sistema bancario en el que se puede acceder a datos de cuenta mediante diferentes aplicaciones web; a la que pueden acceder los clientes (banca en línea), el personal del servicio (principalmente leído) y el departamento de administración de cuentas (herramienta de administración). Estas aplicaciones se ejecutan como aplicaciones web separadas en diferentes máquinas, pero usan los mismos datos y un conjunto de consultas de búsqueda y manipulación de datos comunes.

Un enfoque posible es construir una aplicación central que se ajusta a las necesidades comunes de los clientes, es decir, el almacenamiento de datos, manipulación y servicios de búsqueda. Los clientes pueden llamar a esta aplicación central para cumplir sus solicitudes. El requisito es que las aplicaciones se construyan sobre una pila Wicket/Spring/Hibernate como WAR.

Para obtener un panorama, aquí están algunos de los posibles enfoques que pensamos:

A El enfoque monolítico. Construir una gran aplicación web que se adapte a todas las necesidades (esto no es realmente una opción)

B El enfoque de la API. Cree una API de acceso a la base de datos central (JAR) para acceso/manipulación de datos. Cada aplicación web se compila como una GUERRA separada que usa la API para acceder a una base de datos. No hay una aplicación central separada.

C RMI approach. La aplicación principal se ejecuta como una aplicación independiente (posiblemente una GUERRA) y ofrece servicios a través de RMI (o HttpInvoker).

D WS approach. Al igual que C, pero reemplace la RMI con los servicios web

E Enfoque OSGi. Cree todos los componentes como módulos OSGi y que se ejecuten en un contenedor OSGi. Posiblemente use SpringSource dm Server o ModuleFusion. Este enfoque no era una opción para nosotros por algunas razones ...

Esperanza Podría aclarar el problema. Estamos yendo con la opción B, pero no estoy muy seguro con eso. ¿Cuáles son sus opiniones? ¿Alguna otra solución? ¿Cuáles son los inconvenientes de cada solución?

Answer 1

B, C y D son solo formas diferentes de lograr lo mismo.

Lo primero que pensé fue simplemente tener todo el código de consumidor conectado a una base de datos común. Esto es ciertamente factible y eliminaría el código que no desea colocar en el medio. El inconveniente, por supuesto, es que si el esquema cambia, todos los consumidores necesitan ser actualizados.

Otra solución es posible que desee tener en cuenta es dar a cada consumidor de su propia base de datos, utilizando algún tipo de replicación para mantenerlos sincronizados.

Answer 2

creo que usted tiene que ir en la dirección oppposite - de abajo hacia arriba. Por supuesto, debe avanzar y retroceder para verificar que todo esté funcionando, pero esta es la dirección general:

Piense en sus datos - esquema DB, cómo las transacciones son importantes (por ejemplo, en los sistemas bancarios, todo se trata de transacciones), etc.

a continuación, defina el método de acceso común - del conjunto de procedimientos almacenados a motor de transacción distribuida ...

el siguiente paso es una lógica de negocio/presentación - lo que podría ser generalizado y lo que es un tema de personalización.

y la etapa final son las interfaces, visualización e informes

Answer 3

Creo que es necesario tener una aplicación independiente que todas las aplicaciones de cliente utilizarán como su capa de datos. El motivo es que desea asegurarse de que todos accedan a la base de datos de la misma manera. También hay algunas condiciones de carrera que puede obtener y que las transacciones de la base de datos pueden no ser capaces de prevenir. La otra razón es que usar la base de datos como una forma de RPC es un antipatrón conocido. Si todas sus aplicaciones acceden directamente a la base de datos, casi inevitablemente terminará con una tabla de "eventos" que las distintas aplicaciones sondean periódicamente ... no hacen eso.

Answer 4

Además de las respuestas proporcionadas, si está considerando tener varias aplicaciones trabajando con la base de datos al mismo tiempo, considere una memoria caché distribuida como parte de su solución, también. La belleza de la memoria caché distribuida es que se puede acceder por varias aplicaciones al mismo tiempo, además de distribuirse. No estoy seguro de si esto es válido para todas las variaciones de Java, como Ehcache, etc., ya que no procedo de un fondo Java.

Lo que estamos haciendo actualmente es abstraer los datos un nivel más allá que antes. Ahora tenemos un DAL al que se puede acceder directamente, pero hemos puesto una "fábrica de modelos" frente al DAL. El propósito de Model Factory es intermediar tanto el caché como la capa de datos, actuando como un paso a paso. Por lo tanto, la persona que llama siempre llama a la Fábrica de Modelos y no al código DAL o de almacenamiento en caché directamente. Esta capa de abstracción básicamente recuperará datos del DAL en una falla de caché sin agregar la complejidad a la API.

Answer 5

Parece que A y E están fuera de la imagen como ha indicado en su pregunta por varias razones. La opción A sería una gran aplicación que dificultaría el mantenimiento en el futuro.

B, C y D son esencialmente los mismos desde el punto de vista arquitectónico, ya que implican el acceso remoto a bibliotecas comunes desde varias aplicaciones web, la única diferencia es el mecanismo de transporte. Recomiendo implementar esto en EJB 3 o Spring si es posible en lugar de hacerlo con sus propias bibliotecas RMI, ya que cualquiera de estas proporciona una buena estructura sobre RMI/Webservices.

Así que creo que este problema se reduce básicamente a las dos opciones siguientes:

1) incluyen a los negocios y las clases de capa DAO como un tarro común incluido en el despliegue de todas las aplicaciones web.

Ventajas:

• La implementación es más fácil.
• Las aplicaciones tendrán un mejor rendimiento inicialmente ya que no hay acceso remoto a otros servidores.

Desventajas:

• No se puede agregar más hardware para el nivel medio en concreto (capas de servicios y DAO) ya que está incluido en cada aplicación web.
• Otros equipos comerciales de la organización no tendrán acceso a los servicios de su empresa, ya que no existe una interfaz remota.

2) Despliegue el servicio empresarial y las clases de capa DAO en un servidor de aplicaciones independiente y exponga los métodos comerciales de forma remota.

Ventajas:

• Puede ampliar el servicio de negocio y la capa DAO según sea necesario, dependiendo de la carga de las diversas aplicaciones web le llama.
• Otras aplicaciones en la organización pueden hacer uso de sus interfaces si es necesario.
• Más escalable
• Obtiene todas las ventajas de Java EE.

Desventajas:

• Más de implementación compleja.
• Otro servidor para mantener y supervisar.
• Podría ser más lento ya que las llamadas se realizarán a través de la red aunque esto no debería ser un problema.

En ambos casos, si las interfaces de cambiar el código de cliente tendrá que cambiar por lo que este no es un factor en la decisión. Las transacciones deben manejarse en el nivel del método de servicio comercial, por lo que esto tampoco debería ser un factor.

Creo que depende del tamaño de las aplicaciones y de la escalabilidad de la solución para garantizar la complejidad adicional de la opción 2 anterior.