SOA piloté par événements

L'architecture SOA pilotée par les événements est une forme d' architecture orientée services (SOA), qui combine l'intelligence et la proactivité de l'architecture pilotée par les événements avec les capacités organisationnelles des offres de services . Avant l'architecture SOA pilotée par les événements, la plate-forme SOA classique orchestrait les services de manière centralisée, via des processus métier prédéfinis, en supposant que ce qui aurait dû être déclenché est défini dans un processus métier. Cette approche plus ancienne (parfois appelée SOA 1.0) ne tient pas compte des événements qui se produisent dans ou en dehors de processus métier spécifiques. Ainsi, les événements complexes, dans lesquels un modèle d'activités (à la fois planifiées et non planifiées) doit déclencher un ensemble de services, ne sont pas pris en compte dans l'architecture SOA 1.0 traditionnelle.

L'architecture SOA 2.0 (« SOA pilotée par événements ») permet aux utilisateurs professionnels de surveiller, d'analyser et d'enrichir les événements afin d'établir des liens entre des événements disparates qui ne semblent pas à première vue évidents. Cela rend ces événements enrichis visibles pour d'autres, en particulier les analystes commerciaux ou les directeurs marketing, et permet également au système SOA 2.0 d'automatiser éventuellement les actions à entreprendre pour traiter un modèle unique.

SOA 2.0 permet de créer des événements métier de haut niveau à partir de nombreux événements système de bas niveau. Les événements sont créés en filtrant des données en temps réel (provenant de middleware, d'applications, de bases de données et de services Web, par exemple) et en les enrichissant de détails déterminants tels que des dépendances ou des relations de cause à effet découvertes en corrélant d'autres événements.

Si les événements enrichis générés par un environnement SOA 2.0 montrent clairement que le taux d'abandon des paniers d'achat des clients a augmenté au cours des derniers jours, une notification au service marketing pourrait lancer une recherche sur les mesures prises par les concurrents pour inciter les clients à acheter des produits ailleurs. Y avait-il un produit commun dans la plupart des paniers d'achat ? Si oui, quels sont les prix proposés par la concurrence ?

En pratique, cette relation entre les événements diffusés en continu est traitée par un moteur de vecteurs causaux, qui effectue une recherche en fonction des événements récemment visualisés et attribue un vecteur causal à un événement si une relation est découverte. Si A est la cause de B, le moteur de vecteurs causaux vérifie si l'index de règle du vecteur causal de B contient une référence à A. Le moteur peut gérer simultanément des événements pour différentes transactions, peut-être dans un ordre différent de celui dans lequel ils se sont produits.

Contrairement aux systèmes séquentiels ou procéduraux (dans lesquels les clients doivent interroger les demandes de modification), l'architecture SOA pilotée par événements permet aux systèmes et aux composants de répondre de manière dynamique, en temps réel, à mesure que des événements se produisent. SOA 2.0 complète et étend SOA 1.0 en introduisant des capacités de traitement de longue durée.

La capacité de traitement à long terme permet à l'architecture de collecter divers événements asynchrones sur une longue période et de corréler ces événements dans des relations de cause à effet. Les modèles d'événements SOA 2.0 peuvent être conçus et mis en œuvre pour rechercher des relations d'événements qui s'étendent sur des jours, des semaines ou des mois ; et lorsque certains critères sont remplis, déclencher un processus métier pour traiter le modèle d'événement.

La programmation pilotée par événements SOA 2.0 est structurée autour du concept de relations découplées entre producteurs et consommateurs d'événements : un consommateur d'événements ne se soucie pas de savoir où ou pourquoi un événement se produit ; il se préoccupe plutôt de savoir s'il sera invoqué lorsque l'événement se produit. Les systèmes et les applications qui séparent les producteurs d'événements des consommateurs d'événements s'appuient généralement sur un répartiteur d'événements, ou canal. Ce canal contient une file d'attente d'événements qui agit comme intermédiaire entre les producteurs d'événements et les gestionnaires d'événements.

Le paradigme prototypique SOA 2.0 contient quatre éléments essentiels :

1. plusieurs événements de système de bas niveau qui, séparément, ne semblent pas avoir de relation, mais grâce à la détection de modèles en comparant ces nombreux événements, une corrélation inhabituelle ou moins évidente devient évidente ;
2. un certain degré d’enrichissement des données par l’infusion d’informations liées à chaque événement afin d’illustrer plus clairement comment les nombreux événements sont liés ;
3. une condition de déclenchement qui, si elle n'est pas remplie, n'entraîne pas la création de l'événement de niveau métier, mais lorsque la condition de déclenchement est remplie, l'événement métier de niveau supérieur est créé ;
4. un processus humain ou automatisé qui est invoqué lorsque l'événement déclencheur est atteint.

Les services Web SOA 2.0 peuvent être composés de deux manières : orchestration et chorégraphie. Dans l'orchestration, un processus central prend le contrôle des services Web impliqués et coordonne l'exécution des différentes opérations sur les services Web impliqués dans l'opération. Les services SOA 2.0 impliqués ne savent pas (et n'ont pas besoin de savoir) qu'ils font partie d'une composition ou d'un processus métier supérieur. Seul le coordinateur central de l'orchestration le sait, de sorte que l'orchestration est centralisée avec des définitions explicites des opérations et l'ordre d'invocation des services SOA 2.0.

La chorégraphie, en revanche, ne repose pas sur un coordinateur central. Au contraire, chaque service SOA 2.0 impliqué dans la chorégraphie sait exactement quand exécuter ses opérations (en fonction de critères de déclenchement définis) et avec qui interagir. La chorégraphie est un effort collaboratif axé sur l'échange de messages. Tous les participants à la chorégraphie doivent être conscients du processus métier, des opérations à exécuter, des messages à échanger et du calendrier des échanges de messages.

BPEL suit le paradigme de l'orchestration. La chorégraphie est couverte par d'autres normes, telles que WSCI (Web Services Choreography Interface) et WS-CDL (Web Services Choreography Description Language).

Les relations de cause à effet sont inhérentes au monde qui nous entoure et sont intrinsèques à notre prise de décision. L’intelligence humaine traite et rassemble ces relations plus rapidement que les capacités de calcul artificielles actuelles. L’un des obstacles fondamentaux de l’intelligence artificielle est l’absence d’une capacité automatisée à relier les événements entre eux comme lorsqu’un humain utilise son intuition.

En utilisant un moteur vectoriel causal, la perception de la causalité peut être améliorée dans des conditions spatiotemporelles appropriées basées sur des règles structurelles et temporelles inscrites dans le moteur. La perception de sémantiques causales complexes, telles que les causalités additives, médiatisées et bidirectionnelles, doit être codée afin que le moteur puisse faire la distinction entre les événements qui sont liés et ceux qui semblent seulement être liés mais qui, en fait, ne le sont pas.

Le moteur utilise la propagation du taux de variation du vecteur causal prépondérant pour coder la relation entre les événements et établit un ordre partiel dans lequel il valide la causalité perçue entre plusieurs occurrences. Le moteur lit et rejoue la séquence d'événements dans un ordre temporel différent pour déduire ce qui pourrait être des connexions topologiques liées et compare ces rejouements à des règles préprogrammées par un analyste .

Plusieurs événements système de bas niveau sont traités par le moteur de vecteurs causaux et comparés à ces règles pour déclencher des événements métier de niveau supérieur. Pour ce faire, il utilise une application console de moteur de vecteurs causaux (CVE) qui affiche les événements en temps réel pour les analystes métier. Alors que les flux d'événements peuvent être observés au fur et à mesure qu'ils se produisent, à la manière d'un cours boursier, l'application console CVE comporte plusieurs fenêtres qui répertorient les mêmes événements dans différents contextes, afin que les analystes métier puissent voir ce que fait le CVE avec les relations entre eux.

La fenêtre séquentielle affiche les événements dans l'ordre de date et d'horodatage, une ou plusieurs autres fenêtres dans divers ordres tandis que le CVE parcourt la liste des règles et crée des relations implicites entre les événements. Différents boutons et contrôles existent dans l'application console qui permettent aux analystes commerciaux de créer des relations entre les événements à la volée et de définir des règles qui répondent à ces relations.

Les analystes commerciaux peuvent ajouter des détails supplémentaires à la définition de l'entreprise grâce à une instruction de requête SQL associée à une règle ou à un contexte d'événement. L'application CVE fonctionne de manière très similaire à une application de trading d'actions moderne que les gestionnaires de fonds communs de placement utilisent pour gérer les risques. Un exemple d'application et de moteur CVE peut être vu dans SILK.

La plupart des implémentations de bus de services d'entreprise (ESB) contiennent une fonctionnalité appelée « médiation ». Par exemple, les flux de médiation font partie de l' interception du bus de services d'entreprise WebSphere . Mule prend également en charge les flux de médiation. Les flux de médiation modifient les messages transmis entre les services existants et les clients qui utilisent ces services. Un flux de médiation sert de médiateur ou intervient pour fournir des fonctions, telles que la journalisation des messages, la transformation des données et le routage. En général, les fonctions peuvent être implémentées à l'aide du modèle de conception d'interception.

Lorsque les messages transitent par l'ESB, celui-ci enrichit les messages destinés à un canal qui surveille un événement métier de haut niveau. Autrement dit, pour chaque message, l'ESB peut interroger une base de données pour obtenir des informations supplémentaires sur une entité de données au sein du message. Par exemple, en fonction de l'ID client, le flux de médiation ESB peut obtenir le code postal dans lequel réside le client. Ou, en fonction de l'adresse IP de la demande d'origine de l'utilisateur final, le flux de médiation ESB peut rechercher dans quel pays, état ou comté se trouve cette adresse IP.

Ces exemples représentent l’enrichissement des données, le concept d’ajout de valeur supplémentaire aux données existantes, en fonction de l’intention de l’événement commercial de haut niveau qui doit finalement être déclenché.

Un flux de médiation ESB est l'un des types de composants d'une architecture de composants de service (SCA). Comme tout composant SCA, le programme accède à un flux de médiation via les exportations qu'il fournit, et le flux de médiation transmet les messages à d'autres services externes via les importations. Des types spéciaux d'importations et d'exportations pour JMS , appelés liaisons JMS, permettent aux développeurs de spécifier la configuration de liaison et d'écrire le code de gestion des données. Le flux de médiation se compose d'une série de primitives de médiation qui manipulent les messages lorsqu'ils circulent dans le bus .

Une fois que les développeurs ont codé la liaison personnalisée pour l'exportation et l'importation, ils peuvent commencer à se concentrer sur le composant de flux de médiation. Dans l'éditeur d'assemblage WebSphere Integration Developer, cette opération est effectuée par le composant de médiation de liaison personnalisée JMS, où chaque opération sur l'interface du composant de flux est représentée par une demande et une réponse.

Le framework SDO ( Service Data Objects ) fournit un cadre unifié pour le développement d'applications de données. Avec SDO, les développeurs n'ont pas besoin de connaître une API spécifique pour accéder aux données et les utiliser. Grâce à SDO, les développeurs travaillent simplement avec des données provenant de plusieurs sources de données, telles que des bases de données relationnelles, des composants EJB d'entité, des pages XML, des services Web, l'architecture des composants de service et des pages JavaServer.

Les flux de médiation sont entièrement indépendants des liaisons utilisées dans les importations et les exportations. En fait, l'objectif d'une conversion en instance SDO DataObject en dehors de l'implémentation du flux est que les flux de médiation peuvent alors être créés sans connaître le protocole et le format avec lesquels les messages sont envoyés vers et depuis le module de médiation.

Une condition de déclenchement au niveau de l'entreprise permet à l'architecture SOA 2.0 d'établir des solutions de veille client en temps réel , d'automatisation du marketing et de fidélisation de la clientèle, entre autres fonctionnalités. Les objets métier modélisent des entités du monde réel dans l'architecture, telles que les clients, les comptes, les prêts et les itinéraires de voyage. Lorsque l'état de l'un de ces objets change et qu'un agent de surveillance remarque que ce changement est significatif (par rapport à la liste des critères à surveiller), un événement est créé et transmis aux autres agents de surveillance.

Par exemple, la détection d'un problème ou d'une opportunité commerciale réels peut entraîner une augmentation des revenus. Si un client annule une commande, une capacité de production supplémentaire peut réduire la rentabilité de la production. Un événement SOA 2.0 peut avertir le service marketing de créer une campagne de vente spéciale qui revendrait la capacité excédentaire, récupérant ainsi le coût par unité rentable d'origine.

Surveillance automatique des événements dans les activités des processus opérationnels au fur et à mesure de leur exécution pour voir si une action immédiate doit être entreprise à l'intérieur ou à l'extérieur de l'entreprise. Ces agents de surveillance testent en permanence les conditions commerciales spécifiques et les changements dans les opérations commerciales. Si nécessaire, les agents alertent les personnes, font des recommandations, envoient des messages à d'autres applications ou invoquent des processus commerciaux entiers lorsque de telles conditions ou changements se produisent.

Un processus opérationnel déclenché doit soutenir directement la croissance des revenus grâce à la maîtrise des coûts, à la réactivité aux conditions commerciales ou à la capacité à saisir de nouvelles opportunités de marché. Les processus opérationnels qui en résultent peuvent également mesurer les progrès opérationnels vers la réalisation des objectifs, contrôler les coûts opérationnels en communiquant uniquement ce qui est nécessaire à ceux qui ont besoin de le savoir, ou signaler l'état de performance des processus clés aux principaux décideurs.

Par exemple, vous pouvez créer un événement CRM à partir d'un message « panier abandonné » (en analysant la transaction, l'ID client et l'heure), en utilisant d'autres filtres pour extraire la valeur des produits dans le panier et en exploitant les capacités de corrélation du système pour ajouter des indicateurs de causalité tels que des problèmes de performances du site de commerce. Votre événement CRM peut également inclure la valeur ou le rang du client dans la base de données client...

À titre d’exemple, en fonction des types d’appels de service indépendants reçus, la plateforme SOA 2.0 pourrait identifier un défaut de produit en détectant le modèle sous-jacent des plaintes distinctes, puis en déclenchant une alerte à l’ingénierie ou à la production concernant le défaut éventuel.

La fonctionnalité de publication/abonnement est un mécanisme qui peut être utilisé dans la plupart des implémentations de bus de services d'entreprise SOA 1.0. En implémentant la fonctionnalité ESB sous forme de messages Pub/Sub, aucune connaissance avancée des événements système n'est nécessaire pour créer des modèles de messages SOA 2.0. Une fois qu'une entreprise a implémenté de nombreuses fonctions de publication, les analystes de middleware SOA peuvent se lancer dans la tâche de déterminer quels messages de publication disponibles peuvent être assemblés dans un modèle unique pour détecter un déclencheur enrichi SOA 2.0.

Les mécanismes du moteur vectoriel causal (CVE) sont mis en œuvre simplement, avec une vue extensible des constructions SQL écrites dans des procédures stockées . Si A provoque B et que la causalité doit se produire dans un nombre N de transactions, alors la clause d'horodatage SQL ORDER BY crée un ensemble de résultats qui incrémente un compteur de toutes les transactions qui se sont produites dans un laps de temps, un nombre N de transactions B correspondant à l'occurrence A. La création de procédures stockées supplémentaires est réalisée via l'application console CVE ou en utilisant n'importe quelle boîte à outils de développeur de base de données standard.

Les algorithmes de domaine, tels que la logique de domaine fièvre/grippe/infection dans la référence citée, sont utilisés pour dériver le code SQL qui applique les règles métier sélectionnées au cas d'utilisation. L'utilisation de CVE dans les environnements SOA améliore l'agilité de l'entreprise car l'application des principes SOA 2.0 identifie les opportunités commerciales qui auraient autrement été manquées ou identifiées beaucoup plus tard.

L'imagerie par résonance magnétique fonctionnelle (IRMf) utilisant l'analyse de causalité de Granger (GCA) détecte les effets causaux entre les régions du cerveau. Les résultats d'un test d'échantillon ont démontré un effet causal positif entre le rFIC et le cortex cingulaire antérieur dorsal (dACC).

Le moteur d'analyse Oracle CVE utilise un ensemble de modèles théoriques, chacun d'entre eux évaluant une partie ou la totalité des données. Lorsqu'un analyste d'entreprise configure des facteurs causaux, il spécifie des critères indiquant quels modèles doivent prendre en compte quel facteur causal.