Download pdf - Ice Spanish

c David Vallejo Fern ndez. Se permite la copia, distribuci n y/o modicaci n de este documento a o o bajo los t rminos de la licencia de documentaci n libre GNU, versi n 2 o cualquier versi n posterior e o o o publicada por la Free Software Foundation, sin secciones invariantes. Puede consultar esta licencia en http://www.gnu.org.A Este documento fue compuesto con LTEX. Im genes generadas con OpenOfce. a

Indice general1. Introducci n o 1.1. Introducci n general a los middlewares o 1.1.1. Conceptos . . . . . . . . . . . . 1.1.2. Fundamentos b sicos . . . . . . a 1.2. Caractersticas generales de ICE . . . . 1.3. Organizaci n de este documento . . . . o 1 1 1 2 3 4

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

I

Un vistazo a ICE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56 6 6 19 19 19 21 22 22 23 23 24 24 24 24 26 26 26 27 30 32 33

2. Toma de contacto con ICE 2.1. La arquitectura de ICE . . . . . . . . . . . . . . . 2.1.1. Terminologa . . . . . . . . . . . . . . . . 2.1.2. Slice (Lenguaje de especicaci n para ICE) o 2.1.3. Mappings de lenguajes . . . . . . . . . . . 2.1.4. Estructura cliente-servidor . . . . . . . . . 2.1.5. El protocolo ICE . . . . . . . . . . . . . . 2.1.6. Persistencia de objetos . . . . . . . . . . . 2.2. Servicios ofrecidos por ICE . . . . . . . . . . . . . 2.2.1. IceGrid . . . . . . . . . . . . . . . . . . . 2.2.2. IceBox . . . . . . . . . . . . . . . . . . . 2.2.3. IceStorm . . . . . . . . . . . . . . . . . . 2.2.4. IcePatch2 . . . . . . . . . . . . . . . . . . 2.2.5. Glacier2 . . . . . . . . . . . . . . . . . . . 2.3. Benecios arquitect nicos de ICE . . . . . . . . . o

3. Un ejemplo sencillo de aplicaci n con ICE o 3.1. Hola mundo! con ICE . . . . . . . . . . . . . . . . . . . . 3.1.1. Escribiendo la denici n en Slice . . . . . . . . . . o 3.1.2. Escribiendo la aplicaci n en Python . . . . . . . . . o 3.1.3. Escribiendo la aplicaci n en C++ . . . . . . . . . . o 3.1.4. Escribiendo la aplicaci n en Java . . . . . . . . . . o 3.1.5. Escribiendo la parte cliente de la aplicaci n en Ruby o

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3

INDICE GENERAL

4

II

Slice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3536 36 37 37 38 39 40 40 41 42 46 46

4. El lenguaje Slice 4.1. Introducci n . . . . . . . . . . . . . . . . . . o 4.2. Aspectos b sicos . . . . . . . . . . . . . . . a 4.2.1. Compilaci n . . . . . . . . . . . . . o 4.2.2. Ficheros fuente . . . . . . . . . . . . 4.2.3. Reglas l xicas . . . . . . . . . . . . . e 4.2.4. M dulos . . . . . . . . . . . . . . . o 4.2.5. Tipos b sicos en Slice . . . . . . . . a 4.2.6. Tipos denidos por el usuario . . . . 4.2.7. Interfaces, operaciones, y excepciones 4.3. Aspectos avanzados . . . . . . . . . . . . . . 4.3.1. Clases . . . . . . . . . . . . . . . . .

III

ICE avanzado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4748 48 48 49 49 50 50 51 52 53 54 54 54 56 57 58 59 59 60 61 63 63 64

5. Propiedades de ICE y conguraci n o 5.1. Introducci n . . . . . . . . . . . o 5.2. Propiedades . . . . . . . . . . . 5.3. Archivos de conguraci n . . . o 5.4. La propiedad Ice.Cong . . . .

6. Programaci n asncrona o 6.1. Introducci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 6.1.1. Invocaci n de m todos asncrona o AMI (Asynchronous Method Ino e vocation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2. Tratamiento de m todos asncrono o AMD (Asynchronous Method e Dispatch) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3. Controlando la generaci n de c digo utilizando metadatos . . . . . . o o 6.1.4. Transparencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. AMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1. Simulando AMI utilizando invocaciones oneway . . . . . . . . . . . 6.2.2. Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4. Cuestiones asociadas a la concurrencia . . . . . . . . . . . . . . . . 6.2.5. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. AMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1. Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Transferencia eciente de cheros 7.1. Introducci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 7.2. Versi n inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o

7.3. 7.4. 7.5. 7.6. 7.7. 7.8.

Usando AMI . . . . . . . . . . . . . . . . . . . . . Incrementando la eciencia con dos llamadas AMI . Uso de la caracterstica zero-copy del mapping a C++ Utilizando AMD en el servidor . . . . . . . . . . . . A n m s eciente . . . . . . . . . . . . . . . . . . . u a Conclusiones . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

66 69 71 72 73 76

IV

Servicios en ICE

7778 78 80 86 86 87 87 88 89 92 92 95 95 99

8. IceGrid 8.1. Introducci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 8.2. Ejemplo de aplicaci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 9. Freeze 9.1. Introducci n . . . . . . . . . . o 9.2. Freeze map . . . . . . . . . . 9.2.1. Ejemplo de aplicaci n o 9.3. Freeze evictor . . . . . . . . . 9.3.1. Ejemplo de aplicaci n o 10. Glacier2 10.1. Introducci n . . . . . . . . o 10.2. Ejemplos de aplicaciones . 10.2.1. Ejemplo b sico . . a 10.2.2. Ejemplo avanzado

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

11. IceBox 101 11.1. Introducci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 o 11.2. Ejemplo de aplicaci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 o 12. IceStorm 104 12.1. Introducci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 o 12.2. Ejemplo de aplicaci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 o 13. IcePatch2 110 13.1. Introducci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 o 13.2. Ejemplo de aplicaci n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 o Bibliografa 113

Captulo 1 Introducci n o1.1. Introducci n general a los middlewares o 1.1.1. Conceptos 1.1.2. Fundamentos b sicos a 1.2. Caractersticas generales de ICE 1.3. Organizaci n de este documento o

1.1.1.1.1.

Introducci n general a los middlewares oConceptos

Se puede entender un middleware como un software de conectividad que hace posible que aplicaciones distribuidas pueden ejecutarse sobre distintas plataformas heterog neas, es decir, e sobre plataformas con distintos sistemas operativos, que usan distintos protocolos de red y, que incluso, involucran distintos lenguajes de programaci n en la aplicaci n distribuida. o o Desde otro punto de vista distinto, un middleware se puede entender como una abstracci n en la complejidad y en la heterogeneidad que las redes de comunicaciones imponen. o De hecho, uno de los objetivos de un middleware es ofrecer un acuerdo en las interfaces y en los mecanismos de interoperabilidad, como contrapartida de los distintos desacuerdos en hardware, sistemas operativos, protocolos de red, y lenguajes de programaci n. o

1

1.1. Introducci n general a los middlewares o

2

Aplicacin

Aplicacin

APIs Middleware Serviciosdesistemas distribuidosInterfaz plataforma Interfaz plataforma

Plataforma Sistema operativo

Plataforma Sistema operativo

Figura 1.1: Esquema general de un middleware

1.1.2.

Fundamentos b sicos a

La mayora de los middlewares tratan de acercar el modelo de programaci n a un punto o de vista local, es decir, enmascarando la llamada a los procedimientos remotos. Por otra parte, el enfoque m s extendido es el de la generaci n de un proxy en la parte del cliente y a o de un esqueleto en la parte del servidor. Para ello, el cliente utiliza un objeto proxy con la misma interfaz denida en la parte del servidor, y que act a como intermediario. El servidor, u por otro lado, utiliza un esqueleto encargado de traducir los eventos de la red a invocaciones sobre el objeto en cuesti n. Como se puede apreciar, existe un gran acercamiento de la versi n o o distribuida a la versi n centralizada. o Las principales responsabilidades de un proxy son las siguientes: Codicar la invocaci n y los argumentos en un mensaje. o Esperar la respuesta y decodicar el valor o los valores de retorno. Por otra parte, las principales responsabilidades de un esqueleto son las siguientes: Esperar una invocaci n y decodicar el mensaje y los argumentos. o

1.2. Caractersticas generales de ICE Invocar el m todo real. e Codicar el valor o los valores de retorno en un mensaje de respuesta.

3

Una cuesti n importante a tener en cuenta es la codicaci n de los datos en la red. Por o o ejemplo, es posible tener distintas representaciones de un mismo tipo de datos dependiendo del computador empleado. Para solucionar este problema, se suele denir una representaci n o externa can nica, y transformar a y desde un formato binario a partir de la representaci n o o externa. Este proceso es conocido como proceso de marshalling y unmarshalling. Por otra parte, el middleware tambi n ha de gestionar problemas inherentes a las comue nicaciones, como por ejemplo la identicaci n de mensajes, la gesti n de retransmisiones, la o o gesti n de conexiones, y la identicaci n de objetos. Por todo ello, la soluci n m s extendida o o o a se basa en un n cleo de comunicaciones gen rico y de un generador autom tico de proxies y u e a esqueletos.

1.2.

Caractersticas generales de ICE

ICE (Internet Communication Engine) [4] es un middleware orientado a objetos, es decir, ICE proporciona herramientas, APIs, y soporte de bibliotecas para construir aplicaciones cliente-servidor orientadas a objetos. Una aplicaci n ICE se puede usar en entornos o heterog neos: los clientes y los servidores pueden escribirse en diferentes lenguajes de proe gramaci n, pueden ejecutarse en distintos sistemas operativos y en distintas arquitecturas, o y pueden comunicarse empleando diferentes tecnologas de red. Adem s, el c digo fuente a o de estas aplicaciones puede portarse de manera independiente al entorno de desarrollo. Los principales objetivos de diseno de ICE son los siguientes: Proporcionar un middleware listo para usarse en sistemas heterog neos. e Proveer un conjunto completo de caractersticas que soporten el desarrollo de aplica ciones distribuidas reales en un amplio rango de dominios. Evitar una complejidad innecesaria, haciendo que ICE sea f cil de aprender y de usar. a

1.3. Organizaci n de este documento o

4

Proporcionar una implementaci n eciente en ancho de banda, en uso de memoria, y o en carga de CPU. Proporcionar una implementaci n basada en la seguridad, de forma que se pueda usar o sobre redes no seguras. Se puede decir que la losofa de ICE se basa en construir una plataforma tan potente como CORBA, pero sin cometer todos los fallos de esta y evitando una complejidad innecesaria.

1.3.

Organizaci n de este documento o

Este documento est estructurado en cuatro partes: a Parte I, Un vistazo a ICE, realiza una toma de contacto con el middleware ZeroC ICE y expone un ejemplo sencillo de aplicaci n en ICE. o Parte II, Slice, alude al lenguaje de denici n de interfaces de ZeroC ICE, comentando o los aspectos b sicos por un lado y algunos de los aspectos m s avanzados por otro. a a Parte III, ICE avanzado, expone ciertos aspectos avanzados de ZeroC ICE. Parte IV, Servicios en ICE, realiza un estudio de los servicios propuestos por el middleware ZeroC ICE desde una perspectiva eminentemente pr ctica. a

Parte I Un vistazo a ICE

5

Captulo 2 Toma de contacto con ICE2.1. La arquitectura de ICE 2.1.1. Terminologa 2.1.2. Slice (Lenguaje de especicaci n para ICE) o 2.1.3. Mappings de lenguajes 2.1.4. Estructura cliente-servidor 2.1.5. El protocolo ICE 2.1.6. Persistencia de objetos 2.2. Servicios ofrecidos por ICE 2.2.1. IceGrid 2.2.2. IceBox 2.2.3. IceStorm 2.2.4. IcePatch2 2.2.5. Glacier2 2.3. Benecios arquitect nicos de ICE o

2.1.2.1.1.

La arquitectura de ICETerminologa

ICE introduce una serie de conceptos t cnicos que componen su propio vocabulario, como e ocurre con cualquier nueva tecnologa. Sin embargo, el objetivo perseguido fue reutilizar la

6

2.1. La arquitectura de ICE

7

mayor parte de terminologa existente en sistemas de este tipo, de forma que la cantidad de t rminos introducidos fuera mnima. De hecho, si el lector ha trabajado con tecnologas e relacionadas como CORBA, la terminologa aqu descrita le ser muy familiar. a 2.1.1.1. Clientes y servidores

Los t rminos cliente y servidor no est n directamente asociados a dos partes distintas de e a una aplicaci n, sino que m s bien hacen referencia a los roles que las diferentes partes de una o a aplicaci n pueden asumir durante una petici n: o o Los clientes son entidades activas, es decir, emiten solicitudes de servicio a un servidor. Los servidores son entidades pasivas, es decir, proporcionan un servicio en respuesta a las solicitudes de los clientes. Normalmente, los clientes no son clientes puros en el sentido de que s lo solicitan peticioo nes. En su lugar, los clientes suelen ser entidades hbridas que asumen tanto el rol de cliente como el de servidor. De hecho, los sistemas cliente-servidor suelen describirse de una forma m s eciente como sistemas peer-to-peer. a 2.1.1.2. Objetos ICE

Un objeto ICE es una entidad conceptual o una abstracci n que mantiene una serie de o caractersticas: Un objeto ICE es una entidad en el espacio de direcciones remoto o local que es capaz de responder a las peticiones de los clientes. Un unico objeto ICE puede instanciarse en un unico servidor o, de manera redundante, en m ltiples servidores. Si un objeto tienes varias instancias simult neamente, todava u a sigue siendo un unico objeto ICE. Cada objeto ICE tiene una o m s interfaces. Una interfaz es una colecci n de operaa o ciones soportadas por un objeto. Los clientes emiten sus peticiones invocando dichas operaciones.


8

Una operaci n tiene cero o m s par metros y un valor de retorno. Los par metros y o a a a los valores de retorno tienen un tipo especco. Adem s, los par metros tienen una a a determinada direcci n: los par metros de entrada se inicializan en la parte del cliente y o a se pasan al servidor, y los par metros de salida se inicializan en el servidor y se pasan a a la parte del servidor. (El valor de retorno es simplemente un par metro de salida a especial). Un objeto ICE tiene una interfaz distinguida del resto y conocida como la interfaz principal. Adem s, un objeto ICE puede proporcionar cero o m s interfaces alternativas, a a conocidas como facetas o facets. De esta forma, un cliente puede seleccionar entre las distintas facetas de un objeto para elegir la interfaz con la que quiere trabajar. Cada objeto ICE tiene una identidad de objeto unica. La identidad de un objeto es un valor identicativo que distingue a un objeto del resto de objetos. El modelo de objetos denido por ICE asume que las identidades de los objetos son unicas de forma global, es decir, dos objetos no pueden tener la misma identidad dentro de un dominio de comunicaci n en ICE. o 2.1.1.3. Proxies Para que un cliente sea capaz de comunicarse con un objeto ICE ha de tener acceso a un proxy para el objeto ICE. Un proxy es un componente local al espacio de direcciones del cliente, y representa al (posiblemente remoto) objeto ICE para el cliente. Adem s, act a como a u el embajador local de un objeto ICE, de forma que cuando un cliente invoca una operaci n o en el proxy, el n cleo de ejecuci n de ICE: u o 1. Localiza al objeto ICE. 2. Activa el servidor del objeto ICE si no est en ejecuci n. a o 3. Activa el objeto ICE dentro del servidor. 4. Transmite los par metros de entrada al objeto ICE. a 5. Espera a que la operaci n se complete. o


9

6. Devuelve los par metros de salida y el valor de retorno al cliente (o una excepci n en a o caso de error). Un proxy encapsula toda la informaci n necesaria para que tenga lugar todo este proceso. o En particular, un proxy contiene informaci n asociada a diversas cuestiones: o Informaci n de direccionamiento que permite al n cleo de ejecuci n de la parte del o u o cliente contactar con el servidor correcto. Informaci n asociada a la identidad del objeto que identica qu objeto particular es el o e destino de la petici n en el servidor. o Informaci n sobre el identicador de faceta opcional que determina a qu faceta del o e objeto en concreto se reere el proxy. 2.1.1.4. Proxies textuales (stringed proxies)

La informaci n asociada a un proxy se puede representar como una cadena. Por ejemplo, o la cadena SimplePrinter:default -p 10000 es una representaci n legible de un proxy. El n cleo de ejecuci n de ICE proporciona o u o llamadas a su API para convertir proxies en cadenas y viceversa. Sin embargo, este tipo de representaci n se utiliza para aplicaciones b sicas y con prop sitos did cticos, ya que su o a o a tratamiento requiere de operaciones adicionales que se pueden evitar utilizando otro tipo de representaciones expuestas a continuaci n. o 2.1.1.5. Proxies directos (direct proxies)

Un proxy directo es un proxy que encapsula una identidad de objeto junto con la direcci n asociada a su servidor. Dicha direcci n est completamente especicada por los siguieno o a tes componentes: Un identicador de protocolo (como TCP/IP o UDP).


10

Una direcci n especca de un protocolo (como el nombre y el puerto de una m quina). o a Con el objetivo de contactar con el objeto asociado a un proxy directo, el n cleo de ejeu cuci n de ICE utiliza la informaci n de direccionamiento vinculada al proxy para contactar o o con el servidor, de forma que la identidad del objeto se enva al servidor con cada petici n o realizada por el cliente. 2.1.1.6. Proxies indirectos (indirect proxies)

Un proxy indirecto tiene dos formas. Puede proporcionar s lo la identidad de un objeto, o o puede especicar una identidad junto con un identicador de adaptador de objetos. Un objeto que es accesible utilizando s lo su identidad se denomina objeto bien conocido. Por ejemplo, o la cadena SimplePrinter es un proxy v lido para un objeto bien conocido con la identidad a SimplePrinter. Un proxy indirecto que incluye un identicador de adaptador de objetos tiene la forma textual SimplePrinter@PrinterAdapter. Cualquier objeto del adaptador de objetos puede ser accedido utilizando dicho proxy sin importar si ese objeto tambi n es un objeto e bien conocido. Se puede apreciar que un proxy indirecto no contiene informaci n de direccionamiento. o Para determinar el servidor correcto, el n cleo de ejecuci n de la parte del cliente pasa la u o informaci n del proxy a un servicio de localizaci n. Posteriormente, el servicio de localizao o ci n utiliza la identidad del objeto o el identicador del adaptador de objetos como clave en o una tabla de b squeda que contiene la direcci n del servidor y que devuelve la direcci n del u o o servidor actual al cliente. El n cleo de ejecuci n de la parte del cliente es capaz ahora de u o contactar con el servidor y de enviar la solicitud del cliente de la manera habitual. El proceso completo es similar a la traducci n de los nombres de dominio en Internet a direcciones IP, o es decir, similar al DNS. 2.1.1.7. Binding directo y binding indirecto El proceso de convertir la informaci n de un proxy en una pareja protocolo-direcci n se o o conoce como binding. De forma intuitiva, la resoluci n directa se usa para los proxies directos o y la resoluci n indirecta para los proxies indirectos. o


11

La principal ventaja de la resoluci n indirecta es que permita movilidad de servidores o (es decir, cambiar su direcci n) sin tener que invalidar los proxies existentes asociados a o los clientes. De hecho, los proxies indirectos siguen trabajando aunque haya migraci n del o servidor a otro lugar. 2.1.1.8. Proxies jos (xed proxies)

Un proxy jo es un proxy que est asociado a una conexi n en particular: en lugar de a o contener informaci n de direccionamiento o de un nombre de adaptador, el proxy contiene o un manejador de conexi n. Dicho manejador de conexi n permanece en un estado v lido o o a siempre que la conexi n permanezca abierta. Si la conexi n se cierra, el proxy no funciona o o (y no volver a funcionar m s). Los proxies jos no pueden pasarse como par metros a la a a a hora de invocar operaciones, y son utilizados para permitir comunicaciones bidireccionales, de forma que un servidor puede efectuar retrollamadas a un cliente sin tener que abrir una nueva conexi n. o 2.1.1.9. Replicaci n o

En ICE, la replicaci n implica hacer disponibles en m ltiples direcciones a los adaptadoo u res de objetos (y a sus objetos). El principal objetivo de la replicaci n es el de proporcionar o redundancia ejecutando el mismo servidor en distintas m quinas. Si en una de ellas se produce a un error, el servidor permanece disponible en el resto. Utilizar la replicaci n tambi n implica que las aplicaciones est n dise adas teniendo en o e e n cuenta dicho concepto. En particular, signica que un cliente pueda acceder a un objeto a trav s de una direcci n y que obtenga el mismo resultado si hubiera accedido a trav s de otra. e o e ICE soporta una forma limitada de replicaci n cuando un proxy especica m ltiples dio u recciones para un objeto. El n cleo de ejecuci n de ICE selecciona una de esas direcciones de u o manera aleatoria para su intento de conexi n inicial, e intenta contactar con el resto en caso o de fallo. Por ejemplo, considere este proxy: SimplePrinter:tcp -h server1 -p 10001:tcp -h server 2 -p 10002


12

El proxy indica que el objeto identicado por SimplePrinter est disponible utilizando dos a direcciones TCP, una en la m quina server1 y otra en la m quina server2. Se supone que los a a administradores del sistema garantizan que el servidor est en ejecuci n tanto en la m quina a o a server1 como en la m quina server2. a 2.1.1.10. Grupos de r plica e

Adem s de la replicaci n basada en proxies comentada en la secci n anterior, ICE soporta a o o una forma m s util de replicaci n conocida como grupos de r plica que requiren el uso de un a o e servicio de localizaci n. o Un grupo de r plica tiene un identicador unico y consiste en un n mero determinado de e u adaptadores de objetos. Un adaptador de objetos puede ser miembro de al menos un grupo de r plica. Dicho adaptador se considera como un adaptador de objetos replicado. e Despu s de haber establecido un grupo de r plica, su identicador puede utilizarse como e e un proxy indirecto en lugar de un identicador de adaptador. Por ejemplo, un grupo de r plica e identicado por PrinterAdapters puede utilizarse como un proxy de la siguiente forma: SimplePrinter@PrinterAdapters Un grupo de r plica es tratado por el servicio de localizaci n como un adaptador de objee o tos virtual. El comportamiento del servicio de localizaci n cuando resuelve un proxy indirecto o que contiene el identicador de un grupo de r plica es un aspecto relacionado con la implee mentaci n. Por ejemplo, el servicio de localizaci n podra tomar la decisi n de devolver las o o o direcciones de todos los adaptadores de objetos del grupo, en cuyo caso el n cleo de ejecuu ci n de la parte del cliente podra seleccionar una de esas direcciones de manera aleatoria o utilizando la forma limitada de replicaci n comentada en la anterior secci n. Otra posibilio o dad para el servicio de localizaci n sera la de devolver una unica direcci n seleccionada en o o funci n de una determinada heurstica. o Sin tener en cuenta c mo el servicio de localizaci n resuelve un grupo de r plica, el o o e principal benecio es la indirecci n: el servicio de localizaci n puede a adir m s inteligencia o o n a al proceso de resoluci n actuando como intermediario. o

2.1. La arquitectura de ICE 2.1.1.11. Sirvientes (Servants)

13

Como se coment anteriormente, un objeto ICE es una entidad conceptual que tiene un o tipo, una identidad, e informaci n de direccionamiento. Sin embargo, las peticiones de los o clientes deben terminar en una entidad de procesamiento en el lado del servidor que proporcione el comportamiento para la invocaci n de una operaci n. En otras palabras, una petici n o o o de un cliente ha de terminar en la ejecuci n de un determinado c digo en el servidor, el cual o o estar escrito en un determinado lenguaje de programaci n y ejecutado en un determinado a o procesador. El componente en la parte del servidor que proporciona el comportamiento asociado a la invocaci n de operaciones se denomina sirviente. Un sirviente encarna a uno o m s objetos o a ICE. En la pr ctica, un sirviente es simplemente una instancia de una clase escrita por un el a desarrollador de la aplicaci n y que est registrada en el n cleo de ejecuci n de la parte del o a u o servidor como el sirviente para uno o m s objetos ICE. Los m todos de esa clase se correspona e deran con las operaciones de la interfaz del objeto ICE y proporcionaran el comportamiento para dichas operaciones. Un unico sirviente puede encarnar a un unico objeto ICE en un determinado momento o a varios objetos ICE de manera simult nea. En el primer caso, la identidad del objeto ICE a encarnado por el sirviente est implcita en el sirviente. En el segundo caso, el sirviente mana tiene la identidad del objeto ICE con cada solicitud, de forma que pueda decidir qu objeto e encarnar mientras dure dicha solicitud. En cambio, un unico objeto ICE puede tener m ltiples sirvientes. Por ejemplo, podramos u tomar la decisi n de crear un proxy para un objeto ICE con dos direcciones distintas para o distintas m quinas. En ese caso, tendramos dos servidores, en los que cada servidor cona tendra un sirviente para el mismo objeto ICE. Cuando un cliente invoca una operaci n en o dicho objeto, el n cleo de ejecuci n de la parte del cliente enva la petici n a un servidor. u o o En otras palabras, tener varios sirvientes para un unico objeto ICE permite la construcci n de o sistemas redundantes: el n cleo de ejecuci n de la parte del cliente trata de enviar la petici n u o o a un servidor y, si dicho servidor falla, enva la petici n al segundo servidor. S lo en el caso o o de que el segundo servidor falle, el error se enva para que sea tratado por el c digo de la o

2.1. La arquitectura de ICE aplicaci n de la parte del cliente. o 2.1.1.12. Sem ntica at-most-once a

14

Las solicitudes ICE tienen una sem ntica at-most-once: el n cleo de ejecuci n de ICE a u o hace todo lo posible para entregar una solicitud al destino correcto y, dependiendo de las circunstancias, puede volver a intentar una solicitud en caso de fallo. ICE garantiza que entregar la solicitud o, en caso de que no pueda hacerlo, informar al cliente con una determinada a a excepci n. Bajo ninguna circunstancia una solicitud se entregar dos veces, es decir, los reino a tentos se llevar n a cabo s lo si se conoce con certeza que un intento previo fall . a o o Esta sem ntica es importante porque asegura que las operaciones que no son idempotena tes puedan usarse con seguridad. Una operaci n es idempotente es una operaci n que, si se o o ejecuta dos veces, provoca el mismo efecto que si se ejecut una vez. Por ejemplo, x = 1; es o una operaci n idempotente, mientras que x++; no es una operaci n idempotente. o o Sin este tipo de sem nticas se pueden construir sistemas distribuidos robustos ante la prea sencia de fallos en la red. Sin embargo, los sistemas reales requieren operaciones no idempotentes, por lo que la sem ntica at-most-once es una necesidad, incluso aunque implique tener a un sistema menos robusto ante la presencia de fallos. ICE permite marcar a una determinada operaci n como idempotente. Para tales operaciones, el n cleo de ejecuci n de ICE utiliza un o u o mecanismo de recuperaci n de error m s agresivo que para las operaciones no idempotentes. o a 2.1.1.13. Invocaci n de m todos sncrona o e

Por defecto, el modelo de envo de peticiones utilizado por ICE est basado en la llama a da sncrona a procedimientos remotos: una invocaci n de operaci n se comporta como una o o llamada local a un procedimiento, es decir, el hilo del cliente se suspende mientras dure la llamada y se vuelve activar cuando la llamada se ha completado (y todos los resultados est n a disponibles).

2.1. La arquitectura de ICE 2.1.1.14. Invocaci n de m todos asncrona o e

15

ICE tambi n proporciona invocaci n de m todos asncrona (asynchronous method invoe o e cation) o AMI: un cliente puede invocar operaciones de manera asncrona, es decir, el cliente utiliza un proxy de la manera habitual para invocar una operaci n pero, adem s de pasar los o a par metros necesarios, tambi n pasa un objeto de retrollamada (callback object) y retorna a e de la invocaci n inmediatamente. Una vez que la operaci n se ha completado, el n cleo de o o u ejecuci n de la parte del cliente invoca a un m todo en el objeto de retrollamada pasado inio e cialmente, proporcionando los resultados de la operaci n a dicho objeto (o en caso de error, o proporcionando la informaci n sobre la excepci n asociada). o o El servidor no es capaz de diferenciar una invocaci n asncrona de una sncrona. De heo cho, en ambos casos el servidor simplemente aprecia que un cliente ha invocado una operaci n en un objeto. o 2.1.1.15. Tratamiento de m todos asncrono e

El tratamiento de m todos asncrono (asynchronous method dispatch) o AMD es el equie valente a AMI en el lado del servidor. En el tratamiento sncrono por defecto el n cleo de u ejecuci n de la parte del servidor y mientras la operaci n se est ejecutando (o durmiendo o o a debido a que espera para obtener un dato), el hilo de ejecuci n asociado al servidor s lo se o o libera cuando la operaci n se ha completado. o Con AMD se informa de la llegada de la invocaci n de una operaci n al c digo de la o o o aplicaci n de la parte del servidor. Sin embargo, en lugar de forzar al proceso a atender la o petici n inmediatamente, la aplicaci n de la parte del servidor puede retrasar el procesamiento o o de dicha petici n y liberar el hilo de ejecuci n asociado a la misma. El c digo de aplicaci n o o o o de la parte del servidor es ahora libre de hacer lo que quiera. Eventualmente, una vez que los resultados de la aplicaci n est n disponibles, el c digo de aplicaci n de la parte del servidor o a o o realiza una llamada al API para informar al n cleo de ejecuci n de la parte del servidor de u o que la petici n que se realiz con anterioridad ha sido completada. En este momento, los o o resultados de la ooperaci n invocada se envan al cliente. o AMD es util, por ejemplo, si un servidor ofrece operaciones que bloquean a los clientes


16

por un periodo largo de tiempo. Por ejemplo, el servidor puede tener un objeto con una operaci n get que devuelva los datos de una fuente de datos externa y asncrona, lo cual bloqueara o al cliente hasta que los datos estuvieran disponibles. Con el tratamiento sncrono, cada cliente que esperara unos determinados datos estara vinculado a un hilo de ejecuci n del servidor. Claramente, este enfoque no es escalable con o una docena de clientes. Con AMD, centenas o incluso miles de clientes podran bloquearse en la misma invocaci n sin estar vinculados a los hilos del servidor. o El tratamiento sncrono y asncrono de m todos son transparentes al cliente, es decir, el e cliente es incapaz de saber si un determinado servidor realiza un tratamiento sncrono o, por el contrario, un tratamiento asncrono. 2.1.1.16. Invocaci n de m todos en una direcci n (Oneway Method Invocation) o e o

Los clientes pueden invocar una operaci n como una operaci n en una direcci n (oneway). o o o Dicha invocaci n mantiene una sem ntica best-effort. Para este tipo de invocaciones, el n cleo o a u de ejecuci n de la parte del cliente entrega la invocaci n al transporte local, y la invocaci n se o o o completa en la parte del cliente tan pronto como el transporte local almacene la invocaci n. o La invocaci n actual se enva de forma transparente por el sistema operativo. El servidor no o responde a invocaciones de este tipo, es decir, el ujo de tr co es s lo del cliente al servidor, a o pero no al rev s. e Este tipo de invocaciones no son reales. Por ejemplo, el objeto destino puede no existir, por lo que la invocaci n simplemente se perdera. De forma similar, la operaci n podra ser o o tratada por un sirviente en el servidor, pero dicha operaci n podra fallar (por ejemplo, porque o los valores de los par metros no fuesen correctos). En este caso, el cliente no recibira ning n a u tipo de noticaci n al respecto. o Las invocaciones oneway son s lo posibles en operaciones que no tienen ning n tipo de o u valor de retorno, no tienen par metros de salidad, y no arrojan ning n tipo de excepci n de a u o usuario. En lo que se reere al c digo de aplicaci n de la parte del servidor estas invocaciones son o o transparentes, es decir, no existe ninguna forma de distinguir una invocaci n twoway de una o oneway.


17

Las invocaciones oneway est n disponibles s lo si el objeto destino ofrece un transporte a o orientado a ujo, como TCP/IP o SSL. 2.1.1.17. Invocaci n de m todos en una direcci n y por lotes (batched oneway method o e o invocation) Cada invocaci n oneway enva un mensaje al servidor. En una serie de mensajes cortos, la o sobrecarga es considerable: los n cleos de ejecuci n del cliente y del servidor deben cambiar u o entre el modo usuario y el modo n cleo para cada mensaje y, a nivel de red, se incrementa la u sobrecarga debido a la auencia de paquetes de control y de conrmaci n. o Las invocaciones batched oneway permiten enviar una serie de invocaciones oneway en un unico mensaje: cada vez que se invoca una operaci n batched oneway, dicha invocaci n o o se almacena en un buffer en la parte del cliente. Una vez que se han acumulado todas las invocaciones a enviar, se lleva a cabo una llamada al API para enviar todas las invocaciones a la vez. A continuaci n, el n cleo de ejecuci n de la parte del cliente enva todas las invocao u o ciones almacenadas en un unico mensaje, y el servidor recibe todas esas invocaciones en un unico mensaje. Este enfoque evita los inconvenientes descritos anteriormente. Las invocaciones individuales en este tipo de mensajes se procesan por un unico hilo en el orden en el que fueron colocadas en el buffer. De este modo se garantiza que las operaciones individuales sean procesadas en orden en el servidor. Las invocaciones batched oneway son particularmente utiles para servicios de mensajes como IceStorm, y para las interfaces de grano no que ofrecen operaciones set para atributos peque os. n 2.1.1.18. Datagram invocations Este tipo de invocaciones mantienen una sem ntica best-effort similar a las invocaciones a oneway. Sin embargo, requieren que el mecanismo de transporte empleado sea UDP. Estas invocaciones tienen las mismas caractersticas que las invocaciones oneway, pero abarcan un mayor n mero de escenarios de error: u Las invocaciones pueden perderse en la red debido a la naturaleza del protocolo UDP.


18

Las invocaciones pueden llegar fuera de orden debido a la naturaleza del protocolo UPD. Este tipo de invocaciones cobr n m s sentido en el ambito de las redes locales, en las a a que la posibilidad de p rdida es peque a, y en situaciones en las que la baja latencia es m s e n a importante que la abilidad, como por ejemplo en aplicaciones interactivas en Internet. 2.1.1.19. Batched datagram invocations Este tipo de invocaciones son an logas a las batched oneway invocations, pero en el ambia to del protocolo UDP. 2.1.1.20. Excepciones en tiempo de ejecuci n o

Cualquier invocaci n a una operaci n puede lanzar una excepci n en tiempo de ejecuci n. o o o o Las excepciones en tiempo de ejecuci n est n predenidas por el n cleo de ejecuci n de ICE o a u o y cubren condiciones de error comunes, como fallos de conexi n, timeouts, o fallo en la o asignaci n de recursos. Dichas excepciones se presentan a la aplicaci n como excepciones o o propias a C++, Java, o C#, por ejemplo, y se integran en la forma de tratar las excepciones de estos lenguajes de programaci n. o 2.1.1.21. Excepciones denidas por el usuario

Las excepciones denidas por el usuario se utilizan para indicar condiciones de error especcas a la aplicaci n a los clientes. Dichas excepciones pueden llevar asociadas una o determinada cantidad de datos complejos y pueden integrarse en jerarquas de herencia, lo cual permite que la aplicaci n cliente maneje diversas categoras de errores generales. o 2.1.1.22. Propiedades

La mayor parte del n cleo de ejecuci n de ICE se puede congurar a trav s de las propieu o e dades. Estos elementos son parejas clave-valor , como por ejemplo Ice.Default.Protocol=tcp. Dichas propiedades est n normalmente almacenadas en cheros de texto y son trasladadas al a


19

n cleo de ejecuci n de ICE para congurar diversas opciones, como el tama o del pool de u o n hilos, el nivel de traceado, y muchos otros par metros de conguraci n. a o

2.1.2.

Slice (Lenguaje de especicaci n para ICE) o

Como se mencion anteriormente, cada objeto ICE tiene una interfaz con un determinado o n mero de operaciones. Las interfaces, las operaciones, y los tipos de datos intercambiados u entre el cliente y el servidor se denen utilizando el lenguaje Slice. Slice permite denir el contrato entre el cliente y el servidor de forma independiente del lenguaje de programaci n o empleado. Las deniciones Slice se compilan por un compilador a una API para un lenguaje de programaci n especco, es decir, la parte de la API que es especca a las interfaces y los o tipos que previamente han sido denidos y que consisten en c digo generado. o

2.1.3.

Mappings de lenguajes

Las reglas que rigen c mo se traslada cada construcci n Slice en un lenguaje de prograo o maci n especco se conocen como mappings de lenguajes. Por ejemplo, para el mapping a o C++, una secuencia en Slice aparece como un vector STL, mientras que para el mapping a Java, una secuencia en Slice aparece como un array. Con el objetivo de determinar qu aspecto e tiene la API generada para un determinado lenguaje, s lo se necesita conocer la especicaci n o o en Slice y las reglas de mapping hacia dicho lenguaje. Actualmente, ICE proporciona mappings para los lenguajes C++, Java, C#, Visual Basic .NET, Python, y, para el lado del cliente, PHP y Ruby.

2.1.4.

Estructura cliente-servidor

Los clientes y los servidores ICE tienen la estructura l gica interna mostrada en la gura o 2.1. Tanto el cliente como el servidor se pueden entender como una mezcla de c digo de o aplicaci n, c digo de bibliotecas, y c digo generado a partir de las deniciones Slice: o o o El n cleo de ICE contiene el soporte de ejecuci n para las comunicaciones remotas u o


20

Aplicacincliente

Aplicacinservidora

Cdigo proxy

APIIce

APIIce

Esqueleto

Adaptador objetos

NcleoclienteIce Red

NcleoservidorIce

Figura 2.1: Estructura cliente-servidor

en el lado del cliente y en el del servidor. De cara al desarrollador, dicho n cleo se u corresponde con un determinado n mero de bibliotecas con las que la aplicaci n puede u o enlazar. La parte gen rica del n cleo de ICE, a la cual se accede a trav s del API de ICE. e u e El desarrollador utiliza esta API para la gesti n de tareas administrativas, como por o ejemplo la inicializaci n y nalizaci n del n cleo de ejecuci n de ICE. o o u o El c digo de los proxies se genera a partir de las deniciones en Slice y, por lo tanto, es o especco a los tipos de objetos y de datos denidos en Slice. Dicho c digo tiene dos o funciones principales: proporciona una interfaz para el cliente y proporciona c digo de o marshaling y unmarshaling. Marshaling es el proceso de serializar una estructura de datos compleja, como una secuencia o un diccionario, para la transmisi n por la red. o Este c digo convierte los datos en una forma est ndar para la transmisi n de forma o a o independiente de la arquitectura de las m quinas involucradas (como por ejemplo biga endian) y de las reglas de relleno. Unmarshaling es el proceso contrario.


21

El c digo del esqueleto tambi n se genera a partir de la denici n en Slice y, por lo o e o tanto, es especco a los tipos de objetos y datos denidos en Slice. Dicho c digo es el o equivalente al generado para el proxy pero en la parte del servidor. El adaptador de objetos es una parte de la API de ICE especco al lado del servidor: s lo los servidores utilizan los adaptadores de objetos. Un adaptador de objetos tiene o varios funciones, como traducir las peticiones de los clientes a los m todos espece cos al lenguaje de programaci n empleado, asociarse a uno o m s puntos nales de o a transporte, o crear los proxies que pueden pasarse a los clientes.

2.1.5.

El protocolo ICE

ICE proporciona un protocolo RPC que puede utilizar tanto TCP/IP como UPD como capa de transporte subyacente. Adem s, ICE permite utilizar SSL, de forma que todas las a comunicaciones entre el cliente y el servidor est n encriptadas. e El protocolo ICE dene: Un determinado n mero de tipos de mensajes, como por ejemplo de solicitud y resu puesta. Una m quina de estados que determina qu secuencia siguen los distintos tipos de mena e sajes que se intercambian el cliente y el servidor, junto con el establecimiento de conexi n asociado. o Reglas de codicicaci n que determinan c mo se representa cada tipo de datos en la o o red. Una cabecera para cada tipo de mensaje que contiene detalles como el tipo del mensaje, el tama o del mensaje, y el protocolo y la versi n de codiciaci n empleados. n o o ICE tambi n soporta compresi n en la red: ajustando un par metro de conguraci n se e o a o pueden comprimir todos los datos asociados al tr co de red cara reducir el ancho de banda a utilizado. Esta propiedad resulta util si la aplicaci n intercambia grandes cantidades de datos o entre el cliente y el servidor.

2.2. Servicios ofrecidos por ICE

22

El protocolo ICE tambi n soporta operaciones bidireccionales: si un servidor quiere enviar e un mensaje a un objeto de retrollamada proporcionado por el cliente, la retrollamada puede efectuarse a partir de la conexi n establecida inicialmente por el cliente. Esta caracterstio ca es especialmente importante cuando el cliente est detr s de un cortafuegos que permite a a conexiones de salida pero no de entrada.

2.1.6.

Persistencia de objetos

ICE dispone de un servicio de persistencia que se denomina Freeze. Freeze facilita el almacenamiento del estado de un objeto en una base de datos, de forma que el desarrollador dene en Slice el estado almacenado para los objetos y el compilador Freeze genera c digo o que permite almacenar y recuperar el estado de los objetos en y desde una base de datos, respectivamente. Por defecto, ICE utiliza Berkeley DB y su base de datos asociada. ICE tambi n proporciona herramientas que facilitan el mantenimiento de bases de datos e y la migraci n del contenido de las bases de datos existentes a un nuevo esquema si las o deniciones de los objetos cambian.

2.2.

Servicios ofrecidos por ICE

El n cleo de ICE proporciona una sosticada plataforma cliente-servidor para el desarrou llo de aplicaciones distribuidas. Sin embargo, las aplicaciones reales necesitan normalmente algo m s que las capacidades remotas, como por ejemplo la activaci n de servidores bajo a o demanda, la distribuci n de proxies a los clientes, la distribuci n de eventos asncronos, la o o conguraci n de aplicaciones, etc. o ICE maneja una serie de servicios que gestionan estas caractersticas y otras. Dichos ser vicios se implementan como servidores ICE de forma que la aplicaci n desarrollada act e o u como un cliente. Ninguno de estos servicios utilizan caractersticas internas a ICE ocultas a la aplicaci n en cuesti n, por lo que en teora es posible desarrollar servicios equivalentes o o por parte del desarrollador. Sin embargo, manteniendo estos servicios disponibles como parte de la plataforma permite al desarrollador centrarse en el desarrollo de la aplicaci n en lugar o de construir la infraestructura necesaria en primer lugar. Adem s, la construcci n de dichos a o

2.2. Servicios ofrecidos por ICE

23

servicios no es un esfuerzo trivial, por lo que es aconsejable conocer y usar los servicios disponibles en lugar de reinventar la rueda en cada aplicaci n. o

2.2.1.

IceGrid

IceGrid es la implementaci n de un servicio de localizaci n ICE que transforma la ino o formaci n simb lica en un proxy indirecto asociado a una pareja protocolo-direcci n en lo o o o que se reere a resoluci n indirecta. Adem s de ser un servicio de localizaci n, IceGrid tiene o a o muchas otras caractersticas: IceGrid permite el registro de servidores para un arranque autom tico, es decir, habilita a la activaci n de servidores bajo demanda (servidores que se activan cuando el cliente o emite una solicitud). IceGrid proporciona herramientas que facilitan la conguraci n de aplicaciones como plejas que contienen ciertos servidores. IceGrid soporta la replicaci n y el balanceado de carga. o IceGrid automatiza la distribuci n de los ejecutables asociados a los servidores y de sus o archivos vinculados. IceGrid proporciona un servicio que permite a los clientes obtener proxies para los objetos en los que est n interesados. a

2.2.2.

IceBox

IceBox es un unico servidor de aplicaciones que permite gestionar el arranque y la parada de un determinado n mero de componentes de aplicaci n. Dichos componentes se pueden u o desplegar como una biblioteca din mica en lugar de un proceso. Esto hecho reduce la sobrea carga global del sistema, por ejemplo, permitiendo ejecutar varios componentes en una unica m quina virtual Java en lugar de tener m ltiples procesos, cada uno con su propia m quina a u a virtual.

2.3. Benecios arquitect nicos de ICE o

24

2.2.3.

IceStorm

IceStorm es un servicio de publicaci n-subscripci n que act a como un distribuidor de o o u eventos entre servidores y clientes. Los publicadores envan eventos al servicio IceBox, el cual los notica a los subscriptores. De esta forma, un unico evento publicado por el publicador se puede enviar a m ltiples subscriptores. Los eventos est n categorizados en funci n de un u a o tema, y los subscriptores especican los temas en los que est n interesados. IceBox permite a seleccionar entre distintos criterios de calidad de servicio para que las aplicaciones puedan obtener una relaci n abilidad-rendimiento apropiada. o

2.2.4.

IcePatch2

IcePatch2 es un servicio que permite la f cil distribuci n de actualizaciones de software a o a los clientes. Estos simplemente han de conectarse al servidor IcePatch2 y solicitar actualizaciones para una determinada aplicaci n. El servicio chequea autom ticamente la versi n o a o de los clientes y enva cualquier actualizaci n disponible en un formato comprimido para o gestionar ecientemente el ancho de banda. Estas actualizaciones pueden ser seguras utilizando el servicio Glacier2, de forma que s lo los clientes autorizados puedan descargarse o actualizaciones.

2.2.5.

Glacier2

Glacier2 es el servicio de cortafuegos de ICE, el cual permite que tanto los clientes como los servidores se comuniquen de forma segura a trav s de un cortafuegos sin comprometer la e seguridad. El tr co entre el cliente y el servidor queda completamente encriptado utilizando a certicados de clave p blica y es bidireccional. Glacier2 tambi n proporciona soporte para la u e autenticaci n mutua y para la gesti n segura de sesiones. o o

2.3.

Benecios arquitect nicos de ICE o

La arquitectura propuesta por ICE proporciona un serie de benecios a los desarrolladores de aplicaciones:

2.3. Benecios arquitect nicos de ICE o Mantiene una sem ntica orientada a objetos. a Proporciona un manejo sncrono y asncrono de mensajes. Soporta m ltiples interfaces. u Es independiente de la m quina. a Es independiente del lenguaje de programaci n. o

25

Es independiente de la implementaci n, es decir, el cliente no necesita conocer c mo o o el servidor implementa sus objetos. Es independiente del sistema operativo. Soporta el manejo de hilos. Es independiente del protocolo de transporte empleado. Mantiene transparencia en lo que a localizaci n y servicios se reere (IceGrid). o Es seguro (SSL y Glacier2). Permite hacer persistentes las aplicaciones (Freeze). Tiene disponible el c digo fuente. o

Captulo 3 Un ejemplo sencillo de aplicaci n con ICE o3.1. Hola mundo! con ICE 3.1.1. Escribiendo la denici n en Slice o 3.1.2. Escribiendo la aplicaci n en Python o 3.1.3. Escribiendo la aplicaci n en C++ o 3.1.4. Escribiendo la aplicaci n en Java o 3.1.5. Escribiendo la parte cliente de la aplicaci n en Ruby o

3.1.

Hola mundo! con ICE

En esta secci n se estudiar como crear una sencilla aplicaci n cliente-servidor utilizando o a o los lenguajes Python, C++, Java, y Ruby para la parte cliente. Dicha aplicaci n en cuesti n o o ser una versi n remota del cl sico Hola mundo!. El objetivo de esta secci n es establecer a o a o una primera toma de contacto en lo que a desarrollo con ICE se reere.

3.1.1.

Escribiendo la denici n en Slice o

El primer paso en lo que al desarrollo de aplicaciones ICE se reere consiste en la denici n de un chero que especique las interfaces utilizadas por la aplicaci n. Para el sencillo o o ejemplo que se presenta a continuaci n, dicha denici n sera la siguiente: o o module Demo {

26

3.1. Hola mundo! con ICE

27

interface HolaMundo { void saludar (); }; };

La denici n en Slice consiste en un m dulo Demo, el cual contiene una unica interfaz o o denominada HolaMundo. Dicha interfaz es muy simple y s lo proporciona una operaci n: o o saludar. Esta operaci n no acepta par metros de entrada y no devuelve ning n valor. o a u

3.1.2.

Escribiendo la aplicaci n en Python o

Esta secci n muestra c mo crear la aplicaci n Hola Mundo! en Python. o o o 3.1.2.1. Escribiendo el servidor

El servidor, cuyo c digo se explicar a continuaci n es el siguiente: o a oimport sys, traceback, Ice Ice.loadSlice(../slice/holaMundo.ice, [-I /usr/share/slice]) import Demo class HolaMundoI (Demo.HolaMundo): def saludar (self, current = None): print Hola Mundo! class Server (Ice.Application): def run (self, argv): self.shutdownOnInterrupt() adapter = self.communicator().createObjectAdapterWithEndpoints( HolaMundoAdapter, default -p 10000) adapter.add(HolaMundoI(), Ice.stringToIdentity(HolaMundo)) adapter.activate() self.communicator().waitForShutdown() return 0 Server().main(sys.argv)

Como se puede apreciar, el c digo es muy sencillo gracias a la potencia que nos ofreo ce Python. De hecho, s lo necesitaremos utilizar las mnimas instrucciones de cara a poner o nuestra aplicaci n en funcionamiento. o La primera parte del programa est vinculada a la importanci n de m dulos y a la carga a o o del archivo en el que previamente denimos nuestras especicaciones en Slice. Es importante resaltar que es necesario incluir el m dulo Ice en todas nuestras aplicaciones ICE. As mismo, o


28

merece la pena hablar sobre la operaci n loadSlice, la cual nos permite generar el c digo asoo o ciado al archivo denido en Slice de forma din mica, es decir, permitiendo que los archivos a Slice se carguen en tiempo de ejecuci n y se traduzcan din micamente en c digo Python, el o a o cual es inmediatamente compilado y queda disponible para la aplicaci n del usuario. En el o caso especco del cliente, la interfaz HolaMundo se traduce en una clase que representa el esqueleto asociado a dicha interfaz. Como se ver posteriormente, su h mologo en la parte a o del cliente est representado por el proxy. a A continuaci n se dene la clase HolaMundoI, la cual es una especializaci n de la clase o o Demo.HolaMundo, que a su vez representa al esqueleto generado por ICE a partir de la interfaz HolaMundo. Ahora simplemente se han de implementar las operaciones denidas en dicha interfaz. En este caso, se propone una implementaci n de la operaci n saludar, la cual o o imprime por pantalla un mensaje. El siguiente paso consiste en escribir el c digo asociado a la aplicaci n servidora en cueso o ti n. Para ello, y como se observa en el c digo expuesto, se dene la clase Server. Esta clase o o contiene todo el c digo asociado a la instanciaci n de los recursos necesarios para obtener o o la parte servidora de la aplicaci n. En primer lugar, se observa c mo la clase Server hereda o o de la clase Ice.Application, proporcionada por ICE para encapsular todo el c digo asociado o a las actividades de inicializaci n y nalizaci n. El idea de esta clase es que el desarrollador o o cree una especializaci n de la misma y que implemente el m todo abstracto run en la clase o e derivada. El aspecto que se obtiene al utilizar esta clase es el siguiente:class Server (Ice.Application): def run (self, argv): self.shutdownOnInterrupt() .... # Server code. .... self.communicator().waitForShutdown() return 0 Server().main(sys.argv)

Utilizar la clase Ice.Application hace m s sencilla la creaci n de aplicaciones ICE. a o Finalmente, quedan por ejecutar tres instrucciones para completar la parte servidora: 1. Crear un adaptador de objetos: para ello se utiliza la operaci n createObjectAdapterWito hEndpoints, especicando el nombre del adaptador de objetos (HolaMundoAdapter) y


29

la direcci n en la que escuchar dicho adaptador de objetos (default -p 10000). En este o a caso, dicha direcci n utiliza el protocolo TCP/IP por defecto y el puerto 10000. o 2. Informar al adaptador de objetos de la existencia de un nuevo sirviente: para ello se utiliza la operaci n add, especicando la instancia especca del sirviente (HolaMundoI()) o y el identicador asociado a dicha instancia (Ice.stringToIdentity(HolaMundo)). En este caso, la cadena HolaMundo es el nombre del sirviente. 3. Activar el adaptador de objetos: para ello se utiliza la operaci n activate. o Ya s lo se necesita instanciar la clase Server y el servidor quedar a la escucha para o a atender las peticiones de los clientes. Llegados a este punto, es importante resaltar que el c digo comentado anteriormente es o esencialmente el mismo para todos los servidores. As mismo, se puede comprobar que Pyt hon minimiza la cantidad de c digo necesaria para el desarrollo de aplicaciones ICE, lo cual o lo hace especialmente util para temas de prototipado. 3.1.2.2. Escribiendo el cliente

La parte asociada al cliente, la cual es m s sencilla a n si cabe que la del servidor y que a u se explicar a continuaci n, se expone a continuaci n: a o oimport sys, traceback, Ice Ice.loadSlice(../slice/holaMundo.ice, [-I /usr/share/slice]) import Demo class Client (Ice.Application): def run (self, argv): self.shutdownOnInterrupt() basePrx = self.communicator().stringToProxy( HolaMundo:default -p 10000) holaMundoPrx = Demo.HolaMundoPrx.checkedCast(basePrx) holaMundoPrx.saludar() self.communicator().waitForShutdown() return 0 Client().main(sys.argv)

El c digo del cliente es id ntico al del servidor a excepci n del c digo asociado al m todo o e o o e run. En este caso, la aplicaci n s lo ha de crear un proxy al objeto registrado en la parte del o o


30

servidor y ejecutar la operaci n saludar en dicho proxy, ya que este act a como embajador o u de dicho objeto. Para ello se han de llevar a cabo los siguientes pasos: 1. Obtener un proxy al objeto remoto: para ello se utiliza la operaci n stringToProxy, o pas ndole como par metro la cadena HolaMundo:default -p 10000, la cual contiene a a la identidad del objeto y el puerto usado por el servidor. 2. Realizar una conversi n del proxy obtenido en el paso anterior (el cual es del tipo o Ice::ObjectPrx) a un proxy del tipo Demo::HolaMundoPrx: para ello se utiliza la operaci n Demo.HolaMundoPrx.checkedCast, la cual enva un mensaje al servidor para o comprobar que realmente est asociado a la interfaz Demo::HolaMundo. En ese caa so, la llamada devuelve un proxy del tipo Demo.HolaMundoPrx. En caso contrario, la llamada devuelve None.

3.1.3.

Escribiendo la aplicaci n en C++ o

El sencillo ejemplo Hola Mundo! es pr cticamente id ntico a su hom logo en Python, a e o pero con la salvedad del cambio de sintaxis asociado. 3.1.3.1. Escribiendo el servidor

El servidor, cuyo c digo se explicar a continuaci n es el siguiente: o a o#include #include using namespace std; using namespace Demo; class HolaMundoI : public HolaMundo { public: virtual void saludar (const Ice::Current&); }; void HolaMundoI:: saludar (const Ice::Current&) { cout add(object, communicator()->stringToIdentity("HolaMundo")); adapter->activate(); communicator()->waitForShutdown(); return 0; } }; int main (int argc, char *argv[]) { Server server; return server.main(argc, argv); }

Como se puede apreciar, la funcionalidad del c digo mostrado es la misma que para el o lenguaje Python. En primer lugar, se incluyen los archivos de cabecera necesarios para hacer funcionar la aplicaci n servidora. Estos son el archivo Ice/Application.h, para hacer uso de la funcionao lidad denida en la clase Application, y el archivo HolaMundo.h, el cual se genera a partir de compilar el archivo HolaMundo.ice para el lenguaje C++. Posteriormente, se importan los contenidos de los espacios de nombrado std y Demo. A continuaci n, se implementa la clase HolaMundoI, la cual deriva de la clase HolaMuno do y, que a su vez, fue generada a partir de las deniciones Slice del archivo HolaMundo.ice. El resto del c digo es similar que para el ejemplo en Python: o 1. Se crea el adaptador de objetos. 2. Se informa al adaptador de objetos de la existencia del sirviente. 3. Se activa el adaptador de objetos. 3.1.3.2. Escribiendo el cliente

La parte cliente es an loga a la denido con el lenguaje Python y se expone a continuaa ci n: o


32

#include #include using namespace std; using namespace Demo; class Client : virtual public Ice::Application { virtual int run (int, char*[]) { Ice::ObjectPrx base = communicator()-> stringToProxy("HolaMundo:default -p 10000"); HolaMundoPrx holaMundoPrx = HolaMundoPrx::checkedCast(base); holaMundoPrx->saludar(); communicator()->waitForShutdown(); return 0; } }; int main (int argc, char *argv[]) { Client client; return client.main(argc, argv); }

3.1.4.

Escribiendo la aplicaci n en Java o

El primer paso para crear la aplicaci n en Java consiste en compilar la deni n Slice o o para generar los proxies y esqueletos asociados. Para ello, se pueden ejecutar los siguientes comandos:mkdir generated slice2java --output-dir generated HolaMundo.ice

El siguiente paso es implementar la interfaz denida para el ejemplo b sico: apublic class HolaMundoI extends Demo._HolaMundoDisp { public void printString (String s, Ice.Current current) { System.out.println("Hola Mundo!"); } }

3.1.4.1.

Escribiendo el servidor

A continuaci n se presenta el c digo del servidor: o opublic class Server extends Ice.Application { public int run (String[] args) { Ice.ObjectAdapter adapter = communicator(). createObjectAdapterWithEndpoints("HolaMundoAdapter", "default -p 10000");


33

Ice.Object object = new HolaMundoI(); adapter.add(object, Ice.Util.stringToIdentity("HolaMundo")); adapter.activate(); communicator().waitForShutdown(); return 0; } }

3.1.4.2.

Escribiendo el cliente

A continuaci n se presenta el c digo del cliente: o opublic class Client extends Ice.Application { public int run (String[] args) { Ice.Objectprx base = communicator().stringToProxy( "HolaMundo:default -p 10000"); Demo.HolaMundoPrx prx = Demo.HolaMundoPrxHelper. checkedCast(base); if (prx == null) a throw new Error("Proxy no vlido"); prx.saludar(); communicator().waitForShutdown(); return 0; } }

Como se puede apreciar, tanto el cliente como el servidor son id nticos a los especicados e en otros lenguajes.

3.1.5.

Escribiendo la parte cliente de la aplicaci n en Ruby o

La parte cliente de la aplicaci n escrita en Ruby es pr cticamente id ntica a la denida en o a e Python:require Ice Ice::loadSlice(../slice/HolaMundo.ice) class Client < Ice::Application def run (args) comm = Ice::Application::communicator() basePrx = comm.stringToProxy( HolaMundo:default -p 10000) holaMundoPrx = HolaMundoPrx.checkedCast(basePrx) holaMundoPrx.saludar() return 0 end end


34

app = Client.new() exit(app.main(ARGV))

Parte II Slice

35

Captulo 4 El lenguaje Slice4.1. Introducci n o 4.2. Aspectos b sicos a 4.2.1. Compilaci n o 4.2.2. Ficheros fuente 4.2.3. Reglas l xicas e 4.2.4. M dulos o 4.2.5. Tipos b sicos en Slice a 4.2.6. Tipos denidos por el usuario 4.2.7. Interfaces, operaciones, y excepciones 4.3. Aspectos avanzados 4.3.1. Clases

4.1.

Introducci n o

Slice (Specication Language for Ice) es el mecanismo de abstracci n fundamental para o separar las interfaces de los objetos de su implementaci n. Slice establece un contrato entre o el cliente y el servidor que describe los tipos y las interfaces de los objetos utilizados por la aplicaci n. Esta descripci n es independiente del lenguaje de implementaci n, por lo que no o o o importa que el cliente est implementado utilizando el mismo lenguaje que en el servidor. e Las deniciones en Slice se compilan para un determinado lenguaje de implementaci n o a trav s de un compilador. Dicho compilador se encarga de traducir las deniciones indee 36

4.2. Aspectos b sicos a

37

pendiente del lenguaje en deniciones de tipos especcas del lenguaje y en APIs. Son estos tipos y estas deniciones los que ser n utilizados por el desarrollador de cara a proporcionar a la funcionalidad de la aplicaci n y a interactuar con ICE. Los algoritmos de traducci n para o o los distintos lenguajes de implementaci n se conocen como mappings de lenguajes. Actualo mente, ICE dene mappings para C++, Java, C#, Visual Basic .NET, Python, PHP, y Ruby (estos dos ultimos en lo que a la parte del cliente se reere).

4.2.4.2.1.

a Aspectos b sicosCompilaci n o

El compilador de Slice produce archivos fuente que han de ser combinados con el c digo o de la aplicaci n para generar los ejecutables asociados al cliente y al servidor. o En la gura 4.1 se muestra la situaci n en la que tanto el cliente como el servidor est n o a implementados utilizando C++. El compilador Slice genera dos archivos a partir de una denici n Slice en un archivo fuente Printer.ice: un chero de cabecera (Printer.h) y un chero o fuente (Printer.cpp). El chero de cabecera Printer.h contiene deniciones que se corresponden a los tipos utilizados en la denici n Slice. Este archivo se incluye tanto en el c digo del cliente o o como en el del servidor para asegurar que ambos est n de acuerdo con los tipos y las a interfaces utilizadas por la aplicaci n. o El chero fuente Printer.cpp proporciona un API al cliente para enviar los mensajes a los objetos remotos. El c digo fuente del cliente (Client.cpp) contiene la l gica de o o la aplicaci n del lado del cliente. El c digo fuente generado y el c digo del cliente se o o o compilan y se enlazan para obtener el ejecutable asociado al cliente. Por otra parte, el chero fuente asociado al servidor (Server.cpp) contiene la l gica de la o aplicaci n de la parte del servidor (la implementaci n de los objetos, es decir, los sirvientes). o o El proceso de compilaci n y enlazado es hom logo al de la parte del cliente. o o


38

Figura 4.1: Proceso de desarrollo si el cliente y el servidor comparten el mismo lenguaje de programaci n o

El proceso asociado a la utilizaci n de distintos lenguajes de programaci n en el lado del o o cliente y en el del servidor es pr cticamente id ntico al comentado anteriormente. En la gura a e 4.2 se muestra un ejemplo.

4.2.2.

Ficheros fuente

Los archivos que contiene deniciones Slice han de terminar con la extensi n .ice, como o por ejemplo Printer.ice. Slice es un lenguaje libre de forma, es decir, se pueden utilizar espacios, tabulaciones verticales y horizontales, o retornos de carro para formatear el c digo de la manera deseada. o Por otra parte, Slice es preprocesado por el preprocesador C++, de forma que se pueden utilizar las directivas de preprocesado comunes, como por ejemplo #include. Sin embargo, estas sentencias han de indicarse al principio del archivo, justo antes de cualquier denici n o Slice.


39

Figura 4.2: Proceso de desarrollo si el cliente y el servidor no comparten el mismo lenguaje de programaci n o

4.2.3.

Reglas l xicas e

Las reglas l xicas de Slice son muy parecidas a las de los lenguajes C++ y Java, a excepe ci n de algunas diferencias en lo que a identicadores se reere. o Los comentarios permitidos por Slice son de los tipos utilizados en C y en C++:/* * Comentario estilo C. */ // Comentario estilo C++.

Los identicadores han de comenzar por un car cter alfab tico seguido de cualquier sea e cuencia de caracteres alfanum ricos. Los identicadores Slice est n restringidos al rango de e a caracteres alfab ticos ASCII. Por otra parte, Slice no permite el uso de guiones de subrayado e en los identicadores. Adem s, no son sensibles a may sculas. Para profundizar m s sobre a u a las reglas l xicas de Slice ver [4]. e


40

4.2.4.

M dulos o

Un problema com n en grandes sistemas son los conictos de nombres conforme estos u crecen. Slice proporciona el constructor module para solventar este problema:module Demo { module Client { // Definiciones aqu... }; module Server { // Definiciones aqu... }; };

Un m dulo pueden contener cualquier construcci n denida en Slice, incluso otros m duo o o los. Adem s, Slice necesita que cualquier denici n est incluida dentro de un m dulo, es a o e o decir, no se pueden tener deniciones globales. Los m dulos pueden abrirse y cerrarse en cualquier lugar, lo cual resulta muy util en o proyectos grandes, de forma que se puede estructurar el contenido de un m dulo en varios o archivos fuente. Adem s, cuando se produce un cambio en uno de estos cheros, s lo se a o necesita recompilar el chero que ha cambiado.

4.2.5.

Tipos b sicos en Slice a

Slice proporciona los siguientes tipos de datos b sicos: a bool byte short int long oat double

4.2. Aspectos b sicos a string Para una informaci n m s detallada sobre los mismos consultar [4]. o a

41

4.2.6.

Tipos denidos por el usuario

Adem s de los tipos b sicos comentados previamente, Slice proporciona los siguientes a a tipos de datos denidos por el usuario: Enumeraciones. Estructuras. Secuencias. Diccionarios. Una enumeraci n en Slice es parecida a la denida en C++: oenum Fruta{Pera, Manzana, Naranja};

Una estructura en Slice contiene uno o m s miembros de un determinado tipo, incluyendo a tipos complejos denidos por el usuario:struct Hora { short hora; short minute; short second; };

Una secuencia es un vector de elementos de longitud variable:sequence BandejaDeFruta;

Un diccionario es un conjunto de parejas clave-valor:struct Empleado { long numero; string primerApellido; string segundoApellido; }; dictionary Empleados;


42

Aunque los diccionarios se podran implementar como una secuencia de estructuras, re sulta m s adecuado utilizar diccionarios por dos motivos principalmente: a Un diccionario hace explcito el dise o del desarrollador de la aplicaci n. n o A nivel de lenguaje de programaci n, las secuencias se implementan como vectores y o requieren una b squeda linear para localizar un elemento. Por otra parte, los diccionau rios est n implementados de acuerdo a una estructura de datos eciente en tiempos de a b squeda. u Para una informaci n m s detallada sobre los tipos de datos denidos por el usuario cono a sultar [4]. Slice tambi n soporta la denici n de constantes a trav s de uno de los siguientes tipos e o e de datos: Un tipo integral (bool, byte, short, int, long, o un tipo enumerado). oat o double. string.

4.2.7.

Interfaces, operaciones, y excepciones

El principal objetivo de Slice es la denici n de interfaces, por ejemplo: ostruct Hora { short hora; short minute; short second; }; interface Reloj { Hora obtenerHora(); void establecerHora(Hora h); };

La denici n anterior especica un tipo de interfaz denominado Reloj. Dicha interfaz o soporta dos operaciones: obtenerHora y establecerHora. Los clientes acceden a un objeto que soporta la interfaz Reloj invocando una operaci n en un proxy para dicho objeto: para o


43

obtener la hora actual el cliente invoca a la hora operaci n obtenerHora, y para establecerla o invoca a la operaci n establecerHora, especicando un par metro del tipo Hora. o a La denici n de una operaci n ha de tener un tipo de retorno y cero o m s deniciones o o a de param tros. Por defecto, los par metros enviados del cliente al servidor son par metros de e a a entrada. Para pasar un par metro del servidor al cliente se pueden emplear los par metros de a a salida, utilizando para ello el modicador out:void obtenerHora(out Hora h);

En cuanto a las operaciones que devuelven varios par metros de salida existen distintas a opciones, como por ejemplo especicar que todos esos par metros sean de salida o asociar el a valor de retorno al par metro de salida m s importante y utilizar el modicador out para el a a resto:bool siguiente(out Registro r);

Slice no soporta ning n tipo de sobrecarga de operaciones. Todas las operaciones de una u interfaz han de tener un nombre distinto entre s. Este hecho se debe a que existen ciertos lenguajes que no soportan esta caracterstica. Existen distintos modicadores que se pueden aplicar a la denici n de las operaciones o en funci n de su naturaleza. Algunas operaciones no modican el estado del objeto sobre o el que operan, mientras que otras son idempotentes, es decir, se obtiene el mismo resultado tanto si se invocan una vez como si se invocan varias. El desarrollador puede informar a ICE sobre estos hechos de cara a que este utilice mecanismos m s agresivos con el objetivo de a ahorrar recursos y proporcionar una implementaci n m s eciente. Para ello, se utilizan los o a modicadores nonmutating e idempotent, respectivamente:struct Hora { short hora; short minute; short second; }; interface Reloj { nonmutating Hora obtenerHora(); idempotent void establecerHora(Hora h); };


44

En lo relativo a excepciones, ICE permite la denici n de excepciones de usuario para o indicar al cliente las condiciones de error que se produzcan:exception Error {}; exception RangeError { Hora errorEnLaHora; Hora tiempoMin; Hora tiempoMax; }; interface Reloj { nonmutating Hora obtenerHora(); idempotent void establecerHora(Hora h) throws RangeError, Error; };

Las excepciones en Slice son parecidas a las estructuras en el sentido de que pueden tener un n mero arbitrario de miembros, pero con la salvedad de que las excepciones pueden no u tener miembros. Adem s, Slice soporta la herencia de excepciones. De hecho, mantiene un a arbol de herencia en el que se especican las excepciones propias al entorno de ejecuci n de o ICE. Es importante tener en cuenta que una operaci n s lo puede lanzar una excepci n que o o o previamente fue especicada en su denici n en Slice. Adem s, las excepciones no se consio a deran tipos de datos de primera clase, por lo que no pueden pasarse como par metros en las a operaciones ni utilizarlos como miembros en la denici n de estructuras, entre otras restrico ciones. Siguiendo con el ejemplo del reloj se podra denir un servidor en el que estuvieran pre sentas las zonas horarias de todo el mundo:exception ErrorGenerico { string razon; }; struct Hora { short hora; short minute; short second; }; exception ValorHoraErroneo extends ErrorGenerico {}; interface Reloj { nonmutating Hora obtenerHora();


45

idempotent void establecerHora(Hora h) throws ValorHoraErroneo; }; dictionary MapaZonas; exception NombreZonaErroneo extends ErrorGenerico {}; interface RelojMundial { idempotent void aadirZona(string nombre, Reloj* relojZona); n void eliminarZona(string nombre) throws NombreZonaErroneo; nonmutating Reloj* encontrarZona(string nombre) throws NombreZonaErroneo; nonmutating MapaZonas listaZonas(); idempotent void establecerZonas(MapaZonas zonas); };

La interfaz RelojMundial act a como un gestor de zonas, es decir, un gestor de parejas u nombre de la zona y reloj. Dicha interfaz proporciona operaciones para a adir zonas, eliminar n zonas, encontrar zonas, obtener la lista completa de zonas, y establecer la lista de zonas. El concepto m s importante de este ejemplo reside en que las propias interfaces son tipos de a datos por s mismas y, por lo tanto, se pueden pasar como par metros y pueden ser devueltas, a como se aprecia en las operaciones a adirZona y eliminarZona, respectivamente. El operador n se conoce como operador proxy. Su argumento m s a la izquierda ha de ser una interfaz (o a una clase), y su tipo de retorno es un proxy. Un proxy se puede entender como un puntero que referencia a un objeto. La sem ntica de los proxies es muy parecida a los punteros asociados a a una instancia de clase en C++. Cuando un cliente pasa un proxy Reloj a la operaci n a adirZona, el proxy hace refeo n rencia al objeto de tipo Reloj real en el servidor. El objeto ICE Reloj referenciado por ese proxy puede estar implementado en el mismo proceso servidor que la interfaz RelojMundial o en un proceso de servidor distinto. Desde el punto de vista del cliente, la localizaci n fsica o de dicho objeto no importa. En otras palabras, el proxy act a como el embajador local del u objeto remoto: invocar una operaci n en el proxy se traduce en invocar la operaci n en la o o implementaci n del objeto real. Si el objeto est implementado en un espacio de direcciones o a distinto al del cliente, ICE realiza una llamada a procedimiento remoto. Si el objeto est ima plementado en el mismo espacio de direcciones, ICE realiza una llamada local desde el proxy a la implementaci n del objeto. o Al igual que ocurre con las excepciones, las interfaces tambi n soportan el concepto de e

4.3. Aspectos avanzados herencia.

46

4.3.

Aspectos avanzados

En esta secci n se comentar n algunos aspectos avanzados de Slice. Sin embargo, para o a obtener una informaci n m s completa y detallada se recomienda estudiar [4]. o a

4.3.1.

Clases

Adem s de las interfaces, Slice permite la denici n de clases. Las clases son como las a o interfaces en el sentido de que tienen operaciones, y se parecen a las estructuras debido a que pueden incluir atributos. El resultado son unos objetos hbridos que pueden tratarse al igual que las interfaces y pasarse por referencia, o pueden tratarse como atributos y pasarse por valor. El benecio de las clases es una mayor exibilidad a la hora de desarrollar aplicaciones: las clases permiten modelar el comportamiento a implementar en el lado del cliente y las interfaces permiten representar el comportamiento a implementar en el lado del servidor. Las clases soportan la herencia y, por lo tanto, el polimorsmo. El utilizar clases en ciertos contextos, como por ejemplo denir una clase con operaciones, implica reexionar sobre ciertos aspectos asociados a la arquitectura de la aplicaci n. El tener o una clase con operaciones denidas en ellas implica utilizar c digo nativo del lado del cliente o y, por lo tanto, elimina la transparencia de implementaci n proporcionada por las interfaces. o Una clase Slice tambi n puede utilizarse como un sirviente en un servidor, es decir, una e instancia de una clase se puede utilizar para proporcionar el comportamiento de un interfaz:interface Tiempo { nonmutating Hora obtenerHora(); idempotent void establecerHora(Hora h); }; class Reloj implements Tiempo { Hora hora; };

Parte III ICE avanzado

47

Captulo 5 Propiedades de ICE y conguraci n o5.1. Introducci n o 5.2. Propiedades 5.3. Archivos de conguraci n o 5.4. La propiedad Ice.Cong

5.1.

Introducci n o

ICE utiliza un mecanismo de conguraci n que permite controlar muchos aspectos del o comportamiento de las aplicaciones ICE en tiempo de ejecuci n, como el tama o m ximo de o n a los mensajes, el n mero de hilos, o si generar mensajes de trazas de red. Dicho mecanismo u de conguraci n no s lo es util para congurar ICE, sino que tambi n se puede utilizar para o o e proporcionar par metros de conguraci n a las propias aplicaciones. Este mecanismo es muy a o simple en el sentido de que se puede utilizar con una sencilla API, y escalable en el sentido de que se adapta a la necesidades de la mayora de aplicaciones.

5.2.

Propiedades

ICE y sus distintos subsistemas se conguran a trav s de las propiedades. Una propiedad e es un par nombre-valor, por ejemplo:

48

5.3. Archivos de conguraci n o

49

Ice.UDP.SndSize=65535

En este ejemplo, el nombre de la propiedad es Ice.UPD.SndSize y su valor es 65535.

5.3.

Archivos de conguraci n o

Los valores de las propiedades se establecen normalmente en archivos de conguraci n. o Un archivo de conguraci n contiene un determinado n mero de parejas nombre-valor, cada o u uno en una lnea del mismo. El car cter # se utiliza para introducir comentarios que se extien a den para la lnea actual en la que se introduce dicho car cter. Un ejemplo es el siguiente: a# Ejemplo de archivo de configuracin para ICE. o Ice.MessageSizeMax = 2048 # Tamao mximo de 2MB. n a Ice.Trace.Network = 3 # Mximo nivel de traza de red. a Ice.Trace.Protocol = # Desactivada la traza de protocolo.

Para C++, Python, y .NET, ICE lee los contenidos del archivo de conguraci n cuando o se crea el communicator. Por defecto, el nombre del archivo de conguraci n se determina o leyendo el contenido de la variable de entorno ICE CONFIG.

5.4.

La propiedad Ice.Cong

La propiedad Ice.Cong tiene un signicado especial para ICE: determina la ruta del archivo de conguraci n a partir del cual leer los valores de las distintas propiedades. Por o a ejemplo:$ ./server --Ice.Config=/usr/local/holaMundo/config

Para aspectos m s detallados como acceder y establecer los valores de las propiedades a desde una aplicaci n se recomienda consultar [4]. o

Captulo 6 Programaci n asncrona o 6.1. Introducci n o o e 6.1.1. Invocaci n de m todos asncrona o AMI (Asynchronous Method Invocation) 6.1.2. Tratamiento de m todos asncrono o AMD (Asynchronous Method Dispatch) e 6.1.3. Controlando la generaci n de c digo utilizando metadatos o o 6.1.4. Transparencia 6.2. AMI 6.2.1. Simulando AMI utilizando invocaciones oneway 6.2.2. Mappings 6.2.3. Ejemplo 6.2.4. Cuestiones asociadas a la concurrencia 6.2.5. Timeouts 6.3. AMD 6.3.1. Mappings 6.3.2. Ejemplo

6.1.

Introducci n o

La mayora de las tecnologas middleware m s modernas tratan de facilitar la transici n a o de los programadores al desarrollo de aplicaciones distribuidas. Para ello, lo que hacen es acercar el modelo de programaci n tradicional a los entornos distribuidos, de forma que las o llamadas a procedimientos remotos sean pr cticamente id nticas a las llamadas locales. Sin a e

50

6.1. Introducci n o

51

embargo, la implementaci n de un objeto en una aplicaci n distribuida puede estar impleo o mentado en otra m quina distinta a la que invoca una operaci n suya, por lo que existen a o ciertas diferencias sem nticas que el programador ha de tener en cuenta, como por ejemplo a la sobrecarga derivada de la invocaci n a operaciones remotas o los errores derivados de la o propia red. A pesar de estas cuestiones, la experiencia del programador con la programaci n o orientada a objetos es a n relevante, y este modelo de programaci n sncrona, en el que el u o hilo que invoca una operaci n se queda bloqueado hasta que esta naliza, es familiar y f cil o a de entender. ICE es inherentemente un plataforma middleware asncrona que simula el comportamien to sncrono para el benecio de las aplicaciones (y de sus programadores). Cuando una apli caci n ICE ejecuta una operaci n sncrona en un proxy vinculado a un objeto remoto, los o o par metros de entrada de la operaci n se codican junto con el mensaje a transportar, y el a o hilo de ejecuci n que lleva a cabo esa invocaci n se bloquea con el objetivo de simular la llao o mada sncrona. Mientras tanto, ICE opera en un segundo plano procesando los mensajes hasta que se recibe la respuesta y el hilo que ejecut la llamada queda bloqueado para decodicar o los resultados. Existen muchas situaciones en las que la naturaleza bloqueante de la programaci n sncroo na resulta muy restrictiva. Por ejemplo, la aplicaci n puede disponer de trabajo util para ejecuo tar mientras est a la espera de una invocaci n remota. De esta forma, utilizar una invocaci n a o o sncrona fuerza a la aplicaci n a posponer ese trabajo hasta que se reciba la respuesta asociada o o a desarrollarlo en otro hilo de ejecuci n distinto. Cuando ninguna de estas alternativas reo sulta aceptable, la facilidades asncronas proporcionadas por ICE suponen una soluci n ecaz o para mejorar el rendimiento y la escalabilidad, o para simplicar ciertas tareas complejas.

6.1.1.

Invocaci n de m todos asncrona o AMI (Asynchronous Method o e Invocation)

AMI es el t rmino empleado para describir el soporte del lado del cliente en el modelo e de programaci n asncrono. Utilizando AMI, una invocaci n remota no bloquea el hilo de o o ejecuci n asociado mientras se espera la respuesta asociada a dicha invocaci n. En su lugar, o o

6.1. Introducci n o

52

dicho hilo puede continuar sus actividades y ICE notica a la aplicaci n cuando la respuesta o llega. Esta noticaci n se efect a a trav s de una retrollamada de un objeto proporcionado o u e por la aplicaci n desarrollada. o

6.1.2.

Tratamiento de m todos asncrono o AMD (Asynchronous Mete hod Dispatch)

El n mero de solicitudes sncronas simult neas que un servidor es capaz de soportar queda u a determinado por el modelo de concurrencia del servidor. Si todos los hilos est n ocupados a atendiendo a operaciones que requieren mucho tiempo, entonces no existen hilos disponibles con los que procesar nuevas peticiones y, por lo tanto, es posible que los clientes experimenten una inaceptable p rdida de respuesta. e AMD, el equivalente en el lado del servidor de AMI, trata este problema de escalabilidad. Utilizando AMD, un servidor es capaz de recibir una solicitud y entonces suspender su procesamiento para liberar el hilo asociado tan pronto como sea posible. Cuando dicho procesamiento se reanuda y los resultados est n disponibles, el servidor enva una respuesta a explcita utilizando un objeto de retrollamada proporcionado por el n cleo de ejecuci n de u o ICE. En t rminos pr cticos, una operaci n AMD tpicamente encola los datos de la solicitud e a o (como por ejemplo el objeto de retrollamada y los argumentos de la operaci n) para proceo sarlos posteriormente por un hilo de la aplicaci n (o un conjunto de hilos). De esta forma, el o servidor minimiza el n mero de hilos asociados al tratamiento de operaciones y es capaz de u soportar miles de clientes de manera simult nea y eciente. a Un caso de uso alternativo para AMD es una operaci n que requiere una mayor cantidad o de procesamiento despu s de completar una solicitud del cliente. Con el objetivo de minimie zar el tiempo de espera del cliente, la operaci n devuelve los resultados mientras en el hilo o asociado al tratamiento de dicha solicitud espera, y entonces contin a utilizando dicho hilo u para el trabajo adicional.

6.1. Introducci n o

53

6.1.3.

Controlando la generaci n de c digo utilizando metadatos o o

Para indicar el uso de un modelo de programaci n asncrono (AMI, AMD, o ambos) se o utilizan metadatos en las deniciones Slice. El programador puede especicar estos metadatos a dos niveles: a nivel de interfaz o de clase, o a nivel de operaci n individual. Si se o especica para una interfaz o una clase, entonces el soporte asncrono se genera para todas sus operaciones. De forma alternativa, si el soporte asncrono se necesitas lo para ciertas ope o raciones, entonces el c digo generado puede minimizarse especicando los metadatos s lo o o para los operaciones que as lo requieran. Los m todos de invocaci n sncronos se generan siempre en un proxy, de forma que ese o pecicando los metadatos AMI simplemente se a aden los m todos de invocaci n asncron e o nos. Por otra parte, especicar los metadatos AMD implica que los m todos de tratamiento e sncrono sean reemplazados por sus hom logos asncronos. o Un ejemplo en Slice es el siguiente:[ami] interface I { bool esValido(); float calcularMedia(); }; interface J { [amd] void comenzarProceso(); [ami, amd] int finalizarProceso(); };

En este ejemplo, todos los m todos asociados a la interfaz I se generan con soporte para e invocaciones sncronas y asncronas. En la interfaz J, la operaci n comenzarProceso utiliza o un tratamiento asncrono, mientras que la operaci n nalizarProceso soporta una invocaci n o o y un tratamiento asncronos. Especicar metadatos a nivel de operaci n, en lugar de a nivel de interfaz o de clase, o no s lo minimiza la cantidad de c digo generado, sino lo que es m s importante, tambi n o o a e minimiza la complejidad. Aunque el modelo asncrono es m s exible, tambi n resulta m s a e a complejo de utilizar. Por lo tanto, es decisi n del desarrollador limitar el uso del modelo o asncrono para aquellas operaciones en las que proporcione determinadas ventajas, utilizando el modelo sncrono para el resto, el cual resulta m s sencillo. a

6.2. AMI

54

6.1.4.

Transparencia

El uso del modelo asncrono no afecta a lo