DCOM - fil

Plan
Distributed Component Object Model
1. DCOM - DCE
2. DCOM & Co.
DCOM / COM+
3. Fonctionalités
4. Définitions
Lionel Seinturier
5. MIDL
Université Pierre & Marie Curie
6. Interface
[email protected]
7. Serveur
11/7/02
1
Lionel Seinturier
DCOM
2
1. DCOM - DCE
Lionel Seinturier
1. DCOM - DCE
DCE : Distributed Computing Environment
Applications
• modèle de système distribué
• défini par le consortium Open Group (X11, Motif, CDE, ...)
• 3 versions majeures (1992 : 1.0 / 1994 : 1.1 / 1996 : 1.2)
• www.opengroup.org/tech/dce/
autres serv.
à définir
• même but (succès ? échec ?) que le modèle des couches réseaux ISO
• organisation de l’environnement réparti en cellules
• la cellule reflète au niv. inform. le schéma organisationnel de l’entr.
Ex. : - 3 cellules : conception, production, marketing
- ou 2 cellules : grille-pain (c. p. m.), moteur (c. p. m.)
DCE
Service de
sécurité
Serv. stations
sans disque
Service de fichiers distants
Service
de temps
Service
de noms
aut. serv.
à définir
Service
d’administration
DCOM
RPC
Threads
• chaque cellule contient au moins en 1 exempl. les types de serveurs
définis par l’architecture DCE
DCOM
3
Lionel Seinturier
Système d’exploitation
DCOM
4
Lionel Seinturier
1. DCOM - DCE
1. DCOM - DCE
Architecture DCE
DCE vs CORBA
• Threads : gestion de processus légers ( règles priorité + ordonn. + synchro. )
• RPC : gestion d’invocations distantes ( ≠ sém. : au + 1, au - 1, diff. à tous )
• pas OO
• plus proche du système d’exploitation
• moins de services disponibles
• néanmoins services + fondamentaux du pt de vue syst. (threads, sécurité)
• Service de temps : assure la synchronisation d’horloges locales
• Service de noms : correspondance entre identifiants logiques et localisations ϕ
( ≡ CORBA COSNaming, RMIRegistry)
• Service de fichiers distants (DFS) :
montage de partitions disques par rsx ( ≡ NFS ), basé sur AFS
• Service de stations sans disque : serveur de démarrage pour des terminaux légers
• Service de sécurité : crypte et authentifie les com. sur un rsx
( ≡ CORBA COSSecurity ), basé sur Kerberos
• Service d’administration : permet d’administrer et de configurer à distance les
les serveurs de l’env. DCE
DCOM
5
Lionel Seinturier
• pas vraiment d’implantations disponibles en accès libre (GPL, ...)
• base logicielle installée nettement moins importante
• techno. DCE essentiellement utilisée par de grandes applications indust.
→ non visible à l’utilisateur λ
• techno. DCE trop en avance sur son temps ?
DCOM
2. DCOM & Co.
Format de données
Bus de
communication
OLE 1.0
DDE
OLE 2.0 16 bits
COM
OLE 32 bits
NT 3.51
COM
RPC DCE
OCX
OLE Network
NT 4
DCOM
ActiveX
7
Lionel Seinturier
2. DCOM & Co.
Galaxie des technologies middleware de Microsoft
DCOM
6
Modèle de
composants
graphiques
OLE : Object Linking and Embedding
définit un format d’échange de données entre applications
3 types d’informations :
- données de présentations (méta-fichier graphique)
- informations de classe (id. de l’application créatrice)
- données brutes (ou réf. à un fichier les contenant)
DDE : Dynamic Data Exchange
basé sur le syst. d’évts de Windows
permet à 2 applications d’échanger des données dynamiquement
Lionel Seinturier
COM : Component Object Model
standard binaire de :
- communication avec un objet
- gestion du cycle de vie de l’objet
- définit comment un obj. indique aux autres ce qu’il sait faire
DCOM
8
Lionel Seinturier
2. DCOM & Co.
3. Fonctionalités
• transparence à la localisation des objets
• activation d’objets dynamique et à distance
- SCM (Service Control Manager) : 1 par machine d’un env. DCOM
• sécurité des communications
- NTLM (NT Lan Manager authentification protocol)
- SAM (Security Account Manager)
• accès aux objets via des interfaces
• support du cycle de vie des objets (création, destruction)
• découverte dynamique des interfaces implantées par un objet
• intéropérabilité binaire entre langages hétérogènes
• détection des pannes de serveurs/rsx
- mécanisme de ping géré par le OXID Resolver
• isolation des ctx d’exéc. dans des apartments (MTA:multi-thr. / STA:single thr.)
• réutilisation d’objets par contenance ou agrégation (pas d’héritage)
• référentiel d’interfaces (type library) et d’implantations
• invocation de méthode statique et dynamique (automation)
• mécanisme de gestion d’événements distribués
Evolution de DCOM
COM+
intégration dans DCOM de
• MTS (transaction)
• MSMQ (mess. async.)
DNA
Distributed interNet
applications Architecture
Modèle DNA
DCOM
9
Lionel Seinturier
DCOM
10
4. Définitions
4. Définitions
Exemple
Objet COM ≈ objet au sens CORBA ou RMI
- entité accessible à distance par rsx
- possédant 1 ou +sieurs interfaces
- répondant à des invocations de méthodes
- construit à partir d’une classe
MonComposantCOM (EXE) [machine 1]
IUnknown
ILoveCOM
Composant COM
- module binaire (DLL ou EXE)
- contenant 1 ou +sieurs objets COM
- comp. ActiveX = composant COM avec une interface graphique
IUnknown
IViewer
CoPersonality
CoViewer
IHateCOM
OCRServer (DLL) [machine 2]
Légende graphique
ORPC
IUnknown
Objet COM
IOCR
Composant COM
CoOCREngine
Objet
COM
Objet
Interface
DCOM
Lionel Seinturier
11
Lionel Seinturier
DCOM
12
DCOM
RPC DCE
ORPC
RPC
Lionel Seinturier
4. Définitions
5. MIDL
Interface COM
Langage de description des interfaces des objets COM
• collection de fonctions
• API binaire ≡ tableau de pointeurs ou vtable (virtual table)
vers les méthodes d’un objet COM (écrits en C++, Java ou VB)
• permet de définir des interfaces, constantes, types et opérations
• pas de variables (au sens attributs de IDL CORBA)
• supporte l’héritage d’interfaces
• convention graph. : prises jacks dans des diag. dits bullet and stick
• tout obj. COM doit au moins implanter l’interf. prédef. IUnknown
• permet la def. de librairies = interf. implantées par les classes d’un composant
• chaque interf. COM est associée à un IID (Interface IDentifier)
- nombre sur 128 bits qui identifie de manière unique toute interface
- déterminé par un algo. mis au point par l’OSF pour DCE
qui utilise la date, l’heure, l’id. de la carte rsx
et un compteur haute fréquence ( ≡ fonction de hachage )
- créable à l’aide de primitives syst. (CoCreateGuid) de l’API Windows
• décrite dans le langage MIDL (Microsoft Interface Definition Language)
DCOM
13
Lionel Seinturier
librairie associée à ce composant
- 1 classe avec 3 interfaces
- 1 classe avec 2 interfaces
• les librairies et les classes sont associées à des identifiants uniques
(de même type que ceux des interf.)
• les lib., classes et interf. ont des paramètres qui en précisent la sémantique
• les méth. des interf. retournent tjrs un param. du type prédéf. HRESULT
DCOM
5. MIDL
14
Lionel Seinturier
5. MIDL
Structure d’un fichier MIDL
Types de données MIDL
Exemple
[paramètres]
<interface>
<constantes>
<types>
<opérations>
• boolean (1 octet)
• byte (1)
• char (1), wchar_t (2, Unicode)
• float (4), double (8)
• small (1)
• short (2)
• long (4)
• hyper (8)
typedef long age;
[paramètres]
<librairie>
[paramètres]
<classes>
[paramètres]
<interfaces>
partie parfois désignée
par l’acronyme ODL
DCOM
[ object, uuid(9372A220-B4BD-11d1-ABE1-00207810D5FE) ]
interface IOcr : IUnknown {
const char * chaine = «exemple»;
typedef float reel;
[message] HRESULT met( [in] boolean bool,
[in,size_is(12)] byte * p );
HRESULT meth2( [out,string] wchar_t * ptr );
}
[ uuid(9372A2B2-B4BD-11d1-ABE1-00207810D5FE), version(1.0) ]
library OCREngineLib {
enum couleur {rouge, vert, bleu};
union carre switch(couleur c) {
case rouge: short num1;
case vert : long num2;
case bleu : hyper num3;
};
• * (4 octets, pointeur)
• [] (tableau)
• enum (énumération)
• struct (structures)
• union (type discriminé)
• VARIANT (type indifférencié)
[ uuid(9372A2B3-B4BD-11d1-ABE1-00207810D5FE) ]
coclass CoOcrEngine {
[default] interface IOcr;
interface ISpell;
} }
15
struct personne {
float taille;
long age;
};
Lionel Seinturier
DCOM
typedef long tab [];
typedef short * ptr;
16
Lionel Seinturier
5. MIDL
5. MIDL
Paramètres des interfaces
• [object]
: objet COM distant
: objet COM local
• [local]
• [uuid]
: l’identifiant de l’interf.
: n° de version de l’interf.
• [version]
Valeur de retour des méthodes
• pas d’exception (au sens CORBA IDL, Java ou C++)
! HRESULT : valeur sur 32 bits qui indique si l’op. a réussi ou échouée
Paramètres des méthodes
• [message]
: appel de méthode asynchrone (seul. param. entrée)
: idem mais sémantique de l’appel best effort
• [maybe]
Paramètres des arguments de méthodes
• [in], [out] et [in,out] : entrée, sortie et entrée/sortie
• [size_is(n)]
: taille pour un pointeur ou un tableau
• [string]
: le pointeur est considéré comme une chaîne
≡ zone mémoire terminée par NULL
S
R
Source
Code
• S : 1 bit ( 0 : succès / 1 : échec )
• R : 2 bits réservés (à une utilisation future ?)
• Source : 13 bits indiquant qui a généré l’erreur (RPC, rsx, Windows, ...)
• Code : 16 bits correspondant des codes d’erreur spécifiques à chaque source
≈ 50 paramètres ! complexe !
DCOM
17
Lionel Seinturier
DCOM
6. Interface
Interface IDispatch
• définit les opérations
- QueryInterface : retourne une liste des interf. implantées par l’obj.
- AddRef : appelée chaque fois que l’on crée une réf. suppl. sur l’obj.
- Release : appelée chaque fois que l’on libère une réf. sur l’obj.
• doit être implantée par tout objet COM
DCOM
Lionel Seinturier
6. Interface
Interface IUnknown
ptr
18
vtbl
Implantations
pfnQueryInterface
pfnAddRef
pfnRelease
pfnOcrImage
pfnOcrZone
CoOcrEngine::pfnQueryInterface
CoOcrEngine::pfnAddRef
CoOcrEngine::pfnRelease
CoOcrEngine::pfnOcrImage
CoOcrEngine::pfnOcrZone
19
Lionel Seinturier
• permet l’invocation dynamique de méthode ( ≡ CORBA DII + DSI )
• invoc. dyn. : appelée Automation dans le vocabulaire Microsoft
• principe : interrog. d’une interf. pour savoir si elle implante la méthode x
• les interf. invoc. dyn. doivent hériter de IDispatch ou
être déclarées en tant que dispinterface
≡ interface IOcrPanel: IDispatch
dispinterface IOcrPanel {
methods: [id(1)] HRESULT Status( [in] short status );
properties: [id(2)] short Age;
}
• possibilité de déf. des propriétés ( ≡ attributs d’une interf. CORBA IDL )
• meth. et prop. d’une interf. IDispatch sont associées à des identifiants
• les interf. IDispatch def. 4 méth. spéc. à implanter (en + des 3 de IUnknown)
• les interf. invoc. dyn. sont stockées dans une type library
• les interf. invocables stat. et dyn. sont dites duales (prop. dual de l’interf.)
DCOM
20
Lionel Seinturier
7. Serveur
7. Serveur
Serveur COM = exécutable qui implante 1 ou +sieurs interf. COM
Scénario de création d’un serveur COM
• le serveur ne crée pas
directement des obj. COM
• il utilise une class factory
= obj. chargé d’instancier
d’autres objets
1. le serveur instancie une class factory et l’enregistre auprès de COM
2. le client demande un pointeur sur cette class factory
3. le client demande une instance de cette classe
4. la class factory crée l’instance et retourne un pointeur
5. le client interagit avec l’instance
6.7.8. le client libère les ptrs de l’inst. et de la cl. fact., le serv. est éteint
objet COM
objet COM
objet COM
Class & Co
Objet client
IClassFactory2
3 types de serveurs
- in-process : DLL, même espace mémoire que le client (pb de sécurité ?)
- out-of-process
- locaux : EXE, communication par lightweigth RPC (optimisé)
- distants : EXE, communication par ORPC
- surrogate : encapsulateur de serv. in-process en serv. out-of-process
! permet à des in-process d’être accédés à dist.
! renforce leur sécurité
DCOM
21
Lionel Seinturier
Serveur
API COM
1. CoRegisterClassObject
2. CoGetClassObject
4. Create
3. CreateInstanceLic
5. appels de méthodes
6. Release
7. Release
8. CoRevokeClassObject
DCOM
22
7. Serveur
Lionel Seinturier
7. Serveur
Serveurs sources et puits
Réutilisation de code dans les serveurs COM
• permet de gérer des événements distribués ( ≡ CORBA COSEvent )
• les obj. sources spécifient (en IDL) les événements qu’ils produisent
• les obj. puits spécifient (en IDL) les événements auxquels ils s’abonnent
• pas d’héritage pour les objets COM
• une réutilisation du code par contenance/délégation ou agrégation
• les obj. sources sont dits connectables, leurs interf. sont dites sortantes
• les obj. puits sont appelés sinks, leurs interf. sont dites entrantes
• contenance = l’obj. encapsulateur délègue les appels aux obj. contenus
• agrégation = les interf. des obj. contenus sont visibles directement de l’extérieur
les obj. internes délègent leur interf. IUnknown à l’encapsulateur
interf. entr.
connectable
obj. source
DCOM
IUnknown
de A, B, C
sink
obj. puits
interf. sort.
23
IUnknown
de A, B, C
A
A
A
A
sink
obj. puits
B
B
C
B
sink
obj. puits
C
C
C
C
Lionel Seinturier
DCOM
24
Lionel Seinturier
7. Serveur
Moniker
• identificateur qui agit comme un alias persistant pour un obj. COM
• doit implanter l’interf. IMoniker
• fournit par ex. un accès transparent à un fichier distr., une req. d’une bd,
un parag. dans un doc., les cellules d’un tab., une machine dist.
Types de monikers
• file moniker : alias pour un nom de fichier
• item moniker : élément dans un fichier en liaison avec un file moniker
ex : ligne dans une feuille de calcul Excel
• generic composite moniker : collection d’autres monikers
• anti moniker : «bidouille» pour les gc monikers
permet de spécifier «ignore le moniker suivant dans la liste»
cause : on ne peut pas retirer de moniker d’un gcm, seul. en ajouter un
DCOM
25
Lionel Seinturier