Un modèle d'assemblage de composants par Contrat et ...

THÈSE DE DOCTORAT DU CONSERVATOIRE NATIONAL DES ARTS ET MÉTIERS - CNAM - Spécialité : INFORMATIQUE Présentée par LEGOND-AUBRY Fabrice Sujet de la thèse Un modèle d’assemblage de composants par Contrat et Programmation Orientée Aspect Soutenue le 11 juillet 2005, devant le jury composé de : M. Florin Gérard Professeur au Conservatoire National des Arts et Métiers, CEDRIC Directeur M. Seinturier Lionel Maître de conférence à l’Université Paris VI, LIP6 Encadrant M. Estublier Jacky Directeur de recherche CNRS, IMAG LSR Rapporteur M. Sadou Salah Maître de conférence HDR à l’Université de Bretagne Sud, Valoria Rapp M. Gressier Eric Professeur au Conservatoire National des Arts et Métiers, CEDRIC Examinateur M. Girault Claude à l’Université Paris VI, LIP6 M. Traverson Bruno EDF/GDF, Ingénieur Recherche à la division R& D InvitéUn modèle d’assemblage de composants par Contrat et Programmation Orientée Aspect Résumé de la thèse La taille croissante des applications et la multitude de leurs interconnexions rendent de plus en plus difficile leur conception. Les composants offrent une couche d’abstraction qui améliore leurs mises en interactions et isole le code pour améliorer la portabilité et l’inter-opérabilité. Cependant les composants souffrent d’une grande complexité de déploiement et d’un manque d’outils pour la description de leurs assemblages et de leurs dépendances. Actuellement, il n’existe pas de solution industrielle standardisée pour permettre l’assemblage et l’extension des composants. Il faut utiliser des outils spécifiques non compatibles ou des plates-formes à composants dédiées. Nous proposons une méthode pour faciliter l’assemblage et la réutilisation de ces entités trop souvent considérées comme de simples serveurs. Nous introduisons les notions de dépendance, de connecteur, de demi-contrats et de contrats entre composants qui nous permettent d’expliciter des règles d’assemblage utilisées ensuite pour garantir la correction du système formé. Nous projetons ensuite ces contrats sur des plates-formes composants existantes. La Programma- tion Orientée Aspect (POA) nous permet d’injecter le code dans les composants sans en modifier le code source et en conservant la compatibilité avec la multitude de plates-formes existantes. La POA nous permet aussi par extension d’implanter des services non fonctionnels au niveau métier des composants sur des plates-formes tel que EJB et CCM. Nous avons mis en œuvre cette approche avec l’étude d’un service de contrôle comportementale des composants. Ce service nous permet, au cours de l’exécution, de vérifier la conformité des composants avec leur spécification. Mots Clés : Contrats, Composition, Assemblage, Composants, Programmation Orientée Aspect (POA), EJB, CCMAn aspect oriented, contract aware, component model Abstract Components are more and more widely used to create complex distributed systems. One finds them invariousapplicationslikedata-processingapplications,intensivecalculationapplications,information systemsapplications,oreveninembeddedsystems.Theirreusablestructuremadethemvaluedentities to create applications. However, the "design by component" is a new method for which the entities composition raises several difficulties. On the contrary to the object oriented programming which carries out a downward analysis of the problems, the components form reusable elements that the designers can assemble to create an application. The design by component remains however a new technology and the composition rules of these entities are not well defined. The interaction between components often requires the correct following of a strict protocol. The interactionbondsevolvebetweenthecomponentsduringtheexecution.Thus,itisgenerallyimpossible to validate these relations during the conception phase. So, we present a method to ease the assembly and the re-use of these entities too frequently consideredassimpleserverswhichlimitstheircapacityofcollectiveaction.Weintroduceadependency concept and a notion of contract between components which enable us to clarify rules of assembly and, then, use them to guarantee the correction of the formed system. We project these contracts on component platforms. Our proposed solution is based on the aspect oriented programming (AOP) which enables us to inject additional code in the components without modifying their source code. Thanks to this aspect oriented programming aware component platform, we can check, at runtime, the execution flow of a component based application. The AOP also enables us by extension to add non-functional services on the functional components code of multiple components platforms such as EJB or CCM. Keywords:Contracts,Composition,Assembly,Components,aspectorientedprogramming(AOP), delegationTable des matières I Introduction 1 1 Introduction 3 1.1 Thème de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Une implémentation utilisant des concepts de plus en plus abstraits . . . . . . . . . . . 4 1.3 De nouvelles abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1 Les composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2 L’utilisation de la modélisation et des contrats . . . . . . . . . . . . . . . . . . 6 1.3.3 La séparation des préoccupations et la POA . . . . . . . . . . . . . . . . . . . . 8 1.4 Une solution globale et générique est-elle possible? . . . . . . . . . . . . . . . . . . . . 10 1.5 Objectifs et plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.1 Les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5.2 Notre solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5.3 Le plan de thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 II État de l’art 15 2 Etat de l’art 17 2.1 Différents axes de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Les plates-formes à composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.1 La notion de composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.2 Les composants "Enterprise Java Beans" (EJB) . . . . . . . . . . . . . . . . . . 21 2.2.2.1 Architecture générale du modèle EJB 2.0 . . . . . . . . . . . . . . . . 22 2.2.2.2 Les composants EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2.3 Détails de l’architecture d’une plate-forme EJB . . . . . . . . . . . . . 24 2.2.2.4 Les différents types de composants EJB . . . . . . . . . . . . . . . . . 24 vvi 2.2.2.5 Déploiement et assemblage . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.2.6 Evaluation du modèle EJB . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.2.7 Ouvertures du modèle EJB 3.0 . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3 Les composants "Corba Component Model" (CCM) . . . . . . . . . . . . . . . 30 2.2.3.1 Le middleware CORBA, support de CCM . . . . . . . . . . . . . . . . 30 2.2.3.2 Le modèle CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.2.3.3 Le Composant CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.2.3.4 L’interface home dans CCM . . . . . . . . . . . . . . . . . . . . . . . 36 2.2.3.5 Déploiement, assemblage et exécution . . . . . . . . . . . . . . . . . . 36 2.2.3.6 Evaluation du modèle CCM . . . . . . . . . . . . . . . . . . . . . . . 37 2.2.4 JavaPod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.2.4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.2.4.2 La composition dans JavaPod . . . . . . . . . . . . . . . . . . . . . . 39 2.2.4.3 Evaluation de Javapod . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.2.5 Tableau résumé sur les composants . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.3 La Programmation Orientée Aspect (POA) . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.1 Principes de la POA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.2 AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.2.1 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.3.2.2 Définitions des aspects . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.3.2.3 Quelques subtilités concernant les pointcuts . . . . . . . . . . . . . . 47 2.3.2.4 Evaluation d’AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.3 JAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.3.1 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.3.3.2 Outils de transformations de code . . . . . . . . . . . . . . . . . . . . 49 2.3.3.3 Mécanismes internes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3.3.4 Définition des aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3.3.5 Evaluation de JAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.3.4 AspectWerkz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.4.1 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.4.2 Définition des aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.4.3 Evaluation d’AspectWerkz . . . . . . . . . . . . . . . . . . . . . . . . 56 2.3.5 Tableau résumé sur la POA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.4 Outils de modélisation et d’assemblage . . . . . . . . . . . . . . . . . . . . . . . . . . . 56vii 2.4.1 Unified Modeling Language : Objectifs . . . . . . . . . . . . . . . . . . . . . . . 58 2.4.2 Une modélisation du monde objet : UML 1.x . . . . . . . . . . . . . . . . . . . 58 2.4.2.1 Les éléments d’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.4.2.2 UML 1.x et les composants . . . . . . . . . . . . . . . . . . . . . . . . 61 2