Comprendre DCOM

Table des matières

1. - Architecture distribuée

1.1 - Distribued COM (DCOM).

1.2 - Fonctionnement interprocessus transparent

1.3 - Transparence locale et distante

1.4 - Configuration et test de composants à distance

2. - Conclusion.

 

 

 

1 - Architecture distribuée

Qui dit création de solutions regroupant plusieurs composants dit possibilité de créer les composants et de les déployer dans le cadre d'un accès à distance à travers le réseau. La difficulté à accomplir simplement ces opérations a constitué le principal frein à l'adoption à grande échelle d'une architecture à trois niveaux pour les solutions client-serveur.

1.1 Distribued COM (DCOM).

Visual Basic version  4.0 a remédié à ce problème avec l'introduction de l'Automation à distance. Le modèle COM distribué améliore désormais ces fonctionnalités et constitue une évolution du modèle standard COM. L'Automation à distance est toujours prise en charge dans un souci de compatibilité avec les versions précédentes et notamment dans le cadre du déploiement sur des systèmes 16 bits. Tous les utilitaires d'Automation à distance fournis avec la version 4.0 ont été améliorés pour prendre en charge les deux types de systèmes distants.

Visual Basic vous permet de créer des composants ActiveX (précédemment appelés Serveur OLE Automation), de déployer ces composants et d'y accéder sur des systèmes Windows NT et Windows 95 distants, comme s'il s'agissait de composants locaux. Il n'y a aucune distinction entre exécution sur le client et exécution sur le serveur ; un composant ActiveX peut donc être exécuté sur une station de travail client comme sur un serveur distant, sans qu'il soit nécessaire de recompiler l'application client ou le composant ActiveX.

Sur une machine, le modèle COM fournit automatiquement une combinaison proxy/stub à chaque extrémité de la connexion entre un composant ActiveX et son processus client.

Dans le cas de composants situés sur des machines distinctes, le modèle COM distribué joue pour l'essentiel le même rôle, fournissant de manière transparente une combinaison proxy/stub et des services de transport réseau.

L'Automation à distance fournit un composant logiciel supplémentaire, Automation Manager, et remplace la combinaison proxy/stub d'origine par des modules capables de communiquer sur un réseau, comme indiqué dans la figure 3.1.

Figure 3.1 Automation à distance entre deux ordinateurs

Automation Manager réside sur la machine distante et transmet les requêtes du marshaler (empaquetées) provenant du proxy Automation à distance de l'ordinateur local vers l'objet stub Automation à distance correspondant sur le serveur. Automation Manager utilise un processus de marshaling pour les valeurs renvoyées. Elles sont ensuite renvoyées au composant client ActiveX par l'intermédiaire du proxy Automation à distance. Le client, comme le serveur, ignore qu'il s'agit d'une connexion à distance.

Les utilitaires permettant d'inscrire, de cataloguer et d'exporter des composants ActiveX sont décrits dans les sections suivantes. Il s'agit notamment des utilitaires suivants  :

· Utilitaire d'inscription client

· Gestionnaire de connexion d'automation à distance

· Gestionnaire de regroupement

· Object Gallery

Le modèle COM distribué (également appelé DCOM), le système d'objets distribués de Microsoft, est une interface ActiveX destinée aux applications réseau de composants distribués. Le modèle DCOM offre également une transparence au niveau du réseau et une automatisation des communications, de sorte que les communications peuvent intervenir entre des objets sans qu'un objet connaisse nécessairement l'emplacement de l'autre objet. Les objets peuvent se situer dans des processus différents sur la même machine ou sur des machines distinctes.

Le modèle COM distribué permet une interopération transparente entre les applications ActiveX exécutées sur différentes machines, en utilisant un appel de procédure à distance (RPC, Remote Procedure Call) standard. Le mécanisme RPC, appelé Microsoft RPC, a été conçu à partir du standard RPC de l'environnement DCE (Distributed Computing Environment) de l'OSF (Open Software Foundation).

Le modèle COM distribué permet aux développeurs de l'entreprise de diviser une application en modules de composants qui peuvent tous s'exécuter de façon transparente sur différents ordinateurs. Grâce à cette transparence réseau, ces composants semblent, pour les utilisateurs et les programmeurs, être situés sur une même machine.

La technologie des objets distribués peut également être utilisée pour faire apparaître des réseaux et des ressources d'information globaux comme locaux, facilitant et accélérant pour les utilisateurs l'accès aux informations stratégiques de l'entreprise. Par l'intermédiaire du modèle COM distribué et de l'Automation à distance, les utilisateurs peuvent situer et exécuter des composants sur des réseaux globaux, sans même être conscients que les informations sont à des milliers de kilomètres.

 

1.2 - Fonctionnement interprocessus transparent

Il serait relativement facile de résoudre le problème de l'établissement d'une architecture logicielle de composants si les développeurs pouvaient considérer que toutes les interactions entre composants se produisent au sein du même espace de processus. Mais en réalité, ce n'est généralement pas le cas.

 

1.3 - Transparence locale et distante

Le standard ActiveX est conçu pour permettre aux clients de communiquer de façon transparente avec des composants, quel que soit l'endroit où ces composants sont exécutés, qu'ils soient dans le même processus, sur la même machine ou sur une autre machine. Cela signifie qu'il existe un modèle de programmation unique pour tous les types de composants ActiveX.

Du point de vue d'une application client, tous les composants ActiveX sont accessibles par l'intermédiaire de pointeurs d'interface. Un pointeur doit être in-process, et en fait, tout appel à une fonction de l'interface atteint toujours dans un premier temps une partie ou une autre de code in-process. Si le composant ActiveX est un composant in-process (un fichier .dll), l'appel l'atteint directement. Si le composant est un composant out-of-process, l'appel atteint d'abord ce qu'on appelle un objet proxy fourni par le modèle COM lui-même, qui génère l'appel de procédure à distance approprié vers l'autre processus ou l'autre machine.

Du point de vue d'un composant ActiveX, tous les appels aux fonctions de l'interface du composant se font par l'intermédiaire d'un pointeur sur cette interface. Comme indiqué précédemment, un pointeur n'a de contexte que dans un seul processus, et l'élément appelant doit toujours être une partie de code in-process. Si le composant ActiveX est un composant in-process, l'élément appelant est le client lui-même. Sinon, l'élément appelant est un objet stub (fourni par le modèle COM) qui récupère l'appel de procédure à distance de l'objet proxy dans le processus client et le transforme en appel d'interface vers le composant serveur.

Du point de vue des clients et des serveurs, leur communication se fait toujours directement avec un autre code in-process.

En résumé, l'utilisation des composants ActiveX locaux ou distants est identique une fois que les adresses des composants ont été entrées dans la base de registres. Cette transparence locale/distante présente un certain nombre d'avantages non négligeables  :

· Une solution commune aux problèmes indépendants de la distance entre le client et le serveur. Par exemple, les connexions, appels de fonctions, négociations d'interface, évolutions de fonctions, etc., se produisent exactement de la même façon pour les composants interopérant dans le même processus que pour les composants interopérant sur des réseaux globaux.

· Les développeurs optimisent leurs connaissances. Les nouveaux services sont simplement mis à disposition par l'intermédiaire de nouvelles interfaces, et une fois que les développeurs maîtrisent le traitement des interfaces, ils savent déjà comment traiter les services qui seront créés ultérieurement.

· Les concepteurs de composants peuvent se concentrer sur la conception. Lors de la création des composants d'une application d'entreprise, les concepteurs peuvent se consacrer à la création à proprement parler, sans avoir à se soucier des mécanismes de communication sous-jacents à prendre en compte pour les divers scénarios d'interfonctionnement. Le modèle COM distribué fournit directement ces mécanismes, y compris la transparence réseau.

1.4 - Configuration et test de composants à distance

Pour configurer et faire la démonstration des composants ActiveX utilisant Automation à distance ou le modèle d'objet composant (COM) distribué, un exemple d'application très simple est fourni dans le dossier \Samples\Entrpris\Hello de votre installation Visual Basic. Vous trouverez des instructions pour configurer les composants client-serveur de cette application exemple sur plusieurs ordinateurs dans la section "Installation des composants Automation à distance et COM distribué" du chapitre "Distribution de vos applications " du Guide de l'utilisateur.

Une fois que vous avez installé et enregistré les deux composants conformément aux instructions, vous pouvez lancer l'application client (Helo_cli.exe) sur votre ordinateur, tandis que le composant serveur (Helo_svr.exe) s'exécute en local ou à distance. Pour basculer entre le déploiement local ou distant du composant serveur, utilisez le Gestionnaire de connexion d'automation à distance.

 

2 - Conclusion.

La conception et le développement d’applications clients/serveur performantes sur des plates-formes Windows 32 bits nécessitent l’utilisation des nouvelles technologies et architectures Microsoft. Il n’est plus pensable de développer une application avec Visual Basic 5 et d’avoir recours à OLE Automation comme architecture distribuée ou à DAO comme interface unique d’accès aux données.

 

DCOM est le modèle d’architecture distribuée incontournable sur plate-forme Windows 32 bits il apporte des facilités importantes au niveau de la sécurité et de la distribution des composants mais aussi des gains notables de performances. DCOM facilite en outre le développement de composants réutilisables.