close

Modèle d'objet composant

Aller à la navigation Aller à la recherche

En informatique , le Component Object Model (connu sous l' acronyme COM , en anglais pour Component Object Model ) est une interface pour composants logiciels introduite par Microsoft en 1993 . COM permet la communication interprocessus et la création d'objets dynamiques avec n'importe quel langage de programmation prenant en charge cette technologie. [1] Le terme COM est souvent utilisé dans le monde du développement logiciel avec plusieurs sens : OLE , OLE Automation , ActiveX , COM+ et DCOM . Bien que l'introduction de COM remonte à 1993, Microsoft n'a commencé à utiliser ce nom avec emphase qu'en 1997 .

Bien qu'il ait également été porté sur d'autres plates-formes, COM est principalement utilisé avec Microsoft Windows . Un remplacement progressif au moins partiel de COM par le framework Microsoft .NET est prévu .

Histoire

Anthony Williams, l'un des principaux esprits impliqués dans la création de l'architecture COM, a distribué quelques documents internes de Microsoft traitant du concept de composants logiciels ; " Architecture d'objet : traiter l'inconnu - ou - la sécurité des types dans une classe dynamiquement extensible " en 1988 et " Sur l'héritage : ce que cela signifie et comment l'utiliser " (" Sur l'héritage : ce que cela signifie et comment l'utiliser ") en 1990 . Celles-ci ont jeté les bases de bon nombre, sinon de toutes, des idées derrière les principes fondamentaux de COM.

De plusieurs de ces idées , le premier framework orienté objet de Microsoft est né, OLE ( un acronyme pour Object linking and embedding ). OLE a été construit à partir de DDE et conçu en mettant l'accent sur les documents composites ; il a été introduit pour la première fois avec Word pour Windows et Excel en 1991 , et a ensuite été inclus avec Windows, à partir de la version 3.1 en 1992 . Un exemple de document composé peut être une feuille Excel dans un document Word ; lorsque la feuille de calcul est modifiée, les modifications apparaissent automatiquement dans le document Word.

En 1991, Microsoft a introduit la technologie VBX (acronyme de Visual Basic extension , Visual Basic Extension ) avec Visual Basic 1.0.

En 1993 , Microsoft a publié OLE 2, ayant COM comme modèle d'objet sous-jacent. Alors qu'OLE 1 se concentrait sur les documents composés, COM et OLE 2 avaient une adresse plus générique. En 1994 , les contrôles OLE (OCX, OLE Control eXtension) ont été introduits en tant que successeurs naturels des contrôles VBX ; dans le même temps, Microsoft annonçait qu'OLE 2 s'appellerait simplement « OLE », et qu'il ne s'agirait plus d'un acronyme, mais d'un vrai nom par lequel l'entreprise désignerait ses technologies orientées objet.

Par la suite, au début de 1996 , Microsoft a changé le nom de certaines parties d'OLE liées à Internet en ActiveX , entamant ainsi le processus qui l'a conduit à renommer toutes les technologies OLE en ActiveX au fil des années, à la seule exception de la technologie des documents composites utilisés. dans Microsoft Office . Plus tard cette année-là, Microsoft a publié DCOM (acronyme de Distributed component object model ) en réponse à CORBA .

Structure et fonctionnement COM

Le but du Component Object Model est de permettre la création de composants logiciels binaires : bien qu'il ait été créé avec le langage C++ à l'esprit , COM est neutre par rapport au langage de programmation, c'est-à-dire que vous pouvez utiliser n'importe quel langage de programmation pour utiliser COM composants à l'exécution. Cette neutralité est obtenue en spécifiant les formats des appels de données et de fonctions avec le langage IDL complètement indépendant . Conceptuellement, il s'agit donc d'un pas de plus que les bibliothèques de liens dynamiques ( DLL ). Chaque objet COM doit être unique au sein du système et est utilisé via des interfaces logicielles uniques au monde . Pour assurer l'unicité, le programmeur qui crée un nouvel objet COM crée un GUID pour celui-ci (un numéro d'identification de 128 bits généré aléatoirement qui est, presque certainement, différent de tous les autres GUID du système) et un GUID pour chacune des interfaces qui l'objet implémente ; ces GUID sont appelés CLSID (ID de classe) s'ils font référence à un objet COM et IID (ID d'interface) s'ils font référence à une interface. Pour qu'un objet COM soit utilisé, il doit être enregistré dans Windows dans le registre , c'est-à-dire qu'une entrée est créée dans le registre qui mappe le CLSID du composant au fichier disque qui l'implémente physiquement et à toute information de configuration. Lorsqu'un programme demande un composant COM donné, il se réfère au CLSID correspondant : Windows se chargera de trouver le fichier sur disque (DLL ou EXE ) et de charger le code nécessaire. Une fois cela fait, le programme demandera au composant nouvellement créé d'accéder à l'une de ses interfaces, en utilisant l'IID de celui dont il a besoin.

Les interfaces

Une interface COM est une collection de fonctions : c'est-à-dire qu'il s'agit d'une classe virtuelle pure , et dans la programmation orientée objet, elle est généralement modélisée comme ceci. Tous les composants COM doivent au moins implémenter l' interface standard IUnknown. En fait, toutes les interfaces COM sont dérivées de l' interface IUnknown. Il se compose de trois méthodes : AddRef()et , Release()qui mettent en œuvre le comptage de références et contrôlent le cycle de vie des interfaces ; et , qui en spécifiant un IID permet à l'appelant d'obtenir des références aux différentes interfaces fournies par le composant. QueryInterface()

Matériellement, une interface consiste en un pointeur vers une table de fonctions virtuelles qui contient une liste de pointeurs vers les fonctions qui implémentent les méthodes déclarées dans l'interface, dans le même ordre dans lequel elles sont déclarées. Cette technique de passage de listes de pointeurs de fonction est une évolution directe de celle utilisée dans OLE 1.0 pour communiquer avec ses bibliothèques système.

COM spécifie de nombreuses autres interfaces standard utilisées pour la communication entre les composants. Par exemple, une de ces interfaces est IStream, qui est fournie par des composants qui ont une sémantique de flux de données (par exemple, le composant FileStreamutilisé pour lire et écrire des fichiers). Il fournit les méthodes Readet Writepour effectuer des lectures et des écritures de flux. Une autre interface standard est IOleObjectfournie par des composants qui prévoient d'être connectés ou encapsulés à l'intérieur d'un conteneur. IOleObjectcontient des méthodes qui permettent aux appelants de déterminer le rectangle englobant du composant, de déterminer si le composant prend en charge des opérations telles que Open , Save , etc.

Comme déjà mentionné, COM a été développé avec C ++ à l'esprit, il utilise donc largement les pointeurs. Cela rendait impossible l'utilisation d'objets COM avec des langages qui n'en avaient pas, tels que Visual Basic , Java et tous les langages de script ; OLE Automation , entre autres, a remédié à cette situation. Les interfaces de pointeur étaient appelées interfaces personnalisées et flanquées de nouvelles interfaces analogues mais sans pointeurs, basées sur des tableaux et des collections d'objets, appelées interfaces d'automatisation ; dans la version Automation, l'interface IUnknown est remplacée par IDispatch . Le même composant peut implémenter les mêmes interfaces dans les deux versions ; Cependant, la version personnalisée est obligatoire, tandis que l'automatisation n'est qu'optionnelle.

Comptage de références

Le comptage de références est utilisé par les composants COM pour savoir quand ils peuvent se terminer et se décharger de la RAM. Un programme client qui utilise le composant ne peut pas procéder à son élimination lorsqu'il a fini de l'utiliser, car il pourrait encore être utilisé par d'autres programmes clients (après tout dans l'environnement COM il est possible qu'un client, une fois l'interaction avec un composant, vous transmettez le pointeur d'interface du même composant à un autre client). L'élimination d'un composant est donc gérée par elle-même par comptage de références ; cette technique prévoit que l'objet COM (c'est-à-dire le composant), lors du passage du pointeur d'une de ses interfaces à un programme client (ce qui se produit suite à la demande par le client de pouvoir utiliser cette interface particulière), augmente le "compte de références ". Lorsque le client a fini d'utiliser l'objet COM, il appelle la méthode IUnknown :: Release () qui décrémente le "nombre de références" de 1. Lorsqu'un client reçoit le pointeur vers une interface d'un autre client, il invoque la méthode IUnknown :: AddRef () sur l'objet COM, qui incrémente le même "compte de références" de 1. L'objet COM s'autodétruira lorsque le "compte de références" sera égal à 0.

Héritage, confinement et agrégation

La norme fournit un mécanisme d'héritage unique qui permet à un composant d'étendre les fonctions d'un autre : chaque interface peut hériter des méthodes d'une (et d'une seule) interface préexistante, mais pas modifier ou remplacer les méthodes héritées de l'interface "père" . Plus généralement, il est assez courant que des objets COM d'une certaine complexité utilisent d'autres objets COM à l'intérieur d'eux-mêmes ; on parle de contenant un objet COM si celui-ci utilise ses interfaces sans les rendre disponibles à l'extérieur de lui, et d' agrégation s'il le fait.

RegFree COM

Windows XP a introduit un nouveau mode d'enregistrement local des composants COM, appelé COM sans inscription ou RegFree COM en abrégé. Avec cette technique, les applications n'ont plus à enregistrer les métadonnées d'activation et le CLSID dans le registre Windows, mais peuvent les spécifier dans leur manifeste ; il peut s'agir d'un fichier XML qui réside dans le répertoire de l'application elle-même ou qui peut être contenu dans l'en-tête de son fichier exécutable, sous forme de section au format binaire. Lorsque Windows charge l'application et référence ses objets COM, la fabrique de classe (l'entité qui crée physiquement les objets COM) consultera le manifeste de l'application pour rechercher les GUID spécifiés et les métadonnées associées et chargera ceux fournis avec l'application ; ce n'est que si le manifeste ne contient pas les GUID requis qu'il consultera le registre Windows et (le cas échéant) qu'il créera les objets COM système équivalents. La limitation de cette technologie est qu'elle ne peut pas être utilisée avec des composants COM qui doivent être visibles dans tout le système, elle ne peut donc pas être utilisée pour des serveurs COM OutOfProcess ou pour implémenter des parties du système d'exploitation ( MDAC , MSXML , DirectX ou Internet Explorer ).

Technologies associées

COM a été la principale plate-forme de développement de logiciels pour Windows et, à ce titre, a influencé le développement d'un certain nombre de technologies de support.

COM +

Avec Windows 2000 , un nombre important d'extensions COM appelées COM+ ont été introduites . À peu près au même moment, Microsoft a réduit DCOM en tant qu'entité distincte.

DCOM

.NET

La plate-forme COM a été largement dépassée par Microsoft .NET , et le marketing de Microsoft est entièrement centré sur .NET ; d'une certaine manière, COM est même désormais obsolète au profit de .NET. Malgré cela, COM reste une technologie importante en raison de sa base logicielle massive - par exemple, le SDK DirectX est basé sur COM ; de plus, un composant COM est théoriquement toujours plus performant qu'un composant managé .NET correspondant . Au moment d'écrire ces lignes, Microsoft n'a pas annoncé son intention de retirer ou d'interrompre le support COM.

Certains services fournis par COM +, tels que les transactions et les files d'attente de composants , sont toujours importants pour les applications d'entreprise .NET.

Il y a une limite à la rétrocompatibilité . Un objet COM peut être utilisé dans .NET en implémentant un runtime callable wrapper (RCW).

Sécurité Internet

Étant donné que les composants COM et ActiveX s'exécutent en tant que code natif sur la machine de l'utilisateur, il existe peu de restrictions sur ce que leur code peut faire. Beaucoup de ces problèmes ont été résolus par la dépréciation relative de COM dans les plates-formes développées depuis lors, telles que la plate- forme Java , et plus tard également la plate-forme .NET .

L'idée de Microsoft d'encapsuler le contenu actif sur les pages Web sous la forme de composants COM / ActiveX (au lieu, par exemple, d' applets Java ) a créé un certain nombre de problèmes dans le navigateur Internet Explorer , entraînant une explosion des infections par des virus informatiques , chevaux de Troie et logiciels espions . Ces attaques de logiciels malveillants doivent principalement à ActiveX leur activation et leur propagation vers d'autres ordinateurs. Microsoft a reconnu le problème d'ActiveX dès 1996 , lorsque Charles Fitzgerald , directeur de l'équipe Java de Microsoft, a déclaré : « Si vous voulez la sécurité sur le Net , déconnectez votre ordinateur. (...) Nous n'avons jamais affirmé qu'ActiveX est intrinsèquement sûr.

Critiques

Étant donné que COM est assez complexe à mettre en œuvre, les programmeurs courent le risque d'être distraits par d'autres activités secondaires.

Initialisation de l'environnement

Pour chaque thread nécessitant la fonctionnalité COM, le programmeur doit ajouter des appels explicites aux fonctions CoInitialize[Ex]et CoUninitialize; de plus, le code qui utilise le presse-papiers ou le glisser-déposer OLE doit appeler OleInitializeet OleUninitialize. Étant donné que certains threads du système peuvent avoir été créés par des bibliothèques qui n'utilisent pas COM, le programmeur doit être prudent lorsqu'il utilise une fonction COM dans un thread qui n'a pas été créé dans le programme lui-même.

Tri des messages

Lorsqu'un Single-Threaded Apartment est initialisé, il crée une fenêtre cachée qui est utilisée pour adresser les messages inter-appartements et inter-processus . Cette fenêtre doit avoir sa procédure standard de traitement des messages. Ce processus est connu sous le nom de pompage de messages. Dans les versions précédentes de Windows, le non-respect de cette procédure pouvait provoquer un plantage à l'échelle du système. Ce problème est encore compliqué par certaines API Windows qui initialisent COM dans le cadre de leur implémentation, ce qui entraîne à son tour un manque de détails d'implémentation du composant COM.

Comptage de références

Un scénario dans lequel le comptage de références entraîne des problèmes est celui dans lequel deux objets COM se réfèrent l'un à l'autre, comme cela se produit par exemple en utilisant des « points de connexion » ou des « récepteurs d' événements » . Dans ce cas, aucun objet ne peut se libérer car il doit d'abord libérer l'autre, qui lui ne peut pas être libéré car il a encore une référence à l'objet qui voudrait le libérer. Ce cercle vicieux peut être rompu de deux manières : une terminaison hors bande de l'un des deux objets, ou la création de deux objets COM identiques et faiblement référencés, dont l'un sert à se connecter au partenaire de communication et l'autre ne sert qu'à finir le premier.

L'enfer des DLL

Chaque interface COM est également un contrat entre l'appelant et l'appelé : un programme utilisant un composant COM doit supposer que les méthodes qu'il appelle se comporteront toujours comme prévu et n'a aucun contrôle sur elles. Étant donné que l'emplacement de chaque composant est stocké dans un emplacement au niveau du système (dans Windows dans le registre ), une seule version du même composant peut être installée sur le système à un moment donné, généralement la version que la dernière application installée il a apportée avec lui; si le nouveau composant a des propriétés même légèrement différentes du précédent, d'autres applications généreront soudainement des erreurs et un comportement imprévisible ou aléatoire, sans raison apparente. Ce phénomène s'appelle " l'enfer des DLL " , une situation tristement célèbre pour les programmeurs et les administrateurs système. Avec le RegFree COM de Windows XP, ce grave inconvénient peut être considérablement réduit.

Remarques

  1. ^ Component Object Model Technologies , de microsoft.com , Microsoft Corporation.

Objets associés

Liens externes

Extrait de " https://it.wikipedia.org/w/index.php?title=Component_Object_Model&oldid=116813102 "