database - SOA y bases de datos compartidas

shared

Question

No entiendo SOA (Arquitectura Orientada a Servicios) y bases de datos. Si bien me atrae el concepto SOA (que encapsula la lógica de negocios reutilizable en los servicios) no puedo entender cómo se supone que funciona si las tablas de datos encapsuladas en un servicio son requeridas por otros servicios / sistemas, o si la SOA es adecuada para todo en este escenario?

Para ser más concretos, supongamos que tengo dos servicios:

• CustomerService : contiene la tabla de mi base de datos de Customers y la lógica comercial asociada.
• OrderService : contiene mi tabla de Orders y lógica.

Ahora, ¿qué sucede si necesito JOIN las tablas de Customers y Orders con una declaración SQL? Si las tablas contienen millones de entradas, se obtendría un rendimiento inaceptable si tuviera que enviar los datos a través de la red utilizando SOAP / XML. ¿Y cómo realizar el JOIN ?

Haciendo un poco de investigación, he encontrado algunas soluciones propuestas:

• Use la replicación para hacer una copia local de los datos requeridos donde sea necesario. Pero luego no hay encapsulación y, ¿cuál es el punto de usar SOA? Esto se discute en StackOverflow pero no hay un consenso claro.
• Configure un Servicio de Datos Maestros que encapsule todos los datos de la base de datos. Supongo que obtendría un tamaño de monstruo (esencialmente con una llamada a la API para cada procedimiento almacenado) y requeriría actualizaciones todo el tiempo. Para mí esto parece estar relacionado con el concepto de bus de datos empresariales .

Si tiene alguna entrada sobre esto, por favor hágamelo saber.

Edit: Ha pasado un año y mi interés en SOA ha disminuido, al igual que la popularidad del concepto en general. Hoy en día, las personas parecen querer enfocarse en los servicios REST.

Answer 1

El principio rector es que está bien almacenar en caché datos inmutables. Esto significa que pueden existir datos simples e inmutables de la entidad del cliente en el servicio de pedidos y no hay necesidad de acudir al servicio al cliente cada vez que necesite la información. Romper todo a servicios aislados y luego hacer estas llamadas a procedimientos remotos ignora las falacias de la computación distribuida . Si tiene necesidades de informes extensas, necesita crear un servicio adicional. Llamo a ese servicio de informes agregados, que, de nuevo, obtiene datos de solo lectura para fines de informes. Puedes ver un artículo que escribí sobre eso para InfoQ hace unos años.

Answer 2

En la pregunta de SO que citó, varias personas afirman que está bien que un servicio acceda a otros datos de servicios, por lo que el servicio de pedidos podría tener una funcionalidad GetAllWithCustomer, que devolvería todos los pedidos junto con los detalles del cliente para ese pedido.

Además, esta pregunta mía puede ser útil:

https://softwareengineering.stackexchange.com/questions/115958/is-it-bad-practice-for-services-to-share-a-database-in-soa

Answer 3

Uno de los principios definitorios de un "servicio" en este contexto es que posee, absolutamente, los datos en el área de los que es responsable, así como las operaciones sobre esos datos.

La copia de datos, a través de la replicación o cualquier otro mecanismo, cede esa responsabilidad. O bien reproduce las reglas de negocios, o eventualmente terminará en una situación en la que terminará necesitando el otro servicio actualizado para cambiar sus reglas internas.

Usar un solo servicio de datos es solo "no SOA"; Si tiene un solo lugar que administra todos los datos, no tiene servicios independientes, solo tiene un servicio.

Yo sugeriría, en cambio, la tercera opción: usar la composición para juntar esos datos, evitando por completo la operación UNIR del nivel de base de datos.

En lugar de pensar en la necesidad de unir esos dos valores en la base de datos, piense en cómo componerlos juntos en los bordes:

Cuando representa una página HTML para un cliente, puede suministrar HTML desde múltiples servicios y redactarlos visualmente: los detalles del cliente provienen del servicio al cliente y los detalles del pedido del servicio de pedidos.

Del mismo modo, un correo electrónico de factura: componga datos suministrados desde múltiples servicios visualmente, sin necesidad de unirse a la base de datos.

Esto tiene dos ventajas: una: elimina la necesidad de unirse a la base de datos e incluso la necesidad de tener los datos almacenados en el mismo tipo de base de datos. Ahora, cada servicio puede usar cualquier almacén de datos que sea más apropiado para su necesidad.

Dos, puedes cambiar más fácilmente el exterior de tu aplicación. Si tiene partes pequeñas y compuestas, puede agregar fácilmente reorganizar las partes de nuevas maneras.