De l'autre côté du middleware

Au confluent des intérêts techniques et commerciaux de tous les acteurs de l'industrie informatique, l'Internet et le Web cristallisent aujourd'hui les courants de pensée dans le domaine du développement d'applications. Les idées, parfois fort anciennes à l'échelle de la discipline informatique elle-même et souvent longuement mûries dans les laboratoires, jaillissent sous l'effet de la croissance explosive de l'Internet et du Web (on dénombrait 36,7 millions de nœuds connectés au milieu de l'année 1998, 650 000 sites Web au début de l'année 1997 et 2,8 millions en août 1998). Il aura fallu une dizaine d'années pour que les interfaces utilisateur graphiques s'imposent, cinq à dix ans pour que l'architecture client-serveur se banalise ; aujourd'hui les fameuses " années Internet " se comptent en semaines, voire en journées !

Ainsi, on est passé allègrement de l'architecture client-serveur à celle dite distribuée ou encore multi-niveau dans un souci de plus grande souplesse d'emploi ; de diminution des coûts de développement et de maintenance des applications informatiques ; d'ouverture et d'universalité des protocoles de communication et des formats de données ; de généralisation des documents structurés et des langages de développement. Ces vagues successives de technologies se brisent parfois sur le roc, plus ou moins érodé, des solutions techniques mises en place antérieurement dans les systèmes d'information des entreprises. Se pose alors le problème récurrent de l'intégration des nouvelles applications à l'existant généralement prédominant.

Cela se traduit par autant de questions posées aux départements informatiques des entreprises, aux chefs de projets, aux chargés de développement et, de plus en plus, aux utilisateurs. Ces utilisateurs sont devenus acteurs et partie prenante dans le débat d'aujourd'hui. Comment exploiter les avantages offerts par ces nouvelles techniques sans bouleverser des méthodes et des procédés antérieurement établis ? Comment faire migrer les applications et les données existantes vers ces nouvelles solutions ? Comment faire cohabiter nouvelles et anciennes applications ? Comment créer un ensemble cohérent de services, internes ou externes, à partir de ces applications hétérogènes ? Comment les ouvrir, le cas échéant, totalement ou partiellement au Web ? Faut-il adapter ou réécrire ?

La bataille des modèles objets, version middleware

Notons que ces questions, loin d'être nouvelles, ne surprendront pas ceux qui ont une expérience du monde de l'informatique d'entreprise. Les technologies objet, dont les origines remontent au début balbutiant des langages de programmation eux-mêmes, ont mûri longuement dans les travaux de recherche académiques. Elles ont trouvé des véhicules techniques et commerciaux dans les langages de programmation comme Eiffel, CLOS, Object, mais surtout dans C++ et dans Java, dont le succès a permis la vulgarisation de l'objet. Ces langages de assurent une meilleure productivité des programmeurs et contribuent par conséquent largement à résoudre certaines questions.

Fortes de ce premier succès, les technologies sont reprises et voient leur portée s'élever de la (simple) programmation à la conception et à l'intégration d'applications. Le discours des prosélytes est à peu près le suivant : si l'on arrive d'une part à distinguer la face publique des applications (appelée interface), visible du point de vue des utilisateurs de la face privée (appelée implémentation) qui ne concerne que les choix techniques du développeur, et d'autre part à mettre en relation ces interfaces, non seulement la conception et le développement d'applications deviennent un jeu d'assemblage, mais le rapport coûts/bénéfices est sensiblement modifié. Les implémentations sont alors interchangeables du moment que sont respectées les interfaces, et la même implémentation peut être réutilisée autant de fois que son interface est requise. L'analogie avec les équipementiers et les ensembliers dans l'industrie automobile, ou encore avec les composants électroniques et les constructeurs est claire !

Au début des années 90, deux organisations que tout éloigne s'engagent sur cette voie : l'Object Management Group (OMG) et Microsoft. L'OMG, un consortium qui regroupe aujourd'hui plus de 800 acteurs de l'industrie informatique (éditeurs de logiciels, constructeurs, utilisateurs) se fait le champion consensuel des technologies objet et publie la norme Common Object Request Broker Architecture entre 1989 et 1996. Microsoft parvient dans le même temps (de 1990 à 1996) à de restructurer Windows et sa collection initialement hétéroclite de services en adoptant un principe fédérateur orienté objet : le Component Object Model (COM) ; l'avatar actuel du modèle COM, ActiveX, est présent dans tous les produits Microsoft, systèmes d'exploitation comme applications.

À l'examen des deux systèmes, on constate qu'il y a séparation effective des interfaces et des implémentations : dans Corba, comme dans ActiveX, les interfaces des objets y sont décrites dans un langage indépendant des langages de programmation employés pour leurs implémentations respectives En revanche, il y a encore peu de temps, la communication entre objets était peu, voire pas, assurée : des objets Microsoft pouvaient communiquer entre eux, mais n'étaient pas ou difficilement en mesure de le faire avec des objets Corba. Ces incompatibilités entre modèles objet, entretenus par les enjeux commerciaux sous-jacents, promettaient de sonner le glas de la réutilisation prophétisée par les élégiaques des systèmes d'objets distribués. Le rideau allait-il donc tomber sur une fracture irréductible entre une norme théoriquement satisfaisante, complète, consensuelle, mais souffrant d'une distribution limitée de produits commerciaux, et une entreprise, aux ambitions monopolistiques, offrant aujourd'hui des solutions pragmatiques mais fermées ?

La bataille des modèles objets, version serveur

Le succès du Web, puis du langage de programmation Java, surprend les deux clans dans leur lutte fratricide pour imposer un modèle objet. Leur réaction est néanmoins rapide. L'OMG voit dans la population croissante des programmeurs Java une nouvelle communauté à galvaniser. Le groupe, arrivant au bout de sa mission de spécification et d'évangélisation, espère ainsi trouver un second souffle. Après les atermoiements tragi-comiques de la fin 1995, Microsoft annonce fort et clair qu'il " embrasse et étend " les technologies de l'Internet et du Web. La résultante de ces efforts et de ces glissements de stratégie est en fait bénéfique à tous : Java, devenant la lingua franca des nouveaux développements objet, estompe du même coup les grandes différences entre les modèles objets. Aujourd'hui, ce débat s'est apaisé et l'on peut développer des objets Corba en Java, capable d'interagir avec d'autres objets de l'univers Corba écrits dans d'autres langages de programmation. De même, on développe des objets COM en Java avec les outils de Microsoft ou ceux d'autres fournisseurs. Les solutions techniques d'interopérabilité entre le monde Corba et le monde COM se stabilisent. En janvier 1998, Iona, une société d'origine irlandaise cotée au NASDAQ et considérée comme l'un des champions de Corba, annonce ainsi l'acquisition de la licence du code source de COM auprès de Microsoft et engage une politique de livraison de produits d'intégration entre Corba et COM.

L'affaire semble donc réglée. En fait, le théâtre des opérations s 'est simplement déplacé : après avoir gagné la bataille du client et du middleware, les objets partent à l'assaut des serveurs. La stratégie déroulée par Javasoft pour la plate-forme Java tout au long des années 1997-1999 illustre cette analyse. D'abord présenté comme le langage de choix pour la création d'applets , Java est devenu, au gré des spécifications et des livraisons successives de Javasoft, une véritable plate-forme de développement qui vise à couvrir le plus grand territoire applicatif possible : depuis les téléphones cellulaires et les cartes à puces jusqu'aux applications d'entreprise, en passant par les ordinateurs de poche. Les Java Beans, le modèle objet inspiré de Corba et élaboré par Javasoft, se dégagent de leur gangue originelle encore imprégnée d'interface graphique et de technologies propres au client pour devenir dans leur nouvelle incarnation, les Enterprise Java Beans (EJB), un modèle complet de composants logiciels adaptés aux besoins de serveurs d'applications. Microsoft ne reste pas inactif et complète sa gamme de produits pour serveurs avec Microsoft Message Queue Server (MSMQ) et Microsoft Transaction Server (MTS). MTS, en particulier, ouvre les objets COM aux transactions et à la distribution, comme Corba le fait pour son propre modèle et EJB pour les composants écrits en Java.

Les grands acteurs de l'informatique ont fourbi leurs armes, la bataille pour le contrôle de l'architecture objet des systèmes d'information peut s'engager.

Les spécifications de l'OMG : CorbaComponents et Object Transaction Services (OTS)

Le modèle de composants logiciels adopté par l'OMG au début de l'année 2000 trouve ses sources d'inspiration dans l'ensemble architectural élaboré par l'OMG depuis 1989 et dans les concepts apportés par la plate-forme de développement Java Enterprise Edition qui contient les EJB. La norme Corba décrit les services transactionnels appropriés à un système d'objets distribués. L'Object Transaction Service (OTS) fait partie de CorbaServices, c'est-à-dire des services généraux sur lesquels peuvent s'appuyer les applications objet distribuées. CorbaServices est constitué d'un ensemble de spécifications qui couvrent, entre autres, les annuaires, la gestion des événements, la sauvegarde et la récupération de l'état des objets, l'administration, l'authentification et la sécurité des objets, leur cycle de vie et leurs relations, ainsi que les transactions. Comme tous les services qu'elle décrit, la norme Corba spécifie l'OTS en utilisant l'Interface Definition Language (IDL) pour présenter les objets qui le composent.

OTS est conçu comme une adaptation des principes des moniteurs transactionnels classiques au monde des objets distribués. L'OMG ne fait pas là œuvre révolutionnaire, bien au contraire : d'une part, le groupe doit se conformer aux règles de fonctionnement qui lui imposent d'adopter les standards qu'il promulgue sur la base de produits et de technologies disponibles commercialement ; d'autre part, un organisme de standardisation, en l'occurrence X/Open, a déjà établi un modèle, X/Open Distributed Transaction Processing (DTP), assez généralement adoptée par les fournisseurs. L'objectif affiché de la norme OTS est d'unir le modèle transactionnel, à la valeur éprouvée dans les applications traditionnelles, au modèle objet, garant d'une meilleure productivité et d'une plus grande qualité des applications. Tout objet Corba doit pouvoir participer à une transaction sans pour autant imposer des restrictions fonctionnelles relatives à son usage dans une application distribuée. De ce principe découle la séparation des services transactionnels à proprement parler de l'ORB lui-même. Pourquoi ne pas envisager l'approche inverse : doter un moniteur transactionnel éprouvé des fonctionnalités supplémentaires qui en feraient un ORB ? Ce serait là une pétition de principe : dans un modèle objet, les objets sont les éléments constitutifs de l'application ; ils ne sont pas conçus en fonction de l'usage, transactionnel ou non, qu'il en sera fait. La séparation des services transactionnels de ceux de l'ORB permet aux transactions d'être construites sur des objets définis antérieurement ou extérieurement et rend possible des transactions qui mettent en jeu à la fois des objets et des ressources situées à l'extérieur de l'ORB. Un service transactionnel comme OTS favorise donc l'intégration des objets Corba aux applications non objet du système d'information.

Le service de transaction fournit un mécanisme de synchronisation des opérations dans une application répartie suivant le modèle client-serveur multiniveau. Comme une transaction met en jeu plusieurs objets et requêtes dont on doit pouvoir confirmer ou annuler les effets tout au long de son exécution, seuls les objets qui y participent doivent être en mesure de l'identifier. Cette identité est en quelque sorte partagée par les objets qui composent une transaction. On parle alors de contexte de transaction.

Dans un scénario d'application typique, un programme client commence une transaction en appelant un objet particulier d'OTS qui établit un nouveau contexte de transaction associé à la tâche du programme client. Le programme client envoie ensuite les messages, ou requêtes dans le vocabulaire Corba. Ces requêtes sont associées implicitement au contexte de transaction. Lorsque le programme client met fin à la transaction, via une autre requête adressée à OTS, les changements produits sont confirmés ou annulés suivant le succès ou l'échec de l'opération. Dans ce scénario, le contexte de transaction est implicitement transmis aux objets destinataires des requêtes du programme client, sans intervention directe de ce dernier. D'autres scénarios sont envisageables : avec OTS le programme client peut contrôler explicitement la transmission du contexte de transaction (comme un paramètre supplémentaire dans une requête) aux objets participant à la transaction. Le service de transaction doit donc offrir des mécanismes de contrôle explicite et implicite du contexte de transaction.

Les applications transactionnelles s'appuyant sur OTS mettent en jeu cinq catégories d'objets :

• · Les clients transactionnels. Il s'agit typiquement d'un programme qui fait appel à une transaction : dans l'achat d'un livre sur une librairie en ligne, par exemple, le navigateur Web qui entame la transaction est un client transactionnel.
• · Les objets transactionnels. Ils représentent la transaction en cours sur le serveur : c'est le caddie qui contient les différents livres en cours de commande dans l'exemple précédent.
• · Les objets récupérables (recoverable objects). Ils sont associés à des ressources, c'est-à-dire des données modifiées par la transaction. Dans l'exemple de la librairie en ligne, les objets qui représentent le compte bancaire du client et celui du vendeur, doivent être respectivement débité et crédité en même temps lors de l'exécution de la transaction. Dans la plupart des transactions, ces objets correspondent aux tables ou aux enregistrements dans une base de données relationnelles.
• · Les serveurs transactionnels. C'est l'environnement d'exécution des objets transactionnels. Dans l'exemple de la librairie en ligne, le serveur transactionnel est constitué du serveur Web et du serveur d'applications responsable des transactions.
• · Les serveurs récupérables (recoverable servers). Ce sont les serveurs chargés de la gestion des données dont les transactions doivent protéger l'intégrité. Dans notre exemple, il s'agit serveur du système de gestion de bases de données relationnelles piloté par le serveur d'applications.

Ces principes sont en fait, nous allons le voir, valables pour tous les systèmes de composants logiciels.

L'architecture de composants logiciels EJB de Sun Microsystems

Les Enterprise Java Beans (EJB) sont le résultat d'un travail de spécification entamé par Sun Microsystems et ses partenaires. La première version est dévoilée à la conférence JavaOne en mars 1998. En construisant les EJB, Sun s'est fixé une mission : faire pénétrer le langage de programmation Java sur le marché des applications informatiques d'entreprise en le dotant d'un modèle de composants logiciels complet, simple d'usage et facile à intégrer à l'existant. Cet axe de développement de la plate-forme Java illustre la mutation, encore inachevée, qui transforme un langage de programmation restreint à l'animation des pages Web en un modèle complet de composants logiciels, en concurrence avec les modèles reposant sur une architecture classique y compris celui deMicrosoft.

Les objectifs que se sont fixés les concepteurs d'EJB sont les suivants :

• · fournir aux applications d'entreprise une architecture standard de composants logiciels répartis qui permette l'assemblage de composants construits avec des outils hétérogènes ;
• · suivre la philosophie de déploiement des applications sans recompilation, caractéristique du langage de programmation Java ;
• · simplifier le travail du programmeur en cachant les problèmes complexes de gestion des ressources, de gestion d'états et de parallélisme des tâches ; fournirun jeu d'API complet pour que le programmeur puisse contrôler complètement le fonctionnement des composants ;
• · faciliter le développement des applications et permettre leur déploiement dans des environnements a priori hétérogènes ;
• · assurer la compatibilité avec les autres API qui enrichissent le langage de programmation Java ;
• · offrir une compatibilité entre les EJB les serveurs d'applications existants et faciliter l'adjonction des EJB aux environnements de développement commerciaux ;
• · assurer la compatibilité entre les EJB et la norme Corba de l'OMG.

Cet inventaire met en évidence qu'EJB est un outil de productivité pour le programmeur d'applications d'entreprise qui n'est pas exclusivement réservé à la création d'applets ; les EJB s'adaptent aux environnements variés des fournisseurs d'outils logiciels et de technologies. En adoptant les EJB, on participe à l'essor de l'industrie du composant logiciel métier que Sun, secondé par IBM, s'emploie à favoriser.

Le cycle de vie d'une application à base des EJB est une " pièce de théâtre " qui compte six rôles complémentaires ; ils se succèdent au cours du déroulement de la pièce. Ces rôles peuvent être tenus par un individu ou une équipe dans une organisation, un fournisseur ou une organisation tierce ; une même organisation tient éventuellement plusieurs rôles dans le scénario qui mène du développement au déploiement d'une application à base de composants.

• · L'éditeur de composants EJB est typiquement un spécialiste métier du ou des secteurs auxquels il fournit ses produits. Son expertise n'est pas technique. Il s'appuie sur un conteneur EJB fourni par un tiers qui le libère des préoccupations ayant trait aux transactions, à la gestion de ressources ou à l'exploitation du multitâche. En revanche, il fournit ses composants spécialisés dans un format prédéfini (ejb-jar), sous forme d'une collection de classes Java, les interfaces dites locales et distantes de ces composants EJB, du descripteur de déploiement et de leurs propriétés d'environnement. C'est au prix de cette conformité que les composants de l'éditeur d'EJB trouvent place dans tout environnement de développement ou de déploiement, tant interne qu'externe.
• · À l'aide d'un environnement de développement graphique, le développeur assemble son application en y ajoutant ou en y retirant des composants Beans (provenant d'un ou de plusieurs éditeurs) et en ajustant leurs paramètres. Comme l'interface et l'implémentation d'un composant séparés, EJB assure que l'assembleur n'a pas à connaître de la structure interne des composants qu'il assemble pour créer une application. Son expertise est également fonctionnelle et se rapporte au métier ou au domaine de l'application plutôt qu'à l'informatique et à la programmation. L'assemblage produit des applications (avec ou sans interfaces graphiques), des nouveaux composants logiciels EJB, ou encore des applets. Il est possible de poursuivre et de réaliser l'assemblage de composants Beans une fois l'application déployée : il n'y a pas de séparation stricte en développement et déploiement, la maintenance et l'enrichissement fonctionnel d'une application à base d'EJB sont continus.
• · Le déploiement des EJB est contrôlé par des informations particulières, attachées au composant logiciel lui-même. Le descripteur de déploiement gère ces informations. Cette nouvelle séparation entre le composant et l'information nécessaire à son déploiement permet d'adapter l'application dans laquelle figure le composant à des environnements opérationnels différents, par exemple du point de vue de la sécurité ou des privilèges d'accès. Les services requis et fournis par les EJB, en particulier tout ce qui concerne les transactions et la gestion des ressources, sont assurés par des plates-formes techniques, des serveurs d'applications qui se conforment aux spécifications du modèle EJB. On s'attend à ce que des spécialistes des systèmes d'exploitation ou des environnements transactionnels plutôt que des experts d'un secteur ou d'un métier particulier implémentent ces services. Une fois de plus, le recours à des interfaces formalisées assure un partage complet des responsabilités et, à terme, une robustesse accrue de l'application.Typiquement, un serveur EJB fournit une implémentation d'un conteneur EJB avec les interfaces de conteneur de session et de conteneur d'entité qui le caractérisent. Les interfaces de programmation d'un serveur EJB sont rendues publiques pour qu'un tiers puisse rapidement créer des conteneurs EJB spécifiques à un domaine ou à une technologie particulière.
• · Le conteneur EJB est en fait la pièce maîtresse du dispositif qui assure le contrat entre le composant EJB et le serveur d'applications. Si par exemple, le composant EJB délègue au conteneur la gestion de la persistance de son état, le conteneur doit faire appel aux services sous-jacents du serveur de manière à assurer cette fonction indépendamment du procédé retenu (système de fichiers, système de gestion de bases de données, transaction externe…). L'édition de conteneurs EJB est le domaine des programmeurs système ou des spécialistes des modes de migration et de gestion de données. Un fournisseur de progiciel intégré peut mettre en œuvre cette interface de conteneur EJB au dessus de l'architecture traditionnelle de ses produits et faciliter ainsi leur intégration dans un monde de composants logiciels écrits en Java. Le conteneur EJB est également responsable de la gestion des versions des composants qu'il contient. Il doit d'ailleurs effectuer cette gestion sans remettre en cause les assemblages déjà établis entre composants de manière à simplifier la livraison des mises à jour des applications au cours de leur cycle de vie.
• · Le conteneur EJB est logiquement accompagné d'un ensemble d'outils d'administration et de suivi des applications qui permettent de contrôler l'exécution des assemblages d'EJB. La tâche inévitable de l'administration du système s'opère dans les environnements de gestion usuellement associés soit au conteneur EJB ou au serveur EJB.

L'architecture des EJB reprend à son compte les caractéristiques des composants logiciels Beans. Le modèle EJB s'appuie sur une identification des rôles qui s'inspire de la distinction conteneur/contenu. On retrouve ce principe dans les documents composites de l'architecture OLE chez Microsoft et chez des concurrents moins chanceux comme CI Labs avec OpenDoc, dans les moniteurs transactionnels classiques qui contiennent, en quelque sorte, des transactions sur des données ainsi à l'abri des manipulations directes des applications.

Les relations entre composants EJB et l'application qu'ils sous-tendent sont les suivantes :

• · Les composants sont créés et gérés à l'exécution de l'application par un conteneur EJB.
• · On peut modifier un composant EJB à l'exécution de l'application en agissant sur ses propriétés d'environnement.
• · Les attributs proprement opérationnels du composant EJB (comportement transactionnel, sécurité…) sont séparés du code exécutable (bytecode) du composant lui-même ; ces paramètres peuvent être ajustés dans les phases de développement ou de déploiement.
• · Le client d'un composant EJB ne peut accéder directement au composant en question et doit passer par le conteneur et le serveur EJB.
• · Un composant EJB peut être déployé dans tout conteneur qui respecte les interfaces EJB ; des composants EJB peuvent fournir des services supplémentaires pourvu qu'ils soient alors basés sur des conteneurs ou des serveurs qui le permettent.
• · Il est possible d'assembler les composants EJB d'origines diverses sans exiger de recompilation ou d'accès à leur code source.

Ces aspects généraux d'un système à base de composants sont indépendants du langage de programmation Java. Leur implémentation dans les EJB s'appuie, en revanche, sur les propriétés de la machine virtuelle et sur la possibilité de charger dynamiquement en mémoire un ensemble de classes Java. On peut aussi considérer que les EJB sont une spécialisation des Java Beans trop généraux pour apporter un réponse aux besoins d'une informatique d'entreprise.

Les " contrats " EJB définissent les rôles et les responsabilités des différents constituants d'une application.

Le contrat client définit la relation entre un programme client et le conteneur de composants logiciels EJB. Ce contrat décrit les obligations relatives à l'identité, à l'invocation des méthodes et à l'interface dite locale du composant.

Un client attend d'un conteneur EJB qu'il lui fournisse un identifiant unique pour chaque composant logiciel EJB qu'il utilise. Lorsqu'il s'agit d'un composant de type session, le conteneur est responsable de la création et de l'assignation de cet identifiant unique. Un composant de type entité (en général associé à des données dans la transaction) fournit une clé primaire que le conteneur intègre dans l'identifiant du composant.

Un composant EJB et son conteneur coopèrent pour assurer l'invocation des méthodes du composant. Les interfaces fonctionnelles du composant Beans situé à l'intérieur du conteneur EJB sont qualifiées de distantes. Le conteneur est responsable de l'appel des méthodes du composant sollicité par le client et le composant EJB est évidemment responsable de leur implémentation et de leur exécution. Le composant EJB doit également implémenter l'interface dite locale (home interface) ; elle contient les méthodes qui permettent de créer une instance du composant en question, de rechercher ce composant dans le conteneur EJB ou un ensemble de composants. Cette interface locale, les " usines à objets " dans le monde DCOM/ActiveX de Microsoft ou les " usines à transactions " de la norme Corba OTS jouent le même rôle.

Le contrat composant définit la relation entre les composants EJB et leur conteneur. Ce contrat est divisé en plusieurs interfaces :

• · Une série de rappels (callbacks) que le composant implémente et que le conteneur déclenche durant les transactions. Pour un composant de session EJB, ces rappels concerne la synchronisation des événements transactionnels ; pour un composant de type entité, ces rappels ont trait à la sauvegarde et la récupération des états et des sonnées associées.
• · L'interface de contexte de session qui est transmise à un composant EJB de type session à sa création. Au travers de cette interface le composant contenu peut faire appel aux services fournis par le conteneur EJB qui l'englobe.
• · L'interface d'environnement que le conteneur met à la disposition des composants EJB.
• · On retrouve dans ces dernières définitions les grandes sections des interfaces OTS de la norme Corba, elles-mêmes inspirées de la norme DTP de l'X/Open. D'une manière plus générale, le modèle transactionnel des composants EJB utilise abondamment les travaux techniques sur lesquels repose la norme Corba OTS. Son implémentation est, en ce sens, plus élaborée puisqu'elle met en jeu certaines caractéristiques propres du langage de programmation Java et la formalisation de systèmes à base de composants issue de Java Beans.

Comme les fichiers au format jar, les fichiers au format ejb-jar contiennent toutes les informations requises pour le bon fonctionnement des composants EJB. Viennent s'ajouter les descripteurs de déploiement et les propriétés d'environnements ; cette information relative à l'exécution et au déploiement des composants complète l'information de conception, déjà présente dans les Java Beans.

Pour assurer les caractéristiques ACID des transactions entre Java Beans, le modèle EJB distingue deux types de composants EJB : les sessions et les entités :

• · Un composant EJB de type session effectue les opérations, transactionnelles ou non, par délégation du programme client appelant. Il y a une session par programme client. Le composant EJB de type session est responsable de l'intégrité des données manipulées durant la transaction. Les objets de type session disparaissent si le serveur de composants EJB périt, victime d'une défaillance ; le programme client a alors la charge de créer une nouvelle session pour poursuivre son exécution le cas échéant.
• · Un composant de type entité représente des données dont l'intégrité doit être préservée durant les transactions : c'est une ressource dans la terminologie Corba OTS. De nature transactionnelle, il permet l'accès concurrent de plusieurs programmes client à ces données. Il survit aux défaillances du serveur de composants EJB qui n'affectent pas son état.

Il s'agit là de la simple transcription dans un monde Java de la définition d'une transaction, à courte durée de vie, et d'une ressource, à longue durée de vie et dont l'état doit être préservé. On attend d'un serveur de composants EJB qu'il permette à une application de faire tourner un grand nombre de sessions et d'entités simultanément.

La spécification EJB définit la compatibilité entre le contrat client et le monde Corba en fournissant :

• · une projection des interfaces du contrat client EJB dans l'IDL de Corba ;
• · un mécanisme de passage de contexte de transaction et de sécurité entre les transactions conformes à la norme OTS et les sessions EJB.

Cette spécification a un double objectif : faciliter l'interopérabilité entre serveurs de composants EJB différents et permettre à des programmes client qui ne seraient pas écrits en Java ou qui ne se conformeraient pas au modèle EJB de faire appel à des composants transactionnels EJB du côté du serveur.

Notons que les EJB constituent une première expression complète d'un système à composants répartis en combinant les Java Beans aux notions transactionnelles. Bien que destiné au seul langage de programmation Java et s'appuyant sur ses idiosyncrasies, le modèle EJB réunit les caractéristiques générales d'un système à composants répartis et des traits qui le différencient d'un tel système. Toute l'architecture s'articule autour du processus d'assemblage de composants logiciels en applications. Les objets compilés sont enrichis de la description de leurs propriétés, de leurs méthodes et des événements auxquels ils réagissent : il s'agit de l'information de conception ; à cela s'ajoutent des paramètres qui régissent leur comportement lors de l'exécution et leur relation à l'environnement (transactionnel) dans lequel elle se déroule : il s'agit de l'information de déploiement. Bien que groupés en unités distinctes dans des fichiers au format ejb-jar, l'implémentation exécutable et ces informations restent séparées. Elles peuvent donc être manipulées par des outils et dans des environnements différents : il devient possible d'adapter le comportement des composants EJB sans recompiler ni accéder au code source ; par ailleurs, on peut mettre à jour une application avec une nouvelle version d'une implémentation fonctionnelle sans avoir à désassembler puis à rassembler l'application. Cet assemblage dynamique fonctionne aussi bien à la conception de l'application qu'au cours de son exécution.

L'architecture de composants logiciels de Microsoft (Windows 2000)

Microsoft Transaction Server fait partie intégrante de Windows 2000, la version 5 de NT. Un module de MTS, le Distributed Transaction Coordinator (DTC), est installée comme un service NT et se trouve donc à la disposition de toutes les applications. Le contrôle et la configuration de MTS s'effectuent de manière standard sous NT, soit au travers de la console d'administration, soit au travers de pages d'administration en HTML livrées avec MTS.

MTS se présente comme une véritable plate-forme d'exécution de composants logiciels, conformes à la norme DCOM. Il est construit pour satisfaire les objectifs suivants :

• · séparer la gestion des composants logiciels du ou des programmes clients ;
• · gérer les applications transactionnelles ;
• · simplifier l'usage du multitâche ;
• · simplifier les problèmes de sécurité ;
• · faciliter l'installation de services et de composants au vol ;
• · offrir une solution transactionnelle robuste capable de résister à une montée en charge.

Microsoft, l'OMG et JavaSoft partagent, sur ces points, les mêmes objectifs avec Microsoft. L'OMG vise à les formaliser avec une approche orientée objet et JavaSoft vise, dans le même temps, à donner avec les EJB une respectabilité nouvelle à Java pour le développement d'applications d'entreprise. Le grand mouvement de Microsoft vers le monde du serveur et des applications d'entreprise se traduit par l'importance considérable donnée à NT et à sa superstructure (SQL Server, MTS, MSMQ…). Dans ce contexte, MTS est la plate-forme centrale d'exécution de composants logiciels COM de Microsoft.

La première fonctionnalité d'une plate-forme d'exécution de composants est de contrôler le cycle de vie des composants logiciels dont elle est responsable. Hors MTS, un programme client COM doit gérer lui-même chacun des composants qu'il utilise, ce qui signifie :

• 1. instancier le composant ;
• 2. initialiser cette instance ;
• 3. faire appel aux différentes méthodes de l'instance initialisée suivant les besoins ;
• 4. maintenir le compte des références (via l'interface IUnknown) ;
• 5. détruire l'instance une fois ces opérations terminées.

Cette séquence d'opérations rappelle bien évidemment la gestion de structures et d'objets dans le langage de programmation C++ et s'oppose en cela à la programmation en Java dans laquelle la machine virtuelle contrôle le cycle de vie des objets. Une telle séquence est typique de l'usage d'un objet ActiveX dans une page ASP, par exemple. Dans un tel cas, tous les composants restent en mémoire tant que la page ASP est active. On a donc intérêt à détruire les objets juste après l'appel à l'une de leurs méthodes. Il est clair, cependant, que cette solution qui réduit l'encombrement de la mémoire diminue les performances : l'instanciation et l'initialisation répétées du composant imposent des délais d'exécution intolérables dans un environnement multi-utilisateur. De plus, il faut conserver l'état du composant entre ses différentes instanciations, ce qui alourdit le code du programme client. De même, si le composant est lié à une base de données, l'ouverture et la fermeture réitérées de connexions au serveur de données surcharge immédiatement le réseau.

MTS sépare l'administration des composants (instanciation, installation, destruction) de leur utilisation. Comme le conteneur EJB, MTS gère des " réservoirs " de composants dont il fournit une instance à la demande du client. Lorsque l'instance est inutilisée, elle redevient disponible dans le réservoir pour un autre programme client. Quant au programme client, il reçoit de MTS un ersatz de composant, appelé contexte objet, qui a l'apparence, c'est-à-dire les interfaces, du composant. MTS associe le contexte objet à l'une des instances (le code exécutable) disponible dans le réservoir correspondant.

En général, la construction du contexte objet est possible puisqu'à chaque composant COM correspond une bibliothèque de types qui décrit ses propriétés et la signature de toutes ses méthodes. Cette information est enregistrée dans un fichier unique sur une machine sous Windows. Ce fichier, appelé registre, associe à chaque interface individuelle non seulement sa description complète mais également des attributs de déploiement et de version. MTS utilise cette description du composant pour reconstituer à l'identique le contexte objet et ses interfaces de celles du composant original.

Ce mécanisme est identique à celui des interfaces locale et distante pour une session EJB sans état. DCOM dispose également d'usine à objets qui séparent l'instanciation de l'initialisation des objets (au travers de l'interface IFactory). MTS intercepte les appels aux usines à objets, qui font partie des objets DCOM, de façon à générer un contexte objet pour chaque demande d'instanciation venant d'un programme client. Cette interface, qui joue le même rôle que l'interface locale (home interface) dans EJB, s'appelle class factory wrapper (enveloppe d'usine à composants !). Dans MTS comme dans EJB, ces mécanismes sont génériques et indépendants de composants uniquement parce que ces derniers contiennent la description complète de leurs propriétés et de leurs méthodes. Cette description est explicite (BeanInfo) ou implicite (via les interfaces Introspection et Core Reflection) dans les EJB, explicite dans le modèle DCOM (bibliothèque de types déclarée dans le registre).

Comme le conteneur EJB génère au vol l'interface distante du composant EJB pour le programme client, MTS produit un contexte objet qui apparaît au programme client comme un composant réel. Cette séparation entre clients et composants permet à MTS et au conteneurs EJB de fournir des services sans imposer de contraintes particulières ni au programme client ni au composant lui-même. Ainsi, les fournisseurs de composants n'ont pas à écrire de code supplémentaire pour assurer le bon fonctionnement de leurs logiciels dans un environnement transactionnel.

MTS se présente donc comme un conteneur COM au même titre que le conteneur EJB sépare les implémentations des programmes client de celle des composants logiciels. Comme les modèles OTS et EJB, il sépare clients et composants et facilite ainsi l'interposition de services sans imposer de révision du code source du client ou du composant.

Les choix architecturaux sont similaires : le composant est en fait " représenté " par un objet intermédiaire (objet EJB ou contexte objet dans MTS) qui implémente par délégation toute l'interface fonctionnelle du composant. Cet objet intermédiaire est créé automatiquement par le conteneur (EJB ou MTS) lors de l'instanciation, sur la base de l'information (propriétés et signatures des méthodes) déclarée et associée au code exécutable du composant. Cette association est sous la responsabilité du programmeur. Dans le cas d'EJB qui exploite les particularités du bytecode du langage de programmation Java, elle peut être automatisée. Dans le cas de DCOM et de MTS, cette information est déclarée et enregistrée dans un fichier, dit registre, qui centralise ces descriptions.

En revanche, la gestion du multitâche est différente dans les deux architectures. Le langage de programmation Java fournit directement la prise en charge du multitâche réalisée par la machine virtuelle Java. Cette intégration poussée du multitâche est évidemment exploitée dans EJB, ce qui permet une grande souplesse dans l'implémentation des composants logiciels. Dans le cas de MTS, les modèles hérités des versions 16 bits de Windows et des premières versions de NT (jusqu'à la version 3.51) brouillent quelque peu la vision. Ces modèles particuliers, s'ils rendent la programmation directe du multitâche relativement complexe dans NT, permettent cependant d'exploiter sans modification des composants COM conçus et écrits avant la livraison de NT et de MTS.

Enfin, les deux systèmes proposent un dispositif de regroupement des composants et de l'information qui leur est attachée. Le format adopté permet l'échange des composants entre deux serveurs et leur installation automatique sur un nouveau serveur. Toutes les informations attachées aux composants peuvent être modifiées tant au développement qu'au déploiement, au travers d'outils d'administration appropriés.

Les caractéristiques générales des systèmes de composants logiciels

De l'examen de ces différents exemples d'architecture d'objets logiciels répartis il est possible d'abstraire quelques principes fondateurs qui reflètent l'état de l'art dans le domaine. Ces systèmes de composants logiciels doivent être envisagés, du point de vue technique, sous deux angles : celui du développement de l'application dont la métaphore générale est celle de l'assemblage ; et celui du déploiement ou de l'exécution dont la métaphore est alors celle de la transaction. Les frontières entre phases de développement et de déploiement, entre analyse et maintenance, entre propriétaire et ouvert sont beaucoup moins clairement délimitées que dans les méthodologies traditionnelles et que dans les environnements techniques de type mainframe ou même client-serveur. En effet, dans un système de composants logiciels, il est possible de changer ou de modifier un composant au vol sans remettre en cause l'application (parfois même en cours d'exécution) ; il est possible d'actualiser un composant sans nécessairement arrêter les applications qui en dépendent ; le rôle des standards est essentiel pour assurer l'interopérabilité entre composants logiciels issus de divers fournisseurs et pour protéger les implémentations propriétaires des composants qui en font la valeur.

Dans la phase de déploiement et d'exécution de l'application à base de composants, le principe de dissociation des programmes clients, des serveurs et des services permet de créer un environnement d'exécution propre aux applications sans avoir à retoucher les objets et les composants logiciels sur lesquels elles s'appuient. Les services requis comme les annuaires, la sécurité, les transactions sont dits interposés entre les programmes client et serveur. L'interposition permet d'élaborer clients et serveurs en toute indépendance. La plate-forme d'exécution, aussi appelée serveur d'applications, a pour mission de contrôler le cycle de vie des composants logiciels auxquels les programmes clients font appel et d'assurer l'interposition des services.

Pour pouvoir être assemblé puis fonctionner dans l'environnement d'exécution, le code binaire exécutable ne suffit pas si l'on veut préserver l'indépendance des différents rôles entre clients, serveurs et services. Pour la phase de développement, l'assemblage de composants logiciels impose la découverte au vol des propriétés et des méthodes du composant et, dans le modèle EJB, les événements auxquels il est associé. Ces données supplémentaires doivent être jointes au code exécutable proprement dit. Les systèmes de composants logiciels du marché diffèrent sur la représentation de cette information ainsi que sur le mécanisme d'association au code exécutable. Les environnements de développement facilitent, voire même automatisent complètement, cet effort de documentation supplémentaire au travers d'interfaces graphiques et de notation graphique standardisée aujourd'hui par la norme UML. Mais ce n'est pas tout : le composant doit également être livré avec des données supplémentaires ayant trait, cette fois, aux services qu'il requiert pour son exécution. Cette information complémentaire au serveur d'applications de configurer ou de paramétrer, là aussi au vol, l'interposition adéquate des services (transaction, annuaire, sécurité, persistance…). Ces deux " paquets " de données supplémentaires qui s'ajoutent au code exécutable illustrent une approche déclarative de l'assemblage de composants logiciels qui s'oppose aux méthodes traditionnelles de composition d'applications à partir de modules compilés (édition de liens) ou de bibliothèques - même si les bibliothèques liées dynamiquement représentent un progrès dans cette direction.