Modelo de objeto componente

Interfaz binaria de aplicación de Microsoft

COM

Modelo de objeto componente
Estado	En vigor
Publicado por primera vez	1993 ; Hace 28 años ( 1993 )
Ultima versión	Nivel de vida 2021
Organización	Microsoft
Serie	Servicios del sistema
Estándares básicos	MIDL , UUID
Estándares relacionados	reemplazado: DDE construido sobre COM: OLE , OLE Automation , Browser Helper Object , ActiveX , COM + , DCOM , Windows shell , DirectX , UMDF , Windows Runtime
Dominio	Interfaz de componentes
Abreviatura	COM
Sitio web	docs .microsoft .com / en-us / windows / win32 / com / the-component-object-model

El modelo de objetos componentes ( COM ) es un estándar de interfaz binaria para componentes de software introducido por Microsoft en 1993. Se utiliza para permitir la creación de objetos de comunicación entre procesos en una amplia gama de lenguajes de programación . COM es la base de varias otras tecnologías y marcos de Microsoft, incluidos OLE , OLE Automation , Browser Helper Object , ActiveX , COM + , DCOM , el shell de Windows , DirectX , UMDF yTiempo de ejecución de Windows . La esencia de COM es una forma de implementación de objetos neutral en el lenguaje que se puede usar en entornos diferentes de aquel en el que fueron creados, incluso a través de los límites de la máquina. Para componentes bien redactados, COM permite la reutilización de objetos sin conocimiento de su implementación interna, ya que obliga a los implementadores de componentes a proporcionar interfaces bien definidas que están separadas de la implementación. Las diferentes semánticas de asignación de los lenguajes se adaptan al hacer que los objetos sean responsables de su propia creación y destrucción mediante el recuento de referencias . La conversión de tipos de conversión entre diferentes interfaces de un objeto se logra a través de laQueryInterfacemétodo. El método preferido de "herencia" dentro de COM es la creación de subobjetos a los que se delegan las "llamadas" al método.

COM es una tecnología de interfaz definida e implementada como estándar solo en Microsoft Windows y Core Foundation 1.3 de Apple y una interfaz de programación de aplicaciones (API) de complemento posterior . ^[1] Este último solo implementa un subconjunto de toda la interfaz COM. ^[2] Para algunas aplicaciones, COM ha sido reemplazado, al menos hasta cierto punto, por el marco de Microsoft .NET y el soporte para servicios web a través de Windows Communication Foundation (WCF). Sin embargo, los objetos COM se pueden utilizar con todos los lenguajes .NET a través de .NET COM Interop . DCOM en red utiliza formatos propietarios binarios, mientras que WCF fomenta el uso de mensajería SOAP basada en XML . COM es muy similar a otras tecnologías de interfaz de software de componentes , como CORBA y Enterprise JavaBeans , aunque cada una tiene sus propias fortalezas y debilidades. A diferencia de C ++, COM proporciona una interfaz binaria de aplicación (ABI) estable que no cambia entre las versiones del compilador. ^[3] Esto hace que las interfaces COM resulten atractivas para las bibliotecas C ++ orientadas a objetos que deben utilizar los clientes compilados con diferentes versiones del compilador.

Historia

Uno de los primeros métodos de comunicación entre procesos en Windows fue Dynamic Data Exchange (DDE), ^[4] introducido por primera vez en 1987, ^[5] que permitía enviar y recibir mensajes en las llamadas "conversaciones" entre aplicaciones. Antony Williams , quien participó en la creación de la arquitectura COM, luego distribuyó dos artículos internos en Microsoft que abrazaron el concepto de componentes de software: Arquitectura de objetos: Manejo de la seguridad desconocida o de tipos en una biblioteca de clases dinámicamente extensible en 1988 y Sobre la herencia: qué significa y cómo usarlo en 1990. Estos proporcionaron la base de muchas de las ideas detrás de COM.Vinculación e incrustación de objetos (OLE), el primer marco basado en objetos de Microsoft, se creó sobre DDE y se diseñó específicamente para documentos compuestos . Se introdujo con Word para Windows y Excel en 1991, y luego se incluyó con Windows, comenzando con la versión 3.1 en 1992. Un ejemplo de un documento compuesto es una hoja de cálculo incrustada en un documento de Word para Windows: a medida que se realizan cambios en la hoja de cálculo dentro de Excel, aparecen automáticamente dentro del documento de Word.

En 1991, Microsoft introdujo Extensiones de Visual Basic (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 que los objetos se coloquen gráficamente en un formulario y se manipulen mediante propiedades y métodos . Estos fueron posteriormente adaptados para su uso por otros lenguajes como Visual C ++ . En 1992, cuando se lanzó la versión 3.1 de Windows , Microsoft lanzó OLE 2 con su modelo de objetos subyacente . La interfaz binaria de la aplicación COM (ABI) era la misma que la MAPI ABI (lanzada en 1992), y como si estuviera basada en MSRPC y, en última instancia, en laOpen Group 's DCE / RPC . Mientras que OLE 1 se centró en documentos compuestos, COM y OLE 2 se diseñaron para abordar componentes de software en general. Las conversaciones de texto y los mensajes de Windows demostraron no ser lo suficientemente flexibles como para permitir compartir características de la aplicación de una manera robusta y extensible, por lo que COM se creó como una nueva base y OLE cambió a OLE2. En 1994 se introdujeron los controles personalizados OLE (OCX) como el sucesor de los controles VBX. Al mismo tiempo, Microsoft declaró que OLE 2 simplemente se conocería como "OLE", y que OLE ya no era un acrónimo, sino un nombre para todas las tecnologías de componentes de la compañía. A principios de 1996, Microsoft encontró un nuevo uso para los controles personalizados OLE, ampliando la capacidad de su navegador web para presentar contenido,renombrado algunas partes de OLE relacionadas con elInternet " ActiveX ", y gradualmente se renombró todas las tecnologías OLE a ActiveX, excepto la tecnología de documentos compuestos que se usaba en Microsoft Office . Más tarde ese año, Microsoft extendió COM para trabajar en la red con DCOM . ^[6]

Tecnologías relacionadas

COM fue la principal plataforma de desarrollo de software para Windows y, como tal, influyó en el desarrollo de una serie de tecnologías de apoyo. Asimismo, estuvo fuertemente influenciado por tecnologías anteriores.

DDE

COM reemplazó a DDE como la forma preferida de comunicación entre procesos.

DCE / RPC y MSRPC

Como modelo de componentes de varios idiomas, COM se basa en un lenguaje de definición de interfaz, o IDL, para describir los objetos y las funciones asociadas. El COM IDL se basa en gran medida en el DCE / RPC IDL rico en funciones, con extensiones orientadas a objetos. La propia implementación de Microsoft de DCE / RPC, conocida como MSRPC, se usa mucho 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

DCOM ( Distributed COM ) extendió el alcance de COM desde simplemente admitir a un solo usuario con aplicaciones separadas que se comunican en el escritorio de Windows, hasta activar 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 características 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.

COM +

Para que Microsoft brinde 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 (subprocesos), así como para posicionar Windows como una alternativa a otros sistemas operativos de nivel empresarial, Microsoft introdujo una tecnología llamada Microsoft Transaction Server (MTS) en Windows NT 4. Con Windows 2000, esa extensión significativa de COM se incorporó al sistema operativo (a diferencia de la serie de herramientas externas proporcionadas por MTS ) y se renombró COM + . Al mismo tiempo, Microsoft restó importancia a DCOMcomo una entidad separada. Los componentes que hicieron uso de los servicios COM + fueron manejados más directamente por la capa agregada de COM +, en particular por el soporte del sistema operativo para la interceptación. En la primera versión de MTS, se agregó la interceptación: la instalación de un componente MTS modificaría el Registro de Windows para llamar al software MTS, y no al componente directamente. Windows 2000 también revisó la aplicación del panel de control de Servicios de componentes que se usa para configurar los componentes COM +.

Una ventaja de COM + era que se podía ejecutar en "granjas de componentes". Las instancias de un componente, si se codifican correctamente, pueden agruparse y reutilizarse mediante nuevas llamadas a su rutina de inicialización sin descargarlo de la memoria. Los componentes también se pueden distribuir (llamados desde otra máquina). COM + y Microsoft Visual Studio proporcionaron herramientas para facilitar la generación de proxies del lado del cliente, por lo que, aunque se utilizó DCOM para realizar la llamada remota, fue fácil para los desarrolladores. COM + también introdujo un mecanismo de eventos de suscriptor / publicador 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

Artículo principal: .NET Framework

Microsoft .NET proporciona medios tanto para proporcionar tecnología de componentes como para interactuar con COM + (a través de ensamblajes de interoperabilidad COM); .NET proporciona envoltorios para la mayoría de los controles COM de uso común. Microsoft .NET oculta la mayor parte de los detalles de la creación de componentes y, por lo tanto, facilita el desarrollo. .NET puede aprovechar COM + a través del espacio de nombres System.EnterpriseServices, y varios de los servicios que ofrece COM + se han duplicado en versiones recientes de .NET. Por ejemplo, el espacio de nombres System.Transactions en .NET proporciona la clase TransactionScope, que proporciona gestión de transacciones sin recurrir a COM +. Del mismo modo, los componentes en cola pueden ser reemplazados por Windows Communication Foundation con un MSMQtransporte. (Sin embargo, MSMQ es un componente COM nativo). Existe un soporte limitado para la compatibilidad con versiones anteriores. Un objeto COM se puede utilizar en .NET implementando un Runtime Callable Wrapper (RCW). ^{[7] Los} objetos NET que se ajustan a 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 .NET, los objetos que utilizan la otra tecnología aparecen como objetos nativos. Consulte Interoperabilidad COM . WCF (Windows Communication Foundation) alivia una serie de desafíos de ejecución remota de COM. Por ejemplo, permite que los objetos se clasifiquen de manera transparente por valor a través de los límites de procesos o máquinas con mayor facilidad.

Tiempo de ejecución de Windows

Artículo principal: Windows Runtime

El nuevo modelo de aplicación y programación de Windows Runtime (o WinRT, que no debe confundirse con Windows RT ) de Microsoft es esencialmente una API basada en COM, aunque se basa en un COM mejorado. Debido a su base similar a COM, Windows Runtime permite una interfaz relativamente fácil desde múltiples idiomas, tal como lo hace COM, pero es esencialmente una API nativa no administrada. Sin embargo, 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 común permite una sobrecarga significativamente menor que P / Invoke cuando se invoca WinRT desde aplicaciones .NET, y su sintaxis es mucho más simple.

Nano-COM (también conocido como XPCOM)

Nano-COM es un subconjunto importante del modelo de objetos componentes que se centra exclusivamente en los aspectos de interfaz binaria de aplicación (ABI) de COM para permitir llamadas a funciones y métodos en módulos / componentes compilados de forma independiente. Nano-COM se puede expresar fácilmente en un solo archivo de encabezado de C ++ que es portátil para todos los compiladores de C ++. Nano-COM extiende la ABI nativa de la arquitectura de instrucción subyacente y el sistema operativo para agregar soporte para referencias de objetos con tipo (las ABI típicas se enfocan solo en tipos atómicos, estructuras, arreglos y convenciones de llamada de funciones). Mozilla utilizó la base de Nano-COM para arrancar Firefox (llamado XPCOM ), y actualmente se utiliza como tecnología ABI base para DirectX / Direct3D / DirectML .

Un archivo de encabezado Nano-COM define o nombra al menos tres tipos:

• GUID para identificar los tipos de interfaz: este es efectivamente un número de 128 bits
• HRESULT para identificar códigos de error de llamadas a métodos: este es efectivamente un uso estandarizado de entradas de 32 bits a valores bien conocidos (S_OK, E_FAIL, E_OUTOFMEMORY, etc.)
• I Desconocido como el tipo base para todas las referencias de objetos escritas: se trata de funciones virtuales abstractas para admitir la adquisición estilo dynamic_cast <T> de nuevos tipos de interfaz y el recuento de referencias a la shared_ptr <T>

Muchos usos de Nano-COM también definen dos funciones para abordar los búferes de memoria asignados al destinatario como resultados

• <NanoCom> Alloc: lo llaman las implementaciones de métodos para asignar búferes sin procesar (no objetos) que se devuelven al llamador
• <NanoCom> Gratis: llamado por los llamadores del método para liberar búferes asignados a los destinatarios una vez que ya no estén en uso

Algunas implementaciones de Nano-COM, como Direct3D, evitan las funciones de asignación y se limitan a usar únicamente búferes asignados por el llamador.

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 a través de construcciones de lenguaje estándar (por ejemplo, nuevo operador C ++).

Seguridad

Los componentes COM y ActiveX se ejecutan como código nativo en la máquina del usuario, sin espacio aislado. Por lo tanto, existen pocas restricciones sobre lo que puede hacer el código. Por lo tanto, la práctica anterior de incrustar componentes ActiveX en páginas web con Internet Explorer generó problemas con las infecciones de malware . Microsoft reconoció el problema con ActiveX ya en 1996 cuando Charles Fitzgerald dijo: "Nunca afirmamos desde el principio que ActiveX es intrínsecamente seguro". ^[9] Reciente ^{[ ¿cuándo? ]} versiones de Internet Explorer avisan al usuario antes de instalar controles ActiveX, lo que permite al usuario no permitir la instalación de controles desde sitios en los que el usuario no confía. Los controles ActiveX están firmadoscon firmas digitales para garantizar su autenticidad. También es posible deshabilitar los controles ActiveX por completo o permitir solo unos pocos seleccionados. El soporte transparente para servidores COM fuera de proceso aún promueve la seguridad del software en términos de aislamiento de procesos . Esto puede resultar útil para desacoplar subsistemas de gran aplicación 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, solo 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 falso en un subsistema puede dañar aleatoriamente otros subsistemas.

Detalles técnicos

Los programadores COM crean su software utilizando componentes compatibles con COM . Los diferentes tipos de componentes se identifican mediante ID de clase (CLSID), que son identificadores únicos globales (GUID). Cada componente COM expone su funcionalidad a través de una o más interfaces . Las diferentes interfaces admitidas por un componente se distinguen entre sí mediante los ID de interfaz (IID), que también son GUID. Las interfaces COM tienen enlaces en varios lenguajes, como C , C ++ , Visual Basic , Delphi , Python ^{[10] [11]}y varios de los lenguajes de scripting implementados en la plataforma Windows. Todo el acceso a los componentes se realiza a través de los métodos de las interfaces. Esto permite técnicas como la programación entre procesos, o incluso entre computadoras (esta última utilizando el soporte de DCOM).

Interfaces

Todos los componentes COM implementan la interfaz IUnknown ( personalizada ), que expone métodos para el recuento de referencias y la conversión de tipos ( conversión ). Una interfaz IUnknown personalizada consiste en 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 mismo orden en que se declaran en la interfaz. Por lo tanto, la sobrecarga de invocación en proceso es comparable a las llamadas a métodos virtuales en C ++ . Además de las interfaces personalizadas , COM también admite interfaces de envío heredadas de IDispatch. Las interfaces de envío admiten el enlace tardío para la automatización OLE . Esto permite acceder de forma nativa a las interfaces de despacho desde una gama más amplia de lenguajes de programación que las interfaces personalizadas .

Clases

Una clase COM ("coclase") es una implementación concreta de una o más interfaces y se parece mucho a las clases de los lenguajes de programación orientados a objetos. Las clases se crean en función de su ID de clase ( CLSID ) o en función de su cadena de identificación programática ( ProgID ). 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 no se puede acceder a los objetos directamente, sino solo a través de sus interfaces. COM también tiene soporte para múltiples implementaciones de la misma interfaz, de modo que los clientes en tiempo de ejecución pueden elegir qué implementación de una interfaz instanciar.

Lenguaje de definición de interfaz y bibliotecas de tipos

Las bibliotecas de tipos contienen metadatos para representar tipos COM. Estos tipos se describen mediante el lenguaje de definición de interfaz de Microsoft (MSIDL / IDL). Los archivos IDL definen clases orientadas a objetos, interfaces, estructuras, enumeraciones y otros tipos definidos por el usuario de una manera independiente del lenguaje. IDL es similar en apariencia a las declaraciones de C ++ con algunas palabras clave adicionales como "interfaz" y "biblioteca" para definir interfaces y colecciones de clases. IDL también admite el uso de atributos entre corchetes antes de las declaraciones para proporcionar información adicional, como los GUID de interfaz y las relaciones entre los parámetros de puntero y los campos de longitud. Los archivos IDL son compilados por el compilador MIDL. Para C / C ++, el compilador MIDL genera un archivo de encabezado independiente del compilador que contiene definiciones de estructura para coincidir 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 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 remotospara habilitar DCOM para comunicación fuera de proceso. El compilador MIDL también puede compilar archivos IDL en una biblioteca de tipos (TLB). Los archivos TLB contienen metadatos binarios que pueden ser procesados ​​por diferentes compiladores de lenguaje y entornos de ejecución (por ejemplo, VB, Delphi, .NET, etc.) para generar construcciones específicas del lenguaje para representar los tipos COM definidos en el TLB. Para C ++, esto convertirá el TLB de nuevo a su representación IDL.

COM como marco de objetos

Debido a que COM es un marco de tiempo de ejecución, los tipos deben ser identificables y especificables individualmente en tiempo de ejecución. Para lograr esto, se utilizan identificadores únicos globales (GUID). Cada tipo de COM se designa con su propio GUID para su identificación en tiempo de ejecución. Para que la información sobre los tipos COM sea accesible tanto en tiempo de compilación como en tiempo de ejecución, COM utiliza bibliotecas de tipos. Es a través del uso efectivo de bibliotecas de tipos que COM logra sus capacidades como marco dinámico para la interacción de objetos.

Considere la siguiente definición de coclase de ejemplo en un IDL:

coclass SomeClass { [predeterminado] interfaz ISomeInterface;};

El fragmento de código anterior declara una clase COM nombrada SomeClassque implementa una interfaz llamada ISomeInterface.

Esto es conceptualmente equivalente a definir la siguiente clase de C ++:

clase  SomeClass  :  public  ISomeInterface  {  ...  ... };

donde ISomeInterface es una clase virtual pura de C ++ (a veces llamada clase base abstracta).

Los archivos IDL que contienen interfaces y clases COM se compilan en archivos de bibliotecas de tipos (TLB), que los clientes pueden analizar posteriormente en tiempo de ejecución para determinar qué interfaces admite un objeto e invocar los métodos de interfaz de un objeto.

En C ++, los objetos COM se instancian con la CoCreateInstancefunción que toma el ID de clase (CLSID) y el ID de interfaz (IID) como argumentos. La instanciación de SomeClassse puede implementar de la siguiente manera:

ISomeInterface *  interface_ptr  =  NULL ; HRESULT  hr  =  CoCreateInstance ( CLSID_SomeClass ,  NULL ,  CLSCTX_ALL ,  IID_ISomeInterface ,  ( void ** ) & interface_ptr );

En este ejemplo, el subsistema COM se utiliza para obtener un puntero a un objeto que implementa la ISomeInterfaceinterfaz, y se requiere la implementación particular de esta interfaz de la coclase CLSID_SomeClass.

Recuento de referencias

Todos los objetos COM utilizan el recuento de referencias para administrar la vida útil de los objetos. Los recuentos de referencias son controlados por los clientes a través de los métodos AddRef y Release en la interfaz obligatoria IUnknown que implementan todos los objetos COM. Los objetos COM son entonces responsables de liberar su propia memoria cuando el recuento de referencias cae a cero. Ciertos lenguajes (por ejemplo, Visual Basic ) proporcionan un recuento de referencias automático para que los desarrolladores de objetos COM no necesiten mantener explícitamente ningún contador de referencias internas en sus códigos fuente. En C ++, un codificador puede realizar un recuento de referencias explícito o utilizar punteros inteligentes para gestionar automáticamente los recuentos de referencias.

Las siguientes son pautas sobre cuándo llamar a AddRef y Release en objetos COM:

• Las funciones y métodos que devuelven referencias de interfaz (mediante el valor de retorno o mediante el parámetro "out") incrementarán el recuento de referencias del objeto devuelto antes de regresar.
• Se debe llamar a Release en un puntero de interfaz antes de que el puntero se sobrescriba o salga del alcance.
• Si se realiza una copia en un puntero de referencia de interfaz, se debe llamar a AddRef en ese puntero.
• AddRef y Release deben llamarse en la interfaz específica a la que se hace referencia, ya que un objeto puede implementar recuentos de referencia por interfaz para asignar recursos internos solo para las interfaces a las que se hace referencia.

No todas las llamadas de recuento de referencias se envían a objetos remotos a través del cable; un proxy mantiene solo una referencia en el objeto remoto y mantiene su propio recuento de referencias locales. Para simplificar el desarrollo COM, Microsoft introdujo ATL (Active Template Library) para desarrolladores de C ++. ATL proporciona un paradigma de desarrollo COM de nivel superior. También protege a los desarrolladores de aplicaciones de cliente COM de la necesidad de mantener directamente el recuento de referencias, proporcionando objetos de puntero inteligente . Otras bibliotecas y lenguajes que son compatibles con COM incluyen Microsoft Foundation Classes , VC Compiler COM Support, ^[12] VBScript , Visual Basic , ECMAScript ( JavaScript) y Borland Delphi .

Programación

COM es un estándar binario independiente del lenguaje que se puede desarrollar en cualquier lenguaje de programación capaz de comprender e implementar sus tipos de datos e interfaces definidos en binarios. Las implementaciones COM son responsables de entrar y salir del entorno COM, instanciar y contar objetos COM, consultar objetos para interfaces compatibles y manejar errores. El compilador de Microsoft Visual C ++ admite extensiones del lenguaje C ++ denominado Atributos de C ++ . ^[13] Estas extensiones están diseñadas para simplificar el desarrollo COM y eliminar gran parte del código de plomería necesario para implementar servidores COM en C ++. ^[14]

Uso del registro

En Windows, las clases COM, las interfaces y las bibliotecas de tipos se enumeran por GUID en el registro , en HKEY_CLASSES_ROOT \ CLSID para las clases y HKEY_CLASSES_ROOT \ Interface para las interfaces. Las bibliotecas COM utilizan el registro para ubicar las bibliotecas locales correctas para cada objeto COM o la ubicación de red para un servicio remoto.

COM sin registro

Registro libres COM (RegFree COM) es una tecnología introducida con Windows XP que permite Component Object Model (COM) componentes a la activación tienda de metadatos y el CLSID ( Class ID) para el componente sin utilizar el registro . En cambio, los metadatos y CLSID de las clases implementadas en el componente se declaran en un manifiesto de ensamblado (descrito mediante XML ), almacenado como un recurso en el ejecutable o como un archivo separado instalado con el componente. ^[15] Esto permite instalar múltiples versiones del mismo componente en diferentes directorios, descritos por sus propios manifiestos, así como la implementación de XCOPY .^[16] Esta técnica tiene un soporte limitado para servidores COM EXE ^[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 de él 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. Solo si la búsqueda falla, se analiza el registro . ^[dieciséis]

Creación manual de instancias de objetos COM

Los objetos COM también se pueden crear manualmente, dada la ruta del archivo DLL y el GUID del objeto. Esto no requiere que la DLL o GUID se registre en el registro del sistema y no hace uso de archivos de manifiesto. Una DLL COM exporta una función denominada DllGetClassObject. Llamar a DllGetClassObject con el GUID deseado y IID_IClassFactory proporciona una instancia de un objeto de fábrica . El objeto Factory tiene un método CreateInstance, que puede crear instancias de un objeto dado un GUID de interfaz. ^[19] Este es el mismo proceso que se utiliza internamente al crear instancias de componentes COM registrados. ^[20]

Si el objeto COM creado crea una instancia de otro objeto COM utilizando la API CoCreateInstance genérica, intentará hacerlo de la forma genérica habitual, utilizando el registro o los archivos de manifiesto. Pero puede crear objetos internos (que pueden no estar registrados en absoluto) y distribuir referencias a interfaces para ellos, utilizando su propio conocimiento privado.

Transparencia de procesos y redes

Los objetos COM se pueden instanciar y referenciar de forma transparente desde el 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 sobre 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.

Enhebrar

En COM, el subproceso se aborda a través de 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 un solo subproceso (STA) , apartamento de varios subprocesos (MTA) y apartamento de subproceso neutro(N / A). 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 subprocesos 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.

Tipo de apartamento	Descripción
Apartamento de un solo subproceso [22] ( STA ), (ThreadingModel = Apartamento )	Un solo hilo está dedicado a ejecutar los métodos del objeto. En tal disposición, las llamadas a métodos de subprocesos fuera del apartamento son ordenadas y puestas en cola automáticamente por el sistema (a través de una cola de mensajes estándar de Windows). Por lo tanto, el tiempo de ejecución COM proporciona sincronización automática para garantizar que cada llamada al método de un objeto se ejecute siempre hasta su finalización antes de que se invoque otro. Por lo tanto, el desarrollador no necesita preocuparse por el bloqueo de la rosca o las condiciones de carrera.
Apartamento de subprocesos múltiples [23] ( MTA ), (ThreadingModel = Free )	El tiempo de ejecución COM no proporciona sincronización y se permite que varios subprocesos llamen a objetos COM simultáneamente. Por lo tanto, los objetos COM deben realizar su propia sincronización para evitar que el acceso simultáneo desde varios subprocesos provoque una condición de anticipación. Las llamadas a un objeto MTA desde un subproceso en una STA también se calculan.
Apartamento determinado dinámicamente (ThreadingModel = Both )	En el modo de apartamento Ambos , el servidor selecciona automáticamente STA o MTA en la creación del objeto para que coincida con el tipo de apartamento del subproceso que realiza la llamada. [24] Esto puede ser útil para evitar la sobrecarga de cálculo cuando un subproceso STA accede a los servidores MTA.
Apartamento de hilo neutro ( NA ), (ThreadingModel = Neutral )	Un apartamento especial sin hilos asignados. Cuando un subproceso STA o MTA llama a un objeto NA en el mismo proceso, el subproceso que realiza la llamada abandona temporalmente su apartamento y ejecuta código directamente en el NA sin ningún cambio de subproceso. [25] Por lo tanto, se puede pensar en NA como una optimización para llamadas eficientes a métodos entre departamentos.

Los hilos y los 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 del mismo apartamento se realizan directamente sin ayuda de COM. Las llamadas de método realizadas en todos los apartamentos se logran mediante la clasificación. Esto requiere el uso de proxies y stubs.

Críticas

Dado que COM tiene una implementación bastante compleja, los programadores pueden distraerse con algunos de los problemas de "plomería".

Mensaje de bombeo

Cuando se inicializa una STA, crea una ventana oculta que se utiliza para el enrutamiento de mensajes entre departamentos y entre procesos. Esta ventana debe tener su cola de mensajes regularmente "bombeada". Esta construcción se conoce como " bomba de mensajes ". En versiones anteriores de Windows, no hacerlo podría provocar interbloqueos 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 "pérdida" de detalles de implementación.

Recuento de referencias

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 se queden huérfanos. Los objetos también pueden dejarse con recuentos de referencia activos si se utiliza el modelo COM "receptor de eventos". Dado que el objeto que dispara 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 generalmente se rompen usando 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 sola implementación expone dos objetos COM separados (también conocidos como identidades). Esto crea una referencia débil entre los objetos COM, evitando un ciclo de referencia.

DLL Hell

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 pueden 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.

Ver también

• Definición de modelo de objeto multiplataforma multiplataforma de objetos portátiles (informática)
• Modelo de objetos componentes distribuidos (DCOM), extensión que permite que COM funcione en redes
• Common Language Infrastructure Modelo de objetos multiplataforma multiplataforma .NET actual
• Windows Runtime , un modelo de aplicación, versión evolucionada de COM dirigida a Windows 8
• CORBA Common Object Request Broker Architecture, modelo abierto de objetos multiplataforma en varios idiomas
• Modelo de objetos multiplataforma de lenguaje cruzado abierto de D-Bus
• Marco de componentes de KParts KDE
• SOM IBM System Object Model, alternativa rica en funciones a COM
• XPCOM Mozilla Applications Cross Platform Component Object Model
• Enterprise JavaBeans
• Invocación de método remoto de Java
• Motor de comunicaciones de Internet
• Enlace de idioma
• Interfaz de función externa
• Convención de llamadas
• Destrozar nombre
• Interfaz de programación de aplicaciones : API
• Interfaz binaria de aplicación - ABI
• Generador de enlaces de interfaces automáticos de código abierto SWIG de muchos idiomas a otros idiomas

Notas

1. "Archivo de documentación" . developer.apple.com .
2. "Complementos y COM de Microsoft" . Apple Inc. Consultado el 5 de octubre de 2010 .
3. Foro de Microsoft: compatibilidad binaria en las versiones de Visual C ++
4. "Acerca de la red DDE - Aplicaciones de Windows" . Microsoft .com . 30 de mayo de 2018.
5. "La técnica de ejecución de código aprovecha el intercambio dinámico de datos" . McAfee .com . 27 de octubre de 2017.
6. "draft-brown-dcom-v1-spec-03 - Protocolo de modelo de objeto componente distribuido - DCOM / 1.0" . datatracker.ietf.org . Consultado el 29 de agosto de 2019 .
7. rpetrusha. "Contenedor invocable en tiempo de ejecución" . msdn.microsoft.com .
8. rpetrusha. "Envoltura invocable COM" . msdn.microsoft.com .
9. Steinberg, Jill (1 de marzo de 1997). "Los componentes de la competencia hacen que los panelistas sean espinosos" . JavaWorld . Consultado el 16 de julio de 2020 .
10. "Índice de documentación de win32com" . docs.activestate.com .
11. "Python y COM" . www.boddie.org.uk .
12. "Soporte COM del compilador" . MSDN . Microsoft.
13. Microsoft MSDN: referencia de atributos de C ++
14. MSDN Magazine: Atributos de C ++: Haga que la programación COM sea una brisa con una nueva función en Visual Studio .NET
15. "Manifiestos de la asamblea" . MSDN . Consultado el 5 de noviembre de 2009 .
16. Dave Templin. "Simplifique la implementación de aplicaciones con ClickOnce y COM sin registro" . Revista MSDN . Consultado el 22 de abril de 2008 .
17. "Cómo utilizar un servidor COM fuera de proceso sin su archivo tlb" . Consultado el 16 de abril de 2011 .
18. "Conceptos de aplicaciones aisladas y ensamblajes en paralelo" . MSDN . Consultado el 5 de febrero de 2016 .
19. Arkhipov, Mikhail (1 de abril de 2005). "COM sin registro" . Blogs de MSDN . Consultado el 29 de abril de 2016 .
20. "Punto de entrada de DllGetClassObject (COM)" . MSDN . 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.
21. Microsoft MSDN: procesos, subprocesos y apartamentos
22. Microsoft MSDN: apartamentos de un solo subproceso
23. Microsoft MSDN: apartamentos multiproceso
24. Microsoft MSDN: comprensión y uso de modelos de subprocesos COM
25. Codeguru: Comprensión de apartamentos COM

Referencias

• "COM: Una breve introducción (powerpoint)" . Consultado el 7 de marzo de 2006 .
• Box, Don (1998). COM esencial . Addison-Wesley. ISBN 978-0-201-63446-4.
• Chappell, David (1996). Comprensión de ActiveX y OLE . Microsoft Press. ISBN 978-1-57231-216-6.
• "Integración y Migración de servicios COM + a WCF" . Consultado el 15 de abril de 2010 .

Enlaces externos

• Modelo de objetos componentes en MSDN
• Entrevista con Tony Williams, co-inventor de COM (Webcast de video, agosto de 2006)
• Información: diferencia entre controles OLE y controles ActiveX de Microsoft
• Especificación de formato de datos TypeLib (no oficial) con utilidad de descarga de código abierto.
• El glosario COM / DCOM