FR3002340A1 - Middleware a deploiement modulaire - Google Patents

Abstract

Procédé de génération de modules d'exécution d'application comportant les étapes suivantes : - de détermination d'au moins une première ressource informatique disponible pour un premier composant informatique auprès d'un deuxième composant informatique, lesdits premier et deuxième composants informatiques faisant partie d'un module d'exécution d'application initial, - de génération d'une interface permettant l'identification et l'accès de ladite au moins une première ressource par ledit premier composant informatique, - d'encapsulation dudit deuxième composant informatique et de ladite interface générée dans un troisième composant informatique, - de génération d'un noyau avec au moins un analyseur de composant configuré pour lier au moins deux composants entre eux, à partir d'interfaces respectives permettant l'identification et l'accès à des ressources informatiques dont lesdits composants ont besoin l'un auprès de l'autre, et - de génération d'un module d'exécution d'application comportant ledit troisième composant informatique et ledit noyau.

Description

La présente invention concerne l'exécution et l'intégration d'applications informatiques. Un « middleware » (module (ou ensemble de module(s)) logiciel(s) intermédiaire(s)) est un logiciel comportant des composants logiciels (« composants » dans la suite) qui offrent des services (ou fonctions) accessibles par des applications informatiques via une ou plusieurs interfaces. Un serveur d'application (par exemple un serveur d'application d'entreprise ou autre) comportant un tel middleware est schématiquement représenté sur la figure la. Le middleware 100 fournit un ensemble de services à des applications 101 «Al », 102 «A2 ». Ces services sont par exemple des services web, des interfaces de programmation (JMS par exemple, sigle de « Java Messaging Service », qui est une interface de programmation de service de communications), ou autre. Les applications sont par exemple des navigateurs web, des applications bancaires, des applications de facturation ou autre. Le middleware est par exemple lancé à partir d'une machine virtuelle 103 « JVM » (telle qu'une machine virtuelle Java). La machine virtuelle fonctionnant elle-même à partir d'un serveur matériel 104 « SERVEUR ». La figure lb illustre plus en détails la structure du middleware 100. Celui-ci comporte deux (ou un tout autre nombre) composants 105 « 25 Cl » et 106 « C2 ». Les composants sont par exemple des conteneurs de senflets (Tomcat par exemple ou autre), des composants de communication entre applications via l'utilisation de files d'attente (« message queue » en anglais ou « MQ »), des composants de service http, des composants de 30 journalisation, de gestion des configurations, des préférences, d'analyse syntaxique XML, d'accès aux dispositifs, d'administration de paquetage, d'administration des permissions, de gestion des connexions, de pistage applicatif, de gestion de l'énergie, de sécurité, ou d'autres types de composants. Chaque composant fournit des services accessibles aux applications utilisant le middleware via des interfaces. Ainsi, dans l'exemple de la figure 1 a, le composant Cl fournit deux services 107 « Sll » et 108 « S12 » accessibles via une interface 109 « 11 ». Le service Sll est par exemple utilisé par l'application Al. Toujours selon l'exemple de la figure 1 b, le composant C2 fournit trois services 110 « S21 », 111 « S22 » et 112 « S23 » accessibles via une interface 113 « 12 ». Le service « S23 » est par exemple utilisé par l'application «A2 ».

Lors de son fonctionnement, selon les services utilisés par les applications, le middleware fait appel à un ou plusieurs composants. Un composant sollicité pour la fourniture d'un service donné à une application peut faire intervenir un autre composant. Le composant peut fournir des services par l'utilisation de ressources informatiques qu'il gère.

Ainsi, comme représenté par la double flèche 114 les composants Cl et C2 peuvent utiliser chacun des ressources informatiques disponibles auprès de l'autre composant. Cette utilisation peut se faire via des interfaces de service. Deux approches sont possibles, les fonctions du service peuvent être exprimées sous forme de « verbes » (approche orienté service, SOA sigle de « Service Oriented Architecture »), elles peuvent aussi être exprimées sous forme de « noms » (la ressource est directement exposée, cette approche est dite ROA - sigle de « Ressource Oriented Architecture »). Les composants peuvent utiliser les services fournis par d'autres composants et donc indirectement les ressources des autres composants. Lors de la génération (ou de l'installation) d'un middleware, celui-ci est fourni avec des composants ayant différentes versions respectives. Au cours du temps, des modifications peuvent être rendues nécessaires dans l'un ou plusieurs des composants appartenant au middleware. En particulier, les évolutions des applications entraînent des évolutions dans les services fournis par le middleware, ce qui nécessite fréquemment des changements (et donc des évolutions) de version de ces composants. En outre, à l'usage, des corrections peuvent s'avérer nécessaires pour le bon fonctionnement du middleware. De telles corrections impliquent de nouvelles versions des composants. Un middleware tel qu'illustré par la figure lb a une structure monolithique. Ainsi, lorsqu'un composant du middleware est modifié (et qu'il change donc de version), l'ensemble du middleware doit être géré et déployé de nouveau. Ainsi, une modification d'un seul composant nécessite la modification globale du middleware. La structure monolithique des middlewares est problématique du fait que la modification du middleware implique une suspension de la fourniture de la totalité des services accessibles par les applications. Ainsi, dans l'exemple de la figure 1 b, dans l'éventualité où le composant Cl devait être mis à jour, non seulement le service S1 1 fourni à l'application Al serait suspendu mais le service S23 fourni à l'application A2 serait également suspendu alors même que le service S23 peut ne pas nécessiter la mise en oeuvre du composant Cl.

Ainsi, la structure monolithique des middlewares pose des difficultés dans le déploiement à très grande échelle des serveurs d'applications. En effet, lorsqu'un très grand nombre d'applications utilise les services d'un même middleware, il n'est pas possible de mettre l'intégralité du middleware à jour trop fréquemment sans compromettre la stabilité de l'accès par les applications aux services fournis. Cette impossibilité va pourtant à l'encontre du besoin d'évolution croissant des composants pour les adapter aux services requis par les applications. Il existe donc un besoin pour permettre la mise à jour des composants des middlewares sans compromettre l'accessibilité par les applications utilisant le middleware aux services fournis par celui-ci. La présente invention s'inscrit dans ce cadre. Un premier aspect de l'invention concerne un procédé de génération de module d'exécution d'application comportant les étapes suivantes : - de détermination d'au moins une première ressource informatique disponible pour un premier composant informatique auprès d'un deuxième composant informatique, lesdits premier et deuxième composants informatiques faisant partie d'un module d'exécution d'application initial, - de génération d'une interface permettant l'identification et l'accès de ladite au moins une première ressource par ledit premier composant informatique, - d'encapsulation dudit deuxième composant informatique et de ladite interface générée dans un troisième composant informatique, - de génération d'un noyau avec au moins un analyseur de composant configuré pour lier au moins deux composants entre eux, à partir d'interfaces respectives permettant l'identification et l'accès à des ressources informatiques dont lesdits composants ont besoin l'un auprès de l'autre, et - de génération d'un module d'exécution d'application comportant ledit troisième composant informatique et ledit noyau. Un procédé selon le premier aspect permet de fournir, à partir d'un module d'exécution d'application (ou module intermédiaire, module médiateur ou middleware) monolithique, un module d'exécution d'application à déploiement modulaire permettant des mises à jour des composants sans nécessiter la remise en cause du module d'exécution d'application dans sa globalité.

Un module d'exécution d'application obtenu selon le premier aspect peut en outre être complété par de nouveaux composants ou être modifié pour en supprimer. Le procédé peut en outre comporter une étape de lancement dudit module d'exécution d'application généré.

Ainsi, il est possible d'offrir un lancement à la demande de modules d'exécution d'application comportant des composants souhaités. Ledit module d'exécution d'application généré peut être lancé à partir d'une première machine virtuelle fonctionnant sur un serveur matériel sur lequel est lancée une deuxième machine virtuelle supportant ledit module d'exécution d'application initial. Ainsi, le module d'exécution d'application généré peut fonctionner en recouvrement du premier. Il est alors possible d'offrir un nouveau module d'exécution d'application modulable sans toucher aux modules d'exécution d'application initiaux. Le procédé peut en outre comporter les étapes : - de détermination d'au moins une deuxième ressource informatique disponible pour ledit deuxième composant informatique auprès dudit premier composant informatique, - de génération d'une interface permettant l'identification et l'accès de ladite au moins une deuxième ressource par ledit deuxième composant informatique, - d'encapsulation dudit premier composant et de ladite interface crée dans un quatrième composant informatique. Ledit module d'exécution d'application comporte alors ledit quatrième composant informatique. Par exemple, pour chaque composant informatique du module d'exécution initial, un composant informatique est généré par encapsulation dudit chaque composant informatique du module d'exécution initial et d'une interface permettant l'identification et l'accès à au moins une ressource informatique disponible auprès dudit chaque composant informatique du module d'exécution initial pour les autres composants informatiques du module d'exécution initial. Ainsi, tous les composants informatiques du module d'exécution d'application initial peuvent être repris dans le module d'exécution d'application généré, tout en offrant une modularité qui n'existait pas dans le module d'exécution d'application initial.

Le procédé peut en outre comporter l'intégration au sein dudit module d'exécution d'application d'au moins un composant informatique externe comportant une interface permettant l'identification et l'accès à au moins une ressource informatique disponible auprès dudit composant informatique externe pour d'autres composants informatiques, ledit composant informatique externe ne faisant pas partie dudit module d'exécution initial.

Il est alors possible de compléter le module d'exécution d'application généré avec des composants non présents dans le module d'exécution d'application initial. Le module d'exécution d'application généré peut comporter au moins 5 deux composants informatiques issus de l'encapsulation d'un au moins deux composants informatiques faisant partie de deux modules d'exécution d'application initiaux respectifs distincts. Ainsi, le module d'exécution d'application généré peut être bâti à partir de plusieurs modules d'exécution d'application initiaux. 10 Ledit troisième composant peut être configuré pour la fourniture d'un seul service dudit module d'exécution d'application initial. Ainsi, les composants du module d'exécution d'application généré peuvent être mis à jour en fonction du service nécessitant la mise à jour. Les autres services ne nécessitant pas la mise à jour peuvent alors continuer à 15 fonctionner avec le composant non mis à jour. Par exemple, des troisièmes composants informatiques sont créés pour chaque service dudit module d'exécution d'application initial. Ainsi, le ou les modules d'exécution d'application initiaux sont complètement modularisés, service par service. 20 Un deuxième aspect de l'invention concerne un procédé de lancement de module d'exécution d'application à la demande comportant les étapes suivantes : - de réception d'une requête de lancement de module d'exécution d'application comportant un composant informatique identifié, 25 - génération d'un module d'exécution d'application selon le premier aspect, ledit module d'exécution d'application comportant ledit composant informatique identifié, et - lancement dudit module d'exécution d'application généré. Par exemple, ledit composant informatique est identifié dans une 30 bibliothèque de composants informatiques d'au moins un module d'exécution d'application initial utilisé pour la génération d'un module d'exécution d'application selon le premier aspect.

Par exemple encore, ladite bibliothèque de composants comporte en outre au moins un composant informatique externe ne faisant pas partie dudit au moins module d'exécution initial. Un troisième aspect de l'invention concerne un programme d'ordinateur ainsi qu'un produit programme d'ordinateur et un support de stockage pour de tels programmes et produits, permettant la mise en oeuvre d'un procédé selon le premier aspect de l'invention, lorsque le programme est stocké dans une mémoire d'un système de génération et/ou de lancement de module d'exécution d'application et exécuté par au moins un processeur d'un tel système. Un quatrième aspect de l'invention concerne un système, par exemple un serveur (tel qu'un serveur d'application), configuré pour la mise en oeuvre d'un procédé selon le premier et/ou le deuxième aspect. Par exemple, le serveur comporte une unité de traitement configurée pour : - la détermination d'au moins une première ressource informatique disponible pour un premier composant informatique auprès d'un deuxième composant informatique, lesdits premier et deuxième composants informatiques faisant partie d'un module d'exécution d'application initial, - la génération d'une interface permettant l'identification et l'accès de 20 ladite au moins une première ressource par ledit premier composant informatique, - l'encapsulation dudit deuxième composant informatique et de ladite interface générée dans un troisième composant informatique, - la génération d'un noyau avec au moins un analyseur de composant 25 configuré pour lier au moins deux composants entre eux, à partir d'interfaces respectives permettant l'identification et l'accès à des ressources informatiques dont lesdits composants ont besoin l'un auprès de l'autre, et - la génération d'un module d'exécution d'application comportant ledit troisième composant informatique et ledit noyau. 30 Le système peut en outre comporter une unité de communication pour recevoir une requête de lancement de module d'exécution d'application comportant un composant informatique identifié. L'unité de traitement peut en outre être configurée pour la génération d'un module d'exécution d'application selon le premier aspect, ledit module d'exécution d'application comportant ledit composant informatique identifié, et le lancement dudit module d'exécution d'application généré.

Les objets selon les deuxième, troisième et quatrième aspects de l'invention offrent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la présente description détaillée qui suit, à titre d'exemple non limitatif, et des figures annexées parmi lesquelles, en outre les figures la et lb: - les figures 2a et 2b illustrent un module d'exécution d'application à déploiement modulaire ; - les figures 3a à 3i illustrent l'obtention d'un module d'exécution d'application à déploiement modulaire ; - la figure 4 illustre une réalisation d'un module d'exécution d'application à déploiement modulaire ; - les figures 5 à 7 représentent des organigrammes d'étapes mises en oeuvre pour la génération et/ou le lancement d'un module d'exécution d'application à déploiement modulaire ; et - la figure 8 illustre schématiquement un dispositif et/ou un système selon des modes de réalisation. Dans ce qui suit, il est décrit un processus permettant d'obtenir un module d'exécution d'application (« middleware » dans la suite) à déploiement modulaire. Un tel middleware peut être obtenu à partir d'un middleware à déploiement monolithique initial. Comme schématiquement illustré par la figure 2a, un middleware à déploiement modulaire 200 « M1' » selon des modes de réalisation peut être lancé à partir d'un conteneur d'hébergement comme par exemple une machine virtuelle 201 fonctionnant à partir d'un serveur matériel 203. Par exemple, la machine virtuelle est de type Java. Le middleware M1' fournit des services à des applications 204 « Al' » et 205 « A2' » (ou un tout autre nombre). La figure 2b illustre plus en détails la structure du middleware M1'.

L'application Al' utilise un service 206 « S11' » via une interface 207 « 11'». Le service S11' est fourni par un composant 208 « C1' ». L'application Al' utilise un service 209 « S23'» via une interface 210 « I2'». Le service S23' est fourni par un composant 211 « C2'».

Chacun des composants C1' et C2' peut utiliser des ressources informatiques de l'autre composant comme illustré par la double flèche 212. Les ressources de chaque composant lui permettent d'offrir des services à des applications ou à d'autres composants. Néanmoins, les composants peuvent faire appel aux services fournis par d'autres composants.

Contrairement au middleware M1 illustré en référence à la figure 1 b, le couplage entre les composants C1' et C2' est conçu en sorte qu'une modification du composants C1' ne nécessite pas une modification du composants C2' et inversement. Le couplage entre les composants n'est pas fort comme dans le middleware décrit en référence à la figure 1 b. En effet, le middleware M1' comporte un noyau 213 capable de gérer des interfaces propres à chaque composant afin de rendre possible les interactions entre eux. Les interfaces propres à chaque composant permettent d'identifier et d'accéder aux ressources informatiques disponibles auprès de chaque composant. En outre, chaque composant du middleware M1' peut n'offrir qu'un seul service en sorte que chaque composant peut être mis à jour en fonction d'un service fourni. Par exemple, le middleware M1' est obtenu à partir du middleware M1 décrit en référence à la figure 1 b. Ainsi, les applications Al' et A2' peuvent respectivement correspondre aux applications Al et A2. Les services S11' et S23' peuvent correspondre aux services Sll et S23. Les interfaces 11' et 12' peuvent correspondre aux interfaces 11 et 12. Les composants C1' et C2' peuvent être obtenus à partir des composants Cl et C2. Le middleware M1' peut comporter d'autres composants. Par exemple, il peut comporter des composants correspondant aux autres services 30 du middleware M1 ou des composants externes non présents dans le middleware Ml. 3002 3 40 10 Dans la suite de la description, en référence aux figures 3a à 3e, le processus d'obtention d'un middleware tel que décrit ci-dessus est présenté plus en détails. Il est par exemple supposé que les composants Cl' et C2' du middleware Mtsont obtenus à partir des composants Cl et C2 du middleware 5 M1 qui est alors considéré comme le middleware initial. D'autres modes d'obtention du middleware M1' sont possibles, par exemple à partir d'une pluralité de middlewares initiaux. La figure 3a illustre une phase d'identification, au sein des composants du middleware Ml, des ressources informatiques disponibles 10 auprès de chacun, pour les autres composants. Le composant Cl comporte par exemple un ensemble de ressources informatiques 300 (R11, RiN). Ces ressources informatiques sont utilisées pour la fourniture de services à des applications. Les ressources informatiques peuvent être utilisées par d'autres composants. Dans un souci de concision, un exemple schématique est 15 considéré selon lequel une ressource 301 « R11 » du composant Cl est utilisée par le composant C2. Toujours dans un souci de concision, on considère une seule ressource 301 « R21 », parmi un ensemble de composants 303 (R21, --- R2p) du composant C2 utilisée par le composant Cl. Une fois les ressources utilisées par les composants identifiées, des 20 interfaces sont générées. La figure 3b illustre cette phase de génération des interfaces. L'interface 304 « 112 » est générée en sorte d'identifier pour le composant Cl, la ressource informatique du composant C2 disponible pour lui, c'est-à-dire dans le présent exemple, la ressource R21. L'interface 305 « 121 » 25 est générée de sorte à identifier pour le composant C2 la ressource informatique du composant Cl disponible pour lui, c'est-à-dire dans le présent exemple, la ressource R11. En outre, les interfaces générées permettent à chaque composant l'accès à la ressource identifiée. Les interfaces comportent par exemple des métadonnées décrivant les ressources.

Dans un souci de concision, les interfaces décrites font le lien entre une seule ressource et un seul composant. Cependant, il est possible qu'une même ressource soit disponible pour plusieurs composants. L'interface peut alors être adaptée pour tenir compte de ce fait. Il est aussi possible de générer plusieurs interfaces pour chaque ressource et pour chaque composant susceptible d'utiliser cette ressource. Une fois les interfaces générées, une phase de création des 5 composants du middleware M1' est mise en oeuvre. Ces composants sont par exemple créés par encapsulation des composants du middleware M1 et des interfaces générées pour ces composants. La figure 3c illustre l'encapsulation du composant Cl et de l'interface 112 dans le composant Cl'. La figure 3d illustre quant à elle l'encapsulation du composant C2 et de l'interface 121 dans le 10 composant C2'. L'encapsulation se fait par exemple dans des paquetages (« bundles ») OSGi (sigle de « Open Services Gateway initiative »). Le noyau 213 Le noyau peut alors contenir un kit de composants logiciels structurels (« framework » ou « canevas ») d'exécution OSGi permettant de charger les bundles. 15 Une fois les composants du middleware M1' créés, ils sont intégrés à celui-ci dans une nouvelle phase. Comme illustré par la figure 3e, le middleware M1' 200 est généré et les modules Cl', C2' y sont installés. D'autres composants peuvent être intégrés au middleware 200. Il s'agit par exemple d'un module extérieur 306 « CExT », n'appartenant pas au middleware 20 initial 100. Ce module extérieur comporte néanmoins, comme les composants Cl' et C2' une interface identifiant et permettant l'accès à des ressources de ce composant par les autres composants intégrées au middleware. En effet, le noyau 213 du middleware M1' comporte au moins un module d'analyse (analyseur ou scanneur) 307 permettant d'identifier les 25 composants et de faire les liens adéquats entre les composants en fonction des ressources dont chacun a besoin auprès des autres. Grâce à leur interface, les composants peuvent se déclarer au noyau et le scanneur peut, à partir des interfaces encapsulées dans les composants, faire les liens. Chaque module d'analyse est capable de reconnaître un ou 30 plusieurs types de composant (par exemple, un module d'analyse peut reconnaître le type « .war », et/ou le type « .xml », et/ou le type « .txt », et/ou autre).

La figure 3f illustre un exemple de réalisation de noyau 308. Par exemple, lorsqu'un module d'analyse 309 reconnaît un type de composant, il marque le composant en question avec un marqueur identifiant ce type. Dans le cas où un module d'analyse est prévu pour chaque type de composant, les modules peuvent scanner les composants en parallèle et apposer chacun leurs marqueurs respectifs sur les composants. Les modules d'analyse peuvent être lancés simultanément ou au fur et à mesure. Par exemple, la détection d'un type de composant par un module d'analyse peut déclencher le lancement d'un autre module d'analyse.

Une fois qu'un ou plusieurs composants ont été marqué(s), un module de déploiement 310, associé au type de marqueur apposé peut être mis en oeuvre. Par exemple, à chaque module d'analyse est associé un module de déploiement. Si le module d'analyse est relatif à un type de composant, le module de déploiement est alors également relatif à ce type de composant. Le module de déploiement est capable d'explorer le conteneur (fichier, répertoire, ou autre) marqué par le module d'analyse de et déterminer le composant qui s'y trouve effectivement. Le module de déploiement peut alors permettre de prendre les mesure utiles au lancement du composant comme par exemple la gestion des conflits entre composants, la préparation de l'installation du composant dans le middleware, son installation, ou autre. D'une manière générale, le noyau permet la gestion de la modularité du middleware. Il peut comporter un ou plusieurs sous-modules comme représenté sur la figure 3f. Un premier module 311, SMO (pour « Système de Modularité Homogène ») peut par exemple gérer les composants dit « homogènes » (il s'agit par exemple des paquetages ou « bundles »). Un deuxième module 312, SMH (pour « Système de Modularité Hétérogène ») peut gérer les composants dits « hétérogènes » se présentant sous la forme d'éléments de types différents. Le noyau peut être entièrement compris dans le middleware M1', 30 comme représenté dans la figure 3e. Cependant, d'autres mises en oeuvre sont possibles, par exemple, il est possible que le module SMO 311, chargé de la gestion des modules homogènes, utilisé par le noyau du middleware M1' 200 soit celui du module initial M1 100. Comme représenté par la figure 3g, le middleware initial M1 partage le module SMO avec le noyau 308 du middleware M1'. Ainsi le module SMO fait à la fois partie du middleware M1 et du middleware M1'. Le module SMH 312 fait quant à lui partie du middleware M1' seulement. Une fois les composants intégrés au middleware M1', celui-ci est prêt à être lancé. Il peut offrir les mêmes services que ceux du middleware initial, voire des services supplémentaires pour le cas où des composants extérieurs ont été intégrés.

Cependant, à la différence du middleware initial, le middleware obtenu selon le processus décrit ci-avant bénéficie d'un couplage entre les composants qui n'est pas aussi fort que dans le middleware initial (le couplage peut être dit « lâche »). Grâce aux interfaces encapsulées avec les composants, ceux-ci peuvent être alors mis à jour indépendamment les uns des autres. Le middleware M1' peut être mis en oeuvre de différentes manières. Par exemple, dans une mise en oeuvre, le middleware M1' fonctionne en recouvrement au-dessus d'un ou plusieurs middlewares initiaux. Le middleware M1' peut alors être considéré comme un système de virtualisation des middlewares initiaux. Cependant, la modularité offerte par le middleware M1' permet d'obtenir une modularité de l'accès aux fonctions à l'exécution et en plus, une modularité du déploiement du middleware. Il est alors possible d'accéder à un ensemble de services fournis par le middleware M1' alors que le ou les middlewares sous-jacents réalisent les fonctions de manière monolithique. Dans ce cas, les serveurs 104 et 203 des figures la et 2a sont un même serveur et les machines virtuelles 103, 201 sont lancées parallèlement sur ce serveur. La modularité offerte par le middleware M1' permet d'accéder à un service fourni par un composant de M1' dans une version donnée alors que le 30 composant correspondant dans le middleware initial sous-jacent est dans une autre version.

Elle permet aussi d'avoir accès à deux versions différentes d'un même service, offert par deux composants du middleware M1' alors que le middleware initial n'offrait qu'une seule version du service offert par un unique composant correspondant aux deux composants du middleware M1'. Cela est par exemple utile pour accéder à un même service à partir d'un composant en code propriétaire et/ou en code libre (« open source »). La modularité permet également d'accéder à des services composés à partir de services initiaux au sein d'un même middleware ou au sein de plusieurs middlewares initiaux.

Lorsque le middleware M1' fonctionne en recouvrement, comme illustré par la figure 3h du point de vue des applications 313, seul le middleware M1' est disponible. Bien que des composants du middleware initial M1 puissent être utilisés, le middleware M1 n'apparaît pas aux applications. Le middleware M1' recouvre donc le middleware Ml, même si les deux middlewares peuvent en fait fonctionner en parallèle sur la même machine virtuelle. Dans tous ces cas, en partant du ou des middlewares initiaux, seul le composant utile à la mise en oeuvre du service est à livrer et pas l'intégralité du m iddleware.

Par exemple encore, dans une autre mise en oeuvre, le middleware initial lui-même est déjà pourvu d'un noyau comportant un scanneur comme décrit ci-avant et capable de lier entre eux des composants avec interface intégrée. Dans cette mise en oeuvre, le middleware initial diffère de celui décrit en référence à la figure la en ce qu'il comporte un noyau tel que décrit ci-avant.

Ainsi, il est possible de créer dans le middleware initial lui-même des nouveaux composants « à la carte » pouvant être mis à jour dynamiquement sans arrêter le middleware dans sa globalité. Ce mode de fonctionnement dit « direct» est représenté sur la figure 3i. Cette fois, les applications ont accès au middleware M1' directement car c'est le seul à fonctionner sur la machine virtuelle. Il n'y a pas de recouvrement comme dans le cas de la figure 3h. D'autres mises en oeuvre du middleware M1' sont possibles.

Avec un middleware à déploiement modulaire tel que décrit ci-dessus, la mise à jour de composant est rendu plus simple puisqu'elle ne nécessite pas la remise à niveau complète du middleware. Une mise à jour de composant peut ainsi s'effectuer simplement de la manière suivante : - identification du composant à mettre à jour, - arrêt dudit composant (ou « débranchement » de celui-ci), l'application qui utilise son ou ses services est alors éventuellement mise en pause, - intégration du composant mis à jour (ce composant comporte une interface comme décrite ci-avant), et redémarrage éventuel de l'application, - un test du nouveau composant peut aussi être mise en oeuvre. La figure 4 illustre une réalisation d'un middleware à déploiement modulaire 400 (M1').

Un premier middleware initial 401 (M1) est un serveur d'application dans une première version. Par exemple, il s'agit d'un serveur d'application JBoss dans la version 7.0.2. Un deuxième middleware initial 402 (M2) est aussi un serveur d'application dans une deuxième version. Par exemple, il s'agit d'un serveur d'application JBoss dans la version 7.1.0.

Le middleware M1 comporte : - un composant 403 offrant par exemple un service web 404. Le composant 403 est par exemple un conteneur de servlet Tomcat dans une version 7.0.11. - un composant 405 de communication entre applications via l'utilisation de files d'attente (« message queue » en anglais ou « MQ ») offrant un service d'interface de programmation (JMS par exemple, sigle de « Java Messaging Service ») 406. - un ensemble de composants 407, par exemple de type OSGi, offrant un ensemble de services 408 tels que des services http, de 30 journalisation, de gestion des configurations, des préférences, d'analyse syntaxique XML, d'accès aux dispositifs, d'administration de paquetage, d'administration des permissions, de gestion des connexions, de pistage applicatif, de gestion de l'énergie, de sécurité, ou autre. Le middleware M1 comporte : - un composant 409 offrant par exemple un service web 410. Le 5 composant 409 est par exemple un conteneur de servlet Tomcat dans une version 7.0.15. - un composant 411 de communication entre applications via l'utilisation de files d'attente (« message queue » en anglais ou « MQ ») offrant un service d'interface de programmation (JMS par exemple, sigle de « Java 10 Messaging Service ») 412. - un ensemble de composants 413, par exemple de type OSGi, offrant un ensemble de services 414 tels que des services http, de journalisation, de gestion des configurations, des préférences, d'analyse syntaxique XML, d'accès aux dispositifs, d'administration de paquetage, 15 d'administration des permissions, de gestion des connexions, de pistage applicatif, de gestion de l'énergie, de sécurité, ou autre. Le noyau 415 du middleware M1' peut par exemple utiliser des services offerts par des composants des middlewares M1 et M2. Dans cet exemple, le noyau utilise les services JMS 406 et OSGi 414 des composants 20 405 et 413 des middlewares M1 et M2. Le module M1' comporte quant à lui : - un composant 416 offrant par exemple un service web 417. Le composant 416 est par exemple un conteneur de servlet Tomcat dans une version 7.0.33. Cette version est présente dans le middleware M1' alors qu'elle 25 ne l'est ni dans le middleware M1 ni dans le middleware M2 grâce aux mécanismes décrits ci-avant. - un composant 418 de communication entre applications offrant un service d'interface de programmation (JMS par exemple, sigle de « Java Messaging Service ») 419. Ce composant est par exemple une implantation 30 JORAM. Ce composant est présent dans le middleware M1' alors qu'il ne l'est ni dans le middleware M1 ni dans le middleware M2 grâce aux mécanismes décrits ci-avant. Ce composant a pu être intégré en tant que composant externe. Le middleware M1' déployé dynamiquement permet de répondre à des besoins spécifiques d'une application 420 utilisant les services 417 et 419 5 sans remettre en cause les middlewares M1 et M2. Les exemples donnés ci-dessus sont purement illustratifs et l'invention peut être mise en oeuvre avec d'autres types de composants, d'autres kits de composants (« frameworks » ou « canevas ») que OSGi, d'autres langages que Java. 10 La figure 5 est un organigramme d'étapes pouvant être mises en oeuvre pour la génération (et/ou le lancement) d'un module d'exécution d'application (middleware) selon des modes de réalisation. Lors d'une étape 500, il est procédé à la sélection d'un composant d'un (ou de plusieurs) middleware(s) initial (initiaux). Une interface (telle que 15 décrite en référence à la figure 3b) est ensuite générée pour ce composant sélectionné. L'interface et le composant sont ensuite encapsulés dans un nouveau composant à intégrer dans le middleware à générer. Il est alors vérifié lors d'une étape 503, s'il reste d'autres composants à traiter dans le middleware initial. Cette vérification peut se faire en fonction 20 d'une liste de composants à intégrer listant tout ou partie des composants du middleware initial, en fonction des besoins des applications. S'il reste des composants à traiter (OUI), le processus retourne à l'étape 500 pour traiter un autre composant. Dans le cas contraire (NON) on passe à l'étape 504 de génération du 25 noyau (tel que décrit en référence à la figure 2b ou 3e). Le middleware est ensuite généré lors de l'étape 505 en y intégrant les composants générés lors des itérations de l'étape 502. Une étape 506 peut être mise en oeuvre visant à vérifier si des composants externes doivent être intégrés au middleware. Si ce n'est pas le 30 cas (NON), le middleware peut être lancé lors d'une étape 507. Si au contraire (OUI), un composant externe doit être intégré, cela est réalisé lors d'une étape 508, préalablement à l'étape 507.

Un processus de génération de middleware peut être mis en oeuvre dans le cadre d'un lancement de middleware à la demande. Un tel lancement est décrit en référence à la figure 6. Un utilisateur 600 fait une requête 601 d'accès à une bibliothèque de 5 composants fournie par un système de lancement de middleware à la demande 602. En réponse, le système 602 renvoie des données 603 représentatives d'une telle bibliothèque. L'utilisateur sélectionne ensuite lors d'une étape 604, parmi les composants de la bibliothèque, ceux qu'il souhaite voir mis en oeuvre pour 10 l'exécution des applications. Le processus ci-avant (601, 603, 604) peut être facultatif, si par exemple, l'utilisateur à une connaissance a priori des composants qu'il souhaite voir mis en oeuvre. L'utilisateur envoie une requête 605 vers le système 602 qui 15 comporte une identification des composants que le middleware à lancer doit mettre en oeuvre. Le système génère le middleware lors d'une étape 606, comme décrit ci-avant. Le système peut informer l'utilisateur avec un message 607 lorsque le middleware est généré. L'utilisateur peut alors confirmer le lancement 20 lors d'une étape 608 et transmettre un message de confirmation 609 vers le système 602. Cette confirmation peut être facultative, mais elle peut permettre à l'utilisateur de compléter le middleware avec d'autres composants ou d'en supprimer certains avant le lancement (cette étape de modification n'est pas représentée). En effet, comme décrit ci-avant. Le middleware généré est 25 modulable, ce qui permet de le modifier aisément. Le système 602 lance le middleware lors de l'étape 610. Un message de confirmation 611 peut être envoyé à l'utilisateur. Une fourniture d'une bibliothèque de composants est décrite en référence à la figure 7. 30 Lors d'une étape 700, la bibliothèque est initialisée. Il s'agit par exemple de générer une bibliothèque vide en mettant en place la structure de donnée pour recevoir la bibliothèque finale.

Lors de l'étape 701, il est procédé à une étape d'identification de composants dans un ou plusieurs middlewares initiaux. Une liste de composants est alors générée. Un composant est ensuite sélectionné lors d'une étape 702, et une interface correspondant est générée lors de l'étape 703 pour l'encapsuler, avec le composant sélectionné, dans un nouveau composant lors d'une étape 704. La bibliothèque est alors mise à jour avec le nouveau composant généré. Par exemple, un lien est introduit vers un espace mémoire dans lequel est stocké le nouveau composant. Il est aussi possible d'ajouter un descriptif du 10 composant. Lors de l'étape 706, il est vérifié s'il reste des composants à traiter parmi ceux identifiés lors de l'étape 701. S'il reste des composants à traiter (OUI), le processus retourne à l'étape 702. Dans le cas contraire (NON), une étape 707 est mise en oeuvre pour vérifier si des composants externes doivent 15 être ajoutés dans la bibliothèque. Ces composants externes sont par exemple des composants ne faisant pas partie des middlewares initiaux considérés lors de la phase d'identification 701. Si des composants externes sont à ajouter dans la bibliothèque (OUI), une étape 708 de mise à jour de la bibliothèque est mise en oeuvre avec ces composants externes. Une étape 709 est alors mise 20 en oeuvre pour fournir la bibliothèque à un utilisateur souhaitant la consulter pour lancer un middleware à la demande. Lors de l'étape 707, s'il n'est pas nécessaire d'ajouter un composant externe (NON), l'étape 709 est mise en oeuvre directement. Un programme d'ordinateur selon des modes de réalisation peut être 25 réalisé par la personne du métier à la lecture de la présente description et en particulier des organigrammes des figures 5, 6 et 7. Un dispositif de génération de module d'exécution d'application et/ou de lancement d'un tel module selon des modes de réalisation est schématiquement décrit en référence à la figure 8.

30 Le dispositif 80 de la figure 8 comporte une unité de mémoire 81 (MEM). Cette unité de mémoire comporte une mémoire vive pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé conforme à l'invention, selon divers modes de réalisation. L'unité de mémoire comporte par ailleurs une mémoire non volatile (par exemple du type EEPROM) pour stocker par exemple un programme d'ordinateur, selon un mode de réalisation, pour son exécution par un ou plusieurs processeurs (non représentés) d'une unité de traitement 82 (PROC) du dispositif. Par exemple, l'unité de mémoire peut stocker un ou plusieurs composants informatiques sous forme de fichiers (par exemple .zip) pour leur intégration dans un module d'exécution d'application. Le dispositif comporte par ailleurs une unité de communication 83 10 (COM), par exemple pour échanger des données et des messages avec un utilisateur pour la génération et/ou le lancement de middlewares à la demande. La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D'autres 15 variantes et modes de réalisation peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. Dans les revendications, le terme "comporter" n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un 20 seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être 25 compris comme limitant la portée de l'invention.

Claims (15)

1. REVENDICATIONS1. Procédé de génération de module d'exécution d'application (200) comportant les étapes suivantes : - de détermination (500) d'au moins une première ressource informatique (302) disponible pour un premier composant informatique (105) auprès d'un deuxième composant informatique (106), lesdits premier et deuxième composants informatiques faisant partie d'un module d'exécution d'application initial (100), - de génération (501) d'une interface (305) permettant l'identification et l'accès de ladite au moins une première ressource par ledit premier composant informatique, - d'encapsulation (502) dudit deuxième composant informatique et de ladite interface générée dans un troisième composant informatique (211), - de génération (504) d'un noyau (213) avec au moins un analyseur de composant (307) configuré pour lier au moins deux composants entre eux, à partir d'interfaces respectives permettant l'identification et l'accès à des ressources informatiques dont lesdits composants ont besoin l'un auprès de l'autre, et - de génération (505) d'un module d'exécution d'application (200) comportant ledit troisième composant informatique et ledit noyau.
2. 2. Procédé selon la revendication 1, comportant en outre une étape de lancement (507) dudit module d'exécution d'application généré. 25
3. 3. Procédé selon la revendication 2, dans lequel ledit module d'exécution d'application généré est lancé à partir d'une première machine virtuelle fonctionnant sur un serveur matériel sur lequel est lancée une deuxième machine virtuelle supportant ledit module d'exécution d'application 30 initial.
4. 4. Procédé selon l'une des revendications précédentes, comportant en outre les étapes : - de détermination d'au moins une deuxième ressource informatique disponible pour ledit deuxième composant informatique auprès dudit premier composant informatique, - de génération d'une interface (304) permettant l'identification et l'accès de ladite au moins une deuxième ressource informatique (301) par ledit deuxième composant informatique (211), - d'encapsulation dudit premier composant (105) et de ladite interface créée dans un quatrième composant informatique (208), et dans lequel ledit module d'exécution d'application comporte ledit quatrième composant informatique.
5. 5. Procédé selon l'une des revendications précédentes, dans lequel pour chaque composant informatique du module d'exécution initial, un composant informatique est généré par encapsulation dudit chaque composant informatique du module d'exécution initial et d'une interface permettant l'identification et l'accès à au moins ressource informatique disponible auprès dudit chaque composant informatique du module d'exécution initial pour les autres composants informatiques du module d'exécution initial.
6. 6. Procédé selon l'une des revendications précédentes, comportant en outre l'intégration au sein dudit module d'exécution d'application d'un moins un composant informatique externe (306) comportant une interface permettant l'identification et l'accès à au moins ressource informatique disponible auprès dudit composant informatique externe pour d'autres composants informatiques, ledit composant informatique externe ne faisant pas partie dudit module d'exécution initial.
7. 7. Procédé selon l'une de revendications précédentes, dans lequel le module d'exécution d'application généré comporte au moins deux composants informatiques issus de l'encapsulation d'un au moins deux composantsinformatiques faisant partie de deux module d'exécution d'application initiaux respectifs distincts.
8. 8. Procédé selon l'une des revendications précédentes, dans lequel ledit troisième composant est configuré pour la fourniture d'un seul service dudit module d'exécution d'application initial.
9. 9. Procédé selon la revendication 8, dans lequel des troisièmes composants informatiques sont créés pour chaque service dudit module d'exécution d'application initial
10. 10. Procédé de lancement de module d'exécution d'application à la demande comportant les étapes suivantes : - de réception d'une requête (605) de lancement de module d'exécution d'application comportant un composant informatique identifié, - génération (606) d'un module d'exécution d'application selon l'une des revendications 1 à 9, ledit module d'exécution d'application comportant ledit composant informatique identifié, et - lancement (610) dudit module d'exécution d'application généré. 20
11. 11. Procédé selon la revendication 10, dans lequel, ledit composant informatique est identifié dans une bibliothèque de composants informatiques d'au moins un module d'exécution d'application initial utilisé pour la génération d'un module d'exécution d'application selon l'une des revendications 1 à 8.
12. 12. Procédé selon la revendication 11, dans lequel ladite bibliothèque de composants comporte en outre au moins un composant informatique externe ne faisant pas partie dudit au moins module d'exécution initial. 25 30
13. 13. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une des revendications précédentes, lorsqu'il estchargé et exécuté par au moins un processeur d'un dispositif ou un système de génération et/ou de lancement de module d'exécution d'application.
14. 14. Système de génération et/ou lancement de module d'exécution d'application comportant une unité de traitement (82) configurée: - la détermination d'au moins une première ressource informatique disponible pour un premier composant informatique auprès d'un deuxième composant informatique, lesdits premier et deuxième composants informatiques faisant partie d'un module d'exécution d'application initial, - la génération d'une interface permettant l'identification et l'accès de ladite au moins une première ressource par ledit premier composant informatique, - l'encapsulation dudit deuxième composant informatique et de ladite interface générée dans un troisième composant informatique, - la génération d'un noyau avec au moins un analyseur de composant configuré pour lier au moins deux composants entre eux, à partir d'interfaces respectives permettant l'identification et l'accès à des ressources informatiques dont lesdits composants ont besoin l'un auprès de l'autre, et - la génération d'un module d'exécution d'application comportant ledit troisième composant informatique et ledit noyau.
15. 15. Système selon la revendication 14, comportant en outre une unité de communication (83) configurée pour recevoir une requête de lancement de module d'exécution d'application comportant un composant informatique identifié, et dans lequel l'unité de traitement est en outre configurée pour la génération d'un module d'exécution d'application comportant ledit composant informatique identifié, et le lancement dudit module d'exécution d'application généré.