Detalles de serialización
Si usa serialización estándar, COM controla todos los detalles que se describen aquí. Sin embargo, hay algunos programadores que necesitan estos detalles y para aquellos interesados en la información subyacente. La serialización es el proceso de empaquetado y desempaquetado de parámetros para que se pueda realizar una llamada a procedimiento remoto.
Los distintos tipos de parámetros se serializa de diferentes maneras. Por ejemplo, la serialización de un parámetro entero implica simplemente copiar el valor en el búfer de mensajes. (Aunque incluso en este sencillo caso, hay problemas como el orden de bytes con el que tratar en llamadas entre equipos). Sin embargo, la serialización de una matriz es un proceso más complejo. Los miembros de matriz se copian en un orden específico para que el otro lado pueda reconstruir la matriz exactamente. Cuando se serializa un puntero, los datos a los que apunta el puntero se copian siguiendo las reglas y convenciones para tratar con punteros anidados en estructuras. Existen funciones únicas para controlar el cálculo de referencias de cada tipo de parámetro.
Con la serialización estándar, los servidores proxy y los códigos auxiliares son recursos de todo el sistema para la interfaz e interactúan con el canal a través de un protocolo estándar. Las referencias estándar se pueden usar tanto mediante interfaces estándar definidas por COM como por interfaces personalizadas, como se indica a continuación:
- En el caso de la mayoría de las interfaces COM, los servidores proxy y los códigos auxiliares para las serializaciones estándar son objetos de componentes en proceso que se cargan desde un archivo DLL de todo el sistema proporcionado por COM en Ole32.dll.
- En el caso de interfaces personalizadas, el diseñador de interfaces genera los proxies y los códigos auxiliares para el cálculo de referencias estándar, normalmente con MIDL. Estos servidores proxy y códigos auxiliares se configuran estáticamente en el registro, por lo que cualquier cliente potencial puede usar la interfaz personalizada a través de los límites del proceso. Estos proxies y códigos auxiliares se cargan desde un archivo DLL que se encuentra a través del registro del sistema, mediante el identificador de interfaz (IID) para la interfaz personalizada que serializa.
- Una alternativa al uso de MIDL para generar proxies y códigos auxiliares para interfaces personalizadas, se puede generar una biblioteca de tipos en su lugar y el sistema proporcionado, el motor de serialización controlado por la biblioteca de tipos serializará la interfaz.
Como alternativa al cálculo de referencias estándar, una interfaz (estándar o personalizada) puede usar serialización personalizada. Con la serialización personalizada, un objeto implementa dinámicamente los servidores proxy en tiempo de ejecución para cada interfaz que admita. Para cualquier interfaz determinada, el objeto puede seleccionar serialización estándar proporcionada por COM o serialización personalizada. Esta elección se realiza mediante el objeto en una interfaz por interfaz. Una vez realizada la elección de una interfaz determinada, permanece en vigor durante la duración del objeto. Sin embargo, una interfaz de un objeto puede usar serialización personalizada, mientras que otra usa serialización estándar.
La serialización personalizada es intrínsecamente única para el objeto que la implementa. Usa servidores proxy implementados por el objeto y proporcionados al sistema bajo solicitud en tiempo de ejecución. Los objetos que implementan la serialización personalizada deben implementar la interfaz IMarshal , mientras que los objetos que admiten serializaciones estándar no.
Si decide escribir una interfaz personalizada, debe proporcionar compatibilidad con serialización para ella. Normalmente, proporcionará un archivo DLL de serialización estándar para la interfaz que diseñe. Puede crear el código proxy/código auxiliar y el archivo DLL proxy/stub, o puede crear una biblioteca de tipos que COM usará para realizar serialización controlada por datos (mediante los datos de la biblioteca de tipos).
Para que un cliente realice una llamada a un método de interfaz en un objeto de otro proceso implica la cooperación de varios componentes. El proxy estándar es un fragmento de código específico de la interfaz que reside en el espacio de proceso del cliente y prepara los parámetros de interfaz para la transmisión. Empaqueta, o serializa, de tal forma que se puedan volver a crear y comprender en el proceso de recepción. El código auxiliar estándar, también un fragmento de código específico de la interfaz, reside en el espacio de proceso del servidor y invierte el trabajo del proxy. Los desempaquetados de código auxiliar, o desmarshales, los parámetros enviados y los reenvía a la aplicación de objeto. También empaqueta la información de respuesta para volver a enviar al cliente.
Nota
Los lectores más familiarizados con RPC que COM pueden usarse para ver los términos código auxiliar de cliente y código auxiliar del servidor. Estos términos son análogos a proxy y código auxiliar.
Componentes de comunicaciones entre procesos
En el diagrama siguiente se muestra el flujo de comunicación entre los componentes implicados. En el lado cliente del límite del proceso, la llamada al método del cliente pasa por el proxy y, a continuación, en el canal, que forma parte de la biblioteca COM. El canal envía el búfer que contiene los parámetros serializado a la biblioteca en tiempo de ejecución rpc, que la transmite a través del límite del proceso. El tiempo de ejecución de RPC y las bibliotecas COM existen en ambos lados del proceso. La distinción entre el canal y el tiempo de ejecución de RPC es una característica de esta implementación y no forma parte del modelo de programación ni del modelo conceptual para los objetos cliente/servidor COM. Los servidores COM solo ven el proxy o el código auxiliar y, indirectamente, el canal. Las implementaciones futuras pueden usar diferentes capas por debajo del canal o ninguna capa.
Temas relacionados