Rapport de Stage DEA dInformatique ? Rapport de Stage DEA dInformatique ... 2.3.4 Importation

  • Published on
    15-Sep-2018

  • View
    212

  • Download
    0

Transcript

Universit dvry-Val dEssonneInstitut National des TlcommunicationsRapport de StageDEA dInformatiqueSERVICES DE RECHERCHE INTELLIGENTSET DPLOIEMENT DYNAMIQUEDAPPLICATIONS MULTI-COMPOSANTSDhouha AYEDResponsable de DEA : Jean-Marc DELOSMEResponsable de stage : Chantal TACONETJuillet 2001Ce stage de DEA a t ralis au sein du laboratoire Systmes Rpartis du dpartement Informatiquede lInstitut National des TlcommunicationsRemerciementsCe stage a t ralis au sein de lquipe systmes rpartis de lInstitut National des Tl-communications dEvry.Je remercie, le chef du dpartement informatique, Monsieur Guy Bernard, pour mavoir accueillidans son quipe.Je remercie vivement Madame Chantal Taconet pour mavoir propos ce sujet et mavoir encadrpendant toute la priode de stage.Je tiens remercier toute lquipe de systmes rpartis notamment Monsieur Denis Conan, Mon-sieur Christian Bac, Monsieur Daniel Millot et Madame Sophie Chabridon pour leurs conseils etleurs aides.Je tiens exprimer ma profonde gratitude au thsards : Erik Putrycz, Olivier Villin, RonaldoRamos et Victor Budau pour leur aide prcieuse et leur soutien.Je remercie aussi ma collgue, stagaire de DEA, Lydialle Debassen.Je finis en remerciant mes parents et ma famille pour leur soutien et tous mes amis pour leursencouragements.iiiTable des matires1 Introduction 11.1 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Prsentation du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Etude comparative des services de recherche sur proprits 32.1 Concepts de courtage et terminologie . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Trader CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.1 Types de services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Exportation de services auprs du trader . . . . . . . . . . . . . . . . . . 52.2.3 Importation de services et langage de contraintes . . . . . . . . . . . . . 62.2.4 Fdration du service de recherche . . . . . . . . . . . . . . . . . . . . . 62.2.5 Proprits dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.6 API trader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.6.1 Les interfaces dutilisation . . . . . . . . . . . . . . . . . . . 82.2.6.2 Les interfaces dadministration . . . . . . . . . . . . . . . . . 102.2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Service de recherche de Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 Vue gnrale sur le modle du service de recherche de Jini . . . . . . . . 112.3.2 Connexion au service de recherche . . . . . . . . . . . . . . . . . . . . . 132.3.3 Exportation de services auprs dun service de recherche . . . . . . . . . 142.3.4 Importation de services auprs dun service de recherche . . . . . . . . . 142.3.5 Structure des donnes enregistrs au niveau du service de recherche . . . 152.3.6 Mthodes de recherche doffres de service . . . . . . . . . . . . . . . . . 152.3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Service de recherche de Salutation . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.1 Architecture de Salutation . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.1.1 Salutation Manager . . . . . . . . . . . . . . . . . . . . . . . 162.4.1.2 Services de courtage . . . . . . . . . . . . . . . . . . . . . . . 182.4.2 Units fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4.3 Structure des donnes au niveau de salutation . . . . . . . . . . . . . . . 192.4.4 Processus dimportation de services . . . . . . . . . . . . . . . . . . . . 202.4.5 API de Salutation Manager . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22iii2.5 Le service de recherche de UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.1 Prsentation de UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.2 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.3 UDDI : structure des donnes . . . . . . . . . . . . . . . . . . . . . . . 242.5.3.1 La structure de donnes businessEntity . . . . . . . . . . . . . 252.5.3.2 La structure de donnes businessService . . . . . . . . . . . . 262.5.3.3 La structure de donnes bindingTemplate . . . . . . . . . . . . 262.5.3.4 La structure de donnes tModel . . . . . . . . . . . . . . . . . 272.5.3.5 La structure de donnes publisherAssertion . . . . . . . . . . . 272.5.4 Interface de programmation UDDI . . . . . . . . . . . . . . . . . . . . . 272.5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.6 Etude comparative des services de recherche sur proprits . . . . . . . . . . . . 292.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Les applications base de composants 333.1 Limites des applications orientes objet . . . . . . . . . . . . . . . . . . . . . . 333.2 Modles de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3 Le modle de composants CCM (Corba Component Model) . . . . . . . . . . . 353.3.1 Le modle abstrait de composants de lOMG . . . . . . . . . . . . . . . 363.3.2 Les maisons de composants . . . . . . . . . . . . . . . . . . . . . . . . 363.3.3 Le modle de programmation . . . . . . . . . . . . . . . . . . . . . . . 363.3.4 Le modle dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.5 Le modle de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.5.1 Etapes de production et de dploiement des applications . . . . 373.3.5.2 Paquetages de composant . . . . . . . . . . . . . . . . . . . . 393.3.5.3 Descripteurs de composants . . . . . . . . . . . . . . . . . . . 393.3.5.4 Paquetage dassemblage de composants . . . . . . . . . . . . 393.3.5.5 Dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 Infrastructure gnrale de dploiement 414.1 Description de linfrastructure de dploiement . . . . . . . . . . . . . . . . . . . 414.1.1 Ressources et des tapes de dploiement . . . . . . . . . . . . . . . . . . 424.1.2 Les serveurs de paquetages . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.3 Les serveurs de composants (ou serveurs dexcution) . . . . . . . . . . 444.1.4 Le serveur de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . 454.1.4.1 Le descripteur de dploiement statique . . . . . . . . . . . . . 454.1.4.2 Descripteur de dploiement dynamique . . . . . . . . . . . . . 464.1.4.3 Descripteur de dploiement concret . . . . . . . . . . . . . . . 474.1.5 Le service de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1.5.1 Exportation de services . . . . . . . . . . . . . . . . . . . . . 484.1.5.2 Importation de services . . . . . . . . . . . . . . . . . . . . . 484.1.6 Le Client de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . 49iv4.1.6.1 Construction des requtes de recherche par le client de d-ploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.1.6.2 Construction dune requte de dploiement par le client de d-ploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2 Repliement ou terminaison du dploiement . . . . . . . . . . . . . . . . . . . . 514.3 Smantique du dploiement en cas dchec . . . . . . . . . . . . . . . . . . . . 514.3.1 Panne du serveur de dploiement . . . . . . . . . . . . . . . . . . . . . . 514.3.2 Panne de lun des serveurs de composants ou du serveur de recherche . . 534.3.3 Panne du serveur de recherche . . . . . . . . . . . . . . . . . . . . . . . 534.3.4 Panne du serveur de paquetages . . . . . . . . . . . . . . . . . . . . . . 534.3.5 Dconnexion de lutilisateur . . . . . . . . . . . . . . . . . . . . . . . . 544.3.6 Rutilisation de lapplication et caches utilisateur . . . . . . . . . . . . . 545 Conception du serveur de dploiement 575.1 Modlisation UML de linfrastruture de dploiement . . . . . . . . . . . . . . . 576 Conclusion 611vviTable des figures2.1 Fonctionnement du trader Corba . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Filtrage des offres par le trader Corba . . . . . . . . . . . . . . . . . . . . . . . 72.3 Graphe dhritage entre interfaces IDL du module Costrading . . . . . . . . . . . 92.4 Diffrentes tapes pour la connexion, lexportation et limportation de servicesau niveau du service de recherche Jini. . . . . . . . . . . . . . . . . . . . . . . . 122.5 Architecture gnrale de salutation. . . . . . . . . . . . . . . . . . . . . . . . . 172.6 Architecture dtaille de salutation. . . . . . . . . . . . . . . . . . . . . . . . . 172.7 Structure des donnes au niveau de salutation. . . . . . . . . . . . . . . . . . . . 192.8 Dcouverte et utilisation de service au niveau de salutation. . . . . . . . . . . . . 222.9 Ouverture et fermeture dune session de service au niveau de salutation. . . . . . 232.10 Structure des donnes UDDI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Etapes de production et de dploiement des applications. . . . . . . . . . . . . . 384.1 Infrastructure et tapes de dploiement . . . . . . . . . . . . . . . . . . . . . . . 445.1 Modle UML du dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2 Diagramme dvnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60viiviiiListe des tableaux2.1 API UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2 Comparaison des services de recherche sur proprits . . . . . . . . . . . . . . . 30ixxChapitre 1IntroductionLes systmes dinformation modernes sont de plus en plus installs sur des rseaux grandechelle. La mise en place de ces systmes sur un rseau tendu se base sur lutilisation dapplica-tions distribues complexes construites partir de composants logiciels autonomes et coopratifspouvant tre places sur de multiples serveurs distans.Par ailleurs, le progrs de linformatique mobile et des services rseau (rseaux sans fil, internet,...) ainsi que lvolution de la technologie des terminaux (PC portables, PDAs, tlphones mo-biles, ...) permettent aux utilisateurs daccder aux diffrents services quils demandent partirdendroits diffrents et des moments variables : un mme utilisateur, peut se connecter unemme application, le mme jour, de son travail en utilisant un PC, de sa voiture partir dunPDA ou de chez lui travers un ordinateur portable.1.1 ProblmatiqueLa mobilit et la variabilit denvironnements de connexions des utilisateurs, implique unevariabilit de lenvironnement dexcution des applications selon la localisation des utilisateurs,des dbits des moyens de communication, de capacit de terminaux utiliss notamment deprocesseur, mmoire, systme et langages supports, ...Cette variabilit de lenvironnement dexcution ncessite ladaptation de chaque application son contexte dutilisation (utiliser une interface graphique sadaptant la taille de lcran, nepas placer tous les composants de lapplication sur le terminal utilisateur sil nest pas assezpuissant, ...).Dautre part, linstallation manuelle des diffrents services sur chaque terminal partir duquellutilisateur veut se connecter est une tche rude. Il faut donc que ce genre dinstallation soitautomatique. Linstallation automatique des diffrents composants dune application sappelleun dploiement.11.2 Prsentation du sujetNotre objectif est de proposer une plate forme de dploiement pour que les applicationsdistribues, construites partir de composants logiciels autonomes et coopratifs puissent etreutilises dans un contexte mobile de manire plus simple, plus extensible et plus transparente.Une bauche de solution aux problmes cites au dessus a t propose, dans le projet Cesureen lan 2000 fait par Gemplus en association avec lINT, lINRIA et le LIFL. Seulement,cette solution se limitait une application bancaire et ne prsentait pas un vrai systme dedploiement.Il sagit donc de proposer une infrastructure de dploiement pour les applications multi-composants qui soit gnrale et qui permet de chercher dune manire dynamique les diffrentscomposants dune application ainsi que les diffrents serveurs sur lesquels sexcuteront cescomposants tout en assurant une adaptation au contexte utilisateur.Dans le premier chapitre, nous ferons une tude comparative des services de recherche intel-ligents. Ces outils, permettent une recherche de services sur le rseau partir de ses diffrentesproprits. Cette spcificit leur permet dtre un lment esssentiel dans notre infrastructure, quipermettra de dterminer les diffrents composants dune application en sadaptant au contextedutilisation. Le deuxime chapitre prsente une tude des applications multi-composants et dudploiement travers le modle CCM (Corba Coponent Model). Dans le troisime chapitre, nousdcrivons linfrastructure de dploiement que nous proposons tout en dfinissant une smantiquedu dploiement en cas dchec. Enfin, le quatrime chapitre prsente un modle UML pour ledploiement et une description IDL (Interface Definition Language) de linterface du serveur dedploiement.2Chapitre 2Etude comparative des services derecherche sur propritsIl existe plusieurs manires de rechercher un objet. La recherche dun objet partir dun nomsymbolique (exemple : URL) peut tre suffisante lorsque le client connat exactement ce quilcherche. Ce genre de recherche peut tre compar la recherche dans des pages blanches oil faut connatre le nom de la personne recherche pour pouvoir trouver son numro de tlphone.Souvent, les clients ont besoin dun mcanisme plus dynamique pour localiser des objets. Parexemple, un client peut avoir juste une ide du type dobjet dont il a besoin mais pas toutes lesinformations quil faut pour faire un choix prcis. Les services de recherche sur proprits offrentdes fonctionnalits permettant des clients de localiser des objets partir de leurs proprits. Cegenre de service ne stocke pas les noms des objets mais une description dtaille des objets. Lesclients peuvent alors bnficier dune recherche dynamique des services base sur des requtes travers les descriptions du service. Ce type de recherche peut tre compar des pages jaunes.Au lieu de lister les services par leur nom, les pages jaunes catgorisent les entres par sujet etdcrivent chaque entre avec dtails.La recherche sur proprits joue un rle essentiel dans le dploiment des applications multi-composants puisquelle permet la recherche des diffrents composants dune application de ma-nire quelle sadapte le mieux lenvironnement dexcution.Dans ce chapitre, nous allons tudier quatre services de recherche sur proprits : le trader deCorba, le service de recherche de jini, le service de recherche de Salutation et le service derecherche de UDDI. Nous essayerons de donner assez de dtails sur chacun deux afin que lelecteur puisse comprendre leur principe de fonctionnement ainsi que leurs points forts et leurspoints faibles. Le chapitre se terminera par une comparaison des quatres services de recherchetudis.32.1 Concepts de courtage et terminologieLe service de recherche sur proprits appel aussi service de courtage, service de trading,service de vente ou service de mdiation est un service permettant de dcouvrir dynami-quement les services offerts. Il facilite donc lannonce et la dcouverte des services. Quand unserveur dsire annoncer (ou publier) son service, il enregistre son offre de service auprs du ser-vice de courtage : cest lopration dexportation. Le programme qui publie un service sappelleexportateur. Lorsquun client requiert un service, il met une requte de recherche au service decourtage en spcifiant quelques caractristiques de ce service : cest lopration dimportation etle programme qui leffectue sappelle importateur.Le service de recherche enregistre les publications de services. Ces publications sappellent desoffres de service.2.2 Trader CORBALe besoin dutiliser des pages jaunes dans lenvironnement Corba a donn naissance unservice de courtage propre CORBA. Le principe de fonctionnement de ce service peut se rsu-mer comme suit : Une application serveur va exporter vers le trader la description et la rfrencedun objet qui lui est propre. Les applications clientes dsirant utiliser cet objet interrogeront letrader en fournissant des critres de slection. Une fois que lapplication aura la rfrence surlobjet demand comme rsultat, elle pourra lutiliser travers le bus CORBA [GGM97] (voirfigure 2.1).FIG. 2.1 Fonctionnement du trader Corba42.2.1 Types de servicesLes services offerts sont dcrits sur un rseau dune manire abstraite au niveau du trader laide dune structure appele type de service. Les types de services peuvent tre comparsaux catgories des pages jaunes. La recherche dun htel dans les pages jaunes, par exemple,suppose quil y ait un certain nombre dinformations communes tous les htels comme unnom, un numro de tlphone, une adresse, un prix pour une nuit dans une chambre, le typede service dune offre reprsente les types dinformations quun importateur peut utiliser pourrechercher un service au niveau du trader ou dune autre manire le type de service dtermineles proprits utilises pour dcrire une offre de service. Les types de service sont organissdune manire hirarchique selon un arbre dhritage.Le ServiceTypeRepository joue le rle de dpositaire de stockage des types doffres deservices et assure la vrification du typage lors de lexcution des requtes dexportationet de recherche. Dans ce dpositaire, un type doffres de services est caractris par quatrelments[OMG00]. Un nom unique identifiant le type de service. Des super types hrits permettant de dfinir une classification des types par hritage mul-tiple. Une interface OMG IDL laquelle les services exports doivent se conformer. 0 ou plusieurs types de proprits dfinissant laspect comportemental du service.Le type de proprit est un triplet . Le mode indique si la proprit estoptionnelle ou obligatoire lors de lenregistrement dune offre de service de ce type et si ellepeut changer de valeur aprs la publication de loffre. Les modes de proprits sont les suivants : normal : la valeur de la proprit est optionnelle, elle peut tre modifie ou supprime. readonly : idem normal mais si la valeur de la proprit est fournie lexportation alorselle ne peut plus tre modifie. mandatory : une valeur doit obligatoirement tre affecte la proprit lors de lexporta-tion. mandatory readonly : idem mandatory mais non modifiable.Linterface ServiceTypeRepository [OMG00] offre plusieurs opration pour grer les diff-rents types de service : lopration add_type permet dajouter un type de service. La modificationet la suppression dun type se font respectivement par les oprations modify_type et remove_type(voir dtails dans la section 2.2.6 ).2.2.2 Exportation de services auprs du traderTout objet CORBA peut tre export au niveau du service de recherche sur proprits sousforme dune offre de service. Une offre de service permet dassocier, pour un type de service5donn, la rfrence de lobjet CORBA avec les valeurs de proprits qui le caractrisent (toutesles proprits obligatoires et certaines optionnelles)[HV99].Chaque offre de service a un identifiant unique renvoy lexportateur par le trader lors dunedemande de publication. Il permet lexportateur de modifier ou retirer loffre.Lexportation de service se fait grce linterface Register (voir dtails dans la section 2.2.6 ).2.2.3 Importation de services et langage de contraintesPour importer un service quelconque sur le rseau, un importateur envoie une requte vers letrader contenant :1. Le nom du type de service. Exemple : htel.2. Des contraintes sur le service recherch.Dans notre exemple, ces contraintes dterminerontquels htels particuliers lutilisateur cherche.Il peut par exemple chercher un htel dont lenombre dtoiles est suprieur deux et ayant une piscine.3. Des prfrences dfinissant un ordre dans lequel seront retourns les rsultats.4. Des politiques contrlant des aspects non fonctionnels de recherche tels que le nombredoffres retournes et sil sagit de retourner la description complte dun service ou seule-ment la rfrence sur lobjet.Limportation de service se fait grce linterface Lookup dtaille dans la section 2.2.6.La slection doffres de service se fait par une rduction de lensemble doffres offerts par lesdiffrents traders par des politiques de recherches dfinies au niveau de chaque trader. Cet espacedoffres est alors filtr par le type de service demand et une expression de contraintes. Les offresslectionnes par le filtre sont ensuite ordonnes par une expression de prfrences (voir figure2.2 ).Les contraintes et les prfrences sont exprimes laide dun langage de contraintes appelOCL (OMG Constraint Language). Elles sont construites partir de noms de proprits duntype de service, des valeurs prises par ces proprits et des oprateurs logiques, comparatifs,mathmatiques et dexistence.2.2.4 Fdration du service de rechercheLa fdration des traders permet laccs un grand nombre doffres de services sans avoirbesoin denregistrer toutes les offres sur un seul trader. La fdration de recherche doffres esttransparente par rapport aux utilisateurs. Un trader fdr est vu par un utilisateur comme unseul trader logique.Les traders fdrs sont relis entre eux travers un graphe orient. Chaque trader a desinformations sur ce graphe. Les liens reprsentent des chemins de propagation des requtes duntrader source vers un trader destination. Chaque lien reprsente un arc dans le graphe de tradingdont les sommets reprsentent des traders. Un lien dcrit les connaissances quun trader a dunautre service de courtage quil utilise et des informations sur le moment o il faut envoyer une6FIG. 2.2 Filtrage des offres par le trader Corbaopration vers le trader cible[OMG00].Les traders sont fdrs de manire quun trader agissant comme un client pour un autretrader. Supposons par exemple quun client envoie une requte vers un trader A. Le trader A faitdes recherches au niveau de sa base de donnes mais fait suivre aussi la requte vers son traderfdr B. Le trader B retournera ses rsultats vers A qui les mergera ses propres rsultats etretournera les rsultats finaux vers lutilisateur.La topologie de la fdration des traders peut tre complexe et peut parfois contenir desboucles. La spcification de lOMG [OMG00] demande aux traders fdrs dimplmenter ladtection de boucles de manire ce que les requtes partant dun client ne soient pas transmisesdun trader vers un autre indfiniment.2.2.5 Proprits dynamiquesGnralement, une proprit dune offre de service a une valeur fixe enregistre parlexportateur. Cette valeur ne change pas sauf si quelquun la modifie explicitement. Ce genrede proprits statiques nest pas adquat pour certains types de services. Par exemple pourla recherche dactions dans la bourse, le prix dune action subit des fluctuations rapides.Lutilisation de proprits statiques demande la mise jour frquente de la proprit prix delaction.7Pour accommoder ce genre de situations, les traders offrent la possibilit dutiliser desproprits dynamiques. Les valeurs de ces proprits ne rsident pas dans le trader, ellesseront values la demande lors dune recherche travers un objet dvaluation de propritsdynamiques dsign par lexportateur.La structure dune proprit dynamique contient linterface de lvaluateur dynamique deproprits, le type de donnes des proprits dynamiques retournes et des informations sup-plmentaires dimplmentation[HV99]. Quand la valeur dune proprit est demande, le traderinvoque la mthode evalDP partir de linterface Dynamic_PropEval (voir section 2.2.6).2.2.6 API traderLe trader CORBA offre onze interfaces faisant partie du module Costrading. Ces interfacespermettent limportation et lexportation de services, lexportation de proxies doffres de ser-vices, la modification de la structure de la fdration et la configuration du trader.2.2.6.1 Les interfaces dutilisationLa structure IDL du module Costrading est donne dans la spcification de lOMG [OMG00].Cette structure dfinit quatre interfaces abstraites de base ayant comme tche de regrouper lesfonctionnalits relies utilises par dautres interfaces.Ces interfaces abstraites sont : ImportAttributes, TraderComponents, SupportAttributes et Lin-kAttributes. Le graphe dhritage entre interfaces IDL est reprsent sur la figure 2.3 [HV99].Les interfaces les plus importantes sont les suivantes :Linterface lookup : cette interface permet limportation de services. Elle noffre que lopra-tion query permettant aux importateurs de rechercher des objets. Lutilisation dune telleopration ncessite six paramtres.1. Le nom du type de service.2. Des contraintes qui doivent tre satisfaites par les proprits des offres de servicesrecherches.3. Des prfrences dfinissant un ordre pour les services retourns.4. Les stratgies appliquer le long de la recherche.5. La liste des noms de proprits (exemple : aucune, toutes, certaines) dont les valeursdevront tre retournes lapplication cliente.6. Le nombre maximal de rponses dsir.Si le nombre de rponses dpasse le nombre maximal spcifi, un itrateur sera retournafin que le client puisse parcourir le reste de la liste.8FIG. 2.3 Graphe dhritage entre interfaces IDL du module Costrading9Linterface register : cette interface permet aux diffrentes applications distribues de publierleurs services et de mettre jour le contenu du dpositaire du service de courtage. Lapublication dun service (enregistrement dun service au niveau du service de courtage) sefait laide de lopration export ncessitant les paramtres suivants :1. Le nom du type de service,2. Une rfrence linterface qui offre le service,3. Des valeurs pour les proprits du service.Il est possible de modifier une description dun service avec lopration modify ou suppri-mer des services du dpositaire avec lopration withdraw.Linterface OfferIterator : cette interface permet le parcours des rsultats de recherche quinont pas pu tre stocks dans la squence IDL.Linterface Link : cette interface permet de constituer une fdration de services de recherche.La connexion entre les traders se fait grce lopration add_link. La modification et leretrait de liens se font respectivement laide des oprations modify_link et remove_link.Linterface DynamicPropEval : cette interface permet de calculer, lexcution, la valeur cou-rante dune proprit dynamique au travers de lopration EvalDP.Linterface proxy : cette interface permet de dterminer la rfrence relle dun objet offrantun service. Cette interface est utilise, par exemple, pour trouver un objet (rpondant auxcritres demands) dans un ensemble dobjets potentiels (par exemple sil y a quilibragede charge)[GGM97].2.2.6.2 Les interfaces dadministrationLes interfaces dadministration sont au nombre de deux et permettent de contrler le fonc-tionnement du service de courtage et manipuler le rfrentiel des types de service.Linterface ServiceTypeRepository : permet de grer le dpositaire des types de services.Lopration add_type permet dajouter un type.La modification et la suppression dun type se fait respectivement par les oprations mo-dify_type et remove_type.Linterface Admin [OMG00] : cette interface permet de faire ladministration proprement dite :elle permet de dfinir le nombre maximum de rponses retournes lors dune recherche,des politiques de recherche tel que le nombre de traders pouvant tre parcourus partir decelui-ci, etc. Lorsquune requte est lance vers un trader, ce sont les paramtres par dfautqui seront utiliss. Tous ces paramtres peuvent tre surchargs dans une requte.2.2.7 ConclusionEnfin, comme conclusion pour cette section, Le service de recherche de Corba, prsenteune multitude de points forts. Il se distigue particulirement par sa fdration de recherche, sonutiliation dun language de contraintes et de la notion de type de service. Il permet aussi aux10utilisateurs de spcifiers des politiques de recherche et de dfinir des proprits dynamiques.Seulement, ce service nest pas simple utiliser et lutilisation de son API ncessite lcriture debeaucoup de lignes de code.2.3 Service de recherche de JiniJini est un systme distribu bas sur lide de la fdration de groupes et des ressources.Le but dun tel systme est doffrir un outil flexible et facilement administr qui permet auxapplications clientes de retrouver les diffrentes ressources du rseau dune manire dynamique.Ces ressources peuvent tre matrielles, logicielles ou une combinaison des deux.Jini tend lenvironnement dune application java dune seule machine virtuelle vers un rseaude machines locales. Ce rseau peut mme tre un rseau domestique connectant des tlviseurs,des rfrigrateurs, des chaines stro, ...Jini offre des mcanismes pour la construction de services, leur recherche, leur communica-tion et leur utilisation dans un systme distribu.Dans le cadre de ce stage, nous ne nous sommes intresss qu la recherche des services.Le service de recherche Jini est bas sur un trio de protocoles appels : dcouverte, jointe etrecherche. La paire de protocoles dcouverte et jointe se produit au moment o un service vientdtre implant dans le rseau. La dcouverte a lieu lorsquun service est en qute dun service de recherche auprs duquelsenregistrer. La jointe a lieu au moment o le service de recherche est localis et que le service veut syenregistrer. La recherche a lieu lorsquune application cliente a besoin de localiser et invoquer unservice dcrit par son type dinterface crite en Java et un ensemble dattributs.La paire dcouverte/jointe est le processus permettant lajout dun service au systme Jini.2.3.1 Vue gnrale sur le modle du service de recherche de JiniLe service de recherche maintient une collection plate darticles dcrivant des services.Chaque article reprsente une instance dun service disponible au niveau de Jini [JIN01a]. Unarticle contient un stub RMI (si le service est implment comme un service distant) ou un autreobjet que les programmes utilisent pour accder au service (si le service utilise un proxy local)ainsi quune collection extensible dattributs dcrivant le service.Ds quun nouveau service est cr, le service senregistre au niveau du service de recherche deJini avec un ensemble initial dattributs.Les programmes ayant besoin dun type de service particulier peuvent utiliser le servicede recherche pour trouver une instance de ce service. une correspondance peut tre faite en sebasant sur des types de donnes spcifiques implments par le service ainsi que les attributs11spcifiques attachs au service. Par exemple, un programme qui a besoin dutiliser des transac-tions peut chercher un service supportant le type net.jini.transaction.server.TransactionManager.Une grande varit de vues hirarchiques peut tre impose la collection des articles deservices plate en faisant des agrgats dattributs selon les types de services.Le service de recherche offre un ensemble de mthodes permettant une exploration de lacollection. Une varit dinterfaces utilisateur peut tre construite en utilisant ces mthodespermettant aux utilisateurs et administrateurs la navigation. Une fois quun service est trouv,lutilisateur peut interagir avec le service en tlchargeant une applet " interface utilisateur "attache comme un autre attribut larticle de service.La figure 2.4 illustre le fonctionnement de la recherche de services dans le systme jini.Les diffrentes tapes de connexion au service de recherche, dimportation et dexportation deservices prsentes sur la figure, vont tre expliques en dtail dans ce qui suit.FIG. 2.4 Diffrentes tapes pour la connexion, lexportation et limportation de services auniveau du service de recherche Jini.122.3.2 Connexion au service de rechercheUn exportateur ou un importateur dans jini commence par chercher un service de rechercheauprs duquel il exportera ou cherchera importer des services. Ceci est ralis travers unmulticast de requtes (tape 1 de la figure 2.4) et une coute de rponses travers le rseaulocal (tape 2 de la figure 2.4) pour sidentifier auprs dun service de recherche quelconque.Tous les services de recherche de proximit fournissent une rponse ces entits appelantes sousforme dobjet de recherche (tape 3 de la figure 2.4). Dans le cas o il y a plusieurs servicesde recherche dans le rseau, ces objets seront mis dans un tableau et seront placs au niveaude lappelant (exportateur ou un importateur) pour jouer le rle de proxy pour le service derecherche. Si on veut que linvocation des services de recherche se fasse distance, au lieu delobjet proxy, un stub RMI sera plac au niveau de lexportateur ou limportateur.Les objets proxy de recherche reprsentent une instance de linterface ServiceRegistrar sui-vante :public interface ServiceRegistrar {ServiceRegistration register(ServiceItem item,long leaseDuration)throws RemoteException;Object lookup(ServiceTemplate tmpl)throws RemoteException;ServiceMatcheslookup(ServiceTemplate tmpl, int maxMatches)throws RemoteException;EventRegistration notify(ServiceTemplate tmpl,int transitions,RemoteEventListener listener,MarshalledObject handback,long leaseDuration)throws RemoteException;Class[] getEntryClasses(ServiceTemplate tmpl)throws RemoteException;Object[] getFieldValues(ServiceTemplate tmpl,int setIndex,String field)throws NoSuchFieldException, RemoteException;Class[] getServiceTypes(ServiceTemplate tmpl,String prefix)throws RemoteException;ServiceID getServiceID();LookupLocator getLocator() throws RemoteException;String[] getGroups() throws RemoteException;}ServiceRegistrar dfinit linterface du service de recherche. Cette interface nest pas dis-tante ; chaque implmentation du service de recherche, exporte des objets proxy, locaux au ni-veau client, qui implmentent linterface ServiceRegistrar utilisant un protocole spcifique pourcommuniquer avec le serveur. Les mthodes offertes par cette interface permettent essentielle-ment denregistrer les services (register), les rechercher (lookup) et recevoir des vnements de13notification (notify) lorsquun service est modifi.ServiceRegistrar offre aussi des mthodes pour explorer les diffrents services selon trois axesmajeurs : par type de service, par valeurs dattributs et par classes dattributs.La mthode register est utilise pour enregistrer un nouveau service. Un service enregistr,est manipul laide dune instance de linterface ServiceRegistration suivante :public interface ServiceRegistration {ServiceID getServiceID();Lease getLease();void addAttributes(Entry[] attrSets)throws UnknownLeaseException, RemoteException;void modifyAttributes(Entry[] attrSetTemplates,Entry[] attrSets)throws UnknownLeaseException, RemoteException;void setAttributes(Entry[] attrSets)throws UnknownLeaseException, RemoteException;}La mthode getServiceID retourne lidentifiant du service.La mthode addAttributes rajoute lensemble des attributs spcifis en paramtre au service en-registr.La mthode modifyAttributes sert modifier lensemble des attributs existants ; Chaque valeurdattribut se trouvant dans le tableau attrSetTemplates sera remplace par la valeur dattributayant le mme indice dans le tableau attrSets.La mthode setAttributes efface tous les attributs dun service et les remplace par lensembledattributs spcifis.2.3.3 Exportation de services auprs dun service de rechercheUne fois quun exportateur a identifi le service de recherche de proximit, il peut sy enre-gistrer en invoquant la mthode register du proxy de recherche en lui passant comme paramtresune copie de linterface du service quil offre et un tableau dattributs dcrivant le service (tape4 de la figure 2.4). Cette tape copie lobjet de service et les attributs au niveau du service derecherche.2.3.4 Importation de services auprs dun service de rechercheUne fois quun importateur a identifi et sest connect au service de recherche de proximit,il peut faire des recherche en invoquant la mthode lookup du proxy de recherche en lui passantcomme paramtres le type (linterface) du service recherch et un tableau de valeurs dattributs(tape 5 de la figure 2.4).Le service de recherche enverra un ensemble de rsultats parmi lesquels limportateur fait unchoix (tapes 6 et 7 de la figure 2.4). Une fois le choix de lutilisateur sest fix sur un service,le service de recherche copiera lobjet de service au niveau de limportateur (tape 9 de la figure2.4) ce qui lui permettera une communication directe avec le service demand (tape 10 de lafigure 2.4).142.3.5 Structure des donnes enregistrs au niveau du service de rechercheLes services sont enregistrs au niveau du service de recherche sous forme dune instance dela classe ServiceItem (article de service) suivante :public class ServiceItem implements Serializable {public ServiceItem(ServiceID serviceID,Object service,Entry[] attributeSets) {...}public ServiceID serviceID;public Object service;public Entry[] attributeSets;}Chaque service est assign un identifiant universel unique (UUID).En plus de son identifiant, un service est caractris par une interface et un ensemble d attributs.Les attributs dun service sont reprsents comme un tableau densemble dattributs. Un en-semble dattribut est reprsent comme une instance dune classe Java o chaque attribut est unchamp public de cette classe. La classe offre un typage fort des attributs.Un article de service peut contenir plusieurs instances de classes diffrentes dattributs ou dela mme classe avec des valeurs dattributs diffrentes. Par exemple, un article peut avoir plu-sieurs instances de la classe " Nom ", chacune donnant un nom au service dans un langagediffrent, une instance de la classe " localisation " et dune classe " Propritaire ". Dune manireplus concrte un ensemble dattributs est implment avec une classe implmentant linterfacenet.jini.core.entry.Entry[JIN01b]2.3.6 Mthodes de recherche doffres de serviceLes articles de services dans le service de recherche sont apparis en utilisant des instancesde la classe ServiceTemplate.public class ServiceTemplate implements Serializable {public ServiceTemplate(ServiceID serviceID,Class[] serviceTypes,Entry[] attributeSetTemplates) {...}public ServiceID serviceID;public Class[] serviceTypes;public Entry[] attributeSetTemplates;}Un article de service (item) correspond un patron de service (tmpl) si : item.serviceID est gal tmpl.serviceID (ou si tmpl.serviceID est null), et item.service est une instance de chaque type dans tmpl.serviceTypes, et item.attributeSets contient au moins une entre gale son entre homologue dans tmpl.AttributeSetTemplates.Une entre correspond un calque dentre si la classe du calque est la mme ou une su-per classe de la classe de lentre et chaque champ non vide dans le calque est gal au champcorrespondant dans lentre.152.3.7 ConclusionLe plus grand avantage du service de recherche de Jini se situe dans le fait que la connexion ce service se fait dune manire dynamique : aucune application nest relie par dfaut un ser-vice de recherche. Toute application voulant enregistrer ou rechercher des services doit commen-cer par rechercher un service de recherche auquel elle peut se connecter. Seulement, le servicede recherche Jini se limite la recherche de services de proximit.2.4 Service de recherche de Salutation" Salutation " a t conu pour rsoudre les problmes de dcouverte de services et leursutilisation travers un large ensemble dapplications et quipements dans un environnementtendu de connectivit et mobilit. Larchitecture de " Salutation " est conue de manire treindpendante du processeur, du Systme dexploitation et des protocoles de communication. "Salutation" offre des mthodes standards pour les applications afin dexporter les services quilsoffrent, importer les services dont ils ont besoin et tablir une session interoprable avec lesapplications offrant ces services [Sal01].2.4.1 Architecture de Salutation2.4.1.1 Salutation ManagerLarchitecture de " Salutation " est construite autour dune entit midleware appele " Saluta-tion Manager " (SLM) qui joue le rle dun courtier pour les diffrentes applications. SalutationManager permet aux applications de dcouvrir et utiliser les services offerts par dautres appli-cations.Comme le montre la figure 2.5, chaque entit sur le rseau doit tre relie au maximum un Salutation Manager qui peut tre plac localement sur lentit elle mme ou sur une entitdistante (dans ce cas Salutation Manager est invoqu distance travers du RPC).Salutation Manager communique avec dautres Salutation Managers pour assurer son rle decourtier en utilisant un protocole de communication qui lui est propre. Ce protocole utilise leRPC version 2 de Sun Microsystems.Salutation Manager offre deux interfaces indpendantes des couches basses du rseau (Cf. fi-gure 2.6) :1. Une API appele " Salutation Manager API " (SLM-API) permettant aux importateurs etexportateurs la publication et la recherche de services.2. Une interface maintenant une sparation avec les couches basses du rseau appele " Sa-lutation Manager Transport Interface " (SLM-TI) utilise par les entits dpendantes descouches rseau appels Transport Managers (TM ).16FIG. 2.5 Architecture gnrale de salutation.FIG. 2.6 Architecture dtaille de salutation.17SLM-API et SLM-TI assurent tous les deux le rle de courtage.Chaque Salutation Manager a un identificateur universel unique (SLM-ID) qui lidentifieauprs des importateurs, exportateurs et Salutation Managers.Un Salutation Manager travaille avec un ou plusieurs Transport Managers. Chaque TransportManager dcouvre dautres Salutation Managers distants connects aux rseaux quil supporte.Le Transport Manager rcupre lidentificateur unique de chaque Salutation Manager distantdcouvert et lenregistre avec lidentificateur du Salutation Manager local et maintient lassocia-tion entre ces identificateurs et leurs adresses rseaux.Les Transport Managers peuvent dcouvrir les Salutation Manager de diffrentes manires : Les transport Managers peuvent avoir des tables statiques contenant les adresses rseaudes Salutation Manager distants. Le Transport Manager fait un broadcast de requtes pour trouver dautres Salutation Ma-nager distants.2.4.1.2 Services de courtagePour assurer sa fonction de courtier, Salutation Manager offre trois services de courtage :Base de registres : Le " Salutation Manager " comporte une base de registres pour enregistrerdes informations sur les services connects au Salutation Manager localement ou dis-tance. Ce rfrentiel peut aussi contenir des informations sur les services enregistrs dansdautres Salutation Managers.La Dcouverte de services : La dcouverte de services par un Salutation Manager se fait endcouvrant dautres Salutation Managers distants et en dterminant les services qui y sontenregistrs. Une comparaison est faite entre les types de services requis par le SalutationManager local et les types de services disponibles au niveau du Salutation Manager distant.La transmission des types de services requis partir du Salutation Manager local vers leSalutation Manager distant et la transmission de rponses du Salutation Manager distantvers le Salutation Manager local se fait travers du RPC.Selon les demandes dun importateur, Salutation Manager peut dterminer : Les caractristiques de tous les services enregistrs dans les Salutation Managers dis-tants. Les caractristiques dun service spcifique enregistr dans les Salutation Manager dis-tants. La prsence dun service vrifiant un ensemble de caractristiques spcifiques dans lesSalutation Managers distants.La Disponibilit de service : Salutation Manager peut vrifier priodiquement la disponibilitdun service avec le Salutation Manager auquel il est li en changeant des messages RPC.182.4.2 Units fonctionnellesUne unit fonctionnelle est une reprsentation abstraite des fonctions offertes par une applica-tion . Par exemple, une fonction qui imprime des documents peut dfinir une unit fonctionnellequon note [print]. A chaque unit fonctionnelle est associ un ensemble dattributs. Par exemple,lunit fonctionnelle [print] a comme attributs la taille du papier pouvant tre utilis, densit despixels, couleurs,...Larchitecture de " Salutation " dfinit une syntaxe et une smantique pour dcrire les attributs dechaque unit fonctionnelle appele " enregistrement de description dunit fonctionnelle " dcritsdans la section suivante.2.4.3 Structure des donnes au niveau de salutationUne entit qui a plusieurs fonctions sur le rseau, contient une multitude dunits fonction-nelles. Lensemble de ses units fonctionnelles forme un service qui est dcrit par un enregis-trement de description de services. Un enregistrement de description de services est donc unecollection denregistrements de description dunits fonctionnelles. Les enregistrements de des-cription dunits fonctionnelles sont eux mme composs denregistrements contenant les va-leurs dattributs dcrivant les units fonctionnelles.La figure 2.7 dcrit la structure des diffrents enregistrements.FIG. 2.7 Structure des donnes au niveau de salutation.Pour pouvoir dcrire les diffrents services exports et imports sur le rseau, trois typesdenregistrements sont dfinis : Enregistrement de description de services (SDR : Service Description Record) Enregistrement de description de lunit fonctionnelle (FUDR : Functional Unit Des-cription Record) : consiste en un champ entte contenant lidentificateur de lunitfonctionnelle, exemple [Scan] et une clef suivi par zro ou plusieurs enregistrements19dattributs.Les requetes et les rponses pour la recherche de services sont changes sous forme deSDRs et FUDRs. Enregistrement dattribut : cet enregistrement comporte un identificateur dattributidentifiant le type dattribut.Dans le cas o lattribut se trouve dans un FUDR enregistr sur la base des registres dunSalutation Manager ou un FUDR reprsentant une requte, le champ suivant lidentifica-teur du type dattribut sera un identificateur dune fonction de comparaison dattributs.Mais dans le cas o lattribut se trouve dans un FUDR rponse (voir section 2.4.4), lechamp suivant sera le rsultat de la comparaison entre les deux attributs enregistrs etcelui de la requte.Les formats de lenregistrement de description de service, de lenregistrement de descriptionde lunit fonctionnelle et des enregistrements dattributs sont spcifis laide dune syntaxeabstraite dfinie par lISO 8824.Il existe trois classes denregistrements de description de services : Les enregistrements de description de services enregistrs sur un Salutation Managerdonn. Les enregistrements de description de services demands reprsentant les requtes utilisa-teurs. Les enregistrements de description de services Rponses reprsentant des rponses desrequtes de recherche.La fonction de ces trois classes sera mieux explique dans la section 2.4.42.4.4 Processus dimportation de servicesLapplication cliente construit un ou plusieurs enregistrements de description dunits fonc-tionnelles englobants les diffrentes fonctions dont il a besoin et lenvoie au Salutation Manager qui elle est relie. Par exemple, si lapplication cherche un simple service de FAX sansaucune particularit, elle enverra un simple enregistrement de description dunit fonctionnellequi est [FAX] sans aucune proprit. Par contre, si lapplication a besoin dun appareil ayantplusieurs fonctionnalits tels que l impression, le fax et le scannage, plusieurs enregistrements dedescription dunits fonctionnelles doivent tre rassembls en un enregistrement de descriptionde service.Le salutation Manager de lapplication cliente fait des recherches locales et distantes en en-voyant lenregistrement de description de service reu vers d autres Salutations Managers. Cetterecherche consiste en une comparaison entre le FUDR envoy et celui enregistr dans la base deregistres du Salutation Manager. Sil sagit du mme type dunit fonctionnelle, il comparera lestypes et les valeurs des attributs.Si la comparaison aboutit un rsultat positif, le Salutation Manager construit un nouveau FUDRreprsentant lunion entre le FUDR envoy et celui enregistr. Ce nouveau FUDR est appel20FUDR de comparaison et est renvoy lapplication cliente comme rsultat.Si la comparaison choue, un FUDR vide est retourn lapplication cliente.2.4.5 API de Salutation ManagerGrce lAPI de Salutation Manager [Sal01], les applications peuvent sinscrire pourcommuniquer entre elles travers le protocole de Salutation Manager indpendamment de lacouche rseau. Cette API offre les fonctions suivantes (Cf. figures 2.8 et 2.9) :Enregistrement de service : lentit qui offre le service appelle slmRegisterCapability() ouslmUnregisterCapability() pour senregistrer ou seffacer au niveau de Salutation Managerlocal comme une unit fonctionnelle.Dcouverte de service : un client appelle slmSearchCapability() pour demander au SalutationManager local de chercher des Salutations Managers contenant des units fonctionnellesoffrants certaines capacits. Le Salutation Manager local retourne au client, la liste desidentificateurs de Salutation Managers contenant une unit fonctionnelle offrant le servicedemand par le client. Si le client ne spcifie aucune capacit particulire en appelantslmSearchCapability(), la liste retourne, contiendra tous les identificateurs des SalutationManagers connus. Le client peut appeler aussi slmQueryCapability() pour dcouvrirquelles units fonctionnelles sont enregistres ainsi que leurs capacits sur le SalutationManager spcifi par le client.Utilisation de service : un client peut appeler slmOpenService pour demander au SalutationManager local dinitier une session de service avec une unit fonctionnelle spcifiqueenregistre au niveau du Salutation Manager Local ou dun autre distant.Le salutation Manager au niveau duquel lunit fonctionnelle spcifie est enregistre,appelle la fonction fnOpenService() pour notifier lunit fonctionnelle de cette demandedouverture de service. Lunit fonctionnelle peut accepter ou rejeter la demande.Le rsultat est renvoy au client travers le paramtre de retour de slmOpenService().Une fois la session de service tablie, le client appelle slmTransferData() pour que leSalutation Manager local puisse envoyer des donnes lautre bout de la session ouverte.Le Salutation Manager se trouvant lautre bout, appelle la fonction fnReceiveData(),pour indiquer que les donnes sont bien reues.Le client et lunit fonctionnelle refont le processus de transfert de donnes autant de foisquil faut.Une fois le transfert termin, le client appelle slmCloseService() pour demander auSalutation Manager local de fermer la session de service. Dans ce cas, le SalutationManager distant appelle la fonction fnCloseService() pour notifier pour la fermeture desession.21Vrification de disponibilit : lunit fonctionnelle peut appeler slmStartAvailabilityCheckpour demander au Salutation Manager local de vrifier priodiquement si une unitfonctionnelle spcifique enregistre au niveau du Salutation Manager local ou distant estencore enregistre et tourne.Si Salutation Manager trouve que lunit fonctionnelle spcifie nest plus disponible, ilappelle la fonction fnNotifyFUUnvailability(). Lunit fonctionnelle appelle slmCancelA-vailabilityCheck() lorsque la vrification de disponibilit nest plus ncessaire.Autres : Le client peut appeler slmGetVersion() pour avoir le numro de version de lAPI duSalutation Manager. Il peut aussi appeler slmGetLocalSLMID() pour avoir lidentifiant duSalutation Manager local ou appeler slmGetSLMIDbyAddr() pour avoir lidentifiant deSalutation Manager local sous forme de son adresse rseau.FIG. 2.8 Dcouverte et utilisation de service au niveau de salutation.2.4.6 ConclusionSalutation se distingue par une API compltement indpendante des couches infrieures durseau et par un protocole de communication qui lui est propre. Mais ce service de recherche est,comme Jini, limit la racherche de services de proximit.22FIG. 2.9 Ouverture et fermeture dune session de service au niveau de salutation.2.5 Le service de recherche de UDDI2.5.1 Prsentation de UDDIUDDI (Universal Description, Discovery & Integration) est un projet industriel qui a t lancen Septembre 2000 par Ariba, IBM, Microsoft et trente trois autres compagnies. Aujourdhui,le consortium UDDI compte plus de 200 membres. UDDI est le nom dun groupe de bases deregistres web exposant des informations sur des affaires, des entreprises des vendeurs...[udd01]Le but principal de UDDI est de faciliter lintgration B to B 1 et offrir des mcanismes per-mettant de dcouvrir les interfaces de programmations (APIs) offertes par une entreprise pourinteragir avec les autres travers le commerce lectronique.Les informations quune entreprise peut enregistrer dans la base des registres sont des informa-tions sur son nom, des contacts, des codes industriels, des classifications de produits, des URLs,lensemble des services offerts ainsi que des informations sur leurs interfaces techniques et leursfonctionnements.2.5.2 ExempleSupposons que lentreprise X expose un service de facturation Web afin que les fournisseursde lentreprise puissent envoyer des factures lectroniques. De la mme manire, un vendeur V1Business to Business23peut offrir un service Web permettant denvoyer des commandes dune manire lectronique. Silentreprise X, veut acheter des quipements informatiques travers le web, elle cherchera tousles vendeurs dquipements informatiques sur le web en utilisant UDDI. Supposons maintenantque lentreprise X veuille savoir lequel de ces vendeurs dquipements informatiques offre desservices web compatibles avec ses systmes. Par exemple, si elle supporte des commandes lec-troniques se basant sur SOAP, elle aura donc besoin dun vendeur qui accepte des commandesde ce type qui soient compatibles avec son processus. Pour satisfaire ce genre de besoin, chaqueentreprise enregistre au niveau de UDDI tous ses services ainsi que leurs types. Ce type de ser-vice aura un identificateur unique et fera partie dun groupe de types de services bien connusenregistrs dans UDDI. Ces types de services sont appels tModels. Chaque tModel a un nom,une description et un identificateur unique. Cet identificateur est appel tmodelkey et il est notUUID (Universal Unique Identifier).En ayant un groupe de types de services bien dfinis, UDDI offre la possibilit de savoir com-ment faire du ebusiness avec une entreprise donne. Ceci est lavantage principal de UDDI parrapport aux autres pages jaunes du web telles que celles de Yahoo, Lycos, Mamma ou les autres.2.5.3 UDDI : structure des donnesUDDI utilise XML (Extensible Markup Language) [XML00] et une technologie qui lui estrelie appele SOAP (Simple Object Access Protocol) qui est une spcification pour lutilisationde XML dans les changes de messages[SOA00].Les informations enregistres au niveau de UDDI, utilisent cinq types de structures de don-nes. Cette division par type dinformation offre une simple partition qui facilite la comprhen-sion et la localisation des informations enregistres. La figure 2.10 reprsente ces cinq types destructures de donnes.Chacun des cinq types de structures de donnes est utilis pour exprimer des types de donnesspcifiques arrangs dans une relation qui suit le modle de la figure 2.10.Les donnes gres par UDDI sont sensibles la relation parent/descendant . Comme lemontre la figure 2.10, la structure de donnes BusinessEntity contient un ou plusieurs structuresbusinessService. Une structure businessService englobe des instances spcifiques de structuresbindingTemplate contenant chacune leur tour un pointeur vers une structure tModel. Ce genrede relation sappelle " une relation de contenance ".Une structure bindingTemplate ne peut pas pointer vers plus quune structure tModel.Aucune structure ne peut tre contenue par plus dune structure parente.Les informations sur les affaires, leurs services et leurs informations techniques sont spa-res de manire quils soient accessibles individuellment laide didentifiants uniques notsUUID (Universal Unique Identifier) ou cls. Ces cls sont attribues lorsque linformation estenregistre pour la premire fois au niveau de la base de registres de UDDI.24FIG. 2.10 Structure des donnes UDDI.2.5.3.1 La structure de donnes businessEntityLa structure businessEntity reprsente toutes les informations connues sur le business et lesservices quil offre :Dun point de vue XML, comme la structure businessEntity se trouve au niveau le plus haut,elle ne contiendra que des informations descriptives du business comme le nom et la descriptionde lindustrie, des informations permettant davoir un contact avec des personnes responsables ouautres (emails, adresses, tel ...), des URLs, une liste contenant zro ou plusieurs businessServices(voir section 2.5.3.2), ...Les informations sur les services et les informations techniques sont exprimes au niveau de labusinessService travers la relation de contenance.252.5.3.2 La structure de donnes businessServiceChaque structure businessService reprsente une classification logique de services etreprsente le descendant dune seule structure businessEntity.Lidentit du businessEntity parent est dtermine en examinant la valeur du champ busi-nessKey. Mais lidentifiant unique dun businessService est donn par le champs serviceKey.La structure dun businessService comporte aussi un nom et une description, dun service ainsiquune liste de de zro ou plusieurs bindingTemplates (voir section 2.5.3.3).2.5.3.3 La structure de donnes bindingTemplateLes descriptions techniques des services web sont places dans des instances des structuresbindingTemplate. Chaque structure bindingTemplate est la fille dune seule structure business-Service.La structure dun bindingTemplate comporte un identifiant du service auquel appartient cesinformations techniques (serviceKey) et un identifiant unique du bindingTemplate. Un binding-Template reprsente un point dentre aux diffrents services web (acessPoint). Ce point dentrepeut par exemple reprsenter une URL qui permet daccder directement au service afin de luti-liser.262.5.3.4 La structure de donnes tModelLe but principal de UDDI est de dcrire les services web de manire pouvoir les recherchermais aussi davoir linformation ncessaire qui permet dinteragir avec le service. Les tModelssont des sortes de types de services. Ils servent dterminer les compatibilits entre services et les dcrire dune manire qui facilite leur recherche.Cette structure comporte un identificateur unique (tModelKey), le nom du tModel, le nom dusite oprateur UDDI incluant dans sa base de registres le tModel, une description du tModel etdes rfrences sur des documentations techniques.2.5.3.5 La structure de donnes publisherAssertionPlusieurs grandes entreprises ne sont pas reprsentes par une seule businessEntity parcequils offrent des services de natures diverses. Plusieurs structures businessEntity peuvent donctre publies pour reprsenter une seule filiale. Deux entreprises lies utilisent donc des messagesxx_publisherAssertion pour indiquer la relation existante entre les deux.2.5.4 Interface de programmation UDDIUDDI offre un ensemble dAPIs sous forme de services web bass sur le protocole SOAP.Pour linstant, il y a deux sites oprateurs offrant des services web UDDI, un de Microsoft [uddb]et un autre de IBM [udda]. Ces deux sites implmentent lAPI UDDI pour permettre aux diff-rentes entreprises dexporter et importer leurs services.[udd01] prsente une spcification dtaille des APIs UDDI, ces APIs se divisent gnrale-ment en deux catgories : des APIs dexportation et des APIs dimportation comme le montre letableau 2.1.Linvocation des APIs UDDI est assure par envoie de messages SOAP avec le contenu ap-propri. Par exemple pour chercher lentreprise XYZ, il faut envoyer le bout de code XML sui-vant dans le corps dun message SOAP.XYZLe message SOAP qui sera retourn partir du service UDDI contiendra toutes les entreprisesenregistres dont les proprits correspondent aux critres demands par lutilisateur.27Recherche dune entit Catgoriefind_business importationfind_service importationfind_binding importationfind_tModel importationObtenir des dtails propos dune entit Catgorieget_businessDetail importationget_serviceDetail importationget_bindingDetail importationget_tModelDetail importationEnregistrement dentit Catgoriesave_business exportationsave_service exportationsave_binding exportationsave_tModel exportationEffacement dentit Catgoriedelete_business exportationdelete_service exportationdelete_binding exportationdelete_tModel exportationTAB. 2.1 API UDDI282.5.5 ConclusionUDDI offre un servie de pages jaunes sur le Web. Sa particularit par rapport aux autres pagesjaunes du web rside dans le fait quil offre des oprations dinteroprabilit entre les diffrentsservices offerts sur le web et enregistrs sur sa base de registres. Linconvnients de ce serviceest quil noffre aucune fdration de la recherche.2.6 Etude comparative des services de recherche sur propri-tsLe tableau 2.2 prsente une comparaison entre les quatres services de recherches : TraderCORBA, Jini, Salutation et UDDI.La connexion au service de recherche Jini, prsente une particularit par rapport aux autresservices, dans le sens o il sagit de commencer par chercher le service de recherche lui-mmeen faisant un multicast sur le rseau, une application nest donc pas relie un service derecherche par dfaut comme dans le cas du trader Corba et salutation.Pour se connecter au trader Corba, une application a un fichier de configuration partir duquelelle rcupre la rfrence dobjet interoprable (IOR) du trader au niveau duquel elle peutexporter ou lancer une importation dun service. De la mme manire, chaque machine voulantbnficier du service de recherche salutation, doit tre relie localement ou distance unSalutation Manager qui lui est propre.Le service de recherche de UDDI est toujours offert par un site oprateur sur le web. Toutepersonne dsirant rechercher un service peut donc aller directement sur le site et faire desrecherche avec des mots cls. Mais les personnes qui dsirent exporter des services doivent crerun compte sur le site. Seul Jini offre donc une dtermination dynamique du service de recherche.Concernant la structuration des donnes au niveau du service de recherche, le trader Corbaest le seul service de recherche qui propose la notion de type de service laquelle doit seconformer tout type doffre de service, ce qui offre un typage fort des diffrentes offres. Jinioffre aussi un typage fort pour les diffrentes offres grce la classe ServiceItem 2.3.5 demanire ce que chaque offre soit une instance de cette classe.Au niveau de salutation, une offre de service doit tre sous forme de FUDR 2.4.3 et au niveaude UDDI, chacune des structures de donnes businessEntity, serviceEntity, bindingTemplate ettModel ont une structure bien dfinie en XML[spec] et chaque offre de service doit se conformer cette structure.La structure des donnes au niveau de Salutation et UDDI noffre aucun typage fort mais sertjuste identifier les diffrents champs et attributs constituant les offres de service.Le trader Corba et Salutation se distinguent par leur fdration de la recherche de services.Mais, la fdrations de recherche du trader est plus tendue et se base sur des graphes orientsde recherche.29Trader CORBA Jini Salutation UDDIConnexion IOR du traderdans un fichier deconfigurationMulticast et re-cherche dun ser-vice de recherchede proximitMise en placedun SLM pourchaque entitCration decompte pourpublier un serviceStructuredes don-nesConforme destypes de servicesInstance de laclasse ServiceI-temSDR, FUDR, Format XMLFdration Traders relisentre eux par ungraphe orientPontage entreservices derechercheRPC pour com-muniquer avecdes SLM distantspas de fdrationde rechercheTypes despropritsSimples ou com-poss, support deproprits dyna-miques, supportde propritsmodifiablessous forme declasses, supportde propritsmodifiablesSimples ou com-possFormat texteFiltres deselection deservicesOprationslogiques et ma-thmatiques entrevaleurs et nomsde propritsgali entre pro-pritsgali entreproprits, unionentre FUDRenvoye etenregistregalit entre pro-pritsAPI, publi-cationInterface Register ServiceRegistrer.registerSlmRegister-CapabilityPublishing APIAPI, re-chercheInterface Lookup ServiceRegistrer.lookupSlmSearch-CapabilityInquiry APIParticularit Politiques de re-chercheConnexion dyna-mique un ser-vice de rechercheInterface in-dpendante dutransportOffre des in-formationsdinteroprabilitentre servicesLimitations Pas simple utiliser, ncessitebeaucoup delignes de codeLimit aux ser-vices de proxi-mitLimit aux ser-vices de proxi-mitPropre aux indus-tries sur le webTAB. 2.2 Comparaison des services de recherche sur proprits30Jini permet de faire le pontage avec des services de recherche dautres types comme Salutationou autres. Par contre, Il est impossible de rechercher un service qui a t enregistr sur un siteoprateur diffrent de celui au niveau duquel on fait la recherche.Chacun des services Salutation, Jini et trader Corba supportent des proprits de typessimples et composs. Au niveau de Jini, les proprits sont sous forme de classes et au niveau deUDDI, toutes les proprits sont au format texte.Le trader Corba et Jini permettent tous les deux de modifier des valeurs de proprits de servicesdj enregistrs.Le trader corba est le seul qui supporte les proprits dynamiques.La slection de services au niveau de UDDI, Jini et Salutation se fait avec des tests dgalitentre proprits. Le trader corba est le seul qui propose un langage pour dfinir les contraintes etles prfrences (OCL), qui peut faire des oprations logiques et mathmatiques entre valeurs etnoms de proprits.Chacun des quatre services de recherche que nous avons tudi offre une API servant essen-tiellement exporter et importer les services et grer les services enregistrs dans un dpositaire.LAPI du trader Corba est la plus difficile implmenter ; une recherche faisant appel la m-thode query de linterface lookup ncessite une centaine de lignes de codes [LMMG01]. MaislAPI du trader Corba est la seule qui permet la dfinition de politiques de recherche et offre unerecherche trs tendue par rapport Jini et Salutation qui se limitent la recherche de servicesde proximit.Salutation est le seul qui offre une API compltement indpendante de la couche rseau et peuttre implmente avec nimporte quel language. Les APIs de Jini ne peuvent tre implmentsquen Java, le trader Corba se limite aux objets Corba et le service de recherche UDDI nestvalable que dans un environnement Web.Contrairement au trader Corba qui permet de rechercher une rfrence sur un objet Corba, Jinipermet la recherche dobjets srialiss.Ce qui distingue UDDI par rapport aux autres services de recherche cest sa capacit doffrir desinformations sur linteroprabilit et la compatibilit entre les diffrents services.2.7 ConclusionNous avons tudi quatre services de recherche sur proprits. Chacun de ces services pr-sente des avantages et des inconvnients. Le trader Corba tant le plus complet, nous avons choiside lutiliser dans notre infrastructure de dploiement prsente dans le chapitre 4. Nous avonspu pallier son inconvnient majeur qui est la complexit de son API en utilisant en utilisantTORBA (contrats de courtage pour TORBA) [LMMG01].3132Chapitre 3Les applications base de composantsLun des buts principaux de ce stage, consiste tudier le dploiement dynamique des ap-plications multi-composants. Il nous est donc ncessaire de prsenter la notion de composantslogiciels qui peut tre nouvelle pour certains. Nous commencerons, dans ce chapitre, par prsen-ter dune manire gnrale les composants et les diffrents modles de composants existants. Parla suite, nous dcrirons le modle de composants de Corba (CCM : Corba Component Model)en focalisant sur son apport majeur quest le dploiement.3.1 Limites des applications orientes objetIl y a eu au cours de ces dernires annes, un courant de recherche trs actif portant surlutilisation des modles et des langages objets pour la construction dune application rpartie.Ces modles permettaient dune part, dexprimer les interfaces des entits logicielles manipulesrsultat de la conception et dautre part, de bien sparer la dfinition de ces interfaces delimplantation des entits logicielles. Lobjectif principal des modles objet tait damliorerla modlisation dune application, doptimiser la rutilisation du code produit, et dadresserlensemble du cycle de production des applications. Cependant, lintgration dentits logiciellesexistantes peut savrer difficile si leur modle dexcution est incompatible avec le modleimpos par le langage objet choisi pour le dveloppement de nouvelles entits. Par ailleurs,les modles et langages objets ne sont pas, en gnral, adapts la description des schmasde coordination et de communication complexes. En effet, un grand nombre de ces modlesoffrent leurs utilisateurs un mode de communication et dexcution fond sur des interactionssynchrones de type client-serveur.Pour pallier les dfauts de lapproche objet et adresser des notions non prvues initialement,lapproche composant est apparue [MMG99].333.2 Modles de composantsUne application construite selon une approche oriente composant peut tre vue comme unecollection de logiciels indpendants, interconnects laide dune plate-forme de communica-tion.Un composant est un module logiciel autonome pouvant tre configur et install surdiffrentes plates-formes. Ce composant, exporte diffrents attributs et mthodes[MMG99].Un composant logiciel peut tre compar un composant lectronique (circuit intgr). Pourconstruire un circuit lectrique, il sagit dinterconnecter un ensemble de composants lectro-niques vues comme des boites noires et dont on ne connat que le principe de fonctionnement,les services rendus, quelques rgles de connexion et la manire dont chacun deux peut commu-niquer avec son environnement (tension dentre, de sortie, ...). La construction dapplications base de composants logiciels repose sur le mme principe.Lapproche composant encourage les dveloppeurs construire les diffrentes parties deleurs applications sous forme de modules rutilisables.Une conception soigne, doit permettre la personnalisation de ces modules dans lenvironnementoprationnel. Le processus de la personnalisation dune application dans un environnementdonn sappelle le dploiement.Les composants sont donc les units de base pour la construction dapplications distribues.Le dveloppement base de composants se fait gnralement en trois tapes : la conceptionde chaque composant, leur implmentation et leur intgration (ou assemblage). La conceptionconsiste dcrire les fonctionnalits des diffrents composants en spcifiants leurs ports (inter-faces, vnements, ...). Ltape dimplmentation consiste crire le code interne du composant.Par la suite, le composant peut tre dploy (instanci sur un serveur) et peut tre assembl avecun autre composant lintrieur dun framework dune application distribue. La constructiondapplications par assemblage se fait laide de langages de description darchitectures.Il existe plusieurs modles de composants : Modles universitaires : Durra du CMU [BWD93], Darwin de lImperial College[KM98], UniCon du CMU [SDK95], Olan dvelopp au laboratoire SIRAC [BBABR96]de lINRIA-Rhne-Alpes et JavaPods [BR00] du mme laboratoire. Modles industriels : .net de Microsoft [Rog97], JavaBeans [Jav] et Enterprise Java Beans[EJB] de Sun Microsystems. Modles de rfrence : ODP (Open Distributed Processing) de lISO et lITU et CCM[com] (Corba Component Model) de lOMG (Object Management Group)Nous avons choisi de dcrire quelques concepts du modle CCM de corba et cela, pour lesraisons suivantes : le modle de composants .net 1 [Rog97] est propritaire et principalement destin aux1ou bien COM, DCOM et COM+ qui sont les prdcesseurs de .net34plates-formes Microsoft de type PC. En plus, les spcifications ne sont jamais stables. Le dploiement des EJB [EJB] est essentiellement mono-site, ce qui rpond essentielle-ment aux besoins des applications de type commerce lectronique sexcutant sur des sitesmarchands, mais pas aux applications rellement distribues.Nous estimons donc que CCM est la spcification de modle de composants la plus complte.3.3 Le modle de composants CCM (Corba Component Mo-del)La spcification du CCM [com99] est dcoupe en quatre modles et un mta-modle : Le modle abstrait : ce modle offre aux concepteurs le moyen dexprimer les interfaces(fournies et utilises) et les proprits des diffrents types de composants ainsi que leursgestionnaires dinstances. Le modle de programmation : ce modle spcifie le langage CIDL (Component Imple-mentation Definition Language) utiliser pour dfinir la structure de limplantation duntype de composant, ainsi que certains de ses aspects non fonctionnels (persistance, tran-sactions, scurit). Lutilisation de ce langage est associe un framework, appel CIF(Component Implementation Framework), qui dfinit la manire avec laquelle les partiesfonctionnelles (programmes) et non-fonctionnelles (dcrites en IDL / CIDL et gnres)doivent cooprer. Il inclut aussi la manire dont limplantation dun composant interagitavec le container. Le modle de dploiement : ce modle dfinit un processus qui permet dinstaller uneapplication sur diffrents sites dexcution de manire simple et automatique. Le modlede dploiement sappuie sur lutilisation de paquetages dployables et composables decomposants, ainsi que de descripteurs de dploiement OSD (Open Software Description)2. Le modle de dploiement introduit trois types de descripteurs exprims en OSD. Cesdescripteurs contiennent des informations sur : les implantations dun composant (et lesbesoins logiciels associs), les composants (interface, services, tat,. . . ) et la politiquedassemblage des diffrents composants qui forment lapplication [MMG00]. Le modle dexcution dfinit lenvironnement dexcution des instances de composants(cest un modle de container). Le rle principal des containers est de masquer et prendreen charge les aspects non fonctionnels des composants quil nest alors plus ncessaire deprogrammer. Le mta-modle de composant est bas sur UML et dispose de projection vers le MOF(Meta Object Facility)2OSD est un vocabulaire XML353.3.1 Le modle abstrait de composants de lOMGLes composants apportent au monde CORBA la possibilit davoir plusieurs interfaces as-socies avec un unique objet. La norme Composants regroupe sous le nom de port tout modedinteraction qui existe par rapport un composant. Quatre types de ports sont dfinis dans lecontexte du CCM. Les facettes : une facette est une interface fournie par un type de composant et qui estutilise par des clients en mode synchrone. Seule linterface dont le client a besoin estfournie.Si on regarde un distributeur de boissons, on y voit plusieurs interfaces : une interfacepour le consommateur (payer, selectionner une boisson, prendre la boisson), une interfacepour le fournisseur (ouvrir distributeur, mettre des boissons, mettre de la monnaie, viderla caisse, fermer le distributeur) et une interface pour le dpanneur (ouvrir le capot arrire,fermer le capot arrire). Les rceptacles : un rceptacle est une interface utilise par un type de composant enmode synchrone. Il sagit dun point de connexion conceptuel. Il permet donc dassemblerdes composants et des objets. La composition permet de concevoir plus facilement desapplications en permettant aux composants de faire de la dlgation de traitement.Il y a deux types de ports qui traitent des vnements : Les puits : un puit dvnement est une interface fournie par un type de composant etutilise par ses clients en mode asynchrone. Il permet un composant de recevoir desvnements dun certain type. Les sources : une source dvnements est une interface utilise par un type de composanten mode asynchrone. Il y a deux catgories de sources dvnements : les connectables enmode un vers un, et les connectables en mode un vers n.3.3.2 Les maisons de composantsUne maison de composants est un gestionnaire pour instances dun mme composant. Ellegre le cycle de vie des instances, ventuellement laide de cls primaires. Pour cela, elle offreune fabrique dinstances de composant et des outils de recherche qui utilisent des cls. Le cyclede vie dun composant se dcompose en deux phases : la phase de configuration et la phasefonctionnelle. La configuration dun composant repose principalement sur le positionnement desvaleurs de ses attributs.3.3.3 Le modle de programmationLe CIF (Component Implementation Framework) dfinit le modle de programmation pourimplanter des composants. Il inclut un langage dclaratif : CIDL (Component ImplementationDescription Language) pour dcrire les implantations de composants, de leurs maisons et de ltatdes composants. Le CIF utilise CIDL pour gnrer les squelettes et les souches. Cela automatiselimplantation de nombreux comportements de base (navigation, activation, gestion de ltat, du36cycle de vie, . . . ). Le CIF est conu pour tre compatible avec le framework du POA 3, tout enmasquant sa complexit.3.3.4 Le modle dexcutionUn container est un environnement dexcution pour une instance de composant CORBA.Cet environnement est implant comme un serveur dapplications et/ou comme une plate-formede production de telles applications.Toutes les instances de composants, quel que soit leur type, sont cres et gres par un container.Une instance de composant ne peut pas exister sans tre supporte par un container. Dautre part,un type de container ne peut accueillir quun unique type de composant pour lequel il a t conu.Deux types de containers ont t dfinis : des volatiles et des persistants.3.3.5 Le modle de dploiementLe dploiement des composants permet dautomatiser la diffusion et la mise en place duneapplication distribue.3.3.5.1 Etapes de production et de dploiement des applicationsLes tapes de production des applications base de composants sont les suivants :1. Dfinition des types de composants laide du langage IDL tendu dfinit par CORBA 3.2. Projection des types de composants en IDL compatible CORBA 2 tout en produisant undescripteur de composants dont limplantation doit tre complt par le dveloppeur.3. Implantation du type de composant.4. Pour tre diffusable, le type de composant est packag avec son descripteur et une confi-guration par dfaut, au sein dune archive.5. Inclusion du paquetage de composant dans un assemblage.6. Paquetage de lassemblage de composants afin de regrouper dans une archive les implan-tations, le descripteur de lassemblage et la configuration des composants pour ce contexteprcis. Grce ce paquetage, les paquetages dassemblage sont diffusables ou rutilisablesdans une nouvelle composition.7. Dploiement des paquetages de composants et dassemblages et instanciation des applica-tions sur leurs sites dexcutions.La figure 3.1 [MMG00], rsume les tapes que nous venons de dcrire. Dans ce qui suit, nousallons prsenter les diffrents types de paquetages et de descripteurs ncessaires au dploiement,que nous venons de citer dans les tapes ci-dessus.Dans le modle CCM, chaque composant est plac dans un paquetage et a des descripteurs qui luisont propres. En plus des paquetages de composants, nous disposons de paquetages dassemblagequi permettent la connexion des diffrents composants.3Portable Object Adapter37FIG. 3.1 Etapes de production et de dploiement des applications.383.3.5.2 Paquetages de composantUn paquetage dentit logicielle est lunit de dploiementest. Il est reprsent par un des-cripteur et un ensemble de fichiers contenant limplantation de lentit. Ce descripteur dcrit lecontenu du paquetage. Il offre des informations dordre gnral relatives lentit logicielle (au-teur, description, interface OMG IDL, etc) ainsi quune description des implantations (nom, sys-tme dexploitation cible, langage dimplantation, dpt de code, etc). Ce descripteur regroupeaussi les dpendances du composant par rapport lenvironnement.3.3.5.3 Descripteurs de composantsCes descripteurs spcifient les caractristiques dun composant spcifies pendant la phasede conception et la phase de dveloppement. Il existe deux types de descripteurs de composants. Un descripteur de fonctionnalits contenant des informations se rapportant la structuredun composant : hritage, interfaces supportes, ports, ... Ce type de description permet un outil de connecter les composants entre eux lors de la phase de dploiement. Un descripteur de dploiement qui contient des informations de dploiement servant dterminer le type de structure daccueil ncessaire au composant et fournir aux structuresdaccueil des informations sur le composant. Ces informations indiquent aussi les besoinstransactionnels du composant, la qualit de service des ports, des informations concernantles capacits multithread du composant et leur mode dutilisation, ainsi que la maniredachever la phase de configuration.Ces descripteurs sont en partie gnrs par un compilateur CIDL, et en partie modifis par unoutil de packaging (pour les notions de persistance, transaction, threading,. . . )3.3.5.4 Paquetage dassemblage de composantsUn paquetage de composant permet de dployer un composant "seul". Un paquetage das-semblage permet de dployer de manire simple des composants dpendants les uns des autres. Iloffre un patron (ou template) pour instancier un ensemble de composants et les connecter les unsaux autres. Un tel paquetage regroupe un descripteur, un ensemble de paquetages de composantset un ensemble de fichiers de proprits.Le fichier dassemblage est une archive regroupant le descripteur, les archives de composants etles fichiers de proprits.Le descripteur dassemblage de composants dcrit lassemblage des composants, cest--direles lments de description des composants, des connexions et du partitionnement. Le descrip-teur rfrence les fichiers de chaque composant et dcrit les connexions entre composants. Cedescripteur dfinit des regroupements logiques pour les composants, regroupements qui serontprojets au dploiement sur des sites physiques. Le descripteur dassemblage va servir de baseau processus de dploiement.Le descripteur de proprits dcrit le paramtrage des composants et des maisons de compo-sants. Il est utilis pour configurer un composant ou une maison : positionnement des attributs.Il fournit des proprits par dfaut qui peuvent tre modifies par lutilisateur. Les informationscontenues dans ce type de descripteur seront utilises par les objets de configurations.393.3.5.5 DploiementLe dploiement se fait en quatre tapes de base :1. Le choix des sites dinstallation de composants.2. Installation des implantations o cela est ncessaire (si elles ne sont pas dj prsentes).3. Instanciation des maisons suivie de celle des composants.4. Connexion des composants (dans le cas des assemblages).Seulement, les implmentations faites du modle de dploiement du CCM restent statiques etnutilisent pas des procdures totalement automatises puisque le choix des sites dinstallationde composants est fix lavance.3.4 ConclusionLe modle de dploiement CCM contribue accrotre la rutilisabilit dentits logiciellesen facilitant lutilisation et lintgration de composants existants. Seulement, aucune implmen-tation totalment automatise, de ce modle, na t propose. Les implmentation faites jus-quaujourdhui ne prsentent aucun aspect dynamique par rapport ladaptation au contextedexcution de lutilisateur.40Chapitre 4Infrastructure gnrale de dploiementJusqu nos jours, le dploiement des applications reste statique et nutilise pas des moyensqui lautomatisent totalement. Le but que nous cherchons est donc dautomatiser et rendre dyna-mique le dploiement des applications.Dans ce chapitre, nous allons dcrire une infrastructure qui offre un ensemble dapplicationsaccessibles par les utilisateurs partir dendroits diffrents sans avoir les installer manuelle-ment sur chaque terminal. Cette disponibilit des applications est rendue possible grce unmcanisme de dploiement dapplications la demande qui prend en compte le contexte deconnexion de lutilisateur.Nous allons commencer par dcrire linfrastructure de dploiement que nous proposons ainsique les diffrentes tapes du dploiement automatique. Ensuite nous traiterons le problme dela terminaison de dploiement. Nous insisterons principalement sur le rle et les fonctionnali-ts du serveur de dploiement. Enfin, nous terminerons par prsenter une smantique pour ledploiement en cas dchec.4.1 Description de linfrastructure de dploiementUn processus de dploiement est lensemble des oprations automatiques ncessaires pourquun utilisateur puisse accder un service faisant intervenir plusieurs htes sans avoir linstaller manuellement. Ce processus est invoqu chaque fois quun utilisateur se connecteau rseau pour utiliser un service.Les utilisateurs peuvent se connecter aux diffrents services offerts partir de terminaux etdenvironnements diffrents : ils peuvent se connecter partir dun PC quelconque, dun PDA,dun tlphone portable ou dun ordinateur portable et cela partir dendroits diffrents et enutilisant des systmes diffrents. Il est donc important que le dploiement prenne en compte lecontexte de connexion de lutilisateur.Les applications que nous considrons sont construites partir dun ensemble de composantslogiciels : une interface graphique (si le terminal de lutilisateur est capable de laccueillir) etdautres composants qui cooprent pour assurer les traitements demands par lutilisateur.41Les applications base de composants rpondent bien nos besoins puisque dune part, ellesconstituent un bon moyen pour construire des applications modulaires et rutilisables et dautrepart, elles permettent lexcution de chaque composant sur un site diffrent. Notre unit dedploiement sera donc le composant logiciel.Pour les applications que nous considrons, un mme type de composant peut avoir desimplmentations diffrentes. Par exemple, un composant de type interface graphique diffredun type terminal un autre pour une mme application (linterface graphique nest pas lamme pour un PDA ou un ordinateur portable ne serait-ce qu cause de la diffrence de la taillede lcran).Chaque composant sera plac dans un paquetage. Chaque paquetage contient une version donnedu composant dans une implmentation ddie un environnement dexcution particulier. Lesdiffrents paquetages des composants, constituant les diffrentes applications, sont placs dansdes serveurs de paquetages.Les paquetages de composants des diffrentes applications sont gnralement tlchargsau moment de la connexion de lutilisateur et instancis sur des serveurs que nous appellonsdes serveurs de composants ou serveurs dexcution. Ces serveurs offrent un environnementfavorable pour linstallation et lexcution de lapplication. Un des serveurs de composantsprivilgis pour accueillir les composants dune application est le terminal de lutilisateur. Si cedernier ne comporte pas les ressources ncessaires pour accueillir la totalit des composants delapplication, ces derniers seront disperses sur les diffrents serveurs de composants selon leurcharge et leur capacit.Il existe des composants logiciels qui doivent tre instancis avant la demande daccs delutilisateur lapplication cest dire dans la phase de prparation de linfrastructure de d-ploiement. Ces composants sont prinstancis pour les raisons suivantes : Si le paquetage du composant a une grande taille, son tlchargement prendra beaucoupde temps. Il existe des composants qui doivent toujours tre placs sur des serveurs fixes pour desraisons de scurit ou parce quils utilisent des ressources fixes comme les bases de don-nes.4.1.1 Ressources et des tapes de dploiementPour assurer le dploiement des applications, une infrastructure de dploiement doit treprpare lavance et doit contenir :1. Un ou plusieurs serveurs de dploiement.2. Un client de dploiement au niveau du terminal utilisateur.3. Un ou plusieurs serveurs de recherche sur proprits (voir section ??).4. Un ou plusieurs serveurs de composants.425. Un ou plusieurs serveurs de paquetages.Linfrastructure peut contenir un systme dquilibrage de charge entre les serveurs decomposants.En plus de linstallation de ces diffrents serveurs, linfrastructure doit initialement contenir Lescomposants prinstancis.Le processus de dploiement suit les tapes suivantes (voir figure 4.1) :1. lutilisateur choisit lapplication quil veut utiliser en prcisant quelques critrres de choix.2. Le client de dploiement envoie une requte vers le serveur de recherche pour chercherlapplication demande.3. Le client de dploiement envoie une requte vers le serveur de recherche pour chercher unserveur de dploiement de proximit pour dployer lapplication.4. Le client de dploiement collecte des informations sur le contexte utilisateur, puis envoieune requte de dploiement vers le serveur de dploiement.5. Le serveur de dploiement demande au service de recherche de rechercher les diffrentspaquetages des composants constituants lapplication demande par lutilisateur ainsi queles diffrents serveurs de composants capables dinstancier ces paquetages. Si lapplica-tion comporte des composants prinstancis, le service de recherche ne retournera que lesserveurs sur lesquels ils ont t instancis.6. Le serveur de dploiement reoit la rponse du service de recherche et envoie des ordresde dploiement vers les serveurs de composants dsigns par le service de recherche.7. Les serveurs de composants recevant ces ordres vont tlcharger les paquetages des ser-veurs de paquetages indiqus par le service de recherche et les instancier.8. Une fois que tous les composants sont instancis, le serveur de dploiement connecterales diffrents composants et donne la main lutilisateur qui peut, partir de ce moment,utiliser lapplication.Dans ce qui suit, nous allons expliquer dune manire dtaille le rle de chaque ressourcede linfrastructure de dploiement et plus particulirement le serveur de dploiement, coeur denotre travail.4.1.2 Les serveurs de paquetagesUn serveur de paquetages, reprsente un espace de stockage de composants logiciels avantleurs instanciation.Un mme type de composants peut exister sous forme de plusieurs paquetages. Nous disposonsdun fichier pour chaque implmentation de composant ; chaque fichier (ou paquetage) contien-dra une version du composant dans une implmentation ddie un type de machine ou environ-nement dexcution particulier.43FIG. 4.1 Infrastructure et tapes de dploiementChaque paquetage est mis disposition sous la forme dun fichier darchive contenant : les com-posants logiciels, les scripts dinstallation, la documentation, ...[Con00]4.1.3 Les serveurs de composants (ou serveurs dexcution)Les serveurs de composants appels aussi gestionnaires dinstances ou serveurs dexcution,fournissent un environnement dexcution pour accueillir les composants logiciels aprs leursinstanciation.Suite un ordre du serveur de dploiement, le serveur de composants, tlchargera le paquetagedsign par le service de recherche partir du serveur de paquetages qui lhberge et linstan-ciera. Le tlchargement peut tre fait par nimporte quel service de transfert de fichiers.Le serveur principal dexcution (de composants) dune application est le terminal utilisateur.Dans le cas o le terminal est riche en ressources tel un PC, le terminal utilisateur, peut tre leseul serveur dexcution. Mais dans le cas dun terminal pauvre en ressources tel quun PDA ouun tlphone portable, il faudra chercher dautres serveurs dexcution pour excuter les partiesde lapplication qui ne peuvent pas sexcuter sur le terminal [Con].Le serveur dexcution reoit la rfrence dun paquetage tlcharger et retourne la rfrencedun composant instanci [PTB02].444.1.4 Le serveur de dploiementLe dploiement dune application est assur par un serveur de dploiement quon appelleaussi gestionnaire de dploiement. Notre infrastructure comporte plusieurs serveurs de dploie-ment. Nanmoins, une application esy dploye par un seul serveur de dploiement choisi par leserveur de recherche, selon des caractres de proximit, au moment o lutilisateur accde auservice.Le rle dun serveur de dploiement consiste superviser la recherche de composantsprinstancis, la recherche de paquetages et de serveurs de composants, linstanciation et laconnexion de tous les composants ncessaires pour faire fonctionner lapplication et enfin lelancement de lapplication au niveau de lutilisateur final.A chaque fois que le serveur de dploiement reoit une liste de rsultats de recherches decomposants prinstancis, de serveurs de composants, de dploiement ou de paquetages, illenregistre dans son journal pour une utilisation ultrieure, et choisit le premier lment de cetteliste, puisque la liste retourne est trie par ordre des prfrences.Le serveur de dploiement inscrit toutes les instructions quil effectue dans un fichier journal.Le serveur de dploiement prend en compte les informations sur le contexte utilisateur pourdployer une application qui sadapte lenvironnement utilisateur.Pour assurer le dploiement des diffrentes applications, le serveur de dploiement utilise desdescripteurs de dploiement qui servent essentiellement donner des information dune partsur larchitecture de lapplication, savoir les diffrents composants qui la constituent et leursinterconnexions et dautre part des informations utiles pour le dploiement qui seront donnssous forme d attributs fonctionnels et non fonctionnels.Dans le cadre de notre application, trois types de descripteurs seront utiliss par le serveur dedploiement lors du dploiement dune application : Un descripteur de dploiement statique qui contiendra des informations sur larchitecturede lapplication et des informations sur le dploiement de lapplication qui sont invariablesquelque soit le contexte dexcution de lutilisateur. Un descripteur de dploiement dynamique qui contient des informations de dploiementvariables en fonction du contexte dutilisation (il sera envoy au serveur de dploiement). Un descripteur de dploiement concret qui dcrit larchitecture et les proprits de lappli-cation qui a t finalement dploye (il sera retourn par le serveur de dploiement).4.1.4.1 Le descripteur de dploiement statiqueLes descripteurs de dploiement statiques se trouvent dans des fichiers de descripteurs de d-ploiement qui peuvent tre placs sur nimporte quel serveur sur le rseau. Ces fichiers sont crits laide dun langage de description darchitecture dapplications (ADL : Architecture Descrip-tion Language).Les descripteurs statiques contiennent les informations sur larchitecture de lapplication sui-45vantes : nom de lapplication, nom de chaque composant, linterconnexion entre les composants.En plus des informations darchitecture, les descripteurs statiques contiennent des infor-mations servant au dploiement de lapplication. Localisation du composant aprs instanciation : il faut prciser si le composant une foisinstanci, doit tre plac sur un serveur de composant prcis comme le terminal utilisateur,sur un serveur banalis quelconque ou sur le mme serveur quun autre composant. Nouspouvons par exemple prciser ce niveau que le composant " interface graphique " doittre plac au niveau du terminal lors de linstanciation. Le cycle de vie (ou life cycle) du composant : le cycle de vie dun composant peut tre detype entit, process ou session.Les composants session sont des composants avec un tat volatile, et une identit qui nestpas persistante. La dure de vie dun tel composant est une interaction de la part du client.Les composants process sont des composants avec un tat persistant gr par le composantou par le container. Le fait que cet tat soit persistant nest pas visible pour le client. Liden-tit du composant est persistante, et gre par le composant. Elle est rendue visible au clientvia des oprations dfinies par lutilisateur. Les composants entits sont des composantssemblables aux composants processus pour la persistance. Nanmoins, cette persistanceest visible pour le client.Par exemple, linterface graphique dune application est un composant session. Puisque sijamais lutilisateur ferme lapplication, nous navons pas besoin de sauvegarder ltat delinterface graphique pour le restituer la prochaine fois. Un compte bancaire est un compo-sant entit, puisquil doit conserver son tat pour chaque prochaine connexion. Un agentqui fait un virement entre deux comptes est un composant process puisque ds quil fait levirement demand par lutilisateur il disparait tout seul. Les composants session et processsont gnralement sous forme de paquetages. par contre les composants entit doivent treprinstancis.Le processus de dploiement diffre pour composants paquetages et prinstancis. Pourles composants prinstancis, le dploiement consiste les rechercher quelque part sur lerseau et pour les composants paquetages, il sagit de trouver le paquetage et par la suitele serveur de composants capable dinstancier ce paquetage.4.1.4.2 Descripteur de dploiement dynamiqueLe descripteur de dploiement dynamique est celui quutilise le serveur de dploiement pourfaire le dploiement de lapplication demande par lutilisateur. Il contient donc le descripteurstatique de lapplication auquel il rajoute des informations variables en fonction du contextedexcution et les prfrences utilisateur et qui sont : le contexte de connexion utilisateur : Ce sont les proprits du terminal utilisateur (ceux duserveur de composants se trouvant au niveau du terminal) : la vitesse dhorloge du proces-seur, la mmoire, le systme dexploitation utilis, la charge du processeur, les langages de46programmation supports, la taille de lcran, ...Ce genre dinformations peut inclure la localisation gographique de lutilisateur qui peuttre utile pour certains services comme dans le cas o lutilisateur voudrait chercher desrestaurants dans la zone o il se trouve ou veut avoir des informations sur la mto. les prfrences et les contraintes utilisateur. un ensemble de services de recherche tris par ordre de proximit dont les rfrences sontfournies par le client de dploiement.4.1.4.3 Descripteur de dploiement concretLe descripteur de dploiement dynamique, va tre utilis par le serveur de dploiement pourconstruire des requtes de recherche vers le serveur de recherche dans le but de choisir dyna-miquement les diffrents composants qui constitueront lapplication ainsi que les serveurs surlesquels ils vont sexcuter. Ce choix se fera en fonction des proprits contenues dans ce des-cripteur. Une fois que le dploiement de lapplication sera termin, le serveur de dploiementconstruira un descripteur de dploiement concret qui dcrit larchitecture et les attributs de lap-plication qui a finalement t dploye.Ce descripteur sert essentiellement pour le repliement (voir section 4.2) et pour des connexionsultrieures de lutilisateur. Il contient ces informations. Le nom de lapplication qui a t finalement dploye. Le nom du serveur de dploiement qui a dploy lapplication. Le nom de chaque composant de lapplication dploye. Le nom du serveur de composant et la rfrence sur ce serveur de chaque composantinstanci. Le nom du serveur de paquetages et la rfrence sur ce serveur de chaque paquetage decomposant tlcharg. linterconnexion entre les composants.Une fois le dploiement de lapplication est termin, le serveur de dploiement enregistre ledescripteur de dploiement concret sur son journal et redonne la main lutilisateur en envoyant,vers le client de dploiement, le descripteur concret quil a construit avec les diffrentes listesde recherche (liste des serveurs de dploiement trouvs, liste des applications trouves, liste desserveurs de composants trouvs et les paquetages de composants trouvs) rcupres partir duserveur de recherche pour quil puisse les mettre dans le cache utilisateur qui sen servira lors deconnexions ultrieures (voir section 4.3.6).4.1.5 Le service de rechercheCe service est aussi important que le gestionnaire de dploiement lui-mme. Il assure la partieintelligente et dynamique du dploiement en trouvant la meilleure adquation entre le contexte dudploiement et les ressources disponibles au moment du dploiement. Notre infrastructure de d-ploiement comporte plusieurs services de recherches en mirroring. Chaque serveur de recherchemaintient un dpositaire contenant toutes les ressources disponibles : serveurs de dploiement,applications, paquetages de composants, serveurs de composants et composants prinstancis.47Chaque fournisseur de service gre un ensemble de ces serveurs dont il maintient les noms, lesadresses et la localisation gographique dans un fichier plac sur un serveur quelconque du r-seau. Ce fichier sera automatiquement rapatri par le client de dploiement son dmarrage (voirsection 4.1.6).4.1.5.1 Exportation de servicesChaque serveur de dploiement, application, paquetage de composant, serveur de composantsou composant prinstanci nouvellement install est enregistr auprs du service de recherche. Une application est dcrite au niveau du dpositaire par un nom, des fonctionnalits, unensemble de proprits et lemplacement dun fichier de description de dploiement pourcette application. Un serveur de dploiement est dcrit au niveau du dpositaire par un nom, une localisationlogique (adresse IP) et une localisation physique (zone, latitude, longitude). Un paquetage de composants est dcrit au niveau du dpositaire par le type de composantcontenu dans le paquetage, une URL partir de laquelle le paquetage peut tre tlcharget un ensemble dinformations sur lenvironnement dexcution. Lenvironnement dex-cution traduit des informations sur les ressources minimales ncessaires pour instancier lepaquetage comme le type dhte et le systme dexploitation sur lesquels le composantpeut sexcuter, la vitesse minimale du processeur, la mmoire minimale, ... Un serveur de composants est dcrit au niveau du dpositaire par un type dhte (serveurbanalis, PC portable, PDA, tlphone mobile, ), des informations sur ses capacits et res-sources (mmoire, processeur, ...), une localisation logique (adresse IP), une localisationphysique (zone, latitude, longitude, ), des informations sur sa charge, les logiciels suppor-ts, ... Un composant prinstanci est dcrit au niveau du dpositaire par un type de composant etune URL du serveur de composants sur lequel il est instanci.4.1.5.2 Importation de servicesPour dployer une application, quatre types de recherches sont effectus :Importation dapplications : La recherche des applications se fait partir du type dapplicationdemand et des prfrences utilisateur.Importation de serveurs de dploiement : La recherche dun serveur se base sur des critresde proximit entre lui et le client de dploiement.La notion de proximit est difficile exprimer : elle peut par exemple tre rduite unenotion de rapidit daccs ou une distance minimale entre le serveur de dploiement et leclient de dploiement donne par les latitudes et les longitudes respectives.Importation de paquetages de composants : La recherche de paquetages se base sur le typede composant souhait et un ensemble de proprits comportementales ou de personna-lisation. Gnralement, la recherche de paquetages est ralise avant la recherche dunserveur de composants o va tre instanci le paquetage. Mais dans certains cas, comme48pour linterface graphique, nous avons un serveur de composants (qui est dans le cas denotre exemple le terminal utilisateur) et nous devons chercher un paquetage (qui est dansce cas linterface graphique utilisateur) pouvant sexcuter sur le serveur de composants.Dans ce cas, il faut rajouter aux proprits statiques dun composant que lon vient de citer,des proprits de recherche dynamiques comme les contraintes techniques dexcution.En effet, les sites dexcution tant dcouverts lors du dploiement, leurs contraintes tech-niques ne peuvent tre connues avant. Le paquetage sera donc recherch en fonction delimplantation du type de composant quil contient qui doit tre en phase avec les sitesdexcution.Importation de serveurs de composants : Une fois les paquetages dfinis, il est ncessaire derechercher des sites dexcution pour les composants quils contiennent. Ces sites doiventavoir les ressources matrielles et logicielles ncessaires pour accueillir ces composants.Il est important de prendre en compte la charge dynamique des serveurs de composantset de trouver les moins chargs. En plus, il peut tre intressant de penser amliorer laperformance et garantir une certaine simplicit en cherchant des serveurs de composantsproches du serveur de dploiement.4.1.6 Le Client de dploiementNous voulons que lutilisateur puisse accder au service et que celui-ci soit choisi et confi-gur laide de ses paramtres personnels et que la diversit des configurations dapplicationssoit gre sans son intervention.Pour pouvoir dployer et accder aux diffrentes applications, un utilisateur doit avoir unclient de dploiement install sur son terminal. Cette entit logicielle permet essentiellement dechoisir une application ou un service et denvoyer une requte de dploiement vers le serveur dedploiement.Le client de dploiement inclut une interface graphique permettant un utilisateur de choisir unservice parmi les diffrents services offerts et prciser quelques proprits de ce service. Cesproprits peuvent tre exprimes sous forme de contraintes et prfrences.Linterface graphique du client de dploiement fournit une liste de noms de proprits avec deschamps remplir l o lutilisateur peut par exemple prciser la langue quil prfre, la monnaiequil veut utiliser, sil cherche un service payant ou pas et si le service est payant, il pourraprciser la marge des prix quil prfre,...Cette liste de contraintes et de prfrences contient des valeurs par dfaut au cas o lutilisateurne voudrait prciser aucune prfrence. Par ailleurs, cette liste porte sur des proprits gnralesqui peuvent tre communes tout type dapplication mais lutilisateur peut ajouter dunemanire dynamique ses propres contraintes et prfrences la liste.Une fois que lutilisateur aura saisi ces informations, il naura plus intervenir, cest leclient de dploiement qui se chargera dassurer le dploiement de lapplication et assurera latransparence du dploiement au niveau de lutilisateur.49Ds son dmarrage, le client de dploiement rapatrie le fichier contenant la liste des serveursde recherche propres son fournisseur de service dont il connait ladresse lavance. Une foierapatrie, cette liste est trie selon un ordre de proximit des serveurs de recherche par rapport la localisation du terminal utilisateur. Le client de dploiement fait ce trie en rcuprant des in-formations de localisation partir dun localisateur install sur le terminal utilisateur. Le client dedploiement choisira le premier serveur de recherche de la liste. Le rle du client de dploiementconsiste envoyer trois types de requtes partir du terminal utilisateur. La premire requte per-met la recherche dun service ou dune application bien particulire que lutilisateur demande,la deuxime permet la recherche dun serveur de dploiement de proximit et la troisime, sert dployer lapplication choisie partir du serveur de dploiement dsign.4.1.6.1 Construction des requtes de recherche par le client de dploiementLe client de dploiement construit la requte de recherche avec les contraintes et les prf-rences quil faut partir de ce qua saisi lutilisateur dans les diffrents champs et lenvoie auservice de recherche qui fait sa recherche et renvoie lensemble des rsultats au client de dploie-ment. Le client de dploiement choisit la premire application de la liste des rsultats puisquilconsidre que cest celle qui rpond le plus aux prfrences de lutilisateur et essaie par la suitede construire la deuxime requte vers le serveur de recherche partir des informations sur ledbit support au niveau du terminal utilisateur ou des information de localisation gographiquede lutilisateur pour chercher un serveur de dploiement de proximit. Enfin, le client de dploie-ment envoie la troisime requte vers le serveur de dploiement pour dployer lapplication.4.1.6.2 Construction dune requte de dploiement par le client de dploiementLa requte de dploiement consiste en un descripteur de dploiement dynamique (adapt aucontexte utilisateur, voir section 4.1.4.2). Ce descripteur de dploiement sera construit partirdes informations suivantes : le descripteur de dploiement statique sera rcupr partir dun fichier de description dedploiement dont lidentification et lemplacemant ont t indiqus dans lune des propri-ts de laplication indique par le serveur de recherche. Les informations sur la localisation gographique de lutilisateur seront rcupres partirdune entit capable de dterminer la localisation de lutilisateur (zone, latitude, longitude)que nous appelerons localisateur. les informations sur le contexte dexcution de lutilisateur seront rcupres partir duserveur de composants du terminal utilisateur. les informations sur les prfrences utilisateur seront extraites partir de ce qua saisilutilisatur dans le formulaire qui lui a t fourni par linterface graphique. Le client dedploiement ne rcuprera que les prfrences que lutilisateur a prcises et qui sont utiles ce niveau (pour le dploiement). Lutilisateur peut saisir des contraintes et des prfrencesinutiles pour le dploiement, mais le client de dploiement peut extraire les proprits utilesgrce au type de service de lapplication dployer enregistr dans le service de recherche.50En effet, le type de service contient les noms et les types de proprits supportes parle service. Le client de dploiement ne rcuprera donc que le contenu des champs duformulaire remplies par lutilisateurs se rapportant ces proprits.Une fois construite, la requte de dploiement sera envoye vers le serveur de dploiement quisen servira pour dployer lapplication demande en utilisant les informations de contexte setrouvant dans cette requte.4.2 Repliement ou terminaison du dploiementUne fois que lutilisateur a termin son travail et quil ferme lapplication, le serveur dedploiement, doit effacer les instances de composants propres aux applications de lutilisateurqui ont t places sur les diffrents serveurs de composants en effectuant des oprations inversesau dploiement : cest le repliement.Lvnement de fermeture de lapplication sera captur par le client de dploiement qui enverraune requte de terminaison du dploiement vers le serveur de dploiement.La requte de terminaison du dploiement contient le descripteur de dploiement concret quele client de dploiement a reu la fin de la phase de dploiement. Ce descripteur, permet auserveur de dploiement didentifier, les serveurs de composants sur lesquels ont t instancisdes paquetages propres lapplication utilisateur, pour quil puisse envoyer des ordres vers cesserveurs de composants pour effacer ces instances.Lutilisateur peut aussi annuler sa demande et choisir de se dconnecter avant la terminaisondu dploiement de lapplication sans utiliser cette dernire. Dans ce cas, cet ordre dannulationsera captur par le client de dploiement et envoy vers le serveur de dploiement.Une annulation est traite, au niveau du serveur de dploiement, comme une dconnexion invo-lontaire de lutilisateur (voir section 4.3.5)4.3 Smantique du dploiement en cas dchecCinq classes dchec peuvent survenir au moment du dploiement de lapplication :1. dconnexion involontaire de lutilisateur : ce genre de dconnexion peut tre caus par unecoupure de courant, des problmes de rseau, un puisement de charge de batterie, ...2. panne du serveur de dploiement,3. panne de lun des serveurs de composants ( part celui du terminal utilisateur),4. panne au niveau du serveur de recherche,5. panne du serveur de paquetages.4.3.1 Panne du serveur de dploiementLe serveur de dploiement, dsign par le service de recherche pour grer le dploiementdune application peut tomber en panne pendant une requte du client de dploiement. Si cela51arrive, nous aurons deux cas possibles : Le serveur de dploiement dpasse un certain dlai en panne, au bout duquel, il ne redonnepas la main au client de dploiement en lui retournant un descripteur concret, le clientde dploiement suppose que ce serveur est en panne et envoie une deuxime requte dedploiement vers le serveur de dploiement suivant dans la liste quil a reue la phasede recherche. Si jamais, dans le pire des cas, il parcours toute la liste des serveurs dedploiement et il trouve que tous les serveurs sont en panne, il envoie un message derreur lutilisateur lui indiquant que lapplication ne peut tre dploye.Lorsquun serveur de dploiement se rveille dune panne et trouve quil a dpass letemps dattente du client de dploiement, il saura que la requte de dploiement quiltraitait a t redirige et fera un repliement partir de son journal. Le serveur de dploiement repart avant de dpasser le dlai dattente du client dedploiement. Dans ce cas, nous disposons de trois cas possibles selon les moments o leserveur de dploiement est tomb en panne : Le serveur de dploiement est tomb en panne avant denvoyer la requte de recherchevers le service de recherche ou avant denvoyer les ordres de dploiement vers lesserveurs de composants. Lorsque le serveur de dploiement reprend, il trouvera dansson journal ce qui a t fait prcdemment. Il vrifie dabord sil a dpass le tempsdattente du client de dploiement. Sil ne la pas dpass, il vrifie si lutilisateur nesest pas dconnect involontairement ou sil na pas annul sa demande pendant sapanne en envoyant un signal de vrification de prsence vers le client de dploiement.Si lutilisateur est encore l, en attente de rponse, le serveur de dploiement poursuivrale dploiement en envoyant, selon le moment o il est tomb en panne, la requte derecherche ou les ordres de dploiement vers le serveur de dploiement.Si le serveur de dploiement ne reoit pas une rponse du client de dploiement ou sila dpass son temps dattente, il ne termine pas le dploiement de lapplication et faitun repliement partir des informations quil rcupre partir de son journal. Le serveur de dploiement envoie les ordres de dploiement vers les serveurs decomposants ou une requte de recherche vers le service de recherche, tombe en panneet rate leurs rponses. Lorsquil reprend, il trouvera dans son journal quil a envoydes ordres de dploiement ou une requte de recherche, sans recevoir de rponses.Il commence donc par vrifier la prsence de lutilisateur et le temps dattente duclient de dploiement. Si tout va bien, il renvoie les mmes ordres de dploiementou requtes de recherche trouvs dans le journal vers les mmes destinataires. Sinon(dans le cas ou il a dpass le temps dattente du client de dploiement ou lutilisateura annul sa demande), sil na envoy quune requte de recherche, il ne poursuit pasle dploiement. Mais sil a envoy des ordres de dploiement vers des serveurs decomposants, il fera un repliement.52 Le serveur de dploiement tombe en panne une fois que le dploiement de lapplica-tion est termin mais juste avant de donner la main lutilisateur et de lui envoyer ledescripteur de dploiement concret. Dans ce cas, lorsquil reprend, il se reprera avecson journal et construira le descripteur de dploiement concret. Si le temps dattentedu client de dploiement a t dpass ou lutilisateur a annul sa demande pendant lemoment o le serveur de dploiement est en panne, ce descripteur concret sera utilispour annuler le dploiement dj fait. Sinon, il sera envoy vers lutilisateur.4.3.2 Panne de lun des serveurs de composants ou du serveur de re-chercheLorsque le serveur de dploiement envoie des ordres de dploiement vers les serveurs decomposants, il se met en attente de leurs rponses qui lui indiqueront que linstanciation desdiffrents composants sest bien passe. Si un ou plusieurs serveurs de composants nont pasdonn de rponse, aprs un certain dlai dattente, le serveur de dploiement reprend la listede serveurs de composants reue prcdemment du service de recherche, choisit le serveur decomposants qui suit le serveur qui na pas rpondu dans la liste et renvoie lordre de dploiementvers le nouveau serveur de composant choisi. De la mme manire, le serveur de dploiementenvoie une requte de recherche vers le service de recherche. Si ce dernier na pas rpondu, leserveur de dploiement redirige sa requte vers un autre service de recherche.Si aucun serveur de recherche ou aucun serveur de composants ne sont trouvs, un messagederreur sera envoye vers lutilisateur et un repliement sera fait.4.3.3 Panne du serveur de recherche4.3.4 Panne du serveur de paquetagesChaque serveur de composants envoie une requte de tlchargement de fichier vers un ser-veur de paquetages. Si au bout dun certain dlai, le fichier na pas pu tre tlcharg, le serveurde composants enverra une exception vers le serveur de dploiement lui signalant que le serveurde paquetages est en panne.Le serveur de dploiement renvoie un autre ordre de dploiement vers le serveur de composantsayant signal lerreur avec un nouveau serveur de paquetages. Le nouveau serveur de paquetageschoisi sera celui qui suit dans la liste de rsultats de recherche le serveur de paquetages qui at propos prcdemment. Sil ny a plus de serveurs de paquetages dans la liste, un messagederreur sera envoy vers lutilisateur.Nous pouvons envisager cette solution, si nous voulons que toute la gestion des erreurs soitcentralise au niveau du serveur de dploiement. Mais la gestion des pannes des serveurs depaquetages sera plus simple si le serveur de dploiement envoie la liste de recherche des dif-frents paquetages et leurs serveurs vers le serveur de composants au mme moment o il luienvoie la requte dinstanciation pour quil sen serve directement, sans passer par le serveur dedploiement, si jamais il y a eu une panne du serveur de paquetages.534.3.5 Dconnexion de lutilisateurLa dconnexion de lutilisateur peut subvenir nimporte quel moment de la phase dedploiement. Si la dconnexion survient avant que le serveur de dploiement nenvoie des ordresde dploiement, il sagira juste de ne pas poursuivre le dploiement.Sinon, le dploiement se passera normalement, le serveur de dploiement, construira un descrip-teur de dploiement concret comme prvu mais lutilisera plutt pour pour faire un repliementlorsquil se rendra compte que le client de dploiement ne peut pas recevoir ce descripteur.Lutilisateur peut aussi se dconnecter involontairement aprs la terminaison du dploiementde lapplication mais pendant lutilisation de lapplication. Dans ce cas, le problme qui se pose,cest que la fermeture de lapplication ne sera pas dtecte et le repliement ne peut tre ralis.Comme solution ce genre de problmes, nous proposons que le serveur de dploiement se mette vrifier la prsence de lutilisateur en lui envoyant des signaux intervalles de temps rguliers partir du moment o il a termin le dploiement et quil a donn la main lutilisateur. Si leclient de dploiement ne donne pas de rponse ces signaux, il fait un repliement partir dudescripteur concret sauvegard dans le journal.4.3.6 Rutilisation de lapplication et caches utilisateurLorsquun utilisateur se reconnecte une mme application partir dun mme terminal, ildoit trouver sur son cache les informations ncessaires permettant dviter de recommencer latotalit du dploiement. Pour cela, nous disposons de trois types de cache au niveau de lutilisa-teur : Un cache descripteur : ce cache sauvegarde le descripteur de dploiement concret duneapplication Un cache de prfrences utilisateur : ce cache sauvegarde les contraintes et les prfrencesutilisateur. Un cache de recherches : ce cache sauvegarde les diffrentes listes de recherches faitespar le serveur de recherche : la liste des serveurs de paquetages, la liste des serveurs decomposants et la liste de serveurs de dploiement.En demandant lutilisation du mme type dapplication, lutilisateur doit retrouver les prf-rences quil a saisies la dernire fois et qui seront rcupres partir du cache de prfrencesutilisateur. Ces prfrences seront automatiquement affiches au niveau de linterface graphique la place des prfrences par dfaut. Si lutilisateur ne change aucune de ces prfrences, leclient de dploiement rcuprera le descripteur concret se trouvant sur le cache descripteur etlenverra au serveur de dploiement la place du descripteur dynamique de dploiement, quilutilisera directement pour envoyer des ordres de dploiement (dinstanciation) vers les serveursde composants sans passer par les diffrentes tapes de recherche. Si jamais il y a des pannesdans les serveurs indiqus par le descripteur concret du cache, ce qui est trs possible puisqueces serveurs ont t attribus il y a longtemps, les listes de recherche seront rcupres partirdu cache de recherche pour rediriger les diffrentes requtes vers des serveurs se trouvant sur ces54listes.5556Chapitre 5Conception du serveur de dploiementDans ce chapitre, nous allons proposer un modle UML pour le dploiement. Nous essaye-rons de focaliser sur la conception dtaille du serveur de dploiement en dfinissant ses in-terfaces et les descripteurs quil utilise. Nous essayerons de donner les diagrammes de classes,dtats et dvnements pour le modle de dploiement que nous proposons Par la suite nousessayerons de dfinir en IDL les interfaces du serveur et du client de dploiement.5.1 Modlisation UML de linfrastruture de dploiementLa figure ... montre le diagramme de classe pour notre infrastructure de dploiement. Ce mo-dle comporte 17 classes : la classe DeployementServer modlise un serveur de dploiement,la classe componentServer modlise un serveur de composants, la classe PackageServer mod-lise un serveur de paquetages, la classe ResearchServer modlise un serveur de recherche quiutilise le trader Corba, la classe Deployment modlise lentit dployant une application sur leserveur de dploiement, les classes DynamicDescriptor, ConcretDescriptor et StaticDescriptormodlisent respectivement les descripteurs dynamiques, concrets et statiques, les classes com-ponentPackage et instanciatedComponent modlisent respectivement les composants sous formede paquetages et les composants instancis, la classe DeploymentClient modlise un client dedploiement, la classe TerminalUser modlise le terminal utilisateur, la classe User modlise unutilisateur, la classe localiser modlise un localisateur, la classe Journal modlise un journal ut-lis par un serveur de dploiement et enfin, la classe Application modlise une application quelutilisateur veut dployer. Nous allons, dans ce qui suit expliquer le rle que joue chaque classe : Une classe serveur de recherche est caractrise par le nom du serveur (donn sous formedURL), son adresse IP et sa localisation gographique (zone, latitude et longitude). Ellecomporte quatre mthodes de recherche et quatre mthodes pour effacer les diffrents ser-vices enregistrs au niveau du dpositaire.Cette classe prsente une couche au dessus du trader Corba qui utilise directement ses in-terfaces.Chacune des classes DeployementServer, componentServer, PackageServer et Applicationont une relation dassociation avec la classe ResearchServer leur permettant de senregis-57FIG. 5.1 Modle UML du dploiement58trer au niveau du serveur de dploiement. Chaque objet de ces classes doit senregistrer suraumoins un serveur de recherche. Toutes ces associations sont donc multiples de 1 n. Un serveur de composants est dcrit par ses caractristiques physiques( processeur, m-moire, systme dexploitation, ...), son nom (donn sous forme dURL), son adresse IP etsa localisation gographique. Un serveur de composant hberge des composants instancis.Il a donc une relation dagrgation avec la classe instanciatedComponent. Un serveur de paquetages est dcrit par son nom (donn sous forme dURL) et son adresseIP.Les deux classes PackageServer et ComponentServer sont lis par une relation dasso-ciation de 1 n permettant au serveur de composants de tlcharger les paquetages decomposants partir des serveurs de paquetage. Les trois classes Entity, Process et Session (voir section 4.1.4.1) hritent de la classe Ins-tanciatedComponent. La classe Entity modlisent les composants prinstancis, cest pourcette raison que cette classe comporte une associaion avec le serveur de recherche lui per-mettant de senregistrer dans le dpositaire. Un composant sous forme de paquetage (ComponentPackage) est dcrit par une URL, lesystme dexploitation sur lequel il peut sexcuter, le type et la frquence du processeurminimale ainsi que la taille de mmoire minimale qui lui sont ncessaires pour pouvoirsexcuter. Une application utilisateur est caractrise par un nom, des fonctionnalits et un fichiercontenant son decripteur statique. Le terminal utilisateur peut avoir au plus un localisateur et peut contenir au plus un clientde dploiement. Le client de dploiement a une seule mthode ListExtract permettant de choisir la premireapplication de la liste de recherche retourne par le serveur de recherche.Le client de dploiement ne peut un moment donn envoyer une requte de rechercheque vers un seul serveur de recherche.Il a donc une association unaire avec le serveur derecherche. Un client de dploiement a une association avec le descripteur statique pourpouvoir en extraire des informations sur larchitecture des applications dployer ainsique des informations statiques sur le dploiement, une association avec le localisateur duterminal utilisateur pour pouvoir en extraire des informatins sur la localisation gogra-phique de lutilisateur et une association avec lutilisateur pour extraire les contraintes etles prfrences de lutilisateur.Le client de dploiement a aussi une relation dassociation avec la classe DynamicDes-criptor lui permettant de crer un descripteur dynamique. Un descripteur de dploiement dynamique est dcrit par Un descripteur de dploiement statique est dcrit par Un descripteur de dploiement concret est dcrit par59FIG. 5.2 Diagramme dvnements60Chapitre 6ConclusionDans une premire partie, nous avons prsent le contexte et ses problmes. Puis nous avonsintroduit une courte prsentation de CORBA base de nos solutions au problme. La partie axesur ltude de la littrature nous a permis dclaircir nos ides, nos solutions et de souligner lesbesoins en QoS pour les applications multimdia. Enfin nous avons dcrit larchitecture Exten-ded CORBA, en y ajoutant une proposition de protocoles pour les Ressources Managers. Notreapproche a t de percevoir les nombreuses interrogations lies aux systmes distribus, de tenterde trouver des solutions ou dans certains cas de proposer des ides nouvelles. Nous navons paspu raliser une application concrte sur Extended CORBA du fait du manque de temps. Le fruitde ces recherches est soumis sous forme darticle une confrence IEEE Pittsburg aux Etat Unis.Le domaine des systmes rpartis est en pleine volution. Linternet sature alors que les uti-lisateurs qui sont de plus en plus nombreux commencent tout juste lutiliser. Les applicationsse veulent ouvertes vers le rseau des rseaux qui na dj plus davenir sous la forme que lonconnat. Son remplaant est en test dans diffrents laboratoires. Lavenir risque de se trouverdans les Network Computers qui font beaucoup parler deux ces temps-ci. La ralisation dunearchitecture dune telle envergure a permis dapprocher et surtout de ctoyer les nombreux pro-blmes inhrents aux machines et aux rseaux actuels. Nous avons pu ainsi raliser la difficultlie penser client/serveur, prendre en compte les problmes rseaux, systmes, logiciels etmme matriel. Il est vident que rsoudre tout ceci nest pas simple et lavenir en informatiquevolue trop rapidement pour miser sans erreur sur un quelconque produit. Les nombreuses ques-tions souleves durant ce stage mritent de trouver des rponses dans le cadre dune ou plusieursthses.6162Bibliographie[BBABR96] L. Bellissard, S. Ben Atallah, F. Boyer, and M. Riveill. Distributed ApplicationConfiguration. Proc. of the 16th IEEE International Conference on DistributedComputing Systems (ICDCS96), (Hong Kong), April 1996.[BR00] E. Bruneton and M. Riveill. JavaPod : une plate-forme composants adaptable etextensible. Rapport de recherche INRIA Nr3850, Janvier 2000.[BWD93] M. Barbacci, C. Weinstock, D. Doubleday, M. Gardener, and R. Lichota. Durra : AStructure Description Language for Developping Distributed Applications. IEEESoftware Engeneering Journal, (pp.83-94), Mars 1993.[com] Composants de lOMG. http ://www.omg.org/library/schedule/CORBA_Component_Model_RFP.htm.[com99] Omg : Corba components : Joint revised submission. Object Management Group,Aot 1999.[Con] Configuration et Excution de Services pour les Usagers Mobiles des RseauxEtendus (CESURE). Rapport final.[Con00] Configuration et Excution de Services pour les Usagers Mobiles des RseauxEtendus (CESURE). Spcifications de linfrastructure systme, 2000.[EJB] Enterprise Java Beans : Server Component Model for Java.http ://java.sun.com/products/ejb/white_paper.html.[GGM97] J.M. Geib, C. Gransart, and P. Merle. Corba : Des concepts la pratique. Inter-Editions, 1997.[HV99] M. Henning and S. Vinoski. Advanced CORBA programming with C++. AddisonWesley, 1999.[Jav] Components for the Java Platform. http ://java.sun.com/docs/books/tutorial/javabeans/index.html.[JIN01a] jini architecture specification. Sun Microsystems, Dcembre 2001.[JIN01b] Jini lookup service. Sun Microsystems, Dcembre 2001.[KM98] J. Kramer and J. Magee. Analysing Dynamic Change in Software Architecture :A case of study. Proc. Of the 4th Intnl Conference on Configurable DistributedSystems (ICCDS98), IEEE, Annapolis MD, USA, pp.91-100, May 1998.[LMMG01] S. Leblanc, R. Marvie, P. MERLE, and J.M. Geib. TORBA :contrats de curtagepour CORBA. Calculateurs parallles, 2001.63[MMG99] R. Marvie, P. Merle, and J. Geib. "Des objets aux composants CORBA, premiretude et exprimentation avec CorbaScript". In Proceedings of the 12th Interna-tional Conference on Software and Systems Engineering and their Applications(ICSSEA99), Paris, France,, Dcembre 1999.[MMG00] R. Marvie, P. Merle, and J. Geib. Towards a Dynamic CORBA Component Plat-form. In Proceedings of the 2nd International Symposium on Distributed ObjectApplications (DOA2000), Antwerp, Belgium,, Septembre 2000.[OMG00] Trading Object Service Specification. OMG documents formal/00-06-27, May2000.[PTB02] E. Putrycz, C. Taconet, and G. Bernard. Smart Deployment Infrastructure for mo-bile applications. Soumis Mobicom, 2002.[Rog97] D. Rogerson. Inside COM. Microsoft Programming Series, Microsoft Press,, 1997.[Sal01] Salutation Architecture Specification. The salutation consortiumhttp ://www.salutation.org, June, 2001.[SDK95] M. Shaw, R. DeLine, D.V. Klein, T.L. Ross, and G. Toung, D.M.and Zelesnik.Abstraction for Software Architecture and Tools to Support Them. IEEE Trans.Software Engineering, vol.SE-21(N.4), pp. 314-335, Avril 1995.[SOA00] Simple Object Access Protocol (SOAP) 1.1. W3C Note,http ://www.w3.org/TR/SOAP/, 08 May 2000.[udda] site oprateur IBM pour UDDI. http ://www-3.ibm.com/services/uddi/testregistry/inquiryapi.[uddb] Site oprateur Microsoft pour UDDI. http ://uddi.microsoft.com.[udd01] UDDI Version 2.0 API Specification . UDDI Open Draft Specificationhttp ://www.uddi.org/pubs/ProgrammersAPI-V2.00-Open-20010608.pdf, 8 June2001.[XML00] XML 1.0 (Second Edition). W3C Recommandation, http ://www.w3.org/TR/REC-xml-names, 6 Octobre 2000.64

Recommended

View more >