Enfoques para la integración de aplicaciones Enterprise Service Bus. Funcionalidad DATAREON ESB

La integración de aplicaciones es un problema al que tarde o temprano se enfrenta el departamento de TI de cualquier organización que tenga más de una de estas aplicaciones. Aquí hay una lista lejos de ser completa de tareas que encajan en el concepto de "integración":

• la necesidad de mantener directorios generales (por ejemplo, directorios de clientes o empleados);
• iniciar actividades en un sistema de información cuando ocurren eventos en otro;
• proceso de negocio (una secuencia organizada de acciones realizadas tanto por personas como por sistemas de información) que ocurre en varias aplicaciones;
• interacción de información con socios comerciales (por ejemplo, solicitud automática de precios de componentes al proveedor);
• unificación de intercambios de información y procesos comerciales en las sucursales de la empresa.

Si este tipo de acción ocurre rara vez en una empresa (por ejemplo, una vez al día), entonces estas acciones se pueden organizar de manera improvisada, por ejemplo, cargando manualmente datos de una aplicación en formato Excel y cargándolos en otra aplicación. o incluso utilizando la entrada de información duplicada en dos sistemas a la vez. Sin embargo, si la necesidad de interacción de información entre aplicaciones surge muchas veces al día, entonces surge la cuestión del uso ineficaz de los recursos humanos y, como consecuencia, surge la necesidad de automatizar este procedimiento.

Integración punto a punto

La tarea de la integración punto a punto es relativamente sencilla. Es necesario comprender cómo cada uno de los dos sistemas que interactúan está listo para transmitir y recibir datos, crear soluciones técnicas apropiadas para acceder a estas interfaces y también implementar un mecanismo para convertir datos del formato del sistema de origen al formato del sistema de destino. En el mejor de los casos, los sistemas de información proporcionan una interfaz de programación especial (API) para la integración y, en el peor de los casos, la información debe leerse y escribirse directamente en la base de datos de la aplicación. Como resultado, surge una solución de integración local: un módulo de software independiente de diseño propio con todos los requisitos consiguientes para su mantenimiento y conservación de su relevancia.

Integración punto a punto

Esto no es un gran problema siempre que haya pocas integraciones punto a punto: una o dos. Sin embargo, la práctica muestra que el número de integraciones punto a punto tiende a aumentar y la calidad de la gestión de estas integraciones, por el contrario, disminuye rápidamente. Las razones para esto son muchas: el número de módulos de integración está aumentando, los desarrolladores que crearon uno u otro módulo abandonan la organización, los formatos de datos en los sistemas integrados están cambiando, etc. El triste resultado del desarrollo evolutivo de las integraciones punto a punto es la "carne picada" más compleja de las interacciones de integración entre aplicaciones empresariales, cuya actitud de los empleados del departamento de TI se puede expresar más fácilmente en pocas palabras: "Mientras Funciona, es mejor no tocarlo”. Sin embargo, esta situación no conviene ni al propio departamento de TI ni a los clientes empresariales.

Relleno de integración

Autobús de servicio único

Después de experimentar varias generaciones de diferentes enfoques para la integración de aplicaciones, la industria global del software ha llegado al concepto de un único Enterprise Service Bus (ESB). Desde un punto de vista arquitectónico, un ESB es una solución de software que garantiza que todas las aplicaciones integradas interactúen a través de un único punto, de manera uniforme, proporcionando a los desarrolladores y administradores un medio unificado y centralizado para desarrollar, probar y monitorear el progreso de todos los escenarios de integración.

Los principales componentes que componen un autobús de servicio moderno son:

• un intermediario de mensajes es una columna vertebral de alto rendimiento para intercambiar mensajes en un formato unificado entre aplicaciones en tiempo real;
• adaptadores: los adaptadores tecnológicos y los adaptadores para sistemas empresariales brindan interacción con las aplicaciones en un formato que les resulta aceptable, presentando la información de estos mensajes en un formato unificado percibido por el corredor: cuantos más adaptadores diferentes proporcione una plataforma de integración en particular, mayores serán las posibilidades que su implementación en su organización no requerirá trabajo adicional para crear adaptadores específicos para sus sistemas;
• entorno para desarrollar escenarios de integración: cuanto más simple y rápido sea el desarrollo de escenarios de integración, menor será la inversión en este desarrollo y, por lo tanto, más rápido será el retorno de la inversión. El moderno bus de integración proporciona al desarrollador herramientas visuales para construir escenarios de integración, que en la mayoría de los casos permiten prescindir de la codificación de bajo nivel;
• Herramientas SOA: el cumplimiento de los principios de la arquitectura orientada a servicios es un estándar incondicional para todas las soluciones de integración del tipo "bus de servicio único" (como su nombre lo indica). Los sistemas de información son considerados aquí como proveedores y consumidores de servicios; todos los servicios publicados en el autobús se colocan en un registro único con capacidad de reutilización y gestión de políticas asociadas a los servicios;
• diversas herramientas de control y gestión (auditorías, logs, seguimiento centralizado, seguimiento del cumplimiento de acuerdos de nivel de servicio, etc.).

Las ventajas de utilizar un único autobús de servicio incluyen:

• escalamiento: la capacidad de crear soluciones de cualquier tamaño y carga;
• flexibilidad: la capacidad de implementar y cambiar escenarios de integración sin una participación significativa de los desarrolladores;
• seguridad: las herramientas integradas de autenticación y autorización brindan control de acceso a los servicios a nivel del propio bus, liberando a los desarrolladores de escenarios de integración de la tarea de implementar estos mecanismos;
• el uso de estándares abiertos: reduce la participación de costosos especialistas en tecnologías patentadas;
• centralización de herramientas de control y administración: le permite evitar "desdibujar" el punto de responsabilidad de los escenarios de integración, garantizar el monitoreo operativo y la alerta temprana en caso de fallas.

Otro requisito importante para la funcionalidad de un entorno ESB es la capacidad de implementar la integración con organizaciones externas: socios comerciales, proveedores, clientes corporativos, sucursales remotas. Las características de dicha integración son la calidad impredecible de los canales, la falta de garantías de entrega de información y la mala preparación para la integración como tal; por regla general, la organización asociada ofrece una gama muy limitada de formatos de intercambio de datos. En este caso, el bus de integración debe contener una herramienta para construir la interacción B2B que permita el intercambio de información de acuerdo con estándares abiertos, incluidos los de la industria, garantice la entrega garantizada, tenga los medios para configurar el intercambio de información en el contexto de un socio comercial específico y, por supuesto, Por supuesto, trabajar en total conformidad con los principios de la propia plataforma de integración, aislando al desarrollador de escenarios de integración de los detalles técnicos de la interacción con el socio.

Autobús de servicio empresarial

Gestión de procesos de negocio

Una proporción significativa de escenarios de integración implica que el intercambio de información involucra no solo aplicaciones que actúan como fuentes o receptores de información, sino también personas: empleados de la organización que realizan diversas tareas o toman decisiones. En este caso, podemos hablar de ir más allá de la integración "pura" y del surgimiento de una nueva entidad en el foco de nuestra atención: los procesos de negocio, y en los requisitos para la plataforma de integración, una nueva funcionalidad para la gestión de procesos de negocio (Business Process Management). , BPM). Si existen requisitos BPM, la plataforma de integración debe proporcionar al desarrollador:

• una herramienta para el diseño visual de procesos comerciales: lo óptimo es que estas herramientas puedan ser utilizadas por personas alejadas de TI, por ejemplo, analistas comerciales o metodólogos. Además, la capacidad de transferir modelos de procesos de negocio desde herramientas de modelado especializadas al entorno de desarrollo es extremadamente útil. La misma herramienta debería permitir diseñar formularios de tareas para los participantes en el proceso, protegiendo al máximo a los desarrolladores de la programación;
• entorno de ejecución de procesos de negocios: un motor especial que proporciona procesamiento de reglas de negocios, transferencia de tareas entre usuarios y sistemas de información de acuerdo con modelos de procesos de negocios desarrollados, así como procesamiento de situaciones excepcionales (por ejemplo, el ejecutor excede el tiempo asignado para completar una tarea);
• portal de participantes en procesos de negocio: un portal especializado que permite a los usuarios iniciar procesos, participar en ellos, monitorear el progreso de los procesos en ejecución y realizar acciones administrativas de acuerdo con los derechos establecidos para ellos;
• herramientas de seguimiento y control. La capacidad de analizar rápida y retrospectivamente el flujo de los procesos de negocio es una parte importante de cualquier plataforma BPM.

Muchos proveedores de software ahora están optando por combinar el marco BPM y el bus de integración en una única plataforma de middleware, eliminando la estricta separación que ha existido durante varios años entre los sistemas BPM y las herramientas de integración de aplicaciones. Este enfoque es muy progresista. Algunos proveedores van aún más allá y agregan herramientas profesionales de modelado de procesos comerciales a la plataforma. Software AG es pionero en esto con una solución que combina la reconocida herramienta de modelado ARIS Platform y el entorno de integración/BPM de webMethods.

Uso integral de la plataforma de integración.

Ofertas en el mercado

Actualmente, existen tres grupos de ofertas de software para crear ESB. Estos grupos varían tanto en precio como en funcionalidad ofrecida.

El primer grupo está formado por propuestas de empresas cuyos productos son líderes en la investigación de agencias analíticas en todas las categorías indicadas en el artículo (ESB, SOA Governance, BPM, B2B). Este grupo incluye:

• IBM con su línea de productos WebSphere;
• Software AG con plataforma de integración webMethods;
• Oracle con toda una serie de propuestas;
• Tibco con línea de Integración Empresarial.

En principio, aquellos a quienes no les gustan los compromisos pueden elegir cualquiera de estos fabricantes: todas las empresas que cotizan en bolsa ofrecen líneas de productos completas (sin embargo, en el caso de Oracle, no siempre está claro de qué producto estamos hablando, ya que después Al comprar varias empresas, Oracle ofrece inmediatamente varios productos, no siempre suficientemente integrados entre sí). Tibco se distancia un poco, ya que el tamaño de esta empresa es mucho menor que el de los demás miembros de este cuatro, lo que puede generar algunas dudas sobre su estabilidad. Software AG aún no es un fabricante muy conocido en el mercado ruso, pero la plataforma webMethods, que hoy es la oferta clave de esta empresa, tiene un gran potencial. IBM y sus productos ya son conocidos y utilizados por muchas empresas, pero algunas de ellas tienen quejas sobre el coste de implementación y mantenimiento del sistema.

El segundo grupo de propuestas son empresas que se centran principalmente en la funcionalidad ESB "pura" y han logrado éxito en este ámbito. Este grupo incluye: Sun (Glassfish), Progress (Sonic) y Fujitsu.

Las ofertas de estas empresas son buenas si no pretendes ampliar el alcance de tu plataforma hacia BPM y/o B2B. De lo contrario, corre el riesgo de quedarse con una funcionalidad insuficientemente desarrollada y aumentar significativamente los costos para mejorarla y satisfacer sus necesidades.

El tercer grupo es el más numeroso e incluye todas las propuestas no incluidas en los dos grupos anteriores. No tiene sentido enumerar todas las propuestas sobre el tema ESB en este artículo; puede obtener una lista de este tipo en cualquier motor de búsqueda. Si su presupuesto para la integración es limitado y está dispuesto a experimentar, puede probar suerte con cualquiera de ellos. Sin embargo, usted asume los riesgos relacionados tanto con una funcionalidad insuficientemente desarrollada como con posibles problemas con la confiabilidad, el soporte técnico y las perspectivas de desarrollo del producto.

Conclusión

En conclusión, me gustaría dar a los lectores algunos consejos sencillos sobre cómo elegir un bus de integración:

• Piense en crear una solución de integración sin esperar a que los problemas de interoperabilidad de las aplicaciones le pongan contra la pared. Cuanto más grandes son los escombros, más difícil es limpiarlos;
• Elija su plataforma con cuidado. Busque un proveedor que le satisfaga en todos los aspectos, ya que ahora hay mucho para elegir. Deberían interesarle tanto los parámetros tecnológicos de la plataforma como los aspectos metodológicos de implementación;
• piensa en el futuro. Los requisitos funcionales de los que se da cuenta ahora pueden cambiar significativamente en un año, y si la plataforma no los satisface, tendrá que "moverse" a otra. Y un movimiento, como sabes, equivale a dos incendios.

Las aplicaciones modernas rara vez funcionan de forma aislada; una aplicación no puede hacer nada significativo sin interactuar con otras aplicaciones. La arquitectura orientada a servicios integra aplicaciones de colaboración y las acelera al dividir la aplicación en partes que se pueden combinar entre sí. El modelo SOA (los consumidores de servicios llaman a los proveedores de servicios) puede parecer simple, pero plantea dos cuestiones importantes:

1. ¿Cómo encuentra un consumidor el proveedor del servicio al que quiere llamar?
2. ¿Cómo puede un consumidor invocar de forma rápida y fiable un servicio en una red lenta y poco fiable?

Resulta que existe una solución sencilla para ambos problemas: un enfoque llamado Enterprise Service Bus (ESB). Un ESB facilita tanto al consumidor como al proveedor la invocación de un servicio, gestionando todas las interacciones complejas entre ellos. ESB no solo facilita que las aplicaciones (o partes de aplicaciones) llamen a un servicio, sino que también les ayuda a comunicar datos y distribuir notificaciones de eventos. El diseño ESB implementa muchos patrones de diseño y especificaciones estándar reconocidos.

Escribí este artículo para ayudarle a usted, el desarrollador, a comprender por qué ESB es una parte útil y necesaria de la integración de aplicaciones, incluida SOA. Este artículo no cubre definiciones ni productos, sino que se centra en las características y capacidades de ESB que no es necesario que usted mismo implemente. Este artículo explica lo que ESB hace por usted.

servicios de llamadas

Para ayudarlo a comprender la integración de aplicaciones y SOA, comenzaré analizando cómo funcionan los servicios web. Los servicios web son la única forma de implementar una llamada de servicio. Puede que esta ni siquiera sea la mejor manera, pero es el enfoque más estandarizado disponible actualmente, y los servicios web ayudan a guiar el diseño, que es lo que pretendo hacer.

Primero, debo explicar la terminología. Un servicio web es muy parecido a una función en la programación de procedimientos: tiene un nombre, parámetros y un resultado. el nombre es Identificador uniforme de recursos(URI - Identificador uniforme de recursos) ​​que proveedor Los servicios web se utilizan para hacer que un servicio web esté disponible como punto final. El proveedor de servicios web utiliza el URI del punto final como dirección para localizar e invocar el servicio web. EN pedido Hay una acción y parámetros específicos que el consumidor pasa al servicio web cuando llama al punto final. Una vez completado el servicio, el punto final envía respuesta de vuelta al consumidor, que informa el éxito (o error) y contiene el resultado del servicio. Es decir, el consumidor llama al punto final del proveedor, envía una solicitud y recibe una respuesta.

La definición actual de cómo implementar un servicio web es WS-I Basic Profile 1.1, que consta del protocolo "SOAP 1.1 sobre HTTP 1.1" descrito en el lenguaje de descripción de servicios web (WSDL) 1.1 (se proporciona un enlace a la especificación en sí en la sección " "). En SOAP sobre HTTP, el consumidor invoca un servicio mediante una solicitud SOAP enviada a través de HTTP en una solicitud HTTP. El consumidor bloquea sincrónicamente el socket HTTP, esperando una respuesta HTTP que contenga una respuesta SOAP. La API de un punto final se describe mediante su WSDL, un contrato entre el consumidor y el proveedor de servicios.

Ahora que comprende la terminología, veamos las opciones sobre cómo funciona un consumidor cuando llama a un servicio: llamadas sincrónicas y asincrónicas.

Comparación de llamadas sincrónicas y asincrónicas

El consumidor puede llamar al servicio de forma sincrónica o asincrónica. Desde el punto de vista del consumidor, las diferencias son las siguientes:

• Sincrónico. El consumidor utiliza un hilo para llamar al servicio; el hilo envía una solicitud, se bloquea mientras el servicio se está ejecutando y espera una respuesta;
• Asincrónico. El consumidor utiliza dos subprocesos para llamar al servicio; uno es para enviar una solicitud, el segundo es para recibir una respuesta.

Conceptos asincrónico Y sincrónico A menudo se confunde con conceptos. coherente Y paralelo. Estos últimos conceptos se refieren al orden en que se realizan diversas tareas, mientras que sincrónico Y asincrónico Tratar la forma en que un hilo realiza una sola tarea, como llamar a un solo servicio. Una buena manera de comprender la diferencia entre una llamada sincrónica y asincrónica es considerar las consecuencias de la recuperación tras un fallo:

• Sincrónico. Si un consumidor experimenta una falla mientras está bloqueado mientras se ejecuta un servicio, no puede volver a conectarse a ese servicio después de reiniciar, por lo que se pierde la respuesta. El consumidor deberá repetir la solicitud y esperar que no haya ninguna emergencia;
• Asincrónico. Si un consumidor experimenta una emergencia mientras espera una respuesta a una solicitud, después de reiniciar, el consumidor puede continuar esperando una respuesta, lo que significa que la respuesta no se pierde.

La recuperación ante fallos no es la única diferencia entre las llamadas sincrónicas y asincrónicas, pero si está intentando determinar el estilo de la llamada específica que se utiliza, observar la recuperación ante fallos le ayudará a hacerlo.

Ahora que sabe cómo elegir una opción de interacción al llamar a un servicio, veamos las opciones para conectar a un consumidor con un proveedor. El consumidor puede elegir las siguientes opciones de conexión:

1. Llamada directa sincrónica;
2. Llamada síncrona a través de un intermediario (broker);
3. Llamada asíncrona a través de un intermediario (broker).

Consideraré cada opción por separado.

Llamada directa sincrónica

El método de llamada al servicio web SOAP sobre HTTP es directo: similar a una llamada a función, el consumidor conoce la dirección del punto final y lo llama directamente. Para una llamada exitosa, el servicio web debe funcionar cuando el consumidor llama al punto final y debe responder antes de que se agote el tiempo de espera del consumidor. Si el servicio web se implementa en una nueva ubicación (por ejemplo, un dominio de Internet diferente), se debe notificar al consumidor sobre el nuevo URI del punto final. Al implementar varios proveedores de servicios del mismo tipo, el punto final de cada proveedor debe tener un URI diferente. Para seleccionar un proveedor de servicios específico, el consumidor debe conocer cada URI.

Por ejemplo, consideremos un simple servicio web de cotización de acciones: el consumidor pasa un símbolo bursátil y recibe su valor actual. Este servicio puede ser proporcionado por diferentes empresas de corretaje, cada una de las cuales tendrá su propio URI. Encontrar un URI de servicio web es el problema del huevo y la gallina. Si el consumidor conociera la ubicación del punto final, podría solicitar la dirección del servicio, pero cuál es esa dirección es algo que el consumidor debe saber antes de poder solicitar la dirección.

Para resolver este problema, existe una especificación de integración y descubrimiento de descripción universal (UDDI) que describe un servicio web que es un directorio (similar a una guía telefónica) para buscar otros servicios web. La idea es implementar un servicio UDDI en una dirección que sea bien conocida por el consumidor; el consumidor puede utilizar UDDI para buscar otros servicios web.

En la situación del servicio de cotización de acciones, el consumidor conoce la dirección del servicio UDDI, que a su vez conoce las direcciones de los servicios de cotización de acciones (ver Figura 1).

La Figura 2 muestra cómo un consumidor utiliza un servicio UDDI para encontrar el punto final de los proveedores de servicios de cotización de acciones y llamar a uno de ellos. El proceso sigue el siguiente algoritmo:

1. El consumidor solicita a la UDDI una lista de proveedores de servicios;
2. El consumidor selecciona un punto final de proveedor de una lista obtenida de UDDI;
3. El consumidor llama a este punto final.

Observo que el algoritmo para elegir un proveedor depende completamente del consumidor; en este ejemplo, el consumidor simplemente selecciona el primero de la lista. En una situación real, esta elección puede resultar más difícil.

También señalaré que dado que el punto final de un servicio puede cambiar, cada vez que un consumidor quiera llamar a un servicio, debe volver a consultar UDDI y verificar si la información del proveedor ha cambiado. Tener que realizar una solicitud UDDI en cada llamada de servicio genera una sobrecarga adicional, especialmente en la situación normal en la que la información del proveedor no cambia.

Llamada síncrona a través de un intermediario

La desventaja de una llamada directa es que el consumidor necesita conocer el URI del punto final del proveedor para poder llamar al servicio. Utiliza UDDI como directorio para buscar este URI. Si hay varios proveedores, el UDDI contiene varios URI y el consumidor debe seleccionar uno de ellos. Si el proveedor cambia el URI del punto final, debe volver a registrarse en el servidor UDDI para que UDDI almacene el nuevo URI. El consumidor debe volver a solicitar UDDI para obtener un nuevo URI. Básicamente, esto significa que cada vez que un consumidor quiera invocar un servicio, debe consultar en el UDDI los URI de los puntos finales y seleccionar uno de ellos. Esto resulta en un esfuerzo significativo para el consumidor durante las operaciones periódicas de consultar UDDI y seleccionar un proveedor. Este enfoque también obliga al consumidor a seleccionar un proveedor de alguna manera, presumiblemente de una lista equivalente.

Una forma de simplificar el problema es introducir un intermediario que actúe como intermediario al llamar a un servicio web. El consumidor ya no llama directamente al servicio del proveedor, sino que llama al servicio proxy del corredor, que a su vez llama al servicio del proveedor. El consumidor debe conocer el URI del punto final del servicio proxy y, por lo tanto, utiliza UDDI para buscar la dirección, pero en este caso, UDDI solo devuelve un URI y el consumidor no tiene que elegir. Es posible que el consumidor ni siquiera sea consciente de que el punto final es un servicio proxy; sólo sabe que puede utilizar este URI para llamar a un servicio web. El corredor conecta al consumidor con los proveedores de servicios (ver Figura 3).

El URI del servicio proxy debe ser estable: después de que un consumidor usa UDDI para obtener el URI del servicio proxy en la primera llamada al servicio, el consumidor puede reutilizar ese URI para llamadas sucesivas (al menos hasta que el servicio proxy deje de ejecutarse). Mientras tanto, el servicio de proxy realiza un seguimiento de los proveedores, sus URI (que pueden cambiar entre llamadas), su disponibilidad (si falló la última llamada), su carga (cuánto duró la última llamada), etc. El servicio proxy puede asumir la responsabilidad de seleccionar el mejor proveedor para cada llamada, aliviando al consumidor de esta carga. El consumidor simplemente llama al mismo servicio proxy cada vez y este se coordina con varios proveedores.

La Figura 4 muestra cómo un consumidor utiliza un corredor cuando invoca un servicio. El algoritmo de funcionamiento es el siguiente:

1. El consumidor consulta a UDDI para obtener una lista de proveedores de servicios. El URI devuelto por UDDI es en realidad un servicio proxy. UDDI solo devolverá un URI, no varios, porque el corredor solo tiene un servicio de proxy para cualquier servicio determinado;
2. El consumidor llama al servicio utilizando el URI del proxy;
3. El servicio de proxy selecciona un proveedor de servicios de una lista de proveedores disponibles;
4. El servicio proxy llama al punto final del proveedor seleccionado.

Tenga en cuenta que se ha eliminado del consumidor la preocupación por elegir un proveedor: esta elección se implementa en el servicio de proxy del corredor. Esto hace la vida más fácil al consumidor. Después de todo, el proceso de selección en el servicio de proxy puede no ser diferente del proceso utilizado por el consumidor. Sin embargo, dado que el servidor UDDI y el servicio proxy están encapsulados en el intermediario, se pueden implementar fácilmente determinadas funciones, como almacenar en caché información UDDI y recibir notificaciones del servidor UDDI al servicio proxy de que la información almacenada en caché ya no está actualizada.

Tenga en cuenta también que, dado que la dirección del proxy es estable, el consumidor no tiene que consultar constantemente UDDI cada vez que se llama al servicio. Es decir, el consumidor solo necesita solicitar UDDI una vez, luego almacenar en caché la dirección del servicio proxy y utilizarla al realizar llamadas repetidas al servicio. Esto reduce significativamente los gastos generales al llamar al servicio.

Llamada asíncrona a través de un proxy

La desventaja del enfoque sincrónico es que el consumidor debe esperar a que se complete el servicio; el hilo debe bloquearse mientras el servicio se está ejecutando. Si el servicio está funcionando durante mucho tiempo, el consumidor puede dejar de esperar una respuesta. Cuando un consumidor hace una solicitud (y si no hay proveedores de servicios que funcionen o están sobrecargados), no puede esperar. Y, como se mencionó anteriormente, si un consumidor experimenta una emergencia durante un bloqueo del trabajo, incluso después de un reinicio, se perderá la respuesta y será necesario volver a intentar la llamada.

Una solución común a este problema es que el consumidor llame al servicio de forma asincrónica. En este enfoque, el consumidor utiliza un hilo para enviar la solicitud y un segundo para recibir la respuesta. Es decir, el consumidor no tiene que bloquear el trabajo mientras espera una respuesta y puede realizar otro trabajo mientras tanto. En consecuencia, el consumidor es mucho menos sensible a la vida útil del proveedor.

El intermediario, que permite a un consumidor invocar un servicio web de forma asincrónica, se implementa mediante un sistema de mensajería que utiliza colas de mensajes para enviar una solicitud y recibir una respuesta. De manera similar a un servicio de proxy síncrono, un par de colas de mensajes actúa como una dirección única que utiliza el consumidor para invocar el servicio, independientemente del número de posibles proveedores escuchando (consulte la Figura 5).

Este enfoque utiliza el patrón Solicitud-Respuesta para invocar un servicio web. En lugar del protocolo HTTP especificado en WS-I BP 1.1, las funciones de transporte ahora pueden realizar colas de mensajes. La solicitud y respuesta SOAP son las mismas que con el WS-I BP, pero están incluidas en mensajes del sistema de mensajería.

La Figura 6 muestra cómo un consumidor invoca un servicio de forma asincrónica utilizando un intermediario utilizando el siguiente algoritmo:

1. El consumidor pasa la solicitud SOAP como un mensaje a la cola de solicitudes. El consumidor finaliza su trabajo y puede utilizar el hilo para realizar otras tareas;
2. Cada proveedor es un consumidor de la cola de solicitudes, lo que los convierte en consumidores competitivos. El sistema de mensajería determina qué proveedor puede recibir el mensaje y garantiza que solo un proveedor lo reciba. El funcionamiento real de esto depende de la implementación del sistema de mensajería;
3. El proveedor ganador recibe un mensaje de la cola de solicitudes;
4. El proveedor realiza el servicio;
5. El proveedor envía la respuesta SOAP como un mensaje a la cola de respuestas. El proveedor ahora finaliza su trabajo y puede usar su hilo para otras tareas (por ejemplo, esperar la siguiente solicitud);
6. El hilo del consumidor que escucha recibe un mensaje que contiene una respuesta SOAP.

Tenga en cuenta que la función de selección de proveedor ahora está implementada en el sistema de mensajería, lo que facilita la vida del consumidor. Tenga en cuenta también que si el consumidor experimenta una emergencia después de transmitir la solicitud (e incluso si la respuesta está lista mientras tanto), el sistema de mensajería almacenará la respuesta en la cola de respuestas hasta que el consumidor vuelva a estar operativo.

También señalaré que el consumidor no utiliza UDDI para buscar colas de solicitudes y respuestas. Actualmente no existe un servicio estándar para devolver un par de direcciones de cola, por lo que el consumidor simplemente necesita conocer las direcciones. Están codificados en el programa de consumo o los lee desde un archivo de configuración. En el futuro, deberíamos ampliar UDDI o especificar un servicio similar que un consumidor pueda solicitar para definir un par de colas para invocar un servicio específico.

Ahora conoce las opciones para los tipos de conexión para los servicios de llamadas. Veamos capacidades de integración adicionales que también pueden ser útiles y luego cómo diseñar un ESB que nos proporcione estas capacidades.

Otras opciones de integración

ESB también brinda la capacidad de ir más allá de las llamadas de servicio e integrar aplicaciones y partes de SOA utilizando otras tecnologías. Una llamada de servicio es casi siempre una operación bidireccional, lo que significa que la solicitud pasa del consumidor al proveedor y la respuesta se envía en la otra dirección. Otras tecnologías de integración operan como operaciones unidireccionales, donde el remitente transmite información al destinatario y no espera una respuesta; el destinatario simplemente recibe la información sin necesidad de respuesta.

Transferencia de datos

A veces una aplicación simplemente necesita pasar datos a otra aplicación sin tener que llamar al procedimiento del destinatario y ciertamente sin esperar el resultado. El remitente no necesita decirle al destinatario qué hacer con los datos; simplemente hace que esos datos estén disponibles.

Se puede utilizar una llamada de servicio para transferir datos, lo que equivale a llamar a un método de establecimiento, pero la transferencia de datos se realiza mediante el principio RPC. En realidad, la transferencia de datos se parece más a la transferencia de archivos: el remitente exporta los datos y el destinatario los importa sin decirle explícitamente qué hacer con los datos. Esto se parece más a un mensaje SOAP de estilo documento que a un mensaje de estilo RPC.

El uso de ESB para la transferencia de datos aumenta la capacidad de encontrar un destinatario y transferir datos de manera confiable. El remitente no necesita saber cómo encontrar al destinatario, sólo necesita saber cómo encontrar el ESB y confiar en él para encontrar al destinatario. La ESB también es responsable de la transferencia fiable de datos. El remitente puede simplemente reenviar los datos al ESB y estar seguro de que se transmitirán.

Puede encontrar información adicional sobre la tecnología de transferencia de datos en la plantilla de mensaje de documento (para obtener más información sobre esto, consulte el libro " ", cuyo enlace se encuentra en la sección " ").

Notificación de evento

A veces es necesario notificar un cambio en una aplicación a otras aplicaciones. Por ejemplo, si un consumidor cambia su dirección en una aplicación, se debe notificar a otras aplicaciones con sus propias bases de datos para que puedan corregir sus registros.

Una vez más, una aplicación puede llamar a un servicio en otra aplicación para informarle del cambio, pero este enfoque presenta tres problemas. Los dos primeros problemas son los mismos que con la transferencia de datos. En primer lugar, la llamada de servicio es demasiado específica en términos de decirle al receptor qué hacer con la información y, en segundo lugar, tiende a ser bidireccional, lo que obliga al remitente a esperar una respuesta (incluso de forma asíncrona), que en realidad no desea. hacer .

El tercer y más importante problema al llamar a un servicio para notificar un evento es que llamar a un servicio es inherentemente un proceso uno a uno, de consumidor a proveedor, mientras que la notificación de eventos es esencialmente un proceso de uno a muchos", transmitió. , está destinado a todos los destinatarios interesados. Al utilizar una llamada de servicio, el remitente tendría que realizar un seguimiento de todos los destinatarios interesados ​​y llamar al servicio para cada uno de ellos individualmente. Es mejor dejar dicha transmisión de notificaciones en manos de un intermediario ubicado entre el remitente y los destinatarios.

El uso de un ESB para la notificación de eventos aumenta su capacidad para mantener una lista de destinatarios interesados ​​y garantizar que la notificación se entregue a cada uno de ellos. Permite al destinatario enviar una notificación solo una vez y tener la confianza de que se entregará a todos los destinatarios interesados, sin importar quiénes sean. Debido a que esta operación es unidireccional, el remitente puede realizar otras tareas mientras se entregan las notificaciones y las notificaciones se pueden entregar en paralelo.

Puede encontrar información adicional sobre la tecnología de transferencia de datos en la plantilla de mensaje de evento (nuevamente, consulte el libro "Patrones de integración empresarial", vinculado en la sección " ").

Desarrollo de bus de servicio empresarial

Ahora ya conoce la diferencia entre llamar directamente al servicio web de un proveedor y utilizar un corredor para hacerlo. También aprendió cómo un corredor puede permitir que un consumidor llame a un servicio de forma sincrónica o asincrónica.

A ESB se le suele llamar corredor. Entonces, ¿cómo encaja el ESB en los diseños y patrones establecidos?

Autodescripción y descubribilidad

Lo que diferencia a los servicios web de otros enfoques de integración es que un consumidor puede comunicarse dinámicamente con un proveedor de servicios. Esto se logra a través de las siguientes dos funcionalidades principales:

• Autodescripción. Un servicio web se describe a sí mismo de forma legible por máquina. Dos o más proveedores del mismo servicio se vuelven inmediatamente reconocibles, incluso si se implementan de forma completamente diferente, porque sus interfaces descriptivas coinciden con la misma descripción;
• Detectabilidad. Los proveedores de servicios web se pueden organizar en directorios mantenidos automáticamente. El consumidor puede navegar por dicho directorio para encontrar el proveedor del servicio deseado.

Esta funcionalidad de servicios web es muy diferente de los enfoques de integración existentes. En ellos, las interfaces se definían en tiempo de compilación y durante la comunicación entre el consumidor y los proveedores. Los formatos de los mensajes no se expresaron de forma descriptiva. Se basaban en un acuerdo interno y no se podía exigir que siguieran este formato, lo que provocaba que el destinatario no pudiera procesar la estructura creada por el remitente.

La capacidad de autodescribir los servicios web simplificó la integración al declarar las interfaces que debían seguirse. El descubrimiento dinámico de servicios liberó al consumidor de depender de un proveedor específico para una dirección específica, pero esta capacidad también creó sus propios problemas. ¿Debería el consumidor buscar proveedores de servicios una vez o continuamente?

Era difícil resolver la tensión entre vincular a un consumidor a un proveedor de una vez por todas en tiempo de compilación y potencialmente buscar un nuevo proveedor en cada llamada en tiempo de ejecución. El ESB propuso una tercera opción de compromiso: permitir que un consumidor contacte dinámicamente un servicio de proxy una vez y aún pueda utilizar múltiples proveedores y futuros proveedores a través de ese servicio de proxy.

Por lo tanto, el ESB no solo pone a disposición de los consumidores servicios para que llamen, sino que también les ofrece la posibilidad de encontrar servicios mediante programación.

Puerta de enlace de servicio

La base de un ESB síncrono es la llamada puerta de enlace de servicios, que actúa como intermediario entre los consumidores y proveedores de servicios, facilitando el procesamiento de llamadas intermediadas síncronas. Proporciona acceso a todos los servicios conocidos y servicios proxy para cada uno de ellos. De esta manera, la puerta de enlace proporciona una "ventana única" para un consumidor que desea llamar a cualquier servicio de cualquier proveedor conocido por la puerta de enlace.

Si los servicios que coordina la puerta de enlace son servicios web, entonces se autodescriben. Cada servicio declara su interfaz mediante un WSDL, que consta de las cuatro partes siguientes:

1. Tipos de puerto– Un conjunto de operaciones realizadas por un servicio web. El tipo de puerto podría ser stockBrokerServices con puertos/operaciones como getQuote.
2. Mensajes– Formato de solicitud y respuesta, como getQuoteRequest (que contiene el símbolo bursátil) y getQuoteResponse (que contiene el precio).
3. Tipos– Tipos de datos utilizados por el servicio web, como símbolo y precio (o simplemente xs:string y xs:decimal).
4. Conexiones– Dirección para llamar a la operación, por ejemplo, http://stockbroker.example.com/getQuote.

Estos servicios web de puerta de enlace (o más específicamente sus servicios de proxy) también son detectables. La puerta de enlace proporciona esta capacidad como un servicio UDDI, como se analizó anteriormente. Para encontrar la dirección de llamada de servicio, el consumidor consulta el servicio UDDI de la puerta de enlace para obtener una lista de proveedores para la operación WSDL deseada y recibe la dirección del servicio proxy de la puerta de enlace para esa operación.

Autobús de mensajes

El ESB asíncrono se basa en el conocido patrón Message Bus descrito en el libro " Plantillas de integración empresarial", al que se hace referencia en la sección " ". Un bus de mensajes es una colección de canales de mensajes (también conocidos como colas o temas), generalmente configurados como pares de canales de solicitud-respuesta. Cada par representa un servicio que puede ser invocado por un consumidor utilizando el bus. Este consumidor pasa un mensaje a la cola de solicitudes del servicio y luego (asincrónicamente) escucha la cola de respuestas para obtener el resultado. Sabe qué resultado coincide con su solicitud particular porque el resultado tiene el identificador de correlación correcto.

El consumidor que llama al servicio no sabe realmente quién está prestando el servicio. Los proveedores de servicios también están conectados al bus de mensajes y lo escuchan en busca de mensajes de solicitud. Si hay varios proveedores de servicios, compiten entre sí como consumidores para recibir una solicitud particular. El sistema de mensajes que implementa el bus de mensajes actúa como un administrador de mensajes y distribuye mensajes de solicitud a los proveedores de servicios, optimizando de alguna manera esta distribución dependiendo del equilibrio de carga, retrasos de la red, etc. Una vez que un proveedor de servicios recibe una solicitud, ejecuta el servicio y coloca el resultado en un mensaje en una cola de respuestas condicional. Es decir, el proveedor y el consumidor nunca conocen directamente la ubicación del otro; solo conocen el bus de mensajes y la dirección de los canales correspondientes y pueden comunicarse a través de canales comunes.

Este bus de mensajes es la esencia de un ESB y no hay nada nuevo aquí. Los integradores de aplicaciones han utilizado esta tecnología durante más de una década, utilizando productos de colas de mensajes como WebSphere® MQ y TIBCO Enterprise Message Service. Y, de hecho, a menudo se dice que si utiliza productos de mensajería empresarial, entonces tiene un ESB. Los clientes de IBM han estado disfrutando de estas capacidades durante algún tiempo con WebSphere Business Integration Message Broker y WebSphere MQ.

Entonces, ¿el ESB es sólo un bus de mensajes? No, el bus de mensajes es definitivamente el núcleo de un ESB asíncrono, pero hay más en un ESB completo. El ESB tiene capacidades que el bus de mensajes nunca tuvo: las capacidades de autodescripción y descubrimiento antes mencionadas.

Mejor bus de mensajes

Entonces, si el bus de mensajes no es un ESB completo, ¿qué más hace el ESB?

Una desventaja de la tecnología de bus de mensajes tradicional es su falta de capacidad de autodescripción. Desde la perspectiva del consumidor, existen múltiples canales para invocar múltiples servicios. Pero, ¿cuál de estos canales es necesario para que un consumidor llame al servicio deseado? El consumidor no puede simplemente enviar una solicitud a cualquier canal de solicitud; debe conocer el canal correcto a utilizar para llamar a un servicio en particular. De lo contrario, puede comprar un billete de avión en lugar del libro deseado. Además, incluso después de determinar (de alguna manera) el canal correcto (y el canal para escuchar una respuesta), el consumidor debe saber el formato de datos en el cual enviar la solicitud (y en qué formato de datos esperar la respuesta).

Como se analizó anteriormente, para los servicios web sincrónicos este problema se resuelve con WSDL, que ahora también es una variante del estándar para describir servicios asincrónicos. El WSDL asociado con un canal de solicitud debe describir qué servicio proporciona el canal, así como el formato del mensaje de solicitud que debe proporcionar el consumidor. El WSDL probablemente también debería especificar el canal de respuesta en el que el consumidor debería escuchar para recibir la respuesta y el formato del mensaje de respuesta esperado. De esta manera, la aplicación que llama puede analizar mediante programación un par de canales de invocación de servicios y determinar si brindan el servicio deseado utilizando los formatos de mensajes de solicitud y respuesta deseados.

Los canales de servicios autodescriptivos introducen otro problema, concretamente el problema de descubrimiento, que los servicios web sincrónicos resuelven con UDDI. Como se analizó anteriormente, el consumidor consulta al servidor UDDI la dirección del proveedor de servicios web y el servidor devuelve la URL de ese proveedor. El consumidor utiliza esta URL para llamar al servicio.

El ESB necesita un servicio de directorio similar con una API similar a UDDI que el consumidor pueda utilizar para consultar la dirección del servicio que implementa la operación WSDL deseada. El ESB devuelve la dirección del par correspondiente de canales de solicitud y respuesta. Es decir, un cliente ESB, similar a un cliente UDDI, no debe saber nada más que lo siguiente:

1. WSDL que describe el servicio al que quiere llamar.
2. La dirección del servicio de directorio de ESB (que puede derivarse de la dirección raíz de ESB).

Esto es suficiente para descubrir los canales de solicitud y respuesta del servicio y comenzar a llamar al servicio. Además, este servicio de directorio es un servicio más proporcionado por la ESB, como si fuera el servicio principal para buscar otros servicios.

¿Síncrono o asíncrono?

Los consumidores de servicios se enfrentan a una elección artificial entre dos estilos de interacción: sincrónica o asincrónica. Para resolver este dilema, muchos ESB admitirán ambos modos y, de hecho, pueden ofrecer dos modelos de llamadas para el mismo servicio. En este caso, el consumidor, al solicitar la dirección del servicio, podrá recibir dos opciones: una para el modo síncrono y la segunda para el modo asíncrono. Luego, el consumidor puede elegir el modelo de llamada que más le convenga. Independientemente del modelo, se ejecuta el mismo servicio, aunque la instancia específica del proveedor del servicio puede diferir.

Es decir, un ESB es mejor que un bus de mensajes tradicional porque un ESB también hace que el servicio sea autodescriptivo y proporciona un servicio de directorio para encontrar otros servicios. Esto es lo que los proveedores de productos de construcción ESB se esfuerzan por ofrecer.

Conclusión

Como has visto, el servicio se puede llamar de cualquiera de las siguientes formas:

1. Directa y sincrónicamente;
2. Sincrónicamente a través de un corredor;
3. De forma asincrónica a través de un corredor.

Enterprise Service Bus es un intermediario que admite la invocación de servicios en modo síncrono y asíncrono. También permite la transferencia de datos y notificaciones de eventos entre aplicaciones. Ayuda a los consumidores a encontrar proveedores y gestiona los detalles de las interacciones entre ellos.

Un ESB sincrónico es una puerta de enlace de servicios que actúa como coordinador central para múltiples servicios. El ESB asíncrono es un bus de mensajes cuyos servicios también admiten las capacidades de autodescripción y descubrimiento de los servicios web. Actualmente existen estándares y patrones para implementar un ESB síncrono y un bus de mensajes que facilita un ESB asíncrono. Se necesitan normas adicionales para aprovechar todo el potencial del ESB.

Si realiza una auditoría de la infraestructura de TI en este punto, un diagnóstico típico se verá así:

1) La infraestructura de TI existente contiene demasiadas interconexiones (a veces ocultas y mal documentadas) entre sistemas y, por lo tanto, requiere muchas aprobaciones y modificaciones al realizar cualquier cambio, incluso mínimo.

2) No existe una unidad de control única encargada de actualizar y proporcionar datos de los diversos sistemas de información.

3) No hay control sobre los procesos de intercambio: no existe un entorno unificado para el intercambio de datos entre sistemas de información.

4) Existe un “zoológico tecnológico”: se utilizan una variedad de sistemas de información y protocolos de intercambio de datos, muchos conectores (a menudo desarrollados por encargo o de forma independiente), etc.

La solución a muchos de estos problemas radica en la transición a la construcción de una infraestructura de TI basada en el concepto de Arquitectura Orientada a Servicios (SOA), cuyo elemento clave es el Bus de Servicios de Integración. Un bus es un software que permite combinar una gran cantidad de plataformas y aplicaciones, así como organizar la interacción entre ellas en función de servicios. Al mismo tiempo, no importan las tecnologías sobre las que se implementen los sistemas y sus servicios; puede ser JAVA, .NET u otra plataforma.

El bus de integración normalmente proporciona las siguientes funciones:

Transformación de mensajes, así como transmisión de mensajes, reenvío algorítmico, puesta en cola y seguimiento;

Trabajar con mensajes en modos: sincrónico, asíncrono, punto a punto, publicación-suscripción;

Soporte para mensajes XML y SOAP;

Capacidad para conectar múltiples sistemas a través de adaptadores y API listos para usar para escribir nuevos adaptadores;

Orquestación (ubicación, coordinación y gestión automática) de servicios.

Conceptualmente, la arquitectura que utiliza Integration Service Bus tiene este aspecto:

Figura 1 Arquitectura utilizando un bus de integración

Al introducir un bus de integración, la integración de nuevos sistemas, tanto adquiridos como desarrollados de forma independiente, se simplifica enormemente. Los servicios ya no son aplicaciones monolíticas, sino que se dividen en servicios únicos. Por ejemplo: el servicio compuesto “considerar una solicitud de préstamo” se puede dividir en los siguientes “servicios unitarios”:

• Introduce los datos del cliente
• Comprobar si existe un registro para un cliente determinado
• Obtenga una lista de cuentas de clientes
• Obtener una lista de servicios utilizados por el cliente
• Obtenga datos agregados sobre el historial de pagos de préstamos
• Obtener datos para el informe
• Obtener saldo de cuenta
• Calcular calificación crediticia
• Generar un informe para revisión por parte del gerente.
• Actualizar detalles de la cuenta
• Generar una notificación para un cliente

Tenga en cuenta que algunos "servicios unitarios" se pueden utilizar en las operaciones de otros componentes, lo que agrega integridad al sistema, lo hace más fácil de mantener y reduce el riesgo.

Por ejemplo, el portal de clientes de un banco combina informes de cuentas corrientes, informes de pagos de hipotecas y extractos de tarjetas de crédito en una sola página. Al mismo tiempo, los datos de la cuenta, los datos del pago de la hipoteca y los datos de la tarjeta de crédito se pueden obtener de diferentes sistemas. Según los datos de CRM, en la misma página se puede mostrar una oferta potencialmente interesante específicamente para un cliente determinado.

Como resultado de la implementación del bus de integración, se logra la transparencia del intercambio de datos en el marco de los procesos comerciales existentes e implementados, es posible aumentar la eficiencia y productividad de los empleados y departamentos, así como mejorar la calidad del cliente. satisfacción y reducir los costos de creación y mantenimiento de la infraestructura TI del Banco.

La siguiente ilustración muestra cómo cambia la interacción de los sistemas de TI del banco después de la implementación del bus de integración.

Dibujo2 Arquitectura TI del banco antes y después de la implementación del bus

Actualmente, la elección en el mercado de autobuses de integración es bastante amplia. Se presentan tanto sistemas comerciales como productos de código abierto. Entre los fabricantes de buses de integración líderes en implantación en Rusia, podemos destacar IBM y Oracle; TIBCO puede incluirse entre los principales proveedores extranjeros.

Consideremos la implementación de buses de integración en varios grandes bancos internacionales.

Chinatrust Commercial Bank utiliza un bus de integración para respaldar sus productos y servicios. La arquitectura orientada a servicios basada en el bus de integración integra más de setenta sistemas en múltiples plataformas, tales como: sistema bancario automatizado, banca en red, sistema hipotecario, sistema de lotería, sistema de automatización de flujo de trabajo, menú de voz interactivo, etc. En tiempo real, se encuentran disponibles servicios como agregación de datos, resumen de cuenta, transferencias entrantes y salientes, transferencias, notificaciones (la funcionalidad de comunicaciones basadas en eventos está habilitada) y otros. Los costes de integración de nuevos sistemas han disminuido en una media del 30 al 40%.

Actualmente, el bus de integración del banco soporta 100.000 transacciones diarias en el sector corporativo y 50.000 en el minorista. El número de transacciones bancarias en línea aumentó de 150.000 a 1.200.000 por día.

El banco singapurense-malasio OCBC estableció recientemente un objetivo de cinco años de aumentar la eficiencia operativa en un 25% y reducir el costo de desarrollar nuevas interfaces de software en un 30%. El primer servicio basado en SOA se lanzó en 2006. Después de seis meses, había 116 servicios unitarios en funcionamiento, cada uno de los cuales se podía utilizar en servicios compuestos. 50 servicios individuales formaron parte de varios componentes. Para apoyar los procesos de integración, el banco creó un Centro de Competencia de Integración. OCBC cree que SOA desempeña un papel clave en el logro de sus objetivos declarados.

En Japón, la competencia en el campo de la banca por Internet es extremadamente alta. Sumishin Net Bank, Ltd. se fijó el objetivo de ofrecer una amplia gama de productos al mercado en un período de tiempo más corto que otras instituciones financieras. Para lograr este objetivo, el banco necesitaba cumplir con los estrictos estándares técnicos impuestos al sector bancario japonés y al mismo tiempo desarrollar una ventaja competitiva. Se desarrolló una arquitectura orientada a servicios utilizando diez productos de software, incluido un bus de integración. En sólo 18 meses después del lanzamiento de la nueva línea de servicios, se invirtieron aproximadamente 600 mil millones de yenes (alrededor de 6 mil millones de dólares) en el banco y se abrieron 400.000 cuentas. Se logró una flexibilidad increíble al agregar nuevos servicios. El costo de su desarrollo ha disminuido significativamente.

En Rusia, los autobuses de integración se utilizan en muchas grandes empresas, incluidos los operadores de telecomunicaciones, el sector bancario, así como en el complejo de sistemas de gobierno electrónico de la Federación de Rusia. La implementación de buses de integración suele ser realizada por integradores de sistemas. En particular, nuestra empresa AMT-GROUP, que según cnews.ru está incluida entre las 20 principales empresas rusas que prestan servicios de TI a bancos, tiene una experiencia exitosa en el trabajo con buses de integración y su implementación en diversos campos de actividad, incluido el sector bancario. . Nuestros especialistas tienen una amplia experiencia en la creación de arquitecturas orientadas a servicios basadas en buses de integración, incluyendo la auditoría de procesos de negocio y su posterior automatización, la creación de conectores para sistemas integrados y la optimización del entorno de trabajo.

El artículo utiliza materiales de fuentes abiertas:
http://www.tibco.com/multimedia/ss-ctcb_tcm8-15110.pdf
http://www.eawriter.com/images/case_studies/TIBCO_2.pdf
http://www-01.ibm.com/software/success/cssdb.nsf/CS/JSTS-7V4BWP?OpenDocument&Site=corp&cty=en_us

Tasa:

4 15

En Moscú, desde 1958, existía la tercera calle Stroiteley, pero en 1963 se le cambió el nombre: ahora es la calle Maria Ulyanova, y el edificio 25 en esta calle es un edificio Khrushchev de cinco pisos. En Leningrado (San Petersburgo), la calle 3 de los Constructores nunca existió...

Estoy hablando nuevamente de la integración de aplicaciones. Hoy leí el estándar nacional para el flujo de documentos interdepartamentales GOST R 53898-2010. Y el estándar parece estar "correcto" escrito en XML y hay todo tipo de campos útiles en 53 páginas y todos los detalles. Recuerdo que a finales del siglo pasado abogué firmemente por la aparición de estándares para mensajes electrónicos en las páginas de la revista Computer en el artículo El factor de Internet en el desarrollo de sistemas cliente-banco a finales del siglo pasado. Todo parecía más optimista que al principio de éste. Las puntocom aún no habían colapsado, el cielo estaba más alto, la hierba era más verde, los sitios sociales eran creíbles y Fielding aún no había defendido su disertación titulada Transferencia de Estado Representacional. ¿Qué pasó en poco más de diez años y por qué ya no me entusiasma la idea de estandarizar el formato de un documento electrónico? Nada importante, sólo ha cambiado el paradigma de integración de aplicaciones.

¿Cómo era antes? Un banco envió un mensaje de correo electrónico a otro (lo siento, yo estaba trabajando en Inkombank en ese momento, así que hablaré de bancos). El segundo banco recibió el mensaje y le envió un recibo. Todo esto fue cifrado diez veces, certificado con firma digital, la función hash del mensaje original se incluyó en el recibo... números de entrada y salida, marcas de tiempo (también criptográficas, por cierto), etc. etc. La cuestión más discutida de esos años fue si es necesario generar un recibo por el recibo y qué hacer cuando el recibo no fue entregado. En general, da miedo recordar hasta qué nivel de complejidad se puede llevar el proceso de sincronización de los estados de múltiples imágenes virtuales de un documento real. Fue más fácil con papel. Al menos hasta la invención de la fotocopiadora.

Volvamos a los tiempos modernos. Si existían colas de mensajes para entregar mensajes de forma segura y confiable, entonces apareció el bus de servicio para eliminar el intercambio de mensajes. Y no me digáis que este mismo autobús es el que intercambia mensajes. Lo sé, lo hacemos nosotros mismos, pero no es muy correcto. La idea original del autobús de servicio, especialmente Empresa Service Bus (ESB) no se trata de pasar mensajes, sino de garantizar que ninguna aplicación tenga que preocuparse por crear su propia instancia local de un objeto. El objetivo del servicio es poder obtener siempre dicho objeto. Si necesita un documento, ingrese la URL y use el método HTTP GET para recibir y leer el documento. Si deseaba cambiar un documento, lo cambiaba usando la misma URL usando el método HTTP PUT. Se agregó POST, se eliminó DELETE, ¿qué podría ser más simple? Dale a tu documento una URL. Utilice un protocolo estilo WebDAV para tomar un documento, trabajar en él y devolverlo a su lugar en un nuevo estado, el mismo definido como copia maestra, es decir. a la misma URL de donde lo tomaron

De lo contrario, es un apocalipsis. Los recibos y notificaciones de cambios de estado no son tan malos. La necesidad de interpretar los campos del documento de la misma forma y, para ello, sincronizar los libros de referencia, es un problema. La Tercera Calle de los Constructores de Moscú y la Tercera Calle de los Constructores de San Petersburgo, como se sabe por la película principal de Año Nuevo, están lejos de ser la misma. Quizás el único libro de referencia que se interpreta por igual en diferentes departamentos sea el calendario gregoriano. Y luego, no estoy completamente seguro. U otro ejemplo: mi nombre en el pasaporte internacional no coincide con mi nombre en la visa británica pegada en el mismo pasaporte internacional. El pasaporte dice MAXIM y la visa dice MAKSIM. Por eso tengo miedo de cruzar la frontera :) Agreguemos a esto la diferencia en los conjuntos de estados de los documentos en diferentes sistemas, diferentes gráficos de transición, documentos compuestos que incluyen un conjunto de otros documentos, sobres electrónicos, etc. un problema de increíble complejidad combinatoria. ¿Qué pasa si el documento no va a un departamento, sino a varios a la vez? En uno se cumplirá, en otro será rechazado, en el tercero se perderá. Por lo tanto, muy pronto los encargados del proceso agregarán una ruta a este documento, expresada lacónicamente en notación BPMN en una docena de páginas. Excepciones, devoluciones, cancelaciones, resultados incorrectos de verificación de firma digital, recibos no entregados, claves caducadas... La matriz está en reposo (pero los programadores siguen trabajando)

En la rápida evolución de la tecnología informática, a veces se revelan de forma completamente inesperada nuevas posibilidades para viejas ideas. Por ejemplo, como el recuerdo aparentemente olvidado de los núcleos de ferrita. A pesar de todas sus deficiencias, su cualidad positiva era la capacidad de recordar y almacenar datos indefinidamente sin recargar, a diferencia de los módulos RAM semiconductores modernos. Y ahora, literalmente ante nuestros ojos, está reviviendo en forma de una prometedora tecnología MRAM, que también utiliza un bucle de histéresis magnética de dos posiciones. En consecuencia, mantendrá su estado sin nutrición. Con el resurgimiento de la memoria magnética, un procedimiento tan familiar para iniciar una computadora será cosa del pasado.

Algo similar ocurre con las autopistas de intercambio de datos construidas según el principio del “autobús común”. Ahora es difícil apreciar el carácter revolucionario de la idea de un autobús común, pero en un momento fue una verdadera revolución. El bus Unibus común, propuesto hace tres décadas por ingenieros de Digital Equipment Corporation como base arquitectónica para la minicomputadora PDP-11, resultó ser un medio extremadamente eficaz (y, lo más importante, económico) para integrar diferentes tipos de dispositivos. Posteriormente, se construyeron muchos ordenadores según el principio del bus, incluidos todos los PC modernos. De hecho, el mercado de dispositivos periféricos comenzó a tomar forma a partir del bus común. Sin embargo, con el tiempo, los autobuses, utilizados como elemento arquitectónico central de una computadora, comenzaron a dar paso a conmutadores más rápidos, sin dejar de ser una de las principales opciones para conectar dispositivos periféricos. Hoy el neumático, que se llama. Autobús de servicio empresarial (ESB), puede desempeñar aproximadamente el mismo papel que el Unibus, con todas las ventajas, pero a un nivel superior.

De hecho, los acontecimientos se están desarrollando rápidamente. Hace apenas un año, uno de los principales analistas del Grupo Gartner, Efim Natis, sugirió lo siguiente: "Uno de los principales enfoques para crear una infraestructura de aplicaciones empresariales es construir utilizando procesos asincrónicos débilmente acoplados". Y en un artículo de InfoWorld de octubre de 2002 de John Udell, "Ahora que todos estamos de acuerdo en que los servicios web deben comunicarse de manera asincrónica, ha quedado claro que el middleware orientado a mensajes (middleware orientado a mensajes, MOM) se vuelve crítico".

Como puede ver, en apenas un año, la suposición se convirtió en una declaración. Sonic Software, formada por varios alumnos de BEA Systems y hoy reconocida como uno de los líderes en el desarrollo de middleware, jugó un papel importante para que esto sucediera. Varias otras pequeñas empresas han realizado un trabajo muy interesante (por ejemplo, Collaxa), pero Sonic fue uno de los primeros en ofrecer su implementación de procesos asincrónicos débilmente acoplados. A pesar de toda la novedad, en su producto de software SonicXQ ESB la empresa, de hecho, implementa la antigua idea de un bus común, tomada de las minicomputadoras, pero al mismo tiempo la incorpora con una nueva apariencia.

En este caso, el ESB es genérico en el sentido de que conecta todas las aplicaciones de la empresa. ESB, implementado mediante SOA (Arquitectura orientada a servicios), está diseñado para integrar aplicaciones empresariales basadas en servicios web asíncronos orientados a documentos y arquitectura de conector J2EE (JCA). Estas dos tecnologías proporcionan enrutamiento de mensajes basado en contenido y le permiten organizar la interacción entre aplicaciones e integrar la gestión de procesos de negocio de tal manera que sea posible prescindir de intermediarios costosos.

La originalidad del desarrollo de SonicXQ atrajo considerable atención. Históricamente, los intermediarios de integración (a veces llamados servidores de integración) fueron los primeros en surgir. Las soluciones construidas sobre la base de intermediarios de integración se pueden representar en forma de conmutadores. Con su ayuda, se forma una especie de metacomputadora hipotética, donde todo el control se basa en un principio centralizado. El resultado es algo así como un hiperordenador central. Sonic hizo más o menos lo mismo que DEC, que hace tres décadas ofrecía minicomputadoras de bus como una alternativa de bajo costo a las mainframes; La solución de Sonic permite construir una especie de metacomputadora para toda la empresa, pero a un costo menor. El resultado es algo parecido a un minimetaordenador: en lugar de un costoso conmutador, se ofrece un Enterprise Service Bus.

La tecnología SonicXQ no apareció de repente. Tiene dos fuentes bastante conocidas. El primero es el middleware basado en mensajes. Este tipo de herramientas de software está experimentando una verdadera reencarnación, especialmente en relación con la aparición del Java Message Service de Sun Microsystems. Puede leer sobre lo que está sucediendo en este frente y con más detalle sobre SonicMQ, el predecesor inmediato de SonicXQ, en. Ambas publicaciones siguen siendo relevantes, pero el panorama del software empresarial ha cambiado significativamente durante el año pasado, especialmente con el impacto de los servicios web. Hace apenas un año, cuando se estaban preparando estas publicaciones, la idea de qué eran los servicios web y cuál era su significado era bastante vaga. Con el tiempo, la situación se ha aclarado considerablemente y los servicios web deberían considerarse como la segunda fuente de SonicXQ.

Autobús de servicio empresarial

Entre los acontecimientos del año pasado, cabe señalar que apareció algo nuevo e inusual en la terminología profesional. Algunos en el campo de Microsoft/IBM lo llaman “orquestación” de servicios web; otros en el campo de Sun/BEA lo llaman “coreografía”. La última batalla en la guerra de estándares se está intensificando sobre cuál es la mejor manera de hacer que las aplicaciones empresariales funcionen de manera consistente utilizando servicios web. El motivo de esta nueva actividad es que finalmente quedó claro para todos: en las condiciones actuales, las capacidades de las aplicaciones estrechamente acopladas se han agotado y la complejidad de los sistemas se ha vuelto demasiado grande. Sin embargo, el esquema original para distribuir servicios web utilizando repositorios creados según el estándar UDDI resultó ser de poca utilidad para fines corporativos. Al mismo tiempo, los servicios web, y especialmente sus versiones asincrónicas orientadas a documentos, ofrecen una salida real al estancamiento de la complejidad. Desde una perspectiva técnica, el desafío de construir una infraestructura de aplicaciones empresariales utilizando procesos asincrónicos débilmente acoplados tiene varias soluciones alternativas.

Enterprise Service Bus, basado en SonicXQ, es uno de ellos. La columna vertebral empresarial de SonicXQ permite una arquitectura distribuida y orientada a servicios. ESB le permite crear contenedores para alojar servicios. Los servicios son fáciles de ensamblar y orquestar porque un servicio que está en contenedores y forma parte del ESB está expuesto a otras partes del ESB. Además, toda la estructura es virtual; la red física real en la que “vive” puede estar sujeta a cambios sin pérdida de funcionalidad.

Durante el funcionamiento del ESB, uno o más servicios asociados se encuentran en un contenedor especial (contenedor de servicios). Los contenedores son un medio para mover servicios a través de un proceso distribuido según rutas de mensajes. El procedimiento para pasar un mensaje es el siguiente. El mensaje se envía a la entrada del bus ESB. Aquí se le agrega una ruta que le permite organizar la promoción basada en contenido a través de un proceso distribuido; este proceso tiene control descentralizado; Como parte de este proceso, el mensaje viaja a través de varios servicios hasta llegar a un punto final donde se recupera del contenedor.

Se pueden utilizar nombres lógicos en lugar de nombres físicos para especificar puntos finales. El establecimiento de una correspondencia entre nombres físicos y lógicos (mapeo) se realiza mediante un mecanismo especial incluido en el ESB. Por tanto, la capacidad de virtualización está inherentemente integrada en la arquitectura; el sistema puede cambiar sin modificar el código ni destruir los procesos de negocio existentes. La configuración permite múltiples niveles de Calidad de Servicio (QoS) para garantizar el paso confiable de mensajes entre aplicaciones. En general, cuando un mensaje ha completado toda su ruta, abandona el punto final del destinatario y se envía un mensaje de confirmación de recepción al remitente. La belleza de un proceso de transmisión de mensajes distribuidos basado en ESB es que su lógica es muy cercana a la comunicación del mundo real.

Fundamentos: JCA y Servicios Web

La integración de aplicaciones ofrecida en ESB es posible gracias a la llegada de la arquitectura de interconexión JCA de Sun Microsystems y SOAP, un protocolo estándar para servicios web. JCA, diseñado específicamente para superar las complejidades asociadas con la integración de aplicaciones, proporciona métodos estandarizados para realizar esta tarea. El sistema de información corporativo, construido sobre los principios de JCA, utiliza la interfaz JDBC para acceder a las aplicaciones. Hoy en día este enfoque es bastante popular; La mayoría de los servidores de aplicaciones modernos, incluidos BEA WebLogic e IBM WebSphere, admiten adaptadores JCA. Además, muchos proveedores de soluciones de paquetes tienen la intención de admitir JCA en futuras versiones de sus productos.

La originalidad del uso de los servicios web por parte de SonicXQ radica en la forma en que se organiza el proceso de "orquestación" (o "coreografía"). Está basado en el protocolo SOAP, pero superpuesto con un formato de mensaje simple y escalable. Al mismo tiempo, SonicXQ Enterprise Service Bus proporciona compatibilidad tanto con el modelo de documento SOAP asíncrono (modelo asíncrono de documento) como con el modelo SOAP síncrono, basado en el principio de llamadas a procedimientos remotos (RPC). En SonicXQ, los servicios se describen en WSDL, pero WSDL está directamente integrado en Distributed Processing Framework. Como resultado, el servicio puede o no registrarse en el directorio UDDI externo si no es necesario.

Sin exagerar, la tecnología SonicXQ se puede llamar extrema: combina una serie de tendencias modernas en informática corporativa. Pero quizás lo más interesante es que permite comprender mejor qué son los servicios web. Y no con palabras, sino con hechos.

Literatura

1. Leonid Cherniak. OIM, renacimiento //

2. Valery Kor zhov. Cartero de solicitudes //

3. Stuart J. Johnston, Las guerras de servicios web toman un giro artístico. ¿Coreografía u orquestación? Revista XML, 2002, núm. 10/11