IMPLEMENTACIÓN DE UN DISEÑO CON JADE Y JADE-S

En la sección precedente se presentó una breve descripción de las características y operación de Jade y Jade-S, en esta sección se establece una guía enfocada a la implementación de diseños obtenidos con la metodología propuesta en Jade y Jade-S.

El primer punto a tomar en cuenta es la correspondencia entre las abstracciones usadas en el diseño y aquellas presentes en Jade. El principal elemento de un diseño obtenido con la metodología propuesta es la clase de agente. En el modelo de agentes, una clase representa a un tipo de agente que existirá en el sistema y se definen los roles que dicho agente actuará. En Jade la clase Agent es la abstracción asociada al concepto de

agente y, de acuerdo a referencia, los agentes del sistema deberán extender a esta clase. Se puede establecer una correspondencia uno a uno entre clases de agentes en el modelo de agentes y subclases de la clase Agent en Jade, es decir que cada clase de agente

del modelo de agentes será implementada mediante una clase Java que extiende a la clase

Agent.

Las clases de agentes en el diseño detallado no representan la lógica del comportamiento de los agentes, la lógica está definida en los roles que el agente actúa. En Jade la clase Agent tampoco es la que permite la implementación de la lógica de las tareas

que realizan los agentes, para ello Jade propone la clase Behaviour (comportamiento), la

Jade deben tener una agenda de comportamientos a llevar a cabo, de igual manera que en el diseño detallado las clases de agentes tienen un conjunto de roles a actuar.

Entonces cada rol en el modelo final de roles se puede implementar mediante un comportamiento. Jade provee un conjunto de sub-clases de la clase Behaviour. Dichas

clases permiten implementar comportamientos comunes como por ejemplo, repetir una actividad indefinidamente (CyclicBehaviour) o realizarla una sola vez (OneShotBehaviour),

definir una secuencia de tareas a realizar de acuerdo a una máquina de estados (FSMBehaviour), responder a solicitudes hechas por otros agentes o hacer solicitudes a

otros agentes de acuerdo a protocolos comunes como Fipa-Request (AchieveREResponder

y AchieveREInitiator). Estas especializaciones de la clase Behaviour son las que deben ser

utilizadas para implementar los roles.

Sin embargo, cada rol tiene un conjunto de actividades y protocolos que realizar, cada uno de los cuales debe ser implementado. Los actividades pueden implementarse mediante métodos miembros de la clase (que extiende a Behaviour) que implementa al rol.

El modelo de servicios en el diseño detallado incluye a los protocolos, vistos desde el punto de vista de los agentes, en lugar del de los roles. Un protocolo representa una interacción entre dos roles, lo cual se puede implementar haciendo uso de las sub-clases de

Behaviour especializadas en la interacción. Ya que los roles representan la lógica del

comportamiento de los agentes, se puede decir que los protocolos representan la lógica de la interacción entre agentes. No pueden implementarse por separado los protocolos y los servicios, sino que su implementación debe ser la misma.

Entonces, tomando en cuenta que las responsabilidades de un rol (sus actividades y protocolos y su secuencia lógica) implican la realización de diversas tareas y que un rol es implementado mediante un comportamiento, se debe poner especial atención al tipo de comportamiento con el que se implementa un rol y hacer uso de la sub-clase adecuada de

Behaviour.

Las entradas y salidas de los protocolos pueden ser implementadas de diversas maneras, por ejemplo mediante simples cadenas de texto, mediante clases Java, mediante una ontología, etc. Sin importar la manera de implementar las entradas y salidas, la clase

Agent provee los mecanismos necesarios y suficientes para intercambiarlas durante la

interacción entre agentes.

Las entidades pasivas, u objetos, definidos en el diseño pueden ser implementadas mediante simples extensiones a la clase Object de Java.

Entonces, para implementar un diseño se pueden seguir los siguientes pasos:

1. Por cada clase de agente presente en el modelo de agentes, crear una especialización de la clase jade.core.Agent.

2. Por cada rol presente en el modelo final de roles, crear una especialización de una de las clases de comportamiento provistas por Jade. Por cada actividad asignada a dicho rol, crear en la clase un método que la implemente.

3. Por cada servicio en el modelo de servicios, crear una especialización de una de las clases de comunicación que provee Jade.

4. Por cada objeto presente en el modelo de comportamiento, crear una clase Java que lo implemente.

En cuanto a la seguridad, es necesario retomar los cuatro tipos de restricciones posibles en la metodología propuesta: genéricas, sobre acciones, sobre atributos y sobre interacciones.

Las restricciones sobre atributos indican, como su nombre lo dice, atributos que deberán poseer las entidades, ya sean activas o pasivas. La implementación de este tipo de restricciones es la más simple. Por cada restricción de este tipo sobre un objeto o rol, solo se deberá asegurar que dicho atributo esté presente en la clase Java que implementa al objeto o en la sub-clase de Agent que implementa al agente que actúa el rol.

Para las restricciones genéricas, sobre acciones y sobre interacciones, la implementación es más compleja y depende de la habilidad del desarrollador. Como se estableció en el capítulo 4, el universo de posibles restricciones es infinito, por lo tanto no es realista decir que todas las restricciones puedan ser implementadas de la misma manera o inclusive que puedan ser implementadas en Jade y Jade-S.

Como se mencionó anteriormente, Jade-S provee mecanismos de autenticación, autorización (basada en la autenticación), de privacidad en el intercambio de mensajes y de verificación de integridad. A continuación se describirá la manera de utilizar estos mecanismos para la implementación de restricciones sobre acciones e interacciones.

Los mecanismos de privacidad e integridad no tienen relevancia para las restricciones sobre la capacidad efectiva de las entidades, pero si los mecanismos de autenticación y autorización.

La capacidad efectiva de los agentes está enfocada a la modificación de los recursos presentes en el sistema ya sea generando, consumiendo o modificando los recursos. Desde el punto de vista de la implementación, la capacidad efectiva incluye la creación, modificación y eliminación de información, la cual puede estar presente en el sistema como archivos, estructuras de datos en memoria, bases de datos, servicios de sistema, etc.

Para otorgar a un agente el permiso para realizar una acción sobre un cierto recurso es necesario primero identificar la manera en que el recurso está implementado en el sistema. Si el recurso es un archivo, el permiso puede otorgarse al agente indicando de manera explícita que el código que implementa al agente tiene el permiso sobre el archivo en específico. Por ejemplo, si el archivo se llama recurso.txt, y el agente Agente1 tiene el permiso de escribir sobre el archivo, una política como la siguiente otorgaría el permiso de escritura.

grant codebase "file: <ruta>/Agente1.class" {

permission java.io.FilePermission “recurso.txt”, “write”; };

Si el recurso fuera una base de datos, el permiso podría otorgarse sobre la capacidad de conectarse a la base de datos a través de sockets (SocketPermission) o sobre la capacidad

Sin embargo, una parte importante de las restricciones sobre la capacidad efectiva de los agentes es la verificación de precondiciones y poscondiciones, lo cual no está soportado por el mecanismo de autorización de Jade-S. Por lo tanto, corresponde al desarrollador incluir en el código que implementa a la actividad la verificación de las precondiciones y poscondiciones. Lo mismo aplica a las restricciones sobre interacciones, pues no hay manera de verificar las precondiciones y poscondiciones.

En cuanto a las interacciones entre agentes, las restricciones en algunos casos incluirán condiciones que indiquen que solo una clase de agente puede iniciar o responder a una interacción, este tipo de restricción puede implementarse mediante un código similar al siguiente:

grant principal jade.security.Name “Agente1” {

permission java.io.MessagePermission “agent-name=Agente2”, “send-to”; };

Con este código, se otorga al agente Agente1 el permiso de enviar mensajes al agente Agente2 y con esto, solo Agente1 podrá interactuar con Agente2. Hay que tomar en cuenta que los permisos en Jade-S son explícitos, es decir que lo que no esté explícitamente permitido está por defecto prohibidas.

En cuanto a las restricciones genéricas, como se mencionó en el capítulo 4, son aquellas que no restringen acciones, interacciones o atributos, por lo cual el número de posibles restricciones de este tipo es infinito. Sin embargo, restricciones genéricas como las presentadas en el capítulo 5, por ejemplo la restricción 1 (contar con un mecanismo de verificación de integridad) o la 20 (garantizar la privacidad de la información intercambiada durante las interacciones) del modelo preliminar de restricciones mostrado en dicho capítulo, son implementadas por defecto al usar Jade-S.

Entonces, la implementación de un diseño obtenido mediante la metodología propuesta es un proceso complicado que depende de la habilidad del equipo de implementación. Las restricciones que conforman el diseño no pueden ser generalizadas y no se puede establecer una receta para su implementación.