Vue d’ensemble technique de COM

  • Article

Cette rubrique fournit une vue d’ensemble du modèle COM (Microsoft Component Object Model) :

Introduction à COM

Le modèle COM (Microsoft Component Object Model) définit une norme d’interopérabilité binaire pour la création de bibliothèques de logiciels réutilisables qui interagissent au moment de l’exécution. Vous pouvez utiliser des bibliothèques COM sans avoir à les compiler dans votre application. COM est la base d’un certain nombre de produits et technologies Microsoft, tels que Lecteur multimédia Windows et Windows Server.

COM définit une norme binaire qui s’applique à de nombreux systèmes d’exploitation et plateformes matérielles. Pour l’informatique réseau, COM définit un format de fil standard et un protocole pour l’interaction entre les objets qui s’exécutent sur différentes plateformes matérielles. COM est indépendant du langage d’implémentation, ce qui signifie que vous pouvez créer des bibliothèques COM à l’aide de différents langages de programmation, tels que C++ et ceux du .NET Framework.

La spécification COM fournit tous les concepts fondamentaux qui permettent la réutilisation de logiciels multiplateformes :

  • Standard binaire pour les appels de fonction entre les composants.
  • Provision pour les regroupements fortement typés de fonctions dans des interfaces.
  • Interface de base qui fournit le polymorphisme, la découverte de fonctionnalités et le suivi de la durée de vie des objets.
  • Mécanisme qui identifie de manière unique les composants et leurs interfaces.
  • Chargeur de composants qui crée des instances de composant à partir d’un déploiement.

COM comporte un certain nombre d’éléments qui fonctionnent ensemble pour permettre la création d’applications créées à partir de composants réutilisables :

  • Système hôte qui fournit un environnement d’exécution conforme à la spécification COM.
  • Interfaces qui définissent des contrats de fonctionnalités et composants qui implémentent des interfaces.
  • Serveurs qui fournissent des composants au système et clients qui utilisent les fonctionnalités fournies par les composants.
  • Registre qui effectue le suivi de l’emplacement où les composants sont déployés sur les hôtes locaux et distants.
  • Gestionnaire de contrôle des services qui localise les composants sur les hôtes locaux et distants et connecte les serveurs aux clients.
  • Protocole de stockage structuré qui définit comment naviguer dans le contenu des fichiers sur le système de fichiers de l’hôte.

L’activation de la réutilisation du code sur les hôtes et les plateformes est essentielle pour COM. Une implémentation d’interface réutilisable est nommée un composant, un objet de composant ou un objet COM. Un composant implémente une ou plusieurs interfaces COM.

Vous définissez une bibliothèque COM personnalisée en concevant les interfaces que votre bibliothèque implémente. Les consommateurs de votre bibliothèque peuvent découvrir et utiliser ses fonctionnalités sans connaître les détails de déploiement et d’implémentation de votre bibliothèque.

Objets et interfaces

Un objet COM expose ses fonctionnalités via une interface, qui est une collection de fonctions membres. Une interface COM définit le comportement attendu et les responsabilités d’un composant, et spécifie un contrat fortement typé qui fournit un petit ensemble d’opérations associées. Toutes les communications entre les composants COM se produisent via des interfaces, et tous les services proposés par un composant sont exposés via son interface. Un appelant peut accéder uniquement aux fonctions membres de l’interface. L’état interne n’est pas disponible pour un appelant, sauf s’il est exposé dans l’interface.

Les interfaces sont fortement typées. Chaque interface a son propre identificateur d’interface unique, appelé IID, qui élimine les collisions qui peuvent se produire avec des noms lisibles par l’homme. L’IID est un identificateur global unique (GUID), qui est identique à l’ID universellement unique (UUID) défini par l’Open Software Foundation (OSF) Distributed Computing Environment (DCE). Lorsque vous créez une interface, vous devez créer un identificateur pour cette interface. Lorsqu’un appelant utilise une interface, il doit utiliser l’identificateur unique. Cette identification explicite améliore la robustesse en éliminant les conflits d’affectation de noms qui entraîneraient un échec de l’exécution.

Lorsque vous définissez une nouvelle interface, vous pouvez créer une définition d’interface à l’aide du langage IDL (Interface Definition Language). À partir de cette définition d’interface, le compilateur IDL Microsoft génère des fichiers d’en-tête à utiliser par les applications qui utilisent l’interface et du code source pour gérer les appels de procédure distante. L’IDL fourni par Microsoft est basé sur des extensions simples de DCE IDL, une norme du secteur pour l’informatique distribuée basée sur les appels de procédure distante (RPC). IDL est un outil pratique pour le concepteur d’interface et n’est pas essentiel à l’interopérabilité COM. Avec IDL, vous n’avez pas besoin de créer manuellement des fichiers d’en-tête pour chaque environnement de programmation. Pour plus d’informations, consultez Définition d’interfaces COM.

L’héritage est utilisé avec parcimonie dans les interfaces COM. COM prend en charge l’héritage d’interface uniquement pour réutiliser un contrat associé à une interface de base. COM ne prend pas en charge l’héritage sélectif ; Par conséquent, si une interface hérite d’une autre, elle inclut toutes les fonctions que l’interface de base définit. En outre, les interfaces utilisent un seul héritage, au lieu d’un héritage multiple, pour obtenir des fonctions à partir d’une interface de base.

Implémentation d’interface

Vous ne pouvez pas créer une instance d’une interface COM par elle-même. Au lieu de cela, vous créez une instance d’une classe qui implémente l’interface. En C++, une interface COM est modélisée en tant que classe de base abstraite, ce qui signifie que l’interface est une classe C++ qui contient uniquement des fonctions membres virtuelles pures. Une bibliothèque C++ implémente des objets COM en héritant les signatures de fonction membre d’une ou plusieurs interfaces, en remplaçant chaque fonction membre et en fournissant une implémentation pour chaque fonction.

Vous pouvez utiliser n’importe quel langage de programmation qui prend en charge le concept de pointeurs de fonction pour implémenter une interface COM. Par exemple, en C, une interface est une structure contenant un pointeur vers une table de pointeurs de fonction, un pour chaque méthode de l’interface.

Lorsque vous implémentez une interface, votre classe doit fournir une implémentation pour chaque fonction de l’interface. Si la classe n’a pas de travail à effectuer dans une fonction d’interface, l’implémentation peut être une instruction de retour unique.

Une classe COM est identifiée à l’aide d’un ID de classe (CLSID) 128 bits unique qui associe une classe à un déploiement particulier dans le système de fichiers, qui pour Windows est une DLL ou exe. Un CLSID est un GUID, ce qui signifie qu’aucune autre classe n’a le même CLSID. L’utilisation d’identificateurs de classe uniques empêche les collisions de noms entre les classes. Par exemple, deux fournisseurs différents peuvent écrire une classe nommée CStack, mais les deux classes ont un CLSID unique, de sorte que toute possibilité de collision est évitée.

Vous obtenez un nouveau CLSID à l’aide de la fonction CoCreateGuid ou d’un outil de création COM, tel que Visual Studio, qui appelle cette fonction en interne.

The IUnknown Interface

Toutes les interfaces COM héritent de l’interface IUnknown . L’interface IUnknown contient les opérations COM fondamentales pour le polymorphisme et la gestion instance durée de vie. L’interface IUnknown a trois fonctions membres, nommées QueryInterface, AddRef et Release. Tous les objets COM sont requis pour implémenter l’interface IUnknown .

La fonction membre QueryInterface fournit un polymorphisme pour COM. Appelez QueryInterface pour déterminer au moment de l’exécution si un objet COM prend en charge une interface particulière. L’objet COM retourne un pointeur d’interface dans le ppvObject paramètre s’il implémente l’interface demandée; sinon, il retourne NULL. La fonction membre QueryInterface permet la navigation entre toutes les interfaces prises en charge par un objet COM.

La durée de vie d’un objet COM instance est contrôlée par son nombre de références. Les fonctions membres IUnknownAddRef et Release contrôlent le nombre. AddRef incrémente le nombre et Release décrémente le nombre. Lorsque le nombre de références atteint zéro, la fonction membre Release peut libérer le instance, car aucun appelant ne l’utilise.

Modèle client/serveur

Une classe COM implémente un certain nombre d’interfaces COM. L’implémentation se compose de fichiers binaires qui s’exécutent lorsqu’un appelant interagit avec un instance de la classe COM. COM permet d’utiliser une classe dans différentes applications, y compris les applications écrites sans connaître une classe particulière. Sur une plateforme Windows, les classes existent dans une bibliothèque liée dynamique (DLL) ou dans une autre application (EXE).

Sur son système hôte, COM gère une base de données d’inscription de tous les CLSID pour les objets COM installés sur le système. La base de données d’inscription est un mappage entre chaque CLSID et l’emplacement de la DLL ou de l’EXE qui héberge la classe correspondante. COM interroge cette base de données chaque fois qu’un appelant souhaite créer un instance d’une classe COM. L’appelant doit connaître uniquement le CLSID pour demander une nouvelle instance de la classe.

L’interaction entre un objet COM et ses appelants est modélisée comme une relation client/serveur. Le client est l’appelant qui demande un objet COM à partir du système, et le serveur est le module qui héberge les objets COM qui fournissent des services aux clients.

Un client COM est un appelant qui transmet un CLSID au système pour demander une instance d’un objet COM. Le moyen le plus simple de créer un instance consiste à appeler la fonction COM, CoCreateInstance.

La fonction CoCreateInstance crée un instance du CLSID spécifié et retourne un pointeur d’interface du type demandé par le client. Le client est responsable de la gestion de la durée de vie de l’instance en appelant sa fonction Release lorsque le client a terminé de l’utiliser. Pour créer plusieurs objets basés sur un SEUL CLSID, appelez la fonction CoGetClassObject . Pour vous connecter à un objet déjà créé et en cours d’exécution, appelez la fonction GetActiveObject .

Un serveur COM fournit une implémentation COM au système. Un serveur associe un CLSID à une classe COM, héberge l’implémentation de la classe, implémente une fabrique de classes pour créer des instances de la classe et fournit le déchargement du serveur.

Notes

Un serveur COM n’est pas identique à l’objet COM qu’il fournit au système.

 

Pour activer la création d’un objet COM, un serveur COM doit fournir une implémentation de l’interface IClassFactory . Les clients peuvent appeler la méthode CreateInstance pour demander une nouvelle instance d’un objet COM, mais ces requêtes sont généralement encapsulées dans la fonction CoCreateInstance.

Vous pouvez déployer un serveur COM en tant que bibliothèque partagée chargée dans le processus du client au moment de l’exécution (DLL sur les plateformes Windows) ou en tant que module exécutable (EXE sur les plateformes Windows). Pour plus d’informations, consultez Inscription d’applications COM.

Gestionnaire de contrôle des services

Le Gestionnaire de contrôle de service (SCM) gère la demande du client pour un instance d’un objet COM. La liste suivante montre la séquence d’événements :

  • Un client demande un pointeur d’interface vers un objet COM à partir de la bibliothèque COM en appelant une fonction telle que CoCreateInstance avec le CLSID de l’objet COM.
  • La bibliothèque COM interroge le SCM pour trouver le serveur qui correspond au CLSID demandé.
  • Le SCM localise le serveur et demande la création de l’objet COM à partir de la fabrique de classes fournie par le serveur.
  • Si elle réussit, la bibliothèque COM retourne un pointeur d’interface vers le client.

Une fois que le système COM a connecté un objet serveur à un client, le client et l’objet communiquent directement. Il n’y a pas de surcharge supplémentaire liée à l’appel d’un temps d’exécution intermédiaire.

Lorsque vous inscrivez un serveur COM auprès du système hôte, vous pouvez spécifier différentes façons d’activer le serveur. La liste suivante montre les trois façons dont le SCM peut activer un serveur COM :

  • In-process : le SCM retourne le chemin du fichier de la DLL qui contient l’implémentation du serveur d’objets. La bibliothèque COM charge la DLL et l’interroge pour son pointeur d’interface de fabrique de classe.
  • Local : le SCM démarre l’exécutable local qui inscrit une fabrique de classes au démarrage, et son pointeur d’interface est disponible pour le système et les clients.
  • Distant : le SCM local acquiert un pointeur d’interface de fabrique de classe à partir du SCM qui s’exécute sur un ordinateur distant.

Lorsqu’un client demande un objet COM, la bibliothèque COM contacte le SCM sur l’hôte local. Le SCM localise le serveur COM approprié, qui peut être local ou distant, et le serveur retourne un pointeur d’interface vers la fabrique de classes du serveur. Lorsque la fabrique de classes est disponible, la bibliothèque COM ou le client peut utiliser la fabrique de classes pour créer l’objet demandé. Pour plus d’informations, consultez Implémentation d’IClassFactory.

Possibilité de réutilisation

COM prend en charge la réutilisation des boîtes noires, ce qui signifie que les détails d’implémentation d’un composant réutilisable ne sont pas exposés aux clients. Pour obtenir la réutilisation des boîtes noires, COM prend en charge deux mécanismes par le biais desquels un objet peut en réutiliser un autre. Les deux formes de réutilisation sont nommées confinement et agrégation. Par convention, l’objet réutilisé est nommé l’objet interne, et l’objet qui utilise l’objet interne est nommé l’objet externe.

En confinement, l’objet externe se comporte comme un client de l’objet interne. L’objet externe est un conteneur logique pour l’objet interne, et lorsque l’objet externe utilise les services de l’objet interne, l’objet externe délègue l’implémentation aux interfaces de l’objet interne. Cela signifie que l’objet externe est implémenté en termes de services de l’objet interne. L’objet externe peut ne pas prendre en charge les mêmes interfaces que l’objet interne, et l’objet externe peut utiliser l’interface d’un objet interne pour faciliter l’implémentation de parties d’une autre interface sur l’objet externe.

Dans l’agrégation, l’objet externe expose les interfaces de l’objet interne comme si elles étaient implémentées sur l’objet externe. Cela est utile lorsque l’objet externe délègue toujours chaque appel sur l’une de ses interfaces à la même interface de l’objet interne. L’agrégation est une commodité qui permet à l’objet externe d’éviter une surcharge d’implémentation supplémentaire.

Pour plus d’informations, consultez Réutilisation d’objets.

Objets de stockage et de flux

Les objets COM enregistrent l’état d’un fichier à l’aide du stockage structuré, qui est une forme de stockage persistant qui permet de naviguer dans le contenu d’un fichier à l’aide de la sémantique du système de fichiers. Le traitement du contenu d’un fichier de cette manière permet des fonctionnalités telles que l’accès incrémentiel, les transactions et le partage entre les processus.

La spécification de stockage persistant COM fournit deux types d’éléments de stockage : les objets de stockage et les objets de flux. Ces objets sont implémentés par la bibliothèque COM et les applications utilisateur implémentent rarement ces éléments de stockage. Les objets de stockage implémentent l’interface IStorage et les objets de flux implémentent l’interface IStream .

Un objet de flux contient des données et est conceptuellement similaire à un fichier unique dans un système de fichiers. Chaque flux dispose de droits d’accès et d’un pointeur de recherche unique. Grâce à l’interface IStream , vous pouvez lire, écrire, rechercher et effectuer d’autres opérations sur les données sous-jacentes du flux. Un flux est nommé à l’aide d’une chaîne de texte. Il peut contenir n’importe quelle structure interne, car il s’agit d’un flux plat d’octets. En outre, les fonctions de l’interface IStream sont similaires aux fonctions basées sur un handle de fichier standard, telles que celles de la bibliothèque runtime ANSI C.

Un objet de stockage est conceptuellement similaire à un répertoire dans un système de fichiers. Chaque stockage peut contenir n’importe quel nombre d’objets de sous-stockage et n’importe quel nombre de flux. Chaque stockage a ses propres droits d’accès. Grâce à l’interface IStorage , vous pouvez effectuer des opérations telles que l’énumération, le déplacement, la copie, le renommage, la création et la suppression d’éléments. Un objet de stockage ne stocke pas de données définies par l’application, mais il stocke implicitement les noms des éléments (stockages et flux) qu’il contient.

Les objets de stockage et de flux peuvent être partagés entre les processus lorsqu’ils sont implémentés conformément à la spécification COM sur une plateforme hôte. Cela permet aux objets qui s’exécutent in-process ou out-of-process d’avoir un accès incrémentiel égal à leur stockage de fichiers. Étant donné que COM est chargé dans chaque processus séparément, il utilise des mécanismes de mémoire partagée pris en charge par le système d’exploitation pour communiquer l’état des éléments ouverts et leurs modes d’accès entre les processus.

Chaque objet de stockage et de flux dans un fichier structuré a un nom pour l’identifier. Le nom est une chaîne qui suit une convention particulière. Pour plus d’informations, consultez Conventions d’affectation de noms des objets de stockage. Le nom est passé aux fonctions IStorage pour spécifier l’élément du stockage sur lequel opérer. Les noms des objets de stockage racine sont identiques aux noms de fichiers dans le système de fichiers sous-jacent, et ces noms doivent respecter les conventions et restrictions du système de fichiers. Chaînes passées aux fonctions liées au stockage dont les fichiers de nom sont transmis au système de fichiers sans interprétation ni modification.

Les noms des éléments contenus dans les objets de stockage sont gérés par l’implémentation de l’objet de stockage en question. Toutes les implémentations d’objets de stockage doivent prendre en charge les noms d’éléments de 32 caractères, et certaines implémentations peuvent prendre en charge des noms plus longs. Les noms sont stockés avec une conservation de la casse, mais ils sont comparés comme ne respectant pas la casse. Les applications qui définissent des noms d’éléments de stockage doivent choisir des noms qui fonctionnent dans l’une ou l’autre des situations.

Vous accédez à chaque élément d’un fichier de stockage structuré à l’aide de fonctions et d’interfaces implémentées par COM. Cela signifie que d’autres applications peuvent parcourir le fichier en naviguant avec les fonctions d’interface IStorage qui fournissent des services de type répertoire. En outre, d’autres applications peuvent utiliser les données du fichier, sans avoir à exécuter l’application qui a écrit le fichier. Lorsqu’une application COM accède aux fichiers de stockage structuré d’une autre application, des droits d’accès Windows standard s’appliquent et l’application doit disposer de privilèges suffisants.

Un objet COM peut se lire et écrire lui-même dans un stockage persistant. Un client interroge l’une des interfaces liées à la persistance sur l’objet COM, en fonction du contexte de l’opération. Les objets COM peuvent implémenter n’importe quelle combinaison des interfaces suivantes :

  • IPersistStorage : l’objet COM lit et écrit son état persistant dans un objet de stockage. Le client fournit à l’objet un pointeur IStorage via cette interface. Il s’agit de la seule interface de persistance qui inclut la sémantique pour l’accès incrémentiel.
  • IPersistStream : l’objet COM lit et écrit son état persistant dans un objet de flux. Le client fournit à l’objet un pointeur IStream via cette interface.
  • IPersistFile : l’objet COM lit et écrit son état persistant directement dans un fichier sur le système sous-jacent. Cette interface n’implique pas IStorage ou IStream , sauf si le fichier sous-jacent est accessible via ces interfaces, mais l’interface IPersistFile n’a aucune sémantique pour les stockages et les flux. Le client fournit à l’objet un nom de fichier et appelle les fonctions Enregistrer ou Charger .

Transfert de données

Le stockage structuré fournit la base de l’échange de données entre les objets et les processus COM, qui est appelé transfert de données uniforme. Avant l’implémentation de COM dans OLE 2, le transfert de données sur Windows était spécifié par des protocoles de transfert, tels que le Presse-papiers et les protocoles glisser-déplacer. Chaque protocole de transfert avait son propre ensemble de fonctions qui liaient le protocole à la requête, et un code spécifique était nécessaire pour gérer chaque protocole et procédure d’échange différents. Le transfert de données uniforme représente tous les transferts de données à l’aide de l’interface IDataObject , qui sépare les opérations d’échange de données courantes du protocole de transfert.

L’interface IDataObject encapsule les opérations d’obtention et de définition standard sur les données, les requêtes et les énumérations et les notifications qui détectent quand les données changent dans un objet. Le transfert uniforme de données permet des descriptions détaillées des formats de données, ainsi que l’utilisation de différents supports de stockage pour le transfert de données.

Pendant le transfert de données uniformes, tous les protocoles échangent un pointeur vers une interface IDataObject . Le serveur est la source des données et implémente un objet de données utilisable dans n’importe quel protocole d’échange de données. Le client consomme les données et demande des données à partir d’un objet de données lorsqu’il reçoit un pointeur IDataObject de n’importe quel protocole. Une fois l’échange de pointeur effectué, les deux côtés gèrent l’échange de données de manière uniforme, via l’interface IDataObject .

COM définit deux structures de données qui permettent un transfert de données uniforme. La structure FORMATETC représente un format de Presse-papiers généralisé et la structure STGMEDIUM représente le support de transfert en tant que handle de mémoire.

Le client crée une structure FORMATETC pour indiquer le type de données qu’il demande à une source de données, et elle est utilisée par la source de données pour décrire les formats qu’elle fournit. Le client interroge une source de données pour connaître ses formats disponibles en demandant son interface IEnumFORMATETC . Pour plus d’informations, consultez La structure FORMATETC.

Le client crée une structure STGMEDIUM et la transmet à la méthode GetData , et l’objet de données retourne les données dans la structure STGMEDIUM fournie.

La structure STGMEDIUM permet aux clients et aux sources de données de choisir le support d’échange le plus efficace. Par exemple, si les données à échanger sont très volumineuses, la source de données peut indiquer un support sur disque comme format préféré, au lieu de main mémoire. Cette flexibilité permet des échanges de données efficaces qui peuvent être aussi rapides que le passage d’un pointeur vers un IStorage ou un IStream. Pour plus d’informations, consultez La structure STGMEDIUM.

Un client d’une source de données peut nécessiter une notification lorsque les données changent. COM gère les notifications de modification de données à l’aide d’un objet récepteur de conseil , qui implémente l’interface IAdviseSink . L’objet récepteur advise et l’interface IAdviseSink sont implémentés par le client, qui transmet un pointeur IAdviseSink à la source de données. Lorsque la source de données détecte une modification dans les données sous-jacentes, elle appelle une méthode IAdviseSink pour avertir le client. Pour plus d’informations, consultez Notification de données.

Communication à distance

COM active le calcul distant et distribué. La communication à distance d’interface permet à une fonction membre de retourner un pointeur d’interface vers un objet COM qui se trouve dans un processus différent ou sur un autre ordinateur hôte. L’infrastructure qui effectue la communication à distance de l’interface est transparente pour le client et le serveur d’objets. Ni le client ni le serveur n’ont besoin des détails de déploiement de l’autre pour communiquer via une interface distante. Un client appelle des fonctions membres sur la même interface pour communiquer avec un objet COM in-process, out-of-process sur l’hôte local ou sur un ordinateur distant. Les appels locaux et distants sur la même interface ne sont pas reconnaissables pour le client.

Pour communiquer avec un objet COM, un client appelle toujours une implémentation in-process. Si l’objet COM est en cours, l’appel est direct. Si l’objet COM est hors processus ou distant, COM fournit une implémentation de proxy qui transfère l’appel à l’objet à l’aide du protocole RPC (Remote Procedure Call).

Un objet COM reçoit toujours des appels d’un client via une implémentation in-process. Si l’appelant est en cours, l’appel est direct. Si l’appelant est hors processus ou distant, COM fournit une implémentation stub qui reçoit l’appel de procédure distante du proxy dans le processus client.

Le marshaling est la procédure d’empaquetage de la pile des appels pour la transmission du proxy au stub. Le démarshalage est le déballage qui se produit à l’extrémité de réception. Les valeurs de retour sont marshalées et non délimitées du stub vers le proxy. Ce type de communication est également appelé « envoi d’un appel sur le réseau ».

Chaque type de données différent a des règles pour le marshaling. Les pointeurs d’interface ont également un protocole de marshaling, qui est encapsulé dans la fonction CoMarshalInterface . Dans la plupart des cas, le marshaling d’interface standard, qui est fourni par le système, est suffisant, mais un objet COM peut éventuellement implémenter le marshaling d’interface personnalisé pour contrôler la création de proxys d’objets distants vers lui-même. Pour plus d’informations, consultez Communication inter-objets.

Sécurité

COM fournit deux formes de sécurité d’application. L’un d’eux est la sécurité d’activation, qui spécifie comment les nouveaux objets sont créés, comment les clients se connectent aux objets nouveaux et existants, et comment certains services publics, tels que la table de classes et la table d’objets en cours d’exécution, sont sécurisés. L’autre est la sécurité d’appel, qui spécifie le fonctionnement de la sécurité dans une connexion établie entre un client et un objet COM.

La sécurité d’activation est appliquée automatiquement par le Gestionnaire de contrôle des services (SCM). Lorsque le SCM reçoit une demande de récupération d’un objet COM, il vérifie la demande par rapport aux informations de sécurité stockées dans le Registre.

Les implémentations SCM offrent généralement une configuration basée sur le Registre pour l’administration des classes déployées et pour des comptes d’utilisateur spécifiques sur l’hôte. Pour plus d’informations, consultez Sécurité d’activation.

La sécurité des appels est appliquée automatiquement ou est appliquée par l’application. Si l’application fournit des informations d’installation, COM effectue les vérifications nécessaires pour sécuriser l’application.

Le mécanisme automatique vérifie la sécurité du processus, mais pas des objets ou des méthodes individuels. Si une application nécessite une sécurité plus fine, COM fournit des fonctions que les applications peuvent utiliser pour effectuer leur propre vérification de sécurité.

Les mécanismes automatiques et personnalisés peuvent être utilisés ensemble, de sorte qu’une application peut demander à COM d’effectuer une vérification de sécurité automatique, puis d’effectuer ses propres opérations.

Les services de sécurité des appels COM sont divisés en catégories suivantes :

  • Fonctions générales appelées à la fois par les clients et les serveurs, qui permettent d’initialiser le mécanisme de sécurité automatique et d’inscrire les services d’authentification automatique. Les API de sécurité d’appel général sont les fonctions CoInitializeSecurity et CoQueryAuthenticationServices .
  • Interfaces sur les proxys clients, qui permettent au client de contrôler la sécurité sur les appels à des interfaces individuelles. L’interface IClientSecurity et les fonctions CoQueryProxyBlanket, CoSetProxyBlanket et CoCopyProxy assurent la sécurité des appels sur un objet distant.
  • Fonctions côté serveur et interfaces de contexte d’appel, qui permettent au serveur de récupérer des informations de sécurité sur un appel et d’emprunter l’identité de l’appelant. L’interface IServerSecurity et les fonctions CoGetCallContext, CoImpersonateClient et CoRevertToSelf assurent la sécurité des appels côté serveur.

Souvent, le client interroge l’objet COM pour l’interface IClientSecurity , qui est implémentée localement par la couche de communication à distance. Le client utilise cette interface pour contrôler la sécurité des proxys d’interface individuels sur l’objet COM avant d’effectuer un appel sur l’une des interfaces.

Lorsqu’un appel arrive sur le serveur, le serveur peut appeler la fonction CoGetCallContext pour récupérer une interface IServerSecurity, ce qui permet au serveur d’case activée l’authentification du client et d’emprunter l’identité du client, si nécessaire. L’objet IServerSecurity est valide pendant la durée de l’appel.

Appelez la fonction CoInitializeSecurity pour initialiser la couche de sécurité et définissez les valeurs spécifiées comme sécurité par défaut. Si un processus n’appelle pas CoInitializeSecurity, COM l’appelle automatiquement la première fois qu’une interface est marshalée ou non délimitée, en inscrivant la sécurité par défaut du système. La fonction CoInitializeSecurity permet au client d’établir la sécurité d’appel par défaut pour le processus, ce qui évite l’utilisation d’IClientSecurity sur des proxys individuels. La fonction CoInitializeSecurity permet à un serveur d’inscrire des services d’authentification automatique pour le processus. Pour plus d’informations, consultez Définition de la sécurité Process-Wide avec CoInitializeSecurity.

Clients et serveurs COM

Définition d’interfaces COM

Inscription d’applications COM

Sécurité dans COM

Processus, threads et appartements