Serialización de interoperabilidad

La serialización de interoperabilidad rige cómo se pasan los datos en los argumentos de método y los valores devueltos entre la memoria administrada y la no administrada durante las llamadas. La serialización de interoperabilidad es una actividad en tiempo de ejecución realizada por el servicio de serialización de Common Language Runtime.

La mayoría de los tipos de datos tienen representaciones comunes en la memoria administrada y no administrada. El administrador de serialización de interoperabilidad controla esos tipos automáticamente. Otros tipos pueden ser ambiguos o no representados en memoria administrada.

Un tipo ambiguo puede tener varias representaciones no administradas que se asignan a un solo tipo administrado o tener falta de información de tipo, como el tamaño de una matriz. Para los tipos ambiguos, el mariscal proporciona una representación predeterminada y representaciones alternativas cuando existen varias. Se pueden proporcionar instrucciones explícitas al administrador de serialización sobre cómo serializar un tipo ambiguo.

Modelos de invocación de plataforma e interoperabilidad COM

Common Language Runtime proporciona dos mecanismos para interoperar con código no administrado:

• Invocación de plataforma, que permite que el código administrado llame a funciones exportadas desde una biblioteca no administrada.
• Interoperabilidad COM, que permite que el código administrado interactúe con objetos del Modelo de objetos componentes (COM) a través de interfaces.

Tanto la invocación de la plataforma como la interoperabilidad COM usan la serialización de interoperabilidad para mover con precisión los argumentos de método desde el autor de la llamada al destinatario y viceversa, si es necesario. Como se muestra en la ilustración siguiente, una llamada al método de invocación de plataforma fluye desde código administrado a no administrado y nunca viceversa, salvo cuando se involucran funciones de devolución de llamada. Aunque las llamadas de invocación de plataforma solo pueden fluir desde código administrado a no administrado, los datos pueden fluir en ambas direcciones como parámetros de entrada o salida. Las llamadas al método de interoperabilidad COM pueden fluir en cualquier dirección.

En el nivel más bajo, ambos mecanismos usan el mismo servicio de serialización de interoperabilidad; sin embargo, hay determinados tipos de datos que solo se admiten en la interoperabilidad COM o en la invocación de la plataforma. Para obtener más información, consulte Comportamiento de serialización predeterminado.

Marshalling y COM Apartments

El administrador de serialización de interoperabilidad serializa los datos entre el montón de Common Language Runtime y el montón no administrado. La serialización se produce siempre que el autor de la llamada y el destinatario no pueden operar en la misma instancia de datos. El administrador de serialización de interoperabilidad permite al autor de la llamada y al destinatario operar en los mismos datos, incluso aunque tengan su propia copia de los datos.

COM también dispone de un administrador de serialización que serializa datos entre apartamentos COM o diferentes procesos COM. Al realizar llamadas entre código administrado y no administrado en el mismo apartamento COM, el administrador de serialización de interoperabilidad es el único administrador de serialización implicado. Al realizar llamadas entre código administrado y código no administrado en un apartamento COM diferente o en un proceso diferente, están implicados tanto el administrador de serialización de interoperabilidad como el administrador de serialización de COM.

Clientes COM y servidores administrados

Un servidor administrado exportado con una biblioteca de tipos registrada por la herramienta de registro de ensamblados (Regasm.exe) tiene una entrada del Registro ThreadingModel establecida en Both. Este valor indica que el servidor se puede activar en un apartamento de un solo subproceso (STA) o en un apartamento multiproceso (MTA). El objeto de servidor se crea en el mismo apartamento que su llamador, como se muestra en la tabla siguiente:

Dado que el cliente y el servidor están en el mismo apartamento, el servicio de serialización de interoperabilidad controla automáticamente toda la serialización de datos. La ilustración siguiente muestra cómo opera el servicio de serialización de interoperabilidad entre montones administrados y no administrados dentro del mismo apartamento de estilo COM.

Si planea exportar un servidor administrado, tenga en cuenta que el cliente COM determina el apartamento del servidor. Un servidor administrado llamado por un cliente COM inicializado en un MTA debe garantizar la seguridad de los subprocesos.

Clientes administrados y servidores COM

La configuración predeterminada para los apartamentos de cliente administrados es MTA; Sin embargo, el tipo de aplicación del cliente .NET puede cambiar la configuración predeterminada. Por ejemplo, una configuración de apartamento cliente de Visual Basic es STA. Puede usar la propiedad System.STAThreadAttribute, la propiedad System.MTAThreadAttribute, la propiedad Thread.ApartmentState, o la propiedad Page.AspCompatMode para examinar y cambiar la configuración del apartamento de un cliente gestionado.

El autor del componente establece la afinidad del subproceso de un servidor COM. En la tabla siguiente se muestran las combinaciones de configuraciones de apartamentos para clientes .NET y servidores COM. También muestra los requisitos de empaquetamiento resultantes para las combinaciones.

Cuando un cliente administrado y un servidor no administrado están en el mismo apartamento, el servicio de serialización de interoperabilidad controla toda la serialización de datos. Sin embargo, cuando el cliente y el servidor se inicializan en apartamentos diferentes, también es necesaria la serialización de COM. En la ilustración siguiente se muestran los elementos de una llamada entre apartamentos:

Para la serialización entre apartamentos, puede hacer lo siguiente:

• Aceptar la sobrecarga que supone la serialización entre apartamentos, que solo es apreciable cuando hay muchas llamadas que cruzan el límite. Debe registrar la biblioteca de tipos del componente COM para que las llamadas crucen correctamente el límite del apartamento.

• Modifique el subproceso principal estableciendo el subproceso de cliente en STA o MTA. Por ejemplo, si el cliente de C# llama a muchos componentes COM de STA, puede evitar la serialización entre apartamentos si establece el subproceso principal en STA.

  Nota:

  Una vez que se establece el subproceso de un cliente C# en STA, las llamadas a componentes COM de MTA requerirán la serialización entre apartamentos.

Para obtener instrucciones sobre cómo seleccionar explícitamente un modelo de contenedor, vea Subprocesamiento administrado y no administrado.

Serialización de llamadas remotas

Al igual que con la serialización entre apartamentos, la serialización de COM participa en todas las llamadas entre código administrado y no administrado siempre que los objetos residan en procesos independientes. Por ejemplo:

• Un cliente COM que invoca un servidor administrado en un host remoto usa COM distribuido (DCOM).
• Un cliente administrado que invoca un servidor COM en un host remoto usa DCOM.

En la siguiente ilustración, se muestra cómo la serialización de interoperabilidad y la serialización de COM proporcionan canales de comunicación entre procesos y límites de hosts:

Conservación de la identidad

Common Language Runtime conserva la identidad de las referencias administradas y no administradas. En la ilustración siguiente se muestra el flujo de referencias directas no administradas (fila superior) y referencias administradas directas (fila inferior) en los límites de proceso y host.

En esta ilustración:

• Un cliente no administrado obtiene una referencia a un objeto COM de un objeto administrado que obtiene esta referencia de un host remoto. El mecanismo de comunicación remota es DCOM.

• Un cliente administrado obtiene una referencia a un objeto administrado de un objeto COM que obtiene esta referencia de un host remoto. El mecanismo de comunicación remota es DCOM.

  Nota:

  La biblioteca de tipos exportada del servidor administrado debe estar registrada.

El número de límites de proceso entre llamador y destinatario es irrelevante; la misma referencia directa se produce para las llamadas dentro del proceso y fuera de proceso.

Comunicación remota administrada

El runtime también proporciona comunicación remota administrada que puede usarse para establecer un canal de comunicaciones entre objetos administrados a través varios procesos y límites de hosts. La comunicación remota administrada puede dar cabida a un firewall entre los componentes de comunicación, como se muestra en la ilustración siguiente:

Llamadas remotas entre firewalls mediante SOAP o la clase TcpChannel

Algunas llamadas no administradas se pueden canalizar a través de SOAP, como las llamadas entre componentes con servicio y COM.

Temas relacionados

Referencia

System.Runtime.InteropServices