SOA y bases de datos compartidas

No entiendo SOA (Arquitectura orientada a servicios) y bases de datos. Aunque me atrae el concepto SOA (encapsulando la lógica comercial reutilizable en servicios) no puedo entender cómo se supone que debe funcionar si otros servicios/sistemas requieren tablas de datos encapsuladas en un servicio, o si es SOA adecuado en absoluto en este escenario?SOA y bases de datos compartidas

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

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

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

Investigando un poco, he encontrado algunas soluciones propuestas:

Use replication para hacer una copia local de los datos requeridos cuando sea necesario. Pero luego no hay encapsulamiento y entonces ¿para qué sirve SOA? Esto se discute en on StackOverflow pero no hay un consenso claro.
Configure un Master Data Service que encapsula todos los datos de la base de datos. Supongo que sería monstruoso (con esencialmente una llamada API para cada procedimiento almacenado) y requiere actualizaciones todo el tiempo. Para mí, esto parece estar relacionado con el concepto enterprise data bus.

Si tiene alguna información al respecto, háganmelo saber.

Editar: 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 RESTful en su lugar.

Fuente

2011-11-16 Gruber

Tu edición hace absolutamente ningún sentido. Los servicios RESTful son una cuestión de diseño de API, y tener servicios individuales en realidad empuja las cosas hacia SOA. Entonces, su comentario acerca de pasar de SOA a REST es similar a decir pasar de comer plátanos a usar relojes de alarma. – Max

Gracias por la entrada, pero no estoy seguro de estar de acuerdo con usted. Desde los albores de la evolución de la arquitectura orientada a servicios (SOA), SOA se ha comparado y contrastado con el modelo de la interfaz RESTful. [SearchSOA] (http://searchsoa.techtarget.com/tip/SOA-and-RESTful-interfaces-When-why-they-sould-beould-combined) - Gruber hace 24 minutos – Gruber

También verifique esto: http: // martinfowler.com/articles/enterpriseREST.html#bounded-contexts –

Uno de los principios definitorios de un "servicio" en este contexto es que posee, absolutamente, los datos en el área de la 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, anula esa responsabilidad. O bien, usted replica las reglas del negocio, o eventualmente terminará en una situación en la que termina necesitando el otro servicio actualizado para cambiar sus reglas internas.

El uso de un solo servicio de datos es simplemente "no hacer SOA"; si tiene un solo lugar que gestiona todos los datos, no tiene servicios independientes, solo tiene un servicio.

Sugeriría, en cambio, la tercera opción: utilice la composición para juntar esos datos, evitando por completo la operación de JOIN de nivel de base de datos.

En lugar de pensar acerca de la necesidad de unirse a esos dos valores en la base de datos, piensa acerca de cómo componer juntos en los bordes:

Cuando procesa una página HTML para un cliente, se puede suministrar HTML desde múltiples servicios y los componen visualmente uno al otro: los detalles del cliente provienen del servicio al cliente y los detalles del pedido del servicio de pedido.

Del mismo modo que un correo electrónico de factura: compone visualmente los datos suministrados desde múltiples servicios, sin necesidad de la unión en la base de datos.

Esto tiene dos ventajas: una, se 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, puede cambiar más fácilmente el exterior de su aplicación. Si tiene piezas pequeñas y compostables, puede agregar fácilmente reorganizar las piezas de formas nuevas.

Fuente

2011-11-17 03:30:57

Al buscar pistas, no encontré tu idea, es un enfoque interesante. Si pudiera eliminar la necesidad de 'UNIRSE', no surgiría el problema original. Sin embargo, en mi caso, el 'JOIN' parece difícil de eludir ya que el resultado no es para fines de presentación. Pero lo pensaré un poco. Algo crucial que usted señala es que ** un servicio debe poseer sus propios datos ** y operaciones asociadas. Ha habido desacuerdo sobre eso en [otros hilos] (http://stackoverflow.com/questions/4019902/soa-joining-data-across-multiple-services). ¡Gracias por responder! – Gruber

Udi Dahan tiene un blog aquí: http://www.udidahan.com/ - su trabajo ha sido muy valioso para dar forma a mis puntos de vista sobre el tema, y encontrará mucha más información valiosa allí. –

¿Está sugiriendo que el servicio al cliente solo puede acceder a los datos del cliente y que el servicio de pedidos solo puede acceder a los datos del pedido? No he visto ninguna mención de esto en los libros de Thomas Erl. Por favor, ¿podría proporcionar una referencia? –

El principio rector es que se pueden almacenar datos inmutables Esto significa que pueden existir datos inmutables de la entidad del cliente en el servicio de pedido y no hay necesidad de ir al servicio de atención al cliente cada vez que necesite la información. Romper todo a servicios aislados y luego hacer siempre estas llamadas a procedimientos remotos ignora el fallacies of distributed computing. Si tiene muchas necesidades de informes, necesita crear un servicio adicional. Llamo a ese servicio de Informes Agregados, que, de nuevo, obtiene datos de solo lectura para fines de informes. Puede ver un artículo I wrote about that for InfoQ hace unos años

Fuente

2011-11-18 10:30:47

Leí tu artículo. Gran lectura. Supongo que el almacenamiento en caché de los datos de otros servicios combinados con el mecanismo impulsado por eventos que describes funcionaría. Para los servicios cuyos datos no cambian a menudo, creo que podría salirse con la tarea de permitir que los servicios actualicen sus cachés una vez por noche, lo que eliminaría la complejidad del manejo de eventos. – Gruber

Es posible que desee comprobar patrones complementarios como CQRS http://martinfowler.com/bliki/CQRS.html –

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 esa orden.

Además, esta cuestión de la mina puede ser útil:

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

Fuente

2011-12-01 13:29:58

Gracias. Parece que las personas tienen diferentes puntos de vista sobre esto. Si, por ejemplo, replico la 'tabla de datos' CustomerService' Customers' (por razones de rendimiento) a 'OrderService', termino con un problema de" spaghetti "si el diseño de' Customers' necesita cambiar --- I luego tiene que actualizar el código de 'OrderService'. Y con SOA eso es de lo que quiero alejarme. – Gruber

@ user1035411 No creo que deba replicar los datos. Simplemente creo que el servicio Order debería tener acceso a los datos de los Servicios al Cliente. Otra cosa a tener en cuenta es que puede querer una tabla de clientes para el servicio de pedidos que contendría datos de clientes que son relevantes solo para el servicio de pedidos. El nombre del cliente sería utilizado por muchos servicios, por lo que permanecería en el cliente. pero el límite de crédito tal vez podría ser un candidato para el servicio de pedido? Esto evitaría que el diseño de los clientes cambie con demasiada frecuencia. –

Quiero cumplir el principio de SOA de que los servicios solo hablan a través de sus interfaces, por lo que nunca tengo que actualizar otros servicios si uno se cambia internamente. Estoy de acuerdo con usted en que los servicios pueden necesitar almacenar datos de otros servicios. El problema es el rendimiento y cómo actualizar los datos en caché. La obtención de grandes cantidades de datos a través de SOAP/XML produce una gran carga de red, mientras que la replicación suele ser bastante fluida. Como la replicación rompe el principio SOA, creo que voy a intentarlo de otra manera y, como usted sugiere, solo almacenaré una cantidad mínima de datos. – Gruber

Respuesta

Cuestiones relacionadas