Modelo de objetos de componentes

El lenguaje COM IDL se basa en el lenguaje DCE/RPC IDL, rico en funcionalidades, con extensiones orientadas a objetos. La implementación de DCE/RPC de Microsoft, MSRPC , se utiliza como mecanismo principal de comunicación entre procesos para los servicios y componentes internos de Windows NT, lo que la convierte en una base obvia.

DCOM extiende COM, pasando de simplemente admitir un único usuario con aplicaciones independientes que se comunican en el escritorio de Windows, a activar objetos que se ejecutan bajo diferentes contextos de seguridad y en distintas máquinas de la red. Con ello se añadieron las funciones necesarias para configurar qué usuarios tienen autorización para crear, activar y llamar a objetos, para identificar al usuario que realiza la llamada y para especificar el cifrado necesario para la seguridad de las llamadas.

Microsoft introdujo Microsoft Transaction Server (MTS) en Windows NT 4 con el fin de proporcionar 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 a Windows como una alternativa a otros sistemas operativos de nivel empresarial.

Renombrado como COM+ en Windows 2000, el conjunto de características se integró en el sistema operativo, a diferencia de la serie de herramientas externas proporcionadas por MTS. Al mismo tiempo, Microsoft restó importancia a DCOM como entidad independiente. Los componentes que utilizaban COM+ se gestionaban de forma más directa mediante la capa adicional de COM+, en particular mediante la compatibilidad del sistema operativo con la interceptación. En la primera versión de MTS, la interceptación se añadió posteriormente : al instalar un componente de MTS, se modificaba el Registro de Windows para que llamara al software de MTS, y no directamente al componente.

Windows 2000 incluía actualizaciones del panel de control de Servicios de componentes para configurar los componentes COM+.

Una ventaja de COM+ era que podía ejecutarse en "granjas de componentes". Las instancias de un componente, si estaban codificadas correctamente, podían agruparse y reutilizarse mediante nuevas llamadas a su rutina de inicialización sin descargarlas de la memoria. Los componentes también podían distribuirse (llamarse desde otra máquina). COM+ y Microsoft Visual Studio proporcionaban herramientas para facilitar la generación de proxies del lado del cliente, por lo que, aunque se utilizaba DCOM para realizar la llamada remota, resultaba sencillo 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 asíncrona entre aplicaciones) con componentes llamados Componentes en cola . Los eventos COM+ extienden el modelo de programación COM+ para admitir eventos de enlace tardío (véase Enlace tardío ) o llamadas a métodos entre el publicador 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 lo tanto, facilita el desarrollo.

.NET proporciona adaptadores para controles COM de uso común.

.NET puede aprovechar COM+ mediante el System.EnterpriseServicesespacio de nombres, y varios de los servicios que ofrece COM+ se han replicado en .NET. Por ejemplo, el System.Transactionsespacio de nombres proporciona la TransactionScopeclase, que ofrece gestión de transacciones sin necesidad de recurrir a COM+. Del mismo modo, los componentes en cola pueden sustituirse por Windows Communication Foundation (WCF) con un transporte MSMQ .

Existe un soporte limitado para la retrocompatibilidad. Un objeto COM puede usarse en .NET implementando un Runtime Callable Wrapper (RCW). ^{[ 11 ]} Los objetos NET que cumplen con ciertas restricciones de interfaz pueden usarse en objetos COM llamando a un COM Callable Wrapper (CCW). ^{[ 12 ]} Tanto desde el lado de COM como de .NET, los objetos que usan la otra tecnología aparecen como objetos nativos. Consulte Interop COM .

WCF facilita la solución de varios problemas de ejecución remota de COM. Por ejemplo, permite que los objetos se transfieran de forma transparente por valor a través de los límites de procesos o máquinas con mayor facilidad.

Windows Runtime ( WinRT ) es una API basada en COM, aunque una variante mejorada. Gracias a su arquitectura similar a COM, WinRT admite la interfaz desde múltiples contextos de programación, pero se trata de una API nativa no administrada. Las definiciones de la API se almacenan en archivos ".winmd", codificados en formato de metadatos ECMA 335, el mismo formato de metadatos de la CLI que utiliza .NET con algunas modificaciones. Este formato de metadatos permite una sobrecarga significativamente menor que P/Invoke cuando WinRT se invoca desde aplicaciones .NET.

Nano-COM es un subconjunto de COM centrado en los aspectos de la interfaz binaria de la aplicación (ABI) que permiten realizar llamadas a funciones y métodos entre módulos/componentes compilados de forma independiente. Nano-COM se puede expresar en un archivo de cabecera C++ portable. Nano-COM extiende la ABI nativa de la arquitectura de instrucciones y el sistema operativo subyacentes para admitir referencias a objetos tipados , mientras que una ABI típica se centra en tipos atómicos, estructuras, matrices y convenciones de llamada a funciones.

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

• GUID : identifica un tipo de interfaz.

• HRESULT : códigos de resultado del método, como S_OK, E_FAIL, E_OUTOFMEMORY

• IUnknown : tipo base para referencias a objetos; funciones virtuales abstractas para admitir dynamic_cast<T>la adquisición de nuevos tipos de interfaz y el conteo de referencias al estilo de lashared_ptr<T>

Muchos usos de Nano-COM definen dos funciones para acceder a los búferes de memoria asignados por la función llamada como resultados:

• <NanoCom>Alloc : llamado por las implementaciones de métodos para asignar búferes sin procesar (no objetos) que se devuelven al llamador.

• <NanoCom>Free : llamada por quienes llaman a un método para liberar los búferes asignados por la función llamada cuando ya no están en uso.

Algunas implementaciones de Nano-COM, como Direct3D, prescinden de las funciones de asignación de memoria y se limitan a utilizar únicamente búferes asignados por quien realiza la llamada.

Nano-COM no tiene noción de clases, apartamentos, serialización, registro, etc. En cambio, las referencias a objetos simplemente se pasan entre límites de funciones y se asignan mediante construcciones de lenguaje estándar (por ejemplo, newel operador C++).

Nano-COM se utiliza actualmente 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 aislamiento (sandboxing ), existen pocas restricciones sobre lo que puede hacer. El uso de componentes ActiveX, como los que admitía Internet Explorer , en una página web provocó problemas de infecciones de malware . Microsoft reconoció el problema ya en 1996, cuando Charles Fitzgerald afirmó: «Nunca afirmamos de antemano que ActiveX fuera intrínsecamente seguro». ^{[ 13 ]} Las versiones posteriores de Internet Explorer solicitan la confirmación del usuario antes de instalar un control ActiveX, lo que le permite bloquear la instalación.

Como medida de protección, un control ActiveX se firma con una firma digital para garantizar su autenticidad.

También es posible deshabilitar por completo los controles ActiveX o permitir solo unos pocos seleccionados.

La compatibilidad transparente con servidores COM fuera de proceso fomenta la seguridad del software en términos de aislamiento de procesos . Esto puede ser útil para desacoplar subsistemas de aplicaciones grandes en procesos separados. El aislamiento de procesos limita la corrupción de estado en un proceso, evitando que afecte negativamente la integridad de los demás, ya que solo se comunican a través de interfaces estrictamente definidas. Por lo tanto, solo es necesario reiniciar el subsistema afectado para recuperar un estado válido. Esto no ocurre con los subsistemas dentro del mismo proceso, donde un puntero erróneo en un subsistema puede corromper aleatoriamente a otros subsistemas.

Una coclase , una clase COM, implementa una o más interfaces. Se identifica mediante un identificador de clase, llamado CLSID (que es un GUID) , y mediante un identificador programático legible por humanos , llamado ProgID. Una coclase se crea a través de uno de estos identificadores.

Cada interfaz COM extiende la IUnknowninterfaz, que expone métodos para el conteo de referencias y para acceder a las otras interfaces del objeto , de forma 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 , derivada de IUnknown, proporciona acceso anticipado mediante 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, la sobrecarga de una invocación dentro del proceso es comparable a la de una llamada a un método virtual de C++.

El despacho, también conocido como acceso de enlace tardío , se proporciona mediante la implementación de IDispatch. El despacho permite el acceso desde una gama más amplia de contextos de programación que una interfaz personalizada.

Al igual que muchos lenguajes orientados a objetos, COM proporciona una separación entre la interfaz y la implementación. Esta distinción es especialmente marcada en COM, donde un objeto no tiene una interfaz predeterminada. Un cliente debe solicitar una interfaz para tener acceso a ella. COM admite múltiples implementaciones de la misma interfaz, de modo que los clientes pueden elegir qué implementación utilizar.

Una biblioteca de tipos COM define metadatos COM, como coclases e interfaces. Una biblioteca puede definirse como un lenguaje de definición de interfaces (IDL), una sintaxis independiente del lenguaje de programación. IDL es similar a C++, con una 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 su uso con C/C++, el compilador MIDL genera un archivo de cabecera con structdefiniciones que coinciden con las tablas virtuales (vtbls) de las interfaces declaradas y un archivo C que contiene las declaraciones de los identificadores únicos de interfaz (GUID) . El compilador MIDL también puede generar el código fuente C++ de un módulo proxy. Este proxy contiene funciones auxiliares para convertir las llamadas COM en llamadas a procedimientos remotos, lo que permite la comunicación DCOM fuera del 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 llamada SomeClass que implementa una interfaz llamada ISomeInterface .

coclass SomeClass { [ default ] interface 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 SomeClass : público ISomeInterface { };

En C++, los objetos COM se instancian mediante la función CoCreateInstance del subsistema COM , que recibe el CLSID y el IID. La clase SomeClass se puede crear de la siguiente manera:

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

COM es relativamente complejo, especialmente en comparación con tecnologías de componentes más modernas como .NET.

Cuando se inicializa un STA, se 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 "bombeada" regularmente. Esta construcción se conoce como " bombeo de mensajes ". En versiones anteriores de Windows, no hacerlo podí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 "fuga" de detalles de implementación. ^{[ 30 ]}

El conteo de referencias dentro de COM puede causar problemas si dos o más objetos se referencian circularmente . 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 conteos de referencias activos si se utiliza el modelo COM de "sumidero de eventos". Dado que el objeto que dispara el evento necesita una referencia al objeto que reacciona al evento, el conteo de referencias de este último nunca llegará a cero. Los ciclos de referencias generalmente se rompen mediante la terminación fuera de banda o las identidades divididas. En la técnica de terminación fuera de banda, un objeto expone un método que, al ser llamado, lo obliga a liberar 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, evitando un ciclo de referencias. ^{[ 31 ]}

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 algunos casos podrían verse afectados por el problema de la sobrecarga de DLL . La funcionalidad COM sin registro elimina este problema para los componentes en proceso; esta funcionalidad no está disponible para servidores fuera de proceso.