.NET REMOTING
by Juan Martínez Gil
[email protected]
Índice de contenidos
Parte
1: Introducción a .NET
Parte
2: .NET Remoting
[email protected]
2
La plataforma .NET: introducción




Apuesta de Microsoft para competir con la plataforma Java.
Objetivo: desarrollar componentes software utilizando casi
cualquier lenguaje, de forma que lo que escribamos en un
lenguaje pueda utilizarse desde cualquier otro
transparentemente (servicios web como middleware).
Compiladores de múltiples lenguajes (Visual Basic .NET,
C#, Eiffel, Smalltalk, etc...).
Conjunto de tecnologías para desarrollar y utilizar
componentes que nos permitan crear formularios web,
servicios web y aplicaciones Windows.
[email protected]
3
La plataforma .NET: modelos

Nuevo modelo de ejecución:
– Common Language Runtime (CLR): similar a la
máquina virtual de Java
– Máquina virtual que ejecuta código intermedio (MSIL).
– Orientado a objetos, garbage collection, nuevo modelo
de delegación de eventos, seguridad,...
– Independiente del lenguaje de programación:



CTS (Common Type System).
CLS (Common Language Specification): permite que puedan
interactuar fragmentos de código escritos en distintos lenguajes
(C#, VB.NET. Managed C++, Eiffel.NET, etc...).
Nuevo modelo de componentes:
– Ensamblados. Reemplazan a COM.
[email protected]
4
La plataforma .NET: assemblies (1)

Los assemblies constituyen la unidad lógica de
despliegue en la plataforma .NET. Vienen a ser
algo parecido a los ficheros JAR de Java.
[email protected]
5
La plataforma .NET: assemblies (y 2)

Un assembly incluye:
– metadatos acerca de los componentes incluidos en el
assembly (versiones, tipos, dependencias, etc...).
– metadatos acerca de los tipos incluidos (propiedades,
atributos, métodos, signaturas, clases base...)
– el código intermedio MSIL (Microsoft Intermediate
Language, similar a los bytecodes de Java).
– los recursos adicionales que sean necesarios (imágenes,
textos...).

Una aplicación está formada por uno o varios
assemblies.
[email protected]
6
La plataforma .NET: MSIL

Para que un lenguaje sea soportado ha de existir un
compilador que lo traduzca a MSIL. A la hora de
ejecutar el código intermedio, éste es siempre
compilado a código nativo.
[email protected]
7
La plataforma .NET: aportaciones






Programación de interfaces gráficas (WinForms) y
de interfaces web (ASP.NET, WebForms).
Acceso a datos de forma independiente al lenguaje
de programación: ADO.net (similar a ADO).
Los datos se pueden ver y procesar de forma
relacional (tablas) o jerárquica (XML).
Framework acceso remoto (.NET Remoting),
que sustituye a DCOM.
XML y servicios web integrados en la plataforma.
Dominios de aplicación, programación
orientada a aspectos (atributos), etc...
[email protected]
8
La plataforma .NET: formularios

Los formularios Windows están construidos sobre
la base de la plataforma .NET.
– Permiten construir complejas aplicaciones Windows en
un entorno de desarrollo visual de aplicaciones (RAD:
Rapid Application Development)..

Los formularios web se construyen con ASP.NET
(evolución natural y lógica de ASP).
– ASP.NET permite utilizar controles complejos, facilita
la gestión de sesiones, permite separar la interfaz de la
lógica interna, elimina la distinción entre ASP e ISAPI
y nos permite emplear cualquier lenguaje de
programación que esté soportado por .NET.
[email protected]
9
La plataforma .NET: instalación

SDK(Software Development Kit):
incluye la
plataforma .NET y todo lo necesario para
desarrollar, compilar, probar y distribuir
aplicaciones para la plataforma .NET.
 Se necesita uno de los siguientes SO’s:
– Microsoft Windows NT 4.0 (Service Pack 6a)
– Microsoft Windows 2000 (SP 2 recomendado)
– Microsoft Windows XP Professional

Recomendado Internet Explorer 5.01 o posterior.
 Visual Studio .NET incluye la plataforma .NET (no
hay que instalar el SDK).
[email protected]
10
La plataforma .NET: comparación

.NET vs J2EE (Java 2 Enterprise Edition)
[email protected]
11
.NET Remoting: introducción (1)

Tecnología de objetos distribuidos sucesora de
DCOM.
 Objetivo: crear herramientas que faciliten la
distribución de la aplicación en red de forma
transparente.
 Marco variado y extensible para que los objetos de
distintos dominios de aplicaciones, procesos y
equipos se puedan comunicar sin problemas.
 Ideas fundamentales encontradas ya en CORBA o
Java RMI, aunque la combinación final es algo
diferente.
[email protected]
12
.NET Remoting: introducción (y 2)

Gran flexibilidad.
 Tecnologías independientes del lenguaje de
programación y con las comunicaciones en un
nivel de abstracción elevado.
 Modelo de programación sencillo y eficaz, así
como compatibilidad en tiempo de ejecución que
permite interacciones transparentes.
 Va un poco más allá de la distribución de
aplicaciones en red de forma transparente.
[email protected]
13
.NET Remoting: definiciones (1)

Un AppDomain es el entorno donde se ejecuta la
aplicación, por lo que la comunicación se dará
entre distintos AppDomains, siendo un
AppDomain el cliente y otro el servidor.
 Un canal es la forma de ordenar, formatear o
transmitir mensajes a través de AppDomains, de
forma que nosotros podamos decir que queremos
transmitir un mensaje bien por medio de un
protocolo de transporte como el TCP o de
aplicación como pudiese ser el HTTP o cualquier
canal implementado por la arquitectura.
[email protected]
14
NET Remoting: definiciones (y 2)

Un proxy es un objeto que se encarga de abstraer
la comunicación entre cliente/servidor de forma
que los objetos de otro AppDomain (remotos)
parezcan locales.
 Un sumidero (sink) es un recipiente capaz de
recibir mensajes de Remoting (IMessage),
tratarlos y enviarlos al siguiente sumidero en la
cadena de comunicación.
[email protected]
15
.NET Remoting: comunicación (1)

Forma práctica de administrar conversaciones
RPC sincrónicas y asincrónicas cliente/servidor a
través de dominios de aplicación (AppDomains).
 Para poder invocar métodos en un objeto remoto
necesitamos un proxy en el cliente, y para poder
crearlo se necesita especificar el canal y la
localización del objeto remoto; este proxy recibe
las peticiones del cliente y se comunica
remotamente de forma totalmente transparente con
el servidor en el otro AppDomain, tratando los
objetos como si fuesen locales.
[email protected]
16
.NET Remoting: comunicación (2)

El primer sumidero transforma la invocación del
cliente en un mensaje aplanado (serializado) que
se irá enviando a cada uno de los sumideros que
separan al cliente del sumidero final que introduce
la información en el canal real.
 El mensaje se transmite de un sumidero canal en el
cliente a un sumidero canal del servidor, que
realiza el proceso inverso al del cliente e invoca el
método sobre el objeto indicado.
 Los parámetros de retorno (si los hay) se envían
de vuelta al cliente utilizando el mismo canal.
[email protected]
17
.NET Remoting: comunicación (y 3)
[email protected]
18
.NET Remoting: objetos (1)

Objetos activados en el servidor cuando el cliente
invoca el 1º método (sólo cuando es necesario).
 Tipos de objetos remotos:
– Activados en el servidor (SAO: Server Activated
Object):


Singleton: 1 sóla instancia sirve a todos los clientes.
SingleCall: 1 instancia por cada solicitud.
– Activados por el cliente (CAO: Client Actived Object):


Objetos activados por el cliente
Publicación dinámica: publicación de un
determinado objeto en una dirección URL
específica.
[email protected]
19
.NET Remoting: objetos (2)

Objetos de llamada única (SingleCall): se activan
cuando llega una petición para ellos, ejecutan la
petición y se desactivan. No conservan estado
entre conexiones (Ej: HTTP 1.0).
 Objetos "Singleton“: dan servicio a varias
peticiones de clientes diferentes manteniendo el
estado.
 Objetos activados en el cliente: llamada “new” o
“Activator.CreateInstance()” y se envía la solicitud
al servidor; cada cliente es atendido por su propia
instancia del servidor específica.
[email protected]
20
.NET Remoting: objetos (3)

Con los servicios remotos .NET se pueden pasar
objetos de una aplicación a otra de diversas
maneras:
– En forma de parámetros en las llamadas a métodos:
public int myRemoteMethod (MyRemoteObject myObj)
– Como valor de devolución de las llamadas a métodos:
public MyRemoteObject myRemoteMethod(String myString)
– En forma de valores derivados del acceso a los campos
o propiedades de un componente .NET:
myObj.myNestedObject
[email protected]
21
.NET Remoting: objetos (y 4)

Cada vez que se pasan objetos definidos como
cálculo mediante valor (MBV) de una aplicación
a otra, se realiza una copia completa de los
mismos.
 Cada vez que se pasan objetos definidos como
cálculo mediante referencia (MBR) de una
aplicación a otra, se establece una referencia para
los mismos. Cuando la referencia al objeto
(ObjRef) llega a la aplicación remota, se convierte
en un "proxy" en el objeto original.
[email protected]
22
.NET Remoting: acceso objetos

Hay que conocer las interfaces del objeto remoto
para poder construir el proxy (ObjRef) que
permita acceder a él.
 Se introducirá su localización en los ficheros de
configuración del canal o se pasará su URI al
objeto con el que obtener una referencia (proxy).
 Cuando el propio objeto remoto (no proxy) llega
al cliente, se puede utilizar de forma local (copia
por valor, no por referencia). El objeto debe
pertenecer a una clase serializable, es decir, que
se pueda convertir a un estado persistente que se
pueda transmitir.
[email protected]
23
.NET Remoting: ejemplo (1)

Código de ejemplo para un objeto simple de
servidor de los servicios remotos .NET:
using System;
using System.Runtime.Remoting;
namespace myRemoteService {
public class myRemoteObject : MarshalByRefObject {
public String myRemoteMethod(String s) {
return "Hello World";
}
}
}
[email protected]
24
.NET Remoting: ejemplo (2)

Código de ejemplo del cliente para obtener acceso
a este objeto (parte 1):
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using myRemoteService;
public class Client {
public static int Main(string[] args) {
ChannelServices.RegisterChannel(new HttpChannel());
[email protected]
25
.NET Remoting: ejemplo (y 3)

Código de ejemplo del cliente para obtener acceso
a este objeto (parte 2):
// Crear una instancia de la clase myRemoteObject
myRemoteObject myObj = (myRemoteObject)
Activator.GetObject (typeof(myRemoteObject),
"http://myHost:7021/host/myRemoteObject.soap");
myObj. myRemoteMethod ("Hello World");
return 0;
}
}
[email protected]
26
.NET Remoting: duración

Basada en concesiones.
 Para los objetos con referencias a objetos que se
transportan fuera de la aplicación, se crea una
concesión con un tiempo determinado ampliable.
 Cuando el tiempo de concesión llega a cero, la
concesión caduca y el objeto se desconecta del
marco de los servicios remotos .NET.
 Se podrá recopilar durante la siguiente recolección
de elementos no utilizados si se han liberado todas
las referencias al objeto dentro del dominio de la
aplicación.
[email protected]
27
.NET Remoting: alojamiento

Los objetos de servicios remotos .NET se pueden
alojar en:
– Un ejecutable administrado: cualquier archivo .NET
EXE normal o en un servicio administrado.
– IIS (Internet Information Server): los objetos reciben
los mensajes a través del canal HTTP. Se debe crear una
raíz virtual, en la que se copiará"remoting.config“. El
ejecutable o la DLL que contiene el objeto remoto se
debe colocar en el directorio “bin”, en el directorio al
que señala la raíz de IIS.
– Servicios de componentes .NET: para aprovechar los
diferentes servicios de COM+, tales como las
transacciones, JIT, la agrupación de objetos, etc...
[email protected]
28
.NET Remoting: servicios del canal

System.Runtime.Remoting.Channels.
 Facilitan el medio de transporte necesario para
establecer estas comunicaciones.
 Canales HTTP (protocolo SOAP) y TCP (carga
binaria).
 Se pueden conectar (a través de IChannel)
utilizando canales personalizados en los que se
puede escribir para permitir la integración de
aplicaciones muy diversas.
[email protected]
29
.NET Remoting: serialización

Formateadores de serialización
(System.Runtime.Serialization.Formatters).
 Codifican y decodifican los mensajes con los que
se comunican los dominios de aplicaciones y las
aplicaciones .NET.
 2 formateadores nativos: Binario y SOAP.
 Se pueden conectar implementando la interfaz
IRemotingFormatter y conectándola al canal
mencionado anteriormente.
[email protected]
30
.NET Remoting: contextos (1)

Un contexto es un límite que contiene objetos que
comparten propiedades comunes en tiempo de
ejecución.
 Cada vez que se activa un objeto .NET, el tiempo
de ejecución comprueba si el contexto actual es
compatible para, en caso de que no lo fuera, crear
un nuevo contexto.
 En un único contexto se pueden ejecutar varios
objetos a la vez, y puede existir más de un
contexto en un dominio de aplicación.
[email protected]
31
.NET Remoting: contextos (y 2)

La llamada desde un objeto perteneciente a un
contexto hacia otro objeto de un contexto diferente
pasará por un proxy de contextos.
 Existen unas clases relacionadas últimamente a un
contexto determinado, a las que se pueden asignar
atributos personalizados especiales, conocidos
como atributos de contexto. Estos atributos son
totalmente extensibles y se pueden generar y
adjuntar a la clase.
 Los objetos que se encuentran limitados a un
contexto derivan de System.ContextBoundObject.
[email protected]
32
.NET Remoting: metadatos

Se utilizan para almacenar la información
sobre los componentes, permitiendo la
programación en varios lenguajes.
 Permiten crear objetos proxy de forma
dinámica.
 El formateador de serialización utiliza
metadatos para convertir las llamadas a
métodos en flujo de carga y viceversa.
[email protected]
33
.NET Remoting: configuración





Los archivos de configuración (.config) se utilizan
para especificar la información concreta sobre
servicios remotos de un objeto determinado.
1 objeto AppDomain – 1 archivo de configuración
Se favorece la transparencia de ubicación.
Se separa la información transparente de
configuración del código del cliente, para así
poder realizar cambios modificando simplemente
el archivo de configuración, sin necesidad de
editar y volver a compilar el de origen.
Pueden utilizarlos tanto cliente como servidor.
[email protected]
34
.NET Remoting: escenarios

Combinaciones cliente-servidor
[email protected]
35
.NET Remoting: conclusiones





Arquitectura para distribuir objetos sencilla.
No intenta alcanzar potencia y flexibilidad de
CORBA.
Muy sencilla de utilizar para el desarrollador (los
detalles pasan inadvertidos).
Marco eficaz, extensible e independiente del
lenguaje que permite desarrollar sistemas
distribuidos sólidos y escalables.
Servicios remotos integrados a la perfección con
los servicios Web y permiten exponer objetos
.NET para tener acceso en varias plataformas.
[email protected]
36
Descargar

.NET REMOTING