Automatisation OLE

Dans la programmation d'applications Microsoft Windows , OLE Automation (plus tard renommé simplement Automation ) est un mécanisme de communication interprocessus créé par Microsoft . Il est basé sur un sous-ensemble de Component Object Model (COM) qui était destiné à être utilisé par les langages de script – à l'origine Visual Basic – mais qui est maintenant utilisé par plusieurs langages sous Windows. Tous les objets d'automatisation sont nécessaires pour implémenter l' interface IDispatch . Il fournit une infrastructure par laquelle les applications appelées contrôleurs d'automatisation peuvent accéder et manipuler (c'est-à-dire définir des propriétés ou appeler des méthodes sur) des objets d'automatisation partagés qui sont exportés par d'autres applications. Il remplace Dynamic Data Exchange (DDE), un ancien mécanisme permettant aux applications de se contrôler mutuellement. Comme avec DDE, dans OLE Automation, le contrôleur d'automatisation est le « client » et l'application exportant les objets d'automatisation est le « serveur ».

Contrairement à ce que leur nom laisse entendre, les objets d'automatisation n'utilisent pas nécessairement Microsoft OLE , bien que certains objets d'automatisation puissent être utilisés dans des environnements OLE. La confusion trouve ses racines dans la définition antérieure d'OLE par Microsoft, qui était auparavant plus ou moins synonyme de COM.

Pour garantir l'interopérabilité, les interfaces d'automatisation sont limitées à l'utilisation d'un sous-ensemble de tous les types COM. Plus précisément, les interfaces d'automatisation doivent utiliser SAFEARRAY au lieu de tableaux COM bruts.

Les serveurs COM compatibles avec l'automatisation peuvent cependant s'appuyer sur l'implémentation de marshalling OLE intégrée. Cela évite le besoin de projets proxy/stub supplémentaires pour le marshalling hors processus.

L'automatisation a été conçue dans un souci de simplicité de création de scripts. Les contrôleurs fournissent donc souvent des langages tels que Visual Basic for Applications aux utilisateurs finaux, leur permettant de contrôler les objets d'automatisation via des scripts. Les objets d'automatisation sont souvent écrits dans des langages conventionnels tels que C++ , où les attributs C++ peuvent être utilisés pour simplifier le développement, Des langages tels que Visual Basic et Borland Delphi fournissent également une syntaxe pratique pour l'automatisation qui masque la complexité de l'implémentation sous-jacente.

Pour automatiser une application, le développeur d'un contrôleur d'automatisation doit connaître le modèle d'objet utilisé par l'application cible exportant les objets d'activation. Cela nécessite que le développeur de l'application cible documente publiquement son modèle d'objet. Le développement de contrôleurs d'automatisation sans connaissance du modèle d'objet de l'application cible est « difficile, voire impossible ». En raison de ces complications, les composants d'automatisation sont généralement fournis avec des bibliothèques de types , qui contiennent des métadonnées sur les classes, les interfaces et d'autres fonctionnalités exposées par une bibliothèque d'objets. Les interfaces sont décrites dans le langage Microsoft Interface Definition Language . Les bibliothèques de types peuvent être visualisées à l'aide de divers outils, tels que Microsoft OLE/COM Object Viewer ( oleview.exe, partie du Microsoft Platform SDK ) ou l'Object Browser dans Visual Basic (jusqu'à la version 6) et Visual Studio .NET . Les bibliothèques de types sont utilisées pour générer un modèle de proxy / code stub pour l'interopérabilité entre COM et d'autres plates-formes, telles que Microsoft .NET et Java . Par exemple, le SDK .NET Framework comprend des outils qui peuvent générer une DLL proxy .NET pour accéder aux objets Automation en utilisant à la fois une liaison précoce (avec des informations sur les interfaces extraites d'une bibliothèque de types) et une liaison tardive (via IDispatch, mappée sur l'API .NET Reflection), avec le pont .NET-to-COM intégré appelé COM Interop . Bien que Java ne dispose pas de prise en charge COM intégrée, des ensembles d'outils comme JACOB et jSegue peuvent générer du code source proxy (composé de deux parties, un ensemble de classes Java et une source C++ pour une DLL d'interface native Java ) à partir de bibliothèques de types. Ces solutions ne fonctionnent que sous Windows. Une autre bibliothèque j-Interop basée sur Java permet l'interopérabilité avec les composants COM sans JNI , en utilisant le protocole de fil DCOM (MSRPC) et fonctionne également sur les plates-formes non Windows.

Microsoft a documenté publiquement le modèle objet de toutes les applications de Microsoft Office , et certains autres développeurs de logiciels ont également documenté les modèles objet de leurs applications. Les modèles objet sont présentés aux contrôleurs d'automatisation sous forme de bibliothèques de types, avec leurs interfaces décrites en ODL .

L'automatisation est disponible pour une variété de langues, y compris, mais sans s'y limiter :