Définition de l'Object Management Group

Nous allons présenter, maintenant, la définition de la phase de déploiement proposée par l'Object

Management Group (OMG) via sa spécification Deployment and Configuration of Component-based Distributed Applications (D&C). Cette présentation se base sur la version 4.0 de la spécification, qui a été

publiée en avril 2006 et cible clairement les applications distribuées à base de composants [OMG06]. La spécification D&C voit la phase de déploiement comme un processus linéaire et séquentiel. Elle définit un ensemble de trois pré-conditions au processus de déploiement :

• La première pré-condition stipule que le fournisseur du logiciel doit packager le logiciel conformément à la spécification D&C. Ainsi, tout package doit contenir des métadonnées décrivant le logiciel et les binaires exécutables des différents éléments composant le logiciel. Plusieurs binaires exécutables peuvent être proposés pour un même élément. Le package doit, ensuite, être publié et mis à la disposition du déployeur via, par exemple, d'un CDROM, de l'URL d'un site FTP.

• La seconde pré-condition impose l'existence et la disponibilité d'un environnement cible. Cet environnement est une infrastructure composée de systèmes distribués (ordinateurs, réseaux, etc.) sur laquelle le logiciel est destiné à être exécuté.

• Enfin, la troisième et dernière pré-condition rend obligatoire la présence d'un dépôt (repository). Ce dépôt étant, au minimum, une zone dans laquelle le logiciel packagé est stocké avant le début du processus de déploiement.

Le processus de déploiement en lui-même débute lorsque le logiciel est acquis par un acteur qui, par cette action, devient le propriétaire du logiciel (software owner). Un logiciel ne peut être acquis qu'après avoir été développé, packagé, publié par un fournisseur de logiciel. Le logiciel est déployé par son propriétaire qui endosse, par la même, le rôle de déployeur.

La phase de déploiement est structurée en cinq étapes, à savoir, l'Installation, la Configuration, le Planning, la Preparation et le Launch. Ces cinq étapes sont enchainées les unes après les autres de manière linéaire et séquentielle.

La première étape est l'installation. Elle est définie comme la récupération, l'acquisition d'un package logiciel (software package) publié et son rapatriement dans un dépôt logiciel sous le contrôle du déployeur. Un dépôt peut se situer, ou non, sur la même machine ou sur le même système de fichier que celui dans lequel le logiciel va être déployé. C'est une zone qui permet au déployeur d'appliquer des politiques au logiciel, comme l'authentification ou la certification (du logiciel), avant de lancer toute étape concernant l'exécution du logiciel à proprement dit. Un dépôt ne doit pas nécessairement être persistant et ne doit pas, non plus, nécessairement stocker ou avoir une copie du logiciel ou des métadonnées du logiciel. L'OMG propose, aussi, sa propre définition de l'activité d'installation. Ainsi, l'installation n'est pas définie comme le déplacement d'un logiciel vers l'environnement d'exécution où il pourra ensuite être activé, mais simplement comme le déplacement du logiciel acquis vers le dépôt du déployeur.

La seconde étape du processus de déploiement est la configuration. Pour être configuré, un package logiciel doit être installé dans le dépôt du déployeur. Le déployeur est le seul à pouvoir effectivement le configurer. Les possibilités de configuration offertes dépendent de chaque package logiciel. Un package logiciel peut, par exemple, offrir des options de configuration concernant la langue à utiliser, le système de mesure, le délai d'attente entre chaque mesure ou encore la fréquence et le formatage des rapports de mesures générés. Plusieurs configurations peuvent être associées à un même package logiciel. Enfin, cette seconde étape ne concerne que la configuration des fonctions du package logiciel et n'est en aucun cas destinée à la prise de décisions concernant le déploiement comme, par exemple, le choix de l'implémentation à utiliser ou, le cas échéant, le choix de la distribution des différents éléments du package logiciel.

La troisième étape est la planification (Planning). Son but est de définir comment et où une configuration va être exécutée dans l'environnement cible. Pour rappel, la spécification définit un environnement comme étant une infrastructure composée d'ordinateurs et de réseaux. L'activité de planification prend en compte les requis de la configuration à déployer, ainsi que les ressources offertes par l'environnement cible et sélectionne les implémentations à utiliser. Elle décide également comment et où la configuration donnée sera exécutée dans l'environnement cible. Le résultat de l'étape de planification est un plan de déploiement spécifique (à la configuration en cours de déploiement, ainsi qu'à l'environnement cible). Le déploiement ainsi mis en œuvre est un déploiement sensible au contexte.

La planification met en avant deux modes, à savoir, la planification juste à temps (Just-in-time

planning) et la planification par avance (Advanced planning). Le premier mode consiste à calculer le plan

de déploiement d'une configuration donnée pour un environnement cible et à le faire exécuter immédiatement via l'étape de préparation. Nous verrons dans le paragraphe suivant que l'étape de préparation consiste à appliquer, exécuter, mettre en œuvre le plan de déploiement. Ce premier mode permet de ne pas faire d'hypothèses concernant l'évolution des ressources de l'environnement cible. En effet, les ressources d'un environnement peuvent évoluer au cours du temps et par conséquent invalider le plan de déploiement produit par la planification. Le second mode de planification est le mode par avance. Contrairement à l'approche précédente, ce second mode consiste certes toujours à produire un plan de déploiement pour une configuration donnée et un environnement cible, mais cette fois, le plan de déploiement produit n'est pas destiné à être mis en œuvre immédiatement (toujours via l'étape de préparation). Ainsi, la planification par avance permet, par exemple, d'éviter les interactions avec l'environnement cible si le système de déploiement en possède une image, un modèle. De plus, si une configuration est destinée à être déployée dans un ensemble d'environnements identiques, alors la planification par avance permet de ne calculer qu'un unique plan de déploiement qui pourra être appliqué à cet ensemble d'environnements cibles, permettant ainsi d'économiser le calcul d'étapes de planification. Cependant, ce second mode suppose que les ressources de l'environnement cible requises par le plan de déploiement du logiciel soient toujours disponibles lors de la mise en œuvre effective de ce dernier. La spécification ne précise rien quant à l'invalidation d'un plan déploiement (par exemple l'idée d'une date de péremption pourrait être introduite au niveau des plans de déploiement).

L'avant dernière étape est appelée préparation. Elle est définie comme la mise en œuvre effective des décisions prises lors de la planification. Ces décisions sont spécifiées dans le plan de déploiement. Le but de la préparation est de rendre le logiciel prêt à être exécuté. Cette mise en œuvre consiste, entre autre, à déplacer des binaires exécutables dans les ordinateurs qui leur ont été attribués. Comme pour la planification deux modes de préparation sont distingués. Le premier est le mode juste à temps, le second est le mode par avance. Le mode juste à temps implique que l'étape de préparation doit immédiatement être suivie par l'étape de lancement. Le mode par avance n'impose pas cette contrainte.

La cinquième et dernière étape est le lancement (Launch). Elle consiste à démarrer l'exécution du logiciel, en prenant, dans l'environnement, toutes les ressources requises par le ou les packages logiciels. Le lancement d'une application à base de composants implique l'instanciation des composants dans les ordinateurs de l'environnement cible, la configuration de ces instances de composants et la mise en place des interactions entre les différentes instances et enfin, le démarrage de l'exécution de l'application en elle-même. Dès que l'application s'exécute (c'est-à-dire une fois qu'elle est dans l'état activé) alors, soit l'application s'exécute tant que son exécution n'est pas complète, soit elle est arrêtée (c'est-à-dire désactivée) en utilisant la même infrastructure de déploiement que celle par laquelle son lancement a été effectué.

Les cinq étapes que nous venons de présenter peuvent tout à fait être déroulées une par une séparément, ou comme une seule grande étape de déploiement entièrement automatisée. La figure ci-dessous présente ces cinq étapes, ainsi que les liens entre ces étapes et le vecteur (c'est-à-dire l'unité de déploiement) utilisé par chaque lien.

Figure 25. La phase de déploiement définie par l'OMG.

2.4 Synthèse

L'OMG, via sa spécification D&C, définit le déploiement comme étant un processus constitué de cinq étapes. Ce processus commence une fois que le logiciel a été acquis et se termine par l'arrêt de l'exécution du logiciel (c'est-à-dire sa désactivation), tout en passant par le déplacement du logiciel dans un dépôt, le choix des implémentations à utiliser pour réaliser le logiciel, le choix de la distribution du logiciel, l'insertion des implémentations dans l'environnement et enfin, le lancement de l'exécution du logiciel (c'est-à-dire son activation). Les termes unité de déploiement, environnement cible, plan de déploiement ainsi que le rôle de déployeur sont aussi définis.

Cette définition comporte un élément surprenant. En effet, l'OMG donne une définition de l'installation très particulière. Cette définition n'a aucun rapport avec la définition habituellement retenue (comme, par exemple, dans les deux autres définitions du déploiement que nous présentons dans cette section). En effet, la définition consensuelle stipule qu'installer un logiciel consiste à le déplacer dans l'environnement cible, ainsi qu'à distribuer les artéfacts du logiciel de façon à rendre possible son exécution (c'est-à-dire permettre son activation). Pour l'OMG, l'installation consiste à acquérir un logiciel publié et à le rapatrier dans un dépôt logiciel sous le contrôle du déployeur.

L'OMG a aussi fusionné les rôles d'administrateur (dans le cadre du déploiement) et de déployeur sous son propre rôle de déployeur. Ainsi, pour l'OMG, c'est le déployeur qui acquiert le logiciel (il joue le rôle de Repository Administrator), qui précise la distribution des artéfacts du logiciel sur l'environnement cible (il joue alors le rôle de Planner) et qui décide de l'occurrence des étapes de déploiement (c'est alors l'Executor). Or, généralement, ces trois tâches incombent à l'administrateur, puisque c'est ce dernier qui est en charge de la gestion des licences des logiciels, de la gestion de l'environnement et puisqu'il commande les activités de déploiement qui doivent être mises en œuvre. De son côté, le déployeur est en charge de l'exécution des activités de déploiement commandées.

Ensuite, il apparaît clairement que l'exécution du logiciel est l'unique but du déploiement pour l'OMG. Typiquement, l'activité de maintenance, pouvant mettre en jeu, par exemple, des mises à jour statiques ou dynamiques, l'évolution ou le dynamisme n'est pas mentionnée. Et de manière plus surprenante encore, bien qu'elle considère l'étape de préparation, l'OMG ne considère pas la désinstallation (du logiciel).

D'une manière générale, la définition du déploiement proposée par l'OMG à une portée plus grande que celle de C. Szyperski, cela dit, la définition de l'OMG reste tout de même moins complète que celle de l'université du Colorado que nous allons présenter ci-après. Enfin, à l'image de la définition de C. Szyperski qui prend tout son sens dans le cadre de l'utilisation d'un logiciel de déploiement prenant en entrée une configuration définie par le déployeur, ici, la définition de l'OMG prend son sens dans le cadre d'une infrastructure qui doit pouvoir être remise à zéro, afin d'assurer la désinstallation du ou des logiciels déployés (comme dans une grille, par exemple).