Arquitectura remota de .NET Framework

Este tema es específico de una tecnología heredada que se mantiene para la compatibilidad con versiones anteriores con aplicaciones existentes y no se recomienda para nuevo desarrollo. Las aplicaciones distribuidas se deberían desarrollar utilizando  Windows Communication Foundation (WCF).

La infraestructura de .NET Remoting constituye una aproximación abstracta a la comunicación entre procesos. Aquellos objetos que se pueden pasar o copiar por valor se traspasan automáticamente entre las aplicaciones a dominios de aplicación diferentes o a equipos diferentes. Para realizar este trabajo, marque sus clases predeterminadas como serializables.

La fuerza real del sistema remoto, sin embargo, reside en su capacidad de habilitar la comunicación entre los objetos de dominios o procesos de aplicación diferentes utilizando diferentes protocolos de transporte, formatos de serialización, esquemas del período de duración del objeto y modos de creación de objetos. Además, la comunicación remota hace posible intervenir en casi cualquier fase del proceso comunicativo.

Si ha puesto en funcionamiento varias aplicaciones distribuidas o está interesado en mover los componentes a otros equipos para aumentar la escalabilidad de su programa, resulta muy fácil entender el sistema remoto como un sistema genérico de comunicación entre procesos con algunas acciones predeterminadas que administran fácilmente la mayoría de los escenarios. La siguiente discusión comienza con los conceptos básicos de la comunicación entre procesos utilizando la comunicación remota.

Copias frente a Referencias

La comunicación entre procesos requiere un objeto del servidor cuya funcionalidad se proporcione a los llamadores que se encuentran fuera de su proceso, a un cliente que realiza las llamadas en el objeto del servidor y a un mecanismo de transporte para llevar las llamadas de un extremo al otro. Las direcciones de los métodos del servidor son lógicas y funcionan correctamente en un proceso, pero no lo hacen en un proceso de cliente diferente. Para aliviar este problema, un cliente puede llamar a un objeto servidor realizando una copia íntegra del objeto y moviéndolo al proceso del cliente, donde se pueden invocar los métodos de la copia directamente.

No obstante, muchos objetos no pueden, o no deberían, copiarse y moverse a otros procesos para ser ejecutados. No se deberían copiar o pasar por valor a otros procesos aquellos objetos de gran tamaño. Normalmente, un cliente requiere solo la información devuelta por uno o algunos métodos en el objeto del servidor. Copiar el objeto del servidor completo, incluyendo lo que podrían ser inmensas cantidades de información interna o estructuras de aplicación ejecutable no relacionadas con los requisitos del cliente, constituiría una pérdida de ancho banda así como de memoria del cliente y tiempo de proceso. Además, muchos objetos exponen la funcionalidad pública pero requieren los datos privados para la ejecución interna. Copiar estos objetos podría permitir examinar los datos internos a clientes no autorizados y, de este modo, crear posibles problemas de seguridad. Finalmente, algunos objetos utilizan datos que no se pueden copiar de forma comprensible alguna. Por ejemplo, un objeto FileInfo contiene una referencia a un archivo del sistema operativo, que tiene una dirección única en la memoria del proceso de servidor. Puede copiar esta dirección, pero ésta no será válida en otro proceso.

En estos casos, el proceso del servidor debería pasar al proceso del cliente una referencia para el objeto del servidor, en lugar de una copia del objeto. Los clientes pueden utilizar esta referencia para llamar al objeto del servidor. Estas llamadas no se ejecutan en el proceso del cliente. En su lugar, el sistema remoto recoge toda la información acerca de la llamada y la envía al proceso del servidor, donde se interpreta, donde se encuentra el objeto del servidor correcto y donde se realiza la llamada al objeto del servidor en nombre del objeto del cliente. A continuación, el resultado de la llamada se manda de vuelta al proceso del cliente para que éste se lo devuelva al cliente. El ancho banda solamente se utiliza para obtener la información importante: la llamada, los argumentos de la llamada y cualesquiera valores o excepciones devueltos.

La arquitectura remota simplificada

Utilizar las referencias de objeto para comunicarse entre los objetos del servidor y los clientes es la parte más importante de la comunicación remota. No obstante, la arquitectura remota proporciona al programador un procedimiento más básico. Si configura correctamente el cliente, simplemente cree una nueva instancia del objeto remoto utilizando new (o la función de creación de instancia de su lenguaje de programación administrado). Su cliente recibe una referencia al objeto del servidor y, a continuación, usted puede llamar a sus métodos como si el objeto estuviera en su proceso en lugar de estar ejecutándose desde un equipo independiente. El sistema remoto utiliza los objetos de proxy para crear la impresión que el objeto del servidor se halla en el proceso del cliente. Los proxys son objetos que se presentan como si fuesen otro objeto. Cuando su cliente crea una instancia del tipo remoto, la infraestructura remota crea un objeto proxy que, para su cliente, es exactamente igual que el tipo remoto. Su cliente llama a un método en ese proxy y el sistema remoto recibe la llamada, la enruta al proceso del servidor, invoca el objeto del servidor y devuelve el valor devuelto al proxy del cliente, que devuelve el resultado al cliente.

Las llamadas remotas se deben transmitir de alguna forma entre el cliente y el proceso del servidor. Si usted estuviera generando un sistema remoto, debería comenzar por aprender programación de redes y una gran variedad de protocolos y especificaciones de formato de serialización. En el sistema .NET Remoting, la combinación de tecnologías subyacentes exigía abrir una conexión de red y utilizar un protocolo determinado para enviar los bytes a la aplicación receptora que se representa como un canal de transporte.

Un canal es un tipo que toma un flujo de datos, crea un paquete según un protocolo de red determinado y envía el paquete a otro equipo. Algunos canales solamente pueden recibir información, otros solo pueden enviarla y existen otros, como el Canal Tcp predeterminado y las clases canal Http, que se pueden utilizar en cualquier dirección.

Aunque el proceso del servidor sabe todo sobre cada tipo único, el cliente solo conoce que el proceso del servidor desea una referencia a un objeto de otro dominio de aplicación, quizás de otro equipo. Desde el mundo exterior del dominio de aplicación del servidor, una dirección URL ubica el objeto. Las direcciones URL que representan tipos únicos para el mundo exterior son direcciones URL de activación, que aseguran que su llamada remota se realice al tipo apropiado. Para obtener más información, consulte Direcciones URL de activación.

Diseño del sistema remoto completo

Suponga tiene una aplicación que se ejecuta en un equipo y desea utilizar la funcionalidad expuesta por un tipo que está almacenado en otro equipo. En la siguiente ilustración se muestra el proceso de comunicación remota general.

Si se configuran ambos lados de la relación correctamente, el cliente simplemente crea una nueva instancia de la clase de servidor. El sistema remoto crea un objeto proxy que representa la clase y devuelve al objeto del cliente una referencia al proxy. Cuando un cliente llama a un método, la infraestructura remota administra la llamada, comprueba la información de tipo y envía la llamada al proceso de servidor a través del canal. Un canal de escucha escoge la solicitud y la reenvía al sistema remoto del servidor, que busca (o, en caso necesario, crea) y llama al objeto solicitado. A continuación, se invierte el proceso puesto que el sistema remoto del servidor empaqueta la respuesta en un mensaje que el canal del servidor envía al canal del cliente. Finalmente, el sistema remoto del cliente devuelve el resultado de la llamada al objeto del cliente a través del proxy.

Para llevar a cabo esta tarea se requiere muy poco código real pero se debería pensar un mínimo en el diseño y en la configuración de la relación. El código puede ser completamente correcto y aún así fallar si una dirección URL o el número de puerto son incorrectos. Para obtener más información, consulte Configuración.

Aunque esta perspectiva general de alto nivel del proceso de comunicación remota es bastante sencilla, los detalles del nivel inferior pueden ser bastante complejos. En otros temas se proporciona una discusión más detallada de los elementos principales de la comunicación remota, tal y como figura en la sección “Consulte también”.

Vea también

Conceptos

Límites: Procesos y dominios de aplicación
Objetos remotos y no remotos
Canales
Seguridad en comunicación remota
Configuración de aplicaciones remotas

Otros recursos

Información general de servicios remotos de .NET Framework
Activación de objeto y duraciones