Technologie Des Composants

CBSE: Component Based Software Engineering
et
CBSD: Component Based Software Development
Technologie des Composants
Dfinitions
CBSE (Component based software

engineering) ?
Logiciel = assemblage de composants

(ventuellement indpendant)
CBSE= dveloppement des composants et
dveloppement par les composants
Un composant alors?
Cours de Gnie Logiciel
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. - Desmon
DSouza, in Catalysis
Composant
Pas de dfinitions universel (un peu comme les

objets dans les annes 90)
Composant est fait pour la composition (seul point
commun dans leur nature)
Sappuyer sur les dfinitions mergentes de
lindustrie (il y en a 4 principales)
Composant= unit de composition, peut tre
dploy indpendamment et peut tre assembl
(est sujet composition) par une tierce personne
[Szyperski]
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(nonnecessity)
CBSE induit des changements dans lapproche de

conception des systmes, de la gestion des projets
et du style dorganisation
Structure dun Composant
Interface (opration requise)
Implantation
Interface (oprations offertes)
Spcification des composants
Un mta modle UML pour la spcification smantique des composants

Interfaces
Spcification des points daccs au

composant
Capture la syntaxe des oprations (proprits
fonctionnelles)
Utilisation de lIDL (interface Definition
Language)
CBSD
Dveloppement des composants

Construire des composants ouverts lintgration

Dveloppement avec les composants

Intgrer/assembler des composants pour en faire

une application
Role: Dveloppeur de composant
Role: Intgrateur de composants
Obstacles surmonter?
Contraintes
Pour le dveloppeur
Pour lintgrateur
Connaissance insuffisante de lenvironnement

dexcution cible
Mise en uvre des adaptateurs ( glue )
Pb. Evaluer le dlai de ralisation de

ladaptateur p/r celui du composant!
10
Dveloppement de composants
Toujours documenter tous les aspects du

composant

Les fonctionnalits
Les proprits (non fonctionnelles/techniques)

performance,
Consommation des ressources,
Limitations et
Robutesse
Mettre disposition un jeu de Test

Toujours tester le composant dans lenvironnement cible
11
Dveloppement des composants

Provide source code to help the application developer

understand the semantics of the component.
Design the components so that they can be integrated into
existing component models.
Describe models in which the component works and describe
how to make it work with other models.
Carefully generalize the components to permit reuse in a variety
of future contexts.
Note, however, that solving a general rather than a specific
problem requires more work.
Make sure that the application developers can adapt the
component to their requirements. This can be done with sink
interfaces to which the user adds an interface to the component
so that the component can utilize that interface to communicate
with the user.
12
Organisation et Gestion des Projets

Evolution de larchitecture des applications

Systme centralis vers des systmes distribus
Emergence des Technologies de lInternet
Inadquation des modles de processus traditionnel (modles de
la cascade, itratif, spirales et prototypage)
Identification des composants qui peuvent servir dans le cadre du
produit developper
Selection des composants compatibles avec le produit cible
Cration des composants propritaires (ceux des fonctionnalits
dont on a pas trouver de composants)
Adaptation des composants slectionns la spcification des
besoins (Wrapping)
Assemblage/dploiement du produit dans le cadre dun
framework pour composants
Remplacement des composants par de nouvelles versions.
13
Cycle de CBSD vs modle de la Cascade
14
Niveaux dutilisation
Enterprise Architecture
Technologie
des composants
System Architecture
Application Architecture
Macro Architecture
Technologie
Objet
Micro Architecture
object
15
Les composants
Quest-ce que cest ?

module logiciel autonome pouvant tre install sur

diffrentes plates-formes
qui exporte diffrents attributs, proprits ou mthodes
qui peut tre configur
capable de sauto-dcrire
Intrt : tre des briques de base configurables pour

permettre la construction dune application par
composition
Quelques composants de lindustrie

COM / DCOM, Java Beans,

Enterprise Java Beans, Composants CORBA
16
Modles de composants:
caractrisation du composant
Comment coopre un composant

Ce que fournit le composant (entres)

Ce quutilise le composant (dpendances)

composantes, interfaces, oprations, proprits

composition et rfrences aux autres composants
modes de communication des connecteurs (synchrone,

asynchrone, flots)
Proprits configurables du composant

Contraintes techniques (QoS)

middleware : placement, scurit, transaction

internes : cycle de vie, persistance
implantation : OS, bibliothques, version
17
Modle de composants:
Conteneur et structures daccueil
Conteneur

encapsulation dun composant (et ses composantes)

prise en charge (masque) les services systmes
nommage, scurit, transaction, persistance ...
prise en charge partielle des connecteurs
invocations et vnements
techniquement par interposition (ou dlgation)
Structures daccueil

espace dexcution des conteneurs et des composants

mdiateur entre les conteneurs et les services systmes
18
Modles de composants:
Conteneur et structure daccueil
19
Modle de composants: synthse

Le modle gre linfrastructure

Permet ainsi lutilisateur de se concentrer sur les besoins

mtier
Offre diffrents niveau de services aux dveloppeurs
(tableau ci-aprs)
COM
Java
CORBA
COM
component
JavaBeans
CORBA
Objects
Distribution
DCOM
RMI
CORBA IIOP
Services dentreprise
COM+
EJB/J2EE
CORBA
Services
Composant de base
20
Linfrastructure daccueil
Les middlewares
Contraintes de la distribution(1)

Protocoles d'accs distants (CORBA, RMI, IIOP)

Gestion de la charge,
Gestion des pannes,
Persistence, intgration au back-end,
Gestion des transactions,
Clustering,
Redploiement chaud,
Arrt de serveurs sans interrompre l'application,
22
Contraintes de la distribution(2)

Gestion des traces, rglages (tuning and auditing),

Programmation multithread
Problmes de nommage
Securit, performances,
Gestion des tats
Cycle de vie des objets
Gestion des ressources (Resource pooling)
Requte

par message (message-oriented midddleware)

Par appel de procdure distante (RPC)
Par invocation de mthodes distantes (Object-oriented
middleware)
23
Solution
Qui s'occupe de tout ceci : le middleware !

Offre un protocole de communication et un

ensemble de services
Permet que lon se concentre sur lapplication
sans soccuper du reste
Le middleware peut-il exister en dehors

dun modle de composants???
24
Le concept de middleware
Face aux besoins de solutions informatiques de plus

en plus clates et de grande chelle, se posent de
faon aigu les problmes
dintgration de logiciels divers

douverture du systme au monde extrieur

apprhender lconomie mondiale
de conception rapide dapplications portables

viter les O(nn) passerelles
logiciel de plus en plus volutif
La solution est de faire abstraction des supports

matriels et logiciels utiliss, et de se limiter un
mode de coopration unifi entre applications.
Middleware
25
Rle dun middleware(1)
Middleware
Noeud1
Noeud2
Noeudn
Service de communicat ion
26
Rle des middlewares(2)

Middleware ou intergiciel est la couche du milieu

Cest une notion des annes 1990 (CORBA, )
Un middleware se positionne entre les

applications et les supports matriels et les
moyens de communications, en faisant
abstraction de ceux-ci.
L accs ces composantes se fait par des API
normalises et portables
27
Rles dun middleware(3)

Un middleware propose un mode de

coopration entre applications sparant
interface et implantation, souvent fond sur le
mode client/serveur et le n-tier
Programme
utilisateur
Serveur de
traitements
Interface au
serveur de
traitement
Interface au
serveur de
donnes
Serveur de
donnes
28
Modle client/serveur
Client
Programme dapplication faisant linterface entre

un utilisateur et le noyau de lapplication.

Tient compte : des formalismes de lIU

de la machine de support
des logiciels disponibles chez le client
Serveur
Programme fournissant les services dune

application en faisant abstraction des
formalismes, des logiciels dutilisation et des
machines support.
29
Exemple de modle client/serveur

Minitel : le logiciel client (PROM) fait ldition des

requtes et laffichage partir de grilles prdfinies.
Quand existe RAM, les grilles spcifiques dune
application peuvent tre tlcharges et rester sur
le poste Minitel.
Bases de donnes : Un serveur SQL rend la base
interrogeable distance depuis des machines
diffrentes, des systmes de fichiers diffrents, des
interprtes SQL diffrents. Llaboration, ldition, la
connexion des requtes, la mise en forme des
rsultats sont faites par le client.
Web : Browsers diffrents.
30
Fonction de lintergiciel
Lintergiciel a quatre fonctions principales

Fournir une interface ou API (Applications Programming

Interface) de haut niveau aux applications
Masquer lhtrognit des systmes matriels et
logiciels sous-jacents
Rendre la rpartition aussi invisible ( transparente) que
possible
Fournir des services rpartis dusage courant
Lintergiciel vise faciliter la programmation rpartie

Dveloppement, volution, rutilisation des applications

Portabilit des applications entre plates- formes
Interoperabilit dapplications htrognes
31
Typologie des intergiciels

Middlewares par files de messages

Middlewares orients vnements

files de messages entre applications

DECmessageQ, IBM MQSeries
bus applicatifs ToolTalk
communications anonymes entre agents
Middlewares par appel de procdures

distantes

appel de procdures chez le fournisseur

RPC Sun, OSF DCE
32
Typologie des intergiciels

Middlewares orients objet

Middlewares orients documents : Web

orients navigation hypertexte

traitement dans le client (applets) et dans le serveur (cgi,
servlets)
Intgration dapplications
CORBA de lOMG; DCOM de Microsoft
Web Services
Coordination
Accs aux donnes, persistance
Support dapplications mobiles
33
Middlewares par files de messages

Abstraction : lextrieur dune application est vu comme un

ensemble de files de messages de et vers lesquelles on peut
recevoir et envoyer des messages.
Coopration : asynchrone par l'intermdiaire de files de
messages gres par le middleware.
Les applications communicantes doivent tre daccord sur le
contenu des messages - qui nest pas gr par le middleware.
Application A
Application B
rseau
Interprtation
sauvegarde
Middleware
sauvegarde
34
Middlewares sur Bus a Evnements

Abstraction : une application peut publier des vnements sur

le bus, et sabonner des vnements.
Coopration : asynchrone, anonyme et multiple par diffusion.
Un vnement peut tre reu par 0, 1 ou n rcepteurs. Les
applications doivent se mettre daccord sur les types
dvnements.
Application 4
Application 3
Application 1
Application 2
35
middlewares par appel de procedures distantes

Abstraction : une application peut appeler des procdures dans

dautres applications, et fournir des points dentre de procdures
aux autres.
Coopration : client/serveur synchrone. Les interfaces de
procdures sont publies dans un langage RPC IDL qui permet
dobtenir les souches dappel et de rception. Il peut y avoir
diffrentes smantiques dappels (scurit, transactions)
Client
Proc A
Proc A
Proc B
Proc B
Fournisseur
Middleware /RPC
36
Middlewares Orients Objets

Abstraction : une application appelle des services distants

perus comme des objets, elle peut aussi rendre visible des
services dcrits par des interfaces orientes objet.
Coopration : client/serveur par appel de mthodes distantes.
Lobjet est llment de structuration. Les interfaces dobjets
sont publies dans un langage IDL.
IDL
Client
Fournisseur
Middleware
37
Schma de fonctionnement
Site Appelant (Client)
Site Appel (serveur)
appel
Emballage
Envoi(req.,param.)
Client
Rception(req.,param.)
dballage
<attente>
Excution
Procdure
Messages
emballage
envoi(rsultats)
Rception(rsultats)
Deballage
Retour
Proxy
Biblio.
Communication
Biblio.
Communication
Squelette et
Dispatcher
serveur
Communication Physique
Communication Logique
38
L ARCHITECTURE DE
L OMG
CORBA
Le Modle objet client/serveur
Application
Cliente
Rfrence
de lobjet
Code
dimplantation
Bus CORBA
Objet
Requte
CORBA
Activation
Etat de
lobjet
Interface
de lobjet
Application
Serveur
40
Le Modle objet client/serveur

Application cliente : programme qui invoque des objets au

travers du bus.
Rfrence de lobjet : structure dsignant lobjet CORBA
permettant de le localiser.
Interface de lobjet : type abstrait de lobjet CORBA dfinissant
les attributs et oprations.
Requte : mcanisme dinvocation de lobjet.
Objet CORBA : composant logiciel cible.
Activation : processus dassociation dun objet dimplantation
un objet CORBA.
Implantation dun objet : entit codant lobjet CORBA un instant
donn.
Code dimplantation : traitements associs aux oprations.
Application serveur : structure daccueil des objets dimplantation
et des excutions.
41
Larchitecture globale de lOMG

Objets
applicatifs
Interfaces
de domaines
Utilitaires communs
Tlcoms
Spcifiques et
non standardiss
Sant
IHM
Finance
Administration
Data Warehouse
Workflow
Bus dobjets rpartis
Nommage
Persistance
Interrogations
Externalisation
Evnements
Transactions
Relations
Cycle de vie
Proprits
Collections
Changements
Concurrence
Scurit
Temps
Vendeur
Licences
Services dobjets
communs
42
Larchitecture globale de LOMG

Le bus objets rpartis (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)
43
Caractristiques du bus dobjets repartis

CORBA

Liaison avec tous les langages de programmation par

projection d un langage commun IDL.
Transparence des invocations : les requtes aux objets semblent
toujours tre locales, le bus se chargeant de les acheminer au
mieux .
Invocations statiques et dynamiques : requtes compiles ou
cres l excution.
Systme auto-descriptif : les interfaces des objets sont connues
du bus et aussi accessibles par les programmes (rfrentiel des
interfaces).
Activation automatique et transparente des objets : les objets ne
sont en mmoire que sils sont utiliss.
Interoprabilit des bus : partir de CORBA 2.0, un protocole
commun a t dfini (IIOP sur TCP/IP).
44
Larchitecture du bus CORBA

Client
SII
Fournisseur
DII
SSI
DSI
Adaptateur dobjets
Interface Bus
Interface Bus
ORB
ORB
Rfrentiel des interfaces
Rfrentiel des implantations

45
Larchitecture du bus CORBA

ORB : noyau de communication

SII : interface dinvocations statiques
DII : interface dinvocations dynamiques
IR : rfrentiel des interfaces IDL
Interface du bus : primitives de base
SSI : interface de squelettes statiques
DSI : interface de squelettes dynamiques
BOA : adaptateur dobjets
ImplR: rfrentiel des implantations
46
lments dimplantation
Ces diffrents blocs sont dcrits dans le langage IDL, ce qui les
rend accessibles au travers du bus. Cela permet dhomogniser
les diffrentes implantations possibles de la norme.
Il est possible de construire un bus CORBA :
A lintrieur dun seul processus utilisation dIDL pour spcifier
entre processus dune mme machine systme dexploitation
objet (Spring)
entre processus de sites diffrents par exemple sur Internet avec
IIOP
par fdration du bus CORBA passerelles spcifiques ou
gnriques (DSI)
Les IOR pour IIOP doivent contenir :
ladresse IP de la machine Internet

un port pour se connecter au serveur
une cl -de format libre- pour dsigner lobjet dans le serveur
47
Les services objet communs

Objets applicatifs
Interfaces de domaines
Spcifiques et
non standardiss
Tlcoms
Sant
Utilitaires communs
IHM
Finance
Administration
Data Warehouse
Workflow
Bus dobjets rpartis
Nommage
Persistance
Interrogations
Externalisation

Evnements
Transactions
Relations
Cycle de vie
Proprits
Collections
Changements
Concurrence
Scurit
Vendeur
Temps
Licences
Services dobjets
communs
COSS1 : Nommage, Evnement, Persistance, Cycle De Vie

COSS2 : Transactions, Concurrence, Relations,
Externalisation
COSS3 : Scurit, Temps
COSS4 : Interrogations, Licences, Proprits
COSS5 : Vendeur, Collections, Changements
48
Les utilitaires communs et les interfaces de

domaines
Objets applicatifs
Interfaces de domaines
Spcifiques et
non standardiss
Tlcoms
Sant
Utilitaires communs
IHM
Finance
Administration
Data Warehouse
Workflow
Bus dobjets rpartis
Nommage
Persistance
Interrogations
Externalisation
Evnements
Transactions
Relations
Cycle de vie
Proprits
Collections
Changements
Concurrence
Scurit
Vendeur
Temps
Licences
Services dobjets
communs
Utilitaires communs : Interface utilisateur, gestion de

l information, administration du systme, gestion de tches
Interfaces de domaine (objets mtiers) : sant, tlcoms,
finances, commerce Business Object FrameWorks (BOFs)
49
LOMG IDL

INTERFACE DEFINITION LANGUAGE

Le langage IDL permet dexprimer sous la forme de
contrats IDL, la coopration entre les fournisseurs et
les utilisateurs de services

en sparant linterface de limplantation des objets

en masquant les divers problmes lis linteroprabilit,
lhtrognit et la localisation de ceux-ci
Contrat IDL = {interfaces crites en IDL}

Interface IDL = {attributs et oprations dun type
dobjet}
50
LOMG IDL

Un contrat IDL isole les clients et les fournisseurs de

linfrastructure logicielle et matrielle les mettant en
relation, cest--dire du bus CORBA.
Les contrats IDL sont projets en souches IDL dans
lenvironnement de programmation du client et en
squelettes IDL dans lenvironnement de
programmation du fournisseur.
Contrat
Client
Fournisseur
IDL
Le client
invoque localement
les souches
pour
Squelette
accderSouche
aux objets
Bus CORBA
Les souches IDL construisent des requtes, qui vont
tre transportes par le bus, puis dlivres par celuici aux squelettes IDL qui les dlgueront aux objets
51
IDL : un langage fortement type

Valeurs IDL
Types dynamiques
Types complexes
TypeCode
any
Types simples
Short
UShort
Long
Ulong
LongLong
ULongLong
Types dobjets
Dfinis par
lutilisateur
Enum
Struct
Union
Array
Sequence
Float
Double
LongDouble
Char
WChar
String
WString
Boolean
Octet
52
IDL : UN LANGAGE
FORTEMENT TYPE
Le format des types de base est dfini par la norme pour rgler
les problmes dhtrognit des donnes.
Nouveaut : les types de mtadonnes :
TypeCode : pour stocker la description dun type.
Any : pour stocker une valeur dun type et son TypeCode.
Interface PileGnrique {
readonly attribute any sommet;
void empiler (in any valeur);
...
ID
L
53
I D L : HERITAGE
interfaceCalendrierFerie: Calendrier {..};

interface Calculatrice {..};
Interface Calendrier_Calculatrice: Calendrier, Calculatrice {..};
Interface CalendrierFerie_Calculatrice: CalendrierFerie_Calculatrice {};
Calendrier
CalendrierFerie
Calculatrice
Calendrier_Calculatrice
CalendrierFerie_Calculatrice
54
I D L : HERITAGE
Hritage simple et multiple
Pas de redfinition ni de surcharge
Conflits de noms interdits
Hritage rpt sans conflits de noms
Un objet ne peut implanter quune et une

seule interface (pour linstant)
55
La projection du langage IDL

Fichier IDL
Prcompilateur
IDL vers C++
Prcompilateur
IDL vers Java
Client C++
Serveur Java
Souches C++
Squelette Java
IIOP
ORB A
ORB B
Une projection est la traduction dans un langage

dimplantation de spcifications IDL
Les rgles de projection sont normalises 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.

56
OMG IDL : CONCLUSION

Langage simple et complet

MAIS

Rgles de projections complexes

Pas de passage dobjets par valeur
Pas de possibilits dexprimer autre chose que les
interfaces.

Smantiques
pr/post conditions
graphes dobjets
...
57
LES COMPOSANTES DU
BUS CORBA
Les principales composantes ncessaires la mise en uvre dun bus
CORBA sont :
linterface de base au bus

les adaptateurs dobjets
le rfrentiel des interfaces
le rfrentiel des implmentations (non encore normalis)
Elles sont dcrites en IDL dans le module CORBA

Elles compltent le mcanisme dinvocations (SII) et de rception
(SSI) statiques (souches et squelette rsultat de la compilation IDL).
Un autre mcanisme de coopration client/serveur consiste en
interfaces dinvocations (DII) et squelettes (DSI) dynamiques.
58
LINTERFACE O R B
Une rfrence vers un objet de type CORBA::ORB est retourn
linitialisation du bus.
Elle permet dobtenir ensuite les premiers objets utiles : les objets
notoires que sont par exemple le service de nommage et le
rfrentiel des interfaces.
ID
L
interface ORB {
typedef string ObjectId;
typedef sequence<ObjectId>ObjectIdList;
ObjectIdList list_initial_services O;
Pbject resolve_initial_references (in ObjectID identifier);
};
59
LINTERFACE O R B
Linterface ORB dfinit aussi les oprations de conversion

rfrence dobjet
chane IOR
ID
L
interface ORB {
string Object_to_string (in Object obj);
Object string_to_Object (in string str);
};
60
LES ADAPTATEURS DOBJETS

Une implantation dun objet doit fournir un espace mmoire et un
contexte dexcution. Lactivation dune implantation est ralise
dans le monde CORBA par un adaptateur dobjet.
Cela isole le bus des diffrentes technologies pouvant tre
employes dans limplantation des objets.
Un adaptateur dobjet doit :

Connatre les implantations utilises et savoir les activer,

savoir gnrer et interprter des rfrences d objets,
savoir dlguer les demandes d oprations vers les objets
BOA : Basic Object Adapter

LOA : Library Object Adapter
OODA : Object-Oriented Database Adapter
POA : Portable Object Adapter (nouveau)
COA : Card Object
adapter (LIFL/Gemplus)
61
LE REFERENTIEL DES INTERFACES
Toutes les dfinitions IDL sont conserves dans un rfrentiel des

interfaces structur comme un ensemble dobjets, eux -mmes dcrits
par des interfaces IDL et donc accessibles du bus.
Utilisations :

Distribution des interfaces IDL,

contrle des graphes dhritage,
construction doutils gnrateur de code, AGL ou browsers,
vrification des signatures des oprations,
fdration de bus CORBA,
introspection et objets auto-descriptifs.
62
LE REFERENTIEL DES INTERFACES
La norme CORBA dfinit les interfaces IDL de consultation,

de navigation et de modification du rfrentiel des interfaces.
Cest la ressource la plus volumineuse des implantations CORBA

(+ de 50 % des points d entre)
63
LES MECANISMES DYNAMIQUES

Le mcanisme DII (Dynamic Invocation Interface)
Ce mcanisme permet un client dinvoquer les objets sans utiliser de souches
IDL prgnres. Pour cela le client va construire dynamiquement les requtes,
et doit donc dcouvrir dynamiquement, via lIR, linterface des objets.
L API DII permet de crer des objets de type Request, et dy placer la rfrence
de lobjet cible, le nom de lopration, la liste des arguments et le rsultat.
Request
Rfrence de lobjet
Nom de lopration
nom de largument
rsultat
any
valeur
TypeCode
64
LES INTERETS DU MECANISME DII

Le client s adapte dynamiquement aux objets quil souhaite

invoquer.
Ceux-ci peuvent donc voluer sans modifications de clients.
Possibilit de construire des clients sans connatre les types

des objets quils utiliseront.
Indispensable pour la navigation dans les bases dobjets
dcouvertes dynamiquement.
Mcanismes de base pour la cration dIHM, de browsers et

de langages interprts utilisant des objets CORBA.
CORBA
65
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..
66

Le mcanisme DSI (Dynamic Skeleton Interface)
Ce mcanisme permet un serveur de recevoir
des requtes sans utiliser le squelettes IDL
prgnrs. Il peut donc traiter des requtes pour
n importe quel type d objets.
L API DSI permet de rcuprer les diffrentes

composantes d une requte.
67

Le mcanisme DSI fut initialement dfini pour permettre
la mise en place de passerelles entre bus CORBA. Il est
possible de lutiliser pour implanter dynamiquement des
objets dans un serveur.
passerelle
client
serveur
IDL
DSI
DII
requte A
IDL
requte B
68
LES SERVICES NORMALISES DE

CORBA
Common Object Service Specifications COSS
COSS 1 : Nommage, Evnement, Persistance, Cycle de vie.
COSS 2 : Transactions, Concurrence, Relations, Externalisation.
COSS 3 : Scurit, Temps.
COSS 4 : Interrogations, Licences, Proprits.
COSS 5 : Vendeur, Collections, changements.
69
Service nommage: Name service

Lobjectif est de permettre de retrouver

dynamiquement les objets ncessaires
(service de pages blanches ).
Ce service gre un graphe de contextes de
nommage, chaque contexte tant une liste
dassociations nom symbolique - rfrence
dobjet.
70
CosNaming::Name est la dfinition IDL des chemins

d accs dans le graphe de contextes
Un chemin est une squence de composants
(en IDL : CosNaming::NameComponent)
71

Un contexte est dfini en IDL par

CosNaming::NamingContext et fournit des
oprations de base telles l ajout (bind) ou la
recherche (resolve) d une association, ou
encore l obtention du contexte dans une liste
dfinie par
CosNaming::BindingList et
CosNaming::Binding.
72
Service vendeur: Trader service

Mme principe que le service nommage sous

la forme pages jaunes
Les fournisseurs enregistrent leurs objets
dans ce service en les caractrisant par un
ensemble de proprits (paires nom-valeur).
Les clients indiquent le type de service dsir
et des critres pour effectuer la recherche.
Comme pour le service de nommage,il est
possible de fdrer les services Vendeur.
73
Service vnements: Event Service

Ce service permet aux objets de produire des

vnements asynchrones destination
dobjets consommateurs, et cela au travers
de canaux dvnements.
Mode Push :

le producteur a linitiative,
le consommateur est notifi des dpts.
Mode Pull :
le consommateur met des requtes de retrait.

74
Service vnements: Event Service

Un canal peut tre non-typ (any) ou typ (IDL).
producteur
consommateur
Push
Pull
Canal dvnement
75
Service transactions: Object Transaction

Service (OTS)
Ce service assure lexcution de traitements

transactionnels impliquant des objets
distants.
2-invoke (c)
Client
4-End T
Serveur
3-register
ORB
1-Begin T
5-propagate
context
Transaction Service
76
Service securite: Security Service

Ce service permet didentifier et dauthentifier

les clients, de chiffrer et de certifier les
communications et de contrler les
autorisations daccs.
Ce service utilise les notions de :

serveur dauthentification
clients / rles / droits (et dlgation de droits)
Secure IIOP (utilisant Kerberos ou SSL)
77
Service concurrence d acces: Concurrency

Service

Ce service fournit les mcanismes pour

contrler et ordonnancer les invocations
concurrentes sur les objets.
Le mcanisme propos est le verrou.
verrou
Ce service est conu pour tre utilis
conjointement avec le service de transactions.
78
Le service cycle de vie Life Cycle

Service
Ce service dcrit des interfaces pour

la cration,
la copie,
le dplacement,
la destruction
des objets du bus.

Il dfinit la notion dObject Factory
79
Le service changements (Versionning

Service)
Ce service permet de grer et de suivre

lvolution des diffrentes versions des
objets.
Ce service maintient des informations sur les
volutions des interfaces et des
implantations.
implantations
80
Le service temps (Time Service)

Ce service fournit des interfaces permettant

dobtenir une horloge globale sur le bus (Universal

Time Object)
de mesurer le temps
de synchroniser les objets.
81
Conclusion
Les Middlewares rpondent aux besoins des

applications et systmes

rpartis,
htrognes,
ouverts,
volutifs.
Restent les problmes lis leur complexit de

mise en uvre
Ils servent de socle aux infrastructures daccueil
Lmergence des modles de composants a
favoris la diffusion de la technologie.
82
Bibliographie
Szyperski C. Component software: beyond object-oriented

programming. Addison wesley, reading, Mass., 2nd Edition
Gamma E. and al. Design Patterns, Elements of reusable ObjectOriented 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
83

Technologie Des Composants

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Technologie Des Composants

Transféré par

Droits d'auteur :

Formats disponibles

CBSE: Component Based Software Engineering

Technologie des Composants

CBSE (Component based software

Logiciel = assemblage de composants

Cours de Gnie Logiciel

A binary unit of independent production, acquisition, and

Pas de dfinitions universel (un peu comme les

Cours de Gnie Logiciel

OT is Neither Necessary Nor Sufficient for CBSE

OT was a useful and convenient starting point for CBSE

CBSE induit des changements dans lapproche de

Cours de Gnie Logiciel

Structure dun Composant

Interface (opration requise)

Interface (oprations offertes)

Cours de Gnie Logiciel

Spcification des composants

Un mta modle UML pour la spcification smantique des composants

Spcification des points daccs au

Cours de Gnie Logiciel

Dveloppement des composants

Construire des composants ouverts lintgration

Dveloppement avec les composants

Intgrer/assembler des composants pour en faire

Role: Dveloppeur de composant

Role: Intgrateur de composants

Cours de Gnie Logiciel

Connaissance insuffisante de lenvironnement

Pb. Evaluer le dlai de ralisation de

Cours de Gnie Logiciel

Toujours documenter tous les aspects du

Mettre disposition un jeu de Test

Toujours tester le composant dans lenvironnement cible

Cours de Gnie Logiciel

Dveloppement des composants

Provide source code to help the application developer

Cours de Gnie Logiciel

Organisation et Gestion des Projets

Evolution de larchitecture des applications

Cycle de CBSD vs modle de la Cascade

Cours de Gnie Logiciel

Cours de Gnie Logiciel

Quest-ce que cest ?

module logiciel autonome pouvant tre install sur

Intrt : tre des briques de base configurables pour

COM / DCOM, Java Beans,

Cours de Gnie Logiciel

Comment coopre un composant

Ce que fournit le composant (entres)

Ce quutilise le composant (dpendances)

composantes, interfaces, oprations, proprits

modes de communication des connecteurs (synchrone,

Proprits configurables du composant

middleware : placement, scurit, transaction

encapsulation dun composant (et ses composantes)

espace dexcution des conteneurs et des composants

Cours de Gnie Logiciel

Cours de Gnie Logiciel

Modle de composants: synthse

Le modle gre linfrastructure

Permet ainsi lutilisateur de se concentrer sur les besoins

Cours de Gnie Logiciel

Protocoles d'accs distants (CORBA, RMI, IIOP)