OLE est l'abréviation de Object Linking and Embedding, ce qui signifie Intégration d'objets et Lien sur des objets. OLE est une technologie qui a été développée par Microsoft, initialement dans le but de permettre la programmation d'objets capables d'être insérés dans des applications réceptacles soit par intégration complète, soit par référence (ce que l'on appelle une liaison). Ce but a été atteint pour la plupart des applications et apparaît à présent dans le menu Coller | Collage spécial. Les objets intégrés ou liés sont capables de s'afficher dans l'application qui les contient. Ils sont également capables de fournir un certain nombre de services standards permettant leur manipulation (ces services peuvent être la sauvegarde de leur état, la capacité à être édité, etc...). OLE est donc un remplacement efficace des liaisons DDE.

Pour réaliser cet objectif, Microsoft a dû fournir un standard de communication entre les différentes applications qui voulaient être OLE. Ce standard de communication, définit la méthode à employer pour accéder aux fonctionnalités des objets OLE, ainsi que les principaux services qui peuvent être nécessaires lors de l'intégration d'objets. Les programmeurs désirant réaliser une application OLE devaient se conformer au protocole d'appel du standard et fournir un certain nombre des services définis dans OLE. Ce standard a été conçu de manière ouverte, c'est à dire qu'il n'est pas nécessaire de fournir tous les services définis dans OLE pour être fonctionnel. Cependant, plus un objet OLE offre de services, meilleure son intégration est. De même, plus une application est capable d'utiliser des services, plus elle est fonctionnelle avec les objets qui fournissent ces services. Par ailleurs, il est possible de définir des services différents de ceux définis dans OLE, le système est donc également extensible.

Le standard de communication qui a été défini se nomme COM, ce qui signifie Component Object Model, ou Modèle Objet de Composants. La plupart des services sont définis dans OLE, cependant, COM lui-même utilise un certain nombre de services. La limite entre ce qui est défini par COM et ce qui est défini par OLE est donc floue, mais en principe, les services COM sont tous des services systèmes.

Comme on l'a dit, initialement, OLE devait permettre l'intégration des objets entre applications. En fait, il s'est avéré qu'OLE faisait beaucoup plus que cela : grâce à COM, il permettait l'écriture de composants logiciels réutilisables par différentes applications. Il s'agit donc bien d'une technologie à composants.

Microsoft a ensuite complété la technologie COM afin de permettre la répartition des composants sur un réseau. L'aspect distribué des composants COM ainsi répartis a donné le nom à cette extension de COM, que l'on appelle simplement DCOM (pour Distributed COM). Dans la suite du document, on considérera que COM est distribué, on utilisera donc systématiquement le terme DCOM.

Du point de vue du programmeur, DCOM spécifie la manière dont les composants peuvent être utilisés. Du point de vue du système, DCOM spécifie les services que ce dernier doit fournir aux programmeurs. Ce dernier aspect est moins intéressant (ou du moins il n'intéresse que Microsoft), parce que ces spécifications ne concernent que les éditeurs de logiciels qui désirent implémenter DCOM. Je ne décrirai donc DCOM que du point de vue des programmeurs.

DCOM regroupe les fonctionnalités des composants par interfaces. Une interface est un jeu de fonctions plus ou moins liées sémantiquement, qui permettent d'utiliser un composant. Un composant peut implémenter plusieurs interfaces.

DCOM spécifie la forme des interfaces au niveau binaire. Ces interfaces sont en fait un pointeur sur le tableau de pointeurs de fonctions que les compilateurs C++ pour Windows génèrent pour gérer les méthodes virtuelles des classes C++. Ceci implique qu'il est relativement facile de programmer des composants DCOM et encore plus facile de les utiliser en C++ : les interfaces sont simplement des classes abstraites pures. Cependant, comme cette structure peut être recréée dans d'autres langages, on n'est donc pas obligé d'utiliser le C++. DCOM est donc indépendant du langage. En particulier, on peut programmer et utiliser des composants DCOM en C, en Pascal, en Visual Basic, en Assembleur, en Visual J++.

Les interfaces sont identifiées dans le système par des nombres uniques à 128 bits. Ces nombres sont appelés les GUID (Globally Unique IDentifier, soit Identificateur globalement unique), ou UUID (Universally Unique IDentifier, soit Identificateur universel unique). Un utilitaire, UUIDGEN.EXE, est fourni pour générer de tels nombres. Ces nombres sont calculés pour être absolument unique dans le monde et en tout temps, ils permettent donc d'éviter toute collision entre les identificateurs des interfaces définies par tous les programmeurs du monde. Ceci implique qu'à chaque interface correspond un GUID et un seul. Une fois qu'une interface a été définie, on ne peut plus la modifier (pas même l'étendre) : on doit refaire une autre interface (cette nouvelle interface pourra cependant hériter des méthodes de l'interface à étendre, mais sera identifiée par son propre UUID). Une interface est donc parfaitement identifiée par son UUID, souvent appelé IID (pour Interface IDentifier), et constitue le contrat qu'un composant passe avec ceux qui l'utilisent. Les composants qui disposent de cette interface signifient simplement qu'ils gèrent les fonctionnalités de cette interface, et qu'ils les géreront toujours sous cette forme.

Pour utiliser une interface d'un composant, il faut d'abord la demander. Ce mécanisme permet l'identification dynamique des fonctionnalités d'un composant : soit le composant serveur gère l'interface demandée et on obtient un pointeur sur cette interface, soit il ne la gère pas et on ne reçoit rien en retour. On ne peut donc utiliser les composants que par l'intermédiaire des interfaces qu'ils gèrent. DCOM spécifie la manière de créer les composants et d'obtenir des interfaces.

Les composants sont également identifiés par un GUID. Comme les composants de COM sont appelés des classes, dont les instances sont les objets OLE eux-mêmes, les GUID qui leurs sont attribués sont appelés les CLSID (CLaSs IDentifier, soit Identificateur de classe). Tous ces GUID sont stockés dans des entrées spécifiques de la base de registre, que le système peut consulter pour faire fonctionner DCOM. La clé principale qui permet de stocker toutes les informations du système sur DCOM est HKEY_CLASSES_ROOT.

Les composants peuvent être écrits aussi bien sous la forme de DLL que sous la forme d'exécutables. Les fichiers qui implémentent des composants sont appelés des serveurs. Les programmes qui utilisent un composant sont ses clients. Quel que soit le type de serveur, DCOM fournit les mécanismes nécessaires pour que ceux-ci s'enregistrent dans le système et puissent être utilisés. Ces mécanismes assurent une totale transparence aussi bien pour l'implémentation des composants vis-à-vis du type de serveur qui les contient que pour les clients. De plus, les serveurs peuvent être exécutés sur une autre machine que celle sur laquelle tourne un client. DCOM assure ainsi une complète transparence par rapport au réseau ou aux communications entre composants. Pour le client, l'utilisation d'un service revient toujours à appeler une fonction d'une interface, et pour le serveur, l'implémentation d'un service revient toujours à écrire cette interface.

On se méfiera de la terminologie de DCOM. Les serveurs peuvent eux-mêmes être clients d'autres composants. Il s'agit ici d'une extension du modèle client/serveur, où chacun peut être à la fois soit l'un, soit l'autre.

Pour assurer la transparence au niveau du réseau, DCOM utilise les RPC (Remote Procedure Call, ou Appels de procédures à distance). Il facilite ainsi énormément la gestion du réseau pour les programmeurs. En particulier, il prend en charge les communications et le marshalling, c'est à dire l'encapsulation du côté client des paramètres donnés par le client à la fonction appelée, ainsi que la reconstitution de ces paramètres du coté serveur pour l'appel de la fonction. Bien entendu, DCOM reste ouvert et permet au programmeur de réaliser son propre marshalling, ou de contrôler son propre protocole de communication.

Le protocole RPC utilisé par Microsoft est basé sur les spécifications DCE (Distributed Computing Environment) et n'a absolument rien à voir avec le standard RPC de Sun, utilisé couramment dans le monde Unix.

DCOM est multithreadé. Il permet de réaliser des appels synchrones (bloquants) ou asynchrones. Il permet de contrôler les problèmes de réentrance par sérialisation des appels ou de laisser la gestion du multithreading et des concurrences d'accès au programmeur. Il peut également gérer les interblocages.

DCOM est sécurisé par les droits d'accès des utilisateurs. Ceci signifie qu'il est nécessaire de disposer d'un serveur de domaine pour donner ces droits (en pratique, ce serveur est un poste Windows Server). DCOM gère également les licences d'utilisation pour les composants commerciaux.

DCOM gère la durée de vie des objets OLE par compte de références sur ces objets. Les objets ne sont détruits que lorsque tous les clients de ces objets ont relâché leur référence qu'ils détenaient sur eux.

DCOM permet de stocker la description des interfaces dans ce qu'on appelle des type libraries. Ces bibliothèques stockent la description des interfaces, des fonctions des interfaces, de leurs paramètres et de leurs rôles. Elles permettent donc à un tout le monde d'utiliser un composant même sans en avoir la documentation.

DCOM définit les interfaces qui sont nécessaires pour l'utiliser. En particulier, il est possible d'utiliser les interfaces donnant accès aux fonctionnalités du marshaling, à la gestion de la mémoire de manière uniforme entre les objets OLE, à la gestion du multithreading, à la gestion des type libraries et à la connectivité des objets OLE entre eux.

À toutes ces fonctionnalités, on peut ajouter des fonctionnalités système implémentées sous la forme d'objets DCOM. La plupart des nouvelles fonctionnalités ajoutées à Windows par Microsoft ne sont accessibles que par l'intermédiaire d'objets COM systèmes. On prendra par exemple la gestion directe des périphériques par Direct X, dont toutes les fonctionnalités sont implémentées sous la forme de composants DCOM.

OLE ajoute aux services fournis par DCOM les fonctionnalités suivantes :

• gestion de la persistance des objets à l'aide de stockages structurés ;
• gestion des noms des objets et de leur recherche dans le système à l'aide de composants spécifiques (à l'aide des monikers, qui sont des composants permettant de localiser d'autres composants) ;
• gestion des transferts de données uniformes entre applications ;
• gestion du copier/coller ;
• gestion de la visualisation des objets dans leurs conteneurs ;
• gestion de l'édition et de la modification des objets au sein même de leurs conteneurs ;
• gestion de la programmation des objets par script (OLE Automation) ;
• mise à disposition de contrôles OLE permettant de simplifier la programmation ;
• intégration dans l'interface utilisateur Windows 9x ou NT.