LogicRaptors - ktulu.com.ar

Transcripción

LogicRaptors
“Una Arquitectura de Software Integrada a la WWW
para Soportar Agentes Móviles Basados en Prolog”
Tesis de Grado de la carrera Ingeniería de Sistemas
Julio 2002
Alumnos:
Diego Tolbaños
Luis Parravicini
Directores:
Alejandro Zunino
Edgardo Belloni
Facultad de Ciencias Exactas
Universidad del Centro de la Provincia de Buenos Aires
Indice de Contenidos
1 Introducción...........................................................................................................................................1
1.1 Motivaciones ....................................................................................................................................1
1.2 Solución Propuesta ...........................................................................................................................3
1.2.1 Infraestructura para el soporte de Agentes Móviles Inteligentes ...............................................3
1.2.2 LogicRaptors .............................................................................................................................4
1.2.3 Aplicaciones del trabajo ............................................................................................................5
1.3 Organización de la documentación...................................................................................................6
2 Conceptos Básicos sobre Agentes de Software y Agentes Móviles ............................................7
2.1 Introducción......................................................................................................................................7
2.2 Paradigmas de redes de computación ...............................................................................................8
2.2.1 Paradigma Cliente-Servidor ......................................................................................................9
2.2.2 Paradigma de Código por Demanda ..........................................................................................9
2.2.3 Paradigma de Evaluación Remota ...........................................................................................10
2.2.4 Paradigma de Agentes Móviles ...............................................................................................10
2.3 Agentes de Software.......................................................................................................................11
2.3.1 Clausura de Agentes ................................................................................................................12
2.4 Movilidad .......................................................................................................................................12
2.4.1 Nodos.......................................................................................................................................13
2.4.2 Movilidad de Agentes..............................................................................................................13
2.4.2.1 Agentes Estacionarios.......................................................................................................13
2.4.2.2 Agentes móviles ...............................................................................................................14
2.4.2.3 Contexto ...........................................................................................................................16
2.4.2.4 Lugares de ejecución ........................................................................................................16
2.5 Sistemas de agentes móviles...........................................................................................................16
2.5.1 Sistemas de Agentes Móviles vs Sistemas Middleware ..........................................................17
2.5.2 Características de los Sistemas de Agentes Móviles ...............................................................17
2.5.2.1 Ejecución de agentes ........................................................................................................17
2.5.2.2 Generación y administración de identidades ....................................................................18
2.5.2.3 Persistencia .......................................................................................................................18
2.5.2.4 Migración .........................................................................................................................19
2.5.2.5 Comunicación...................................................................................................................20
2.5.2.6 Acceso a recursos externos...............................................................................................21
2.5.2.7 Seguridad..........................................................................................................................21
2.5.3 Estandarización – MASIF – ....................................................................................................22
2.6 Aplicaciones basadas en agentes ....................................................................................................22
2.6.1 El conocimiento.......................................................................................................................22
2.6.2 Comunidades de Agentes ........................................................................................................23
2.6.2.1 Comunidad Homogénea ...................................................................................................23
2.6.2.2 Comunidad Heterogénea ..................................................................................................23
2.6.3 Aplicaciones de Agentes Móviles ...........................................................................................24
2.7 Usuarios finales ..............................................................................................................................25
3 Catálogo de Sistemas de Agentes Móviles ....................................................................................26
3.1 Introducción....................................................................................................................................26
3.2 Sistemas de Agentes Móviles .........................................................................................................26
3.2.1 Telescript .................................................................................................................................27
3.2.2 Aglets workbench....................................................................................................................28
3.2.3 ffMAIN....................................................................................................................................30
3.2.4 D'Agents ..................................................................................................................................31
3.2.5 AgentSpace..............................................................................................................................32
3.2.6 JiNNI .......................................................................................................................................34
3.3 Sistemas de Agentes Móviles alternativos .....................................................................................36
3.3.1 Voyager universal ORB...........................................................................................................36
i
3.3.2 Jumping Beans.........................................................................................................................37
3.3.3 Concordia ................................................................................................................................39
3.4 Comparaciones de los Sistemas de Agentes Móviles .....................................................................40
3.4.1 Similitudes...............................................................................................................................40
3.4.2 Diferencias...............................................................................................................................40
3.4.2.1 Terminología ....................................................................................................................40
3.4.2.2 Temas de nivel de soporte ................................................................................................41
3.4.2.3 Temas del nivel de administración ...................................................................................41
3.4.2.4 Temas del nivel de aplicación...........................................................................................42
3.4.2.5 Lenguajes de los agentes ..................................................................................................42
3.4.3 Características técnicas............................................................................................................42
3.4.3.1 Identidades........................................................................................................................42
3.4.3.2 Persistencia .......................................................................................................................43
3.4.3.3 Migración .........................................................................................................................43
3.4.3.4 Comunicación...................................................................................................................43
3.4.3.5 Acceso a recursos externos...............................................................................................44
3.4.3.6 Seguridad..........................................................................................................................44
3.4.3.7 Integración con la web......................................................................................................44
4 LogicRaptors .......................................................................................................................................45
4.1 Introducción....................................................................................................................................45
4.2 Arquitectura de Referencia.............................................................................................................45
4.3 LogicRaptor (Agente Móvil Inteligente) ........................................................................................47
4.4 Implementación de la Arquitectura ................................................................................................48
4.4.1 Nests ........................................................................................................................................48
4.4.2 Administrador de Agentes (AgentManager)............................................................................49
4.4.3 Administrador de Confiabilidad ..............................................................................................49
4.4.4 Servicio de Directorios ............................................................................................................50
4.5 Método de Extensión de JavaLog...................................................................................................50
4.5.1 Mecanismo de Extensión.........................................................................................................50
4.5.2 Nuevos Predicados ..................................................................................................................52
4.6 Protocolo MTP ...............................................................................................................................52
4.6.1 Descripción..............................................................................................................................53
4.6.2 Servicios de los Componentes .................................................................................................53
4.6.2.1 Nest...................................................................................................................................53
4.6.2.2 ExtendedNest....................................................................................................................54
4.6.2.3 Directory...........................................................................................................................55
4.6.3 Clases de MTP.........................................................................................................................55
4.7 LogicRaptors Center.......................................................................................................................57
4.7.1 Requerimientos........................................................................................................................57
4.7.2 Descripción de la Herramienta ................................................................................................57
4.7.2.1 Raptor Manager ................................................................................................................58
4.7.2.2 Nest View .........................................................................................................................58
4.7.2.3 Nest Observer ...................................................................................................................59
4.7.2.4 Documentation .................................................................................................................60
4.7.3 Implementación .......................................................................................................................60
4.8 Características técnicas de la arquitectura propuesta...................................................................... 61
4.8.1 Identidades...............................................................................................................................61
4.8.2 Persistencia ..............................................................................................................................61
4.8.3 Migración ................................................................................................................................62
4.8.4 Comunicación..........................................................................................................................62
4.8.5 Acceso a recursos externos......................................................................................................62
4.8.6 Seguridad.................................................................................................................................62
4.8.7 Integración con la web.............................................................................................................62
5 Performance de los LogicRaptors versus Agentes Estacionarios ..............................................63
5.1 Introducción....................................................................................................................................63
5.2 Descripción de la Experiencia ........................................................................................................64
5.2.1 El Problema de la Búsqueda de Información...........................................................................64
5.2.2 Diseño de la Solución .............................................................................................................64
ii
5.2.2.1 Librerías............................................................................................................................64
5.2.2.2 Configuración de los Agentes...........................................................................................65
5.2.2.3 Aproximación con Agentes Estacionarios ........................................................................65
5.2.2.4 Aproximación con Agentes Móviles ................................................................................66
5.2.3 Ambiente de Ejecución............................................................................................................67
5.3 Testeo y Análisis ............................................................................................................................67
5.3.1 KSnuffle ..................................................................................................................................68
5.3.2 Resultados ...............................................................................................................................68
5.3.2.1 Cantidad de paquetes ........................................................................................................68
5.3.2.2 Tráfico en kilobytes ..........................................................................................................69
5.3.2.3 Cantidad total de datos transmitidos en kilobytes.............................................................69
5.3.2.4 Tiempo consumido en minutos.........................................................................................69
5.3.3 Análisis de los datos obtenidos................................................................................................70
5.3.3.1 Tráfico generado en la red ................................................................................................70
5.3.3.2 Overhead de comunicación...............................................................................................71
5.3.3.3 Impacto en las comunicaciones ........................................................................................71
5.3.3.4 Tiempos de Ejecución ......................................................................................................73
5.4 Conclusiones de la experiencia.......................................................................................................74
6 Conclusiones.......................................................................................................................................76
6.1 Limitaciones y posibles trabajos futuros ........................................................................................77
Apéndice A: JavaLog ............................................................................................................................79
A.1 Introducción...................................................................................................................................79
A.2 Integración de objetos y lógica ......................................................................................................80
A.3 El lenguaje JavaLog.......................................................................................................................81
A.3.1 Objetos Java en programas Prolog..........................................................................................81
A.3.1.1 Creación...........................................................................................................................81
A.3.1.2 Interacción Java-Prolog ...................................................................................................81
A.3.1.3 Envío de mensajes ...........................................................................................................82
A.3.2 Prolog Embebido ....................................................................................................................83
A.3.2.1 Módulos lógicos...............................................................................................................83
A.3.2.2 Composición de Módulo lógicos .....................................................................................88
A.3.2.3 Preprocesador JavaLog....................................................................................................90
A.4 Interacción entre agentes ...............................................................................................................90
A.4.1 Arquitectura Blackboard.........................................................................................................91
A.4.2 Delegación ..............................................................................................................................93
Glosario de Términos............................................................................................................................96
Referencias Bibliográficas....................................................................................................................99
iii
Indice de Figuras
Figura 1.1: Componentes de la arquitectura de referencia
Figura 2.1: Paradigma Cliente-Servidor
Figura 2.2: Paradigma de Código por Demanda
Figura 2.3: Paradigma de Evaluación Remota
Figura 2.4: Paradigma de Agentes Móviles
Figura 2.5: Diferentes semánticas ofrecidas por la operación de migración
Figura 2.6: Relaciones entre un agente, y comunidades homogéneas y heterogéneas
Figura 3.1: Esquema conceptual del framework Telescript
Figura 3.2: Esquema conceptual del framework de los Aglets
Figura 3.3: Esquema conceptual del framework ffMAIN
Figura 3.4: Esquema conceptual del framework D´Agents
Figura 3.5: Arquitectura AgentSpace
Figura 3.6: Arquitectura Jumping Beans
Figura 4.1: Diagrama de componentes de la arquitectura de referencia
Figura 4.2: Diagrama de clases de los Nests
Figura 4.3: Diagrama de Interacción de la carga de los predicados definidos
Figura 4.4: Diagrama de clases de Javalog.raptors.mtp
Figura 4.5: Vista de la interface de RaptorManager
Figura 4.6: Vista de la interface de NestView
Figura 4.7: Vista de la interface de NestObserver
Figura 4.8: Diagrama de clases de LogicRaptors Center
Figura 5.1: Diagrama de secuencia de búsqueda de un agente estacionario
Figura 5.2: Diagrama de secuencia de búsqueda de un LogicRaptor
Figura 5.3: Tráfico de red generado por los LogicRaptors vs los agentes estacionarios
Figura 5.4: Porcentaje de desperdicio de ancho de banda
Figura 5.5: Tráfico de red generado por los Agentes Estacionarios
Figura 5.6: Tráfico de red generado por los LogicRaptors
Figura 5.7: Tiempo de ejecución de los LogicRaptors vs los agentes estacionarios
Figura A.1: Esquema de composición de módulos
Figura A.2: Arquitectura Blackboard
Figura A.3: Sistema de múltiples comunidades de agentes
Figura A.4: Interacción entre agentes
04
09
10
10
11
20
24
28
29
31
32
33
37
46
48
51
55
58
59
60
61
66
66
70
71
72
72
74
80
92
94
94
iv
Indice de Tablas
Tabla 4.1: Descripción de los predicados incorporados a JavaLog.
Tabla 5.1: Características de las computadoras utilizadas en la primer escenario de
la experiencia.
Tabla 5.2: Características de las computadoras utilizadas en el segundo escenario de la
experiencia.
Tabla 5.3: Datos obtenidos de la cantidad de paquetes transmitidos.
Tabla 5.4: Datos obtenidos del tráfico de red generado.
Tabla 5.5: Datos obtenidos de la cantidad total de datos transmitidos.
Tabla 5.6: Datos obtenidos del tiempo de ejecución con velocidad de transmisión de 100
mbps.
Tabla 5.7: Datos obtenidos del tiempo de ejecución con velocidad de transmisión de 10 mbps.
52
67
67
68
69
69
69
70
v
1
Introducción
En este capítulo se presentan las motivaciones y
objetivos del presente trabajo, dando además una
primera visión general de la solución propuesta.
También se describe la organización del resto de
esta documentación.
1.1 Motivaciones
La tecnología orientada a agentes de software y sus diversas ramas aparecen hoy
en día como una de las más importantes para construir el software de las futuras
computadoras. El éxito creciente de esta nueva generación de servicios y aplicaciones
basadas en agentes produce un potencial industrial y un impacto económico en
diferentes áreas. Entre las principales podemos mencionar: el comercio, los medios de
comunicación, y en general todas aquellas áreas en donde sea necesario la adquisición
y el manejo de información.
Uno de los dominios mas importantes hoy en día de las aplicaciones basadas en
agentes es Internet, y aunque la tecnología de las comunicaciones ha tenido un notable
crecimiento estos últimos años, no ha podido crecer a la misma velocidad en que lo ha
hecho la cantidad de información disponible en toda la red. Por otro lado, al mismo
tiempo que creció la cantidad de información, también se incrementó el número de
usuarios que utiliza los servicios provistos en Internet. Por lo tanto, se puede inferir
que pronto los canales de comunicación no serán suficientes para abastecer las
demandas de todos los usuarios, y debido a eso es que paradigmas computacionales de
redes clásicos como el paradigma Cliente-Servidor o el paradigma de código en
Demanda, están siendo reemplazados por el paradigma de agentes móviles.
Dentro de las tecnologías orientadas a agentes, particularmente los sistemas de
agentes móviles representan actualmente uno de los paradigmas más prometedores
para la programación de sistemas ampliamente distribuidos y heterogéneos [Chess 95].
Este tipo de sistemas involucra dos conceptos básicos: sitios servidores de recursos y
agentes que poseen la habilidad de trasladarse a los sitios para acceder a sus recursos, o
contactarse con otros agentes [Kotz 99]. La movilidad de agentes, es decir su habilidad
de migrar de un sitio a otro, constituye la principal diferencia de enfoque con respecto
a otras alternativas existentes para el desarrollo de sistemas distribuidos, como los de
llamadas a procedimientos remotos, evaluación remota o código por demanda
[Fuggetta 98].
Introducción
Las principales ventajas identificadas en el uso de agentes móviles, radican en la
potencial reducción de costos de comunicación global mediante la migración de las
unidades de computación a los datos y la posibilidad de distribuir computaciones
complejas en diferentes sitios, posiblemente heterogéneos. Adicionalmente, varios
trabajos [Lange 99], [Gray 00], [Wong 97] han mostrado la utilidad de los agentes
móviles para aplicaciones de comercio electrónico, recuperación de información
distribuida, entre otras. Tales aplicaciones se benefician al utilizar agentes móviles al
explotar sus capacidades de procesamiento autónomo y asincrónico, adaptabilidad
dinámica a los cambios de su ambiente de ejecución y tolerancia a fallas.
Los lenguajes de programación orientados a objetos poseen características que
permiten satisfacer parte de los requerimientos de la programación orientada a agentes
[Shoham 97] y en particular de agentes móviles [Wong 99]. Según estos enfoques, un
agente puede modelarse mediante un objeto cuyos métodos representan sus
habilidades, y las variables de instancia su estado mental. De esta forma, un objeto
encapsulará en sus métodos capacidades comportamentales de un agente y su
conocimiento estará dado por el estado de sus variables de instancia.
Actualmente, se ha desarrollado un número importante de sistemas que utilizan
el lenguaje orientado a objetos Java como soporte de programación de agentes móviles.
Ejemplos de estos sistemas de soporte basados en Java, son: Aglets [Lange 98], SOMA
[Bellavista 99] y MOLE [Strasser 96]. Las ventajas que Java provee a la tecnología de
agentes móviles, son fundamentalmente su soporte multiplataforma y la ubicuidad de
su máquina virtual, lo cual facilita la adopción de agentes móviles en Internet.
Adicionalmente, Java presenta características no encontradas en otros lenguajes que
permiten la implementación directa de agentes móviles [Wong 99]. Por ejemplo, Java
facilita la migración del código del agente y su estado mediante mecanismos de
serialización de objetos y carga dinámica de clases locales o remotas. Por otra parte, el
soporte de comunicaciones en redes provisto por Java incluye sockets, comunicaciones
mediante diversos protocolos y una infraestructura para el acceso a objetos distribuidos
denominado remote method invocation (RMI).
A pesar de las bondades que los lenguajes orientados a objetos presentan para la
programación orientada a agentes en general, y Java en particular para agentes
móviles, estos lenguajes adolecen sin embargo de limitaciones. Estas limitaciones se
evidencian a la hora de tratar con las actitudes mentales de los agentes, debido a que se
deben implementar distintos algoritmos de inferencia sobre las variables de instancia
que representan el conocimiento del agente. Estos algoritmos, en caso de ser
implementados en lenguajes orientados a objetos, son en general, costosos de
programar y poco flexibles a cambios [Zunino 01].
Es ampliamente aceptado que el paradigma de programación lógica representa
una alternativa apropiada para manejar actitudes mentales debido a su evidente soporte
para representar e inferir relaciones [Wooldridge 99]. Los lenguajes de programación
en lógica permiten representar actitudes mentales en forma declarativa por medio de
cláusulas lógicas. Estas cláusulas son interpretadas por algoritmos deductivos que, en
el contexto de la programación de agentes, dan origen a razonamientos dependientes
del conocimiento propio de los agentes. Desafortunadamente, los lenguajes lógicos
presentan deficiencias en la programación de agentes debido a su imposibilidad de
encapsular información y tratar con conocimiento privado [Amandi et al. 99].
JavaLog es un lenguaje de programación multiparadigma que integra ambas,
programación lógica y orientada a objetos, por lo tanto facilita y mejora el desarrollo
2
Introducción
de sistemas de agentes inteligentes. Esto ayuda a solucionar las limitaciones
mencionadas anteriormente, permitiendo a los agentes manejar actitudes mentales
complejas.
Para poder integrar las ventajas que proveen los sistemas de agentes móviles
mencionadas anteriormente, principalmente la reducción de costos de comunicación
con las ventajas de utilizar agentes programados en Prolog se necesita tener una
arquitectura que brinde soporte para la movilidad de tales tipos de agentes.
Entre todos los sistemas de agentes móviles existentes, el más similar a nuestro
sistema de agentes móviles ideal es Jinni, el cual consiste de un interprete Prolog
desarrollado en Java. Pero, aunque presenta las ventajas mencionadas anteriormente
sobre el uso conjunto de los paradigmas orientado a objetos y lógico; presenta también
varias desventajas. Sólo soporta un subconjunto muy reducido de Prolog, lo que limita
considerablemente su potencia expresiva. Otro aspecto que dificulta enormemente la
utilización de Jinni lo constituye su limitado esquema de migración de unidades de
ejecución. A pesar de que las alternativas para solucionar estas deficiencias utilizando
los recursos propios del lenguaje son variadas, todas ellas adolecen de dos problemas:
no son transparentes para el programador y en ciertos casos generan más problemas
que los que solucionan. Estudiaremos con más detalle este sistema en el capítulo 3.
Nuestra propuesta consiste en una arquitectura que permite implementar sistemas
de agentes móviles usando Javalog. Esto permite que los agentes sean programados
usando el paradigma de programación en lógica y todos los mecanismos de
comunicación estén implementados en Java.
1.2 Solución Propuesta
En esta propuesta se presenta un enfoque para soportar el diseño y programación
de agentes móviles inteligentes basados en Prolog. Este enfoque es materializado
esencialmente por una arquitectura de software basada en agentes móviles
desarrollados en JavaLog [Amandi et al. 99], [Zunino 01], un lenguaje que integra los
paradigmas de programación lógica y de orientación a objetos.
1.2.1 Infraestructura para el soporte de Agentes Móviles Inteligentes
La Figura 1.1 presenta una arquitectura de software para el soporte de agentes
móviles inteligentes. Esta se basa esencialmente en la arquitectura genérica de agentes
móviles basados en Java descripta en [Belloni - Campo 01]. En el diagrama, que utiliza
notación UML [Rumbaugh et al. 99], se pueden visualizar los diferentes componentes
que forman parte de la arquitectura.
Los principales componentes son el administrador de agentes, el administrador
de comunicaciones entre agentes, el administrador de seguridad, el administrador de
confiabilidad, el portal servidor de aplicaciones y un administrador de directorios.
El administrador de agentes es responsable por la recepción de agentes para su
ejecución en el sitio local y del envío de agentes para ser ejecutados en sitios remotos.
Antes de efectuar la migración de un agente, este administrador lo serializa junto
con su estado. Luego, delega el envío de esta representación serializada del agente al
administrador de confiabilidad, el cual asegura que el agente es recibido por el
administrador de agentes correspondiente en el sitio destino. Al recibirlo, este
3
Introducción
componente reconstruye el agente y los objetos que el referencia, a partir de su
representación serializada, creando su contexto de ejecución.
Servidor de Agentes Móviles Inteligentes
Administrador de
Comunicaciones
entre Agentes
Servidor de Agentes
Móviles Inteligentes
Administrador
de Agentes
Administrador de
Acceso a Servidores
de Aplicaciones
Aplicación
Externa
Brain
Agente Móvil
Inteligente
(LogicRaptor)
Módulo
Lógico
Administrador
de Confiabilidad
Administrador
de Seguridad
Administrador
de Directorios
Figura 1.1: Componentes de la arquitectura de referencia
El administrador de seguridad es responsable por la autenticación del agente
antes de que este comience su ejecución. La máquina virtual Java subyacente invocará
automáticamente a este componente para autorizar cualquier intento de utilizar
recursos del sistema por parte de los agentes.
El administrador de comunicaciones entre agentes facilita la comunicación entre
agentes móviles dispersos en diferentes sitios. Los agentes pueden utilizar el
administrador de directorios para identificar la localización de un servidor de
aplicaciones y luego migrar al sitio en el cual este servidor esta localizado. El portal
servidor de aplicaciones representa para los agentes un punto de acceso a aplicaciones
externas al sistema de agentes móviles, residentes en el sitio local, como por ejemplo
acceso a servidores de bases de datos.
1.2.2 LogicRaptors
Los agentes móviles descriptos son implementados con JavaLog [Amandi et al.
99], [Zunino 01], un lenguaje que integra los paradigmas de orientación a objetos
(Java) y de programación lógica (Prolog). JavaLog utiliza objetos para modelar las
habilidades de los agentes y cláusulas lógicas para modelar el estado mental de dichos
agentes. Las habilidades de los agentes pueden estar representadas por capacidades de
acción como por capacidades de comunicación con otros agentes, mientras que el
estado mental puede presentarse en forma de creencias, intenciones y compromisos.
JavaLog define al módulo como concepto básico de manipulación. En este sentido, un
objeto y un método son vistos como módulos. Un objeto es un módulo que encapsula
datos y un método es un objeto que encapsula comportamiento
Los agentes móviles construidos con JavaLog son denominados LogicRaptors.
Estos agentes encapsulan un objeto compuesto denominado brain. Este objeto es una
4
Introducción
instancia de un intérprete de módulos lógicos que utiliza cláusulas Prolog. Este
intérprete está implementado en Java y permite utilizar objetos dentro de cláusulas
lógicas, así como embeber módulos lógicos dentro de código Java. Cada agente es una
instancia de una clase que puede definir parte de sus métodos en Java y parte en
Prolog. La definición de los métodos de una clase en JavaLog puede estar compuesta
por varios módulos lógicos definidos en métodos y módulos lógicos referenciados por
variables de instancia.
Adicionalmente, la arquitectura permite incorporar servicios más inteligentes a
los sitios Web mediante la utilización de agentes inteligentes móviles. Así, en cada
sitio capaz de ejecutar LogicRaptors, existe al menos un Nest, el cual funciona como
una dársena Web para los LogicRaptors, permitiendo así extender aplicaciones legadas
cliente / servidor basadas en la Web con agentes móviles LogicRaptors.
1.2.3 Aplicaciones del trabajo
El enfoque presentado para desarrollo de agentes va a ser aplicado en el dominio
Socialware. El término Socialware se utiliza para caracterizar al tipo de sistemas
multiagente que proveen mecanismos de asistencia a las actividades de sociedades
virtuales [Hattori 99]. Como ejemplos típicos de estas actividades se encuentra el
comercio electrónico, planificación de reuniones y convocatorias u ofrecimientos de
voluntarios a campañas solidarias.
Las aplicaciones descriptas pueden verse beneficiadas con el uso de agentes
móviles representando a diferentes miembros de una comunidad virtual al desarrollar
actividades sociales en comunidades remotas. Tales agentes podrían transportar las
preferencias y restricciones de su representado, encapsulando estas actitudes mentales
en forma declarativa.
En particular, se utilizarán LogicRaptors en aplicaciones del dominio Socialware
con el fin de establecer experimentalmente las ventajas de la utilización de agentes
móviles respecto de tecnologías cliente / servidor tradicionales. En tal sentido, se
evaluarán aspectos tales como performance, tráfico de red (tanto en LAN como en
WAN), uso de recursos de hardware, etc.
Como parte de este trabajo se realizó una experiencia cuyo principal propósito es
recolectar datos cuantitativos que permitan determinar precisamente bajo que
circunstancias conviene la utilización de agentes móviles y en que casos no. Mas aún,
el objetivo de las mediciones es permitir fundamentar la conveniencia de elegir el uso
de agentes móviles, en nuestro caso los LogicRaptors, por sobre los agentes
estacionarios, cuando las comunicaciones son muy frecuentes y a una velocidad de
transferencia muy inferior a la de una red local, como es el caso de Internet.
Para realizar el análisis de performance entre los distintos sistemas multi-agentes
desarrollamos soluciones con agentes móviles (LogicRaptors) y estacionarios al
problema de búsqueda de información distribuida en Internet, más precisamente
búsqueda de libros entre diferentes librerías virtuales. Cada una de las aproximaciones
fue evaluada usando varias métricas para poder descubrir las ventajas y desventajas de
cada variante.
5
Introducción
1.3 Organización de la documentación
En el capítulo 2 se resumen los conceptos básicos y la terminología utilizada en
el paradigma de agentes en general y en el de agentes móviles en particular. En el
capítulo 3 se presentan algunos de los sistemas multi-agentes, mas significativos,
existentes actualmente,. En el capítulo 4 se detalla el diseño y la implementación de
nuestra propuesta. Luego en el capítulo 5 se detalla una experiencia realizada a fin de
medir el desempeño de los LogicRaptors comparándolos con agentes estacionarios. En
el capítulo 6 se enumeran las conclusiones y trabajos futuros. Finalmente en el
apéndice A, se detallan las características más importantes de Javalog.
6
2
Conceptos Básicos sobre
Agentes de Software
y Agentes Móviles
Este capítulo resume los conceptos básicos y la terminología utilizada
en el paradigma de agentes en general y en el de agentes móviles en particular.
2.1 Introducción
El paradigma de agentes no es nuevo puesto que ha sido una línea de
investigación profusa en el área de Inteligencia Artificial Distribuida durante un
número importante de años.
En el presente, la world wide web y el lenguaje de programación Java han
inyectado un gran interés por la investigación, desarrollo y difusión del paradigma de
agentes. Una motivación particular para la utilización de agentes, hoy día, es la enorme
cantidad de información disponible en Internet. En este contexto, los agentes presentan
un potencial significativo en la búsqueda, recuperación y filtrado de información. Así
mismo, la habilidad de los agentes para actuar en representación de los usuarios
constituye una capacidad crucial del paradigma que garantiza su inminente
implementación y distribución en un ámbito como el de Internet.
Actualmente, existen al menos dos comunidades realizando investigación y
desarrollos en el área de agentes: la comunidad de sistemas multi-agente y la
comunidad de agentes móviles. La primera de estas comunidades se enfrenta
mayormente a los problemas inherentes a los agentes estacionarios distribuidos en una
red, los cuales pueden comunicarse y colaborar persiguiendo un objetivo común. La
otra comunidad trata a los agentes móviles como un paradigma para el desarrollo de
sistemas ampliamente distribuidos y heterogéneos. Esta última comunidad se ve
representada en su mayoría por investigadores y desarrolladores en el área de
tecnologías orientadas a objetos con una fuerte capacitación en sistemas operativos y
sistemas distribuidos.
Conceptos Básicos sobre Agentes de Software y Agentes Móviles
Por lo tanto, y debido a que el paradigma de desarrollo basado en agentes de
software es un área multidisciplinaria, se hace necesario establecer en primer término,
un contexto común para discutir sobre agentes, sistemas de agentes y aplicaciones
basadas en agentes. Este contexto común facilitará luego la comprensión y
comparación de los Sistemas de Agentes Móviles existentes.
En el presente capítulo se explican los principales paradigmas de redes de
computación existentes en la actualidad (sección 2). Luego se introduce las
definiciones básicas de agente, clausura de agentes y nodos (sección 3). Se presentan
además, los conceptos relacionados con la movilidad de un agente (sección 4), y se
establecen las definiciones elementales de contexto y lugar de ejecución (sección 5).
Posteriormente, en la sección 6, se desarrolla el concepto de sistema de agentes
móviles detallando las características principales de este tipo de sistemas. Finalmente,
se caracterizan también las aplicaciones basadas en agentes en términos generales, y
las de agentes móviles en particular (sección 7), resaltando además el rol de los
usuarios en este tipo de aplicaciones (sección 8).
2.2 Paradigmas de redes de computación
Poner a la disposición la capacidad de procesamiento de los sitios de una red no
es una idea nueva, sino al contrario, se trata de una técnica muy usual; el paradigma
cliente/servidor es la base para distribuir la utilización de los recursos de una red,
incluyendo, desde luego, el de procesamiento. Bajo este esquema, el código
denominado servicio, está prefijado en una estación que juega un papel específico -el
servidor- y que está a la disposición de todos los sitios cliente. Bajo este esquema se
puede distribuir el cómputo mediante la instalación de servicios en diferentes
servidores de la red. Gracias a esta popular arquitectura, se han desarrollado
intensamente los sistemas distribuidos que conocemos en la actualidad; sin embargo al
crecer cada vez más las redes, se encontraron límites a este esquema.
Así, se empezó a sentir la necesidad de flexibilizar la ejecución distribuida,
basada en servicios prefijados en un servidor. Una primera idea fue la siguiente, en
lugar de que los servicios estuvieran fijos siempre en una estación, por qué no
moverlos a cualquiera de las estaciones conectadas a la red. Así, por ejemplo,
aparecieron los programas que residen en el servidor pero que son ejecutados en los
clientes (código en demanda); con esta técnica se libera a los servidores, aligerando su
carga y por lo tanto, su tiempo de respuesta. Posteriormente, apareció Java como un
lenguaje orientado a objetos y de propósito general, que permite la distribución de
código a clientes remotos. Otra idea fue, si es posible mover código del servidor al
cliente, por qué no, del cliente al servidor; este paradigma llamado evaluación remota,
dio nacimiento al término de servidores elásticos. Con esta facilidad, el servidor no
está sólo restringido a la ejecución de servicios generales prefijados, sino además,
puede ejecutar servicios específicos requeridos por un cliente, quien envía el código
correspondiente, pero no cuenta con los recursos que tiene el servidor. Así, una vez
liberado el sentido del movimiento, por qué no liberar la iniciativa en la migración. De
este modo, un programa con capacidad de migrar podría decidir por sí mismo una
nueva migración si en el sitio al que llegó no encontró la información o los recursos
necesarios para completar su misión. Para que esto sea factible, es necesario que el
control de migración tenga una mayor flexibilidad y que esté a la disposición del
programador de este tipo de aplicaciones. El mecanismo de decisión de migrar puede
ser prefijado en un lenguaje imperativo como C o bien podría flexibilizarse aún con
8
técnicas de programación declarativa como la orientada a objetos o incluso, aún más,
dando al lenguaje capacidades de procesar y almacenar conocimiento tal, que al viajar,
le permita modificar, tanto su propio conocimiento como el del sitio visitado (si éste
contara también con esa misma capacidad).
Con este último esquema entramos en el terreno de la inteligencia artificial y a
dicho tipo de entidades se les conoce como agentes móviles (entidades autónomas con
una gran flexibilidad de movimiento y de cómputo). Así, mover y ejecutar código
distante son los mecanismos fundamentales de este nuevo tipo de paradigma.
Los agentes móviles proveen un paradigma poderoso y uniforme para redes de
computación. Pueden revolucionar el diseño y desarrollo de sistemas distribuidos, para
comprender mejor esto analizaremos con más detalle los paradigmas de redes de
computación antes mencionados.
2.2.1 Paradigma Cliente-Servidor
En el paradigma Cliente-Servidor (figura 2.1), el servidor publica un conjunto
de servicios para acceder a algunos recursos. El código que implementa esos servicios
está en el servidor (se dice que el servidor mantiene el know-how) y se ejecuta ahí
mismo, es decir que el servidor también tiene la capacidad de procesamiento. Si el
cliente está interesado en acceder a un recurso almacenado en el servidor entonces
simplemente usa uno o más de los servicios provistos. Por lo tanto, en este paradigma
el servidor mantiene todo: los recursos, el procesamiento y el know-how.
Servidor
Know
How
Cliente
Figura 2.1: Paradigma Cliente-Servidor
La mayoría de los sistemas distribuidos estén basados en este paradigma y es
soportado por varias tecnologías como: Llamado a Procedimiento Remoto (RPC),
CORBA, Invocación a Métodos Remotos de Java (RMI), etc.
2.2.2 Paradigma de Código por Demanda
En el paradigma de código por demanda (figura 2.2) cuando el cliente es
incapaz de ejecutar una tarea debido a la falta del código (know-how) puede
solicitárselo a otro nodo en la red.
Una vez que el código es recibido por el cliente la computación es llevada a
cabo en el cliente. Por lo tanto el cliente mantiene la capacidad de procesamiento y los
recursos.
9
Servidor
Cliente
Download
(Applet)
Know
How
Know
How
Figura 2.2: Paradigma de Código por Demanda
Los Applets de Java son ejemplos prácticos de este paradigma. Los applets son
descargados en navegadores web y ejecutados localmente utilizando los recursos que
posee el cliente.
2.2.3 Paradigma de Evaluación Remota
El paradigma de Evaluación Remota (figura 2.3) fue propuesto como una
alternativa al paradigma Cliente-Servidor, a comienzos de la década del 90. En este
paradigma, el cliente envía el código del procedimiento (know-how), requiriendo al
servidor que lo ejecute y retorne luego los resultados.
Cliente
Know
How
Servidor
Know
How
Figura 2.3: Paradigma de Evaluación Remota
2.2.4 Paradigma de Agentes Móviles
En esta sección se dará una breve introducción del paradigma de agentes
móviles. En la siguiente, cuando se describan los agentes móviles, se continuará y se
agregarán detalles concernientes a este paradigma.
El paradigma de agentes móviles (figura 2.4) puede ser comprendido como un
concepto arquitectónico para la realización de sistemas distribuidos. Tal paradigma es
particularmente conveniente si la adaptabilidad y la flexibilidad están entre las
principales características que el sistema a desarrollar debe poseer.
La característica clave de este paradigma es que cualquier sitio en la red posee
un alto grado de flexibilidad para poseer cualquier combinación de know-how,
procesamientos y recursos. Sus capacidades de procesamiento pueden ser combinadas
con recursos locales. El know-how, en forma de agente móvil, ya no está atado a un
sitio en particular.
10
Agente
red
Know
How
Host
Agente
red
Know
How
red
Host
Figura 2.4: Paradigma de Agentes Móviles
2.3 Agentes de Software
Existen numerosas definiciones acerca de agentes, y generalmente varían unas de
otras dependiendo del dominio en donde se sitúen los agentes. Por lo tanto es difícil
encontrar una definición que se ajuste con exactitud a lo que nosotros consideramos
como un agente de software.
Una definición básica de agente de software, aunque demasiado general y
tomada desde el punto de vista de un usuario final es la siguiente:
Un agente es un programa que asiste a alguien (una persona) o algo (una
organización u otro agente) y actúa por sí mismo con cierta autonomía. [LangeOshima 98].
Otra de las definiciones de agente más comúnmente utilizada es aquella que
presentan [Woolridge-Jennings 73]. Ellos elaboran acerca de lo que es un agente
basándose principalmente en dos nociones: una definición fuerte de agente y otra débil.
La definición fuerte involucra técnicas de inteligencia artificial y modelos para
caracterizar a los agentes, desde un punto de vista interno, utilizando nociones
mentales como ser su conocimiento, sus creencias, intenciones y obligaciones, o
incluso sus atributos emocionales. Mientras que en la definición débil las
características más importantes son la autonomía, sociabilidad, reactividad y
movilidad, y estas se observan desde un punto de vista externo.
Dado que existen muchos tipos de agentes que operan de diversas maneras, las
características que todos estos agentes comparten constituyen la esencia para
determinar con mayor precisión qué es un agente.
Un agente es una entidad de software que:
¾ Está situado dentro de un ambiente de ejecución.
¾ Posee alguna de las siguientes características:
• es reactivo: sensible a los cambios en el ambiente y actúa de acuerdo a
esos cambios.
• es autónomo: tiene control sobre sus acciones.
• está dirigido por objetivos (proactivo).
• es temporalmente continuo: está ejecutando continuamente .
¾ Y también puede poseer alguna de estas características ortogonales:
• es comunicativo: capaz de comunicarse con otros agentes.
• es móvil: puede migrar de un nodo a otro.
11
• es capaz de aprender: se va adaptando de acuerdo con experiencias
previas.
[Lange-Oshima 98]
La anterior definición describe más detalladamente y desde el punto de vista de
un programador, que es, como se comporta y las características que debe poseer un
agente.
2.3.1 Clausura de Agentes
El código de un agente consiste no solamente del código de su tipo/clase
específico, sino también del código de todos los tipos/clases heredadas o referenciadas.
A dicho conjunto se le llama la clausura del agente.
2.4 Movilidad
La gran difusión en el uso de redes a gran escala, como lo es Internet, está
planteando al mismo tiempo y de manera correlacionada, un nuevo dominio de
aplicación y un nuevo paradigma de programación que, cada vez, se empieza a
escuchar más y que tiene que ver con la movilidad. Últimamente se mencionan
términos como código móvil, comunicación "inteligente", agentes móviles, migración
de procesos, aplicaciones itinerantes, etc. Pero no sólo se habla de conceptos, también
hay ya herramientas disponibles que integran esa característica, como por ejemplo,
Java.
La idea básica de este paradigma es la transmisión no de datos, sino la de código
listo para ser ejecutado en algún servidor de la red. Si se analiza bien, esta idea no es
nada nueva, la podemos encontrar desde los principios de las redes, cuando se iniciaba
la descentralización de las grandes computadoras. En esa época se popularizaron los
RJE (remote job entry), minicomputadoras de uso específico, cuya función era enviar
lotes de programas (código) para ser ejecutados en una gran computadora central de
propósito general, y posteriormente, recibir los resultados. En este caso no se
transmitían datos, se enviaba código. Otro ejemplo, es el popular RSH (Remote Shell)
de UNIX, que existe desde que el sistema operativo UNIX se integró a una red TCP/IP.
Con este intérprete, no sólo se puede enviar y ejecutar código en cualquiera de las
estaciones UNIX conectadas a una red, sino además permite intercomunicar los
procesos distantes a través de un mecanismo de comunicación muy simple, los "pipes"
(envío/ejecución de código distante y "pipes" son los mecanismos básicos de
programación de procesos distribuidos en una red de sistemas UNIX).
Igualmente, como ha sucedido con otros paradigmas, aunque el concepto básico
ya existía, no se había generalizado ni tampoco se había analizado todo su potencial
aplicativo. Este potencial sólo se hizo patente, primero, cuando el uso de las redes se
hizo muy popular, gracias a las interfaces abiertas que permitieron la interconexión de
sitios heterogéneos, como es el caso de los "navegadores"; y segundo, cuando la
interconexión de estaciones se hizo a una gran escala, como es el caso actual de
Internet. Con una red de esta dimensión, en principio se cuenta con la posibilidad de
utilizar todos los recursos de la red, los cuales son prácticamente ilimitados, aún
comparándolos con los que podría ofrecer la mayor supercomputadora del mundo. En
particular, uno de los recursos más interesantes que se pueden utilizar es el de
procesamiento que, potencialmente, ofrece todos los sitios conectados a la red.
12
El concepto de movilidad plantea, a nivel de la implementación, problemas tales
como: lograr una ejecución homogénea en procesadores heterogéneos; distintos temas
asociados con la seguridad del sistema; generalizar y controlar las funciones básicas
para integrarlas en la semántica de un lenguaje orientado a la movilidad; y definir
modelos que nos faciliten la especificación y diseño de aplicaciones itinerantes. Todos
estos problemas, son temas de desarrollo e investigación que actualmente se están
realizando en diversos centros y laboratorios de investigación. Sin embargo, aunque no
se ha definido la movilidad, ya hay lenguajes que tienen ciertas características de
movilidad, tales como Java y Telescript.
Con estos nuevos lenguajes se pueden implementar aplicaciones que requieran de
enviar instructivos completos (programas) en lugar de un intercambio de datos o
llamadas a ejecución remota, o el envío de expertos viajantes (agentes móviles) con
capacidad para migrar, si requiere de otros recursos no existentes en el sitio visitado;
nuevas aplicaciones que antes no se planteaban al pensar que el código era inamovible.
2.4.1 Nodos
Un nodo, también llamado comúnmente host, sitio ó servidor, es una
infraestructura de hardware y software sobre la cual los agentes son ejecutados.
Típicamente, un nodo es una computadora, pero en el futuro cercano seguramente este
concepto abarcará computadoras móviles/portátiles, como por ejemplo asistentes
personales digitales, comunicadores personales inteligentes, PCs hand-helds,
televisores, teléfonos celulares y otros dispositivos.
Usualmente, un agente ejecuta en un nodo. Sin embargo, durante su ciclo de
vida, puede migrar a través de un número arbitrario de nodos. Un agente puede estar
duplicado, pero cada agente sólo puede ser ejecutado en un nodo a la vez.
2.4.2 Movilidad de Agentes
Dentro de la movilidad de código una de las aplicaciones mas importantes es la
movilidad de agentes de software. Los sistemas que utilizan agentes móviles deben
tener especial cuidado en considerar cuestiones relacionadas a como identificar a
agentes viajantes desconocidos con los que se desea comunicar; como proteger a los
sitios receptores de agentes "mal intencionados"; como proteger a los agentes viajantes
de sitios "mal intencionados", etc.
La movilidad es una propiedad ortogonal de los agentes, es decir que no todos
los agentes son móviles. Por lo tanto, con respecto a esta propiedad, hay dos tipos de
agentes: móviles y estacionarios (o estáticos).
2.4.2.1 Agentes Estacionarios
Un agente estacionario ejecuta solamente en el sistema en donde comienza la
ejecución. Si necesita información que no está en el sistema o necesita interactuar con
un agente ubicado en un sistema diferente, típicamente usa un mecanismo de
comunicación tal como llamado a procedimientos remotos (RPC).
Una característica importante de los agentes estacionarios es que debido a que
no migran de un nodo a otro, no presentan problemas de seguridad para el sistema, sin
13
embargo, en el sistema, igualmente, se deben prevenir ataques de agentes de otros
sistemas de agentes móviles.
2.4.2.2 Agentes móviles
Un agente móvil no está atado al sistema en donde comienza su ejecución. Tiene
la habilidad de transportarse de un nodo a otro. Puede migrar entre diferentes nodos
para ejecutar algunas tareas predefinidas de forma local a los recursos que le sean
necesarios (tales como otros agentes, un sistema de archivos, o grandes bases de
datos). Las ventajas de ejecutar localmente con respecto a los recursos necesitados
frente a la ejecución remota, son principalmente, la disminución del tráfico de red y del
tiempo de ejecución, Esta ventaja puede ser de mucha utilidad cuando la aplicación se
ejecuta en redes muy saturadas o con alto nivel de latencia y bajas tasas de
transferencia.
Por medio de la transmisión de programas ejecutables entre diferentes máquinas
(posiblemente heterogéneas), la computación basada en agentes móviles introduce un
nuevo paradigma, como se explicó brevemente en la sección 2.2.3, para la
implementación de aplicaciones distribuidas en un ambiente abierto y dinámico.
A partir del punto de vista del clásico estilo arquitectónico cliente-servidor, el
cual es actualmente el modelo arquitectónico que prevalece para el desarrollo de
sistemas distribuidos, los agentes móviles pueden ser vistos como una extensión o
generalización del bien conocido mecanismo de llamada a procedimiento remoto
(RPC). No obstante, mientras que en el caso de RPC se mueven datos del cliente a un
procedimiento que ya reside en el servidor, en el contexto de agentes móviles el cliente
despacha un agente, el cual viaja al servidor y realiza allí su tarea interactuando
localmente con los recursos de dicho servidor. Adicionalmente, es de destacar que en
el caso de RPC, el cliente usualmente permanece ocioso mientras el procedimiento
remoto es ejecutado.
Por lo tanto, los agentes móviles son capaces de emular el mecanismo de llamada
a procedimiento remoto pero fundamentalmente, ellos permiten también estructuras
más flexibles y dinámicas que los tradicionales sistemas basados en el paradigma
cliente-servidor. Comparado con mecanismos de menor nivel de abstracción tales
como RPC o pasaje de mensajes, el uso de agentes móviles en el desarrollo de
aplicaciones distribuidas tiene varios beneficios:
•
Ejecución asincrónica de tareas: Los clientes pueden realizar otras tareas
mientras el agente actúa en su representación en un sitio remoto.
•
Mayor dinámica: No es necesario instalar un procedimiento específico en
un servidor y anticipar tipos de requerimientos de servicios; un cliente o un
proveedor de servicio puede enviar diferentes tipos de agentes
(implementando nuevos servicios, por ejemplo) a un servidor sin necesidad
de reconfigurar el mismo.
•
Reducción del ancho de banda de la comunicación: Si grandes volúmenes
de datos del servidor deben ser procesados (datos acerca del clima, por
ejemplo) o si sólo porciones relevantes de información deben ser filtradas,
resulta más económico transferir la computación (es decir, un agente en este
caso) a los datos que enviar los datos a la computación.
14
•
Mejora de las capacidades de tiempo real: Agentes actuando localmente
sobre un sitio remoto pueden reaccionar más rápido a eventos remotos que
si estos eventos y reacciones a tales eventos tienen que ser comunicados
entre la máquina remota y una entidad central.
•
Alto grado de robustez: Un agente puede ser instruido acerca de cómo tratar
con problemas potenciales tales como servidores no disponibles (como por
ejemplo, ir a fuentes alternativas o reintentar posteriormente). En general, la
tolerancia a fallas es promovida debido a que el agente móvil es capaz de
reaccionar ante situaciones adversas.
•
Soporte mejorado ante mecanismos conectados de forma intermitente: En
lugar de estar en línea por algún largo periodo, un usuario puede desarrollar
un agente móvil de forma desconectada, despachar el agente durante una
breve sesión de conexión y recibir el agente nuevamente junto con el
resultado posteriormente. Aplicaciones basadas en agentes móviles sobre un
dispositivo personal (tal como un PDA) pueden moverse a un sitio que está
en línea permanentemente cuando el dispositivo es apagado para salvar
energía.
En un sentido amplio, un agente es un programa que actúa en representación de
un usuario. En este contexto, un agente móvil es un programa el cual representa a un
usuario en una red de computadoras. Este programa es capaz de migrar de forma
autónoma entre diferentes sitios, para realizar alguna computación en representación
de dicho usuario [Karnik-Tripathi 98].
Esencialmente, el paradigma de agentes móviles ha evolucionado a partir de
otros dos paradigmas antecesores: Cliente-Servidor y Evaluación Remota [KarnikTripathi 98]. Tradicionalmente, el desarrollo de las aplicaciones distribuidas se ha
basado en el paradigma cliente-servidor en el cual los procesos clientes y servidores se
comunican por medio de pasaje de mensajes o llamadas a procedimientos remotos
(RPC). Esta forma de comunicación es sincrónica, es decir el cliente se suspende
después de enviar un requerimiento al servidor, esperando por los resultados de la
llamada remota.
En RPC se transmiten datos entre el cliente y el servidor. Esta transmisión de
datos se da en ambas direcciones. En el paradigma de evaluación remota, se envía
código desde el cliente al servidor, y se retornan datos. En contraste con estos
enfoques, en el paradigma de agentes móviles se envía, del cliente al servidor, un
programa que encapsula código, datos y contexto de ejecución. A diferencia de una
llamada a procedimiento, el agente móvil no tiene que retornar los resultados al cliente.
El agente podría migrar a otros servidores y transmitir la información recolectada a su
lugar de origen o volver a tal sitio según sea más apropiado.
Los agentes móviles pueden ser considerados como el último punto en la
evolución incremental de las abstracciones existentes sobre movilidad, que incluyen:
código, objetos y procesos móviles [White 98]. Así por ejemplo, lo que se transfiere en
un caso de código móvil, tal como la transferencia de un applet, consiste únicamente
de código. En un caso de objeto móvil esto consiste de código y datos, mientras que en
un caso de proceso móvil se incluye además el estado del hilo de ejecución. Entre
tanto el estado transferido de un agente móvil consiste además del código, datos, y
15
contexto de ejecución, la autoridad de su propietario, que certifica sus derechos en el
acceso a los recursos y servicios disponibles para el agente.
Por otra parte, y teniendo en cuenta el patrón de movimiento [White 98], se
pueden establecer diferencias importantes entre los agentes móviles, applets y servlets.
Un applet es descargado (downloaded) en el cliente desde el servidor, mientras que un
servlet se carga (uploaded) en el servidor como consecuencia de un requerimiento por
parte del cliente. Los agentes móviles, por su parte, pueden migrar entre diferentes
sitios sin interactuar continuamente con aquel que lo originara. Este sitio o lugar de
origen se ve involucrado generalmente, en el ciclo de vida del agente móvil, sólo
cuando el agente migra al primer sitio en su derrotero y cuando el agente retorna del
último lugar visitado.
2.4.2.3 Contexto
El contexto es la interfase pública provista por cada sistema de agentes móviles.
Hay un mapeo directo y único entre el sistema de agentes móviles y el contexto, lo que
significa que cada sistema de agentes móviles está representado por un correspondiente
contexto.
2.4.2.4 Lugares de ejecución
El contexto puede organizarse en un conjunto de entidades lógicas designadas
por lugares de ejecución, places, sitios o simplemente lugares. Esto significa que un
contexto contiene varios lugares. Los lugares y el contexto están unívocamente
identificados por una dirección electrónica.
Los lugares y los agentes constituyen los conceptos básicos inherentes a un
sistema de agentes móviles [White 97]. Un sistema de agentes móviles involucra un
número de lugares donde se proveen diferentes recursos y servicios dispuestos para los
agentes. Los lugares son lugares lógicos donde los agentes ejecutan, se encuentran y se
comunican con otros agentes, además pueden migrar o moverse entre varios lugares
con el objeto de reunirse con otros agentes o para acceder a los servicios y recursos
provistos por los lugares de ejecución.
2.5 Sistemas de agentes móviles
El sistema responsable del soporte y manipulación de los agentes se denomina
Sistema de Agentes Móviles. Uno o más sistemas de agentes móviles pueden existir en
cada nodo. Algunas veces un sistema de agentes móviles es también llamado un
"sistema de agentes". Sin embargo, preferimos sistema de agentes móviles ya que
"sistema de agentes" es demasiado general y algunas veces ambiguo. Otros nombres
que suelen recibir los sistemas de agentes móviles, son "motor" (engine), "servidor de
agentes" (agent server), "punto de encuentro de agentes", etc.
El sistema de agentes móviles provee un ambiente computacional completo para
ejecutar un agente, así como también otras características tales como persistencia del
agente, seguridad y movilidad. Para poder soportar aplicaciones distribuidas y en
particular movilidad de los agentes, diferentes sistemas de agentes móviles deben
poder comunicarse entre ellos usando protocolos de bajo nivel y acordar en formatos
comunes de representación de agentes (por ejemplo, usando técnicas bien conocidas de
16
marshalling como las que se encuentran en los sistemas de RPC y CORBA). El sistema
de agentes móviles debería también proveer (o al menos integrar) APIs específicas
para permitir accesos a servicios externos y recursos, tales como bases de datos (por
ejemplo ODBC o JDBC), el sistema de archivos y dispositivos físicos (mouse,
pantalla, teclado o smart cards).
2.5.1 Sistemas de Agentes Móviles vs Sistemas Middleware
Un Sistema Middleware es software que conecta dos aplicaciones separadas. Por
ejemplo, hay numerosos productos middleware que enlazan sistemas de bases de datos
a servidores Web. Esto permite a los usuarios requerir datos de una base de datos
usando formularios mostrados sobre un navegador Web, y esto permite al servidor
Web retornar páginas Web dinámicas basadas en el pedido y en perfil de los usuarios.
El término middleware es usado para describir productos separados que sirven como
pegamento entre dos aplicaciones. Es, por lo tanto, distinto de importar o exportar
características que pueden ser construidas en una de las aplicaciones. Middleware es a
veces llamado “tubería” porque conecta dos lados de una aplicación y pasa datos entre
ellas.
Es importante resaltar la relación entre sistemas de agentes móviles y sistemas
middleware, tales como implementaciones CORBA, RMI y DCOM. Estos últimos
presentan algunas similitudes porque soportan el desarrollo y la ejecución de
aplicaciones distribuidas. Sin embargo, los sistemas de agentes móviles proveen un
framework para desarrollar aplicaciones basadas principalmente en el paradigma de
agentes. Mientras que los sistemas middleware usan el paradigma orientado a objetos.
La principal diferencia entre estos tipos de sistemas es mejor discutida a través de dos
dimensiones: flexibilidad y especificidad. Los sistemas de agentes móviles son
diseñados e implementados para soportar tipos bien definidos de aplicaciones basadas
en agentes, llamada la generación emergente de aplicaciones de agentes (móviles), en
el contexto de comercio electrónico. Por otro lado, los sistemas middleware (tales
como implementaciones CORBA, RMI y DCOM) son más flexibles porque ellos
ofrecen características de soporte de bajo nivel.
Se espera que la siguiente generación de sistemas de agentes móviles sea
desarrollada sobre algún tipo de sistema middleware porque provee distintas
características técnicas (tales como comunicación, seguridad y persistencia) que
pueden ser usadas directamente y más fácilmente por arquitecturas de sistemas de
agentes móviles
2.5.2 Características de los Sistemas de Agentes Móviles
Los sistemas de agentes móviles tienen un conjunto de características, tanto
técnicas como funcionales, que son necesarias para el soporte de aplicaciones basadas
en agentes. A continuación analizaremos algunas de las mas significativas:
2.5.2.1 Ejecución de agentes
El requerimiento más básico de un sistema de agentes móviles es el de proveer
un ambiente de ejecución para los agentes. Este ambiente asigna a cada agente
recursos, tales como espacio en disco, memoria, tiempo de CPU y canales de
17
comunicación.. El ambiente es responsable de la ejecución/interpretación del código
del agente.
Hay dos enfoques diferentes del diseño del sistema de sistemas móviles:
•
Sistemas de agentes móviles con lenguaje de programación de Agentes
(APL): Este es lo usado por la mayoría de los sistemas, en el cual hay
soporte sólo para agentes programados en un lenguaje de programación
específico.
•
Sistemas MA independiente del APL. El diseño de este tipo de sistema de
agentes móviles permite la integración de diferentes ambientes de ejecución
de una manera independiente e incremental. De esta manera, el sistema
soporta la ejecución de agentes construidos usando diferentes lenguajes de
programación, ya que el ambiente de ejecución correspondiente existe. Sin
embargo, se debe hacer notar que aunque los agentes pueden ser
programados en diferentes lenguajes, deben proveer un modelo de objetos
similar (por ejemplo: librerías de clases específicas).
2.5.2.2 Generación y administración de identidades
Debido a la interacción entre agentes y entre agentes y usuarios aparece la
cuestión de como identificar a los agentes y los lugares de ejecución donde ejecutan.
Hay diferentes perspectivas:
•
Tipos de identificador: Un recurso puede ser identificado de diferentes
maneras: por su dirección o por su nombre.
•
Modelos de administración: Hay dos modelos principales de administración
de nombres/direcciones: uno lineal y otro jerárquico. En el primero a cada
recurso se le asigna una identificación única global, independiente del lugar
del recurso, es decir hay un único servidor encargado de asignar direcciones
únicas o convertir nombres lógicos en direcciones físicas. En el modelo
jerárquico, hay una jerarquía de dominios y cada uno manejado por su
propio servidor, una dirección se compone de varias partes cada una
representando una subdirección en la jerarquía de dominios.
•
Tipos de recursos: En general, los siguientes recursos deben ser
identificados en forma distinta: sistemas de agentes móviles, lugares de
ejecución y agentes.
2.5.2.3 Persistencia
La persistencia puede ser definida como la capacidad de guardar la información
del estado de un ambiente de ejecución a otro.
La persistencia es una característica muy necesaria en ocasiones. Por ejemplo, un
agente que va a estar inactivo por mucho tiempo puede ser almacenado en disco para
ahorrar memoria, o un agente que migra a otro sitio puede querer continuar su
ejecución en el mismo estado en que estaba antes de migrar.
El agente debe ser serializado (convertido a una secuencia de bytes en un
formato predeterminado) antes de ser almacenado o transmitido a través de una red, y
18
la operación inversa, deserialización, es realizada cuando el sistema de agentes móviles
obtiene el agente desde un medio de almacenamiento o de la red.
Hay diferentes tipos de persistencia, las más comunes son:
•
Solo datos: Se almacenan los datos manipulados por el agente. Estos datos
consisten de un conjunto de variables locales, globales y compartidas.
Desafortunadamente, no todas las variables son serializables. Por ejemplo,
en Java, las variables static y transient no son incluidos en la serialización
de un objeto.
•
Solo código: El código del agente es serializado, incluyendo referencias,
código heredado y/o clases referenciadas (clausura de código).
•
Solamente la imagen: El estado de ejecución (información sobre la pila de
ejecución) es almacenado, pero no el código del agente.
•
El agente entero: El agente es almacenado en una manera consistente,
incluyendo datos, imagen de ejecución y el código específico.
2.5.2.4 Migración
La migración de un agente es el proceso de moverse de un lugar de ejecución a
otro. También se le llama navegación o simplemente movilidad.
Desde el punto de vista del estado de ejecución hay dos aproximaciones:
•
Migración fuerte: En este tipo de sistemas de agentes móviles los agentes
pueden contener primitivas de migración en cualquier punto en el código,
sin necesidad de obtener el estado explícitamente en el nodo destino.
Cuando una primitiva de migración es ejecutada, el estado actual del agente
(datos y pila de ejecución) y el código son pasados por un proceso de
marshalling y transmitidos al lugar de destino. Cuando arriba, el agente
resume su ejecución a partir de la instrucción siguiente a la primitiva de
migración. La obtención del estado es realizada por el sistema de agentes
móviles e involucra los siguientes pasos: recepción del agente, realizar un
unmarshalling del agente y recreación del ambiente de ejecución previo a la
migración.
•
Migración débil: En este tipo de sistemas, un agente es transmitido pero su
estado de ejecución no. Este es el caso de la mayoría de los sistemas
basados en Java, ya que la máquina virtual no permite el acceso a la pila de
ejecución de un thread. Debido a esto los diseñadores de sistemas de
agentes móviles, si quieren soportar migración fuerte, deben proveer algún
mecanismo para guardar el estado previo a la migración.
19
x = 1;
moveTo(place2);
b = b + 1;
x = 1;
moveTo(place2);
b = b + 1;
place2
place1
run() {
while (true)
switch(x) {
case 0:
...
x = 1;
moveTo(place2);
case 1:
b = b + 1;
break;
default:
x = 0;
break;
}}
run() {
while (true)
switch(x) {
case 0:
...
x = 1;
moveTo(place2);
case 1:
b = b + 1;
break;
default:
x = 0;
break;
}}
place1
Migracíon Fuerte
place2
Migracíon Débil
Figura 2.5: Diferentes semánticas ofrecidas por la operación de migración
Por otro lado,
aproximaciones:
del punto de vista de la clausura del agente existen tres
•
El código no migra: En este caso sólo migra el estado del agente, esto es
útil cuando los agentes ejecutan en lugares bien conocidos y estos lugares
poseen todos el mismo código del agente.
•
La clausura del agente migra entera: En este caso el agente es
autosuficiente, es decir él posee todo el código que necesita. La principal
desventaja es que generalmente estos agentes son muy grandes y se hace
muy costoso su transporte.
•
El código migra incrementalmente: Migra sólo el código básico. El restante
es transportado dinámicamente (por demanda).
2.5.2.5 Comunicación
Con respecto a la comunicación e interacción entre agentes es importante
identificar las siguientes características:
•
Sincronicidad: la comunicación es síncrona cuando las partes involucradas
se sincronizan ellas mismas antes de transmitir cualquier dato. Esto es útil
en lugares donde se requieren confirmaciones urgentes o diálogos
interactivos. La comunicación es asíncrona cuando las partes no necesitan
coordinarse.
•
Localidad: de acuerdo a un análisis espacial la interacción entre agentes
puede ser local o remota. Cuando la comunicación es local los agentes se
reúnen en un lugar común y pueden utilizar cualquier mecanismo de
comunicación entre procesos conocido, como memoria compartida,
archivos, pipes, etc. Cuando la interacción es remota, los agentes se
comunican utilizando pasaje de mensajes, RPC o algún otro mecanismo de
comunicación remota.
20
•
Intermediación: La interacción entre agentes puede ser directa o indirecta.
En la primera un agente invoca un método del otro explícitamente. Cuando
la interacción es indirecta, los agentes no se comunican directamente sino
que utilizan un servicio de intermediación.
•
Destinatario: Si el destino de la comunicación es un solo agente la
comunicación es punto a punto, si es un grupo restringido de agentes, se
llama multicast, o si es a todos, broadcast.
Una cuestión importante es la comunicación durante el proceso de migración, es
decir que sucede cuando un agente, involucrado en alguna conversación/interacción
con otro, debe migrar a otro lugar de ejecución. Básicamente hay dos aproximaciones.
En una el canal no se mantiene abierto y cuando el agente migra simplemente se pierde
toda comunicación con sus pares. Mientras que en la otra el sistema de agentes móviles
es responsable de mantener los canales de comunicación abiertos entre los agentes.
2.5.2.6 Acceso a recursos externos
Los agentes deben ser capaces de interactuar con recursos externos, tal como
bases de datos, sistemas de archivos, dispositivos de interface de usuario (teclado,
monitor, mouse, etc). Es responsabilidad del sistema de agentes móviles proveer a los
agentes de un acceso controlado a tales recursos. Existen dos aproximaciones para
estos accesos:
•
Solamente los agentes estacionarios pueden acceder a los recursos críticos:
En esté caso loa agentes móviles están restringidos a interactuar con otros
agentes. Los agentes estacionarios son responsables de explorar los
diferentes recursos y se convierten en intermediarios entre esos recursos y
los agentes móviles. Esta aproximación simplifica los mecanismos de
seguridad.
•
Los agentes móviles acceden a recursos externos: Este es un enfoque mas
liberal que el anterior, si el sistema de agentes móviles provee los medios
necesarios y el agente cumple con los requisitos de seguridad, entonces
podrá acceder a recursos externos.
2.5.2.7 Seguridad
La seguridad es una característica crítica en el proceso de movilidad de código y
particularmente en la migración de agentes. Los aspectos más importantes a tener en
cuenta son:
•
Autenticación y control de acceso: Cuando un agente migra a nuevo nodo,
su identidad debe ser verificada. Las identidades de su propietario o del
propietario de su lugar de ejecución original pueden también ser verificadas.
Si la autenticación tiene éxito el agente ejecuta en el lugar de ejecución,
pero limitado por los permisos de acceso que le fueron otorgados, de
acuerdo a las políticas del sistema. Los procesos de verificación de
identidad más usuales están basados en mecanismos de firmas digitales,
claves de criptografía, o certificados digitales.
21
•
Integridad: Mientras un agente es transmitido por la red, su contenido
puede ser alterado, es decir que sus objetivos pueden ser cambiados o
comportamiento no deseado agregado. Para evitar esto se necesita un canal
de comunicación seguro y esto se puede implementar: en el nivel de
aplicación, mediante encriptación soportada por los sistemas de agentes
móviles o en el nivel de red, con mecanismos como SSL o TLS.
•
Control de consumo de recursos: Este aspecto concierne el problema de
como un sistema de agentes móviles puede controlar la consumición de
recursos por parte de agentes externos. Esto se debe controlar pues un
conjunto de agentes malignos podrían eventualmente degradar la
performance de un sistema simplemente consumiendo su tiempo de CPU, o
su memoria.
2.5.3 Estandarización – MASIF –
A pesar que los sistemas de agentes móviles existentes difieren notablemente en
cuanto a su arquitectura e implementación existen algunos intentos de conseguir
estándares, principalmente para permitir su inserción masiva en el mercado. Uno de los
intentos de estandarización más importante es la propuesta MASIF (Mobile Agent
System Interoperability Facility). La especificación MASIF contiene un modelo
conceptual detallado que fue aceptado por cinco proveedores de sistemas de agentes
móviles. Sin embargo, se enfocó en la interoperabilidad de los sistemas de agentes
móviles a través de la adopción de dos interfaces principales: MAF-AgentSystem, para
la administración y transferencia de agentes; y MAFFinder, para la localización y los
nombres. Más aún, la especificación MASIF fue diseñada principalmente para la OMG
(Object Managment Group), consecuentemente está fuertemente atada a la arquitectura
CORBA.
2.6 Aplicaciones basadas en agentes
Una aplicación basada en agentes puede consistir de solo un agente (por ejemplo
un agente de búsqueda de información) pero usualmente involucra varios agentes que
interactúan y se comunican entre ellos.
La típica metáfora usada para hablar informalmente sobre una aplicación basada
en agentes es la comunidad (en este caso, una comunidad de agentes). Por lo tanto, en
este trabajo se usaron ambos términos, dependiendo de si la oración es formal o
informal.
2.6.1 El conocimiento
El conocimiento es la descripción de algún hecho, alguna relación entre hechos
y/o otras relaciones en algunos contextos restringidos. Cualquier agente en la misma
comunidad puede usar el conocimiento mantenido por cualquier otro agente. Es
probable que en el nivel de implementación, el conocimiento de todos los agentes
pertenecientes a la misma comunidad será mantenidos en una base de datos.
22
2.6.2 Comunidades de Agentes
Una comunidad (esto es, una aplicación basada en agentes) esta formada por un
conjunto de agentes que saben como comportarse, comparten su conocimiento, y se
comunican usando un lenguaje común.
La comunidad es el concepto lógico que se puede aplicar sobre un número de
nodos. Un agente pertenece a una o varias comunidades si se le es permitido pertenecer
a aquellas comunidades, hablar sus respectivos lenguajes y compartir su conocimiento.
Habrá agentes invitados (guest agent) que se les permite sólo acceso limitado al
conocimiento de la comunidad, probablemente introducido por otro agente que es
responsable de su comportamiento. Otros agentes pueden especializarse como
traductores para diferentes lenguajes, mediadores para resolver conflictos o agentes de
policía para parar o matar agentes con mal comportamiento.
2.6.2.1 Comunidad Homogénea
Una comunidad homogénea es un conjunto de agentes que comparten el mismo
conocimiento y es soportado por un mismo sistema de agentes móviles.
La noción de una comunidad homogénea hace surgir dos nuevos aspectos. El
primero involucra la necesidad de un lenguaje de comunicación entre sistemas
homogéneos. Básicamente hay dos formas: declarativo (por ejemplo KQML [LabrouFinn 97]) o procedural y/o orientado a objetos (por ejemplo Tcl, Telescript y Java). El
segundo aspecto involucra como representar el conocimiento específico de una
comunidad. También tiene dos acercamientos básicos: APIs específicos y protocolos
comunes entre las principales entidades responsables (por ejemplo: KIF [GeneserethKetchpel], un DTD especifico en XML [XML 98]) y el desarrollo y manejo de la
comunidad involucrada. [Riecken 94] [Singh 88].
2.6.2.2 Comunidad Heterogénea
Una comunidad heterogénea es una extensión del concepto de comunidad en
términos de capacidades y complejidad deseadas ya que es un conjunto de agentes
compartiendo el mismo conocimiento, pero soportados por diferentes sistemas de
agentes móviles. Esta clase de aplicaciones basadas en agentes requieren interacciones
y comunicación entre un conjunto de agentes heterogéneos. Por ejemplo, en el estado
actual de los sistemas de agentes móviles, un agente Telescript y un agente Aglet no
pueden comunicarse directamente usando sus primitivas estándar. Obviamente, pueden
interactuar usando mecanismos de comunicación de bajo nivel tales como sockets o
archivos compartidos. Sin embargo, si utilizan estos mecanismos, no pueden
aprovechar las ventajas de sus primitivas de alto nivel integradas con sus respectivos
modelos de objetos, por ejemplo, sus características de seguridad.
En este caso la comunicación entre agentes debe ser independiente de cualquier
lenguaje o sistema de agentes móviles. En este rango hay varios esfuerzos no
necesariamente compatibles:
•
el esfuerzo KSE con el lenguaje KQML;
•
el ACL de Foundation for Intelligent Physical Agents [FIPA 97];
23
•
la iniciativa del W3L con el concepto de "servicio web" con tecnologías
tales como SOAP [Box 00], WSDL [Christensen 01] y UDDI [UDD1 00].
La figura 2.6 muestra las relaciones entre un agente y comunidades homogéneas
y heterogéneas.
complejidad
Comunidad Heterogénea
Agente
Comunidad
Homogénea
características
Figura 2.6: Relaciones entre un agente, y comunidades homogéneas y heterogéneas
1. El agente ofrece capacidades básicas, tales como autonomía y persistencia, pero no
necesariamente movilidad y comunicación con los usuarios.
2.
Un conjunto de agentes homogéneos define una comunidad homogénea el cual es
el segundo nivel de la jerarquía.
3.
En el tercer nivel de la jerarquía, la noción de comunidad heterogénea requiere
comunicación e interacción entre un conjunto de agentes heterogéneos.
2.6.3 Aplicaciones de Agentes Móviles
Comparado con los enfoques tradicionales para computación distribuida, los
agentes móviles prometen (al menos en muchos casos) tratar de forma más eficiente y
elegante con un ambiente abierto, dinámico y heterogéneo como aquel que caracteriza
hoy día a las aplicaciones basadas en Internet.
Un tipo particular de aplicaciones basadas en agentes son aquellas que
involucran agentes móviles. Debido a las características propias de los agentes móviles
el dominio de las aplicaciones se incrementa notablemente. Los agentes móviles
pueden ser útiles en un sin número de aplicaciones. Ciertamente, el comercio
electrónico es una de las áreas más atractivas a este respecto: un agente móvil puede
actuar (en representación de un usuario) como un comprador, vendedor, o
intermediario en el comercio de mercaderías, servicios, e información. En este
contexto, los agentes móviles pueden emular un tour de compras en Internet,
localizando las ofertas más baratas o convenientes publicadas en los servidores de web,
y cuando estuvieran equipados con una estrategia de negociación y preferencias tales
como rangos de precios aceptables, ellos podrían realizar transacciones en
representación de sus usuarios.
Otro dominio de aplicación general es el de búsqueda de información en Internet
(donde la información reside frecuentemente en los servidores de web) o el de
recuperación de información en grandes bases de datos remotas cuando las consultas
no puedan anticiparse. En este caso los agentes transportan un perfil de su respectivo
24
usuario, alguna otra representación de las preferencias del usuario, o bien ellos
incorporan directamente una implementación de una consulta específica de
información (es decir un procedimiento de recuperación) y permitir así compresión
semántica de información por medio del filtrado remoto de datos. En particular, una
aplicación útil para agentes móviles es la de recolección de información dispersa en
muchos sitios y la realización de algunas transacciones cuando es encontrada
información apropiada.
Otro dominio de aplicación típico es el de Monitoreo: Los agentes pueden ser
enviados a sitios remotos a esperar por la ocurrencia de ciertos eventos o a que cierta
información este disponible y entonces reaccionar en consecuencia (como por ejemplo,
comprar acciones en una bolsa de comercio virtual). Similarmente, los agentes móviles
pueden también ser utilizados para la automatización de muchas tareas respecto de la
administración y configuración de redes (como por ejemplo, para diagnóstico remoto),
en particular para los así llamados servicios de red inteligentes. Los agentes pueden
instalar software en máquinas remotas, o bien ellos pueden personalizar dispositivos y
servicios remotos.
2.7 Usuarios finales
Todos los usuarios de una aplicación basada en agentes tienen en general agentes
que ejecutan tareas para ellos. Los usuarios pueden interactuar con sus propios agentes,
o pueden eventualmente interactuar con los agentes que pertenecen a otros usuarios si
sus respectivos administradores de seguridad le otorgan ese comportamiento. Los
usuarios interactúan con los agentes de varias formas de acuerdo a sus interfaces. Por
ejemplo, pueden interactuar a través de e-mail, formularios HTML, applets Java, o
componentes Active-X.
Los usuarios tienen derechos sobre sus agentes, como suspender la ejecución,
cambiar sus conocimiento y objetivos, o incluso eliminarlos. Sin embargo, estos
derechos están restringidos por el sistema de agentes móviles soportado así como
también por decisiones políticas de las respectivas aplicaciones.
25
3
Catálogo de Sistemas
de Agentes Móviles
En este capítulo se analizan varios de los Sistemas
de Agentes Móviles existentes hoy en día.
3.1 Introducción
Hay muchos sistemas de agentes móviles disponibles, tales como Aglets
Workbench, D'Agents, Telescript, Odyssey, Tacoma, Concordia, Jumping Beans,
AgentSpace, Mole, MOA, PageSpace y JiNNi, cada uno de ellos con características y
funcionalidad similares. Aunque en algunos casos contienen diferencias técnicas y
conceptuales importantes. Teniendo en cuenta el capítulo anterior, ahora es posible
analizar y comparar sistemas de agentes móviles conocidos de acuerdo a la terminología
y conceptos detallados anteriormente.
El capítulo está organizado en cinco secciones. La sección 2 presenta un estudio
de los principales sistemas de agentes móviles existentes en la actualidad. En la sección
3 se describen otros sistemas que no son considerados "verdaderos" Sistemas de
Agentes Móviles, porque carecen de algunas características necesarias para ser
considerados como tales. Finalmente, en la sección 4 se realiza una comparación de los
sistemas anteriormente descriptos.
3.2 Sistemas de Agentes Móviles
Telescript fue el estándar de referencia para los sistemas de agentes móviles en
1995 porque fue innovador y fue un punto de quiebre en tecnologías de agentes. Sin
embargo, Telescript falló porque era muy grande, inestable, tenía una performance
pobre y además incluía un lenguaje de programación difícil de aprender. Por otro lado,
ffMAIN tenía un lenguaje y un sistema independientes. Sin embargo, tenía severas
limitaciones que afectaban la performance para el desarrollo de aplicaciones complejas.
Los Aglets Workbench, hoy la referencia en sistemas de agentes móviles basados en
Java, necesitan un modelo de objetos elaborado, por ejemplo una noción de lugares de
ejecución organizados jerárquicamente o la administración de familias de agentes y
clusters. También le faltan capacidades técnicas, como niveles de control de acceso y
un administrador de agentes, y asociación transparente entre usuarios y agentes. Es de
Catálogo de Sistemas de Agentes Móviles
esperar que estos (y otros sistemas de agentes móviles) mejoren para poder soportar el
desarrollo y ejecución de aplicaciones basadas en agentes flexibles, confiables, seguras
y eficientes. Para lograr estos objetivos, los sistemas de agentes móviles futuros
deberían incorporar una combinación de las mejores características de los sistemas de
agentes móviles existentes, por ejemplo cada uno debería proveer:
La independencia de protocolo de TCP/IP y/o sistemas de agentes móviles
basados en HTTP, como encontramos en ffMAIN, para habilitar la migración y la
comunicación entre agentes independientemente del sistema de agentes móviles o de un
lenguaje de programación específico.
La fuerte integración con Java, como la soportada por Aglets Workbench, debido
a que Java es el estándar para el desarrollo de aplicaciones de agentes móviles.
3.2.1 Telescript
Telescript [White 94][White 97][Gral.Magic 97], desarrollado por General Magic,
fue el primer producto comercial que proveyó la tecnología para el desarrollo de
aplicaciones distribuidas basada en agentes móviles.
El modelo de Telescript estaba inspirado en el paradigma del mercado electrónico,
compuesto de dos tipos principales de participantes: clientes y proveedores de servicios
(productores o brokers). Los clientes envían agentes a visitar un conjunto de lugares
donde pueden encontrar los servicios provistos por los proveedores de servicios.
Las nociones de agentes móviles y lugares de ejecución (simplemente llamados
lugares) son muy claras. En Telescript, un lugar es un proceso del sistema operativo que
provee no solo un contexto para los agentes pero también provee servicios. Por lo tanto,
un lugar Telescript puede ser categorizado como un conjunto de lugares y agentes
estacionarios.
Telescript esta principalmente compuesto de los siguientes componentes:
•
El lenguaje de programación (también llamado Telescript), muy basado en
objetos y similar a SmallTalk, en el cual "todo" es un objeto, dinámico,
persistente, portable y seguro.
•
El sistema de agentes móviles, llamado el "motor". Este componente ejecuta el
lenguaje Telescript, esto es, soporta y ejecuta los recursos del modelo de objetos,
tales como agentes y lugares. El sistema de agentes móviles también maneja
aquellos recursos vía tres APIs: manejo de persistencia, transporte de agentes y
acceso a los recursos externos (ver Figura 3.1).
•
Protocolos para representar los agentes (esto es: el protocolo de serialización de
objetos) y su transporte entre motores Telescript.
Telescript fue diseñado para el desarrollo de aplicaciones basadas en agentes
homogéneos, en ambientes propietarios, tales como servicios en redes de
telecomunicaciones manejadas por sus respectivos operadores. PersonalLink de AT&T
fue uno de los pocos ejemplos de esta tecnología.
27
Agent
Agent
Agent
place
place
Telescript Engine
API
Figura 3.1: Esquema conceptual del framework Telescript
Luego, Telescript adoptó el ambiente abierto de la web con un sistema llamado
Trabiz [Gral.Magic 95], pero no tuvo mayor éxito comercial. Trabiz estaba compuesto
de un conjunto de servicios, los cuales integraban tecnologías tanto de Telescript como
de la web, basadas en modelos web basados en servidores [Rodrigues Silva et al. 97].
En 1997, General Magic anunció que abandonaba sus productos Telescript/Trabiz. Al
mismo tiempo, General Magic anunciaba su nuevo sistema de agentes móviles basado
en Java, llamado Odyssey [Gral.Magic 97], el cual adoptó algunos de los conceptos y
técnicas de Telescript. Sin embargo, Odyssey actualmente es también un proyecto
difunto. Se debe hacer notar que tanto Telescript, Trabiz así como también Odyssey
fueron abandonados no solo por sus problemas técnicos, sino principalmente por los
cambios de negocios de General Magic.
Telescript era un sistema de agentes móviles avanzado en varias áreas, tales como
seguridad, movilidad, persistencia y comunicación. Sin embargo, no era lo
suficientemente flexible y dinámico, ya que fue diseñado para aplicaciones propietarias
en ambientes cerrados. Por ejemplo, el manejo del nombre y dirección no estaba basado
en estándares de Internet; la interacción directa entre agentes implicaba que tenían que
conocerse en tiempo de desarrollo. Como tal, no fue posible introducir nuevos agentes,
con nuevas interfaces y funcionalidad, en tiempo de ejecución. Peor aún, Telescript era
un sistema enorme e inestable con mala performance.
3.2.2 Aglets workbench
Aglets Workbench (AWB) o simplemente Aglets [Lange-Oshima 98][IBM 97] es
un sistema de agentes móviles concebido en el Laboratorio de Investigación de IBM en
Tokio y es soportado por la tecnología Java. Contiene los siguientes componentes
principales (como se muestra en la Figura 3.2):
•
JAAPI (Java Aglet API): Consiste de un conjunto de clases e interfaces que
permiten la construcción de agentes y aplicaciones basadas en aquellos agentes.
•
Servidor de Aglets (Aglet Server) (agletsd): Una aplicación Java que esta
dividida en los siguientes componentes: (1) servidor del protocolo propietario
ATP (Aglet Transport Protocol) sobre el cual están soportadas las operaciones
28
de migración y comunicación de agentes; (2) el contexto de ejecución de los
Aglets; y opcionalmente (3) un monitor de aglets con GUI. Esta herramienta,
conocida como Tahiti, provee una interface gráfica (basada en el paquete AWT
de Java) para manejar y monitorear aglets.
•
Fiji: Permite la creación de applets con soporte (esto es: contextos de ejecución)
para la existencia de aglets. Este componente le permite a los usuarios enviar
aglets desde cualquier web browser (siempre que estos browsers ejecuten
applets Java).
Aglet
Aglet
Context
agletsd + Tahiti
Java VM
Figura 3.2: Esquema conceptual del framework de los Aglets
El modelo de objetos de los Aglets incluye un conjunto de clases e interfaces
contenidas en la librería JAAPI. Un aglet es un objeto (potencialmente móvil) que
existe y es ejecutado, en cada momento, en algún contexto determinado (AgletContext).
Cada aglet tiene un objeto shadow que lo representa, llamado AgletProxy. Este proxy
funciona como un escudo y pasa todos los mensajes a su respectivo aglet. El proxy
previene acceso directo a los métodos del aglet y provee transparencia de lugar.
Desde una perspectiva tecnológica, los Aglets tienen las siguientes características
principales:
•
Identidades: El manejo de identidades de un servidor (o contexto) de Aglets esta
basado directamente en el mecanismo de URL (uniform resource locator). Por
otro lado, los aglets son unívocamente identificados a través de una instancia de
AgletIdentifier, la cual se garantiza que sea única y global para cada aglet.
•
Persistencia: Aunque no esta especificado en forma explícita en la
documentación disponible, se provee persistencia externa para los datos de los
aglets. Por otro lado, el código se mantiene en disco de la misma forma que
cualquier otra clase Java es almacenada.
•
Migración: En parte debido al hecho de que la especificación actual de la
maquina virtual Java no provee acceso a la pila del thread que actualmente esta
corriendo, los Aglets no proveen migración de todo el estado de los agentes
(migración débil). Esto significa que el programador tiene que controlar de que
lugar el agente llega usando variables de estado globales.
29
•
Comunicación: El modelo de proxy minimiza el problema de la comunicación
entre agentes móviles. Como se explicó brevemente anteriormente, los agentes
se comunican entre ellos usando sus respectivos proxies. Adicionalmente, varias
semánticas de comunicación son provistas, tales como síncrona, asíncrona y
semánticas futuras.
•
Accesos a recursos externos: Ya que los aglets son objetos Java, no hay
restricciones de interacción entre ellos y otros recursos externos siempre que
existen y los aglets conozcan sus repetitivas APIs (por ejemplo: AWT, JDBC,
RMI). Adicionalmente, el security manager, definido en el nivel global del
servidor, permite cada tipo de interacción para los agentes creados localmente
(ver más abajo).
•
Seguridad: Un security manager (una instancia de la clase AgletSecurityManager) está definido para reconocer dos tipos de aglets: trusted y untrusted.
Un aglet es trusted cuando ha sido creado localmente y su codebase es local. Si
estas suposiciones no están verificadas, no es trusted. El server manager puede
configurar, basado en un conjunto predefinido de categorías (por ejemplo:
sistema de archivos, red, sistema de ventanas), las diferentes operaciones no
permitidas a los aglets untrusted. Por otro lado, los aglets trusted tienen acceso a
la mayoría de las operaciones provistas por el servidor.
3.2.3 ffMAIN
El proyecto ffMAIN [Lingnau et al. 95] fue desarrollado en la Universidad
Göethe, en Alemania. La principal importancia de ffMAIN es su paradigma de agentes
móviles para ambientes abiertos y su exclusivo uso de tecnologías web.
La arquitectura general de este sistema contiene tres componentes, como se
muestra en la Figura 3.3: el servidor de agentes, el ambiente de ejecución, y el agente.
El servidor de agentes consiste de un servidor HTTP modificado para manejar un nuevo
conjunto de métodos (además de GET, PUT y POST) y mantener un espacio de
información para soportar la comunicación entre agentes.
El ambiente de ejecución consiste de una máquina virtual que soporta la ejecución
e interpretación del código del agente. En el caso concreto, se utilizó un interprete Tcl
[Lingnau et al. 95]. Sin embargo, de acuerdo a los autores, no hay restricciones que
prevengan que otros lenguajes sean soportados. El servidor de agentes crea un proceso
autónomo por cada agente y su respectivo ambiente de ejecución. De esta manera, se
obtiene la independencia entre el sistema de agentes móviles y el agente.
El proceso de transportar agentes esta basado en el protocolo HTTP. Cuando el
usuario quiere crear un agente, un mensaje HTTP es enviado. Este mensaje contiene la
información POST server/create (donde server es el url del servidor HTTP extendido)
en el encabezado y los datos, código y atributos del agente (encapsulado en un tipo
MIME) en el cuerpo del pedido. Cuando el servidor recibe este mensaje, el mensaje es
validado (de acuerdo a los atributos indicados), y en el caso de que sea válido y
contenga un agente reconocible, el servidor envía la ejecución del agente al ambiente
apropiado. Finalmente, el servidor devuelve un mensaje de respuesta al usuario
indicando el resultado de la operación.
30
RS = Run-time Support
RS
RS
Shared Information
Space
Agent Server
(Servidor HTTP modificado)
Figura 3.3: Esquema conceptual del framework ffMAIN
El mecanismo de manejo de agentes (suspensión, actualización de parámetros,
borrado) es hecho por el usuario o por otro agente a través de mensajes específicos
enviados al servidor (métodos POST, GET, y DGET). Por ejemplo:
POST server/create;
POST server/moves;
POST server/visit/id;
POST server/info?key;
GET server/info?key;
DGET server/info?key;
La comunicación de los agentes es hecha indirectamente a través de operaciones
elementales de escritura (POST), lectura (GET), y lectura destructiva (DGET) en un
espacio de información público como el propuesto por el modelo Linda [Freeman
96][Gelernter 85]. Este espacio es mantenido y manejado en cada nodo por el respectivo
servidor de agentes y consiste de un conjunto de tuplas en la forma <K,A,V>, donde K
es la clave (identidad); A es una lista de control de acceso que especifica todas las
operaciones y entidades que se les permite realizar operaciones sobre la tupla; y V
consiste de la información en sí misma, cuya sintaxis y semántica estando definidas en
el contexto de cada aplicación.
3.2.4 D'Agents
D'Agents (llamados anteriormente Agent-Tcl) [Darmouth 88][Gray 95] es una
infraestructura de agentes móviles (de acuerdo a su definición original: "agente
transportable") que fue desarrollado en Dartmouth College, en USA. Aunque fue
desarrollado basado en un intérprete Tcl, D'Agents fue diseñado para que sea
independiente de la maquina virtual y su respectivo lenguaje. Actualmente, además de
Tcl, D'Agents soporta Scheme, Java, y C/C++ para agentes móviles.
D'Agents no toma en cuenta la noción de lugar de ejecución como una estructura
de encuentro y ejecución de agentes, el lugar de ejecución corresponde en D'Agents a la
identificación de un servidor de agentes.
31
El interprete Tcl consiste de una máquina virtual Tcl extendida con los siguientes
cuatro componentes (como se muestra en la Figura 3.4): (1) un módulo para capturar el
estado del agente para proveer checkpoint/restart transparentes en las operaciones de
migración; (2) un modelo de seguridad, para inhibir a los agentes de la ejecución de
operaciones impropias; (3) una interfaz (API) para que el servidor de agentes
implemente, conteniendo, por ejemplo, primitivas de comunicación y migración; y (4)
el interprete Tcl.
Agents
Interpreter
Tcl
security
state capture
Java Scheme
AgentServer
E-Mail
TCP/IP
server API
Agent
Agent
VM
VM
soc ket
proc ess
Agent Server
table
agent
Figura 3.4: Esquema conceptual del framework D´Agents
El servidor de agentes consiste de dos procesos cooperativos: (1) un proceso de
sockets que es responsable de la creación, manejo y transporte de agentes, soportando,
por ejemplo, las primitivas agent_fork, agent_jump y agent_submit; y (2) un proceso
asíncrono (tabla de agentes) que es responsable por el manejo de identidades y la
comunicación entre agentes a través de las primitivas agent_send y agent_receive.
Cada agente es un proceso autónomo, creado por el servidor de agentes, que más
allá de su código específico, tiene el código del intérprete respectivo.
Consecuentemente, D'Agents provee (tal como ffMAIN), una independencia real entre
el ambiente de ejecución y el lenguaje en el cual el agente es desarrollado.
3.2.5 AgentSpace
AgentSpace [Rodrigues Silva et al. 98] es un framework para agentes móviles en
Java desarrollado en la Universidad Técnica de Lisboa (IST/INSEC), en Portugal.
Los objetivos principales de AgentSpace son el soporte, desarrollo y manejo de
aplicaciones distribuidas y dinámicas basadas en agentes. Estos objetivos están
provistos por tres componentes separados pero bien integrados entre ellos, como se
muestra en la Figura 3.5.
32
AS-Client
plac e
Voyager
plac
placee
Java VM
c ontext
AS-API
AS-Server
Voyager
Other
applications
Java VM
Figura 3.5: Arquitectura AgentSpace
Tanto el componente del servidor como el del cliente corren sobre Voyager
[ObjectSpace 99] y la máquina virtual Java (JVM), y pueden ejecutar en la misma o en
diferentes máquinas. Los agentes siempre corren en el contexto del server AgentSpace.
Por otro lado, interactúan con su usuario final a través de applets (o frames) corriendo
en el contexto de un web browser o aplicaciones genéricas corriendo directamente sobre
una JVM.
El servidor AgentSpace (AS-Server) es un proceso Java con múltiples threads en
el cual los agentes ejecutan. AS-Server provee varios servicios: (1) creación de agentes
y lugar, (2) ejecución de agentes, (3) control de acceso, (4) persistencia de agentes, (5)
movilidad de agentes, (6) generación de identidades únicas (UID), (7) soporte para
comunicación de agentes, y opcionalmente (8) una interface de línea de comando para
manejar/monitorear el servidor y sus agentes.
El cliente AgentSpace (AS-client) soporta (dependiendo del nivel de acceso del
usuario), el manejo y monitoreo de agentes y recursos relacionados. AS-Client es una
aplicación/applet Java (almacenada en una máquina que tenga un AS-Server). Provee
una adecuada integración con la web y ofrece a los usuarios de Internet la posibilidad de
manejar sus agentes remotamente. Más aún, el AS-Client puede acceder a varios ASServer al mismo tiempo, proveyendo un conveniente trade-off entre integración e
independencia.
La interface de programación de aplicaciones AgentSpace (AS-API) es un
paquete de interfaces Java y clases que definen las reglas para construir agentes y usar
otros recursos mantenidos en el Servidor AgentSpace. En particular, AS-API incluye
soporte para lo siguiente: (1) construcción de clases de agentes y sus instancias, creados
y almacenados para su posterior uso en la base de datos del AS-Server, y (2) desarrollo
de applets/frames clientes para proveer interfaces a los agentes.
AgentSpace, como los Aglets, proveen un ambiente para desarrollar aplicaciones
basadas en Java. Aunque ambos sistemas tiene estas similitudes, sus respectivos
modelos de objetos y APIs son diferentes. Las diferencias entre AgentSpace y los
Aglets, tales como elegancia en la programación, mecanismos de seguridad, integración
con el usuario final o transparencia de ubicación, proveen ventajas para el programador.
Mas aún, AgentSpace presenta un modelo de objetos más completo al proveer lo
siguiente: (1) una mejor organización de recursos, a través de la noción de lugares de
33
ejecución, (2) el manejo integrado de usuario, grupos de usuario y permisos, (3)
mecanismo de seguridad flexibles que permitan ligar dinámicamente security managers
tanto a los agentes como a los lugares, (4) la asociación transparente de políticas de
seguridad, un usuario y un agente en el tiempo de creación de un agente, (5) una
integración adecuada de los agentes con aplicaciones basadas en Internet/web.
Por otro lado, los Aglets tienen las siguientes ventajas sobre AgentSpace: (1) un
elaborado mecanismo basado en mensajes de comunicación y manejo, (2) un modelo
flexible para manejar eventos, y (3) una significante colección de agentes especializados
y clases helper asociadas (por ejemplo: brokers KQML; notificación de eventos; puntos
de encuentro). Este último punto es una consecuencia de su inherente popularidad y su
asociación con IBM.
AgentSpace y Voyager (ver mas abajo para una breve descripción de Voyager
Universal ORB) están muy relacionados entre sí. Naturalmente, algunas de las ventajas
de AgentSpace son consecuencia de la adopción de Voyager, el cual es una mejor
alternativa middleware, que, por ejemplo, RMI. Sin embargo, AgentSpace tiene sus
propias virtudes, específicamente en el nivel de la definición del modelo de objetos,
donde hay una estrecha asociación entre agentes, usuarios y security managers en
tiempo de creación de agentes.
3.2.6 JiNNI
Jinni (Java INference engine and Neworked Interactor) es un lenguaje de
programación lógico multithreading comercial, para la integración de componentes de
procesamiento de conocimiento basado en Prolog y objetos Java en aplicaciones
distribuidas, tales como aplicaciones cliente/servidor en redes o applets en Internet..
Es un lenguaje interpretado y su sintaxis está basada en un subgrupo del lenguaje
Prolog que no incluye operadores. Esencialmente, Jinni define una ontología para el
desarrollo de aplicaciones en el lenguaje. Esta ontología involucra cosas, lugares y
agentes. Las cosas son representadas como términos Prolog. Los lugares son procesos
ejecutando sobre diferentes sitios con un componente server escuchando en un puerto y
un componente blackboard que permite sincronizar las transacciones Linda multiusuario
[Carriero-Gelernter 89], los llamados a predicados remotos y las operaciones de
movilidad de código. Los agentes son colecciones de threads ejecutando un conjunto de
objetivos, posiblemente distribuidos sobre un conjunto de diferentes lugares y
usualmente ejecutando transacciones locales y remotas en coordinación con otros
agentes.
Aunque Jinni define esta ontología, Jinni no provee abstracciones en el lenguaje
para agentes o lugares. Jinni permite movilidad en ambientes heterogéneos ya que su
intérprete está desarrollado en Java. Las unidades de ejecución de Jinni son
denominadas engines, o threads móviles. Un engine incluye el estado de las variables
Prolog, las cláusulas que conforman el programa y el estado de ejecución del mismo.
Las unidades de ejecución utilizan un servidor Jinni que provee los servicios de soporte.
Dicho intérprete corre sobre la máquina virtual Java.
La comunicación entre entidades de ejecución se realiza mediante blackboards
(espacios de tuplas con cláusulas lógicas) locales a los threads, intercambio de mensajes
y memoria compartida (la base de datos de cada intérprete Jinni) y la sincronización
mediante unificación de términos.
34
Un unidad de ejecución puede enviar código a otras unidades o a un servidor Jinni
para que ser ejecutado (ejecución remota). Las unidades de ejecución y los procesos que
ellas realizan pueden ser móviles. La movilidad es soportada mediante migración
proactiva, es decir explícitamente usando los predicados predefinidos move y return.
La administración del espacio de datos se efectúa por copia (todos los recursos
son transferibles). Esto no presenta mayores inconvenientes, debido a que el lenguaje no
permite manipular recursos que requieran de otros mecanismos (tales como archivos o
ventanas).
La seguridad no es uno de los puntos fuertes del lenguaje. Sólo provee un
mecanismo de seguridad inter-EC basado en autenticación por identificador.
La mayor ventaja de Jinni es su facilidad de uso, debido a la combinación de un
lenguaje declarativo (Prolog) y movilidad fuerte. Al estar basado en un subconjunto de
Prolog, la programación de agentes inteligentes con Jinni es mucho más simple que con
las otra plataformas existentes. A pesar de estas ventajas, Jinni sólo soporta un
subconjunto muy reducido de Prolog (por ej. no soporta corte en el backtracking), lo
cual limita considerablemente su potencia expresiva. Otro aspecto que dificulta
enormemente la utilización de Jinni lo constituye su limitado esquema de migración de
unidades de ejecución. Una unidad de ejecución Jinni está formada por un thread más el
código de la cláusula actual. Con el fin de clarificar el mecanismo de migración de
Jinni, considérese el siguiente ejemplo:
there,
move,
println(on_server),
member(X,[1,2,3]),
return,
println(back).
Al ejecutarse los predicados there y move, el lenguaje migra el estado del thread
más el código de la cláusula en ejecución al servidor Jinni. Luego, evalúa
member(X,[1,2,3]) y retorna. Nótese que en éste fragmento de código se asume que
member está definido en el servidor. El problema surge si esto no sucede, pues el
lenguaje no provee otros mecanismos para definir la clausura de código de un agente. A
pesar de que las alternativas para solucionar estas deficiencias utilizando los recursos
propios del lenguaje son variadas, todas ellas adolecen de dos problemas: no son
transparentes para el programador y en ciertos casos generan más problemas que los que
solucionan. Por ejemplo, un esquema muy utilizado para migrar el código de un agente
en su totalidad consiste en definir un predicado moveAgent que coloca todo el código
del agente en una lista Prolog, transfiere el thread al servidor, luego aserta el código del
agente contenido en la lista en el servidor y continúa ejecutando el thread. El problema
de esta solución consiste en cómo determinar qué código pertenece al agente.
Adicionalmente, puede ocurrir que parte del código de un agente se encuentre ya
definido en el servidor remoto, con lo cual se producirían duplicaciones de código o
incluso fallas en la ejecución por tratarse de una cláusula con el mismo nombre y
parámetros, pero con diferente significado.
35
3.3 Sistemas de Agentes Móviles alternativos
Por supuesto que hay muchos otros sistemas de agentes móviles, algunos
desarrollados en ambientes académicos y otros desarrollados por la industria. Sin
embargo, algunos de estos sistemas ya han desaparecido (tal como Kafta u Odyssey), y
otros desaparecerán, mientras que otros emergerán en un futuro cercano.
Aun más, hay otros sistemas que no pueden ser definidos como "verdaderos"
sistemas de agentes móviles aunque proveen algunas características de movilidad de
código. Ejemplos de estos sistemas son Voyager Universal ORB [ObjectSpace 99] y el
sistema Jumping Beans [AdAstra 99]. A continuación describimos algunos aspectos
arquitectónicos de estos sistemas híbridos.
3.3.1 Voyager universal ORB
Voyager es un producto comercial de ObjectSpace Inc. que soporta el desarrollo
de aplicaciones distribuidas basadas en Java. Voyager es un conjunto de productos
100% en Java. Originalmente (la primera versión), Voyager era solo un ORB Java
mucho mejor que su equivalente RMI de Sun. Sin embargo, actualmente uno debería
ver Voyager Universal ORB (versión 3.1) como una línea de productos con los
siguientes items [ObjectSpace 99]:
•
Voyager ORB - Un broker de objetos de alta performance que simultáneamente
soporta CORBA y RMI. Su innovadora generación dinámica del proxy lleva a la
facilidad de uso a un nivel mas alto al remover la necesidad de generadores de
stubs. Voyager ORB incluye un servicio de nombres universal, directorio
universal, framework de activación, publicación-suscripción, y tecnología de
agentes móviles.
•
Voyager ORB Professional - A partir de la base de Voyager ORB, con una
framework de activación, soporte COM, integración JNDI, directorio replicado
persistente, servicio de nombres CORBA, XML Dinámico, manejo de
conexiones y soporte para clientes ultra-livianos (15K).
•
Voyager Management Console - Permite la creación y mantenimiento de perfiles
de configuración para los servidores Voyager. Además, provee la habilidad para
monitorear servicios Voyager, tales como seguridad y transacciones, en tiempo
real. La utilidad de administración es totalmente extensible, proveyendo un
framework para la administración grafica de objetos del usuario por medio de la
consola. (Requiere Voyager ORB Professional).
•
Voyager Security - Incluye un framework de seguridad flexible, implementación
de seguridad liviana, soporte para comunicaciones seguras por medio de
adaptadores SSL, y tunneling de firewalls usando HTTP o el protocolo estándar
SOCKS. (Requiere Voyager ORB Professional).
•
Voyager Transactions - Soporte de transacciones distribuidas totalmente
compatibles con OTS, incluyendo commit de dos fases, un adaptador JDBC de
commit de una fase, transacciones planas y anidadas. (Requiere Voyager ORB
Professional).
•
Voyager Application Server - Ofrece un verdadero ambiente de desarrollo EJB
(Enterprise Java Beans) que desacopla la lógica de la aplicación de la lógica de
la programación de sistemas. Construido sobre Voyager ORB Professional,
36
Voyager Application Server abarca todo el API Enterprise Java para soportar la
interacción de un amplio rango de tecnologías. Voyager permite que las
organizaciones disminuyan sus inversiones en tecnología actuando de puente
entre APIs legacy y las nuevas APIs Enterprise Java. Y debido a que Voyager
Application Server tiene esas nuevas API, las organizaciones pueden
evolucionar junto con la industria.
Es importante hacer notar que Voyager no es un sistema de agentes móviles real,
tal como se ha explicado anteriormente. Sin embargo, Voyager tiene también la noción
explícita de un agente (como un objeto autónomo y móvil), así como también la noción
de un lugar (un objeto o una aplicación a donde el agente puede moverse).
3.3.2 Jumping Beans
Jumping Beans es un producto comercial de Ad Astra Engineering Inc. [AdAstra
99] que permite a los desarrolladores Java construir aplicaciones móviles que pueden
saltar de computadora a computadora durante su ejecución.
Jumping Beans provee un modelo conceptual y arquitectónico diferente a los
analizados hasta ahora, tal como se muestra en la Figura 3.6:
Host
Enviroment
Host
Enviroment
Mobile applic ation
Mobile applic ation
Mobile applic ation
Mobile applic ation
Mobile applic ation
Jumping
Beans
Agency
Jumping
Beans
Agency
Server
Host
Enviroment
Host
Enviroment
Mobile applic ation
Mobile applic ation
Mobile applic ation
Jumping
Beans
Agency
Jumping
Beans
Agency
Figura 3.6: Arquitectura Jumping Beans
Jumping Beans usa los términos "aplicación móvil" y "Jumping Beans Agency,
los cuales corresponden (mas o menos) a los términos "agente" y "contexto" usados en
nuestro modelo de referencia.
Más aún, Jumping Beans incluye algunas características innovadoras en el nivel
técnico. Mientras que la mayoría de los sistemas de agentes móviles están diseñados
sobre una arquitectura punto-a-punto, Jumping Beans presenta una arquitectura clienteservidor. Los clientes son el software instalado en cada máquina donde las aplicaciones
móviles pueden correr, y son llamados "agencias". El servidor es el componente de
software responsable por la administración y el control de seguridad. Las aplicaciones
37
móviles nunca corren en el contexto del servidor. Un conjunto de agencias con un
server constituyen un dominio Jumping Beans. Un dominio tiene un servidor central, el
cual autentica las agencias que se unen al dominio.
Otras características adicionales de Jumping Beans son las siguientes:
•
La arquitectura Jumping Beans, incluyendo su esquema de direccionamiento y
modelo cliente/servidor, es totalmente escalable, mientras que otras tienen
problemas.
•
Jumping Beans es fácil de integrar en ambientes existentes porque: (1) no
requiere migración a un ORB propietario, (2) instancia la aplicación que llega a
una JVM ordinaria, y no requiere un ambiente de ejecución propietario, (3) no
requiere herencia Java, solamente una simple implementación de interfaces.
•
Las aplicaciones móviles Jumping Beans son fácilmente administradas desde el
servidor central. Otras tecnologías de agentes no tienen en cuenta la
administración de los agentes.
•
Jumping Beans tiene seguridad built-in que es comprensiva y fácil de
administrar. Otras tecnologías de agentes proveen poca seguridad o no proveen
seguridad. Otras ofrecen características de seguridad que son difíciles de
manejar y requieren un esfuerzo de desarrollo significante de parte del usuario
final para implementarlo.
•
Jumping Beans es tolerante a fallas. En el evento de una falla de hardware
inesperada, Jumping Beans se recuperará al último estado almacenado de todos
sus componentes. También, la transferencia de aplicaciones móviles Jumping
Beans de un sitio a otro es totalmente transaccional, por lo que una aplicación
móvil no estará duplicada o se perderá en el evento de una falla inesperada de la
red.
•
Otras tecnologías de agentes requieren un embarazoso post-procesador. Las
aplicaciones móviles Jumping Beans usan clases Java y no requieren ningún
post-procesamiento.
•
Jumping Beans se puede usar fácilmente en problemas del mundo real con
muchas contingencias y complicadas relaciones entre si, tales como redes con
fallas, temas de seguridad, operación desconectada, y administración. Otras
tecnologías se han centrado en resolver problemas ideales, en vez de problemas
reales. Por lo tanto, no están diseñadas para ser fácilmente implementadas en un
ambiente real de una empresa.
Es claro que la arquitectura de Jumping Beans tiene un punto central de fallas y
un potencial cuello de botella en cuanto a performance en el servidor central. Sin
embargo, una solución para resolver estos problemas es crear muchos dominios de
pequeño tamaño, cada uno con su propio servidor. Sin embargo, en la versión actual de
Jumping Beans los agentes no pueden migrar entre dominios. Jumping Beans aclara que
soportará esta versión en el futuro.
38
3.3.3 Concordia
Concordia es una infraestructura middleware basada en Java para desarrollar y
administrar aplicaciones de agentes móviles. Fue desarrollada en Mitsubishi Electric
ITA [Mitsubishi 99][Wong et al. 97] y consiste de un conjunto de librerías de clases
Java para la ejecución del servidor, desarrollo de aplicaciones y activación de agentes.
Cada nodo en el sistema, referido como Concordia Server, contiene los siguientes
componentes sobre un JVM:
•
Security Manager: Este componente es un objeto Java cuyo dueño es la JVM
que administra la protección de recursos. A los agentes se les asignan
identidades que les permite acceder a los recursos del servidor. A diferencia de
los Aglets, la protección de los recursos esta basada en el usuario del agente en
vez del desarrollador.
•
Service Bridge: Este componente le permite a los desarrolladores agregar
servicios al Servidor Concordia para soportar agentes cuando estos migran al
servidor.
•
Directory Manager: Este componente habilita a los agentes a localizar a los
servidores con los que estos desean interactuar en un sitio.
•
Administrator: Este componente corre en una JVM aparte y es responsable de
comenzar y parar otros componentes del sistema. Además, administra cambios
en los perfiles de seguridad, tanto de agentes como de servidores, monitorea el
progreso de agentes, y almacena estadísticas de los agentes y del sistema.
•
Persistent Store Manager: Este componente es responsable por el
almacenamiento del estado interno de un agente y la recuperación de un agente
luego de una falla en el servidor o un crash del sistema.
•
Event Manager: Este componente acepta registraciones de eventos desde objetos
y agentes, escucha y recibe eventos, notifica a los objetos y agentes (locales y
remotos) interesados de los eventos que recibe - una aplicación del patrón
observer.
•
Queue Manager: Este componente administra las colas de entrada y salida para
transportar los agentes rápida y confiablemente, a través de la red entre
Servidores de Agentes (Agent Servers) locales y remotos. Los agentes están
almacenados en la cola local mientras que un servidor remoto está en reparación,
para proveer un mecanismo de almacenamiento y reenvío y son almacenados en
disco (localmente) para implementar el bien conocido protocolo de commit de
dos fases, incrementando la confiabilidad.
•
Agent Manager: Este componente es responsable por la propagación de
agente a otro Agent Manager en otro servidor Concordia y la invocación de
método predeterminado del agente (ubicado en su Itinerario y configurable
acuerdo al lugar) una vez que llega a destino. También provee el contexto
ejecución para un agente.
•
Agente: Este componente es un objeto conteniendo una combinación del código
y datos del agente. Los viajes de un agente están descriptos en su Itinerario, una
colección de destinos definidos como pares lugar/método, mantenidos fuera del
agente.
un
un
de
de
39
Concordia tiene varias características que vale la pena mencionar. Primero, su
esquema de itinerarios para la invocación de un método arbitrario del agente una vez
que migra a un servidor. Segundo, además de manejar comunicación asíncrona de
eventos entre agentes, esta la comunicación inter-agentes colaborativa de Concordia. En
esta situación, las clases CollaboratorAgent y AgentGroup se proveen para que los
agentes sincronicen reuniones, y analicen y compartan resultados. Finalmente, está el
soporte de Concordia ante fallas. Además de hacer a los agentes persistentes, Concordia
considera otras situaciones tales como fallas de los managers, por ejemplo cuando
EventManager se reinicializa, y situaciones donde los agentes fallan en llegar a sus
reuniones. En estas situaciones, el uso de proxies ha incrementado la confiabilidad del
sistema escudando agentes u objetos de los efectos de fallas del sistema y del servidor.
Para que sea un éxito comercial, el sistema futuro debe considerar estos y otros temas
de calidad de servicio.
3.4 Comparaciones de los Sistemas de Agentes Móviles
Aunque los sistemas de agentes móviles analizados tienen muchos aspectos
comunes o similares, también tienen grandes diferencias. A continuación se analizaran
tales similitudes y diferencias teniendo en cuenta las características comunes de los
sistemas de agentes móviles explicadas en la sección 2.3.
3.4.1 Similitudes
Todos requieren algún tipo de servidor (el cual llamamos en esta documentación
"sistema de agentes móviles") que soporta las principales funcionalidades.
Todos proveen agentes como entidades autónomas y componentes activos (u
objetos activos) que pueden ser procesos autónomos, threads, o grupos de threads, los
cuales son independientes del nivel de implementación.
Todos proveen características para soportar el mismo tipo de aplicaciones:
aplicaciones distribuidas basadas en el paradigma de agentes, las cuales son
independientes de la complejidad del modelo de objetos, riqueza, o facilidad de uso.
3.4.2 Diferencias
Por otro lado, las principales diferencias entre los sistemas de agentes móviles
analizados están basadas en los temas analizados en las siguientes subsecciones.
3.4.2.1 Terminología
Se utilizan diferentes nombres en diferentes sistemas de agentes móviles para
referirse al mismo concepto. Por ejemplo, los agentes son llamados "agente móvil",
"agente transportable" y "aglet"; los sistemas de ejecución de agentes son llamados
"motor", "servidor HTTP extendido", "agletsd", y "AS-Server". Más aún, el mismo
nombre es usualmente usado con diferentes significados. Por ejemplo, el "lugar" de
Telescript es mejor visto como un conjunto de "agentes estacionarios" que un lugar de
acuerdo a la definición en la sección 2.4.
40
3.4.2.2 Temas de nivel de soporte
Hay esencialmente dos componentes conceptuales en todos los sistemas de
agentes móviles. En general, el conjunto de estos componentes es llamado "sistema de
agentes móviles". El primer componente, el sistema de ejecución de agentes, es común
a todos los sistemas discutidos. Sin embargo, en el otro componente llamado Agent
Execution Environment, tienen grandes diferencias. Todos los sistemas analizados
proveen un ambiente donde los agentes son ejecutados. Estos ambientes son máquinas
virtuales de los lenguajes de programación soportados, tales como Telescript (para
Telescript), Java (para los Aglets y AgentSpace), y Tcl (para ffMAIN y D'Agents). Sin
embargo hay una diferencia fundamental entre ellos, en los sistemas de agentes móviles
tales como ffMain o D'Agents, los agentes corren como procesos externos autónomos
separados de sus respectivos ambiente de ejecución. Los sistemas como estos son más
modulares y abiertos en cuanto al soporte para múltiples lenguajes de programación.
Por otro lado, en sistemas como Telescript, Aglets y AgentSpace, los agentes y el
ambiente de ejecución son ejecutados en el mismo proceso porque los agentes están
implementados como threads o grupos de threads. Esta situación implica un
acoplamiento mas estrecho entre los ambientes de ejecución y los agentes y,
consecuentemente logran una mejor performance.
3.4.2.3 Temas del nivel de administración
Los sistemas deberían proveer herramientas especializadas asociadas con cada
componente definido en el nivel de soporte. Diferentes usuarios podrían acceder y
administrar diferentes recursos tales como agentes, clases de agentes, clases de meta
agentes, lugares, o grupos de usuarios. Estas herramientas tendrían que ser
suficientemente genéricas para ser usadas independientemente de cualquier dominio de
aplicación específico.
No encontramos ninguna información relevante sobre herramientas para
Telescript, debido a que fue comercializado como parte del paquete del servidor web
Tabriz y luego fue sacado del mercado, y también debido al hecho de que las
herramientas conocidas están orientadas a dominios de aplicaciones específicos.
D'Agents tiene bastantes herramientas de debugging y tracking. También tiene
managers para manejar recursos internos, tales como archivos, librerías, programas y la
red. Para ffMAIN, las herramientas provistas son páginas HTML relativamente simples
con acceso directo al correspondiente AES (servidor HTTP extendido). A pesar de
alguna funcionalidad útil, esta interface es demasiado simple y restrictiva para los
puntos de vista del usuario final y del programador. Con respecto a los Aglets y
AgentSpace, ambos sistemas ofrecen herramientas con GUI basadas en librerías Java,
las cuales son llamadas Tahiti y AS-Client respectivamente. Sin embargo, hay otras
diferencias entre ellos. Tahiti corre como un thread interno de un agletsd con lo que hay
un mapeo uno-a-uno entre Tahiti y el servidor. Por otro lado, AS-Client corre como un
applet Java o una aplicación Java. Esto implica que los AS-Clients y AS-Servers pueden
correr independientemente en la misma o en diferentes maquinas porque interactúan a
través de un protocolo de comunicación local/remota. Más aun, AS-Client permite a los
usuarios conectarse con uno o más AS-Servers en Internet. Por último, AS-Client es la
única herramienta que ofrece administración de clases de agentes y meta clases (esto es,
incorpora el componente ATS manager).
41
3.4.2.4 Temas del nivel de aplicación
Todos los sistemas de agentes móviles analizados ofrecen soporte para
aplicaciones homogéneas basadas en agentes. Sin embargo, ninguna de ellas considera
el soporte para aplicaciones basadas en agentes heterogéneas. Sin embargo, este aspecto
puede ser atacado a través de la adopción de algún mecanismo de comunicación de alto
nivel (por ejemplo: basado en KQML [Labrou - Finn 97]). Otra manera de manejar este
tema, en el nivel arquitectónico del sistema de agentes móviles, es a través de la
adopción de algún estándar interoperativo, tal como MASIF de la OMG [Milojicic et al.
98]. GrassHopper [IKV++ 98] fue el primer sistema de agentes móviles que implementó
el estándar.
3.4.2.5 Lenguajes de los agentes
En este grupo analizamos las relaciones entre los sistemas multi-agentes y
lenguajes usados para construir agentes. Identificamos dos tipos distintos de lenguajes:
• Lenguajes de programación de agentes (APL). Estos son los lenguajes usados
para programar agentes. La mayoría de los sistemas de agentes móviles actuales
utilizan Java como el lenguaje para desarrollar agentes. Este es el caso de los
Aglets y AgentSpace pero también para otros sistemas como Mole [Strasser et al.
96], MOA [LaForge et al. 98], Odyssey [Gral.Magic 97], JAE [Park-Leuker 97],
CyberAgents [CAgents 99], GrassHopper [IKV++ 98], Concordia [Wong et al.
97], e incluso, mas recientemente, D'Agents. Sin embargo, sistemas como
ffMAIN y D'Agents que son abiertos en cuanto a los lenguajes de programación
pueden también (al menos en teoría) soportar Java. Sin embargo, en todos los
casos hay un modelo de objetos común con un API propietario.
• Lenguajes de comunicación de agentes (ACL). Los sistemas de agentes móviles
que analizamos tienen una razón común a los ACLs: los agentes se comunican
usando primitivas propietarias provistas por el modelo de objetos de sus
respectivos sistemas de agentes móviles. Debido a que el principal interés de los
sistemas de agentes móviles no era soportar aplicaciones basadas en agentes
heterogéneas, los agentes se comunican entre ellos usando su propio lenguaje de
comunicación y estas primitivas de bajo nivel. Por ejemplo, los Aglets ofrecen un
paquete Java basado en KQML para que los agentes intercambien mensajes
KQML. Es posible que en el futuro cercano que la mayoría de los sistemas de
agentes móviles ofrezcan algún tipo de API basada en KQML y/o el ACL de
FIPA.
3.4.3 Características técnicas
A continuación detallaremos las principales características técnicas de los
sistemas de agentes móviles analizados. Nos hemos centrado en los siguientes aspectos:
identidades, persistencia, migración, comunicación, acceso a los recursos externos,
seguridad e integración con la web.
3.4.3.1 Identidades
Como se hizo notar en la Sección.2.5.2.2, hay muchos tradeoffs y decisiones
técnicas que involucran la definición de la identidad de un agente cuando se diseña un
42
sistema de agentes móviles. Para Telescript y D'Agents las identidades de los agentes
están en espacios de nombres lineales basados en esquemas de propiedades. Todos los
otros sistemas adoptaron un esquema abierto basado en uniform resource identifiers
(esto es, URI/URL internos).
3.4.3.2 Persistencia
Todos los sistemas usan un repositorio externo para mantener la información
requerida. En los sistemas Java (Aglets y AgentSpace) el código del agente se mantiene
en el sistema de archivos (en algún directorio referenciado por el classpath del sistema
de agentes móviles). Por otro lado, los datos del agente (esto es: la versión serializada
del agente) son mantenidos en algún archivo binario con formato propietario junto con
todos los recursos administrados por tales sistemas. Finalmente, en la mayoría de los
sistemas la imagen de ejecución del agente no se mantiene porque JVM no permite el
acceso a la pila del thread. Sin embargo, otros sistemas (tales como D'Agents), proveen
una JVM modificada para poder capturar el la pila del thread. Esto no ocurre en
sistemas comerciales basados en Java (tales como Aglets, Jumping Beans o Concordia).
3.4.3.3 Migración
Como se mostró en la Figura 2.5, hay dos maneras de realizar la migración de los
agentes: migración fuerte (Telescript y D'Agents), y migración débil (Aglets, ffMAIN, y
AgentSpace). Sin embargo, hay una gran diferencia entre la migración en los Aglets y
AgentSpace. En los Aglets, el mismo callback (concretamente el callback run) es
llamado luego de la operación de migración. En AgentSpace, el programador puede
especificar (como un argumento del método moveTo) que callback tendría ser invocado
luego de la operación de migración, proveyendo una solución de programación más
elegante y flexible.
3.4.3.4 Comunicación
Todos los sistemas proveen primitivas de comunicación de bajo nivel, basadas en
el intercambio de mensajes. Un aspecto analizado es la semántica de las primitivas de
comunicación. Los Aglets y AgentSpace proveen un conjunto versátil de primitivas de
comunicación tales como soporte para modelos síncronos, asíncronos y futuros.
En cuanto a la localidad, todos los sistemas de agentes móviles proveen
comunicación inter-agentes independientemente de su posicionamiento relativo. Sin
embargo, hay una importante diferencia entre ellos: Sistemas como ffMAIN y D'Agents
proveen interacción indirecta, mientras que los demás proveen capacidades de
interacción directas. (Por supuesto, los agentes D'Agents o ffMAIN pueden
comunicarse directamente usando mecanismo de comunicación de bajo nivel, tales
como sockets o pipes. Además, D'Agents tiene soporte para RPC en el caso de Tcl). La
interacción indirecta representa un modelo más general, independiente del lenguaje e
incluso seguro. Sin embargo, la interacción directa es más apropiada in aplicaciones
cerradas, debido mayormente a la performance.
43
3.4.3.5 Acceso a recursos externos
Todos los sistemas de agentes móviles proveen funcionalidades y APIs que
permiten que los agentes accedan a los recursos externos tales como bases de datos, y
sistema de archivos. Sin embargo, hay algunas diferencias entre estos sistemas. Por
ejemplo, en Telescript los agentes móviles no pueden acceder a los recursos externos
directamente; solo a través de los lugares Telescript (que son, como se vio antes,
agentes estacionarios de acuerdo al modelo de referencia). En D'Agents, Aglets y
AgentSpace existe la posibilidad de prevenir que agentes móviles externos accedan a
recursos críticos. Esto es usualmente controlado por SecurityManagers definidos y
configurados en cada nivel del servidor de agentes.
3.4.3.6 Seguridad
D'Agents y Telescript son los sistemas de agentes móviles más seguros. En
general, cada sistema provee algunas características de seguridad, al menos para
prevenir ataques de agentes móviles externos. Esto es considerado el nivel mínimo de
seguridad y se provee, por ejemplo, por los Aglets. Adicionalmente, otros servicios de
seguridad deberían ser considerados en aplicaciones reales y críticas, tales como control
de acceso basado en autentificación del usuario, integridad del agente y privacidad, y
prevención contra el consumo de recursos. Este ultimo requerimiento es una de las
mayores limitaciones de seguridad de los actuales sistemas de agentes móviles en Java
debido al hecho de la JVM no ofrece ningún soporte para controlar los recursos
consumidos por un objeto Java.
3.4.3.7 Integración con la web
Excepto por Telescript, la mayoría de los sistemas de agentes móviles actuales
proveen una fuerte integración con la tecnología de Internet/Web. Incluso con la
extensión del protocolo HTTP ocurridas en el sistema ffMAIN, la mayoría de los
actuales sistemas de agentes móviles no cambian, o extienden, componentes estándar de
la web (tales como servidores web, clientes o protocolo). Usualmente, la integración
con la web se realiza en el nivel del cliente a través de algún applet Java que puede
acceder al servidor de agentes y, consecuentemente, puede interactuar con los agentes.
Algunos applets proveen un contexto mínimo para correr agentes en el contexto del
cliente Web (como en los Aglets) mientras que otros solo proveen soporte para la
interacción con agentes remotos (como en AgentSpace).
44
4
LogicRaptors
En este capítulo se detalla el diseño y
la implementación de los LogicRaptors
y de la arquitectura que brinda soporte
para su movilidad.
4.1 Introducción
En los capítulos anteriores se introdujeron los conceptos necesarios para
comprender el funcionamiento de los sistemas de agentes móviles y luego se analizaron
diferentes sistemas existentes en la actualidad, logrando comprender las ventajas y
desventajas de cada uno.
En el presente capítulo se detallará el diseño y la implementación de los
LogicRaptors y de la arquitectura que brinda el soporte para su movilidad. Primero, en
la sección 4.2 se describe brevemente una arquitectura genérica de sistemas de agentes
móviles tomada como referencia para este trabajo; en la sección 4.3, se explicarán los
agentes móviles desarrollados; luego en la sección 4.4 la instanciación de la arquitectura
descripta anteriormente. Después se explicará el mecanismo provisto por JavaLog para
extender su comportamiento (sección 4.5), el cual es de suma importancia en el
desarrollo de la presente propuesta. A continuación se detalla el protocolo utilizado para
la comunicación entre servidores (sección 4.6), y la herramienta desarrollada para
facilitar el uso de la arquitectura y manipular los LogicRaptors (sección 4.7), y por
último, en la sección 4.8, se resumen las principales características de la arquitectura
presentada.
4.2 Arquitectura de Referencia
En el presente trabajo es necesario implementar un sistema de agentes móviles,
para ello se tomó como referencia una arquitectura genérica, descripta en [BelloniCampo 01]. A continuación se detallarán las características más relevantes de la
arquitectura mencionada.
La siguiente figura muestra el diagrama de componentes de una arquitectura de
software para el soporte de agentes móviles inteligentes. El diagrama utiliza notación
UML [Rational 97].
LogicRaptors
Servidor de Agentes Móviles Inteligentes
Administrador de
Comunicaciones
entre Agentes
Servidor de Agentes
Móviles Inteligentes
Administrador
de Agentes
Administrador de
Acceso a Servidores
de Aplicaciones
Aplicación
Externa
Brain
Agente Móvil
Inteligente
(LogicRaptor)
Módulo
Lógico
Administrador
de Confiabilidad
Administrador
de Seguridad
Administrador
de Directorios
Figura 4.1: Diagrama de componentes de la arquitectura de referencia
En esta arquitectura se reconocen diferentes componentes principales: un
administrador de agentes; un administrador de comunicaciones entre agentes; un
administrador de seguridad; un administrador de confiabilidad; un portal servidor de
aplicaciones; y un administrador de directorios.
El administrador de agentes es responsable por la recepción de agentes para su
ejecución en el sitio local y del envío de agentes para ser ejecutados en sitios remotos.
Antes de efectuar la migración de un agente, este administrador lo serializa junto con su
estado.
Luego, delega el envío de esta representación serializada del agente al
administrador de confiabilidad, el cual asegura que el agente es recibido por el
administrador de agentes correspondiente en el sitio destino. Al recibirlo, este
componente reconstruye el agente y los objetos que él referencia, a partir de su
representación serializada, creando su contexto de ejecución.
El administrador de seguridad es responsable por la autenticación del agente
antes de que este comience su ejecución. La máquina virtual Java subyacente invocará
automáticamente a este componente para autorizar cualquier intento de utilizar recursos
del sistema por parte de los agentes. El administrador de comunicaciones entre agentes
facilita la comunicación entre agentes móviles dispersos en diferentes sitios.
Los agentes pueden utilizar el administrador de directorios para identificar la
localización de un servidor de aplicaciones y luego migrar al sitio en el cual este
servidor esta localizado. El portal servidor de aplicaciones representa para los agentes
un punto de acceso a aplicaciones externas al sistema de agentes móviles, residentes en
el sitio local, como por ejemplo acceso a servidores de bases de datos.
Los agentes móviles descriptos son implementados con JavaLog, un lenguaje que
integra los paradigmas de orientación a objetos (Java) y de programación lógica
(Prolog). JavaLog utiliza objetos para modelar las habilidades de los agentes y cláusulas
lógicas para modelar el estado mental de dichos agentes. Las habilidades de los agentes
pueden estar representadas por capacidades de acción como por capacidades de
46
LogicRaptors
comunicación con otros agentes, mientras que el estado mental puede presentarse en
forma de creencias, intenciones y compromisos. JavaLog define al módulo como
concepto básico de manipulación. En este sentido, un objeto y un método son vistos
como módulos. Un objeto es un módulo que encapsula datos y un método es un objeto
que encapsula comportamiento Los agentes móviles construidos con JavaLog son
denominados LogicRaptors. Estos agentes encapsulan un objeto compuesto denominado
Brain. Este objeto es una instancia de un intérprete de módulos lógicos que utiliza
cláusulas Prolog. Este intérprete está implementado en Java y permite utilizar objetos
dentro de cláusulas lógicas, así como embeber módulos lógicos dentro de código Java.
Cada agente es una instancia de una clase que puede definir parte de sus métodos en
Java y parte en Prolog. La definición de los métodos de una clase en JavaLog puede
estar compuesta por varios módulos lógicos definidos en métodos y módulos lógicos
referenciados por variables de instancia. Adicionalmente, la arquitectura permite
incorporar servicios más inteligentes a los sitios Web mediante la utilización de agentes
inteligentes móviles. Así, en cada sitio capaz de ejecutar LogicRaptors, existe al menos
un Nest, el cual funciona como una dársena Web para los LogicRaptors, permitiendo así
extender aplicaciones legadas cliente / servidor basadas en la Web con agentes móviles
LogicRaptors.
4.3 LogicRaptor (Agente Móvil Inteligente)
Los módulos lógicos móviles de JavaLog son vistos en nuestra aproximación
como agentes basados en lógica llamados LogicRaptors, capaces de moverse entre
diferentes servidores (Nests) para poder realizar sus tareas cerca de los recursos
requeridos, de esta manera se evita congestionar la red transfiriendo los datos hacia el
lugar de procesamiento.
Como una especialización de un componente Brain, un LogicRaptor soporta
todos los predicados definidos por un intérprete Prolog estándar, así como también
aquellos mecanismos de intercomunicación entre agentes basados en módulos lógicos
provistos por JavaLog.
Un LogicRaptor extiende un componente Brain con servicios de movilidad y
provee soporte para ofrecer sus servicios a aplicaciones web. Para que un LogicRaptor
migre a otro sitio, se utiliza el predicado moveTo. Antes del transporte, el administrador
de agentes (AgentManager) en el sitio local serializa el LogicRaptor y su estado. Por
ejemplo: su base de conocimiento, objetivos corrientes a satisfacer, variables
instanciadas, puntos de backtracking, etc.
Luego, el AgentManager lo envía a su par en el sitio destino. Una vez que el
AgentManager en el sitio remoto recibe un agente, reconstruye el LogicRaptor y a los
objetos que referencia y luego resume su evaluación. Eventualmente, después de
realizar algún procesamiento, el LogicRaptor podría retornar a su sitio de origen
llamando al predicado built-in goHome.
47
LogicRaptors
4.4 Implementación de la Arquitectura
Tomando como referencia la arquitectura genérica explicada en las sección 4.2, se
decidió implementar algunos de sus componentes, como el Administrador de Agentes,
el Administrador de Confiabilidad y el Administrador de Directorios, además del
ambiente de ejecución para los agentes(LogicRaptors), al cual se le dió el nombre de
nest (nido).
Los demás componentes que forman parte de la arquitectura de referencia, como
el Administrador de Seguridad o el Administrador de Acceso a Aplicaciones, fueron
pensadas como posibles futuras mejoras a la arquitectura.
4.4.1 Nests
Los agentes móviles requieren ambientes de ejecución que actúen como
servidores que aceptan agentes y proveen recursos para ellos. En nuestra arquitectura
tales servidores son llamados Nests. Un Nest es responsable de la ejecución del código
del agente y de proveer operaciones para los programadores de agentes, tales como
aquellas que le permiten a los agentes migrar, comunicarse, acceder a los recursos del
sitio, etc.
Como se puede ver en la Fig. 2 la clase base de cualquier Nest es la clase abstracta
GenericNest. Esta sólo se encarga de atender los pedidos de los clientes y delegar la
atención de estos al comportamiento que implementen sus subclases. La funcionalidad
que provee la clase Nest es el soporte para la recepción y envío de agentes móviles y un
blackboard para la comunicación entre los agentes presentes en dicho Nest. Sobre esto,
ExtendedNest agrega servicios para manipular en forma remota sus conocimientos y/o
el contenido del módulo de conocimientos utilizado en la comunicación entre agentes
(blackboard) que posee.
Un Nest es identificado unívocamente en toda la red por medio de su dirección
(URL). Esta dirección es la utilizada por los agentes móviles cuando desean migrar
hacia algún Nest. La clase Directory es la encargada de administrar las direcciones de
los Nests que se encuentran activos y es la forma de que luego los agentes móviles
puedan conocer nuevos Nests hacia donde migrar para realizar sus procesamientos.
GenericNest
Nest
Directory
ExtendedNest
Figura 4.2: Diagrama de clases de los Nests
48
LogicRaptors
Todos los pedidos y respuestas utilizan el protocolo MTP creado a tal efecto (ver
sección 4.6 para más detalles sobre el protocolo).
El mecanismo de delegación de la atención de los pedidos de los clientes en
GenericNest fue diseñado de tal manera que para agregar nueva funcionalidad sólo sea
necesario agregarlos a una subclase sin tener que modificar la clase base. Otra ventaja
de este diseño es que es posible habilitar / deshabilitar los servicios provistos por los
Nests en tiempo de ejecución sin necesidad modificar a las clases.
Los Nests permiten que la mayoría de sus parámetros de inicialización puedan ser
modificados, permitiendo entre otras cosas:
•
Mostrar información de utilidad en el debugging de nuevo código.
•
Llevar un log de las acciones hechas por los agentes.
•
Elegir el contenido inicial del blackboard.
•
Cambiar el nombre del blackboard.
•
Qué administrador de directorios utilizar.
Si el Nest desea registrar su dirección con el administrador de directorios o no.
Aunque la utilidad principal de un Nest es que sea conocido por los agentes móviles
para que puedan migrar a él, esta opción es sumamente útil cuando se está desarrollando
o depurando código y se desea evitar el arribo de agentes móviles al Nest.
4.4.2 Administrador de Agentes (AgentManager)
La decisión de aceptar un agente o no así como de enviar un agente a otro Nest es
hecha por la clase AgentManager. Esta clase tiene el comportamiento básico para
aceptar y enviar un agente. Además, mediante el patrón de diseño Observer permite que
un observador sepa cuando un agente es enviado o recibido. La transferencia del agente
se hace pasando los objetos serializados por un filtro que comprime los datos, para
aprovechar el ancho de banda disponible y acelerar la transmisión del agente. Esta
transferencia del agente puede efectuarse en forma tanto sincrónica como asincrónica.
La funcionalidad provista por AgentManager es mínima para que cualquier
control o funcionalidad extra que se quiera agregar pueda realizarse creando subclases
de AgentManager. Un ejemplo de esto es el manager que utiliza Nest,
NumberedAgentManager, esta clase se encarga de administrar un conjunto acotado en
numero de agentes (El tamaño del conjunto es definido por el objeto que utiliza al
administrador). Este método de agregar funcionalidad tiene la desventaja de que los
diferentes tipos de funcionalidad agregados al estar cada uno en una subclase son o
mutuamente exclusivos o completamente inclusivos.
4.4.3 Administrador de Confiabilidad
El componente de confiabilidad presente en el sistema es minimalista.
Actualmente es un observador de NumberedAgentManager que al recibir la notificación
de que un agente murió (es decir, termino su evaluación) y si su Nest origen no es el
actual, se envía su cuerpo al sitio destino. Un agente no debería morir en un Nest que no
es el de origen a menos que haya ocurrido algún error por parte del programador, por lo
49
LogicRaptors
que este componente la única utilidad que tiene es como ayuda para el debugging de los
agentes.
4.4.4 Servicio de Directorios
Para resolver el problema de como un agente llega a conocer otros Nests que le
son de interés, se diseñó un sistema de directorio de Nests. Cada Nest cuando es creado
registra su URL con un Directory (al cual debe conocer de antemano), luego, cuando un
agente desea obtener una lista de Nests a los cuales puede llegar a migrar, solo debe
pedirse ese listado mediante alguna de las versiones del predicado getHosts.
El proceso de registración de un Nest con un Directory utiliza un intervalo entre
reintentos pequeño y luego duplica este intervalo entre reintentos sucesivos, hasta que
un valor máximo es alcanzado [DeSchon - Braden 98] (dicha técnica es llamada
retroceso exponencial) para casos donde el Directory no puede ser alcanzado por alguna
razón especial (congestión en la red, etc.).
Debido a que el alta de un nuevo Nest en el directorio no es una operación
frecuente, los datos del directorio se mantendrán constantes por períodos de tiempo
grandes. Por lo tanto, una optimización a la que se recurrió para disminuir el tiempo de
respuesta de un getHosts fue utilizar el patrón proxy para tener almacenados localmente
los datos de los directorios usados. Esto es implementado por LocalDirectory, el cual
puede almacenar el contenido de varios directorios y asignarles a cada uno por separado
un tiempo de vida, durante el cual los datos cacheados localmente se consideran frescos
y todos los pedidos se responden utilizando estos datos.
Directory permite almacenar métricas referentes a un sitio para que los agentes
puedan conocer características del sitio antes de realizar la migración. Las métricas del
sitio se agregan cuando el Nest se registra con el Directory. Y cada métrica consiste de
una dupla de valores de la forma <nombre, valor>. El agente puede hacer uso de estas
métricas utilizando alguna de las variantes del predicado getHosts (ver 4.5.2 para más
información) las cuales dada una lista de métricas, devuelven todos los sitios que
cumplen con tales requisitos. La semántica otorgada a cada métrica corre por cuenta de
los agentes móviles y los Nests.
El URL del Directory por omisión se obtiene del NestManager, el cual a su vez, lo
obtiene del valor de la propiedad del sistema javalog.marlets.defaultDirectoryManager.
4.5 Método de Extensión de JavaLog
Para agregar el comportamiento de movilidad necesario para nuestro trabajo, se
utilizó el mecanismo de extensión soportado por JavaLog. Este mecanismo, utilizado
para definir los predicados, consta de dos pasos; el primero es definir los nuevos
predicados con código Prolog y luego crear una subclase de JavaLog.extension donde se
encuentre la nueva funcionalidad. A continuación se explica con mayores detalles
dichos pasos.
4.5.1 Mecanismo de Extensión
Primero, la definición mediante código Prolog de los nuevos predicados: Cuando
PlEngine se inicializa, consulta todos los archivos .pl dentro del directorio "init". Aquí
50
LogicRaptors
se encuentran las asociaciones entre predicados Prolog y código nativo. Así, por
ejemplo, la definición de getHosts(H) es la siguiente:
getHosts(H) :- builtIn(getHosts, H).
Esto indica que el predicado getHosts(H) debe resolverse utilizando el método
nativo getHosts, lo que nos lleva al segundo paso.
Todos los métodos públicos de las clases del paquete JavaLog.extension son los
métodos que hasta ahora hemos llamado "nativos". Esto fue para llevar una analogía
con los métodos nativos de Java, que podría verse similar a estos, ya que existen formas
de invocar código en cierto lenguaje y estos métodos son hooks a código en otro
lenguaje. Estos métodos pueden ser asociados con un predicado Prolog como se indico
arriba.
Para cargar las clases se invoca al método loadExtensions de la clase
que se encarga de referenciar a todas las clases del paquete
JavaLog.extension haciendo así que estas sean inicializadas (en el caso de poseer
inicializaciones estáticas). Luego se registra cada clase en PlBuiltIn mediante el
método RegisterClass, el cual se encarga de agregar la clase al vector de clases
registradas y agregar a una tabla de hash los métodos públicos de la clase que se está
registrando. Esta tabla de hash es luego utilizada para invocar a los predicados builtIn.
JavaLog.Loader
El siguiente diagrama de interacción ejemplifica el proceso detallado
anteriormente (para reducir el tamaño del diagrama se muestran sólo dos clases de
JavaLog.extension).
Loader
PlBuiltIn
extension.
LogicRaptors
extension.
Database
loadExtensions()
inicialización estática
RegisterClass()
inicialización estática
RegisterClass()
Figura 4.3: Diagrama de Interacción de la carga de los predicados definidos
51
LogicRaptors
4.5.2 Nuevos Predicados
A continuación se detallan los predicados que fueron agregados a JavaLog para el
soporte de movilidad:
Predicado
Descripción
MoveTo(Sitio)
Intenta migrar el estado del LogicRaptor cuyo código contiene
dicho predicado en evaluación al Nest apuntado por el URI Sitio.
En caso de fallar, la evaluación continua localmente. En caso de
lograr la migración del código satisfactoriamente, la evaluación
local y las variables ligadas hasta el momento son devueltas como
respuesta. La evaluación continua en el Nest destino.
CloneAt(Sitio)
Similar a moveTo(Sitio), con la excepción de que se continua la
evaluación local tanto como si falla como si tiene éxito la
migración de código. Con esto se logra un clon del agente en el
Nest referenciado por Sitio. Sería similar a un fork(3), pero
remoto.
GetHosts(Sitios)
Devuelve en Sitios una lista con todos los URIs de los Nests
registrados en el Directory por omisión.
GetHosts(Sitios, Directory)
Ídem getHosts(Sitios) pero el query es enviado al URI Directory.
GetHosts(Métrica, Operador,
Valor, Sitios)
Devuelve la lista de Nests que cumplen con la condición de que
tengan como valor en la métrica Métrica un valor que satisfaga el
operador Operador. Los operadores definidos son: max, min, lt, le,
gt, ge, eq, ne. En el caso de utilizar el operador max o min, el
argumento Valor es innecesario.
GetHosts(Métrica, Operador,
Valor, Sitios, Directory)
Ídem el predicado anterior, pero realizando la consulta al Directory
Directory.
GetHosts(Políticas, Sitios)
Políticas representa una lista con condiciones que debe cumplir
(todas) un Nest para ser incluido en la lista de retorno Sitios. Cada
elemento de esta lista es otra lista donde, el primer elemento es la
métrica, el segundo el operador y, en el caso de que el operador no
sea max o min, es necesario un tercer elemento con el valor a
comparar.
Así,
el
query
getHosts([[offers,gt,100],
[distance,lt,3]],H) devuelve todos los Nests que tengan mas de 100
ofertas publicadas y estén a una distancia menor a 3.
Tabla 4.1: Descripción de los predicados incorporados a JavaLog
4.6 Protocolo MTP
El protocolo usado en la comunicación entre Nests se denomina MTP (MTP
Transfer Protocol). A continuación se detallará el protocolo y luego, como este es
utilizado por los Nests, ExtendedNests y Directories para ofrecer sus servicios. En
general habrá una descripción del servicio y luego se detallará lo mismo mediante BNF
[BNF 02] y las extensiones a BNF definidas en [Crocker et al 82] para descartar
cualquier ambigüedad. Luego de finalizada la descripción del protocolo, se presentará la
jerarquía de clases que proveen mecanismos de comunicación por medio de este
protocolo.
52
LogicRaptors
4.6.1 Descripción
Los terminales LF y SP se utilizan para especificar un fin de línea (\n) y un
espacio en blanco (\s), respectivamente; por lo que cualquier espacio en blanco en los
BNF que no esté representado por el terminal SP, debe ignorarse, pues solo fueron
incluidos para mejorar la legibilidad.
Un pedido se compone de un nombre de servicio con cero o más argumentos y la
respuesta esta compuesta del valor de éxito / fracaso del pedido e información de
respuesta adicional, la cual es dependiente del pedido y puede ser nula. En caso de que
el pedido haya fracasado, la información adicional contiene la razón de esto.
<pedido> ::= <nombre_servicio> *( LF <argumento> ) LF
El nombre del servicio es sensitivo a las mayúsculas / minúsculas.
Todas las respuestas son de la forma: la primer línea indica éxito o fracaso del
servicio, el éxito se indica con la cadena "OK" y el fracaso con la cadena "ERROR". En
ambos casos pueden devolver información adicional. En el caso de error la siguiente
línea tiene una cadena con el mensaje de error y en el caso de éxito la información
adicional devuelta es dependiente del servicio pedido. Si no se recibe nada como
servicio, el error es la cadena "missing service".
<respuesta> ::= ( <exito> | <fracaso> | missing service ) LF
<exito> ::= OK [<datos>]
<fracaso> ::= ERROR [<descripcion-del-error>]
4.6.2 Servicios de los Componentes
A continuación se detallarán los servicios característicos de los diferentes tipos de
Nests y el servidor de directorios.
4.6.2.1 Nest
Los servicios provistos por Nest son los mínimos necesarios para aceptar agentes
móviles, y son los siguientes:
<servicio-nest> ::= ( <acceptBrain> | <acceptBrain-sync> | <getAgentsStatus> ) LF
acceptBrain acepta un agente en forma asincrónica. Luego del servicio viene en forma
serializada y filtrada a través del algoritmo de compresión gzip el estado del Brain.
<acceptBrain> ::= acceptBrain LF <agente>
acceptBrain-sync acepta un Brain, continua la ejecución y devuelve los resultados
(answer()).
<acceptBrain-sync> ::= acceptBrain-sync LF <agente>
53
LogicRaptors
getAgentsStatus devuelve una línea por agente presente en el Nest, teniendo esta un
booleano indicando si el agente está evaluando su código (está vivo) o no (ha muerto).
En el caso de estar muerto el agente, seguido del booleano se muestra el estado de sus
variables. Este servicio se encuentra habilitado siempre que el Nest que recibe el pedido
tenga la opción de debugging habilitada.
<getAgentsStatus> ::= getAgentsStatus
<respuesta> ::= OK LF *( true | false *( <lista> ) )
4.6.2.2 ExtendedNest
Los servicios que ExtendedNest agrega a los definidos por Nest son para poder
manipular el Brain que posee la clase base, Nest.
<servicio-extendednest> ::= ( <addCapability> | <activeCapability> | <removeCapability> |
<answerQuery> ) LF
addCapability agrega un módulo lógico al Brain, cuyo nombre y código es provisto
por los argumentos del pedido.
<addCapability> ::= addCapability LF <nombre-modulo> LF <código>
activeCapability activa un modulo lógico cuyo nombre fue provisto como argumento
del pedido. Este servicio es usualmente usado luego de crear un módulo mediante
addCapability.
<activeCapability> ::= activeCapability LF <nombre-modulo> LF
removeCapability elimina un modulo lógico (siempre que este no esté activado).
<removeCapability> ::= removeCapability LF <nombre-modulo> LF
answerQuery evalúa el código provisto como argumento del pedido y devuelve el
estado de las variables. Los datos que devuelve en caso de devolver OK son: la primer
línea es un booleano (convertido a cadena (true / false)) que indica el resultado del
query. En el caso de que el query haya tenido éxito, la siguiente línea contiene estado de
las variables; devuelve el resultado de Brain.answer().toString().
<answerQuery> ::= answerQuery LF <código>
En el caso de que no haya ocurrido ningún error la respuesta es:
<respuesta> ::= OK LF (true | false) LF *( <nombre_variable> = <valor> ) LF
<valor> ::= <numero> | <cadena> | <lista>
<lista> ::= [ *( <valor> ) ]
54
LogicRaptors
4.6.2.3 Directory
Los servicios provistos por Directory son los necesarios para mantener y
suministrar información acerca de los diferentes nest.
<servicio-directory> ::= ( <getHosts> | <registerNest> | <transferData> ) LF
getHosts devuelve la lista de sitios registrados en este DirectoryManager. El formato de
la lista es el del Hashtable.toString. Por ejemplo, si hay tres elementos y estos son x1,
x2 y x3, el resultado sería: "['x1','x2','x3']".
<getHosts> ::= getHosts | getHosts LF <metrica> LF <operador> LF <valor>
registerNest agrega un Nest a la lista de sitios disponibles. En caso de ya estar
registrado no hace nada. Opcionalmente, se pueden registrar ciertas propiedades del
sitio, para que posteriores búsquedas las devuelvan. Estas propiedades podrían llegar a
ser usadas, por ejemplo, para proveer métricas de los sitios que un agente pueda decidir
basándose en esa información si migrar al sitio o no.
<url> es cualquier URI absoluto [Berners-Lee et al 98].
<registerNest> ::= registerNest LF <url> LF *( <propiedad> LF <valor> ) LF
transferData envía como respuesta todos los hechos que contienen los nests
registrados, así como también las métricas de estos. Es utilizado por LocalDirectory
para poder cachear localmente una copia del Directory.
<transferData> ::= transferData
4.6.3 Clases de MTP
Las clases encargadas de llevar a cabo la comunicación entre Nests mediante
MTP son las que se encuentran en el paquete Javalog.raptors.mtp donde cada una de
ellas provee esta comunicación a diferentes niveles de abstracción.
DefaultMessage
NestMessage
ProtocolMessage
DirectoryMessage
Figura 4.4: Diagrama de clases de Javalog.raptors.mtp
55
LogicRaptors
A continuación se describe cada clase de la jerarquía y se muestra como realizar la
misma tarea con cada una de ellas. El ejemplo que se utilizará es obtener un listado de
los Nests registrados en cierto DirectoryManager.
La clase base ProtocolMessage es una clase que provee comunicación a nivel de
streams con los Nests, en una forma similar a la provista por
java.net.URLConnection. De hecho, se utiliza una instancia de URLConnection para
proveer estos servicios. Esta clase es utilizada solo para proveer los servicios básicos a
DefaultMessage. Aunque la comunicación se realiza mediante una conexión HTTP, es
posible soportar diferentes protocolos (SMTP, CORBA, etc.) con solo cambiar el
método de conexión de esta clase (los protocolos de conexión soportados son los
soportados por el Java o los que se agreguen mediante nuevos SocketFactory).
A continuación de presenta un ejemplo de la utilización de la clase
ProtocolMessage:
ejemplo:
....
ProtocolMessage conn =
new ProtocolMessage("http://raptors.org.ar/Directory");
conn.writeLine("getHosts");
String[] res = conn.getResponseAsArray();
if (res.length > 0 && res[0].equals("OK")) {
// respuesta exitosa
} else {
String error = (res.length > 1 ? res[1] : null);
System.out.println("Ocurrió el error: " + error);
}
....
La clase DefaultMessage es una clase abstracta que utiliza una instancia de
ProtocolMessage y provee soporte para el protocolo de comunicación que es utilizado
por los Nests (MTP), el cual fue descrito anteriormente. En este nivel de abstracción, ya
no se manejan streams de datos sino pedidos / respuestas MTP. Es importante hacer
notar que esta clase entiende de pedidos / respuestas MTP solo a un nivel sintáctico. Los
clientes de esta clase (sus subclases o el código que la utilice) le da valor semántico a
los datos que transporta DefaultMessage.
Las clases que heredan de DefaultMessage son provistas para facilitar la
comunicación entre código Java y Nests, ya que cada una de ellas implementa una
interfase (interfase en el sentido general del termino y no una interfase Java) de
comunicación entre los diferentes tipos de Nests y el Directory. Cada una de estas
subclases de DefaultMessage tiene un método Java por cada servicio que provee el Nest
con el que se comunica alguna de estas clases.
56
LogicRaptors
A continuación de presenta un ejemplo de la utilización de la clase
DirectoryMessage, que es una de las que heredan de la clase DefaultMessage.
ejemplo:
....
DirectoryMessage conn =
new DirectoryMessage("http://raptors.org.ar/Directory");
if (conn.getHosts()) {
// respuesta exitosa
} else {
System.out.println("Ocurrió el error: " + conn.getLastError());
}
....
4.7 LogicRaptors Center
En la sección anterior se describió el diseño e implementación de una arquitectura
para soportar agentes móviles basados en Prolog. Sería interesante poder manipular
agentes sin tener que tener amplios conocimientos de todos los detalles de bajo nivel,
tales como comunicación, sincronización etc., involucrados en la implementación de la
arquitectura anteriormente descripta. Para ello se diseño LogicRaptors Center, el cual es
una herramienta básica para la administración de los LogicRaptors y supervisión de los
Nest, con ella y desde el LogicRaptor Manager se puede crear, editar, enviar a
recolectar datos a un LogicRaptor y luego examinar los resultados, también se puede,
desde el NestView, hacer consultas directamente a un Nest como lo haría un
LogicRaptor, desde el NestObserver, se puede consultar el estado de un Nest para
determinar en que estado se encuentra y por último también se puede consultar la
documentación de todas las clases Java que componen este trabajo.
4.7.1 Requerimientos
El diseño de la herramienta se basó principalmente en dos puntos: debía ser de
fácil utilización aún para aquellas personas no familiarizadas con la programación en
Java, sólo con algunos conocimientos básicos de Prolog y en segundo lugar, dado que la
implementación de la arquitectura de los LogicRaptors se realizó en Java, lo que
garantiza su funcionamiento en muchas plataformas, la herramienta también debía
poder utilizarse desde las plataformas soportadas por Java.
4.7.2 Descripción de la Herramienta
En la herramienta se identifican cuatro utilidades: Raptor Manager, Nest View,
Nest Observer y Documentation.
57
LogicRaptors
4.7.2.1 Raptor Manager
Es la parte central de LogicRaptors Center, desde aquí se pueden crear agentes
LogicRaptors, en el momento de la creación se le debe configurar su nombre y sus
preferencias para la búsqueda. Las preferencias de búsqueda son condiciones lógicas,
cada una independiente de las otras y unidas por un AND lógico.
Luego que un LogicRaptor es creado, se encuentra listo para ser enviado a Nests
remotos en busca de información, cuando regresa se puede visualizar la cantidad de
aciertos que tuvo la búsqueda y si se quiere se pueden conocer los detalles de los
resultados de la búsqueda.
Los datos de un LogicRaptor, tales como su nombre o sus preferencias pueden ser
editadas en cualquier momento haciendo click sobre su nombre, si el agente se
encuentra viajando, estas modificaciones no surgirán efecto hasta que regrese.
Otra utilidad que brinda Raptor Manager es la de poder editar el código Prolog
que el LogicRaptor luego va a utilizar para realizar las diferentes búsquedas. Si no se
edita tal código el agente será creado con el código por omisión provisto por la
herramienta.
Por último cuando un LogicRaptor ya no es útil, Raptor Manager provee la
posibilidad de eliminarlo. Para ilustrar lo mencionado anteriormente sobre Raptor
Manager se muestra a continuación la interface de la herramienta.
Figura 4.5: Vista de la interface de RaptorManager
4.7.2.2 Nest View
Es una interfase a un ExtendedNest para poder, desde un navegador, hacer
pedidos al ExtendedNest para manipular su Brain. Los pedidos que se pueden hacer son
el de agregar una capacidad, activar una capacidad, remover una capacidad y responder
58
LogicRaptors
a un query, por lo que NestView puede funcionar como un miniambiente de
programación en JavaLog. A continuación se muestra la interface de NestView.
Figura 4.6: Vista de la interface de NestView
4.7.2.3 Nest Observer
Muestra los agentes presentes en un ExtendedNest dado y refresca la información
cada una cantidad de segundos indicada por el usuario, esto es de mucha utilidad
cuando se quiere rastrear a un LogicRaptor ya sea para medir su performance o para
determinar la ruta que esta siguiendo. A continuación se muestra la interface de
NestObserver.
59
LogicRaptors
Figura 4.7: Vista de la interface de NestObserver
4.7.2.4 Documentation
En esta sección se encuentra la documentación de todas las clases Java que
forman parte de la implementación de la arquitectura de los LogicRaptors, esta
documentación fue generada automáticamente por la herramienta JavaDoc que provee
el JDK (Java Development Kit).
4.7.3 Implementación
Para que la herramienta funcione bajo cualquier plataforma y dado la amplia
aceptación del uso de Internet hoy en día se decidió implementar LogicRaptors Center
con tecnologías compatibles con la web, como HTML, WebMacro, JavaScript y Java
Servlets. Las tres primeras se usaron para desarrollar la interfase, mientras que con los
servlets se desarrolló la funcionalidad de la herramienta. Estas tecnologías permiten que
LogicRaptor Center pueda ser navegado desde cualquier navegador ya sea local o
remotamente utilizando el protocolo HTTP.
WebMacro [WM 01] es un motor para plantillas HTML. WebMacro simplifica el
desarrollo de servlets separando el diseño de las paginas web de la programación.
JavaScript es un lenguaje interpretado creado por Netscape usado en el desarrollo de
paginas web para agregar comportamiento dinámico [WHA 03].
Los servlets implementados para LogicRaptors Center son tres: AgentsHome,
NestView y NestObserver. En la siguiente figura se detalla el diagrama de clases de la
herramienta.
60
LogicRaptors
HttpServlet
GenericNest
NestView
NestObserver
Nest
AgentHome
Figura 4.8: Diagrama de clases de LogicRaptors Center
AgentsHome se encarga de toda la funcionalidad provista por RaptorManager.
Hereda de Nest; debido a que los agentes deben utilizar funcionalidad de movilidad
propia de los Nests, además, AgentsHome es un intermediario entre el usuario y un
Nest, y se encarga solamente de manipular a los agentes del usuario y dejando las
operaciones propias de movilidad como responsabilidad de las clases pertenecientes a la
implementación de la arquitectura.
Las clases NestView y NestObserver se encargan de implementar la funcionalidad
provista por las utilidades homónimas.
4.8 Características técnicas de la arquitectura propuesta
A continuación detallaremos las principales características técnicas de la
arquitectura presentada. En este resumen nos hemos centrado en los mismos aspectos
que analizamos en los sistemas de agentes móviles estudiados en el capítulo 3, es decir:
identidades, persistencia, migración, comunicación, acceso a recursos externos,
seguridad e integración con la web.
4.8.1 Identidades
El esquema para las identidades de los Nest y Directory está basado directamente
en el mecanismo de Uniform Resource Locators (URL). En cuanto a las identidades de
los agentes, estos tienen un identificador único por Nest. O sea que pueden existir
identificadores de agentes duplicados en el sistema.
4.8.2 Persistencia
La persistencia provista es la que provee el API de serialización de Java. Aunque
este comportamiento no fue implementado para el caso de los nests, es posible
almacenar el estado de un nest en algún repositorio externo para, por ejemplo, la
61
LogicRaptors
recuperación ante fallas. El estado del nest comprende a los agentes presentes en el nest,
a sus datos, su estado de ejecución y el contenido del blackboard.
4.8.3 Migración
El tipo de migración de código utilizado es migración fuerte. Esto presenta una
ventaja en cuanto que el código del agente es mucho más legible que el código de un
agente con migración débil.
4.8.4 Comunicación
La comunicación provista es principalmente una interacción agente – blackboard,
aunque se podrían usar los predicados JavaLog existentes para crear una comunicación
entre agentes.
4.8.5 Acceso a recursos externos
Al ser los agentes objetos Java, estos pueden acceder a los recursos externos
siempre que estos existen y los agentes conozcan sus respectivas APIs.
4.8.6 Seguridad
En nuestro caso, la seguridad no era un objetivo fundamental del trabajo, por lo
que como se explicó anteriormente, el componente de seguridad implementado es
mínimo.
4.8.7 Integración con la web
Hay dos tipos de comunicación existente en el sistema LogicRaptors, la
comunicación entre los componentes de la arquitectura y la de los agentes–blackboard.
Toda la comunicación entre los componentes del sistema se realiza sobre HTTP. A
excepción de la comunicación agentes–blackboard que se realiza mediante RMI, y esta
comunicación es siempre local al sitio. Además, las aplicaciones desarrolladas para
monitorear el estado de un Nest y administrar los agentes móviles también utilizan
HTTP para comunicarse.
62
5
Performance de los
LogicRaptors versus
Agentes Estacionarios
En este capítulo se detalla una experiencia realizada
a fin de medir el desempeño de los LogicRaptors
comparándolos con agentes estacionarios.
.
5.1 Introducción
En los capítulos anteriores se presento una arquitectura integrada a la web para
soportar agentes móviles basados en lógica.
Esta arquitectura permite materializar sistemas multi-agentes. En los últimos
años, los sistemas multi-agentes han crecido en popularidad como una solución viable
para complejos sistemas de información distribuidos. El “sistema abierto” mas grande
es Internet, donde nuevos contenidos están siendo generados día a día. La naturaleza
distribuida de la información en Internet conduce por sí misma a soluciones multiagentes. Los sistemas multi-agentes presentan ventajas como la de ser más rápidos,
consumir menos ancho de banda en comunicaciones y ser más confiables que los
demás sistemas, y particularmente el tipo de agentes usados, móviles o estacionarios,
también tienen sus propios conjuntos de ventajas y desventajas.
El propósito de este capítulo es recolectar datos cuantitativos que permitan
determinar precisamente bajo que circunstancias conviene la utilización de agentes
móviles y en que casos conviene la utilización de estacionarios. Mas aún, el objetivo
de las mediciones es fundamentar la conveniencia de elegir el uso de agentes móviles,
en nuestro caso los LogicRaptors, por sobre los agentes estacionarios, cuando las
comunicaciones son muy frecuentes y a una velocidad de transferencia muy inferior a
la de una red local, como es el caso de Internet.
Para realizar el análisis de performance entre los distintos sistemas multi-agentes
desarrollamos soluciones con agentes móviles (LogicRaptors) y estacionarios al
problema de búsqueda de información distribuida en Internet, más precisamente
búsquedas de libros entre diferentes librerías virtuales. Cada una de las aproximaciones
fue evaluada usando varias métricas de performance para poder descubrir las ventajas
y desventajas de cada variante.
Performance de los LogicRaptors vs. Agentes Estacionarios
El resto del capítulo está estructurado como sigue. En la sección 2 se realiza una
descripción del problema a simular, el diseño de las soluciones y algunas cuestiones
técnicas involucradas en el desarrollo de la experiencia, en la sección siguiente
(sección 3) se presentan y se analizan los datos obtenidos, y por último, en la sección 4
se discuten las conclusiones arrojadas por la experiencia.
5.2 Descripción de la Experiencia
El objetivo de la experiencia, como se dijo anteriormente, es obtener datos para
fundamentar la conveniencia de la utilización de agentes móviles en vez de
estacionarios. Para llevar a cabo esta experiencia se debía seleccionar un dominio de
aplicación suficientemente general, como para que las conclusiones obtenidas sigan
teniendo valor mas allá de ese dominio. Con esa consigna, se decidió realizar la
experiencia basados en el problema de búsqueda de información distribuida.
Se implementó la arquitectura descripta en el capítulo anterior, utilizada por
ambas soluciones, la de agentes estacionarios y la de agentes móviles. Los nests
representan a las librerías virtuales.
Además, también se debía seleccionar un ambiente de ejecución donde llevar a
cabo la experiencia. Se decidió realizar la experiencia en una red de computadoras
aislada con distintas plataformas y sistemas operativos. En la sección 5.2.3 se dan más
detalles técnicos acerca del ambiente de ejecución de la experiencia.
5.2.1 El Problema de la Búsqueda de Información
La búsqueda de información es de gran importancia en la actualidad. El
problema es que, hoy en día, los usuarios tienen grandes cantidades de información a
su disposición distribuida a través de una inmensa infraestructura de almacenamiento
de datos, esta infraestructura además de ser muy grande está creciendo notablemente
día a día.
Un caso particular del problema de búsqueda de información es el de búsqueda
de libros en librerías virtuales. Hoy en día existen numerosos portales de Internet
encargados de vender libros, tal es el caso de portales como Amazon, Submarino,
Virtual Bookstore, etc. Estos sitios publican las ofertas de los libros que desean vender
y los compradores se encuentran con el problema de encontrar el libro que desean entre
una enorme cantidad de portales que lo ofrecen.
5.2.2 Diseño de la Solución
Para realizar la experiencia se utilizó la arquitectura de los LogicRaptors, tanto
para los agentes móviles, que es para lo que fue creada, como para los agentes
estacionarios. Esto se logró modificando el código de los agentes, negándoles la
posibilidad de migrar a otro sitio y exigiéndoles que las consultas las hagan en forma
remota utilizando los predicados connect y disconnect de JavaLog.
5.2.2.1 Librerías
Cada librería va a estar representada por un nest en donde va a estar publicada la
oferta de libros que posee. La cantidad de libros publicados es de aproximadamente
64
150. Cada libro es publicado en el blackboard de la librería como un hecho Prolog, que
tiene la siguiente estructura:
Book([lang],place,edit,pub_date,pages,stock,[author],title,code)
Donde:
[lang]
Lista de idiomas en los que está disponible el libro.
place
Lugar de origen del libro.
edit
Editorial que editó el libro.
pub_date
Fecha de publicación el libro.
pages
Cantidad de páginas del libro.
stock
Cantidad de ejemplares del libro que posee la librería en stock.
[author]
Lista de los autores que escribieron el libro.
title
Título del libro.
code
Código del libro.
5.2.2.2 Configuración de los Agentes
Para realizar la experiencia se utilizaron tres agentes diferentes. Al primer agente
se le configuraron sus preferencias de manera que no encuentre ningún libro de la base
de datos de las diferentes librerías, el segundo agente encuentra aproximadamente la
mitad de los libros y por último el tercer agente encuentra todos los libros de las
librerías.
El motivo para crear a los tres agentes con distintas preferencias fue lograr que,
cuando se comunica un sitio con otro para intercambiar información, el volumen de los
datos a transmitir sea diferente.
En un sistema de agentes móviles la información transferida es el agente entero,
y en el caso de un sistema de agentes estacionarios se transmiten los datos requeridos y
se reciben los que son encontrados. En ambos casos, los parámetros que se van a medir
(tráfico de red, tiempo, etc) dependen mucho de las preferencias del agente, es decir
cuanto más datos encuentre más datos se deben transmitir por la red.
5.2.2.3 Aproximación con Agentes Estacionarios
Los agentes utilizados en esta experiencia permanecen estacionarios en un
mismo sitio y consultan cada una de las librerías existentes buscando si tienen algún
libro que sea de interés para el usuario de acuerdo a sus preferencias. En la figura 5.1
se ve la secuencia que sigue un agente estacionario para consultar las diferentes
librerías:
65
Host Origen
Host
Origen
Librería 1
Librería 2
(Nest)
(Nest)
Librería 3
Librería n
(Nest)
(Nest)
request
results
Librería N
...
Librería 1
request
results
request
results
Librería 2
Librería 3
request
Librería 6
results
Librería 5
Librería 4
Figura 5.1 Diagrama de secuencia de búsqueda de un agente estacionario
La forma de evaluación remota es por medio del predicado connect. El siguiente
pseudo-código muestra el algoritmo que sigue un agente estacionario:
obtener librerías
por cada librería
por cada libro
si el libro concuerda con preferencias de usuario
agregar libro a libros encontrados
devolver datos al usuario
5.2.2.4 Aproximación con Agentes Móviles
Los agentes utilizados en esta experiencia migran a cada librería y realizan
consultas en forma local buscando libros que sean de interés para el usuario de acuerdo
a sus preferencias. En la figura 5.2 se ve la secuencia que sigue un LogicRaptor para
consultar las diferentes librerías:
Host Origen
Host
Origen
Librería N
...
Librería 1
Librería 1
(Nest)
Librería 2
(Nest)
Librería 3
(Nest)
...
Librería n
(Nest)
code + request
code + request
+ results
code + request
+ results
code + request
+ results
Librería 6
Librería 2
Librería 3
Librería 4
code + complete results
Librería 5
Figura 5.2 Diagrama de secuencia de búsqueda de un LogicRaptor
El agente utiliza los predicados connectb y disconnectb para conectarse al
blackboard de la librería. El siguiente pseudo código muestra el algoritmo que utiliza
un agente móvil.
66
obtener librerías
por cada librería
migrar a la librería
si no se pudo migrar a la librería continuar con la sig.
por cada libro
si el libro concuerda con preferencias de usuario
agregar libro a libros encontrados
devolver datos al usuario
Como se puede observar si se lo compara con el código anteriormente mostrado
para el agente estacionario, la única diferencia es la migración de código.
La implementación de los fragmentos de pseudo-código mostrados anteriormente
es realizada en el paradigma de programación lógico, utilizando los predicados de
JavaLog más los explicados en la sección 4.5.2 (getHosts, moveTo, etc)
5.2.3 Ambiente de Ejecución
La experiencia se llevó a cabo en dos escenarios diferentes. La mayor parte de
las mediciones (tráfico de red, cantidad de paquetes, etc) se realizaron sobre el primer
escenario, compuesto por siete computadoras pertenecientes a una red aislada cuya
velocidad de transferencia es de 100 Mbps. En el segundo escenario se midieron los
tiempos de ejecución en cinco computadoras conectadas a 100Mbps y a 10 Mbps. En
ambos casos se utilizaron máquinas diferentes, con distintas plataformas y sistemas
operativos.
En las tablas 5.1 y 5.2 se pueden ver las características de las computadoras
utilizadas en ambos escenarios.
1º Escenario (100Mbps)
Cantidad
Procesador
Memoria (MB)
1
SUN Ultra Sparc 2
128
3
SUN Ultra Sparc 10
256
3
PII 400Mhz
128
Sistema Operativo
Solaris 5.8
Solaris 5.8
Mandrake 7.0
Tabla 5.1: Características de las computadoras utilizadas en la primer escenario de la experiencia.
2º Escenario (10Mbps)
Cantidad
Procesador
Memoria
4
SUN Ultra Sparc 10
256
1
2 x SUN Ultra Sparc 250
512
Sistema Operativo
Solaris 5.8
Solaris 5.8
Tabla 5.2: Características de las computadoras utilizadas en el segundo escenario de la experiencia.
5.3 Testeo y Análisis
Se realizaron mediciones comparando la solución al problema descripto
anteriormente, que utiliza agentes móviles con la que utiliza agentes estacionarios.
Se realizaron cuatro pruebas para cada una de las tres configuraciones de agentes
a fin de reducir la desviación producida por algún fenómeno aleatorio como puede ser
un error en el canal de comunicación.
67
Para capturar las comunicaciones y realizar las mediciones necesarias se utilizó
la aplicación ksnuffle versión 2.2.
5.3.1 KSnuffle
Ksnuffle 2.2 es una herramienta para monitorear el tráfico en una red, que
ejecuta en el sistema operativo Linux. Ksnuffle utiliza como base el código de tcpdump, que es una herramienta Unix.
Las características mas importantes de Ksnuffle 2.2 son:
• Soporta los protocolos TCP/IP y UDP/IP.
• Permite realizar un filtrado básico a través de la GUI y un filtrado más
avanzado vía programas.
• Múltiples monitores concurrentes.
• Sniffing remoto vía un proceso de server remoto.
• Estructura del protocolo visualizado a nivel de aplicación.
• Visualización del flujo de datos TCP.
• Generación de archivos de logs.
• Visualización textual del tráfico de red.
• Histogramas de carga de red y visualización de promedios de carga.
• Ejecución de comandos sobre eventos específicos.
• Generación de un resumen del tráfico total en una red o en una parte de ella.
KSnuffle realiza el filtrado de paquetes exactamente como tcp-dump. Para más
detalles leer las páginas del manual de Linux correspondiente a esta utilidad.
5.3.2 Resultados
En las mediciones se tomaron en cuenta, principalmente, cuatro métricas de
performance, la cantidad de paquetes TCP enviados, el tráfico de red, la cantidad total
de datos transmitidos y el tiempo consumido.
5.3.2.1 Cantidad de paquetes
Esta métrica da la cantidad de paquetes capturados por ksnuffle durante la
experiencia por ambas aproximaciones.
Móvil
1º corrida
264
2º corrida
262
3º corrida
280
4º corrida
262
Promedio 267
Ag1
Estacionario
12301
13091
12930
9112
11858,5
Móvil
911
869
874
920
893,5
Ag2
Ag3
Estacionario Móvil Estacionario
655400
1470
812886
635700
1445
820572
608955
1436
846372
661244
1487
841536
640324,7
1459,5
830341,5
Tabla 5.3: Datos obtenidos de la cantidad de paquetes transmitidos.
68
5.3.2.2 Tráfico en kilobytes
Es la suma de todos los datos transmitidos por la red. Esto incluye los datos de
los encabezados de los protocolos usados y los datos propios de la experiencia
realizada.
Móvil
1º corrida
125
2º corrida
125
3º corrida
129
4º corrida
125
Promedio 126
Ag1
Estacionario
3343
3579
3533
2337
3198
Móvil
677
650
632
68
664,2
Ag2
Estacionario
185355
173988
165464
186112
177729,7
Móvil
708,8
736,8
695,5
697,3
709,6
Ag3
Estacionario
231430
234230
242466
240768
237223,5
Tabla 5.4: Datos obtenidos del tráfico de red generado.
5.3.2.3 Cantidad total de datos transmitidos en kilobytes
Estos son sólo los datos de la experiencia realizada. Sin incluir los encabezados
de los protocolos que se utilizan para enviar los datos de la experiencia.
Ag1
Móvil Estacionario
1º corrida
116
2910
2º corrida
116
3118
3º corrida
119
3077
4º corrida
116
2014
Promedio 116,75
2779,75
Móvil
645
621
605
674
636,2
Ag2
Estacionario
164854
150785
146788
166698
157281,2
Móvil
659
687,9
646,8
650,3
661
Ag3
Estacionario
202852
205397
212742
211209
208050
Tabla 5.5: Datos obtenidos de la cantidad total de datos transmitidos.
5.3.2.4 Tiempo consumido en minutos
Estos datos corresponden al tiempo, en minutos, insumido por los agentes desde
que comienzan su evaluación hasta que terminan.
Las mediciones se tomaron en el escenario 2, detallado en la sección 5.2.3.
Adicionalmente se varió la velocidad de transmisión entre las máquinas pertenecientes
al escenario, con el fin de realizar un seguimiento del comportamiento de los agentes
móviles/estacionarios a medida que la red es mas lenta. Primero, se testeó con una
velocidad de transferencia de 100 Mbps y posteriormente con una de 10 Mbps.
100 mbps
Móvil
1º corrida
2:47
2º corrida
2:50
3º corrida
2:43
4º corrida
2:45
Promedio 2:46
Ag1
Estacionario
00:30
00:29
00:30
00:30
00:29
Móvil
05:40
05:47
05:37
05:42
05:41
Ag2
Estacionario
06:05
06:12
06:02
06:05
06:06
Móvil
11:25
11:20
11:32
11:23
11:25
Ag3
Estacionario
20:08
20:02
20:10
19:46
20:01
Tabla 5.6: Datos obtenidos del tiempo de ejecución con velocidad transmisión de 100 mbps.
69
10 mbps
Móvil
1º corrida 03:01
2º corrida 03:01
3º corrida 02:54
4º corrida 03:03
Promedio 02:59
Ag1
Estacionario
00:40
00:40
00:39
00:41
0:40
Móvil
7:01
7:03
6:54
7:10
7:02
Ag2
Estacionario
9:24
9:25
9:12
9:38
9:24
Móvil
13:54
13:56
13:40
14:06
13:54
Ag3
Estacionario
30:02
30:03
29:45
30:24
30:03
Tabla 5.7: Datos obtenidos del tiempo de ejecución con velocidad de transmisión de 10 mbps.
5.3.3 Análisis de los datos obtenidos
Como se explicó anteriormente las tres primeras métricas están estrechamente
relacionadas, las tres miden la carga de red generada por cada sistema. En
consecuencia, tomaremos a las mediciones de tráfico total de red como parámetro
principal a analizar, ya que es la que tiene mayor incidencia en la performance final de
la red donde se ejecuten los sistemas multi-agentes.
5.3.3.1 Tráfico generado en la red
Los datos obtenidos del tráfico de red producido por ambas aproximaciones
marcan una enorme diferencia a favor de los sistemas de agentes móviles.
Por ejemplo, para el agente 2, el cual es un caso medio entre el 1 y el 3, el tráfico
que genera el agente estacionario es en promedio de 177.730 kilobytes, mientras que,
para el agente móvil el promedio es de 664 kilobytes. Es decir, que el agente
estacionario genera aproximadamente el tráfico que generarían 267 agentes móviles
ejecutando a la vez.
250000
Tráfico (Kb)
200000
LogicRaptors
150000
Agentes
Estacionarios
100000
50000
0
Agente 1
Agente 2
Agente 3
Figura 5.3 Tráfico de red generado por los LogicRaptors vs los agentes estacionarios.
Si analizamos al agente 1 vemos que el agente estacionario genera,
aproximadamente, el mismo tráfico que generarían 25 agentes móviles. Mientras que
con el agente 3, el tráfico del estacionario equivaldría a 334 agentes móviles
ejecutando simultáneamente.
70
Estos números permiten concluir, que a medida que la cantidad de datos
transportados es mayor, la diferencia de tráfico generado por ambas aproximaciones se
va haciendo cada vez mayor. En la figura 5.3 se puede ver el tráfico de red generado
por una aproximación y por otra.
5.3.3.2 Overhead de comunicación
Otro aspecto interesante para ver es como, debido a la excesiva cantidad de
paquetes generados por los agentes estacionarios, se produce un gran desperdicio de
ancho de banda. Este desperdicio es producido principalmente por el overhead propio
de los encabezados de los paquetes TCP/IP. Como consecuencia de esto, los agentes
estacionarios sufren una considerable baja en el porcentaje de datos trasmitidos.
Si observamos, por ejemplo los datos pertenecientes al agente 2, trasmite para el
agente móvil un promedio de 893 paquetes, mientras que, para el agente estacionario el
promedio es de 640.325 paquetes. Esto influye notablemente en los porcentajes de
datos transmitidos. Para el agente móvil el tráfico total es, en promedio, de 664
kilobytes, de los cuales 636 kilobytes, es decir un de 96 por ciento, son datos y
solamente un 4 por ciento es overhead de comunicación. En cambio, el agente
estacionario genera un tráfico total, en promedio, de 177.730 kilobytes, de los cuales
157.281 kilobytes son datos, esta da un porcentaje de casi 12 % de desperdicio. En la
figura 5.4 Se pueden visualizar los porcentajes de desperdicio de kilobytes.
LogicRaptor
Agente Estacionario
12%
4%
96%
88%
Datos Trasmitidos
Desperdicio
Figura 5.4 Porcentaje de desperdicio de ancho de banda.
De este análisis se deduce que los agentes móviles no solo producen menos
carga en la red, sino también que la aprovechan mejor.
5.3.3.3 Impacto en las comunicaciones
Como se puede ver en la figura 5.5, el flujo del tráfico de red total generado por
la aproximación que utiliza agentes estacionarios es de carácter continuo, es decir que
agrega importante carga en la red desde el momento en que el agente comienza a
realizar la búsqueda de libros hasta que termina.
71
Figura 5.5 Tráfico de red generado por los Agentes Estacionarios
Por otro lado, como se visualiza en la figura 5.6, los agentes móviles
(LogicRaptors) solo generan tráfico de red durante pequeñas porciones de tiempo, que
corresponden al momento en que se trasladan de un sitio a otro.
Figura 5.6 Tráfico de red generado por los LogicRaptors
72
Esta forma de comunicación por ráfagas de tiempo, produce un notable impacto
positivo en las comunicaciones, ya que ha diferencia del sistema que utiliza agentes
estacionarios permite que otras aplicaciones utilicen la red, sin mayores problemas, al
mismo tiempo que el sistema multi-agente está ejecutando.
5.3.3.4 Tiempos de Ejecución
Con respecto a los tiempos de ejecución, antes de realizar cualquier análisis, es
importante aclarar, que los tiempos obtenidos son grandes debido principalmente a dos
motivos.
En primer lugar, el algoritmo que utilizan los agentes para hacer las búsquedas
(matching) en los blackboard de cada librería tiene una complejidad de O(n2) y esto es
muy costoso en relación con algoritmos de búsqueda estándar que están en orden de
O(n.log n). Una alternativa para reducir el costo temporal del algoritmo sería utilizar el
predicado retract. que es la forma usual de recorrer los hechos del blackboard, pero el
uso de este método para recorrer el blackboard tendría como consecuencia (en el caso
de existir más de un agente realizando consultas simultáneamente sobre el blackboard)
que cada agente solo pudiera ver información parcial. Además, cualquier modificación
de los datos del blackboard ocasionaría problemas de sincronización y por ende
resultados de búsqueda erróneos.
Otra razón para que los tiempos de ejecución sean grandes es que debido a que la
versión de JavaLog utilizada en el trabajo, usa para almacenar la base de datos Prolog
una tabla de dispersión, y va dispersando los diferentes hechos y cláusulas por su
cabeza y aridad. En nuestro caso todas las publicaciones de libros (hechos) tienen la
misma cabeza (book) y la misma aridad (9), por lo tanto, todas caen en el mismo balde
de la tabla de dispersión, provocando que la búsqueda en esa estructura sea similar a
buscar en una lista, perdiendo de esta manera las ventajas que tienen las tablas de
dispersión para realizar búsquedas.
En la figura 5.7 se pueden visualizar las curvas pertenecientes al tiempo de
ejecución de los agentes en función de la cantidad de datos transmitidos, tanto cuando
la velocidad de transmisión de la red es 100mbps como cuando es de 10mbps.
Decimos tiempo de ejecución en función de la cantidad de datos transmitidos ya
que, debido a como se configuraron los agentes, el agente 3 transmite mayor cantidad
de datos que el agente 2 y este, a su vez, transmite mas que el agente 1.
En el gráfico se puede ver que los tiempos de ejecución para los agentes
estacionarios crecen abruptamente a medida que aumenta la cantidad de datos que
trasportan. En cambio, la curva temporal para los agentes móviles tiene un crecimiento
mucho más suave, tendiendo a mantenerse constante cuando la cantidad de datos
transportados es grande. Esta tendencia se hace más notoria cuando la velocidad de la
red es 10 mbps.
73
Tiempo (minutos)
40
30
20
10
0
Agente 1
Agente 2
Agente 3
Cantidad de Datos Transmitidos (Kilobytes)
LogicRaptor (100mbps)
Ag.Estacionario (100 mbps)
LogicRaptor (10mbps)
Ag.Estacionario (10mbps)
Figura 5.7 Tiempo de ejecución de los LogicRaptors vs los agentes estacionarios.
5.4 Conclusiones de la experiencia
Luego de realizar el análisis de los datos obtenidos, se puede concluir, como se
esperaba, que la carga de red generada es la principal ventaja de los sistemas de
agentes móviles, con respecto a los agentes estacionarios.
Por otro lado, la tendencia marca que el sistema de agentes móviles es más
rápido a medida que la velocidad de transferencia de red es menor y la cantidad de
datos trasportados es mayor. Por lo tanto, para aplicaciones que manejan un volumen
importante de datos en Internet, donde la velocidad de transferencia es mucho menor a
la que poseen las redes donde se realizó la experiencia, es ampliamente recomendable
el uso de sistemas de agentes móviles. Más aún, en Internet, un sistema de agentes
estacionarios, como el usado en esta experiencia, es una solución inviable, ya que
haciendo una progresión sobre los datos obtenidos, si bajáramos la velocidad de
transmisión de la red a los valores reales de Internet, obtener resultados nos llevaría
unas cuantas horas.
Creemos que la principal razón por la que los sistemas de agentes estacionarios
son más lentos es debido a la cantidad de overhead, en comunicaciones y en tiempo de
CPU, necesario para mantener las conversaciones con los otros sitios, en donde están
las librerías.
Aunque nuestra experiencia nos muestra que los sistemas de agentes móviles son
la mejor opción, principalmente debido a la ineficiencia de la aproximación con
agentes estacionarios, también es cierto que esta experiencia no incluye todos los casos
posibles. Sería interesante poder ampliar la experiencia a diferentes dominios de
aplicación y ambientes de ejecución.
74
Aunque tratamos un solo problema y en un número limitado de casos, creemos
que experimentos como este son un paso importante hacia una objetiva evaluación de
los sistemas multi-agentes, que permitan tener datos cuantitativos sobre los cuales
basar y justificar decisiones de diseño.
75
6
Conclusiones
En este capítulo se analizan las diferentes
conclusiones sobre el trabajo y se presentan
propuestas para trabajos futuros.
.
En este trabajo se presentó una arquitectura integrada a la web para soportar
agentes móviles basados en lógica. Esta arquitectura fue desarrollada utilizando el
paradigma lógico y el orientado a objetos. Esto permite que los agentes sean
programados usando el paradigma de programación en lógica y todos los mecanismos
de comunicación estén implementados en Java. También se presentó una herramienta
web, llamada LogicRaptors Center, que permite administrar los sistemas de agentes
móviles que utilizan la arquitectura desarrollada.
La primer parte del trabajo consistió en un estudio exhaustivo de varios de los
principales sistemas de agentes móviles existentes hoy en día. Este análisis se realizó
con el fin de encontrar las características buenas y malas de cada uno, permitiendo de
esta manera que el diseño de nuestra arquitectura solucione algunas de las limitaciones
encontradas en los sistemas de agentes móviles estudiados.
Para el diseño de la arquitectura se utilizó como referencia una arquitectura
genérica para sistemas de agentes móviles (sección 4.2), esto permitió focalizarnos
estrictamente en el diseño del soporte para agentes basados en lógica, dejando de lado
cuestiones ya ampliamente discutidas por varios autores, como, por ejemplo, la de
decidir que componentes debe contener una arquitectura de agentes móviles y cuales no.
La arquitectura presentada permite, además de aprovechar las ventajas del
paradigma lógico para la representación de estados mentales y de Java para la
comunicación, mantener el estado de ejecución de un agente, mientras migra de un host
a otro (Migración Fuerte).
Para coordinar las comunicaciones necesarias entre los diferentes nests fue
implementado un protocolo de comunicación llamado MTP (MTP Transfer Protocol).
Esto permite obtener un alto grado de independencia con respecto a los protocolos de
comunicación de bajo nivel como TCP/IP o UDP/IP.
Otra característica importante que posee es la de permitir que un agente móvil sea
programado utilizando toda la potencia expresiva que brinda JavaLog (predicados
Prolog + predicados propios de JavaLog), solucionando de esta manera una de las
principales limitaciones que posee Jinni, que solo soporta un subconjunto muy reducido
Conclusiones
de Prolog (por ejemplo no soporta corte en el backtracking), lo cual limita
considerablemente su potencia expresiva.
Otro aspecto de la arquitectura que mejora la alternativa propuesta por Jinni, es el
esquema de migración de los agentes. En nuestra arquitectura un agente cuando migra
transporta todos los módulos lógicos pertenecientes a su conocimiento. De esta manera
se soluciona uno de los principales problemas de Jinni, en donde un agente al migrar
solo está formado por un thread más el código de la cláusula actual y al no proveer, el
lenguaje, otros mecanismos para definir la clausura de código de un agente, no se puede
asegurar que el agente pueda continuar su ejecución en el sitio destino.
La manera de solucionar el problema anterior que propone Jinni, no es
transparente para el programador y en ciertos casos genera más problemas que los que
solucionan. En nuestra propuesta, para lograr la movilidad de los agentes, el
programador solo debe definirles sus preferencias y los algoritmos de búsqueda y no
debe preocuparse por detalles de bajo nivel.
Con el fin de poder manipular agentes sin tener que tener amplios conocimientos
de todos los detalles de bajo nivel, se diseño LogicRaptors Center, el cual es una
herramienta básica para la administración de los LogicRaptors y supervisión de los
Nest.
Una vez terminado el diseño e implementación de la arquitectura propuesta, y con
el propósito de recolectar datos cuantitativos, que permitan determinar precisamente la
conveniencia de la utilización de agentes móviles sobre la utilización de estacionarios,
se realizó una experiencia simulando un sistema de búsqueda de ofertas de libros, en
librerías virtuales.
Se realizó el análisis de performance entre los sistemas multi-agentes móviles
(LogicRaptors) y estacionarios, ambas aproximaciones fueron evaluadas usando varias
métricas de performance para poder descubrir las ventajas y desventajas de cada
variante.
La experiencia realizada nos permite concluir, principalmente, que la carga de red
generada es la mayor ventaja de los sistemas de agentes móviles, con respecto a los
agentes estacionarios. En cuanto a la velocidad pudimos ver que, a medida que la
velocidad de transferencia de red es menor y la cantidad de datos transportados es
mayor, los agentes móviles realizan las tareas más rápidamente que los estacionarios.
Esto es consecuencia directa de la cantidad excesiva de comunicación que debe realizar
un agente estacionario para llevar a cabo sus tareas.
6.1 Limitaciones y posibles trabajos futuros
Las pruebas realizadas a la arquitectura muestran que ésta funciona de manera
satisfactoria, cumpliendo con los objetivos trazados al principio. Aunque, todas las
pruebas fueron realizadas en un ambiente ideal, donde no había que considerar
problemas de seguridad, por lo que queda como posibles extensiones implementar los
componentes de la arquitectura de referencia que no fueron implementados como el
administrador de seguridad, el de confiabilidad o el administrador de accesos a
servidores de aplicaciones.
Agregar un componente de confiabilidad al Nest permitiría que este pueda
recuperar su estado ante el eventual caso de una caída del sistema. Para esto tendría que
77
Conclusiones
almacenar, según alguna política a definir, los agentes presentes en el Nest con su
correspondiente estado de ejecución y el estado del blackboard.
Aunque no estaba dentro de los objetivos de nuestro trabajo, uno de los problemas
que encontramos fue la performance de los agentes. Como se explicó en la sección
5.3.3.4, los tiempos elevados se deben en parte a que en el momento de desarrollo de
nuestro trabajo, JavaLog no estaba optimizado para almacenar grandes volúmenes de
datos. Por lo tanto, una posible mejora es integrar nuestro trabajo con la nueva versión
de JavaLog, que mejora notablemente lo mecanismos de almacenamiento. Actualmente
en JavaLog se puede almacenar un modulo lógico en una base de datos y conectarse a
ella usando JDBC. Esto, sin dudas, mejorará notoriamente la performance en las
búsquedas, en los blackboards, de los LogicRaptors.
Otra manera de disminuir los tiempos de ejecución de los LogicRaptors sería
agregar predicados a JavaLog dedicados a optimizar las búsquedas en la base de datos
Prolog. JavaLog no posee un mecanismo para iterar sobre todos los hechos de una base
de datos sin utilizar el método usado generalmente para tal fin, es decir, haciendo un
recorrido recursivo, donde con cada iteración lo que se hace es eliminar el primer hecho
encontrado, procesarlo, realizar la llamada recursiva y luego insertarlo nuevamente en la
base de datos. Por lo tanto, para recorrer la base de datos se deben utilizar algoritmos
cuya complejidad temporal es inaceptable.
Una posible extensión a este trabajo, la cual optimizaría notablemente el
comportamiento global de la arquitectura, sería permitir la comunicación entre los
LogicRaptors para que puedan actuar colaborativamente en una tarea determinada, por
ejemplo, en la búsqueda de información.
Por otro lado, sería interesante extender LogicRaptors Center, para convertirla en
una herramienta más completa para la manipulación y programación de agentes y
administración de los nest. Algunas de las características que se le podrían agregar son:
• Realizar un seguimiento de manera gráfica de la ruta tomada por los diferentes
agentes, dado que esa información actualmente es volcada en archivos de logs.
• Poseer directivas para los agentes que se encuentran viajando, por ejemplo:
abortar la búsqueda y regresar a casa con los resultados conseguidos hasta el
momento, no ir a un sitio determinado (filtrar hosts) o simplemente poder
eliminar a un agente a distancia.
• Mecanismos de persistencia para, tanto, las diferentes configuraciones de los
agentes, como así también la información obtenida por ellos.
Por último podemos agregar que adherir a un estándar como MASIF permitiría
aceptar en los Nests no sólo LogicRaptors sino cualquier agente que cumpla con este
estándar. Esto ampliaría el dominio de aplicación de la arquitectura, permitiendo ser
usada en problemas más generales que los tratados en este trabajo.
78
A
JavaLog
En este apéndice se detallan las
características más importantes
de JavaLog.
A.1 Introducción
En este apéndice se presentará un resumen de las características más importantes
de JavaLog. Es importante destacar que es fundamental la comprensión de algunos
aspectos de JavaLog, ya que el trabajo presentado en los capítulos anteriores está
construido usando este lenguaje.
La programación de agentes involucra tanto el encapsulamiento de sus
comportamientos como el de su estado mental. Estas características han llevado a que
se utilicen lenguajes orientados a objetos para programar sistemas multi-agentes. Los
lenguajes orientados a objetos han mostrado poseer varias de las características
necesarias para codificar funciones clásicas de agentes. Sin embargo, cuando estados
mentales complejos deben ser administrados, la programación lógica ha mostrado ser
una mejor alternativa para la implementación de actitudes mentales. En consecuencia,
viejas ideas con relación a lenguajes multi-paradigmas [Ishikawa 86] [Fukunaga 86]
[Mello 87] aparecen como una posible solución a la programación de agentes. Entre
tales las propuestas, JavaLog utiliza aquellas ubicadas en el contexto de utilizar
cláusulas lógicas para representar conocimiento interno de objetos, intentando resolver
los inconvenientes encontrados en la programación de agentes y sistemas multiagentes.
JavaLog es un lenguaje multi-paradigma que permite construir agentes a partir de
objetos Java capaces de manipular conocimiento en formato de cláusulas lógicas
Prolog o extensiones de este lenguaje lógico. La integración de programación orientada
a objetos y programación lógica alcanzada en JavaLog ha sido basada en el concepto
de módulo lógico. Un módulo lógico es la encapsulación de una secuencia de cláusulas
lógicas. Estos módulos pueden ser ubicados tanto en métodos Java como en variables,
para luego ser combinados de diversas maneras.
El apéndice se organiza de la siguiente manera. La sección 2 se presenta algunos
aspectos sobre la integración de paradigmas. En la sección 3, presenta los componentes
más relevantes del lenguaje, describiendo los mecanismos que hacen posible la
JavaLog
interacción entre objetos y cláusulas lógicas. En la sección 4 se describen las primitivas
de comunicación provistas por JavaLog.
A.2 Integración de objetos y lógica
Los paradigmas lógico y orientado a objetos trabajan sobre diferentes elementos.
Para integrar la programación orientada a objetos con la programación lógica y
viceversa es necesario realizar un mapeo entre los elementos de cada uno.
La programación orientada a objetos utiliza elementos (objetos) que son
accedidos en un contexto restringido. Estos objetos son manipulados por métodos y
encapsulan datos propios de la entidad que modelan. Por otro lado, la programación
lógica trabaja con términos y cláusulas.
JavaLog es una integración entre los paradigmas: lógico y orientado a objetos
desarrollado para la programación de agentes. La programación orientada a agentes
utiliza objetos para modelar las habilidades de los agentes y cláusulas lógicas para
modelar el estado mental de dichos agentes. Las habilidades de los agentes pueden
estar representadas por capacidades de acción como por capacidades de comunicación
con otros agentes, mientras que el estado mental puede presentarse en forma de
creencias, intenciones, compromisos, etc. Esta integración define el módulo como el
componente básico de manipulación. En el dominio de JavaLog, un objeto y un
método de la programación orientada a objetos se ven como módulos. Un objeto es un
módulo que encapsula datos y un método es un módulo que encapsula
comportamiento. Además, JavaLog utiliza el concepto de módulo lógico como un
conjunto de cláusulas de Horn. De esta manera, un agente puede modelarse como una
composición de módulos.
En la figura A.1 se pueden observar dos agentes compuestos por módulos y una
referencia a un objeto (llamado brain) que hace las veces de cerebro del agente. Este
objeto es una instancia de un intérprete de módulos lógicos que utiliza cláusulas
Prolog. Cada agente es una instancia de una clase que puede definir parte de sus
métodos en Java y parte en Prolog. Así, la definición de los métodos de una clase
puede estar compuesta por varios módulos lógicos. Una instancia de una clase de este
tipo presenta una composición de módulos lógicos definidos en métodos y módulos
lógicos referenciados por variables de instancia.
Figura A.1: Esquema de composición de módulos
80
JavaLog
Para realizar esta composición de módulos lógicos y orientados a objetos
mediante la integración de objetos y lógica, JavaLog provee un intérprete Prolog
basado en el concepto de módulo. Este intérprete está implementado en Java y permite
utilizar objetos dentro de cláusulas lógicas, así como embeber módulos lógicos dentro
de código Java. En las secciones siguientes se describen las distintas formas de integrar
objetos y lógica con JavaLog.
A.3 El lenguaje JavaLog
Para poder utilizar objetos Java en programas Prolog y módulos lógicos Prolog
en objetos Java es necesario contar con un conjunto de primitivas que permitan esta
integración. JavaLog ofrece un lenguaje de interacción objetos-lógica-objetos que le
brinda al programador de agentes la posibilidad de utilizar las características de ambos
paradigmas.
A.3.1 Objetos Java en programas Prolog
En la programación de agentes se requiere manipular un conjunto de estados
mentales que son resultado, o dan como resultado, la utilización de algunas de las
habilidades del agente. Para modelar los estados mentales como cláusulas lógicas y las
habilidades como métodos de objetos es necesario poseer una forma de interacción que
permita:
•
Crear objetos Java en programas Prolog.
•
Adquirir una representación lógica de un objeto creado en Java.
•
Enviar mensajes a objetos en evaluaciones Prolog.
A.3.1.1 Creación
Cuando en Prolog se desea construir algún tipo de visualización, por ejemplo,
por razones de claridad y eficiencia, resulta conveniente utilizar las herramientas de
visualización que provee un lenguaje orientado a objetos como Java. Así, si se desea
crear un botón en una ventana desde un programa Prolog, se puede utilizar el predicado
predefinido newInstance( +Class, +Var) que invoca al constructor de la clase Class y
coloca el objeto creado en Var de la forma:
newInstance( 'Button', Button1).
Esta primitiva presenta una de las formas de incorporar objetos Java en los
programas Prolog.
De esta manera, se pueden crear objetos que luego serán utilizados e inclusive
almacenados en una base de datos Prolog.
A.3.1.2 Interacción Java-Prolog
Una de las características de mayor utilidad es la posibilidad de representar
objetos Java en cláusulas Prolog. Es decir, es posible obtener una representación en
81
JavaLog
forma de cláusula lógica de un objeto. Esto se logra utilizando un mensaje particular
llamado toClause de la forma:
PlClause.toClause(aPerson, new UnaryFunction[ ] {
new UnaryFunction() {
public Object execute(Object arg) {
return ((Person)arg).firstname() }
}
new UnaryFunction() {
public Object Execute(Object arg) {
return ((Person)arg).lastname() }
}
} );
Este fragmento de código toma un objeto aPerson, instancia de la clase Person y
lo transforma en una cláusula Prolog, instancia de la clase PlClause. El método
toClause ejecuta las funciones de un arreglo (bloque) pasado como segundo argumento
sobre el primer argumento. Este arreglo contiene la política de mapeo del objeto a la
cláusula. Es decir, en este ejemplo se desea representar al objeto aPerson con una
estructura con functor person (nombre de la clase) y argumentos nombre y apellido (
de acuerdo al estado del objeto). Supongamos que este fragmento de código se ejecuta
con el objeto aPerson cuyo valor de retorno del mensaje firstname() es Francisco y el
de lastname() es Sanchez, la cláusula correspondiente será person( aPerson, 'Francisco',
'Sanchez'). Donde Aperson es una variable ligada con el objeto aPerson.
A.3.1.3 Envío de mensajes
Una vez que se tiene una forma de acceder a un objeto Java, es necesario poder
acceder al estado interno del mismo, u obtener algún comportamiento particular. En la
programación orientada a objetos esto se logra con el envío de mensajes al objeto
destino. Este proceso en la programación JavaLog, se llama invocación de módulos (en
este caso de comportamiento). JavaLog provee un predicado predefinido que, dado un
objeto (módulo que encapsula datos), invoca sus métodos (módulos de
comportamiento). Por ejemplo, si con una consulta Prolog se recupera el módulo que
encapsula los datos de Francisco Sánchez:
?- person( X, 'Francisco', 'Sanchez').
La variable X se ligará con la instancia de Person correspondiente. Si se desea
conocer la edad de Francisco Sanchez, es posible invocar al método age():
?- send( X, age, [ ], Y).
Esta consulta enviará el mensaje age al objeto aPerson y ligará la variable Y con
el valor retornado por el método correspondiente. Esto es equivalente a la sentencia
Java:
Y = aPerson.age();
82
JavaLog
A.3.2 Prolog Embebido
La característica más importante de JavaLog es la posibilidad de manipular en
forma indistinta módulos lógicos y módulos orientados a objetos. Esta característica
guía la definición del lenguaje JavaLog en base al manejo de módulos lógicos. Un
módulo lógico puede almacenarse en una base de datos Prolog o puede asignarse a
variables Java de forma tal que pueda ser activado cuando se necesite utilizar su
contenido en una evaluación determinada. De esta forma, las cláusulas lógicas
embebidas en los métodos Java se traducen a módulos lógicos asociados a la clase del
objeto mediante el preprocesador JavaLog. El preprocesador JavaLog toma como
entrada código Java con Prolog embebido (código JavaLog) y genera un archivo con el
código Java equivalente.
A.3.2.1 Módulos lógicos
La interacción entre módulos lógicos y módulos orientados a objetos esta
definida en base a tres parámetros: referencia, comunicación y composición. Cuando se
habla de referencia, se establece la locación de los módulos lógicos como variables de
instancia o como parte de los métodos de las clases. De esta manera un objeto JavaLog
puede contener conocimiento privado en cláusulas lógicas. Las capacidades de acción
de los objetos-agentes JavaLog vienen dadas por los métodos Java que tiene la
posibilidad de encapsular módulos lógicos y consultas sobre una base lógica. Por
ejemplo, supongamos un agente comerciante como una instancia de la clase
CommerceAgent que tiene la habilidad de seleccionar y comprar elementos de
acuerdo a las preferencias de la persona que representa. Las preferencias de este agente
pueden cambiar por razones contextuales, con lo cual, la habilidad de comprar cada
tipo de elemento está regida por las preferencias activas. Por esta razón, los distintos
conjuntos de preferencias se almacenan en módulos lógicos como el que sigue:
preference(car, [ford, Model, Price]):Model > 1998,
Price < 60000.
preference(motorcycle, [yamaha, Model, Price]):Model >= 1999,
Price < 9000.
Utilizando JavaLog, la clase del agente comerciante se define de la siguiente manera:
public class CommerceAgent {
private Brain brain;
private PlLogicModule userPreferences;
public CommerceAgent( PlLogicModule userPreferences ) {
brain = new Brain()
this.userPreferences = userPreferences;
}
...
83
JavaLog
public Brain brain(){ return this.brain; }
...
public boolean buyArticle( Article anArticle ) {
userPreferences.enable();
type = anArticle.type;
if (?-preferences( #anArticle#, [#type#,
#brand#, #model#, #price#]).)
buy(anArticle);
userPreferences.disable();
}}
En este ejemplo se puede observar que la variable userPreferences referencia
un módulo lógico con las preferencias del agente. Estas preferencias son habilitadas
cuando se necesitan (por ejemplo en la decisión de la compra o no del artículo) y son
deshabilitadas después de utilizarse. Para verificar la aceptabilidad de la compra, se
embebe una consulta Prolog que utiliza el conocimiento activado del agente acerca de
sus preferencias. Esta consulta contiene variables encerradas entre #. Esta es la forma
en que JavaLog utiliza las variables Java en consultas Prolog.
Cuando se tiene un agente de este tipo se debe definir un método brain() que
retorna una instancia del intérprete JavaLog. El intérprete JavaLog es el encargado de
realizar todas las deducciones a partir de módulos lógicos. Este intérprete es asociado
con lo que sería el cerebro del objeto-agente JavaLog. Ahora bien, si se necesita
construir un agente que cambie de preferencias de acuerdo a ciertas condiciones dadas
en su contexto, es posible definir un módulo lógico para cada una de las condiciones.
Es decir, suponiendo que el agente comerciante posee las preferencias anteriores
en condiciones normales, pero ante una necesidad de inversión puede cambiar sus
preferencias a:
preference(car, [ _, Model, Price]):Model > 1995,
Price < 100000.
preference(motorcycle, [ _, Model, Price]):Model >= 1995,
Price < 15000.
De esta manera, el agente comerciante puede contener dos o más variables de
instancia con las distintas preferencias. Estas preferencias serán cambiadas cuando el
usuario del agente lo desee utilizando el método switchContext. El siguiente
fragmento de código muestra esta incorporación a la clase CommerceAgent.
private int actualPref;
private PlLogicModule[ ] userPreferences;
public CommerceAgent( PlLogicModule userPreferences ) {
brain = new Brain();
84
JavaLog
this.userPreferences[0] = userPreferences;
this.actualPref = 0;
}
...
...
public int addPreferences(PlLogicModule userPreferences ){
this.userPreferences[this.userPreferences.length + 1] =
userPreferences;
return this.userPreferences.length + 1;
}
...
public void switchContext( int newContext ) {
this.actualPref =ñewContext;
}
...
public boolean buyArticle( Article anArticle ){
userPreferences[actualPref].enable();
buy(anArticle);
userPreferences[actualPref].disable();
}}
En un objeto de la clase CommerceAgent se pueden incorporar la cantidad de
módulos lógicos con preferencias que se deseen. Para conocer qué preferencia tiene
que utilizar en la decisión de una compra, el agente comerciante conoce cuál es el
módulo lógico que debe activar en el momento de la compra por medio de una variable
de instancia actualPref. Otra implementación de esta clase podría contemplar la
posibilidad de realizar combinaciones de módulos lógicos de acuerdo a ciertas
condiciones variables, con lo cual las posibilidades de utilización del conocimiento del
agente se ven ampliamente incrementadas. El manejo de los módulos lógicos (también
llamados capacidades del agente) puede ser delegado al intérprete JavaLog. Una
instancia de la clase Brain puede manipular una cantidad de capacidades de un agente
con la utilización de primitivas de agregado, activación y desactivación de
capacidades. De esta manera, la clase CommerceAgent podría codificarse de la
siguiente manera:
private int nextContext;
public CommerceAgent( String userPreferences ) {
brain = new Brain()
brain().addCapability(“Context1”, userPreferences);
nextContext=2;
}
85
JavaLog
...
...
public int addPreferences( String userPreferences ) {
brain().addCapability(“Context” + nextContext,
userPreferences);
return nextContext++;
}
...
public void switchContext( int newContext ) {
brain().deleteCapabilities();
brain().activeCapability( “Context” + newContext);
}
..
public boolean buyArticle( Article anArticle ) {
buy(anArticle);
}}
En este ejemplo se puede observar la utilización de los métodos para el manejo
de las capacidades de un agente. El método addCapability agrega un módulo lógico
al conocimiento del agente, activeCapability activa para la evaluación un módulo
lógico y deleteCapabilies desactiva todos los módulos lógicos del agente.
Por otra parte, JavaLog permite embeber módulos lógicos en módulos de
comportamiento (métodos). Por ejemplo podría crearse una instancia del agente
comerciante anteriormente definido de la siguiente manera:
CommerceAgent anAgent = new ComerceAgent(
{{preference(car, [ford, Model, Price]):Model > 1998,
Price < 60000.
preference(motorcycle, [yamaha, Model, Price]):Model >= 1999,
Price < 9000.
}} );
Donde el código encerrado entre {{ y }} es traducido a un módulo lógico que es
pasado como parámetro al constructor de la clase CommerceAgent.
Cuando se embeben módulos lógicos en métodos, JavaLog aplica una política de
activación de dichos módulos tal que, un módulo puede ser activado explícita o
implícitamente y puede ser desactivado manual o automáticamente. El ejemplo anterior
muestra una forma de activación/desactivación explícita. El siguiente código muestra
un ejemplo de activación implícita y desactivación automática.
86
JavaLog
...
public void extra() {
{{ edge(4,6). }};
}
...
public void test() {
Integer i = new Integer( 1 );
extra();
System.out.println( "edge(X,Y) " + ?-edge(X,Y).
+ " X=" + brain().answer().get("X")
+ " Y=" + brain().answer().get("Y") );
{{ edge(#i#,2).
edge(2,3).
edge(3,4).
edge(6,7).
connected(X,Y):-edge(X,Y).
connected(X,Y):-edge(X,Z),edge(Z,Y).
?-edge(1,Y).
?-connected(A,B).
?-connected(4,7).
}};
System.out.println( brain().answer() );
}
Este código muestra la inclusión de dos módulos lógicos dentro de métodos Java.
El código Prolog encerrado entre doble llaves en los métodos extra() y test() se
traduce a módulos lógicos incluidos en las capacidades del brain de un objeto de esta
clase. La invocación al método extra() en test() produce la activación del módulo
lógico asociado con ese método. Luego, una consulta Prolog del tipo ?-edge(X, Y)
producirá una evaluación sobre el módulo lógico extra. Seguidamente se activará el
módulo lógico asociado con el método test(), el cual incorporará una serie de
cláusulas a su base de conocimientos y luego tratará de satisfacer las consultas
correspondientes. Una vez realizadas estas tres consultas (consultas múltiples), el
intérprete brain desactivará todos sus módulos lógicos (incluyendo extra). Resumiendo,
la inclusión de consultas dentro de módulos lógicos embebidos en métodos Java
produce la desactivación automática de todas las capacidades activas del agente,
mientras que una consulta embebida en el código Java, se evalúa sin efectos
colaterales.
JavaLog brinda una forma de acceder al valor al cual quedaron ligadas las
variables Prolog después de una consulta, así como el resultado de las últimas
consultas (en el caso de consultas múltiples). Para acceder al valor de una variable
puede utilizarse un diccionario de variables conteniendo pares del tipo (nombre, valor).
En el ejemplo anterior, este proceso está resumido en brain.answer().get(“X”).
Para recuperar el valor de la i-ésima consulta se podrá utilizar brain.result( i ).
87
JavaLog
A.3.2.2 Composición de Módulo lógicos
La composición de módulos lógicos puede ser tratada desde dos puntos de vista.
Los módulos lógicos referenciados por variables pueden ser combinados con la
utilización de métodos predefinidos. Por ejemplo enable() y disable() en el caso del
agente comerciante pueden utilizarse para activar cada uno de los conocimientos en
forma separada o combinada.
Los módulos lógicos embebidos en métodos Java pueden ser combinados
mediante la herencia.
Así, por ejemplo el siguiente fragmento de código muestra un método definido
con código JavaLog. El sector de código delimitado entre “{{“ y “ }}” define la forma
de evaluación de un estudiante en forma de cláusulas Prolog (un módulo lógico). A
continuación, el código contiene una consulta Prolog que obtiene la calificación de un
estudiante. En este caso el predicado Prolog incluye una variable Java #aStudent#
con un objeto estudiante.
public class Profesor {
...
...
public String qualification() {
{{ qualification(Student, 'A'):- exercise(Student, passed),
finalTest(Student, passed).
qualification(Student, 'B'):- exercise(Student, passed).
...
?- qualification(#aStudent#, X). }};
if( brain().result(1) )
return brain().answer().get( “X” ).toString();
else
return null;
}}
Una subclase de Profesor puede redefinir el método qualification. La forma
de realizar dicha redefinición permite obtener distintas combinaciones de módulos
lógicos: redefinición o conjunción de módulos lógicos. Si el método de la superclase
contiene una consulta en el módulo lógico embebido, toda subclase de esa clase
redefinirá el módulo lógico correspondiente. Si, en cambio, el módulo lógico de la
superclase no contiene consultas, la subclasificación producirá una agregación de
módulos lógicos. En el caso de la clase Profesor, el módulo lógico contenido en el
método qualification(Student aStudent) incluye una consulta, con lo cual
cualquier redefinición del método concluirá en una redefinición del módulo lógico. Por
ejemplo, la clase PostGradoProfesor redefine este método y utiliza la evaluación
sobre el módulo lógico de su superclase.
public class PostGradoProfesor extends Profesor {
88
JavaLog
...
public String qualification( Student aStudent ) {
String qualification=super().qualification(aStudent)
{{ qualification(Student, 'A'):- #qualification# = 'A',
seminary(Student, 'A').
qualification(Student, 'B'):- #qualification# = 'A',
seminary(Student, 'B').
?- qualification(#aStudent#, X). }};
...
}
Para conseguir la agregación de módulos lógicos, una clase puede embeber
módulos lógicos que sólo contengan cláusulas (sin consultas). En el caso del profesor,
si la consulta: ?-qualification(#aStudent#, X) no se encontrara dentro del
módulo lógico, cualquier subclase podría agregar un módulo lógico con cláusulas con
la misma cabeza, o bien redefinir dichas cláusulas (sin invocar al súper). El siguiente
fragmento de código muestra una nueva definición de la clase Profesor.
public class Profesor {
...
...
public String qualification(){
{{ qualification(Student, 'A'):exercise(1, Student, passed),
exercise(2, Student, passed),
finalTest(Student, passed).
qualification(Student, 'B'):exercise(Student, passed),
exercise(2, Student, passed).
}};
}...
public String qualification( Student aStudent ) {
qualification();
?- qualification(#aStudent#, X). ;
if( brain().result(1) )
else
return null;
}}
Una instancia de esta clase, si recibe el mensaje qualification(aStudent)
invoca el método qualification(). Este método agrega el módulo lógico a su base
de conocimiento. Luego se realiza la consulta a partir de esta base de conocimiento. Si
se quiere implementar la clase correspondiente a un profesor con otra forma de
89
JavaLog
calificación, se pueden agregar niveles de calificación al Profesor (redefiniendo
qualification() ), como muestra el siguiente ejemplo.
public class ProfesorA extends Profesor{
...
public String qualification() {
super.qualification();
{{ qualification(Student, 'C'):- exercise(1,
Student, passed). }};
}
...
}
En esta redefinición del método qualification() la invocación a
super.qualification() incorpora a la base de conocimiento el módulo lógico del
método de la superclase y luego se agrega el módulo lógico definido en el método de la
subclase. Por otro lado, si se omite esta invocación, la base de conocimiento contendrá
sólo el módulo lógico definido en la subclase, con lo que se logra el efecto de
reescritura del módulo lógico. Existe otra forma de modificar la base de conocimiento
del objeto en forma dinámica. Es decir, la posibilidad de tratar los módulos lógicos y
los módulos orientados a objetos sin distinción permite que un módulo lógico sea
pasado como parámetro a un método y, de esta manera, ser activado en el cerebro del
objeto-agente.
A.3.2.3 Preprocesador JavaLog
Una vez que el código JavaLog es escrito es necesario traducirlo a su equivalente
en código Java. Esta tarea es realizada por el preprocesador JavaLog. El preprocesador
JavaLog toma como entrada un archivo de extensión javalog y genera un archivo con
extensión java que luego puede ser compilado a bytecode por cualquier compilador jdk
1.1.3 o superiores. Si, por ejemplo, el código del agente comerciante se encuentra en
un archivo commerceAgent con extensión javalog, la siguiente invocación al
preprocesador generará el archivo commerceAgent con extensión .java.
./JavaLog.sh -p commerceagent.javalog
A.4 Interacción entre agentes
Uno de los puntos de estudio fundamentales en la programación de agentes es la
comunicación en sistemas multi-agentes. En un sistema de este tipo existen una
cantidad de agentes ocupándose de realizar la tarea que le ha sido asignada. Para esto,
es posible que necesiten tanto recursos compartidos, como conocimiento compartido.
Es decir, es frecuente que un agente necesite del conocimiento (o parte del
conocimiento) de otro agente para alcanzar un objetivo propio. Cuando se trata con
sistemas multi-agentes, donde estos agentes comparten parte de su conocimiento o
tienen objetivos comunes, es necesario contar con alguna forma de organización del
sistema para obtener la mayor productividad individual y colectiva. Un primer paso
90
JavaLog
hacia esta organización es la posibilidad de contar con algún medio de comunicación
que permita implementar algoritmos de coordinación.
JavaLog incorpora una arquitectura de referencia para la programación de
sistemas multi-agentes que permite modelar un agente como un objeto Java y su estado
mental como cláusulas Prolog. Además, brinda una serie de primitivas de
comunicación entre agentes para compartir conocimientos y objetivos. En este aspecto,
el concepto de módulo lógico toma fundamental importancia ya que cada agente
encapsula parte de su conocimiento (o todo su conocimiento) en módulos lógicos.
Estos módulos lógicos pueden ser privados al agente o pueden ser publicados en un
repositorio Prolog para que pueda ser utilizado por el resto de la comunidad de agentes.
Este repositorio se ajusta a una arquitectura Blackboard, donde se posee un medio de
comunicación centralizado en el cual los distintos componentes de la arquitectura leen
o escriben datos relevantes al procesamiento de las tareas colectivas. Además, estos
agentes pueden comunicarse entre si (sin la utilización del Blackboard) para, por
ejemplo, pedir ayuda a otros agentes.
De esta manera, un agente que es incapaz de resolver una consulta puede delegar
esta tarea, o parte de ella, a otro agente que con su conocimiento, puede llevar a cabo
satisfactoriamente la evaluación de la misma consulta.
En las próximas secciones se describirán las primitivas de comunicación que
ofrece JavaLog para una arquitectura distribuida y una arquitectura Blackboard.
A.4.1 Arquitectura Blackboard
La arquitectura Blackboard está definida en función a su componente principal,
el blackboard. Un blackboard es una estructura de datos que puede ser leída y
modificada por programas llamados fuentes de conocimiento (Knowledge Source).
Cada fuente de conocimiento se especializa en la resolución de una parte particular de
un tarea completa. Así, todas las KS trabajan en forma conjunta en la búsqueda de una
solución. Estos programas especializados son independientes entre sí. El rumbo
tomado por el sistema está determinado principalmente por el estado del
procesamiento, el cual es evaluado por un componente central que controla y coordina
los programas especializados. De esta forma, es posible realizar un control de los datos
de manera oportunista. Esto aumenta la experiencia del componente de control, a partir
de lo cual, puede construir heurísticas derivadas experimentalmente para controlar el
procesamiento. JavaLog ofrece una serie de primitivas de comunicación donde las
fuentes de conocimiento (objetos agentes) se pueden comunicar con un componente
centralizado. En un sistema multi-agente, cada componente de la comunidad de
agentes posee su base de conocimiento privada y un cerebro (intérprete Prolog) que la
interpreta. Además, la comunidad puede tener una base de conocimiento pública
(blackboard) y un agente con un comportamiento especial (componente de control).
La figura A.2 muestra una arquitectura blackboard definida por un objeto-agente
centralizado (componente de control) que posee una base de conocimiento privada.
Este intérprete puede hacer pública una parte de su base de conocimiento (blackboard)
para que todos los agentes de la comunidad escriban y lean de ella. Además, cada
agente del sistema, posee su propio cerebro (intérprete Prolog) con su respectiva base
de conocimiento privada.
91
JavaLog
Figura A.2: Arquitectura Blackboard
En este contexto, el agente de control puede publicar un módulo lógico en el
blackboard con la primitiva publishm(ModuleName), donde ModuleName es el
nombre del módulo que se desea publicar. Un agente comparte su estado mental
utilizando los predicados publish y publishm y pregunta por los módulos públicos de
un agente con registryObjs:
publish(Identificador): hace pública la base de datos del agente. La base de datos se
publica con el nombre.
//<NombreHost>/JavaLog/<Identificador>.
publishm(NombreMódulo, Identificador): hace público un módulo lógico del agente.
El módulo lógico se publica con el nombre.
//<NombreHost>/JavaLog/<NombreMódulo>/<Identificador>.
registryObjs(NombreHost, ListaURL): consulta con el host NombreHost qué módulos
lógicos exporta. ListaURL se instancia con una lista con los identificadores de módulos
remotos.
Luego, otro agente puede conectarse al blackboard utilizando la primitiva
connect(ModuleName: El predicado connect incorpora una referencia a un módulo
lógico remoto en la base de datos local; connect recibe un argumento con un
identificador de un objeto remoto con la sintaxis:
//<NombreHost>/JavaLog/<Identificador>
donde NombreHost es el nombre o la dirección IP (Internet Protocol) del host que
contiene el módulo lógico identificado por Identificador. De esta forma, la conexión a
una base de conocimiento remota puede verse como la incorporación de un módulo
lógico remoto a la base local . Por ejemplo, si un agente ejecuta:
connect('//javaLog.exa.unicen.edu.ar/JavaLog/publicDataBase').
se produce la incorporación de un módulo lógico remoto con el contenido de la base de
datos del servidor especificado, a la base de datos del agente.
Luego de que un agente se conecta con una base de datos remota, la evaluación
de una consulta local se realiza de la misma forma que antes, sólo que ahora se tiene en
cuenta el contenido de la base remota. Si este agente desea escribir algo en el
blackboard, puede hacerlo con la utilización de assertm(ModuleName, Clause). El
predicado assertm se utiliza para agregar cláusulas a un módulo lógico, y por lo tanto
puede ser usado con un módulo lógico remoto de la misma forma que con un módulo
lógico local.
92
JavaLog
A.4.2 Delegación
JavaLog provee facilidades para efectuar delegación de tareas entre agentes. El
mecanismo de delegación permite a un agente solicitar a otros la realización de tareas
determinadas. Dicho mecanismo resulta de utilidad, por ejemplo, cuando existen
agentes con diferentes capacidades, y por consiguiente, con diferente estado mental;
así, un agente puede solicitar la colaboración de los agentes aptos para cada tarea en
particular. Es decir, un agente puede tener el conocimiento necesario para satisfacer
una consulta pero puede carecer de la habilidad de efectuar esa consulta. Por medio del
mecanismo de evaluación remota, un agente puede utilizar el cerebro y, por
consiguiente, el conocimiento de otro agente para realizar un razonamiento, sin
necesidad que el dueño del cerebro implemente la habilidad correspondiente JavaLog
define tres predicados para efectuar comunicación directa entre distintos objetosagente:
present(Identificador): se utiliza para permitir que otros intérpretes soliciten la
evaluación de cláusulas en forma remota. El agente se registra con un identificador con
la siguiente sintaxis:
rcall(Service, Query): evalúa una consulta en el intérprete identificado por Service,
donde Service es un identificador de la forma:
Si la consulta que se ejecuta en el intérprete remoto es satisfactoria, la evaluación tiene
éxito. Si el host no se encuentra, el intérprete remoto no acepta invocaciones remotas, o
Query no es verdadero, entonces rcall falla.
rsolutions(Service, Query, Result): es similar a rcall salvo que solicita al intérprete
remoto que considere todas las posibles reevaluaciones de Query. Si la evaluación de
Query tiene éxito, la variable Result se instancia con todas las sustituciones posibles
que hacen que Query sea verdadero.
La utilización de estas primitivas permite la comunicación tanto de agentes
integrantes de una misma comunidad, como la comunicación entre agentes de
comunidades distintas. Es decir, es posible tener un grupo de agentes compartiendo
conocimiento mediante un blackboard donde uno o más de esos agentes tienen la
capacidad de comunicarse con agentes externos a su comunidad (que no conocen de la
existencia del blackboard). Por medio del envío de mensajes a agentes remotos, este
agente externo puede, indirectamente, utilizar el conocimiento del agente con el que se
comunica. Este agente, al ser parte de la comunidad del blackboard utiliza en su
razonamiento el contenido del mismo. La figura A.3 muestra un sistema de múltiples
comunidades de agentes compartiendo conocimiento y la comunicación
intercomunidad dada a partir de la comunicación entre pares de agentes.
93
JavaLog
Figura A.3: Sistema de múltiples comunidades de agentes
Así, por ejemplo, la figura A.4 muestra al agente comerciante que intenta
comprar algunos elementos en un repositorio de artículos. Este repositorio contiene
ofertas publicadas por varios agentes vendedores en forma de módulos lógicos.
Figura A.4: Interacción entre agentes
La administración del repositorio está en manos de un agente intermediario.
Cuando el agente comerciante se comunica con el coordinador, le realiza una consulta
de la forma:
rcall( //blackboardManager, article(Type, Offer)).
Luego, el intermediario ejecuta la consulta en su base de conocimiento (el blackboard)
e instancia la variable Offer con el resultado de su búsqueda. A partir de este resultado,
el agente comerciante lo compara con sus preferencias y decide la compra. En esta
consulta al coordinador, el agente podría utilizar la primitiva rsolutions:
rsolutions( //blackboard, article(Type, _ ), ListOfOffers)
94
JavaLog
De esta forma, el agente comerciante obtiene un conjunto de artículos que
satisfacen la consulta. Luego, debe elegir de acuerdo a sus preferencias, cuál es la más
apropiada.
95
Glosario de Términos
Agente móvil: Entidad autónoma con capacidades comportamentales y con un
conocimiento interno. Se lo puede definir como un componente de software
(programa) activo que percibe, razona, se comunica y tiene la capacidad de migrar de
un sitio a otro.
Broker: Funciona como intermediario, permitiendo la comunicación entre diferentes
componentes de software distribuidos en una red.
Código en demanda: Paradigma de redes de computación. El cliente posee los
recursos necesarios para la ejecución de un servicio, pero no sabe como usarlos para
realizar dicho servicio. El código es obtenido de un servidor remoto. Este esquema es
utilizado por los applets o por el mecanismo de pasaje de parámetros de RMI (en Java).
CORBA: “Common Object Request Broker Architecture” es una arquitectura y
especificación para crear, distribuir y administrar objetos distribuidos en una red.
Permite que programas en diferentes lugares de la red se comuniquen en una red a
través de una interfase común.
DCOM (Distributed Component Object Model): Es un conjunto de interfaces en las
cuales los objetos del programa cliente puede pedir servicios de programas servidores
en otras computadoras dentro de una red. DCOM es generalmente equivalente a
CORBA en cuanto a que provee un conjunto de servicios distribuidos.
Espacio de datos (o estado): Es el conjunto de asociaciones de los recursos que están
siendo compartidos con otros agentes. En la mayoría de las implementaciones de Java,
esta constituido por los objetos asociados al agente.
Estado de ejecución: El control y los datos
ejecución.
internos asociados a la unidad de
Evaluación remota: Paradigma de redes de computación. El cliente tiene conoce
como realizar el servicio, pero carece de los recursos necesarios, los cuales tiene el
servidor. Luego de recibir el código en el servidor, la interacción procede como en el
paradigma cliente-servidor, con el código accediendo a los recursos, ahora locales, y
enviando los resultados de vuelta al cte.. Ejemplos: shells remotos y servidores SQL.
Groupware: Se refiere a los programas que ayudan a la gente a trabajar
colaborativamente mientras que pueden encontrarse físicamente apartadas entre ellas.
Linkeo remoto dinámico (remote dynamic linking): Es la habilidad de resolver el
nombre de una clase en tiempo de ejecución recuperando el bytecode de un nodo
remoto y linkeándolo en el nodo local. Esta técnica está soportada por Java por el
hecho de que el class loader es programable.
Marshalling: Proceso de reunir datos de una o más aplicaciones en un mensaje y,
organizar y convertirlos a un formato apropiado para el receptor del mensaje. Es
usualmente requerido para el intercambio de mensajes entre aplicaciones escritas en
diferentes lenguajes y/o corriendo en plataformas cuya representación interna de los
datos es diferente entre sí.
Migración débil: Los sistemas que soportan movilidad débil permiten la transferencia
de código de aplicación de o hacia un sitio diferente. En el destino, el código puede ser
corrido en una nueva unidad de ejecución o puede ser ligado a una existente. Comienza
su ejecución desde el principio.
Migración fuerte: Los sistemas que soportan movilidad fuerte permiten a una unidad
de ejecución moverse como un todo, reteniendo su estado de ejecución. La migración
es transparente, en el sentido de que la unidad de ejecución continúa en el nuevo sitio
en la instrucción siguiente a la que disparó la migración.
ORB (Object Request Broker): Es la lógica que actúa de intermediario entre un
pedido del cliente de un servicio y la respuesta de dicho servicio.
RMI (Remote Method Invocation): Se podría ver como la versión Java de RPC.
RPC (Remote Procedure Call): Llamado a Procedimiento Remoto es un protocolo
que un programa puede usar para pedir un servicio a un programa ubicado en otra
computadora. RPC utiliza el modelo cliente / servidor; el programa que pide el servicio
es el cliente y el programa que provee el servicio es el servidor. Al igual que un
llamado a una función local, RPC es una operación síncrona.
Sistemas Middleware: Un Sistema Middleware es software que conecta dos
aplicaciones separadas. El término middleware es usado para describir productos
separados que sirven como pegamento entre dos aplicaciones.
97
Stub: Es un programa pequeño que sustituye a uno más grande, para que sea
posiblemente cargado más tarde o que esté ubicado en un sitio remoto.
Unidad de ejecución: Las unidades de ejecución representan flujos de computación.
Los ejemplos típicos son procesos de un solo thread o threads individuales de un
proceso con múltiples threads.
Workflow: Es un termino usado para describir las tareas, pasos, organizaciones o
personas involucradas, información de entrada y de salida, y las herramientas
necesarias en cada paso de un proceso de negocios.
98
Referencias Bibliográficas
[AdAstra 99]
AdAstra Engineering, Inc. “Jumping Beans white paper”
http://www.JumpingBeans.com , 1999.
[Amandi et al. 99]
A. Amandi, A. Zunino, R. Iturregui. Multi-paradigm Languages Supporting Multi-Agent
Development. Multi-Agent System Engineering, 9a European Workshop on Modelling
Autonomous Agents in a Multi-Agent World, MAAMAW'99, pp 128-139, 1999.
[Bellavista 99]
P. Bellavista and A. Corradi and C Stefanelli. A secure and open mobile agent
programming environment. The Fourth International Symposium on Autonomous
Decentralized Systems: Integration of Heterogeneous Systems, pp 238-245, 1999.
[Belloni-Campo 01] E. Belloni, M. Campo. BrainLets: Dynamic Inferential Capabilities for Agent-based
Web Systems. Revista Iberoamericana de Inteligencia Artificial. No. 13, pp 108-0114,
2001.
http://aepia.dsic.upv.es/revista/numeros/13/belloni.PDF
[Berners-Lee et al
98]
Tim Berners-Lee, Roy T. Fielding, Larry Masinter. Uniform Resource Identifiers
(URI): Generic Syntax and Semantics, RFC 2396, 1998.
[BNF 02]
def. Bakus Nour Form
[Box 00]
D.Box et al.. “Simple Object Access Protocol (SOAP) 1.1”. W3C Note May 2000
http:///www.w3.org/TR/SOAP.
[CAgents 99]
FTP Software, “CyberAgents”
http://wwwftp.com/cyberagents/
[Carriero-Gelernter
89]
D.Gelernter, P.Carriero, “Transactions in Linda”
Languajes Syst. 1989
[Chess 95]
David Chess, Benjamin Grosof, Colin Harrison, David Levine, Colin Paris, Gene
Tsudik. Itinerant Agents for Mobile Computing, IBM Research Report, RC 20010,
1995.
http://www.research.ibm.com/massdist/rc20010.ps
[Christensen 01]
E. Christensen et al. “Web Services Description Languaje (WSDL) 1.1”. W3C Note
March 2001.
http:///www.w3.org/TR/wsdl .
[Crocker et al 82]
Crocker, Vittal, Progran y Henderson. Standard for the format of ARPA internet text
mssages, RFC 822, 1982.
[Darmouth 88]
Darmouth College. “D’agents: mobile agents at Darmouth College”.
http://www.es.darmouth/edu/~agent/. 1988
[DeSchon, Braden
88]
A. DeSchon, R. Braden. Background File Transfer Protocol, RFC 1068, 1988.
[FIPA 97]
Foundation for Intelligent Physical Agents (FIPA), FIPA 97 Specification, Version 2.0,
Part2, Agent Communication Languaje , 1998.
http://wwwdrogo.cselt.stet.it/fipa/spec/fipa97/fipa97.htm.
[Freeman 96]
E.Freeman, “Linda group”, http://www.cd.yale.edu/HTML/YALE/CS/Linda/linda.html.
1996
en ACM Trans.Programming
[Fuggetta 98]
Alfonso Fuggetta and Gian Pietro Picco and Giovanni Vigna. Understanding Code
Mobility, IEEE Transactions on Software Engineering, Vol 24, No. 5, pp 342-361,
1998.
[Fukunaga 86]
K. Fukunaga, S.Hirose. ”An Experience with a Prolog-Based Object Oriented
Languaje”. Proc.OOPSLA’86 Conference. 1986.
[Gelernter 85]
D.Gelernter, “Generative communications in Linda” ACM Trans.Programming
Languajes Syst. Vol.7 nº1. 1985.
[Genesereth –
Ketchpel 94]
M.R.Genesereth, S.P.Ketchpel, ”Software Agents”, Communications of the ACM,
37(7):48-53. 1994
[Gral.Magic 95]
General Magic, Inc. Tabriz Ware, 1995
http://www.genmagic.com/Tabriz/.
[Gral.Magic 97]
General Magic, Inc. Odyssey Product Information, 1997
http://www.genmagic.com/agents/odyssey.html
[Gray 00]
Robert S. Gray, David Kotz, George Cybenko, Daniela Rus. “Mobile Agents:
Motivations and State-of-the-Art Systems”. Dartmouth College, Computer Science,
TR2000-365, 2000.
ftp://ftp.cs.dartmouth.edu/TR/TR2000-365.ps.Z
[Gray 95]
R.Gray, “Agent Tcl: a transportable agent system”, en Proc. CIKM Workshop Intell
Inform Agents (CIKM’95). 1995
[Hattori 99]
Fumio Hattori, Takeshi Ohguro, Makoto Yokoo, Shigeo Matsubara, Sen Yoshida.
“Socialware: multiagent systems for supporting network communities.”
Communications of the ACM, Vol 42, No. 3, pp 55-61, 1999.
http://www.acm.org:80/pubs/citations/journals/cacm/1999-42-3/p55-hattori/
[IBM 97]
IBM Research, IBM Aglets software development kit, “Technical Report home page,
Tokio Research Laboratory, Japan, 1997
http://www.ibm.co.jp/trl/aglets.
[IKV++ 98]
IKV++ GmbH, “GrassHopper, an intelligent mobile agent platform written in 100%
pure Java”, 1998.
[Ishikawa 86]
Y.Ishikawa, M.Tokoro. “ A Concurrent Object-Oriented Knowledge Representation
Languaje Orient84/K: It’s features and implementation”. SIGPLAN Notices, 21 (11):
232-241.. 1986
[Karnik - Tripathi
98]
N.Karnik, A.R.Tripathi. “Design Issues in Mobile Agent Programming Systems”. IEEE
Concurrency, Vol.6, nº3. 1998.
[Kotz 99]
Robert S. Gray, David Kotz, George Cybenko, Daniela Rus. Mobile Agents:
Motivations and State-of-the-Art Systems. Dartmouth College, Computer Science,
2000.
ftp://ftp.cs.dartmouth.edu/TR/TR2000-365.ps.Z
[Labrou - Finn 97]
Y.Labrou, T.Finn, “A Proposal for a New KQML Specification”. Technical Report CS97-03, Computer Science and Electrical Engineering Department, University of
Maryland, Baltimore 1997.
[LaForge et al. 98]
W.LaForge, D.Milojicic y D.Chauhan. “Mobile objects and agents, design,
implementation and lessons learned”. IEEE Vol.5. 1998
Danny B. Lange, Mitsuru Oshima. Programming and Deploying Mobile Agents with
Java Aglets. Addison-Wesley, pp xxiv + 225. isbn 0-201-32582-9. 1998.
[Lange 98]
[Lange 99]
Danny B. Lange, Mitsuru Oshima. Seven good reasons for mobile agents.
Communications of the ACM, Vol 42, No. 3, pp 88-89, 1999.
http://www.acm.org:80/pubs/citations/journals/cacm/1999-42-3/p88-lange/
[Lange-Oshima 98] D.Lange y M.Oshima. “Programming and Deploying Java Mobile Agents with Aglets.”
Adisson-Wesley, 1998
100
[Lingnau et al. 95]
A.Ligneau, O.Drobnik y P.Domel, “An HTTP-based infraestructure for mobile agents,
WWW J, (Fourth Int.WWW Conf.). Diciembre 1995
[Mello 86]
P.Mello, A.Natali. “Objects as Communicating Prolog Units”. En Proceedings of
ECOOP’87, European Conference on Object-Oriented Programming. 1987.
[Milojicic et al. 98]
D.Milojicic et al.”MASIF, the OMG mobile agent system interoperability facility” en
nd
Proc.2 Int. Worshop Mobile Agents, 1998.
Mitsubishi Electric ITA, “Concordia”
http://www.meita.com/HSL/Projects/Concordia. 1999.
[Mitsubishi 99]
[ObjectSpace 99]
ObjectSpace, Inc. “The ObjectSpace Voyager Universal ORB”
http://www.objectspace.com, 1999.
[Park-Leuker 97]
A.Park, S.Leuker, “A multi-agent architecture supporting services Accesses”, en
Mobile Agents’97, Lecture Notes in Computer Science 1219, Springer-Verlag, 1997.
[Rational 97]
UML Notation Guide, Rational Software, 1997, Rational Software.
[Rodrigues Silva et
al. 97]
A. Rodrigues Silva, M.Mira da Silva y J.Delgado. “A survey of web information
systems”. Proc. World Conference WWW, internet & intranet.(WebNet’97), Toronto,
Canadá, Noviembre de 1997.
[Rodrigues Silva et
al. 98]
A.Rodrigues Silva, M. Mira da Silva y J.Delgado, ”AgentSpace: an implementation of
a next-generation mobile agent system” en Proceedings of Mobile Agents ’98,
Stuttgart, Germany. Lecture Notes in Computer Science 1477, springer-Verlag. 1998
[Rumbaugh et al
99]
James Rumbaugh, Ivar Jacobson y Grady Booch. The Unified Modeling Language
Reference Manual, Addison-Wesley, First Edition, 1999.
[Shoham 97]
Yoav Shoham. An Overview of Agent-Oriented Programming. Software Agents, AAAI
Press / The MIT Press. pp 217-290, 1997.
[Strasser 96]
Strasser M., Baumann J., Hohl F., 1996. “Mole: A Java-based mobile object system”.
nd
Proc. 2 ECOOP Workshop Mobile Object System, Dpunkt.
[Strasser et al. 96]
M.Strasser, J.Baumann y F.Hohl, “Mole: A Java-based mobile object system” en
nd
Proc.2 ECOOP Workshop Mobile Object Syst. Dpunkt. 1996.
[UDD1 00]
UDD1 Consortium, “UDD1 Technical White Paper”. September 2000
http://www.udd1.org/.
[WHA 03]
http://whatis.com
[White 94]
J.White.”Telescript technology: The foundation for the electronic marketplace”.
Technical report, General Magic. Inc. 1994
[White 97]
J.White.”Telescript technology: An introduction to the language.” J.Bradshaw (ed).
Software Agentes. AAAI MIT Press 1997.
[White 98]
J.White, “Personal communication, 1998” en Mobility: Process, Computers and
agents. D.Milojicic, F.Douglis and R.Wheler (Eds) Addison-Wesley 1999.
[WM 05]
http://webmacro.org
[Wong 97]
Wong D., Paciorek N., Walsh T., DiCelie J., Young M., Peet B., 1997. “Concordia: An
infrastructurefot collaborating mobile agents”. Proc.First Int. Workshop on Mobile
Agents.
[Wong 99]
David Wong, Noemi Paciorek and Dana Moore. Java-based Mobile Agents.
Communications of the ACM, Vol 42 No 3, pp 92-102, 1999.
http://www.acm.org/pubs/articles/journals/cacm/1999-42-3/p92-wong/p92-wong.pdf
[Wong et al. 97]
D.Wong, N.Paciorek, T.Walsh, J.DiCelie, M.Young y B.Peet, “Concordia: An
infraestructure for collaborating mobile agents”, en Proc. First Int. Workshop on
Mobile Agents, 1997.
101
[Wooldridge 99]
M. Wooldridge. Intelligent Agents. Multiagent Systems, The MIT Press, 1999.
[Woolridge –
Jennings 95]
M.Woolridge, N.Jennings, “Intelligent agents: Theory and practice”. Knowle.
Eng.Rev. vol.10 nro.5. 1995
[XML 98]
World Wide Web Consortium, “Extensible markup languaje (XML)”
http://www.w3c.org/, 1998.
[Zunino 01]
Alejandro Zunino, Luis Berdún, Analía Amandi. JavaLog: un Lenguaje para la
Programación de Agentes. Revista Iberoamericana de Inteligencia Artificial, No. 13,
pp 94-99. sin 1337-3601. 2001.
[Zunino 99]
Zunino A., Iturregui R., Amandi A., ”Javalog: una integración de objetos y lógica para
la programación de agentes”. Instituto ISISTAN, Universidad Nacional del Centro de
la Pcia. de Bs. As. 1999.
102

LogicRaptors - ktulu.com.ar

Transcripción

Documentos relacionados

Pseudocódigo, algoritmo, programación