Introducción
.NET Remoting es un mecanismo para comunicarse entre objetos que no están en el
mismo proceso. Es un sistema genérico para que diferentes aplicaciones se
comuniquen entre sí. Los objetos .NET están expuestos a procesos remotos, lo que
permite la comunicación entre procesos. Las aplicaciones se pueden ubicar en la misma
computadora, diferentes computadoras en la misma red o en computadoras en redes
separadas.
Microsoft .NET Remoting proporciona un marco que permite que los objetos interactúen
entre sí a través de dominios de aplicación. La comunicación remota se diseñó de tal
manera que oculta los aspectos más difíciles, como la administración de conexiones, el
cálculo de datos y la lectura y escritura de XML y SOAP. El marco proporciona una serie
de servicios, que incluyen activación de objetos y soporte de vida útil de los objetos, así
como canales de comunicación que son responsables de transportar mensajes hacia y
desde aplicaciones remotas.
Objetos remotos
¿Qué son los objetos remotos?
Cualquier objeto fuera del dominio de la aplicación debe considerarse remoto. Los
objetos locales que no se pueden serializar no se pueden pasar a un dominio de
aplicación diferente y, por lo tanto, no son remotos. Cualquier objeto se puede cambiar a
un objeto remoto derivando de MarshalByRefObject, o haciéndolo serializable
agregando la etiqueta [Serializable] o implementando la interfaz ISerializable. Cuando
un cliente activa un objeto remoto, recibe un proxy para el objeto remoto. Todas las
operaciones en este proxy son indirectamente apropiadas para permitir que la
infraestructura Remoting intercepte y reenvíe las llamadas de manera apropiada. En los
casos en que el proxy y los objetos remotos se encuentran en diferentes dominios de
aplicación, todos los parámetros de llamada al método en la pila se convierten en
mensajes y se transportan al dominio de la aplicación remota, donde los mensajes se
vuelven a convertir en un marco de pila y se invoca la llamada al método. Se utiliza el
mismo procedimiento para devolver resultados de la llamada al método.
Tipos de objetos remotos .NET
Hay tres tipos de objetos que se pueden configurar para servir como objetos remotos
.NET. Puede elegir el tipo de objeto según los requisitos de su aplicación.
Single Call
Los objetos single call atienden una y solo una solicitud entrante. Los objetos single call
son útiles en escenarios donde se requiere que los objetos hagan una cantidad finita de
trabajo. Por lo general, no se requieren objetos single call para almacenar información
de estado, y no pueden retener información de estado entre llamadas de método.
Objetos Singleton
Los objetos Singleton son aquellos que sirven a múltiples clientes y, por lo tanto,
comparten datos almacenando información de estado entre invocaciones de clientes.
Son útiles en los casos en que los datos deben compartirse explícitamente entre los
clientes, y también en los que la sobrecarga de crear y mantener objetos es sustancial.
Objetos activados por el cliente (CAO)
Los objetos activados por el cliente (CAO) son objetos del lado del servidor que se
activan a pedido del cliente. Cuando el cliente envía una solicitud para un objeto de
servidor utilizando un operador "new", se envía un mensaje de solicitud de activación a
la aplicación remota. Luego, el servidor crea una instancia de la clase solicitada y
devuelve un ObjRef a la aplicación cliente que lo invocó. Luego se crea un proxy en el
lado del cliente utilizando ObjRef. Las llamadas al método del cliente se ejecutarán en el
proxy. Los objetos activados por el cliente pueden almacenar información de estado
entre llamadas de método para su cliente específico, y no a través de diferentes objetos
de cliente. Cada invocación de "new" devuelve un proxy a una instancia independiente
del tipo de servidor.
Dominios
En .NET, cuando una aplicación se carga en la memoria, se crea un proceso y, dentro
de este proceso, se crea un dominio de aplicación. La aplicación se carga realmente en
el dominio de la aplicación. Si esta aplicación se comunica con otra aplicación, tiene que
usar Remoting porque la otra aplicación tendrá su propio dominio, y en todos los
dominios, el objeto no puede comunicarse directamente. Pueden existir diferentes
dominios de aplicación en el mismo proceso, o pueden existir en diferentes procesos.
Contextos
El tiempo de ejecución .NET divide aún más el dominio de la aplicación en contextos.
Un contexto garantiza que un conjunto común de restricciones y semántica de uso
gobierne todo el acceso a los objetos dentro de él. Todas las aplicaciones tienen un
contexto predeterminado en el que se construyen los objetos, a menos que se indique lo
contrario. Un contexto, como un dominio de aplicación, forma un límite de .NET
Remoting. Las solicitudes de acceso se deben ordenar en todos los contextos.
Proxies
Cuando se realiza una llamada entre objetos en el mismo dominio de aplicación, solo se
requiere una llamada local normal; sin embargo, una llamada a través de dominios de
aplicación requiere una llamada remota. Para facilitar una llamada remota, .NET
Framework introduce un proxy en el lado del cliente. Este proxy es una instancia de la
clase TransparentProxy, directamente disponible para que el cliente se comunique con
el objeto remoto. En general, un objeto proxy es un objeto que actúa en lugar de otro
objeto. El objeto proxy garantiza que todas las llamadas realizadas en el proxy se
desvíen a la instancia correcta del objeto remoto. En .NET Remoting, el proxy gestiona
el proceso de cálculo de referencias y las otras tareas necesarias para realizar llamadas
transfronterizas. La infraestructura de .NET Remoting maneja automáticamente la
creación y administración de proxies.
RealProxy y TransparentProxy
.NET Remoting Framework utiliza dos objetos proxy para realizar su trabajo de realizar
una llamada remota desde un objeto de cliente a un objeto de servidor remoto: un
objeto RealProxy y un objeto TransparentProxy. El objeto RealProxy hace el trabajo de
enviar mensajes al objeto remoto y recibir mensajes de respuesta del objeto remoto.
TransparentProxy interactúa con el cliente y realiza el trabajo de interceptar la llamada
al método remoto realizada por el cliente.
Marshaling
El objeto Marshalling especifica cómo se expone un objeto remoto a la aplicación
cliente. Es el proceso de empaquetar una solicitud de acceso a objetos en un dominio
de aplicación y pasar esa solicitud a otro dominio. La infraestructura .NET Remoting
gestiona todo el proceso de cálculo de referencias. Hay dos métodos por los cuales un
objeto remoto puede estar disponible para un objeto de cliente local: Marshall por valor
y Marshall por referencia.
Marshalling objects by value
La clasificación por valor es análoga a tener una copia del objeto del servidor en el
cliente. Los objetos que se ordenan por valor se crean en el servidor remoto, se
serializan en una secuencia y se transmiten al cliente donde se reconstruye una copia
exacta. Una vez copiados al dominio de la aplicación del llamante (mediante el proceso
de cálculo de referencias), todas las llamadas a métodos y accesos a propiedades se
ejecutan completamente dentro de ese dominio.
Marshall por valor tiene varias implicaciones; primero, todo el objeto remoto se
transmite en la red. En segundo lugar, algunos o todo el objeto remoto pueden no tener
relevancia fuera de su contexto local. Por ejemplo, el objeto remoto puede tener una
conexión a una base de datos, o un identificador a una ventana, o un identificador de
archivo, etc. Tercero, partes del objeto remoto pueden no ser serializables. Además,
cuando el cliente invoca un método en un objeto MBV, la máquina local realiza la
ejecución, lo que significa que el código compilado (clase remota) debe estar disponible
para el cliente. Debido a que el objeto existe completamente en el dominio de la
aplicación del llamante, no se comunican cambios de estado al objeto al dominio de la
aplicación de origen, o desde el originador de regreso al llamante.
Sin embargo, los objetos MBV son muy eficientes si son pequeños y proporcionan una
función repetida que no consume ancho de banda. Todo el objeto existe en el dominio
de la persona que llama, por lo que no es necesario reunir los accesos a través de los
límites del dominio. El uso de objetos de Marshall por valor puede aumentar el
rendimiento y reducir el tráfico de red, cuando se usa para objetos pequeños u objetos a
los que tendrá muchos accesos.
Marshall por clases de valor debe estar marcado con el atributo [Serilaizable] para
utilizar la serialización predeterminada o debe implementar la interfaz ISerializable.
Marshalling objects by reference
Marshalling por referencia es análoga a tener un puntero al objeto. Marshall por
referencia pasa una referencia al objeto remoto de vuelta al cliente. Esta referencia es
una clase ObjRef que contiene toda la información necesaria para generar el objeto
proxy que se comunica con el objeto remoto real. En la red, solo se pasan los
parámetros y los valores de retorno. Una invocación de método remoto requiere que el
objeto remoto llame a su método en el host remoto (servidor).
Marshall por clases de referencia debe heredar de [Link].
Marshalling realizada por .NET Framework
Marshal por referencias se realiza mediante .NET Framework. No tenemos que escribir
ningún código para ello.
Canales
La infraestructura de .NET Remoting proporciona un mecanismo por el cual se envía
una secuencia de bytes de un punto a otro (cliente a servidor, etc.). Esto se logra a
través de un canal. Estrictamente hablando, es una clase que implementa la interfaz
IChannel. Existen dos canales de .NET Remoting predefinidos en
[Link], TcpChannel y HttpChannel. Para usar
TcpChannel, el servidor debe crear instancias y registrar la clase TcpServerChannel y el
cliente, la clase TcpClientChannel.
La selección de canales está sujeta a las siguientes reglas:
·0 Se debe registrar al menos un canal con el marco remoto antes de poder llamar
a un objeto remoto. Los canales deben registrarse antes de que se registren los
objetos.
·1 Los canales se registran por dominio de aplicación. Puede haber múltiples
dominios de aplicación en un solo proceso. Cuando un proceso muere, todos los
canales que registra se destruyen automáticamente.
·2 Es ilegal registrar el mismo canal que escucha en el mismo puerto más de una
vez. Aunque los canales están registrados por dominio de aplicación, los
diferentes dominios de aplicación en la misma máquina no pueden registrar el
mismo canal escuchando en el mismo puerto. Puede registrar el mismo canal
escuchando en dos puertos diferentes para un dominio de aplicación.
·3 Los clientes pueden comunicarse con un objeto remoto utilizando cualquier
canal registrado. El marco remoto asegura que el objeto remoto esté conectado
al canal correcto cuando un cliente intenta conectarse a él. El cliente es
responsable de llamar a RegisterChannel en la clase ChannelService antes de
intentar comunicarse con un objeto remoto.
Formateadores de serialización
.NET Remoting utiliza la serialización para copiar objetos de marshall por valor y para
enviar referencias de objetos que son de marshall por referencia, entre dominios de
aplicación. .NET Framework admite dos tipos de serialización: serialización binaria y
serialización XML.
Los formateadores se utilizan para codificar y decodificar los mensajes antes de que el
canal los transporte. Hay dos formateadores nativos en el tiempo de ejecución de .NET,
a saber, binario ([Link]) y SOAP
([Link]). Las aplicaciones pueden usar
codificación binaria donde el rendimiento es crítico, o codificación XML donde la
interoperabilidad con otros marcos remotos es esencial.
Un punto clave para recordar es que .NET Remoting siempre usa serialización binaria,
pero puede elegir los formatos de salida. El tipo de serialización (binario o XML)
determina qué datos del objeto se emiten. El formateador determina el formato en el
que se almacenan esos datos.
Los datos en formato binario tienen un tamaño menor que en formato XML. El tamaño
más pequeño hace que el formato binario sea la opción obvia para las aplicaciones de
intranet o cuando el rendimiento de la red es crítico. Sin embargo, no todos los firewalls
se ven bien en los datos con formato binario, por lo que si está distribuyendo una
aplicación que necesita usar Remoting a través de Internet, es posible que se vea
obligado a usar el formato SOAP. Otro beneficio del formato SOAP es que es legible por
humanos, lo que le brinda la oportunidad de examinar el tráfico de mensajes para su
depuración. Afortunadamente, Remoting funciona exactamente igual,
independientemente del formateador que use, por lo que puede usar el formato SOAP
durante el desarrollo inicial y la depuración, y luego convertirlo a formato binario para el
lanzamiento de producción.
.NET Remoting Metadata
.NET Remoting utiliza metadatos para crear dinámicamente objetos proxy. Los objetos
proxy que se crean en el lado del cliente tienen los mismos miembros que la clase
original. Pero la implementación del objeto proxy solo reenvía todas las solicitudes a
través del tiempo de ejecución de .NET Remoting al objeto original. El formateador de
serialización utiliza metadatos para convertir llamadas de método a flujo de carga útil y
viceversa.
El cliente puede obtener la información de metadatos requerida para acceder al objeto
remoto de las siguientes maneras:
·4 El ensamblado .NET del objeto del servidor.
·5 El objeto Remoting puede proporcionar un archivo WSDL (Lenguaje de
descripción de servicios web) que describe el objeto y sus métodos.
·6 Los clientes .NET pueden usar la utilidad SOAPSUDS para descargar el
esquema XML del servidor (generado en el servidor) para generar archivos de
origen o un ensamblado que contenga solo metadatos, sin código.
Activación de objetos
La activación de objetos se refiere a las diversas formas en que se puede instanciar un
objeto remoto.
- Los objetos Marshall por valor tienen un esquema de activación simple, se crean
cuando el cliente los solicita por primera vez.
- Marshall por objetos de referencia tiene dos esquemas de activación:
Objetos activados por el servidor (SAO)
Los objetos activados por el servidor se crean solo cuando el cliente realiza la primera
llamada al método remoto. En otras palabras, cuando el cliente solicita la creación del
objeto remoto, solo se crea el proxy local en el cliente, el objeto remoto real en el
servidor se instancia en la primera llamada al método.
Objetos activados por el cliente (CAO)
Estos se crean en el servidor inmediatamente a solicitud del cliente. Se crea una
instancia de un objeto activado por el cliente cada vez que el cliente crea una instancia.
Cuándo usar qué tipo de activación depende de diferentes escenarios. Algunos de ellos
son:
- La referencia de objeto Singleton al mismo objeto de servidor, y cualquier cambio
realizado a ese objeto por un cliente es visible para todos los clientes del objeto.
- Utilice el modelo SingleCall para proporcionar un modelo de programación sin estado
(el modelo tradicional de solicitud / respuesta de servicios web), o en cualquier
momento que no necesite mantener un estado de objeto persistente en el servidor.
- Utilice la activación del cliente (CAO) si el objeto necesita mantener información de
estado persistente por cliente.
