Agentes Móviles en Internet - Aglets SDK (I) (ES)

Overview

• ¿Qué es un Agente Móvil Autónomo?
• Arquitectura genérica de una plataforma para AMAs
• Agentes Móviles Autónomos y seguridad
• ¿…pero sirven para algo útil?
• Conclusiones

This is the first of a 3 articles serie. See the 2nd an 3rd part.

---

El concepto de Agente Móvil Autónomo es fascinante a la vez que temible: código capaz de autoenviarse a voluntad hasta alcanzar el objetivo de la tarea que se le fue encomendada…, reconozco que suena a virus asesino, sí, pero muere primero el ignorante asustado que el precavido informado. En esta serie intentaremos mostrar que son mucho más fascinantes que temibles, que en ocasiones el malo no es el que llega sino el que espera la llegada, y que pese a lo que nos digan, en casa de uno sólo entra quien uno quiere.

Como ya avanzábamos en la entradilla, en esta pequeña serie de artículos vamos a hablar de agentes móviles autónomos en general, y de la implementación sobre la plataforma Java que de ellos ha realizado IMB Japón: Aglets ¹.

El objetivo de la serie es presentar al lector el paradigma de agentes móviles como una alternativa muy prometedora dentro del marco de la computación distribuida y construcción de sistemas complejos a partir de comportamientos sociales sencillos. Pero menos verborrea y entremos en materia…

¿Qué es un Agente Móvil Autónomo?

Como veremos más tarde, un AMA (Agente Móvil Autónomo) es un tipo especial de agente con capacidad para desplazarse por una red y de decidir su destino final.

Pero para comprender adecuadamente la parte (Agente Móvil Autónomo), describiremos primero el todo (Agente). Un agente es un programa informático específicamente diseñado para realizar una tarea bien definida, con una interacción mínima con el usuario, y un diseño tal que nos permita interpretarlo como una entidad independiente y capaz. El cuadro CARACTERÍSTICAS TÍPICAS DE UN AGENTE muestra algunas de las características más habituales que podemos hallar en los agentes.

La idea intuitiva de un agente es la de un programa que hace algo por nosotros, esto es, que dada una mínima orientación por nuestra parte, lleva a cabo una tarea de nuestro interés.

El ayudante de Office 97 es un ejemplo familiar de agente. Lo percibimos como una entidad en sí mismo, como un sirviente o colaborador dispuesto a ayudarnos a encontrar la información que buscamos. Su diseño ‘inteligente’, otra característica posible de los agentes, así como la iconografía empleada (asociación del ayudante, por ejemplo, con un simpático clip) logran que la ilusión de entidad independiente y capaz se multiplique. Por supuesto, no deja de ser un programa, pero la percepción del mismo como entidad útil capaz de realizar tareas por nosotros lo convierten en una herramienta de la que ya no queremos prescindir. Antes del asistente teníamos un motor de búsqueda; ahora tenemos un trabajador especializado a nuestra entera disposición.

Si a estas alturas el lector no ha comenzado a entender el cambio conceptual al que nos conduce el uso masivo de agentes, es que es incapaz de valorar el trabajo de miles de trabajadores especialistas dispuestos a trabajar sin desfallecer por nosotros. O tal vez debería seguir leyendo, y ver si de todo esto sale algo bueno.

Pero acotemos un poco más; pasemos de agentes a agentes móviles. Un agente móvil es un agente sobre el que podemos realizar las siguientes operaciones: podemos detener su ejecución, almacenar su estado en un medio permanente, enviarlo (código y estado) a través de una red, recuperar su estado en el nuevo host, y proseguir su ejecución en el punto en el que se dejó. Esto puede ser interesante, por ejemplo, en el siguiente marco. Imaginemos una red interna a un grupo de investigación que dispone de una infraestructura de agentes móviles para optimizar los recursos de cómputo de sus 10 ordenadores más potentes. Los agentes realizan tareas de todo tipo: desde gestionar listas automáticas de e-mails hasta realizar cálculos costosos por pedido (registrando el consumo, para facturar después). Con el fin de optimizar la capacidad de computación de los 10 ordenadores, el gestor de agentes móviles traslada agentes a los ordenadores menos cargados en un momento dado. Se logra así un mejor aprovechamiento de los recursos y se minimiza el tiempo de cómputo al paralelizar las tareas más costosas.

Finalmente, si seguimos acotando, llegamos a los Agentes Móviles Autónomos (AMA en lo sucesivo). Un AMA es un agente móvil programado para saltar a otro host cuando lo considere oportuno (ver Figura A). Un AMA puede desear saltar a otro host por diferentes razones, que van desde haber terminado su tarea en él y querer autoenviarse al siguiente en el itinerario, hasta autoenviarse a cualquier host activo porque recibe una notificación de que el que ocupa actualmente va a desconectarse.

Como vemos, los AMA son un tipo de agente muy especial y, por tanto, requiere de una plataforma muy específica.

Afortunadamente, aunque la implementación final es variada, podemos definir con bastante claridad los aspectos generales de estas plataformas (o soporte) para trabajar con AMAs. Veremos que esto nos despeja muchas dudas.

Arquitectura genérica de una plataforma para AMAs

Cualquier arquitectura de soporte para AMAs, dispondrá de los siguientes elementos:

• AMAs
• Aplicación HOST para AMAs
• Interfaz AMA/HOST
• Subsistema de seguridad
• Subsistema de serialización/deserialización
• Protocolo de transporte de AMAs

La implementación final puede ser muy variada, pero la estructura básica es siempre la misma. Vamos a tratar de explicar claramente cómo se combinan estos elementos para dar soporte a los AMAs.

Ya conocemos a los Agentes Móviles Autónomos, por lo que hablaremos primero de la aplicación HOST para AMAs (cuando hablemos de Aglets más adelante en la serie, a esta aplicación le llamaremos “contexto”). La aplicación HOST, que asumiremos que corre en su propio subproceso de ejecución, es la encargada de gestionar el hospedaje, la seguridad y el transporte de los AMA. Deberá ser capaz de crear, eliminar, enviar y recibir AMAs de forma automática y en un entorno seguro para el administrador del sistema o usuario. Nada impide que un ordenador tenga dos o más aplicaciones HOST.

El interfaz AMA/HOST es el mecanismo de comunicación entre el AMA y la aplicación HOST. Gracias a él, el AMA puede solicitar ser enviado a otra aplicación HOST (ya sea en el mismo ordenador o en otro distinto), crear AMAs hijo, autodestruirse, etc.

El subsistema de seguridad provee mecanismos para que la ejecución de AMAs no fiables o desconocidos no pongan en peligro al sistema. Como veremos más adelante, la arquitectura debe contemplar no sólo la seguridad contra AMAs no fiables sino también contra aplicaciones HOST maliciosas.

El subsistema de serialización/deserialización se encarga de convertir el AMA (código+estado) en una secuencia binaria susceptible de ser transferida por una red, así como de crear un AMA a partir de dichas secuencias.

Finalmente, el protocolo de transporte es el protocolo de negociación entre aplicaciones HOST para transferirse AMAs entre sí.

Para tener una visualización clara, todo junto queda más o menos como se narra en el cuadro ARQUITECTURA DE SOPORTE PARA AMAs. El ejemplo está sacado de una de las primeras pruebas que podemos hacer con el Aglets SDK.

Dadas las exigentes medidas de seguridad, y su carácter multiplataforma intrínseco, las arquitecturas de agentes móviles tienen en su núcleo algún tipo de máquina virtual que interpreta el código de los agentes; Java, por tanto, facilita el diseño de éstas enormemente. No en vano, aunque algunas plataformas poseen su propia M.V. de propósito específico, la gran mayoría están construidas sobre Java.

Agentes Móviles Autónomos y seguridad

Tras leer el escenario presentado en el cuadro ARQUITECTURA DE SOPORTE PARA AMAs, podemos llegar fácilmente a las siguientes conclusiones relativas a la seguridad que ofrece trabajar con Agentes Móviles Autónomos:

• Sin una aplicación HOST que espere y gestione la llegada de AMAs, jamás entrará ninguno en nuestro ordenador (ver Figura B). En casa de uno sólo entra quien uno quiere. Así que nada de desenchufar el modem para que no nos infecte algún agente del tipo Constipado, ¿está claro?

• El sistema de seguridad contra AMAs maliciosos será tan bueno como capaz sea la aplicación HOST de limitar los privilegios de acceso a recursos de los agentes que le lleguen.

• Tan malo es un AMA mala leche, como un HOST que se dedique a alterar el código y/o el estado de honrados y útiles AMAs. En ocasiones el malo no es el que llega, sino el que espera la llegada.

El elemento clave de la seguridad es, como vemos, encerrar el código ejecutable del AMA en una región aislada y segura, y limitar después sus accesos a los recursos del sistema (disco, pantalla, red…).

Puede que algún lector se esté preguntando cómo puede entonces hacer algo útil un agente, si llega a un host que le limita todo tipo de acciones. La respuesta es simple si pensamos en términos humanos: el agente deberá llegar a su destino, explorar y reconocer el entorno, y negociar con agentes locales que sí tengan privilegios para que éstos le suministren información o realicen las tareas que él quiere (ver Figura C). Para que se puedan efectuar estas interacciones, el HOST debe proporcionar algún medio de comunicación entre AMAs, así como distinguir entre agentes fiables (con privilegios) y no fiables (sin ellos).

Un ejemplo de todo esto, muy sencillo y fácil de diseñar, es un agente servidor de ficheros. Un agente que acuda al host en busca de un fichero, solicitará a nuestro agente servidor de ficheros acceder a tal o cual archivo. Siguiendo nuestras instrucciones, el agente local (con permiso de acceso, por ejemplo, al directorio /agentes/ftp y subdirectorios) responderá a las peticiones de navegación realizadas por el agente recién llegado. Podrá exigir un password, una clave de cifrado, o cualquier cosa que se nos ocurra.

¿…pero sirven para algo útil?

Esta sencilla pregunta, típica de jefes prácticos y usualmente respondida con un “todavía no hemos encontrado su aplicación adecuada, pero parece muy prometedor”, ha cortado centenares de “prometedoras” líneas de investigación.

Muy probablemente, el que imaginó seriamente por primera vez los AMAs (tal vez Jim White, ver ²) pensaba más en lo fascinante de tener código móvil con autonomía, que en resolver un problema software. Sin embargo, pasada la fascinación y la etapa inicial de investigación, los AMAs han encontrado su utilidad en diferentes áreas.

En primer lugar, tienen un importante campo de aplicación en arquitecturas cliente/servidor donde el número de transacciones entre múltiples clientes y el servidor son numerosas y el ancho de banda reducido. Cada transacción requiere de un tiempo para completarse y genera un tráfico en la red. Si los accesos al servidor se disparan, el rendimiento del conjunto puede caer en picado.

Una arquitectura basada en AMAs resuelve este problema trasladando un agente al servidor para que, una vez allí, realice localmente todas las transacciones que antes se hacían remotamente. Las ventajas son obvias: la red queda descargada para otras tareas, y, dado que el ancho de banda local es mucho mayor que el de la red, el tiempo en completar todas las transacciones es menor. Obviamente, para que todo esto funcione se deben cumplir ciertos requisitos.

A modo orientativo, podemos estimar el orden de magnitud del punto crítico en el cual la arquitectura basada en AMAs mejora a la tradicional cliente/servidor. Haciendo unos sencillos cálculos, encontraremos fácilmente un resultado que nos sorprenderá por su obviedad: el tiempo total disminuye (así como el ancho de banda consumido) cuando el tamaño del AMA transferido es inferior a la suma de tamaños de los paquetes intercambiados en las transacciones.

Los AMAs también resuelven bien ciertos problemas creados por conexiones poco fiables o intermitentes. Como ejemplo, cierto host podría enviar a un agente a realizar alguna tarea laboriosa o larga, y pasar a modo off-line (apagando el modem, por ejemplo). El agente, una vez finalizada la tarea, intentaría regresar al host origen. Al no poder, esperaría pacientemente, chequeando de tanto en tanto, a que su host origen despertase. Una vez éste pasara a modo on-line, el agente regresaría trayendo los resultados que le fueron solicitados.

El diseño de arquitecturas clásicas cliente/servidor se ve simplificado enormemente con el modelo de AMAs, pues cliente y servidor se pueden implementar como agentes con un sistema común de mensajería bien diseñado. El lector agudo detectará la enorme maleabilidad y extensibilidad a posteriori de este enfoque frente al tradicional.

Finalmente en esta lista (que sólo muestra la punta del iceberg, aún por descubrir), pero no por ello menos importante, los AMAs resuelven muy bien aquellos problemas en los que, por su complejidad, sea fácil definir el comportamiento de los elementos y sus relaciones, pero difícil o imposible modelizar el comportamiento global del conjunto. Pensemos, por ejemplo, en la enorme capacidad de una sociedad “hormiga” frente a una de sus integrantes.

Posiblemente, sea el comportamiento “social” de una arquitectura de AMAs el que mayores sorpresas (esperemos que positivas) nos de en el futuro. Donde antes teníamos objetos pasivos, a la espera de que se le pida ejecutar uno de sus métodos, ahora tendremos objetos activos, capaces de tomar decisiones por cuenta propia. Es este nuevo paradigma el que nos abre el camino hacia una computación distribuida y social donde, gracias al comportamiento de los agentes, el conjunto es infinitamente más que la suma de sus partes. La teoría de la complejidad juega aquí un papel de gran importancia.

Conclusiones

De todo lo que aquí se ha contado, deberían quedar muy claros los siguientes puntos:

• Los AMAs son útiles para ciertas tareas y bajo ciertas condiciones. Además, inician un nueva forma de pensar dentro del campo de la computación distribuida.

• Su potencial debe ser sopesado con los aspectos de seguridad.

• La seguridad será tan buena como queramos; podemos inicialmente limitar el acceso a todo, y dar sólo después permisos livianos o no problemáticos.

Muchos habrán notado que no hemos hablado todavía de los “Aglets”; no lo haremos hasta la próxima entrega de la serie.

El objetivo de esta primera entrega era únicamente (y si se ha conseguido, ya es un gran logro) el de despertar curiosidad entre los que desconocían los AMAs, y resolver algunas dudas entre los que ya los conocían.

Para aquellos que no puedan esperar a investigar sobre los AMAs, les recomiendo que acudan a la página principal de Aglets que se indica en la bibliografía. Para profundizar más en el mundo de los Agentes, nada mejor que la página principal de la Agent Society³. ObjectSpace proporciona una comparativa de las diferentes plataformas de AMAs existentes (aunque algo antigua) en su página principal⁴. Un abrazo, y hasta la próxima entrega.

---