Activation d’une orchestration

L’activation d’une orchestration est l’étape qui consiste à transformer la structure de donnée

représentant une définition d’orchestration en une orchestration active. Dans la section 2.2 de ce

chapitre, nous avons identifié les termes qui concernent la construction, le reste des termes concerne

l’activation des orchestrations.

On considère que les orchestrations sont stockées dans un tableau de portée globale qui est structuré

comme montré dans la figure suivante :

step_t tab[ORCHESTRATION_MAX][STEP_MAX][INFO_MAX] = {

{

{FROM,URI1,LOCALHOST},

{AGREGATE,1,LOCALHOST},

{PROCESS,2,LOCALHOST},

{TO,URI2,HOST_2},

{TO,4,HOST_2},

{FROM,4,LOCALHOST},

{PROCESS,5,LOCALHOST},

{SPLIT,6,LOCALHOST},

{TO,URI3,HOST_2}

}

};

-Figure 3-14 Structure de données associée à une orchestration.

Cette structure est composée de trois dimensions :

 La première dimension représente le nombre maximum d’éléments ORCHESTRATION_MAX =

2 qui correspond au nombre d’orchestrations supportées par le système.

 La deuxième dimension décrit le nombre maximum d’éléments STEP_MAX = « step_t » qui

correspond au nombre maximum d’étapes dans une orchestration.

 _{La troisième dimension porte sur le nombre maximum d’éléments INFO_MAX = 3 qui}

correspond au nombre d’informations disponibles pour chaque étape. Le premier élément

correspond au type de l’étape. Le deuxième correspond à l’identifiant de l’étape. Le troisième

correspond à l’hôte sur lequel s’exécute l’étape.

Chaque élément dans cette structure est composé du type de l’EIP correspondant, d’une URI ou bien

un identifiant et de l’hôte sur lequel il écoute. Il est à noter que nous avons ajouté la possibilité d’utilisé

la constante « LOCALHOST » qui permet de spécifier que le choix de l’hôte est délégué à l’activateur.

Nous décrivons dans les sous sections suivantes les automates utilisés pour l’activation d’une

orchestration.

116

2.3.1 Déclaration du système d’activation

La déclaration du module d’activation consiste en une instanciation des automates intervenants dans

l’activation d’une orchestration. Nous avons deux types de déclarations :

 Toutes les possibilités d’EIPs et d’échanges sont instanciées. De cette manière, l’activateur

peut se servir dans les pools d’EIPs et d’échanges afin d’activer les instances nécessaires à

l’activation de l’orchestration.

 _{Les autres composantes du système sont instanciées de manière unitaire. Il est à noter que}

dans notre système, nous déclarons un « Client » qui se connecte à l’hôte identifié par « URI1 »

et un « Service » qui écoute sur « URI3 » de sachant que les deux « URI » sont différentes.

L’orchestration que nous utilisons et qui est définie comme structure de donnée dans la Figure 3-14

est activée par le système qui est illustré dans la Figure 3-15.

client = Client(URI1,HOST_1); service = Service(URI3,HOST_2); runtime = Runtime(); repo = Repository(); installer = Installer(); activator = RouteActivator(tab); agency = AgentHost(URI2,HOST_2,AGENT_ORCH); admin = Admin(AGENT_ORCH,HOST_1); system admin,installer,runtime,repo,activator,client,service, agency,Consumer,Provider, Exchange, EipProcesseur;

Figure 3-15 Structure de données associée à une orchestration.

Le système global est composé de douze automates dont les rôles sont :

 « client » : représente le client qui invoque l’orchestration sur l‘URL « URI1 » sur l’hôte

« HOST_1 » données en paramètres. C’est un automate élémentaire à deux états et deux

transitions.

 « service » : représente le service partenaire invoqué à l‘URL « URI2 » sur l’hôte « HOST_2 »

données en paramètres. C’est un automate élémentaire à deux états et deux transitions.

 « runtime » : permet d’installer une orchestration.

 « repo » : permet de garder la définition d’une orchestration et de la fournir au « runtime » au

moment de l’installation.

 « activator » : gère l’activation d’une route qui a été installé

 « installer » : gère l’installation d’une route dans le Repository

 « admin » : déclenche la demande d’ajout d’une orchestration qui sera installée grâce à

l’automate « installer »

 « agency » : gère l’installation de l’orchestration sur l’hôte distant. Cet automate est appelé

117

 « Consumer » : est le pool des Consumer (cf : équation (2-42))

 « Provider » : est le pool des Provider (cf : équation (2-41))

 « Exchange » : est le pool des échanges (cf : équation (2-43))

 « EIPProcesseur » : est le pool des EIPs (cf : équation (2-77))

2.3.2 Le modèle du référentiel

Le modèle du référentiel nommé « Repository » est construit à partir de sa définition décrite dans la

Section 2.4.1.3 du Chapitre 2. Son objectif est de stocker les définitions d’orchestrations. Il dispose

pour cela de deux canaux :

- « repoGet » permet de récupérer la définition d’une orchestration à partir de son identifiant

dans le référentiel.

- « repoPut » permet de charger la définition d’une orchestration dans le référentiel et de

récupérer l’identifiant de cette dernière dans le référentiel.

Le canal « http » est utilisé pour véhiculer l’identifiant de l’orchestration dans le cas de récupération

de définition. Il est aussi utilisé pour la récupération de l’identifiant dans le référentiel dans le cas de

partage de la définition d’orchestration.

Le tableau « replica » est utilisé pour stocker la définition des orchestrations. Ce même tableau est

utilisé pour récupérer cette définition et la retourner à l’automate qui la demande.

Figure 3-16 Modélisation du référentiel.

Le modèle « Repository » est composé de quatre états :

 Un premier état « Ready » qui représente l’état où le référentiel est prêt pour traiter une

requête.

 Un deuxième état « Setting » qui représente l’ajout d’une nouvelle définition d’orchestration.

118

 Un troisième état « Getting » qui représente la récupération d’une définition d’orchestration.

L’identifiant de l’orchestration à récupérer est passé via le canal « repoGet », la définition est

retournée via le canal « http ».

 _{Le quatrième état « EndOp » marque la fin du traitement d’une opération du référentiel.}

2.3.3 Le modèle de l’activateur

Le modèle Activateur « Activator » est construit à partir de sa définition décrite dans la section 2.4.1.8

du Chapitre 2. Son objectif est d’activer les orchestrations en se basant sur leurs définitions. Il prend

en paramètre le tableau de définition d’orchestration (cf : Figure 3-9). Pour chaque étape

d’orchestration, il active une instance de l’EIP correspondant à son type et il active aussi un échange

entre l’EIP courant et l’EIP suivant.

Figure 3-17 Modélisation de l’activation d’une orchestration.

Le modèle « Activator » est composé de six états :

 Un premier état « Idle » qui représente l’état où l’activateur est prêt pour activer une

orchestration.

 Un deuxième état « Ready » est atteint suite à une demande d’activation sur le canal

« activate ».

 Un troisième état « NextStep » est atteint pour chaque étape de l’orchestration mise à part la

dernière étape.

 Une quatrième étape « Activating » marque l’activation d’une étape. L’activation d’une étape

consiste à activer un échange et un EIP qui sont associés à cette étape.

119

 La sixième étape « ConnectingOut » marque l’activation de la dernière étape qui consiste en

l’activation de l’EIP correspondant à cette étape et la connexion de l’échange de sortie.

2.3.4 Les modèles d’EIP

Les modèles d’EIP deviennent actifs suite à la réception d’un message d’activation sur le canal

« activateEip ». Le message d’activation est destiné à un type particulier spécifié par le premier

paramètre. Les modèles d’EIP sont partagés sur deux familles :

- Les EIP représentant les « Message Endpoints » (cf : 2.2.1) sont représentés par les modèles

« Consumer » et « Provider » représentés dans la Figure 3-18. Ils ont comme particularité de

communiquer d’un côté avec des « Client » pour le « Consumer » et avec des « Service » ou

bien d’autres orchestrations pour les « Provider ». Les modèles « Consumer » et « Provider »

sont composés de cinq états :

o L’état « Idle » qui représente l’état l’inactivité.

o L’état « Ready » qui représente l’état suite à l’activation de l’EIP après une émission

sur le canal « activateEIP ». La distinction entre ces EIPs est effectuée grâce au premier

paramètre du canal « activateEIP » qui correspond au type d’EIP à activer.

o _{Les états « Consuming » et « Providing » représentent les états marquants la réception}

de requêtes à traitées. Pour le consumer, il s’agit d’une requête reçue sur une « URI »

et transmise par l’échange à l’EIP suivant. Pour le « Provider », il s’agit de récupérer la

requête sur l’entrée de l’échange et de la transmettre sur le canal « URI ».

o L’état « Processing » est atteint tant que la réponse à la requête n’a pas été reçue sur

le canal adéquat.

o _{L’état « Replaying » représente la transformation de la réponse reçue et sa transition}

120

Figure 3-18 Modèles des « Message Endpoint ».

- Tous les autres types d’EIP sont représentés par le modèle « EipProcesseur » représentés dans

la Figure 3-19. Le modèle « EipProcesseur » composé de quatre états :

o _{L’état « Idle » qui représente l’état l’inactivité.}

o _{L’état « Ready » qui représente l’état suite à l’activation de l’EIP après une émission}

sur le canal « activateEIP ».

o _{L’état « Tau » représente une action invisible effectuée par l’EIP. Il est atteint suite à}

une réception sur l’échange « in » et renvoie un résultat sur l’échange « out ».

o L’état « End » marque la fin du traitement d’une invocation d’EIP. Après cette étape,

l’automate revient vers l’état « Ready » afin de pouvoir traiter une nouvelle requête.

Figure 3-19 Structure de données associée à une orchestration.

Une fois actifs, les modèles d’EIP sont dans l’état « Ready » en attendant la réception d’un message en

entrée. Suite à ce message ils parcourent les différents états et revient pour se stabiliser dans l’état

« Ready »

2.3.5 Le modèle du moteur d’exécution

Le modèle moteur d’exécution « Runtime » est construit à partir de sa définition décrite dans la section

2.4.1.5 du Chapitre 2. Son objectif est de récupérer l’identifiant de l’orchestration à installer et de

lancer son activation sur l’hôte passé en entrée sur le canal « install ». Le moteur d’exécution permet

de lancer l’activation d’une orchestration soit sur l’hôte local identifié par la constante « LOCALHOST »

soit sur un hôte distant.

121

Figure 3-20 Modélisation du moteur d’exécution.

Le modèle « Runtime » est composé de cinq états :

 Un premier état « Ready » qui représente l’état où le moteur d’exécution est près pour

recevoir une demande d’installation d’orchestration.

 _{Un deuxième état « Installing » correspond à une demande d’installation d’une orchestration}

grâce à une communication sur le canal « install » où l’orchestration est identifiée par son

« bundleId » et doit être installée sur l’hôte identifié par « hostId ». les deux paramètres sont

passés sur le canal « install ».

 Un troisième état « Pulled » est atteint quand l’orchestration est récupérée depuis le

référentiel.

 _{Un quatrième état « Activated » marque la fin de l’activation d’une orchestration. Un status}

est renvoyé à l’invocateur et l’automate se réinitialise après cet état.

3 Vérification

Nous avons mis en valeur des propriétés liées aux orchestrations à partir des spécifications écrites au

chapitre 2 : application du Template de migration, construction et activation d’une orchestration. Ces

propriétés doivent être préservées dans l’implantation qui est faite au chapitre 4. Aussi, nous nous

intéressons à leur preuve par model-checking

3.1Démarche

Les propriétés qui nous intéressent sont des propriétés liées à la migration et aux communications

d’une orchestration. Nous avons séparé les propriétés en deux parties car nous avons deux familles

d’automates. Dans chaque partie, il y a des propriétés liées à la migration et la communication que

nous prouvons dans les sections suivantes.

Dans le document Orchestration d'agents mobiles en communauté (Page 116-122)