'NET REMOTING

1
.NET REMOTING

• by Juan Martínez Gil

2
Índice de contenidos

• Parte 1 Introducción a .NET
• Parte 2 .NET Remoting

3
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.

4
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.

5
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.

6
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.

7
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.

8
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...

9
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.

10
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 SOs
• 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).

11
La plataforma .NET comparación

• .NET vs J2EE (Java 2 Enterprise Edition)

12
.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.

13
.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.

14
.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.

15
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.

16
.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.

17
.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.

18
.NET Remoting comunicación (y 3)
19
.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.

20
.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.

21
.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étodospublic int myRemoteMethod
  (MyRemoteObject myObj)
• Como valor de devolución de las llamadas a
  métodospublic MyRemoteObject myRemoteMethod(Stri
  ng myString)
• En forma de valores derivados del acceso a los
  campos o propiedades de un componente .NET
  myObj.myNestedObject

22
.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.

23
.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.

24
.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"

25
.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())

26
.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//myHost7021/host/myRemoteObject.soap")
  myObj. myRemoteMethod ("Hello World")
  
• return 0

27
.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.

28
.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...

29
.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.

30
.NET Remoting serialización

• Formateadores de serialización (System.Runtime.Ser
  ialization.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.

31
.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.

32
.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.

33
.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.

34
.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.

35
.NET Remoting escenarios

• Combinaciones cliente-servidor

36
.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.