I.3 Les pistes de réponse à l’agilité des processus
I.3.1 Les événements
I.3.1.1 Définition de l’événement
Le terme événement provient du latin evenire, qui signifie advenir. Dans son accep- tion étymologique, le mot événement recouvre tout ce qui se produit, arrive ou apparaît (sens général). Au pluriel, les événements désignent l’ensemble des faits qui créent telle ou telle situation, telle conjoncture [Larousse (dictionnaire), 2013].
Dans la littérature scientifique, deux courants de pensée existent : le premier affirme que l’événement est forcément lié à l’activité, le second défend le fait que l’événement n’est pas nécessairement lié à l’activité et précise que l’activité peut ou non utiliser l’évé- nement (cette deuxième tendance est plus proche de ce que nous allons utiliser.) [Morley et al., 2007], pour qui un événement est « quelque chose qui arrive et qui provoque le déclenchement d’une activité », s’inscrit clairement dans le premier cas. L’acteur res- ponsable de cette activité doit être informé que l’événement s’est produit. C’est pour- quoi l’événement est souvent matérialisé par de l’information. L’événement est aussi vu dans [Morley et al., 2007] du point de vue processus, comme « un stimulus qui provoque une réaction dans une activité ». La notion de stimulus traduit le fait qu’un événement est quelque chose qui arrive, sans impliquer aucun acteur de l’activité et sans consom- mer aucune de ses ressources. Toujours d’après [Morley et al., 2007], un événement est toujours associé à une ou plusieurs activités sur lesquelles il agit. Un même événement peut agir sur plusieurs activités, permettant alors d’indiquer les activités pouvant se dérouler en parallèle. Inversement, plusieurs activités peuvent être associées à la même activité. Dans ce cas, l’activité est dotée d’une règle de synchronisation indiquant si les événements doivent être ou non simultanés.
Cependant [Chandy and Schulte, 2009] donnent une définition plus large de l’événe- ment, sans le lier nécessairement à l’activié. L’événement est « quelque chose qui arrive ». Ils ajoutent que la caractéristique fondamentale des événements est qu’ils ne peuvent pas être entièrement prévus. Compte tenu de ce fait, nous ne pouvons pas prédire quand un événement critique va arriver.
On peut trouver une définition proche de celle de Chandy dans le Glossaire du Management des Événements, créé par le symposium EPTS (Event Processing Technical Society) [EPTS, 2008] dans le but de poser les fondations d’une standardisation des concepts de traitement d’événements. Dans ce glossaire dont l’approche consiste à définir chaque terme indépendamment d’un produit, d’une implémentation ou d’un domaine d’application particulier, (Luckham et al., 2008) définissent un événement suivant deux dimensions :
• L’activité qui a lieu et engendre l’événement. L’événement est ainsi vu comme tout ce qui advient ou dont l’avènement est envisagé, par exemple une opération financière, un atterrissage d’avion, un capteur qui fournit des données, un chan- gement d’état dans une base de données ou d’une machine à états finis, le séisme au large des côtes de Honshu, l’abolition de l’esclavage, la bataille de Marathon. • La formalisation, c’est-à-dire la représentation de cette activité dans un système informatique (objet, message, tuple). L’événement est alors un objet qui repré- sente, encode, enregistre un fait, généralement à des fins de traitement informa- tique. Par exemple : un ordre d’achat (enregistré comme une activité d’achat), un email de confirmation d’une réservation de vol, une fiche de réclamation client, le résultat d’une lecture d’un capteur RFID (Radio Frequency IDentification). Les événements reçus sont manipulés par les systèmes informatiques par traitement de leurs représentations en tant qu’objets événement. La même activité peut être re- présentée par plus d’un objet événement, et chaque objet événement peut enregistrer différents attributs de l’activité.
I.3.1.2 Le recueil des événements
Tels que décrits dans le précédent paragraphe, les événements sont porteurs de don- nées concernant l’état d’une partie du système ou du système de traitement. Ils repré- sentent les données informant du statut d’une activité, les données émises par un capteur, l’émission d’un rapport par un pompier sur le terrain, la réception d’un ordre par un sous-traitant, etc. Ainsi que définis par [Luckham and Schulte, 2008], les événements peuvent être considérés comme les instances d’un type d’événement : par exemple, tous les événements émis par un certain type de capteur auront le même type, c’est-à-dire la même structure et les mêmes propriétés.
Le mécanisme d’émission et de réception des événements est basé sur le paradigme pu- blication/abonnement (publish/subscribe). Dans un système publication/abonnement, les abonnés, aussi appelés consommateurs, peuvent exprimer leur intérêt pour un type d’événement ou un motif de types d’événements, et être notifiés de la génération de n’importe quel événement émis par les producteurs qui correspond à cet intérêt. Les événements sont propagés de façon asynchrone3. En effet, un service prévient tous ses
abonnés par émission d’un événement qu’il vient de réaliser une opération donnée. En- suite, c’est aux consommateurs de traiter cet événement.
Par conséquent, l’ensemble du système est chargé de faire la correspondance entre les événements émis et les abonnements, et de ne transmettre des producteurs aux consom- 3. En informatique, l’asynchronisme signifie que le programme A qui envoie des données à un pro- gramme B via la fonction a n’attend pas la réponse de B à A pour continuer à s’exécuter. Typiquement, une communication par email est asynchrone (A envoie un email à B, et n’attend pas la réponse de B pour vaquer à ses occupations) alors qu’une communication téléphonique est une communication syn- chrone (A appelle B et doit attendre que B ait fini de lui parler pour raccrocher et passer à une autre activité).
mateurs que les événements pertinents. L’intérêt d’un tel système est la possibilité de disséminer une grande quantité d’information à un large ensemble de consommateurs. Chaque consommateur reçoit alors uniquement l’information qui correspond à son abon- nement : ceci évite de surcharger les consommateurs en information inutile (« flood ») et de rendre cette dernière inexploitable (au mieux).
Une de nos hypothèses de travail est que l’architecture des SI des partenaires de la collaboration est orientée services (SOA). L’architecture SOA est une forme d’architec- ture de médiation qui repose sur les interactions entre des composants logiciels appelés services. Un service est une fonctionnalité définie d’un SI qui est divisée en opérations. Les Services Web présentent l’avantage supplémentaire d’être accessible à travers un ré- seau (Internet, intranet, etc.) via des interfaces permettant l’appel des opérations sans accéder à leur mécanique proprement dite. Les services communiquent entre eux via des messages.
Notre nouvelle hypothèse est que les web services des partenaires de la collabora- tion sont capable d’émettre et de recevoir des événements. A cette fin, ils proposent des fonctionnalités d’émission et d’abonnement aux événements. Pour cela, ils implémentent les recommandations de la norme WS-Notification pour gérer les mécanismes publica- tion/abonnement [OASIS, 2006b, OASIS, 2006c, OASIS, 2006a]. Ainsi, un web service peut envoyer des événements à propos de son état (invoqué, en cours d’exécution, ter- miné, interrompu) en sus des habituels échanges de messages (par exemple, un relevé de mesure en réponse à une requête émise par le système de surveillance de la centrale) avec les autres web services. Les capteurs et autres appareils situés sur le terrain envoient également des événements concernant les mesures qu’ils observent : ces événements per- mettent de constituer une photographie de la situation collaborative et de suivre son évolution. De façon à collecter tous les événements concernant la situation collaborative, l’abonnement portera sur tous les types d’événements provenant tant de l’exécution des workflows collaboratifs que du terrain de la collaboration.
I.3.1.3 Le traitement des événements complexes
Une fois les événements collectés, il faut les traiter pour en extraire l’information pertinente (au regard des objectifs de la collaboration). Pour cela, un traitement infor- matique va réaliser des opérations sur les événements, incluant la lecture, la création, la transformation, la suppression et l’abstraction des données portées par ces événements. C’est ce que l’on appelle le CEP (Complex Event Processing). Le moteur de CEP va « écouter » les événements entrants et les passer au crible d’un ensemble de règles métier (contenant des motifs d’événements4) définies par les acteurs de la situation collabo-
4. Un motif d’événement permet la détection de séquences d’événements liés par des relations tem- porelles, de causalité, etc.. Lorsqu’une séquence d’événements correspond à un motif, elle constitue une instance de ce motif. Exemple (très simple) de motif : l’événement B suit l’événement A dans un laps de temps de 20 secondes.
rative. Si des événements entrants réalisent une instance de motif d’événements, alors les règles liées à ce motif sont exécutées et permettent au moteur de CEP de générer de nouveaux événements. Ces nouveaux événements constituent donc de nouvelles don- nées, qui peuvent enrichir la connaissance concernant la situation collaborative et son environnement.
Un exemple de règle métier très simple peut être :
SI (vitesse du vent > 50 km/h) et (taux de radiation augmente de 5%)
durant les 5 dernières minutes)
ALORS GénérerEvénement(Alerte())
Un moteur de CEP peut, à travers les règles métier, réaliser plusieurs types de filtrage et d’agrégation des données : ceci sera détaillé dans les chapitres suivants.
De façon à collecter tous les événements concernant la situation collaborative et à pouvoir en déduire de nouveaux événements (i.e. de nouvelles données), le moteur de CEP s’abonne à tous les types d’événements provenant tant de l’exécution des workflows collaboratifs que du terrain.