1 / 75

LOG4430 : Architecture logicielle et conception avancée

LOG4430 : Architecture logicielle et conception avancée. Composition et architectures par composants. Composition et architectures par composants. Mise en contexte Introduction aux composants logiciels Le modèle de composants Fractal Lectures à faire. 1. Contexte.

brendan-wagner
Télécharger la présentation

LOG4430 : Architecture logicielle et conception avancée

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LOG4430 :Architecture logicielle et conception avancée Composition et architectures par composants

  2. Composition et architectures par composants • Mise en contexte • Introduction aux composants logiciels • Le modèle de composants Fractal • Lectures à faire

  3. 1. Contexte • Limitations des architecture à objets • Complexité du chargement dynamique • Ad hoc • Solution partielle des cadre de références et autres plugiciels

  4. 1. Introduction Contexte : ingénierie du système/intergiciel (middleware) • Les entreprises et les organisations construisent maintenant des systèmes d'information globaux intégrant des applications jusqu'ici indépendantes, ainsi que des développements nouveaux. Ce processus d'intégration doit tenir compte des applications dites patrimoniales (en anglais : legacy), qui ont été developpées avant l'avènement des standards ouverts actuels, utilisent des outils « propriétaires », et nécessitent des environnements spécifiques. • Une application patrimoniale ne peut être utilisée qu‘à travers une interface specifiée, et ne peut être modifiée. La plupart du temps, l'application doit être reprise telle quelle car le coût de sa réécriture serait prohibitif. • Le principe des solutions actuelles est d'adopter une norme commune, non liée a un langage particulier, pour interconnecter différentes applications. La norme spécifie des interfaces et des protocoles d'échange pour la communication entre applications. • Les protocoles sont realisees par une couche logicielle qui fonctionne comme un bus d'echanges entre applications: c’est l’ intergiciel (middleware) [http://sardes.inrialpes.fr/ecole/2006/chapitre1.pdf]

  5. 1. Introduction • Passé (année 1990) : objet • mouvance « à la CORBA:Common Object Request Broker Architecture » • CORBA en 5 points: • Toutes les méthodes sont virtuelles ; il n'y a ni polymorphisme paramétrique, ni méthode protégée ou privée,… • Chaque composant est décrit sous la forme d'une interface écrite en langage IDL • Une correspondance a été spécifiée entre le langage IDL et différents langages de programmation • Des précompilateurs dédiés permettent de générer automatiquement le squelette de l'interface IDL dans un langage donné (code pour appels distants et traitements de résultats: stub et skeleton) • Applications et composants Corba mélangent typages statique et dynamique: les composants sont décrits statiquement par une interface mais les composants qui utilisent celui-ci doivent vérifier dynamiquement que l'interface est effectivement implantée.

  6. 1. Introduction • Besoins • configuration • déploiement • empaquetage (packaging) • assemblage • dynamicité • gestion des interactions et des dépendances • Présent : plusieurs tendances • composant, aspect, MDE, réflexivité

  7. 1. Introduction • Composant vs objet • plus haut niveau abstraction • meilleure encapsulation, protection, autonomie • programmation + systématique + vérifiable • communications plus explicites • port, interface, connecteur • connectables • schéma de connexion (ADL) : « plan » applicatif • séparation « métier » - technique • meilleure converture du cycle de vie • conception, implémentation, packaging, déploiement, exécution

  8. 1. Introduction • Définition composant • 1ère apparition terme [McIlroy 68] • 30 ans + tard : Sun EJB, OMG CCM, MS .NET/COM+, … • recensement [Szyperski 02] : 11 définitions +/- ≡ • A component is a unit of composition with contractuallyspecifiedinterfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties. [Szyperski 97]

  9. 1. Introduction Nombreux modèles de composant (20+) • construits au-dessus Java, C, C++ • EJB, Java Beans, CCM, COM+, JMX, OSGi, SCA, CCA, SF, SOM • Fractal, K-Component, Comet, Kilim, OpenCOM, FuseJ, Jiazzi, SOFA, ArticBeans, Draco, Wcomp, Rubus, PACC-Pin, OLAN, Newton, COSMOS, Java/A, HK2, Koala, PECOS, Knit, nesC, saveCCM, CAmkES • Technologies utilisant les modèles de composants: • Bonobo, Carbon, Plexus, Spring, Avalon • Au niveau analyse/conception : UML2

  10. 1. Introduction Conséquence de la multiplicité des modèles • multiplicité du vocabulaire • composant, bean, bundle • interface/liaison, port/connecteur, facette, puits, source • requis/fourni, client/serveur, export/import, service/référence • conteneur, membrane, services techniques, contrôleur • Framework (cadriciel), serveur d’applications • grande variabilité dans les propriétés attachées aux notions • exemples • Fractal : composant, interface, liaison, client/serveur • CCM : composant, facette, port, puits, source • UML 2 : composant, fragment, port, interface • OSGi : bundle, package importé/exporté, service/référence • un même terme peut avoir des acceptations ≠ selon les modèles • qualifier les notions (« connecteur au sens … ») • pas toujours facile de définir les équivalences

  11. interface requise fournie composant liaison 1. Introduction 1ère grande catégorie de modèle de composants • Triptyque : composant, interface, liaison • un composant fourni et/ou requiert une ou plusieurs interfaces • une liaison est un chemin de communicationentre une interface requise et une interface fournie

  12. connecteur composant 1. Introduction 2ème grande catégorie de modèle de composants • triptyque : composant, port, connecteur • un composant fourni et/ou requiert une ou plusieurs ports • un connecteur implémente un schéma de communication entre des composants (client/serveur, diffusion, etc.) • un composant est relié à un connecteur via un ou plusieurs ports • connecteur  liaison avec comportement • on peut considérerconnecteur = composant (de communication) • composant, interface, liaison

  13. Application Middleware 1. Introduction Classification des modèles pour système/intergiciel • application : EJB, CCM, .NET/COM+, SCA, Spring • middleware : Fractal, JMX, OpenCOM, OSGi • middleware componentisé pour applications à base de composants • JonasALaCarte : Fractal + EJB [Abdellatif 05] • OSGi + EJB [Desertot 05]

  14. 1. Introduction Quelques « poncifs » à propos des composants • COTS (Commercial Off The Shelf) • Les composants peuvent être réutilisés • Réduction des coûts de fabrication et de maintenance • mais quid de la contractualisation ? • « Programming in the large » • vs « programming in the small » (objet) • vrai d’un certain point de vue • mais nouveaux points à traiter (liés au non fonctionnel par ex.)

  15. 2. Le modèle Fractal • FT R&D, INRIA • open source • http://fractal.ow2.org • Historique • fin 2000 : premières réflexions autour de Fractal • 06/2002 • 1ère version stable API • implémentation de référence (Julia) • 1ère version de l’ADL • 01/2004 • définition de l’ADL v2 (ADL extensible) • implémentation disponible 03/2004

  16. 2. Le modèle Fractal • ingénierie des systèmes et du middleware • suffisamment général pour être appliqué à tout autre domaine • grain fin (wrt EJB ou CCM) proche d’un modèle de classe • léger (surcoût faible par rapport aux objets) • indépendant des langages de programmation • vision homogène des couches (OS, middleware, services, applications) • Fractal everywhere • dans le but de faciliter et d’unifier • conception, développement, déploiement, administration

  17. 2. Le modèle Fractal • ouvert et adaptable • les services extra-fonctionnels peuvent être personnalisés • il n’y a pas une seule “forme” de composants Fractal • 2 usages possibles avec Fractal • framework de composants pour construire des applications/systèmes • on utilise la forme “standard” des composants Fractal • framework de frameworks de composants • on construit d’autres “formes” de composants • avec introspection minimale et aggregation simple (à la COM) • avec contrôleurs de liaison et de cycle de vie (à la OSGi) • avec hiérarchie à 2 niveaux et liaison (à la SCA) • avec des liaisons multicast (à la CCA) • avec des contrôleurs d’attribut (à la MBean) • avec des contrôleurs de persistance et de transaction (à la EJB) • … • on développe des applications avec ces autres “formes”

  18. 2. Le modèle Fractal • Différent plateformes • 3 en Java • Julia implémentation de référence • AOKell aspects + componentisation des membranes • ProActive composants actifs pour les grilles • 2 en C (Think, Cecilia), • 1 en C++ (Plasma), • 1 en SmallTalk (FracTalk), • 1 pour .NET (FractNet) • ≠ implémentations pour ≠ besoins

  19. 2. Le modèle Fractal Exemple de middleware/applications développées avec Fractal • comanche : serveur Web • Speedo : persistance données Sun JDO [Chassande 05] • GoTM : moniteur transactionnel [Rouvoy 04] • Joram Dream : serveur JMS Scalagent [Quéma 05] • JonasALaCarte : serveur Java EE [Abdelatif 05] • Petals : ESB JBI [ EBMWebsourcing / OW2 ] • FraSCAti : plate-forme SCA [ INRIA / ANR SCOrWare ] • FractalGUI : conception d’applications Fractal • FractalExplorer : console d’administration applications Fractal • serveur données répliquées + cohérence Li & Hudak [Loiret 03]

  20. Définition d’un composant Fractal Composant: une entité au moment de l’exécution Structure récursive Capacités réflexive http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  21. Définition d’un composant Fractal Un composant a 2 dimensions • métier • contrôle • les propriétés extra-fonctionnelles • mise en œuvre par une membrane • composée d’un ensemble de contrôleurs • par ex. : sécurité, transaction, persistance, arrêt/démarrage, nommage • contrôleur accessible par une interface dite de contrôle • rôle d’un framework Fractal (Julia, AOKell, …) • fournir un cadre pour développer • des applications Fractal • des contrôleurs et des membranes

  22. Interfaces Interface fournie (ou serveur): Points d’accès au services fournis par le composant. (convention: dessinées à gauche) Interface requise (ou client): Points d’accès pour recevoir des services par d’autres composants. (convention: dessinées à droite) Interface de contrôle: Points d’accès pour des fonctionnalités ne faisant pas partie du service fourni (ex: cycle de vie, propriétés récursives)

  23. Membrane et contenu Membrane Contient les interfaces (fonctionnelles et contrôle) Composé de contrôleurs qui implémentent des interfaces de contrôle. Chaque contrôleur a sa propre tâche. Permets l’introspection et la configuration du composant Contenu Composé d’un nombre fini de composants (sous composants)

  24. Sous composants Un composant peut contenir des sous composants… (composant composite) Gère les sous composant à l’aide de l’interface ContentController (CC). A l’absence de cette interface: composant primitif – boîte noire

  25. http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.htmlhttp://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  26. En résumé

  27. Composant partagés Un composant peut être ajouté à des composant différents (composant parent) Un composant partagé accède à la liste des parents à l’aide de l’interface de contôle SuperController (SC).

  28. Composant partagés http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  29. Autres interfaces de contrôle NameController (NC) LifeCycle (LC) Etats d’un composant: Démarré ou Arrêté AttributeControlles (AC)

  30. En résumé Interfaces de contrôle prédéfinies dans Fractal • Convention de nommage : suffixe -controller • Pour les composants primitifs • binding-controller gestion d'une liaison (créer/supprimer) • lifecycle-controller démarrer/arrêter le composant • name-controller nommer du composant • super-controller le composite auquel  le composant • + pour les composants composites • content-controller gérer le contenu d'un composite (ajouter/retirer des sous-composants)

  31. its internes En résumé • Interface : obligatoire vs facultative • combinaison avec métier/contrôle et client/serveur ok • Interface : interne vs externe • externe : en façade d'un composant ou d'un composite • interne : pendant d'une itf externe pour un composite • combinaison avec métier /contrôle ok • combinaison avec client/serveur ok • Interface : simple vs multiple (collection) • cardinalité de la liaison • référence ou collection de références • combinaison avec métier seulement • combinaison avec client/serveur ok

  32. Liaisons Des sous composants dans un même composant peuvent être reliés par des liaisons (bindings) Binding: une liaison orienté de l’interface requise vers l’interface fournie. La liaison appartient au contenu du composant de l’interface requise Controller par l’interface de contrôle BindingController (BC)

  33. Règles de liaison Une liaison est une connexion d’une interface requise vers une interface fournie Une liaison ne peut pas passer à travers d’une membrane Les composant relié par la liaison doivent être dans le même composant parent.

  34. Liaisons Valide? http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  35. Liaisons Valide? Non! Pourquoi? http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  36. Liaisons Valide? http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  37. Liaisons Valide? Oui! Pourquoi? http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  38. Liaisons Valide? http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  39. Liaisons Valide? Non! Pourquoi? http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  40. Liaisons Valide? http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  41. Liaisons Valide? Non! Pourquoi? http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  42. Liaisons Visibilité: pour indiquer si l’interface est sur la face interne ou externe de la membrane En pratique les interfaces internes, ainsi que les connections entre interfaces internes et externes, sont créées automatiquement

  43. Interface interne Interfaces internes http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  44. Connexions Connexions créées automatiquement http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  45. Liaisons Entre CC et interface requise http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  46. Liaisons Entre interface requise et fournie du même composant http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  47. export import normale En résumé 2 formes • primitive • au sein d’un même espaced’adressage • invocation méthode locale • composite • ≠ sémantiques d’invocation possible • par ex. invocation distante

  48. Définition d’interfaces Interface: nom, visibilité, et type Nom: getFcInterface(in string interfaceName) Visibilité (concerne les composant composite): externe ou interne Type: Nom Rôle: fournie ou requise Cardinalité: combien d’interfaces de ce type le composant peut avoir Contingence: indique si la fonctionnalité de l’interface est garantie quand le composant est actif Signature (pour Julia, la signature est le nom de la classe java de l’Interface).

  49. Accès au interfaces Requise: BC http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

  50. Accès au interfaces Externe: interface de contrôle Component (C) http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

More Related