PDF de programación - Curso 2014 4

Introducción
En esta nueva práctica vamos a seguir explorarando nuevos “modo de vida”. Ya
hemos visto que este concepto es fundamental para entender el funcionamiento de
una aplicación distribuida.

Curso de Middleware. Práctica 4.

1 de 11

Extendiendo los modos de vida
Hasta el momento hemos vistos dos modelos de vida de los objetos remotos:
SingleCall y Singleton. En ambos casos, el servidor crea el objeto cuando el cliente
realiza una petición. En el caso del SingleCall el servidor elimina el objeto cuando
termina la llamada y en el caso de Singleton el objeto sigue activo durante un tiempo
que puede ser configurable. En este ejemplo vamos a trabajar con nuevos modos de
vida de un objeto.
El modo “SingleCall” es un modo de vida que recuerda mucho la filosofía de HTTP y
de las páginas web. Se abre una conexión, se solicita un recurso y se cierra la
conexión. Al menos en su forma más habitual. Se suele utilizar cuando se requiere un
servicio que no mantiene un estado previo. Por ejemplo, para lanzar una impresión en
un servidor de impresoras.
El modo “Singleton” en cambio se utiliza cuando es necesario mantener un estado en
el servidor y que este estado sea común y único entre todos los clientes. El ejemplo
más representativo es el servidor de nombres que hemos desarrollado durante este
curso.
Pero a veces es necesario mantener un estado y que este estado sea propio de cada
cliente. Un ejemplo de ello se produce en la lista de la compra en los comercios
online. Cada usuario tiene su propia lista de compra y no esperamos que un usuario
vea lo que está comprando otro. En estos casos, los modos de vida anteriores no
suelen ser recomendables. Queremos que sea el programa cliente quien tenga dicha
responsabilidad de crear y mantener el objeto remoto. En ese caso hablamos de
objetos activados por el cliente (Client-Activated Object o CAO).
Antes de entrar en ese concepto vamos a ver cómo se puede configurar Remoting sin
necesidad de ficheros. Para ello vamos a reemplazar el fichero de configuración por
una configuración por código. La configuración por fichero es muy cómoda si la
configuración es conocida de antemano ya que nos evita tener que recompilar el
código. Pero habrá veces que no es posible conocer los parámetros de la configuración
hasta el momento de la ejecución (por ejemplo, si le pedimos al usuario los datos de
conexión). En esos casos, la configuración tendremos que hacerla por programa. El
código del servidor sería algo del estilo:

Curso de Middleware. Práctica 4.

2 de 11

//Servidor.cs
using System;
using System.Runtime.Remoting;

//Atencion a estos using:
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

using Calculo;

public class Servidor
{

public static void Main (string[] args)
{
//RemotingConfiguration.Configure("Servidor.config");

HttpChannel chnl = new HttpChannel(1234);
ChannelServices.RegisterChannel(chnl);

RemotingConfiguration.RegisterWellKnownServiceType(



typeof(Calculo.Calculadora),
"Calculadora.remota",
WellKnownObjectMode.Singleton);


Console.WriteLine("Atendiendo las peticiones...");

Console.WriteLine("Pulse Enter para salir...");
Console.ReadLine();

}

}

Si comparamos el fichero de configuración con el código utilizado es evidente la
correspondencia entre uno y el otro. Podemos observar que hemos reemplazado la
llamada a “Configure” por una llamadas a “RegisterChannel” y a
“RegisterWellKnownServiceType “. La primera llamada es necesaria hacerla por cada
uno de los canales que tengamos abiertos en nuestro servidor. La segunda es necesaria
para cada tipo de objeto que queramos publicar. En nuestro ejemplo hemos definido el
objeto como Singleton.
Notad también que hemos incluido los nombres de espacio (namespace)
“System.Runtime.Remoting.Channels” y “System.Runtime.Remoting.Channels.Http“.
Esto es necesario para tener visibilidad sobre las funciones mencionadas.
Dependiendo de la configuración de tu máquina es probable que, para compilar el
ejemplo, tengas que incluir la librería System.Runtime.Remoting.dll en el proceso de

Curso de Middleware. Práctica 4.

3 de 11

compilación.
El cliente también podemos configurarlo mediante programa. Por ejemplo:

//Cliente.cs
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

using Calculo;

public class Cliente
{

public static void Main (string[] args)
{
//RemotingConfiguration.Configure("Cliente.config");



HttpChannel chnl = new HttpChannel();
ChannelServices.RegisterChannel(chnl);

RemotingConfiguration.RegisterWellKnownClientType(

typeof(Calculo.Calculadora),
"http://localhost:1234/Calculadora.remota"
);



Console.WriteLine("Creando la calculadora");
Calculadora calc = new Calculadora();



......

Console.WriteLine("Pulse Enter para salir...");
Console.ReadLine();

}

}

Para el cliente podemos hacer los mismos comentarios que hemos hecho para el
servidor. Dejamos al alumno analizar el código y estudiar la correspondencia con el
fichero de configuración.

Curso de Middleware. Práctica 4.

4 de 11

Modo de vida de objeto publicado
Hasta el momento hemos vistos dos modelos de vida de los objetos remotos:
SingleCall y Singleton. En ambos casos, el servidor crea el objeto cuando el cliente
realiza una petición. En el caso del SingleCall el servidor elimina el objeto cuando
termina la llamada y en el caso de Singleton el objeto sigue activo durante un tiempo
que puede ser configurable. En este ejemplo vamos a trabajar con dos nuevos modos
de vida de un objeto.
Hay ocasiones en los que el servidor tiene que crear el objeto antes de cualquier
llamada de los clientes. En este caso, el servidor primero crear los objetos y después
los “publica”. Veamos un ejemplo:

using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

using Calculo;

public class Servidor
{

public static void Main (string[] args)
{
//RemotingConfiguration.Configure("Servidor.config");

HttpChannel chnl = new HttpChannel(1234);
ChannelServices.RegisterChannel(chnl);

Calculadora calc = new Calculadora();
RemotingServices.Marshal

(calc,"Calculadora.remota");


Console.WriteLine("Atendiendo las peticiones...");

Console.WriteLine("Pulse Enter para salir...");
Console.ReadLine();

}

}

El resto del código, incluyendo el correspondiente al cliente, sigue siendo el mismo.

Curso de Middleware. Práctica 4.

5 de 11

Modo de vida de objeto activado por cliente
Este tipo de objetos se llaman objetos publicados y junto con los objetos de llamada
simple o los singleton forman el grupo de objetos activados por el servidor (Server-
Activated Object o también conocidos por SAO). Se llaman de esta forma el hecho de
que cuando un cliente crea un objeto remoto, realmente lo que hace es crear un proxy
al objeto sin comunicarse con el servidor. Únicamente cuando el cliente utiliza alguno
de los servicios del objeto se pone en contacto con el servidor. En ese momento el
servidor decide si crear o reutilizar alguno de los objetos que tiene a tal efecto. Esto
es, la responsabilidad de la vida del objeto recae sobre el servidor.
Cuando queremos que sea el cliente quien tenga dicha responsabilidad hablamos de
objetos activados por el cliente (Client-Activated Object o CAO). Veamos un ejemplo
de como se usan. Primero el servidor:

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

using Calculo;

public class Servidor
{

public static void Main (string[] args)
{

HttpChannel chnl = new HttpChannel(1234);
ChannelServices.RegisterChannel(chnl);

RemotingConfiguration.ApplicationName =

"UnServidorDelCurso";

RemotingConfiguration.RegisterActivatedServiceType(

typeof(Calculo.Calculadora));


Console.WriteLine("Atendiendo las peticiones...");

Console.WriteLine("Pulse Enter para salir...");
Console.ReadLine();

}

}

Ahora la configuración del servidor es ligeramente diferente. Lo que publicamos es el
nombre del servidor en lugar del nombre de los recursos que atiende dicho servidor.
En nuestro ejemplo, hemos asignado un nombre de “UnServidorDelCurso”.

Curso de Middleware. Práctica 4.

6 de 11

El código del cliente sería parecido a:

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;

using Calculo;

public class Cliente
{

public static void Main (string[] args)
{
HttpChannel chnl = new HttpChannel();
ChannelServices.RegisterChannel(chnl);

RemotingConfiguration.RegisterActivatedClientType(

typeof(Calculo.Calculadora),
"http://localhost:1234/UnServidorDelCurso");



Console.WriteLine("Creando muchas calculadoras");

Calculadora calc1 = new Calculadora();
Calculadora calc2 = new Calculadora();
Calculadora calc3 = new Calculadora();

.......

}

}

En este ejemplo, el cliente sigue actuando como de costumbre. Para ver la diferencia
en el comportamiento os proponemos incluir algunas trazas en el cliente con puntos
de parada controladas (con lectura del teclado por ejemplo). Observad la secuencia de
llamadas y de creación de objetos.

Curso de Middleware. Práctica 4.

7 de 11

Ejercicios adicionales

Os proponemos varios ejercicios que nos ayuden a entender el comportamiento de
estas características:
1.- Modifica el código de la calculadora de tal forma que puedas determinar cuantos
objetos se crean y si éstos se comparten entre los clientes. T