El modelo de objetos componentes ( COM ) es una tecnología de interfaz binaria para componentes de software de Microsoft que permite utilizar objetos de forma neutral en cuanto al lenguaje entre diferentes lenguajes de programación , contextos de programación, procesos y máquinas .
COM es la base para otras tecnologías de componentes específicos del dominio de Microsoft, incluidas OLE , OLE Automation , ActiveX , COM+ y DCOM , así como implementaciones como DirectX , Windows Shell , UMDF , Windows Runtime y Browser Helper Object .
COM permite el uso de objetos con sólo conocer su interfaz; no su implementación interna. El implementador del componente define interfaces que están separadas de la implementación.
El soporte para múltiples contextos de programación se maneja confiando en el objeto para aspectos que serían difíciles de implementar como instalación. La compatibilidad con múltiples usos de un objeto se logra exigiendo que cada objeto se destruya a sí mismo mediante el recuento de referencias . Cada objeto también proporciona acceso a las interfaces de un objeto (similar a la conversión de tipo ).
COM está disponible sólo en Microsoft Windows y en la interfaz de programación de aplicaciones (API) de complemento Core Foundation 1.3 de Apple . [1] Este último solo implementa un subconjunto de toda la interfaz COM. [2]
Con el tiempo, COM está siendo reemplazado por otras tecnologías como Microsoft .NET y servicios web (es decir, a través de WCF ). Sin embargo, los objetos COM se pueden utilizar en un lenguaje .NET a través de COM Interop .
COM es similar a otras tecnologías de componentes como SOM , CORBA y Enterprise JavaBeans , aunque cada una tiene sus fortalezas y debilidades.
A diferencia de C++ , COM proporciona una interfaz binaria de aplicación (ABI) estable que no se ve afectada por las diferencias del compilador. [3] Esto hace que el uso de COM sea ventajoso para bibliotecas C++ orientadas a objetos que van a ser utilizadas por clientes compilados a través de diferentes compiladores.
Introducido en 1987, el intercambio dinámico de datos (DDE) fue una de las primeras tecnologías de comunicación entre procesos en Windows . [4] [5] Permitía enviar y recibir mensajes en las llamadas conversaciones entre aplicaciones.
Antony Williams, involucrado en la arquitectura de COM, distribuyó dos artículos dentro de Microsoft que abrazaban el concepto de componentes de software: Arquitectura de objetos: cómo lidiar con lo desconocido – o – seguridad de tipos en una biblioteca de clases dinámicamente extensible en 1988 y Sobre la herencia: qué significa y cómo To Use It en 1990. Estos proporcionaron la base de muchas de las ideas detrás de COM.
Object Linking and Embedding (OLE), el primer marco basado en objetos de Microsoft, se creó en DDE y se diseñó específicamente para documentos compuestos . Se introdujo con Word y Excel en 1991 y luego se incluyó con Windows, a partir de la versión 3.1 en 1992. Un ejemplo de documento compuesto es una hoja de cálculo incrustada en un documento de Word. A medida que se realizan cambios en la hoja de cálculo en Excel, aparecen automáticamente en el documento de Word.
En 1991, Microsoft introdujo la tecnología Visual Basic Extension (VBX) con Visual Basic 1.0. Un VBX es una extensión empaquetada en forma de biblioteca de vínculos dinámicos (DLL) que permite colocar gráficamente objetos en un formulario y manipularlos mediante propiedades y métodos . Posteriormente se adaptaron para su uso en otros lenguajes como Visual C++ .
En 1992, con Windows 3.1 , Microsoft lanzó OLE 2 con su nuevo modelo de objetos subyacente , COM. La interfaz binaria de la aplicación COM (ABI) era la misma que la MAPI ABI (lanzada en 1992) y estaba basada en MSRPC y, en última instancia, en DCE/RPC de Open Group . COM se creó para reemplazar DDE ya que su conversación basada en texto y el diseño de mensajería de Windows no eran lo suficientemente flexibles como para permitir compartir funciones de aplicaciones de una manera sólida y extensible.
En 1994, se introdujo la tecnología de control personalizado OLE (OCX), basada en COM, como sucesora de VBX. Al mismo tiempo, Microsoft afirmó que OLE 2 se conocería simplemente como "OLE".
A principios de 1996, Microsoft encontró un nuevo uso para OCX: ampliar la capacidad de su navegador web. Microsoft cambió el nombre de algunas partes de OLE relacionadas con Internet a ActiveX y gradualmente cambió el nombre de todas las tecnologías OLE a ActiveX, excepto la tecnología de documentos compuestos que se usaba en Microsoft Office .
Más tarde, en 1996, Microsoft amplió COM para que funcione en toda la red con DCOM . [6]
COM IDL se basa en DCE/RPC IDL, rico en funciones, con extensiones orientadas a objetos. La implementación de Microsoft de DCE/RPC, MSRPC , se utiliza como el principal mecanismo de comunicación entre procesos para los servicios y componentes internos de Windows NT, lo que la convierte en una elección obvia de base.
DCOM amplía COM desde el simple soporte de un único usuario con aplicaciones separadas que se comunican en el escritorio de Windows, hasta la activación de objetos que se ejecutan en diferentes contextos de seguridad y en diferentes máquinas a través de la red. Con esto se agregaron las funciones necesarias para configurar qué usuarios tienen autoridad para crear, activar y llamar objetos, para identificar al usuario que llama, así como especificar el cifrado requerido para la seguridad de las llamadas.
Microsoft introdujo Microsoft Transaction Server (MTS) en Windows NT 4 para brindar a los desarrolladores soporte para transacciones distribuidas , agrupación de recursos, aplicaciones desconectadas, publicación y suscripción de eventos, mejor administración de memoria y procesador (hilos), así como para posicionar a Windows como una alternativa a otros sistemas operativos de nivel empresarial.
Renombrado como COM+ en Windows 2000, el conjunto de funciones se incorporó al sistema operativo a diferencia de la serie de herramientas externas proporcionadas por MTS. Al mismo tiempo, Microsoft restó importancia a DCOM como entidad separada. Los componentes que usaban COM+ fueron manejados más directamente por la capa agregada de COM+; en particular mediante el soporte del sistema operativo para la interceptación. En la primera versión de MTS, se añadió la interceptación: la instalación de un componente de MTS modificaría el Registro de Windows para llamar al software MTS, y no al componente directamente.
Windows 2000 incluyó actualizaciones del panel de control de Servicios de componentes para configurar componentes COM+.
Una ventaja de COM+ era que podía ejecutarse en "granjas de componentes". Las instancias de un componente, si se codifican correctamente, podrían agruparse y reutilizarse mediante nuevas llamadas a su rutina de inicialización sin descargarlas de la memoria. Los componentes también podrían distribuirse (llamarse desde otra máquina). COM+ y Microsoft Visual Studio proporcionaron herramientas para facilitar la generación de servidores proxy del lado del cliente, por lo que, aunque se utilizó DCOM para realizar la llamada remota, fue fácil de hacer para los desarrolladores. COM+ también introdujo un mecanismo de eventos de suscriptor/editor llamado Eventos COM+ y proporcionó una nueva forma de aprovechar MSMQ (una tecnología que proporciona mensajería asincrónica entre aplicaciones) con componentes llamados Componentes en cola . Los eventos COM+ amplían el modelo de programación COM+ para admitir eventos de enlace tardío (consulte Enlace tardío ) o llamadas a métodos entre el editor o suscriptor y el sistema de eventos.
.NET es la tecnología de componentes de Microsoft que reemplaza a COM. .NET oculta muchos detalles de la creación de componentes y, por tanto, facilita el desarrollo.
.NET proporciona contenedores para controles COM de uso común.
.NET puede aprovechar COM+ a través del System.EnterpriseServicesespacio de nombres y varios de los servicios que proporciona COM+ se han duplicado en .NET. Por ejemplo, el System.Transactionsespacio de nombres proporciona la TransactionScopeclase, que proporciona gestión de transacciones sin recurrir a COM+. De manera similar, Windows Communication Foundation (WCF) puede reemplazar los componentes en cola con un transporte MSMQ .
Hay soporte limitado para la compatibilidad con versiones anteriores. Se puede utilizar un objeto COM en .NET implementando un Runtime Callable Wrapper (RCW). [7] Los objetos NET que cumplen con ciertas restricciones de interfaz se pueden usar en objetos COM llamando a un contenedor invocable COM (CCW). [8] Tanto desde el lado COM como desde el lado .NET, los objetos que utilizan la otra tecnología aparecen como objetos nativos. Consulte Interoperabilidad COM .
WCF facilita una serie de desafíos de ejecución remota de COM. Por ejemplo, permite ordenar de forma transparente los objetos por valor a través de los límites del proceso o de la máquina con mayor facilidad.
Windows Runtime ( WinRT ) es una API basada en COM, aunque es una variante COM mejorada. Debido a su base similar a COM, WinRT admite la interfaz desde múltiples contextos de programación, pero es una API nativa no administrada. Las definiciones de API se almacenan en archivos ".winmd", que están codificados en formato de metadatos ECMA 335; el mismo formato de metadatos CLI que utiliza .NET con algunas modificaciones. Este formato de metadatos permite una sobrecarga significativamente menor que P/Invoke cuando se invoca WinRT desde aplicaciones .NET.
Nano-COM es un subconjunto de COM centrado en los aspectos de la interfaz binaria de aplicación (ABI) de COM que permiten llamadas a funciones y métodos a través de módulos/componentes compilados de forma independiente. Nano-COM se puede expresar en un archivo de encabezado C++ portátil. Nano-COM extiende la ABI nativa de la arquitectura de instrucciones subyacente y el sistema operativo para admitir referencias de objetos escritos, mientras que una ABI típica se centra en tipos atómicos, estructuras, matrices y convenciones de llamada de funciones.
Un archivo de encabezado Nano-COM define o nombra al menos tres tipos:
dynamic_cast<T>la adquisición de nuevos tipos de interfaz y el recuento de referencias a lashared_ptr<T>Muchos usos de Nano-COM definen dos funciones para abordar los buffers de memoria asignados al destinatario como resultados:
Algunas implementaciones de Nano-COM, como Direct3D, evitan las funciones de asignación y se limitan a utilizar únicamente buffers asignados por la persona que llama.
Nano-COM no tiene noción de clases, apartamentos, clasificación, registro, etc. Más bien, las referencias a objetos simplemente se pasan a través de los límites de las funciones y se asignan mediante construcciones de lenguaje estándar (por ejemplo, newoperador C++).
Mozilla utilizó la base Nano-COM para iniciar Firefox (llamado XPCOM ) y actualmente se utiliza como tecnología ABI base para DirectX / Direct3D / DirectML .
Dado que un control ActiveX (cualquier componente COM) se ejecuta como código nativo, sin protección de espacio aislado , existen pocas restricciones sobre lo que puede hacer. El uso de componentes ActiveX, compatibles con Internet Explorer , en una página web provoca problemas de infección de malware . Microsoft reconoció el problema ya en 1996, cuando Charles Fitzgerald dijo: "Nunca afirmamos desde el principio que ActiveX sea intrínsecamente seguro". [9] Las versiones posteriores de Internet Explorer avisan al usuario antes de instalar un control ActiveX, lo que les permite bloquear la instalación.
Como nivel de protección, un control ActiveX está firmado con una firma digital para garantizar la autenticidad.
También es posible desactivar los controles ActiveX por completo o permitir sólo unos pocos seleccionados.
El soporte transparente para servidores COM fuera de proceso promueve la seguridad del software en términos de aislamiento de procesos . Esto puede resultar útil para desacoplar subsistemas de aplicaciones grandes en procesos separados. El aislamiento de procesos limita la corrupción del estado en un proceso para que no afecte negativamente la integridad de los otros procesos, ya que solo se comunican a través de interfaces estrictamente definidas. Por lo tanto, sólo es necesario reiniciar el subsistema afectado para recuperar el estado válido. Este no es el caso de los subsistemas dentro del mismo proceso, donde un puntero no autorizado en un subsistema puede corromper aleatoriamente otros subsistemas.
COM se admite mediante enlaces en varios lenguajes, como C , C++ , Visual Basic , Delphi , Python [10] [11] y varios de los contextos de secuencias de comandos de Windows. El acceso a los componentes se realiza a través de métodos de interfaz . Esto permite llamadas directas durante el proceso y a través del acceso al subsistema COM/DCOM entre procesos y computadoras.
Una coclase , una clase COM, implementa una o más interfaces. Se identifica mediante un ID de clase, denominado CLSID , que es GUID , y mediante un identificador programático legible por humanos , denominado ProgID . Una coclase se crea a través de uno de estos identificadores.
Cada interfaz COM extiende la IUnknowninterfaz, lo que expone métodos para el recuento de referencias y para acceder a las otras interfaces del objeto, similar a la conversión de tipos , también conocida como conversión de tipos.
Una interfaz se identifica mediante un ID de interfaz (IID), un GUID.
Una interfaz personalizada , cualquier cosa derivada de IUnknown, proporciona acceso enlazado temprano a través de un puntero a una tabla de métodos virtuales que contiene una lista de punteros a las funciones que implementan las funciones declaradas en la interfaz, en el orden en que se declaran. Por lo tanto, una sobrecarga de invocación en proceso es comparable a una llamada a un método virtual de C++.
El envío, también conocido como acceso tardío , se proporciona mediante la implementación de IDispatch. El envío permite el acceso desde una gama más amplia de contextos de programación que una interfaz personalizada.
Como muchos lenguajes orientados a objetos, COM proporciona una separación entre la interfaz y la implementación. Esta distinción es especialmente fuerte en COM donde un objeto no tiene una interfaz predeterminada. Un cliente debe solicitar una interfaz para tener acceso. COM admite múltiples implementaciones de la misma interfaz, de modo que los clientes pueden elegir qué implementación de una interfaz usar.
Una biblioteca de tipos COM define metadatos COM, como coclases e interfaces. Una biblioteca se puede definir como lenguaje de definición de interfaz (IDL); una sintaxis independiente del lenguaje de programación. IDL es similar a C++ con sintaxis adicional para definir interfaces y coclases. IDL también admite atributos entre corchetes antes de las declaraciones para definir metadatos como identificadores y relaciones entre parámetros.
Un archivo IDL se compila mediante el compilador MIDL. Para usar con C/C++, el compilador MIDL genera un archivo de encabezado con structdefiniciones que coinciden con los vtbls de las interfaces declaradas y un archivo C que contiene declaraciones de los GUID de la interfaz . El compilador MIDL también puede generar el código fuente C++ para un módulo proxy. Este proxy contiene códigos auxiliares de métodos para convertir llamadas COM en llamadas a procedimientos remotos para habilitar DCOM para la comunicación fuera de proceso.
MIDL puede generar una biblioteca de tipos binarios (TLB) que otras herramientas pueden utilizar para admitir el acceso desde otros contextos.
El siguiente código IDL declara una coclase denominada SomeClassque implementa una interfaz denominada ISomeInterface.
coclass SomeClass { [predeterminado] interfaz ISomeInterface;};Esto es conceptualmente equivalente al siguiente código C++ donde ISomeInterface es una clase virtual pura , también conocida como clase base abstracta.
clase ISomeInterface {}; clase AlgunaClase : pública IAlgunaInterfaz { }; En C++, los objetos COM se crean instancias a través de la CoCreateInstancefunción del subsistema COM que toma el CLSID y el IID. SomeClassse puede crear de la siguiente manera:
ISomeInterface * interface_ptr = NULL ; HRESULT hr = CoCreateInstance ( CLSID_SomeClass , NULL , CLSCTX_ALL , IID_ISomeInterface , ( void ** ) & interface_ptr ); Un objeto COM utiliza el recuento de referencias para gestionar la vida útil del objeto. Los clientes controlan el recuento de referencias de un objeto a través de los métodos IUnknown AddRefy Release. Los objetos COM son responsables de liberar su propia memoria cuando el recuento de referencias cae a cero. Algunos contextos de programación (por ejemplo, Visual Basic ) proporcionan un recuento automático de referencias para simplificar el uso de objetos. En C++, se puede utilizar un puntero inteligente para automatizar la gestión del recuento de referencias.
Las siguientes son pautas sobre cuándo se debe llamar a AddRef y Release :
Para objetos remotos, no todas las llamadas de recuento de referencias se envían por cable. Un proxy mantiene solo una referencia en el objeto remoto y mantiene su propio recuento de referencias locales.
Para simplificar el desarrollo COM para los desarrolladores de C++, Microsoft introdujo ATL (Active Template Library) . ATL proporciona un paradigma de desarrollo COM de nivel relativamente alto. También protege a los desarrolladores de aplicaciones cliente COM de la necesidad de mantener directamente el recuento de referencias al proporcionar tipos de punteros inteligentes . Otras bibliotecas y lenguajes compatibles con COM incluyen Microsoft Foundation Classes , VC Compiler COM Support, [12] VBScript , Visual Basic , ECMAScript ( JavaScript ) y Borland Delphi .
COM es un estándar binario independiente del lenguaje que permite utilizar objetos en cualquier contexto de programación capaz de acceder a sus interfaces binarias.
El software cliente COM es responsable de habilitar el subsistema COM, crear instancias y contar referencias de objetos COM y consultar objetos para interfaces compatibles.
El compilador de Microsoft Visual C++ admite extensiones del lenguaje C++, denominadas Atributos de C++ , [13] que están diseñadas para simplificar el desarrollo de COM y minimizar el código repetitivo necesario para implementar servidores COM en C++. [14]
Originalmente, era necesario almacenar los metadatos de la biblioteca de tipos en el registro del sistema. Un cliente COM usaría la información del registro para la creación de objetos.
COM sin registro (RegFree) se introdujo con Windows XP para permitir almacenar metadatos de biblioteca de tipos como un manifiesto de ensamblaje, ya sea como un recurso en el archivo ejecutable o en un archivo separado instalado con el componente. [15] Esto permite instalar múltiples versiones del mismo componente en la misma computadora, en diferentes directorios. Y permite la implementación de XCOPY . [16] Esta tecnología tiene soporte limitado para servidores EXE COM [17] y no se puede utilizar para componentes de todo el sistema como MDAC , MSXML , DirectX o Internet Explorer .
Durante la carga de la aplicación, el cargador de Windows busca el manifiesto. [18] Si está presente, el cargador agrega información del mismo al contexto de activación. [16] Cuando la fábrica de clases COM intenta crear una instancia de una clase, primero se verifica el contexto de activación para ver si se puede encontrar una implementación para el CLSID. Sólo si la búsqueda falla, se analiza el registro . [dieciséis]
Se puede crear un objeto COM sin información de la biblioteca de tipos; con solo una ruta al archivo DLL y CLSID. Un cliente puede utilizar la función COM DLL DllGetClassObjectcon CLSID e IID_IClassFactory para crear una instancia de un objeto de fábrica . Luego, el cliente puede usar los objetos de fábrica CreateInstancepara crear una instancia. [19] Este es el mismo proceso que utiliza el subsistema COM. [20] Si un objeto creado de esta manera crea otro objeto, lo hará de la forma habitual (usando el registro o manifiesto). Pero puede crear objetos internos (que pueden no estar registrados en absoluto) y entregarles referencias a interfaces, utilizando su propio conocimiento privado.
Un objeto COM se puede crear y utilizar de forma transparente desde dentro del mismo proceso (en proceso), a través de los límites del proceso (fuera de proceso) o de forma remota a través de la red (DCOM). Los objetos remotos y fuera de proceso utilizan la clasificación para serializar llamadas a métodos y devolver valores a través de los límites del proceso o de la red. Esta clasificación es invisible para el cliente, que accede al objeto como si fuera un objeto local en proceso.
En COM, el subproceso se aborda mediante un concepto conocido como apartamentos . [21] Un objeto COM individual vive exactamente en un apartamento, que puede ser de un solo subproceso o de varios subprocesos. Hay tres tipos de apartamentos en COM: apartamento de subproceso único (STA) , apartamento de subprocesos múltiples (MTA) y apartamento de subproceso neutro (NA). Cada apartamento representa un mecanismo mediante el cual el estado interno de un objeto puede sincronizarse a través de múltiples subprocesos. Un proceso puede constar de varios objetos COM, algunos de los cuales pueden usar STA y otros pueden usar MTA. Todos los hilos que acceden a objetos COM viven de manera similar en un apartamento. La elección del apartamento para subprocesos y objetos COM se determina en tiempo de ejecución y no se puede cambiar.
Los hilos y objetos que pertenecen al mismo apartamento siguen las mismas reglas de acceso a los hilos. Por lo tanto, las llamadas a métodos que se realizan dentro de la misma vivienda se realizan directamente sin ayuda de COM. Las llamadas a métodos realizadas entre apartamentos se logran mediante clasificación. Esto requiere el uso de proxies y stubs.
COM es relativamente complejo, especialmente en comparación con tecnologías de componentes más modernas como .NET.
Cuando se inicializa una STA, crea una ventana oculta que se utiliza para el enrutamiento de mensajes entre apartamentos y entre procesos. Esta ventana debe tener su cola de mensajes "bombeada" periódicamente. Esta construcción se conoce como " bomba de mensajes ". En versiones anteriores de Windows, no hacerlo podría provocar bloqueos en todo el sistema. Este problema se complica por algunas API de Windows que inicializan COM como parte de su implementación, lo que provoca una "fuga" de detalles de implementación.
El recuento de referencias dentro de COM puede causar problemas si se hace referencia circular a dos o más objetos . El diseño de una aplicación debe tener esto en cuenta para que los objetos no queden huérfanos. Los objetos también pueden quedar con recuentos de referencia activos si se utiliza el modelo COM "receptor de eventos". Dado que el objeto que desencadena el evento necesita una referencia al objeto que reacciona al evento, el recuento de referencias de este último nunca llegará a cero. Los ciclos de referencia normalmente se rompen mediante terminación fuera de banda o identidades divididas. En la técnica de terminación fuera de banda, un objeto expone un método que, cuando se llama, lo obliga a eliminar sus referencias a otros objetos, rompiendo así el ciclo. En la técnica de identidad dividida, una única implementación expone dos objetos COM separados (también conocidos como identidades). Esto crea una referencia débil entre los objetos COM, lo que impide un ciclo de referencia.
Debido a que los componentes COM en proceso se implementan en archivos DLL y el registro solo permite una única versión por CLSID, en algunas situaciones podrían estar sujetos al efecto " DLL Hell ". La capacidad COM sin registro elimina este problema para los componentes en proceso; COM sin registro no está disponible para servidores fuera de proceso.
Si una llamada a la función CoGetClassObject encuentra el objeto de clase que se va a cargar en una DLL, CoGetClassObject utiliza la función DllGetClassObject exportada de la DLL.