Cómo implementar un acoplamiento flexible con una arquitectura SOA

Question

Últimamente he estado investigando mucho sobre SOA y ESB, etc.

Estoy trabajando en el rediseño de algunos sistemas heredados en el trabajo ahora y me gustaría construirlos con una arquitectura más SOA de la que tiene actualmente.Usamos 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 corregimos errores o actualizamos, necesitamos volver a implementar nuestros 5 sitios web, lo que puede ser un proceso que lleva bastante tiempo.

Mi objetivo es hacer que las interfaces entre servicios estén ligeramente acopladas para que se puedan realizar cambios sin tener que volver a implementar todos los servicios y sitios web dependientes.

Necesito la capacidad de ampliar una interfaz de servicio ya existente sin interrumpir ni actualizar ninguna de sus dependencias.¿Alguno de ustedes ha encontrado este problema antes?¿Cómo lo solucionaste?

Answer 1

Yo sugeriría que buscan en un estilo diferente de servicios que tal vez usted ha estado haciendo hasta ahora. Considerar los servicios que colaboran entre sí mediante eventos, en lugar de petición / respuesta. He estado usando este método durante muchos años con clientes en diversos mercados verticales con una gran cantidad de é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

Hay un par de enfoques que puede adoptar.Nuestra arquitectura SOA implica mensajes XML enviados hacia y desde los servicios.Una forma de lograr lo que usted describe es evitando el uso de una biblioteca de enlace de datos a nuestro esquema XML y usando un analizador XML genérico para obtener solo los nodos de datos que desea, ignorando aquellos que no le interesan.De esta manera, el servicio puede agregar nuevos nodos adicionales al mensaje sin interrumpir a nadie que lo esté usando actualmente.Por lo general, solo hacemos esto cuando necesitamos solo uno o dos datos de una estructura de esquema más grande.

Alternativamente, 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 marcha al mismo tiempo.Con el tiempo, desaprobamos y luego eliminamos las versiones anteriores, mientras eventualmente migramos el código dependiente a versiones más nuevas.De esta manera, aquellos que dependen del servicio pueden continuar usando la versión existente del servicio mientras alguna 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 sólo se versiona el esquema, sino también todo el código de implementación subyacente.

Espero que esto ayude.

Answer 3

Lo que estamos pidiendo no es un tema fácil. Hay muchas maneras de ir sobre la fabricación de su Arquitectura Orientada a Servicios acoplada débilmente.

Yo sugiero revisar de Thomas Erl SOA serie de libros . En él se explica todo muy claramente y en profundidad.

Answer 4

Hay algunas pratices comunes para lograr la articulación flexible de servicios.

1. Uso doc / estilo literal de servicios web, piense en los datos (el formato de alambre) en lugar de RPC, evitar el esquema basado en el enlace de datos.

2. acatar estrictamente el contrato cuando el envío de los datos, pero mantener unos supuestos procesamiento de datos entrantes, XPath es una buena herramienta para eso (suelto en, bien cerrado)

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

Answer 5

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

• Ubicación del sistema de llamada (su dirección física): ¿Su URL de uso de aplicaciones directas para acceder a los sistemas o es el desacoplado aplicación a través de una capa de abstracción que es responsable para el mantenimiento de las conexiones entre los sistemas? El Registro de Servicios y el paradigma grupo de servicio utilizado en SAP NetWeaver CE son buenos ejemplos de lo que tal abstracción podría ser similar. el uso de una bus de servicios empresariales (ESB) es otro ejemplo. El caso es que la aplicación no debe codificar la dirección física de la llamado sistema con el fin de realmente ser considerado débilmente acoplado.

• Número de receptores: ¿La aplicación especifica cuáles son los sistemas los receptores de una llamada de servicio? A no voluntad compuesto débilmente acoplado especificar sistemas particulares, pero saldrá de la entrega de su mensajes a una capa de aplicación contrato de servicio. Un bien aplicación acoplado será llamar explícitamente los sistemas de recepción en orden; una aplicación débilmente acoplados simplemente hace que las llamadas a la interfaz de servicio y permite la ejecución del contrato de servicios la capa de cuidar de los detalles de la entrega de mensajes a la derecha sistemas.

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

• Formato de los datos: ¿La aplicación de la reutilización de los formatos de datos proporcionados por los sistemas de back-end o ¿Está utilizando un sistema de tipo de datos canónica que es independiente de los sistemas de tipo utilizados en la llamada aplicaciones? Si se vuelve a utilizar los tipos de datos de backend sistemas, es probable que tenga que luchar con las conversiones de tipos de datos en su aplicación, y esto no es un enfoque muy imprecisa.

• Tiempo de respuesta: ¿Requiere la aplicación denominan sistemas para responder dentro de un cierto marco de tiempo o es aceptable para la aplicación a recibir una respuesta minutos, horas, días o incluso más tarde?