.NET REMOTING

1. .NET REMOTING by Juan Martínez Gil madmaxx2002@wanadoo.es

2. Índice de contenidos • Parte 1: Introducción a .NET • Parte 2: .NET Remoting madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

5. La plataforma .NET: assemblies (1) • Losassemblies constituyen la unidad lógica de despliegue en la plataforma .NET. Vienen a ser algo parecido a los ficheros JAR de Java. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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... madmaxx2002@wanadoo.es

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 webse 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. madmaxx2002@wanadoo.es

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 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). madmaxx2002@wanadoo.es

11. La plataforma .NET: comparación • .NET vs J2EE (Java 2 Enterprise Edition) madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

18. .NET Remoting: comunicación (y 3) madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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é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 madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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"; } } } madmaxx2002@wanadoo.es

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()); madmaxx2002@wanadoo.es

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://myHost:7021/host/myRemoteObject.soap"); myObj. myRemoteMethod ("Hello World"); return 0; } } madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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... madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

30. .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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es

35. .NET Remoting: escenarios • Combinaciones cliente-servidor madmaxx2002@wanadoo.es

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. madmaxx2002@wanadoo.es