Implantation du Modèle

Introduction aux technologies utilisées

Cette section a pour objectif d’introduire les technologies utilisées dans le cadre de notre implantation. L’ISM est notre modèle d’exécution, c’est le lieu d’utilisation de ces technologies. Nous reprenons les couches applicatives illustrées dans la Figure 2-27 du chapitre 2 en justifiant les choix des technologies sur les couches importantes. Nous avons défini trois niveaux de PSM dans la section 4 du chapitre 2, ces niveaux de transformation nous permettent d’aboutir à un agent d’orchestration prêt à être utilisé dans un cluster de bus logiciels. Nous nous attardons dans cette section sur la structure et les composants de ce cluster. Nous décrivons ainsi l’implantation du système qui permet d’évaluer nos agents d’orchestrations. Ce système est composé du conteneur d’application, du moteur d’exécution et du référentiel décrit respectivement dans les sections 2.4.1.4, 2.4.1.5 et 2.4.1.3 du chapitre 2. 2.1 Choix du bus logiciel Les bus logiciels sont communément utilisés afin de mettre en place des architectures SOA (Service Oriented Architecture). Ce type d’architecture est basé sur l’identification des services faiblement couplés avec un middleware pour supporter l’intégration et l’orchestration de ces services. Un bus Implantation du Modèle 127 logiciel est considéré comme un important facilitateur pour SOA et à juste titre, considéré comme l’épine dorsale de l’architecture SOA. C’est une architecture qui exploite les Web services, la messagerie middleware, le routage intelligent et la transformation de flux [74]. 2.1.1 Caractéristiques du bus logiciel Les ESB sont définis de manières différentes selon leurs fournisseurs. Il existe cependant un dénominateur commun entre les différents ESBs qui est formulé comme un ensemble de caractéristiques qu’un ESB doit implanter :  fournir la transparence de localisation  fournir des normes fondées sur une plate-forme de messagerie pour l’intégration des services d’entreprise  assurer le couplage faible dans la communication des composants en faisant abstraction des protocoles et les formats de données  prendre en charge un routage intelligent par contenu des messages et les transformations de flux  être léger avec une architecture dynamique  fournir des outils simples d’administration  avoir la capacité d’être déployé dans un environnement distribué et pouvoir être à la base d’un cluster  supporter la recherche dynamique de services, au niveau des registres, et des versions de services.

Critère de comparaison

Un ESB offre des services sous la forme de fonctionnalités. Ces servicessont configurables à leurs tours et des services supplémentaires peuvent être facilement ajoutés. L’extensibilité d’un ESB permet également l’ajout de services externes pour inter-opérer avec l’ensemble existant de services. Ces services permettent l’intégration d’applications d’entreprise en autorisant la communication à travers des messages de médiation entre les composants. La connectivité entre l’application et l’ESB se doit d’être en cohérence avec l’approche basée sur les standards de l’architecture SOA et ne doit surtout pas en être propriétaire. Les services offerts par les ESBs peuvent être étendus pour assurer la sécurité, le support transactionnel et la robustesse de la plate-forme. En outre, ils peuvent inclure d’autres services spécifiques tels que le service Registre, des processus métier d’orchestration, etc. Nous ne fournissons pas une matrice comparative de tous les ESBs disponibles qui couvre les différents critères. Car nous considérons que ce n’est pas possible de créer une matrice correcte et constructive : les produits proposent souvent un trop grand nombre de fonctionnalités et concepts différents. De plus, la liste des fonctionnalités évolue d’une release à une autre d’un même ESB. Nous optons plutôt pour une approche qui permet de prédéfinir les besoins, puis d’évaluer les produits qui conviennent le mieux. Nous utilisons les critères suivants : 128  Facilité d’utilisation : ce critère concerne la complexité de l’installation, le nombre d’outils nécessaires à cette installation.  Maintenabilité : ce critère concerne l’administrabilité du produit, c’est-à-dire si la solution offre une interface pour le monitoring ?  Communauté : ce critère concerne lesforums publics actifs ou des listes de diffusion aussi bien que les articles, tutoriels, et vidéos qui permettent de cerner la solution  Efficacité : ce critère concerne la couverture de l’ESB par rapport aux fonctionnalités requises pour la mise en œuvre de notre système.  Flexibilité : ce critère concerne l’ouverture de l’ESB à des modifications profondes afin de personnaliser les fonctionnalités du produit pour répondre à nos besoins  Extensibilité : ce critère concerne la possible d’étendre le produit, c’est-à-dire si les interfaces proposées par le produit sont basées sur des standards.  Connecteurs : ce critère concerne les adaptateurs disponibles pour interfacer l’ESB avec des services développés avec d’autres technologies et d’autres protocoles. Nous présentons dans la Figure 4-1 les avantages et les inconvénients des ESBs sur deux niveaux. Ce choix de représentation est basé sur le fait que la plupart des ESB payants ont une version gratuite. Dans les colonnes, nous faisons la distinction entre des solutions propriétaires et des solutions open source. Nous distinguons par un code de couleurs (vert == bien, jaune == acceptable, rouge == mauvais) les critères au sein de la même famille d’ESB.