nformacin general de .

NET Framework Remoting

Visual Studio 2005 Otras versiones

y y

.NET Framework 4 Visual Studio 2008

.NET Remoting permite crear fcilmente aplicaciones ampliamente distribuidas, tanto si los componentes de las aplicaciones estn todos en un equipo como si estn repartidos por el mundo. Se pueden crear aplicaciones de cliente que utilicen objetos en otros procesos del mismo equipo o en cualquier otro equipo disponible en la red. Tambin se puede utilizar .NET Remoting para comunicarse con otros dominios de aplicacin en el mismo proceso. (Para obtener ms informacin sobre la programacin de los dominios de aplicacin, vea Programar con dominios de aplicacin.) .NET Remoting proporciona un enfoque abstracto en la comunicacin entre procesos que separa el objeto utilizado de forma remota de un dominio de aplicacin de cliente o servidor especfico y de un mecanismo espec fico de comunicacin. Por lo tanto, se trata de un sistema flexible y fcilmente personalizable. Se puede reemplazar un protocolo de comunicacin con otro o un formato de serializacin con otro sin tener que recompilar el cliente ni el servidor. Adems, el sistema de interaccin remota no presupone ningn modelo de aplicacin en particular. Se puede comunicar desde una aplicacin Web, una aplicacin de consola, un servicio de Windows, desde casi cualquier aplicacin que se desee utilizar. Los servidores de interaccin remota tambin pueden ser cualquier tipo de dominio de aplicacin. Cualquier aplicacin puede albergar objetos de interaccin remota y proporcionar sus servicios a cualquier cliente en su equipo o red. Nota Por motivos de seguridad, es muy recomendable exponer los extremos de interaccin remota a travs de canales seguros. No exponga nunca extremos de interaccin remota inseguros en Internet. Si desea utilizar .NET Remoting para crear una aplicacin en la que dos componentes se comunican directamente ms all de los lmites de los dominios de aplicacin, slo deber crear lo siguiente:
y

Un objeto que se puede utilizar de forma remota.

Incluso en una aplicacin compleja de varios clientes o servidores .NET Remoting puede considerarse de esta manera. Las aplicaciones host y cliente tambin deben configurarse con la infraestructura remota y es preciso comprender las cuestiones de vida til y de activacin que conlleva dicha infraestructura.

Arquit tura Remotin

Visual Studio 2005

.N

Framework

La infraestructura de .N Remotin es un enfoque abstracto de la comunicacin entre procesos. La mayor parte del sistema funciona sin llamar la atencin. Por ejemplo, los objetos que se pueden pasar por valor, o copiar, se pasan automticamente de una aplicacin a otra en dominios de aplicacin o en equipos distintos. Slo tiene que marcar sus clases personalizadas como serializables para que el sistema funcione. Pero la verdadera ventaja del sistema de interaccin remota es su capacidad para permitir la comunicacin entre objetos pertenecientes a dominios de aplicacin o a procesos distintos mediante diferentes protocolos de transporte, formatos de serializacin, esquemas de duracin de objetos y modos de creacin de objetos. Adems, la interaccin remota permite intervenir en prcticamente todas las fases del proceso de comunicacin, sea cual sea la razn. Tanto si implement una serie de aplicaciones distribuidas como si slo desea mover componentes a otros equipos para aumentar la escalabilidad de su programa, le resultar ms fcil si considera el sistema de interaccin remota como un sistema genrico de comunicacin entre procesos con algunas implementaciones predeterminadas capaces de controlar fcilmente la mayora de los escenarios posibles. La e plicacin siguiente comienza con los principios bsicos de la comunicacin entre procesos mediante la interaccin remota.

Copias y referen ias

La comunicacin entre procesos requiere un objeto servidor cuya funcionalidad est a disposicin de los llamadores fuera de su proceso, un cliente que realice llamadas al objeto servidor y un mecanismo de transporte que lleve las llamadas de un e tremo a otro. Las direcciones de los mtodos del servidor son lgicas y funcionan correctamente en un proceso, pero no funcionan en otro proceso de cliente. Para solucionar este problema, el cliente puede llamar a un objeto servidor realizando una copia de todo el objeto y pasndola al proceso de cliente, donde se pueden invocar directamente los mtodos de la copia.

y y

Un dominio de aplicacin hos para esc char las solicitudes de dicho objeto. Un dominio de aplicacin de cli ente que realiza solicitudes para dicho objeto.

No obstante, muchos objetos no se pueden o no se deben copiar ni pasar a otros procesos para ejecutarse. Los objetos sumamente grandes con muchos mtodos son los menos aconsejables para copiar o pasar por valor a otros procesos. Normalmente, un cliente slo necesita la informacin devuelta por un solo mtodo o por unos pocos en el objeto servidor. Copiar el objeto servidor entero, incluyendo lo que podran ser enormes cantidades de informacin interna o estructuras ejecutables no relacionadas con las necesidades del cliente, supondra desperdiciar el ancho de banda as como la memoria del cliente y el tiempo que se emplea en procesarlo todo. Adems, muchos objetos e ponen una funcionalidad pblica pero requieren datos privados para la ejecucin interna. Copiar estos objetos podra permitir que clientes no autorizados e aminaran datos internos, lo que posibi litara la aparicin de problemas de seguridad. Por ltimo, algunos objetos utilizan datos que no se pueden copiar de ninguna forma comprensible. Por ejemplo, un objeto FileInfo contiene una referencia a un archivo de sistema operativo que tiene una direccin nica en la memoria del proceso del servidor. Puede copiar esta direccin, pero nunca tendr sentido en otro proceso. En estos casos, el proceso del servidor deb era pasar al proceso del cliente una referencia al objeto 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 vez de eso, el sistema de interaccin remota rene toda la informacin referente a la llamada y la enva al proceso del servidor, donde se interpreta, se busca el objeto del servidor correcto y se realiza la llamada a dicho objeto en nombre del objeto del cliente. A c ontinuacin, se devuelve el resultado de la llamada al proceso del cliente para que se lo devuelva a su vez al cliente. El ancho de banda se utiliza nicamente para la informacin esencial: la llamada, sus argumentos y todas las e cepciones o valores devueltos.

Arquitectura simplificada de interaccin remota

El uso de referencias a objetos para la comunicacin entre objetos de servidor y clientes es la esencia de la interaccin remota. No obstante, la arquitectura de interaccin remota proporciona al programador un procedimiento an ms sencillo. Si configura correctamente el cliente, slo tiene que crear una nueva instancia del objeto remoto mediante new (o la funcin de creacin de instancias del lenguaje de programacin administrado que utilice). Su clien te recibe una referencia al objeto de servidor, lo que le permite llamar a sus mtodos como si el objeto estuviera en su proceso en lugar de estar ejecutndose en otro equipo. El sistema de interaccin remota utiliza objetos proxy para dar la impresin de que el objeto del servidor se encuentra en el proceso del cliente. Los objetos proxy son objetos complementarios, que se presentan como si fueran otro objeto. Cuando un cliente crea una instancia del tipo remoto, la infraestructura de interaccin remota crea un objeto proxy que, para su cliente, tiene exactamente la misma apariencia que el tipo remoto. Su cliente llama a un mtodo en ese objeto proxy y el sistema de interaccin remota recibe la llamada, la dirige hacia el

proceso del servidor, invoca al objeto de servidor y enva el valor devuelto al objeto proxy del cliente, que a su vez devuelve el resultado al cliente. Las llamadas remotas deben ser transmitidas de alguna forma entre el cliente y el proceso del servidor. Si crea un sistema de interaccin remota por su cuenta, podra empezar aprendiendo programacin de redes y una amplia gama de protocolos y especificaciones de formatos de serializacin. En el sistema .NET Remoting, la combinacin de tecnologas subyacentes necesarias para abrir una conexin de red y utilizar un determinado protocolo para enviar los bytes a la aplicacin receptora se representa como un canal de transporte. Un canal es un tipo que toma una secuencia de datos, crea un paquete segn un determinado protocolo de red y lo enva a otro equipo. Algunos canales slo pueden recibir informacin, otros slo pueden enviarla y otros, como las clases predeterminadas TcpChannel y HttpChannel, se pueden utilizar en ambos sentidos. Aunque el proceso del servidor conoce perfectamente todos los tipos, el clie nte slo sabe que necesita una referencia a un objeto de otro dominio de aplicacin, puede que de otro equipo. Desde el exterior del dominio de aplicacin de servidor, una direccin URL ubica el objeto. Las direcciones URL que representan tipos nicos para el mundo exterior son direcciones URL de activacin, que garantizan que su llamada remota va dirigida al tipo apropiado. Para obtener ms informacin, vea Direcciones URL de activacin.

Diseo completo de un sistema de interaccin remota

Imagine que en su equipo se ejecuta una aplicacin y desea utilizar la funcionalidad expuesta por un tipo almacenado en otro equipo. En la ilustracin siguiente se muestra el proceso general de interaccin remota. Proceso de interaccin remota

Si ambas partes de la relacin estn configurados correctamente, un cliente se limita a crear una nueva instancia de la clase de servidor. El sistema de interaccin remota crea un objeto proxy que representa a la clase y devuelve al objeto del cliente una referencia al objeto proxy. Cuando un cliente llama a un mtodo, la infraestructura de interaccin remota controla la llamada, comprueba el tipo de informacin y dirige la llamada por el canal hacia el proceso del servidor. Un canal a la escucha detecta la solicitud y la reenva al sistema de interaccin remota del servidor, que a su vez busca (o crea, si es necesario) y llama al objeto solicitado. A continuacin el proceso se invierte: el sistema de interaccin remota del servidor incluye la respuesta en un mensaje que el canal del servidor enva al canal del cliente. Por ltimo, el sistema de interaccin remota del cliente devuelve el resultado de la llamada al objeto del cliente a travs del objeto proxy. Para que esto funcione se necesita muy poco cdigo propiamente dicho, pero es conveniente reflexionar un poco sobre el diseo y la configuracin de la relacin. El cdigo puede ser totalmente correcto y an as no funcionar porque una direccin URL o un nmero de puerto no lo sean. Para obtene r ms informacin, vea Configuracin. Aunque esta informacin general del proceso bsico de interaccin remota es bastante sencilla, los detalles de los niveles inferiores pue den resultar muy complejos. En otros temas, como los indicados a continuacin, se describen con ms detalle los elementos principales de la interaccin remota.

DIRECCIONES URL DE ACTIVACIN

Los objetos activados en el servidor que se publican en una direccin URL fuera del dominio de aplicacin se denominan tipos conocidos. Por tanto, la direccin URL recibe la denominacin de direccin URL de objeto conocido. Una direccin URL de objeto conocido tiene la siguiente forma: EsquemaProtocolo :// NombreEquipo : Puerto / PosibleNombreAplicacin / UriObjeto No obstante, es importante resaltar que si aloja un objeto remoto en los Servicios de Internet Information Server (IIS), no podr declarar un nombre de aplicacin. En este caso, el directorio virtual de su apl icacin pasa automticamente a ser el nombre de la aplicacin. Adems, podra ser necesario introducir algunos cambios poco importantes. Los objetos activados en el cliente no necesitan una direccin URL nica para cada uno, porque el sistema .NET Remoting genera automticamente una direccin URL nica para cada instancia. Como resultado, la direccin URL que se utiliza para activar un objeto de activacin en el cliente recibe el nombre de direccin URL de activacin en el cliente. Una direccin URL de activacin en el cliente tiene esta forma: EsquemaProtocolo :// NombreEquipo : Puerto / PosibleNombreAplicacin Si usa objetos TcpChannel, se requiere el nmero de puerto.

Con dominios de aplicacin host que no sean IIS, puede configurar el tipo utilizable de forma remota mediante programacin o utilizar un archivo de configuracin. En el segundo caso, debe cargar los valores en el archivo llamando a RemotingConfiguration.Configure y pasando el nombre del archivo de configuracin. (Cuando aloja un tipo utilizable de f orma remota en los Servicios de Internet Information Server (IIS), se detectarn los elementos <service>.) Aunque puede utilizar cualquier nombre de archivo para el archivo de configuracin de interaccin remota, la configuracin de la seguridad de la aplicacin slo se aplicar si est incluida en un archivo cuyo nombre tenga esta forma: <NombreAplicacin>.<ExtansinArchivo>.confi

Se recomienda utilizar este formato de nombre de archivo en la mayora de los casos. Por ejemplo, si el ejecutable host es MiServidor.exe, el nombre apropiado para el archivo de configuracin es MiServidor.exe.config. Independientemente del nombre de archivo que elija, puede pasar varios archivos de configuracin a Confi ure. A menudo resulta til especificar los canales, formateadores y proveedores de canales personalizados en otro archivo o archivos y, despus, registrarlos todos en sucesivas llamadas a Confi ure. De esta forma podr copiar los archivos de configuracin que slo se encargan de los canales, los proveedores o de cualquier otra funcionalidad personalizada. Si especifica plantillas de canales personalizados en un archivo Channels.config y proveedores personalizados en un archivo Providers.config, puede usar las llamadas que se muestran en el siguiente ejemplo de cdigo para configurar su cliente de interaccin remota.

LMITES: PROCESOS Y DOMINIOS DE

APLICACIN
Los sistemas operativos y los entornos de motores de tiempo de ejecucin modernos necesitan proteger cada aplicacin frente a los errores de las dems aplicaciones. Este mecanismo de proteccin se implementa mediante el uso de procesos y dominios de aplicacin.

Procesos
Para proteger a unas aplicaciones de otras, en los sistemas operativos Microsoft Windows se ejecutan cada una en su propio proceso. Si se produce un error en una aplicacin por algn motivo, slo se ve afectado ese proceso, mientras que las aplicaciones de otros procesos siguen funcionando. Naturalmente, debido a que las direcciones de memoria en un proceso no tienen sentido en ningn otro, puede resultar un tanto complejo llamar a las funciones de un proceso desde otro. Clculo de referencias es el trmino asignado a los eventos que se producen cuando una llamada y sus argumentos se empaquetan en un proceso y se

desempaquetan en otro, de manera que una llamada que atraviese el lmite de un proceso pueda realizarse.

Dominios de aplicacin
En el entorno administrado, los dominios de aplicacin, que se pueden considerar co mo procesos lgicos, y los contextos proporcionan aislamiento y seguridad a un costo menor y con una capacidad mayor para escalar correctamente que un proceso de sistema operativo, gracias, entre otros factores, al hecho de que el cdigo administrado dispone de seguridad de tipos verificable. Toda aplicacin administrada se ejecuta en un dominio de aplicacin, tanto si otra aplicacin inicia un dominio en su lugar como si el entorno host inicia uno por ella. .NET Remoting facilita la infraestructura para comunicarse entre dominios de aplicacin de una manera sencilla, protegida por las tecnologas de seguridad.