Corba Component Model (CCM)

1
Corba Component Model(CCM)

• SAMAHA Antoine

UJF/ISTG/RICM3 http//www-istg.ujf-grenoble.fr/
Année Universitaire 2001-2002
2
Sommaire

• Motivations
• Limites de la programmation OO
• Les composants
• Corba Component Model (CCM)
• Introduction
• Composants CORBA
• Modèle abstrait
• Implémentation des composants
• Les conteneurs
• Création de lot, assemblage et déploiement
• Vue générale
• Conclusion

3
Motivations

• Motivation pour la programmation orientée
  composant
• Construction dapplications par assemblage
  dentités existantes ( composants )
• Formalisme pour décrire les interactions entre
  composants
• Formalisme pour décrire le déploiement des
  composants
• Outils de développement, Outils de déploiement,
  Outils dadministration.
• Les limites de la programmation par objets

4
Limites de la programmation OO(1/2)

• Beaucoup de tâches doivent être gérées
  manuellement
• Définition des instances
• Gestion des dépendances entre classes/modules
• Structure des applications peu lisible (un
  ensemble de fichiers )
• Absence de vision globale de lapplication
• Les principaux concepts sont définis au niveau
  dun objet individuel
• Pas de notion de description globale de
  larchitecture

5
Limites de la programmation OO(2/2)

• Évolutions/modifications difficiles
• Changement de mode de communication
• Évolution, ajout, suppression de fonctionnalités
• Modification du placement des objets
• Absence de services
• Les services nécessaires doivent être réalisées
   à la main (persistance, sécurité, tolérances
  aux fautes..)
• Déploiement ( installation )
• Peu ou pas doutils pour installer les
  exécutables sur les différentes sites

6
Les composants(1/4)

• Programmation orientée composant
• Égale programmation par assemblage plutôt que par
  développement (cas de la programmation OO)
• Focaliser lexpertise sur les problèmes du
  domaine à informatiser plutôt que sur des
  compétences techniques informatiques

7
Les composants(2/4)

• Définition d'un composant
• Égale module logiciel
• Qui exporte différents attributs, propriétés et
  méthodes
• Qui est prévu pour être configuré
• Qui est prévu pour être installé
• Qui fournit un mécanisme lui permettant de
  s'auto-décrire
• Composant objet configurateur installateur
• Objectif avoir des briques de bases
  réutilisables

8
Les composants(3/4)

• Caractérisation d'un composant
• Il fournit des services
• Il utilise d'autres composants
• Il possède des propriétés
• configurables
• Il spécifie quelles doivent être les
  caractéristiques de l'environnement pour qu'il
  puisse être installé correctement
• En terme de système (OS, librairies, ...)
• En terme de services (transaction, sécurité,
  persistance, ...)

utilisation de composants
9
Les composants(4/4)

• Environnement d'exécution d'un composant
• Conteneur
• Encapsulation d'un composant
• Prise en charge (masquage)
• des services systèmes
• Prise en charge des
• connexions entre composants
• Invocations et événements
• Structure d'accueil
• Espace d'exécution
• Médiateur entre les conteneurs et le
  système/middleware

10
CCM - Introduction(1/2)

• Un modèle de composant compatible avec les EJB
• Un modèle qui permet de décrire le déploiement,
  la configuration et la composition.
• Un modèle de composant applique la composition au
  lieu de lhéritage
• Indépendance de la plate-forme et du langage de
  programmation
• Inclusion de la gestion des événements
• Notion dinterface exportées et requises

11
CCM - Introduction(2/2)

• Deux types de composants
• Les composants basiques (similaires à EJB)
• Les composants étendus
• Spécification des composants
• Modèle abstrait des composants
• Modèle dimplantation des composants
• Modèle de programmation des conteneurs
• Architecture des conteneurs des composants
• Création des lot, assemblage et déploiement
• Interfonctionnement avec EJB 1.1

12
CCM - Composants CORBA (1/4)

• Un composant CCM possède
• 1 ou plusieurs interfaces (appelées port)
• Une fabrique (appelée home)
• 3 types de ports (facette, réceptacle, événement)
• Les attributs valeurs nommées, permettre la
  configuration dun composant
• Un composant possède une référence de base (IOR
  pour un objet CORBA )
• Accès à un composant via la référence de base
• Interface de navigation
• Tous les composants héritent du composant de base
  ComponentBase
• ( CORBAObject pour les objets )
• Les composants se déclarent en IDL3 (extension de
  lIDL de base)
• Traducteur IDL3 ? IDL

13
CCM - Composants CORBA (2/4)

• Architecture générale dun composant CORBA

14
CCM - Composants CORBA (3/4)

• Facette
• Facette interface fournit par un composant
  CORBA
• Facette fournit un point de vue sur un composant
• Chaque composant exporte une ou plusieurs
  interfaces IDL 
• Permet à plusieurs clients davoir des points de
  vue sur un même composant
• Différence fondamentale avec les objets qui, eux,
  ne comportent quune interface IDL
• Chaque facette possède une référence et
  correspond à une interface IDL
• Réceptacle
• Réceptable point de connexion entre composants
• Permet de créer des liens entre composants
• 2 types de connexion simples ou multiples
• Utilise des méthodes de connexion et de
  déconnexion dynamiques

15
CCM - Composants CORBA (4/4)

• Evénement
• Ports de réception/émission dévénements
  asynchrones
• 2 types de producteurs 1-1 et 1-n
• 2 types de ports producteur/consommateur ( ou
  source/puits )
• Les clients sabonnent à des types dévénements
• Modèle de communication de type push
• Fabrique
• Gestionnaire du cycle de vie dun type de
  composant
• Gère les instances dun composant
• Offre des outils de recherche dinstances basés
  sur des clés

16
CCM - Modèle abstrait (1/9)

• Adaptation entre lIDL3 étendu et lIDL
  traditionnel
• Les composants se déclarent en IDL3 (extension de
  lIDL de base)
• LIDL étendu reste compatible avec lIDL
  traditionnel

17
CCM - Modèle abstrait (2/9)

• Décrire un composant
• En IDL étendu définit le nouveau mots clef
  component
• Component un_composant
• // Description du composant
• En IDL traditionnel (un composant devient une
  interface qui hérite de linterface standard
  ComponentsCCMObject)
• Interface un_composant ComponentsCCMObject
• //Description du composant

18
CCM - Modèle abstrait (3/9)

• Décrire des facettes
• Mots clef provides
• Component un_composant
• Provides IA interface_a
• Provides IB interface_b
• En IDL traditionnel ( provides devient une
  opérations qui renvoie la facette spécifiée)
• IA provides_interfaces_a() (pour récupérer la
  référence)
• Lopération Get_component permet de récupérer une
  référence vers le composant
• Le composant offrira la référence dune
  interface de navigation
• opération qui renvoie lensemble des références
  des divers facettes avec leurs noms respective

19
CCM - Modèle abstrait (4/9)

• Décrire des réceptacles
• Mots clef uses ( permet de spécifier le nom
  dinterface qui pourra être connectée à ce
  composant)
• Component un_composant
• uses IC entree_c
• uses multiple ID entree_b
• Mots clef multiple (un composant peut manipuler
  plusieurs interfaces de ce types en même temps)
• En IDL traditionnel
• Void connect_entree_c() raises (componentsAlready
  Connected, ComponentsInvalidConnection)
  //connecter
• IC disconnect_entree_c() raises
  (componentsNoConnection)//déconnecter
• IC get_connection_entree_c() // récupérer
  linterface connectée

20
CCM - Modèle abstrait (5/9)

• Décrire des sources dévénements
• Deux types événements
• Vers un ensemble de consommateurs dévénements
•  fournisseur  (publisher)
• Vers un canal dévénements  émetteur  (emitter)
• Deux mots clefs publishes, emits
• Component un_composant
• emits firstEvent premier
• Publishes secopndEvent second
• Les clauses emits et publishes en IDL classique
  spécifier des opérations qui permettent à un
  consommateur ou à un canal dévénements, de
  souscrire et de stopper sa souscription à un type
  dévénements.

21
CCM - Modèle abstrait (6/9)

• Décrire des puits dévénements
• Mot clefs consume
• Component un_composant
• consumes thirdEvent troisième
• Décrire des attributs
• La description dun attribut se fait comme en IDL
  standard
• Extension
• Readonly attribute float Solde raises(PermissionIn
  correcte)
• Attribute String nom getraises(NomPasDefini) set
  raises(NomIncorrect)
• //types dexceptions pour chaque type daction
  (lecture et/ou écriture)

22
CCM - Modèle abstrait (7/9)

• Décrire linterface Home
• Gère le composant son cycle de vie, opérations
  de recherche
• Deux types dinterfaces Home
• Celles qui gèrent un composant sans clef primaire
• Celles qui gèrent un composant avec clef primaire
• Remarque
• Plusieurs interfaces Home peuvent être définies
  pour un même composants
• Une interface Home peut hériter dune autre
  interface home

23
CCM - Modèle abstrait (8/9)

• Celles qui gèrent un composant sans clef primaire
• home nom_de_la_home manages nom_de_composant
  
• //corps de la home
• Léquivalence dune description de Home en IDL
  classique
• Interface de Home explicite (opérations décrits
  par lutilisateurs)
• Interface de Home implicite (opérations standard
  pour une Home)
• Interface Home qui hérite des deux interfaces
  précédentes
• interface nom_de_la_homeImplicit
  Components KeylessCCMHome
• nom_de_composant create()// créer une
  nouvelle instance du composant

24
CCM - Modèle abstrait (9/9)

• Celles qui gèrent un composant avec clef primaire
• home nom_de_la_home manages
  nom_de_composant primaryKey type_de_la_clef
  //corps de la home
• Léquivalence dune description de Home en IDL
  classique
• Identique à celui dune Home sans clef primaire
• En plus des modifications de linterface
  implicite
• interface nom_de_la_homeImplicit
• nom_de_composant create()
• nom_de_composant find_by_ primary_Key(in
  type_de_la_clef Key)
• raises(componentsUnknownKeyValue,
  ComponentsInvalidKey)
• Void remove(in type_de_la_clef Key)
• raises(componentsUnknownKeyValue,
  ComponentsInvalidKey)
• type_de_la_clef get_ primary_Key(in
  nom_de_composant comp)

25
Implémentation des composants(1/5)

• CIDL (Component Implementation Definition
  Language)
• Langage spécifique qui décrire limplantation du
  composant
• Simplifie la mise en œuvre de la persistance et
  des transactions du composant
• Permet de spécifier une composition, qui permet
  la mise en place de relations entre les
  descriptions IDL et les exécuteurs (les entités
  qui implantent les interfaces décrites en IDL)
• Deux types dexécuteurs
• Home Executor //Implantation de linterface Home
• Component Executor // Implantation du composant

26
Implémentation des composants(2/5)

• En utilisant lIDL et CIDL, des compilateurs
  spécifiques génèrent automatiquement le canevas
  dimplantation du composant

27
Implémentation des composants(3/5)

• Syntaxe de description dune composition
• compositon catégorie_de_la_composition
  nom_de_la_composition
• // Description des éléments de persistance
• facilite la mise en œuvre de la persistance du
  composant
• // Description de la Home Executor
• précise le nom des classes dimplantation de la
  Home et du composant ainsi que des
  informations de liaison aux procédures de
  persistance
• // Description des Home Proxy
• permet de définir des Home séparées des
  composants( distantes)

28
Implémentation des composants(4/5)

• Les quatre catégories de composition
• Service un composant de type service nutilise
  pas de clef primaire, nest pas persistant, et de
  plus est sans état
• Session ce composant nutilise pas de clef
  primaire et nest pas persistant
• Process ce composant est persistant mais
  nutilise pas de clef primaire
• Entity ce composant est persistant et utilise
  une clef primaire

29
Implémentation des composants(5/5)

• Les exemple utilisant une description de Home
  Executor
• composition session ExempleComposition
• home executor HomeExempleImpl
• implements HomeExemple
• manages ExempleImpl
• Lexécuteur Home du composant sera implanté par
  la classe HomeExempleImpl

30
Les conteneurs
31
Création de lot, assemblage et déploiement

• Création de lots
• Rassemble tous les constituants dun composant
• Le descripteur logiciel (software Package
  Descriptor) cest un fichier XML portant
  lextension .csd pour CORBA software Descriptor
• Le descripteur de composant (CORBA Component
  descriptor) cest un fichier XML portant
  lextension .ccd pour CORBA Component Descriptor
  
• Le descripteur de propriétés (Property File
  descriptor) cest un fichier XML portant
  lextension .cpf pour Component Property File

32
Création de lot, assemblage et déploiement

• Assemblage
• Le descripteur dassemblage de composants
  (Component Assembly Descriptor) cest un fichier
  XML qui énumère les caractéristiques de
  lassemblage portant lextension .cad
• Déploiement

33
Vue générale
34
Conclusion

• Séparation des fonctionnalités
• Développement
• Déploiement
• Administration
• Comparaison CCM vs EJB
• Plus complet
• Moins avancé
• Plus complexe