Modèle d'objet de composant

Component Object Model ( COM ) est une technologie d'interface binaire pour les composants logiciels de Microsoft qui permet d'utiliser des objets de manière neutre entre différents langages de programmation , contextes de programmation, processus et machines .

COM est la base d'autres technologies de composants spécifiques au domaine Microsoft, notamment OLE , OLE Automation , ActiveX , COM+ et DCOM, ainsi que des implémentations telles que DirectX , Windows Shell , UMDF , Windows Runtime et Browser Helper Object .

COM permet d'utiliser un objet en connaissant uniquement son interface, et non son implémentation interne. L'implémenteur de composant définit des interfaces distinctes de l'implémentation.

La prise en charge de contextes de programmation multiples est gérée en s'appuyant sur l'objet pour des aspects qui seraient difficiles à implémenter en tant que fonctionnalité. La prise en charge de plusieurs utilisations d'un objet est gérée en exigeant que chaque objet s'autodétruise via le comptage de références . L'accès aux interfaces d'un objet (similaire à la conversion de type ) est également fourni par chaque objet.

COM est disponible uniquement dans Microsoft Windows et dans l'interface de programmation d'applications plug-in (API) Core Foundation 1.3 et versions ultérieures d'Apple . Cette dernière implémente uniquement un sous-ensemble de l'interface COM dans son ensemble.

Au fil du temps, COM est remplacé par d'autres technologies telles que Microsoft .NET et les services Web (via WCF ). Cependant, les objets COM peuvent être utilisés dans un langage .NET via COM Interop .

COM est similaire à d’autres technologies de composants telles que SOM , CORBA et Enterprise JavaBeans , bien que chacun ait ses forces et ses faiblesses.

Contrairement à C++ , COM fournit une interface binaire d'application (ABI) stable qui n'est pas affectée par les différences de compilateur. Cela rend l'utilisation de COM avantageuse pour les bibliothèques C++ orientées objet qui doivent être utilisées par des clients compilés via différents compilateurs.

Introduit en 1987, Dynamic Data Exchange (DDE) était l'une des premières technologies de communication interprocessus dans Windows . des conversations dites entre applications.

Antony Williams, impliqué dans l'architecture de COM, a distribué deux articles au sein de Microsoft qui adoptaient le concept de composants logiciels : Object Architecture: Dealing With the Unknown – or – Type Safety in a Dynamically Extensible Class Library en 1988 et On Inheritance: What It Means and How To Use It en 1990. Ces articles ont fourni la base de nombreuses idées à l'origine de COM.

Object Linking and Embedding (OLE), le premier framework basé sur les objets de Microsoft, a été construit sur DDE et conçu spécifiquement pour les documents composés . Il a été introduit avec Word et Excel en 1991, et a ensuite été inclus dans Windows, à partir de la version 3.1 en 1992. Un exemple de document composé est une feuille de calcul incorporée dans un document Word. Lorsque des modifications sont apportées à la feuille de calcul dans Excel, elles apparaissent automatiquement dans le document Word.

En 1991, Microsoft a introduit la technologie Visual Basic Extension (VBX) avec Visual Basic 1.0. Un VBX est une extension packagée sous la forme d'une bibliothèque de liens dynamiques (DLL) qui permet de placer graphiquement des objets dans un formulaire et de les manipuler à l'aide de propriétés et de méthodes . Ces dernières ont ensuite été adaptées pour être utilisées par d'autres langages tels que Visual C++ .

En 1992, avec Windows 3.1 , Microsoft a publié OLE 2 avec son nouveau modèle objet sous-jacent , COM. L' interface binaire d'application (ABI) COM était la même que l'ABI MAPI (sortie en 1992), et comme elle était basée sur MSRPC et finalement sur DCE/RPC de l' Open Group . COM a été créé pour remplacer DDE car sa conception de conversation textuelle et de messagerie Windows n'était pas suffisamment flexible pour permettre le partage de fonctionnalités d'application de manière robuste et extensible.

En 1994, la technologie de contrôle personnalisé OLE (OCX), basée sur COM, a été introduite comme successeur de VBX. Au même moment, Microsoft a déclaré que OLE 2 serait simplement connu sous le nom de « OLE ».

Début 1996, Microsoft a trouvé une nouvelle utilisation pour OCX : étendre les capacités de son navigateur Web. Microsoft a renommé certaines parties d'OLE liées à Internet en ActiveX et a progressivement renommé toutes les technologies OLE en ActiveX, à l'exception de la technologie de document composé utilisée dans Microsoft Office .

Plus tard en 1996, Microsoft a étendu COM pour fonctionner sur le réseau avec DCOM .

Le langage IDL COM est basé sur le langage IDL DCE/RPC riche en fonctionnalités, avec des extensions orientées objet. L'implémentation de DCE/RPC par Microsoft, MSRPC , est utilisée comme mécanisme de communication interprocessus principal pour les services et les composants internes de Windows NT, ce qui en fait un choix évident de base.

DCOM étend COM de la simple prise en charge d'un utilisateur unique avec des applications distinctes communiquant sur le bureau Windows à l'activation d'objets exécutés dans des contextes de sécurité différents et sur différentes machines du réseau. Avec cela, des fonctionnalités nécessaires ont été ajoutées pour configurer les utilisateurs autorisés à créer, activer et appeler des objets, pour identifier l'utilisateur appelant, ainsi que pour spécifier le cryptage requis pour la sécurité des appels.

Microsoft a introduit Microsoft Transaction Server (MTS) dans Windows NT 4 afin de fournir aux développeurs un support pour les transactions distribuées , la mise en commun des ressources, les applications déconnectées, la publication et l'abonnement d'événements, une meilleure gestion de la mémoire et du processeur (thread), ainsi que pour positionner Windows comme une alternative aux autres systèmes d'exploitation de niveau entreprise.

Rebaptisé COM+ dans Windows 2000, cet ensemble de fonctionnalités a été intégré au système d'exploitation, contrairement à la série d'outils externes fournis par MTS. Dans le même temps, Microsoft a réduit l'importance de DCOM en tant qu'entité distincte. Les composants qui utilisaient COM+ étaient gérés plus directement par la couche supplémentaire de COM+, en particulier par la prise en charge de l'interception par le système d'exploitation. Dans la première version de MTS, l'interception a été ajoutée : l'installation d'un composant MTS modifiait le registre Windows pour appeler le logiciel MTS, et non le composant directement.

Windows 2000 inclut des mises à jour du panneau de configuration des services de composants pour la configuration des composants COM+.

L'un des avantages de COM+ était qu'il pouvait être exécuté dans des « fermes de composants ». Les instances d'un composant, si elles étaient correctement codées, pouvaient être regroupées et réutilisées par de nouveaux appels à sa routine d'initialisation sans le décharger de la mémoire. Les composants pouvaient également être distribués (appelés depuis une autre machine). COM+ et Microsoft Visual Studio fournissaient des outils pour faciliter la génération de proxys côté client. Ainsi, bien que DCOM ait été utilisé pour effectuer l'appel à distance, il était facile à réaliser pour les développeurs. COM+ a également introduit un mécanisme d'événement abonné/éditeur appelé COM+ Events et a fourni une nouvelle façon d'exploiter MSMQ (une technologie qui fournit une messagerie asynchrone inter-applications) avec des composants appelés Queued Components . Les événements COM+ étendent le modèle de programmation COM+ pour prendre en charge les événements à liaison tardive (voir Late binding ) ou les appels de méthode entre l'éditeur ou l'abonné et le système d'événements.

.NET est la technologie de composants de Microsoft qui remplace COM. .NET masque de nombreux détails de la création de composants et facilite donc le développement.

.NET fournit des wrappers pour les contrôles COM couramment utilisés.

.NET peut exploiter COM+ via l' System.EnterpriseServicesespace de noms, et plusieurs des services fournis par COM+ ont été dupliqués dans .NET. Par exemple, l' System.Transactionsespace de noms fournit la TransactionScopeclasse, qui assure la gestion des transactions sans recourir à COM+. De même, les composants en file d'attente peuvent être remplacés par Windows Communication Foundation (WCF) avec un transport MSMQ .

La compatibilité descendante est limitée. Un objet COM peut être utilisé dans .NET en implémentant un wrapper appelable au moment de l'exécution (RCW). Les objets .NET conformes à certaines restrictions d'interface peuvent être utilisés dans des objets COM en appelant un wrapper appelable COM (CCW). Du côté COM comme du côté .NET, les objets utilisant l'autre technologie apparaissent comme des objets natifs. Voir COM Interop .

WCF simplifie un certain nombre de problèmes d'exécution à distance de COM. Par exemple, il permet de regrouper les objets de manière transparente par valeur au-delà des limites des processus ou des machines, plus facilement.

Windows Runtime ( WinRT ) est une API basée sur COM, bien qu'il s'agisse d'une variante COM améliorée. En raison de sa base de type COM, WinRT prend en charge l'interfaçage à partir de plusieurs contextes de programmation, mais il s'agit d'une API native non gérée. Les définitions d'API sont stockées dans des fichiers « .winmd », qui sont codés au format de métadonnées ECMA 335 ; le même format de métadonnées CLI que celui utilisé par .NET avec quelques modifications. Ce format de métadonnées permet une surcharge considérablement inférieure à celle de P/Invoke lorsque WinRT est invoqué à partir d'applications .NET.

Nano-COM est un sous-ensemble de COM axé sur les aspects d' interface binaire d'application (ABI) de COM qui permettent des appels de fonctions et de méthodes sur des modules/composants compilés indépendamment. Nano-COM peut être exprimé dans un fichier d'en-tête C++ portable. Nano-COM étend l'ABI native de l'architecture d'instructions sous-jacente et du système d'exploitation pour prendre en charge les références d'objet typées, tandis qu'une ABI typique se concentre sur les types atomiques, les structures, les tableaux et les conventions d'appel de fonctions.

Un fichier d'en-tête Nano-COM définit ou nomme au moins trois types :

• GUID – identifie un type d’interface

• HRESULT – codes de résultat de méthode tels que S_OK, E_FAIL, E_OUTOFMEMORY

• IUnknown – type de base pour les références d'objets ; fonctions virtuelles abstraites pour prendre en charge dynamic_cast<T>l'acquisition de nouveaux types d'interfaces et le comptage de références à la manière de IUnknownshared_ptr<T>

De nombreuses utilisations de Nano-COM définissent deux fonctions pour adresser les tampons de mémoire alloués à l'appelé comme résultats :

• <NanoCom>Alloc – appelé par les implémentations de méthodes pour allouer des tampons bruts (pas des objets) qui sont renvoyés à l'appelant

• <NanoCom>Free – appelé par les appelants de méthode pour libérer les tampons alloués à l'appelé lorsqu'ils ne sont plus utilisés

Certaines implémentations de Nano-COM telles que Direct3D évitent les fonctions d'allocation et se limitent à utiliser uniquement les tampons alloués par l'appelant.

Nano-COM n'a aucune notion de classes, d'appartements, de marshaling, d'enregistrement, etc. Au contraire, les références d'objet sont simplement transmises à travers les limites des fonctions et allouées via des constructions de langage standard (par exemple, newl'opérateur C++).

La base de Nano-COM a été utilisée par Mozilla pour démarrer Firefox (appelé XPCOM ), et est actuellement utilisée comme technologie ABI de base pour DirectX / Direct3D / DirectML .

Étant donné qu'un contrôle ActiveX (tout composant COM) s'exécute en tant que code natif, sans protection sandbox , il existe peu de restrictions sur ce qu'il peut faire. L'utilisation de composants ActiveX, comme Internet Explorer , dans une page Web, entraîne des problèmes d'infection par des logiciels malveillants . Microsoft a reconnu le problème dès 1996 lorsque Charles Fitzgerald a déclaré : « Nous n'avons jamais affirmé à l'avance qu'ActiveX était intrinsèquement sécurisé ». Les versions ultérieures d'Internet Explorer invitent l'utilisateur à installer un contrôle ActiveX, ce qui lui permet de bloquer l'installation.

Comme niveau de protection, un contrôle ActiveX est signé avec une signature numérique pour garantir son authenticité.

Il est également possible de désactiver complètement les contrôles ActiveX ou d'en autoriser seulement quelques-uns.

La prise en charge transparente des serveurs COM hors processus favorise la sécurité logicielle en termes d' isolation des processus . Cela peut être utile pour découpler les sous-systèmes d'une application volumineuse en processus distincts. L'isolation des processus limite la corruption d'état dans un processus et empêche ainsi l'intégrité des autres processus d'être affectée, car ils ne communiquent que via des interfaces strictement définies. Ainsi, seul le sous-système affecté doit être redémarré pour retrouver un état valide. Ce n'est pas le cas pour les sous-systèmes au sein du même processus, où un pointeur malveillant dans un sous-système peut corrompre de manière aléatoire d'autres sous-systèmes.

COM est pris en charge via des liaisons dans plusieurs langages, tels que C , C++ , Visual Basic , Delphi , Python et plusieurs contextes de script Windows. L'accès aux composants s'effectue via des méthodes d'interface . Cela permet un appel direct en cours de processus et via l'accès au sous-système COM/DCOM entre les processus et les ordinateurs.

Une coclasse , une classe COM, implémente une ou plusieurs interfaces. Elle est identifiée par un identifiant de classe, appelé CLSID qui est un GUID , et par un identifiant programmatique lisible par l'homme , appelé ProgID . Une coclasse est créée via l'un de ces identifiants.

Chaque interface COM étend l' IUnknowninterface, qui expose des méthodes de comptage de références et d'accès aux autres interfaces de l'objet, de manière similaire à la conversion de type , également appelée conversion de type.

Une interface est identifiée par un ID d'interface (IID), un GUID.

Une interface personnalisée , tout ce qui en dérive IUnknown, fournit un accès anticipé via un pointeur vers une table de méthodes virtuelles qui contient une liste de pointeurs vers les fonctions qui implémentent les fonctions déclarées dans l'interface, dans l'ordre dans lequel elles sont déclarées. Une surcharge d'invocation en cours de processus est donc comparable à un appel de méthode virtuelle C++.

La répartition, également appelée accès tardif , est fournie par l'implémentation IDispatchde . La répartition permet l'accès à partir d'une gamme plus large de contextes de programmation qu'une interface personnalisée.

Comme de nombreux langages orientés objet, COM propose une séparation entre l'interface et l'implémentation. Cette distinction est particulièrement forte dans COM où un objet n'a pas d'interface par défaut. Un client doit demander une interface pour avoir accès. COM prend en charge plusieurs implémentations de la même interface, de sorte que les clients peuvent choisir l'implémentation d'une interface à utiliser.

Une bibliothèque de types COM définit des métadonnées COM, telles que des coclasses et des interfaces. Une bibliothèque peut être définie comme un langage de définition d'interface (IDL) ; une syntaxe indépendante du langage de programmation. IDL est similaire à C++ avec une syntaxe supplémentaire pour définir des interfaces et des coclasses. IDL prend également en charge les attributs entre crochets avant les déclarations pour définir des métadonnées telles que des identifiants et des relations entre les paramètres.

Un fichier IDL est compilé via le compilateur MIDL. Pour une utilisation avec C/C++, le compilateur MIDL génère un fichier d'en-tête avec structdes définitions correspondant aux vtbls des interfaces déclarées et un fichier C contenant les déclarations des GUID d'interface . Le code source C++ d'un module proxy peut également être généré par le compilateur MIDL. Ce proxy contient des stubs de méthode pour convertir les appels COM en appels de procédure distante afin d'activer DCOM pour la communication hors processus.

MIDL peut générer une bibliothèque de types binaires (TLB) qui peut être utilisée par d'autres outils pour prendre en charge l'accès à partir d'un autre contexte.

Le code IDL suivant déclare une coclasse nommée SomeClassqui implémente une interface nommée ISomeInterface.

coclass SomeClass { [par défaut] interface ISomeInterface; }; 

Ceci est conceptuellement équivalent au code C++ suivant où ISomeInterface est une classe virtuelle pure , également appelée classe de base abstraite.

classe ISomeInterface {}; classe SomeClass : public ISomeInterface { };

En C++, les objets COM sont instanciés via la CoCreateInstancefonction de sous-système COM qui prend le CLSID et l'IID. SomeClasspeuvent être créés comme suit :

ISomeInterface * interface_ptr = NULL ; HRESULT hr = CoCreateInstance ( CLSID_SomeClass , NULL , CLSCTX_ALL , IID_ISomeInterface , ( void ** ) & interface_ptr );

Un objet COM utilise le comptage de références pour gérer la durée de vie de l'objet. Le nombre de références d'un objet est contrôlé par les clients via les méthodes IUnknown AddRefet Release. Les objets COM sont responsables de la libération de leur propre mémoire lorsque le nombre de références tombe à zéro. Certains contextes de programmation (par exemple, Visual Basic ) fournissent un comptage automatique des références pour simplifier l'utilisation des objets. En C++, un pointeur intelligent peut être utilisé pour automatiser la gestion du nombre de références.

Voici quelques directives sur le moment où AddRef et Release doivent être appelés :

• Une fonction qui renvoie une référence d'interface (via une valeur de retour ou via un paramètre « out ») incrémente le nombre d'objets renvoyés

• La libération est appelée avant que le pointeur d'interface ne soit écrasé ou ne sorte du champ d'application

• Si une copie est effectuée sur un pointeur de référence d'interface, AddRef est appelé

• AddRef et Release sont appelés sur l'interface qui est référencée (et non sur une interface différente du même objet) car un objet peut implémenter des comptages de références par interface afin d'allouer des ressources internes uniquement pour les interfaces référencées

Pour les objets distants, tous les appels de comptage de références ne sont pas envoyés via le réseau. Un proxy ne conserve qu'une seule référence sur l'objet distant et conserve son propre comptage de références local.

Pour simplifier le développement COM pour les développeurs C++, Microsoft a introduit ATL (Active Template Library) . ATL fournit un paradigme de développement COM de niveau relativement élevé. Il protège également les développeurs d'applications clientes COM de la nécessité de maintenir directement le comptage des références, en fournissant des types de pointeurs intelligents . D'autres bibliothèques et langages compatibles COM incluent les classes Microsoft Foundation , le support COM du compilateur VC , VBScript , Visual Basic , ECMAScript ( JavaScript ) et Borland Delphi .

COM est une norme binaire indépendante du langage qui permet d'utiliser des objets dans n'importe quel contexte de programmation capable d'accéder à ses interfaces binaires.

Le logiciel client COM est responsable de l'activation du sous-système COM, de l'instanciation et du comptage des références des objets COM et de l'interrogation des objets pour les interfaces prises en charge.

Le compilateur Microsoft Visual C++ prend en charge les extensions du langage C++, appelées attributs C++ , qui sont conçues pour simplifier le développement COM et minimiser le code standard requis pour implémenter les serveurs COM en C++.

À l'origine, les métadonnées de la bibliothèque de types devaient être stockées dans le registre système. Un client COM utilisait les informations du registre pour créer des objets.

La technologie COM sans enregistrement (RegFree) a été introduite avec Windows XP pour permettre le stockage des métadonnées de la bibliothèque de types sous forme de manifeste d'assemblage, soit en tant que ressource dans le fichier exécutable, soit dans un fichier séparé installé avec le composant. Cela permet d'installer plusieurs versions du même composant sur le même ordinateur, dans des répertoires différents. Et cela permet le déploiement XCOPY . Cette technologie a un support limité pour les serveurs COM EXE et ne peut pas être utilisée pour les composants à l'échelle du système tels que MDAC , MSXML , DirectX ou Internet Explorer .

Lors du chargement de l'application, le chargeur Windows recherche le manifeste. S'il est présent, le chargeur ajoute des informations au contexte d'activation. Lorsque la fabrique de classes COM tente d'instancier une classe, le contexte d'activation est d'abord vérifié pour voir si une implémentation du CLSID peut être trouvée. Ce n'est que si la recherche échoue que le registre est analysé.

Un objet COM peut être créé sans informations de bibliothèque de types, avec seulement un chemin vers le fichier DLLDllGetClassObject et le CLSID. Un client peut utiliser la fonction DLL COM avec le CLSID et IID_IClassFactory pour créer une instance d'un objet factory . Le client peut ensuite utiliser l'objet factory CreateInstancepour créer une instance. Il s'agit du même processus que celui utilisé par le sous-système COM. Si un objet créé de cette manière crée un autre objet, il le fera de la manière habituelle (en utilisant le registre ou le manifeste). Mais il peut créer des objets internes (qui peuvent ne pas être enregistrés du tout) et leur transmettre des références aux interfaces, en utilisant ses propres connaissances privées.

Un objet COM peut être créé et utilisé de manière transparente au sein du même processus (in-process), au-delà des limites du processus (out-of-process) ou à distance via le réseau (DCOM). Les objets out-of-process et distants utilisent le marshalling pour sérialiser les appels de méthode et renvoyer des valeurs au-delà des limites du processus ou du réseau. Ce marshalling est invisible pour le client, qui accède à l'objet comme s'il s'agissait d'un objet in-process local.

Dans COM, le threading est abordé par le biais d'un concept appelé appartements . Un objet COM individuel réside dans un seul appartement, qui peut être monothread ou multithread. Il existe trois types d'appartements dans COM : Single-Threaded Apartment (STA) , Multi-Threaded Apartment (MTA) et Thread Neutral Apartment (NA). Chaque appartement représente un mécanisme par lequel l'état interne d'un objet peut être synchronisé sur plusieurs threads. Un processus peut être constitué de plusieurs objets COM, dont certains peuvent utiliser STA et d'autres peuvent utiliser MTA. Tous les threads accédant aux objets COM vivent de la même manière dans un seul appartement. Le choix de l'appartement pour les objets COM et les threads est déterminé au moment de l'exécution et ne peut pas être modifié.

Les threads et les objets qui appartiennent au même appartement suivent les mêmes règles d'accès aux threads. Les appels de méthodes effectués à l'intérieur du même appartement sont donc exécutés directement sans aucune assistance de COM. Les appels de méthodes effectués entre les appartements sont réalisés via le marshalling. Cela nécessite l'utilisation de proxys et de stubs.

COM est relativement complexe, surtout comparé aux technologies de composants plus modernes telles que .NET.

Lorsqu'un STA est initialisé, il crée une fenêtre cachée qui est utilisée pour le routage des messages entre les appartements et entre les processus. La file d'attente de messages de cette fenêtre doit être régulièrement « pompée ». Cette construction est connue sous le nom de « pompe à messages ». Sur les versions antérieures de Windows, le fait de ne pas le faire pouvait entraîner des blocages à l'échelle du système. Ce problème est compliqué par certaines API Windows qui initialisent COM dans le cadre de leur implémentation, ce qui provoque une « fuite » des détails d'implémentation.

Le comptage de références dans COM peut poser des problèmes si deux objets ou plus sont référencés de manière circulaire . La conception d'une application doit en tenir compte afin que les objets ne restent pas orphelins. Les objets peuvent également être laissés avec des comptages de références actifs si le modèle « puits d'événements » COM est utilisé. Étant donné que l'objet qui déclenche l'événement a besoin d'une référence à l'objet réagissant à l'événement, le comptage de références de ce dernier n'atteindra jamais zéro. Les cycles de référence sont généralement interrompus à l'aide d'une terminaison hors bande ou d'identités fractionnées. Dans la technique de terminaison hors bande, un objet expose une méthode qui, lorsqu'elle est appelée, le force à supprimer ses références à d'autres objets, interrompant ainsi le cycle. Dans la technique d'identité fractionnée, une seule implémentation expose deux objets COM distincts (également appelés identités). Cela crée une référence faible entre les objets COM, empêchant un cycle de référence.

Étant donné que les composants COM in-process sont implémentés dans des fichiers DLL et que l'enregistrement n'autorise qu'une seule version par CLSID, ils peuvent dans certaines situations être sujets à l'effet « DLL Hell ». La fonctionnalité COM sans enregistrement élimine ce problème pour les composants in-process ; la fonctionnalité COM sans enregistrement n'est pas disponible pour les serveurs hors processus.