Mise en oeuvre de DCOM

Table des matières

1. But et domaine d’emploi.

2. Relations composants ActiveX - DCOM.

3. Exemple d’application.

3.1 L’application cliente

3.2 L’application serveur.

3.3 Fonctionnement.

3.3.1 Préparation de l’installation du composant distant.

3.3.2 Préparation de l’installation du client.

3.3.3 Installation du composant distant.

3.3.4 Configuration du composant distant.

3.3.5 Installation du client.

3.4 Résumé.

4. Une application trois tiers avec DCOM.

4.1 Une application trois tiers.

4.2 Le client.

4.3 Le composant distant.

5. Conclusion.

 

 

1 - But et domaine d’emploi.

Ce document présente aux développeurs Visual Basic expérimentés la mise en œuvre de DCOM au travers de deux applications exemples dont le but est de montrer par la pratique le déploiement de solutions à base d’architecture distribuée en mettant en évidence les points suivants :

 

 

2 - Relations composants ActiveX - DCOM.

Un composant ActiveX est tout code exécutable mettant ses objets à disposition d'autres applications conformément au standard ActiveX, basé sur le modèle d'objet composant (COM, Component Object Model).

La technologie ActiveX repose sur le principe du partage des objets. La relation impliquée par les composants ActiveX est une relation client-serveur, dans laquelle le client demande les objets et le serveur les fournit. Cependant, la distinction entre clients et serveurs est floue, car un même composant peut être (et en réalité, est souvent) à la fois client et serveur. De ce fait, ils sont généralement appelés "composants ActiveX" plutôt que "clients ActiveX" et "serveurs ActiveX ". Dans un contexte d'exécution donné, toutefois, la relation client-serveur a son importance.

Les deux composants d'une relation client-serveur peuvent être situés sur un même ordinateur ou être exécutés sur deux ordinateurs distincts reliés en réseau. Un composant ActiveX est dit local lorsqu'il est exécuté sur le même ordinateur que son processus client, et distant s'il est exécuté sur un autre ordinateur.

Sur un même ordinateur, un composant ActiveX peut être exécuté in-process ou out-of-process par rapport au client. Un composant ActiveX in-process est implémenté en tant que bibliothèque de liaisons dynamiques (fichier .dll) et est de ce fait exécuté dans le même processus que le demandeur des objets. Un composant ActiveX out-of-process est un exécutable (fichier .exe), tel que Microsoft Excel, qui s'exécute dans son propre espace d'adressage.

Un composant ActiveX in-process partage avec son client le même espace d'adressage, de sorte que les appels aux méthodes d'un composant ActiveX in-process peuvent utiliser la pile du client. Lorsque vous transmettez un paramètre par référence au sein de l'espace d'adressage du processus client (ce qui implique sa transmission à un serveur in-process) la procédure à laquelle vous le transmettez peut accéder directement aux données.

Cependant, une méthode d'un autre processus ne peut pas utiliser de pointeur sur l'espace d'adressage du client. La technologie ActiveX résout ce problème en copiant les données pour ce paramètre dans l'espace d'adressage du composant out-of-process et en remplaçant le pointeur sur les données d'origine par un pointeur sur la copie.

La méthode du composant ActiveX utilise le pointeur pour modifier la copie. Quand cette méthode prend fin, les données correspondant à tout paramètre ByRef sont recopiées dans l'espace d'adressage du client. Ce mode de déplacement des données entre deux processus est appelé marshaling.

Un client ActiveX et un composant ActiveX out-of-process communiquent par un mécanisme proxy/stub automatiquement fourni par le modèle COM. Le proxy et le stub gèrent le marshaling et l'annulation du marshaling des paramètres qui sont transmis aux méthodes du composant  ; leur transparence est complète pour le processus client. Mais le marshaling est plus lent que la transmission de paramètres au sein d'un processus, notamment si ces paramètres sont transmis par référence.

Cependant, les services d'un composant ActiveX out-of-process peuvent être partagés par de nombreux clients, tandis que chaque client doit disposer de sa propre copie d'un serveur in-process. De plus, le mécanisme proxy/stub peut être étendu à l'ensemble du réseau par l'intermédiaire du modèle COM distribué, afin de fournir des services à l'échelle de l'entreprise.

 

3 - Exemple d’application.

Cette application simple est livrée avec Visual Basic (samples\Entreprise\Hello). Elle se décompose en deux applications :

 

3.1 - L’application cliente

La forme du client contient un seul bouton cmdSayHi et le code suivant :

La forme client.

Dim objNew As Object
___________________________________________________
Private Sub cmdSayHi_Click()
MsgBox objNew.SayHello
End Sub
___________________________________________________
Private Sub Form_Load()
Set objNew = CreateObject("HelloProj.HelloClass")
End Sub
___________________________________________________
Private Sub Form_Unload(Cancel As Integer)
Set objNew = Nothing
End Sub

Le code du client.

3.2 - L’application serveur.

Le serveur est composé d’une classe HelloClass (la forme frmHello ne sert que pour le déboggage).

Public Function SayHello() As String
SayHello = "Utilisateur de Microsoft Visual Basic, Bonjour!"
End Function

Private Sub Class_Terminate()
nload frmHello
End Sub

Le code du serveur.

3.3 - Fonctionnement.

L’application serveur étant un ActiveX EXE, nous sommes ici en présence d’un serveur "out-of-process" (voir § 1). Ce serveur est donc directement exportable sur un serveur physique et facilement accessible depuis le client en utilisant l’architecture DCOM.

Pour faire fonctionner ce projet il faut préalablement compiler le serveur afin que celui-ci soit répertorié dans la base de registre.

Veillez à ce que l’option "Remote Server Files" soit correctement positionnée avant de compiler le projet serveur. C’est cette option qui détermine si le composant ActiveX sera exécuté sur un serveur distant.

Le fonctionnement de l’application est simple, lorsqu’un utilisateur actionne le bouton "Dire Bonjour " le client fait appel à la méthode (fonction) SayHello du serveur (objNew.SayHello), objNew étant une instance du serveur HelloProj.

 

3.3.1 - Préparation de l’installation du composant distant.

Cette opération se fait simplement à l’aide de l’assistant d’installation de Visual Basic :

Suivre les instructions suivantes :

Sélectionner ensuite les options les plus adaptées à vos besoins.

La procédure de distribution du composant est prête, il ne reste plus qu’a l’installer sur un serveur avec le "Setup" ainsi généré.

 

3.3.2 Préparation de l’installation du client.

Suivez la même procédure que pour le serveur jusqu'à l’écran :

Cliquer sur "Add Remote" pour désigner les composants distants :

L’option de compilation "Remote Server Files" que nous avons positionné sur les propriétés du projet serveur permet de générer un fichier ".VBR " qui indique au Setup le type de composant distant et les modifications à apporter à la base de registre. C’est de ce fichier que la procédure d’installation à besoin pour pouvoir détecter l’utilisation de composants DCOM.

  • VB5SERVERINFO
  • VERSION=1.0.2422
  • HKEY_CLASSES_ROOT\Typelib\{A12BF96C-CD53-11D1-A3B3-00E029045EDB}\1.0\0\win32 = helo_svr.exe
  • HKEY_CLASSES_ROOT\Typelib\{A12BF96C-CD53-11D1-A3B3-00E029045EDB}\1.0\FLAGS = 0
  • HKEY_CLASSES_ROOT\HelloProj.HelloClass\CLSID = {A12BF969-CD53-11D1-A3B3-00E029045EDB}
  • HKEY_CLASSES_ROOT\CLSID\{A12BF969-CD53-11D1-A3B3-00E029045EDB}\ProgID = HelloProj.HelloClass
  • HKEY_CLASSES_ROOT\CLSID\{A12BF969-CD53-11D1-A3B3-00E029045EDB}\Version = 1.0
  • HKEY_CLASSES_ROOT\CLSID\{A12BF969-CD53-11D1-A3B3-00E029045EDB}\Typelib = {A12BF96C-CD53-11D1-A3B3-00E029045EDB}
  • HKEY_CLASSES_ROOT\CLSID\{A12BF969-CD53-11D1-A3B3-00E029045EDB}\LocalServer32 = helo_svr.exe
  • HKEY_CLASSES_ROOT\INTERFACE\{A12BF968-CD53-11D1-A3B3-00E029045EDB} = HelloClass
  • HKEY_CLASSES_ROOT\INTERFACE\{A12BF968-CD53-11D1-A3B3-00E029045EDB}\ProxyStubClsid = {00020420-0000-0000-C000-000000000046}
  • HKEY_CLASSES_ROOT\INTERFACE\{A12BF968-CD53-11D1-A3B3-00E029045EDB}\ProxyStubClsid32 = {00020420-0000-0000-C000-000000000046}
  • HKEY_CLASSES_ROOT\INTERFACE\{A12BF968-CD53-11D1-A3B3-00E029045EDB}\Typelib = {A12BF96C-CD53-11D1-A3B3-00E029045EDB}
  • HKEY_CLASSES_ROOT\INTERFACE\{A12BF968-CD53-11D1-A3B3-00E029045EDB}\Typelib\"version" = 1.0

Le contenu du fichier ".VBR " du serveur helo_srv.exe

Confirmer l’utilisation de DCOM :

Terminer la procédure normalement.

A ce stade les deux procédures d’installations sont créer, il ne reste plus qu’à installer physiquement les programmes.

 

3.3.3 - Installation du composant distant.

La procédure d’installation se limite à l’exécution du "Setup" créé au § 2.3.1 sur le serveur d’accueil.

3.3.4 Configuration du composant distant.

Le composant distant peut être configuré (sécurité, règles d’exécution) à l’aide de l’utilitaire DCOMCNFG livré sur toutes les machines NT (mais qui n’est utilisable qu’à partir d’une session Administrateur) :

 

3.3.5 - Installation du client.

Exécuter normalement le "Setup" créé au § 2.3.2 celui-ci demande alors sur quel serveur se trouve le composant distant.

3.4 - Résumé.

Voici en résumé l’ensemble des étapes nécessaires pour créer une application cliente utilisant des composants distants :

 

 

4 - Une application trois tiers avec DCOM.

Dans le cadre d’application clients/serveur trois tiers les définitions des "DSN ODBC" se font uniquement sur le serveur sur lequel les composants d’accès aux sources de données sont installés.

 

4.1 - Une application trois tiers.

Cette petite application utilise la base Pubs de SQL-Server pour interroger un auteur par son identifiant.

La structure du projet :

4.2 - Le client.

 

4.3 - Le composant distant.

 

5 - Conclusion.

La simplicité de mise en œuvre de composants répartis avec DCOM apporte une grande souplesse dans les développements et dans la réutilisation de codes (objets et composants). Cette architecture allège et simplifie surtout le processus déploiement d’applications clients/serveur.

Si la conception de composants partagés réutilisables est un peu plus longue et contraignante, il n’en est pas moins vrai que les gains dans la conception et le développement de nouveaux projets utilisant ces mêmes composants seront rapidement importants. Il convient donc de toujours penser "réutilisation" et de tenter de séparer les fonctions qui seront communes à plusieurs applications ou à plusieurs programmes d’une même application afin d’accroître et la productivité des équipes de développement et la facilité de maintenance des applications clients/serveur.