11 .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.
12 .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.
13 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.
14 .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.
15 .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.
16 .NET Remoting: comunicación (y 3)
17 .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.
18 .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.
19 .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
20 .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.
21 .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.
22 .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"; } } }
23 .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());
24 .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; } }
25 .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.
26 .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…
27 .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.
28 .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.
29 .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.
30 .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.
| Página siguiente |