Oswald Regular
OpenSans Regular
Continuous>Flows®

Le traitement en temps réel des données métier est particulièrement difficile, et rares sont les logiciels aptes à en braver les contraintes. Avec Ab Initio®, c'est mission accomplie.

Ab Initio offre un large éventail d'applications temps réel : des applications par mini-lots aux applications de "messagerie asynchrone" aux volumes élevés, des applications orientées service (SOA) à celles de requête/réponse à faible latence. Toutes intègrent une seule et unique technologie : la fonction Continuous>Flows® du Co>Operating System.

Le Co>Operating System® est un moteur de flux de données. Ce moteur fait circuler des flux d'enregistrements ou de transactions dans une séquence de "composants". Chacun des composants effectue divers traitements sur les données d’entrée, en appliquant des règles métier, par exemple, pour produire des enregistrements de sortie. La logique de traitement complexe est décomposée en étapes, chacune étant réalisée par un composant différent. Les enregistrements circulent dans le jeu de composants nécessaire jusqu'à ce que le traitement soit terminé.

Ce modèle de flux de données convient parfaitement aux traitements batch et temps réel. Une application batch peut être similaire, si ce n'est identique, à l'application temps réel correspondante. Ce sont les composants à chaque extrémité qui déterminent si l'application est considérée comme un traitement batch ou temps réel. En effet, une application batch se connecte à des fichiers plats et à des composants de table de base de données. Une application temps réel se connecte à des files d’attente de messagerie, des services Web, des appels de procédure à distance (RPC), des serveurs CICS et/ou à des composants particuliers (généralement via TCP/sockets).

Avec Ab Initio, la similarité entre les applications batch et celles en temps réel, ainsi que l'utilisation d'une même technologie (le Co>Operating System) simplifie le processus et permet d'améliorer les performances. Cette complexité réduite se traduit par une productivité accrue et l'amélioration des performances permet de diminuer les coûts.

Réutilisation de la logique métier entre les applications batch et les applications temps réel

La plupart du temps, les composants de logique métier, situés entre ceux d’entrée et ceux de sortie, restent inchangés, ce qui signifie que la même logique métier peut être réutilisée pour les applications batch et pour celles en temps réel. Cela améliore nettement la productivité. Avec les approches non-Ab Initio, les technologies et méthodologies de traitement batch et temps réel sont généralement très différentes, si bien que la même logique métier doit être réimplémentée plusieurs fois. En revanche, avec Ab Initio, la logique métier est développée une seule fois, puis appliquée dans les infrastrucures batch et temps réel :

Optimisation des performances pour différents modèles d'exécution en temps réel

Les architectes d'applications sont souvent confrontés à la nécessité de respecter des exigences de performance apparemment contradictoires :

  • Les applications batch doivent traiter les données de manière aussi efficace que possible. L'exécution d'une tâche batch peut être longue en raison du grand nombre de transactions à traiter, et aucun résultat n'est disponible tant que la tâche n'est pas terminée. Toutefois, pendant son exécution, une tâche batch est censée pouvoir traiter un très grand nombre d'enregistrements par seconde.
  • Les applications par "mini-lots" sont des ensembles de tâches batch traitant chacun de petits volumes de données. Il peut cependant y avoir des milliers, voire des dizaines de milliers, de petites tâches de ce type exécutées chaque jour. En limitant la quantité de données traitée par une tâche, il est possible de réduire le temps de réponse de cette dernière. Cette approche permet également à ces mêmes applications de traiter de très gros volumes de données de manière efficace dans une configuration batch classique. (La solution Ab Initio Conduct>It® facilite la gestion de dizaines de milliers de tâches par jour et les complexités qui y sont liées)
  • Les applications de messagerie asynchrones se connectent à des files d’attente de messages et doivent également traiter les transactions de manière efficace. Cependant, les systèmes en aval doivent généralement recevoir leurs messages de réponse dans un délai compris entre quelques secondes et quelques dizaines de secondes. En effet, si une application asynchrone peut répondre en une ou deux secondes, une utilisation interactive est possible.
  • Les applications « requête/réponse » ou applications de messagerie synchrones sont censées traiter une transaction dès qu'elle se présente et y répondre aussi rapidement que possible, généralement avec une latence inférieure à une seconde. Si plusieurs applications de ce type travaillent de concert pour traiter une transaction, chacune d'entre elles doit répondre en dixièmes ou centièmes de seconde. Ab Initio traite en quelques dizaines de millisecondes seulement cet instant critique (contrairement aux temps de réponses de certains systèmes spécialisés).

La solution Continuous>Flows du Co>Operating System Ab Initio fonctionne avec la même efficacité pour chacun de ces modes utilisés par de nombreux clients. Ces différentes approches et leurs conditions requises ont en effet été prises en compte dès le départ dans l'élaboration du Co>Operating System.

Dans Ab Initio, il existe deux différences majeures entre les applications batch (ou par mini-lots) et les applications en temps réel :

  • Arrêt : les applications batch s'arrêtent dès qu'elles ont terminé le traitement de toutes les données de leurs entrées. Après l'arrêt, aucune ressource système ne reste associée à une application batch.

    Une fois démarrées, les applications en temps réel restent actives indéfiniment pour recevoir et traiter les transactions qui arrivent sur leurs entrées. En cas de temps mort dans le flux, une application temps réel attend simplement l'arrivée de nouvelles transactions.

  • Points de reprise et récupération : les applications batch prennent les points de reprise à des emplacements prédéterminés d’une application, et toutes les données qui passent sur l'un de ces emplacements sont enregistrées sur disque (si ce n'est pas le cas, le point de reprise n'a pas réussi). La récupération consiste simplement à redémarrer une application au dernier point de reprise réussi.

    Les applications temps réel peuvent créer des points de reprise entre les transactions, soit à chaque transaction soit moins fréquemment, sur la base d'autres critères (tels que le temps écoulé ou le nombre de transactions). Une application redémarrée commence automatiquement à la dernière transaction qui a passé un point de reprise sans problème.

Prise en charge de nombreux systèmes en temps réel

Continuous>Flows d'Ab Initio fonctionne avec un large éventail de systèmes en temps réel :

  • Systèmes tiers de mise en file d’attente : IBM MQ, JMS, RabbitMQ, Kafka et Microsoft MQ. Ab Initio fournit des composants permettant de se connecter directement à tous ces systèmes de mise en file d’attente.
  • Services Web : WebSphere, WebLogic, IIS et Apache/Tomcat.
  • Mise en file d'attente et appel de procédure à distance (RPC) Ab Initio pour les connexions point à point à large volume et de faible latence entre les applications Ab Initio.
  • Logiciels de messagerie existants/internes.

Prise en charge native des services Web et SOA

Les applications Ab Initio peuvent facilement implémenter des services Web dans une architecture orientée service (SOA). Cette opération est réalisée au moyen d'un servlet fourni par Ab Initio qui est installé sur un serveur d'applications standard (WebSphere, WebLogic, IIS ou Apache/Tomcat) choisi par le client. Ce servlet propose un mécanisme d'enregistrement qui associe des appels de service Web particuliers à des applications Ab Initio. Lors d'un appel de service Web entrant, le servlet communique avec l'application Ab Initio via TCP (l'application Ab Initio est exécutée dans son propre jeu de processus et se trouve en dehors du serveur d'applications) et renvoie au demandeur initial les résultats renvoyés par l'application Ab Initio.

Le Co>Operating System assure également l'analyse des messages définis par WSDL.

Interface avec des systèmes de messagerie préexistants et à usages particuliers

Les produits de mise en files d’attente et les services Web sont relativement nouveaux dans le secteur, et leurs performances sont modestes. Les clients dont la messagerie traite de larges volumes ou dont les besoins sont antérieurs à la commercialisation de produits de mise en file d’attente, ont créé leurs propres solutions de messagerie haute performance.

Continuous>Flows assure une interaction efficace avec ces solutions héritées grâce à des composants de traitement spéciaux ("Universal Subscribe" et "Universal Publish"). Ces composants appellent des sous-routines C++ personnalisées qui servent d'interface avec le système de messagerie hérité. Ils gèrent également le retour en arrière et la récupération en cas d'échec.

Ab Initio, conjointement avec les systèmes de messagerie à usages particuliers, peut atteindre des niveaux de performance extrêmement élevés : des records de plus de 500 000 messages par seconde ont été atteints dans des applications stratégiques.

Par ailleurs, les composants Universal Subscribe et Universal Publish sont utilisés de la même manière que les autres composants Continuous>Flows pour les produits de mise en file d’attente tiers. Cela permet aux utilisateurs de passer de leur solution de mise en file d’attente maison à un produit tiers sans apporter de modifications majeures à leurs applications Ab Initio.

Robustesse en cas d'échec

Avec la fonction de point de reprise du Co>Operating System, les échecs d’application sont traités de manière particulièrement fiable. Un point de reprise permet à une application de valider des modifications dans plusieurs bases de données et systèmes d'entrée et de sortie (files d'attente). En cas d'échec d'une application, le Co>Operating System effectue un retour en arrière de l'environnement jusqu'au dernier point de reprise réussi. Une fois le problème résolu (échec de chargement de la base de données, espace disque insuffisant ou panne du réseau), l'application peut être redémarrée et choisira automatiquement la sauvegarde suivant la dernière transaction traitée avec succès.

La plupart des programmes de points de reprise consomment généralement une bonne partie des ressources de traitement, et les efforts des développeurs visant à réduire ce coût aboutissent souvent à des applications complexes et instables. Le Co>Operating System a été conçu à la fois pour être performant et robuste. Il propose un certain nombre de solutions de reprise qui favorisent un juste équilibre entre temps de récupération et latence des transactions. Dans tous les cas, le Co>Operating System garantit qu'au final, l'ensemble des transactions sera écrit une seule fois sur tous les périphériques cible (bases de données, fichiers et files d'attente).

Le Co>Operating System fournit deux mécanismes fondamentaux de points de reprise. Le plus connu est le protocole XA standard pour la validation en deux phases. Le Co>Operating System comprend un gestionnaire de transactions qui coordonne les validations entre différentes bases de données et divers produits de mise en file d’attente. Il est même en mesure de traiter les transactions batch en une seule validation afin d'augmenter le débit.

Toutefois, XA comporte des limites : sa charge de traitement est élevée ; il est difficile à administrer, et il n'est pas pris en charge par tous les périphériques d'entrée et de sortie souhaités. C'est pourquoi, la plupart des utilisateurs Ab Initio ont recours au mécanisme de point de reprise natif du Co>Operating System, qui s'apparente au mécanisme de validation en deux phases. Ce mécanisme fonctionne avec tous les périphériques d'entrée et de sortie (bases de données, fichiers et files d’attente) auxquels Ab Initio se connecte, il est exécuté sur des serveurs hétérogènes et distribués, et il est très performant et extrêmement robuste. Ab Initio a même intégré dans ses composants de connexion des moyens permettant de compenser les limites de certains produits de gestion de mise en file d’attente tiers : par exemple, dans certains produits, la défaillance d’un gestionnaire de files d’attente peut entraîner une transmission répétée des transactions.

Avec le système de points de reprise natif du Co>Operating System, les développeurs peuvent contrôler la fréquence des points de reprise de diverses manières, par exemple en fonction du nombre de transactions et du temps écoulé, ou suite à un événement, telle que la présence d'un jeton spécial dans le flux de messages. En outre, ils peuvent contrôler le niveau de cohérence transactionnelle au moment du point de reprise sur plusieurs périphériques de sortie. Avec les valeurs par défaut, les performances sont élevées ; aucune transaction n'est perdue et la justesse de l'application n'est pas affectée.

Robustesse de fonctionnement

Le Co>Operating System répond aux conditions de fonctionnement requises pour les applications stratégiques en temps réel. Voici quelques fonctions disponibles :

  • Exécution simultanée de plusieurs instances d'une application temps réel pour l'équilibrage de la charge et le basculement
  • Arrêt de certains éléments d'un système d'application de sorte que des modules mis à jour puissent être démarrés sans interruption d'un système fonctionnant en continu
  • Mise en commun des connexions aux bases de données pour limiter l'utilisation des ressources
  • « Empilage » de plusieurs composants en un seul processus en vue de réduire le temps de traitement et l'encombrement de la mémoire
  • Utilisation de « micrographes » (logique de graphe chargeable de manière dynamique) afin de limiter considérablement l'utilisation des ressources du système d'exploitation

Conclusion

L'approche de Continuous>Flows en matière de traitement en temps réel permet de bénéficier d'une productivité accrue grâce aux flux de données graphiques. Elle offre également un modèle général de connexion aux flux de données et elle fournit des mécanismes robustes de points de reprise et de coordination des transactions.

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