CHAPITRE 2 : Notre approche logicielle
3.1 Définition d’agents d’orchestration π-DSL
Le modèle PIM est le lieu de définition d’orchestration de manière indépendante de tout choix
technologique.
3.1.1 Propriétés d’agents d’orchestration
Dans la littérature, un agent logiciel est caractérisé par des propriétés qui permettent de le distinguer
par rapport à un simple programme. Cela dit, selon F. Stan et A. Graesser [46] un agent logiciel est
donc un programme logiciel caractérisé par quatre propriétés principales :
Autonomie : un agent est maitre de ses décisions. son comportement n’est pas dirigé par
l’extérieur, l’agent s’autogère lui-même. Nous pouvons partager la propriété d’autonomie en
deux aspects :
o L’autonomie interne veut dire que l’agent est capable de changer son état selon son
objectif,
o L’autonomie d’action veut dire que l’agent est capable de prendre une décision en se
basant sur les informations perçues de son environnement,
Réactivité : l’agent est capable de percevoir les changements de son environnement et
de mener éventuellement des actions en réaction au changement de cet environnement,
Proactivité : un agent est capable de déterminer les actions à mener pour attendre son objectif
il se base pour cela sur son état interne et les informations perçues de son environnement,
Sociabilité : un agent est capable de communiquer avec d’autres agents, afin de mener à bien
sa mission et attendre son objectif.
Suite au travail exposé en section 2 , nous pouvons considérer une orchestration écrite en π-DSL
comme la description du comportement d’un agent logiciel. Plus généralement, à un instant donné,
l’ensemble des orchestrations en cours d’exécution peut être perçu comme une communauté d’agents
interagissant par appel de service. Nous avons évidemment introduit le concept de mobilité dans le
langage d’EIP afin d’offrir à chaque agent la possibilité de migrer sur un autre bus logiciel. Ainsi notre
79
but est de montrer par prototypage que la propriété de mobilité introduite dans un comportement
amène et entraine la propriété de tolérance aux pannes sur l’ensemble de la communauté.
La structure du langage π-DSL fait qu’une orchestration définie dans ce langage peut être qualifiée
d’agent car les quatre propriétés caractérisant un agent sont assurées par le π-DSL à savoir :
Autonomie : cette propriété est assurée par le fait qu’une orchestration comporte la
description de son comportement au sein même de sa définition.
Réactivité : le pattern Dynamic Router (cf : section 2.2.8) est défini dans le langage π-DSL afin
que les orchestrations puissent réagir aux changements dans les partenaires de cette
orchestrations.
Proactivité : le pattern Message Router (cf : section 2.2.5) permet de définir plusieurs choix
dans une orchestration. Au cours de son exécution, une orchestration se base sur son contexte
et son état afin de faire les choix dédiés à sa situation.
Sociabilité : une orchestration a pour vocation de communiquer avec d’autres orchestrations.
Le π-DSL offre pour cela une définition des patterns Message Endpoint et Request Replay (cf :
section 2.2.1) qui sont dédiés à la communication.
Vu que les propriétés caractérisant l’agent sont définies dans le langage π-DSL, une orchestration qui
est définie avec le π-DSL est considérée comme un agent logiciel dédié à l’orchestration. Nous appelons
cela un agent d’orchestration. Cet agent d’orchestration est packagé sous forme de « Bundle » une
fois que sa construction est finie. Cela a pour objectif de normaliser la structure du livrable pour qu’il
soit conforme au format consommé par les bus logiciels.
3.1.2 Définition d’un agent d’orchestration
La Figure 2.19 montre les interactions entre les composants d’un agent d’orchestration qui font appel
à un service, qui transforment le résultat de ce service avant de retourner la réponse modifiée au client
à l’initiative de l’invocation.
Figure 2-19 Exemple d’agent d'orchestration
80
𝐴𝑔𝑒𝑛𝑡𝑂𝑟𝑐ℎ(inUrl, outUri, 𝑒𝑖𝑝⃗⃗⃗⃗⃗⃗⃗) ≝ 𝑓𝑟𝑜𝑚̅̅̅̅̅̅̅〈inUrl 〉. 𝑝𝑟𝑜𝑐𝑒𝑠𝑠̅̅̅̅̅̅̅̅̅̅̅〈𝑃〉. 𝑡𝑜̅ 〈outUri 〉 (2-98)
Dans notre approche, chaque agent a une définition qui le caractérise par une orchestration qui lui est
propre. La définition d’une orchestration est à la charge du spécifieur dans le cadre des EIPs offerts par
le langage π-DSL.
3.1.3 Activation d’un agent d’orchestration
Comme le présente la Figure 2-20, un agent d’orchestration a trois états. Sa définition appartient au
PIM. Pour ses interactions avec le terme 𝑅𝑜𝑢𝑡𝑒, une structure de données est créée au niveau PIM.
L’activation expose cette structure de données en créant un 𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟 et d’autres termes
appartenant au PIM. Dans cette figure, nous faisons abstraction de quelques paramètres des termes
utilisées afin de ne pas encombrer notre illustration.
Figure 2-20 Activation d'un agent d’orchestration
𝑨𝒈𝒆𝒏𝒕𝑶𝒓𝒄𝒉 ≝ 𝒇𝒓𝒐𝒎̅̅̅̅̅̅̅̅〈𝐢𝐧𝐔𝐫𝐥 〉. 𝒑𝒓𝒐𝒄𝒆𝒔𝒔̅̅̅̅̅̅̅̅̅̅̅̅〈𝑷〉. 𝒕𝒐̅̅̅〈𝐨𝐮𝐭𝐔𝐫𝐢 〉
𝐴𝑔𝑒𝑛𝑡𝑂𝑟𝑐ℎ | (𝝂 𝒍)𝑹𝒐𝒖𝒕𝒆𝒔(𝒍)
𝐴𝑔𝑒𝑛𝑡𝑂𝑟𝑐ℎ | (𝜈 𝑙)(𝑅𝑜𝑢𝑡𝑒𝑠(𝑙)|𝑨𝒄𝒕𝒊𝒗𝒂𝒕𝒐𝒓(𝒍))
Définition
en π-DSL
Représentation par
structure de données
de type liste
Orchestration
active
81
La Figure 2-20 a pour but de replacer dans notre contexte de travail, l’ensemble des concepts vus
jusqu’à maintenant. Ainsi, elle offre une autre perspective du cycle de vie d’un agent d’orchestration.
Au départ le terme 𝐴𝑑𝑚𝑖𝑛 reçoit la définition d’orchestration. Suite aux échanges avec le terme
𝑅𝑜𝑢𝑡𝑒𝑠 une représentation de données chainée est créée. Suite aux interactions avec le terme
𝐴𝑐𝑡𝑖𝑣𝑎𝑡𝑜𝑟 un workflow est disponible à l’invocation. A chaque émission, le terme 𝑅𝑜𝑢𝑡𝑒 peut faire la
distinction entre une réception sur le canal 𝑓𝑟𝑜𝑚 pour l’ajout d’une route dans l’orchestration en cours
de transformation et les autres EIPs. Pour ce faire, le terme 𝑅𝑜𝑢𝑡𝑒𝑠 délègue le traitement de
l’intégration des EIP à l’orchestration au terme 𝑅𝑜𝑢𝑡𝑒. Il fait donc appel au terme Route après chaque
émission sur le canal EIP 𝑓𝑟𝑜𝑚.
Une fois l’orchestration disponible, elle peut être demandée pour invocation ou pour laisser place à
une nouvelle version. Ce dernier aspect n’a pas été pris en compte dans nos spécifications.
Le découpage tel que montré Figure 2.20 nous permet de garder conserver la gestion l’une structure
de données intermédiaire (au niveau PIM) qui peut éventuellement entre modifiée pour l’adapter au
vocabulaire cible.
Dans le document
Orchestration d'agents mobiles en communauté
(Page 79-82)