PDF de programación - curso 2014 5

Introducción
Uno de los objetivos en el desarrollo de aplicaciones distribuidas es separar
claramente el código que el servidor ofrece y el que el cliente utiliza. Las razones son
múltiples y van desde razones de diseño típicas de orientación a objetos hasta razones
de mercado (no nos interesa que los clientes tengan nuestro código). Para resolver
este problema es necesario que el servidor publique un “contrato” que pueda utilizar
el cliente. Históricamente, este contrato se ha definido utilizando un lenguaje propio
llamado IDL (Lenguaje para la Descripción del Interfaz). Con este lenguaje, el
fabricante del servidor escribía el contrato que podía suministrar. El cliente utilizaba
este contrato para generar parte de su código.

Si observamos nuestras prácticas, la librería que tenía la Calculadora (Calculo.dll) era
común tanto al cliente como al servidor. Se compilaba y enlazaba en ambas
aplicaciones. Con lo que hemos visto hasta la fecha podríamos preguntarnos si es
posible separar al cliente del servidor y sobre todo si son necesarios o no dichos
“contratos” en .Net Remoting. Responder a estas preguntas es el objetivo de nuestra
práctica. A lo largo de ella vamos a explorar varios mecanismos para la separación del
código entre el cliente y el servidor.

Curso de Middleware. Práctica 5.

1 de 27

Breve Historia
Antes de meternos con las prácticas, me gustaría contaros una breve historia de la
ingeniería del software. Y es que la ingeniería del software ha influido mucho en los
paradigmas y diseño de los middleware.
Al principio de los tiempos (más o menos por los años 1960) se produce un primer
salto en la evolución. Uno de hecho muy importante: los programadores pasan de
utilizar el ensamblador a usar lenguajes de alto nivel que deben ser compilados.
Ejemplos representativos son COBOL o Fortran. Pronto se descubre que no todo es
tan maravilloso como parece y se detectan problemas. El código está poco o nada
estructurado, lo que convierte un programa en un monstruo difícil de mantener. Yo he
llegado a ver un único programa de unas 15 páginas en Fortran (con sus GOTO)!!.
No tarda en aparece una nueva generación. Por los años finales de los 60 o principios
de los 70 nacen ya lenguajes de programación que refuerzan los conceptos de
estructura (C o Pascal). De todas formas, la estructura es aún muy básica. La unidad
de estructura es la función o procedimiento. Se empieza a pensar seriamente sobre la
reutilización del código. En esta fecha tan temprana, lo único que podemos reutilizar
es la función. Los sistemas distribuidos generan tecnologías acordes con esta filosofía
y nace el RPC (llamada a procedimientos remotos). El principal problema que se
detecta es que la lógica del código está fuertemente unida a los datos. Es necesario
encapsular el código con sus datos.
Y nace la orientación a objetos. En este nuevo paso, los programadores consiguen una
nueva unidad de reutilización: la clase. Estamos sobre los años 1980 y aparecen
nuevos lenguajes: Smalltalk y más tarde C++. Con el concepto de clase, los
programadores pueden encapsular el código con sus datos, aislando los problemas. El
mundo se ve como una jerarquía de clases que, de una forma ideal, representa nuestro
mundo. Evidentemente, los sistemas distribuidos tienen que evolucionar y adaptarse a
estos nuevos conceptos. El middlware evoluciona hacia la orientación a objetos, las
primeras alternativas son CORBA y le siguen otras como .Net Remoting. En paralelo
(en algunos casos es previo) se exploran otras alternativas como los middlware
orientados al mensaje, con sistemas de colas tipo MQSeries.
Pero los problemas siguen estando. Sigue siendo difícil la reutilización de código y la
integración de sistemas. El concepto de clase viene acompañado de los conceptos de
herencia y jerarquía. Y estos conceptos son problemáticos para los sistemas
distribuidos. No siempre se puede distribuir el código sin hacer visibles todos los
niveles de la jerarquía y clases más básicas. Además, es complicado hacer que un
programa escrito en Ada pueda ser utilizado por un programador de C++. Pero es que
otros muchos de los problemas de distribución de código siguen sin solucionar, por
ejemplo el versionado.
Era necesario evolucionar hacia nuevos conceptos. Esta evolución ha sido menos
abrupta que las anteriores y desemboca en el concepto de programación orientada al
componente (Component-Oriented Programming). Los primeros intentos se producen
sobre los años 1990. La idea es que los programadores acuerdan un cierto contrato que
debe ser neutro al lenguaje y a la arquitectura interna del sistema. Se hacen relevantes
los conceptos como IDL e interface. La unidad de reutilización es el interface. El
programador puede hacer y distribuir tantas implementaciones como desee (incluso en

Curso de Middleware. Práctica 5.

2 de 27

diferentes lenguajes de programación), siempre y cuando respete el contrato
(interface). Cuando un cliente llama a un componente, se utiliza un protocolo neutro
al lenguaje. Es decir, llamamos a los miembros del componente utilizando un
protocolo determinado, incluso si en ambos lados de la llamada utilizamos el mismo
lenguaje de programación. Ejemplos de estos sistemas son COM, DCOM, JavaBeans,
etc.
Espero que a estas alturas del curso, sepamos identificar muchos de estos conceptos
en las prácticas que ya habéis realizado. Si tienes alguna dificultad, no dudes en
comentarlo con vuestro profesor.
Pero la historia no se queda aquí. Tras el esfuerzo que genera la idea de componente,
los sistemas siguen teniendo problemas de reutilización de código. Y es que los
ingenieros del software se encuentran una y otra vez con el mismo problema. Para
reutilizar debemos separar (desacoplar) el código, pero la unión del código es lo que
nos permite integrar aplicaciones y por lo tanto generar valor. Es un “no puedo vivir
contigo pero tampoco sin ti”.
Y de esta forma, el sistema evoluciona hacia las aplicaciones orientadas a servicios.
De nuevo se hace un esfuerzo para reducir las dependencias y aislar las unidades de
reutilización. Es el momento en el que el middleware toma una nueva variante: los
servicios web; pero eso lo dejamos para otro ejercicio.
El futuro está aún por escribir, pero hay una tendencia clara en la que el middleware
desaparece y es el propio lenguaje el que ofrece la capacidad de distribuir la
aplicación. Por ahora tenemos lenguajes paralelos ya establecidos. El propio C# ya
incorpora alguna de esas características pero hay muchos más. Si tenéis tiempo mirad
las propuestas de lenguajes cómo X10. El siguiente paso en toda esta evolución
posiblemente sea que el lenguaje se haga responsable de toda la funcionalidad que
suministra actualmente el middleware. Ya hay algunos experimentos en este sentido.
Por ejemplo, usando Scala y Spark podemos procesar datos de forma distribuida
(usando el modelo map/reduce). Existe una fuerte investigación en lenguajes
funcionales distribuidos (por ejemplo Haskell distributido).
Pero volvamos a nuestra práctica. El objetivo de toda esta historia era ilustrar que los
sistemas distribuidos actuales suelen estar desacoplados. Y para ello es importante
identificar y aislar el código que queremos distribuir y reutilizar. Hasta la fecha hemos
compartido el código de nuestra calculadora tanto en el cliente como en el servidor.
No parece nada positivo, visto todo lo anterior, no?. Intentemos poner algún
remedio...

Curso de Middleware. Práctica 5.

3 de 27

maquina:numero de puerto/tu servicio?wsdl



Utilización de Interface
Uno de los problemas que estabamos describiendo es que necesitamos de un
mecanismo que nos permita describir lo que hace una clase sin necesidad de dar el
código de la misma. Antes de ver el concepto de interface, os propongo hacer una
pequeña prueba. Arranca el servidor de nuestra primera práctica con la calculadora
distribuida. Asegúrate que está arrancada sobre un canal http (en el fichero de
configuración aparece el protocolo). Ahora, con un navegador intenta abrir la URL
añadiendo al final “?wsdl” :
http://tu

por ejemplo:
http://localhost:1234/Calculadora.remota?wsdl
Observa que cuando utilizamos “?wsdl” como parámetro de la url, se obtiene una
descripción en XML de los objetos remotos que están siendo atendidos en esa url.
Intenta analizar lo que ves. Cambia algo en tu calculadora y observa como la página
refleja ese cambio. Este ejercicio lo volveremos a ver cuando estudiemos SOAP
(Simple Object Access Protocol ). De hecho lo que sale por nuestro navegador es la
descripción en WSDL (Web Services Description Language), un estándar del W3C.
Esa descripción se corresponde con el contrato de nuestra calculadora. Es una forma
de describir los servicios que ofrece nuestro objeto remoto. En este caso, estamos
viendo WSDL que es una forma neutral basada en XML de describir el
funcionamiento de una clase. Pero no es el único. Otra alternativa es el IDL
(“Lenguaje de Definición de Interfaces”) muy utilizado en Corba y en algunos
sistemas basados en Rmi. Un ejemplo de IDL sería:

module HelloApp
{
interface Hello
{
string sayHello();
oneway void shutdown();
};
};

Una tercera alternativa es utilizar el propio lenguaje de programación. Muchos
lenguajes tienen un mecanismo llamado “interface” que nos permite describir dicho
contrato.
Se dice que la clase que realmente desarrolla el código “implementa” el interface. Os
proponemos como ejercicio diseñar un interface que se corresp