Oswald Regular
OpenSans Regular
Continuous>Flows®

El procesamiento de datos empresariales en tiempo real representa un verdadero desafío cuyos requisitos muy pocos productos de software son capaces de satisfacer. Ab Initio® es uno de ellos.

Ab Initio es compatible con una amplia gama de aplicaciones en tiempo real, como la aplicación “mini-batch”, la aplicación de “mensajería asincrónica” de alto volumen, las aplicaciones orientadas a servicios de cliente (en inglés “Service Oriented Architecture”, o SOA), o las aplicaciones de “solicitud/respuesta” de baja latencia. Aplicaciones todas ellas con una tecnología única: el módulo Continuous>Flows del Co>Operating System®.

El Co>Operating System® es un “motor de flujo de datos” que hace que secuencias de registros, o de transacciones, fluyan a través de una secuencia de “componentes”. Cada uno de estos componentes realiza varias computaciones con registros de entrada para generar registros de salida (aplicando, por ejemplo, reglas de negocio). La lógica de procesamiento compleja se descompone en pasos de fácil comprensión, cada uno de los cuales lo realiza un componente diferente. Los registros fluyen a través del conjunto de componentes necesario hasta que el procesamiento se completa.

Este modelo de flujo de datos es adecuado tanto para el procesamiento por lotes como para el procesamiento en tiempo real. Aunque la mayor parte de una aplicación por lotes y su correspondiente aplicación en tiempo real sean muy similares (o incluso, idénticas), son los componentes de punto final los que determinan si la aplicación será por lotes o en tiempo real. Una aplicación por lotes se conecta a archivos planos y a componentes de tabla de base de datos estáticos. Por el contrario, una aplicación en tiempo real se conecta a colas de mensajes, servicios web, RPC, servidores CICS y/o componentes especiales (normalmente vía sockets TCP).

Con Ab Initio, la ventaja de que las aplicaciones por lotes y las aplicaciones en tiempo real tengan tanto en común redunda en una complejidad significativamente más baja y en un rendimiento mucho más alto (a lo que ayuda el que ambas aplicaciones utilicen una única tecnología, el Co>Operating System). La menor complejidad se traduce así en una más alta productividad y en la consiguiente reducción de costos.

Reutilización de la lógica de negocios entre aplicaciones por lotes y en tiempo real

En la mayoría de los casos, los componentes de la lógica de negocios entre los componentes de entrada y de salida permanecen iguales, lo que significa que la misma lógica se puede reutilizar entre las aplicaciones por lotes y las aplicaciones en tiempo real. Esto último tiene implicaciones decisivas para la productividad. En aquellas soluciones que no usan la tecnología de Ab Initio, las tecnologías y las metodologías para el procesamiento por lotes y en tiempo real suelen ser muy diferentes (lo que obliga a implementar la misma lógica de negocio varias veces dentro del rango de usos que va desde la ejecución por lotes a la ejecución en tiempo real). Con Ab Initio, la lógica del negocio sólo se desarrolla una vez, para integrarse luego en las infraestructuras por lotes y en tiempo real de Ab Initio:

Mejora del rendimiento para diferentes modelos de ejecución en tiempo real

Los arquitectos de aplicaciones se enfrentan a menudo a dificultades que nacen de la necesidad de satisfacer requisitos de rendimiento aparentemente en conflicto:

  • Las aplicaciones por lotes necesitan procesar datos lo más eficazmente posible. Puede ocurrir que un trabajo por lotes tarde mucho en ejecutarse porque hay demasiadas transacciones para procesar, de manera que ninguno de los resultados está disponible hasta que se completa el trabajo. Sin embargo, durante la ejecución, se espera que un trabajo por lotes procese un número muy alto de registros por segundo.
  • Las aplicaciones “mini-batch” son colecciones de trabajos por lotes que procesan individualmente pequeños volúmenes de datos. A veces sucede que en un día se ejecutan miles o decenas de miles de pequeños trabajos de ese tipo. Al limitar la cantidad de datos procesados por un trabajo, se minimiza el tiempo de respuesta. Este planteamiento también permite que las mismas aplicaciones procesen con eficacia volúmenes de datos muy grandes en una modalidad por lotes tradicional. La administración de decenas de miles de trabajos al día presenta su propio conjunto de complejidades, que Conduct>It® de Ab Initio resuelve con solvencia.
  • Las aplicaciones de mensajería asincrónica se conectan a colas de mensajes. Se trata de aplicaciones que también necesitan procesar transacciones tan eficazmente como sea posible. Sin embargo, los sistemas que siguen en la cadena de procesamiento esperan, en general, sus mensajes de respuesta en un plazo que oscila entre unos pocos segundos y decenas de segundos. De hecho, si una aplicación asincrónica puede responder dentro de un plazo de un segundo o dos, puede también ser compatible con el uso interactivo.
  • Se espera que las aplicaciones de mensajería de “solicitud/respuesta” o asincrónicas procesen una transacción tan pronto como aparezca y que respondan tan rápido como sea posible (por lo común, con una latencia menor a un segundo). Si varias aplicaciones de ese tipo trabajan juntas para procesar una transacción, es posible que las aplicaciones individuales necesiten emitir respuestas en un plazo que oscila entre décimas y centésimas de un segundo. Ab Initio se mueve en ese “punto óptimo” donde las unidades de trabajo significativas se realizan confiablemente en el rango de las decenas de milisegundos (por contraste con los umbrales más amplios dentro de los cuales se manejan otros sistemas especializados más estrechos).

Continuous>Flows del Co>Operating System de Ab Initio es una tecnología única que los clientes utilizan de forma eficaz en todos los modos referidos anteriormente. Y ello es factible porque la arquitectura del Co>Operating System fue diseñada, desde el primer momento, para satisfacer los requisitos impuestos por los más diversos planteamientos de trabajo.

Ab Initio presenta dos diferencias primordiales entre las aplicaciones por lotes (incluidas las “mini-batch”) y las aplicaciones en tiempo real:

  • Terminación: Las aplicaciones por lotes finalizan cuando han terminado de procesar todos los datos de sus entradas. Después de la terminación, no queda ningún recurso del sistema asociado a una aplicación por lotes.

    Una vez iniciadas, las aplicaciones en tiempo real permanecen activas indefinidamente hasta recibir y procesar las transacciones que llegan a sus entradas. Si hay un período de inactividad en el flujo de transacciones, una aplicación en tiempo real espera hasta que aparezcan nuevas transacciones.

  • Puntos de verificación y recuperación: Las aplicaciones por lotes toman puntos de verificación en ubicaciones predeterminadas. Todos los datos que pasan por una de estas ubicaciones se guardan en el disco (a no ser que el punto de verificación no haya sido comprobado con éxito). La recuperación consiste simplemente en reiniciar una aplicación en el último punto de verificación que tuvo éxito.

    Las aplicaciones en tiempo real pueden tomar puntos de verificación entre transacciones con una frecuencia que puede ser tan alta como para hacerlo con cada transacción. O pueden, también, hacerlo con menor frecuencia y según otros criterios (como el tiempo transcurrido, o el número de transacciones). Una aplicación reiniciada automáticamente retoma el procesamiento en la última transacción registrada con éxito por el punto de verificación.

Interfaz con una amplia gama de sistemas en tiempo real

Continuous>Flows de Ab Initio suministra interfaces con una amplia gama de sistemas en tiempo real:

  • sistemas de colas de mensajes de terceros: IBM MQ, JMS, RabbitMQ, Kafka y Microsoft MQ. Ab Initio proporciona componentes para conectar directamente con todos estos sistemas de colas de mensajes.
  • servicios web: WebSphere, WebLogic, IIS y Apache/Tomcat.
  • colas de mensajes de Ab Initio y RPC para conexiones de punto a punto de latencia baja y volumen alto entre aplicaciones de Ab Initio.
  • software de mensajería heredado o interno.

Soporte nativo para servicios web y SOA

Las aplicaciones de Ab Initio pueden implementar fácilmente servicios web en una arquitectura orientada a servicios (SOA). Esto se logra mediante un servlet proporcionado por Ab Initio que está instalado en el servidor de aplicaciones estándar que elija el cliente: WebSphere, WebLogic, IIS o Apache/Tomcat. El servlet proporciona un mecanismo de registro para asociar invocaciones a un servicio web determinado con aplicaciones de Ab Initio específicas. Cuando se recibe una invocación a un servicio web, el servlet se comunica con la aplicación de Ab Initio vía TCP (la aplicación de Ab Initio se ejecuta en su propio conjunto de procesos y está fuera del servidor de aplicaciones), para devolver después al solicitante original los resultados remitidos por la aplicación de Ab Initio.

El Co>Operating System también proporciona compatibilidad total con el análisis de mensajes definidos por WSDL.

Interfaces con sistemas de mensajería de propósito especial y heredados

Los productos de colas de mensajes comerciales y los servicios web son relativamente nuevos en la industria y ofrecen tasas de rendimiento modestas. Los clientes con grandes volúmenes de mensajes han armado soluciones de mensajería internas de alto rendimiento (como también lo han hecho aquellas empresas cuyas necesidades son anteriores a la aparición de productos comerciales de colas de mensajes).

Continuous>Flows suministra interfaces robustas compatibles con estas soluciones heredadas a través de componentes de procesamiento especiales (“Universal Subscribe” y “Universal Publish”). Estos componentes invocan subrutinas de C++ personalizadas que se comunican con el sistema de mensajería heredado. También manejan la restitución y la recuperación en caso de errores.

Ab Initio, en combinación con los sistemas de mensajería de propósito especial, puede alcanzar tasas de rendimiento extremadamente altas. Se han llegado a medir tasas continuadas de más de 500 000 mensajes por segundo en aplicaciones de misión crítica.

Además, los componentes Universal Subscribe y Universal Publish se utilizan de la misma forma que los componentes de Continuous>Flows para productos de colas de mensajes creados por terceros. Esto proporciona a los usuarios la opción de cambiar su solución de colas de mensajes interna por un producto de colas de mensajes de terceros. Y de forma sencilla, además: haciendo simplemente unos cambios menores en sus aplicaciones de Ab Initio.

Robustez en caso de errores

Los puntos de verificación del Co>Operating System proporcionan un manejo robusto de los errores de la aplicación. Un punto de verificación permite que una aplicación confirme cambios en varias bases de datos y sistemas de entrada y de salida (colas). En el caso de que se produzca un error en la aplicación, el Co>Operating System “restituye” el entorno hasta el último punto de verificación que tuvo éxito. Cuando se haya solucionado el problema subyacente (“la base de datos no se puede cargar”, “no hay espacio suficiente en el disco”, “hay un error en la red”, son algunos de los mensajes), la aplicación se puede reiniciar. En ese caso, retomará el procesamiento automáticamente desde la última transacción procesada con éxito.

Es sabido dentro de la industria que, en general, los esquemas de puntos de verificación consumen una cuota elevada de recursos computacionales. Los intentos de los desarrolladores por minimizar ese gasto suelen dar lugar a aplicaciones inestables y complejas. La arquitectura del Co>Operating System fue diseñada tanto para tener un rendimiento extremadamente alto como para que sea robusta. El Co>Operating System proporciona alternativas a los puntos de verificación que compensan la latencia de transacciones frente al tiempo de recuperación. En todos los casos, el Co>Operating System garantiza que, en última instancia, cada una de las transacciones sólo se escriba una vez en todos los dispositivos de destino (bases de datos, archivos y colas).

El Co>Operating System recurre a dos mecanismos básicos para fijar los puntos de verificación. El más conocido es el protocolo estándar XA para confirmaciones en dos fases. El Co>Operating System incluye un administrador de transacciones que coordina las confirmaciones a través de productos de bases de datos y de colas de mensajes dispares (que puede, incluso, procesar transacciones por lotes en una confirmación única para incrementar así el flujo transmitido).

Sin embargo, el protocolo XA entraña ciertas limitaciones. Además de incurrir en un gasto elevado de recursos computacionales y de ser complejo de administrar, no es compatible con todos los dispositivos de entrada y de salida deseados. De ahí, que la mayor parte de los usuarios de Ab Initio dependan del mecanismo de puntos de verificación nativo del Co>Operating System, muy similar a una confirmación en dos fases. Este mecanismo, que destaca por su rendimiento elevado y robustez, funciona con todos los dispositivos de entrada y de salida con los que se conecta Ab Initio (bases de datos, archivos y colas). Y funciona, además, con servidores en ambientes heterogéneos y distribuidos. Ab Initio también ha integrado en sus componentes de conector maneras de compensar las limitaciones de ciertos productos de colas de mensajes de otros desarrolladores de software. Quizá se entienda con un ejemplo: en ciertos productos, el fallo de un administrador de colas de mensajes puede hacer que las transacciones se entreguen más de una vez.

Con el sistema de puntos de verificación nativo del Co>Operating System, se puede controlar la frecuencia de los puntos de verificación de varias maneras. Como por ejemplo, a través del número de transacciones y el tiempo transcurrido; o a través del resultado de un evento como un testigo especial en la secuencia de mensajes. Además, se puede controlar el grado de coherencia transaccional en el tiempo del punto de verificación a través de varios dispositivos de salida. Las opciones de configuración por defecto dan como resultado un rendimiento muy alto, ya que nunca se pierden transacciones y tampoco se sacrifica la corrección de la aplicación.

Robustez operacional

El Co>Operating System satisface con rigor las exigencias operacionales para las aplicaciones en tiempo real de misión crítica. Algunos ejemplos de mecanismos son:

  • la ejecución de varias instancias de una aplicación en tiempo real, y al mismo tiempo, para el equilibrio de las cargas y la conmutación por error;
  • la desactivación de fragmentos de un sistema de aplicaciones para que unos módulos actualizados puedan ser iniciados sin suspender un sistema nonstop que brinda soluciones las 24 horas del día;
  • la agrupación de conexiones con las bases de datos para limitar el uso de recursos;
  • la agrupación de varios componentes (“folding”) en un proceso único para disminuir el gasto de CPU y el consumo de memoria;
  • la utilización de “micrografos” (lógica de grafos que se puede cargar dinámicamente) para reducir dramáticamente el uso de recursos del sistema operativo.

Conclusión

El enfoque con el que Continuous>Flows resuelve el procesamiento en tiempo real combina tres elementos. A saber: un incremento de la productividad fruto de la implementación de flujos de datos gráficos; un modelo general para establecer la conexión con secuencias de datos; y, por último, mecanismos robustos para trabajar de manera confiable con puntos de verificación y para coordinar transacciones.

English
Français
Idioma:
Español
Deutsch
简体中文
日本語