Développement d'applications COM

Remonter à Développement d'applications interopérables à l'aide de COM

Delphi fournit des experts et des classes qui facilitent l'implémentation d'applications basées sur COM (Component Object Model) de Microsoft. Grâce à ces experts, vous pouvez créer des classes et des composants basés sur COM que vous utiliserez dans des applications, ou vous pouvez créer des clients et des serveurs COM complètement fonctionnels qui implémentent des objets COM sophistiqués, des serveurs Automation (y compris, des objets Active Server), des contrôles ActiveX ou des fiches ActiveForms.

Cette rubrique aborde les thèmes suivants :

• Présentation des technologies COM
• Interfaces COM
• Serveurs COM
• Clients COM

Présentation des technologies COM

COM est un modèle de composant logiciel indépendant du langage qui permet l'interaction entre des composants logiciels et des applications s'exécutant sous Windows. L'aspect le plus important de COM est de permettre la communication entre composants, entre applications et entre clients et serveurs, par le biais d'interfaces clairement définies. Les interfaces offrent aux clients un moyen de demander à un composant COM quelles fonctionnalités il prend en charge à l'exécution. Pour fournir d'autres fonctionnalités à votre composant, il suffit d'ajouter une autre interface pour ces fonctionnalités.

Les applications peuvent accéder aux interfaces des composants COM se trouvant sur le même ordinateur que l'application ou sur un autre ordinateur du réseau, en utilisant un mécanisme nommé DCOM (Distributed COM).

COM est à la fois une spécification et une implémentation. La spécification COM définit comment des objets sont créés et comment ils communiquent entre eux. Selon cette spécification, les objets COM peuvent être écrits dans différents langages, exécutés dans différents espaces de processus et sur différentes plates-formes. Tant que les objets se conforment à la spécification, ils peuvent communiquer. Cela vous permet d'intégrer le code de composants existants à de nouveaux composants implémentés dans des langages orientés objet.

L'implémentation COM est construite dans le sous-système Win32, qui fournit de nombreux services intégrés prenant en charge la spécification. La bibliothèque COM contient un ensemble d'interfaces standard définissant la fonctionnalité interne d'un objet COM et un petit ensemble de fonctions API pour la création et la gestion des objets COM.

Lorsque vous utilisez dans votre application les experts de Delphi et les objets de la VCL, vous utilisez l'implémentation Delphi de la spécification COM. En outre, Delphi fournit quelques enveloppes pour les services COM dont les fonctionnalités ne sont pas implémentées directement, comme les documents Active. Ces enveloppes sont définies dans l'unité ComObj, et les définitions d'API se trouvent dans l'unité AxCtrls.

Remarque : Les objets et les langages des interfaces Delphi ont conformes à la spécification COM. L'implémentation Delphi de la spécification COM utilise un ensemble de classes appelé cadre de travail Delphi ActiveX (DAX). Ces classes se trouvent dans les unités AxCtrls, OleCtrls et OleServer. En outre, l'interface Delphi avec l'API COM se trouve dans ActiveX.pas et ComSvcs.pas.

Interfaces COM

Les clients COM communiquent avec des objets par le biais d'interfaces COM. Les interfaces sont des groupes de routines, liées par la logique ou par la sémantique, qui assurent la communication entre le fournisseur d'un service (objet serveur) et ses clients.

Par exemple, tout objet COM doit implémenter l'interface de base, IUnknown. Via une routine appelée QueryInterface de IUnknown, les clients peut demander les autres interfaces implémentées par le serveur.

Les objets peuvent avoir plusieurs interfaces, où chacune implémente une fonctionnalité. L'interface est le moyen d'indiquer au client le service fourni par l'objet, sans lui donner les détails de l'implémentation sur la façon dont ce service est fourni.

Les aspects majeurs des interfaces COM sont les suivants :

• Une fois publiées, les interfaces ne changent pas. Une interface permet d'accéder à un ensemble précis de fonctions. Les fonctionnalités supplémentaires sont fournies par le biais d'interfaces supplémentaires.
• Par convention, les identificateurs d'interfaces COM commencent par un I majuscule suivi d'un nom symbolique définissant l'interface, comme IMalloc or IPersist.
• L'identification unique des interfaces est garantie par un GUID (Globally Unique Identifier), qui est un nombre aléatoire de 128 bits. Les GUID utilisés pour identifier les interfaces sont appelés IID (Identificateurs d'interfaces). Ils permettent d'éliminer les conflits de noms entre différentes versions d'un produit ou différents produits.
• Les interfaces sont indépendantes du langage. Vous pouvez utiliser n'importe quel langage pour implémenter une interface COM, à condition que ce langage prenne en charge les structures de pointeurs et puisse appeler une fonction via un pointeur, de façon explicite ou implicite.
• Les interfaces ne sont pas elles-mêmes des objets ; elles fournissent l'accès à un objet. Donc, les clients n'ont pas accès directement aux données ; ils accèdent aux données par le biais d'un pointeur d'interface. Windows 2000 ajoute une autre couche d'indirection, connue sous le nom d'intercepteur, à partir duquel il fournit des fonctionnalités COM+ telles que l'activation just-in-time et le regroupement d'objets.
• Les interfaces sont toujours héritées de l'interface de base, IUnknown.
• Les interfaces peuvent être redirigées par COM via des proxy pour permettre aux appels de méthodes de l'interface de s'effectuer entre différents threads, processus et machines en réseau, sans que les objets client ou serveur ne soient jamais informés de la redirection.

L'interface IUnknown

Les objets COM doivent tous prendre en charge l'interface fondamentale, appelée IUnknown qui représente un typedef sur le type d'interface de base IInterface. IUnknown contient les routines suivantes :

• QueryInterface: Fournit des pointeurs sur d'autres interfaces prises en charge par l'objet.
• AddRef et Release : Méthodes simples de décompte de références qui permettent à un objet de contrôler sa durée de vie et de se supprimer lui-même lorsque le client n'a plus besoin de son service.

Les clients obtiennent des pointeurs sur d'autres interfaces via la méthode QueryInterface de IUnknown. QueryInterface connaît chaque interface de l'objet serveur et peut donner au client un pointeur vers l'interface demandée. Lorsqu'il reçoit un pointeur vers une interface, le client est assuré de pouvoir appeler n'importe quelle méthode de l'interface.

Les objets contrôlent leur propre durée de vie grâce aux méthodes AddRef et Release de IUnknown, qui sont de simples méthodes de décompte de références. Tant que le décompte de références d'un objet est différent de zéro, l'objet reste en mémoire. Dès qu'il atteint zéro, l'implémentation de l'interface peut en toute sécurité disposer des objets sous-jacents.

Pointeurs d'interface COM

Un pointeur d'interface est un pointeur vers une instance d'objet qui pointe, à son tour, vers l'implémentation de chaque méthode de l'interface. L'implémentation est accédée via un tableau de pointeurs vers ces méthodes, appelé vtable. Les vtables sont similaires au mécanisme utilisé pour gérer les fonctions virtuelles sous Delphi. A cause de cette similitude, le compilateur peut résoudre les appels de méthode de l'interface de la même manière qu'il résout les appels des méthodes de classes Delphi.

La vtable est partagée par toutes les instances d'une classe objet, et pour chaque instance de l'objet, le code de l'objet alloue une deuxième structure contenant ses données privées. Le pointeur d'interface du client est alors un pointeur sur le pointeur sur la vtable.

Dans Windows 2000 et toutes les versions ultérieures de Windows, quand un objet s'exécute sous COM+, un autre niveau d'indirection est fourni entre le pointeur d'interface et le pointeur vtable. Le pointeur d'interface disponible sur le client pointe sur un intercepteur, qui à son tour pointe sur la vtable. Cela permet à COM+ de fournir des services comme l'activation just-in-time, par lequel le serveur peut être désactivé et réactivé dynamiquement d'une façon opaque pour le client. COM+ garantit que l'intercepteur se comporte comme s'il était un pointeur vtable ordinaire.

Serveurs COM

Un serveur COM est une application ou une bibliothèque qui fournit des services à une application ou bibliothèque client. Un serveur COM est constitué d'un ou de plusieurs objets COM, un objet COM étant un ensemble de propriétés (données membre ou contenu) et de méthodes (fonctions membre).

Les clients ne savent pas comment l'objet COM effectue son service ; l'implémentation de l'objet reste cachée. Un objet met ses services à disposition par le biais de ses interfaces comme décrit précédemment.

En outre, les clients n'ont pas besoin de savoir où réside l'objet COM. COM offre un accès transparent, quel que soit l'emplacement de l'objet.

Quand il demande un service à un objet COM, le client transmet un identificateur de classe (CLSID) à COM. Un CLSID est juste un GUID qui référence un objet COM. COM utilise ce CLSID, recensé dans le registre système, pour localiser l'implémentation appropriée du serveur. Une fois le serveur localisé, COM amène le code en mémoire, et fait créer par le serveur une instance de l'objet pour le client. Ce processus est géré indirectement par un objet spécial appelé une factory (basé sur les interfaces) qui crée sur demande des instances d'objet.

Au minimum, un serveur COM doit effectuer ceci :

• Recenser des entrées dans le registre système pour associer le module serveur à l'identificateur de classe (CLSID).
• Implémenter un objet factory de classe, qui crée un autre objet à partir d'un CLSID particulier.
• Exposer la factory d'objet à COM.
• Fournir un mécanisme de déchargement grâce auquel un serveur qui ne sert pas de client pourra être supprimé de la mémoire.

Clients COM

Les clients COM sont des applications qui utilisent un objet COM implémenté par une autre application ou bibliothèque. Les types les plus courants sont les contrôleurs Automation, qui contrôlent un serveur Automation et les conteneurs ActiveX, qui accueillent un contrôle ActiveX.

Il y a deux types de clients COM : les contrôleurs et les conteneurs. Un contrôleur lance le serveur et interagit avec lui via son interface. Il demande des services de l'objet COM ou il le pilote comme processus distinct. Les conteneurs accueillent des contrôles visuels ou des objets qui apparaissent dans l'interface utilisateur du conteneur. Ils utilisent des interfaces prédéfinies pour négocier les problèmes d'affichage avec les objets serveur. Il est impossible d'avoir une relation conteneur sur DCOM ; par exemple, les contrôles visuels qui apparaissent dans l'interface utilisateur du conteneur doivent être localisés localement. En effet, les contrôles sont supposés se dessiner eux-mêmes, ce qui nécessite qu'ils puissent accéder aux ressources GDI locales.

La réalisation de ces deux types de clients COM est étonnamment similaire : l'application client obtient une interface pour l'objet serveur et en utilise les propriétés et méthodes. Delphi facilite le développement d'un contrôleur Automation en permettant d'importer la bibliothèque de types ou un contrôle ActiveX dans un composant enveloppe de telle manière que les objets serveur apparaissent comme les autres composants VCL. Delphi vous permet d'envelopper la CoClass serveur dans un composant du client que vous pouvez même installer sur la palette des composants. Vous trouverez des exemples de ces enveloppes de composants sur deux pages de la palette des composants, des exemples d'enveloppes ActiveX sur la page ActiveX et des exemples d'objets Automation sur la page Serveurs.

Même si vous ne choisissez pas d'envelopper un objet serveur et de l'installer dans la palette des composants, vous devez rendre sa définition d'interface accessible à votre application. Pour ce faire, vous pouvez importer les informations de la bibliothèque de types du serveur.

Les clients peuvent toujours interroger les interfaces d'un objet COM pour déterminer ce qu'il est capable de faire. Tous les objets COM permettent aux clients de demander les interfaces connues. De plus, si le serveur gère l'interface IDispatch, les clients peuvent demander au serveur des informations sur les méthodes gérées par le serveur. Les objets serveurs n'ont pas d'attentes concernant l'utilisation de ses objets par le client. De même, les clients n'ont pas besoin de savoir comment un objet fournit les services ; ils s'en remettent simplement sur les objets serveurs pour fournir les services qu'ils décrivent dans leurs interfaces.

Extensions de COM

COM a évolué et a été étendu au-delà des services COM de base. COM sert de fondement à d'autres technologies, comme l'Automation, les contrôles ActiveX, les documents Active et les annuaires Active. En outre, si vous travaillez dans un environnement distribué important, vous pouvez créer des objets COM transactionnels. Avant Windows 2000, ces objets ne faisaient pas partie de COM, mais s'exécutaient dans l'environnement Microsoft Transaction Server (MTS). Avec l'arrivée de Windows 2000, cette gestion est intégrée dans COM+. Delphi fournit des experts permettant d'implémenter facilement des applications qui utilisent toutes ces technologies dans l'environnement Delphi.

Serveurs Automation

L'Automation désigne la capacité d'une application à contrôler par programme les objets d'une autre application, comme une macro qui peut manipuler plusieurs applications à la fois. Le client d'un objet Automation est appelé contrôleur Automation, et l'objet serveur manipulé est appelé objet Automation. L'Automation peut être utilisée sur des serveurs en processus, locaux ou distants.

L'Automation présente deux caractéristiques principales :

• L'objet Automation définit un ensemble de propriétés et de commandes, et décrit ses capacités via les descriptions de type. Pour ce faire, il doit disposer d'un moyen de fournir des informations sur les interfaces de l'objet, les méthodes des interfaces et les arguments de ces méthodes. Généralement, ces informations se trouvent dans des bibliothèques de types. Le serveur Automation peut aussi générer dynamiquement des informations de types lorsqu'elles lui sont demandées via son interface IDispatch.
• Les objets Automation rendent ces méthodes accessibles pour que d'autres applications puissent les utiliser. Pour cela, ils implémentent l'interface IDispatch. C'est par le biais de cette interface qu'un objet peut exposer toutes ses méthodes et propriétés. Et c'est par le biais de la méthode primaire de cette interface que les méthodes de l'objet peuvent être appelées, une fois qu'elles ont été identifiées grâce aux informations de type.

Les développeurs utilisent souvent l'Automation pour créer et utiliser des objets OLE non visuels qui s'exécutent dans n'importe quel espace processus, car l'interface Automation IDispatch automatise le processus de marshaling. En revanche, l'Automation limite les types que vous pouvez utiliser.

Contrôles Active X

Les experts de Delphi facilitent la création des contrôles ActiveX. ActiveX est une technologie qui permet aux composants COM, particulièrement aux contrôles, d'être plus compacts et efficaces. Cela est particulièrement important pour les contrôles conçus pour des applications Intranet qui nécessitent leur téléchargement par le client avant de les utiliser.

Les contrôles ActiveX sont des contrôles visuels qui s'exécutent uniquement comme des serveurs en processus et qui peuvent s'intégrer dans une application conteneur ActiveX. Ce ne sont pas des applications complètes par eux-mêmes, vous pouvez les voir comme des contrôles OLE déjà écrits qui sont réutilisables dans diverses applications. Les contrôles ActiveX ont une interface utilisateur apparente et reposent sur l'utilisation d'interfaces prédéfinies pour négocier les entrées/sorties et les questions d'affichage avec le conteneur hôte.

Les contrôles ActiveX utilisent l'Automation pour exposer leurs propriétés, méthodes et événements. Leurs fonctionnalités incluent la capacité à déclencher des événements, la liaison aux sources de données et la gestion de licence.

Les contrôles ActiveX s'utilisent parfois dans un site Web comme objets interactifs placés dans une page Web. Ainsi, ActiveX est devenu un standard particulièrement destiné à des contenus interactifs pour le Web, y compris l'utilisation de documents ActiveX employés pour visualiser des documents non HTML via un navigateur Web. Pour plus d'informations sur la technologie ActiveX, voir le site Web de Microsoft.

Documents Active

Les Documents Active (préalablement appelés documents OLE) constituent un ensemble de services COM prenant en charge la liaison et l'incorporation, le glisser-déplacer, ainsi que l'édition visuelle. Les documents Active intègrent de façon transparente des données ou des objets de différents formats, par exemple des clips sonores, des feuilles de calcul, du texte et des images.

Au contraire des contrôles ActiveX, les Documents Active ne sont pas limités aux serveurs en processus; ils peuvent être utilisés dans des applications inter-processus.

Au contraire des objets Automation, qui ne sont presque jamais visuels, les objets Document Active peuvent être visuellement actifs dans une autre application. De ce fait, les objets Document Active sont associés à deux types de données : les données de présentation, utilisées pour afficher visuellement l'objet sur un écran ou un autre périphérique de sortie, et les données natives, utilisées pour modifier un objet.

Les objets document Active peuvent être des conteneurs ou des serveurs de documents. Bien que Delphi ne fournisse pas d'expert pour créer automatiquement des documents Active, vous pouvez utiliser la classe Vcl.OleCtnrs.TOleContainer de la VCL pour prendre en charge la liaison et l'incorporation dans les documents Active existants.

Vous pouvez aussi utiliser Vcl.OleCtnrs.TOleContainer comme base d'un conteneur de document Active. Pour créer des objets pour les serveurs de documents Active, utilisez une des classes de base COM de la VCL et implémentez les interfaces appropriées à ce type d'objet, en fonction des services que l'objet doit gérer. Pour plus d'informations sur la création et l'utilisation de serveurs de documents Active, voir le site Web Microsoft.

Remarque :  Bien que la spécification des documents Active contienne une gestion intégrée du marshaling des applications à processus croisé, les documents Active ne s'exécutent pas sur des serveurs distants car les types qu'ils utilisent (handles de fenêtre, de menu, etc.) sont spécifiques à un système sur une machine donnée.

Objets transactionnels

Delphi utilise le terme "objets transactionnels" pour désigner des objets qui exploitent les services de transaction, la sécurité et la gestion des ressources proposées par MTS (pour les versions de Windows antérieures à Windows 2000) ou COM+ (pour Windows 2000 et plus). Ces objets sont conçus pour travailler dans des environnements distribués importants.

Les services de transaction garantissent la fiabilité assurant que des activités sont toujours achevées ou annulées. Le serveur ne s'arrête jamais en ayant fait la moitié d'une activité. Les services de sécurité vous permettent d'exposer différents niveaux de services à différentes classes de clients. La gestion des ressources permet à un objet de répondre à davantage de clients en regroupant les ressources et en ne gardant des objets actifs que s'ils sont utilisés. Pour permettre au système de proposer ces services, l'objet doit implémenter l'interface IObjectControl. Pour accéder aux services, les objets transactionnels utilisent une interface appelée IObjectContext qui est créée pour eux par MTS ou COM+.

Avec MTS, l'objet serveur doit être conçu dans une bibliothèque DLL qui est installée dans l'environnement d'exécution MTS. C'est-à-dire que l'objet serveur est un serveur en processus qui s'exécute dans l'espace de processus d'exécution MTS. Avec COM+, cette restriction ne s'applique plus car tous les appels COM sont redirigés par un intercepteur. Pour les clients, les différences entre MTS et COM+ sont transparentes.

Les serveurs MTS ou COM+ rassemblent les objets transactionnels dans le même espace de processus. Dans MTS, ce groupe est appelé un package MTS, alors que dans COM+ il est appelé application COM+. Une même machine peut exécuter plusieurs packages MTS (ou applications COM+), chacun s'exécutant dans son propre espace de processus.

Pour les clients, les objets transactionnels apparaissent semblables aux autres objets serveur COM. Le client n'a pas besoin de savoir quoi que ce soit sur les transactions, la sécurité ou l'activation just-in-time, sauf s'il démarre lui-même une transaction.

MTS et COM+ proposent un outil distinct pour administrer les objets transactionnels. Cet outil vous permet de configurer les objets des packages ou des applications COM+, de visualiser les packages ou les applications COM+ installés dans une machine ou de modifier les attributs des objets, surveiller et gérer les transactions, mettre des objets à la disposition des clients, etc. Dans MTS, cet outil s'appelle explorateur MTS. Dans COM+ c'est le gestionnaire de composants COM+.

Bibliothèques de types

Les bibliothèques de types offrent un moyen d'obtenir davantage d'informations de type sur un objet que les interfaces de l'objet. Les bibliothèques de types contiennent les informations nécessaires sur les objets et leurs interfaces, comme les interfaces associées à tels objets (étant donné le CLSID), les fonctions membre de chaque interface et les arguments requis par ces fonctions.

Vous pouvez obtenir les informations de type en interrogeant une instance d'un objet pendant qu'elle s'exécute ou, en chargeant et en lisant les bibliothèques de types. Grâce à ces informations, vous pouvez implémenter un client qui utilise un objet souhaité, en sachant exactement les fonctions membre dont vous avez besoin, et ce qu'il faut passer à ces fonctions.

Les clients des serveurs Automation, les contrôles ActiveX et les objets transactionnels ont besoin des informations de type. Tous les experts Delphi génèrent automatiquement une bibliothèque de types (même si c'est facultatif avec l'expert objet COM). Vous pouvez visualiser et modifier ces informations de types en utilisant l'éditeur de bibliothèque de types.

Voir aussi

• Utilisation des experts COM