(ActiveX - & - VB6) DCOM

Travail de diplme Visual Basic 6 & technologie ActiveX Frdric Comte
Distributed COM Page Gnr le 22.03.2004 1

Distributed

COM

NB : ce fascicule fait partie dun travail de diplme sur le sujet Technologie ActiveX &
Visual Basic 6 , paru en dcembre 2001 pour lobtention du diplme dIngnieur logiciel
lEIVD (Suisse).
Les autres fascicules sont disponibles ladresse http://activex.developpez.com. La
reproduction - sous nimporte quelle forme que ce soit - est libre de droits. Veuillez
tout de mme en informer lauteur.
Critiques, remarques, questions ? frederic@youplaboum.ch.



1 - Introduction

Lassociation des concepts dobjet et de rpartition a donn naissance un nombre
impressionnant de langages, de systmes et de bibliothques dobjets rpartis. Tous les
projets actuels darchitectures rparties sont bass sur le concept dobjet. Dune part, les
chercheurs issus de la communaut langage de programmation objets tendent les
environnements de programmation vers des architectures rparties, et dautre part, les
chercheurs issus de la communaut systme adoptent le modle objet pour
structurer les concepts de la rpartition.

Bien que certains dveloppeurs universitaires associent les objets et la rpartition
suivants une approche particulire (intgre ou applique), la grande majorit des
systmes objets rpartis, et en particulier, les produits commerciaux, font une
synthse pragmatique des deux approches. Parmi les rejetons du couple objet et
rpartition, les plus connus ont pour noms CORBA, DCOM, Java/RMI, ou encore ONE.

CORBA

Depuis 1989, une association internationale appele lOMG (Object Management Group),
dfinit la spcification de larchitecture dun systme objets
rpartis, appele CORBA (Common Object Request Broker
Architecture). Prs de 700 socits sont actuellement membres de
lOMG, dont aussi bien des socits informatiques comme HP, Sun,
Microsoft, ou IBM, que des utilisateurs comme Boeing ou Alcatel. A
linverse dODP (Open Distributed Processing) - un autre effort de
standardisation darchitectures rparties - CORBA a t dfini dans
un but trs pratique, et de nombreuses mises en oeuvre de la
spcification CORBA sont actuellement sur le march, incluant SOM de IBM, Orbix de
Iona, et Visibroker dInprise.

CORBA associe les concepts dobjet et de rpartition dans une approche la fois intgre
et applique. Lintgration se fait travers la notion dinvocation distance dobjet
(lobjet est lunit de rpartition), et lapplication se fait travers les services de
rpartition qui sont organiss sous forme de bibliothques de classes.

CORBA sappuie sur le protocole IIOP (Internet Inter-ORB Protocol) pour les objets
distants. Toute larchitecture de CORBA dpend dun ORB (Object Request Broker), qui
agit comme un bus objets central sur lequel chaque objet CORBA interagit de manire
transparente avec dautres objets CORBA, quils soient locaux ou distants. Chaque objet
serveur CORBA a une interface (dcrite en IDL, Interface Description Langage), et
expose un ensemble de mthodes. Pour appeler un service, un client acquiert une
rfrence objet un objet serveur, puis il peut - au travers de cette rfrence - effectuer
des appels de mthode comme si lobjet serveur rsidant dans lespace dadressage du
client. LORB soccupe de trouver limplmentation des objets CORBA, de la prparer
recevoir des requtes, de les lui communiquer, et de rpondre au client. Les objets
CORBA interagissent avec ORB soit au travers de linterface de ce dernier, soit au travers
dun adaptateur dobjet (Object Adapter), les plus frquents tant BOA (Basic Object
Adapter), et POA (Portable Object Adapter).

Etant donn que CORBA nest quune spcification, elle peut tre porte sur diverses
plates-formes comme UNIX ou Windows, aussi longtemps que limplmentation des ORB
sur ces plates-formes existent.


DCOM

Bien que membre de lOMG, Microsoft a dvelopp son propre standard dobjets rpartis,
appel DCOM (Distributed Component Object Model). Le terme standard revt dans
ce contexte un caractre particulier, car il signifie standard pour - et seulement pour -
les produits Microsoft.

DCOM supporte les objets distants grce au protocole ORPC (Object Remote Procedure
Call), qui lui, est bas sur RPC (Remote Protocol Call, de DCE : Distributed Computing
Environment) et interagit avec les services run-time de COM. Un serveur DCOM est un
code capable de servir des objets dun type particulier en cours dexcution. Chaque
objet serveur DCOM peut supporter des interfaces multiples, chacune dentre elle
reprsentant un comportement diffrent de lobjet. Un client DCOM appelle les mthodes
exposes dun serveur DCOM en pointant une des interfaces de lobjet du serveur.
Cet appel, au travers du pointeur vers linterface, seffectue comme si lobjet serveur
rsidait dans lespace dadressage du client. Etant donn la spcification binaire de COM,
les composants serveurs DCOM peuvent tre crits en C++, Java, Delphi, Visual Basic,
voire mme COBOL. Aussi longtemps quune plate-forme supporte les services COM,
DCOM lest aussi.

DCOM est le modle distribu de composants le plus utilis sur plate-forme Windows.
Malgr son caractre standard , Microsoft fournit une implmentation aussi bien pour
plate-forme Windows que pour plate-forme Solaris. Notons galement que dautres
compagnies fournissent galement des implmentations : Software AG fournit une
implmentation des services COM et DCOM pour UNIX et Linux avec le produit EntireX, et
Digital permet doprer sur plate-forme OpenVMS.

Java/RMI et Java Beans

La bibliothque de classes RMI (Remote Method Invocation), dveloppe par la socit
JavaSoft (filiale de Sun Microsystems) sappuie sur le protocole JRMP (Java Remote
Method Protocol). Essentiellement bas sur la
srialisation - qui permet aux objets dtre
transmis (marshalling) comme un flux -
spcifique Java (Java Object Serialization), les
objets serveurs et clients doivent tous deux tre
crits en Java. Chaque objet serveur dfinit une
interface permettant daccder lobjet depuis la
machine virtuelle Java dun ordinateur distant
1
.
Linterface expose un ensemble de mthodes
indiquant les services offerts par lobjet serveur.
RMI dpend du mcanisme de nommage RMIRegistry (sexcutant sur la machine
serveur) et permettant de contenir toutes les informations relatives au serveur objets.
Le client RMI acquiert une rfrence un objet serveur en effectuant un lookup sur le
serveur objets, et invoque ensuite les mthodes dsires de la mme manire que si
lobjet serveur rsidait dans son espace dadressage.
Les objets serveurs RMI sont nomms avec une URL (Uniform Resource Locator); ainsi,
un client dsirant obtenir une rfrence sur un objet serveur spcifiera lURL de ce
dernier de la mme manire quon adresse une page HTML.

1
Java, du moins dans les premires versions des bibliothques, ne permet pas linvocation dobjets distants.
Java intgre les objets et la rpartition travers le mcanisme de migration : cest le code qui se dplace.
Lorsquun navigateur comme Netscape charge une page web et rencontre dans un code HTML une tiquette
dsignant une applet Java (soit un programme Java qui peut se tlcharger sur le web), il retrouve le code de
lapplet et le fait migrer vers le site client (en tablissant une connexion TCP/IP). La machine virtuelle Java du
navigateur permet ensuite dexcuter le code Java (en fait le byte code) migr chez le client. Puis le navigateur
efface ensuite le code de la mmoire lorsquil quitte la page web en question.

Java/RMI fonctionne sur toutes les plate-formes implmentant une machine virtuelle
Java.

Lintroduction des Java Beans (puis des EJB
2
, Entreprise Java Beans) pour le
dveloppement dapplications sous forme dun assemblage de composants sappuyant sur
un canevas a dmontr la validit du concept, validit dj dmontre en partie par les
ActiveX, malheureusement tributaires dune seule plate-forme.
Java Beans est un modle de composants portables et multi-plate-forme crit en Java. Il
permet aux dveloppeurs dcrire des composants selon le dogme write once - run
everywhere en bnficiant de la portabilit et de la puissance de Java. Leur
spcification a t dfinie par Sun et de nombreux autres acteurs, tel IBM, impliqus
dans le monde Java, dans le but dinstaurer un vritable march des composants
logiciels.

Les Beans peuvent tre manipuls dans des outils de dveloppement graphique (Jbuilder
de Borland ou Visual Age dIBM par exemple). Un Bean est une classe Java classique qui
adhre certaines conventions concernant ses proprits et sa gestion des vnements.
Cest grce au respect de cette norme quil peut tre analys par lenvironnement qui
laccueille.

1.1 Une comparaison entre Java Beans et ActiveX.

Facilits de maintenance

De ce ct, lavantage a longtemps t du ct des ActiveX : bien documents,
rapidement intgrs aux outils de dveloppement leaders (Visual Basic, Visual C++,
Delphi,.), dsormais ils font partie des meubles. Les Java Beans, pour leur part,
profitent dun effet de mode, et bon nombre doutils (ceux qui supportent le JDK, ds sa
version 1.1, Jbuilder, Power J, Visual Age, par exemple) permettent de dvelopper ceux-
ci. Ils offrent gnralement des assistants de cration aux Java Beans aussi simples que
ceux connus pour les ActiveX, voire souvent plus sophistiqus (selon le ct de la
barrire o lon se place. ).

Performances

En ce qui concerne la performance du composant pris hors de son contexte, lavantage se
situe du ct des ActiveX, qui sappuient sur du code vritablement compil. Les Java
Beans, en revanche, se contentent des performances de Java, qui sont encore
perfectibles.

Etendue du parc

La viabilit dune solution informatique dpend souvent du parc existant un instant
donn. De ce point de vue, les composants ActiveX vendus dans le commerce ont t
pendant longtemps plus nombreux que les bibliothques de Java Beans. Une tendance
qui sinverse, dans la mesure o Java concerne les diteurs de toutes les plate-forme
serveurs. Dautre part, les acteurs majeurs du march base de donnes (Oracle,
Informix, Ingres, IBM) ont plutt jet leur dvolu sur Java quActiveX, tant il est vrai que
le parc install des grands comptes se situe plutt sur des architectures base AS400 ou
UNIX que Microsoft. Cette tendance, que lon croyait un temps devoir disparatre, semble
au contraire se renforcer. Tant et si bien que larchitecture Entreprise Java Beans semble

2
Les EJB sont semblables aux composants MTS/COM+ de Microsoft. Ils rpondent principalement aux
problmatiques de monte en charge et de transactionnel en distinguant les composants mtiers dits Session
Beans, des composants persistants dits Entity Beans. Les serveurs EJB sont le cur des serveurs dapplications
J2EE.

en mesure de dfinit un nouveau standard dans la problmatique des mcanismes
daccs linformation.

Portabilit et interoprabilit

A ce sujet, la comparaison est vite faite : hors de la plate-forme Wintel, peu de chances
(mme si quelques diteurs indpendants proposent des possibilits de dploiement sur
dautres plate-formes) de voir fleurir des ActiveX. Ces derniers ne sont pas portables, et
ninteroprent quavec eux-mmes. Linteroprabilit est nanmoins techniquement
possible par lutilisation de divers ponts permettant la communication avec des Java
Beans ou des objets CORBA. Il reste nanmoins vrai que lajout dun pont est un pis-aller
qui augmente la complexit et diminue les performances.

Cette caractristique rend douteuse, voire improbable la prsence des ActiveX avec les
serveurs UNIX. Un atout de poids pour les Java Beans qui, au contraire, peuvent tre
dploys sur toutes les plate-formes serveurs et qui, par lintermdiaire de CORBA,
bnficient dune interoprabilit sans faille.

Monte en charge

Ct monte en charge, les technologies Java Beans et ActiveX se tiennent dans un
mouchoir de poche : les Java Beans sappuient sur les mdiateurs dobjets de
larchitecture de lOMG (Object Management Group), ces ORB CORBA tels que Visibroker
(socit Inprise) mettent disposition des jeux de composants identiques facilement
distribuables sur plusieurs machines.

De son ct, Microsoft intgre Windows 2000 son Transaction Server, dont lavantage
principal est doffrir une interface dutilisation relativement simple. De cette manire, on
obtient les avantages dun moniteur transactionnel dans les composants ActiveX, en
quelques appels de fonctions. Le faible cot de cette approche permet de
dmocratiser lutilisation des moniteurs transactionnels dans lentreprise.

Le pont Java Beans / ActiveX

Javasoft propose un outil permettant un Java Bean dtre vu comme un ActiveX par les
applications Windows permettant de les visualiser. Il sagit du packager, qui produit,
partir dun Java Bean un fichier destin la base de registres Windows, des fichiers
amorces Java (constituant le pont entre le Java Bean et lActiveX qui lencapsule), et un
fichier binaire OLE dcrivant les mthodes, vnements et proprits insrer dans le
Type Library.
Les classes ncessaires sont insres dans le fichier JAR original. Ce fichier JAR reste
portable si les classes du paquetage sun.beans.ole sont disponibles.

Notons aussi que Microsoft propose sa propre version de cette passerelle, et que loutil
de Taligent, WebRunner Toolkit, effectue lopration inverse : ActiveX en Java Bean.
CORBA quand lui propose un modle permettant en principe dintgrer aussi bien des
Java Beans que des composants ActiveX au sein dun mme environnement.

Alors : Java Beans ou ActiveX ?

Le choix dune architecture nest pas simple. Pour une solution centre sur
UNIX, le choix des Java Beans semble invitable.

De mme, la slection des ActiveX en environnement
exclusivement Windows semble tout aussi judicieuse. Lorsque
les ressources serveurs se partagent les environnements
Windows et UNIX. Une solution mixte peut constituer un bon choix. Le

dveloppement Web autorise - par le biais des adresses URL - laccs des ressources
varies, et cela de manire compltement transparente pour le client. Autant en profiter,
en rpartissant les traitements ct serveur entre les applications Javascript/Java Beans
et ASP/ActiveX.

Une dmarche logique danalyse consiste, dans ce cas, dcouper fonctionnellement
lapplicatif serveur, valider pour chacune des fonctions ladquation des Java Beans ou
ActiveX (en termes de performances et de facilit daccs linformation souhaite) et
implmenter la fonctionnalit avec larchitecture souhaite.

1.2 Le monde des composants distribus selon Microsoft

Faisons le point sur les multiples abrviations qui parsment le jargon qui caractrise
Microsoft. Les 6 technologies fondamentales de DNA (Distributed interNet Applications
3
)
sont :

- COM, qui comme nous lavons vu, permet de dfinir des composants,
- DCOM, qui permet de manipuler ceux-ci de manire distribue,
- MTS (Microsoft Transaction Server), un environnement dexcution dans lequel
les composants voluent, offrant un service de requtes-rponses en fournissant
une scurit ainsi quune gestion des transactions
4
,
- MSDTC (Microsoft Distributed Transaction Coordinator), un outil traitant de
manire automatique les mises jour sur de grosses applications,
- MSMQ (Microsoft Message Queue, nom de code The Falcon), similaire linterface
dinvocation dynamique de CORBA, de manire asynchrone
5
,
- Et MSCS (Microsoft Cluster Server, nom de code The Wolf Pack), permettant de
regrouper plusieurs serveurs pour les faire travailler ensemble.

3
DNA a dsign de 1996 aujourdhui larchitecture de composants distribus de Microsoft. Avec larrive de
.NET, il semblerait que cette appellation soit abandonne au profit dune nouvelle.
4
Les technologies middleware concurrentes de MTS sont les EJB (Entreprise Java Beans) et CCM (CORBA
Component Model).
5
Les technologies MOM (Message Oriented Middleware) concurrentes de MSMQ sont JMS (Java Message
Service) et MQSeries dIBM.


2 - DCOM

2.1 Introduction

Le modle de composants distribus de Microsoft, DCOM, tend COM afin de supporter
les communications inter-objets sur diffrents ordinateurs rpartis sur un rseau LAN
(Local Area Network) ou WAN (Wide Area Network), ou sur Internet.

La distance qui spare COM de DCOM est trs courte : mme si COM permet de
concevoir des objets sexcutant sur des machines distantes, il faudra utiliser loutil de
configuration de DCOM pour permettre votre machine de supporter les objets COM de
manire approprie. En termes de technologie, DCOM ne ncessite pas de
programmation plus spcifique que COM (du moins sous VB), soit ce que ne nous avons
vu jusque l. En fait, il ny a pas de diffrences entre le dveloppement dun serveur out-
of-process COM du dveloppement dun serveur out-of-process DCOM : les programmes
sont identiques.

2.2 Concept fondamentaux de DCOM

DCOM se base sur les couches DCE-RPC pour assurer la transparence au niveau du
rseau et grer les appels distants de composants. Il facilite normment la gestion du
rseau pour les programmeurs, en prenant en charge aussi bien les communications que
le marshalling, soit lencapsulation du ct client des paramtres donns par le client la
fonction appele, ainsi que la reconstitution de ces paramtres du ct serveur pour
lappel de la fonction. DCOM reste galement ouvert et permet au programmeur (sil en a
les comptences) de raliser son propre marshalling, ou de contrler son propre
protocole de communication.
La figure suivante montre schmatiquement la frontire entre le client et le serveur lors
de lappel.

Il ny a pas de diffrences fondamentales entre COM et DCOM, puisque ce dernier ne sert
finalement qu faire communiquer des composants distants relis par un rseau.
Nous verrons par la suite comment configurer une machine pour quelle puisse utiliser
DCOM.

C CO OM M
DCE
RPC C Cl li ie en nt t
M Ma ac ch hi in ne e s se er rv ve eu ur r M Ma ac ch hi in ne e c cl li ie en nt t
C CO OM M
C Co om mp po os sa an nt t

2.3 DCOM dans les technologies de composant de Microsoft

Presse-papiers Windows
(1987)
OLE 1
(1991)
Informatique rpartie
(annes 1980)
Open Software Foundation
Distributed Computing Environment
Appels de procdure distante
(OSF DCE RPC 1992)
DCOM, Windows NT 4.0, MTS 1.0
(1996)
OLE 2 - premire sortie
publique de COM dans le
SDK OLE 2.0
(1993)
ActiveX, COM
Windows NT 3.51,
Windows 95
(1995)
Dbuts de rflexion sur
COM
(1988)
Windows NT 3.5
Support 32 bits
Interface Definition
Language (IDL)
(1994)
Windows NT 4.0 Options Pack : MTS 2.0, MSMQ 1.0, IIS 4.0
(1998)
Windows 2000, COM+, MSMQ 2.0, IIS 5.0
(1999 - 2000)

2.4 Considrations de conception propres aux objets DCOM

Bien quil soit possible de travailler avec des composants COM de manire distante (en
utilisant DCOM), il vous faudra certainement repenser le design de votre composant
avant de le mettre en production. Les compromis de conceptions qui taient acceptables
avec un objet COM ne le sont plus ds que celui-ci est utilis sur un rseau.

Premirement, vous devez garder lesprit que vous aurez deux programmes qui
communiqueront au travers dun rseau. La manire sont ils seront relis na que peu
dimportance, il ne sera pas possible dchanger des donnes aussi vite quil est possible
de le faire sur une machine. De plus, si votre rseau est de type 10BaseT ou 100BaseT, il
faudra penser partager la bande passante entre toutes les machines connectes. Mme
si le rseau est suffisamment rapide pour traiter les communications entre vos deux
machines comme sur une seule, le fait que dautres ordinateurs soient prsents sur ce
rseau narrangera rien laffaire. La premire rgle est donc de minimiser la quantit
dinformations dplace dun ordinateur un autre.

La seconde rgle dcoule de la premire : chaque fois que vous envoyez un message
dune machine une autre, une quantit non ngligeable dinformations - dont la taille
est indpendante de la taille du message - est incluse automatiquement dans celui-ci. Il
vaut donc mieux envoyer un gros message quune centaine de petits messages.
Autrement dit, aprs avoir minimis la taille des messages, il faut les envoyer dans des
paquets les plus gros possibles.

Relativement Visual Basic, voici quelques rgles qui aident raliser ces ides :

Minimisez la quantit de donnes envoye entre deux ordinateurs en transfrant
uniquement ce qui est ncessaire.

Utilisez le mot-cl ByVal pour envoyer linformation dans un sens seulement. Sans
ce mot-cl, DCOM devra retourner la valeur mme si elle na pas t modifie.

Utilisez des objets Recordset (dconnects) dADO
6
pour transfrer linformation
entre machines. ADO met en place un marshalling spcial pour amliorer les
performances de communications sur un rseau.

Utilisez des mthodes qui mettent jour les proprits de manire globale, plutt
que de mettre jour les proprits une une.

6
ADO (ActiveX Data Object) : voir glossaire.


3 - Utilitaire de configuration DCOM

Ce qui diffrencie COM de DCOM est son outil de configuration, qui permet de rgler
comment et o les serveurs out-of-process sont crs en ditant les entres de la base
de registres associes avec un serveur out-of-process COM normal . Techniquement,
cela vite ainsi davoir a spcifier le nom dun ordinateur distant dans linstruction
CreateObject, mais aussi de pouvoir utiliser le mot-cl New dans les instructions Set et
Dim, afin de crer des objets distants.
Cet outil de configuration permet galement de contrler comment lobjet est scuris. Il
est possible de travailler en relation avec les rgles de scurit de Windows NT pour
dcider de rgles trs prcises.

Il existe deux versions de lutilitaire de configurations : une pour Windows 2000 et NT,
lautre pour Windows 95 et 98. Les diffrences entre ces deux versions se situe
essentiellement dans les options de scurit. Comme les OS Windows 95 et 98 ne sont
de loin pas complets en matire de scurit, les options scuritaires de DCOM se
rsument autoriser ou non laccs un composant selon le nom dutilisateur. Nous
dtaillerons donc lutilitaire pour Windows 2000 et NT, dans la mesure o le travail de
lauteur a t effectu sur ces deux OS.

Lutilitaire se lance avec la commande DCOMCNFG dans la bote de dialogue Excuter
(Menu Dmarrer Excuter).

La case Activer Distributed
COM de longlet Proprits
par dfaut est certainement
la plus importante : elle soit
tre coche afin de pouvoir
excuter DCOM sur la
machine. La case Activer les
services permet le support
du protocole de transport
Tunnelling TCP, sur le port
80, afin de communiquer
plus facilement travers les
proxy et firewalls
7
.

7
Cependant, tant que les objets CIS (COM Internet Services) devront tre dvelopps sous Visual C++, cette
possibilit ne pourra sappliquer Visual Basic.

Le niveau didentification devrait tre plac sur Aucun lors du dveloppement et du test
des composants, ce qui permettra dliminer la plupart des erreurs rencontres (on se
penchera alors plus particulirement sur les erreurs de COM).
Attention ne jamais laisser ce niveau Aucun en phase de production, pour des raisons
videntes de scurit (infiltrations externes).

Les diffrentes valeurs du niveau didentification sont les suivantes :

Aucun Aucune vrification de scurit. Devrait tre utilis lorsque le niveau
demprunt didentit est fix Anonyme.

Appel Une vrification est effectue lors de chaque appel.

Confidentialit
du paquet Les donnes, lidentit et la signatures de lmetteur sont encrypts pour
assurer une scurit maximale.

Intgrit
du paquet Lidentit et la signature de lmetteur sont encrypts dans chaque paquet
pour assurer que ceux-ci arrivent inchangs.

Paquet Lidentit de lmetteur est encrypte dans chaque paquet.

Par dfaut Pour Windows 2000 et NT, identique Se connecter.

Se Connecter Les vrifications de scurit sont effectues quand la connection est faite
avec le serveur. Cette option ne fonctionne quavec des protocoles orients
connections.

Le niveau demprunt didentit dcrit comment le nom dutilisateur sera consign sur le
serveur. La valeur Anonyme ne devrait tre utilise uniquement que dans la phase de
test.

Les valeurs sont les suivantes :

Anonyme Le serveur dapplications ne vrifie pas lidentit de lappelant.

Dlguer Le serveur dapplications accomplit certaines tches sur lordinateur du
client. Cette valeur na jamais t implmente par lutilitaire.

Emprunter
lidentit Le serveur dapplications emprunte lidentit du client. Cette valeur nest
disponible que sur la machine qui fait office de serveur.

Identifier Le serveur dapplications vrifie le nom dutilisateur associ avec
lapplication cliente.

La dernire case cocher (Fournit une scurit) demande au serveur de compter le
nombre de clients connects en plus du nombre de rfrences faites sur lobjet COM.
Cocher cette case permet dviter au programmeur dinitialiser le compteur de
rfrences. Du point de vue de Visual Basic, cette case ne sert rien, puisquil nest pas
possible de modifier ce compteur explicitement.


Longlet Scurit par dfaut est utilis pour spcifier quel utilisateur ou groupe dutilisateur
peut accder un objet, lexcuter, ou configurer ses permissions. Ces valeurs sont
modifiables donc relativement un objet donn.

La gestion des utilisateurs tant presque identique celle de Windows 2000/NT, nous ne
lexpliquerons pas ici.

Notons seulement que de manire gnrale, il est plus pratique (et sr) de grer des
groupes dutilisateurs que des individus. Si aucun groupe dj cr nest appropri pour
vos applications DCOM, vous pouvez en crer avec Active Directory (Menu Dmarrer
Programmes Outils dadministration Active Directory, ou Gestion de lordinateur).
Windows 2000/NT supporte les principaux protocoles rseau travaillant en collaboration
avec DCOM. Depuis longlet Protocoles par dfaut, il est possible de les spcifier.

Lordre dans la liste est
important, car DCOM
essaiera dtablir une
connexion avec le protocole
list en premier. Si ce nest
pas possible, il tentera
chaque protocole jusqu ce
quil en trouve un qui
fonctionne.


Voyons maintenant le contenu de longlet Applications. Slectionnez
Fichier.VerifFichier
8
et cliquez sur Proprits.

Toutes les valeurs que vous saisirez dans cette bote de dialogue craseront celles
dfinies par le systme. Il est ainsi possible dajouter des contraintes scuritaires sur un
objet (par exemple limiter son accs seulement quelques personnes, ou supprimer
toutes les scurit lors dune phase de test).

Depuis longlet Gnral, on ne peut modifier que le niveau dauthentification (les valeurs
- qui sont identiques celles de longlet Proprits par dfaut - sont listes plus haut.
Le reste des informations de cette fentre ne sont que des confirmations dinformations
qui sont modifiable ailleurs dans lutilitaire. Par exemple, le type dapplication est contrl
par les valeurs que vous aurez saisies sous longlet Emplacement, et le chemin daccs
local est dfini lors de linscription (registration) de lobjet COM sur votre machine.

8
La prsence de cette application ncessite que vous ayez ralis lEXE ActiveX Fichier . Si ce nest pas le
cas, slectionnez nimporte quelle autre application. Notez que si lutilitaire ne peut identifier le nom de
lapplication, il listera son GUID la place.


Longlet suivant vous
propose 3 choix :

Le premier permet de
travailler en relation avec la
fonction GetObject
9
et de
choisir dutiliser
lordinateur spcifi par
son nom.

Le second (coch par
dfaut) excute lobjet
localement.

Le troisime vous permet
de spcifier lordinateur sur
lequel excuter lobjet.

Imaginons que vous avez coch les trois cases. Si vos donnes sont situes sur un
systme distant, DCOM va essayer de charger lobjet sur cette machine en question
(cette option ne fonctionne que si vous avez cr un objet bas sur des donnes, comme
une feuille Excel ou un document Word). Si lobjet nest pas prsent sur la machine,
DCOM va essayer de charger lobjet localement. Sil ny parvient pas, il va essayer de
charger lobjet sur lordinateur spcifi. Si cela ne donne rien, DCOM retournera un
message derreur.

La case Excuter lapplication sur lordinateur suivant fait essentiellement la mme chose que
de spcifier le nom de lordinateur dans linstruction CreateObject. Lintrt de le faire
ici et non dans CreateObject est quil ny a ds lors plus besoin de se proccuper de ce
que le code contient (codage dur !). Si vous dsirez dplacer lobjet dun ordinateur un
autre, il suffit simplement de le signaler dans lutilitaire de configuration, et le code du
programme reste inchang. Notez que la valeur indique dans le code crase toute autre
valeur.

9
La fonction CreateObject est similaire aux instructions Set.New et Dim.New. Elle cre une nouvelle instance
de lobjet spcifi et retourne une rfrence sur lobjet que lon peut assigner une variable objet avec Set. La
syntaxe de cette fonction est Set varobjet = CreateObject (class [, serveur]) , dans laquelle
varobjet est le nom de la variable objet qui contiendra un pointeur vers le nouvel objet ainsi cr, class est le
nom de lobjet crer, et serveur le nom de la machine o lobjet sera cr (la machine locale par dfaut).
Cette fonction est lunique moyen de crer un objet sur une autre machine, en utilisant les techniques
standards de COM. Si lordinateur distant nexiste pas ou que la scurit empche daccder lobjet, une
erreur dexcution sera gnre, et lobjet ne sera pas cr.


Sous longlet Scurit, on trouve des options similaires celle de longlet Scurit par
dfaut, si ce nest quici vous est offerte la possibilit dutiliser les autorisations par
dfaut, ou de personnaliser les autorisations par individu ou par groupe dindividus qui
peuvent accder lobjet.

Longlet Identit permet de spcifier quel profil utiliser pour excuter lobjet :

Utilisateur interactif
Slectionne le nom (dutilisateur) de celui qui cre linstance de lobjet, ce qui signifie que
le nom de lutilisateur qui ouvre une session sur la console du serveur sera exploit pour
dterminer les rglages de scurit. Si aucun utilisateur nest logg sur la console, une
erreur sera retourne et tout ordinateur distant essayant de crer une instance de lobjet
recevra une erreur.

Utilisateur excutant
Slectionne le nom de la personne qui a excut lobjet en premier. Si vous slectionnez
cette option, le profil de scurit de cette personne sera appliqu.

Cet utilisateur
Si vous slectionnez cette option, le nom dutilisateur spcifi dterminera les droits de
scurit de lobjet COM. Attention : utiliser cette option peut devenir ennuyeux la
longue si la politique de scurit de votre systme (ou de votre entreprise) ncessite de
devoir changer priodiquement le mot de passe.



Longlet Points terminaux
vous permet de lister les
protocoles de
communications pouvant
tre utiliss avec votre
application COM. Il est
galement possible de
rgler des options
spcifiques pour chaque
protocole.



4 - Erreurs de DCOM frquemment rencontres

La plupart des erreurs rencontres - et cest particulirement le cas sous un serveur
Windows 2000/NT - sont en relation avec la scurit. Le meilleur moyen de rgler ce
genre de problme est de fixer des rgles de scurit qui fonctionnent : certains auteurs
recommandent de commencer par supprimer toute scurit, puis de spcifier une rgle
aprs lautre, de tester et de continuer jusqu ce lerreur se produise. A ce moment l, il
devient plus simple de comprendre pourquoi le problme apparat.

Les trois erreurs les plus frquentes sont les suivantes :

Erreur 70 : Permission refuse

Marche suivre (entre chaque point vous devrez ressayer daccder lobjet) :

1/ Vrifiez que DCOM est activ aussi bien sur le serveur que sur le client.

2/ Vrifiez que le nom dutilisateur associ la machine locale a les permissions pour
accder lordinateur distant ainsi que lobjet distant.

3/ Utilisez lutilitaire de configuration de DCOM pour faire les changements suivants
sur le serveur distant DCOM et ressayez :

a/ Modifiez les proprits de scurit de lobjet de telle manire que les
utilisateurs tout le monde, systme et utilisateur interactif ait les autorisations de
lancement de lobjet (pour laccs et pour lexcution).

b/ Sous le mme onglet (Scurit), rgler les autorisations de configuration de
telle manire que les utilisateurs crateur propritaire, systme ainsi
quutilisateur interactif aient le contrle total, et que lutilisateur tout le monde
ait la permission en lecture seule.

c/ Sous longlet Identit, slectionnez lutilisateur interactif ou spcifiez un nom
dutilisateur dun utilisateur appartenant au groupe des administrateurs.
Vrifiez quun mot de passe nest pas requis.

4/ Si cela ne fonctionne toujours pas, rgler le niveau dauthentification par dfaut sur
aucun, ainsi que le niveau demprunt didentit par dfaut sur emprunter lidentit.

5/ Si cela ne fonctionne toujours pas, redmarrer la machine cliente ainsi que
le serveur : certaines modifications peuvent ncessiter le redmarrage de la
machine.

Erreur 429 : Le composant ActiveX ne peut pas crer l'objet

Points vrifier :

- Vrifiez que DCOM est activ aussi bien sur le serveur que sur le client.

- Vrifier que le serveur DCOM est bien inscrit (registered) sur lordinateur client.

- Vrifier que lobjet distant existe sur la machine distante et quil est bien inscrit. Il
est possible que quelquun ait dsinscrit (unregistered) le serveur DCOM. Il se

peut aussi que lors dune mise niveau du serveur DCOM, celui-ci ait acquis un
nouveau GUID.

- Si le programme fonctionne, mais ne fait rien et ne rpond pas, vrifiez sur
lordinateur serveur si le processeur ne tourne pas 100%. Ceci est caus par un
problme de scurit lorsque lobjet distant essaie dcrire quelque chose dans la
base de registres, mais que le nom dutilisateur na pas les permissions pour le
faire. Pour y remdier, changez le nom dutilisateur associ lobjet distant, ou
mettez jour ses permissions.

Erreur 462 : La machine serveur distante n'existe pas ou est indisponible

Points vrifier :

- Vrifiez que le nom de la machine distante est correctement orthographi.

- Vrifiez que vous pouvez vous connecter sur la machine distante. Il est possible
que celle-ci soit dbranche ou quil y ait un problme sur le rseau impliquant les
deux machines.



5 - Exemple de composant DCOM

Nous allons raliser un exemple simple dapplication client/serveur utilisant DCOM. Il est
ncessaire de travailler avec ldition Entreprise de Visual Basic 6 pour ce faire. Ce sera
galement loccasion dutiliser lassistant dempaquetage et de dploiement. Notre
application, lance depuis la machine cliente, affichera lheure de la machine sur laquelle
sexcutera le serveur.
Avant de commencer, il faut activer DCOM (avec lutilitaire Dcomcnfg que nous avons vu
auparavant) sur les machines cliente et serveur.

Crez un rpertoire nomm DCOMDemo et logez-y deux rpertoires nomms Server et
Client.

5.1 Cration du serveur

Lancez Visual Basic 6, et slectionnez un projet ActiveX EXE. Ajoutez le code suivant la
classe cre :

Public Function ServerTime() As String
ServerTime = Time
End Function

Dans les proprits du projet, saisissez DCOMDemo_Svr dans le champ Nom du projet,
ainsi que DCOMDemo_Svr - Server dans le champ Description du projet. Cochez loption
Mode dexcution autonome. Cette option devrait toujours tre coche lorsque le serveur ne
possde aucune interface utilisateur, car elle assure quaucune bote de dialogue ne
saffichera dans le processus dexcution du serveur. Si le serveur est excut dans le
mode Utilisateur Interactif (dans Dcomcnfg) et queffectivement il ny a aucune interaction
de la part de lutilisateur sur le serveur, celui-ci pourrait utiliser lintgralit du temps
CPU.

Sous longlet Composant des proprits du projet, cochez la case Fichier serveur distant, ce
qui aura pour but de gnrer les fichier VBR et TLB requis pour lempaquetage du
programme client sadressant au serveur. Ces fichiers contiennent des entres de la base
de registres qui seront inscrites sur la machine cliente.
Validez, sauvegardez le fichier et le projet, et compilez le serveur (Fichier Crer
DCOMDemo_Svr.exe).

Retournez sous les proprits du projet, et sous longlet Composant, cochez loption
Compatibilit binaire, en vrifiant que le programme spcifi dans le champ soit bien
DCOMDemo_Svr.exe. Cette manuvre permet dassurer que tous les GUID seront les
mmes lors des multiples compilations du serveur.


5.2 Cration du client

Ouvrez un nouveau projet standard EXE, et allez dans les proprits du projet. Sous
longlet Gnral, saisissez DCOMDemo_Cli comme nom de projet, et DCOMDemo_Cli -
Client comme description du projet, et validez.

Dans les rfrences (Projet Rfrences), slectionnez DCOMDemo_Svr - Server (en
cochant la case correspondante) et validez.

Placez un bouton sur la feuille, nomm Run, et ajoutez le code suivant dans son
vnement Click :

Private Sub Command1_Click()
Dim MonObjet As DCOMDemo_Svr.Class1
On Error GoTo Err

Set MonObjet = CreateObject("DCOMDemo_Svr.Class1")
MsgBox "Heure du serveur =" & MonObjet.ServerTime & _
"Heure du client =" & Time

Exit Sub

Err:
MsgBox " la connexion a chou : Erreur " & _
Err.Number & "-" & Err.Description

End Sub

Sauvegardez le fichier et le projet dans le rpertoire Client, puis lancer lexcution de
celui-ci (F5). Les deux heures affiches sont identiques : cest normal puisque le client
est excut sur la mme machine que le serveur.

Gnrez maintenant lexcutable (Fichier Crer DCOMDemo_Cli.exe) et fermez Visual
Basic 6.


5.3 Empaquetage du serveur

Lancez lassistant dempaquetage et de dploiement (Menu Dmarrer
Programmes Microsoft Visual Studio 6.0 Outils Microsoft Visual Studio 6.0 Assistant
Empaquetage et dploiement).

Slectionnez le projet DCOMDemo_Svr.vbp, et cliquez sur Empaquetage. Choisissez le
type dempaquetage Logiciel dinstallation standard, et validez. Le programme va ensuite
afficher la bote de dialogue suivante :

Cliquez sur Non. DCOM nest pas Remote Automation, en fait cette dernire technologie a
t remplace par DCOM.

Lcran suivant vous propose une liste de fichiers empaqueter avec le programme
DCOMDemo_Svr. Il vaut mieux, moins que vous ne sachiez quel est le rle des fichiers,
cliquer sur Suivant en acceptant cette configuration. Vous pouvez ensuite dfinir les
groupes et les lments du menu Dmarrer qui seront crs par le processus dinstallation
( partir desquels le programme pourra tre lanc). Dans la fentre Fichiers partags,
cliquez sur le fichier DCOMDemo_svr.exe si vous dsirez obtenir plusieurs instances
dobjets depuis plusieurs machines diffrentes. Validez pour terminez lempaquetage.

Les fichiers gnrs sont stocks dans le rpertoire Package. Certes, ce rpertoire pse
plus de 4 Mo, mais noubliez pas quil contient toutes les librairies requises pour son
installation (il est donc possible dinstaller le serveur sur une machine sur laquelle ne
figure pas Visual Studio ni Visual Basic).

5.4 Empaquetage du client

Lopration de lempaquetage du client est sensiblement diffrente de celle du serveur,
dans la mesure o celui-ci ne tournera pas sur la mme machine que le client : ce
changement concerne essentiellement linstallation de la librairie de type (fichier .tlb)
ainsi que linscription de plusieurs entres dans la base de registres.

La marche suivre est la suivante :
Aprs avoir slectionn le projet DCOMDemo_Cli.exe et cliqu sur Empaqueter, choisissez
nouveau le type dempaquetage standard, puis lemplacement o vous dsirez
enregistrer les fichiers.

La bote de dialogue suivante apparat :



Cliquez sur OK sans cocher la case, le serveur nayant aucune dpendances.
Dans la fentre Fichiers Inclus, dslectionnez le programme DCOMDemo_Srv.exe,
puisque vous ne voulez pas le distribuer avec DCOMDemo_Cli.exe. Cliquez ensuite sur le
bouton Ajouter, et recherchez le fichier DCOMDemo_Svr.vbr dans le rpertoire du serveur
(DCOMDemo\Server). Ce fichier contient les entres relatives au serveur ajouter dans
la base de registres.

Validez. Vous constaterez que deux fichiers sont apparus dans la liste des fichiers inclus :
DCOMDemo_Svr.VBR et DCOMDemo_Svr.TLB.

Dans la fentre Serveurs distants, il est possible de spcifier le nom de la machine sur
laquelle sexcutera le serveur.


Gnralement, on laisse cette case vide, tant donn quon ne sait pas forcment
lavance o le serveur sera install. Nous verrons plus loin que cest lors de linstallation
que le programme nous demandera de spcifier cette adresse. Cliquez sur Suivant sur
toutes les fentres suivantes afin de terminer le processus dempaquetage.

5.5 Installation du serveur

Installer le serveur sur la machine o vous voulez quil sexcute, en utilisant le package
que vous venez de crer. Si vous dsirez le faire sur la machine utilise pour le
dveloppement, ce nest pas ncessaire, puisque Visual Basic effectue linscription au
moment o il a compil le serveur.

5.6 Installation du client

Installer le client sur la machine o vous voulez quil sexcute. Lors de linstallation,
tant donn que le champ de ladresse de la machine distante a t laiss blanc, le
programme vous demande la localisation de celle-ci.

Voil, il ne vous reste plus qu lancer le serveur, puis le client. A lexcution de celui-ci,
la fentre indiquant lheure des deux machines nest plus la mme que lors de la
premire excution (notez que dans lexemple concret - relativement la figure suivante
- les horloges des deux machines taient particulirement mal rgles.).


5.7 Rglage de la scurit du serveur

En utilisant Dcomcnfg, vous pouvez grer toutes les options de scurit que nous avons
vu auparavant. En phase de test, il est conseill de dsactiver toute barrire qui pourrait
rendre lexcution instable, puis de placer les scurits les unes aprs les autres, en
prenant soin de tester lapplication aprs chaque manuvre. Cette phase peut tre trs
longue en raison de la spcificit de chaque rseau.

6 - Cycle de vie d'un composant distant

NB. Attention ne pas confondre : une machine serveur (ou machine distante) est
considre comme tant lordinateur qui fait office de serveur, alors quun serveur distant
(ou serveur tout court) est considr comme un composant fournissant des services.

Comme nous lavons vu lors du cycle de vie dune EXE ActiveX, un composant distant est
inscrit sur une machine cliente laide du programme CliReg32.exe.
Pour ce faire, il faut tout dabord cocher la case Fichier serveur distant sous longlet
Composant de la fentre de proprits du projet. Puis,
recompiler le tout, et lancer CliReg32.exe la ligne de
commande (qui doit normalement se situer dans le
rpertoire Microsoft Visual Studio\Common\Tools\..).

La compilation du composant distant gnre un fichier dextension .VBR, qui contient des
informations inscrire dans la base de registre. Le programme CliReg32 sen charge : il
faut donc simplement dsigner le nom de fichier .VBR aprs CliReg32 , et le tour est
jou
10
.

Au moment de linscription (Registration Time)

Bien que le concept thorique de DCOM (ou de Remote Automation) soit relativement
simple, il peut savrer nettement plus compliqu en pratique. Lide vritablement
importante retenir est quil faut inscrire le composant sur les deux (ou plus) machines
impliques. Il doit tre inscrit sur la machine serveur afin que DCOM sache quel serveur
EXE charger et comment grer le marshalling des donnes du ct du serveur. Mais il
doit tre galement inscrit sur la machine cliente pour que DCOM puisse crer un objet
proxy pour le composant et grer le marshalling des donnes du ct du client.

Au moment de la conception et de la compilation

Aprs avoir inscrit le composant distant, on peut lutiliser de la mme manire quun
composant EXE ActiveX. En effet, Visual Basic ne soccupe pas de lemplacement de
celui-ci.

Au moment de lexcution

Visual Basic, grce au CLSID de lobjet, recherche un serveur EXE implmentant lobjet.
Si il ne trouve pas de serveur local, il cherche un serveur distant. Puis, les choses
suivantes se mettent en place :

Lorsquil trouve un serveur distant, il contacte le serveur et lui envoie une requte
pour crer lobjet spcifi. Si le serveur accepte sa requte, il lance lexcutable

10
Notons quune dizaine doptions sont possibles sur la ligne de commande, pour les connatre il suffit de lancer
le programme, elles sont indiques (la MSDN, du moins la version de lauteur, ne donne aucune information a
ce sujet). La faon encore plus simple dinscrire un composant sur la machine cliente est de lempaqueter et de
lexcuter ainsi (toutes les manuvres sont automatises).

sur la machine distante. En mme temps, le sous-systme COM cre un objet
proxy sur la machine locale.

Lobjet proxy peut reproduire toutes les interfaces de lobjet rel
11
. Les
proprits et mthodes de linterface de lobjet sont excutes en appelant les
fonctions dans linterface de lobjet proxy. Lobjet proxy utilise le mcanisme
dappel de procdure distante de lOS pour empaqueter (marshal) les donnes
travers le rseau vers la machine distante. Du ct du serveur, lOS appelle lobjet
directement
12
.

Toutes les valeurs ou paramtres passes par rfrence sont empaquetes
(marshalling) en retour vers le systme local, travers lobjet proxy, au client
utilisant lobjet.

Lorsque le projet est ferm ou que lobjet est rfrence sur Nothing, le compteur
de rfrences de lobjet passe zro et lobjet proxy est effac. Lorsque le serveur
distant sait que tous les objets quils fournissait sont librs, il se dcharge.

11
Il est alors possible dutiliser la liaison prcoce, en dfinissant des variables objet dun type spcifique donn.
Cependant, les bnfices de cette technique (liaison prcoce) dans ce genre de cas seront trs minces, tant
donn la charge du rseau.
12
En utilisant Remote Automation en lieu et place de DCOM, on peut considrer une autre couche. Au lieu
dappeler lobjet distant directement, Windows appelle une application nomme Remote Automation Manager,
qui gre les objets Remote Automation. Cette application appelle lobjet en utilisant les techniques standards de
marshalling sur un composant out-of-process. En dautres termes, il ny a plus un canal, mais deux canaux - ou
couches - de marshalling. Le premier le fait au travers du rseau, et le second sur la machine serveur. Il sagit
dune des raisons pour laquelle le protocole DCOM offre de meilleures performances que Remote Automation.


7 - Des DLL distantes ?

Nous avons vu jusquici que lorsquon parlait dobjets distribus avec DCOM, on parlait
dEXE ActiveX. Quand est-il des DLL ? Peut-on les dposer sur une machine distante ?
Le problme est le suivant : une DLL ne peut sexcuter que dans un processus existant.
Lorsquon cre un objet de manire distante, quel processus chargera le contenu de la
DLL (ou les objets implments dans la DLL) ? Mme si un tel processus existait (et il
doit certainement exister des solutions logicielles qui rsolvent le problme) et quil
arrivait empaqueter les donnes pour les envoyer sur lOS de la machine cliente, au
sein de quelle thread (processus lger) les objets sexcuteraient-ils ? En admettant le
cas o tous les composants partagent un mme thread, des problmes tels
quencombrement des appels, ou performance globale sont quasi assurs de se produire.

En fait, DCOM nest tout simplement pas assez sophistiqu pour rsoudre ce genre de
situations, il se limite donc traiter les EXE ActiveX
13
.

13
Pour assurer quune solution base sur serveurs DLL fonctionne, il faudrait un outil qui sache allouer des
threads aux objets, grer leur chargement et dchargement, contrler la scurit, etc. Il serait mme possible
(pour autant que toutes ces techniques soient parfaitement matrises) de dvelopper un EXE ActiveX qui
offrirait ce genre doutil. Ou alors utiliser MTS, dont un des buts est justement de travailler avec les DLL
distantes.

Bibliographie critique et liens Internet

- Developping COM/ActiveX components with Visual Basic 6, Dan Appleman, Sams
1999, 860 pages.
Cet ouvrage sadresse avant tout aux dveloppeurs professionnels sur VB, et
montre les meilleures techniques pour dvelopper des composants COM et DCOM.
Dun niveau trs nettement plus lev que le titre prcdent, cette bible
(presque 900 pages !) passe en revue la conception dobjets COM mais aussi et
surtout les mcanismes internes lors de lexcution des composants. Cest laide
de cet ouvrage que jai ralis une grande partie des explications techniques.

- Au cur de Distributed COM, Guy & Henry Eddon, Microsoft Press 1998, 560 pages.
Ce livre permet au dveloppeur dutiliser efficacement le modle DCOM. Sadresse
un public de connaisseur (Automation, Multithreading, Marshalling,.). Il est capital
davoir une solide exprience en la matire pour se lancer dans cet ouvrage !

- http://msdn.microsoft.com, le lien INCONTOURNABLE pour dvelopper sous plate-
forme Windows.

- http://www.microsoft.com/com/tech/com.asp, la page de Microsoft pour tout ce qui
concerne la technologie COM.

- http://www.microsoft.com/com/tech/DCOM.asp, la page de Microsoft consacre
DCOM, on y tlcharge entres autres des exemples, des SDK, ainsi que toute la
spcification du modle.

- http://www.componentsource.com, le site dune entreprise qui vend des
composants COM, Java, CORBA,. Cest une vraie mine dinformations, la rubrique
consacre lvolution des composants ma servi dans la rdaction du rapport.

(ActiveX - & - VB6) DCOM

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

(ActiveX - & - VB6) DCOM

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Travail de diplme Visual Basic 6 & technologie ActiveX Frdric Comte

Distributed COM Page Gnr le 22.03.2004 1

Vous aimerez peut-être aussi