Modèle d'objet composant

Component Object Model (COM) est une plate-forme Microsoft pour les composants logiciels , introduite en 1993 . Cette plate-forme est utilisée pour permettre la communication entre les processus et la création dynamique d'objets, dans n'importe quel langage de programmation prenant en charge cette technologie. Le terme COM est souvent utilisé dans le monde du développement logiciel comme terme générique pour les technologies OLE, OLE Automation, ActiveX, COM+ et DCOM. Bien que COM ait été introduit en 1993, Microsoft n'a mis l'accent sur le nom COM qu'en 1997.

COM est essentiellement un moyen d'implémenter des objets indépendants du langage, afin qu'ils puissent être utilisés dans des environnements autres que celui dans lequel ils ont été créés, au-delà des limites de la machine. Pour les composants bien créés, COM permet la réutilisation d'objets sans connaissance de leur implémentation interne, car il oblige les implémenteurs de composants à fournir des interfaces bien définies qui sont distinctes de l'implémentation. Différentes sémantiques d'allocation de mémoire sont prises en charge en rendant les objets responsables de leur propre création et destruction via le décompte de références. Vous pouvez convertir entre différentes interfaces d'un objet à l'aide de QueryInterface(). La méthode d'héritage préférée dans COM est la création de sous-objets auxquels les appels de méthode sont délégués (appelée agrégation).

Bien que ces technologies aient été implémentées sur de nombreuses plates-formes, elles sont principalement utilisées avec un programme Microsoft Windows . COM devrait être remplacé, au moins dans une certaine mesure, par Microsoft .NET et la prise en charge des services Web via la Windows Communication Foundation (WCF). Network DCOM utilise des formats binaires propriétaires, tandis que WCF utilise des messages SOAP basés sur XML . COM est également en concurrence avec CORBA et JavaBeans en tant que système de composants logiciels.

Détails techniques

Les programmeurs COM créent des logiciels à l'aide de composants logiciels compatibles COM. Différents types de composants sont identifiés par des ID de type (CLSID), qui sont des identificateurs uniques au monde, ou GUID. Chaque composant COM révèle sa fonctionnalité à travers une ou plusieurs interfaces. Les différentes interfaces prises en charge par un composant se distinguent les unes des autres à l'aide d'ID d'interface (IID), qui sont également des GUID.

Les interfaces COM ont des implémentations dans divers langages, tels que C, C++, Visual Basic et plusieurs des langages de script implémentés sur la plate-forme Windows. Tous les accès aux composants se font par les méthodes des interfaces. Cela permet des techniques telles que l'inter-traitement, voire la programmation inter-ordinateurs (cette dernière via le support DCOM).

Interfaces

Tous les composants COM doivent implémenter au moins l' interface IUnknown standard , et donc toutes les interfaces COM sont dérivées de IUnknown . L' interface IUnknown se compose de trois méthodes : AddRef()et Release(), qui implémentent le comptage de références et le contrôle du cycle de vie de l'interface ; et QueryInterface(), qui en spécifiant un IID permet à un appel de récupérer des références aux différentes interfaces que le composant implémente. L'effet de QueryInterface()est similaire à dynamic_cast <>en C++ ou castingen C# et Java.

Les interfaces d'un composant COM doivent afficher les propriétés réflexives, symétriques et transitives. La propriété réfléchissante fait référence à la capacité pour l'appel à QueryInterface(), étant donné une interface avec l'ID d'interface, de renvoyer la même instance de l'interface. La propriété symétrique fait référence au fait que lorsque l'interface B est récupérée à partir de l'interface A par QueryInterface(), alors l'interface A est également récupérable à partir de l'interface B. La propriété transitive est similaire à la propriété symétrique, mais nécessite que si l'interface B peut être récupérée à partir de A, et C à leur tour à partir de B, alors l'interface C doit être disponible à partir de A.

Une interface consiste en un pointeur de fonction virtuelle qui contient une liste de pointeurs vers les fonctions que la fonction déclarée dans l'interface implémente, dans le même ordre que celui dans lequel elles ont été déclarées dans l'interface. Cette technique de passage de pointeur de fonction de structure est très similaire à celle utilisée par OLE 1.0 pour communiquer avec son système de bibliothèque.

COM spécifie de nombreuses autres interfaces standard utilisées pour permettre la communication entre les composants. Par exemple, l'un d'eux est IStream , qui est destiné aux composants qui ont une sémantique de flux de données (un composant FileStream utilisé pour lire et écrire des fichiers). Il dispose des méthodes Read et Write attendues pour effectuer les lectures et écritures de flux. Une autre interface standard est IOleObject , qui est destinée aux composants qui s'attendent à être liés ou incorporés dans un conteneur. IOleObject contient des méthodes qui permettent aux parties prenantes de déterminer la taille des limites d'un composant rectangle, si le composant prend en charge des opérations telles que 'Open' , 'Save' et ainsi de suite.

Cours

Une classe dans COM est appelée une coclasse , qui est la forme contractée de la classe Component Object . Une coclasse est la façon dont COM définit une classe au sens orienté objet et indépendant du langage. Une coclasse fournit une implémentation concrète d'une ou plusieurs interfaces. Dans COM, de telles implémentations concrètes peuvent être écrites dans n'importe quel langage de programmation prenant en charge le développement de composants COM, tel que C++, Visual Basic, etc.

L'une des plus grandes contributions de COM au monde du développement Windows est la prise de conscience du concept de séparation de l'interface de l'implémentation. Cette prise de conscience a sans aucun doute influencé la façon dont les programmeurs construisent les systèmes d'aujourd'hui. Une extension de ce concept fondamental est le concept d'une interface, de multiples implémentations. Cela signifie qu'au moment de l'exécution, une application peut choisir d'instancier une interface à partir de plusieurs implémentations concrètes.

de définition d'interface et bibliothèques

Les bibliothèques de types contiennent des métadonnées qui représentent les types COM. Cependant, ces types doivent d'abord être décrits à l'aide du Microsoft Interface Definition Language (MIDL). C'est une pratique courante lors du développement d'un composant COM, par exemple lors du démarrage de la définition de types à l'aide d'IDL. Un fichier IDL est ce que COM fournit qui permet aux développeurs de définir indépendamment des classes, des interfaces, des structures, des énumérations et d'autres types définis par l'utilisateur dans un langage. COM IDL est similaire en apparence aux déclarations C ou C++ avec l'ajout de mots-clés tels que "interface" et "library" pour la définition des interfaces et des collections de classes, respectivement. IDL requiert également l'utilisation d'attributs entre crochets avant les déclarations pour fournir des informations supplémentaires, telles que le GUID des interfaces et la relation entre les paramètres de pointeur et de longueur des champs.

Le fichier IDL est compilé par le compilateur MIDL de plusieurs manières pour être utilisé dans différents langages. Pour C/C++, le compilateur MIDL génère un en-tête indépendant du compilateur contenant des définitions de structure qui correspondent aux fonctions virtuelles à la déclaration d'interface et un fichier C contenant les GUID de déclaration d'interface. Le code source C++ d'un module Proxy peut également être généré par le compilateur MIDL. Ce proxy contient des méthodes stub pour convertir les appels COM en RPC, ceci est autorisé par DCOM.

Un fichier IDL peut également être compilé par le compilateur MIDL dans une bibliothèque de types (fichier .TLB). Les métadonnées binaires contenues dans la bibliothèque sont destinées à être traitées par les compilateurs et les environnements d'exécution du langage (VB, Delphi, le .NET CLR, etc.). Le résultat final d'un tel traitement TLB est que des constructions spécifiques au langage sont produites qui représentent la classe COM définie dans le .TLB (et finalement celle définie dans le fichier source IDL).

Comptage de références

La plus importante de toutes les interfaces COM, c'est-à-dire IUnknown (dont toutes les interfaces COM doivent dériver), prend en charge deux concepts principaux : la recherche de fonctionnalités (ou d'interfaces qu'un objet implémente) via la méthode queryInterface(), et la gestion du cycle de vie de l'objet en incluant AddRef ()et Release (). La fonctionnalité de comptage de références et de requête s'applique aux objets (et non à chaque interface) et doit donc avoir une implémentation centralisée.

Les spécifications COM nécessitent une technique appelée comptage de références pour s'assurer que les différents objets sont actifs tant qu'il y a des clients qui ont acquis l'accès à une ou plusieurs de leurs interfaces et, inversement, que le même objet est correctement éliminé lorsque tout le code est présent qui utilise l'objet en a fini avec lui et n'en a plus besoin. Un objet COM est chargé de libérer sa propre mémoire une fois que son compteur de références est décrémenté à zéro.

Pour son exécution, un objet COM conserve généralement une valeur qui sert de référence pour le comptage. Lorsqu'elle est appelée AddRef ()via l'une des interfaces de l'objet, cette valeur est incrémentée. Lorsqu'on appelle Release(), cet entier est décrémenté. AddRef ()et Release ()ils sont le seul moyen par lequel un client d'un objet COM est capable d'influencer son cycle de vie. La valeur interne reste un membre privé de l'objet COM et ne sera jamais directement accessible.

Instanciation

COM standardise le processus d'instanciation (c'est-à-dire de création) d'objets COM en exigeant l'utilisation de la classe Factories . Pour chaque objet COM créé, deux paramètres associés doivent exister :

• Une classe d' identification .
• Une classe Usine .

Chaque classe COM ou CoClass doit être associée à un ID de classe unique (un GUID). Il doit également être associé à sa propre classe Factory (ce qui est obtenu en utilisant un registre centralisé). Une classe Factory est elle-même un objet COM. C'est un objet qui doit exposer l'interface IClassFactory ou IClassFactory2 (cette dernière avec les licences de support). La responsabilité d'un tel objet est la création d'autres objets.

Une classe Factory est généralement contenue dans le même code exécutable (c'est-à-dire le serveur de code) que l'objet COM lui-même. Lorsqu'une classe Factory est appelée pour créer un objet cible, la cible de cet objet est l'identifiant de classe qui doit être fourni. C'est ainsi que la classe Factory sait quelle classe d'objet instancier.

Une seule classe d'objets Factory peut créer des objets de plusieurs classes. Autrement dit, deux objets d' ID de classe différents peuvent être créés par la même classe d'objets Factory . Cependant, cela est transparent pour le système COM.

En déléguant la responsabilité de créer un objet à un objet séparé, un niveau d'abstraction plus élevé est atteint et le développeur a plus de flexibilité.

Pour que les applications clientes puissent acquérir les classes d'objets Factory , les serveurs COM doivent les exposer de manière appropriée. Une classe Factory est exposée différemment selon la nature du code serveur. Un serveur basé sur des DLL doit exporter une fonction globale DllGetClassObject (). Un serveur EXE basé sur la classe Factory s'enregistre au moment de l'exécution via la fonction API Windows de CoRegisterClassObject ().

Programmation

COM est une norme binaire et peut être développé dans n'importe quel langage de programmation capable de comprendre et d'implémenter ses types de données binaires et ses interfaces définis.

Les bibliothèques d'exécution (dans des situations extrêmes, les programmeurs) sont responsables de l'entrée et de la sortie de l'environnement COM, de l'instanciation et du comptage des références des objets COM, des objets pour interroger les informations de version, du codage pour tirer parti des versions avancées des objets.

Transparence des applications et du réseau

Les objets COM peuvent être instanciés et référencés au sein d'un processus, au-delà des limites de processus au sein d'un ordinateur et sur un réseau à l'aide de la technologie DCOM . La sortie du processus et les objets distants peuvent utiliser la sérialisation pour envoyer des appels de méthode et renvoyer des valeurs en arrière et en avant. La sérialisation est invisible pour l'objet et le code utilisant l'objet.

Critique

Message de pompage

Lorsqu'un STA est initialisé, il crée une fenêtre masquée qui est utilisée pour le routage des messages inter-appartements et inter-processus. Cette fenêtre doit avoir sa file d'attente de messages régulièrement pompée. Cette construction est connue sous le nom de bombe à message. Dans les versions antérieures de Windows, ne pas le faire pouvait entraîner des plantages à l'échelle du système. Ce problème est particulièrement désagréable car certaines API Windows initialisent COM dans le cadre de leur application, ce qui entraîne une fuite des détails d'implémentation.

Comptage de références

Le comptage de références dans COM peut entraîner des problèmes si deux ou plusieurs objets sont référencés de manière circulaire. Une conception d'application doit en tenir compte afin que les objets ne soient pas orphelins.

Les objets peuvent également laisser le comptage de références actif si le "cas récepteur" COM est le modèle utilisé. Étant donné que l'objet qui déclenche l'événement a besoin d'une référence d'objet pour réagir à l'événement, le nombre de références d'objet n'atteint jamais zéro.

L'enfer des DLL

Étant donné que l'emplacement de chaque composant est stocké dans un emplacement à l'échelle du système (le registre Windows), il se peut qu'une seule version d'un certain composant soit installée. Par conséquent, COM souffre gravement de l'enfer DLL , où deux applications ou plus nécessitent des versions différentes du même composant.

Windows XP introduit un nouveau mode d'enregistrement d'objets COM : "COM Free Registration". Ce service permet aux applications qui ont besoin d'installer des objets COM de stocker toutes les informations de registre nécessaires à l'enregistrement COM dans le répertoire des requêtes, plutôt que dans le registre global, où à proprement parler une seule requête est utilisée. L'enfer DLL, peut être évité par COM sans registre, la seule limitation étant qu'il nécessite au moins Windows XP ou des versions ultérieures de Windows et qu'il ne doit pas être utilisé pour EXE, COM ou des composants système à l'échelle du serveur tels que MDAC , MSXML , DirectX ou Internet Explorer.

Références

• Berger, Dan (2004). « COM : une brève introduction » . Histoire africaine sur About.com . Consulté le 6 février 2006 . 
• Microsoft Corp. (2006). « Modèle objet composant » . Archivé de l'original le 18/03/2006 . Consulté le 6 février 2006 . 
• Boîte, Don (1998). COM essentiel . Série Addison-Wesley Object Technology . ISBN  0-201-63446-5 . 

Voir aussi

• Modèle d'objet de composant distribué (DCOM)
• Échange dynamique de données (DDE)
• Microsoft .NET (.NET)
• Liaison et incorporation d'objets (OLE)
• composant logiciel
• Ingénierie logicielle basée sur les composants

Liens externes

• Technologies COM de Microsoft .
• Ce qu'est vraiment OLE par Kraig Brockschmidt. Présentation de COM et OLE. (En anglais).
• Groupe d'applications de composants chez Microsoft Research .
• Projet Mozilla ActiveX (en anglais).
• Introduction à Com .
• INFO : Différence entre les contrôles OLE et les contrôles ActiveX de Microsoft.