Cómo implementar acoplamiento flojo con una arquitectura SOA

Question

que he estado haciendo un gran trabajo de investigación últimamente sobre SOA y de ESB etc.

estoy trabajando en el rediseño de algunos sistemas heredados en el trabajo ahora y me gustaría construirlo con más de una arquitectura SOA de la que tiene actualmente. Utilizamos estos servicios en aproximadamente 5 de nuestros sitios web y uno de los mayores problemas que tenemos ahora con nuestro sistema heredado es que casi todo el tiempo cuando realizamos correcciones de fallas o actualizaciones necesitamos volver a implementar nuestros 5 sitios web que pueden ser un proceso bastante lento.

Mi objetivo es hacer que las interfaces entre servicios se acoplen poco para que se puedan realizar cambios sin tener que volver a implementar todos los servicios y sitios web dependientes.

Necesito la capacidad de extender una interfaz de servicio ya existente sin romper o actualizar ninguna de sus dependencias. ¿Alguno de ustedes ha encontrado este problema antes? ¿Cómo lo resolvió?

Answer 1

Te sugiero que busques un estilo diferente de servicios del que quizás has estado haciendo hasta ahora. Considere los servicios que colaboran entre sí utilizando eventos, en lugar de solicitar/responder. He estado utilizando este enfoque durante muchos años con clientes en diversas verticales con un gran éxito. He escrito bastante sobre estos temas en los últimos 4 años. Aquí es un lugar donde usted puede comenzar:

http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/

Espero que ayude.

Answer 2

Lo que estás preguntando no es un tema fácil. Hay muchas formas en que puede hacer que su arquitectura orientada a servicios se acople de manera flexible.

Sugiero revisar Thomas Erl SOA book series. Explica todo muy claramente y en profundidad.

Answer 3

Hay un par de enfoques que puede tomar. Nuestra arquitectura SOA involucra mensajes XML enviados ay desde los servicios. Una forma de lograr lo que describes es evitar el uso de una biblioteca de enlace de datos a nuestro esquema XML y usar un analizador XML genérico para obtener solo los nodos de datos que deseas ignorar aquellos en los que no estás interesado. De esta forma el servicio puede agregar nuevos nodos adicionales al mensaje sin romper a nadie que lo esté usando actualmente. Normalmente solo hacemos esto cuando necesitamos solo una o dos piezas de información de una estructura de esquema más grande.

Como alternativa, la otra solución (preferida) que utilizamos es el control de versiones. Una versión de un servicio se adhiere a un esquema/interfaz particular. Cuando el esquema cambia (por ejemplo, la interfaz se amplía o modifica), creamos una nueva versión del servicio. En cualquier momento, podemos tener 2 o 3 versiones en cualquier momento. Con el tiempo, desaprobamos y luego eliminamos las versiones anteriores, mientras que finalmente migramos el código dependiente a las versiones más recientes. De esta forma, los que dependen del servicio pueden continuar utilizando la versión existente del servicio, mientras que una dependencia particular puede 'actualizarse' a la nueva versión. Las versiones de un servicio que se llaman se definen en un archivo de configuración para el código dependiente. Tenga en cuenta que no solo el esquema obtiene la versión, sino también todo el código de implementación subyacente.

Espero que esto ayude.

Answer 4

Existen algunas prácticas comunes para lograr un acoplamiento flexible para los servicios.

1. Uso doc/estilo literal de servicios web, piense en los datos (el formato de alambre) en lugar de RPC, evitar datos basados ​​en el esquema de unión.

2. cumplir estrictamente el contrato cuando el envío de los datos, pero mantener unos supuestos procesamiento de datos entrantes, XPath es una buena herramienta para que (suelto en, apretado fuera)

3. Uso ESB y evitar cualquier punto directamente a señalar la comunicación entre servicios.

Answer 5

He aquí una lista aproximada para evaluar si su SOA implementa acoplamiento flojo:

• Localización del sistema de llamada (su dirección física): ¿Su aplicación utilizar URLs directos para acceder sistemas o es la aplicación desacoplada a través de una capa de abstracción que es responsable para mantener las conexiones entre los sistemas? El Registro de Servicios y el paradigma de grupo de servicio utilizado en SAP NetWeaver CE son buenos ejemplos de cómo podría ser una abstracción. El uso de un bus de servicio empresarial (ESB) es otro ejemplo. El punto es que la aplicación no debe codificar la dirección física del sistema llamado para que realmente se lo considere poco acoplado.

• Número de receptores: sí especifica la aplicación que los sistemas son los receptores de una llamada de servicio? Un compuesto débilmente acoplado no especificará los sistemas pero dejará la entrega de sus mensajes en una capa de implementación del contrato de servicio. Una aplicación acoplada estrechamente llamará explícitamente a los sistemas receptores en el orden ; una aplicación débilmente acoplada simplemente realiza llamadas a la interfaz de servicio y permite que la capa de implementación de contrato de servicio se encargue de los detalles de la entrega de mensajes a los sistemas correctos.

• disponibilidad de los sistemas: ¿Su aplicación requiere que todos los sistemas que se está conectando a estar en funcionamiento todo el tiempo? Obviamente, este es un requisito muy difícil, especialmente si desea conectarse a sistemas externos que no están bajo su control. Si la respuesta es que todos los sistemas deben estar ejecutándose todo el tiempo, la aplicación está estrechamente acoplada a este respecto.

• Formato de los datos: que hace la aplicación vuelva a utilizar los formatos de datos proporcionados por los sistemas back-end o ¿Está utilizando un sistema de tipo de datos canónica que es independiente de los sistemas de tipo utilizados en los llamados aplicaciones? Si está reutilizando los tipos de datos de los sistemas de fondo , probablemente tenga que lidiar con las conversiones de tipos de datos en su aplicación, y este enfoque no es muy flexible.

• Tiempo de respuesta: ¿Requiere la aplicación llama sistemas para responder dentro de un cierto periodo de tiempo o es aceptable para la aplicación a recibir una respuesta minutos, horas o incluso días después?