Technologie des Composants
-
Upload
moupojou-emmanuel -
Category
Documents
-
view
27 -
download
1
description
Transcript of Technologie des Composants
CBSE: Component Based Software Engineering et CBSD: Component Based Software Development
Technologie des Composants
Cours de Génie Logiciel 2
Définitions
� CBSE (Component based software engineering) ?
� Logiciel = assemblage de composants (éventuellement indépendant)
� CBSE= développement des composants et développement par les composants
� Un composant alors?
Cours de Génie Logiciel 3
Notion de composant
� What is a component ?
� “A binary unit of independent production, acquisition, and
deployment that interact to form a functioning system” - C.
Szyperski, Component Software
� “A component is an independently deliverable package of
operations.” - Texas Instruments Literature
� “A component is just a physical packaging of a society of classes.” - Grady Booch
� “A replaceable unit of development work which
encapsulates design decisions and which will be composed
with other components as part of a larger unit.” - DesmonD’Souza, in Catalysis
Cours de Génie Logiciel 4
Composant� Pas de définitions universel (un peu comme les
objets dans les années 90)
� Composant est fait pour la composition (seul point commun dans leur nature)
� S’appuyer sur les définitions émergentes de l’industrie (il y en a 4 principales)
� Composant= unité de composition, peut être déployé indépendamment et peut être assemblé(est sujet à composition) par une tierce personne [Szyperski]
Cours de Génie Logiciel 5
OT vs CBSE
� “OT is Neither Necessary Nor Sufficient for CBSE”
� OT was a useful and convenient starting point for CBSE
� OT did not express full range of abstractions needed by
CBSE(insufficiency)
� It is possible to realize CBSE without employing OT(non-
necessity)
� CBSE induit des changements dans l’approche de conception des systèmes, de la gestion des projets
et du style d’organisation
Cours de Génie Logiciel 6
Structure d’un Composant
ImplantationInterface (opérations offertes)
Interface (opération requise)
Cours de Génie Logiciel 7
Spécification des composants
Un méta modèle UML pour la spécification sémantique des composants
Cours de Génie Logiciel 8
Interfaces
� Spécification des points d’accès au composant
� Capture la syntaxe des opérations (propriétés
fonctionnelles)
� Utilisation de l’IDL (interface Definition
Language)
Cours de Génie Logiciel 9
CBSD
� Développement des composants
� Construire des composants ouverts à l’intégration
� Role: Développeur de composant
� Développement avec les composants
� Intégrer/assembler des composants pour en faire
une application
� Role: Intégrateur de composants
� Obstacles à surmonter?
Cours de Génie Logiciel 10
Contraintes
� Pour le développeur
� Connaissance insuffisante de l’environnement d’exécution cible
� Pour l’intégrateur
� Mise en œuvre des adaptateurs (« glue »)
� Pb. Evaluer le délai de réalisation de
l’adaptateur p/r à celui du composant!
Cours de Génie Logiciel 11
Développement de composants
� Toujours documenter tous les aspects du composant
� Les fonctionnalités
� Les propriétés (non fonctionnelles/techniques)
� performance,
� Consommation des ressources,
� Limitations et
� Robutesse
� Mettre à disposition un jeu de Test
� Toujours tester le composant dans l’environnement cible
Cours de Génie Logiciel 12
Développement des composants
� Provide source code to help the application developerunderstand the semantics of the component.
� Design the components so that they can be integrated intoexisting component models.
� Describe models in which the component works and describehow to make it work with other models.
� Carefully generalize the components to permit reuse in a varietyof future contexts.
� Note, however, that solving a general rather than a specificproblem requires more work.
� Make sure that the application developers can adapt thecomponent to their requirements. This can be done with sinkinterfaces to which the user adds an interface to the component so that the component can utilize that interface to communicatewith the user.
Cours de Génie Logiciel 13
Organisation et Gestion des Projets
� Evolution de l’architecture des applications� Système centralisé vers des systèmes distribués� Emergence des Technologies de l’Internet
� Inadéquation des modèles de processus traditionnel (modèles de la cascade, itératif, spirales et prototypage)� Identification des composants qui peuvent servir dans le cadre du
produit à developper� Selection des composants compatibles avec le produit cible� Création des composants propriétaires (ceux des fonctionnalités
dont on a pas trouver de composants) � Adaptation des composants sélectionnés à la spécification des
besoins (Wrapping) � Assemblage/déploiement du produit dans le cadre d’un
framework pour composants� Remplacement des composants par de nouvelles versions.
Cours de Génie Logiciel 14
Cycle de CBSD vs modèle de la Cascade
Cours de Génie Logiciel 15
Niveaux d’utilisation
Enterprise Architecture
System Architecture
Application Architecture
Macro Architecture
Micro Architecture
object
Technologiedes composants
TechnologieObjet
Cours de Génie Logiciel 16
Les composants
� Qu’est-ce que c’est ?� module logiciel autonome pouvant être installé sur
différentes plates-formes
� qui exporte différents attributs, propriétés ou méthodes
� qui peut être configuré
� capable de s’auto-décrire
� Intérêt : être des briques de base configurables pour permettre la construction d’une application par composition
� Quelques composants de l’industrie� COM / DCOM, Java Beans,
� Enterprise Java Beans, Composants CORBA
Cours de Génie Logiciel 17
Modèles de composants:caractérisation du composant� Comment coopère un composant
� Ce que fournit le composant (entrées)
� composantes, interfaces, opérations, propriétés
� Ce qu’utilise le composant (dépendances)
� composition et références aux autres composants
� modes de communication des connecteurs (synchrone, asynchrone, flots)
� Propriétés configurables du composant
� Contraintes techniques (QoS)� middleware : placement, sécurité, transaction
� internes : cycle de vie, persistance
� implantation : OS, bibliothèques, version
Cours de Génie Logiciel 18
Modèle de composants:Conteneur et structures d’accueil� Conteneur
� encapsulation d’un composant (et ses composantes)
� prise en charge (masque) les services systèmes
� nommage, sécurité, transaction, persistance ...
� prise en charge partielle des connecteurs
� invocations et événements
� techniquement par interposition (ou délégation)
� Structures d’accueil
� espace d’exécution des conteneurs et des composants
� médiateur entre les conteneurs et les services systèmes
Cours de Génie Logiciel 19
Modèles de composants:Conteneur et structure d’accueil
Cours de Génie Logiciel 20
Modèle de composants: synthèse
� Le modèle gère l’infrastructure� Permet ainsi l’utilisateur de se concentrer sur les besoins
métier
� Offre différents niveau de services aux développeurs (tableau ci-après)
CORBA Services
EJB/J2EECOM+Services d’entreprise
CORBA IIOPRMIDCOMDistribution
CORBA Objects
JavaBeansCOM component
Composant de base
CORBAJavaCOM
L’infrastructure d’accueil
Les middlewares
Cours de Génie Logiciel 22
Contraintes de la distribution(1)
� Protocoles d'accès distants (CORBA, RMI, IIOP…)
� Gestion de la charge,
� Gestion des pannes,
� Persistence, intégration au back-end,
� Gestion des transactions,
� Clustering,
� Redéploiement à chaud,
� Arrêt de serveurs sans interrompre l'application,
Cours de Génie Logiciel 23
Contraintes de la distribution(2)
� Gestion des traces, règlages (tuning and auditing),� Programmation multithread� Problèmes de nommage
� Securité, performances,� Gestion des états
� Cycle de vie des objets� Gestion des ressources (Resource pooling)� Requête
� par message (message-oriented midddleware)
� Par appel de procédure distante (RPC)
� Par invocation de méthodes distantes (Object-orientedmiddleware)
Cours de Génie Logiciel 24
Solution
� Qui s'occupe de tout ceci : le middleware !
� Offre un protocole de communication et un ensemble de services
� Permet que l’on se concentre sur l’application sans s’occuper du reste
� Le middleware peut-il exister en dehors d’un modèle de composants???
Cours de Génie Logiciel 25
Le concept de middleware
� Face aux besoins de solutions informatiques de plus en plus éclatées et de grande échelle, se posent de façon aiguë les problèmes� d’intégration de logiciels divers
� éviter les O(n×n) passerelles
� d’ouverture du système au monde extérieur� appréhender l’économie mondiale
� de conception rapide d’applications portables� logiciel de plus en plus évolutif
� La solution est de faire abstraction des supports matériels et logiciels utilisés, et de se limiter à un mode de coopération unifié entre applications.� Middleware
Cours de Génie Logiciel 26
Middleware
Noeud1 Noeud2 Noeudn
Service de communicat ion
Rôle d’un middleware(1)
Cours de Génie Logiciel 27
Rôle des middlewares(2)
� Middleware ou intergiciel est la couche du «milieu»
� C’est une notion des années 1990 (CORBA, …)
� Un middleware se positionne entre les
applications et les supports matériels et les
moyens de communications, en faisant
abstraction de ceux-ci.
� L ’accès à ces composantes se fait par des API
normalisées et portables
Cours de Génie Logiciel 28
Rôles d’un middleware(3)
� Un middleware propose un mode de
coopération entre applications séparant
interface et implantation, souvent fondé sur le
mode client/serveur et le n-tier
Programme
utilisateur
Serveur de
traitements
Serveur de
données
Interface au
serveur de
traitement
Interface au
serveur de
données
Cours de Génie Logiciel 29
Modèle client/serveur
� Client� Programme d’application faisant l’interface entre
un utilisateur et le noyau de l’application.� Tient compte : des formalismes de l’IU
� de la machine de support
� des logiciels disponibles chez le client
� Serveur� Programme fournissant les services d’une
application en faisant abstraction des formalismes, des logiciels d’utilisation et des machines support.
Cours de Génie Logiciel 30
Exemple de modèle client/serveur
�� MinitelMinitel : le logiciel client (PROM) fait l’édition des requêtes et l’affichage à partir de grilles prédéfinies. Quand existe RAM, les grilles spécifiques d’uneapplication peuvent être téléchargées et rester surle poste Minitel.
�� Bases de Bases de donndonnééeses : Un serveur SQL rend la base interrogeable à distance depuis des machines différentes, des systèmes de fichiers différents, des interprètes SQL différents. L’élaboration, l’édition, la connexion des requêtes, la mise en forme des résultats sont faites par le client.
�� WebWeb : Browsers différents.
Cours de Génie Logiciel 31
Fonction de l’intergiciel
� L’intergiciel a quatre fonctions principales� Fournir une interface ou API (Applications Programming
Interface) de haut niveau aux applications
� Masquer l’hétérogénéité des systèmes matériels et logiciels sous-jacents
� Rendre la répartition aussi invisible (“ transparente”) que possible
� Fournir des services répartis d’usage courant
� L’intergiciel vise à faciliter la programmation répartie� Développement, évolution, réutilisation des applications
� Portabilité des applications entre plates- formes
� Interoperabilité d’applications hétérogènes
Cours de Génie Logiciel 32
Typologie des intergiciels
� Middlewares par files de messagespar files de messages� files de messages entre applications
� DECmessageQ, IBM MQSeries
� Middlewares orientorientééss éévvéénementsnements� bus applicatifs – ToolTalk
� communications anonymes entre agents
� Middlewares par par appelappel de de procprocééduresduresdistantesdistantes� appel de procédures chez le fournisseur
� RPC Sun, OSF DCE
Cours de Génie Logiciel 33
Typologie des intergiciels
� Middlewares orientorientééss objetobjet� CORBA de l’OMG; DCOM de Microsoft
� Middlewares orientorientééss documentsdocuments : Web� orientés navigation hypertexte
� traitement dans le client (applets) et dans le serveur (cgi, servlets)
� Intégration d’applications� Web Services
� Coordination
� Accès aux données, persistance
� Support d’applications mobiles
Cours de Génie Logiciel 34
�� AbstractionAbstraction : l’extérieur d’une application est vu comme un ensemble de files de messages de et vers lesquelles on peutrecevoir et envoyer des messages.
�� CoopCoopéérationration : asynchrone par l'intermédiaire de files de messages gérées par le middleware. Les applications communicantes doivent être d’accord sur le contenu des messages - qui n’est pas géré par le middleware.
Middlewaresauvegarde sauvegarde
réseau
Application A Application B
Interprétation
Middlewares par files de messages
Cours de Génie Logiciel 35
Application 1
Application 4
Application 3
Application 2
�� AbstractionAbstraction : une application peut publier des événements sur
le bus, et s’abonner à des événements.
�� CoopCoopéérationration : asynchrone, anonyme et multiple par diffusion. Un événement peut être reçu par 0, 1 ou n récepteurs. Les
applications doivent se mettre d’accord sur les types
d’événements.
Middlewares sur Bus a Evènements
Cours de Génie Logiciel 36
middlewares par appel de procedures distantes
�� AbstractionAbstraction : une application peut appeler des procédures dansd’autres applications, et fournir des points d’entrée de procéduresaux autres.
�� CoopCoopéérationration : client/serveur synchrone. Les interfaces de procédures sont publiées dans un langage RPC IDL qui permetd’obtenir les souches d’appel et de réception. Il peut y avoir
différentes sémantiques d’appels (sécurité, transactions…)
Client Fournisseur
Middleware /RPC
Proc A
Proc B
Proc A
Proc B
Cours de Génie Logiciel 37
Client Fournisseur
Middleware
IDL
Middlewares Orientés Objets
�� AbstractionAbstraction : une application appelle des services distantsperçus comme des objets, elle peut aussi rendre visible des services décrits par des interfaces orientées objet.
�� CoopCoopéérationration : client/serveur par appel de méthodes distantes. L’objet est l’élément de structuration. Les interfaces d’objets
sont publiées dans un langage IDL.
Cours de Génie Logiciel 38
Schéma de fonctionnement
appel
Site Appelant (Client) Site Appelé (serveur)
Proxy
Retour Biblio.
Communication
Emballage
Envoi(req.,param.)
<attente>
Réception(résultats)
Deballage
Exécution Procédure
Squelette et Dispatcher serveur
Biblio. Communication
déballage
Réception(req.,param.)
envoi(résultats)
emballage
Client Messages
Communication Physique
Communication Logique
LL ’’ARCHITECTURE DE ARCHITECTURE DE LL ’’OMGOMG
CORBA
Cours de Génie Logiciel 40
ApplicationCliente Bus CORBA
Référencede l’objet
Interfacede l’objet
Requête
Objet
CORBAActivation
ApplicationServeur
Etat del’objet
Code d’implantation
Le Modèle objet client/serveur
Cours de Génie Logiciel 41
Le Modèle objet client/serveur
�� Application Application clientecliente : programme qui invoque des objets au travers du bus.
�� RRééfféérencerence de de ll’’objetobjet : structure désignant l’objet CORBA permettant de le localiser.
�� Interface de Interface de ll’’objetobjet : type abstrait de l’objet CORBA définissantles attributs et opérations.
�� RequêteRequête : mécanisme d’invocation de l’objet.
�� ObjetObjet CORBACORBA : composant logiciel cible.
�� ActivationActivation : processus d’association d’un objet d’implantation àun objet CORBA.
�� Implantation dImplantation d’’un un objetobjet : entité codant l’objet CORBA à un instant donné.
�� Code Code dd’’implantationimplantation : traitements associés aux opérations.
�� Application Application serveurserveur : structure d’accueil des objets d’implantationet des exécutions.
Cours de Génie Logiciel 42
Interfacesde domaines
Objetsapplicatifs
Utilitaires communs
Bus d’objets répartis
Services d’objets
communs
Spécifiques etnon standardisés
Santé
Télécoms IHM
Finance
Administration
PersistanceNommage
Data Warehouse
Evénements CollectionsRelations
Workflow
Vendeur
TransactionsInterrogations
Propriétés Concurrence SécuritéExternalisation
Cycle de vie LicencesChangements Temps
L’architecture globale de l’OMG
Cours de Génie Logiciel 43
L’architecture globale de L’OMG
� Le bus à objets répartis (Object Request Broker)
� Les services objets communs (Object Services)
� Les utilitaires communs (Corba Facilities)
� Les interfaces de domaines (Domaine Interfaces)
� Les objets applicatifs (Application Objects)
Cours de Génie Logiciel 44
Caractéristiques du bus d’objets repartis CORBA� Liaison avec « tous » les langages de programmation par
projection d ’un langage commun IDL.
� Transparence des invocations : les requêtes aux objets semblenttoujours être locales, le bus se chargeant de les acheminer « au mieux ».
� Invocations statiques et dynamiques : requêtes compilées ou créées à l ’exécution.
� Système auto-descriptif : les interfaces des objets sont connuesdu bus et aussi accessibles par les programmes (référentiel des interfaces).
� Activation automatique et transparente des objets : les objets nesont en mémoire que s’ils sont utilisés.
� Interopérabilité des bus : à partir de CORBA 2.0, un protocolecommun a été défini (IIOP sur TCP/IP).
Cours de Génie Logiciel 45
Client Fournisseur
DIISII SSI DSI
Interface Bus Interface Bus
Adaptateur d’objets
O R B O R B
Référentiel des interfaces Référentiel des implantations
L’architecture du bus CORBA
Cours de Génie Logiciel 46
L’architecture du bus CORBA
� ORB : noyau de communication
� SII : interface d’invocations statiques
� DII : interface d’invocations dynamiques
� IR : référentiel des interfaces IDL
� Interface du bus : primitives de base
� SSI : interface de squelettes statiques
� DSI : interface de squelettes dynamiques
� BOA : adaptateur d’objets
� ImplR: référentiel des implantations
Cours de Génie Logiciel 47
Éléments d’implantation
� Ces différents blocs sont décrits dans le langage IDL, ce qui les rend accessibles au travers du bus. Cela permet d’homogénéiserles différentes implantations possibles de la norme.
� Il est possible de construire un bus CORBA :� A l’intérieur d’un seul processus utilisation d’IDL pour spécifier� entre processus d’une même machine système d’exploitation
objet (Spring)� entre processus de sites différents par exemple sur Internet avec
IIOP� par fédération du bus CORBA passerelles spécifiques ou
génériques (DSI)� Les IOR pour IIOP doivent contenir :
� l’adresse IP de la machine Internet� un port pour se connecter au serveur� une clé -de format libre- pour désigner l’objet dans le serveur
Cours de Génie Logiciel 48
Bus d’objets répartis
Objets applicatifs
Spécifiques etnon standardisés
Interfaces de domaines
Santé
Télécoms
Finance
Utilitaires communs
IHM Administration
Data Warehouse Workflow
Services d’objets
communs
PersistanceNommage Evénements CollectionsRelations Vendeur
Propriétés Concurrence SécuritéExternalisation
LicencesTempsTransactionsInterrogations Cycle de vie Changements
Les services objet communs
� COSS1 : Nommage, Evénement, Persistance, Cycle De Vie
� COSS2 : Transactions, Concurrence, Relations, Externalisation
� COSS3 : Sécurité, Temps
� COSS4 : Interrogations, Licences, Propriétés
� COSS5 : Vendeur, Collections, Changements
Cours de Génie Logiciel 49
Bus d’objets répartis
Objets applicatifs
Spécifiques etnon standardisés
Interfaces de domaines
Santé
Télécoms
Finance
Utilitaires communs
IHM Administration
Data Warehouse Workflow
Services d’objets
communs
PersistanceNommage Evénements CollectionsRelations Vendeur
Propriétés Concurrence SécuritéExternalisation
LicencesTempsTransactionsInterrogations Cycle de vie Changements
Utilitaires communs : Interface utilisateur, gestion de l ’information, administration du système, gestion de tâches…
Interfaces de domaine (objets métiers) : santé, télécoms, finances, commerce… Business Object FrameWorks (BOFs)
Les utilitaires communs et les interfaces de domaines
Cours de Génie Logiciel 50
LL ’’ O M G I D LO M G I D L
� INTERFACE DEFINITION LANGUAGE
� Le langage IDL permet d’exprimer sous la forme de
contrats IDL, la coopération entre les fournisseurs et les utilisateurs de services
� en séparant l’interface de l’implantation des objets
� en masquant les divers problèmes liés à l’interopérabilité,
l’hétérogénéité et la localisation de ceux-ci
� Contrat IDL = {interfaces écrites en IDL}
� Interface IDL = {attributs et opérations d’un type d’objet}
Cours de Génie Logiciel 51
� Un contrat IDL isole les clients et les fournisseurs de l’infrastructure logicielle et matérielle les mettant en relation, c’est-à-dire du bus CORBA.
� Les contrats IDL sont projetés en souches IDL dansl’environnement de programmation du client et en squelettes IDL dans l’environnement de programmation du fournisseur.
� Le client invoque localement les souches pour accéder aux objets
� Les souches IDL construisent des requêtes, qui vontêtre transportées par le bus, puis délivrées par celui-ci aux squelettes IDL qui les délégueront aux objets
Contrat
IDL
Bus CORBASouche Squelette
Client Fournisseur
L ’ O M G I D L
Cours de Génie Logiciel 52
Valeurs IDL
Types complexesTypes dynamiques Types d’objets
Types simples
TypeCode
any
Enum
Struct
Union
Array
Sequence
Définis par
l’utilisateur
ShortUShort
LongUlong
LongLongULongLong
FloatDoubleLongDouble
CharWChar
StringWString
BooleanOctet
IDL : un langage fortement type
Cours de Génie Logiciel 53
IDL : UN LANGAGEFORTEMENT TYPE
Le format des types de base est défini par la norme pour régler les problèmes d’hétérogénéité des données.
Nouveauté : les types de métadonnées :
TypeCodeTypeCode : pour stocker la description d’un type.
AnyAny : pour stocker une valeur d’un type et son TypeCode.
Interface PileGénérique {
readonly attribute any sommet;
void empiler (in any valeur);
...
ID
L
Cours de Génie Logiciel 54
interfaceCalendrierFerie: Calendrier {..};
interface Calculatrice {..};
Interface Calendrier_Calculatrice: Calendrier, Calculatrice {..};
Interface CalendrierFerie_Calculatrice: CalendrierFerie_Calculatrice {};
Calendrier
CalendrierFerie_Calculatrice
CalendrierFerieCalendrier_Calculatrice
Calculatrice
I D L : HERITAGE
Cours de Génie Logiciel 55
� Héritage simple et multiple
� Pas de redéfinition ni de surcharge
� Conflits de noms interdits
� Héritage répété sans conflits de noms
� Un objet ne peut implanter qu’une et une
seule interface (pour l’instant)
I D L : HERITAGE
Cours de Génie Logiciel 56
La projection du langage IDL
� Une projection est la traduction dans un langage
d’implantation de spécifications IDL
� Les règles de projection sont normalisées et fixent la
traduction de chaque construction IDL en une ou des
constructions du langage cible.
� C, C++, SmallTalk, Ada, Java et Cobol orienté objet.
Fichier IDL
PrécompilateurIDL vers Java
PrécompilateurIDL vers C++
Client C++
Souches C++
ORB A
Serveur Java
Squelette Java
ORB BIIOP
Cours de Génie Logiciel 57
OMG IDL : CONCLUSION
� Langage simple et complet
�� MAISMAIS� Règles de projections complexes� Pas de passage d’objets par valeur
� Pas de possibilités d’exprimer autre chose que les interfaces.� Sémantiques
� pré/post conditions
� graphes d’objets� ...
Cours de Génie Logiciel 58
LES COMPOSANTES DU LES COMPOSANTES DU BUS CORBABUS CORBA
Les principales composantes nécessaires à la mise en œuvre d’un bus CORBA sont :
• l’interface de base au bus• les adaptateurs d’objets• le référentiel des interfaces• le référentiel des implémentations (non encore normalisé)
Elles sont décrites en IDL dans le module CORBA
Elles complètent le mécanisme d’invocations (SII) et de réception (SSI) statiques (souches et squelette résultat de la compilation IDL).
Un autre mécanisme de coopération client/serveur consiste en interfaces d’invocations (DII) et squelettes (DSI) dynamiques.
Cours de Génie Logiciel 59
L’INTERFACE O R B
Une référence vers un objet de type CORBA::ORB est retourné àl’initialisation du bus.
Elle permet d’obtenir ensuite les premiers objets utiles : les objets
notoires que sont par exemple le service de nommage et le
référentiel des interfaces.
interface ORB {
typedef string ObjectId;typedef sequence<ObjectId>ObjectIdList;
ObjectIdList list_initial_services O;Pbject resolve_initial_references (in ObjectID identifier);};
ID
L
Cours de Génie Logiciel 60
L’INTERFACE O R B
L’interface ORB définit aussi les opérations de conversion référence d’objet chaîne IOR
interface ORB {
string Object_to_string (in Object obj);Object string_to_Object (in string str);
};
ID
L
Cours de Génie Logiciel 61
LES ADAPTATEURS D’OBJETS
� Connaître les implantations utilisées et savoir les activer,
� savoir générer et interpréter des références d ’objets,
� savoir déléguer les demandes d ’opérations vers les objets
BOA : Basic Object AdapterBOA : Basic Object Adapter
LOA : Library Object AdapterLOA : Library Object Adapter
OODA : ObjectOODA : Object--Oriented Database AdapterOriented Database Adapter
POA : Portable Object Adapter (nouveau)POA : Portable Object Adapter (nouveau)
COA : Card Object adapter (LIFL/Gemplus)COA : Card Object adapter (LIFL/Gemplus)
Une implantation d’un objet doit fournir un espace mémoire et un contexte d’exécution. L’activation d’une implantation est réalisée dans le monde CORBA par un adaptateur d’objet.Cela isole le bus des différentes technologies pouvant être employées dans l’implantation des objets.
Un adaptateur d’objet doit :
Cours de Génie Logiciel 62
LE REFERENTIEL DES INTERFACES
� Distribution des interfaces IDL,
� contrôle des graphes d’héritage,
� construction d’outils générateur de code, AGL ou browsers,
� vérification des signatures des opérations,
� fédération de bus CORBA,
� introspection et objets auto-descriptifs.
Toutes les définitions IDL sont conservées dans un référentiel des interfaces structuré comme un ensemble d’objets, eux -mêmes décrits par des interfaces IDL et donc accessibles du bus.
Utilisations :
Cours de Génie Logiciel 63
LE REFERENTIEL DES INTERFACES
CC’’est la ressource la plus volumineuse des implantations CORBAest la ressource la plus volumineuse des implantations CORBA
(+ de 50 % des points d(+ de 50 % des points d ’’entrentréée)e)
La norme CORBA définit les interfaces IDL de consultation,de navigation et de modification du référentiel des interfaces.
Cours de Génie Logiciel 64
LES MECANISMES DYNAMIQUES
Le mLe méécanisme DII (Dynamic Invocation Interface)canisme DII (Dynamic Invocation Interface)Ce mécanisme permet à un client d’invoquer les objets sans utiliser de souches
IDL prégénérées. Pour cela le client va construire dynamiquement les requêtes,
et doit donc découvrir dynamiquement, via l’IR, l’interface des objets.
L ’API DII permet de créer des objets de type Request, et d’y placer la référence
de l’objet cible, le nom de l’opération, la liste des arguments et le résultat.
Nom de l’opération
Request
Référence de l’objet
résultat
nom de l’argument
valeur
any
TypeCode
Cours de Génie Logiciel 65
LES INTERETS DU MECANISME DII
� Le client s ’adapte dynamiquement aux objets qu’il souhaite invoquer. Ceux-ci peuvent donc évoluer sans modifications de clients.
� Possibilité de construire des clients sans connaître les types des objets qu’ils utiliseront. Indispensable pour la navigation dans les bases d’objets découvertes dynamiquement.
� Mécanismes de base pour la création d’IHM, de browsers et de langages interprétés utilisant des objets CORBACORBA.
Cours de Génie Logiciel 66
LES INTERETS DU MECANISME DII
L ’interface DII est une interface complexe.
Des outils nouveaux doivent permettre de masquer
cette complexité au profit d ’une plus large utilisation..
Cours de Génie Logiciel 67
LES MECANISMES DYNAMIQUES
Le mLe méécanisme DSI (Dynamic Skeleton Interface)canisme DSI (Dynamic Skeleton Interface)
Ce mécanisme permet à un serveur de recevoir
des requêtes sans utiliser le squelettes IDL
prégénérés. Il peut donc traiter des requêtes pour n ’importe quel type d ’objets.
LL ’’API DSIAPI DSI permet de récupérer les différentes
composantes d ’une requête.
Cours de Génie Logiciel 68
LES MECANISMES DYNAMIQUES
Le mLe méécanisme DSI canisme DSI fut initialement défini pour permettre la mise en place de passerelles entre bus CORBA. Il est possible de l’utiliser pour implanter dynamiquement des objets dans un serveur.
clientclient
requête Brequête Brequête Arequête A
serveurserveur
passerellepasserelle
IDLIDL IDLIDLDIIDIIDSIDSI
Cours de Génie Logiciel 69
LES SERVICES NORMALISES DE CORBA
� COSS 1 : Nommage, Evénement, Persistance, Cycle de vie.
� COSS 2 : Transactions, Concurrence, Relations, Externalisation.
� COSS 3 : Sécurité, Temps.
� COSS 4 : Interrogations, Licences, Propriétés.
� COSS 5 : Vendeur, Collections, changements.
Common Object Service Specifications COSS
Cours de Génie Logiciel 70
� L’objectif est de permettre de retrouver
dynamiquement les objets nécessaires
(service de « pages blanches »).
� Ce service gère un graphe de contextes de
nommage, chaque contexte étant une liste
d’associations nom symbolique - référence
d’objet.
Service nommage: Name service
Cours de Génie Logiciel 71
CosNaming::Name est la définition IDL des chemins d ’accès dans le graphe de contextes
Un chemin est une séquence de composants
(en IDL : CosNaming::NameComponent)
Service nommage: Name service
Cours de Génie Logiciel 72
Service nommage: Name service
� Un contexte est défini en IDL par
CosNaming::NamingContext et fournit des
opérations de base telles l ’ajout (bind) ou la
recherche (resolve) d ’une association, ou
encore l ’obtention du contexte dans une liste
définie par
� CosNaming::BindingList et
� CosNaming::Binding.
Cours de Génie Logiciel 73
� Même principe que le service nommage sous
la forme «« pages jaunespages jaunes »»
� Les fournisseurs enregistrent leurs objets
dans ce service en les caractérisant par un
ensemble de propriétés (paires nom-valeur).
Les clients indiquent le type de service désiré
et des critères pour effectuer la recherche.
� Comme pour le service de nommage,il est
possible de fédérer les services Vendeur.
Service vendeur: Trader service
Cours de Génie Logiciel 74
Service évènements: Event Service
� Ce service permet aux objets de produire des
événements asynchrones à destination
d’objets consommateurs, et cela au travers
de canaux d’événements.
� Mode Push :
� le producteur a l’initiative,
� le consommateur est notifié des dépôts.
� Mode Pull :
� le consommateur émet des requêtes de retrait.
Cours de Génie Logiciel 75
Un canal peut être nonnon--typtypéé (any) ou typtypéé (IDL).
Push Pull
Canal d’événement
producteur consommateur
Service évènements: Event Service
Cours de Génie Logiciel 76
Client Serveur
ORB
context
Transaction Service
1-Begin T
3-register
5-propagate
4-End T
2-invoke (c)
Service transactions: Object Transaction
Service (OTS)
� Ce service assure l’exécution de traitements
transactionnels impliquant des objets
distants.
Cours de Génie Logiciel 77
Service securite: Security Service
� Ce service permet d’identifier et d’authentifier
les clients, de chiffrer et de certifier les
communications et de contrôler les
autorisations d’accès.
� Ce service utilise les notions de :
� serveur d’authentification
� clients / rôles / droits (et délégation de droits)
� Secure IIOP (utilisant Kerberos ou SSL)
Cours de Génie Logiciel 78
� Ce service fournit les mécanismes pour contrôler et ordonnancer les invocations concurrentes sur les objets.
� Le mécanisme proposé est le le verrouverrou.� Ce service est conçu pour être utilisé
conjointement avec le service de transactions.
Service concurrence d ’acces: Concurrency
Service
Cours de Génie Logiciel 79
� Ce service décrit des interfaces pour
� la création,
� la copie,
� le déplacement,
� la destruction
des objets du bus.
� Il définit la notion d’Object Object FactoryFactory
Le service cycle de vie Life Cycle
Service
Cours de Génie Logiciel 80
Le service changements (Versionning
Service)
� Ce service permet de gérer et de suivre
l’éévolutionvolution des différentes versions des
objets.
� Ce service maintient des informations sur les
évolutions des interfacesinterfaces et des
implantationsimplantations.
Cours de Génie Logiciel 81
Le service temps (Time Service)
� Ce service fournit des interfaces permettant
� d’obtenir une horloge globale sur le bus (UniversalTime Object)
� de mesurer le temps
� de synchroniser les objets.
Cours de Génie Logiciel 82
Conclusion
� Les Middlewares répondent aux besoins des applications et systèmes � répartis,� hétérogènes,
� ouverts,
� évolutifs.
� Restent les problèmes liés à leur complexité de mise en œuvre
� Ils servent de socle aux infrastructures d’accueil
� L’émergence des modèles de composants a favorisé la diffusion de la technologie.
Cours de Génie Logiciel 83
Bibliographie� Szyperski C. Component software: beyond object-oriented
programming. Addison wesley, reading, Mass., 2nd Edition
� Gamma E. and al. Design Patterns, Elements of reusable Object-Oriented Software. Addison Wesley, Reading, MA, 1995
� Wolfgang Pree. Design Patterns et Architectures logicielles. Viubert, 1998
� Didier DONSEZ. Les Enterprise Java Beans. Cours de GL, Université Joseph Fourier
� Quelques liens
� Java beans-> http://java.sun.com/beans/doc/
� Corba -> www.omg.org