APLICACIONES DISTRIBUIDAS.

REMOTING A. SERVICIOS Y MECANISMOS QUE OFRECE UN MIDDLEWARE

1. Conoces y puedes explicar las palabras reservadas del código, en particular conoces la diferencia entre paquete (o namespace) y clase. ¿Sabes lo que significa la cláusula “using” (es el equivalente de “import” de java)?

• La principal diferencia que se puede evidenciar a simple vista, es que un paquete agrupa elementos y contiene varias clases.
• Por otro lado una clase es aquella que forma parte de un único y exclusivo paquete.
• La cláusula using, permite interactuar entre diferentes paquetes. Un ejemplo más evidente es cuando utilizamos una clase desde otra clase, necesitamos importar esa clase que necesitamos.

1. Entiendes la diferencia entre paquete y librería (tanto estática como dinámica).

• El paquete se define como el espacio en el cual se organizan un conjunto de clases, interfaces.
• Una librería es un conjunto de implementaciones funcionales codificadas invocadas a través del using.

1. ¿Sabrías hacer el mismo ejemplo sin necesidad de separar la clase del programa principal? ¿Tendría sentido? ¿Puedes explicar alguna ventaja o inconveniente de hacer de una forma u otra?

• Si se la puede realizar, pero la funcionalidad cambiaria. La ventaja principal que se presentaría al separar la clase, es que se pueden reutilizar los métodos de esa clase.

1. Puedes explicar la diferencia de paso de parámetros por valor y por referencia.

• Los parámetros por valor son aquellos que utilizan su contenido de una dirección de memoria a otro.
• Los parámetros por referencia son los métodos u objetos llamados desde otro lugar que utilizan la misma dirección de memoria.

1. Cuando una clase se encuentra dentro de un namespace a uno o varios niveles, ¿Sabes cómo se nombra? ¿Entiendes la diferencia entre “Calculo.Calculadora” y “Calculadora”?

• Namespace declara un conjunto de objetos relacionados, que maneja un espacio de nombres para organizar elementos de código y crea tipos globales únicos.
• Calculo.Calculadora es aquel que ejecuta el código de Calculadora dentro de Cálculo.
• Calculadora por otro lado es la clase.

1. C# no dispone de un operador o instrucción para la destrucción o liberación de objetos (p.e. “delete” o “free”). ¿Entiendes las implicaciones de este concepto? Puedes decir cuando vive un objeto y cuando muere en el ejemplo anterior. ¿Qué es un recolector de memoria (“garbage collector”)?.

• En C# podemos verificar que no necesita una sentencia para liberar o destruir objetos como el delete o free. Esta acción se la realiza internamente cuando compila.
• En el ejemplo en la línea Console.WriteLine, es donde muere la ejecución.
• Se define a Garbage collector como un mecanismo de gestión de memoria que recopila variables y argumentos dentro de una matriz diferenciada por colores.

1. ¿Sabes la diferencia entre un miembro de clase y un miembro de instancia? ¿Cómo los distingues?

• La principal diferencia es que los miembros de clase incluyen a todos los miembros declarados.
• Los miembros de instancia ocupan una dirección de memoria mientras que los miembros de clase ocupan varias direcciones de memoria.

1. ¿Sabes la diferencia entre ámbito de una variable y vida de una instancia? ¿Es  lo mismo? ¿Tenemos que preocuparnos de ello?

• No es lo mismo. El ámbito de una variable es un espacio del programa donde se define la variable
• La vida de una instancia pasa por diferentes estados dentro de un ciclo de vida, desde el momento de su creación hasta que es eliminado o invalido.

1. ¿Dónde se almacenan la variable “calc” del programa principal? . ¿En la pila (stack)? ¿En el montón (heap)? ¿Y los argumentos de los métodos que tenemos en la calculadora?

• La variable calc se almacena en el heap porque es una variable de referencia.
• Los argumentos por otro lado son almacenados en la pila stack.

1. ¿Sabrías decir si alguna de las preguntas anteriores te parecen importantes para los sistemas distribuidos? ¿Cuáles? Intenta razonar tu respuesta.

• Se puede afirmar más claramente que los parámetros por valor son manejados de manera local y ocupa diferentes direcciones de memoria. Los parámetros por referencia en cambio ocupan una sola dirección de memoria y se utilizan en diferentes clases.
• Tambien permite diferenciar ciertos conceptos tales como paquete y librería.

1. En nuestro ejemplo, tenemos una librería llamada “Calculo.dll” y un ejecutable “practica1.exe”. ¿Entiendes la diferencia?

• La principal diferencia es que él .exe tiene un punto de entrada, y se puede ejecutar directamente.
• Una .dll tiene que ser llamada desde un .EXE para ejecutar lo que tiene dentro.

1. ¿Tiene sentido separar el código en dos assemblies (librería y ejecutable)? ¿Puedes explicar alguna ventaja o inconveniente de hacer de una forma u otra?

• Es conveniente separar el código porque al organizar en librerías y ejecutables permiten la reutilización y optimización de recursos disponibles.
• Lo más atractivo que ofrece la programación .NET es construir aplicaciones con diferentes lenguajes.

1. Cuando hemos separado el código de la calculadora para hacer una librería, ¿Ha sido necesario cambiar el nombre del namespace?

• Para la práctica realizada no es necesario. La razón es porque los namespaces se encuentran en diferentes proyectos.

1. ¿Hemos modificado la sentencia que hacía “using”? ¿Tiene sentido hacer esos cambios cuando construimos una librería?

• Si tiene mucho sentido ya que necesitamos incluir la librería “using calculo;” para separar el código en dos proyectos.

1. ¿Para qué sirve añadir una referencia al proyecto? ¿Ha sido necesario añadir otra referencia a la inversa? ¿Qué pasaría? ¿Tiene sentido?

• Si es necesario añadir una referencia al proyecto porque separado en clase cliente y servidor se puede localizar las clases necesarias y por eso es muy importante tener una referencia.

1. En un programa distribuido ¿es importante dividir la funcionalidad en varias librerías? ¿No complica la programación innecesariamente?

• Se pudo evidenciar que es importante dividir la funcionalidad porque en una aplicación distribuida, la parte del código, así como la interfaz solamente debe estar en el cliente. Todo lo que tiene que ver con la parte operativa estará únicamente en el servidor. Por esta razón es necesario separar código y crear librerías como objetivo de un programa distribuido.

PARTE B. MIDDLEWARE .NET REMOTING

1. Entiendes el concepto de Middleware como plataforma para desarrollar aplicaciones distribuidas. Entiendes que .Net Remoting es un middleware. Algunos autores consideran que un middleware debe facilitar otros servicios tales como movilidad, transaccionalidad, seguridad, etc. En ese sentido, .Net Remoting no se podría considerar un middleware como tal. ¿O sí?
2. Antes de seguir piensa que alternativas tenemos para desarrollar un ejemplo similar. ¿Cómo lo harías sin un middleware?. ¿Habrías utilizado más líneas de código? Tienes alternativas en RMI, Corba y otros. Si sabes algo de estos sistemas, intenta compararlos con .NetRemoting a lo largo de las prácticas y de nuestras preguntas.
3. ¿Puedes decir cómo se identifican los objetos “Calculadora” remotos? ¿sabes qué es una URL? ¿Se te ocurre alguna alternativa?. ¿Sabes lo qué es una UUID?. ¿Podrías decir alguna ventaja o inconveniente de los métodos propuestos?. La identificación de objetos o servicios remotos es importante. ¿Cómo lo hacen otros middleware?
4. El cliente apenas ha sufrido cambios, pero ahora ejecuta una calculadora remota. Puedes descubrir la forma que tiene el sistema de conectar dos conceptos diferentes: por un lado el objeto creado con “new Calculadora ()” y por otro el objeto remoto que se ejecuta en el servidor.
5. La calculadora parece que tiene ahora dos nombres: “Calculo.Calculadora” y “Calculadora.remota”. ¿Sabes distinguirlos? ¿Puedes explicar ambos nombres? ¿Es necesario tener dos nombres diferentes?. ¿Cómo los relaciona el sistema?
6. La librería “Calculo.dll” debe ser compartida entre el cliente y el servidor. Asegúrate. ¿Es necesario?. Este punto es importante y nos abre la puerta a nuevas prácticas.
7. Hemos utilizado una arquitectura cliente/servidor muy sencilla, pero ¿puedes explicar la diferencia entre arquitecturas P2P y cliente/servidor?. ¿Necesitamos un middleware diferente?
8. El de parámetros por valor y por referencia son conceptos habituales de la programación. ¿Sabrías decir cómo funciona C# y Java? ¿Son similares? ¿Ha cambiado algo al pasar al modelo distribuido? ¿Las pruebas que hemos realizado son suficientes?
9. ¿La representación de los datos en C# o Java viene dada por la máquina virtual? El comportamiento de C# es diferente al de Java. Intenta averiguar si tu sistema es big o little endian. ¿Cómo lo haces? ¿Entiendes la diferencia?
10. ¿Conoces la diferencia entre sobrecarga y sobreescritura? En C# (y Java) en el primer caso es el compilador quién resuelve la llamada. En el otro es el intérprete de la máquina virtual. ¿Conoces ese funcionamiento? ¿Sabrías explicar todas las implicaciones que tiene? ¿Sabes qué es la covariance?
11. C# dispone de otras características interesantes. Por ejemplo, tiene datos nulos (se expresan poniendo una interrogación al final del tipo, por ejemplo int?), tipos dinámicos (dynamic) o de tipado variable (var). ¿Sabrías explicar qué significan? ¿Podrían influir en el desarrollo de un middleware? ¿Qué sucede con .Net Remoting?
12. C# y Java tienen clases genéricas (templates en otros lenguajes). ¿Sería posible hacer un middleware que soporte esas características del lenguaje? Aún no hemos visto algunos conceptos relacionados, pero intenta razonar sobre qué dificultades podrían presentarse.
13. En C# existen otros conceptos interesantes tales como eventos y delegados (son referencias a métodos). ¿Los conoces? ¿Sabrías cómo usarlos? ¿Tienen impacto en el middleware? ¿Podrías razonar sobre ello?
14. Por último, C# (y en cierta forma Java) tienen herramientas para trabajar con concurrencia (threads, task, futures, async, await, etc.). En prácticas futuras trabajaremos estos conceptos, pero es interesante que nos preparemos y aprendamos algo de ellos. ¿Sabes lo que es una hebra? ¿Sabes qué es un lock (área sincronizada)? ¿Sabrías explicar la razón de que lock en C# tenga un parámetro (normalmente “this”)?

Remoting C. Modo de vida de un objeto remoto.

1. Cuando hemos puesto trazas en el constructor, no se observan en la pantalla del cliente. ¿Es eso posible?

• Cada llamada se ejecuta en una calculadora diferente y se observan diferentes ID en las trazas.

1. Lo más revelador de la práctica es que los objetos remotos tienen una vida diferente a los objetos locales. Pero la programación del cliente utiliza un objeto local de calculadora. ¿Sabrías decir que problemas pueden surgir?

• Si no se llama correctamente a ese objeto local, no sería ubicada con facilidad y a su vez tampoco permitiría realizar alguna acción.

1. En la práctica anterior, parece que el modo “SingleCall” es poco útil. Pero en realidad es bastante utilizado. ¿Sabrías decir dónde? ¿Se te ocurren ventajas e inconvenientes de este modo?

• Cada llamada de cliente es atendida por una nueva instancia de objeto. Este modelo no proporciona gestión estatal. Este modelo es adecuado para equilibrar la carga y aumentar la escalabilidad

1. Igualmente, piensa sobre el modo “Singleton”. Razona sobre sus ventajas e inconvenientes.

• Podemos decir que en este modo una sola instancia de objeto sirve para todas las peticiones de clientes.
• Los singletons garantizan que sólo una instancia de objeto está en la memoria en cualquier momento por dominio de la aplicación. Este único objeto se creará cuando se presente la primera petición para ese objeto.

1. Intenta encontrar algún ejemplo en el que utilizarías uno u otro modo. Razona tus respuestas.

• El código de remoting .NET seria expuesto como SingleCall.
• Cuando se corre a través de un componente de remoting .NET alojado en un servicio de Windows se expone como Singleton.

1. ¿Se te ocurren alternativas a los modos “SingleCall” y “Singleton”?

• Otra alternativa es client- activated que son objetos cuyas vidas son controladas por el cliente, es decir, el dominio de la aplicación llamante. Este modo funciona de manera similar al modelo donde el objeto es local al cliente y el tiempo de vida del objeto referenciado es controlado por el objeto llamante.

1. Al cambiar los parámetros de configuración, solo hemos tocado el fichero de configuración del servidor. El cliente no ha sido modificado.

1. ¿Sabe el cliente qué modo de vida tiene el objeto calculadora?

1. Normalmente, los programadores de las aplicaciones cliente y los programadores del servidor suelen ser diferentes. El modo de vida lo han elegido los programadores del servidor. ¿Cómo saben los clientes el modo de vida que tiene los objetos de un servidor? ¿Podrían controlar los clientes el modo de vida de un objeto remoto? ¿Tiene sentido tal necesidad?