En la programación de aplicaciones de Microsoft Windows , OLE Automation (posteriormente renombrada simplemente como Automation [1] [2] ) es un mecanismo de comunicación entre procesos creado por Microsoft . Se basa en un subconjunto del Modelo de objetos componentes (COM) que fue pensado para su uso por lenguajes de scripting (originalmente Visual Basic), pero ahora es usado por varios lenguajes en Windows. Todos los objetos de automatización deben implementar la interfaz IDispatch . Proporciona una infraestructura mediante la cual las aplicaciones llamadas controladores de automatización pueden acceder y manipular (es decir, establecer propiedades o llamar métodos) objetos de automatización compartidos que son exportados por otras aplicaciones. Reemplaza a Dynamic Data Exchange (DDE), un mecanismo más antiguo para que las aplicaciones se controlen entre sí. [3] Al igual que con DDE, en OLE Automation el controlador de automatización es el "cliente" y la aplicación que exporta los objetos de automatización es el "servidor".
Al contrario de lo que sugiere su nombre, los objetos de automatización no necesariamente utilizan Microsoft OLE , aunque algunos objetos de automatización se pueden utilizar en entornos OLE. La confusión tiene su origen en la definición anterior de OLE de Microsoft, que antes era más o menos un sinónimo de COM.
Para garantizar la interoperabilidad, las interfaces de automatización están limitadas a utilizar un subconjunto de todos los tipos COM. [4] [5] Específicamente, las interfaces de automatización deben utilizar SAFEARRAY en lugar de matrices COM sin procesar.
Sin embargo, los servidores COM compatibles con la automatización pueden confiar en la implementación de serialización OLE incorporada. [6] Esto evita la necesidad de proyectos proxy/stub adicionales para serialización fuera de proceso.
La automatización se diseñó teniendo en mente la facilidad de creación de scripts, por lo que los controladores suelen proporcionar lenguajes como Visual Basic para aplicaciones a los usuarios finales, lo que les permite controlar objetos de automatización a través de scripts. Los objetos de automatización suelen escribirse en lenguajes convencionales como C++ , [7] donde se pueden usar atributos de C++ para simplificar el desarrollo, [8] Lenguajes como Visual Basic y Borland Delphi también proporcionan una sintaxis conveniente para la automatización que oculta la complejidad de la implementación subyacente.
Para automatizar una aplicación, el desarrollador de un controlador de automatización debe conocer el modelo de objetos que utiliza la aplicación de destino que exporta objetos de activación. [9] Esto requiere que el desarrollador de la aplicación de destino documente públicamente su modelo de objetos. El desarrollo de controladores de automatización sin el conocimiento del modelo de objetos de la aplicación de destino es "difícil o imposible". [10]
Debido a estas complicaciones, los componentes de automatización suelen estar provistos de bibliotecas de tipos , que contienen metadatos sobre clases, interfaces y otras características expuestas por una biblioteca de objetos. Las interfaces se describen en el Lenguaje de definición de interfaz de Microsoft . Las bibliotecas de tipos se pueden ver utilizando varias herramientas, como el Visor de objetos OLE/COM de Microsoft ( oleview.exe, parte del SDK de la plataforma Microsoft ) o el Explorador de objetos en Visual Basic (hasta la versión 6) y Visual Studio .NET . Las bibliotecas de tipos se utilizan para generar patrones de proxy / código auxiliar para interoperar entre COM y otras plataformas, como Microsoft .NET y Java . Por ejemplo, el .NET Framework SDK incluye herramientas que pueden generar una DLL proxy .NET para acceder a objetos de Automation utilizando tanto el enlace temprano (con información sobre interfaces extraídas de una biblioteca de tipos) como el enlace tardío (a través de IDispatch, asignado a la API .NET Reflection), con el puente .NET-a-COM integrado llamado COM Interop . [11] Si bien Java carece de soporte COM integrado, conjuntos de herramientas como JACOB [12] y jSegue [13] pueden generar código fuente proxy (que consta de dos partes, un conjunto de clases Java y una fuente C++ para una DLL de interfaz nativa Java ) a partir de bibliotecas de tipos. Estas soluciones solo funcionan en Windows. Otra biblioteca j-Interop [14] basada en Java que permite la interoperabilidad con componentes COM sin JNI , utilizando el protocolo de cable DCOM (MSRPC) y también funciona en plataformas que no son Windows.
Microsoft ha documentado públicamente el modelo de objetos de todas las aplicaciones de Microsoft Office [ 15] y algunos otros desarrolladores de software también han documentado los modelos de objetos de sus aplicaciones. Los modelos de objetos se presentan a los controladores de automatización como bibliotecas de tipos, con sus interfaces descritas en ODL .
La automatización está disponible para una variedad de idiomas, incluidos, entre otros: