LOG4430 : Architecture logicielle et conception avancée

Foutse Khomh

© Guéhéneuc 2009; Arnaoudova 2010; Khomh 2010Département de génie informatique et de génie logicielÉcole Polytechnique de Montréal

LOG4430 :Architecture logicielle et

conception avancée

Composition et architectures par composants

2/75

Composition et architectures par composants1. Mise en contexte2. Introduction aux composants logiciels3. Le modèle de composants Fractal4. Lectures à faire

3/75

1. Contexte

Limitations des architecture à objets Complexité du chargement dynamique

– Ad hoc Solution partielle des cadre de références et

autres plugiciels

4/75

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/75

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/75

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/75

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/75

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 contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties. [Szyperski 97]

9/75

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/75

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/75

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

composant

liaison

interfacerequise fournie

12/75

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

composant

connecteur

connecteur liaison avec comportement

on peut considérerconnecteur = composant (de communication)

composant, interface, liaison

13/75

1. IntroductionClassification des modèles pour système/intergiciel

Application

Middleware

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/75

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/75

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/75


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/75


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/75


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/75


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/75

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/75

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/75

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/75

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/75

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/75http://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

26/75

En résumé

27/75

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/75

Composant partagés


29/75

Autres interfaces de contrôle

NameController (NC) LifeCycle (LC)

– Etats d’un composant: Démarré ou Arrêté AttributeControlles (AC)

30/75

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/75

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

its internes

32/75

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/75

Règles de liaison

1. Une liaison est une connexion d’une interface requise vers une interface fournie

2. Une liaison ne peut pas passer à travers d’une membrane

3. Les composant relié par la liaison doivent être dans le même composant parent.

34/75

Liaisons

Valide?


35/75

Liaisons

Valide? Non! Pourquoi?


36/75

Liaisons Valide?


37/75

Liaisons Valide? Oui! Pourquoi?


38/75

Liaisons Valide?


39/75

Liaisons Valide? Non! Pourquoi?


40/75

Liaisons Valide?


41/75

Liaisons

Valide? Non! Pourquoi?


42/75

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/75

Interface interne

Interfaces internes


44/75

Connexions

Connexions créées automatiquementhttp://fractal.ow2.org/fractal-distribution/fractal-concepts-doc.html

45/75

Liaisons Entre CC et interface requise


46/75

Liaisons

Entre interface requise et fournie du même composant


47/75

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

normale

export import

48/75

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/75

Accès au interfaces

Requise: BC


50/75


Externe: interface de contrôle Component (C)


51/75


Interne: CC


52/75

Créer un composant

créer une instance à partir d’une définition de composant– ≡ new en POO

2 solutions– avec une fabrique (aka Bootstrap

Component)– à partir d’un gabarit (template)

53/75

Créer un composant

Instanciation avec le Bootstrap Component composant prédéfini par Fractal peut instancier n’importe quel composant informations nécessaires

– son type– son implémentation– une forme de membrane

newnew

newnew

newnew

newnew

newnew

newnew

54/75

Créer un composant

Instanciation à partir d’un gabarit utiliser l’existant (template)

– 1 composant ou– 1 assemblage de +sieurs composants

pour en faire une « copie »

Avantage– moins de manipulation pour instancier de grands assemblages

newnew

newnew

55/75

Développer avec Fractal

Développer des applications Fractal en Java 3 outils complémentaires Fraclet

– modèle de programmation à base d'annotations Fractal ADL

– langage de description d'architecture (ADL) basé XML Fractal API

– ensemble d’interfaces Java pour• l'introspection• la reconfiguration• la création/modification dynamique

– de composants et d'assemblage de composants Fractal

56/75

Fraclet

Modèle de programmation Java pour Fractal

à base d’annotations– Java 5 ou– Java 1.4 XDoclet

annotations d'éléments de code (classe, méthode, attribut)– apporte aux éléments une signification en lien avec les concepts

Fractal phase de pré-compilation

– génération du code source associé aux annotations

indépendant des plates-formes (Julia, AOKell)

57/75

Fraclet

Principales annotations

@Component– s’applique à une classe implémentant un composant– 2 attributs optionnels

• name : le nom du composant• provides : les services fournis par le composant

@Requires– s’applique à un attribut (field) : la référence du service requis (de type T)

• attribut de type T pour SINGLETON• attribut de type Map<String,T> pour COLLECTION

– indique que l’attribut correspond à une interface cliente– 3 attributs optionnels

• name : le nom de l'interface• cardinality : Cardinality.SINGLETON (par défaut) ou COLLECTION• contingency : Contingency.MANDATORY (par défaut) ou OPTIONAL

58/75

Java API - Type

Tout type hérite de Type– Sa seule méthode permet de savoir si deux

types sont compatibles

public interface Type { boolean isFcSubTypeOf (Type type);

}

59/75

Java API - InterfaceType

Décrit le type d’interface Fractal

public interface InterfaceType extendsorg.objectweb.fractal.api.Type { String getFcItfName (); String getFcItfSignature (); boolean isFcClientItf (); //role: CLIENT (true) or SERVER (false)boolean isFcOptionalItf (); //contingency : OPTIONAL (true) or // MANDATORY (false)

boolean isFcCollectionItf (); //cardinality : COLLECTION (true) or // SINGLETON (false)

}

60/75

Java API - ComponentType

Un ensemble de InterfaceType

public interface ComponentType extendsorg.objectweb.fractal.api.Type {

InterfaceType[] getFcInterfaceTypes (); InterfaceType getFcInterfaceType (String name)

throws NoSuchInterfaceException;

}

61/75

Java API - TypeFactory

Définie les méthodes qu’une Factory doit avoir

public interface TypeFactory { InterfaceType createFcItfType ( String name, String signature,boolean isClient, boolean isOptional, boolean isCollection) throws

org.objectweb.fractal.api.factory.InstantiationException;

ComponentType createFcType (InterfaceType[] interfaceTypes) throwsorg.objectweb.fractal.api.factory.InstantiationException;

}

62/75

Java API - Interface

Interface Java implémentée par tout interface Fractal

public interface Interface { Component getFcItfOwner (); String getFcItfName (); Type getFcItfType ();boolean isFcInternalItf ();

}

63/75

Java API – Interfaces de contrôle

Component AttributeController BindingController ContentController LifeCycleController NameController SuperController

64/75

Java API – Factory

public interface GenericFactory { Component newFcInstance (Type type, Object controllerDesc, Object contentDesc) throws InstantiationException;

}

public interface Factory { Type getFcInstanceType ();Object getFcControllerDesc (); Object getFcContentDesc (); Component newFcInstance () throws InstantiationException;

}

65/75

Hello World! - Fraclet et Fractal ADL

http://fractal.ow2.org/fractal-distribution/helloworld-julia-fraclet/user-doc.html

66/75

Hello World! – avec Fraclet et Fractal ADL Créer les composants primitifs

– Créer des interfaces Java qui vont être associées avec les interfaces Fractal (Service.java)

– Créer une class Java qui va contenir la logique du composant (ClientImpl.java et ServerImpl.java)

– Insérer les annotations avec Fraclet

Encapsuler les composant primitifs dans un composant composite (décrit avec Fractal ADL) (ClientServerImpl.fractal)

Appeler Fractal ADL Factory pour instancier l’architecture

67/75

Hello World! – avec Fraclet et Fractal ADL Créer un nouveau projet Java Dans un paquetage helloworld créer les trois

classes suivants:– Interface Service– Classe ServerImpl– Classe ClientImpl

Ainsi que le fichier ClientServerImpl.fractal

68/75

Hello World! – avec Fraclet et Fractal ADL L’interface Java - Service

69/75

Hello World! – avec Fraclet et Fractal ADL L’implémentation de l’interface côté Serveur

70/75

Hello World! – avec Fraclet et Fractal ADL L’implémentation de l’interface côté Client

71/75

Hello World! – avec Fraclet et Fractal ADL ClientServerImpl.fractal:

72/75

Hello World! – avec Fraclet et Fractal ADL Placer les fichiers suivants dans le dossier

du projet:– Build.xml– Build.properties

Cliquer droit sur le fichier build.xml – > « Run as » – > « Ant build … » (seconde option)

73/75

Hello World! – avec Fraclet et Fractal ADL Dans l’onglet « Environnement » créer une

nouvelle variable « FRACTAL_HOME » dont la valeur est le chemin vers le dossier fractal-libraries-1.1.2-20080918.101659-2-distribution

Exécuter!

74/75

F4E

Pour développer avec Fractal et Eclipse:– Télécharger le plug-in pour Eclipse F4E:

http://fractal.ow2.org/f4e/

75/75

4. Lectures à faire

http://www.fil.univ-lille1.fr/~seinturi/m2/cagl/index.html – Flâner parmi les «Transparents de cours » – Lire et faire le TP « Fractal »

http://www.fil.univ-lille1.fr/~seinturi/m2/cagl/index.html

http://www.fil.univ-lille1.fr/~seinturi/m2/cagl/index.html

LOG4430 : Architecture logicielle et conception avancée

Documents

Transcript of LOG4430 : Architecture logicielle et conception avancée