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.
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 :
Les architectes d'applications sont souvent confrontés à la nécessité de respecter des exigences de performance apparemment contradictoires :
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.
Continuous>Flows d'Ab Initio fonctionne avec un large éventail de systèmes en temps réel :
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.
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.
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.
Le Co>Operating System répond aux conditions de fonctionnement requises pour les applications stratégiques en temps réel. Voici quelques fonctions disponibles :
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.
