1. Introduccion

1.1 Computación Grid

La necesidad de aprovechar los recursos disponibles en los sistemas informáticos conectados a Internet y simplificar su utilización ha dado lugar a una nueva forma de tecnología de la información conocida como computación grid (Grid Computing). De este modo, los sistemas distribuidos se pueden emplear como un único sistema virtual en aplicaciones intensivas en datos o con gran demanda computacional.

Un Grid es un conjunto de recursos hardware y software distribuidos por Internet que proporcionan servicios accesibles por medio de un conjunto de protocolos e interfaces abiertos (gestión de recursos, gestión remota de procesos, librerías de comunicación, seguridad, soporte a monitorización,...). Las organizaciones virtuales que se interconectan por medio de un Grid tienen que mantener sus propias políticas de seguridad y gestión de recursos. Esto significa que la tecnología usada para construir un Grid es complementaria a otras tecnologías aprovechando los recursos distribuidos en la intranet de una organización.

La computación grid permite aprovechar los momentos de baja carga de todos los computadores conectados mediante una red de alta velocidad. Una plataforma grid de altas prestaciones involucra un conjunto heterogéneo de nodos de computación que pueden residir en diferentes ubicaciones, poseer una estructura diferente y utilizar diferentes políticas. La tecnología grid es una tecnología relativamente nueva, que está en fase de desarrollo y explotación.

En el libro “The Grid: Blueprint for a New Computing Infrastructure”, se compara la tecnología grid con electrical power grid, en el sentido de que el usuario debe poder utilizar los recursos computacionales de la misma forma que la energía eléctrica, es decir, desde cualquier lugar, con un funcionamiento adecuado y un coste asequible. En 1995, durante el congreso SuperComputing 95, se demostró la factibilidad de ejecutar aplicaciones científicas distribuidas en una red de alta velocidad formada por nodos de 17 centros de Estados Unidos. Esta demostración significó el punto de partida de diferentes proyectos que tenían como denominador común la compartición de los recursos de computación distribuidos. Entre los primeros proyectos grid, surge el proyecto Information Power Grid (IPG) de la NASA, que permite la integración y gestión de recursos de los centros de la NASA. Por otro lado, entre las aplicaciones más conocidas se incluyen los proyectos Search for Extraterrestrial Intelligence, que analiza los datos obtenidos por telescopios para la búsqueda de signos de vida extraterrestre, o Great Internet Mersenne Prime Search (GIMPS), cuyo objetivo es el descubrimiento del mayor número primo. Como se puede observar, la computación grid se ha utilizado en el análisis de numerosos tipos de datos. Al igual que el desarrollo de Internet ha sido posible gracias al uso del protocolo estándar TCP/IP, la tecnología grid también posee un estándar de facto, denominado Globus. Globos proporciona una infraestructura software que incorpora los protocolos y servicios básicos necesarios para la construcción de aplicaciones grid. Globus surge a partir de la colaboración de distintas universidades y centros de investigación, que forman The Globus Alliance.

La tecnología grid posibilita la resolución de problemas demasiado costosos a nivel de computación y gestión de la información como para que se resuelvan por una única máquina o un único clúster de estaciones de trabajo. Entre las aplicaciones que hacen uso de este nuevo paradigma, debido a su gran necesidad de computación y el enorme conjunto de datos que utilizan, se encuentran aplicaciones de las denominadas ciencias de la vida, que tienen como principal baluarte el conocimiento del genoma humano o los progresos realizados en las neurociencias, así como

aplicaciones de física, de modelado del clima atmosférico o de visualización. Estas aplicaciones suelen utilizar sistemas que se encargan de la explotación de la información, a partir de técnicas de data mining u otros algoritmos de tratamiento de la información. Todos estos sistemas requieren módulos de adquisición de datos (information retrieval) eficientes y con una alta capacidad de almacenamiento. En general, las denominadas data-intensive applications o aplicaciones con uso intensivo de datos pueden beneficiarse de la aplicación de la computación grid. Este campo, enormemente extenso dada la gran cantidad de información que gestionan hoy en día las aplicaciones, deja abiertos numerosos retos tanto formales como tecnológicos y representa uno de los temas de interés más activos en campo de la informática distribuida.

Resumiendo, las principales ventajas que ofrece la computación grid son: La potencia ilimitada que ofrecen multitud de computadores conectados en red, con su

capacidad de proceso. La integración de sistemas y dispositivos heterogéneos. La eliminación de los cuellos de botella de algunos procesos de computación. Se trata de una solución altamente escalable. Nunca queda obsoleta, como ocurre con los grandes equipos, debido a su capacidad dinámica de

modificar el número y características de sus componentes.

1.2 Ice (The Internet Comunication Engine)

Es un middleware útil para programadores. Una plataforma de comunicación a través de Internet de alto rendimiento, Ice incluye una gran variedad de servicios y plu-ins. Ice esta formado por los siguientes paquetes:

- Slice: El lenguaje de especificación para Ice. Establece el contacto entre servidores y clientes y además es utilizado para describir datos persistentes.

- Compiladores Slice: Las especificaciones en Slice se pueden compilar en varios lenguajes de programación: C++, Java, Pitón, PHP, C# y Visual Basic. Los servidores y clientes Ice trabajan juntos, a pesar del lenguaje de programación.

- Ice: El núcleo de librerias Ice, entre otras características este paquete gestiona todas las tareas de comunicación utilizando un protocolo de altamente eficiente, proporciona soporte de hilos para servidores multihilo y funcionalidades adicionales para soportar escalabilidad extrema con a priori millones de objetos Ice.

- IceUtil: una colección utilidades como manejo de Unicote y programación con hilos (C++ solo).

- IceBox: Un servidor de aplicación especifico para aplicaciones Ice. IceBox puede ejecutar y administrar servicios Ice que son cargados dinámicamente como una DLL, librería compartida o clase Java.

- IceGrid: Un sofisticado servidor de activación y herramienta de despliegue para computación grid avanzada.

- Freeze: proporciona persistencia automática para servants Ice. Con unas pocas líneas de código, una aplicación puede incorporar un vector altamente escalable que gestiona eficientemente objetos persistentes.

- FreezeScript: es necesario para cambiar tipos de datos persistentes, especialmente en proyectos software grandes. Para minimizar el impacto de estos cambios, FreezeScript proporciona herramientas de inspección y migración para bases de datos Freeze. La herramienta soporta scripts basados en XML ya que es potente y fácil de usar.

- IceSSL: Un plug-in de transporte SSL dinámico para el núcleo Ice. Proporciona autenticación, encriptación e integridad de mensaje, utilizando un protocolo SSL estandar.

- Glaciar: Algunos retos de los sistemas middleware son la seguridad y los firewalls. Glaciar es una solución firewall de Ice, que simplifica el despliegue de aplicaciones seguras. Autentica y filtra las solicitudes de los clientes y permite callbacks al cliente de una manera segura. Utilizado en combinación con IceSSL, proporciona una solución segura que no permite intrusos y es fácil de configurar.

- IceStorm: un servicio de mensajería que soporta la federación. En comparación con otros servicios de mensajería o eventos, IceStorm soporta tipado de eventos, entendiendo que la difusión de un mensaje en una federación es tan fácil como invocar un método sobre un interface.

- IcePath: es un servicio de parcheado para distribuciones software. Mantener el software actualizado es una tarea tediosa. IcePath automatiza las actualizaciones tanto de archivos individuales y de jerarquías de directorios. Solo los archivos modificados son descargados en las maquinas cliente, utilizando eficientemente algoritmos de compresión.

2. IceGrid

Es un servicio de activación y localización para aplicaciones Ice. Fue introducido en la versión Ice 3.0, anteriormente su trabajo lo realizaba de forma similar IcePack, pero debido al auge de la computación grid se decidió su aparición. IceGrid realiza todas las funciones que realizaba IcePack y añade nuevas funcionalidades que permiten el desarrollo y administración de aplicaciones Ice en redes grid.

Como desarrollador, se necesita escribir código para ejecutarse sobre computadoras grid, y Ice es una suite ideal como infraestructura para permitir a los componentes de una aplicación grid comunicarse unos con otros. Las características de IceGrid son las siguientes:

Servicio de localización: como implementación de un servicio de localización, IceGrid permite a los clientes unirse indirectamente con sus servidores, haciendo aplicaciones más flexibles y fuertes a los cambios de requisitos.

Activación de servidor bajo demanda: iniciar un proceso servidor Ice se conoce como activación de servidor. IceGrid puede realizar responsablemente la activación de un servidor bajo demanda, es decir, cuando un cliente intenta acceder a un objeto hospedado por el servidor. La activación generalmente ocurre como efecto secundario de una unión indirecta, y es completamente transparente al cliente.

Distribución de la aplicación: IceGrid proporciona una manera apropiada de distribuir la aplicación entre un conjunto de computadoras, sin la necesidad de compartir el sistema de ficheros o complicados scripts. Simplemente configurando un servidor IcePatch2 y permitir que IceGrid descargue los ficheros necesarios y se mantendrán sincronizados.

Duplicación y balance de carga: Icegrid soporta duplicación agrupando los adaptadores de objeto de varios servidores dentro de un único adaptador de objeto virtual. Durante la unión indirecta, un cliente puede ser destinado a un endpoint de cualquiera de estos adaptadores. Además, IceGrid monitoriza la carga de cada computadora y puede utilizar esa información para decidir que endpoint debe de destinarse a un cliente.

Recuperación de errores automática: Ice soporta sistemas de volver a intentar y de recuperación de errores en cualquier proxy que contenga varios endpoints. Cuando se combina con el soporte de duplicación y balance de carga de IceGrid, recuperación de errores se traduce en que solicitud fallida se vuelve a realizar transparentemente en el siguiente endpoint con la menor carga posible.

Respuestas dinámicas: hay que añadir con respecto a la unión transparente, que las aplicaciones pueden interactuar directamente con IceGrid de diferentes formas para localizar objetos.

Monitorización del estado: IceGrid soporta interfaces Slice que permite aplicaciones que monitorizan estas actividades y reciben notificaciones sobre eventos significativos, activando el desarrollo de herramientas o integrando eventos de estado de IceGrid dentro de la estructura de gestión existente.

Administración: IceGrid incluye una línea de comandos herramientas de administración grafica, están disponibles en todas las plataformas soportadas y permiten comenzar, parar, controlar y reconfigurar cualquier servidor gestionado por IceGrid.

Despliegue: se utilizan ficheros XML, se puede indicar los servidores que se desplegaran en cada computador. Las plantillas simplifican la descripción de servidores que son idénticos.

Como computación grid apuntar que el flujo principal y los servidores de cómputo se vuelven sencillos, los usuarios esperan más productividad de sus aplicaciones. IceGrid en cooperación con el entorno de ejecución Ice, te releva de las tareas de bajo nivel para acelerar la construcción y simplifica la administración de las aplicaciones distribuidas.

2.1 Arquitectura

Un ejemplo de Icerid consiste e un único registro y varios nodos., que cooperan juntos para gestionar la información y servir los procesos que componen la aplicación. Cada aplicación asigna servidores a los nodos. El registro mantiene un archivo persistente con esta información, mientras que los nodos son responsables de iniciar y monitorizar los procesos servidor asignados. En una configuración típica, cada nodo se ejecuta en un computador que hospeda servidores Ice. El registro no consume mucho tiempo de procesador, pero comúnmente se ejecuta en el mismo computador como un nodo; de hecho, el registro y un nodo pueden ejecutarse en el mismo proceso si se desea.

Ejemplo

La Figura 1 muestra una aplicación grid muy simple ejecutándose en una red de tres computadoras. El registro IceGrid es le único proceso de interés en el host PC1, mientras que los nodos IceGrid se ejecutan en los hosts PC2 y PC3., en este ejemplo cada servidor ha sido asignado a cada nodo.

Figura 1. Aplicación IceGrid Simple

Desde la perspectiva de una aplicación cliente, la principal responsabilidad del registro es resolver los proxies indirectos como un servicio de localización Ice. Esta contribución es transparente: cuando un cliente primero intenta conectarse a un proxy indirecto, el entorno de ejecución Ice del cliente contacta con el registro para convertir la información simbólica del proxy en un endpoint que permite al cliente establecer una conexión.

Aunque el registro nos suene a algo parecido, es solamente una tabla de búsqueda, esta es la diferencia. Por ejemplo, localizar una solicitud puede provocar que un nodo comience la búsqueda del servidor objetivo automáticamente, o que el registro puede seleccionar el endpoint apropiado basándose en estadísticas de carga de cada computador.

Esto muestra los beneficios de los proxies indirectos: el servicio de localización puede proporcionar una gran funcionalidad sin que una acción especial sea realizada por parte del cliente, a diferencia de lo que ocurre con los proxies directos, los clientes no necesitan conocimientos previos de la dirección y puerto de los servidores. El nivel extra de indirección añade algo de latencia al primer cliente que hace uso de un proxy; sin embargo, todas las interaciones posteriores se realizan

directamente entre el cliente y el servidor, el coste es insignificante. Además, la indirección permite a los servidores migrar a distintas computadoras sin la necesidad de mantener actualizados los proxies por parte del cliente.

Duplicación (Replication)

La flexibilidad de IceGrid permite una variedad de configuraciones interminable. Por ejemplo, si tenemos una red grid y queremos replicar un servidor en cada hoja, como muestra la Figura 2.

Figura 2. Servidor Replicado en una Red Grid

En Ice la duplicación se basa en los adaptadores de objeto y no en los servidores. Cualquier adaptador de objeto en cualquier servidor puede participar en una duplicación, pero es más probable que todos los adaptadores de objeto duplicados sean creados por instancias del mismo servidor ejecutable que esta funcionando en cada computadora. Esta es la configuración del ejemplo anterior, pero IceGrid requiere que cada servidor tenga un único nombre. Server 1 y Server 2 son nombres diferentes para un mismo ejecutable.

El proceso de unión funciona de manera diferente cuando la duplicación esta involucrada, el registro tiene varios adaptadores de objeto para escoger. La descripción de una aplicación IceGrid guía la decisión del registro sobre que adaptador o adaptadores de objeto utilizar. Por ejemplo, el registro puede considerar la carga del sistema de cada computador (que es periódicamente enviado por los nodos) y devolver el endpoint del adaptador de objeto de la computadora que tiene una menor carga. También es posible que el registro combine los endpoints de varios adaptadores de objeto, en cuyo caso el entorno de ejecución Ice en el cliente, selecciona el endpoint para el intento de conexión inicial.

Despliegue (Deployment)

En IceGrid, el despliegue es el proceso de descripción de una aplicación al registro. La descripción contiene la siguiente información:

Grupos de Replica: un grupo de replica es el termino aplicado para definir una colección de adaptadores de objeto duplicados. Una aplicación puede crear los grupos de replica que desee, donde cada grupo debe de tener un identificador único.

Nodos: una aplicación debe asignar los servidores a uno o más nodos. Servidores: la descripción de un servidor incluye un nombre único y la ruta al ejecutable.

También describe la lista de adaptadores de objeto que crea. Adaptadores de Objeto: la información de los adaptadores de objeto incluye sus endpoints y

cualquier objeto bien conocido (well-known) que anuncie. Objetos: un objeto bien conocido es único y se le conoce por su identidad. El registro mantiene

una lista global de cada objeto para utilizarse durante le solicitud de localización.

IceGrid utiliza el término descriptor para referirse a la descripción de una aplicacion y sus componentes; para desplegar una aplicación es obligatorio crear sus descriptores en el registro. Hay diferentes formas de hacerlo:

- Se puede utilizar la herramienta de línea de comandos que lee descriptores XML.- Se pueden crear los descriptores interactivamente con la herramienta de administración grafica.- Se pueden crear los descriptores programando mediante el interface administrativo de IceGrid.

El servidor de registro debe de ejecutarse para poder desplegar una aplicación, pero no es necesario para los nodos que este activo. Los nodos que son arrancados después del despliegue, recuperan la información que necesitan del registro automáticamente. Una vez desplegada, se puede actualizar una aplicación automáticamente.

3. Caracteristicas:

3.1 Objetos Bien Conocidos (Well-Known)

Hay dos tipos de proxies indirectos: uno especifica una identidad y un identificador de adaptador de objetos, mientras que el otro contiene una identidad. Este último tipo de proxy indirecto hace referencia a los objetos bien conocidos, es decir, esta identidad es suficiente para permitir al cliente localizar al objeto. Ice requiere que todas las identidades de objetos de una aplicación sean diferentes, pero generalmente solo unos pocos objetos pueden ser localizados por sus identidades.

El registro mantiene una tabla de estos objetos, que puede ser rellenada de diferentes formas:- estáticamente mediante descriptores- con programación mediante la interface administrativa de IceGrid- dinámicamente utilizando la herramienta de administración de IceGrid

La base de datos del registro mapea una identidad de un objeto a un proxy. Una solicitud de localización que contiene únicamente una identidad, provoca que el registro consulte esta base de datos. Si hay una coincidencia, el registro examina el proxy asociado para determinar si se necesita hacer trabajo adicional.

Figura 3. Ejemplo de Objetos Well-Known y su Proxies

El proxy asociado con Object1 contiene un endpoint, el registro puede simplemente devolver este Proxy al cliente. Para el Object2, el registro publica el id del adaptador y chequea para ver si existe el adaptador identificado como TheAdapter. Si existe, intenta obtener el endpoint del adaptador, lo que puede hacer que el servidor se inicie. Si el registro es capaz de determinar el endpoint de un adaptador, entonces devuelve un proxy directo que contiene ese endpoint al cliente. Si el registro no reconoce TheAdapter o no puede obtener su endpoint, entonces devuelve un Proxy indirecto Object2@TheAdapter al cliente. Si se recibe otro proxy indirecto, el entorno de ejecución Ice en el cliente puede intentar una vez mas resolver el proxy, pero generalmente esto no sucede y el entorno de ejecución Ice en el cliente lanza la excepción NoEndpointException como resultado. Finalmente, el Object3 representa una situación desesperada: ¿puede el registro resolver Object3 cuando su proxy asociado se referencia a el mismo? En este caso, registro devuelve el Proxy Object3 al cliente, lo que causa que el cliente lance la excepción NoEndpointException. Esta claro que esta situación hay que intentar evitarla.

Tipos de Objetos

La base de datos del registro no solo asocia una identidad con un Proxy, también puede asociar un tipo. Técnicamente un “tipo” es un string arbitrario, pero por convención, representa el tipo Slice más obtenido del objeto. Los tipos de objetos son útiles para realizar preguntas.

Descriptores de Objetos

El descriptor de un objeto permite añadir un objeto al registro. Suele aparecer dentro del contexto de un descriptor de un adaptador, como muestra la siguiente figura de un ejemplo XML:

Figura 4. Descriptor de un Objeto

Durante el despliegue, el registro asocia la identidad de un objeto con el proxy indirecto, si el descriptor de un adaptador ha omitido el id del adaptador, el registro ha de generar un identificador único utilizando el id del servidor y el nombre del adaptador.

3.2 Pantillas (Templates)

Las plantillas IceGrid simplifican la tarea de crear los descriptores de una aplicación. Una plantilla es un descriptor parametrizado que se puede instanciar cuando sea necesario. Son componentes de una aplicación IceGrid y por tanto se almacenan en la base de datos del registro. Las plantillas se pueden crear mediante ficheros XML e interactivamente con la herramienta administración grafica.

Se pueden definir plantillas para descriptores de servidores y servicios. En este punto se describen los descriptores de servidores.

Descriptores de Servidores

El ejemplo que muestra la Figura 5, nos muestra la definición de dos nodos que contiene un servidor en cada uno, y que forman parte de una aplicación de ripeo de un cd-rom de audio y convertirlo en archivos MP3. En este ejemplo no se utilizan plantillas.

Figura 5. Definición de Servidores Normal

La Figura 6 muestra una definición equivalente del ejemplo utilizando plantillas.

Figura 6. Definición de Servidores con Plantillas

Se ha definido la plantilla del servidor con el nombre de EncoderServerTemplate. El elemento server-template es un elemento Server que define un servidor de codificación. La única diferencia con el ejemplo anterior es que el elemento server esta parametrizado: el parámetro de la plantilla index se utiliza para formalizar identificadores únicos para el servidor y su adaptador. El símbolo ${indes} se reemplaza con el valor del parámetro index donde aparezca.

La plantilla es instanciada por el elemento server-instance, que se puede utilizar en cualquier sitio donde se utilice el elemento server y que identifica la plantilla que va a ser instanciada y proporciona el valor del parámetro index.

Con esto se consiguen ficheros XML más pequeños, leíbles, y lo más importante e que desplegar servidores en nodos adicionales es más sencillo.

Parámetros de una Plantilla

Los parámetros permiten especificar cada instancia de una plantilla cuando sea necesario. En el ejemplo anterior se definía el parámetro index con un valor diferente para cada instancia, lo que permite asegurar que los identificadores eran únicos, a este tipo de parámetros se les llama parámetros obligatorios (mandatory) y no tienen valor por defecto. Los parámetros permiten definir el valor por defecto que se utiliza en una plantilla si no se especifico ninguno. Un ejemplo de parámetros con valores por defecto, supongamos que la ruta (pathname) del ejecutable del servidor puede cambiar en cada nodo, se puede proporcionar un valor por defecto para este atributo y anularlo cuando sea necesario.

Figura 7. Plantilla con Parámetros con Valor por Defecto

Se puede observar, que la instancia Node1 utiliza el valor por defecto para el nuevo parámetro exepath, pero la instancia Node2 define una localización diferente para el ejecutable del servidor.

Plantillas por Defecto

El registro IceGrid puede ser configurado para proporcionar descriptores de plantillas por defecto para utilizarse en aplicaciones. La propiedad de configuración IceGrid.Registry.DefaultTemplates especifica la ruta del fichero XML que contiene las definiciones de las plantillas. Si el fichero plantilla es proporcionado por la distribución Ice, lo hace como config/templates.xml, y contiene las plantillas de ayuda para desplegar servicios Ice tales como IcePatch2 y Glacier2. Un fichero plantilla puede tener la siguiente estructura:

Figura 8. Estructura de un Fichero Plantilla

El nombre que se le da a la aplicación no es importante, y tu solo tienes que definir las plantillas de los servidores y servicios de esta. Después de configurar el registro para utilizar este fichero, las plantillas por defecto están disponibles para todas las aplicaciones que las necesiten.

Los descriptores de cada aplicación indican si las plantillas por defecto se pueden importar (por defecto no se puede). Si las plantillas son importadas, es esencial copiarlas dentro de los descriptores de la aplicación y tratarlas como si fueran definidas por la propia aplicación. Como resultado, tenemos que los cambios de los ficheros que contienen las plantillas por defecto, no tienen efecto en los descriptores de la aplicación existentes.

3.3 Integración con IceBox

La configuración de los servidores IceBox para que hospeden uno o más servicios, se hace muy fácilmente con IceGrid.

Descriptores

Un servidor IceBox comparte muchas de las características de otros servidores, pero sus requisitos especiales necesitan de un nuevo descriptor. A diferencia de otros servidores, un servidor IceBox generalmente contiene varios servicios independientes, cada uno con su propia instancia comunicadora y fichero de configuración.

Como ejemplo, la siguiente figura muestra una aplicación despliega un servidor IceBox que contiene un servicio:

Figura 9. Ejemplo de Servidor IceBox

Parece muy parecido al descriptor de un servidor. La diferencia más significativa es el descriptor del servicio, que se construye como un servidor en el que se declaran sus atributos como

adaptadores de objeto y propiedades de configuración. El orden en que los servicios son definidos, determina el orden en el que son cargados por el servidor IceBox.El valor del atributo name del adaptador necesita una explicación adicional. El símbolo service es uno de los nombres reservados por IceGrid. En el contexto de un descriptor de servicio, ${service} se reemplaza por el nombre del servicio, y el adaptador de objeto también se le llama ServiceA.

Plantillas

En IceBox se pueden crear plantillas de servicios y plantillas avanzadas, que son plantillas de servicio dentro de una plantilla de un servidor.

3.4 Duplicación (Replication)

IceGrid soporta duplicación como una implementación del servicio de localización de Ice. Una aplicación define sus grupos replica y sus adaptadores de objeto participantes utilizando descriptores, entonces IceGrid genera la configuración del servidor automáticamente.

Descriptor de un Grupo Replica

El descriptor que define un grupo replica puede opcionalmente declarar objetos bien conocidos y configurar los grupos para determinar su comportamiento durante una solicitud de localización. Veamos un ejemplo:

Figura 10. Ejemplo de Duplicación

El descriptor del adaptador se declara como miembro del grupo replica ReplicatedAdapter, que tiene que haber sido creado previamente por el descriptor del grupo replica. El grupo ReplicatedAdapter declara un objeto bien conocido para que un proxy indirecto de la forma TheObject sea equivalente al proxy indirecto TheObject@ReplicatedAdapter.

Miembros de un Grupo Replica

Para que un adaptador de objeto participe en un grupo replica, tiene que especificar la id del grupo en su propiedad de configuración ReplicaGroupId. Identificando el grupo replica en el descriptor de

IceGrid para un adaptador de objeto causa que el nodo incluya la propiedad ReplicaGroupId equivalente en el fichero de configuración que genera para el servidor.

Por defecto, el registro IceGrid requiere que el miembro de un grupo replica sea definido estáticamente. Cuando se crea un descriptor para un adaptador de objeto que identifica un grupo replica, el registro añade el adaptador a lista de miembros validos del grupo. Durante la activación de un adaptador, en el momento que describe sus endpoints al registro, un adaptador además puede reclamar que los miembros en un grupo replica sean validados mediante la lista interna del registro.

En una plicacion IceGrid bien configurada, este proceso ocurre sin incidentes, pero hay situaciones en las que la validación puede fallar. Por ejemplo, la activación de un adaptador falla si la id del adaptador es cambiada sin informar al registro, esto puede ocurrir si se modifica manualmente el fichero de configuración del servidor que fue generado por el nodo. También es posible que la activación falle cuando el registro IceGrid es utilizado únicamente como un servicio de localización, en cuyo caso los descriptores no han sido creados y además el registro no tiene conocimiento anterior de los grupos replica o de sus miembros. En esta situación, la activación de un adaptador hace que el servidor reciba la excepción NotResteredException a menos que el registro sea configurado para permitir la registración dinámica, que se puede hacer definiendo la siguiente propiedad: IceGrid.Registry.DynamicRegistration = 1.

Con esta configuración, un grupo replica es creado implícitamente tan pronto como un adaptador se declara como miembro del grupo, y cualquier adaptador tiene permiso para participar.

La registración dinámica a con frecuencia causa la acumulación de grupos replica y adaptadores obsoletos en el registro. La herramienta de administración de IceGrid permite inspeccionar y limpiar el estado del registro.

3.5 Balance de Carga

La duplicación es una característica muy importante de IceGrid pero cuando se combina con el balance de carga, la duplicación es más útil. Los nodos IceGrid regularmente informan sobre la carga del sistema de sus hosts al registro. La configuración de un grupo replica determina si el registro considera la carga del sistema cuando decide que endpoint(s) devolver al cliente como respuesta a una solicitud de localización.

El balance de carga IceGrid posibilita la asistencia al cliente durante la selección del endpoint inicial para la conexión, todas las solicitudes siguientes sobre el proxy que inicio la conexión son enviadas al mismo servidor sin consideraciones adicionales sobre el balance de carga.

Configurar un Grupo Replica

Un descriptor de un grupo replica opcionalmente contiene un descriptor de balance de carga que determina como se utiliza la carga de los sistemas en las solicitudes de localización. El descriptor de balance de carga contiene la siguiente información:

Tipo: hay varios tipos de balance de carga soportados. Intervalo de muestreo: uno de los tipos de balance de carga considera las estadísticas de carga

del sistema, que es informada por cada nodo a intervalos regulares. El grupo replica puede especificar el intervalo de muestreo a 1, 5 o 55 minutos.

Número de replicas: el grupo replica puede ordenar al registro que devuelva los endpoints de uno (por defecto) o mar adaptadores de objeto. Si el numero N es mayor de 1, el proxy devuelve como respuesta a una solicitud de localización los endpoints de los N adaptadores de objeto. El entorno de ejecución Ice en el cliente selecciona una de los endpoints a azar.

Como ejemplo, el siguiente descriptor muestra la utilización del balance de carga de tipo adaptativo para devolver los endpoints de los dos adaptadores de objeto menos cargados con un intervalo de muestreo de 5 minutos.

Figura 11. Ejemplo de Utilizacion del Balance de Carga

El tipo de balance de carga hay que especificarlo, pero los atributos restantes son opcionales.

Tipos de Balance de Carga

Un grupo replica puede seleccionar uno de los siguientes tipos de balance de carga:

None (ninguno): Si no se quiere balance de carga, una solicitud de localización recibe los endpoints de todos los adaptadores del grupo. El registro no considera la carga del sistema en este caso.

Random (aleatorio): selecciona un adaptador de objeto de entre los disponibles de forma aleatoria. El registro no considera la carga del sistema de un grupo replica con este tipo.

Adaptative (adaptativo): utiliza la información de carga del sistema para elegir los adaptadores de objeto menos cargados durante ese intervalo de muestreo. Este es el único tipo de carga que utiliza intervalos de muestreo.

Round Robin: devuelve los adaptadores de objeto menos recientemente utilizados. El registro no considera la carga del sistema para un grupo replica con este tipo.

3.6 Distribución de la Aplicación

Cuando se hace referencia a una aplicación utilizando el término “despliegue”, se quiere decir que se han creado los en el registro. Una definición mas amplia requiere otras tares adicionales:

Escribir los ficheros de configuración IceGrid y preparar los directorios de datos en cada computador

Instalar los binarios y las librerías dependientes de IceGrid en cada computador Arrancar el registro y/o el nodo en cada computador, y posiblemente configurar el sistema para

que los lance automáticamente Distribución de los ejecutables de los servidores, librerías dependientes y ficheros de soporte a

los nodos apropiados

Las primeras tres tareas son responsabilidad del administrador del sistema, pero IceGrid puede ayudar con el cuarta tarea. Utilizando un servidor IcePatch2, se puede configurar los nodos para descargar los servidores automáticamente y parchearlas en cualquier momento. La siguiente figura muestra la interacción de los componentes.

Figura 12. Interacción de los Componentes

Como se puede observar, desplegar una aplicación IceGrid tiene una gran significación cuando esta involucrado IcePatch2. Después del despliegue, la herramienta administrativa inicia el parcheado, lo que causa que el registro notifique a todos los nodos activos que están configurados para la distribución de la aplicación que comiencen el proceso de parcheado. Cada nodo IceGrid es un cliente IcePatch2, el nodo realiza el parcheo como cualquier otro cliente IcePatch2: se descarga todo si no existe una copia local de la distribución, de lo contrario, realiza un parcheo incremental en el que solo se descarga los nuevos ficheros y de quienes las firmas hayan cambiado.

Los beneficios que conlleva son claros: Los archivos de la distribución se mantienen en una localizacion central Actualizar una distribución en todos los nodos es una manera sencilla de preparar la distribución

maestra y permitir que IceGrid haga el resto La transferencia manual de ejecutables y ficheros de soporte a cada computador es evitable,

junto con los errores que la intervención manual a veces introduce.

Desplegando un Servidor IcePatch2

Si utiliza se utilizan las habilidades de distribución de IceGrid, se recomienda utilizar servidores IcePatch2 junto con la aplicación. Proporcionan los mismos beneficios que cualquier otro servidor IceGrid, incluyendo la activación bajo demanda y administración remota. En aplicaciones que necesitan una distribución muy grande, se pueden replicar varios servidores IcePatch2 para balancear la carga.

Consideraciones del parcheado

Desplegar y parchear se tratan de cómo dos pasos separados: el primer paso es desplegar la aplicación, después se inicia el proceso de parcheado. Los servidores IcePatch2 y los ficheros de soporte son distribuidos por el administrador del sistema junto con el registro IceGrid y los nodos a los computadores apropiados. El servidor es configurado para activación bajo demanda para que su nodo se inicie automáticamente cuando comienza el parcheado. Si el servidor se configura para activación manual, se debe de iniciar antes de comenzar el parcheado.

Plantilla del Servidor

La distribución Ice incluye una plantilla de servidor IcePatch2 que simplifica la inclusión de IcePatch2 en la aplicación. La siguiente figura muestra una parte relevante de fichero config/templates.xml:

Figura 13. Plantilla de Servidor IcePatch2

La ruta del servidor es icepatch2server, es decir, que el programa es presentado en la ruta de búsqueda del ejecutable del nodo. El único parámetro obligatorio es directory, que especifica el directorio de datos del servidor y conoce el valor de la propiedad IcePatch2.Directory. El valor del parámetro instance-name es utilizado como el identificador del servidor cuando se instancia la plantilla; su valor por defecto incluye el nombre de la aplicación en la que la plantilla es instanciada. Este identificador también afecta a dos objetos bien conocidos declaraos por el servidor.

Consideremos el siguiente ejemplo:

Figura 14. Ejemplo de Instanciación con Plantilla

Este ejemplo instancia la plantilla IcePatch2 para crear un servidor identificado como PatchDemo.IcePatch2. Los objetos bien conocidos utilizan este valor como la categoría en sus identificadores, tal como PatchDemo.IcePatch2/server.

Para poder utilizar la plantilla en las aplicaciones, el registro debe de estar configurado para utilizar el fichero config/templates.xml como la plantilla por defecto o copiar la plantilla dentro del fichero XML que describe la aplicación.

Descriptor de Distribución

Proporciona los detalles que necesitan los nodos para poder descargar los ficheros necesarios. El descriptor proporciona el Proxy del servidor IcePatch2 y los nombres de los subdirectorios

comprendidos en la distribución, todos son opcionales. Si el descriptor no proporciona el proxy, entonces el valor por defecto es:

${application}.IcePathc2/server

Este es un proxy indirecto, lo que implica que el servidor es desplegado con la aplicación y puede ser iniciado bajo demanda si es necesario. Si el descriptor no selecciona ningún subdirectorio, entonces el nodo descarga el contenido del directorio de datos IcePatch2.

En XML, un descriptor tiene un comportamiento por defecto que describe como es escrito <distrib/>, para especificar un Proxy se utiliza el atributo icepatch:

<distrib icepatch=”PatchDemo.IcePatch2/Server”/>

Finalmente, se seleccionan subdirectorios con el siguiente elemento:

<distrib><directory>dir1</directory><directory>dir2/subdir</directory>

</distrib>

Si se incluyen solo algunos subdirectorios en la distribución, se pueden minimizar el tiempo y el esfuerzo necesario para descargar el parche en cada nodo.

Distribución del Servidor y la Aplicación

El descriptor de distribución puede ser utilizado en dos contextos: aplicación y servidor. Cuando aparece a nivel de aplicaron, significa que todos los nodos de la aplicación descargan la distribución. Esto es útil para la distribución de los ficheros necesarios por todos los nodos en los que los servidores son desplegados, específicamente en un entrelazado (grid) de computadoras heterogéneas, donde es muy tedioso repetir la misma información de distribución en cada descriptor de un servidor. El siguiente es un ejemplo simple en XML:

<icegrid><aplication name=”PatchDemo”>

<distrib><directory> Common</directory>

</distrib>…

</application></icegrid>

A nivel de servidor, el descriptor de distribución descarga los directorios especificados para un uso privado del servidor:

<icegrid> <application name="PatchDemo">

<distrib> <directory>Common</directory>

</distrib> <node name="Node">

<server id="SimpleServer" ...> <distrib>

<directory>ServerFiles</directory> </distrib>

</server> </node>

</application> </icegrid>

Cuando un descriptor de distribución es definido para ambos niveles, aplicación y distribución, conjuntamente, como se ha mostrado en el ejemplo anterior, IceGrid asume que una relación de dependencia existe entre los dos, a no ser que el servidor sea configurado de otra forma. IceGrid chequea la dependencia antes de parchear el servidor, si el servidor depende de la distribución del servidor, IceGrid parchea primero la distribución de la aplicación, y después parchea la distribución del servidor. Se puede desactivar esta dependencia modificando el descriptor del servidor, configurando el atributo application-distrib con el valor false para informar a IceGrid que las distribuciones son independientes, como muestra el ejemplo siguiente:

<icegrid> <application name="PatchDemo">

<distrib> <directory>Common</directory>

</distrib> <node name="Node">

<server id="SimpleServer" application-distrib="false" ...> <distrib>

<directory>ServerFiles</directory> </distrib>

</server> </node>

</application> </icegrid>

Integridad del Servidor

Antes de que un nodo IceGrid comience a parchear la distribución, este se asegura que todos los servidores relevantes están cerrados (shut down) y les previene para que no se reactiven hasta que se complete el parcheo. Por ejemplo, un nodo desactiva todos los servidores donde sus descriptores declaren una dependencia con la distribución de la aplicación.

Utilización de las Distribuciones

Los nodos almacenan la distribución de la aplicación y de los servidores en su directorio de datos. La ruta de la distribución esta representada por variables reservadas que se pueden utilizar en sus descriptores. aplication.distrib: se utiliza junto al descriptor del servidor para referir al directorio de más alto

nivel de la distribución de la aplicación. server.distrib: contiene el valor del directorio de más alto nivel en la distribución del servidor.

Solo se puede utilizar junto al descriptor del servidor que tiene la distribución.

La siguiente figura muestra un ejemplo de utilización de ambas variables:

Figura 15. Ejemplo de Utilización de las Variables de Distribución

El descriptor para el Server2 proporciona el directorio de distribución del servidor como una opción de la línea de comandos.

3.7 Integración con Glaciar

Este apartado proporciona información para integrar un router Glacier2 en un entorno IceGrid.

Requisitos de Configuración

Un cliente IceGrid típico, puede ser configurado con un proxy localizador, pero los requisitos de configuración cambian cuando el cliente accede indirectamente al servicio de localización mediante un router Glacier2, como muestra la siguiente figura:

Figura 16. Utilización de IceGrid por medio de un Router Glacier2

En esta situación, es el router el que debe de ser configurado como un proxy localizador. Se asume que el endpoint del cliente en el registro utiliza el puerto 8000, el router necesita la siguiente propiedad de configuración:

Ice.Default.Locator=IceGrid/Locutor:tcp –h 10.0.0.2 –p 8000

El nodo es el encargado de proporcionar esta propiedad cuando inicia el router, para que no sea necesario configurarlo explícitamente. Hay que indicar que todos los clientes del router utilizan el mismo localizador.

Si se tiene la intención de administrar remotamente IceGrid mediante un router Glacier2, se necesita definir una propiedad adicional:

Glacier2.SessionManager=IceGrid/SessionManager

Un router solo puede tener un gestor de sesión. Si la aplicación necesita utilizar su propio gestor de sesión, es necesario desplegar un router extra destinado únicamente a los clientes administrativos IceGrid.

Desplegar un Router

La distribución Ice incluye una plantilla de servidor por defecto para servicios Ice tales como IcePatch2 y Glacier2, que simplifica la tarea de desplegar estos servidores en el dominio IceGrid. Un parte relevante del fichero config/template.xml se muestra a continuación:

Figura 17. Parte del Fichero config/template.xml

Hay que destacar que la ruta del servidor es glacier2router, es decir, el programa debe de estar presente el la ruta de búsqueda del ejecutable del nodo. Otro punto importante es el modo de activación del servidor: este utiliza la activación manual (por defecto), es decir, el router debe de iniciarse manualmente. Hay que considerar que el router es el punto de contacto para clientes remotos; si el router no esta funcionando, no hay forma de que los clientes contacten con el localizador y causar que el router se inicie bajo demanda.

Un router Glacier2 posee una plantilla de configuración, de los parámetros que contiene los más interesantes son, por ejemplo, el parámetro instante-name, que permite configurar la propiedad Glacer2.InstanceName. El valor por defecto de este parámetro incluye el nombre de la aplicación

que utiliza la plantilla. Este parámetro también afecta a las identidades de los objetos implementados por el router, veamos el siguiente ejemplo:

<icegrid> <application name="Glacier2Demo">

<node name="Node"> <server-instance template="Glacier2"

client-endpoints="tcp -h 5.6.7.8 -p 8000"session-timeout="300"server-endpoints="tcp -h 10.0.0.1"/>

...</node>

</application></icegrid>

Al instanciar la plantilla Glacier2 se crea un identificador de servidor llamado Glacier2Demo.Glacier2 (que es determinado como valor por defecto para el parámetro instante-name). Los objetos del router utilizan este valor como la categoría en sus identidades como Glacier2Demo.Glacier2/router. El router proxy utilizado por los clientes debe contener una identidad que concuerde.

Para poder hacer referencia a una plantilla Glacier2 en las aplicaciones, se debe tener anteriormente configurado el registro para utilizar el fichero config/templates.xml como plantilla por defecto o copiar la plantilla en el fichero XML que describe la aplicación.

3.8 Activación de Servidor

La activación de un servidor bajo demanda es una característica valorada en las arquitecturas de computación distribuida por varias razones:

Minimiza el tiempo de arranque de la aplicación, evitando la necesidad de pre-iniciar todos los servidores.

Permite a los administradores usar los recursos computacionales más eficientemente porque solo los servidores que actualmente se necesitan funcionan.

Proporciona más fiabilidad en el caso de algunos escenarios de fallo del servidor, por ejemplo, el servidor es reactivado después de un fallo y todavía es capaz de proporcionar algunos servicios a los clientes hasta que el fallo es resuelto.

Permite la activación y desactivación remota.

La Activación al Detalle

La activación se produce cuando un cliente Ice solicita el endpoint de uno de los adaptadores de objeto del servidor mediante un solicitud de localización. Si el servidor no esta activo en ese momento, el cliente publica la solicitud, el nodo activa el servidor y espera al adaptador objeto objetivo para registrar sus endpoints. Una vez que los endpoints del adaptador de objeto están registrados, el registro devuelve la información del endpoint al cliente. Esta secuencia asegura que el cliente revive la información del endpoint después de que el servidor este listo para recibir solicitudes.

Para poder utilizar la activación bajo demanda sobre un adaptador de objeto, el adaptador debe tener un identificador y debe estar en el registro IceGrid.

Eficiencia

Una vez que el servidor esta activado, permanece en ejecución permanentemente. Un nodo desactiva a un servidor cuando lo solicita explícitamente, como resultado, los procesos del servidor tienden a acumularse sobre el nodo que los hospeda.

Una de las ventajas de la activación bajo demanda es ka posibilidad de gestionar los recursos computacionales más eficientemente. Por supuesto hay muchos aspectos involucrados, pero Ice utiliza una técnica particular muy simple: los servidores pueden ser configurados para terminar elegantemente después de que hayan estado parados durante cierto tiempo.

Un escenario habitual es en el que un servidor para automáticamente cuando no ha recibido solicitudes durante un número configurable de segundos. Todo lo que hace falta es establecer la propiedad de configuración de servidor Ice.ServerIdleTime a la cantidad de tiempo deseada.

Registro de Endpoint

En este apartado se explican los requisitos de configuración para activar el registro automático de endpoint en un servidor. IceGrid simplifica el proceso de configuración de dos formas:

1. Un servidor que es activado automáticamente por un nodo IceGrid no necesita configurar explícitamente un proxy para el localizador porque el nodo IceGrid lo define en la línea de comandos del servidor.

2. El mecanismo de despliegue de IceGrid automatiza la creación de un fichero de configuración para el servidor, incluyendo la definición de los identificadores y los endpoints de los adaptadores de objeto.

4. Ejemplo

El ejemplo es el típico HolaMundo para Java. Para poder construir la aplicación necesitamos el Java SDK 1.4.2 o superior y Apache Ant 1.6.3 o superior, que se pueden obtener de:

http://java.sun.com/j2se/index.jsphttp://ant.apache.org/bindownload.cgi

El directorio bin de Ant debe de añadirse a la variable de entorno PATH, y hay que definir las siguientes variables de entonro:

set JAVA_HOME=<Java SDK installation root directory>set ICE_HOME=<Ice installation root directory>set PATH=%ICE_HOME%\bin;%PATH%

Se puede construir la aplicación ejecutando Ant en el directorio donde se encentran los archivos fuente, pero antes de ejecutar la aplicación hay que modificar el CLASSPATH de la siguiente forma: set CLASSPATH=%ICE_HOME%\lib\Ice.jar;%ICE_HOME%\lib\db.jar;classes;%CLASSPATH%

Hay que añadir, que la JVM necesita el directorio que contiene las librerias Berkeley DBque se lista en java.library.path, por tanto el directorio bin de Ice debe de estar en PATH para poder ejecutar las aplicaciones que dependen del componente Ice Freeze.

4.1 Código

A continuación se muestra el código en lenguaje Slice, su equivalente Java, el codigo para clientes y servidores y los descriptores en XML.

Código en Lenguaje Slice

#ifndef HELLO_ICE#define HELLO_ICE

module Demo{

interface Hello{ nonmutating void sayHello(); idempotent void shutdown();};

};

#endif

Archivo de Configuración

IceGrid.InstanceName=DemoIceGrid

## The IceGrid locator proxy.#Ice.Default.Locator=DemoIceGrid/Locator:default -p 12000

## IceGrid registry configuration.#IceGrid.Registry.Client.Endpoints=default -p 12000IceGrid.Registry.Server.Endpoints=defaultIceGrid.Registry.Internal.Endpoints=defaultIceGrid.Registry.Admin.Endpoints=defaultIceGrid.Registry.Data=db/registry

## IceGrid node configuration.#IceGrid.Node.Name=localhostIceGrid.Node.Endpoints=defaultIceGrid.Node.Data=db/nodeIceGrid.Node.CollocateRegistry=1#IceGrid.Node.Output=db#IceGrid.Node.RedirectErrToOut=1

## Trace properties.#IceGrid.Node.Trace.Activator=1IceGrid.Node.Trace.Patch=1#IceGrid.Node.Trace.Adapter=2#IceGrid.Node.Trace.Server=3

Identificador de la Aplicación

<icegrid> <application name="Simple"> <node name="localhost"> <server id="SimpleServer" exe="java" activation="on-demand"> <option>Server</option>

<adapter name="Hello" endpoints="tcp" register-process="true"> <object identity="hello" type="::Demo::Hello"/></adapter><property name="Identity" value="hello"/>

</server> </node> </application></icegrid>

Codigo Java

Servant

import Demo.*;

public class HelloI extends _HelloDisp{ public HelloI(String name) {

_name = name; }

public void sayHello(Ice.Current current) { System.out.println(_name + " says Hello World!"); }

public void shutdown(Ice.Current current) { System.out.println(_name + " shutting down..."); current.adapter.getCommunicator().shutdown(); }

private final String _name;}

Clienteimport Demo.*;

public class Client extends Ice.Application{ private void menu() { System.out.println( "usage:\n" + "t: send greeting\n" + "s: shutdown server\n" + "x: exit\n" + "?: help\n"); }

public int run(String[] args) {

//// First we try to connect to the object with the `hello'// identity. If it's not registered with the registry, we// search for an object with the ::Demo::Hello type.//HelloPrx hello = null;try{ hello = HelloPrxHelper.checkedCast(communicator().stringToProxy("hello"));}catch(Ice.NotRegisteredException ex){ final String proxy = communicator().getProperties().getProperty("IceGrid.InstanceName") +

"/Query"; IceGrid.QueryPrx query = IceGrid.QueryPrxHelper.checkedCast(

communicator().stringToProxy(proxy)); hello = HelloPrxHelper.checkedCast(query.findObjectByType("::Demo::Hello"));}if(hello == null){

System.err.println(": couldn't find a `::Demo::Hello' object");

return 1;}

menu();

java.io.BufferedReader in = new java.io.BufferedReader(new java.io.InputStreamReader(System.in));

String line = null; do { try { System.out.print("==> "); System.out.flush(); line = in.readLine(); if(line == null) { break; } if(line.equals("t")) { hello.sayHello(); } else if(line.equals("s")) { hello.shutdown(); } else if(line.equals("x")) { // Nothing to do } else if(line.equals("?")) { menu(); } else { System.out.println("unknown command `" + line + "'"); menu(); } } catch(java.io.IOException ex) { ex.printStackTrace(); } catch(Ice.LocalException ex) { ex.printStackTrace(); } } while(!line.equals("x"));

return 0; }

public static void main(String[] args) {

Client app = new Client();int status = app.main("Client", args, "config");System.exit(status);

}}

Servidor

public class Server extends Ice.Application{ public int run(String[] args) { Ice.ObjectAdapter adapter = communicator().createObjectAdapter("Hello");

Ice.Properties properties = communicator().getProperties();Ice.Identity id = Ice.Util.stringToIdentity(properties.getProperty("Identity"));

adapter.add(new HelloI(properties.getProperty("Ice.ServerId")), id);

adapter.activate(); communicator().waitForShutdown(); return 0; }

static public void main(String[] args) {

Server app = new Server();int status = app.main("Server", args);System.exit(status);

}}

Descriptor para Utilización de Duplicación

<icegrid> <application name="Simple"> <server-template id="SimpleServer"> <parameter name="index"/> <server id="SimpleServer-${index}" exe="java" activation="on-demand"> <option>Server</option> <adapter name="Hello" endpoints="tcp" register-process="true"

replica-group="ReplicatedHelloAdapter"/> <property name="Identity" value="hello"/> </server> </server-template> <replica-group id="ReplicatedHelloAdapter"> <load-balancing type="round-robin"/> <object identity="hello" type="::Demo::Hello"/> </replica-group>

<node name="localhost"> <server-instance template="SimpleServer" index="1"/> <server-instance template="SimpleServer" index="2"/> <server-instance template="SimpleServer" index="3"/> </node> </application></icegrid>

Descriptor para Utilización de Plantilla

<icegrid> <application name="Simple">

<server-template id="SimpleServer"> <parameter name="index"/> <server id="SimpleServer-${index}" exe="java" activation="on-demand"> <option>Server</option> <adapter name="Hello" endpoints="tcp" register-process="true"> <object identity="hello-${index}" type="::Demo::Hello"/> </adapter>

<property name="Identity" value="hello-${index}"/> </server> </server-template>

<node name="localhost"> <server-instance template="SimpleServer" index="1"/> <server-instance template="SimpleServer" index="2"/> <server-instance template="SimpleServer" index="3"/> </node>

</application></icegrid>

4.3 Ejecutando IceGrid

Una vez que el fichero de configuración esta escrito y la estructura de directorios preparada, se esta preparado para iniciar el registro y nodo Icegrid. Para utilizar un registro y nodo colocado, solo necesitamos usar un comando:

$ icegridnode --Ice.Config=config –warn

Hay otras opciones de línea de comandos soportadas, además de esta, para permitir que un nodo se ejecute como un servicio Windows o demonio Unix.

Cuando el registro esta activo y funcionando, es el momento de desplegar la aplicación. Como nuestro cliente, la utilidad icegridadmin permite definir la propiedad Ice.Default.Locator. Se puede iniciar la utilidad con el siguiente comando en una ventana diferente:

$ icegridadmin --Ice.Config=config -e "application add 'application.xml'"$ java Client

Esto desplegara la aplicación descrita en el fichero “application.xml” e inicia el cliente. Los mensajes se mostraran en la pantalla del servicio IceGrid.

Tambien se pueden usar los descriptote de los siguientes ficheros para desplegar la aplicación:

- application_with_template.xml: Este descriptor se utiliza para demostrar el uso de las plantillas para la definición del servidor. Las plantillas permiten desplegar varias instancias de un mismo servidor fácilmente.

- application_with_replication.xml: Este descriptor se utiliza para mostrar la replicación y el balanceo de la carga de la aplicación sobre varios servidores.

Para utilizar estos ejemplos utilizaremos las siguientes llamadas:

$ icegridadmin --Ice.Config=config -e "application add 'application_with_template.xml'"

o

$ icegridadmin --Ice.Config=config -e "server template instantiate Simple localhost SimpleServer index=4"