SOA Style - Compartir datos

Question

Estoy considerando una arquitectura SOA para un conjunto de servicios para apoyar un negocio que estoy consultando, anteriormente utilizamos la integración de bases de datos donde cada aplicación seleccionaba lo que necesitaba de una base de datos MS SQL compartida y funcionaba con él, etc. Tuvimos varias aplicaciones que se integraban con la base de datos de monstruos, incluidos java, .net y Microsoft Access, existía integridad referencial, ya que todo estaba estrechamente vinculado.

Estoy un poco confundido acerca de cómo admitir el intercambio de datos entre servicios.

Permite tomar el servicio de productos que se encuentra sobre la base de datos de productos proporcionada por el mayorista cada mes. Construimos un modelo de dominio y lo sentamos en la base de datos con Hibernate o lo que sea, el producto de implementación es un gran gráfico de objetos dada la información proporcionada por el mayorista sobre el producto.

Ahora digamos que el servicio de revisión, servicio de precios, servicio de envío y Stock Service se suscribirán a ProductUpdated, ProductAdded, ProductDeleted. El problema es que cada servicio solo necesita una parte o parte de la información sobre el Producto. El envío puede necesitar solo las dimensiones y el peso. Los precios solo pueden necesitar la identificación del producto, el costo mayorista, el descuento por volumen y el precio vigente hasta la fecha. La revisión puede necesitar identificación del producto, nombre del producto, productor. Es una práctica estándar publicar todo el producto (contratos adecuados no específicos del suscriptor, por ejemplo, ProductUpdated, y un esquema adecuado que representa todos los gráficos del objeto del producto) y permite a los suscriptores asignar lo que necesitan a sus modelos de dominio (o diablos hacer lo que quieran con, ni siquiera podría tener un modelo de dominio) ...

O mientras escribo esto estoy pensando que tal vez:

Servicio Producto Publica ProductAdded mensaje (no incluidos los detalles del producto sólo una ID del producto y tal vez una marca de tiempo)

Servicio de precios su bscribes a ProductAdded y publica RequestPricingForProduct mensaje

Servicio Producto publica mensaje ResultForPricingForProduct

Hmm .. parece un poco mejor ... pero se siente como que estoy construyendo el contrato para el servicio del producto en base a qué otros servicios que puedo identificar y lo que van a necesitar, tal vez en el futuro el servicio XYZ requiera algo diferente. Voy a detenerme allí porque creo que se está aclarando dónde estoy confundido ... quizás lo anterior funcionará porque debería exponer una forma de devolver lo que sea que sea público.

Cualquier comentario o dirección muy apreciada. Lo siento si esto parece medio cocido.

Answer 1

Estuve recientemente en tu puesto. El problema de exponer directamente el objeto subyacente a través del servicio es que aumenta el acoplamiento entre capas, y no tiene mucho sentido utilizar una arquitectura orientada a servicios. No podrá cambiar estos objetos o reglas comerciales sin afectar también el servicio web.

Parece que está en el camino correcto. Si realmente quiere separar sus capas, el patrón más común es crear un nuevo conjunto separado de clases de mensajes solo para el servicio web, potencialmente cada servicio, y traducir sus objetos internos hacia adelante y hacia atrás.

Para ver un ejemplo de cómo configurar su capa de servicio de esta manera, consulte el patrón "Interfaz de servicio". En el lado del cliente del servicio, hay un patrón opuesto llamado "Service Gateway".

Application Architecture Guide 2.0 tiene un capítulo completo dedicado a los tipos de decisiones que está tomando (http://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines). Me gustaría descargar toda la guía.

Aquí está la parte más relevante para usted. Para resumir, si se toma el tiempo para crear nuevos métodos de grano grueso, y objetos basados ​​en mensajes, que va a terminar con un servicio mucho mejor web:

cuenta las siguientes pautas en el diseño de una interfaz de servicio : Considere utilizar una interfaz de grano grueso para solicitudes por lotes y minimizar el número de llamadas a través de la red. Diseñe interfaces de servicio de tal manera que los cambios en la lógica de negocios no afecten a la interfaz. No implemente reglas de negocio en una interfaz de servicio. Considere utilizar formatos estándar para parámetros para proporcionar la máxima compatibilidad con diferentes tipos de clientes. No haga suposiciones en el diseño de su interfaz sobre la forma en que los clientes utilizarán el servicio. No use la herencia de objetos para implementar el control de versiones para la interfaz de servicio.

Answer 2

Creo que la solución a este problema es NO compartir los datos. SOA significa que los datos son propiedad de un servicio; es la autoridad técnica de esos datos. Sugiero leer algunos artículos de Pat Helland, como Data On The Inside, Data On The Outside.

Lo único que debe ser compartida entre estos diferentes servicios es la clave principal - la ProductId en su ejemplo. De lo contrario, para cada servicio, los datos que deben ser coherentes con las transacciones van de la mano.

No es necesario que haya un "Producto". Cada servicio puede tener una vista diferente del producto en su servicio. Para el servicio de fijación de precios, tiene un ID de producto y un precio. Para el servicio de revisión, una ID de producto y una revisión. Y así.

Cuando esto empieza a confundir a la gente es cómo mostrar estos datos en la interfaz de usuario si es de todos estos servicios dispares. ¿Cómo puede mostrar una lista de revisiones para un producto que tiene el nombre del producto del ProductService y el texto de revisión del ReviewService?

La respuesta a esto es para componer la interfaz de usuario de todos los diferentes servicios. Obtenga el producto del servicio del producto y obtenga los datos de revisión del servicio de revisión y luego combine esos datos en la IU.