SOA: uniendo datos a través de múltiples servicios

Question

Imagine que tenemos 2 servicios: Producto y orden. Según mi conocimiento de SOA, sé que cada servicio puede tener su propio almacén de datos (una base de datos separada o un grupo de tablas en la misma base de datos). Pero ningún servicio puede tocar el almacén de datos de otro servicio directamente.

Ahora imagine que hemos almacenado el producto y pedido los datos de forma independiente dentro de los Servicios de productos y pedidos. En el Servicio de pedidos, podemos identificar los productos por su ID.

Mi pregunta es: Con esta arquitectura, ¿cómo puedo mostrar la lista de pedidos y detalles del producto en la "misma" página?

Según tengo entendido, debería obtener la lista de artículos de pedido de OrderService. Cada OrderItem tiene un ProductID. Ahora, si hago una llamada por separado a ProductService para recuperar los detalles de cada Producto, eso sería muy ineficiente.

¿Cómo abordaría este problema?

Saludos, Mosh

Answer 1

Hice algunas investigaciones y encontré 2 soluciones diferentes para esto.

1- Los servicios pueden almacenar en caché los datos de otros Servicios localmente. Pero esto requiere un mecanismo de pub/sub, por lo que cualquier cambio en el origen de los datos debe publicarse para que los Servicios suscriptores puedan actualizar su caché local. Esto es costoso de implementar, pero es la solución más rápida porque el Servicio tiene los datos requeridos localmente. También aumenta la disponibilidad de un Servicio impidiendo que dependa de los datos de otros Servicios. En otras palabras, si el otro servicio no está disponible, aún puede hacer su trabajo por sus datos de caché.

2- Alternativamente, un Servicio puede consultar una "lista" de objetos de otro Servicio suministrando una lista de identificadores. Esto evita que se realice una llamada por separado al servicio objetivo para obtener los detalles de un objeto determinado. Esto es más fácil de implementar pero en lo que respecta al rendimiento, no es tan rápido como la solución 1. Además, en caso de que el Servicio objetivo no esté disponible, el Servicio de origen no puede hacer su trabajo.

Espero que esto ayude a otros que se han encontrado con este problema.

Mosh

Answer 2

SOA es sólo una expresión de moda, para el despliegue de componentes detrás de los servicios web. ¿Cuántas tiendas de datos tiene usted? En algunos casos, tiene sentido tener datos particionados detrás de componentes individuales, y en otros casos, todos los datos están detrás de un servicio y en otros casos muchos componentes que exponen interfaces de servicio se conectan a la misma base de datos a través del protocolo de conexión de la base de datos. Aborde el problema abordando el problema, no imponiendo restricciones artificiales.

Answer 3

No creo que haya ningún principio en SOA que los servicios deberían tener un almacén de datos por separado. En general, es realmente poco práctico. Sí, puede tener un servicio de pedidos y productos, y el cliente puede hacer la unión usando la llamada de servicio web como dijo, y esto puede ser aceptable en algunos casos. Pero eso no significa que no pueda tener un servicio específico para un cliente si ya conoce el comportamiento y los requisitos de rendimiento del cliente.
Lo que quiero decir es que debe tener un servicio de búsqueda que devuelva pedidos y productos con la unión hecha en la base de datos. Esto es práctico y resolvería su problema comercial.

Answer 4

Otro enfoque sería tener algún tipo de fuente de datos que vive fuera de los servicios SOA. Esta fuente de datos podría considerarse su caché de datos, su fuente de datos operacionales o incluso un depósito de datos.Los paquetes de extracción pueden exportar los datos de los servicios (y/o algún tipo de mecanismo en tiempo real). Puede consultar esta fuente de datos como lo desee.

La ventaja de este enfoque es que la caja negra SOA se mantiene y puede cambiar un servicio sabiendo cómo lo ha acoplado.

La desventaja es la complejidad añadida y la sobrecarga de mantenimiento.

Answer 5

La integración de bases de datos (que es realmente de lo que está hablando cuando dos servicios comparten una tabla en un DB) es incorrecta en muchos niveles. Es completamente rompe algunos de los principales principios de la ingeniería de software

acoplamiento débil, encapsulación separación de las preocupaciones

de mantenimiento debe de (para ganar ese nombre) completamente independiente, a saber:

1. no debe confiar en otros para garantizar la coherencia y coherencia de sus datos
2. no debe confiar en otros para garantizar la seguridad de sus datos
3. no debe depender de implementaciones externas (solo interfaces)

Dos servicios que comparten datos en el nivel DB no pueden garantizar ninguno de los anteriores.

El hecho de que "controle" ambos servicios es completamente irrelevante. Hoy usted controla ... mañana es posible que desee externalizar o reemplazar uno de los servicios. Eso debería ser tan simple como asegurar que las interfaces apropiadas estén en su lugar.

Imagina ambos servicios que comparten una tabla con algún campo (varchar) en ella. Ahora un servicio necesita cambiar ese campo a numérico ... bang el otro servicio deja de funcionar - el acoplamiento flojo se va por el desagüe.

La mayoría de las veces el truco consiste en definir correctamente el alcance del servicio y estipular claramente qué hace y qué no hace un servicio. También debe evitar convertir todo en un servicio. Establezca la granularidad de su servicio en un nivel alto y los servicios comenzarán a aparecer en todas partes y los dolores de cabeza en la integración aumentarán.

Dicho esto, hay algunas situaciones en las que la integración de datos entre servicios presenta algunos desafíos. La premisa principal es, debería ser siempre, que los datos solo pueden pertenecer a un servicio. Los datos están intrínsecamente ligados a la lógica comercial que afecta la consistencia y coherencia de los datos y, como tal, nunca debe haber más de un servicio que controle cualquier dato dado.

Answer 6

Es desafortunado ver que toda esta discusión se está deteriorando en una búsqueda de enunciado "¿Puedo usar una base de datos compartida o no en SOA?", Que es totalmente irrelevante y no ayuda a responder la pregunta original en absoluto.

Más de una vez en una situación real, los datos ya están almacenados en diferentes sistemas para comenzar. Los datos del cliente, por ejemplo, provienen de CRM, datos de productos de SAP, y datos contratados de otra fuente diferente.

No es una búsqueda para obtener estos datos técnicamente juntos, en lugar de entender que solo hay una fuente de datos. Para decirlo de otra manera, solo hay un propietario de los datos dentro de su empresa, que es el único responsable de mantenerlo y garantizar la calidad de los datos correctos.

Almacenar datos localmente por motivos de rendimiento significa replicar datos, lo que a menudo es una aventura peligrosa, a menos que tenga una sólida estrategia de almacenamiento en caché. Creo que Mosh ha dado algunas respuestas sensatas cuando se enfrenta con un panorama de aplicaciones existente.