Un servicio de movilidad de agentes de software para …materias.fi.uba.ar/7500/SanMartin.pdf · tradicionales como pueden ser aquellos basados en ... que cumpla con los objetivos

Un servicio de movilidad de agentes de software para JADE basado en OSGi

Tesis de Grado de Ingeniería en InformáticaOrientación en Sistemas Distribuidos

TesistaMatías I. San Martín

DirectorProf. Ing. Osvaldo Clúa

Facultad de IngenieríaUniversidad de Buenos Aires

Año 2012

San Martín, Matías Ignacio

I

“Lo haremos... no porque sea fácil, sino porque es difícil”

J. F. Kennedy

(Presidente de los Estados Unidos de América, respecto del proceso que finalmente llevaría al hombre a la Luna)


Resumen

El paradigma de agentes móviles de software define entidades (los agentes) capaces de moverse entre distintos lugares de una red, de forma autónoma y en busca del cumplimiento de sus objetivos particulares. El hecho de contar con estos agentes, capaces de acercarse a los recursos que deben utilizar y de desplazarse a otro sitio cuando así lo requieran, ofrece grandes ventajas frente a paradigmas más tradicionales como pueden ser aquellos basados en arquitecturas del tipo cliente-servidor; siendo particularmente destacables: el ahorro en la transmisión de datos y la prevención de latencias.

Para permitir la ejecución de los agentes de software y ofrecer un conjunto de servicios básicos, es necesario una plataforma de ejecución. JADE (Java Agent DEvelopment Framework) ofrece dicha plataforma y, además, un conjunto de herramientas que posibilitan el desarrollo de los agentes que se ejecutarán en ella. Entre todas las tecnologías de este tipo, JADE resalta por su trayectoria, comunidad creciente y por el hecho de estar liberada bajo una licencia de código abierto (LGPL).

A pesar de contar con años de desarrollo y uso en su haber, JADE es un proyecto todavía en evolución y con posibilidad de mejoras. En particular, en el presente trabajo se propone una nueva versión de un componente de la plataforma (servicio de movilidad); nueva versión que tiene como objetivo permitir la movilidad de los agentes de forma más eficiente y robusta, apuntando a prevenir incoherencias en la definición de los mismos y la transmisión innecesaria de datos.

Para lograr el objetivo descripto, la solución se valió de otra tecnología con madurez y en crecimiento, OSGi, que se enfoca en facilitar la definición de las aplicaciones en forma de componentes reutilizables y dinámicos. Las bondades de esta permitirán llegar a una solución simple y robusta, que cumpla con los objetivos establecidos.

En los primeros capítulos de este trabajo se desarrolla una introducción a los conceptos y tecnologías que dan marco al desarrollo del mismo. Empezando por el paradigma de los agentes móviles de software (capítulo 1), para luego seguir con JADE (capítulo 2) y completar con OSGi (capítulo 3). Luego, se hace un análisis de las limitaciones encontradas en JADE y que busca compensar la solución propuesta en esta obra (capítulo 4). Con esto se da introducción al análisis del contexto, tecnologías y restricciones tenidas en cuenta en el desarrollo de la solución (capítulo 5) y, finalmente, se presenta el prototipo implementado con objeto de verificar la propuesta (capítulo 6 y 7). Este es comparado con la funcionalidad ofrecida por JADE en un conjunto de pruebas cuyos resultados son presentados en el capítulo 8. Se da cierre a esta tesis con una recapitulación en forma de conclusiones de lo

II


presentado, y una descripción de contenidos complementarios al presente; conformados por el inventario de trabajos relacionados, la descripción de una alternativa a la solución expuesta, y la propuesta de ideas para la evolución de lo aquí ofrecido (capítulo 9).

III


Abstract

The mobile software agents paradigm defines entities (agents) capable of moving autonomously among places in a network and following their own agenda. Having these agents, who are able to go closer to the resources necessary to accomplish their goals and of moving elsewhere when needed, offers great advantages over more traditional paradigms such as those based on client-server architectures. In particular, it can be mentioned the savings in data transmission and latency avoidance.

To allow the execution of software agents and to offer them a set of basic services, an execution platform is needed. JADE (Java Agent Development Framework) provides such a platform and, also, a framework for developing the agents that can be executed by it. JADE stands out from others because of its history, growing community and the fact of being released under an open source license (LGPL).

Despite having many years of development and use to its credit, JADE is still an in-progress project and has many features that can be developed or improved. In this work, a new version of an existing component (agent mobility service) is proposed, aiming for a more efficient and robust functionality, trying to avoid inconsistencies in the agent's definitions and preventing unnecessary data transmission.

To achieve the described objective, another mature and growing technology was used, OSGi, which focuses on facilitating the componentization of software modules and applications. The benefits provided by this technology will make it possible to build a simple and robust solution that meets the objectives set.

At the beginning of this work some concepts and technologies are introduced to give some context. First, the mobile software agents paradigm is described (in chapter 1), following with JADE (chapter 2) and the introduction is completed with OSGi (chapter 3). After that, (in chapter 4) the limitations found in JADE are described (focusing in the ones concerned by this work). This will serve as introduction for the study of the context, technologies and restrictions taken into account when developing the solution (chapter 5), to finally lead to the presentation of the prototype implemented to test the proposal (chapters 6 and 7). This prototype is later compared against the service offered by default in JADE through a set of tests cases from which the results are detailed in chapter 8. Finally this thesis is ended with some conclusions about the information presented and a complementary description of related work, an alternative solution to the one given, and some ideas for further work that can be made (chapter 9).

IV


Agradecimientos

A mis padres por haber invertido en mi educación y por su apoyo a lo largo de toda mi vida.

A Silvina por su infinito amor y paciencia.

A mi tutor, Osvaldo Clúa, por haber sabido guiarme en el desarrollo de este proyecto.

A todos los que durante este tiempo me brindaron su apoyo y compañía, y me motivaron a seguir y cumplir mis objetivos.

V


Índice de Contenido

Resumen --------------------------------------------------------------------------------------------------------------IIAbstract --------------------------------------------------------------------------------------------------------------IVAgradecimientos ----------------------------------------------------------------------------------------------------VÍndice de Ilustraciones --------------------------------------------------------------------------------------------XÍndice de Tablas ---------------------------------------------------------------------------------------------------XICapítulo 1: Introducción a los agentes móviles de software --------------------------------------------1

1.1 -Definición de agentes -----------------------------------------------------------------------------------11.1.1 -Agente de software -------------------------------------------------------------------------------11.1.2 -Agente móvil ----------------------------------------------------------------------------------------2

1.2 -Características de los agentes móviles de software --------------------------------------------31.2.1 -Ventajas “heredadas” de los agentes de software ----------------------------------------31.2.2 -Ventajas asociadas a la movilidad ------------------------------------------------------------41.2.3 -Dificultades asociadas a los agentes móviles ---------------------------------------------5

1.3 -Aspectos técnicos asociados con la tecnología de agentes móviles de software ------51.3.1 -Aspectos técnicos propios del agente -------------------------------------------------------51.3.2 -Aspectos técnicos propios de la plataforma de ejecución ------------------------------61.3.3 -Aspectos técnicos propios de la ejecución del agente ----------------------------------6

Requerimiento de única ejecución (exactly-once) --------------------------------------------6Detección de casos de excepción -----------------------------------------------------------------7

1.3.4 -Aspectos técnicos de la comunicación ------------------------------------------------------8Problemas por ser distribuidos ---------------------------------------------------------------------8Problemas por movilidad -----------------------------------------------------------------------------9

1.3.5 -Aspectos técnicos relacionados con la seguridad ----------------------------------------9Capítulo 2: Plataforma JADE para el desarrollo de agentes móviles de software ---------------11

2.1 -Antecedente histórico ----------------------------------------------------------------------------------112.2 -Características de JADE ------------------------------------------------------------------------------12

2.2.1 -Componentes -------------------------------------------------------------------------------------122.2.2 -Arquitectura ----------------------------------------------------------------------------------------122.2.3 -Protocolo de comunicación entre contenedores -----------------------------------------142.2.4 -Agentes ---------------------------------------------------------------------------------------------14

Implementación de agentes -----------------------------------------------------------------------14Comunicación entre agentes ----------------------------------------------------------------------15

2.3 -FIPA --------------------------------------------------------------------------------------------------------162.3.1 -Especificación de arquitectura abstracta -------------------------------------------------162.3.2 -Especificación de administración de agentes --------------------------------------------172.3.3 -Especificación del servicio de transporte de mensajes de agentes ----------------18

Capítulo 3: OSGi: un sistema de componentes dinámicos para Java ------------------------------203.1 -Introducción a OSGi -----------------------------------------------------------------------------------203.2 -ClassLoaders de Java ---------------------------------------------------------------------------------20

3.2.1 -Objetivos de la arquitectura de Class Loaders -------------------------------------------213.2.2 -Reglas de los Class Loaders -----------------------------------------------------------------223.2.3 -Dificultades en el uso de los class loaders ------------------------------------------------23

Class loaders concurrentes -----------------------------------------------------------------------23

VI


Las clases homónimas en distintos class loaders no son la misma clase ------------23Perdidas de memoria significativas -------------------------------------------------------------24La regla de delegación puede romperse (Context Class Loader) -----------------------24

3.3 -Introducción a OSGi y sus conceptos principales ----------------------------------------------243.4 -Limites de la modularidad en la plataforma Java ----------------------------------------------26

3.4.1 -Soporte para la definición de interfaces exportadas ------------------------------------263.4.2 -Soporte para la definición de interfaces importadas ------------------------------------273.4.3 -Soporte para el despliegue y mantenimiento de las aplicaciones ------------------27

3.5 -Capas de OSGi -----------------------------------------------------------------------------------------283.5.1 -Capa de módulos (Module Layer) -----------------------------------------------------------283.5.2 -Capa de ciclo de vida (Lifecycle Layer) ----------------------------------------------------283.5.3 -Capa de servicios (Service Layer) ----------------------------------------------------------30

3.6 -Relación de OSGi con el paradigma de agentes móviles de software -------------------313.6.1 -Modularidad ---------------------------------------------------------------------------------------313.6.2 -Dinamismo -----------------------------------------------------------------------------------------323.6.3 -Control de dependencias ----------------------------------------------------------------------323.6.4 -Portabilidad ---------------------------------------------------------------------------------------32

Capítulo 4: Servicio de movilidad en JADE ----------------------------------------------------------------334.1 -Introducción a los servicios de movilidad de JADE --------------------------------------------334.2 -Servicio de movilidad intra-plataforma ------------------------------------------------------------33

4.2.1 -Generalidades ------------------------------------------------------------------------------------334.2.2 -Implementación actual --------------------------------------------------------------------------33

4.3 -Servicio de movilidad inter-plataforma ------------------------------------------------------------364.3.1 -Generalidades ------------------------------------------------------------------------------------364.3.2 -Implementación actual --------------------------------------------------------------------------36

4.4 -Limitaciones en el servicio de movilidad (intra-plataforma) ---------------------------------404.4.1 -Dificultad 1 – No se puede actualizar el agente -----------------------------------------404.4.2 -Dificultad 2 – Transmisión innecesaria de las clases ----------------------------------40

4.5 -Servicio de movilidad inter-plataforma -----------------------------------------------------------41Capítulo 5: OSGi para potenciar a JADE, propuesta de solución -----------------------------------42

5.1 -Pre-análisis de solución -------------------------------------------------------------------------------425.2 -Solución propuesta -------------------------------------------------------------------------------------425.3 -Pre-requisitos para la solución ----------------------------------------------------------------------42

5.3.1 -Requisito de no modificar el núcleo de JADE --------------------------------------------435.3.2 -Requisito de transparencia en el uso -------------------------------------------------------43

5.4 -Decisiones de diseño ----------------------------------------------------------------------------------435.4.1 -Integración del framework de OSGi y JADE ----------------------------------------------44

Alternativa 1 – OSGi y JADE en paralelo ------------------------------------------------------44Alternativa 2 – JADE sobre OSGi ----------------------------------------------------------------45Alternativa 3 – OSGi empotrado en JADE ----------------------------------------------------46

5.4.2 -Determinación de que bundles son necesarios para los agentes ------------------47Resolución de dependencias dadas las asociaciones en el origen --------------------47Resolución de dependencias mediante heurística de análisis de encabezados ----47Resolución de dependencias con OSGi Bundle Repository (OBR) --------------------48

5.4.3 -Transferencia de datos entre contenedores de la migración -------------------------495.4.4 -Soporte para migración de agentes no empaquetados en bundles ----------------495.4.5 -Mantenimiento de distintas versiones de un mismo bundle o actualización -----49

VII


Capítulo 6: Implementación del servicio de movilidad basado en OSGi para JADE ------------516.1 -Desarrollo del prototipo -------------------------------------------------------------------------------51

6.1.1 -Tecnologías usadas -----------------------------------------------------------------------------516.1.2 -Acceso al prototipo ------------------------------------------------------------------------------52

6.2 -Detalle del prototipo de solución --------------------------------------------------------------------526.2.1 -Servicio de movilidad basado en OSGi ----------------------------------------------------526.2.2 -Comunicación entre contenedores de JADE ---------------------------------------------536.2.3 -Resolución de dependencias necesarias para la migración -------------------------54

Bundle para la transmisión de recursos --------------------------------------------------------54Bundle para la recepción de recursos ----------------------------------------------------------54Bundle para la resolución y pedido de dependencias --------------------------------------55Bundle para el envío de dependencias --------------------------------------------------------55

6.3 -Dificultades en la implementación de la solución ----------------------------------------------566.3.1 -El núcleo de JADE depende del servicio de movilidad y de su interfaz -----------566.3.2 -OBR no estandarizado -------------------------------------------------------------------------586.3.3 -OBR usa solo repositorios basados en XML ---------------------------------------------58

6.4 -Facilidades en la implementación de la solución -----------------------------------------------596.4.1 -Arquitectura modular de JADE ---------------------------------------------------------------596.4.2 -Mecanismo de carga de clases con propiedades específicas ----------------------596.4.3 -Arquitectura de composition filters ----------------------------------------------------------596.4.4 -Capacidad de empotrar un framework OSGi ---------------------------------------------606.4.5 -OSGi administra sus class loaders sin imponer restricciones sobre los demás 60

Capítulo 7: Funcionamiento del prototipo implementado -----------------------------------------------617.1 - Soluciones a las limitaciones del servicio de movilidad de JADE ------------------------61

7.1.1 -Solución a la dificultad 1 – Posibilidad de actualizar el agente ----------------------617.1.2 -Solución a la dificultad 2 – Solo se transmiten los componentes que no estén presentes en destino ------------------------------------------------------------------------------------61

7.2 -Ventajas adicionales de la solución propuesta -------------------------------------------------627.2.1 -Capacidad de definir requerimientos que no son clases ------------------------------627.2.2 -Funcionalidad dinámica de un agente basada en dependencias opcionales ----637.2.3 -Posibilidad de uso de capa de servicios de OSGi --------------------------------------637.2.4 -Solución como punto inicial para implementar JADE sobre OSGi ------------------63

Capítulo 8: Desempeño del prototipo de solución propuesta -----------------------------------------648.1 -Objetivo de las pruebas -------------------------------------------------------------------------------648.2 -Entorno de pruebas ------------------------------------------------------------------------------------648.3 -Pruebas realizadas -------------------------------------------------------------------------------------64

8.3.1 -Detalle de las pruebas realizadas -----------------------------------------------------------658.3.2 -Sobre las mediciones ---------------------------------------------------------------------------66

8.4 -Resultados ------------------------------------------------------------------------------------------------668.4.1 -Sobre los resultados expuestos --------------------------------------------------------------668.4.2 -Análisis de resultados --------------------------------------------------------------------------67

Caso 1 ---------------------------------------------------------------------------------------------------67Caso 2 ---------------------------------------------------------------------------------------------------70Caso 3 ---------------------------------------------------------------------------------------------------72Caso 4 ---------------------------------------------------------------------------------------------------73Caso 1 con máximos valores medidos ---------------------------------------------------------75

8.5 -Conclusiones ---------------------------------------------------------------------------------------------76

VIII


Capítulo 9: Conclusiones ---------------------------------------------------------------------------------------789.1 -Trabajo relacionado y alternativa a la solución propuesta -----------------------------------79

9.1.1 -Plug-in OSGi para JADE -----------------------------------------------------------------------799.1.2 -Servicio de movilidad inter-plataforma -----------------------------------------------------809.1.3 -Solución alternativa mediante uso explícito de class loaders ------------------------81

9.2 -Trabajo futuro e ideas ---------------------------------------------------------------------------------839.2.1 -Uso de repositorio de recursos estandarizado -------------------------------------------839.2.2 -Modularizar JADE a partir de OSGi ---------------------------------------------------------839.2.3 -Uso de los mecanismos de seguridad ofrecidos por OSGi ---------------------------83

Introducción al modelo de seguridad en OSGi -----------------------------------------------83Uso en JADE del modelo de seguridad de OSGi --------------------------------------------84

Glosario -------------------------------------------------------------------------------------------------------------86Bibliografía ---------------------------------------------------------------------------------------------------------90Anexo I: Prueba de transmisión en LEAP IMTP ----------------------------------------------------------93

IX


Índice de Ilustraciones

▪ Ilustración 1: Arquitectura Distributed Coordinated Filters -----------------------------------------13▪ Ilustración 2: Arquitectura en capas de OSGi ---------------------------------------------------------25▪ Ilustración 3: Ciclo de vida de un bundle ---------------------------------------------------------------29▪ Ilustración 4: Esquema de proceso de migración intra-plataforma ------------------------------35▪ Ilustración 5: Esquema del proceso de migración inter-plataforma ------------------------------39▪ Ilustración 6: Integración OSGi en paralelo con JADE ----------------------------------------------44▪ Ilustración 7: Integración JADE sobre OSGi -----------------------------------------------------------45▪ Ilustración 8: Integración con OSGi empotrado en JADE ------------------------------------------46▪ Ilustración 9: Arquitectura de mecanismo de resolución de dependencias en el prototipo implementado ------------------------------------------------------------------------------------------------------56▪ Ilustración 10: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que permanece vivo en el destino ------------------------------------------------------------------68▪ Ilustración 11: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que finaliza en el destino ------------------------------------------------------------------------------71▪ Ilustración 12: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que permanece vivo en el destino y que la definición de este se encuentra en destino previamente a la migración -------------------------------------------------------------------------------------73▪ Ilustración 13: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que finaliza en el destino y que la definición de este se encuentra en objetivo, previamente a la migración -------------------------------------------------------------------------------------74▪ Ilustración 14: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que permanece vivo en el destino. Máximos valores de repeticiones para las capturas realizadas -----------------------------------------------------------------------------------------------------------76

X


Índice de Tablas

▪ Tabla 1: Modificadores de accesibilidad para la funcionalidad ofrecida por una clase en Java, en función de quien puede acceder a dicha funcionalidad. “Package” se encuentra entre paréntesis para indicar que no se trata de un modificador, es la opción por defecto cuando no se indica ninguno. ----------------------------------------------------------------------------------26▪ Tabla 2: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que permanece vivo en el destino ----------------------------------------------------------------------------------67▪ Tabla 3: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que finaliza en el destino ------------------------------------------------------------------------------------------------------------71▪ Tabla 4: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que permanece vivo en el destino y que la definición de este se encuentra en destino previamente a la migración -------------------------------------------------------------------------------------72▪ Tabla 5: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que finaliza en el destino y que la definición de este se encuentra en el objetivo, previamente a la migración --------------------------------------------------------------------------------------------------------------------------74▪ Tabla 6: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que permanece vivo en el destino. Máximos valores de repeticiones para las capturas realizadas --------------------------------------------------------------------------------------------------------------------------75

XI

Introducción a los agentes móviles de software


Capítulo 1Introducción a los agentes móviles de software

En este capítulo se presenta un marco teórico que sirve como introducción al paradigma de los agentes móviles de software.

1.1 - Definición de agentes

1.1.1 - Agente de softwareSe considera un agente a aquello que tiene la capacidad de producir un efecto.

Esta definición simple es la que se obtiene al consultar en la Real Academia Española, pero también es la base sobre la cual diversos autores parten al momento de precisar lo que es un agente [Bradshaw 1997; Rothermel y Hohl 1998].

Especializando a partir del concepto de agente presentado, se dice que un agente de software es un programa informático que implementa la funcionalidad de un agente [Bradshaw 1997]. Más allá de esta definición básica, resulta difícil encontrar un consenso absoluto sobre a que se debe llamar agente (de aquí en más, se usará este término significando agente de software), principalmente debido a que la palabra no está asociada a un contexto específico y, también, por causa de la gran variedad de soluciones a las que se tituló como agente de software [Nwana 1996; Bradshaw 1997].

Sin embargo, es posible definir a un agente a partir del comportamiento y características que se espera que tenga. Se entiende que un agente debe funcionar de manera autónoma (por cuenta propia) y en representación de su usuario; tomando información y posiblemente modificando su entorno, actuando en persecución de sus objetivos y tomando la iniciativa cuando resulte apropiado [Bradshaw 1997; Nwana 1996; Franklin y Graesser 1996; Tanenbaum y Steen 2002].

Entre los atributos que suelen tener (en mayor o menor medida) los agentes de software, se encuentran [Nwana 1996; Bradshaw 1997; Franklin y Graesser 1996]:

• Reactivo: Es capaz de actuar en base al estado de su entorno o a parte de él.

• Autónomo: Puede funcionar sin necesidad de interaccionar con un ser humano, solo guiado (de forma proactiva) por sus objetivos.

• Colaborativo: Tiene la habilidad de actuar en conjunto con otros agentes y (quizás) seres humanos, intercambiando información en un lenguaje de alto

1



nivel y con el fin de cumplir su objetivo y/o un objetivo conjunto.

• Capaz de inferir un objetivo a partir de una especificación abstracta o incompleta. Cabe mencionar que no todos los autores indican esto como un atributo que debe tener un agente de software.

• Longevo: Mantiene su identidad y estado durante un largo período de tiempo (relativo al tiempo que lleva una tarea computacional estándar).

• Inteligente: Debe tomar decisiones en base a cierta lógica con el fin de lograr sus objetivos y, además, se espera que tenga cierto grado de aprendizaje a medida que interacciona con el entorno (aunque no todos los autores coinciden con que este sea un requerimiento).

Extendiendo estas atribuciones elementales, se pueden dar múltiples sub-clasificaciones de agentes de software; ya sea por su grado de movilidad, por si son más deliberativos o reactivos, por sus roles (objetivos), por su nivel de inteligencia, por cuanto colaboran, por su autonomía, etc. [Nwana 1996; Rothermel y Hohl 1998; Bradshaw 1997].

1.1.2 - Agente móvilUn agente móvil de software, es un agente de software con la capacidad de moverse

en una red; interaccionando con hosts (nodos de la red) remotos, obteniendo información y actuando en representación de su dueño. El agente, luego de completar sus tareas, puede (y suele) “volver al usuario”. [Nwana 1996]

La migración de un agente consiste en la transmisión de su código y estado para que pueda continuar con su ejecución en el destino [Rothermel y Hohl 1998]. Se pueden diferenciar dos tipos de migración, strong migration (se podría traducir como “migración completa”) y weak migration (en la misma linea de traducción, sería “migración parcial”). En la primera, se transporta completamente al agente, incluyendo su funcionalidad (código), estado de variables y el estado de ejecución. En la segunda, solo se transporta su funcionalidad y el estado de sus variables [Rothermel y Hohl 1998]. En weak migration, por el hecho de no transportar el estado de ejecución, se fuerza inevitablemente a tener que reiniciar la ejecución del agente en cada nuevo host (pero, posiblemente, a partir de un estado distinto) [Fuggetta, Picco, y Vigna 1998]. Claramente la primer alternativa permite mayor flexibilidad en la migración, sin embargo, el segundo método es útil cuando no es necesaria dicha flexibilidad y se desea evitar el trabajo y tiempo de transferencia extras asociados al guardado y recuperación del estado de la ejecución.

Cabe diferenciar el concepto de agente móvil de los de objetos móviles (mobile objects), ejecución remota (remote execution) y código móvil (mobile code). Un agente móvil, a diferencia de un objeto móvil, actúa en representación de un usuario. La ejecución remota y el código móvil, son conceptos más limitados que el de agente móvil. La primera consiste en realizar un pedido de ejecución de una funcionalidad a

2



un servidor remoto, para luego obtener los resultados. El código móvil, en cambio, consiste en obtener/enviar un fragmento de código o funcionalidad de/a un servidor remoto para ser ejecutado localmente/remotamente [Nilchi, Vafaei, y Hamidi 2008]. En contraste a lo mencionado, el concepto de agente móvil incluye la movilidad del estado, la funcionalidad y de uno o varios objetivos. Sumado a esto, no solo se limita a un solo “salto” (movimiento de un lugar a otro) [Rothermel y Hohl 1998].

Al trabajar con sistemas que utilizan agentes móviles, se suelen diferenciar dos tipos de entidades: los places (este es el término más adoptado, sin embargo, en algunas publicaciones se lo suele nombrar de otras formas) y los agentes (agents). Un place es una entidad pasiva (no realiza acciones por cuenta propia) que le provee a los agentes un entorno de ejecución. Un agente, en cambio, es una entidad activa que pueden moverse entre places para encontrarse con otros agentes y/o utilizar recursos proveídos por los primeros [Rothermel y Hohl 1998].

1.2 - Características de los agentes móviles de software

1.2.1 - Ventajas “heredadas” de los agentes de software

Los agentes móviles heredan las facilidades ofrecidas por los agentes de software; entre las principales, se puede mencionar que simplifican las complejidades de las tareas distribuidas y que permiten superar las limitaciones asociadas al uso de interfaces de usuario de manipulación directa [Bradshaw 1997].

Asociado a la resolución de tareas distribuidas, la primer ganancia surge del hecho de que uno podría delegar en el agente la búsqueda y manipulación de los recursos distribuidos necesarios para completar la tarea asignada, sin necesitar saber cuales son ni como se usan [Harrison, Chess, y Kershenbaum 1995]. Además, mediante la cooperación de múltiples agentes distribuidos, surge cierta “inteligencia” que es mayor a la que se podría tener con el uso de cualquier agente de forma aislada [Nwana 1996].

Por otro lado, al usar un agente, uno puede asignarle objetivos, evitándose especificar de forma exhaustiva como deben completarse. Esto simplifica la realización de tareas respecto a las interfaces de usuario de manipulación directa ya que, en estas, uno debe acceder a los distintos elementos “manualmente” para realizar las acciones necesarias. Como resultado, el usuario podrá delegar en el agente las tareas tediosas que no quiere realizar [Bradshaw 1997].

Adicionalmente, en algunos casos, la visión de un agente como un sistema con intenciones permite facilitar la comprensión del mismo. Es por este motivo que algunos autores consideran que para que algo sea considerado como un agente, debe ser lo suficientemente complejo como para que no pueda ser interpretado a un

3



nivel más básico. [Bradshaw 1997]

1.2.2 - Ventajas asociadas a la movilidadLa movilidad de los agentes en estudio, agrega los siguientes beneficios a los ya

mencionados [Harrison, Chess, y Kershenbaum 1995; Milojicic, LaForge, y Chauhan 1998; Rothermel y Hohl 1998; Lange y Oshima 1999]:

• Reducen el uso de la red, permitiendo explotar el principio de proximidad espacial. Es decir, si los recursos no se pueden mover cerca de donde deben ser trabajados (ya sea por su tamaño o por otro tipo de limitaciones), se mueve el procesamiento cerca de los recursos.

• Permiten evitar latencias en la red, previniendo las demoras debidas a las comunicaciones a mayor distancia, gracias a que se acerca al agente al recurso que se desea acceder.

• Permiten encapsular protocolos, usando un protocolo conocido para desplazar al agente hacia un host remoto y, una vez ahí, posibilitando la utilización de protocolos propietarios.

• Permiten ejecutar tareas de manera asincrónica y autónoma, enviando al agente a “la red” para que opere de forma unilateral. Mientras este se ejecuta, el usuario puede desconectarse y, más tarde, re-conectarse para obtener los resultados.

• Se pueden adaptar de forma dinámica, reaccionando (de forma autónoma) a los cambios en el entorno y reorganizándose (idealmente) de manera óptima para resolver sus objetivos.

• Facilitan la ejecución de tareas distribuidas en plataformas heterogéneas, proveyendo condiciones óptimas para la integración de sistemas por ser, en general, solo dependientes de su entorno de ejecución (y por lo tanto independientes de las arquitecturas y protocolos de transporte utilizados).

• Ofrecen facilidades a la hora de construir sistemas robustos y tolerantes a fallas, aprovechando su habilidad para “darse cuenta” de la existencia de situaciones o sucesos desfavorables y reaccionando ante ellos. Por ejemplo: un agente puede evitar fallas si se mueve más cerca de los recursos o si se aleja de un nodo que está entrando en un estado inconsistente (está por fallar).

• Permiten realizar tareas de forma más escalables, ejecutando un despliegue dinámico de agentes móviles y, de esta forma, permitiendo escalar aplicaciones de manera más simple.

Es importante notar que, si bien muchas de las funcionalidades que facilitan los agentes móviles de software son alcanzables (y hasta superables) con métodos

4



implementados para el fin, la gran ventaja del paradigma estudiado es que las incorpora a todas ellas [Harrison, Chess, y Kershenbaum 1995].

1.2.3 - Dificultades asociadas a los agentes móviles

Entre los problemas asociados a los agentes móviles de software, algunos corresponden a dificultades asociadas a los agentes de software en general, otros corresponden a problemas conocidos de los sistemas distribuidos y otros surgen debido a las particularidades de los agentes móviles. Los aspectos técnicos se tratarán en la siguiente sección, pero a continuación se mencionan dificultades que van más allá de lo técnico.

Una de las cuestiones que deberán ser superadas antes de que sea posible una adopción masiva de los agentes de software, surge a partir de razones sociales en lugar de tecnológicas. Ya que un usuario debe depositar su confianza en el agente para que realice la tarea encomendada en su representación, este no estará dispuesto a hacerlo a menos que entienda como actuará el agente o, al menos, que pueda conocer en un momento determinado cuales son sus intenciones y las acciones que llevará a cabo. Por otro lado, también será necesario que el usuario entienda cuales son las capacidades y limitaciones del agente, en orden de que no exceda sus expectativas respecto de lo realizable por este [Bradshaw 1997].

Por otro lado, resulta complicado definir cuanta responsabilidad tendrá el usuario por las operaciones que hiciera el agente con la autoridad otorgada para actuar en su nombre. Además, habrá que definir quien se hará cargo de las disputas legales que respondan a las interacciones entre los agentes, y que podrían llevar a perjuicios para algún usuario. Por último, es necesario precisar que reglas de “etiqueta” debe seguir un agente para que se pueda lograr una armonía entre los usuarios y quienes brindan los servicios que los agentes consumen [Nwana 1996].

1.3 - Aspectos técnicos asociados con la tecnología de agentes móviles de software

1.3.1 - Aspectos técnicos propios del agenteEntre las dificultades y requerimientos asociados al agente móvil propiamente

dicho, se puede mencionar:

• Un agente debe degradarse con elegancia (degrade gracefully, es un término utilizado para significar un deterioro paulatino a medida que el entorno se vuelve más inadecuado para el sistema) en orden de ser confiable para delegarle tareas [Bradshaw 1997].

• El agente debe poder ejecutarse sobre distintas y variadas arquitecturas.

5



Además, es necesario que no exista el requerimiento de que todos los agentes que vayan a cooperar en la resolución de la tarea asignada hayan sido preparados juntos [Rothermel y Hohl 1998].

• Un agente debe ser capaz de descubrir y administrar los recursos necesarios para cumplir con su objetivo [Rothermel y Hohl 1998].

• El usuario debe saber definir cuando es conveniente usar agentes móviles. El uso de agentes móviles, si bien cuenta con muchas ventajas, no es una solución general. Al igual que con cualquier tecnología, hay que balancear las ventajas y desventajas al momento de tomar la decisión sobre la conveniencia de esta por sobre otras. Entre otras cosas, son notables los siguientes puntos:

◦ El transmitir un agente tiene un costo de comunicación que, en caso de que la operación a realizar no requiera mucho intercambio de información, podría ser mayor que el de realizar la operación directamente desde el cliente o con alguna otra tecnología.

◦ Las complejidades asociadas a la implementación de los mecanismos de seguridad y control sobre el agente para operaciones críticas, pueden representar un mayor costo que los beneficios otorgados por el paradigma [Jansen y Karygiannis 1999].

1.3.2 - Aspectos técnicos propios de la plataforma de ejecución

La plataforma sobre la cual se ejecutan los agentes, es la encargada de brindarles toda la funcionalidad necesaria para que estos puedan completar correctamente sus tareas. Para esto, debe poder soportar la escalabilidad asociada al paradigma o, al menos, debe degradarse con elegancia de modo de poder informar a los agentes asociados que no se les podrá ofrecer la calidad de servicios esperada [Jansen y Karygiannis 1999].

Dada la longevidad que pueden tener los agentes móviles, es importante que estén diseñados para minimizar el “rastro” (información de control, referencias, etc.) asociados a ellos al moverse de nodo a nodo [Milojicic, LaForge, y Chauhan 1998].

1.3.3 - Aspectos técnicos propios de la ejecución del agente

Requerimiento de única ejecución (exactly-once)A partir de la abstracción de agente mencionada en la introducción, seria sensato

pensar que, cuando un usuario le designa una tarea, este esperará que la susodicha se realice exactamente una vez (especialmente si se está hablando de transacciones comerciales). A este requerimiento se lo suele referir como la semántica o propiedad de exactly-once. Esta es crítica para la utilidad de los agentes en

6



aplicaciones donde sus acciones modifican el estado de terceros, ya que, de no cumplirse, no sería seguro su uso. El fundamento es que podría suceder de forma aleatoria que un agente se ejecute una o múltiples veces, cuando en realidad se esperaba que solo lo haga una vez.

La propiedad de exactly-once se definió originalmente para los sistemas RPC (Remote Procedure Call)1 como semántica ante el fallo en la ejecución de un procedimiento. Como extensión, en el contexto de agentes móviles, se debe tener en cuenta que un agente puede realizar una secuencia de pasos en lugar de un único procedimiento [Rothermel y Strasser 1998].

Para poder respetar la propiedad mencionada, será necesario algún mecanismo de ejecución por transacciones y de tolerancia a fallas. Esto tiene (por lo menos) dos complejidades asociadas: primero, los agentes suelen tener tiempos de vida largos; segundo, un agente puede afectar el estado de terceros que también deberán ser tenidos en cuenta [Rothermel y Hohl 1998].

Detección de casos de excepciónDebido a que los agentes realizan tareas de procesamiento distribuido, sus

actividades pueden estar sujetas a distintas situaciones excepcionales. Entre las más habituales y problemáticas se puede mencionar: la terminación abrupta de un agente (crash), el surgimiento de agentes huérfanos y los inter-bloqueos (deadlocks). Cada una a detallarse a continuación.

Una terminación abrupta de un agente (crash), supone que el agente funciona correctamente hasta que en un determinado momento deja de operar por completo (este tipo de falla es equivalente a la que existe en los sistemas distribuidos para los componentes que lo integran, una definición se puede encontrar en [Veríssimo y Rodrigues 2001, 177]). Este caso de excepción es el considerado más habitualmente en las soluciones de tolerancia a fallas.

Un agente también puede fallar presentando un comportamiento indeseable y potencialmente perjudicial para su entorno; sin embargo, este caso se puede considerar como una forma de ataque a la plataforma de ejecución por parte de los agentes (defectuosos) [Jansen y Karygiannis 1999].

El concepto de agentes huérfanos (orphans) se desprende del de “procesamiento huérfano” existente en la computación distribuida. Allí se llama “procesamiento huérfano” a una computación que se continúa realizando cuando el cliente que la solicitó (nomenclatura utilizada en el contexto de una arquitectura cliente-servidor) ya no está disponible para recibir los resultados [Veríssimo y Rodrigues 2001, 248]. Manteniendo la misma idea, se llama agentes huérfanos a aquellos cuya tarea ya no es requerida por la aplicación que los creó (notar que en la palabra “aplicación” se

1 Puede referirse a http://en.wikipedia.org/wiki/Remote_procedure_call para más información.

7

http://en.wikipedia.org/wiki/Remote_procedure_call



está incluyendo posiblemente a un agente “padre”) [Baumann 1997].

Un inter-bloqueo o deadlock surge cuando dos o más procesos esperan por el otro en una configuración desde la cual no se puede progresar. Un deadlock se puede dar siempre que se den las siguientes condiciones [Veríssimo y Rodrigues 2001, 69]:

• Algunos recursos no son compartibles y solo pueden ser mantenidos por un proceso a la vez.

• Al menos un proceso espera por recursos adicionales mientras mantiene un recurso no compartible.

• Un proceso que mantiene un recurso está autorizado a mantenerlo hasta que esté listo para dejarlo (no se le puede “sacar” el recurso al proceso).

• Existe una cadena circular en donde todos los procesos que forman parte de ella esperan por un recurso que tiene el siguiente proceso de la cadena.

Estos casos excepcionales deberán ser resueltos por algún mecanismo de la plataforma o infraestructura sobre la cual se ejecutan los agentes que los sufren, debido a que estos no tienen forma de remediarlos por cuenta propia.

Ya que todos los casos mencionados tienen su equivalente en los sistemas distribuidos convencionales, existen diversos algoritmos que intentan solucionarlos (o, al menos, aminorarlos). Sin embargo, dada la naturaleza asincrónica de los agentes móviles y las intrincadas dependencias que pueden existir entre ellos (no necesariamente del mismo usuario), hay una inherente complejidad en la tarea [Jansen y Karygiannis 1999].

1.3.4 - Aspectos técnicos de la comunicaciónDebido a que los agentes móviles funcionan de manera distribuida y

(principalmente) asincrónica, una efectiva y eficiente comunicación es primordial para su funcionamiento y adopción generalizada [Ahn 2010].

Por otra parte, en orden de permitir interoperatividad entre distintos agentes de distintos usuarios, debe definirse un lenguaje para la interacción entre agentes y con las plataformas de ejecución. Este lenguaje debe ser lo suficientemente flexible como para no limitar la funcionalidad de quienes lo usen y, además, su semántica no puede ser ambigua, de modo que todos los usuarios interpreten lo mismo al analizar un mensaje [Bradshaw 1997].

Problemas por ser distribuidosLas fallas en la comunicación a las que están sujetos los sistemas distribuidos (y

que heredan los agentes móviles), se pueden clasificar en [Veríssimo y Rodrigues 2001, 177,178]:

• Falla por omisión (omission fault): estas ocurren cuando hay una omisión esporádica en la emisión de un mensaje.

8



• Falla por caída (crash fault): este tipo de falla ocurre cuando un componente deja de operar permanentemente.

• Falla en tiempo de respuesta (timing fault): son fallas en el cumplimiento del tiempo de envío del mensaje.

• Fallas de premisas (assertive fault): son en las que un componente realiza una interacción de una manera no especificada. Estas a su vez se sub-clasifican en:

◦ Fallas sintácticas (syntactic fault) cuando la construcción es incorrecta (por ejemplo, si se espera un dígito y se recibe un letra)

◦ Fallas semánticas (semantic faults) cuando el significado es incorrecto (por ejemplo, si se espera un valor entre 0 y 10 y se recibe un -1).

• Fallas arbitrarias (arbitrary faults o Byzantine faults): este corresponde al tipo más general de falla, en el cual no se puede clasificar el comportamiento que tendrá el componente. En estas puede suceder que se generen mensajes espontáneamente, se envíen mensajes mal formados, se descarten mensajes, etc.

Estás fallas son bien conocidas en los ambientes distribuidos y existen todo tipo de soluciones aplicables a las mismas. El detalle de estos y la profundización en los conceptos asociados quedan fuera del alcance del presente trabajo, se refiere al lector a [Veríssimo y Rodrigues 2001] que hace un tratamiento exhaustivo de estos y otros problemas relacionados con los sistemas distribuidos.

Problemas por movilidadLas nuevas dificultades que surgen con el paradigma vienen de la mano con la

movilidad. El hecho de que los agentes móviles puedan desplazarse rápidamente de un nodo a otro, plantea, entre otros, los siguientes aspectos que deben ser tenidos en cuenta [Ahn 2010; Zhao-wen y Wei-dong 2009; Gómez-Martínez, Ilarri, y Merseguer 2007]:

• Como se localiza al agente con el cual se quiere entablar una comunicación.

• Como se trata la información que fue enviada a un agente que ya no se encuentra en la ubicación donde se dirigió el mensaje.

• Como asegurar un desempeño aceptable para la comunicación entre agentes que pueden desplazarse a lugares muy alejados unos de otros.

Se refiere al lector a las fuentes citadas para profundizar sobre estos conceptos.

1.3.5 - Aspectos técnicos relacionados con la seguridad

La seguridad en los agentes móviles merece un apartado especial debido a que es

9



una de las principales dificultades asociadas a estos y que, además, tiene aspectos que aún están sin resolver [Sreedevi et al. 2009]. Los autores suelen clasificar las amenazas a la seguridad existentes en el paradigma según el origen y el destino de los ataques, las categorías resultantes son [Rothermel y Hohl 1998]:

1. Ataques entre agentes.

2. Ataques entre un agente y una plataforma de ejecución. Estos a su vez involucran los casos

a. Ataques de un agente a la plataforma.

b. Ataques de la plataforma al agente que se ejecuta en ella.

3. Ataques entre plataformas de ejecución.

4. Ataques de terceros a la plataforma de ejecución.

En términos generales, como base, un agente debe seguir las siguientes reglas de seguridad [Pham y Karmouch 1998]:

• Las partes involucradas en una operación, en primera instancia, no pueden confiar en la otra.

• Las decisiones críticas deberán ser tomadas en hosts confiables (neutrales para la operación) o, en su defecto, deberán tomarse el recaudo suficiente como para que estas no se vean influenciadas por el lugar donde se toman.

• Los componentes del estado que sean estáticos (no cambien) deberán ser preservados criptograficamente.

Además de los nodos individuales, es importante proteger a los grupos de hosts contra ataques de “bajo perfil” (por ejemplo, consumo de recursos) que no serían detectados por cada uno por separado [Claessens, Preneel, y Vandewalle 2003].

Se refiere al lector a [Jansen y Karygiannis 1999] donde se hace un análisis detallado de los aspectos relacionados con la seguridad en el paradigma en estudio.

10

Plataforma JADE para el desarrollo de agentes móviles de software


Capítulo 2Plataforma JADE para el desarrollo de agentes móviles de software

En este capítulo se brinda una introducción a JADE [«JADE» 2012]. Se analizarán sus principales características que son de relevancia para el presente trabajo.

2.1 - Antecedente histórico

La Fundación para Agentes Inteligentes Físicos (o FIPA por sus sigla en inglés) fue creada en 1996 como una asociación internacional sin fines de lucro, con el objetivo de producir una especificación estándar para la tecnología de agentes heterogéneos que interaccionen entre sí y sistemas basados en agentes [«FIPA» 2012].

Lo que luego se convertiría en JADE, empezó a finales de 1998 propulsado por Telecom Italia (TILAB, antes CSELT) como una implementación que buscaba validar las especificaciones iniciales creadas por FIPA [F. L. Bellifemine, Caire, y Greenwood 2007, 29–30]. Aunque TILAB es el creador del proyecto JADE, este tiene una comunidad creciente que participa en todo el proceso de desarrollo de la plataforma. Esta comunidad se basa en dos puntos principales, el hecho de que el proyecto es de código abierto2, y la existencia de una junta de gobierno para promover la tecnología [F. Bellifemine et al. 2003].

El proyecto JADE se distribuye bajo la licencia de código abierto LGPL (Lesser GNU Public License) en su versión 2.1. En síntesis, esta permite el uso de la tecnología con cualquier fin (sea comercial o no); pero exige que cualquier trabajo derivado de esta, debe ser publicado con la misma licencia [«LGPL v2.1» 2012]. Esta asegura que cualquiera pueda utilizar el producto y, además, que todas las correcciones y mejoras serán retribuidas a la comunidad para que otros puedan aprovecharlas.

La junta de gobierno de JADE fue creada en Mayo del 2003 como iniciativa de TILAB y Motorola. Esta conforma una organización sin fines de lucro con el objeto de promover la evolución y adopción de JADE como plataforma para el desarrollo de aplicaciones basadas en agentes por parte de las industrias de telecomunicaciones móviles. La junta es una organización abierta a cualquier compañía u organización que tenga un concreto interés de negocio en la extensión de JADE, y que se

2 Se refiere al lector a http://en.wikipedia.org/wiki/Open_source para profundizar sobre este concepto.

11

http://en.wikipedia.org/wiki/Open_source



comprometa a contribuir a su desarrollo y promoción [«JADE - The Board Members» 2012].

2.2 - Características de JADE

Un framework es una abstracción que representa código que provee funcionalidades genéricas y que puede ser reemplazado o especializado por el usuario para proveer funcionalidades especificas [«Software framework - Wikipedia, the free encyclopedia» 2011].

En ese sentido, JADE es un framework de agentes móviles de software, ya que permite crear agentes específicos para satisfacer las necesidades del usuario que lo utiliza. Además del framework para el desarrollo de agentes, JADE ofrece una plataforma donde estos podrán ser ejecutados.

En las siguientes subsecciones se presentarán las principales características de JADE en su versión actual (4.2), con el objeto de proveer una visión general de la herramienta, y para luego poder hacer un análisis pertinente al presente trabajo.

2.2.1 - ComponentesEl principal componente que define JADE es la plataforma (platform) que

representa las funcionalidades necesarias para que los agentes puedan operar (notar la equivalencia con los places presentados en la sección 1.1.2). Una plataforma en JADE está compuesta por contenedores (containers) que pueden estar distribuidos en la red y proveen todos los servicios necesarios para albergar y ejecutar los agentes. Los agentes son las entidades con las cuales JADE representa a los agentes móviles de software [F. Bellifemine, Poggi, y Rimassa 1999].

Existe un contenedor especial conocido como el contenedor principal (main container) que representa el punto de inicio de la plataforma, es decir, es el primer contenedor en ser lanzado y, además, todos los demás contenedores que vayan a pertenecer a la plataforma deben registrase con este [F. L. Bellifemine, Caire, y Greenwood 2007, 32].

2.2.2 - ArquitecturaPara facilitar los cambios a su núcleo (funcionalidad elemental), JADE utiliza una

arquitectura llamada distributed coordinated filters. Esta resulta de una mezcla entre la arquitectura Composition Filters (propuesta en [Aksit et al. 1994]) y el modelo de distribución de una plataforma en múltiples contenedores.

En la arquitectura distributed coordinated filters, un contenedor de JADE reside por encima de un nodo. Un nodo aloja servicios que implementan funcionalidades que son coherentes entre sí (a nivel de plataforma). Por ejemplo, en JADE existe un servicio encargado de todo lo concerniente al envío de mensajes, otro que engloba todos los mecanismos necesarios para la migración de agentes, etc. [Giovanni 2004].

12



En la Ilustración 1 se esquematiza el mecanismo de procesamiento de llamadas a servicios desde un contenedor. En este mecanismo, toda acción relacionada con un agente es requerida (por el contenedor en que este reside) al servicio responsable de implementarla. Dicho servicio puede resolver la operación directamente o puede emitir un comando vertical (vertical command). Cuando se emite este comando, se delega la resolución del pedido a un componente del servicio llamado sumidero fuente o de salida (outgoing/source sink). Antes de llegar al sumidero fuente, el comando (vertical) atraviesa una cadena de filtros de salida (outgoing filters). Todos los servicios instalados en el nodo pueden proveer un filtro con el cual reaccionar (de una manera especifica al servicio) a cualquiera de los comandos verticales en el nodo. Un servicio puede decidir si generar un comando vertical o no, pero, cuando lo hace, crea un punto de extensión/modificación en la plataforma en donde se puede agregar procesamiento extra al comando. Un filtro puede modificar e incluso bloquear un comando vertical.

Un servicio puede estar distribuido entre varios nodos de la plataforma. Las interacciones entre distintos nodos se llevan a cabo mediante comandos horizontales (horizontal commands). El componente del servicio que es responsable de aceptar comandos horizontales (entrantes) se llama slice. Al igual que en el caso de un flujo saliente, un slice puede realizar la operación relacionada al comando horizontal directamente o puede emitir un comando vertical. En caso de que se emita un comando vertical, la resolución de la operación es delegada a otro componente del servicio que se conoce como sumidero destino o de entrada (incoming/target sink). De manera análoga al caso del sumidero fuente, antes de llegar al sumidero destino, el comando vertical atraviesa una cadena de filtros de entrada (incoming filters). Todos los servicios instalados en el nodo pueden proveer un filtro de entrada.

13

Ilustración 1: Arquitectura Distributed Coordinated Filters



2.2.3 - Protocolo de comunicación entre contenedores

Para la comunicación entre contenedores de la misma plataforma, JADE dispone de un protocolo interno de transporte de mensajes (Internal Message Transport Protocol o IMTP). Este es utilizado tanto para el envío de mensajes entre agentes, como también para el de comandos internos necesarios para la administración de la plataforma distribuida y el monitoreo del estado de los contenedores [F. L. Bellifemine, Caire, y Greenwood 2007, 41].

Actualmente se ofrecen dos implementaciones de IMTP con JADE, una que está basada en Java RMI y la otra (conocida como LEAP) que utiliza un protocolo propietario sobre conexiones TCP. JADE permite elegir al lanzar la plataforma cual IMTP se utilizará y, además, ofrece un conjunto de configuraciones para ajustar el IMTP a las características específicas de la red y dispositivos sobre los que se despliegue la misma [F. L. Bellifemine, Caire, y Greenwood 2007, 41].

2.2.4 - AgentesEn JADE, el concepto de agente de software se define como “un proceso

computacional que habita una plataforma y, por lo general, ofrece uno o mas servicios que pueden ser publicados mediante una descripción del mismo” [F. L. Bellifemine, Caire, y Greenwood 2007, 15].

Para este framework, un agente tiene las siguientes propiedades principales [F. L. Bellifemine, Caire, y Greenwood 2007]:

• Tiene una identidad única para toda la plataforma.

• Reside en un contenedor de la plataforma.

• Tiene asociado un conjunto de comportamientos (behaviours) que son los que implementan la lógica específica del agente.

• Se comunica con otros agentes mediante mensajes asincrónicos (se ahondará sobre esto más adelante en esta sección y en la 2.3.3).

Tanto la definición como las características principales enunciadas, están basadas en las mismas definidas en los estándares creados por FIPA, sobre la cual se profundizará en la sección 2.3.

Implementación de agentesJADE es un framework implementado completamente en el lenguaje de

programación Java [F. Bellifemine et al. 2008, 51], y toda la funcionalidad que se ejecuta sobre este debe estar implementada en el mismo lenguaje. No se impone ninguna restricción sobre las características del lenguaje que se pueden utilizar, sin embargo, en orden de poder brindar la funcionalidad específica asociada a la plataforma de agentes móviles de software, es necesario tener en cuenta algunas

14



propiedades y seguir ciertos lineamientos [F. Bellifemine, Poggi, y Rimassa 1999]:

• Toda implementación de agente debe ser una especialización de la clase Agent.

• Los agentes tienen su propio hilo de ejecución que lo usan para controlar su ciclo de vida y decidir de forma autónoma cuando se llevarán a cabo las distintas acciones.

• Un agente ejecuta múltiples comportamientos concurrentemente (al mismo tiempo). Sin embargo, es importante tener en cuenta que la metodología de programación de ejecución (scheduling) es cooperativa, esto es, a cada comportamiento se le da la oportunidad de ejecutar hasta que este decida cederla (indicando que desea bloquearse), o hasta que se complete el bloque de instrucciones que este definió para llevar a cabo en el ciclo de ejecución.

El hecho de que los agentes estén asociado a un único hilo de ejecución, permite: el ahorro de recursos (necesarios para el mantenimiento de múltiples hilos); un más rápido cambio entre comportamientos (respecto al que se obtendría si es necesario el cambio entre hilos en ejecución); elimina problemas de sincronización en el acceso de recursos (al no ser posible que distintas tareas estén accediendo al mismo recurso concurrentemente); y, principalmente, permite asegurar que cuando finaliza la ejecución de un comportamiento, el estado del agente sea bien conocido (no pueden ocurrir cambios). Esto último es lo que posibilita implementar la persistencia del estado del agente, ya sea para continuar luego con su ejecución, o para realizar una migración hacia otra ubicación [F. Bellifemine et al. 2008; F. Bellifemine, Poggi, y Rimassa 1999]. Sin embargo, como se mencionó previamente, JADE no impone ninguna restricción respecto a las capacidades del lenguaje de programación Java y, por lo tanto, un programador es libre de crear otros hilos de ejecución según lo requiera. En este caso, es menester tener en cuenta que las ventajas previamente mencionadas ya no seguirán en pie.

Para simplificar el desarrollo de las aplicaciones, con JADE se proveen un conjunto de especializaciones de comportamientos que ofrecen características específicas. Estos permiten realizar tareas repetitivas, de una única vez, periódicas e, incluso, para ejecutar tareas en hilos independientes [Fabio Bellifemine et al. 2010]. De esta forma, el programador solo necesita concentrarse en la lógica necesaria para su aplicación y puede dejar que la funcionalidad se ejecute de acuerdo a algunos de los criterios ya pre-definidos. Existe gran cantidad de otras facilidades listas para usar que se les ofrece a los programadores como parte de JADE, sin embargo, su tratamiento en profundidad queda fuera del alcance del presente trabajo.

Comunicación entre agentesComo ya se anticipó, en JADE la comunicación entre agentes está basada en

15



mensajes asincrónicos. En este contexto, cada agente cuenta con una casilla de mensajes (mailbox) en la cual el entorno de ejecución de JADE pone los mensajes enviados por otros agentes, quienes solo deben indicar el identificador del destinatario [F. Bellifemine et al. 2008]. Cunado un mensaje es puesto en la casilla de mensajes, el agente destinatario es notificado de forma tal que pueda reaccionar al evento. Sin embargo, dado que se trata de un modelo asincrónico, no está determinado cuando el receptor manejará el mensaje e, incluso, puede no hacerlo nunca, siendo esto solo determinado por la lógica interna de dicho agente [F. L. Bellifemine, Caire, y Greenwood 2007, 65].

2.3 - FIPA

Como se mencionó en la sección 2.1, JADE es una implementación que respeta las especificaciones de FIPA. FIPA busca la “promoción de tecnologías y especificaciones de interoperabilidad que faciliten la interconexión punto a punto de sistemas de agentes inteligentes en ambientes comerciales e industriales modernos” [«FIPA - Statement of Intent» 2012]. Para esto, define un conjunto de especificaciones3 que precisan arquitecturas para soportar la comunicación entre agentes, lenguajes de comunicación y de contenido para expresar los mensajes intercambiados, y protocolos de interacción para expandir el alcance de un único mensaje a transacciones completas [«FIPA - Statement of Intent» 2012].

A continuación se describen brevemente algunas de las especificaciones creadas por FIPA de forma tal de generar un contexto y una base para el entendimiento de que lineamientos se definen en estas y, por lo tanto, que criterios siguen las funcionalidades brindadas por JADE.

2.3.1 - Especificación de arquitectura abstracta

La especificación de arquitectura abstracta existe con el objeto de proveer un punto de referencia común e invariante para las implementaciones que cumplan con FIPA [«[FIPA00001]» 2012]. Este documento captura las funcionalidades más críticas y sobresalientes de un sistema de agentes, mientras que, a su vez, provee cierto aislamiento ante pequeños e iterativos cambios que puedan impactar a las especificaciones subyacentes (y más detalladas), conocidas como realizaciones [F. L. Bellifemine, Caire, y Greenwood 2007, 16]. Con este trabajo se busca fomentar la interoperabilidad y reusabilidad de distintas arquitecturas concretas que implementen sistemas de agentes [«[FIPA00001]» 2012].

La arquitectura propuesta en está especificación define de forma abstracta como dos agentes pueden localizarse y comunicarse entre ellos, registrándose e

3 Las especificaciones generadas por FIPA se pueden acceder en http://www.fipa.org/specifications/index.html

16

http://www.fipa.org/specifications/index.html



intercambiando mensajes que representan actos de habla4 y están codificados en un cierto lenguaje de comunicación entre agentes (agent communication languaje o ACL).

En la arquitectura abstracta, además de los lineamientos básicos que todo sistema que cumpla con esta debe obedecer, se describen algunos elementos opcionales. Sin embargo, se debe tener en cuenta que, aunque un elemento sea opcional a nivel abstracto, puede ser obligatorio en una de las especificaciones más particulares (realización) [F. L. Bellifemine, Caire, y Greenwood 2007, 16–26].

2.3.2 - Especificación de administración de agentes

La especificación de administración de agentes apunta principalmente a definir interfaces estándares para acceder a los servicios de administración de agentes (creación, registro, localización, comunicación, migración y retiro) pero excluye el diseño interno e implementación de su infraestructura [«[FIPA00023]» 2012].

El modelo de referencia consiste en los siguientes componentes lógicos [«[FIPA00023]» 2012]:

• Agente: es un proceso computacional que implementa la funcionalidad autónoma y comunicativa de una aplicación.

Los agentes se comunican por medio de un lenguaje de comunicación entre agentes (ACL). Un agente puede ofrecer un conjunto de servicios, publicándolos en un modelo de ejecución unificado e integrado, mediante el uso de una descripción de servicio.

Un agente debe tener por lo menos un dueño y soportar al menos una noción de identidad. Esta identidad, conocida como identificador de agente (agent identifier o AID), etiqueta al agente de forma tal que pueda ser distinguido de forma unívoca dentro del universo de agentes.

Un agente puede ser registrado en una o más direcciones de transporte en las cuales puede ser contactado.

• Plataforma de agentes (Agent Platform o AP): provee la infraestructura física (máquina, sistema operativo, software de soporte, etc) en donde un agente puede ser desplegado. El diseño interno de una AP no está especificado por FIPA.

• Directory Facilitator (DF): provee un servicio de “páginas amarillas” a los agentes. Estos pueden registrar allí sus servicios y consultarlo para encontrar cuales son ofrecidos por otros. Pueden existir múltiples DF en una AP y ser configurados para que sean visibles como una única unidad (federados). El DF es un componente opcional de la AP.

4 Puede referirse a http://es.wikipedia.org/wiki/Teor%C3%ADa_de_los_actos_de_habla para más información.

17

http://es.wikipedia.org/wiki/Teor%C3%ADa_de_los_actos_de_habla



• Sistema de administración de agentes (Agent Management System o AMS): supervisa el acceso y uso de una AP. El AMS permite a los agentes de la AP obtener (previo registro) un AID válido. Además, ofrece un servicio de “páginas blancas” que permite a los agentes consultar la dirección de transporte de los otros. Este es un componente obligatorio en la AP y solo un único AMS existe por cada una de estas.

• Servicio de transporte de mensajes (Message Transport Service o MTS): es el método de comunicación por defecto entre agentes de distintas APs. Se profundizará sobre este servicio en la siguiente sección.

2.3.3 - Especificación del servicio de transporte de mensajes de agentes

La especificación del servicio de transporte de mensajes de agentes se ocupa del transporte de mensajes entre agentes que interaccionan [«[FIPA00067]» 2012]. Define el concepto de canal de comunicación entre agentes (Agent communication channel o ACC) que es la entidad que provee el servicio de transporte de mensajes directamente a los agentes de la AP.

El modelo de referencia para el transporte de mensajes está compuesto por los siguientes niveles:

1. El protocolo de transporte de mensajes (Message Transport Protocol o MTP) que es usado para el transporte físico de mensajes entre dos ACCs.

2. El servicio de transporte de mensajes (Message Transport Service o MTS) que es un servicio proveído por la AP, y que soporta el transporte de mensajes ACL entre agentes en una misma o distintas AP. Se indica también que el uso dentro de una misma AP es opcional y podría elegirse usar cualquier método (propietario) de intercomunicación.

3. El ACL representa el contenido del mensaje transportado por el MTS y el MTP.

Un mensaje está formado por dos partes, el sobre (envelope) que contiene la información de transporte; y el contenido, que está compuesto por el mensaje ACL del agente. Los MTP pueden usar una representación interna para describir el sobre del mensaje, pero deben expresar los mismos términos, representar la misma semántica y realizar las correspondientes acciones asociadas a este.

Un ACC debe transmitir los mensajes que recibe de acuerdo a las instrucciones de transporte contenidas en el sobre del mensaje; y solo es requerido que interprete el sobre, no así el contenido del mismo. Cada ACC que manipule un mensaje puede agregar nueva información al sobre, pero no está permitida la sobre-escritura de la información existente. Es válido, sin embargo, que se re-defina algún parámetro del sobre mediante el agregado de un nuevo parámetro con el mismo nombre, siendo el

18



mecanismo para elegir la versión considerada como actual dependiente de la sintaxis de cada sobre concreto.

19

OSGi: un sistema de componentes dinámicos para Java


Capítulo 3OSGi: un sistema de componentes dinámicos para Java

En este capítulo se presenta la tecnología OSGi y se da un marco teórico de las dificultades de Java que esta busca solucionar. Finalmente se cierra el capítulo con una comparativa entre las características de esta tecnología y los requerimientos del paradigma de agentes móviles de software.

3.1 - Introducción a OSGi

OSGi™ es un conjunto de especificaciones que definen un sistema de componentes dinámicos para Java [«OSGi Alliance | Technology / The OSGi Architecture» 2012]. Estas especificaciones facilitan un modelo de desarrollo en donde las aplicaciones son conformadas (dinámicamente) por una variedad de componentes reutilizables. OSGi permite que estos componentes oculten el detalle de su implementación de otros mediante el uso de servicios, favoreciendo así la reutilización y el dinamismo.

En las siguientes secciones se describirán las características principales de OSGi, enfatizando especialmente en aquellas relevantes para el presente trabajo; pero, previo a esto, se presenta un contexto de referencia relacionado a la tecnología Java.

3.2 - ClassLoaders de Java

Para aclarar cual es la razón de ser de OSGi, es útil entender como funciona el mecanismo de administración de clases en Java y cuales son sus limitaciones.

En Java se llama class loader a un objeto5 responsable de cargar clases6. Este concepto está representado por la jerarquía de clases que tienen como raíz a ClassLoader, y que son las encargadas de localizar o generar los datos que constituyen la definición de las clases y hacerlas disponibles al programa que se está ejecutando. La arquitectura de class loaders permite construir o extender una

5 Concepto definido en el paradigma de programación orientada a objetos, para más información se refiere al lector a http://en.wikipedia.org/wiki/Class_%28computer_programming%29.

6 Concepto definido en el paradigma de programación orientada a objetos, para más información se refiere al lector a http://en.wikipedia.org/wiki/Object_%28object-oriented_programming%29.

20

http://en.wikipedia.org/wiki/Object_(object-oriented_programming)

http://en.wikipedia.org/wiki/Object_(object-oriented_programming)

http://en.wikipedia.org/wiki/Class_(computer_programming)

http://en.wikipedia.org/wiki/Class_(computer_programming)



aplicación de forma dinámica, mediante la obtención de recursos (tanto clases como datos) en tiempo de ejecución [«ClassLoader - JSE7» 2011].

3.2.1 - Objetivos de la arquitectura de Class Loaders

La arquitectura de class loaders de Java busca cumplir los siguientes objetivos [Halloway 2002, 14–17]:

• Transparencia: En general, un programa debe poder ser implementado en Java sin conocimiento explícito de la existencia de los class loaders.

• Extensibilidad: El mecanismo de class loading debe poder extenderse para poder adaptarse a las necesidades específicas de los usuarios.

• Capacidad: Se deben proveer las funcionalidades necesarias para satisfacer los requerimientos más comunes, como ser; poder re-cargar en tiempo de ejecución los cambios que se realizaran al código siendo utilizado, y cargar código desde diversidad de fuentes (por ejemplo, desde la red o un archivo comprimido). Además, este comportamiento debe ser lo suficientemente simple como para que los desarrolladores puedan determinar desde que fuente son obtenidos los recursos utilizados.

• Configurabilidad: Se debe poder definir ciertos parámetros que rijan la obtención de los recursos por parte de la arquitectura de class loaders. Esto no solo debe poder realizarse por los desarrolladores del programa, sino que también deben estar disponible como configuraciones para un administrador (usuario) del sistema.

• Manejo de conflictos de nombres y diversidad de versiones: Diversas clases con el mismo nombre deben poder coexistir en un programa, así como también distintas versiones de una misma clase. Adicionalmente, se debe poder compartir las clases que no cambien frecuentemente, de forma que no sea necesario cargarlas múltiples veces.

• Seguridad: Deben existir ciertas garantías de seguridad para que sea confiable el trabajo con clases obtenidas desde diferentes fuentes.

En Java todas las clases guardan una referencia al class loader que las cargó [«ClassLoader - JSE7» 2011]. Así, cuando una clase hace referencia a otra que no fue cargada aún, está última es obtenida implícitamente por medio del class loader asociado a la primera [Lindholm et al. 2012, 340–342]. Este mecanismo de carga de clases implícito es el que permite cumplir con el objetivo de transparencia.

El hecho de que se pueda redefinir la funcionalidad para la carga de clases (mediante la especialización de la clase ClassLoader) es lo que brinda gran extensibilidad a esta arquitectura. Un ejemplo de esto es la clase URLClassLoader (disponible en la plataforma Java desde su versión 1.2), que

21



ofrece la capacidad de obtener los recursos desde múltiples fuentes; como ser una dirección dentro del sistema de archivos o una dirección remota.

El classpath consiste en un conjunto de rutas (referidas al sistema de archivos) que se configura para indicarle a la plataforma Java donde debe buscar las clases a utilizar en el programa al momento de ejecutarlo [«Setting the class path» 2012]. Esto permite influenciar al mecanismo de class loading sin necesidad de implementar o modificar código del programa.

Finalmente, el uso de distintos class loaders define un contexto para las distintas clases. Estos permiten la coexistencia de múltiples versiones y clases homónimas sin presentar conflictos (cada una puede ser bien diferenciada) y, adicionalmente, asegurando que se dispondrá de los controles necesarios para poder ejecutar las aplicaciones de forma segura y libre de inconsistencias. Sobre estos puntos se profundizará en la siguiente sección.

3.2.2 - Reglas de los Class LoadersPara posibilitar que las clases cargadas por diferentes class loaders puedan ser

utilizadas por un mismo programa y, a su vez, mantener cierta diferenciación entre cada uno de forma tal que puedan utilizarse clases homónimas sin incurrir en comportamientos inesperados, la arquitectura de class loaders (en general) se rige por las siguientes reglas [Halloway 2002, 23–29]:

1. Regla de consistencia: Un class loader nunca carga la misma clase más de una vez.

2. Regla de delegación: Un class loader debe consultar a sus antecesores (padres) antes de cargar una clase (para verificar si ya fue o puede ser cargada por alguno de ellos).

3. Regla de visibilidad: Las clases solo pueden “ver” otras clases cargadas por su delegación de class loaders asociada (conformada por el class loader que la cargó y los padres de este).

La regla de consistencia establece que, una vez que un class loader cargó una clase, un sucesivo pedido por dicha clase obtendrá como resultado la instancia ya cargada. Esto permite determinar inequívocamente que versión de la clase se está utilizando y asegurar que esta no cambiará durante la ejecución. De no cumplirse esta premisa, la estabilidad del programa estaría en riesgo ya que no se podría confiar en la estructura de una clase, pudiendo esta cambiar dinámicamente y sin aviso.

Por otro lado, la regla de delegación permite utilizar clases ya cargadas por otros class loaders siendo que estas serán compartidas con todos los que lo tengan como padre.

Por último, la regla de visibilidad brinda la posibilidad de que coexistan múltiples

22



versiones (homónimas) de la misma clase en un programa. Esto es debido a que la versión cargada por un class loader no será “vista” por el código que haya sido cargado por otro class loader y que no lo tenga como parte de su delegación. Esta regla, además, ofrece ciertas garantías de seguridad, al prevenir que se utilice por error una clase cargada desde una fuente no confiable (desde otro class loader).

Cabe resaltar que las reglas de delegación y visibilidad (en conjunto) definen que para poder utilizar distintas versiones de una misma clase desde otra, la última necesariamente deberá utilizar una interfaz común a ambas (definida por una super-clase o interfaz7 que implementen y que haya sido cargada por un class loader común a la clase usuario y a las distintas versiones de la clase siendo utilizada).

3.2.3 - Dificultades en el uso de los class loaders

El uso de class loaders requiere tener presente algunas cuestiones que, de lo contrario, podría llevar a comportamientos “extraños” en la ejecución del programa.

Class loaders concurrentesSe debe tener especial cuidado al intentar cargar clases concurrentemente o al

especializar la funcionalidad de un class loader de forma tal que pueda incurrir en llamadas re-entrantes durante los pedidos de carga de clases (es decir, cuando el proceso de carga de una clase requiere que se carguen otras y estas, a su vez, llevan a realizar otro pedido de carga al class loader original, que aún no termina de cargar la clase inicial). Este tipo de comportamiento puede llevar a bloqueos inesperados en la ejecución del programa8.

Las clases homónimas en distintos class loaders no son la misma clase

De la regla de visibilidad antes mencionadas, queda claro que una clase con nombre A (por ejemplo) cargada en un class loader, no tiene relación (para la plataforma Java) con otra clase homónima cargada por otro class loader.

Esto puede llevar a situaciones en las que, durante la ejecución de un programa, se generen errores cuya descripción será (algo similar a) “A cannot be cast to A” (lo que se podría traducir como “la clase A no puede ser interpretada como la clase A”). Claramente este tipo de errores resultan desconcertantes al momento de depurar los errores presentes, y demuestran la complejidad al momento de trabajar (explícitamente) con diferentes class loaders.

7 Concepto definido en el paradigma de programación orientada a objetos, para más información se refiere al lector a http://en.wikipedia.org/wiki/Interface_%28object-oriented_programming%29.

8 Queda fuera del alcance del presente trabajo ahondar en la discusión de este problema. Se puede encontrar más información al respecto en [«Multithreaded Custom Class Loaders in Java SE 7» 2011]

23

http://en.wikipedia.org/wiki/Interface_(object-oriented_programming)

http://en.wikipedia.org/wiki/Interface_(object-oriented_programming)



Perdidas de memoria significativasLas consecuencias de mantener referencias obsoletas (que en Java representan

perdidas de memoria, ya que significan objetos que no serán recolectados por el mecanismo de garbage collector) son particularmente severas cuando se está trabajando con class loaders. Cada instancia (objeto) en Java guarda una referencia a su clase (objeto de tipo Class) y, a su vez, (como se mencionó previamente) cada clase guarda una referencia al class loader que la cargó. Además, cada class loader guarda una colección con las clases que cargó (esto permite cumplir con la regla de consistencia mencionada previamente). Todo esto lleva a que la sola existencia de una instancia (obsoleta o no) de una clase, prevenga la liberación de la memoria asociada a todas las clases cargadas por su delegación de class loader asociada [Halloway 2002, 35–36].

La regla de delegación puede romperse (Context Class Loader)

La regla de delegación (enunciada previamente) determina que un class loader debe requerir a su padre la carga de una clase antes de intentar cargarla por su cuenta. Sin embargo, Java provee un mecanismo alternativo para la carga de clases. Mediante este, se puede asociarle a un Thread9 (hilo de ejecución de un programa) un class loader (conocido como context class loader) a utilizar para la carga de clases requeridas por dicho hilo. La presencia de este mecanismo alternativo agrega una nueva variable al momento de analizar y depurar un programa [Halloway 2002, 49–55].

3.3 - Introducción a OSGi y sus conceptos principales

Teniendo un mayor contexto referente a las dificultades que puede traer el trabajar con el mecanismo de class loading de Java, resulta más claro el porque podría preferirse el uso de una tecnología que permita abstraerse del mismo. Una tecnología que extiende la funcionalidad de Java y que (comúnmente) permite ignorar las dificultades del class loading, es OSGi. En esta sección se dará una breve introducción a OSGi y en las subsiguientes se profundizará en los aspectos más relevantes de este.

En términos generales, un módulo representa un límite lógico, de tal forma que su implementación interna está oculta del exterior y solo se expone (opcionalmente) una interfaz bien definida a partir de la cual se puede interactuar con él. Los módulos son piezas independientes (pueden existir sin necesidad de otros) y reutilizables

9 Para más información sobre este concepto, se refiere al lector a http://en.wikipedia.org/wiki/Thread_%28computing%29 y http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html.

24

http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html

http://en.wikipedia.org/wiki/Thread_(computing)



(utilizables en distintas combinaciones con otros módulos).

A partir de la definición de OSGi dada al comienzo de este capítulo, se puede observar que su objetivo es facilitar la implementación de sistemas modulares (que utilizan módulos). En OSGi el concepto de módulo esta representado por lo que se conoce como bundle, y estos encapsulan la funcionalidad desarrollada por los usuarios de OSGi [The OSGi Alliance 2012a, 23].

Al entorno de ejecución que implementa y provee la funcionalidad de OSGi se lo conoce como el framework. Este esta compuesto por tres capas principales [R. Hall et al. 2010, 9–12]:

1. Capa de módulos: se ocupa del empaquetado y compartición del código. Es en esta en la que se define el concepto de bundle.

2. Capa de ciclo de vida: provee la funcionalidad de administración en tiempo de ejecución de los bundles y el acceso al framework subyacente.

3. Capa de servicios: facilita la interacción y comunicación entre los módulos.

La arquitectura de OSGi está representada en la Ilustración 2 [«OSGi Alliance | Technology / The OSGi Architecture» 2012].

Gracias a la arquitectura en capas, es posible utilizar las capas inferiores sin conciencia de las superiores. Por ejemplo, es factible utilizar el concepto de bundle (capa de módulos) sin necesidad de utilizar el comportamiento dinámico ofrecido por la capa de ciclo de vida.

Además del framework, OSGi define un conjunto de servicios estándares (en lo que se conoce como la especificación Compendium) que ofrecen funcionalidades generales, como por ejemplo, logging y configuración de preferencias [«OSGi Alliance | Technology / The OSGi Architecture» 2012].

25

Ilustración 2: Arquitectura en capas de OSGi

Sistema Operativo

Máquina Virtual de Java

Entorno de Ejecución

Módulos

Ciclo de Vida

ServiciosBundles

Se

gu

rida

d



3.4 - Limites de la modularidad en la plataforma Java

La plataforma Java provee las abstracciones de clase (que representan el mismo concepto de la programación orientada a objetos), paquete (agrupación de clases) y archivo JAR (agrupación de clases, paquetes, recursos e información adicional en un archivo) que se pueden reconocer como módulos (cumplen con la definición dada previamente) [Gosling et al. 2012, 163,179; R. Hall et al. 2010, 5–6]. Sin embargo, la flexibilidad de estos módulos es limitada en cuanto a lo que puede llegar a ser necesario en el desarrollo de aplicaciones. A continuación se repasarán algunos aspectos claves que permitirán profundizar en el entendimiento de que funcionalidades OSGi busca complementar.

3.4.1 - Soporte para la definición de interfaces exportadas

En Java el nivel de acceso a las funcionalidades brindadas por una clase está dado por distintos modificadores de accesibilidad resumidos en la Tabla 1 [Gosling et al. 2012, 152–159].

Si bien estos modificadores permiten especificar con gran detalle la accesibilidad a la interfaz ofrecida por una clase, esto no se extiende a nivel de paquete. Por ejemplo, si dos clases pertenecen lógicamente a distintos paquetes y se quiere permitir que compartan cierta funcionalidad entre ellas, la única forma de resolverlo sería definiendo que dichas funciones sean públicas. El inconveniente reside en que, de esta forma, estas también serán “visibles” por cualquier otro paquete o clase. Esto tiene el efecto adverso de que, al no quedar explicita la dependencia entre los distintos módulos, puede dificultar la evolución de las aplicaciones [R. Hall et al. 2010, 5].

OSGi complementa las capacidades de la plataforma estándar de Java permitiendo definir a nivel de bundle que paquetes son visibles (exportados) para los demás. En adición al nombre del paquete exportado, se pueden definir distintos atributos para detallar exactamente cual es la funcionalidad ofrecida. Estos atributos pueden ser: la versión del paquete; e incluso hasta pares nombre-valor

26

Tabla 1: Modificadores de accesibilidad para la funcionalidad ofrecida por una clase en Java, en función de quien puede acceder a dicha funcionalidad. “Package” se encuentra entre paréntesis para indicar que no se trata de un modificador, es la opción por defecto cuando no se indica ninguno.

Modificador Propia Clase Paquete Subclases Otras ClasesPermitido Permitido Permitido PermitidoPermitido Permitido Permitido ProhibidoPermitido Permitido Prohibido ProhibidoPermitido Prohibido Prohibido Prohibido

publicprotected(package)private



arbitrarios, cuyo significado esta dado por una convención con el usuario de la interfaz [The OSGi Alliance 2012a, 37–51].

3.4.2 - Soporte para la definición de interfaces importadas

En Java la forma general para definir que clases están disponibles para ser utilizadas por una aplicación es mediante el classpath (descripto en la sección 3.2.1).

Este mecanismo no favorece la modularidad ya que no permite diferenciar entre los distintos recursos incluidos en el classpath (que, en última instancia, serán los que se utilizarán en la aplicación). Esto dificulta el reconocimiento de las dependencias que utilizará una aplicación al momento de ejecutarse. Por ejemplo, ante la presencia de dos versiones distintas de una dependencia, el mecanismo de class loading obtendrá la primer instancia (de acuerdo al orden de inclusión en el classpath) del recurso buscado. Este problema es tan habitual que incluso tiene nombre propio, classpath hell (o, similar, JAR hell) [R. Hall et al. 2010, 7].

Así como OSGi permite definir con gran detalle la interfaz exportada por un bundle, también permite especificar las dependencias de estos. Por ejemplo, se puede indicar que un bundle solo puede funcionar con un rango específico de versiones de un paquete, o con un paquete que haya sido exportado con un un atributo cuyo valor es el especificado. Luego será el framework el que se encargará de que únicamente estén disponibles en la aplicación aquellos bundles que tengan sus dependencias satisfechas [The OSGi Alliance 2012a, 51–52].

3.4.3 - Soporte para el despliegue y mantenimiento de las aplicaciones

Como se mencionó en secciones anteriores, en la plataforma estándar de Java no hay forma de desplegar una aplicación y confiar que sus dependencias serán satisfechas exactamente con los módulos requeridos. Si en donde se desea desplegar la aplicación existen otras versiones de las dependencias, puede darse un problema del tipo classpath hell (mencionado previamente). Por otro lado, a menos que se recurra a implementaciones especializadas que utilicen explícitamente mecanismos de class loading (con todos sus potenciales inconvenientes, según lo descripto en la sección 3.2.3), no hay forma de realizar mantenimiento (corrección de errores, actualización de versiones o dependencias, etc.) sin detener la aplicación.

Ya se comentó que el framework de OSGi asegura que un bundle solo podrá ser utilizado por una aplicación si sus dependencias son exactamente satisfechas, pero además de esto, es posible reemplazar bundles sin necesidad de detener la aplicación (ni el framework). Incluso se asegura que, mientras se satisfagan las dependencias, no importa cual bundle ofrezca la interfaz requerida. Esto permite explotar al máximo la modularidad de la implementación.

27



3.5 - Capas de OSGi

En la introducción a la tecnología OSGi (ver sección 3.3) se mencionó que el framework está dividido en tres capas principales, la de módulos, la de ciclo de vida y la de servicios. En esta sección se profundizará sobre cada una de ellas.

3.5.1 - Capa de módulos (Module Layer)La capa de módulos es la que define el concepto de bundle. Para Java un bundle

es un archivo JAR con metadatos (datos acerca de los datos) adicionales. Mientras que tradicionalmente todo el contenido de un JAR es completamente visible para el resto de las clases de la aplicación, en OSGi nada es visible a menos que sea exportado (por medio de los metadatos) explícitamente. Para que un bundle pueda acceder a la funcionalidad ofrecida por otro, debe importar explícitamente las partes que desee utilizar.

En Java (generalmente) un JAR encapsula todas las clases que conforman la aplicación. OSGi, en cambio, busca un enfoque más modular, en el cual la aplicación se arma a partir de un conjunto de bundles interconectados por sus dependencias e interfaces ofrecidas, y que pueden ser compartidos por varias aplicaciones. El proceso por el cual los distintos bundles son interconectados según los paquetes que exportan e importan, es nombrado como resolución de bundles. Las interconexiones realizadas en la resolución de los bundles son conocidas como wiring. [The OSGi Alliance 2012a, 37–39]

3.5.2 - Capa de ciclo de vida (Lifecycle Layer)Esta capa es la que define los distintos estados en los que se puede encontrar un

bundle y, además, permite administrarlos (requerir el cambio de su estado). Es gracias a esta capa que las aplicaciones pueden ser extendidas (mediante el agregado de nuevos bundles) y/o actualizadas (mediante el cambio o remoción de bundles) dinámicamente (sin necesidad de detenerla).

Un bundle puede ser instalado, actualizado, iniciado, detenido y desinstalado del framework. Estas transiciones junto con los posibles estados de un bundle se esquematizan en el diagrama de estados en la Ilustración 3.

28



Los posibles estados de un bundle son [The OSGi Alliance 2012a, 89–90]:

1. Instalado (installed): Cuando un bundle es agregado al framework, este comienza en el estado instalado. Este indica que el framework debe verificar las dependencias del bundle antes de que pueda pasar a estar resuelto.

2. Resuelto (resolved): Un bundle solo puede estar en este estado mientras todas sus dependencias estén satisfechas. Para pasar un bundle al estado resuelto, el framework verifica si los bundles ya resueltos satisfacen (exportan) los requerimientos del primero. Es factible que otros bundles deban ser resueltos previo a que el bundle siendo verificado pueda satisfacer sus dependencias. En este caso, se resolverán primero estos antes de completar la resolución del original. Cabe resaltar que, si por algún motivo, un bundle deja de tener sus dependencias satisfechas, este volverá al estado instalado (caso posible debido a la naturaleza dinámica de OSGi).

3. Iniciando (starting): Este es un estado temporal previo a que el bundle sea iniciado. En este, el framework se encarga de que se creen todos los recursos para que el bundle pueda activarse.

4. Activo (active): En este estado el bundle esta iniciado y disponible para cumplir su función.

5. Deteniéndose (stopping): Este es un estado temporal en el cual el framework libera los recursos que se tomaron para poder iniciar el bundle.

6. Desinstalado (uninstalled): El bundle ya no está disponible para las aplicaciones. Para que pueda disponerse nuevamente de este, debe ser

29

Ilustración 3: Ciclo de vida de un bundle



primero (explícitamente) instalado y luego resuelto.

Una acción de actualizar (update) le indica al framework que debe “recargar” el bundle (en general, para obtener una versión más actualizada). Esto obligará al framework a tener que verificar las dependencias del nuevo bundle y, así, poder pasarlo nuevamente al estado en que se encontraba previo a la actualización. Cuando se actualiza un bundle del cual otros dependen (importan paquetes), el framework carga la nueva versión, pero también deja los paquetes de la anterior que estaban siendo usados [The OSGi Alliance 2012a, 95–96]. Esto se hace con el fin de prevenir una reacción en cadena que haría que todas los bundles dependientes de este tengan que volver a ser verificados al instante, lo cual podría llevar a que otros bundles deban también ser verificados, y así sucesivamente. La acción de refrescar (refresh) le indica al framework que realice nuevamente la verificación de dependencias (ahora si, pudiendo llevar a una reacción en cadena que afecte a otros bundles además del que está siendo refrescado). Esto permite que las versiones obsoletas de un bundle que fue actualizado, puedan ser liberadas; y que los bundles que dependían de esta (que son los que se están refrescando), pasen a utilizar la versión actual. Cabe mencionar que la versión obsoleta solo se mantiene relacionada a los bundles que ya estaban resueltos (o activos), siendo que un nuevo bundle solo podrá asociarse a la versión actualizada [The OSGi Alliance 2012a, 95–96,142–143].

Cuando un bundle es instalado en el framework, se le asigna un identificador único que no cambia durante todo su ciclo de vida (solo cambiará si este es desinstalado y vuelto a instalar). Este identificador es el que permite administrarlo dentro del framework. Además de por medio de este identificador, el bundle puede ser identificado por lo que se conoce como location; que es un nombre asignado por quien lo instaló (normalmente relacionado con la dirección de origen o URL desde donde se lo obtuvo, aunque esto no es obligatorio). Por último, el par symbolic name (nombre simbólico) y versión del bundle, también sirve como identificador unívoco del mismo [The OSGi Alliance 2012a, 89].

Los bundles no solo pueden ser administrados de manera externa a la aplicación, internamente el framework es representado por un contexto que es mediante el cual la aplicación (otros bundles) puede modificar los estados de los primeros [The OSGi Alliance 2012a, 100]. Dicho contexto tiene una interfaz estandarizada, por lo que se asegura la portabilidad de las aplicaciones independientemente de sobre que implementación del framework se ejecuten.

3.5.3 - Capa de servicios (Service Layer)La capa de servicios provee la funcionalidad necesaria para crear aplicaciones

basadas en el uso de servicios. En OSGi cada bundle puede registrar una o más interfaces que representan un contrato de servicio. Luego, todo bundle que se ejecute en el mismo framework puede acceder a los servicios registrados, sin necesidad de

30



conocer que bundle o bundles los proveen [The OSGi Alliance 2012a, 115].

Como los bundles, los servicios pueden aparecer y desaparecer dinámicamente del framework. Esto da una gran flexibilidad y dinamismo a la funcionalidad ofrecida por esta capa, ya que permite que uno o más bundles ofrezcan un servicio determinado e, incluso, que se utilicen distintas implementaciones (de forma transparente) con el paso del tiempo.

En OSGi los bundles pueden registrar, buscar y ser notificados ante los cambios (registración y desregistración) en los servicios requeridos [The OSGi Alliance 2012a, 113]. La especificación de un servicio está caracterizada por un conjunto de propiedades, algunas de las cuales están estandarizadas y otras son especiales para cada uno. Mediante la especificación de filtros, los bundles pueden referirse a los servicios en los cuales están interesados (ya sea para la búsqueda o recepción de notificaciones) [The OSGi Alliance 2012a, 114–120].

3.6 - Relación de OSGi con el paradigma de agentes móviles de software

Con la base de conocimiento sobre la tecnología OSGi realizada hasta el momento, es posible analizar cuales son sus virtudes y hacer una contraposición con el paradigma de los agentes móviles de software. En esta sección se busca destacar que las capacidades de OSGi son adecuadas para la implementación de la funcionalidad necesaria para un framework que soporte el concepto de agente móviles de software.

3.6.1 - ModularidadOSGi está íntimamente relacionado con desarrollos modulares. Los bundles en

OSGi representan el concepto de módulo, donde lo primordial es una interfaz bien definida.

Con la definición de módulo utilizada, es posible caracterizar a un agente de software como un módulo en si mismo. Los agentes son entidades auto-contenidas que exponen un comportamiento y, desde el punto de vista de otros agentes, no importa nada más que las interacciones que pueden realizarse entre ellos (un agente no depende de como funciona otro, simplemente le interesa que es lo que puede hacer o hace).

Por como modela JADE los agentes, separando los comportamientos (representados por los behaviours) y la entidad en si (representado por los agents), en ocasiones es posible tomar a cada uno, o un subconjunto de ellos, como módulos individuales. Si los comportamientos no están fuertemente acoplados a la implementación particular del agente (es decir, cumple funciones comunes a varios tipos de agentes), estos pueden ser tomados como módulos que están disponibles

31



para ser compartidos entre distintos agentes.

3.6.2 - DinamismoLa capa de ciclo de vida de OSGi permite insertar y eliminar dinámicamente los

bundles del framework. Esta misma flexibilidad es necesaria para un framework que permita implementar el paradigma de agentes móviles, ya que su principal característica es que pueden desplazarse de un lugar a otro de forma dinámica (siendo necesario hacer disponible su definición cuando esto ocurre).

3.6.3 - Control de dependenciasLa tecnología OSGi permite especificar que dependencias tiene un bundle y,

luego, desplegar la aplicación teniendo la seguridad de que solo será admisible por el framework si se cumplen exactamente los requerimientos que esta impone. El tener esta seguridad es primordial para un contexto como el de los agentes móviles de software, donde, por su naturaleza dinámica, pueden coexistir múltiples definiciones asociadas a distintos proveedores.

3.6.4 - Portabilidad OSGi está diseñado para ser liviano (la versión 4 del framework puede ser

implementada y contenida en un JAR de aproximadamente 300 kiloBytes [«OSGi Alliance | About / Benefits of Using OSGi» 2011]) y funcionar en múltiples plataformas (gracias a que está implementado en Java), así como también no depender de un framework particular (siempre que el framework cumpla con el estándar, toda aplicación estándar puede ser ejecutada en él sin temor a incompatibilidades). Estas características coinciden con las necesidades de la infraestructura que acoja a los agentes móviles, principalmente porque es menester que estos puedan desplazarse por la mayor cantidad de entornos posibles (de modo de no limitar su movilidad).

32

Servicio de movilidad en JADE San Martín, Matías Ignacio

Capítulo 4Servicio de movilidad en JADE

En este capítulo se describen los servicios de JADE asociados con la movilidad de los agentes de software. Se discutirá su implementación actual y algunas de sus limitaciones que inspiraron el desarrollo del presente trabajo .

4.1 - Introducción a los servicios de movilidad de JADE

JADE cuenta con dos servicios de movilidad, uno que permite migrar agentes entre contenedores de la misma plataforma (conocido como servicio de movilidad intra-plataforma) y otro que permite transportar agentes entre diferentes plataformas (servicio de movilidad inter-plataforma o IPMS por su sigla en inglés). El primero se encuentra incluido como parte del núcleo principal del framework, en cambio, el último corresponde a un complemento (plug-in) que se puede agregar al framework, pero que no se incluye con la versión por defecto.

4.2 - Servicio de movilidad intra-plataforma

4.2.1 - GeneralidadesEl “servicio de movilidad intra-plataforma” o “servicio de movilidad de agentes”,

como se lo nombra en la literatura [F. L. Bellifemine, Caire, y Greenwood 2007, 117–119], es un servicio (ver sección 2.2.2) que provee a los agentes de software la capacidad de moverse entre distintos contenedores dentro de la misma plataforma. Como este servicio provee únicamente movilidad dentro de una misma plataforma, es posible implementar la comunicación de forma eficiente y propietaria, permitido porque FIPA no requiere el uso de protocolos estándar en esta situación (ver capítulo 2.3). Este servicio aprovecha la flexibilidad del “servicio de comunicación entre contenedores” de JADE (ver sección 2.2.3) para realizar la transferencia de datos necesaria para la migración de agentes. De esta forma, se logra el objetivo sin necesidad de agregar un nuevo modelo de transporte de información.

4.2.2 - Implementación actualLa siguiente descripción está basada en [F. L. Bellifemine, Caire, y Greenwood

2007, 117–119] y en el código fuente de JADE, disponible en [«JADE» 2012].

Cuando el “servicio de movilidad de agentes” recibe el requerimiento de migrar un agente a otro contenedor, la primera acción que se lleva a cabo es modificar el estado

33


del agente para indicar que se encuentra “en transito”. Esto causa, a su vez, que el agente deje de ejecutar sus actividades (impidiendo que se siga programando la activación de sus comportamientos), de forma tal que pueda ser migrado a destino.

Antes de transportar al agente a destino, el “servicio de movilidad de agentes” genera un comando vertical ofreciendo un punto de extensión (de acuerdo a la arquitectura de distributed coordinated filters, introducida en la sección 2.2.2) y permitiendo saber al resto de los servicios que el agente está a punto de cambiar de contenedor.

Como se mencionó en la introducción a agentes móviles (sección 1.1.2), la migración de un agente debe involucrar la transmisión de su código y estado, pudiendo ser este último solo el estado de las variables (weak migration) o también el estado de ejecución (strong migration). En JADE, un agente se migra únicamente cuando no se está ejecutando ninguno de sus comportamientos asociados. Sin embargo, dado que el estado de las variables de los comportamientos y del agente representan cual es el siguiente paso en su ejecución, por más que no se transporte el estado de ejecución per se, se dice que el tipo de migración es not-so-weak [F. Bellifemine et al. 2008]. Para la migración y reconstrucción del agente en destino, se usa el mecanismo de serialización ofrecido por Java. Este permite persistir un objeto como un arreglo de bytes para luego, con esta información y la definición de la clase asociada, poder crear otra instancia que represente el mismo estado [«Java Object Serialization Specification: Contents» 2012]. Como parte de la migración, la información serializada es transmitida mediante un comando horizontal al contenedor destino.

Como el contenedor destino puede estar ubicado en una máquina virtual de Java distinta al contenedor de origen, es necesario asegurarse que las mismas clases que utilizaba el agente en la fuente estén también disponibles en la meta. Esto es requerido para que pueda llevarse a cabo de forma correcta el proceso de deserialización del estado del agente. Para lograr esto, el “servicio de movilidad de agentes” usa una especialización de un class loader (ver sección 3.2) que implementa la capacidad de requerir clases de un contenedor remoto mediante el uso de comandos horizontales. Dichas clases son pedidas unicamente cuando son necesitadas y deben ser cargadas en el correspondiente class loader. Se mantiene un class loader independiente asociado a un par [nombre de agente , identificador de contenedor origen], lo que permite evitar conflictos entre distintas clases homónimas que definan a diversos agentes.

Finalmente, cuando el agente es correctamente deserializado, un hilo es creado para ejecutarlo. Luego, se da inicio al proceso de “reinicio” del agente, que es el encargado de activar su funcionamiento en el nuevo contenedor. Por último, todos los mensajes que se hubieran generado con destino al agente migrado, son redirigidos a su nueva ubicación, permitiendo que el contenedor origen puede indicar que la migración fue exitosa y eliminar su copia local del agente. De esta forma se completa

34


el proceso de migración.

En la Ilustración 4 se presenta un esquema del proceso recién descripto.

Como información adicional, cabe mencionar que JADE ofrece, además de la

35

Ilustración 4: Esquema de proceso de migración intra-plataforma


capacidad de migrar un agente de un contenedor a otro, la posibilidad de clonar al agente en otro contenedor. Esto es, crear una copia que solo difiera en su identificador. El proceso de clonación es equivalente al de migración, difiriendo unicamente en que se evita eliminar la instancia local del contenedor de origen.

4.3 - Servicio de movilidad inter-plataforma

4.3.1 - GeneralidadesEl “servicio de movilidad inter-plataforma” (IPMS) se distribuye como un

complemento de JADE que puede ser instalado con el objeto de ofrecer a los agentes la capacidad de desplazarse entre distintas plataformas [«About | IPMS» 2012]. La comunicación entre plataformas (necesaria para la migración) fue implementada intentando mantener compatibilidad con la especificación de FIPA para el “soporte de movilidad en la administración de agentes” (cabe aclarar que fue definida como obsoleta en Mayo del 2002 [«[FIPA00087]» 2012]). Solo se realizaron algunos cambios que permitieron diferenciar la fase de transporte del agente respecto de la de activación en destino [F. L. Bellifemine, Caire, y Greenwood 2007, 119–121].

Para la transferencia del agente a la plataforma destino, se utiliza el servicio de transporte de mensajes implementado en JADE (MTS), que cumple con la especificación de FIPA para el transporte de mensajes de agentes (ver sección 2.3.3). Esto tiene como ventajas que no es necesario un canal de transmisión adicional entre las plataformas y, por otro lado, que cualquier plataforma que cumpla con dicha especificación de FIPA podrá procesar los mensajes involucrados (independientemente de si es capaz de interpretarlos para una migración exitosa). Como desventaja se tiene que, al usar un formato de mensaje de propósito general, la transmisión de datos no se puede hacer de forma tan eficiente como podría lograrse si se utilizara uno propietario y para el fin específico.

4.3.2 - Implementación actualLa siguiente descripción está basada en [F. L. Bellifemine, Caire, y Greenwood

2007, 119–121] y en el código fuente del complemento, disponible en [«Downloads | IPMS» 2012].

En la actual implementación, el proceso de migración de los agentes es coordinado por un agente especial conocido como “agente administrador de la movilidad” (Agent Mobility Manager o AMM) que es el que se encarga del envío de los mensajes ACL (según lo especificado por FIPA).

El servicio de migración de un agente hacia otra plataforma fue implementado tratando de ser lo más transparente posible para el usuario y los desarrolladores de los agentes. En particular, para indicar que un agente desea migrarse a una plataforma distinta, solo basta utilizar el identificador de la plataforma destino. Así, y gracias a

36


que existe una diferenciación entre un indicador de contenedor y uno de plataforma, es posible para el servicio de migración inter-plataforma darse cuenta que debe actuar en lugar de que se utilice el mecanismo de movilidad intra-plataforma.

En JADE el punto de inicio de un pedido de migración (ya sea inter o intra-plataforma) es el servicio de movilidad intra-plataforma. Gracias a que dicho servicio genera un punto de extensión mediante el uso de un comando vertical, es posible para el servicio de movilidad inter-plataforma interceptar los pedidos de migración hacia una plataforma distinta y tratarlos por su cuenta. De esta forma es que se logra la solución transparente que se mencionó en párrafos anteriores.

En su última versión10 el IPMS permite utilizar distintas estrategias para la transmisión de las clases que componen la definición del agente. Brevemente, estas son (descripción obtenida de un archivo de texto que funciona como documentación distribuida junto con el código del complemento):

1. Push Cache Transfer Protocol (PCTP): todo el código es transmitido en un único mensaje cada vez que el agente se desplaza. Se implementa un mecanismo (cache) para evitar tener que transferir el código si el agente ya fue migrado previamente al mismo destino.

2. On Demand Transfer Protocol (ODTP): solo las partes requeridas del código son transmitidas cuando son necesarias (este enfoque es equivalente al usado por el “servicio de movilidad intra-plataforma”).

3. Fragment Transfer Protocol (FTP): es equivalente a PCTP, pero el código es transmitido en múltiples mensajes en lugar de uno solo (para evitar utilizar mensajes demasiado grandes).

4. REST Transfer Protocol (RESTTP): en este caso, se usan dos conexiones HTTP11 para la transmisión de la información. El mecanismo de comunicación mediante mensajes ACL (MTS) se usa para coordinar el proceso.

Salvo en la estrategia ODTP, todas cuentan con la ventaja de que una vez terminado el proceso de migración, no hay necesidad de mantener la plataforma de origen activa para asegurar que el agente pueda ser ejecutado correctamente (ya que se dispone de la definición completa del mismo). La estrategia RESTTP resulta la más eficiente de las que ofrecen independencia con la plataforma origen, debido a

10 La última versión de IPMS se puede acceder en http://jipms.svn.sourceforge.net/viewvc/jipms/trunk-devel/, sin embargo, cabe resaltar que dicha versión corresponde a un proyecto en desarrollo (no hay producto liberado oficialmente) y actualmente no presenta actividad (su último cambio tiene dos años de antigüedad).

11 Hypertext Transfer Protocol. Se refiere al lector a http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol para más información.

37

http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

http://jipms.svn.sourceforge.net/viewvc/jipms/trunk-devel/


que el modelo REST12 puede transmitir la información de una forma más óptima que los mensajes ACL. En contraposición, el método RESTTP tiene la desventaja de requerir un nuevo canal de transmisión de datos. Finalmente, la estrategia ODTP tiene la gran ventaja de evitar la transmisión de datos que no son necesarios, pero mantiene una dependencia con la plataforma origen en caso de que se requiera una clase que aún no haya sido transmitida.

Para poder determinar cual es todo el código que define a un agente, el IPMS ofrece dos enfoques: en el primero se requiere que el desarrollador del agente agrupe de forma manual dicho código en un archivo de tipo JAR (Java Archive) y, en el segundo, se ofrece un mecanismo que detecta automáticamente las clases usadas por un agente y genera el paquete sin intervención del usuario. Si bien la última alternativa resulta la más cómoda, la lógica implementada cuenta con algunas limitaciones y puede no ser capaz de reconocer todas las clases necesarias (por ejemplo, en caso de que se usen mecanismos de reflexión para cargar clases) [Ametller-Esquerra y Cucurull-Juan 2012].

En lo que respecta a la seguridad, hasta la corriente implementación del servicio, no existe un mecanismo de control integrado. Actualmente, el control de acceso solo puede lograrse mediante el uso de un modelo de transporte de mensajes seguro o mediante otras herramientas externas que no están directamente relacionadas con la plataforma de JADE [Ametller-Esquerra y Cucurull-Juan 2012].

En la Ilustración 5 se presenta un esquema del proceso de migración inter-plataforma.

12 Puede referirse a http://www.ibm.com/developerworks/webservices/library/ws-restful/ para más información.

38

http://www.ibm.com/developerworks/webservices/library/ws-restful/


39

Ilustración 5: Esquema del proceso de migración inter-plataforma


4.4 - Limitaciones en el servicio de movilidad (intra-plataforma)

El presente trabajo está acotado al servicio de movilidad intra-plataforma, sin embargo, a fin de obtener un análisis más completo, se discutirá de manera más superficial el servicio de movilidad inter-plataforma.

Como fue descripto en la sección correspondiente al servicio de movilidad intra-plataforma (4.2.2), este mantiene un class loader por cada par [nombre de agente , identificador de contenedor origen], lo que previene conflictos ante la migración de dos agentes cuyas clases que lo definen son distintas pero con el mismo nombre. Esto es válido debido a que el nombre (AID, ver sección 2.3.2) identifica a un agente de forma unívoca en toda la plataforma y, por lo tanto, no existe la posibilidad que dos de ellos compartan esta propiedad en un momento determinado. Sin embargo, esto presenta un conjunto de dificultades que se describen en las siguientes subsecciones.

4.4.1 - Dificultad 1 – No se puede actualizar el agente

El hecho de “encapsular” las clases en distintos class loaders permite mantener distintas versiones de clases homónimas para distintos pares [nombre de agente , identificador de contenedor origen]. Sin embargo, no diferencia entre distintas versiones de clases homónimas para el mismo par. Esto hace que sea imposible migrar una versión actualizada de un agente manteniendo su nombre y desde el mismo contenedor origen.

En general, este caso de uso es poco común ya que Java no permite actualizar la versión de una clase que ya ha sido cargada (según lo descripto en la sección 3.2.2) y, además, en JADE las clases son cargadas (mediante el classpath) al iniciar la ejecución de la JVM (máquina virtual de Java) que contendrá al contenedor. Por lo tanto, durante la ejecución de una instancia de un contenedor, se está seguro que la versión de la clase no puede cambiar. No obstante, esta consideración excluye el caso que corresponde al reinicio de un contenedor. En la implementación actual de JADE, es válido detener la ejecución de un contenedor y luego volver a iniciarlo manteniendo el mismo identificador. Si esto se combina con la creación de un agente con el mismo nombre que uno ya migrado anteriormente y que utilice una clase homónima (pero que sea distinta) con alguna usada por este último, el mecanismo de class loaders descripto no permitiría utilizar la “nueva versión” de la clase. Esto puede provocar un comportamiento inesperado del agente ante la migración, debido a que en el contenedor destino se estaría usando una versión incorrecta de la clase.

4.4.2 - Dificultad 2 – Transmisión innecesaria de las clases

El hecho de que cada par [nombre de agente , identificador de contenedor origen]

40


esté asociado a un class loader y, gracias a la regla de consistencia de estos (descripta en la sección 3.2.2), ante una nueva migración del agente, no será necesario transmitir las clases ya transferidas al contenedor destino. Por el contrario, debido a que no se utiliza una jerarquía de class loaders que permita reutilizar estas definiciones (ver la regla de delegación en la sección 3.2.2), la migración de otro agente (con distinto nombre) implicará que todas las clases que lo definen serán transmitidas, independientemente de si estas son las mismas que ya se encuentran en otro class loader (utilizado para otro agente). Esto representa un uso innecesario de ancho de banda entre los contenedores, que podría prevenirse mediante el uso de un mecanismo más sofisticado de class loading.

4.5 - Servicio de movilidad inter-plataforma

El IPMS (en su versión actual) asocia cada JAR transmitido a la plataforma, con una suma de verificación (checksum13) que permite re-utilizarlo o diferenciarlo entre otros homónimos. Esto hace que no exista posibilidad de conflicto de versiones, como sí ocurre en el servicio intra-plataforma. Sin embargo, el problema de transmisión innecesaria de clases sigue siendo (en parte) válido, debido a que distintos JAR pueden contener clases en común por ser necesarias para distintos agentes.

13 Puede referirse a http://en.wikipedia.org/wiki/Checksum para más información.

41

http://en.wikipedia.org/wiki/Checksum

OSGi para potenciar a JADE, propuesta de solución


Capítulo 5OSGi para potenciar a JADE, propuesta de solución

Este capítulo es introductorio a la propuesta de solución a las limitaciones encontradas en el servicio de movilidad de JADE elaborada en el presente trabajo. Aquí se describirá el análisis y decisiones de diseño que se realizaron para definir como sería la solución propuesta.

5.1 - Pre-análisis de solución

Analizando las limitaciones en los servicios de movilidad de JADE (presentadas en la sección 4.4 y 4.5), y conociendo las características de la tecnología OSGi (introducidas en el capítulo 3), se deduce que esta puede servir como cimiento para una solución más robusta en lo que respecta a la administración de las clases que definen a un agente implementado en JADE. El uso de OSGi permitiría que las dificultades asociadas al versionado de las clases sea resuelta en forma transparente, lo cual, además de salvar los problemas descriptos, simplificaría la implementación del servicio de movilidad.

En las siguientes subsecciones se presenta la solución propuesta y se analizan las decisiones que llevaron al diseño final.

5.2 - Solución propuesta

En lineas generales, la solución propuesta consiste en implementar un servicio de movilidad (intra-plataforma) que utilice OSGi para la administración de las clases que definen a los agentes. Luego, cada desarrollador de un agente agrupará sus clases en distintos módulos (bundles) como crea conveniente. Finalmente, el servicio de movilidad basado en OSGi (propuesto como solución) se encargará, de forma automática y transparente para el usuario, de detectar cuales bundles están presentes en el contenedor destino y si estos alcanzan para definir al agente migrado. De no contar con los bundles necesarios, se transferirán (sin intervención del usuario) los que faltaren desde el contenedor origen de la migración.

5.3 - Pre-requisitos para la solución

Se definieron dos pre-requisitos fundamentales al momento de diseñar la solución propuesta, estos son:

42



1. No modificar el núcleo de la plataforma (JADE).

2. Transparencia en el uso de la solución.

El objetivo de imponer dichas necesidades es que la solución sea práctica para ser utilizada por la comunidad de usuarios de JADE. A continuación se detallan los fundamentos de las mismas.

5.3.1 - Requisito de no modificar el núcleo de JADE

Gracias a que JADE utiliza la licencia LGPL, es posible modificar su implementación siempre y cuando el trabajo derivado este licenciado bajo los mismos términos. Al no haber restricciones respecto de los cambios que se pueden realizar, se dispone de gran flexibilidad al momento de implementar mejoras o funcionalidades alternativas a las ofrecidas por la versión oficial de la plataforma. Por otro lado, el iniciar una bifurcación (o fork14) del proyecto para poder añadir los cambios necesarios para una solución aledaña, implica que se deben mantener para dicha versión las correcciones que se realizaran en el proyecto principal o, de lo contrario, resignarse a que esta quede obsoleta con el pasar del tiempo.

Para evitar que el mantenimiento de la solución ofrecida dependa de la administración de una versión alternativa de la plataforma JADE, se impuso como requisito fundamental que el núcleo central de esta no se vea modificado (eliminando la necesidad de crear un fork). De esta forma, las correcciones o cambios realizados en el núcleo de JADE pueden evolucionar de forma independiente a las que se realicen en la solución y, además, los proyectos que dependan de cada una no necesariamente se verán afectados por los cambios realizados en la otra.

5.3.2 - Requisito de transparencia en el usoSi bien el uso de la tecnología OSGi (aunque sea de forma indirecta) requiere

cierto conocimiento sobre esta [R. S. Hall 2011]; para permitir una amplia adopción de la solución propuesta, es deseable que se exija la menor cantidad de conocimientos (extras) posibles, y se ofrezca un modelo de trabajo similar al que se usa en la versión regular de JADE. Es por esto que se definió como parte de los requisitos que, dentro de las limitaciones concebibles, la nueva funcionalidad ofrezca un uso familiar al servicio de movilidad existente de forma nativa (transparencia).

5.4 - Decisiones de diseño

Al momento de tomar las decisiones que finalmente definirían el diseño a usar, se siguieron los lineamientos que permitieran cumplir con los requisitos impuestos (ver

14 Puede referirse a http://en.wikipedia.org/wiki/Fork_%28software_development%29 para más información.

43

http://en.wikipedia.org/wiki/Fork_(software_development)



sección 5.3) y, además, se buscó proveer una solución modular y que pudiera evolucionar a lo largo del tiempo. En los distintos títulos de esta sección se discuten las principales decisiones tomadas, evaluando las alternativas consideradas y describiendo la razón por la cual se terminó eligiendo una por sobre las demás.

5.4.1 - Integración del framework de OSGi y JADE

La funcionalidad de OSGi es ofrecida en forma de frameworks por distintas implementaciones de la especificación. A partir de la versión 4.2 de OSGi [The OSGi Alliance 2009] se definieron mecanismos de uso genéricos que permiten trabajar de manera independiente a la implementación específica del framework. Gracias a esto, al definir la integración con la aplicación, no es necesario establecer restricciones en cuanto a cual implementación se va a utilizar.

Por otro lado, existen distintas alternativas respecto de como acceder al framework desde el punto de vista de una aplicación (en este caso, JADE). A continuación se presentan las variantes contempladas al realizar este trabajo.

Alternativa 1 – OSGi y JADE en paraleloEn [Po-Cheng Huang et al. 2009] y [Nam-Ho Kim et al. 2007] se propone el

modelo de integración entre JADE y OSGi esquematizado en la Ilustración 6.

En este modelo de integración, el framework de OSGi y JADE se ejecutan en paralelo como dos procesos independientes, y la comunicación entre ambos se realiza mediante el intercambio de mensajes.

Esta propuesta resulta válida si se desea utilizar OSGi para consumir servicios desde JADE. Además, tiene la gran ventaja de que no requiere ninguna alteración sobre JADE, sino que solo basta con implementar un agente encargado de las interacciones con OSGi.

Sin embargo, en esta opción no se está integrando la solución al modelo de agentes, sino que se está representando un modelo de servicios ofrecidos a estos. Si

44

Ilustración 6: Integración OSGi en paralelo con JADE



bien es posible simular una solución al problema (por ejemplo, ofreciendo la funcionalidad real de los agentes mediante bundles que evolucionan en lugar de cambiar la implementación de los primeros), se estaría cambiando el paradigma de trabajo.

Esta solución se adapta correctamente al requerimiento de no modificar JADE (ver sección 5.3.1), pero no resulta simple de utilizar (como lo requiere el punto enunciado en la sección 5.3.2) ya que demanda que los usuarios de JADE comiencen a contemplar los problemas desde un enfoque más orientado a los servicios que a uno basado en los agentes de software. Por este motivo, se considera que esta propuesta no resulta conveniente para la problemática presentada en este trabajo.

Alternativa 2 – JADE sobre OSGiEn [Spanoudakis y Moraitis 2008] y [Ribeiro y Soares 2011] proponen un

esquema en el que JADE es desplegado como un bundle y se ejecuta dentro de un framework OSGi. En la Ilustración 7 se esquematiza esta propuesta.

Gracias a que en esta solución los agentes se implementan como bundles, es posible un correcto versionado de los mismos y, por lo tanto, no deberían presentarse los problemas mencionados en la sección 4.4. Esta propuesta cuenta con la ventaja adicional que, al no ser transparente para JADE el hecho de que se está trabajando con OSGi, este podría utilizar alguna de las otras características de dicha tecnología (por ejemplo, la capa de servicios presentada en la sección 3.5.3).

Como inconveniente, este enfoque impone la necesidad de generar un despliegue alternativo de JADE (en forma de bundle para OSGi), lo cual entra parcialmente en conflicto con el requerimiento impuesto en la sección 5.3.1. Además, esta solución exige que los usuarios de JADE trabajen directamente con el framework de OSGi (para poder iniciar la plataforma sobre él), y esto se contrapone

45

Ilustración 7: Integración JADE sobre OSGi



con el requerimiento definido en la sección 5.3.2.

Alternativa 3 – OSGi empotrado en JADEExiste otra forma de integrar una aplicación con un framework de OSGi, que

consiste en empotrar este en la aplicación. Esto se logra haciendo que el framework sea iniciado de forma explícita dentro de la aplicación [R. Hall et al. 2010, 427]. Dicho esquema es el representado en la Ilustración 8.

Al utilizar este esquema, la existencia del framework de OSGi queda oculta dentro de JADE y, gracias a la posibilidad de instalar servicios como complementos, no es necesario modificar el núcleo de este último.

Debido a que existe una distinción entre lo que se ejecuta dentro del framework de OSGi y por fuera de él, es necesario definir una interfaz común que permita comunicar a ambos [R. Hall et al. 2010, 427–430]. Esto es lo que se representa en el esquema de la Ilustración 8 diferenciando a “Agente Base” y “Comp(ortamiento) Base” respecto de “Agente (Bundle)” y “Comp. (Bundle)”. “Agente Base” y “Comp. Base” representan las clases base que se encuentra en la distribución oficial de JADE y de la cual derivan todas las implementaciones de agentes y comportamientos (ver sección 2.2.4). Por otro lado, lo indicado como “Agente (Bundle)” y “Comp. (Bundle)” representan las clases específicas que definen la funcionalidad de los agentes (creadas por los desarrolladores, usuarios de JADE). Así, OSGi se ocupa de administrar las distintas versiones específicas de las clases, y el núcleo de JADE solo trabaja con las clases bases.

Esta es la opción elegida para la solución propuesta ya que brinda transparencia (el usuario no maneja explícitamente el framework de OSGi) y no es necesario modificar al núcleo de JADE. Para poder realizar la integración, se creo un servicio que iniciará el framework de OSGi y se ocupará de identificar cuales bundles son requeridos por cada agente y cuales hacen falta transportar para poder migrar a cada

46

Ilustración 8: Integración con OSGi empotrado en JADE



uno de estos.

5.4.2 - Determinación de que bundles son necesarios para los agentes

Gracias a la definición explicita de las inter-dependencias entre bundles, el framework de OSGi es capaz de identificar que asociaciones debe realizar par resolver cada uno (ver sección 3.5.1). Sin embargo, (hasta el momento de implementar la solución propuesta) esta lógica no es expuesta por el framework mediante una interfaz que pueda consumirse de forma tal de identificar, dado un bundle, cuales otros son suficientes como para resolverlo y, en caso de no poder hacerlo, cuales serían necesarios incorporar. Existen distintas alternativas para implementar esta lógica, en lo restante de esta sección se presentan las analizadas al momento de decidir cual usar en el prototipo realizado.

Resolución de dependencias dadas las asociaciones en el origen

La lógica más simple que podría utilizarse para asegurar que los bundles que implementan un agente puedan ser correctamente resueltos en destino, consiste en determinar cuales son los bundles asociados en el contenedor origen y verificar que existan los mismos en la meta. Esta solución es factible y simple de implementar ya que el framework de OSGi permite identificar cuales son las asociaciones (wires) existentes, dado un bundle específico que esté resuelto. Luego, simplemente se verificaría en destino cuales de la lista de bundles indicados existe, y se requerirían al origen aquellos que no se encontraran.

El problema que presenta esta lógica es que puede significar la transmisión innecesaria de datos. Un bundle podría resolverse utilizando otros que no sean exactamente los mismos que los que se usaban en el origen, pero que ofrecieran los paquetes necesarios. Una de las principales ventajas de OSGi es que permite definir dependencias a nivel de paquetes en lugar de a nivel de bundle (ver sección 3.4) y, al usar el tipo de resolución de dependencia mencionado, no se estaría aprovechando esta capacidad.

Resolución de dependencias mediante heurística de análisis de encabezados

Esta solución propone aprovechar el hecho de que los bundles indican explícitamente que paquetes requieren y exportan, para implementar una lógica capaz de interpretar estos encabezados y decidir cuales bundles serán suficientes o harán falta para resolver al indicado.

Este es el enfoque que sigue actualmente la herramienta Apache Felix Web Console15 (esto pudo verificarse mediante inspección de la implementación correspondiente a la versión 4.0.0, no está documentado en la herramienta). Sin

15 http://felix.apache.org/site/apache-felix-web-console.html

47

http://felix.apache.org/site/apache-felix-web-console.html



embargo, este tipo de análisis puede llegar a ser muy complejo debido a que se pueden definir dependencias muy intrincadas entre bundles.

Resolución de dependencias con OSGi Bundle Repository (OBR)

La OSGi RFC16 112 - Bundle Repository [R. S. Hall y The OSGi Alliance 2006] describe un repositorio de recursos que pueden ser explorados para ser obtenidos y desplegados a necesidad. Este documento trabaja con el concepto genérico de recurso (resource) que expone capacidades (capabilities) y tiene requerimientos (requirements), por lo que un recurso puede representar un bundle, pero también cualquier otra cosa que aplique al concepto.

El concepto expuesto por dicha RFC fue implementado y su interfaz extendida para el framework Apache Felix17 en forma del bundle “Apache Felix OSGi Bundle Repository” [«Apache Felix OSGi Bundle Repository» 2012]. De acuerdo al documento sobre el cual se basa, esta implementación permite trabajar con repositorios (descriptos en formato XML) que posean diferentes recursos (en particular, bundles) y, entre otras cosas, habilita la realización de consultas respecto de cuales de dichos recursos son necesarios para poder satisfacer los requerimientos de otro.

Exactamente la funcionalidad descripta es la que se busca para poder identificar que bundles son necesarios para definir al agente migrado. Solo será necesario asegurarse que en cada contenedor (JADE) existan los repositorios (OBR) que describan todos los bundles disponibles en ellos y, así, poder identificar si se encuentran los necesarios para el agente. En caso de que los bundles presentes no cumplieran los requerimientos, se podrá buscar en el contenedor origen (mediante consultas a la implementación de OBR) cuales bundles serán suficientes para satisfacerlos.

En la versión 5 de la especificación OSGi [The OSGi Alliance 2012a], se creó la “Resource API Specification” que estandariza conceptos equivalentes a los de la RFC mencionada, y que se completa con la “Resolver Service Specification” y “Repository Service Specification” [The OSGi Alliance 2012b]. De esta forma, se permite que dicha funcionalidad se puede implementar de forma genérica para cualquier framework que cumpla con la especificación, eliminando la necesidad de depender de una solución en particular (como es Apache Felix OSGi Bundle Repository). Lamentablemente, al momento de realizar el prototipo presentado (a detallar en la sección 6.2), no se encuentraba disponible una implementación que cumpla con esta especificación, y se tuvo que optar por la integración con la solución específica disponible para el framework Apache Felix.

16 Para más información sobre el concepto de Request for Comments (RFC) se puede referir a http://en.wikipedia.org/wiki/Request_for_Comments

17 http://felix.apache.org/site/index.html

48

http://felix.apache.org/site/index.html

http://en.wikipedia.org/wiki/Request_for_Comments



5.4.3 - Transferencia de datos entre contenedores de la migración

Para la transmisión de los datos necesarios para la migración (por ejemplo, los bundles que hicieran falta), era necesario decidir que enfoque se deseaba seguir: usar IMTP, que es el mecanismo interno que utiliza JADE para la comunicación entre los contenedores de una misma plataforma (ver sección 2.2.3), o utilizar un canal de comunicación alternativo.

Utilizar un canal de comunicación alternativo permitiría elegir uno que fuera óptimo para las necesidades de la solución propuesta. Como lado negativo, esta opción (en general) requiere que se disponga de permisos o necesidades especiales para el uso del mismo (por ejemplo, la apertura de nuevos puertos), y esto no siempre es fácilmente asequible en todos los contextos.

En contraposición, el uso de IMTP puede resultar en transferencias que no son óptimas, pero resulta transparente a nivel administrativo (no se exigen requisitos extra).

Siguiendo con el concepto impuesto por el requerimiento de transparencia en el uso (ver sección 5.3.2), se decidió utilizar el canal basado en IMTP como mecanismo pre-establecido de comunicación.

5.4.4 - Soporte para migración de agentes no empaquetados en bundles

En el servicio ofrecido de forma nativa por JADE, todos los agentes que ejecute el contenedor deben estar definidos por clases localizables por medio del classpath (introducido en la sección 3.2.1), o por aquellas obtenidas como resultado de una migración. En cambio, la solución propuesta define por medio de bundles las clases que utilizan los agentes, siendo que estos pueden ser versionados y utilizados por OSGi.

Si bien es factible diferenciar que clases se obtuvieron del classpath y cuales de un bundle, el permitir que se migren agentes definidos con la primer opción, implica que coexistan dos comportamientos opuestos (el antiguo, sin versionado; y el nuevo, que sí posee esta capacidad). Como con la solución propuesta se busca prevenir los problemas existentes en la opción ofrecida de forma nativa, se decidió no dar soporte a la migración de agentes que no fueran definidos a partir de clases localizadas en bundles. Empero, ya que el uso local de agentes definidos con clases del classpath no presenta los inconvenientes que si presenta la migración de estos, para agentes que no se desean migrar, se posibilita el uso de esta forma de definición.

5.4.5 - Mantenimiento de distintas versiones de un mismo bundle o actualización

Al contar con dos versiones distintas de un bundle, existen dos alternativas para

49



su despliegue, actualizar el original (reemplazándolo) o, por otro lado, instalar el nuevo en simultáneo con el anterior (extendiendo los bundles disponibles).

El actualizar un bundle posibilita que los que requieren sus capacidades puedan utilizar su nueva versión y, además, libera al framework de mantener la instancia antigua. En contraposición, esto exige que los bundles ya resueltos sean refrescados y necesiten pasar por la etapa de resolución nuevamente (según lo descripto en la sección 3.5.2). En este último caso, es factible que, con la versión actualizada, no se satisfagan todas las dependencias que si lo hacían con la versión anterior (lo que, posiblemente, llevaría a demandar que se instale el mismo bundle con su versión anterior, u otro que satisfaga las dependencias insatisfechas).

Instalar una nueva versión del bundle, por otro lado, capacita a posteriores bundles para utilizar la versión actualizada; pero, los que se encuentren ya resueltos y asociados a la versión anteriormente disponible, no se verán afectados por la última. Esto tiene la ventaja de que los módulos ya resueltos no se ven perturbados ante el cambio. Por el contrario, tiene la desventaja de que el framework necesita mantener un bundle adicional y, además, se limita la reutilización de los recursos, siendo que es factible que todos los bundles ya resueltos pudieran trabajar con la versión actualizada (eliminando la necesidad de conservar la previa).

Además de los puntos anteriores, al usar un framework empotrado como parte de la solución propuesta, parte de las clases de la aplicación (JADE) no son administrada por OSGi. Así es que, si se usa el mecanismo de actualización, es menester resolver de forma particular la lógica necesaria para que todas las clases que dependen (aunque sea de forma indirecta) del bundle actualizado, reconozcan el cambio y puedan empezar a usar la nueva versión (es decir, estas clases deben ser “refrescadas” mediante un mecanismo implementado por fuera del framework OSGi).

La actualización de bundles permite que una aplicación pueda sufrir modificaciones sin necesidad de detenerla completamente (ver sección 3.5.2). Por otro lado, en el contexto de agentes móviles de software, si se desea realizar una tarea con una lógica actualizada, es factible designar a un nuevo agente (con dicha lógica) para que resuelva la tarea en lugar del precedente (que implementa la lógica ya obsoleta). Debido a que la actualización de los bundles presenta inconvenientes en cuanto a la administración de las clases de la aplicación, y que su ventaja principal (de actualizar aplicaciones sin necesidad de una detención total) se ve suplida por el paradigma tratado en este trabajo, se determina que resulta más conveniente seguir un enfoque en el cual las distintas versiones de un bundle son instaladas en coexistencia, frente a uno en que se actualizan.

50

Implementación del servicio de movilidad basado en OSGi para JADE


Capítulo 6Implementación del servicio de movilidad basado en OSGi para JADE

Ya contando con una base de las consideraciones realizadas al momento de diseñar la solución propuesta, en este capítulo se detalla como se implementó una versión que sirva como prueba de concepto para verificar la factibilidad del esquema presentado. Se describe el proceso de desarrollo, los componentes principales del prototipo, y las facilidades y dificultades que se encontraron al llevarlo a cabo.

6.1 - Desarrollo del prototipo

El prototipo se desarrolló con dedicación no exclusiva a lo largo de aproximadamente tres meses de trabajo. El objetivo fue crear una versión funcional que permitiera cumplir con la migración de los agentes y aprovechar las capacidades de la tecnología OSGi. Además, se buscó que el mismo sirva como base para una versión que pueda ser utilizada en forma productiva por la comunidad de JADE.

6.1.1 - Tecnologías usadasPara la implementación de este trabajo, se utilizaron las siguientes tecnologías:

• Sistema operativo Linux, distribución Ubuntu en su versión 10.04 (Lucid Lynx) 64 bits.

• Entorno de desarrollo Eclipse [«Eclipse» 2012] en su versión 4.1 y distribución clásica.

• Plug-in para el entorno Eclipse, Subclipse [«subclipse.tigris.org» 2012] en su versión 1.8.8. Este da soporte al entorno Eclipse para el trabajo con la tecnología Subversion.

• Subversion [«Apache Subversion» 2012] en su versión 1.6.6. Esta ofrece un sistema de control de versiones. Se creó un repositorio local con el objeto de facilitar el control a los cambios realizados en las sucesivas iteraciones de desarrollo de los componentes del prototipo implementado.

• Java Standard Edition Development Kit [«Java SE Overview» 2012] versión 6. Específicamente, se utilizó la versión del paquete para la distribución Ubuntu openjdk-6-jdk (6b24-1.11.4-1ubuntu0.10.04.1).

• Framework OSGi Apache Felix [«Apache Felix» 2012] versión 4.0.2.

• Java Agent DEvelopment Framework (JADE) versión 4.1. Cabe señalar que

51



la solución es funcional también en la nueva versión 4.2.

• Proyecto Google Guava [«guava-libraries» 2012]. Este consiste en un conjunto de bibliotecas utilitarias en Java. En realidad, se utilizó el proyecto Guava-OSGi [«guava-osgi» 2012] que es un empaquetado en forma de bundle del primero. En particular, la dependencia es con los paquetes com.google.common.hash y com.google.common.io, en su versión 11.0.1 (que es la que está disponible en guava-osgi).

• Apache Felix Bundle Repository [«Apache Felix OSGi Bundle Repository» 2012], Bundle-Version 1.6.6. Este corresponde al bundle que implementa la funcionalidad de OBR mencionada en la sección 5.4.2. Disponible como parte de la distribución del framework Apache Felix, mencionado previamente.

6.1.2 - Acceso al prototipoEl prototipo implementado es distribuido bajo la licencia GNU Lesser General

Public License (LGPL) versión 2.1 [«LGPL v2.1» 2012] y puede ser accedido desde la página del proyecto en https://sourceforge.net/projects/jade-osmoses/.

6.2 - Detalle del prototipo de solución

Las funcionalidades que conforman la propuesta, se pueden clasificar en tres grandes partes:

1. El servicio de movilidad

2. La comunicación entre contenedores

3. La resolución de dependencias faltantes

Estos se describen en las siguientes subsecciones.

6.2.1 - Servicio de movilidad basado en OSGiEl servicio de movilidad es el núcleo de la solución propuesta. Este consisten en

un servicio de JADE (ver sección 2.2.2) y está basado en el de movilidad intra-plataforma que se dispone por defecto en dicho framework (presentado en la sección 4.2).

Para ofrecer el mayor grado de compatibilidad posible con las funcionalidades basadas en el servicio de movilidad pre-existente, la implementación realizada se hizo manteniendo intactas sus interfaces. Así, es posible utilizar el servicio provisto de igual forma que el anterior (algunos de los problemas y facilidades relacionadas a este punto se discutirán en las secciones 6.3 y 6.4).

El servicio de movilidad implementado se encarga de iniciar el framework OSGi empotrado (ver sección 5.4.1), de forma de poder utilizar las funcionalidades ofrecidas por esta tecnología. Luego de iniciado, se procede a la carga de los bundles

52

https://sourceforge.net/projects/jade-osmoses/



necesarios para el funcionamiento del servicio y de los que se utilizarán para definir los agentes a ser lanzados de forma local.

De manera nativa, JADE permite asociar propiedades a las clases que se utilizarán para definir los agentes a iniciar. Para poder interpretar y actuar en respuesta a propiedades particulares, es necesario registrar en el framework una instancia que implemente la interfaz jade.util.ObjectManager.Loader. Aprovechando esta capacidad, al inicio del servicio de movilidad propuesto, se registra un Loader encargado de interpretar las clases que se caractericen (mediante propiedades) por poseer la especificación de un bundle desde donde se obtendrá dicho recurso. Es así como se logra diferenciar entre las clases para agentes que serán administrados por OSGi (y podrán ser migrados con el servicio ofrecido) y las que corresponden a agentes que se deberán resolver por medio del mecanismo de classpath (que funciona en la versión original del servicio de movilidad).

El último cambio esencial que se hizo al servicio de movilidad intra-plataforma ofrecido por JADE, corresponde a la forma de actuar al momento de la migración de las clases asociadas al agente. Esta operación fue modificada para que junto con la información del agente serializado (ver el proceso de migración, descripto en la sección 4.2.2), se transmita el identificador (nombre simbólico y versión) del bundle al cual está asociado (es decir, donde se define la sub-clase de Agent asociada). De este modo, el contenedor que recibe al agente puede realizar las verificaciones (y pedidos) necesarios para asegurarse que dicho bundle sea resuelto (ver la descripción sobre resolución de bundles en la sección 3.5.2).

6.2.2 - Comunicación entre contenedores de JADE

Como se mencionó en la sección 5.4.3, la transferencia de datos necesarios para el servicio de movilidad propuesto es realizada mediante IMTP (comandos horizontales). Al no modificar la interfaz del servicio de movilidad nativo de JADE, no fue posible agregarle los comandos horizontales necesarios para la transmisión de la información relacionada a la nueva funcionalidad. Es por este motivo que se decidió implementar otro servicio accesorio (nombrado ImtpConnectionTransport), que permitiera definir tales comandos.

El servicio ImtpConnectionTransport se implemento de tal forma que permitiera a sus usuarios obtener “conexiones” con otros contenedores (en Java, definidas mediante un par de clases derivadas de java.io.InputStream y java.io.OutputStream). Estas se crean con el mismo esquema con que se realizan conexiones para comunicaciones basadas en el protocolo TCP (es decir, mediante un extremo que se conecta activamente a otro que espera de forma pasiva). Luego, los que trabajen con dichas “conexiones” podrán hacerlo sin tener en cuenta que, de forma subyacente, las transmisiones se realizan mediante IMTP.

Basándose en el hecho de que todas las transmisiones se realizan por medio de

53



una interfaz uniforme que usa “conexiones”, el servicio de movilidad implementado ofrece la capacidad de definir (mediante configuración) mecanismos de comunicación alternativos. De esta forma, se da la posibilidad de cambiar el protocolo utilizado (por ejemplo, para que use uno más eficiente para su fin), sin necesidad de cambiar el IMTP usado en toda la plataforma.

Aprovechando la abstracción mencionada y con objeto de disponer de un mecanismo alternativo para la comunicación, que no dependa de un servicio externo y que no requiera contenido adicional para la transmisión de datos (como sí lo hace el mecanismo basado en IMTP, que debe incluir los datos necesarios para su funcionamiento); se ofrece, junto al prototipo, una implementación de la interfaz de comunicación basada en sockets TCP. Ya que las “conexiones” expuestas son similares a las usadas para operar con TCP, la implementación de las clases que permiten utilizar esta tecnología para la comunicación, no presenta mayores dificultades.

6.2.3 - Resolución de dependencias necesarias para la migración

Es necesario una lógica de resolución de dependencias debido a que, de igual forma como ocurre con el servicio de migración intra-plataforma nativo de JADE (ver sección 4.2.2), en la solución propuesta puede suceder que el contenedor destino no disponga de todos los recursos necesarios para definir al agente migrado. Esta lógica se implementó como bundles, aprovechando la modularidad y flexibilidad que ofrece la tecnología OSGi. La arquitectura de este mecanismo se esquematiza en la Ilustración 9 (al final de la subsección) y los bundles implementados se detallan a continuación.

Bundle para la transmisión de recursosEn este módulo se define la interfaz necesaria para recibir requerimientos y enviar

los recursos asociados. Ambos conceptos está íntimamente relacionados con los del mismo nombre definidos por la especificación de OBR descripta en la sección 6.2.3.

En la implementación del prototipo, este bundle publica un servicio OSGi (ver descripción de la capa de servicios de OSGi en la sección 3.5.3) que permite realizar un handshaking18 por el cual se acuerda la versión del protocolo de intercambio de información que se va a usar en la comunicación. El uso de este mecanismo permite la evolución de dicho protocolo y asegura la compatibilidad entre distintas versiones, gracias a que es posible identificar cual versión soporta el otro extremo de la comunicación.

Bundle para la recepción de recursosEste representa la contrapartida al “Bundle para la transmisión de recursos“ y

18 Se refiere al lector a http://en.wikipedia.org/wiki/Handshaking para más información sobre este concepto.

54

http://en.wikipedia.org/wiki/Handshaking



define la interfaz necesaria para requerir y recibir recursos.

Al igual que el otro extremo, este publica un servicio OSGi que permite decidir cual protocolo de transmisión de datos se utilizará.

Bundle para la resolución y pedido de dependenciasEste bundle implementa la lógica necesaria para determinar, dado un bundle

específico, que dependencias faltan satisfacer para poder resolverlo. Para lograr su cometido, esta lógica consume la funcionalidad ofrecida por la implementación de OBR disponible (ver sección 5.4.2). Cabe resaltar que las dependencias se refieren a paquetes faltantes (ver sección 3.5.1) y no a módulos (bundles) completos. Trabajando de esta forma se maximiza la modularidad y se minimiza la transmisión de datos (como se describió en la sección 4.4.2).

Esta funcionalidad consume el servicio publicado por el “Bundle para la recepciónde recursos” para poder realizar los pedidos por los recursos que determinase que hicieran falta. Por otro lado, este bundle publicá un servicio OSGi que permite acceder a su funcionalidad y que finalmente es consumido por el servicio (JADE) de movilidad que corresponde a la solución propuesta. Notar que es el contenedor destino el que utiliza este servicio, siendo este quien debe satisfacer las dependencias necesarias para poder definir al agente recibido.

Bundle para el envío de dependenciasEste es el encargado de recibir los pedidos realizados por el “Bundle para la

resolución y pedido de dependencias” y de responder con los recursos disponibles que sirvan para satisfacer dichos requisitos.

Este consume el servicio publicado por el “Bundle para la transmisión derecursos” y se apoya en OBR para determinar cuales de los recursos disponibles serán adecuados para cumplir con el pedido recibido. El servicio (OSGi) publicado por este bundle será aprovechado por el contenedor que desea migrar un agente, para ofrecer cualquier recurso que el destino de la transferencia pudiera necesitar para completarla correctamente.

55



6.3 - Dificultades en la implementación de la solución

Debido a las tecnologías involucradas y a las características de la solución propuesta, existieron algunas dificultades durante la implementación de la prueba de concepto. En las siguientes subsecciones se detallan las principales y se describen que medidas se tomaron para sobrellevar los inconvenientes.

6.3.1 - El núcleo de JADE depende del servicio de movilidad y de su interfaz

En JADE un servicio se compone a partir de los siguientes elementos (esta descripción esta basada en el libro [F. L. Bellifemine, Caire, y Greenwood 2007, 136–144] y solo detalla los aspectos pertinentes a la presente discusión, para un tratamiento más detallado, se refiere al lector a dicha bibliografía):

• Implementación de la interfaz jade.core.Service o especialización de la clase jade.core.BaseService (que implementa la primera y ofrece definiciones por defecto para la mayoría de sus métodos): Esta es la clase principal del servicio y es la única clase indispensable para la existencia del mismo.

• Si se desea que el servicio pueda ser distribuido entre múltiples contenedores (notar que esto no es obligatorio), se debe crear una interfaz (conocida como “interfaz horizontal”) que extienda a

56

Ilustración 9: Arquitectura de mecanismo de resolución de dependencias en el prototipo implementado



jade.core.Service.Slice y que defina todos los métodos que pueden ser invocados remotamente (desde otro contenedor).

• Para un servicio distribuido, la clase que ofrece el acceso al servicio en el contenedor remoto (conocida como proxy), debe extender jade.core.SliceProxy e implementar la interfaz horizontal (mencionada en el ítem anterior). Esta clase tiene el principal propósito de convertir las llamadas a sus métodos en comandos horizontales que serán enviados al contenedor destino. Los proxies son cargados dinámicamente cuando son necesarios y su clase debe llamarse como el nombre del servicio al que están asociados y terminados con la palabra “Proxy” (por ejemplo, si el servicio nombrado “ar.uba.fi.servicioFoo” define un proxy, la clase del último debe llamarse ar.uba.fi.servicioFooProxy).

• Implementación de la “interfaz horizontal” (Slice). Esta recibe y ejecuta la funcionalidad asociada a los comandos horizontales enviados por el proxy (descripto en el ítem anterior).

• Si se desea que los agentes puedan utilizar de forma directa el servicio, este debe ofrecer una clase auxiliar (conocida como helper) que defina los métodos para acceder al mismo.

Como el servicio de movilidad intra-plataforma (descripto en la sección 4.2) es utilizado por el núcleo de JADE para la migración de los agentes móviles, distintas partes de este dependen de las clases específicas que definen al primero (en especial, del proxy y helper). Dado que se desea que el servicio implementado pueda ser integrado al núcleo de JADE de la forma más transparente posible, no se debe modificar su interfaz (conjunto de métodos y comandos asociados), porque, en caso contrario, las clases que dependen de esta dejarían de funcionar.

Esta limitación hizo que no se pudieran agregar nuevos comandos horizontales para el servicio implementado, forzando, por ejemplo, la necesidad de crear el servicio adicional descripto en la sección 6.2.2. También fue preciso mantener comandos que pierden el sentido con la solución presentada. Un ejemplo de esto, es el comando que se utiliza para la transmisión de una clase en particular, siendo que, en la solución propuesta, las transferencias se hacen de a módulos completos (bundles).

Para prevenir comportamientos indefinidos, los comandos que no aplican a la nueva versión del servicio, fueron implementados de tal forma que su llamada provocaría una error (más específicamente, lanzan una especialización de java.lang.Exception), para indicar una falla en la lógica. Esto, entre otras cosas, permite asegurar que no existirán problemas en caso de que distintos contenedores usen diferentes servicios de movilidad, siendo que esto provocaría un error al intentar utilizar un comando que ya no aplica.

57



6.3.2 - OBR no estandarizadoAl momento de implementar el prototipo, no existía especificación estándar de la

funcionalidad propuesta para OBR (descripta en el apartado “Resolución dedependencias con OSGi Bundle Repository (OBR)“ de la sección 5.4.2). Por otro lado, sí se podía acceder a una interfaz esbozada19, pero esta no ofrecía la funcionalidad necesaria como para implementar la solución presentada (por ejemplo, no permitía buscar un recurso a partir de un “filtro” que representase un requerimiento).

Esto hizo finalmente que se tenga que trabajar sobre la implementación específica para el framework Apache Felix (mencionada en el apartado indicado previamente). Dicha versión fue suficiente para lograr llevar a cabo la tarea requerida, pero implicó que la solución ofrecida deba utilizarse únicamente con esta implementación de OSGi.

El hecho de que el prototipo actual esté “acoplado” al framework Felix, no representa mayores inconvenientes en primera instancia debido a que dicho framework se encuentra “oculto” dentro de la implementación, y no resulta una limitación para el usuario. En adición, como se mencionó en la sección 5.4.2, la funcionalidad del repositorio de bundles fue estandarizada y, por lo tanto, futuras versiones se podrán implementar de forma que funcionen sobre cualquier framework OSGi compatible con la correspondiente versión del la especificación.

6.3.3 - OBR usa solo repositorios basados en XML

Como la implementación de OBR usada (ver sección 6.3.2) está basada en la OSGi RFC 112 (introducida en la sección 5.4.2), los repositorios de bundles son definidos a partir de un archivo XML. Esto presenta el inconveniente de que todos los bundles recibidos por medio de la funcionalidad de migración implementada, deben ser descriptos en formato XML para poder ser utilizados por la lógica asociada al repositorio.

Por un lado, la escritura de la información de los bundles recibidos a un archivo XML agrega una carga extra al trabajo de la transferencia del agente; pero, por otro, permite que dicha información quede almacenada para poder volver a ser utilizada en una sucesiva ejecución de la aplicación.

Afortunadamente, en la versión 5 de la especificación de OSGi, la definición de repositorio de bundles fue generalizada, haciendo válido el utilizar otros medios para representarlos. Así, en un futuro, se podrá agilizar el procesamiento de la migración, permitiendo que la información del bundle recibido sea incluida en un repositorio con respaldo en memoria y, eventualmente, luego persistida a un medio que posibilite recuperarla en una sucesiva ejecución.

19 Disponible en http://mirrors.dcarsat.com.ar/apache//felix/org.osgi.service.obr-1.0.2.jar

58

http://mirrors.dcarsat.com.ar/apache//felix/org.osgi.service.obr-1.0.2.jar



6.4 - Facilidades en la implementación de la solución

Así como las tecnologías involucradas y las características de la solución propuesta presentaron algunas dificultades durante la implementación de la prueba de concepto, otras particularidades permitieron resolver ciertos problemas de forma sencilla. En las presentes subsecciones se describirán estas fortalezas y como fueron aprovechadas en la implementación realizada.

6.4.1 - Arquitectura modular de JADEGracias a la arquitectura modular de JADE (descripta en la sección 2.2.2), fue

posible reemplazar el servicio de movilidad sin ningún cambio en el núcleo de la plataforma. Esta capacidad es esencial para permitir cumplir con el objetivo de que no fuera necesario crear una versión alternativa de JADE, impuesto a la solución propuesta en la sección 5.3.1.

Sobre esta capacidad se fundamenta la posibilidad de utilizar el servicio implementado simplemente especificando su clase al iniciar el contendor de JADE. Esto y las características de la solución realizada (descriptas en la sección 6.2), permiten que cumpla con el requerimiento de transparencia en el uso (definido en el apartado 5.3.2).

6.4.2 - Mecanismo de carga de clases con propiedades específicas

Como ya se anticipó en la sección 6.2.1, JADE cuenta con un mecanismo que permite asociarle propiedades a las clases que definen los agentes. Luego, un componente conocido como ObjectManager, se encarga de delegar a un Loader asociado la interpretación de dichas propiedades y la carga de la clase a la que pertenecen.

De esta forma, para poder determinar en que bundle se deben buscar las clases indicadas, se definieron un par de parámetros “bundle_sn” y “bundle_v” que indican el nombre simbólico (symbolic name) y la versión de dicho bundle. Contando con este par, es suficiente para identificar de forma unívoca a un bundle en OSGi [The OSGi Alliance 2012a, 89]. Luego, un Loader implementado para tal fin, se encarga de buscarlo dentro de los bundles resueltos en el framework OSGi empotrado en el servicio.

6.4.3 - Arquitectura de composition filtersLa arquitectura de composition filters permite que las interacciones entre los

distintos servicios que componen a JADE sean mediante mensajes (comandos horizontales y verticales). Por esto es que, manteniendo dichos comandos, es posible reemplazar un servicio sin que el resto se vean afectados.

59



Dentro de las limitaciones mencionadas en la sección 6.3.1, al implementar el nuevo servicio de movilidad, se intentó mantener compatibilidad con los comandos existentes (que utiliza el servicio ofrecido por JADE) y, así, permitir que los que dependieran de estos pudieran seguir funcionando. Si bien la integración no llegó a ser perfecta (ya que se tuvieron que descartar algunos comandos, como se mencionó en la sección 6.3.1), esta arquitectura permitió que el cambio haya sido transparente para todos los servicios que utilizan los comandos que sí se mantuvieron.

6.4.4 - Capacidad de empotrar un framework OSGi

La capacidad de empotrar un framework OSGi en una aplicación (y con mecanismos estándares), fue la que permitió que el uso de OSGi quedara oculto dentro del servicio de movilidad ofrecido como solución en el presente trabajo. De no ser porque la especificación de esta tecnología considera dicha funcionalidad, esto no hubiera sido posible y, probablemente, no se hubiera podido llegar a una solución tan “transparente” como la que se logró.

6.4.5 - OSGi administra sus class loaders sin imponer restricciones sobre los demás

Al integrar un framework OSGi en una aplicación, existe una distinción entre como son administradas las clases por OSGi respecto de como lo son en la aplicación contenedora. El hecho de que el framework de OSGi no imponga ninguna limitación sobre como la aplicación contenedora debe hacer uso de sus mecanismos de class loading, permitió el uso de OGSi para la administración de las clases que definen a los agentes móviles, sin mayores conflictos con el resto de JADE.

60

Funcionamiento del prototipo implementado


Capítulo 7Funcionamiento del prototipo implementado

En el capítulo anterior se describieron los detalles del prototipo que fue implementado con el objeto de probar la funcionalidad propuesta como solución a las limitaciones del servicio de movilidad que ofrece JADE. En las siguientes subsecciones se presentan los resultados obtenidos mediante el uso del servicio de movilidad basado en OSGi (prototipo) y se comparan contra el funcionamiento de la versión oficial.

7.1 - Soluciones a las limitaciones del servicio de movilidad de JADE

En la sección 4.4 se explicaron las limitaciones que presenta el servicio de movilidad de agentes de software que ofrece por defecto la plataforma JADE, y que motivaron el desarrollo del presente trabajo. En las siguientes subsecciones se analiza como el prototipo implementado resuelve dichas restricciones.

7.1.1 - Solución a la dificultad 1 – Posibilidad de actualizar el agente

La solución a la primer dificultad (descripta en la sección 4.4.1), relativa al hecho de que una vez migrado un agente, las clases que lo definen no pueden ser actualizadas; viene de la mano con que, en la solución propuesta, las clases están siempre asociadas a un bundle. De esta forma, puede especificarse exactamente que versión de la clase se debe utilizar, por medio de la identificación del bundle asociado.

Como fue descripto en la sección 6.2.1, al migrar un agente, se envía junto con sus datos serializados el identificador (único) del bundle que lo define. Así es que, si en una futura migración han cambiado las clases que definen a un agente (identificado por su nombre dentro de la plataforma), se puede asegurar que se usarán las correctas, ya que estas pertenecerán a otro bundle.

7.1.2 - Solución a la dificultad 2 – Solo se transmiten los componentes que no estén presentes en destino

La segunda dificultad (descripta en la sección 4.4.2) que surge porque, en el servicio de movilidad intra-plataforma ofrecido por JADE, una misma clase puede ser

61



transmitida múltiples veces a un contenedor destino, es solucionada aprovechando el identificador de bundle que se transmite junto con los datos serializados del agente en migración.

Al contar con el identificador del bundle que contiene las clases que definen al agente que se está recibiendo, el servicio de movilidad basado en OSGi puede determinar si dicho bundle ya se encuentra resuelto en el contenedor destino. Si se da el caso afirmativo, no es necesario transmitir ningún otro dato para la definición del agente. En caso contrario, solo se transmitirán los bundles necesarios para poder resolver al indicado. De esta forma, si agentes migrados previamente provocaron la resolución de bundles que se pueden aprovechar para el agente que se está transmitiendo actualmente, no será necesaria la transmisión de datos para satisfacer las dependencias relativas a los paquetes ya disponibles.

Está claro que el hecho de transmitir el identificador del bundle que contiene las clases que definen al agente migrado, implica un costo que no existía en el servicio de movilidad ofrecido por defecto en JADE. Sin embargo, en general, el tamaño de dicha información es mucho menor que el de la definición de las clases que serían transmitidas innecesariamente de no utilizarse este esquema. En el capítulo 8 se presentan mediciones que profundizan sobre esta idea.

7.2 - Ventajas adicionales de la solución propuesta

El uso de OSGi como parte de la solución propuesta, además de resolver las dificultades ya mencionadas (en la sección 4.4), cuenta con un conjunto de ventajas adicionales que se describirán en las siguientes subsecciones.

7.2.1 - Capacidad de definir requerimientos que no son clases

La especificación de OSGi define la posibilidad de crear requerimientos para los bundles que no necesariamente sean clases. En particular, establece la posibilidad de indicar que un bundle solo podrá ser resuelto en caso de encontrarse en un entorno de ejecución (versión de la JVM) determinado [The OSGi Alliance 2012a, 35–37] o, por otro lado, donde existan ciertas bibliotecas nativas (específicas para un determinado sistema operativo, arquitectura del procesador, etc.) [The OSGi Alliance 2012a, 60–64].

Esta capacidad ofrece la posibilidad de, por ejemplo, definir ciertos comportamientos que solo se podrán activar si el contenedor al cual se migró está ubicado en un nodo que cuente con las características definidas.

62



7.2.2 - Funcionalidad dinámica de un agente basada en dependencias opcionales

Un requerimiento para un bundle puede ser caracterizado como obligatorio u opcional [The OSGi Alliance 2012a, 35]. En el último caso, el bundle podrá ser resuelto independientemente de si el requerimiento es satisfecho o no, siendo que, de no cumplirse, las clases no estarán disponibles para ser usada por este.

El uso de requerimientos opcionales junto con el servicio de movilidad implementado, permite definir agentes que podrán migrar a los distintos contenedores y que tendrán a su disposición capacidades dependientes de los bundles que ya existan en cada uno de ellos (sin forzar la transferencia de datos). Esto crea la posibilidad de implementar agentes muy “livianos” (que no requieren gran cantidad de datos para migrarse) y que aprovechen las funcionalidades que “encuentren” en cada paso de su travesía.

7.2.3 - Posibilidad de uso de capa de servicios de OSGi

Si bien JADE cuenta con la capacidad de ofrecer servicios a los agentes que aloja (ver sección 2.2.2), OSGi cuenta con su propia capa de servicios (descripta en la sección 3.5.3). Esta capa de servicios podría ser utilizada de forma complementaria por los agentes para acceder a ciertas funcionalidades específicas del contenedor en el cual residan actualmente.

7.2.4 - Solución como punto inicial para implementar JADE sobre OSGi

En el capítulo 3 se presentó brevemente la tecnología OSGi y algunas de sus bondades (para un tratamiento más detallado de las mismas, se refiere al lector a [R. Hall et al. 2010]). También se indicó que el principal objetivo de dicha tecnología es la de ofrecer facilidades para implementar aplicaciones modulares. Por otro lado, como fue descripto en la sección 2.2.2, JADE busca tener una arquitectura modular.

Partiendo de la gran compatibilidad que existe entre los objetivos de las distintas tecnologías involucradas, el introducir un framework OSGi para la solución propuesta puede servir de aproximación inicial para que, en un futuro, toda la plataforma JADE pueda basarse sobre OSGi para implementar una modularidad que aproveche toda su potencia.

63

Desempeño del prototipo de solución propuesta


Capítulo 8Desempeño del prototipo de solución propuesta

En este capítulo se presentan los resultados obtenidos por medio de un conjunto de pruebas realizadas utilizando la implementación (prueba de concepto) de la solución propuesta en el presente trabajo, y comparándola contra la versión ofrecida de forma nativa en JADE.

8.1 - Objetivo de las pruebas

Las pruebas fueron realizadas con el objeto de determinar el desempeño del servicio de movilidad propuesto frente al ofrecido por defecto en JADE. Se hizo especial foco en analizar las diferencias en la cantidad de datos transmitidos para la migración, ya que la nueva lógica tiene como principal impacto un cambio en la determinación y consecuente ejecución de que recursos deben ser transmitidos.

8.2 - Entorno de pruebas

Las pruebas se ejecutaron con el siguiente entorno:

• Sistema operativo Linux 64 bits con kernel versión 2.6.32. Distribución Ubuntu en su versión 10.04.

• Java versión 1.6.0_24. OpenJDK Runtime Environment (IcedTea6 1.11.4). OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode).

• Una PC con dos contenedores (JADE) ejecutados en máquinas virtuales Java independientes.

• JADE versión 4.2 [«JADE» 2012].

• Apache Felix Framework (OSGi framework) versión 4.0.3 [«Apache Felix» 2012].

8.3 - Pruebas realizadas

En síntesis, la pruebas realizadas se basan en la migración de agentes definidos únicamente por su clase (es decir, la especialización de Agent, como es requerido por JADE) y un comportamiento (especialización de la clase Behaviour). Todos los agentes migrados comparten la misma definición (clases), pero varían su nombre (identificador dentro de la plataforma).

64



Toda la información relativa a las pruebas realizadas se encuentra en [«JADE OsMoSes / Wiki / metrics» 2012]. Allí se puede acceder a las clases implementadas para el fin, así como también a los scripts (pequeños programas) que permiten reproducir la ejecución realizada y presentada en las siguientes secciones.

8.3.1 - Detalle de las pruebas realizadasEn la prueba participan un contenedor principal (ver sección 2.2.1), que será el

destino de los agentes migrados; y otro contenedor aledaño, que será el que crea los agentes y los envía al primero. Luego, una ejecución de la prueba consistirá en crear consecutivamente una cantidad de agentes y migrarlos a destino. Una vez transmitida una cantidad preestablecida de agentes, la prueba concluye.

El conjunto de pruebas consiste en varias ejecuciones, donde se migran desde uno a veinte agentes. Cada conjunto de pruebas fue realizado utilizando el servicio de movilidad nativo de JADE y el propuesto en este trabajo en dos variedades: usando como canal de comunicación la versión basada en TCP, y la que utiliza IMTP de forma subyacente (ver sección 6.2.2).

Cada conjunto de pruebas se repitió con dos versiones de la definición del agente migrado. En una versión, luego de migrar, el agente se auto-elimina (se da de baja del contenedor). En la segunda versión, el agente permanece vivo en el destino.

Las pruebas realizadas (recién descriptas) se pueden representar con el siguiente algoritmo:

65

• Para cada una de las cantidades Mi de agentes a migrar

◦ Repetir una cantidad R de veces

▪ Ejecutar prueba con servicio de movilidad S migrando Mi agentes que implementan la lógica L

Donde, en las pruebas realizadas, los parámetros son:

Mi variando desde 1 a 20

R con un valor de 50

S variando entre:

• El servicio de movilidad nativo ofrecido por JADE

• El servicio de movilidad basado en OSGi con comunicaciones realizadas por medio de IMTP

• El servicio de movilidad basado en OSGi con comunicaciones realizadas directamente sobre TCP

L variando entre:

• Agente que finaliza luego de llegar a destino

• Agente que permanece ejecutando luego de llegar a destino



8.3.2 - Sobre las medicionesLas mediciones del tráfico utilizado para la migración de los agentes se realizaron

mediante la definición de reglas en el firewall20 (netfilter [«The netfilter.org project» 2012]) del sistema operativo (Linux), por medio de la aplicación iptables [«The netfilter.org “iptables” project» 2012].

Queda fuera del alcance del presente trabajo el detalle de como funcionan los filtros utilizados (se refiere al lector a [«JADE OsMoSes / Wiki / Transmission Between Containers» 2012] donde se presentan las pruebas y su detalle), pero cabe aclarar que estos se definieron de forma tal de contabilizar todo el tráfico TCP que se transmitiera dentro de la misma interfaz de red (localhost21). De esta forma, el valor final obtenido es el total de las transmisiones entre los dos contenedores, que se ejecutaron cada uno en procesos independientes dentro de la misma instancia del sistema operativo .

8.4 - Resultados

8.4.1 - Sobre los resultados expuestosComo se describió previamente, se midieron las ejecuciones con el servicio de

movilidad nativo de JADE y el propuesto en este trabajo, utilizando comunicación basada en IMTP y directamente sobre TCP. Los datos se obtuvieron para la migración desde uno a veinte agentes, y cada caso se ejecutó cincuenta veces antes de pasar al siguiente. Estas repeticiones sirvieron para verificar la estabilidad y confiabilidad de los valores medidos.

Como resultado de la ejecución repetida de cada caso de prueba, se detectó que existe variabilidad en las mediciones realizadas, llegando en algunas ocasiones a diferir el valor máximo obtenido en casi un 17% respecto del mínimo medido para el mismo caso. Un análisis detallado de las ejecuciones (mediante captura de los paquetes transmitidos en la red), llevo a determinar que estas variaciones se deben a la existencia de segmentos TCP de acknowledgment (ACK), que en ocasiones son transmitidos y en otras no (probablemente debido a cambios en los tiempos de transmisión de la información). Cada segmento de ACK individual (sin transferencia de datos) agrega un conteo de 66 Bytes (suma total de los datos necesarios para el conjunto de protocolos que conforman TCP/IP versión 4 sobre Ethernet) a la captura, por lo que pueden llegar a ser significativos respecto del total, siendo que la información transmitida en las pruebas no es de gran tamaño.

En [«JADE OsMoSes / Wiki / Transmission Between Containers» 2012], se

20 Puede referirse a http://en.wikipedia.org/wiki/Firewall_%28computing%29 pará más información sobre el concepto de firewall.

21 Puede referirse a http://en.wikipedia.org/wiki/Localhost para más información sobre este concepto.

66

http://en.wikipedia.org/wiki/Localhost

http://en.wikipedia.org/wiki/Firewall_(computing)



pueden acceder a todas las mediciones obtenidas. Por otro lado, dado que para el análisis de los resultados no todas son de utilidad y, con el fin de simplificar la información presentada, solo se tomarán como referencia los valores mínimos del conjunto de repeticiones para cada caso realizado. Si bien, a fines de entender el desempeño de cada alternativa, sería útil analizar el peor caso posible; las mediciones sin (o con pocas) variaciones (provocadas por los ACKs “superfluos”), permiten identificar tendencias con mayor claridad, por no existir la variable adicional que representa la cantidad de datos “extra” transmitidos.

Por último, para no ignorar la realidad de la existencia de las variaciones ya mencionadas, al finalizar la interpretación de los datos para las mediciones “sin” perturbaciones, se hará un análisis de como su presencia afecta al funcionamiento real de las alternativas estudiadas.

8.4.2 - Análisis de resultados

Caso 1En la Ilustración 10 se presenta la cantidad de bytes transmitidos en función de la

cantidad de agentes migrados para el caso en que el agente migrado continúa su ejecución luego de arribado a destino (no finaliza). La Tabla 2 expone los valores medidos (a partir de los cuales se generó la Ilustración 10).

67

Tabla 2: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que permanece vivo en el destino

Migrados OSGi/IMTP OSGi/TCP Svc nativo1 17864 15626 130782 22549 20259 200163 27182 24944 270064 31867 29577 339445 36448 34210 408826 41133 38843 478207 45766 43528 547588 50399 48213 621289 55032 52898 6873810 59717 57531 7600411 64356 62446 8300212 68995 67137 8989613 73686 71776 9689414 78273 76467 10389215 82964 81158 11089016 87603 85797 11783617 92294 90436 12483418 96933 95075 13178019 101572 99766 13877820 106211 104457 145724



Como se puede observar a partir de la Tabla 2, el servicio de movilidad propuesto en el presente trabajo resulta más costoso en un principio, pero luego es compensado cuando es necesaria la migración de otros agentes que dependen de la misma definición (código). La explicación detrás de estos resultados es que el enfoque basado en OSGi requiere el intercambio de información adicional (respecto de la usada por el servicio nativo de JADE), que está asociada a la descripción del bundle en el cual se define el agente. Así, al transmitir por primera vez un agente, se incurre en un costo extra respecto al que se tiene si solo se transmitieran las clases del mismo (como lo hace el servicio de movilidad nativo ofrecido por JADE).

Por otro lado, al migrar un segundo agente definido con las mismas clases, el enfoque seguido por el servicio ofrecido de forma nativa en JADE (presentado en la sección 4.2.2), hace que las clases que definen al agente deban ser transmitidas nuevamente. En contraposición, la solución aquí propuesta detecta que el agente puede ser definido a partir de los bundles ya existentes en destino (transmitidos en la migración del primer agente), y evita incurrir en el costo de comunicarlo nuevamente. Así es que, con las sucesivas migraciones, el costo inicial se compensa, llevando a que luego de unas pocas, la lógica basada en OSGi empiece a resultar más económica (en término de bytes transmitidos) que la nativa. Finalmente resultando que, para la migración de veinte agentes distintos, se ahorra hasta un 40% del total de bytes transmitidos.

Es válido clarificar que la cantidad de bytes necesaria para migrar dos agentes no resulta el doble que para migrar uno solo debido a que en estas mediciones también

68

Ilustración 10: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que permanece vivo en el destino

1 2 3 4 5 6 7 8 9 10111213141516171819200

20000

40000

60000

80000

100000

120000

140000

160000

OSGi/IMTP

OSGi/TCP

Svc nativo

cantidad agentes transmitidos

cant

idad

de

dato

s tr

ansm

itido

s



se están teniendo en cuenta costos de inicialización de la plataforma (registro de contenedores de JADE, etc.).

Por otro lado, es interesante notar la diferencia existente entre el servicio de movilidad basado en OSGi con transmisión de datos por medio de IMTP, respecto de la que usa directamente TCP; siendo que se observa que la primera resulta siempre más costosa que la última. Esto es así porque, como se mencionó en secciones anteriores, el uso del IMTP que se configura por defecto en la plataforma JADE (este es conocido como “LEAP IMTP” y su tratamiento queda fuera del alcance del presente trabajo), tiene un costo adicional sobre TCP ya que requiere información extra para la implementación de su propia lógica (notar que el primero se transmite sobre este último). Se debe recordar que se puede definir un IMTP alternativo por configuración, pero para las pruebas se utilizó este por ser la alternativa recomendada y disponible por defecto.

En mediciones que se hicieron para determinar el costo extra de transmitir datos por medio de LEAP IMTP, se llegó a determinar que para el envío de un mensaje (comando horizontal), es necesaria la transmisión de dos segmentos TCP, uno usado para el envío del comando y otro para la respuesta. Para el servicio implementado para esta medición, se obtuvo que el primer paquete transmitido (pedido), tiene un costo extra de 166 bytes. Por otro lado, la respuesta (segundo paquete) requiere 19 bytes. Notar que estos son los valores de la información adicional a los datos, y que estos valores pueden variar dependiendo del servicio que los genere. Además, a estos se les pueden sumar de forma opcional (y dependiendo de condiciones de tiempo y aspectos ajenos a la aplicación) el adicional de dos segmentos de ACK de TCP (uno para el pedido y otro para la respuesta) que suman cada uno 66 bytes (ver sección 8.4.1 para otros comentarios relativos a estos). El detalle de esta prueba se puede encontrar en el Anexo I.

Para concluir con el análisis de este primer caso, es conveniente reflexionar sobre el hecho de que estos resultados fueron obtenidos para un agente cuya definición es muy simple (involucra pocas clases). De estar definido por mayor cantidad de clases, con distintas ínter-dependencias entre cada una y una lógica más compleja, los resultados variarían, pudiendo inclinar la balanza del desempeño para una u otra implementación en cada caso. Por ejemplo, si se implementara un agente definido por una gran cantidad de clases, pero que solo usara unas pocas en el común de los casos, la implementación basada en OSGi se vería “perjudicada” debido a que esta demanda que se disponga de la definición completa del agente para poder iniciarlo (es necesario resolver el bundle que lo define). En contraposición, la implementación nativa de JADE solo “pide” las clases a medida que son necesitadas, por lo cual, el no uso de alguna implicaría la no transmisión de la misma. Como segundo ejemplo, se puede considerar una implementación que depende de muchas clases y en la cual la mayoría o todas ellas son usadas regularmente. En este caso, la solución propuesta en este trabajo resultaría en un ahorro de transmisión de datos ya con

69



menor cantidad de agentes migrados, siendo que el costo de la información extra relativa a OSGi resultaría poco significativo frente al costo del envío del conjunto (extenso) de clases que definen al agente. Cabe aclarar que, por un lado, en todo caso es esperable que exista un punto en el cual la implementación basada en OSGi comience a resultar más eficiente que la nativa de JADE, debido a que, en la última, cada agente nuevo requerirá el envío de las clases utilizadas, cuando en la primera no es así. Por otro lado, el mencionado caso patológico podría ser subsanado con formas alternativas de modularizar la definición del agente, así es que, por ejemplo, si este agente puede aprovechar bundles que fueron transmitidos para la definición de otro, no será necesaria la transferencia de estos para que el agente pueda ser migrado y, así, se ahorrará el asociado costo de envío.

Caso 2En la Tabla 3 e Ilustración 11 se presenta la cantidad de bytes transmitidos en

función de la cantidad de agentes migrados para el caso en que el agente migrado finaliza su ejecución luego de arribado a destino. Si bien este caso es muy similar al primero presentado, se puede destacar el hecho de que, aquí, el servicio de movilidad propuesto en este trabajo resulta más eficiente que el nativo de JADE para una cantidad menor de agentes migrados (dos para TCP, frente a tres en el caso anterior; y tres para IMTP, frente a cuatro en el primero). La razón de que esto suceda es que, en este caso, el servicio de movilidad nativo de JADE emite un comando horizontal adicional al finalizar el agente. Este comando es usado para permitir la limpieza de los recursos necesarios para que dicho servicio pueda asegurar la transmisión de las clases que definen al agente. Es este adicional el que aumenta la transmisión de datos y hace que la solución propuesta en este trabajo supere en desempeño a la nativa para una cantidad menor de agentes migrados.

Es justo aclarar que en el prototipo implementado (a partir del cual se obtuvieron las mediciones aquí presentadas), no está incluida la lógica necesaria para la desinstalación de los bundles que ya no son necesarios para definir a los agentes restantes. Sin embargo, debido a que en la solución basada en OSGi, una vez migrado el agente, este se independiza del origen (ya que toda la información necesaria para su definición debe hacerse disponible en destino antes de completarla), no existe necesidad de nuevos intercambios de información cuando este finalice. Así es que se espera que una solución completa no requiera más intercambio de información que la que se usa para el prototipo probado, haciendo que la tendencia presente en este caso siga siendo válida.

70



71

Tabla 3: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que finaliza en el destino

Migrados1 17742 15608 131612 21875 20189 202343 27008 24822 272554 31693 29507 342765 36274 34088 412976 41011 38877 483187 45644 43458 553918 50277 48091 627929 54910 53052 6981310 59595 57737 7688611 64234 62428 8391612 68873 67067 9094613 73512 71810 9802814 78203 76397 10505815 82842 81088 11219216 87585 85779 11922217 92172 90366 12625218 96811 95057 13333419 101502 99696 14041620 106141 104283 147498

OSGi/IMTP OSGi/TCP Svc nativo

Ilustración 11: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que finaliza en el destino

1 2 3 4 5 6 7 8 9 10111213141516171819200

20000

40000

60000

80000

100000

120000

140000

160000

OSGi/IMTP

OSGi/TCP

Svc nativo


cant

idad

de

dato

s tr

ansm

itido

s



Caso 3En la Tabla 4 e Ilustración 12 se presentan los resultados obtenidos para el caso

en que, a diferencia de los anteriores, la definición del agente se encuentra de antemano en destino. Esto con la versión del agente que una vez migrado continúa su ejecución (no finaliza). El caso presentado se daría si para el servicio de movilidad nativo de JADE, la definición de los agentes migrados hubiera sido incluida en el classpath y, para el basado en OSGi, si existieran bundles suficientes para satisfacer sus dependencias (ya sea por haberse instalado “a mano” en el destino, o por estar allí de la migración de otros agentes que necesitaran dichos bundles).

En este caso no existe cantidad de agentes a migrar a partir de la cual el servicio de movilidad basado en OSGi resulte más eficiente que el nativo de JADE. El motivo de esto es que (como se mencionó anteriormente) el primero requiere de información adicional para poder identificar el bundle que define al agente migrado y, por lo tanto, tiene un costo adicional que no presenta la solución nativa de JADE.

Sin embargo, como es claramente observable a partir de la Ilustración 12, el costo extra necesario por la solución basada en OSGi es constante para cada agente migrado, y no afecta a la pendiente de la recta que representa el costo de migración

72

Tabla 4: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que permanece vivo en el destino y que la definición de este se encuentra en destino previamente a la migración

Migrados1 14078 12428 98642 18711 17113 151603 23396 21746 197484 28029 26379 242845 32662 31012 288206 37295 35645 333567 41928 40330 383248 46561 45119 428609 51194 49700 4744810 55879 54661 5198411 60518 59300 5647412 65157 63939 6112013 69796 68630 6566214 74487 73269 7020415 79178 77960 7474616 83817 82599 7934017 88456 87238 8388218 93095 91877 8847619 97734 96568 9301820 102425 101207 97560




(en término de datos transmitidos) en función de la cantidad de agentes migrados. Por otro lado, también es válido aclarar que este costo no depende de la cantidad de clases que definan al agente, por lo que resultará despreciable para casos de agentes más elaborados (con un conjunto más extenso de clases).

Caso 4Siguiendo con el caso en que las definiciones de los agentes migrados se

encuentran en destino, en la Tabla 5 e Ilustración 13 se presenta dicha situación para los agentes que finalizan su ejecución luego de la migración. Como se puede notar, aquí la existencia en el servicio de movilidad nativo de JADE del costo extra del mensaje que informa la finalización del agente (introducido previamente en esta subsección), hace que exista un punto de inflexión en el cual la solución propuesta supera en desempeño al primero.

73

Ilustración 12: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que permanece vivo en el destino y que la definición de este se encuentra en destino previamente a la migración

1 2 3 4 5 6 7 8 9 10111213141516171819200

20000

40000

60000

80000

100000

120000

OSGi/IMTP

OSGi/TCP

Svc nativo


cant

idad

de

dato

s tr

ansm

itido

s



74

Tabla 5: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que finaliza en el destino y que la definición de este se encuentra en el objetivo, previamente a la migración

Migrados1 14078 12428 109252 18763 17061 157373 23396 21746 206514 28029 26379 254885 32662 31012 303256 37295 35645 351627 41928 40278 404318 46613 45015 452689 51246 49648 5015710 55879 54609 5499411 60518 59248 5983812 65157 63939 6468213 69848 68630 6957814 74487 73269 7442215 79178 77960 7931816 83817 82599 8421417 88456 87342 8905818 93147 91877 9390219 97786 96568 9879820 102425 101207 103642


Ilustración 13: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que finaliza en el destino y que la definición de este se encuentra en objetivo, previamente a la migración

1 2 3 4 5 6 7 8 9 10111213141516171819200

20000

40000

60000

80000

100000

120000

OSGi/IMTP

OSGi/TCP

Svc nativo


cant

idad

de

dato

s tr

ansm

itido

s



Caso 1 con máximos valores medidosPara finalizar con la presentación de los resultados obtenidos, se presenta

nuevamente el caso en que el agente migrado continúa su ejecución luego de arribado a destino (no finaliza) y no se dispone de la definición del agente en el objetivo (presentados en la Tabla 2 e Ilustración 10); pero, esta vez, tomando los valores máximos medidos en las repeticiones de cada migración de agentes (ver sección 8.4.1 para las consideraciones mencionadas previamente). Estos valores se pueden observar en la Tabla 6 e Ilustración 14.

En estos datos se puede notar la variabilidad de los valores obtenidos a causa de la sucesión de segmentos ACK del protocolo TCP. Esta variación se puede presentar especialmente en la solución basada en OSGi, debido a que el protocolo de resolución de dependencias (ver sección 6.2.3) intercambia un conjunto de mensajes para lograr su cometido, y esto hace que existan más paquetes que pueden causar la generación de ACKs. Cabe resaltar que en los resultados mostrados, las variaciones resultan significativas debido al tamaño reducido de los datos que se están transmitiendo (estado y definición del agente “simple”). De tratarse de datos más importantes, el costo asociado a cada ACK podría ser

75

Tabla 6: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados y la tecnología usada para la migración. Caso de agente que permanece vivo en el destino. Máximos valores de repeticiones para las capturas realizadas

Migrados1 18282 15938 130782 22653 21824 200683 27338 25860 274904 32769 32581 344285 36604 37974 414186 41237 43039 483567 46615 44980 553468 50555 52409 623889 55188 58104 6932610 59873 62120 7621211 64512 62930 8315812 69255 72132 9015613 73894 77739 9710214 78653 81069 10410015 83224 84006 11120216 87811 89678 11809617 93603 90696 12509418 97365 99336 13209219 102906 102666 13929820 106419 105321 146244




despreciado frente al total (notar que la mayor parte de los mensajes intercambiados por el protocolo mencionado, son independientes al volumen del contenido de los bundles).

8.5 - Conclusiones

De los resultados recién presentados, se puede concluir que, si bien el servicio de movilidad propuesto en el presente trabajo, y con respecto al ofrecido de forma nativa por JADE, requiere mayor cantidad de información para transmitir la definición de los agentes a destino (debido a que es necesario diferenciar y resolver las dependencias de los bundles que la componen); a medida que se migran otros agentes que pueden aprovechar estas definiciones, el costo se empieza a compensar por evitar la re-emisión de la información ya disponible. Esto hace que, a largo plazo, resulte más eficiente la solución basada en OSGi.

Por otro lado, debido a que los bundles transmitidos son persistidos al llegar a destino, se previene que, ante una caída del nodo, esta información deba ser transferida nuevamente. Esto ofrece una facilidad de despliegue que no se encuentra con el servicio nativo de JADE, siendo que en este, para que la información pueda ser aprovechada en el destino desde el inicio, tiene que configurarse mediante el mecanismo de classpath (ver sección 3.2.1).

Si bien existen casos en los que la solución basada en OSGi siempre presentará desventaja en la cantidad de datos transmitidos en la migración (por ejemplo, el caso

76

Ilustración 14: Cantidad de bytes transmitidos para la migración de agentes, según la cantidad de agentes migrados, para cada tecnología usada para la migración. Caso de agente que permanece vivo en el destino. Máximos valores de repeticiones para las capturas realizadas

1 2 3 4 5 6 7 8 9 10111213141516171819200

20000

40000

60000

80000

100000

120000

140000

160000

OSGi/IMTP

OSGi/TCP

Svc nativo


cant

idad

de

dato

s tr

ansm

itido

s



3 presentado), es menester recordar que esta solución ofrece además el beneficio de permitir la actualización de las definiciones de los agentes sin posibilidad de conflictos por clases y agentes homónimos, y sin necesidad de reiniciar los contenedores de la plataforma JADE.

Por otro lado, si bien los resultados presentados ya resultan alentadores y muestran una mejora en la eficiencia de la migración de los agentes móviles, es necesario recordar que la implementación usada para estas pruebas fue realizada como un prototipo o prueba de concepto, y que requiere de trabajo futuro para poder pulir detalles y optimizarla de forma tal de lograr aún mejores resultados.

77

Conclusiones San Martín, Matías Ignacio

Capítulo 9Conclusiones

En el presente trabajo se dio una introducción al paradigma de agentes móviles de software y sus principales ventajas e inconvenientes asociados (capítulo 1). Además, se describió uno de los más importantes y activos proyectos que permiten trabajar con estos, JADE (capítulo 2 y 4). El uso de dicho framework llevo a detectar algunas limitaciones que presenta en su versión actual, siendo, a los ojos de quien escribe y tomando como contexto el paradigma en estudio, la incapacidad de trabajar con versiones actualizadas de los agentes y el no aprovechamiento de información existente para poder agilizar la migración de los mismos, uno de los más interesantes para atacar (sección 4.4).

Así fue como en el proceso de la búsqueda por una solución para las limitaciones mencionadas, se llegó a encontrar la tecnología OSGi y conocer todas sus virtudes (capítulo 3). Luego de explicar las dificultades que conlleva trabajar de forma directa con el mecanismo de class loading de Java (sección 3.2), se pudo resaltar al lector la importancia de contar con una tecnología como OSGi para simplificar la modularización y versionado de los componentes de una aplicación. Haciendo una comparativa entre las posibilidades de OSGi, las características y requerimientos del paradigma en estudio y, especialmente, del aspecto de JADE que se buscaba mejorar, se pudo determinar que la primera es una tecnología que tiene la capacidad de ofrecer mucho valor si se integrase con la última (sección 3.6).

Antes de buscar una forma de solución a las limitaciones encontradas en JADE, se pre-estableció que una implementación satisfactoria debería resultar “transparente” en el uso y no requerir cambios en el núcleo del framework; entendiéndose estas como condiciones necesarias para lograr que la solución pudiera salir del ámbito teórico, para ser aprovechada por toda la comunidad de JADE (sección 5.3). Con estas demandas en mente, se hizo un estudio de las distintas formas en que podrían coordinarse para llegar al objetivo establecido, concluyendo que lo más adecuado sería utilizar un framework OSGi “oculto” dentro de un servicio de JADE (sección 5.4.1). Sobre esta idea fue que se realizó un diseño que permitiría llegar a una implementación funcional (sección 5.4).

Una vez que se tuvo un diseño construido, se procedió a la implementación de un prototipo que cumpliera con las funciones elementales de la solución propuesta, con el objeto de validar si esta podía ser llevada a la práctica y no languidecía en alguna de sus características (capítulo 6).

Finalmente, ya con un prototipo de solución implementado, se pudo poner a prueba su funcionamiento y contrarrestarlo con la opción de servicio de movilidad de agentes ofrecido por defecto en JADE. Con los resultados de estas pruebas, se logró

78


observar que el desempeño del servicio propuesto resulta más que satisfactorio, siendo que se puede obtener un ahorro significativo y creciente en la transmisión de datos, con las sucesivas migraciones de agentes que aprovechasen las definiciones ya puestas a disposición en el destino. Cabiendo también resaltar que a este beneficio hay que adicionarle la nueva posibilidad de actualizar las definiciones de los agentes, sin necesitar reiniciar los contenedores y desechando la posibilidad de inconsistencias debido a colisiones con los nombres y clases de los mismos (capítulo 7 y 8).

Habiendo presentado el núcleo del trabajo realizado, en las siguientes secciones se hace una presentación de trabajos que en mayor o menor medida se relacionan con el aquí presente, y, por otro lado, se expone una solución alternativa que se consideró para solventar las limitaciones ya enunciadas en el servicio de movilidad predefinido de JADE. Finalmente, se concluye el presente con una descripción de opciones sobre las cuales se puede evolucionar la solución propuesta y la integración de las tecnologías OSGi y JADE.

9.1 - Trabajo relacionado y alternativa a la solución propuesta

9.1.1 - Plug-in OSGi para JADEExiste un complemento22 de JADE que lo integra con la tecnología OSGi,

proponiendo ejecutar la plataforma como un bundle dentro de un framework OSGi (como fue descripto para el caso de integración “Alternativa 2 – JADE sobre OSGi“ en la sección 5.4.1). Este tiene como objetivos [Quarantotto y Caire 2010]:

• Crear contenedores JADE dentro de un framework OSGi.

• Crear agentes a partir de bundles presentes en el framework OSGi.

• Empaquetar el código de los agentes dentro de distintos bundles y aprovechar la funcionalidad de actualización de bundles que provee OSGi, para poder actualizar los agentes.

• Ofrecer a los agentes acceso a las funcionalidades de OSGi. Por ejemplo, el registro y uso de servicios OSGi.

Como se discutió en la sección 5.4.1, este enfoque tiene la desventaja de requerir que el usuario (de JADE) comprenda como funciona un framework OSGi. Además, en particular para el complemento en tratamiento, exige que se entienda como definir (a través del framework OSGi) las propiedades para que el bundle de JADE pueda ser activado con configuraciones necesarias para el funcionamiento deseado.

Por más que el complemento aquí descripto aprovecha las bondades de la

22 Todos los complementos para JADE pueden accederse en http://jade.tilab.com/community-addons.php, previo registro de una cuenta gratuita.

79

http://jade.tilab.com/community-addons.php


tecnología OSGi, este no ofrece una solución para la movilidad de los agentes. Esto provoca que las limitaciones mencionadas en la sección 4.4 sigan estando presentes.

Por último, si bien la integración entre JADE y OSGi puede ser positiva (como se estableció en la sección 7.2.4), el enfoque seguido en la solución recién presentada falla en no aprovechar (para la arquitectura de JADE) las facilidades de administración de módulos que ofrece OSGi. Aquí la modularidad de JADE se resuelve de la misma forma que la alternativa sin OSGi (ver sección 2.2.2) y, además, la aplicación completa es vista como un único módulo desde el punto de vista del framework OSGi.

9.1.2 - Servicio de movilidad inter-plataforma

El servicio de movilidad inter-plataforma (o IPMS, introducido en la sección 4.3) fue tratado de forma limitada en el presente trabajo. Sin embargo, cabe analizar como se compara la solución propuesta a dicha funcionalidad, y cuan compatibles son entre ellas.

Ambas soluciones requieren que las clases de los agentes sean agrupadas para su migración. En el caso del IPMS, dicho empaquetado se realiza mediante la creación de un JAR con todas las clases necesarias para el agente. En contraposición, el servicio propuesto en este trabajo, propone realizar agrupaciones en forma de módulos (bundles), diferenciados según su coherencia lógica, y pudiendo componerse varios para ofrecer toda las definiciones necesarias para un agente. Resulta evidente que el enfoque propuesto ofrece mayor flexibilidad para el usuario y, en última instancia, puede limitarse al mismo agrupamiento que en el caso contrastado.

Dependiendo de la estrategia usada para la transferencia de datos (descriptas en la sección 4.3.2), el IPMS utilizará el servicio de transporte de mensajes (entre plataformas) implementado en JADE y, quizás, otro canal (como ser conexiones HTTP). Gracias a la abstracción del uso de “conexiones” en la solución propuesta (ver sección 6.2.2), es posible utilizar la misma implementación y que la transmisión de datos se haga sobre cualquier tipo de canal e, incluso, sobre múltiples de ellos (siempre y cuando se ofrezca la visión de una única “conexión” hacia la funcionalidad cliente). Esto permite que la lógica implementada en dicha “conexión” se ocupe de coordinar (mediante mensajes ACL) el proceso de migración con la plataforma destino. De esta manera, la solución propuesta no ofrece restricciones en cuanto a su uso intra o inter-plataforma.

Debido a que el servicio de movilidad basado en OSGi trabaja con bundles como mínima unidad de transferencia de datos (no se puede transportar una clase individual), no es posible implementar la misma variedad de estrategias de transferencia que se ofrece en la solución de IPMS. Esto puede significar que, bajo

80


ciertas condiciones, el IPMS requiera menor cantidad de transmisión de datos. Sin embargo, como se pudo concluir de las pruebas realizadas en la sección 8.4.2, el servicio basado en OSGi, al tener la capacidad de definir la funcionalidad como composición de módulos, permite ahorrar transferencias a largo plazo. Esto es gracias al hecho de que dichos módulos pueden ser compartidos entre distintos agentes, eliminando la necesidad de una nueva transmisión.

Por último, cabe mencionar algunas bondades extras que ofrece el servicio propuesto en el presente trabajo, y que no son factibles (o son difíciles de obtener) con IPMS:

• Por ser la solución basada en OSGi un servicio independiente y que reemplaza al intra-plataforma, es posible condensar en el mismo la funcionalidad de este y la de IPMS. Esto haría que no fuera necesario desplegar dos servicios de movilidad distintos para obtener ambas clases de movilidad y, así, lograr una transparencia absoluta del tipo a usar.

• Como se mencionó en la sección 7.2, las características de OSGi ofrecen la capacidad de variar la disponibilidad de funcionalidades (bundles) dependiendo de las particularidades del nodo sobre el cual se despliegan. De necesitarse estas mismas en una implementación que no fuese basada en OSGi, deberían resolverse con mecanismos implementados para tal fin y, probablemente, con lógica específica dentro del agente migrado. Además de agregarle una carga al desarrollador del agente, la presencia de dicha lógica haría que el agente contenga más información que deberá ser transmitida (y exigirá más recursos para su migración).

• OSGi ofrece de forma nativa mecanismos para ofrecer seguridad en lo que respecta al despliegue de bundles (sobre estos se profundizará en la sección 9.2.3). Estas facilidades permiten incorporar seguridad en el proceso de migración, la cual no está resuelta en IPMS [Ametller-Esquerra y Cucurull-Juan 2012].

9.1.3 - Solución alternativa mediante uso explícito de class loaders

Como alternativa al enfoque seguido para la solución propuesta, se podrían haber resuelto las limitaciones descriptas en la sección 4.4, mediante un manejo más elaborado de class loaders. Esta potencial solución podría haber tomado las siguientes medidas para solventar los problemas descriptos:

• Para prevenir la transmisión innecesaria de clases, se requeriría implementar una red de class loaders, de forma tal que las versiones de las clases sean cargadas una única vez y luego “compartidas”. Así, al precisar una clase que no fuera conocida por un class loader particular, antes de cargarla podría “preguntar” a los demás si alguno ya la hubiese obtenido y, de ser el caso, utilizar dicha instancia en lugar de tener que requerir la transmisión de la

81


definición de la clase.

• Por otro lado, para diferenciar entre versiones de clases homónimas, una posible alternativa sería calcular una función hash23 sobre la definición de cada una (cuyo formato es descripto en [Lindholm et al. 2012, 69–141]), que permita identificar cambios en la misma. Luego, con el par [nombre de la clase, hash calculado] se podría diferenciar entre clases homónimas (notar que es necesario un análisis detallado para identificar que función hash se debe aplicar para minimizar la probabilidad de colisiones que llevarían a pensar que dos clases son la misma, cuando en realidad no lo son).

Este enfoque cuenta con dos grandes ventajas por sobre el utilizado en el presente trabajo:

1. Es totalmente transparente para el usuario de JADE. Una solución como la descripta ofrecería un uso idéntico al que provee el servicio de movilidad intra-plataforma (y hasta se la podría considerar como una mejora sobre el mismo, en lugar de un cambio).

2. Requiere la mínima cantidad de transmisión de datos debido a que solo se transferirían las clases estrictamente necesarias (y que nunca antes fueron transmitidas).

Si bien las ventajas enunciadas hacen que la solución sea muy atractiva, este acercamiento cuenta con grandes desventajas que hicieron que finalmente no se tomara como solución propuesta:

• Presenta una gran complejidad en su implementación ya que hay que crear un mecanismo elaborado de colaboración entre distintos class loaders. Como se describió en la sección 3.2.3, el trabajo explícito con class loaders resulta muy dificultoso y propenso a errores, esto hace que la solución obtenida sea difícil de entender y mantener.

• A diferencia de la versión basada en OSGi, una solución como la descripta aquí no es fácilmente adaptable al servicio de movilidad inter-plataforma. Esto hace que deba encontrarse una solución independiente para los problemas relacionados con el último.

• La tecnología OSGi tiene ventajas que ofrecerle a toda la plataforma JADE (como se discutió en la sección 7.2.4). En cambio, la solución enfocada solo en los requerimientos del servicio de movilidad intra-plataforma, no aporta beneficios aplicables a los componentes aledaños.

Estas desventajas hicieron que se optara por basarse en una tecnología madura como es OSGi, frente a una solución que apuntara a ser más eficiente pero que, probablemente, cayera en decadencia con el tiempo por su complejidad y dificultad de mantenimiento.

23 Puede referirse a https://en.wikipedia.org/wiki/Hash_function para más información.

82

https://en.wikipedia.org/wiki/Hash_function


9.2 - Trabajo futuro e ideas

El prototipo presentado en este trabajo sirve como punto inicial para una solución a los problemas descriptos en JADE. Sin embargo, existe la posibilidad de evolucionar sobre esta versión. En las siguientes subsecciones se presentan algunas ideas sobre otras mejoras que pudieran realizarse, tomando como punto de partida la implementación presentada.

9.2.1 - Uso de repositorio de recursos estandarizado

En la sección 5.4.2 se introdujo al lector al concepto presentado por la OSGi RFC 112 y su evolución hasta convertirse en parte de la especificación estándar de la tecnología OSGi en su versión 5. También se indicó que debido a las limitaciones presentes al momento de realizar el prototipo para el presente trabajo, este finalmente se basó en una versión del repositorio de bundles que es dependiente del framework de OSGi “Apache Felix”.

Una primera evolución sobre el trabajo realizado debería ser modificar la implementación para que utilice la interfaz estándar del repositorio de recursos (ver sección 5.4.2), de forma tal que no esté limitada al uso de un framework OSGi específico.

Por otro lado, como fue adelantado en la sección 6.3.3, el uso de dicha especificación permitiría implementar una solución que no requiera el almacenado de la información en formato XML como paso inicial para el proceso de migración de un agente, permitiendo una solución más eficiente.

9.2.2 - Modularizar JADE a partir de OSGiYa se mencionó en la sección 7.2.4 que toda la plataforma JADE podría verse

beneficiada con la tecnología OSGi. Por este motivo es que se considera que sería conveniente como trabajo futuro, que se empiece a realizar una re-estructuración de JADE de forma tal que se aprovechen las bondades explicadas.

Cabe resaltar que dicho trabajo deberá ser coordinado con los desarrolladores de este framework, para así evitar la necesidad de crear una versión paralela que presentaría los inconvenientes descriptos en la sección 5.3.1.

9.2.3 - Uso de los mecanismos de seguridad ofrecidos por OSGi

Introducción al modelo de seguridad en OSGiOSGi define una capa de seguridad opcional basada en la arquitectura de

seguridad de Java 224 [The OSGi Alliance 2012a, 9]. En resumen, este modelo

24 Se refiere al lector a http://docs.oracle.com/javase/1.4.2/docs/guide/security/spec/security-spec.doc.html para más información al respecto.

83

http://docs.oracle.com/javase/1.4.2/docs/guide/security/spec/security-spec.doc.html

http://docs.oracle.com/javase/1.4.2/docs/guide/security/spec/security-spec.doc.html


permite asociar a determinadas entidades, permisos para realizar ciertas acciones (queda fuera del alcance del presente trabajo el profundizar en los conceptos involucrados en esta arquitectura). La especificación de OSGi define distintas formas de identificar a las entidades a las cuales asignar los permisos (mencionadas a continuación) y, además, un conjunto de permisos que serán verificados por el framework.

OSGi ofrece la capacidad de identificar a los bundles a los cuales asignarles permisos: por medio su location (propiedad introducida en la sección 3.5.2), o por medio de la firma digital25 de los mismos [The OSGi Alliance 2012a, 9–18]. Por otro lado, como parte de la especificación correspondiente a funcionalidades opcionales de OSGi, se establece la opción de dar permisos basados en el usuario que ejecuta las funciones [The OSGi Alliance 2012b, 109–127].

Los permisos a designar a las distintas entidades se pueden clasificar de acuerdo a la capa del framework OSGi a la que pertenecen (estas fueron introducidas en la sección 3.3):

• Para la capa de módulos, existen los permisos necesarios para especificar que capacidades de un bundle pueden ser ofrecidas por este y/o consumidas por otro (esto es, por ejemplo, que paquetes se pueden exportar o importar) [The OSGi Alliance 2012a, 74–77].

• Para la capa de ciclo de vida, se dan los permisos necesarios para indicar que operaciones relacionadas al ciclo de vida de los bundles pueden ser realizadas. Por ejemplo, existen permisos para permitir desinstalar, resolver, o actualizar un bundle [The OSGi Alliance 2012a, 108–110].

• Para la capa de servicios, se definen los permisos para precisar que servicios pueden ser registrados y/o utilizados por los bundles [The OSGi Alliance 2012a, 125].

OSGi otorga un modelo muy flexible para la asignación de permisos, este se basa en delimitar un conjunto de condiciones que deben ser cumplidas para que apliquen los mismos [The OSGi Alliance 2012a, 277–311]. Además de las condiciones ya mencionadas (que permiten verificar que el bundle tenga una location determinada, o este firmado digitalmente por una o un conjunto de entidades), este modelo posibilita crear nuevas condiciones que serán incluidas en el proceso de verificación. Las reglas asociadas a estas pueden ser definidas de forma tal que otorgen la aplicación del permiso o que la denieguen, ofreciendo así una alternativa entre un esquema de definición de permisos por inclusión o por exclusión.

Uso en JADE del modelo de seguridad de OSGiYa presentado el modelo de seguridad que especifica OSGi, resulta claro que

este podría brindar grandes beneficios a una plataforma que implemente el

25 Para más información sobre este concepto, se puede referir a http://en.wikipedia.org/wiki/Digital_signature.

84

http://en.wikipedia.org/wiki/Digital_signature


paradigma de agentes móviles de software (como es JADE). Aprovechando este, en conjunto con el servicio de movilidad propuesto en el presente trabajo, se pueden definir políticas que prohíban la migración de agentes de fuentes no confiables (identificables mediante firma digital), o que no cumplan con otras características específicas para las necesidades del contenedor que los recibe (mediante el uso de condiciones de OSGi implementadas para tal fin).

Para concluir, cabe destacar el hecho de que, por ser un mecanismo resuelto por OSGi, esta funcionalidad puede hacerse disponible sin mayores problemas y sin incurrir en soluciones específicas y complejas que debieran ser mantenidas en conjunto con el servicio de movilidad implementado.

85

Glosario San Martín, Matías Ignacio

Glosario

ACL (agent communication languaje):Lenguaje en el cual se codifican los mensajes intercambiados entre agentes de software ----------------------------------------------------------------------------------------------------------------------17

Activo:En OSGi, respecto de un bundle, indica el estado en que este se encuentra listo para ser usado -------------------------------------------------------------------------------------------------------------29

Actualizar:En OSGi, respecto de un bundle, es la acción por la cual se le indica al framework que debe reemplazarlo con otra versión del mismo -------------------------------------------------------30

Agente:Aquello que tiene la capacidad de producir un efecto ------------------------------------------------1

Agente de software:En JADE, un proceso computacional que habita una plataforma y, por lo general, ofrece uno o mas servicios que pueden ser publicados mediante una descripción del mismo ---14Programa informático que implementa la funcionalidad de un agente ---------------------------1

Agente móvil de software:Agente de software con la capacidad de moverse en una red informática ---------------------2

Agentes huérfanos:Designación que se le da a los agentes que continúan con la ejecución de su tarea luego de que ya no es requerida por la aplicación que los creó -------------------------------------------7

AMM:En JADE, "agente administrador de la movilidad" (Agent Mobility Manager), es el agente encargado de coordinar el proceso de migración inter-plataforma ------------------------------36

Arquitectura (entorno):Utilizado para significar el conjunto de componentes (hardware, sistema operativo, aplicaciones, etc.) que definen el contexto en el cual se ejecutará el agente de software - 5

Bundle:En OSGi, nombre que se le da al concepto de módulo --------------------------------------------25

Canal de comunicación entre agentes (ACC):En FIPA, es la entidad que provee el servicio de transporte de mensajes directamente a los agentes de la plataforma -------------------------------------------------------------------------------18

Capacidad:En OSGi OBR, un conjunto de propiedades asociadas a un recurso --------------------------47

Casilla de mensajes (mailbox):En JADE, estructura que guarda los mensajes destinados para los agentes y que posibilita el tratamiento asincrónico de los mismos --------------------------------------------------16

Clase:En el paradigma de programación orientada a objetos, abstracción que representa el estado y comportamiento de una entidad --------------------------------------------------------------20

Class loader:En Java, objeto responsable de cargar clases para que puedan ser usadas por la aplicación -------------------------------------------------------------------------------------------------------20

Class loading:En Java, funcionalidad ofrecida por los class loaders ----------------------------------------------21

Classpath:Conjunto de rutas (referidas al sistema de archivos) que se configura para indicarle a la plataforma Java donde debe buscar las clases a utilizar en el programa al momento de ejecutarlo --------------------------------------------------------------------------------------------------------22

Classpath/JAR hell:En Java, se usa para describir las dificultades que pueden surgir en la ejecución de aplicaciones debido a configuraciones erróneas del classpath ----------------------------------27

Código móvil:

86


Consiste en obtener/enviar un fragmento de código o funcionalidad de/a un servidor remoto para ser ejecutado localmente/remotamente -------------------------------------------------2

Comando vertical:En JADE, comando emitido por un servicio para delegar la resolución de un pedido a un sumidero y generar un punto de extensión que otros servicios pueden aprovechar para reaccionar ante el evento -----------------------------------------------------------------------------------13

Comandos horizontal:En JADE, mensaje enviado entre las distintas instancias de un servicio distribuido entre los nodos de una plataforma, para poder completar la acción pedida -------------------------13

Comportamiento (behaviour):En JADE, abstracción que implementa (parte de) la lógica específica del agente ----------14

Contenedor principal:En JADE, instancia especial de contenedor, que representa el punto de inicio de la plataforma -------------------------------------------------------------------------------------------------------12

Contenedores:En JADE, en su conjunto componen la plataforma sobre la que se ejecutan los agentes de software, y proveen todos los servicios necesarios para albergarlos y ejecutarlos ---------12

Context class loader:En Java, se trata de un class loader especial que está asociado al hilo en ejecución -----24

Contexto de un bundle:En OSGi, representa el contexto de ejecución de un bundle en el framework y funciona como interfaz de acceso al último ------------------------------------------------------------------------30

Degradación con elegancia:Término utilizado para significar un deterioro paulatino a medida que el entorno se vuelve más inadecuado para el sistema ---------------------------------------------------------------------------5

Delegación de class loaders:En Java, asociada a una clase, corresponde a la jerarquía de class loaders conformada por el que la cargó y los padres de este ----------------------------------------------------------------22

Descripción de servicio:En FIPA, conjunto de caracterizaciones que describen un servicio brindado por un agente de la plataforma -----------------------------------------------------------------------------------------------17

Desinstalado:En OSGi, respecto de un bundle, indica que este no está más disponible para ser utilizado ----------------------------------------------------------------------------------------------------------------------29

Ejecución remota:Consiste en realizar un pedido de ejecución de una funcionalidad a un servidor remoto, para luego obtener los resultados --------------------------------------------------------------------------2

Filtro de entrada:En JADE, lógica registrada por un servicio para reaccionar a un comando vertical asociado y previo a que este sea resuelto por el sumidero destino -----------------------------13

Filtro de salida:En JADE, lógica registrada por un servicio para reaccionar a un comando vertical asociado y previo a que este sea resuelto por el sumidero de salida --------------------------13

FIPA:La Fundación para Agentes Inteligentes Físicos es una asociación internacional sin fines de lucro, con el objetivo de producir una especificación estándar para la tecnología de agentes heterogéneos que interaccionen entre sí y sistemas basados en agentes --------11

Firma digital:Esquema matemático que sirve para demostrar la autenticidad de un mensaje digital. Una firma digital da al destinatario seguridad de que el mensaje fue creado por el remitente (autenticidad de origen), y que no fue alterado durante la transmisión (integridad) --------82

Fork:Respecto de un proyecto de desarrollo de software, representa una bifurcación del original, es decir, un proyecto derivado de la misma raíz ------------------------------------------42

Framework:Abstracción que representa código que provee funcionalidades genéricas y que puede ser reemplazado o especializado por el usuario para proveer funcionalidades especificas ---12

87


En OSGi, es el entorno de ejecución que implementa y provee la funcionalidad asociada a esta tecnología ------------------------------------------------------------------------------------------------25

Handshaking:Proceso automatizado de negociación que establece de forma dinámica los parámetros de un canal de comunicaciones establecido entre dos entidades antes de que comience la comunicación normal por el canal ------------------------------------------------------------------------53

Identificador de agente (AID):En FIPA, identificador global para la plataforma que permite identificar de forma unívoca a un agente dentro de esta -----------------------------------------------------------------------------------17

IMTP:(Internal Message Transport Protocol) es el protocolo utilizado en JADE para la comunicación entre los contenedores de una plataforma -----------------------------------------14

Instalado:En OSGi, respecto de un bundle, indica el estado en que el bundle es conocido por el framework, pero no está resuelto -------------------------------------------------------------------------29

Inter-bloqueo o deadlock:Situación de falla que surge cuando dos o más procesos esperan por el otro en una configuración desde la cual no se puede progresar ---------------------------------------------------8

Interfaz:En el paradigma de programación orientada a objetos, define un protocolo de uso y comportamiento que deben cumplir las clases que la implementen ----------------------------23

IPMS:En JADE, servicio de movilidad inter-plataforma que, como su nombre lo indica, permite migrar agentes entre distintas plataformas ------------------------------------------------------------33

Location:En OSGi, propiedad de un bundle que corresponde a un nombre que le asigna quien sea que lo instaló. Normalmente está asociado a la dirección (URL) de la cual se obtuvo el mismo, pero esto no es obligatorio -----------------------------------------------------------------------30

Migración:Respecto de un agente, consiste en la transmisión de su código y estado para que pueda continuar con su ejecución en el destino -----------------------------------------------------------------2

Módulo:Representa un límite lógico, de tal forma que su implementación interna está oculta del exterior y solo se expone (opcionalmente) una interfaz bien definida a partir de la cual se puede interaccionar con él ---------------------------------------------------------------------------------24

Nodo:En el contexto de una red de computadoras, corresponde a una de las computadoras que componen la red ------------------------------------------------------------------------------------------------2En JADE, de forma equivalente al concepto en una red de computadoras, corresponde a un entorno que da sustento a un contenedor ---------------------------------------------------------12

Núcleo:Relativo a una aplicación o especificación, corresponde a la parte esencial y obligatoria sin la cual esta no puede funcionar ----------------------------------------------------------------------12

Objeto:En el paradigma de programación orientada a objetos, instancia de una clase -------------20

Objeto móvil:Tipo de ejecución distribuida en la que se transporta código y estado a destino. A diferencia de un agente móvil de software, este concepto no implica la actuación en representación de un usuario -------------------------------------------------------------------------------2

Paquete:En Java, representa una agrupación de tipos (ej. clases) -----------------------------------------26

Place:Entidad pasiva (no realiza acciones por cuenta propia) que le provee a los agentes un entorno de ejecución ------------------------------------------------------------------------------------------3

Plataforma:En JADE, representa las funcionalidades necesarias para que los agentes puedan operar ----------------------------------------------------------------------------------------------------------------------12

88


Protocolo de transporte de mensajes (MTP):En FIPA, es usado para el transporte físico de mensajes entre dos ACCs -------------------18

Realización:En FIPA, corresponde a una especificación que describe una funcionalidad particular y, en general, más detallada que en el caso abstracto ----------------------------------------------------16

Recurso:En OSGi OBR, representa un concepto genérico con capacidades y requerimientos -----47

Refrescar:En OSGi, respecto de un bundle, es la acción por la cual se le indica al framework que debe volver a resolverlo -------------------------------------------------------------------------------------30

Repositorio:En OSGi OBR, representa un conjunto de recursos ------------------------------------------------47

Requerimiento:En OSGi OBR, afirmaciones sobre las capacidades necesarias para un recurso ----------47

Resolución de un bundle:Proceso por el cual el bundle se interconecta con los demás según los paquetes que exporta e importa ---------------------------------------------------------------------------------------------28

Resuelto:En OSGi, respecto de un bundle, estado en el que todas sus dependencias están satisfechas ------------------------------------------------------------------------------------------------------29

Semántica o propiedad de exactly-once:Asociada a la ejecución de una tarea, indica el requerimiento de que esta se realice exactamente una sola vez -----------------------------------------------------------------------------------6

Servicio:En JADE, implementan funcionalidades que son coherentes entre sí (a nivel de plataforma) y son alojados en un nodo -----------------------------------------------------------------12En OSGi, funcionalidad ofrecida por un bundle, representada por una o más interfaces -30

Servicio de transporte de mensajes (MTS):En FIPA, servicio proveído por la plataforma para el transporte de mensajes ACL entre agentes. En JADE es utilizado solo para la comunicación entre distintas plataformas ----18

Slice:En JADE, componente del servicio que es responsable de aceptar comandos horizontales (entrantes) ------------------------------------------------------------------------------------------------------13

Sobre:En FIPA, parte del mensaje que contiene la información de transporte -----------------------18

Strong migration:Tipo de migración de un agente en la que este se transporta completamente, incluyendo su funcionalidad (código), estado de variables y el estado de ejecución ------------------------2

Sumidero destino o de entrada:En JADE, componente del servicio encargado de resolver una operación cuando el slice de dicho servicio genera un comando vertical --------------------------------------------------------13

Sumidero fuente o de salida:En JADE, componente de un servicio que es el encargado de resolver un pedido cuando el primero generó un comando vertical -----------------------------------------------------------------13

Symbolic name:En OSGi, propiedad de un bundle que representa un nombre simbólico asignado por su desarrollador ---------------------------------------------------------------------------------------------------30

Terminación abrupta de (crash):Relativo a un agente de software, indica la situación en la cual este funciona correctamente hasta que en un determinado momento deja de operar por completo (deteniéndose de forma anormal) --------------------------------------------------------------------------7

Weak migration:Tipo de migración de un agente en la que solo se transporta su funcionalidad y el estado de sus variables -------------------------------------------------------------------------------------------------2

Wiring:Interconexiones entre bundles realizadas en su resolución ---------------------------------------28

89

Bibliografía San Martín, Matías Ignacio

Bibliografía

«About | IPMS». 2012. About | Inter-Platform Mobility Project. Accedido Julio 7. https://tao.uab.cat/ipmp/.

Ahn, Jinho. 2010. «Atomic Mobile Agent Group Communication». En 2010 7th IEEE Consumer Communications and Networking Conference, 1–5. Las Vegas, NV, USA. doi:10.1109/CCNC.2010.5421595.

Aksit, Mehmet, Ken Wakita, Jan Bosch, Lodewijk Bergmans, y Akinori Yonezawa. 1994. «Abstracting Object Interactions Using Composition Filters».

Ametller-Esquerra, J., y J. Cucurull-Juan. 2012. «IPMS Documentation». Inter-Platform Mobility Service Documentation for the JADE Platform. Accedido Julio 29. https://tao.uab.cat/ipmp/files/README.

«Apache Felix». 2012. Accedido Agosto 4. http://felix.apache.org/site/index.html.«Apache Felix OSGi Bundle Repository». 2012. Accedido Agosto 4.

http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html.«Apache Subversion». 2012. Accedido Agosto 4. http://subversion.apache.org/.Baumann, J. 1997. «A protocol for orphan detection and termination in mobile agent

systems». Universität Stuttgart, Fakultät Informatik, Fakultätsbericht.Bellifemine, Fabio, Caire Giovanni, Trucco Tiziana, y Rimassa Giovanni. 2010. «Jade

Programmer’s Guide». http://jade.tilab.com/doc/programmersguide.pdf.Bellifemine, Fabio Luigi, Giovanni Caire, y Dominic Greenwood. 2007. Developing Multi-

Agent Systems with JADE. Wiley.Bellifemine, F., G. Caire, A. Poggi, y G. Rimassa. 2003. «JADE - A White Paper»

(Septiembre). http://sites.google.com/site/agentesunsl/WhitePaperJADEEXP.pdf.———. 2008. «JADE: A software framework for developing multi-agent applications. Lessons

learned». Information and Software Technology 50 (1-2): 10–21.Bellifemine, F., A. Poggi, y G. Rimassa. 1999. «JADE–A FIPA-compliant agent framework».

En Proceedings of PAAM, 99:97–108. http://www.dia.fi.upm.es/~phernan/AgentesInteligentes/referencias/bellifemine99.pdf.

Bradshaw, J. M. 1997. «An introduction to software agents». Software agents: 3–46.Claessens, Joris, Bart Preneel, y Joos Vandewalle. 2003. «(How) can mobile agents do

secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions». ACM Trans. Internet Technol. 3 (1): 28–48. doi:10.1145/643477.643479.

«ClassLoader - JSE7». 2011. ClassLoader (Java Platform SE 7 ). Accedido Noviembre 19. http://download.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html.

«Downloads | IPMS». 2012. Downloads | Inter-Platform Mobility Project. Accedido Octubre 1. https://tao.uab.cat/ipmp/node/16.

«Eclipse». 2012. Accedido Agosto 4. http://www.eclipse.org/.«FIPA». 2012. Welcome to the Foundation for Intelligent Physical Agents. Accedido Julio 14.

http://www.fipa.org/.«[FIPA00001]». 2012. FIPA Abstract Architecture Specification. Accedido Julio 1.

http://www.fipa.org/specs/fipa00001/.«[FIPA00023]». 2012. FIPA Agent Management Specification. Accedido Junio 30.

http://www.fipa.org/specs/fipa00023/.«[FIPA00067]». 2012. FIPA Agent Message Transport Service Specification. Accedido Julio 1.

http://www.fipa.org/specs/fipa00067/.«[FIPA00087]». 2012. FIPA Agent Management Support for Mobility Specification. Accedido

Julio 7. http://www.fipa.org/specs/fipa00087/index.html.«FIPA - Statement of Intent». 2012. Statement of Intent. Accedido Julio 1.

http://www.fipa.org/about/mission.html.

90


Franklin, Stan, y Art Graesser. 1996. «Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents»: 21–35.

Fuggetta, Alfonso, Gian Pietro Picco, y Giovanni Vigna. 1998. «Understanding Code Mobility». IEEE Transactions on Software Engineering 24: 342–361.

Giovanni, Caire. 2004. «JADE: the new kernel and last developments». http://jade.tilab.com/papers/Jade-the-services-architecture.pdf.

Gómez-Martínez, Elena, Sergio Ilarri, y José Merseguer. 2007. «Performance analysis of mobile agents tracking». En Proceedings of the 6th international workshop on Software and performance, 181–188. Buenes Aires, Argentina: ACM. doi:10.1145/1216993.1217024.

Gosling, J., B. Joy, G. Steele, G. Bracha, y A. Buckley. 2012. The Java language specification 7 Edition. 7.a ed. Addison-Wesley. http://www.cs.sysu.edu.cn/~lcw/ref/JLS-JavaSE7.pdf.

«guava-libraries». 2012. Accedido Agosto 4. http://code.google.com/p/guava-libraries/.«guava-osgi». 2012. Accedido Agosto 4. http://code.google.com/p/guava-osgi/.Halloway, Stuart Dabbs. 2002. Component Development for the Java Platform. Addison-

Wesley Professional.Hall, Richard, Karl Pauls, Stuart McCulloch, y David Savage. 2010. Osgi in Action: Creating

Modular Applications in Java. Manning Publications.Hall, Richard S. 2011. «Learning to ignore OSGi» Enero 25.

http://felix.apache.org/site/presentations.data/Learning_to_ignore_OSGi.pdf.Hall, Richard S., y The OSGi Alliance. 2006. «RFC-0112 Bundle Repository».

http://www.osgi.org/download/rfc-0112_BundleRepository.pdf.Harrison, Colin G., David M. Chess, y Aaron Kershenbaum. 1995. «Mobile Agents: Are they a

good idea?»«JADE». 2012. Jade - Java Agent DEvelopment Framework. Accedido Julio 4.

http://jade.tilab.com/.«JADE OsMoSes / Wiki / metrics». 2012. Accedido Octubre 12. http://sourceforge.net/p/jade-

osmoses/wiki/metrics/.«JADE OsMoSes / Wiki / Transmission Between Containers». 2012. Accedido Octubre 12.

https://sourceforge.net/p/jade-osmoses/wiki/metrics_nvo_data_transmission_between_containers/.

«JADE - The Board Members». 2012. Jade - Java Agent DEvelopment Framework - The Board Members. Accedido Julio 14. http://jade.tilab.com/theboard-members.htm.

Jansen, W., y T. Karygiannis. 1999. «Mobile agent security». Gaithersburg, MD: National Institute of Standards and Technology.

«Java Object Serialization Specification: Contents». 2012. Accedido Julio 7. http://docs.oracle.com/javase/6/docs/platform/serialization/spec/serialTOC.html.

«Java SE Overview». 2012. Accedido Agosto 4. http://www.oracle.com/technetwork/java/javase/overview/index.html.

Lange, Danny B., y Mitsuru Oshima. 1999. «Seven good reasons for mobile agents». Commun. ACM 42 (3): 88–89. doi:10.1145/295685.298136.

«LGPL v2.1». 2012. Accedido Octubre 1. http://www.gnu.org/licenses/lgpl-2.1.html.«LGPL v3.0». 2012. Accedido Julio 14. http://www.gnu.org/licenses/lgpl.html.Lindholm, Tim, Frank Yellin, G. Bracha, y Alex Buckley. 2012. The Java Virtual Machine

Specification 7 Edition. 7.a ed. Addison-Wesley.Milojicic, Dejan S, William LaForge, y Deepika Chauhan. 1998. «Mobile Objects and Agents

(MOA)». In Proc. Of The Fourth Usenix Conference On Object-Oriented Technologies And Systems: 179–194.

«Multithreaded Custom Class Loaders in Java SE 7». 2011. Accedido Diciembre 10. http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html.

Nam-Ho Kim, Yi-Seok Jeong, Sang-Hwan Ryu, y Dong-Ryeol Shin. 2007. «Mobile Healthcare System based on Collaboration between JADE and OSGi for Scalability». En Multimedia and Ubiquitous Engineering, 2007. MUE ’07. International Conference on, 126–129. doi:10.1109/MUE.2007.153. 10.1109/MUE.2007.153.

91


Nilchi, A. R.N, A. Vafaei, y H. Hamidi. 2008. «Evaluation of Security and Fault Tolerance in Mobile Agents».

Nwana, H. S. 1996. «Software agents: An overview». Knowledge Engineering Review 11 (3): 1–49.

«OSGi Alliance | About / Benefits of Using OSGi». 2011. Accedido Diciembre 10. http://www.osgi.org/About/WhyOSGi.

«OSGi Alliance | Technology / The OSGi Architecture». 2012. Accedido Julio 12. http://www.osgi.org/Technology/WhatIsOSGi.

Pham, V. A, y A. Karmouch. 1998. «Mobile software agents: An overview». IEEE Communications magazine 36 (7): 26–37.

Po-Cheng Huang, Cheng-Yi Chien, Kuan-Rong Lee, Yau-Hwang Kuo, y Ming-Zoo Wu. 2009. «An integration platform for developing context-aware applications based on context reasoning and service automation techniques». En 11th International Conference on Advanced Communication Technology, 2009. ICACT 2009, 03:1819–1823. IEEE.

Quarantotto, Elena, y Giovanni Caire. 2010. «JADE OSGi Guide». http://jade.tilab.com/doc/tutorials/JadeOsgiGuide.pdf.

Ribeiro, R. B.C, y R. B Soares. 2011. «The application of JADE and OSGi technologies in the telecommunications services architecture». En 2011 IEEE EUROCON - International Conference on Computer as a Tool (EUROCON), 1–4. IEEE. doi:10.1109/EUROCON.2011.5929389.

Rothermel, K., y F. Hohl. 1998. Mobile agents.Rothermel, K., y M. Strasser. 1998. «A fault-tolerant protocol for providing the exactly-once

property of mobile agents». En Reliable Distributed Systems, 1998. Proceedings. Seventeenth IEEE Symposium on, 100–108. doi:10.1109/RELDIS.1998.740480. 10.1109/RELDIS.1998.740480.

«Setting the class path». 2012. Accedido Julio 19. http://docs.oracle.com/javase/6/docs/technotes/tools/windows/classpath.html.

«Software framework - Wikipedia, the free encyclopedia». 2011. Accedido Diciembre 10. http://en.wikipedia.org/wiki/Software_framework.

Spanoudakis, N., y P. Moraitis. 2008. «An ambient intelligence application integrating agent and service-oriented technologies». Research and Development in Intelligent Systems XXIV: 393–398.

Sreedevi, R.N, U.N Geeta, U.P. Kulkarni, y A.R. Yardi. 2009. «Enhancing Mobile Agent Applications with Security and Fault Tolerant Capabilities». En 2009 IEEE International Advance Computing Conference, 992–996. Patiala, India. doi:10.1109/IADCC.2009.4809150.

«subclipse.tigris.org». 2012. Accedido Agosto 4. http://subclipse.tigris.org/.Tanenbaum, Andrew S., y Maarten van Steen. 2002. Distributed Systems: Principles and

Paradigms. US ed. Prentice Hall.«The netfilter.org “iptables” project». 2012. Accedido Septiembre 23.

http://www.netfilter.org/projects/iptables/index.html.«The netfilter.org project». 2012. Accedido Septiembre 23. http://www.netfilter.org/.The OSGi Alliance. 2009. OSGi Service Platform Core Specification: Release 4, Version 4.2.

Aqute Publishing.———. 2012a. OSGi Service Platform Core Specification: Release 5. Aqute Publishing.———. 2012b. OSGi Enterprise Release 5. Aqute Publishing.Veríssimo, Paulo, y Luís Rodrigues. 2001. Distributed systems for system architects.

Springer.«Wireshark». 2012. Accedido Septiembre 27. http://www.wireshark.org/.Zhao-wen, W., y W. Wei-dong. 2009. «Mobile Agent Intercommunicating Model Based on

Message Proxy».

92

Prueba de transmisión en LEAP IMTP San Martín, Matías Ignacio

Anexo IPrueba de transmisión en LEAP IMTP

Para aproximar el costo extra en el que se incurre al enviar información mediante un comando horizontal utilizando el protocolo de comunicación entre contenedores de JADE conocido como LEAP (de Lightweight Extensible Agent Platform), se implementó un servicio simple cuyo único objetivo es enviar comandos conteniendo un único byte de información.

Este servicio, luego de unos segundos de crearse, comienza con el envío de una secuencia de bytes hasta completar un total de mensajes configurable. Los mensajes son enviados al contenedor principal (no se dio opción de configuración para el destino ya que se trata de una prueba simple, y este contenedor es el único bien conocido y que es obligatorio para la existencia de la plataforma).

Finalmente, se utilizó la herramienta Wireshark [«Wireshark» 2012] para capturar y analizar el intercambio producido entre dos contenedores (el principal y uno aledaño); ambos ejecutando en máquinas virtuales Java independientes, dentro de la misma instancia del sistema operativo (las características del entorno de ejecución son equivalentes a las descriptas en la sección 8.2).

Como resultado del análisis descripto, se pudo identificar que, en el caso más frecuente, cada comando horizontal llevaba asociado tres segmentos TCP:

1. Con sentido desde el contenedor aledaño al principal y con una longitud de datos (payload del segmento TCP) de 167 bytes, el mensaje correspondiente al comando horizontal (conteniendo el byte transmitido).

2. Con sentido desde el contenedor principal al aledaño y con una longitud de datos de 19 bytes, el mensaje correspondiente a la respuesta del comando horizontal (notar que dicha respuesta es generada por JADE y no fue determinada por el servicio implementado).

3. Un segmento TCP correspondiente al ACK del ítem anterior (sin datos).

De estos resultados, se entiende que, para la prueba realizada, el costo extra (en contenido de segmentos TCP) de transmitir la información deseada es de: 166 bytes (usados en campos de control del comando horizontal), más 19 bytes (necesarios para la respuesta). A esto se le pueden sumar los 66 bytes requeridos para la información de control del conjunto de protocolos TCP/IP sobre Ethernet, por mensaje transmitido. Se debe tener en cuenta que, si bien en la captura realizada el caso más frecuente constaba de los tres segmentos mencionados, en rigor, la cantidad de segmentos puede variar entre dos y cuatro; siendo que los únicos obligatorios son los correspondientes al comando horizontal y su respuesta, y existiendo de forma opcional dos segmentos más debido a los respectivos ACK

93

Prueba de transmisión en LEAP IMTP San Martín, Matías Ignacio

(donde el último ACK solo será necesario en el caso de que no se requiera enviar más información).

Finalmente, cabe resaltar que los valores aquí presentados son dependientes de la prueba realizada, y que para otra información transmitida por otro servicio, los resultados cambiarán. En particular, sin hacer un análisis detallado del protocolo LEAP IMTP y de como este representa los datos transmitidos, se pudo observar que parte del contenido de los segmentos analizados (correspondientes al comando horizontal), incluían el nombre del servicio que los originaba, así como también el nombre de la clase que definía su información.

94

Documents

Un servicio de movilidad de agentes de software para …materias.fi.uba.ar/7500/SanMartin.pdf · tradicionales como pueden ser aquellos basados en ... que cumpla con los objetivos