MÉMOIRE DE STAGE DE MASTER SPÉCIALITÉ : Recherche en Informatique Mention : Informatique, Mathématiques, Statistiques

Transcription

1 ACADÉMIE DE MONTPELLIER UNIVERSITÉ MONTPELLIER II SCIENCE ET TECHNIQUES DU LANGUEDOC MÉMOIRE DE STAGE DE MASTER SPÉCIALITÉ : Recherche en Informatique Mention : Informatique, Mathématiques, Statistiques Organisation / Sélection dans les bibliothèques de composants Trading de composants KHALED OUAFI Date de soutenance: Juillet 2006 Effectué au sein du Laboratoire de Génie Informatique et d Ingénierie de Production de l Ecole des Mines d Alès Sous la direction de CHRISTELLE URTADO et SYLVAIN VAUTTIER

2 Remerciements Je tiens tout d abord à exprimer toute ma gratitude à Monsieur Yannick Vimont, Directeur du Laboratoire de Génie Informatique et d Ingénierie de Production de l Ecole des Mines d Alès, pour m avoir permis de réaliser mon stage de Master dans son laboratoire. Je remercie également Monsieur Roland Ducournau, Responsable de la Spécialité Recherche en Informatique du Master mention IMS à l université Montpellier II, de m avoir accueilli au sein du département Informatique. Je tiens à remercier mes tuteurs Madame Christelle Urtado et Monsieur Sylvain Vauttier, pour leur encadrement, leur présence, leurs connaissances, ainsi que l accueil qu ils m ont fait au sein de leur équipe de recherche. En fait c est grâce à leur support, leurs remarques, leurs efforts, leurs conseils, leurs contrôles, leur direction, leur patience, leur bonté et toutes les informations qu ils m ont fournies que ce mémoire a pu voir le jour sous cette forme. Je remercie également Madame Sylvie Cruvellier la secrétaire du laboratoire, et Madame Francoise Armand la responsable de la bibliothèque. J exprime également ma reconnaissance et mes remerciements au thésard Nicolas Desnos, qui m a accueilli et aidé avec beaucoup de patience tout au long de mon stage. A mes amis profonde reconnaissance. Enfin, à mes parents et à toute la famille un grand merci pour leur soutien et plus particulièrement à ma sœur Khalida de Strasbourg à qui je souhaite pleine réussite à sa thèse de doctorat. 1

3 Table de Matières I. Introduction générale Contexte et problématique Objectifs Plan du mémoire...9 Chapitre II. Les approches à composants Introduction Composants Les spécifications d un composant Les interfaces de composant Niveaux sémantique et protocole Niveau port Modèle de composants Le modèle de composant Fractal et son ADL Notre modèle de composant Conclusion...17 Chapitre III. Les approches de Recherche de Composants Introduction Systèmes de recherche de composants Classification par scénario d utilisation Classification par famille Les techniques de recherche de composants Les techniques classiques de recherche d information Les techniques de classification externe Les techniques de classification structurelle Les techniques de recherche comportementale Techniques de recherche par navigation Conclusion...27 Chapitre IV. Trading et composants Introduction Service dynamique de localisation Service de nom Service d annuaire Service de trading Les Spécifications requises pour un service de trading de composant Le Trading actuel Trading de composant Architecture du service de trading de composant Une étude de la fonction de trading du modèle de RM ODP La fonction de trading d'odp Exigences pour les traders de composants

4 6. Conclusion...45 Chapitre V. Un service de trading pour composants à partir de leurs ports Introduction Services et types de service Un Trader pour composants décrits par leurs ports Exportation des services Importation des services Le processus de trading Choix du type de SGBD : XML ou relationnel Conclusion...56 VI. Conclusion et perspectives...57 Annexe A: Extension du schéma de lʹadl Fractal...60 Annexe B : Schéma du document XML de la requête d importation...62 Annexe C : Déroulement d un exemple d application...63 Annexe D : Feuille de style XSL pour le schéma XML de composants VII. Bibliographie

5 Liste des figures Figure 1.1 : Deux aspects de la réutilisation [KHA 05]....5 Figure 1.2 : Cycle de vie des composants réutilisables....6 Figure 1.3 : Différentes facettes de la problématique de la recherche de composants...7 Figure 2.2 : Une station service avec des composants Fractal...15 Figure 2.3 : L architecture logicielle de la station service avec l ADL Fractal Figure 2.4 : Un méta modèle de composants qui inclut les ports primitifs et composites [DES 06]...16 Figure 3.1 : Classification des systèmes de recherche de composants [KHA 05]...20 Figure 3.2 : Architecture classique dʹun système de recherche d information ad hoc appliqué aux composants...21 Figure 3.3 : Architecture classique dʹun système de recherche d information routage appliqué aux composants...21 Figure 4.1 : Niveau dʹabstraction pour la décomposition du système d information dʹentreprise [TER 99a]...30 Figure 4.2 : Utilisation du service trading des composants pour le développement des SI [TER 99a]...30 Figure 4.3 : Architecture du service trading de composant [TER 99b]...34 Figure 4.4 : Les rôles du trading dʹodp...37 Figure 4.5 : Lʹordre des taches dans le rôle dʹimportateur du trader dʹodp [IRI 01]...41 Figure 4.6 : Propagation dʹune requête dans une fédération de trader dʹodp [IRI 01]...42 Figure 5.1 : Différents formats de l objectif fonctionnel

6 I. Introduction générale 1. Contexte et problématique Le travail présenté dans ce stage s inscrit dans le domaine de la réutilisation de composants et plus précisément dans la recherche et la classification des composants réutilisables. Faciliter et imposer la réutilisation dans l ensemble du processus de développement des systèmes d information (SI) nécessite un cadre technique, méthodologique et organisationnel. Pour ce faire, deux types de processus complémentaires doivent cohabiter comme le montre la figure 1.1 : Figure 1.1 : Deux aspects de la réutilisation [KHA 05]. Développement de composants réutilisables («Design for reuse») : une ingénierie de composants est nécessaire afin de créer, d enrichir puis de maintenir un référentiel de composants réutilisables. Le développement dʹun système de réutilisation doit mettre en œuvre les fonctionnalités d identification, de spécification, de développement, de validation et d organisation des composants. Ce développement suit un processus coopératif et itératif demandant la participation et la mise en accord d experts du domaine. Développement d applications à base de composants («Design by reuse») : un 5

7 tel développement nécessite de nouveaux environnements intégrant de manière systématique la réutilisation de composants. Ces nouveaux environnements doivent intégrer des fonctionnalités de sélection, d adaptation et d intégration de composants pour composer progressivement le système final. La figure 1.2 montre un cycle de vie des composants réutilisables et les différents métiers à travers un exemple d organisation d une équipe de développement de SI adoptant une approche de développement par réutilisation de composants. L exemple met en évidence le rôle central que jouent les bibliothèques de composants dans une telle organisation. Il est donc capital de bien réussir l automatisation de la gestion des bibliothèques de composants pour garantir l aboutissement et l efficacité du projet de réutilisation. Figure 1.2 : Cycle de vie des composants réutilisables. Face à l émergence de collections de composants réutilisables de différents types (conceptuels, logiciels, etc.), certains environnements professionnels de développement d applications ont évolué vers une gestion sommaire de composants. Or, si ces outils permettent effectivement de gérer des bibliothèques de composants, ils n en facilitent pas pour autant leur sélection et leur utilisation par une recherche ou une navigation adaptée. Les bibliothèques de composants sont des éléments clés dans les environnements de développement à base de composants et de réutilisation de 6

8 composants (cf. figure 1.2), mais leur efficacité est optimale lorsque les développeurs et les concepteurs disposent de bibliothèques riches en composants testés et validés, ce qui augmente la fiabilité et diminue le temps de développement des systèmes d information résultants. Malheureusement, mettre simplement à disposition des développeurs des bibliothèques de composants de taille importante n augmente pas forcément la productivité. Le concepteur a besoin de techniques performantes de recherche et de classification de composants. La figure 1.3 situe le domaine de la recherche de composants par rapport aux domaines de l ingénierie des SI, de l ingénierie des composants et de la recherche d information. Figure 1.3 : Différentes facettes de la problématique de la recherche de composants. Telle est la problématique de notre sujet qui situe l importance, la place et l intérêt de notre recherche. 2. Objectifs Lors du processus de développement d une application, le concepteur produit les composants et documente (méta données) leur comportement. Ces méta données sont généralement décrites sous la forme de protocoles qui décrivent les séquences d opérations valides. Un architecte construit une application en sélectionnant des 7

9 composants puis en les assemblant. La cohérence d un assemblage peut être contrôlée à deux niveaux : un niveau syntaxique, dans lequel les types des interfaces connectées sont comparés (interface matching), et un niveau sémantique, dans lequel ce sont les protocoles qui sont comparés. Le processus appropriés de recherche et de choix des composants sont devenus les pierres angulaires de chaque développement efficace à base de composants. Cependant, ces processus font face actuellement à des limitations sérieuses, généralement dues à trois raisons principales. Dʹabord, lʹinformation disponible sur les composants nʹest pas assez expressive pour leur choix efficace. En second lieu, la recherche et les critères d évaluations offertes par les traders courants sont habituellement trop simples pour être utiles en pratique. Enfin, les méthodologies courantes de l ingénierie à base de composants n exploitent pas efficacement le trading pour la recherche et la localisation des composants offrant les services exigés. Dʹabord, une des questions clés dans le développement orienté composant est lʹutilisation dʹune documentation de composants plus complète, plus concise et non ambiguë (c. à d. spécifications). Dans le cas des composants logiciels, leur nature de boîte noire gène la compréhension de leur comportement interne. En outre, seulement les propriétés fonctionnelles sont habituellement prises en considération, alors quʹune autre information cruciale au choix de composant est absente, comme les protocoles ou lʹinformation sémantique [VAL 00], les ports [DES 06] ou les conditions fonctionnelles supplémentaires [ALV 01, CHU 99]. Les fournisseurs de composant logiciel sont également sans aide, fournissant des informations rares et non structurées au sujet des composants [BER 03]. En second lieu, les processus de recherche et d appariement de composant (dans la théorie) sont délégués aux traders, mais le problème est que les traders existants ne fournissent pas toute les fonctionnalités exigées pour un trading sémantique de composants efficace, comme discuté dans [TER 99a]. Enfin, les traders ne sont pas entièrement intégrés dans les méthodologies courantes pour réaliser un développement à base de composants efficace, par conséquent ils manquent plusieurs des avantages potentiels fournis par les traders tels que la découverte de lʹinformation ou le choix partiellement automatisé des composants candidats. Dans ce mémoire, nous présentons un service de trading qui essaye dʹadresser la plupart de leurs imperfections courantes. Une extension dʹinformation utilisée pour décrire les services de composants est également présentée, où non seulement les 8

10 aspects syntaxiques des interfaces sont pris en considération, mais également l exigence syntaxique de collaborations entre interfaces contenue dans les ports, une template pour décrire les requêtes de services est définie. Avec tout cela, il est possible dʹaméliorer les deux services des processus ʹexportationʹ et ʹimportationʹ, et de concevoir et développer les traders améliorés qui se servent des avantages de l information de port pour localiser et rechercher les composants. Il y a plusieurs travaux qui adressent lʹinteropérabilité des composants, aux trois niveaux : niveau signature [OMG 99, ZAR 95], niveau protocole [CAN 00, YEL 97], et niveau sémantique [ROS 01, DHA 96]. Notre approche essaye d étendre cette compatibilité au niveau port [DES 06]. Les notions de ports primitifs et composites constituent un enrichissement des modèles de composants usuels. Nous les proposons comme concepts de granularité adaptée pour assister l architecte lors de la sélection des composants à connecter pour construire une architecture. Plus riches que les simples interfaces, ils véhiculent de l information sur les collaborations que les composants sont susceptibles d établir entre eux. Plus synthétiques et lisibles que les protocoles, ils contiennent tout de même une information sur les dépendances entre interfaces, pertinente pour assister le choix des composants. Les ports primitifs et les ports composites représentent ainsi une abstraction des collaborations potentielles et des dépendances. Tels sont les objectifs de notre travail. 3. Plan du mémoire Ce mémoire est organisé en 6 chapitres. Le chapitre II présente les approches à composants. Cette étude permet l identification des différents niveaux de compatibilité susceptibles d être utilisés lors du processus de développement de systèmes d information. Le chapitre III présente un état de l art sur les techniques de recherche de composants (TRC). Après la présentation d une classification des différentes techniques, nous en présentons des exemples pour chacune des catégories identifiées. Enfin, nous définissons des critères d évaluation des différentes techniques qui nous permettent de les comparer Le chapitre IV présente la relation entre Trading et composants, puis analyse la fonction de trading du standard ODP et ses limitations pour les composants. De 9

11 même, nous proposons une liste d exigences quʹun trader de composants doit accomplir. Ces exigences ont crée les bases pour une implémentation dʹun trader pour des composants décrits par leurs ports. Le chapitre V présente un nouveau service de trading pour composants à partir de leurs ports. Dans un dernier chapitre nous résumons les apports de ce travail et les perspectives envisagées. Des annexes complètent ce document pour en illustrer certaines parties un peu abstraites. 10

12 Chapitre II. Les approches à composants 1. Introduction L approche à base de composants est depuis une dizaine d années considérée comme un nouveau paradigme de développement des systèmes d information [BAR 02]. Les activités de programmation ont été les premières concernées par ce nouveau paradigme. Ce chapitre présente les approches à base de composants. Nous présentons dans les sections 1 et 2 respectivement les notions de composant et leurs spécifications. La section 3 définie un modèle de composant, Ensuite, nous décrirons le modèle de composant Fractal et son ADL. Enfin nous présentons notre modèle de composant comportant les ports primitifs et composites. 2. Composants A l heure actuelle, il n existe pas de normalisation de la notion de composant. Il y a un certain nombre de définitions différentes avec des différences subtiles. Une définition précise est importante afin de déterminer lʹensemble de caractéristiques qui sont significatives pour la description du composant et plus tard pour le trading de composant. La définition suivante donnée par [SZY 98] semble être claire et concise : «un composant logiciel peut être vu comme une unité de composition avec des interfaces fournies et requises contractuellement spécifiées. Cette unité est déployable et toutes ses dépendances externes sont explicites.» 3. Les spécifications d un composant Dans cette section, nous décrivons les caractéristiques d un composant logiciel c.à.d, les interfaces et lʹinformation sémantique, telle que les pré/post conditions, les protocoles et les ports Les interfaces de composant Les composants sont généralement décrits par un ensemble d interfaces qui définissent ce que le composant est capable de fournir et ce que le composant doit requérir Les interfaces peuvent être décrites en utilisant plusieurs notations différentes, selon lʹinformation que nous voulons inclure, et le niveau du détail de spécification. Par exemple, les interfaces de CORBA comprennent les attributs, les types, et les méthodes 11

13 publics dʹobjet. COM suit une approche semblable, mais les composants peuvent avoir plusieurs interfaces, chacune décrit la signature des opérations fournies. Le modèle de composants de CORBA (CCM) stipule également que les interfaces de composants peuvent décrire non seulement les services quʹil fournit, mais également les services qu il exige dʹautres composants pendant son exécution. Cependant, ce genre dʹinformation dʹinterface, également connu sous le nom dʹinformation au niveau de signature ou niveau syntactique, sʹest avéré insuffisant pour le développement d applications [YEL 97, ZAR 95]. 3.2 Niveaux sémantique et protocole Dans les signatures, le niveau sémantique traite la signification des opérationsc.à.d, le comportement [LEA 00] cependant beaucoup plus puissant que les descriptions de signatures seulement. La sémantique comportementale des composants présentent des difficultés sérieuses quand elle est appliquée à de grandes applications : la complexité informatique de prouver les propriétés comportementales des composants et des applications gêne son utilité pratique. Le niveau syntaxique traite les signatures, tandis que la sémantique couvre les aspects «comportementaux» de compatibilité entre composants. En outre, [KON 95] se rapporte aussi à eux comme niveaux statique et dynamique, et [BAS 00] parlent des composants «plug and play», en se rapportant à ces deux niveaux. Le niveau protocole traite juste les protocoles dʹaccès aux services des composants, c.à.d, lʹordre dans lesquels les composants sʹattendent à ce que leurs méthodes soient appelées, et lʹordre dans lequel elles appellent dʹautres méthodes [VAL 00]. Ce niveau, défini par [YEL 97], fournit des contrôles de compatibilité plus puissants que ceux offerts par le niveau de signature usuel. Naturellement, il ne couvre pas tous les aspects sémantiques des composants, mais il nʹest pas mal par rapport aux contrôles sémantiques lourds. C est pourquoi, nous pensons qu il peut être intéressant de définir un niveau de compatibilité intermédiaire entre le niveau syntaxique classiquement mis en oeuvre grâce aux interfaces et la comparaison des protocoles. 3.3 Niveau port Un port [OMG b, ALD 02, HAC 04, BOE 02, PRO03] est une méta information qui documente le comportement d un composant : il décrit le rôle que peut jouer ce 12

14 composant dans une collaboration. Les ports bidirectionnels regroupent les interfaces fournies et requises qui sont utilisées conjointement au sein d une même collaboration. Les ports primitifs composés uniquement d interfaces ne sont pas suffisamment expressifs dans le cas de collaborations complexes. Dans [DES 06] (cf figure 2.4) une proposition d enrichir la description de composants de ports composites pour permettre de représenter tous les types de collaborations. 4. Modèle de composants Un modèle de composants consiste en un ensemble de conventions à respecter dans la construction et l utilisation des composants. L objectif de ces conventions est de permettre de définir et de gérer d une manière uniforme les composants. Elles couvrent toutes les phases du cycle de vie d un système d information à base de composants : la conception, l implantation, l assemblage, le déploiement et l exécution. Concrètement, un modèle de composants décrit certains aspects des composants comme la définition de composants à partir d objets (classes, modules, etc.), les relations entre les composants, les propriétés fonctionnelles et non fonctionnelles de chaque composant, les techniques d assemblage des composants, le déploiement et l exécution d un système d information à base de composants, etc. Dans la pratique, un modèle de composants donné est spécifique à une phase du cycle de vie du composant et du système d information. On trouve ainsi des modèles de composants pour la phase de conception (patrons de conception), et d autres pour les phases d implantation et de déploiement (EJB, CCM, etc.). 5. Le modèle de composant Fractal et son ADL Il existe de nombreuses plates formes à composants comme EJB,.NET ou CCM qui reçoivent de plus en plus d intérêt aussi bien au niveau académique qu industriel. Cependant ces modèles sont principalement dédiés à des composants de gros grain pour des applications de type système d information. Les classes qui implémentent ces composants, suivent des règles de programmation, sont pointées par des descripteurs XML et doivent être exécutées par des serveurs d applications. Elles ne peuvent pas être manipulées aussi facilement que des objets d une machine virtuelle. De plus, les services techniques de ces plates formes sont figés et ne peuvent pas être modifiés, retirés ou ajoutés de façon standard en fonction des besoins. Ainsi, en dépit de cette large adoption de la communauté, demeure le besoin d un modèle de composant léger, proche des concepts d un langage de programmation et ne réclamant pas une mécanique lourde comme les modèles précédemment cités. Le 13

15 modèle de composant Fractal [BRU 04] répond à ces besoins. De plus, un ADL à base de descripteurs XML fait partie des sous projets liés à Fractal. Le modèle de composant Fractal permet la définition, la configuration, et la reconfiguration dynamique de composants et offre une séparation claire entre les besoins fonctionnels et non fonctionnels d une application. Construit comme un modèle de haut niveau, son objectif est de fournir une grande modularité et des possibilités d extension étendues. Le modèle est récursif : un composant est de type primitif ou composite. Dans ce dernier cas, le composant correspond à un assemblage d autres composants primitifs ou composites. Un composant peut également être partagé entre différents composites. Les interfaces jouent un rôle central dans Fractal. Il en existe deux catégories : les interfaces fonctionnelles et celles de contrôle. Les interfaces fonctionnelles sont les points d accès externes d un composant. Fractal offre des interfaces client et serveur. Une interface serveur reçoit des opérations d invocation et une interface cliente en émet. Ainsi une liaison Fractal représente une connexion entre deux composants (liaison primitive). Des liaisons de type multiples (liaisons composites) sont autorisées. Le modèle est fortement typé. De ce fait le type d une interface serveur doit être un sous type de l interface client à laquelle elle est reliée. Comme leur nom l indique, les interfaces de contrôle permettent un certain niveau de contrôle du composant auquel elles sont associées. Ces interfaces ont à charge les besoins non fonctionnels du composant, par exemple la gestion du cycle de vie ou des liaisons à d autres composants. Programmer avec Fractal Cette section illustre par un exemple les concepts du modèle de composant Fractal. La figure 2.2 représente le modèle d une station service. Chaque rectangle correspond à un composant. Les clients utilisent un pistolet pour remplir leur réservoir et payent leur carburant à une caisse connectée à une banque. Chacun de ces composants est un composant primitif Fractal. Nous avons représenté deux composants composites : le premier pour la station, le second pour le système complet. Les composites correspondent à un assemblage de composants primitifs ou composites. Les T attachés aux composants représentent les interfaces fonctionnelles (les interfaces de contrôle ne sont pas représentées sur la figure). Les flèches caractérisent les liaisons entre composants et sont orientées : d une interface cliente vers une interface serveur. Fractal met à disposition une API permettant de créer, introspecter et gérer les 14

16 composants, leurs interfaces et leurs liaisons. Par exemple un composant peut être démarré et arrêté et des liaisons peuvent être créées dynamiquement. Figure 2.2 : Une station service avec des composants Fractal. La définition de l architecture d une application s effectue grâce à un descripteur XML de l ADL Fractal. La figure 2.3 présente un extrait de cette définition dans notre exemple de la station service. Figure 2.3 : L architecture logicielle de la station service avec l ADL Fractal. 15

17 6. Notre modèle de composant Cette sous section vise à présenter comment les ports primitifs et composés sont intégré à un modèle de composant : Elle décrit ainsi un méta modèle de composant. Ce méta modèle [DES 06], comme présenté dans la figure 2.4, est inspiré par le modèle de composants Fractal [BRU 04]. Un composant est récursivement défini (il est hiérarchique). Il est composé dʹune membrane et dʹune architecture, elle même composée de composants. La membrane est décrite par lʹensemble dʹinterfaces représentant les services des composants. La membrane constitue un méta niveau qui permet lʹintrospection et lʹintersession sur le composant. Un port primitif est une représentation abstraite des contributions et des besoins dʹun composant dans une collaboration. Il contient les interfaces requises et fournies. Un port composé est la représentation abstraite dans une collaboration complexe en laquelle des sous collaborations peuvent être distinguées. Ces derniers sont considérés assez indépendant à être représentés en tant que ports séparés qui font partie du port composite. Par ce moyen, la contrainte dʹêtre connecté à un seul composant est relaxée. Figure 2.4 : Un méta modèle de composants qui inclut les ports primitifs et composites [DES 06]. 16

18 7. Conclusion Ce chapitre a présenté les approches à composants en faisant ressortir leurs spécifications. Aussi, Le modèle de composant Fractal et son ADL sont décrits. Puis notre modèle de composant comportant les ports primitifs et composites est présenté. Différents types de composants susceptibles d être utilisés lors du processus de développement de systèmes d information existent. Pendant chacune des phases de développement, Les acteurs d une équipe de développement de systèmes d information sélectionnent et réutilisent des composants qui répondent partiellement ou totalement à leurs besoins. Il est évident que la recherche d un composant varie énormément selon son niveau d abstraction et son modèle de composants. Il y a plusieurs travaux qui adressent lʹinteropérabilité des composants, aux trois niveaux : niveau signature [OMG 99, ZAR 95], niveau protocole [CAN 00, YEL 97], et niveau sémantique [ROS 01, DHA 96]. Notre approche essaye d étendre cette compatibilité au niveau port [DES 06]. 17

19 Chapitre III. Les approches de Recherche de Composants 1. Introduction La recherche dʹinformation (RI) occupe une place importante dans les systèmes dʹinformation. En effet, sʹil est important de savoir modéliser lʹinformation, il est également nécessaire de pouvoir y accéder facilement. Lʹaugmentation du nombre de documents au niveau des entreprises et des institutions ainsi que l avènement des documents électroniques, des documents multimédias et de l Internet nécessite la mise en place de systèmes sophistiqués de recherche dʹinformation. De la même manière, la recherche de composants est fondamentale pour l ingénierie des systèmes à base de composants. L augmentation du nombre de modèles de composants ainsi que l avènement des composants sur étagère (Components Off The Shell) nécessite la mise en place de systèmes sophistiqués de recherche de composants Ce chapitre présente un état de l art des différentes techniques permettant la recherche de composants. Il présente tout d abord une introduction au domaine de la recherche de composants. La deuxième section est consacrée à une identification et classification des différents types de systèmes de recherche de composants. Enfin, La troisième section présente les différentes techniques de recherche de composants que nous avons identifiées. La recherche d information (RI) est un domaine relativement ancien (plus de 30 ans) qui a connu ces dernières années une évolution rapide surtout après l avènement de l Internet et des documents multimédias. Cependant les principes de base des techniques de RI ont peu évolué ; seuls les corpus documentaires ont changé. Un composant pouvant être assimilé à un document électronique. Nous examinons dans un premier lieu s il est possible d appliquer les techniques de recherche d information sur une collection de composants. Avant d aller plus loin dans la présentation du domaine de la recherche d information en général et du domaine de la recherche de composants en particulier, définissons le vocabulaire que nous utilisons dans la suite de ce mémoire. Composants et artefacts Le chapitre 2 définit un composant comme une unité réutilisable de conception (de n importe quel niveau d abstraction) décrite selon un modèle de composants. 18

20 Dans la littérature, on trouve aussi le concept d artefact (en anglais asset ou artefact). La notion d artefact est encore plus générale et n inclut pas seulement la notion de composant, mais elle peut s étendre à la notion de procédure, module, classe, modèle, documentation, spécification, donnée de test, etc. Dans la suite de cet état de l art, nous ne distinguons pas la notion de composant de la notion d artefact car nous considérons qu un composant peut être assimilé à un ensemble d artefacts. Rechercher les artefacts revient donc à rechercher les composants. Nous considérons les artefacts et les composants comme étant des documents électroniques. Lors de la présentation des techniques de RI appliquées aux composants, nous parlons uniquement de composants et de bases de composants. Base de composants Une base de composants est une collection de composants maintenue selon une organisation permettant la recherche et la sélection des composants. Requête Une requête est une expression de termes qui décrivent les besoins en information de l utilisateur. Le concept de terme est souvent associé à une expression textuelle sous la forme d un mot. 2. Systèmes de recherche de composants Il existe fondamentalement deux approches de systèmes de recherche de composants [KHA 05] : l approche par navigation et l approche par requêtes (cf. figure 3.1). Dans l approche par navigation, le système de recherche d information exploite les liens sémantiques qui peuvent exister entre les composants pour faire de la navigation. Dans l approche par requêtes, le principe de base consiste à faire correspondre une requête à une collection de composants et à retourner les composants pertinents à l utilisateur. Le succès de ce type de systèmes dépend en partie de la qualité et de la quantité d informations associées à la requête et aux composants de la base de composants. En effet avec une grande quantité d informations définissant la pertinence des composants, le système sera en mesure d employer des techniques plus avancées pour classer les composants pertinents et non pertinents. 19

21 Figure 3.1 : Classification des systèmes de recherche de composants [KHA 05]. Les systèmes à base de requêtes sont classés selon deux classifications orthogonales : le scénario d utilisation (ad hoc, routage et filtrage) et la famille de techniques de recherche de composants qu ils adoptent (technique classique de RI, classification externe, recherche structurelle et recherche comportementale). 2.1 Classification par scénario d utilisation La classification par scénario d utilisation des systèmes de recherche de composants par requêtes se divise en trois sous catégories : la recherche ad hoc, le routage et le filtrage [HUL 94]. Recherche ad hoc Dans la recherche ad hoc, l utilisateur pose des requêtes auxquelles le système est censé répondre en renvoyant un ensemble de composants ordonnés selon une mesure de pertinence. On considère généralement que le corpus est fixe et que les requêtes sont totalement ouvertes (formulées par l utilisateur). Après avoir reçu une réponse, l utilisateur peut reformuler sa requête pour affiner la recherche (cf. figure 3.2). 20

22 Figure 3.2 : Architecture classique dʹun système de recherche d information ad hoc appliqué aux composants. Routage Dans la technique de routage, les requêtes sont fixées, et il s agit d ordonner un ensemble de composants par rapport à ces requêtes. Chaque requête définit une classe de composants. Il s agit donc d un problème de classification pour lequel on désire ordonner les composants par rapport à chaque classe (cf. figure 3.3). Les corpus sont généralement dynamiques, ils peuvent être volatiles ou évoluer au cours du temps. Figure 3.3 : Architecture classique dʹun système de recherche d information routage appliqué aux composants. 21

23 Filtrage La fonction d un système de filtrage est le tri d un flux de composants issu de sources de composants, puis la présentation à l utilisateur des composants qui correspondent à sa requête. C est aussi une tâche de classification, mais cette fois ci on se limite à prendre une décision sur la pertinence d un composant pour une classe. A la différence du routage, il s agit d une décision binaire. Nous avons présenté dans cette section une classification des systèmes de recherche de composants en trois catégories selon leurs scénarios d interaction avec l utilisateur. Chacune de ces trois catégories peut être utile pour la gestion des composants dans une approche de développement par réutilisation de composants. En effet le filtrage peut aider une équipe de développement de systèmes d information à faire de la veille et à rester à l écoute des fournisseurs de composants du marché et ne prendre selon ses besoins que les composants qui vérifient certaines contraintes de qualité. Le routage peut être utilisé après le filtrage pour classer les composants susceptibles d intéresser l équipe. La recherche ad hoc servira aux ingénieurs pour pouvoir sélectionner les composants dont ils ont besoin pour construire un système d information. Enfin la navigation est un très bon outil pour explorer le contenu d une base de composants ou bien raffiner les résultats obtenus à partir d une approche de recherche de composants ad hoc. 2.2 Classification par famille Les systèmes de recherche de composants adoptant une approche par requête peuvent être classés selon la famille de techniques de recherche de composants qu ils adoptent : les techniques classiques de recherche d information peuvent être appliquées directement sur les composants (code source). les techniques de classification externe indexent une représentation externe des composants. Cette représentation est souvent préparée manuellement sous forme textuelle (par exemple, une documentation en langue naturelle). les techniques de classification structurelle exploitent les propriétés structurelles des composants comme les signatures et les spécifications des services offerts par les composants. les techniques de recherche comportementale exploitent la propriété d exécutabilité des composants logiciels pour les classer. La classification se fait en mesurant certains critères dynamiques comme le temps d exécution ou la mémoire consommée, ou encore en utilisant les traces d exécution. 22

24 Ces techniques de recherche de composants sont décrites dans la section suivante. 3. Les techniques de recherche de composants Cette section détaille chacune des techniques de recherche de composants introduites dans la section Les techniques classiques de recherche d information Le domaine de la recherche de composants peut être considéré comme un sous domaine de la recherche d information (RI). Les premiers travaux sur la recherche de composants ont considéré les composants comme des sortes de documents. Partant de cette hypothèse, ils ont utilisé et adapté les techniques textuelles de la RI aux composants (modèles booléens [SAL 83a], modèles vectoriels [LUH 57, BUC 92], modèles probabilistes [BOO 74, CRO 79], modèles linguistiques [SAL 83, NIE 90]). Ces techniques de RI peuvent donner des résultats satisfaisants avec certains types de composants comme les patrons [COP 95, GAM 95] assimilables à des documents semistructurés textuels. Par contre, les techniques de RI sont peu utiles pour un ingénieur d applications désirant consulter une base de composants logiciels (COM, DCOM, EJB, etc.). Par exemple, les techniques d indexation textuelle sont incapables de répondre aux requêtes du type sélectionner tous les composants utilisant la technologie Java qui implantent l interface notifier. Cette requête suppose que le système dispose d une information externe aux composants indiquant le langage d implantation. Ce même système doit être capable d extraire et d analyser la structure interne du composant. 3.2 Les techniques de classification externe Les techniques de recherche de cette catégorie indexent une représentation externe des composants souvent préparée manuellement Représentation par facettes et vocabulaire L approche de classification par facettes [PRI 87, ZHA 00] pour la recherche de composants consiste à caractériser le composant par un ensemble de facettes. Chaque facette représente une information permettant d identifier et de sélectionner un composant. Une facette est définie par son nom et son espace de termes appelé vocabulaire. Un vocabulaire est l ensemble des termes possibles qui permettent de décrire les aspects de la facette. Par exemple, si on associe à un composant logiciel une facette qui décrit le langage de programmation utilisé pour son implantation, alors la 23

25 facette aura pour nom langage d implantation et aura comme vocabulaire les termes Java, C, C++, etc. Cette technique est puissante et donne de bons résultats à condition de bien choisir les facettes et de bien indexer les composants en donnant les bons termes. Elle nécessite une indexation manuelle souvent coûteuse en temps et en argent Description en langue naturelle Les informations d indexation sont extraites en effectuant une analyse lexicale, syntaxique et sémantique sur la description en langage naturel des composants. Ce qui revient à supposer que la description en langue naturelle décrit avec précision le composant, d où la faiblesse de cette approche. Le mécanisme d interprétation automatique utilisé pour l analyse des composants utilise des techniques linguistiques pour rechercher la description la plus adéquate au besoin exprimé par l ingénieur d applications, ce qui est une deuxième source de difficultés. Cette méthode peut donner de bons résultats mais elle reste difficile à mettre en œuvre. Elle est limitée à des bases de composants spécifiques pour des domaines restreints [GIR 95]. 3.3 Les techniques de classification structurelle Cette approche est basée sur des techniques qui exploitent les propriétés structurelles des documents Appariement de signatures L approche à base d appariement de signatures [ZAR 93] repose principalement sur les techniques d appariement et de transformation de types. Si nous nous plaçons dans un cadre standard de développement par objets, un composant est généralement composé de plusieurs classes. Une classe contient un ensemble de signatures de méthodes, de types et de variables. Un composant peut donc être représenté par un ensemble de signatures. L approche d appariement des signatures prend comme hypothèse que l ensemble de signatures accepté par le système est connu. Les signatures peuvent être basées sur des types simples, des types complexes voire des fonctions. Cette technique est très intéressante si l ingénieur d applications connaît à priori la forme ou le nom d une méthode appartenant au composant qu il cherche. Pour un acteur qui intervient dans une phase tardive du cycle de développement des SI et qui manipule des centaines de composants logiciels, cette technique peut améliorer sensiblement sa productivité. 24

26 3.3.2 Appariement de spécifications L approche à base d appariement de spécifications [ZAR 95, JIL 97, HEM 01] repose sur le principe d appariement des prédicats dans une logique équivalente à la théorie des prédicats. Comme dans le cadre de l approche par appariement de signatures, un composant est considéré comme étant un ensemble de classes et une classe correspond un ensemble d opérations. La spécification d un composant correspond à l union de toutes les spécifications des classes qui le forment. La spécification d une classe est l ensemble de toutes les spécifications de ses opérations. Enfin la spécification d une opération est une paire de prédicats, une pré condition et une post condition qui expriment des contraintes sur les opérations. Les prédicats sont exprimés dans des langages de spécifications formelles. La requête de l ingénieur d applications se présente sous la forme d une spécification formelle de ses besoins. Le système d évaluation des requêtes est un moteur de preuve de théorèmes utilisant des techniques d intelligence artificielle. Son rôle est d essayer de prouver que deux spécifications sont équivalentes ou quasi équivalentes. Il estime une distance qui sera proportionnelle à l effort d adaptation nécessaire pour qu un composant corresponde à la requête utilisateur [JIL 97]. Les approches de recherche de composants à base d appariement de spécifications sont des méthodes très puissantes qui donnent de bons résultats car elles héritent de la rigueur mathématique des formalismes qu elles utilisent. Cependant, ces approches nécessitent de très bonnes connaissances des langages de spécifications formelles comme B, Z ou OCL. Une deuxième difficulté vient du fait que le système d évaluation des requêtes s appuie sur un moteur de preuve de théorèmes. Les algorithmes de démonstration de théorèmes ont une complexité élevée. Si on utilise le système dans un environnement de développement professionnel qui peut contenir des centaines et même des milliers de composants, on risque d obtenir des problèmes de performances voire d impossibilité d avoir des réponses dans des temps raisonnables, d où un réel problème lors du passage à l échelle. 3.4 Les techniques de recherche comportementale Les approches de recherche de composants dites comportementales [POD 92, HAL 93, ATK 95] exploitent la propriété d exécutabilité des composants logiciels pour les classer. Le test du composant logiciel avec l activation de ses opérations avec différentes valeurs de paramètres renvoie des réponses qui sont collectées. Ces collections de réponses décrivent le comportement dynamique du composant selon les paramètres qu il a reçus. Ces collections de réponses sont appelées comportement du 25

27 composant. Pour pouvoir rechercher un composant possédant un comportement spécifique ou qui s en approche le plus, il faut définir une relation d ordre sur les comportements de composants. La requête de l ingénieur d applications se présente sous la forme d un programme qui appelle systématiquement un sous ensemble d opérations de chaque composant de la bibliothèque et qui récupère leurs comportements pour les comparer au comportement recherché. Seuls les composants qui vérifient le comportement indiqué dans la requête sont fournis à l ingénieur d applications. 3.5 Techniques de recherche par navigation Les techniques de recherche de composants par navigation exploitent les relations implicites ou explicites qui peuvent exister entre les composants appartenant à une base de composants. Par exemple, certains environnements de développement adoptent les techniques de recherche de composants par navigation comme le browser de Smalltalk 80 [GOL 84]. Nous présentons dans la suite de cette section deux exemples de souscatégories des approches de recherche de composants par navigation : approche hypertexte et approche par clustering Approche hypertexte L approche hypertexte [GAR 90] [CYB 93] [LAT 88] organise les informations en un graphe de nœuds appelés unités d informations. Ces nœuds sont interconnectés avec plusieurs types de liens appelés relations. L utilisateur navigue à l intérieur du graphe en utilisant les relations. La sémantique associée à ces relations guide l utilisateur selon ses besoins pour sélectionner le bon chemin qu il doit suivre à travers le graphe Approche par clustering Dans l approche par clustering [JEN 93], un graphe hiérarchique de spécifications est construit permettant la navigation pour la recherche de composants. Le graphe est construit en utilisant un algorithme de clustering et une relation de subsomption. Dans un premier temps, la relation de subsomption est utilisée pour construire des graphes hiérarchiques de spécifications. Puis, les graphes sont reliés grâce à un algorithme de clustering sur les sommets des graphes hiérarchiques. Ainsi lors de la navigation, l utilisateur commence par choisir le cluster qui l intéresse, puis continue sa navigation dans la base de spécifications en suivant les liens de subsomption. 26

28 4. Conclusion Après l étude de ces différentes catégories de techniques de recherche de composants, nous constatons qu aucune approche ne fournit une réponse complète aux besoins de l ingénieur d applications. Chaque technique s adresse à un contexte d utilisation particulier. La classification externe permet de classer et de sélectionner les composants selon des critères choisis et fixés par le bibliothécaire car généralement l indexation est faite manuellement. Les techniques d appariement structurel permettent d extraire automatiquement (signature) ou manuellement (spécification) les structures d indexation. Elles permettent une interrogation rigoureuse de la base de composants. Ces techniques sont dédiées à des utilisateurs qui savent avec précision ce qu ils recherchent (signature) et ont une bonne expérience de la spécification formelle (spécification). Les techniques de classification comportementale explorent la dimension dynamique des composants. Leur complexité est analogue à la complexité des techniques de test. Finalement, les approches de recherche de composants par navigation sont souvent utilisées comme un mécanisme complémentaire de raffinement de la recherche des systèmes utilisant les approches linéaires à base de requêtes. Les notions de ports primitifs et composites telles que décrites dans le chapitre II constituent un enrichissement des modèles de composants usuels. Nous les proposons comme concepts de granularité adaptée pour assister l architecte lors de la sélection des composants à connecter pour construire une architecture. Plus riches que les simples interfaces, ils véhiculent de l information sur les collaborations que les composants sont susceptibles d établir entre eux. Plus synthétiques et lisibles que les protocoles, ils contiennent tout de même une information sur les dépendances entre interfaces, pertinente pour assister le choix des composants. Les ports primitifs et les ports composites représentent ainsi une abstraction des collaborations potentielles et des dépendances. 27

29 Chapitre IV. Trading et composants 1. Introduction Un système d information dʹentreprise pourrait être construit en rassemblant les services nécessaires par la composition des composants disponibles choisis parmi une collection fournie par les systèmes dʹentreprise participants pour former le nouveau système d information dʹentreprise. Une des questions centrales pour le développement à base de composants est la localisation des composants. Dans les systèmes ouverts à grande échelle le trading est déjà employé comme mécanisme de localisation de service. Ceci est considéré comme la seule manière de contrôler des services où la connaissance complète du système est peu raisonnable et peu réaliste. Fournir les mécanismes de trading appropriés pour le développement à base de composants exige un passage du trading basé sur l apparence (interface) à celui basé sur le comportement (sémantique). Une architecture de trading de composant sémantiquement augmentée qui permet ce mouvement est présentée. 2. Service dynamique de localisation Selon le nouveau cadre de développement décrit précédemment, la première étape en cours pour développer un nouveau système est le choix des services appropriés dʹune large collection disponible. Le besoin de service qui facilite la localisation de service est une question cruciale. Un problème semblable est la localisation des services dans les systèmes répartis ouverts à grande échelle, qui ont attiré beaucoup dʹintérêt de recherches pour le passé. Un certain nombre d approches différentes sont proposées, comme le nom, lʹannuaire et les services de trading, chacun dʹeux expose certains avantages qui le rend particulièrement approprié aux applications spécifiques. Un regard dans chacun dʹeux nous aidera à déterminer lequel est plus approprié comme base pour notre nouveau cadre de développement Service de nom Un service de nom permet la localisation des services basés sur leurs noms. Les avantages dʹune telle technique sont : en premier lieu, les noms sont plus faciles à se rappeler que des références aux services réels, deuxièmement il permet le découplage des fournisseurs de service et des consommateurs de service. Mais, en même temps lʹutilisation des noms a également son inconvénient principal à mesure que la taille de lʹespace de nom augmente, les développeurs ne peuvent pas maintenir la pléthore de 28

30 noms disponibles. Ajouter une structure à lʹespace de nom pourrait aider, qui a mené à lʹidée dʹun service dʹannuaire Service d annuaire Structurer lʹespace nommé rend la localisation du nom approprié plus facile. Dʹailleurs un service dʹannuaire permet le passage à l echelle car la convention de nomage (hostnaming) dʹinternet sʹavère pratique. Mais, un service dʹannuaire est toujours basé sur lʹassociation des noms aux services. Par conséquent dans le service de nom et le service d annuaire le processus entier de localisation des composants est fondé sur deux hypothèses, dʹabord les noms sont intuitifs sur la nature du service souligné. En second lieu, le schéma dʹappellation déployé en structurant lʹespace nommé est basé sur des principes simples qui rendent la construction nommée facile. Comme nombre de services disponibles dans le système augmente, la validité des deux prétentions sʹaffaiblit Service de trading Des services de trading ont été développés pour répondre à ce problème. Un service de trading est basé sur la notion d appariement d offres de services avec des demandes de service. Il résout les problèmes de schémas d appellation en utilisant une hiérarchie de types de services. La localisation de service nʹexige pas la connaissance du nom du service mais juste les besoins du développeur (spécifications dʹun type de service). Un service de trading semble la seule manière raisonnable de contrôler le développement des systèmes compositionnels à grande échelle, où la connaissance du système entier est impossible et peu réaliste. Une bonne analogie pour faire la différence entre le trader et le service dʹannuaire est lʹannuaire téléphonique, lʹutilisation dʹun service dʹannuaire correspond à lʹutilisation des pages blanches, alors que lʹutilisation dʹun service de trading correspond à lʹutilisation des Pages jaunes. Le trading semble la base la plus appropriée pour la localisation dynamique de service. 3. Les Spécifications requises pour un service de trading de composant Le développement à base de composants de système d information dʹentreprise, exige la décomposition des systèmes dʹentreprise courants en un certain nombre de services et de composants. Cette décomposition de système est faite selon différents niveaux dʹabstraction (cf figure 4.1). Au niveau le plus bas, le système est décomposé en un certain nombre de composants de base. Certains de ces composants groupés ensemble forment les entités fonctionnellement cohésives appelées les services. Au plus haut niveau, ces services sont combinés ensemble pour former le système entier 29

31 dʹentreprise. Dans le développement dʹun SI les systèmes participants peuvent contribuer aux composants de niveau de base ou aux services. Ainsi, le service de trading devrait supporter les deux niveaux. Figure 4.1 : Niveau dʹabstraction pour la décomposition du système d information dʹentreprise [TER 99a]. Le service de trading de composant supportera le développement d un SI de la façon suivante (cf figure 4.2) : en premier, il y a un certain nombre de SI existants. Chacun de ces systèmes se compose dʹun certain nombre de composants reliés (composants de niveau base et services de la figure 1) et dʹun trader sémantique (le cercle noir à lʹintérieur de chaque système). La création du nouveau SI (le système au milieu) sera conduite par un nouveau trader de composant, qui est constitué en composant les traders existants. Puis, le nouveau trader est utilisé pour choisir les composants qui formeront le nouveau SI tandis que l assemblage sera supporté par un service d assemblage (expliqué ci dessous) lié au trader qui crée la nouvelle configuration. Parfois les systèmes existants ne peuvent pas fournir tous les composants nécessaires. Dans ce cas, le trader de composants essaie de rechercher les composants absents ailleurs. Figure 4.2 : Utilisation du service trading des composants pour le développement des SI [TER 99a]. 30

32 3.1. Le Trading actuel La définition admise du trading est : «lʹactivité des services de choix, tels quʹils apparient quelques conditions de service. Le choix est basé sur la comparaison de la spécification dʹun service requis (fourni par un consommateur éventuel) et de la spécification du service fourni par des fournisseurs de service ou leurs agents» [DES 93]. Le trading est basé sur la notion d appariement des offres de service et des demandes de service. Le composant responsable de lʹentretien de lʹespace du trading et de lʹappariement des offres et des demandes sʹappelle un trader. Les traders courants organisent les services en une hiérarchie de types de service. Chaque type de service définit une interface qui prescrit les opérations disponibles pour lʹinteraction entre le fournisseur de service et le consommateur de service. Ils permettent également lʹassociation dʹun certain nombre de propriétés pendant que la valeur dʹattribut est comparée avec chaque type de service. Lʹutilisation des types de service avec les propriétés associées permet lʹexpression des offres et des demandes de service dʹune manière facile. Les fournisseurs de service sʹappellent les exportateurs. Un exportateur exporte une offre de service en indiquant son type de service et ses propriétés de service. Le fournisseur de service peut également raffiner son offre en indiquant un certain nombre de propriétés dʹoffre de service. Les consommateurs de service sʹappellent les importateurs. Un importateur demande un service en indiquant le type du service et des contraintes sur les propriétés du type. Lʹimportateur peut également pouvoir indiquer une portée de recherche et limiter la partie de lʹespace du trading qui veut être recherché. En outre il peut être permis dʹindiquer des critères de sélection pour le choix des offres quand plus dʹune rencontre du type indiqué et des contraintes de propriété et peut indiquer la méthode de recherche qui va être employée par le trader. La combinaison des politiques de trading, dʹexportation et dʹimportation détermine le processus d appariement de service. Le centre dans l appariement de type de service est la notion de conformité de type (si TypeA se conforme à TypeB alors une instance du TypeA peut être remplacée par des instances de TypeB et les clients ne pourront pas détecter que lʹinterface étant employée nʹest pas du type exact demandé). La conformité de type est basée sur la règle aucune de surprise ( no surprise rule ) sur lʹinterface dʹinteraction, qui signifie qu aucune condition dʹentrée ou de sortie ou états dʹarrêt dʹopération nʹémergera. Puisque la conformité de type est déterminée par lʹinterface dʹinteraction, la description des interfaces est cruciale dans le trading. Au niveau de base, la description dʹune interface est basée sur la détermination du type des paramètres et de la valeur de retour pour les méthodes supportées (la signature de lʹinterface). Dans la plupart des cas ce nʹest pas suffisant. Par exemple, dans la 31

33 bibliothèque mathématique de C presque deux tiers des fonctions ont la même signature double >double. Afin de surmonter le problème, le nom de la méthode est considéré comme une partie de la signature. En outre les exceptions sont également considérées comme une partie de la signature dʹune méthode. Pour les spécifications des signatures de méthode et dʹinterfaces en général des langages de définition dʹinterface (IDLs) ont été développés (par exemple CORBA/IDL). Ainsi, le trading est actuellement basé sur les IDLs. Ceci signifie que le fondement du trading est de répondre à des questions de la sorte : «Trouve moi un service qui se conforme au type de service suivant et qui a les attributs suivants» Trading de composant Le fondement du trading actuel nʹest pas suffisant pour le trading de composants en raison de sa nature syntaxique. Un trading sémantiquement riche est nécessaire. Afin dʹétablir ceci, une définition concise des composants est nécessaire. Dans la littérature, il y a un certain nombre de différentes définitions avec des différences subtiles. Une définition précise est importante afin de déterminer lʹensemble de caractéristiques qui sont significatives pour la description du composant et plus tard pour le trading de composant. La définition suivante semble être claire et concise : «un composant de logiciel est lʹunité de composition avec les interfaces contractuellement indiquées et les dépendances explicites de contexte seulement. Un composant logiciel peut être déployé indépendamment et est sujet à la composition par les tiers.» [SZY 98]. Ceci a un certain nombre dʹimplications, qui établissent lʹinopportunité du trading courant comme base pour le service de trading de composant. Puisque le trading courant est insuffisant pour capturer tous les aspects dʹun composant qui sont identifiés par la définition. Selon la définition un composant logiciel est une unité de composition avec les interfaces contractuellement indiquées et les dépendances explicites de contexte seulement. Ceci implique dʹabord que la base du trading devrait être des descriptions de composants et une certaine notion «de la conformité de composant» (la définition de la conformité de type de composant devrait incorporer la notion de la substituabilité dʹune manière analogue à celle du conformité de type. Un préalable à la définition est la définition des types de composants.). En second lieu, si des définitions dʹinterface sont vues comme caractéristiques des contrats dʹinteraction entre deux parties, alors le trading basé sur l IDL semble couvrir la condition contractuellement définie dʹinterface. Dʹune part, si la notion de contrat comme décrite, ce qui indique que non seulement lʹinterface dʹinteraction entre les parties, mais également les engagements et les avantages pour chaque partie sont adoptés. Puis, il est exigé que les interfaces soient être prolongées pour inclure les assertions comme les pré /post conditions et les invariants. Ce sens de contrat soulève un doute sérieux sur l adéquation du trading courant. Il faut 32

34 également noter que lʹapplication de cette notion de contrat dans un modèle orienté composant nʹest pas simple. Enfin, les dépendances de contexte incluent les événements que le composant produit et consomme, ses rapports avec dʹautres composants et son information dʹétat qui doit être exposée à ses clients. Rendre des dépendances de contexte explicites implique que les définitions de composants devraient inclure des constructions pour permettre leur expression. Il y a déjà des tentatives vers cette direction. La suite de la définition de composant exige quʹun composant logiciel peut être déployé indépendamment et est sujet à la composition par les tiers. Le déploiement indépendant des composants pourrait être considéré par suite des conditions précédentes de la définition avec lʹaddition que les dépendances de contexte ne devraient pas être comme grave quant à empêcher le déploiement indépendant du composant. La condition pour la composition par les tiers a cependant des implications significatives. Un tiers est un côté qui nʹa aucune connaissance de l implémentation interne du composant et des implémentations internes des clients du composant. Ceci signifie que les composants impliqués devraient fournir des informations suffisantes au sujet de leur capacités et besoins afin dʹêtre composables. Ceci pose un défi sérieux aux les techniques de trading courantes, puisquʹil exige des informations sémantiques sur le comportement des composants. Ainsi, le trading courant nʹest pas suffisant comme base pour des mécanismes de localisation de composants, comme cʹest le cas pour les composant logiciels. Ce qui est nécessaire est lʹinclusion de la sémantique. En dʹautres termes ce qui est nécessaire est un nouveau genre de trading basé sur la sémantique, «trading sémantique». «Le trading sémantique» est un type fondamentalement différent du trading parce que son fondement est de répondre à des questions du type : «trouve moi un composant/service qui fait la chose suivante» [TER 99b]. Ainsi, on passe de lʹapparence (syntaxe) à la fonctionnalité (sémantique) des composants. 4. Architecture du service de trading de composant Le service trading de composant est basé sur lʹidée du trading sémantique. Avant que son architecture puisse être définie il y a quelques points au sujet du trading sémantique qui ont besoin dʹêtre clarifiés. Dans le trading sémantique, lʹidée est dʹincorporer des informations sémantiques sur le comportement des composants dans le processus de trading. Ceci est réalisé en soutenant le processus de trading avec une base de connaissance qui contient cette information sémantique. Ce central dans la construction de la base de connaissance est 33

35 la définition dʹune ontologie du domaine des composants. La connaissance requise pour la définition de cette ontologie est acquise de lʹanalyse de domaine pendant la conception du système dʹentreprise. En fait, si un processus de conception comme celui décrit dans [18] est suivi, alors les concepts de lʹontologie sont directement les concepts (types) identifiés pendant la conception et leurs rapports sont également directement tracés dans lʹontologie. Si la connaissance du domaine nʹest pas fournie par la conception, alors elle pourrait être acquise par un processus dʹingénierie cognitive renversée. Enfin, le principe dans le trading sémantique est un langage de description de composant. Ce langage devrait permettre les spécifications de lʹapparence (interface) et du comportement des composants et servir également de base à lʹexpression des demandes au trader. Il y a un certain nombre de langages de description de composants déjà disponibles (par exemple voir [KIN 99]). Figure 4.3 : Architecture du service trading de composant [TER 99b]. Lʹarchitecture du service trading de composant est présentée dans la figure 3. Le point central de lʹarchitecture est le trader. Le trader reçoit des demandes de service et répond en fournissant les composants recherchés. Les demandes passent par un certain composant de prétraitement. Un certain nombre de composants de prétraitement permettent au trader de comprendre un certain nombre de formats différents pour exprimer des requètes. Ceci rend le trader plus flexible puisquʹil peut supporter plusieurs langages pour exprimer des requètes. Après que les requètes aient été transformées dans le format de base supporté, qui dépend du langage de description de composant choisi pour le trading sémantique, les requètes sont expédiées au 34

36 «traducteur». Le «traducteur» est le coeur du processus de trading sémantique. Son but est de transformer les requètes du langage de description de composant au langage de représentation de connaissance qui fournira la recherche sémantique. La traduction est faite en utilisant les termes de lʹontologie et la notion de la conformité de composant. Lʹontologie est représentée par un certain nombre de rapports entre ses termes et maintenu dans un service de rapport. La traduction mène à lʹexpansion ou à la restriction de la requète par une manière fonctionelle et sémantique saine. Puis, les requètes traduites sont employées pour rechercher les composants appropriés de lʹespace du trading. Lʹinterface des composants joue un rôle secondaire dans la phase de recherche. Quand la phase de recherche se termine, le trader doit préparer la réponse pour la requète. La préparation de la réponse à la requète est faite avec lʹappui dʹun assembleur de composant. L assembleur de composants considère les composants recherchés et une stratégie d assemblage. La stratégie d assemblage détermine comment l assemblage devrait être effectué et est soutenue par un langage script. Pendant, la phase d assemblage les composants recherchés sont empaquetés pour supporter lʹinterface requise (dans des cas plus complexes une composition pourrait être également crée). En conclusion, le service trading renvoie les composants empaquetés au client. 5. Une étude de la fonction de trading du modèle de RM ODP Les composants logiciels sont employés de plus en plus dans l ingénierie à base de composants pour la construction d applications logicielles [BRE 99, BRO 99, NCU 00]. Du fait, des avantages significatifs lors du développement d applications logicielles, comme réduire les coûts, les efforts et le temps de développement, et augmenter la fiabilité et la flexibilité du produit final. Néanmoins, les processus appropriés de recherche et de choix des composants sont devenus la pierre angulaire de nʹimporte quel développement efficace. Ces processus font face actuellement à des limitations sérieuses, bien que, généralement dues à deux raisons principales. Dʹabord, lʹinformation disponible au sujet des composants nʹest pas assez détaillée pour leur choix efficace. Et en second lieu, la recherche et les critères dʹévaluation sont habituellement trop simples pour avoir une utilité pratique. Dans le premier cas, la nature boîte noire des composants gêne la compréhension de leur comportement interne ; En outre, seulement les propriétés fonctionnelles des composants sont habituellement prises en considération, tandis que dʹautres informations cruciales au choix de composant sont absents, comme les protocoles, les ports [DES 06], les informations sémantiques [VAL 99] ou les exigences non fonctionnelles [ROS 01, CHU 99]. Dʹ autre part, les processus de recherche et d appariement de composants sont délégués aux traders, mais le problème est que les traders actuels ne fournissent pas 35

37 toutes les fonctionnalités requises pour un trading de composant efficace. Dans cette section nous analysons la fonction de trading du standard ODP et ses limitations pour les composants. De même, nous proposons une liste d exigences quʹun trader de composants doit remplir. Ces exigences ont crée les bases pour une implémentation dʹun trader pour des composants décrits par leurs ports La fonction de trading dʹodp RM ODP (Reference Model of Open Distributed Processing) est un modèle qui est conjointement développé par lʹiso (International Standard Organisation et l ITU T (International Telecommunication Union). Ce modèle défend lʹutilisation transparente des services distribués dans les plates formes et les réseaux hétérogènes et la localisation dynamique de ces services. La fonction de trading est lʹune des 24 fonctions du modèle dʹiso/itu T ODP [ISO 97]. Cette spécification a été adoptée par l OMG (Object Management Group) avec le nom de CosTrading pour le service de trading de CORBAservices. À lʹheure actuelle, plusieurs implémentations du service CosTrading sont disponibles sur le marché [ACE 00, OPE 01, ION 00, PRI 01] Rôles dʹobjet Du point de vue de la programmation orientée objet (OOP), une fonction de trading, ou simplement le trader, est un objet de logiciel qui sert dʹintermédiaire entre les objets qui assurent certaines capacités les services et dʹautres objets qui demande une utilisation dynamique de ces capacités. Du point de vue dʹodp, ces objets qui fournissent des capacités à dʹautres objets sʹappellent les exportateurs. Dʹune autre part, les objets qui demandent des capacités aux objets de systèmes sʹappellent les importateurs. Par conséquent, comme nous pouvons voir sur la figure 1, un client du processus de trading peut avoir un des rôles suivants [ISO/IEC ITU/T, 1997] : Le rôle dʹexportateur : Un objet adopte le rôle dʹexportateur quand il doit annoncer un service aux objets de systèmes. L exportation est réalisée au moyen de la méthode export() de l objet trader, plaçant correctement les paramètres pour pouvoir effectuer l enregistrement du service dans le dépôt du trader. Le rôle dʹimportateur : Un objet adopte le rôle dʹimportateur quand il exige certains services stockés dans la base du trader. L importation est réalisée au moyen de la méthode query() de l objet trading, établissant les paramètres correctement. 36

38 Considérons la figure 4.4 représentant un diagramme des transitions. Un ordre dʹinteractions peut être le suivant : En premier lieu, un objet client du trader adopte le rôle dʹexportateur parce quʹil veut annoncer un service dans le trader (1). Après (2), un autre objet client du trader exige certains services qui peuvent être offerts par le trader. Cet objet client adopte le rôle dʹimportateur, imposant ses restrictions de recherche. En conséquence (3), le trader renvoie une ou plusieurs références dʹobjets avec les instances des services souhaités, qui indiquent où ces services sont situés dans le système réparti. Enfin (4), il appartient à lʹobjet client pour choisir une des références dʹobjets proposées par le trader, et pour se connecter directement à lʹobjet qui offre le service recherché. Figure 4.4 : Les rôles du trading dʹodp. Les applications d un tel trader peuvent être multiples. Il peut servir par exemple, pour la réutilisation d applications [MIL 95], pour le rassemblement et la classification des capacités offertes dans les environnements distribués [DAV 00] ou comme buffer de serveur dʹimprimante dans le réseau [ION 00], entre autres applications Les interfaces Un objet trader a différentes interfaces qui permettent lʹinteraction avec des objets client, soulignant les interfaces Register (Registrer) et Lookup (Consultation). Lʹinterface Register décrit une opération dʹexportation (export) cela permet lʹexportation des services, entre dʹautres opérations, telles que la suppression ou la modification d un service existant. Lʹinterface Lookup contient l opération de requête (query) qui permet d extraire les références de service à partir du dépôt. 37

39 Un objet trader fonctionne avec trois genres de dépôts indépendants : (a) un dépôt dʹinterface IR (Interface Repository), (b) un dépôt où les types de service du trader sont stocké STR (Service Type Repository), et enfin (c), un dépôt d offres RO (Repository Offers) où les clients enregistrent leurs offres comme instances des services à partir des type de service dans SRT. Dans les trois sections suivantes nous allons traiter séparément ces groupes dʹinformation. Nous analyserons également un exemple de cas qui illustre le comportement décrit. Une capacité ou un service exporté par un objet client doit être associée à une interface de traitement qui répond à la fonctionnalité du service annoncé. La spécification de la fonction de trading accepte la définition des interfaces dans l IDL OMG, et est stocké dans un dépôt indépendant dʹinterfaces, IR Les types de service Un trader peut supporter différents types de services, tous stockés dans un dépôt de types de services indépendants, STR. Un service trader peut être identifié comme : <TypeName, IDL, Properties>, où TypeName est le type de service annoncé, IDL est le nom de lʹinterface dʹidl qui décrit la signature du service annoncé, et Properties est une liste de propriétés qui rassemble lʹinformation non fonctionnelle non contenue dans lʹinterface du service annoncé. En utilisant la syntaxe de spécification du trader dʹodp, un service peut être exprimé comme suit : service <ServiceTypeName>[:<ServiceTypeName>[,<ServiceTypeName>]*]{ interface <InterfaceTypeName>; [[mandatory] [readonly] property <Type> <PropertyName>;]* } Dans cette notation nous pouvons observer plusieurs caractéristiques. Un nouveau type de service peut être créé à partir des types de services déjà supportés par le trader, grâce à l héritage multiple des super types de service. En outre, un type de service exige également la déclaration dʹun nom simple dʹinterface qui encapsule les aspects informatiques de la capacité du service à annoncer. Un service peut contenir une ou plusieurs propriétés (ou attributs) qui expriment les aspects non fonctionnels, qui ne peuvent pas être recueillis par lʹinterface. Chaque propriété peut être considérée comme une liste courte : <name, type, mode>. Dans ce cas, name est le nom qui identifie la propriété, type est le type de valeur acceptée par la propriété ( par exemple les types chaine de caractère, ou entier). Bien que cette information ne puisse pas être reflétée dans les spécifications, la plupart des implémentations de la fonction de trading d ODP 38

40 utilise les types de CCM CORBA :: TypeCode, comme les fonctions de trading : ORBacus [ION 00], JavaORB [OPE 01] ou AceORB [SHM 01]. Enfin, mode représente le mode dʹaccès à la propriété déclarée. Par exemple, un accès obligatoire (mandatory) signifie quʹune valeur de propriété doit être indiquée quand une offre de ce type de service est exportée Les offres de service Un objet client peut exporter une capacité ou un service au moyen de l opération Lookup :: export. Un objet client exporte un service annonçant une offre d un type de service supporté par le trader. Alors cette offre est enregistrée dans un dépôt d offres indépendant, RO. Une offre de service peut être identifiée comme suit : <TypeName, Location, Properties>, où TypeName est le nom du type de service annoncé, Location est lʹendroit où lʹobjet qui implémente le type de service annoncé est exécuté et Properties est une liste de propriétés qui réalise la définition du type de service de TypeName. Dans ce cas, une propriété est un couple <Name, Value>, où Name est le nom de la propriété et Value est la valeur de cette propriété Un exemple Supposons que nous avons un composant logiciel qui implémente différents algorithmes pour convertir des formats dʹimage, tels que les formats gif, jpg ou png. Une interface simple pour cet exemple pourrait être comme suit : module GifImageConverter { interface Formats { string giftojpg(in string name); string giftopng(in string name); } interface GifImageConverter: Formats { enum Format {jpg, png} string GifConvert(in string name, in string format); } } Dans cet exemple, les méthodes giftojpg et giftopng utilisent et renvoient un paramètre chaîne de caractère pour indiquer le nom de chemin où lʹimage l est stockée. Suivant la syntaxe de définition du type de service dʹodp, cette interface peut être enregistrée par le trader comme suit : 39

41 service GifConverter { interface GifImageConverter; mandatory property string otherformat; mandatory property boolean colour; } Un type de service appelé GifConverter est déclaré, encapsulant lʹinterface GifImageConverter et déclarant deux propriétés additionnelles : le paramètre otherformat utilisé pour spécifier dʹautres formats de conversion ; le paramètre booléen colour indique si lʹoffre accepte des images en couleurs. Enfin, les objets client annoncent leurs implémentations particulières du type GifConverter dans le trader. Par exemple, ce qui suit représente trois offres pour le service GifConverter, qui sont annoncées par trois clients indépendants. offer GifConverter { Location object1; otherformat=" "; colour=false;} offer GifConverter { Location object2; otherformat="tif,bmp" ; colour=true;} offer GifConverter { Location object3; otherformat="bmp"; colour=true;} Dans ce cas, Location est une référence dʹobjet qui implémente le type de service fourni dans le trader ; object1 accepte les formats de conversion dans le type de service GifConverter et il ne supporte pas des images en couleurs. Les deux autres objets fournissent les implémentations qui acceptent des formats de conversion additionnels et les images en couleurs Recherche des offres Dans les sections précédentes nous avons discuté des aspects liés au rôle dʹexportateur dʹun objet. Dans cette section nous allons discuter quelques détails pour le rôle dʹimportateur. La responsabilité principale dʹun service trading est de satisfaire les demandes du client importateur, qui sont concentrées sur quatre issues, <ServiceType, Constraints, Preference, Policies>, où : (a) ServiceType, est le type de service de ces offres de client stockées dans le trader et impliquées dans le processus de recherche. Les conditions de recherche sont établies comme suit. (b) Constraints, est une expression booléenne écrite dans le langage OCL. Par exemple, lʹexpression ʺcolour==true or ʹbmpʹ otherformatʺ signifie que le trader doit 40

42 localiser des offres GifConverter, supportant les images en couleur et des formats de conversion vers les fichiers bmp. (c) Preference, indique lʹordre dans lequel les offres sont retournées au client. Le service trading d ODP supporte cinq préférences : max (ascendant), min (descendant), with (sous condition), random (aléatoire) et first (dans lʹordre normal). Par exemple, en considérant le type de service GifConverter, une préférence with(color==true)ʺ signifie que le trader renverra en premier les offres qui supportent des images en couleurs, après l évaluation de la recherche avec les conditions imposées dans les contraintes. (d) Policies, sont les politiques qui conviennent à la recherche. Par exemple, il y a des politiques qui limitent la cardinalité des ensembles d offres impliquées dans le processus de recherche du trader. La figure 4.2 montre lʹordre des tâches qui sont réalisées dans un rôle dʹimportateur. Ici, le client peut placer différentes cardinalités pour limiter le nombre dʹoffres qui doivent être considérées dans chaque étape. Figure 4.5 : Lʹordre des taches dans le rôle dʹimportateur du trader dʹodp [IRI 01] Fédération des traders La spécification du service de trading dʹodp permet à l administrateur du système de connecter son trader à dʹautres traders bien connus. Ceci permet la propagation des requêtes dans un réseau. Quand un client importateur exécute une opération de requête, le trader recherche toujours les offres dans son dépôt d offres de service. Le trader peut également envoyer la requête aux traders connectés, localisant de nouvelles offres en considérant les mêmes conditions de recherche imposées au trader cible. Dans cette fédération, un objet trader peut jouer le rôle dʹun objet client pour d autres traders. En outre, chaque trader impose ses politiques internes, qui peuvent être propagés par le client dans la demande de requête. Par exemple, comme nous pouvons le voir dans la figure 4.3, une de ces politiques limite la profondeur de la recherche ou le nombre de traders auprès desquels la demande de requête peut être propagée 41

43 (hop_count). La valeur de politique de requête diminue quand la requête est propagée dʹun trader à autre. Cette valeur doit être moins ou égale à la valeur de politique du trader courant. Figure 4.6 : Propagation dʹune requête dans une fédération de trader dʹodp [IRI 01] Exigences pour les traders de composants Dans cette section nous soulignons quelques limitations que la fonction de trading courante dʹodp présente pour les composants. Ces limitations ont été détectées sur la base de lʹexpérience obtenue à partir des implémentations commerciales existantes du service de trading [ION 00, PRI 01, SHM 01]) et sur la base de quelques travaux étroitement liés et des traders académiques [VAS 99, BEA 97, BEI 95, KUT 96, MER 94] Les Exigences du trading La liste suivante présente les dispositifs et les caractéristiques que nous pensons que les traders devraient avoir afin de fournir un service de trading de composant efficace dans les systèmes ouverts. 42

44 (i) Modèle composant hétérogène. Un trader ne devrait pas se limiter à un modèle particulier de composants, mais il devrait pouvoir (simultanément) traiter différents modèles de composant et plateformes, telles que CORBA, CCM (CORBA Component Model), EJB (Enterprise Java Beans), COM (Microsoft s Component Object Model),.NET etc. Les traders hétérogènes devraient travailler avec des protocoles multiples dʹaccès aux services, et s adapter à lʹévolution des modèles actuels. (ii) Un trader est plus quʹun moteur de recherche. Les traders peuvent ressembler superficiellement aux moteurs de recherche, mais exécuter plus de recherches structurées. Dans un trader, lʹappariement dʹheuristique nécessite la modélisation du vocabulaire, fonctions de distance et classes dʹéquivalence dans un espace de propriété spécifique au domaine, contrairement à lʹappariement basé sur les mots et un domaine neutre supporté par des moteurs de recherche. (iii) Fédération. Une coopération de traders peut être fédérée en utilisant différentes stratégies. Lʹapproche directe de fédération exige des traders de communiquer directement avec les traders quʹils fédèrent. Bien que ce soit un schéma très bloqué et commandé, les coûts généraux de communication augmentent avec le nombre de traders fédérés. Dans la fédération à base de dépôt, de multiples traders lisent et écrivent dans le même dépôt de service ; les traders ne communiquent pas directement, ainsi cette approche passe à l échelle. Le problème est lʹimplémentation dʹun dépôt globalement accessible. (iv) Service de composition et dʹadaptation. Les traders courants se concentrent sur les appariements un à un entre les requêtes de client et les instances de services disponibles. Un trader compositionnel pourrait également considérer les appariements un à plusieurs, par lequel une requête de client peut également être accomplie en composant convenablement plusieurs services disponibles, qui fournissent ensemble le service requis complet. En outre, l appariement exact un à un est également inadéquat dans un certain nombre de situations, par exemple entre le moment où le format, la QoS ou les disparités de performance se produisent entre le client et l instance de service assorti le plus étroit. Ce problème peut être résolu en composant une tellle instance de service avec des convertisseurs de format et des moniteurs de performance pour réduire les disparités. (v) Interfaces multiples. Dans les systèmes orientés objet, les services sont décrits par des interfaces, et chaque objet fournit une seule interface (bien quʹil puisse être obtenu à partir de plusieurs par l héritage multiple). Cependant, les composants peuvent simultanément offrir plusieurs interfaces, et ainsi, les services devraient être définis en termes dʹensembles dʹinterfaces. Ce fait doit être particulièrement considéré 43

45 dans l intégration des composants, puisque les conflits entre composants peuvent sembler offrir des interfaces communes [IRI 02] (vi) L appariement flexible. Les appariements exacts traditionnels entre les importations et les exportations sont très restrictifs dans les situations réelles dans lesquelles des critères d appariement plus flexiblesʹ devrait être utilisés. Ceci prend une grande importance dans les systèmes ouverts et extensibles, tels quʹinternet, où les noms de méthodes et les opérations qui composent les services offerts sont choisis de manière arbitraire et non normalisée. Par conséquent, on devrait permettre les appariements partiels qui choisissent également les candidats qui peuvent fournir (une partie d ) un service requis. (vii) Utilisation d heuristiques et de métriques (préférences). Les utilisateurs devraient être capable de spécifier des fonctions heuristiques et des métriques dans la recherche des composants, particulièrement dans le cas de l appariement flexible. (viii) Extension de la procédure de sous typage. Les traders courants organisent les services en une hiérarchie de types de services afin d effectuer l appariement de services. Le cœur de l appariement de types est la notion de sous typage. TypeA est un sous type de TypeB (TypeA <= TypeB) si les instances de TypeA peuvent se substituer aux instances du TypeB et si les clients ne peuvent pas détecter le changement [NIE 95]. Le sous typage est maintenant vérifié seulement au niveau de la signature, mais des extensions doivent être définies afin de faire face à l information comportementale [LEA 00], aux protocoles [CAN 01] et aux ports [DES 06], QoS etc. (ix) Délégation. Les traders devraient pouvoir déléguer des requêtes à dʹautres traders (plus habiles), sʹils ne peuvent pas les résoudre. La délégation de la requete complète ou seulement des parties dʹelle devrait être possible Les imperfections des traders actuels Les traders existants suivent la plupart du temps le modèle de trading dʹodp [ISO 97]. Bien que ce soit un modèle de trading complet et très bien conçu, il suit le modèle général ODP (orienté objet), et donc il présente quelques limitations une fois utilisé dans les systèmes ouverts. En fait, basé sur lʹexpérience obtenue à partir des implémentations commerciales existantes du service de trading (par exemple [ION 00, PRI 01, SHM 01]) et sur la base de quelques travaux étroitement liés et des traders académiques (par exemple [VAS 99, BEA 97, BEI 95, KUT 96, MER 94]), nous pouvons voir comment les traders courants : (1) traitent seulement avec les modèles objet homogènes; (2) utilisent la fédération directe ; (3) ne permettent pas la composition de 44

46 services ou lʹadaptation ; (4) ne fonctionnent qu avec l appariement exact, et seulement au niveau signature ; (5) ne traitent pas les interfaces multiples. 6. Conclusion De la présentation précédente il est clair que lʹutilisation du service de trading de composant dans un cadre de sélection et d assemblage de composants montre un certain nombre dʹavantages : Il simplifie la tache d assemblage d application puisquʹil permet lʹutilisation de la terminologie du domaine pour la description et la recherche des composants. Il augmente la fiabilité du code produit par l assemblage avec la génération explicite de la sémantique de lʹopération supportée par les composants. Cʹest un framework puissant d assemblage, puisquʹil nʹest pas limité par lʹapparence (interface) des composants. Nous avons aussi présenté une étude de la fonction de trading du modèle de référence ODP sur la base de lʹexpérience obtenue à partir des implémentations commerciales existantes du service de trading [ION 00, PRI 01, SHM 01]) et sur la base de quelques travaux étroitement liés et des traders académiques [VAS 99, BEA 97, BEI 95, KUT 96, MER 94]. Comme résultat de cette étude, nous pensons que la fonction de trading courante dʹodp ne sʹajuste pas sur les nécessités dʹun trader de composant. Dans cette perspective, nous avons détecté des limitations de la fonction de trading dʹodp pour les composants. Comme conclusion à cette étude, nous avons proposé une liste d exigences pour un trading de composants. Notre but principal est de concevoir un trader qui peut aider à surmonter ces limitations; Un trader spécifiquement conçu pour traiter avec des composants décrits par leurs ports. 45

47 Chapitre V. Un service de trading pour composants à partir de leurs ports 1. Introduction Le développement orienté composant produit d un intérêt accru dû au développement du logiciel réutilisable, qui a mené au concept des composants commerciaux sur l étagère. Ce paradigme déplace les préoccupations de développement dʹapplications à l assemblage dʹapplications. La construction dʹune application comporte maintenant lʹutilisation des morceaux préfabriqués, peut être développée à différentes moments, par différentes personnes et probablement avec différentes utilisations à lʹesprit. Le but final est de pouvoir réduire le temps dʹélaboration, le coût et l effort, tout en améliorant la flexibilité, la fiabilité et la réutilisabilité de lʹapplication finale due à la réutilisation des composants logiciels déjà testés et validés. Cette approche remet en cause les méthode d ingénierie logicielle classique et les outils courants. Par exemple, la méthode de développement «Waterfall» traditionnelle, basée sur des améliorations successives des exigences de système jusquʹà ce quʹune implémentation concrète appropriée des composants de lʹapplication finale soit atteinte, nʹest pas adaptée au développement à base de composants. Dans le développement orienté composant, le concepteur de système doit également tenir compte de la spécification des composants prédéveloppés qui peuvent exister dans une base de composants logiciels en établissant les exigences initiales du système, afin de les incorporer à toutes les phases du processus de développement [MIL 95, ROB 99, WAL 02]. Il y a un décalage significatif dʹune approche centrée développement vers une approche centrée fourniture, qui vise la recherche et lʹacquisition des composants afin de les réutiliser pour la construction des applications logicielles. Ici, les architectes, les concepteurs et les constructeurs doivent accepter les compensations parmi trois soucis principaux : les exigences dʹutilisateurs, lʹarchitecture de système et les composants [GAR 95] Le processus appropriés de recherche et de choix des composants sont devenus les pierres angulaires de chaque développement efficace à base de composants. Cependant, ces processus font face actuellement à des limitations sérieuses, généralement dues à trois raisons principales. Dʹabord, lʹinformation disponible sur les composants nʹest pas assez expressive pour leur choix efficace. En second lieu, la recherche et les critères d évaluations offertes par les traders courants sont habituellement trop simples pour être utiles en pratique. Enfin, les méthodologies 46

48 courantes de l ingénierie à base de composants n exploitent pas efficacement le trading pour la recherche et la localisation des composants offrant les services exigés. Dʹabord, une des questions clés dans le développement orienté composant est lʹutilisation dʹune documentation composante plus complète, plus concise et non ambiguë (c. à d. spécifications). Dans le cas des composants logiciels, leur nature de boîte noire gène la compréhension de leur comportement interne. En outre, seulement les propriétés fonctionnelles sont habituellement prises en considération, alors que autres informations cruciales pour le choix des composants est absente (protocoles, information sémantique [VAL 00], ports [DES 06] ou conditions fonctionnelles supplémentaires [ALV 01, CHU 99]). Les fournisseurs de composant logiciel sont également sans aide, fournissant des informations rares et non structurées au sujet des composants [BER 03]. En second lieu, les processus de recherche et d appariement de composant (dans la théorie) sont délégués aux traders, mais le problème est que les traders existants ne fournissent pas toute les fonctionnalités exigées pour un trading sémantique de composants efficace, comme discuté dans [TER 99a]. Enfin, les traders ne sont pas entièrement intégrés dans les méthodologies courantes pour réaliser un développement à base de composant efficace, par conséquent ils ne possèdent pas plusieurs des avantages potentiels fournis par les traders tels que la découverte de lʹinformation ou le choix partiellement automatisé des composants candidats. Dans ce chapitre, nous présentons un service de trading qui essaie dʹadresser la plupart de leurs imperfections courantes. Une extension dʹinformation utilisée pour décrire les services de composants est également présentée, où non seulement les aspects syntaxiques des interfaces sont pris en considération, mais également l exigence syntaxique de collaboration entre interfaces contenues dans les ports. Une template pour décrire les requêtes de services est également défini. Avec tout cela, il est possible dʹaméliorer les deux services des processus ʹexportationʹ et ʹimportationʹ, et de concevoir et développer des traders améliorés qui se servent de l information exprimée par les port pour localiser et rechercher les composants. 2. Services et types de service Les composants offrent des services, les clients demandent des services et les traders traitent avec des services. Par conséquent, nous devrions commencer par définir ce qu est un service. Nous adopterons ici la définition de service donnée dans la 47

49 spécification du service de trading dʹodp [ISO 96] : «Un service est un ensemble de possibilités fournies par un objet à un niveau informatique. Un service est une instance de type de service». Dans ODP, un type de service est un type de signature dʹinterface, un ensemble de définitions de propriétés et un ensemble de règles au sujet des modes des propriétés de service. Les signatures dʹinterface décrivent la fonctionnalité de service en termes dʹattributs et méthodes (ODP est orienté objet). Les propriétés de service sont des triplets (nom, type de valeur, mode), où le nom identifie la propriété (par exemple AllowEncryption), le type de valeur établit le type de valeurs permises pour la propriété (par exemple booléen) et le mode spécifie si la propriété est en lecture seule ou en lecture et écriture, ou si elle est facultative ou obligatoire. En outre, les propriétés peuvent également être déclarées comme dynamiques ce qui signifie quʹau lieu de se voir assigner une valeur fixe, elles sont associées à un évaluateur externe qui est responsable de fournir dynamiquement la valeur courante de la propriété (par exemple la longueur courante dʹune file dʹattente). Ce genre de type de service dʹodp est celui généralement utilisé dans la plupart des traders courants. Cependant, nous devons prolonger cette définition afin de permettre des descriptions plus complètes des services, et l adapter aux exigences spécifiques des systèmes à base de composants décrites par leurs ports. Dans notre contexte, un type de service se composera de trois parties principales. La première partie décrit lʹinformation syntaxique (c. à d. signature) et de port. À la différence du type de service dʹodp qui contient juste une interface, notre description fonctionnelle de service définit les ensembles de ports. Un port [OMG b, ALD 02, HAC 04, BOE 02, PRO03] est une méta information qui documente le comportement d un composant : il décrit le rôle que peut jouer ce composant dans une collaboration. Les ports bidirectionnels regroupent les interfaces fournies et requises qui sont utilisées conjointement au sein d une même collaboration. Les ports primitifs composés uniquement d interfaces ne sont pas suffisamment expressifs dans le cas de collaborations complexes. Dans [DES 06] (cf figure 2.4) une proposition d enrichir la description de composants de ports composites pour permettre de représenter tous les types de collaborations. La deuxième partie décrit les composants composites semblable au modèle Fractal. Enfin, lʹinformation sur les liaisons (bindings) entre composants et leurs sous composants est spécifiée. 48

50 3. Un Trader pour composants décrits par leurs ports Une fois que nous avons identifié les qualités que doit posséder un trader de composants à partir de leurs ports, cette section décrit l implémentation dʹun trader pour des composants décrits par leurs ports. Nous avons divisé cette section en trois parties principales. La première traite du composant et la documentation du service, c. à d. comment décrire les services fournis par les composants en termes de leurs types de service. La deuxième partie définit comment les clients peuvent émettre des requêtes au trader et exprimer les importations de service. Enfin, nous décrions le processus de trading. Nous avons utilisé XML comme langage pour documenter les composants (c. à d. descrire les services) et pour exprimer les requêtes. XML est simple, extensible et largement admis au sein de la communauté de développeurs. Afin dʹillustrer notre proposition nous utilisons un exemple simple, celui d un système bancaire doté de ports primitifs et composites. Cette architecture comporte les composants suivants : ATM, Client, Bank, Database. En dépit de sa simplicité, cet exemple nous permettra dʹillustrer notre approche pour documenter les composants, les processus dʹexportation et dʹimportation et la manière dont le tarder fonctionne Exportation des services Pour la description dʹun composant nous avons conçu certains templates de définition de type de document (DTD) basés sur les standard W3C ( Ce schéma correspond à une extension de la DTD de l ADL Fractal avec les éléments nécessaires à la description de notre modèle de composant basé sur les ports. Ces aspects sont détaillés dans l annexe A. Ce qui suit montre un exemple de squelette simple de template du schéma conçu pour le cas du composant ATMBankingSystem (des en têtes de XML sont omis dans le reste de ce document). 49

51 <?xml version="1.0"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="atmbankingsystem" > <interface>... </interface> <primitiveport>... </primitiveport> <compositeport>... </compositeport> <component>... </component> <bindinginterface>... </ bindinginterface > <bindingport>... </ bindingport > </definition> Comme nous pouvons voir dans le document XML, la description dʹun composant commence par une étiquette definition. La définition ci dessus définit le composant «ATMBankingSystem». Lʹen tête indique la version de XML, le codage utilisé, et lʹendroit du DTD de notre extension de l ADL Fractal. Puis, le corps du document décrit les six parties principales dont un type de service se compose avec les liaisons entre interfaces et ports, comme défini dans la section Description des interfaces La description fonctionnelle dʹun composant suit une approche semblable à celle de la plupart des modèles composants communs tels que CCM, EJB ou EDOC [ 27 ]. En fait, elle peut être employée pour décrire des composants de nʹimporte lequel de ces modèles. Lʹinformation contenue dans la présente partie inclut lʹensemble des interfaces que le composant fournit et lʹensemble des interfaces que le composant requiert dʹautres composants. Dans ce qui suit, une interface est définie par un nom, une signature qui détermine son type et le rôle qui peut soit une interface requise (client), soit une interface fournie (server) : <interface name=ʺdialoguesʺ role=ʺserverʺ signature=ʺdialoguesʺ/> Les composants sont assemblés en connectant les interfaces requises d un 50

52 premier composant aux interfaces fournies d un deuxième composant (et vice versa). Le niveau syntaxique fournit un contrôle minimal d un tel assemblage. Il consiste en un contrôle de compatibilité des types des interfaces connectées. Chaque interface est associée à un type qui correspond à un ensemble d opérations qu elle définit. Les types des interfaces connectées sont comparés, comme défini dans la théorie du typage utilisée dans les mécanismes de contrôle des types des langages orientés objets [DUC 02] : une interface requise doit ainsi être un super type de l interface fournie correspondante [OMG a, BRU 04, OPL 03]. Cependant, la correction syntaxique d un assemblage de composants ne garantit pas que l assemblage puisse être utilisé correctement. En effet, la correction syntaxique vérifie uniquement, sur le plan des types, que les composants seront capables d échanger de l information mais ne permet pas de savoir si les composants pourront collaborer, c est à dire s ils pourront échanger des informations ordonnées en séquences formant un dialogue cohérent et leur permettant de fournir les services attendus Description des ports primitifs Un port [OMG b, ALD 02, HAC 04, BOE 02, PRO 03] est une méta information qui documente le comportement d un composant : il décrit le rôle que peut jouer ce composant dans une collaboration. Les ports bidirectionnels regroupent les interfaces fournies et requises qui sont utilisées conjointement au sein d une même collaboration. Dans ce qui suit, un port primitif est défini par un nom et par la liste des nterfaces qu il comporte : <primitiveport name="queresr" interfaces="questionssr ResponsesCR" /> La connexion de deux ports réalise, en une seule opération, la connexion de toutes les interfaces requises (resp. fournies) d un port vers les interfaces fournies (resp. requises) du port connecté. Deux ports sont syntaxiquement compatibles si toutes les interfaces (fournies et requises) de l un trouvent dans l autre une interface compatible Description des ports composites Les ports primitifs, composés uniquement d interfaces, ne sont pas suffisamment expressifs dans le cas de collaborations complexes. Dans [DES 06] (cf figure 2.4) une proposition d enrichir la description de composants de ports composites pour permettre de représenter tous les types de collaborations. Dans ce qui suit, un port composite est défini par un nom et par la liste des ports 51

53 (primitifs ou composites) qu il contient : <compositeport name="diamoncontra" ports="diamon ConTra" /> Pour exprimer les dépendances fonctionnelles sans contraindre l assemblage de façon excessive, la connexion de ports composites impose la connexion de ses ports composants, mais n impose pas qu ils soient connectés à un même composant Description des composants composites Un composant composite peut être défini en spécifiant les interfaces quʹil fournit, les interfaces qu il requit, ces ports primitifs et composites, les sous composants qu il contient, et les bindings entre ces sous composants, et le composant composite luimême: <component name="bank" > <interface name="queryc" role="client" signature="queryc"/> <interface name="controls" role="server" signature="controls"/> <interface name="transactions" role="server" signature="transactions"/> <primitiveport name="quec" interfaces="queryc" /> <primitiveport name="tracon" interfaces="controls TransactionS" /> <compositeport name="quetracon" ports="quec TraCon" /> </component> Description des bindings des interfaces Le binding d interfaces spécifie les connexions entre interfaces, en indiquant l interface requise et l interface fournie. Pour chaque interface, on mentionne en premier le composant, puis la séquence de ports dont elle est membre, en commençant des ports composites au port primitif : <bindinginterface client="client.mondia.dialoguec" server="atm.diamoncontra.diamon.dialogues"/> Description des bindings des ports Le binding de ports spécifie les connexions entre ports, en indiquant les deux ports participants à la connexion. Pour chaque port on mentionne, en premier le composant, puis la séquence de ports composites dont il est membre: <bindingport port1="client.mondia" port2="atm.diamoncontra.diamon"/> 52

54 3.2. Importation des services Une fois que nous avons décrit comment documenter les services d un composant, cette section discute comment les importer, c. à d. comment un client peut les localiser en utilisant le service du trader. Afin dʹimporter un service, le client doit fournir un document XML pour décrire les caractéristiques du service exigé. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE componentquery SYSTEM "componentquery.dtd"> <componentquery name="atmsystembanking" > <query component="atm"> <interface>... </interface> <primitiveport>... </primitiveport> <compositeport>... </compositeport> </query> <query>... </query> </componentquery> Une requête d importation est définie par un nom, ce dernier désignera aussi l architecture résultante aprés le processus de trading. Cette requête contient des sous requêtes, chacune regroupe les descriptions des interfaces,ports primitifs et composites appartenant à un même composant. Le shéma de la DTD de ce document XML d importation est donnée dans l annexe B Le processus de trading Notre trader est une implémentation dʹun service de trading qui fournit une correspendance entre une requête du client (c. à d. une opération dʹimportation) et un ensemble de composants qui peuvent agir en tant que fournisseurs de service valides pour cette requête (candidats dʹexportateur). Nous avons déjà discuté la notation pour des services dʹexportation et dʹimportations, au moyen de documents XML. Dans cette 53

55 section, nous discuterons comment le processus de trading fonctionne, et comment les clients potentiels peuvent se servir avec. Notre implémentation du trader se compose de deux interfaces principales : Register et Lookup, semblables à celles supporté par le trader dʹodp. module Trader { interface Register { boolean export (in string XMLComponent, in string userid, out string results ); boolean withdraw(in string XMLComponent, in string userid, out string results ); boolean replace (in string oldxmlcomponent, in string olduserid, in string newxmlcotscomponent, in string newuserid, out string results ); }; interface Lookup { boolean query (in string XMLcomponentQuery, in long MaxCandidates, out long nhits, out string templates, out string results); }; }; Les trois méthodes de l interface Register permettent lʹenregistrement dʹun document XMLComponent dans le trader, le dépôt, son déplacement et la mise à jour de cette information respectivement. Toutes les méthodes renvoient TRUE si lʹopération réussit, FALSE si elle échoue. Le paramètre results contient une description dans le cas d un échec. L interface Lookup comporte seulement lʹopération de requête, utilisée pour rechercher les composants. En plus du template componentquery avec les critères de sélection, lʹutilisateur peut indiquer le nombre maximum des candidats à retourner. Cette opération renvoie le nombre services trouvés et une chaine de caractère avec la séquence des templates XMLComponent, pour chaque composant trouvé. Notre implémentation courante du Trader garde juste une base de données avec les documents XML enregistrés, qui sert de son dépôt. Dans ce sens, c est juste une implémentation de prototype pour valider la faisabilité de notre proposition. Etant donné une bibliothèque de composants et un objectif fonctionnel, nous 54

56 désignerons par objectif fonctionnel l ensemble des fonctionnalités, identifiées par l architecte, qui doivent être supportées par une architecture. L objectif de cette phase est de produire une architecture décrite par notre extension de l ADL Fractal. Cette architecture doit satisfaire l objectif fonctionnel, elle contient les descriptions des composants participants trouvés à chaque étape d importation et les connexions entre ces composants. On considère l objectif fonctionnel comme requête d mportation vers le trader. Cette requête est décrite par un document XML respectant le schéma de la DTD componentquery,le tableau suivant (cf figure 5.1) montre les différents formats que peut avoir l objectif fonctionnel par rapport à notre modèle de composant qui supporte les ports primitifs et composites. La requête d importation suit le format de l objectif fonctionnel. Interfaces Ports primitifs Ports composites Objectif fonctionnel Ensemble d interfaces Ensemble de ports primitifs Ensemble de ports composites Figure 5.1 : Différents formats de l objectif fonctionnel. Une fois une requête d importation est reçue, le trader recherche dans la bibliothèque en essayant de comparer les descriptions de composants existants avec les descriptions exigées dans l objectif fonctionnel. Lʹalgorithme actuellement codé par le trader pour l appariement avec une template componentquery Q comparée avec une template T du bibliothèque (par conséquent comprenant T dans la liste de candidats pour cette requête) exécute les étapes suivantes : (i) En premier on cherche dans la bibliothèque un composant candidat qui satisfait l objectif fonctionnel, l appariement se fait par compatibilité de type. (ii) On essaye de connecter les interfaces, port primitifs et composites compatibles. Ces derniers seront supprimés de la requête. (iii) On ajoute à la requête Q les nouvelles descriptions contenues dans le composant choisi et qui ne sont pas satisfaites (l ensemble des interfaces, ports primitifs et ports composites non connecté). 55

57 (iii) On répète ce processus jusqu à ce que l objectf fonctionnel soit satisfait (tous les interfaces et ports soient connectés) ou n y ait pas de composant candidats. Dans ce dernier cas, les interfaces et ports non connectés sont ressortis comme éléments de l architecture résultante. Un exemple de déroulement de ce processus est détaillé dans l annexe C. 4. Choix du type de SGBD : XML ou relationnel Un choix important (et plus discutable dans lʹétat actuel des standards et des réalisations logicielles) a été de choisir une base de données XML native. Comme nous utilisons le standard XML comme format dʹéchange (Importation et exportation de documentation de composants), nous disposons donc de deux solutions : Soit mettre un ʺwrapperʺ entre XML et une base de données relationnelle, cʹest à dire implémenter un mécanisme permettant de stocker des documents XML dans une base relationnelle de façon transparente. La majorité des SGBD commerciaux (Oracle ou DB2 d IBM, SQL server) offrent ce service. Les SGBD gratuits (Mysql, PostGreSQL) commencent à intégrer cette fonctionnalité. Soit utiliser directement une base de données traitant nativement du XML. Nous avons testé deux bases XML natives gratuites et open source : Exist [EXI 06] et Xindice [XIN 06] supportant les technologies XPath et XQuery et XUpdate (seulement pour Exist pour le moment). Nous avons choisi la deuxième solution (la base de données Xindice) car (i) les bases XML natives commencent à être matures et (ii) la structure de la base de données n est pas statique contrairement aux bases relationnelles : on peut avoir dans la même collection, des documents de structures différentes. Lors dʹun ajout ou dʹune modification, on peut ou non valider un document XML suivant un schéma et l utilisation de Xpath comme langage de requête pour le processus d importation. 5. Conclusion Dans ce chapitre, nous avons proposé un service de trading pour la construction d applications logicielles à l'aide de composants décrits par leurs ports. Cette proposition se doit en partie à la nécessité d'unir trois domaines dans l ingénierie des composants : les architectures logicielles, la documentation et la spécification des composants, et le processus de trading. 56

58 VI. Conclusion et perspectives Le développement orienté composant vise la construction des systèmes logiciels en recherchant, en choisissant, en adaptant et en intégrant les composants logiciels. Dans un monde où la complexité des applications augmente sans interruption, et la quantité de lʹinformation disponible devient trop volumineuse pour être manipulée par des intermédiaires humains, des processus de trading automatisés doivent jouer un rôle critique. Notre travail a été lié et coordonné avec les travaux de recherche d une thèse de l équipe où j ai été intégré. Ses travaux se rapportent à la «construction assistée d architecture». Les résultats acquis sont décrits dans [DES 06]. La contribution de ces travaux consiste à fournir à l architecte trois niveaux d assistance à la construction d architectures. Le premier propose les ports primitifs et composites comme concepts représentant les collaborations potentielles entre composants. Le deuxième constitue une aide semi automatique basée sur la propriété de quasi validité des architectures, qui est une condition nécessaire à leur validité. Le troisième niveau constitue une aide automatique qui fournit à l architecte l ensemble des (ou, dans le cas où la combinatoire est trop élevée, une sélection de bonnes) architectures quasi valides fonctionnellement satisfaisantes. Notre sujet se situe dans la recherche de composants qui consiste à préparer le travail préliminaire à l assemblage de composants. Nos travaux ont pris en considération ces résultats, pour permettre une meilleure coordination avec ceux menés dans [DES 06]. Cette coordination s articule autour du modèle de composants conçu à l issue de ces travaux, qui intègre les ports primitifs et composites pour un assemblage cohérent. Ce modèle nous a amené à orienter notre travail dans ce cadre, qui introduit les notions de ports primitifs et composites, qui constituent un enrichissement des modèles de composants usuels. Nous les proposons comme concepts de granularité adaptée pour assister l architecte lors de la sélection des composants à connecter pour construire une architecture. Plus riches que les simples interfaces, ils véhiculent de l information sur les collaborations que les composants sont susceptibles d établir entre eux. Plus synthétiques et lisibles que les protocoles, ils contiennent tout de même une information 57

59 sur les dépendances entre interfaces, pertinentes pour assister le choix des composants. Les ports primitifs et les ports composites représentent ainsi une abstraction des collaborations potentielles et des dépendances. Notre recherche a intégré ces notions qui nous ont permis d affiner notre analyse et de l orienter vers la recherche des composants décrits par leurs ports. Nos travaux ont consisté à utiliser le trading comme un système de pages jaunes pour la recherche et la sélection de composants décrits par leurs ports. Pour cela nous avons étendu le schéma de la DTD de l ADL Fractal comme un modèle de documentation de composant. Pour les requêtes d importation on utilise un document XML qui comprend la description de l objectif fonctionnel dont les interfaces, ports primitifs et composites. Pour l expérimentation on a implémenté un prototype qui utilise comme SGBD une base de données XML native. Cette dernière permet l enregistrement de la documentation XML des composants pour l étape de l exportation. Pour l importation de composants on utilise notre modèle de document d importation conçu avec l appui du langage de requête XPath supporté par ce type de SGBD. Nous envisageons plusieurs perspectives pour ce travail tels que : L utilisation d un outil graphique permettant de décrire l objectif fonctionnel sous forme graphique et sa transformation dans un document qui respecte notre modèle de requête d importation, avec l utilisation du langage SVG ( Scalable Vector Graphics ). Ainsi que l implémentation de notre extension de l ADL Fractal pour permettre la génération du code des composants. Parmi d autres extensions possibles à notre travail, notamment, le trader peut compléter certaines des exigences décrites dans le chapitre 4, mais qui ne sont pas toutes mises en application. Quelques issues demeurent ouvertes, comme la substitution dynamique de composants, la définition et lʹutilisation des fonctions heuristiques ou la délégation de requête. Le trading sémantique nʹest pas couvert par notre proposition, puisque nous ne traitons pas actuellement les concepts, les ontologies ou le trading basé sur la connaissance. De même, nous avons construit des ponts à dʹautres traders existants. Lʹidée est de pouvoir relier notre trader de composants à dʹautres services de trading attachés à l ingénierie de composants, visant la fourniture d un service de trading plus complet et plus global. 58

60 Annexes 59

61 Annexe A: Extension du schéma de lʹadl Fractal Une DTD (Déclaration de Type de Document) définit la structure dʹun document, les éléments et attributs qui y sont autorisés, et le type de contenu ou dʹattribut permis. Elle fait la différence entre un document bien formé et un document valide : le premier répond aux exigences de la spécification, tandis que le second se conforme strictement aux règles établies par la DTD à laquelle il fait référence. Le tableau suivant montre les extensions ajoutées à la DTD du modèle Fractal avec les éléments nécessaires à la description de notre modèle de composant basé sur les ports. Extension de l ADL Fractal vers les ports <!ELEMENT definition (interface*,primitiveport*,compositeport*,component*, bindinginterface*,bindingport*,content?,attributes?, controller?,template-controller?) > <!ATTLIST definition name CDATA #REQUIRED extends CDATA #IMPLIED > Modèle Fractal ( //org/objectweb/fractal/adl/xml/basic.dtd ) Composant <!ELEMENT definition (interface*,component*,binding*,content?,attributes?, controller?,template-controller?) > <!ATTLIST definition name CDATA #REQUIRED extends CDATA #IMPLIED > Composant composite <!ELEMENT component (interface*,primitiveport*,compositeport*,component*,binding Interface*,bindingPort*,content?,attributes?, controller?,template-controller?) > <!ATTLIST component name CDATA #REQUIRED definition CDATA #IMPLIED > <!ELEMENT component (interface*,component*,binding*,content?,attributes?, controller?,template-controller?) > <!ATTLIST component name CDATA #REQUIRED definition CDATA #IMPLIED > Interface <!ELEMENT interface EMPTY > <!ATTLIST interface name ID #REQUIRED role (client server) #IMPLIED signature CDATA #IMPLIED contingency (mandatory optional) #IMPLIED cardinality (singleton collection) #IMPLIED > <!ELEMENT interface EMPTY > <!ATTLIST interface name CDATA #REQUIRED role (client server) #IMPLIED signature CDATA #IMPLIED contingency (mandatory optional) #IMPLIED cardinality (singleton collection) #IMPLIED > 60

62 <!ELEMENT primitiveport EMPTY> <!ATTLIST primitiveport name ID #REQUIRED interfaces IDREFS #REQUIRED > Ports primitive et composite <!ELEMENT compositeport EMPTY > <!ATTLIST compositeport name ID #REQUIRED ports IDREFS #REQUIRED > Binding d interfaces <!ELEMENT bindinginterface EMPTY > <!ATTLIST bindinginterface client CDATA #REQUIRED server CDATA #REQUIRED > <!ELEMENT binding EMPTY > <!ATTLIST binding client CDATA #REQUIRED server CDATA #REQUIRED > Binding des ports <!ELEMENT bindingport EMPTY> <!ATTLIST bindingport port1 CDATA #REQUIRED port2 CDATA #REQUIRED > <!ELEMENT attribute EMPTY > <!ATTLIST attribute name CDATA #REQUIRED value CDATA #REQUIRED > <!ELEMENT controller EMPTY > <!ATTLIST controller desc CDATA #REQUIRED > <!ELEMENT template-controller EMPTY > <!ATTLIST template-controller desc CDATA #REQUIRED > <!ELEMENT content EMPTY > <!ATTLIST content class CDATA #REQUIRED > <!ELEMENT attribute EMPTY > <!ATTLIST attribute name CDATA #REQUIRED value CDATA #REQUIRED > <!ELEMENT controller EMPTY > <!ATTLIST controller desc CDATA #REQUIRED > <!ELEMENT template-controller EMPTY > <!ATTLIST template-controller desc CDATA #REQUIRED > <!ELEMENT content EMPTY > <!ATTLIST content class CDATA #REQUIRED > 61

63 Annexe B : Schéma du document XML de la requête d importation <?xml encoding="iso "?> <!ELEMENT componentquery (query)*> <!ATTLIST componentquery name CDATA #REQUIRED> <!ELEMENT query (interface*,primitiveport*,compositeport*)> <!ATTLIST query component CDATA #IMPLIED> <!ELEMENT interface EMPTY> <!ATTLIST interface name ID #REQUIRED role (client server) #IMPLIED signature CDATA #IMPLIED contingency (mandatory optional) #IMPLIED cardinality (singleton collection) #IMPLIED primitiveport CDATA #IMPLIED compositeport CDATA #IMPLIED> <!ELEMENT primitiveport EMPTY> <!ATTLIST primitiveport name CDATA #REQUIRED interfaces CDATA #REQUIRED compositeport CDATA #IMPLIED> <!ELEMENT compositeport EMPTY> <!ATTLIST compositeport name CDATA #REQUIRED ports CDATA #REQUIRED> 62

64 Annexe C : Déroulement d un exemple d application B.1. Exemple d un système bancaire L exemple de la figure C.1 décrit les ccomposants d un système bancaire dotés de ports primitifs et composites [DES 06]. Figure C.1 : Composants de système bancaire dotés de ports primitifs et composites 63

65 B.2. Description des composants Pour cet exemple on va décrire chaque composant qui participe dans le système, par sa documentation en XML valide à l extension de la DTD de l ADL Fractal. Le composant ʺClientʺ <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="client" > <interface name="moneys" role="server" signature="moneys"/> <interface name="dialoguec" role="client" signature="dialoguec"/> <primitiveport name="mondia" interfaces="moneys DialogueC" /> </definition> Le composant ʺATMʺ <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="atm" > <interface name="dialogues" role="server" signature="dialogues"/> <interface name="moneyc" role="client" signature="moneyc"/> <interface name="questionss" role="server" signature="questionss"/> <interface name="responsesc" role="client" signature="responsesc"/> <interface name="controlc" role="client" signature="controlc"/> <interface name="transactionc" role="client" signature="transactionc"/> <interface name="restockings" role="server" signature="restockings"/> <interface name="needsc" role="client" signature="needsc"/> <primitiveport name="diamon" interfaces="dialogues MoneyC" /> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" /> 64

66 <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </definition> Le composant ʺBankʺ <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="bank" > <interface name="queryc" role="client" signature="queryc"/> <interface name="controls" role="server" signature="controls"/> <interface name="transactions" role="server" signature="transactions"/> <primitiveport name="quec" interfaces="queryc" /> <primitiveport name="tracon" interfaces="controls TransactionS" /> <compositeport name="quetracon" ports="quec TraCon" /> </definition> Le composant ʺDataBaseʺ <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="database" > <interface name="querys" role="server" signature="querys"/> <primitiveport name="ques" interfaces="querys" /> </definition> 65

67 B.3. L objectif fonctionnel Interfaces Ports primitifs Ports composites Objectif fonctionnel Ensemble d interfaces Ensemble de ports primitifs Ensemble de ports composites 66

68 B.4. Déroulement de l exemple 0 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE componentquery SYSTEM "componentquery.dtd"> componentquery Ports connectés Architecture résultante <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <componentquery name="atmsystembanking"> <query> <interface name="dialogues" role="server" signature="dialogues" /> </query> </componentquery> Requête xpath = "//interface[@signature='dialogues' Résultat <?xml version="1.0"?> <interface name="dialogues" role="server" signature="dialogues" xmlns:src=" src:col="/db/componentcollection/atm" src:key="atm.xml" /> <definition name="atmsystembanking" > <component name="atm" > <interface name="dialogues" role="server" signature="dialogues"/> <interface name="moneyc" role="client" signature="moneyc"/> <interface name="questionss" role="server" signature="questionss"/> <interface name="responsesc" role="client" signature="responsesc"/> <interface name="controlc" role="client" signature="controlc"/> <interface name="transactionc" role="client" signature="transactionc"/> <interface name="restockings" role="server" signature="restockings"/> <interface name="needsc" role="client" signature="needsc"/> <primitiveport name="diamon" interfaces="dialogues MoneyC" /> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" /> <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </component> </definition> 67

69 1 ère itération <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE componentquery SYSTEM "componentquery.dtd"> <componentquery name="atmsystembanking" > <query component="atm"> <interface name="dialogues" role="server" signature="dialogues" primitiveport="diamon" compositeport="diamoncontra"/> <interface name="moneyc" role="client" signature="moneyc" primitiveport="diamon" compositeport="diamoncontra"/> <interface name="questionss" role="server" signature="questionss" primitiveport="queres"/> <interface name="responsesc" role="client" signature="responsesc" primitiveport="queres"/> <interface name="controlc" role="client" signature="controlc" primitiveport="contra" compositeport="diamoncontra"/> <interface name="transactionc" role="client" signature="transactionc" primitiveport="contra" compositeport="diamoncontra"/> <interface name="restockings" role="server" signature="restockings" primitiveport="resnee"/> <interface name="needsc" role="client" signature="needsc" primitiveport="resnee"/> <primitiveport name="diamon" interfaces="dialogues MoneyC" compositeport="diamoncontra"/> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" compositeport="diamoncontra"/> <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </query> </componentquery> <bindingport port1="client.mondia" port2="atm.diamoncon Tra.DiaMon"/> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="atmsystembanking" > <component name="atm" > <interface name="dialogues" role="server" signature="dialogues"/> <interface name="moneyc" role="client" signature="moneyc"/> <interface name="questionss" role="server" signature="questionss"/> <interface name="responsesc" role="client" signature="responsesc"/> <interface name="controlc" role="client" signature="controlc"/> <interface name="transactionc" role="client" signature="transactionc"/> <interface name="restockings" role="server" signature="restockings"/> <interface name="needsc" role="client" signature="needsc"/> <primitiveport name="diamon" interfaces="dialogues MoneyC" /> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" /> <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </component> <component name="client" > <interface name="moneys" role="server" signature="moneys"/> <interface name="dialoguec" role="client" signature="dialoguec"/> <primitiveport name="mondia" interfaces="moneys DialogueC" /> </component> <bindinginterface client="client.mondia.dialoguec" server="atm.diamoncontra.diamon.dialogues"/> <bindinginterface client="atm.diamoncontra.diamon.moneyc" server="client.mondia.moneys"/> <bindingport port1="client.mondia" port2="atm.diamoncontra.diamon"/> </definition> 68

70 2 ème itération <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE componentquery SYSTEM "componentquery.dtd"> <componentquery name="atmsystembanking" > <query component="atm"> <interface name="questionss" role="server" signature="questionss" primitiveport="queres"/> <interface name="responsesc" role="client" signature="responsesc" primitiveport="queres"/> <interface name="controlc" role="client" signature="controlc" primitiveport="contra" compositeport="diamoncontra"/> <interface name="transactionc" role="client" signature="transactionc" primitiveport="contra" compositeport="diamoncontra"/> <interface name="restockings" role="server" signature="restockings" primitiveport="resnee"/> <interface name="needsc" role="client" signature="needsc" primitiveport="resnee"/> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" compositeport="diamoncontra"/> <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </query> </componentquery> <bindingport port1="atm.diamoncon Tra.ConTra" port2="bank.quetracon. TraCon"/> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="atmsystembanking" > <component name="atm" > <interface name="dialogues" role="server" signature="dialogues"/> <interface name="moneyc" role="client" signature="moneyc"/> <interface name="questionss" role="server" signature="questionss"/> <interface name="responsesc" role="client" signature="responsesc"/> <interface name="controlc" role="client" signature="controlc"/> <interface name="transactionc" role="client" signature="transactionc"/> <interface name="restockings" role="server" signature="restockings"/> <interface name="needsc" role="client" signature="needsc"/> <primitiveport name="diamon" interfaces="dialogues MoneyC" /> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" /> <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </component> <component name="client" > <interface name="moneys" role="server" signature="moneys"/> <interface name="dialoguec" role="client" signature="dialoguec"/> <primitiveport name="mondia" interfaces="moneys DialogueC" /> </component> <component name="bank" > <interface name="queryc" role="client" signature="queryc"/> <interface name="controls" role="server" signature="controls"/> <interface name="transactions" role="server" signature="transactions"/> <primitiveport name="quec" interfaces="queryc" /> <primitiveport name="tracon" interfaces="controls TransactionS" /> <compositeport name="quetracon" ports="quec TraCon" /> </component> <bindinginterface client="client.mondia.dialoguec" server="atm.diamoncontra.diamon.dialogues"/> <bindinginterface client="atm.diamoncontra.diamon.moneyc" server="client.mondia.moneys"/> <bindinginterface client="atm.diamoncontra.contra.controlc" server="bank.quetracon.tracon.moneys"/> <bindinginterface client="atm.diamoncontra.contra.transactionc" server="bank.quetracon.tracon.transactions"/> <bindingport port1="client.mondia" port2="atm.diamoncontra.diamon"/> <bindingport port1="atm.diamoncontra.contra" port2="bank.quetracon.tracon"/> </definition> 69

71 3 ème itération <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE componentquery SYSTEM "componentquery.dtd"> <componentquery name="atmsystembanking" > <query component="atm"> <interface name="questionss" role="server" signature="questionss" primitiveport="queres"/> <interface name="responsesc" role="client" signature="responsesc" primitiveport="queres"/> <interface name="restockings" role="server" signature="restockings" primitiveport="resnee"/> <interface name="needsc" role="client" signature="needsc" primitiveport="resnee"/> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="resnee" interfaces="restockings NeedsC" /> </query> <query component="bank" > <interface name="queryc" role="client" signature="queryc"/> <primitiveport name="quec" interfaces="queryc" /> <compositeport name="quetracon" ports="quec TraCon" /> </query> </componentquery> <bindingport port1="bank.quetracon. QueC" port2="database.ques"/> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="atmsystembanking" > <component name="atm" > <interface name="dialogues" role="server" signature="dialogues"/> <interface name="moneyc" role="client" signature="moneyc"/> <interface name="questionss" role="server" signature="questionss"/> <interface name="responsesc" role="client" signature="responsesc"/> <interface name="controlc" role="client" signature="controlc"/> <interface name="transactionc" role="client" signature="transactionc"/> <interface name="restockings" role="server" signature="restockings"/> <interface name="needsc" role="client" signature="needsc"/> <primitiveport name="diamon" interfaces="dialogues MoneyC" /> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" /> <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </component> <component name="client" > <interface name="moneys" role="server" signature="moneys"/> <interface name="dialoguec" role="client" signature="dialoguec"/> <primitiveport name="mondia" interfaces="moneys DialogueC" /> </component> <component name="bank" > <interface name="queryc" role="client" signature="queryc"/> <interface name="controls" role="server" signature="controls"/> <interface name="transactions" role="server" signature="transactions"/> <primitiveport name="quec" interfaces="queryc" /> <primitiveport name="tracon" interfaces="controls TransactionS" /> <compositeport name="quetracon" ports="quec TraCon" /> </component> <component name="database" > <interface name="querys" role="server" signature="querys"/> <primitiveport name="ques" interfaces="querys" /> </component> <bindinginterface client="client.mondia.dialoguec" server="atm.diamoncontra.diamon.dialogues"/> <bindinginterface client="atm.diamoncontra.diamon.moneyc" server="client.mondia.moneys"/> <bindinginterface client="atm.diamoncontra.contra.controlc" server="bank.quetracon.tracon.moneys"/> <bindinginterface client="atm.diamoncontra.contra.transactionc" server="bank.quetracon.tracon.transactions"/> <bindinginterface client="bank.quetracon.quec" server="database.ques.querys"/> <bindingport port1="client.mondia" port2="atm.diamoncontra.diamon"/> <bindingport port1="atm.diamoncontra.contra" port2="bank.quetracon.tracon"/> <bindingport port1="bank.quetracon.quec" port2="database.ques"/> </definition> 70

72 4 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE componentquery SYSTEM "componentquery.dtd"> <componentquery name="atmsystembanking" > <query component="atm"> <interface name="questionss" role="server" signature="questionss" primitiveport="queres"/> <interface name="responsesc" role="client" signature="responsesc" primitiveport="queres"/> <interface name="restockings" role="server" signature="restockings" primitiveport="resnee"/> <interface name="needsc" role="client" signature="needsc" primitiveport="resnee"/> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="resnee" interfaces="restockings NeedsC" /> </query> </componentquery> <bindingport port1="this.queres" port2="atm.queres"/> <bindingport port1="this.queres" port2="atm.queres"/> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="atmsystembanking" > <component name="atm" > <interface name="dialogues" role="server" signature="dialogues"/> <interface name="moneyc" role="client" signature="moneyc"/> <interface name="questionss" role="server" signature="questionss"/> <interface name="responsesc" role="client" signature="responsesc"/> <interface name="controlc" role="client" signature="controlc"/> <interface name="transactionc" role="client" signature="transactionc"/> <interface name="restockings" role="server" signature="restockings"/> <interface name="needsc" role="client" signature="needsc"/> <primitiveport name="diamon" interfaces="dialogues MoneyC" /> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" /> <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </component> <component name="client" > <interface name="moneys" role="server" signature="moneys"/> <interface name="dialoguec" role="client" signature="dialoguec"/> <primitiveport name="mondia" interfaces="moneys DialogueC" /> </component> <component name="bank" > <interface name="queryc" role="client" signature="queryc"/> <interface name="controls" role="server" signature="controls"/> <interface name="transactions" role="server" signature="transactions"/> <primitiveport name="quec" interfaces="queryc" /> <primitiveport name="tracon" interfaces="controls TransactionS" /> <compositeport name="quetracon" ports="quec TraCon" /> </component> <component name="database" > <interface name="querys" role="server" signature="querys"/> <primitiveport name="ques" interfaces="querys" /> </component> <bindinginterface client="client.mondia.dialoguec" server="atm.diamoncontra.diamon.dialogues"/> <bindinginterface client="atm.diamoncontra.diamon.moneyc" server="client.mondia.moneys"/> <bindinginterface client="atm.diamoncontra.contra.controlc" server="bank.quetracon.tracon.moneys"/> <bindinginterface client="atm.diamoncontra.contra.transactionc" server="bank.quetracon.tracon.transactions"/> <bindinginterface client="bank.quetracon.quec" server="database.ques.querys"/> <bindinginterface client="this.queresr.responsescr" server="atm.queres.responsesc"/> <bindinginterface client="this.queresr.questionssr" server="atm.queres.questionss"/> <bindinginterface client="this.resneer.restockingsr" server="atm.resnee.restockings"/> 71

73 <bindinginterface client="this.queres.responsescr" server="atm.queres.responsesc"/> <bindingport port1="client.mondia" port2="atm.diamoncontra.diamon"/> <bindingport port1="atm.diamoncontra.contra" port2="bank.quetracon.tracon"/> <bindingport port1="bank.quetracon.quec" port2="database.ques"/> <bindingport port1="this.queres" port2="atm.queres"/> <bindingport port1="this.queres" port2="atm.queres"/> </definition> B.5. L architecture du système bancaire après assemblage des composants <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE definition SYSTEM "DTDComponent.dtd"> <definition name="atmbankingsystem" > <interface name="questionssr" role="server" /> <interface name="responsescr" role="client" /> <interface name="restockingsr" role="server" /> <interface name="needscr" role="client" /> <primitiveport name="queresr" interfaces="questionssr ResponsesCR" /> <primitiveport name="resneer" interfaces="restockingsr NeedsCR" /> <component name="client" > <interface name="moneys" role="server" signature="moneys"/> <interface name="dialoguec" role="client" signature="dialoguec"/> <primitiveport name="mondia" interfaces="moneys DialogueC" /> </component> <component name="atm" > <interface name="dialogues" role="server" signature="dialogues"/> <interface name="moneyc" role="client" signature="moneyc"/> <interface name="questionss" role="server" signature="questionss"/> <interface name="responsesc" role="client" signature="responsesc"/> <interface name="controlc" role="client" signature="controlc"/> 72

74 <interface name="transactionc" role="client" signature="transactionc"/> <interface name="restockings" role="server" signature="restockings"/> <interface name="needsc" role="client" signature="needsc"/> <primitiveport name="diamon" interfaces="dialogues MoneyC" /> <primitiveport name="queres" interfaces="questionss ResponsesC" /> <primitiveport name="contra" interfaces="controlc TransactionC" /> <primitiveport name="resnee" interfaces="restockings NeedsC" /> <compositeport name="diamoncontra" ports="diamon ConTra" /> </component> <component name="bank" > <interface name="queryc" role="client" signature="queryc"/> <interface name="controls" role="server" signature="controls"/> <interface name="transactions" role="server" signature="transactions"/> <primitiveport name="quec" interfaces="queryc" /> <primitiveport name="tracon" interfaces="controls TransactionS" /> <compositeport name="quetracon" ports="quec TraCon" /> </component> <component name="database" > <interface name="querys" role="server" signature="querys"/> <primitiveport name="ques" interfaces="querys" /> </component> <bindinginterface client="client.mondia.dialoguec" server="atm.diamoncontra.diamon.dialogues"/> <bindinginterface client="atm.diamoncontra.diamon.moneyc" server="client.mondia.moneys"/> <bindinginterface client="atm.diamoncontra.contra.controlc" server="bank.quetracon.tracon.moneys"/> <bindinginterface client="atm.diamoncontra.contra.transactionc" server="bank.quetracon.tracon.transactions"/> <bindinginterface client="bank.quetracon.quec" server="database.ques.querys"/> <bindinginterface client="this.queresr.responsescr" server="atm.queres.responsesc"/> <bindinginterface client="this.queresr.questionssr" server="atm.queres.questionss"/> <bindinginterface client="this.resneer.restockingsr" server="atm.resnee.restockings"/> <bindinginterface client="this.queres.responsescr" server="atm.queres.responsesc"/> <bindingport port1="client.mondia" port2="atm.diamoncontra.diamon"/> 73

75 <bindingport port1="atm.diamoncontra.contra" port2="bank.quetracon.tracon"/> <bindingport port1="bank.quetracon.quec" port2="database.ques"/> <bindingport port1="this.queres" port2="atm.queres"/> <bindingport port1="this.queres" port2="atm.queres"/> </definition> 74

76 Annexe D : Feuille de style XSL pour le schéma XML de composants Ce schéma permet de transformer la documentation des composants décrite dans le langage XML vers une présentation plus lisible en format HTML, à l aide du langage XSLT. XSLT est un langage de règles utilisé par les processeurs XSLT. Il permet de travailler sur le contenu d un document XML. Il offre la possibilité de le transformer en divers documents XML ayant des structures différents. Outre cette transformation il permet également de générer des formats tels que HTML. <?xml version="1.0"?> <!-- ############################################################################### # File name : XSLComponent.xsl # # Document : Compoment Style Template # # Url : # # Modified : June, 2006 # ############################################################################### --> <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="html" doctype-public ="-//W3C//DTD HTML 4.0 Transitional//EN"/> <xsl:template match="/"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso "/> <title> Component Template </title> </head> <body> <table BORDER="0" COLS="1" WIDTH="100%" > <tr> <h1> <b> Component Template: </b> <xsl:value-of select="definition/@name"/> </h1> </tr> </table> <xsl:for-each select="definition"> <xsl:apply-templates/> </xsl:for-each> 75

77 <table BORDER="0" COLS="1" WIDTH="100%" > <tr><td></td></tr><tr><td></td></tr><tr><td></td></tr> </table> <hr WIDTH="100%"/> <table BORDER="0" COLS="1" WIDTH="100%" > <tr> <td><font size="-1">(c) 2006, Page generated by <A </td> </tr> </table> </body> </html> </xsl:template> <!-- ###################################################################### --> <!-- --> <!-- Global style templates --> <!-- --> <!-- ###################################################################### --> <!-- ###################################################################### --> <!-- Style for Interfaces --> <!-- ###################################################################### --> <xsl:template match="interface"> <h3> Interface : <xsl:value-of select="@name"/> </h3> <li> <b>role : </b> <xsl:value-of select="@role"/> </li> <li> <b>signature : </b> <xsl:value-of select="@signature"/> </li> <xsl:apply-templates/> </xsl:template> 76

78 <!-- ###################################################################### --> <!-- Style for Primitive Ports --> <!-- ###################################################################### --> <xsl:template match="primitiveport"> <h3>primitive port : <xsl:value-of select="@name"/> </h3> <u1> <li> <b>interfaces : </b> <xsl:value-of select="@interfaces"/> </li> </u1> <xsl:apply-templates/> </xsl:template> <!-- ###################################################################### --> <!-- Style for Composite Port --> <!-- ###################################################################### --> <xsl:template match="compositeport"> <h3>composite port : <xsl:value-of select="@name"/> </h3> <u1> <li> <b>ports : </b> <xsl:value-of select="@ports"/> </li> </u1> <xsl:apply-templates/> </xsl:template> <! > </xsl:stylesheet> 77

79 VII. Bibliographie [ALD 02] ALDRICH J., CHAMBERS C., NOTKIN D., ArchJava : connecting software architecture to implementation, ICSE 02 : Proceedings of the 24th Int. Conf. on Software Engineering, New York, NY, USA, 2002, ACM Press, p [ALV 01] Alves, C. F., Rosa, N. S., Cunha, P. R. F., Castro, J. F. B. and Justo, G. R. R. (2001) Using non functional requirements to select components: a formal approach. In Proc. Fourth Iberoamerican Workshop on Requirements Engineering and Software Environments (IDEAS 01), San José, Costa Rica, April 3 6. Instituto Technológico de Costa Rica. [ATK 95] S. Atkinson and R. Duke. Behavioural retrieval from class libraries. Australian Computer Science Communications, 17(1), pages 13 20, January [BAR 02] Barbier F., Cauvet C., Oussalah M., Rieu D., Bennasri S., Souveyet C., Composants dans l Ingénierie des Systèmes d Information : Concepts clés et techniques de réutilisation, Assises du GDR I3, Nancy, Décembre [BAS 00] Bastide, R. and Sy, O. (2000). Towards Components that Plug AND Play. In Vallecillo, A., Hern_andez, J., and Troya, J. M., editors, ECOOPʹ2000 Workshop on Object Interoperability (WOIʹ00), pages [BEA 97] Bearman, M. (1997) Tutorial on ODP Trading Function. Faculty of Information Sciences Engineering, University of Canberra, Australia. [BEI 95] Beitz, A. and Bearman, M. (1995) An ODP trading service for DCE. In Proc. First Int. Workshop on Services in Distributed and Networked Environments (SDNE), Prague, Czech Republic, June 27 28, pp IEEE Computer Society Press. [BER 03] Bertoa, M. F., Troya, J. M. and Vallecillo, V. (2003) A survey on the quality information provided by software component vendors. In Proc. 7th ECOOP Workshop on Quantitative Approaches in Object Oriented Software Engineering (QAOOSE 2003), Darmstadt, Germany, July 21 25, pp Universidade Nova de Lisboa. [BOE 02] DE BOER F. S., JACOB J. F., BONSANGUE M. M., The OMEGA Component model, Deliverable of the IST OMEGA project, [BOO 74] A. Bookstein and D. Swanson. Probabilistic models for automatic indexing. Journal of the American Society for Information science. Vol. 25, N 5, pages , [BRE 99] Brereton, P., Budgen, D., Bennet, K., Munro, M., Layzell, P., MaCaulay, L., Gri_ths, D., and Stannett, C. (1999). The Future of Software. 78

80 Communications of the ACM, 42(12): [BRO 99] Brown, A. W. and Wallnau, K. C. (1999). The Current State of CBSE. IEEE Software, 15(5): [BRU 04] Bruneton E., Coupaye T., Leclercq M., Quema V., Stéfani J. B., An Open Component Model and Its Support in Java, Proceedings of the International Symposium on Component based Software Engineering, Edinburgh, Scotland, May [BUC 92] C. Buckley, G. Salton, J. Allan. Automatic Retrieval with Locality Information using SMART. In TREC 1 Proceedings, pages , [CAN 01] Canal, C., Fuentes, L., Troya, J. M., and Vallecillo, A. (2001). Extending CORBA Interfaces with Protocols. The Computer Journal, 44(5):448{462. [CAU 99] Cauvet C., et Semmak F., La réutilisation dans l ingénierie des systèmes d information, chapitre 1, Génie objet, analyse et conception de l évolution, M. Oussalah Ed, Hermès, [CHU 99] Chung, L., Nixon, B., Yu, E., and Mylopoulos, J. (1999). Non Functional Requirements in Software Engineering. Kluwer Academic Publishers. [COP 95] J. Coplien, D. Schmidt, Pattern Languages of Program Design. Addison Wesley Publishing Company, [CRO 79] W. B. Croft and D.J. Harper. Using Probabilistic Models of Document Retrieval without Relevance Information. Journal of Documentation, pages , vol. 35, [CYB 93] Cybulski J. L. and Reed K., The Use of Templates and Restricted English in Structuring and Analysis of Informal Requirement Specifications, AAITP Technical Report TR024, [DES 93] Jean Pierre Deschrevel, «The ANSA Model for Trading and Federation», Architecture Report APM , Approved 15 July [DAV 00] Davidrajuh, R. (2000). Automating Supplier Selection Procedures. PhD thesis, Narvik Institute of Technology. Norwegian University of Science and Technology. [DES 06] Nicolas Desnos, Christelle Urtado, Sylvain Vauttier, Marianne Huchard Assistance à lʹarchitecte pour la construction dʹarchitectures à base de composants. Actes de Langages et Modèles à Objets (LMO 2006), R. Rouseau, C. Urtado, S. Vauttier, Editors, mars 2006, Nîmes, France, Lavoisier 2006, ISBN , pp37 52 [DHA 96] Dhara, K. K. and Leavens, G. T. (1996). Forcing Behavioral Subtyping Through Speci_cation Inheritance. In 18th International Conference on Software Engineering (ICSE 18), pages 258{267, Berlin, Germany. IEEE Press. [DUC 02] DUCOURNAU R., «Real World as an Argument for Covariant 79

81 Specialization in Programming and Modeling», Advances in Object Oriented Information Systems, OOIS 02 workshops, no 2426 LNCS, Springer, 2002, p [EXI 06] Exist DB, (consulté en 2006). [FIN 98] Finch L., So Much OO, So Little Reuse. Dr. Dobbʹs Journal, mai 1998, [GAR 90] Garg P., Scacchi W., A hypertext system to manage software life cycle documents, IEEE software, pp , mai [GAR 95] Garlan, D., Allen, R. and Ockerbloom, J. (1995) Architectural mismatch: why reuse is so hard. IEEE Softw., 12, [GAM 95] E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns Elements of Reusable Oriented Software. Addison Wesley, [GIR 95] M. R. Girardi. Classification and Retrieval of Software through their Descriptions in Natural Language, Ph.D. dissertation, No. 2782, University of Geneva, December [GOL 84]. Goldberg A., SMALLTALK 80: the interactive programming environment, Addison Wesley Longman Publishing Co., Inc.,Boston, MA, [GRO 01] Grosso W., Java RMI, OʹReilly, [HAC 04] HACKLINGER F., Java/A Taking Components into Java, IASSE, 2004, p [HAL 93] R. J. Hall. Generalized behaviour based retrieval. In Proceedings of the 15th International Conference on Software Engineering, pages , May [HEM 01] D. Hemer and P. Lindsay. Specification based Retrieval Strategies for Module Reuse. In D. Grant and L. Sterling, editors, Proceedings 2001 Australian Software Engineering Conference, August 2001, Canberra, Australia, pages , IEEE Computer Society, [HUL 94] Hull D., Information Retrieval using Statistical Classification.Thèse de doctorat, Université de stanford, [ION 00] IONA (2000) ORBacus trader. ORBacus for C++ and Java. Object Oriented Concepts, Inc., IONA. [IRI 01] L. Iribarne and Antonio Vallecillo. (2001) Study of the RM ODP trading function. Previous technical report to the EUROMICRO Conference. TR CBSE 01. Department of Lenguajes y Computación. University of Almería, Spain. [IRI 02] Iribarne L., Un modelo de mediacion para el desarrolo de software basado en componentes COTS, Thesis in university ofalmeria,2002. [ISO 96] ISO/IEC 13235, ITU T X.9tr (1996) Information Technology Open Distributed Processing ODP Trading Function. International Organization for Standarization and International Telecommunication Union. 80

82 [ISO 97] ISO/IEC ITU/T (1997). Information Technology Open Distributed Processing Trading function: Specification. ISO/IEC , UIT T X.950. [JEN 93] Jeng J. J., Cheng B. H. C., Using formal methods to construct a software component library, In Ian Sommerville and Manfred Paul, editors, Proceedings of the Fourth European Software Engineering Conference, pages Springer Verlag, [JIL 97] L. L. Jilani, J. Desharnais, M. Frappier, R. Mili, and A. Mili. ʺRetrieving Software Components That Minimize Adaptation Effort,ʺ in Proceedings of the 12th Automated Software Engineering Conference, pp , Nov [KHA 05] O. Khayati. Modèles formels et outils génériques pour la gestion et la recherche de composants. Thèse en Informatique à l Université Joseph Fourier (Grenoble), décembre [KIN 99] J.R. Kiniry, «CDL: A Component Description Language», submitted to the Advanced Topics Workshop (ATW) of the 5 th USENIX Conference on Object Oriented Technologies and Systems (COOTS 99), March W/cdl/cdl.html [KON 95] Konstantas, D. (1995). Interoperation of Object Oriented Applications. In Nierstrasz, O. and Tsichritzis, D., editors, Object Oriented Software Composition, pages Prentice Hall. [KUT 96] Kutvonen, L. (1996) Overview of the DRYAD trading system implementation. In IFIP/IEEE Int. Conf. on Distributed Platforms, New York, USA, May 21 23, pp Chapman and Hall. [LAT 88] Latroue L., Jhonson E., Seer: A graphical retrieval system for reusable ADA software module, Proceedings of International IEEE Conference on ADA Application environments, IEEE Computer Society Press, pages , [LEA 00] Leavens, G. T. and Sitaraman, M. (2000) Foundations of Component Based Systems. Cambridge University Press. [MER 94] Merz, M., Muller, K. and Lamersdorf, W. (1994) Service Trading and Mediation in Distributed Computing Systems. In Proc. 14th Int. Conf. on Distributed Computing Systems, Poznan, Poland, June 21 24, pp IEEE Computer Society Press. [MEY 97] (Meyer, 1997) Meyer B., Object Oriented Software Construction, Prentice 81

83 Hall, second edition, [MIL 95] Mili, H., Mili, F., and Mili, A. (1995). Reusing Software: Issues and Research Directions. IEEE Transactions on Software Engineering, 21(6): [NCU 00] Ncube, C. and Maiden, N. (2000). COTS software selection: The need to make tradeoffs between system requirements, architectures and COTS components. In COTS workshop. Continuing Collaborations for Successful COTS Development. [NIE 90] J. Nie et Y. Chiaramella. A Retrieval Model based on an Extented Modal Logic and its Application to the RIME Experimental Approach, ACM SIGIR 90, Bruxelles, Belgique, [NIE 95] Nierstrasz, O. (1995) Regular types for active objects. In Nierstrasz, O., and Tsichritzis, D. (eds), Object Oriented Software Composition. Prentice Hall, pp [NUS 01] Nuseibeh, B. (2001) Weaving together requirements and architectures. IEEE Comp., 34, [OMG a] OMG, «CORBA Components, Version 3.0», http :// pdf. [OMG b] OMG, Unified Modeling Language : Superstructure, version 2.0, ptc/ , http :// [OMG 99] OMG (1999). The CORBA Component Model. Object Management Group. [OPE 01] OpenORB (2001). The OpenORB web site. Distributed Object Group. [OPL 03] OPLUSTIL T., «Inheritance in Architecture Description Languages», Reviewed section of Proceedings of the Week of Doctoral Students 2003 conference (WDS 2003), Matfyzpress, Prague, Czech Republic, June 2003, p [ORF 98] Orfali R., Harkey D., Client/Server Programming with Java and CORBA, 2nd Edition, John Wiley & Sons, March [PER 00] Pernici B., Mecella M., Batini C., Conceptual Modeling and Software Components Reuse: Towards the Unification. In Solvberg A., Brinkkemper S., Lindencrona E. (eds.):information Systems Engineering: State of the Art andresearch Themes. Springer Verlag, [PIT 01] Pitt E., McNiff K., Java RMI: The Remote Method Invocation Guide, Addison Wesley, [POD 92] A. Podgurski and L. Pierce. Behaviour sampling: A technique for 82

84 automated retrieval of reusable components. In Proceedings of the 14th International Conference on Software Engineering, pages , [PRI 01] PrismTech (2001). Trading Service White Paper. PrismTech Open Fusion,Enterprise Integration Services. [PRI 87] R. Prieto Diaz, and P. Freeman. Classifying Software for Reusability. IEEE Software, 4(1), pages 6 16, [PRO 03] PROJECT A., Abstract model of contract based component assembly, ACCORD RNTL project number 4 deliverable, 2003, (in french). [ROB 99] Robertson, S. and Robertson, J. (1999) Mastering the Requirement Process. Addison Wesley and ACM Press. [ROS 01] Rosa, N. S., Alves, C. F., Cunha, P. R. F., and Castro, J. F. B. (2001). Using Non Functional Requirements to Select Components: A Formal Approach. In Fourth Iberoamerican on Requirements Engineering and Software Environments (IDEASʹ2001). San José, Costa Rica. [SAL 83] G. Salton and M.J. McGill. Introduction to modern information retrieval, McGraw hill book company, New York, [SAL 83a] G. Salton, E. A. Fox, and H. Wu. Extended Boolean Information Retrieval, Vol. 36, No. 11, December 1983, Communication of the ACM, pp [SHM 01] Shmidt, D. C. (2001) AceORB (TAO). The Adaptative Communication Environment. Department of Computer Science and Engineering,Washington University, USA. [SZY 98] Szyperski, C. (1998) Component Software. Beyond Object Oriented Programming. Addison Wesley Professional. [TER 99a] S. Terzis and P. Nixon, Semantic Trading: Tackling Interoperability Problems during System Integration, A. Vallecillo, J. Hernandez and J.M. Troya (eds.), ʺObject Interoperabilityʺ, Dept. of Languages and Computer Science, University of Malaga (1999). [TER 99b] S. Terzis and P. Nixon, Component Trading: The basis for a Component Oriented Development Framework, J. Bosch, C. Szyperski and W. Weck (eds.), Proceedings of the 4 th International Workshop on Component Oriented Programming, Research Report 17/99, Dept. of Computer Science and Software Engineering, University of Karlskrona/Ronneby (1999). [TRA 97] Tran, V. and Liu, T. (1997) A procurement centric model for engineering component based software systems. In Proc. Fifth Int. Symp. on Assessment of Software Tools, Pittsburgh, PA, USA, June 3 5, pp IEEE 83

85 Computer Society Press. [VAL 00] Vallecillo, A., Hernández, J. and Troya, J. M. (2000) New issues in object interoperability. In Object Oriented Technology: ECOOP 2000 Workshop Reader, Lecture Notes in Computer Science, 1964, Sophia Antipolis and Cannes, France, June 12 16, pp Springer Verlag. [VAL 99] Vallecillo, A., Hern_andez, J., and Troya, J. M. (1999). Object Interoperability. In Object Oriented Technology: ECOOPʹ99 Workshop Reader, number 1743 in LNCS, pages 1{21. Springer Verlag. [VAS 99] Vasudevan, V. and Bannon, T. (1999). WebTrader: Discovery and Programmed Access to Web Based Services. In Poster at the 8th International WWW Conference (WWW8), Toronto, Canada. UPhttp:// reports/9812 web trader paperup /WebTraderPaper.html. [VIL 03] Villalobos J., Fédération de composants : une architecture logicielle pour la composition par coordination. Thèse en Informatique à l Université Joseph Fourier (Grenoble), juillet [WAL 02] Wallnau, K. C., Hissam, S. A. and Seacord, R. C. (2002) Building Systems from Commercial Components. Addison Wesley, Boston. [XIN 06] Xindice, (consulté en 2006). [YEL 97] [Yellin, D. M. and Strom, R. E. (1997). Protocol Specifications and Component Adaptors. ACM Transactions on Programming Languages and Systems, 19(2): [ZAR 93] A. M. Zaremski and J. M. Wing. Signature matching: A key to reuse. Technical Report CMU CS , Carnegie Mellon University, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213, May [ZAR 95] A. M. Zaremski and J. M. Wing. Specification Matching of Software Components. In Proceeding. Third Symposium on the Foundations of Software Engineering (FSE3), pages 17, ACM SIGSOFT, October [ZHA 00] Z. Zhang, L. Svensson, U. Snis, C. Srensen, H. Fgerlind, T. Lindroth, M. Magnusson, C. Stlund. Enhancing Component Reuse Using Search Techniques, Proceedings of IRIS 23. Laboratorium for Interaction Technology, University of Trollhttan Uddevalla, 84

86 RÉSUMÉ Dans un processus de développement à base de composants, la sélection et l assemblage de composants logiciels incombent à l architecte. Dans ce contexte la présence des processus pour la recherche et la sélection de composant devient impérative pour remplir les exigences architecturales de la future application. Ces processus sont gênés par de nombreux problèmes à tous les niveaux dʹinteropérabilité. Ce travail propose d utiliser le trading de composants décrits par les ports primitifs et composites, qui fournissent un niveau d information intermédiaire. Il s appuie sur une information décrivant les collaborations potentielles entre composants, plus riche que les seules interfaces fournies et requises et plus simple et synthétique que les protocoles. MOTS CLÉS : Développement à base de composants, recherche de composants, trading de composants, ports primitifs et composites. ABSTRACT During a component based development process, the architect selects and assembles software components. In this context, the presence of processes for searching and selection components becomes imperative to fulfill architectural requirements of the future application. These processes are hindered by numerous problems at all levels of interoperability. This work proposes the use of trading for components described with primitive and composite ports that provide an intermediary compatibility level. It is based on information about potential collaborations between components that are both richer than the usual provided and required interfaces and simpler and more synthetic than full protocols. KEYWORDS: Component based software, components retrieval, component trading, primitive and composite ports. 85