remoting .net (vs2005)

5/7/2018 Remoting .NET (VS2005) - slidepdf.com

http://slidepdf.com/reader/full/remoting-net-vs2005 1/7

nformación general de .NET Framework

Remoting

Visual Studio 2005

Otras versiones

y .NET Framework 4

y Visual Studio 2008

.NET Remoting permite crear fácilmente aplicaciones ampliamente distribuidas, tanto

si los componentes de las aplicaciones están todos en un equipo como si estánrepartidos 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 .

También se puede utilizar .NET Remoting para comunicarse con otros dominios de

aplicación en el mismo proceso. (Para obtener más información sobre la programación

de los dominios de aplicación, vea Programar con dominios de aplicación.)

.NET Remoting proporciona un enfoque abstracto en la comunicación entre procesos

que separa el objeto utilizado de forma remota de un dominio de aplicación de cliente

o servidor específico y de un mecanismo específico de comunicación. Por lo tanto, se

trata de un sistema flexible y fácilmente personalizable. Se puede reemplazar un

protocolo de comunicación con otro o un formato de serialización con otro sin tenerque recompilar el cliente ni el servidor. Además, el sistema de interacción remota no

presupone ningún modelo de aplicación en particular. Se puede comunicar desde una

aplicación Web, una aplicación de consola, un servicio de Windows, desde casi

cualquier aplicación que se desee utilizar. Los servidores de interacción remota

también pueden ser cualquier tipo de dominio de aplicación. Cualquier aplicación

puede albergar objetos de interacción 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 interacció

remota a través de canales seguros. No exponga nunca extremos de interacció

remota inseguros en Internet.

Si desea utilizar .NET Remoting para crear una aplicación en la que dos componentes

se comunican directamente más allá de los límites de los dominios de aplicación, sólo

deberá crear lo siguiente:

y Un objeto que se puede utilizar de forma remota.



y Un dominio de aplicación hos

para esc¡

char las solicitudes de dicho ob jeto.

y Un dominio de aplicación de cli ente que realiza solicitudes para dicho ob jeto.

Incluso en una aplicación compleja de varios clientes o servidores¢

.NET Remoting

puede considerarse de esta manera. Las aplicaciones host y cliente también deben

configurarse con la infraestructura remota y es preciso comprender las cuestiones de

vida útil y de activación que conlleva dicha infraestructura.

Arquit tura d .N Framework

Remotin

Visual Studio 2005

La infraestructura de .N £

¤

Remotin¥

es un enfoque abstracto de la comunicación entre

procesos. La mayor parte del sistema funciona sin llamar la atención. Por ejemplo, los

ob jetos que se pueden pasar por valor, o copiar, se pasan automáticamente de una

aplicación a otra en dominios de aplicación o en equipos distintos. Sólo tiene que

marcar sus clases personalizadas como serializables para que el sistema funcione.

Pero la verdadera venta ja del sistema de interacción remota es su capacidad para

permitir la comunicación entre ob jetos pertenecientes a dominios de aplicación o a

procesos distintos mediante dif erentes protocolos de transporte, formatos de

serialización, esquemas de duración de ob jetos y modos de creación de ob jetos.

Además, la interacción remota permite intervenir en prácticamente todas las fases del

proceso de comunicación, sea cual sea la razón.

Tanto si implementó una serie de aplicaciones distribuidas como si sólo desea movercomponentes a otros equipos para aumentar la escalabilidad de su programa, le

resultará más fácil si considera el sistema de interacción remota como un sistema

genérico de comunicación entre procesos con algunas implementaciones

predeterminadas capaces de controlar fácilmente la mayoría de los escenarios

posibles. La e¦ plicación siguiente comienza con los principios básicos de la

comunicación entre procesos mediante la interacción remota.

Copias y ref eren ias

La comunicación entre procesos requiere un ob jeto servidor cuya funcionalidad esté adisposición de los llamadores fuera de su proceso, un cliente que realice llamadas al

ob jeto servidor y un mecanismo de transporte que lleve las llamadas de un e§

tremo a

otro. Las direcciones de los métodos del servidor son lógicas y funcionan

correctamente en un proceso, pero no funcionan en otro proceso de cliente. Para

solucionar este problema, el cliente puede llamar a un ob jeto servidor realizando una

copia de todo el ob jeto y pasándola al proceso de cliente, donde se pueden invocar

directamente los métodos de la copia.



No obstante, muchos ob jetos no se pueden o no se deben copiar ni pasar a otros

procesos para ejecutarse. Los ob jetos sumamente grandes con muchos métodos son

los menos aconsejables para copiar o pasar por valor a otros procesos. Normalmente,

un cliente sólo necesita la información devuelta por un solo método o por unos pocos

en el ob jeto servidor. Copiar el ob jeto servidor entero, incluyendo lo que podrían ser

enormes cantidades de información interna o estructuras ejecutables no relacionadas

con las necesidades del cliente, supondría desperdiciar el ancho de banda así como la

memoria del cliente y el tiempo que se emplea en procesarlo todo. Además, muchos

ob jetos e ̈ ponen una funcionalidad pública pero requieren datos privados para la

ejecución interna. Copiar estos ob jetos podría permitir que clientes no autorizados

e ̈ aminaran datos internos, lo que posibilitaría la aparición de problemas de seguridad.

Por último, algunos ob jetos utilizan datos que no se pueden copiar de ninguna forma

comprensible. Por ejemplo, un ob jeto FileInfo contiene una ref erencia a un archivo de

sistema operativo que tiene una dirección única en la memoria del proceso del

servidor. Puede copiar esta dirección, pero nunca tendrá sentido en otro proceso.

En estos casos, el proceso del servidor deb ería pasar al proceso del cliente una

ref erencia al ob jeto servidor, en lugar de una copia del ob jeto. Los clientes pueden

utilizar esta ref erencia para llamar al ob jeto del servidor. Estas llamadas no se ejecutan

en el proceso del cliente. En vez de eso, el sistema de interacción remota reúne toda la

información ref erente a la llamada y la envía al proceso del servidor, donde se

interpreta, se busca el ob jeto del servidor correcto y se realiza la llamada a dicho

ob jeto en nombre del ob jeto del cliente. A c ontinuación, 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 información esencial: la llamada, sus argumentos y

todas las e ̈

cepciones o valores devueltos.

Arquitectura simplificada de interacción remota

E l uso de referencias a objetos para la comunicación entre objetos de servidor y clientes

es la esencia de la interacción remota. No obstante, la arquitectura de interacción

remota proporciona al programador un procedimiento aún más sencillo. Si configura

correctamente el cliente, sólo tiene que crear una nueva instancia del ob jeto remoto

mediante new (o la función de creación de instancias del lengua je de programación

administrado que utilice). Su cliente recibe una ref erencia al ob jeto de servidor, lo que

le permite llamar a sus métodos como si el ob jeto estuviera en su proceso en lugar de

estar ejecutándose en otro equipo. El sistema de interacción remota utiliza objetos proxy para dar la impresión de que el ob jeto del servidor se encuentra en el proceso

del cliente. Los ob jetos proxy son ob jetos complementarios, que se presentan como si

fueran otro ob jeto. Cuando un cliente crea una instancia del tipo remoto, la

infraestructura de interacción remota crea un ob jeto proxy que, para su cliente, tiene

exactamente la misma apariencia que el tipo remoto. Su cliente llama a un método en

ese ob jeto proxy y el sistema de interacción remota recibe la llamada, la dirige hacia el



proceso del servidor, invoca al ob jeto de servidor y envía el valor devuelto al ob jeto

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 interacción remota por su cuenta, podría

empezar aprendiendo programación de redes y una amplia gama de protocolos y

especificaciones de formatos de serialización. En el sistema .NET Remoting, la

combinación de tecnologías subyacentes necesarias para abrir una conexión de red y

utilizar un determinado protocolo para enviar los bytes a la aplicación receptora se

representa como un canal de tr ansporte.

Un canal es un tipo que toma una secuencia de datos, crea un paquete según un

determinado protocolo de red y lo envía a otro equipo. Algunos canales sólo pueden

recibir información, otros sólo pueden enviarla y otros, como las clases

predeterminadas TcpChannel y HttpChannel, se pueden utilizar en ambos sentidos.

Aunque el proceso del servidor conoce perf ectamente todos los tipos, el clie nte sólo

sabe que necesita una ref erencia a un ob jeto de otro dominio de aplicación, puede

que de otro equipo. Desde el exterior del dominio de aplicación de servidor, una

dirección URL ubica el ob jeto. Las direcciones URL que representan tipos únicos para el

mundo exterior son direcciones URL de activación, que garantizan que su llamada

remota va dirigida al tipo apropiado. Para obtener más información, vea Direcciones

URL de activación.

Diseño completo de un sistema de

interacción remota

Imagine que en su equipo se ejecuta una aplicación y desea utilizar la funcionalidad

expuesta por un tipo almacenado en otro equipo. En la ilustración siguiente se muestra

el proceso general de interacción remota.

Proceso de interacción remota



Si ambas partes de la relación están configurados correctamente, un cliente se limita a

crear una nueva instancia de la clase de servidor. El sistema de interacción remota crea

un ob jeto proxy que representa a la clase y devuelve al ob jeto del cliente una

ref erencia al ob jeto proxy. Cuando un cliente llama a un método, la infraestructura de

interacción remota controla la llamada, comprueba el tipo de información y dirige la

llamada por el canal hacia el proceso del servidor. Un canal a la escucha detecta la

solicitud y la reenvía al sistema de interacción remota del servidor, que a su vez busca

(o crea, si es necesario) y llama al ob jeto solicitado. A continuación el proceso se

invierte: el sistema de interacción remota del servidor incluye la respuesta en un

mensa je que el canal del servidor envía al canal del cliente. Por último, el sistema de

interacción remota del cliente devuelve el resultado de la llamada al ob jeto del cliente

a través del ob jeto proxy.

Para que esto funcione se necesita muy poco código propiamente dicho, pero es

conveniente reflexionar un poco sobre el diseño y la configuración de la relación. El

código puede ser totalmente correcto y aún así no funcionar porque una dirección URL

o un número de puerto no lo sean. Para obtene r más información, vea Configuración.

Aunque esta información general del proceso básico de interacción remota es bastante

sencilla, los detalles de los niveles inf eriores pueden resultar muy complejos. En otros

temas, como los indicados a continuación, se describen con más detalle los elementos

principales de la interacción remota.

DIRECCIONES URL DE ACTIVACIÓN Los ob jetos activados en el servidor que se publican en una direcc ión URL fuera del

dominio de aplicación se denominan tipos conocidos. Por tanto, la dirección URL

recibe la denominación de dirección URL de ob jeto conocido. Una dirección URL de ob jeto conocido tiene la siguiente forma:

E squemaProtocolo :// NombreE quipo : Puerto / PosibleNombreAplicación / UriObjeto

No obstante, es importante resaltar que si alo ja un ob jeto remoto en los Servicios de

Internet Information Server (IIS), no podrá declarar un nombre de aplicación. En este

caso, el directorio virtual de su aplicación pasa automáticamente a ser el nombre de la

aplicación. Además, podría ser necesario introducir algunos cambios poco

importantes.

Los ob jetos activados en el cliente no necesitan una dirección URL única para cadauno, porque el sistema .NET Remoting genera automáticamente una dirección URL

única para cada instancia. Como resultado, la dirección URL que se utiliza para activar

un ob jeto de activación en el cliente recibe el nombre de dirección URL de activación

en el cliente. Una dirección URL de activación en el cliente tiene esta forma:

E squemaProtocolo :// NombreE quipo : Puerto / PosibleNombreAplicación

Si usa ob jetos TcpChannel, se requiere el número de puerto.



Con dominios de aplicación host que no sean IIS, puede configurar el tipo utilizable de

forma remota mediante programación o utilizar un archivo de configuración. En el

segundo caso, debe cargar los valores en el archivo llamando a

RemotingConfiguration.Configur e y pasando el nombre del archivo de configuración.

(Cuando alo ja un tipo utilizable de forma remota en los Servicios de Internet

Information Server (IIS), se detectarán los elementos <service>.) Aunque puede utilizar

cualquier nombre de archivo para el archivo de configuración de interacción remota, la

configuración de la seguridad de la aplicación sólo se aplicará si está incluida en un

archivo cuyo nombre tenga esta forma:

<NombreAplicación>.<Ex tansiónArchivo>.confi©

Se recomienda utilizar este formato de nombre de archivo en la mayoría de los casos.

Por ejemplo, si el ejecutable host es MiServidor.exe, el nombre apropiado para el

archivo de configuración es MiServidor.exe.config.

Independientemente del nombre de archivo que eli ja, puede pasar varios archivos de

configuración a Confi©

ure. A menudo resulta útil especificar los canales,

formateadores y proveedores de canales personalizados en otro archivo o archivos y,

después, registrarlos todos en sucesivas llamadas a Confi©

ure. De esta forma podrá

copiar los archivos de configuración que sólo 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 código para configurar su cliente de interacción remota.

LÍMITES: PROCESOS Y DOMINIOS DE

APLICACIÓN Los sistemas operativos y los entornos de motores de tiempo de ejecución modernos

necesitan proteger cada aplicación frente a los errores de las demás aplicaciones. Este

mecanismo de protección se implementa mediante el uso de procesos y dominios de

aplicación.

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 aplicación por algún

motivo, sólo se ve af ectado 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 ningún otro, puede resultar un tanto complejo llamar a las funciones de un

proceso desde otro. Cálculo de ref erencias es el término 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 límite de un proceso

pueda realizarse.

Dominios de aplicaciónEn el entorno administrado, los dominios de aplicación, que se pueden considerar como

procesos lógicos, 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 código administrado dispone de seguridad de

tipos verificable. Toda aplicación administrada se ejecuta en un dominio de aplicación, tanto si

otra aplicación 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 aplicación de una

manera sencilla, protegida por las tecnologías de seguridad.

remoting .net (vs2005)

Documents