Desarrollo de una aplicación de gestión de servicios turísticos sobre la plataforma THOMAS

Desarrollo de una aplicaci´on de gesti´on de servicios tur´ısticos para la plataforma THOMAS Ingenier´ıa Inform´atica Autor: Jaume Jord´an Prunera Directores: Dra. Estefan´ıa Argente Villaplana Dr. Vicente Juli´an Inglada Septiembre, 2009 2 ´ Indice general 1. Motivaci´on y Objetivos 15 1.1. Motivaci´on.................................. 15 1.2. Objetivos .................................. 17 1.3. Estructura del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2. Estado del Arte 19 2.1. Sistemas Multiagente Abiertos . . . . . . . . . . . . . . . . . . . . . . . 19 2.2. Servicios Web y Sistemas Multiagente . . . . . . . . . . . . . . . . . . . 23 3. THOMAS 27 3.1. Descripci´ongeneral............................. 27 3.2. Agente intermediario SF . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3. Agente intermediario OMS . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.4. Kernel de la plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.5. Implementaci´on de la plataforma THOMAS . . . . . . . . . . . . . . . 35 4. Dise˜no e Implementaci´on de la Aplicaci´on 39 4.1. CasodeEstudio............................... 39 4.1.1. Registro de un agente . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1.2. Registro de un proveedor de hoteles . . . . . . . . . . . . . . . . 46 4.1.3. Registro de un proceso . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.4. Registro de un cliente . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.5. Petici´on de servicio . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1.6. Creaci´on de una nueva unidad . . . . . . . . . . . . . . . . . . . 50 4.1.7. Creaci´on de nuevos roles . . . . . . . . . . . . . . . . . . . . . . 50 4.1.8. Expulsi´on de un agente . . . . . . . . . . . . . . . . . . . . . . . 51 4.1.9. Registro de una norma . . . . . . . . . . . . . . . . . . . . . . . 52 4.2. Implementaci´on del Sistema . . . . . . . . . . . . . . . . . . . . . . . . 53 3 4´ INDICE GENERAL 4.2.1. Interfaz Gr´afica de Usuario . . . . . . . . . . . . . . . . . . . . . 53 4.2.1.1. Interfaces para agentes, servicios y meta-servicios . . . 53 4.2.1.2. Visores del OMS y del SF . . . . . . . . . . . . . . . . 70 4.2.2. Implementaci´on de la Aplicaci´on . . . . . . . . . . . . . . . . . 72 4.2.2.1. Implementaci´on de los agentes y sus interfaces . . . . . 73 4.2.2.2. Implementaci´on de las comunicaciones . . . . . . . . . 74 4.2.2.3. Implementaci´on de los visores del OMS y del SF . . . 76 4.2.2.4. Implementaci´on de los servicios tur´ısticos . . . . . . . 78 4.3. Validaci´on de la plataforma THOMAS . . . . . . . . . . . . . . . . . . 80 4.3.1. Registro de los agentes como miembros de la plataforma THOMAS 80 4.3.2. Registro de proveedores y servicios . . . . . . . . . . . . . . . . 81 4.3.3. B´usqueda y utilizaci´on de servicios tur´ısticos . . . . . . . . . . . 85 4.3.4. Otros meta-servicios . . . . . . . . . . . . . . . . . . . . . . . . 89 4.3.5. Valoraci´onfinal........................... 94 5. Conclusiones y Trabajos Futuros 97 5.1. Conclusiones................................. 97 5.2. Trabajosfuturos .............................. 99 ´ Indice de figuras 3.1. Estructura general de la plataforma THOMAS . . . . . . . . . . . . . . 28 3.2. Estructura de la implementaci´on de la plataforma THOMAS . . . . . . 36 3.3. Interacci´on del SF con un agente cliente y los servicios web . . . . . . . 38 4.1. Estructura de la organizaci´on Travel Agency ............... 40 4.2. Notaci´on de los elementos utilizados en los diagramas . . . . . . . . . . 44 4.3. Escenario de registro de un agente . . . . . . . . . . . . . . . . . . . . . 45 4.4. Escenario de registro de un proveedor de hoteles . . . . . . . . . . . . . 46 4.5. Escenario de registro de un proceso . . . . . . . . . . . . . . . . . . . . 48 4.6. Escenario de registro de un cliente . . . . . . . . . . . . . . . . . . . . . 48 4.7. Escenario de petici´on de servicio . . . . . . . . . . . . . . . . . . . . . . 49 4.8. Escenario de registro de una nueva unidad . . . . . . . . . . . . . . . . 50 4.9. Escenario de registro de nuevos roles . . . . . . . . . . . . . . . . . . . 51 4.10. Escenario de expulsi´on de un agente malicioso . . . . . . . . . . . . . . 52 4.11. Escenario de registro de una norma . . . . . . . . . . . . . . . . . . . . 52 4.12. Interfaz gr´afica de usuario para agentes de tipo cliente . . . . . . . . . . 54 4.13. Interfaz gr´afica de usuario para agentes de tipo proveedor . . . . . . . . 54 4.14. Ejemplo de ventanas de ejecuci´on de servicios . . . . . . . . . . . . . . 55 4.15. Submen´u Register Services del submen´u Structural Services . . . . . . 56 4.16. Submen´u Deregister Services del submen´u Structural Services ..... 57 4.17. Submen´u Informative Services ....................... 57 4.18. Submen´u Dynamical Services ....................... 58 4.19. Submen´u Register Services ......................... 58 4.20. Submen´u Affordability Services ...................... 59 4.21. Submen´u Discovery Services ........................ 60 4.22. Ventana del servicio Acquire Role ..................... 61 4.23. Ventana del servicio Leave Role ...................... 61 5 6´ INDICE DE FIGURAS 4.24. Ventana informativa despu´es del ´exito de encontrar una implementaci´on del servicio Search Hotel con Get Process ................. 62 4.25. Interfaz de agentes de tipo cliente despu´es de buscar un servicio y proveedores ................................. 62 4.26. Ventana del servicio Search Hotel ..................... 64 4.27. Ventana del servicio Search Flight ..................... 64 4.28. Ventana del servicio Reserve Hotel .................... 64 4.29. Ventana del servicio Reserve Flight .................... 65 4.30. Ventana de advertencia de error de introducci´on, causada por tener el campo Country vac´ıo............................ 65 4.31. Ventana de advertencia de error de formato, causada por una incorrecci´on en el campo Category que debe ser un entero . . . . . . . . . . 66 4.32. Ventana de advertencia de error de formato, causada por una incorrecci´on en el campo Date que debe ser de tipo fecha (aaaa-mm-dd) . . 66 4.33. Ventana informativa despu´es del ´exito de la ejecuci´on del servicio Search Hotel ..................................... 66 4.34. Ventana informativa despu´es del ´exito de la ejecuci´on del servicio Reserve Hotel ................................ 66 4.35. Ventana de ejecuci´on del servicio Register Profile ............ 67 4.36. Ventana informativa despu´es del ´exito de la ejecuci´on del meta-servicio Register Profile ............................... 68 4.37. Ventana de ejecuci´on del meta-servicio Deregister Profile ........ 68 4.38. Ventana de aviso de que no hay ning´un perfil registrado . . . . . . . . . 68 4.39. Ventana de ejecuci´on del servicio Register Process ............ 69 4.40. Ventana informativa despu´es del ´exito de la ejecuci´on del meta-servicio Register Process ............................... 69 4.41. Ventana de aviso de que no hay ning´un proceso registrado . . . . . . . 70 4.42. Ventana de ejecuci´on del meta-servicio Remove Provider ........ 70 4.43. Visor del agente intermediario OMS . . . . . . . . . . . . . . . . . . . . 71 4.44. Visor del agente intermediario SF . . . . . . . . . . . . . . . . . . . . . 72 4.45. Visor del agente intermediario SF con perfiles y procesos consultados . 72 4.46. Agente cliente solicitando Acquire Role al inicio de la ejecuci´on . . . . . 81 4.47. Visor del agente intermediario OMS despu´es de que los agentes hayan adquirido el rol member en virtual ..................... 82 ´ INDICE DE FIGURAS 7 4.48. Visor del agente intermediario OMS despu´es de que el agente HotelProvider haya adquirido los roles Provider de la TravelAgency yHotelProvider de la HotelUnit .......................... 82 4.49. Mensaje de advertencia de necesidad de registrar un perfil antes que un proceso.................................... 83 4.50. Ventana de ejecuci´on del servicio Register Profile ............ 83 4.51. Visor del agente intermediario SF con un perfil registrado . . . . . . . . 84 4.52. Ventana de ejecuci´on del servicio Register Process ............ 84 4.53. Visor del agente intermediario SF con un perfil y un proceso registrados 84 4.54. Agente cliente despu´es de encontrar el servicio Search Hotel . . . . . . 85 4.55. Visor del agente intermediario OMS despu´es de que el agente Client haya adquirido los roles Customer de la TravelAgency yHotelCustomer de la HotelUnit ............................... 86 4.56. Agente cliente despu´es de obtener el proceso y el proveedor del servicio Search Hotel ................................. 87 4.57. Ventana del servicio Search Hotel ..................... 87 4.58. Ventana del agente Sniffer de JADE capturando los mensajes enviados entre el cliente y el proveedor HotelProvider ............... 88 4.59. Ventana informativa despu´es del ´exito de la ejecuci´on del servicio Search Hotel ..................................... 88 4.60. Ventana del meta-servicio Register Unit con los campos rellenados para registrar la unidad RestaurantUnit .................... 89 4.61. Visor del agente intermediario OMS despu´es de registrar la nueva unidad RestaurantUnit ............................... 90 4.62. Ventana del meta-servicio Register Role con los campos rellenados para registrar el rol RestaurantProvider ..................... 91 4.63. Visor del agente intermediario OMS despu´es de registrar el nuevo rol RestaurantProvider dentro de la unidad RestaurantUnit ......... 91 4.64. Ventana del meta-servicio Deregister Role con los campos rellenados para eliminar el rol RestaurantProvider .................. 92 4.65. Ventana del meta-servicio Deregister Unit con su ´unico campo rellenado para eliminar la unidad RestaurantUnit .................. 92 4.66. Ventana del meta-servicio Expulse con los campos rellenados para expulsar a un agente malicioso . . . . . . . . . . . . . . . . . . . . . . . 93 4.67. Ventana del meta-servicio Register Norm con los campos rellenados para registarunanuevanorma.......................... 94 8´ INDICE DE FIGURAS ´ Indice de tablas 3.1. Meta-servicios del agente intermediario SF . . . . . . . . . . . . . . . . 32 3.2. Meta-servicios del agente intermediario OMS . . . . . . . . . . . . . . . 34 3.3. Servicios del Kernel de la plataforma (PK) . . . . . . . . . . . . . . . . 35 4.1. Contenido inicial de la UnitList ...................... 41 4.2. Contenido inicial de la RoleList ...................... 41 4.3. Servicios de la organizaci´on Travel Agency, unidad HotelUnit . . . . . . 42 4.4. Servicios de la organizaci´on Travel Agency, unidad FlightUnit ..... 43 9 16 CAP´ ITULO 1. MOTIVACI ´ ON Y OBJETIVOS web es muy com´un. As´ı pues, la necesidad de un SMA abierto basado en organizaciones que cumpla con los requisitos de flexibilidad y escalabilidad inherentes a las nuevas tecnolog´ıas de la informaci´on, hace surgir la idea de fusionar los SMA con los servicios web. Dentro de esta nueva concepci´on de los SMA se encuentra la propuesta THOMAS [10] [3] [22], una plataforma recientemente desarrollada que ofrece una gran versatilidad para gestionar organizaciones virtuales con agentes provenientes de distintos contextos, y en la que se pueden crear y usar una gran diversidad de servicios web. El presente proyecto ha sido impulsado principalmente por la necesidad de validar la plataforma THOMAS. La creaci´on reciente de ´esta requiere la validaci´on de su funcionamiento. Para ello, es recomendable realizar distintas pruebas a dicha plataforma y desarrollar aplicaciones basadas en ella. Por otra parte, tambi´en es necesario disponer de ejemplos en los que se muestre el funcionamiento de la plataforma THOMAS. As´ı pues, este proyecto aporta una aplicaci´on de gesti´on de servicios tur´ısticos usando la plataforma. Con esta aplicaci´on se puede ejecutar un conjunto de escenarios aplicables al contexto de los servicios que ofrece la plataforma. Adem´as, en esta aplicaci´on se trabaja concretamente en la gesti´on de servicios tur´ısticos. Con ello se pretende mostrar una alternativa aplicable a la industria de las nuevas tecnolog´ıas de la informaci´on. 1.2. OBJETIVOS 17 1.2. Objetivos El principal objetivo de este proyecto es la creaci´on de una aplicaci´on de gesti´on de servicios tur´ısticos para la plataforma THOMAS. Para la consecuci´on de dicho objetivo, se desarrollar´an los siguientes sub-objetivos: Estudio de la plataforma THOMAS. An´alisis y comprensi´on del funcionamiento de la plataforma y del uso de sus meta-servicios. Tambi´en se investigar´a su implementaci´on con el fin de obtener los conocimientos necesarios para poder desarrollar la aplicaci´on de gesti´on de servicios tur´ısticos. Dise˜no de la aplicaci´on de gesti´on de servicios tur´ısticos. Se dise˜nar´an agentes proveedores y clientes de servicios relacionados con el turismo. Esto implica un dise˜no apropiado para la correcta ejecuci´on de los meta-servicios de la plataforma THOMAS y de los servicios de gesti´on tur´ıstica. Adem´as, se dise˜nar´a la interfaz adecuada para mostrar la informaci´on de la organizaci´on virtual, accediendo a los datos de inter´es del OMS y del SF. Implementaci´on de la aplicaci´on de gesti´on de servicios tur´ısticos. Se crear´an los agentes proveedores y clientes adaptados a la plataforma THOMAS y tambi´en su sistema de comunicaci´on con los agentes intermediarios OMS y SF utilizando las especificaciones de la plataforma. Adem´as se generar´an distintos servicios web adicionales pertenecientes al ´ambito tur´ıstico, que ser´an usados y prove´ıdos por los agentes desarrollados. Validaci´on de la plataforma THOMAS a trav´es de la aplicaci´on desarrollada. Se realizar´a mediante la ejecuci´on de distintos escenarios en los que se invocar´a un conjunto de servicios web, tanto de la plataforma como externos a ´esta referentes a la gesti´on tur´ıstica. 18 CAP´ ITULO 1. MOTIVACI ´ ON Y OBJETIVOS 1.3. Estructura del trabajo En esta secci´on se explica de forma resumida la estructuraci´on en cap´ıtulos de este trabajo. A parte de este cap´ıtulo de introducci´on, el resto de cap´ıtulos est´an organizados de la siguiente manera: En el cap´ıtulo 2 se explican los conceptos y caracter´ısticas de los SMA abiertos y se relacionan con los servicios web. En el cap´ıtulo 3 se introduce la plataforma THOMAS al lector, explicando sus componentes y aspectos te´oricos as´ı como las cuestiones de su implementaci´on. En el cap´ıtulo 4 se detalla el dise˜no y la implementaci´on de la aplicaci´on desarrollada. Primeramente se explica el caso de estudio sobre el que se basa la aplicaci´on de gesti´on de servicios tur´ısticos. A continuaci´on, se explica la interfaz gr´afica de usuario y los detalles de la implementaci´on del sistema. Finalmente, se realiza una validaci´on de la plataforma THOMAS y de la aplicaci´on desarrollada. En el cap´ıtulo 5 se muestran las conclusiones de este proyecto y los trabajos futuros. Cap´ıtulo 2 Estado del Arte En el campo de las nuevas tecnolog´ıas de la informaci´on, los sistemas multiagente (SMA) han adquirido mucho protagonismo por parte de una notable cantidad de proyectos de investigaci´on dedicados a dichos sistemas. Sus ventajas frente a otros tipos de sistemas software aportan importantes avances y nuevos paradigmas para la resoluci´on de problemas de forma distinta a los sistemas tradicionales. En este cap´ıtulo se introducir´an los conceptos de sistemas multiagente, agentes software y sistemas multiagente abiertos. Tambi´en se relacionar´an los servicios web con los sistemas multiagente dado el creciente inter´es en el uso combinado de ambas tecnolog´ıas. 2.1. Sistemas Multiagente Abiertos El concepto de sistema multiagente surgi´o a partir de la Inteligencia Artificial Distribuida [16]. Es necesario aclarar que aunque se tratan de sistemas distribuidos no son como los tradicionales. La principal diferencia entre ellos es que en un SMA cada agente persigue sus propios objetivos, en cambio, en un sistema distribuido cl´asico todos los nodos pretenden alcanzar un objetivo com´un. Por otra parte, en muchas ocasiones se considera los SMA una parte de la Inteligencia Artificial. Esto es debido a la gran relaci´on existente, ya que la Inteligencia Artificial pretende emular el comportamiento y razonamiento humano, y los SMA son la plataforma para simular sociedades mediante agentes software “inteligentes”. Por lo tanto, los SMA se pueden definir como un conjunto de agentes aut´onomos que 19 20 CAP´ ITULO 2. ESTADO DEL ARTE trabajan juntos para resolver problemas. Estos agentes tienen parte de la informaci´on o de la capacidad para resolver el problema en cuesti´on, por lo que la resoluci´on se debe realizar de forma cooperativa mediante alg´un tipo de comunicaci´on. Los datos suelen estar descentralizados y la computaci´on es as´ıncrona. Adem´as, los agentes pueden decidir las tareas a realizar y qui´en debe realizarlas. Tambi´en es necesario aclarar el concepto de agente software, ya que es la base de cualquier SMA. Sin embargo, no existe una definici´on concisa y aceptada ampliamente por la comunidad cient´ıfica. Una de las primeras definiciones bastante citada es: “un agente se define como una entidad cuyo estado es visto como un conjunto de componentes mentales, tales como creencias, capacidades, elecciones y acuerdos” [19]. Otra de las m´as citadas y un poco m´as actual es la siguiente: “un agente es un sistema inform´atico situado en un entorno y que es capaz de realizar acciones de forma aut´onoma para conseguir sus objetivos de dise˜no” [24]. Estas definiciones son un ejemplo de la discusi´on que supone el concepto de agente, sin embargo, la siguiente definici´on junto con las anteriores ayuda a comprender lo que significa un agente software: “El concepto de agente caracteriza a una entidad software con una arquitectura robusta y adaptable que puede funcionar en distintos entornos o plataformas computacionales y es capaz de realizar de forma inteligente y aut´onoma distintos objetivos intercambiando informaci´on con el entorno, o con otros agentes humanos o computacionales” [9]. Se puede encontrar informaci´on m´as detallada sobre la discusi´on acerca del concepto de agente en [14]. Los SMA ofrecen muchas ventajas frente a la utilizaci´on de otros tipos de tecnolog´ıa software. A continuaci´on se comentar´an algunas de ellas: Se trata de una tecnolog´ıa que incorpora aspectos de Ingenier´ıa del Software, Inteligencia Artificial y telecomunicaciones. Tienen menor coste ya que los agentes facilitan la reusabilidad y requieren menor tiempo de desarrollo que otros sistemas convencionales. Mejoran la funcionalidad y la calidad frente a los sistemas actuales, que son r´ıgidos e inestables. La flexibilidad y adaptabilidad de los SMA es mucho mayor. El mantenimiento se reduce al facilitar la transformaci´on y la evoluci´on. La funcionalidad puede ampliarse o cambiarse modificando el comportamiento, las 2.1. SISTEMAS MULTIAGENTE ABIERTOS 21 estrategias o los objetivos de los agentes. Tambi´en se pueden incluir nuevos agentes y nuevo conocimiento. Son f´acilmente integrables con otras tecnolog´ıas (web, bases de datos, etc.). Facilitan la tarea de los ingenieros porque pueden utilizarse patrones de agentes. Con lo cual, se puede prestar toda la atenci´on en definir el comportamiento del agente en vez de a la codificaci´on convencional. A pesar de la corta historia de los SMA, actualmente existen multitud de aplicaciones en distintos campos. En el ´ambito industrial su utilizaci´on ha sido muy amplia, as´ı pues, existen aplicaciones de control y planificaci´on de la fabricaci´on, dise˜no de productos, control de tr´afico a´ereo, gesti´on de electricidad, ubicaci´on de contenedores, control de l´ıneas de producci´on, etc. Adem´as, tambi´en hay aplicaciones en otros ´ambitos como la medicina, recuperaci´on de la informaci´on, comercio electr´onico y telecomunicaciones. Esto demuestra el inter´es generalizado en el uso de los SMA dadas las ventajas que ofrecen, y probablemente en los pr´oximos a˜nos su desarrollo y aplicaci´on ir´a en aumento. Desde los inicios de los SMA, se han desarrollado muchas plataformas para gestionar la interconexi´on y ejecuci´on de los agentes dentro de un sistema. La tendencia general de la mayor´ıa de las plataformas es seguir los est´andares FIPA1, aunque existen algunas que tienen su propia arquitectura de agentes. Dos de las plataformas m´as conocidas que siguen el est´andar FIPA son Java Agent DEvelopment2(JADE), desarrollada por CSELT S.p.A (actualmente Telecom Italia o TILab), y FIPA Open Source3(FIPA-OS), desarrollada por Nortel Networks. Otras plataformas tambi´en utilizadas en distintos ´ambitos son: ABLE4de IBM, Comtec5yAPRIL6. A continuaci´on se describir´a brevemente la plataforma JADE dada su amplia utilizaci´on y por ser la base de la plataforma THOMAS. JADE es una de las plataformas de SMA m´as conocidas y utilizadas en la actualidad. Como se ha comentado anteriormente, sigue el est´andar de FIPA y est´a desarro1http://www.fipa.org/ 2http://jade.tilab.com/ 3http://www.fipa.org/ 4http://www.alphaworks.ibm.com/tech/able 5http://ias.comtec.co.jp/ap/ 6http://www.nar.fujitsulabs.com/app/ 22 CAP´ ITULO 2. ESTADO DEL ARTE llada en lenguaje Java. Esta plataforma ofrece una librer´ıa para crear agentes que se pueden comunicar entre s´ı mediante el lenguaje FIPA-ACL (Agent Communication Language) y servicios est´andar de gesti´on de agentes FIPA. Tambi´en dispone de una interfaz gr´afica que permite gestionar directamente los agentes, enviar mensajes, monitorizar la ejecuci´on, etc. Adem´as, JADE proporciona un conjunto de agentes ya implementados que pueden ser utilizados para distintos objetivos y que est´an integrados en la plataforma: Directory Facilitator (DF): proporciona los servicios de directorio. Agent Management System (AMS): ejerce de supervisor de acceso y uso de la plataforma. Proporciona un servicio de p´aginas blancas y de ciclo de vida, manteniendo una lista de los identificadores de los agentes (AID) y su estado. Agente Sniffer: es una herramienta que ayuda a la depuraci´on de las interacciones entre los agentes de la plataforma. La funci´on que realiza consiste en interceptar el flujo de mensajes entre los agentes y mostrarlos gr´aficamente para el usuario. Agente Introspector: permite el control del ciclo de vida de los agentes en ejecuci´on y los mensajes que intercambian. Para la implementaci´on de los agentes JADE se debe heredar la clase jade.core.Agent, la cual dispone de m´etodos para iniciar el agente, enviar y recibir mensajes, etc. Adem´as, la plataforma dispone de la clase jade.core.Behaviour que proporciona m´etodos para definir los comportamientos de los agentes. Por otra parte, los sistemas abiertos son aquellos que permiten la entrada de nuevos componentes durante la ejecuci´on del sistema que pueden no haber sido conocidos en la fase de dise˜no [11]. Por lo tanto, los agentes que participen en un sistema de este tipo pueden usar distintos protocolos o estar desarrollados con distintos lenguajes o arquitecturas. Esto proporciona mucha flexibilidad y heterogeneidad al sistema. No obstante, independientemente del dise˜no o desarrollo que haya tenido un componente, se unir´a al sistema adquiriendo un determinado rol para el cual se habr´an establecido un conjunto de normas y permisos que regulen su comportamiento. Los SMA abiertos permiten trabajar en entornos din´amicos en los que los agentes pueden entrar o abandonar el sistema de forma continua [25]. As´ı pues, en la fase de 2.2. SERVICIOS WEB Y SISTEMAS MULTIAGENTE 23 dise˜no no se puede saber cu´antos agentes estar´an presentes en el sistema. Por lo tanto, para el dise˜no se debe considerar esta dinamicidad y tambi´en la heterogeneidad de los distintos agentes que pueden entrar en la organizaci´on. A consecuencia de esto, es necesario establecer control y seguridad ya que pueden entrar agentes poco fiables o con objetivos contrarios a la organizaci´on. Otra parte muy compleja de los SMA abiertos es el desarrollo de las comunicaciones, debido principalmente a la heterogeneidad de los componentes que pueden entrar en el sistema. Se pueden encontrar ejemplos de SMA abiertos como las aplicaciones de e-commerce y los sistemas de agentes de informaci´on [6]. En estos casos, los agentes adoptan temporalmente roles de comprador o de tipos similares. Tambi´en existen algunos trabajos que abordan la problem´atica de los sistemas abiertos mediante la utilizaci´on de agentes internos que representan a los agentes externos que solicitan participar en la organizaci´on [8]. Con lo cual, los agentes externos no participan de forma directa en la organizaci´on y as´ı se pueden evitar muchos problemas de seguridad y de control. 2.2. Servicios Web y Sistemas Multiagente A consecuencia del espectacular crecimiento de Internet han surgido nuevas tecnolog´ıas como los servicios web, los cuales ofrecen distintas funcionalidades aplicables a muchos campos de la computaci´on. Los servicios web se pueden definir como un conjunto de tecnolog´ıas, protocolos y est´andares combinados para interoperar en la web o intercambiar datos entre aplicaciones. Tambi´en pueden ser definidos, desde otro punto de vista [14], como aplicaciones auto-contenidas y modulares que pueden ser descritas, publicadas, localizadas e invocadas en una red, normalmente la web. Para los servicios web existen distintas especificaciones est´andar, algunas frecuentemente usadas son: SOAP (Simple Object Access Protocol) como protocolo de comunicaci´on, WSDL (Web Service Description Language) como lenguaje de descripci´on de servicios, y UDDI (Universal Discovery Description and Integration) como directorio para registro de descripciones de servicios. Los lenguajes de descripci´on de servicios m´as utilizados actualmente son WSDL y OWL-S. A continuaci´on se comentan algunos detalles de ambos lenguajes. El lenguaje WSDL [4] est´a basado en XML y ha sido desarrollado por IBM y Mi- 24 CAP´ ITULO 2. ESTADO DEL ARTE crosoft para describir servicios web. Este lenguaje intenta separar los servicios de los formatos de datos y de los protocolos concretos que se utilicen en la implementaci´on. As´ı pues, define asociaciones entre las descripciones abstractas y sus implementaciones espec´ıficas. Sin embargo, WSDL no permite descripciones sem´anticas ya que se centra m´as en los mappings de los servicios. Adem´as, aunque incluye tipos de entrada y salida, no soporta definici´on de restricciones. Por lo tanto, al tener esta falta de expresividad su uso m´as adecuado es la descripci´on del acceso a los servicios. OWL-S [7] es un lenguaje de ontolog´ıas basado en XML. En concreto es una ontolog´ıa en OWL para describir servicios web. La intenci´on de OWL-S consiste en hacer interpretables los servicios web por parte de los programas. Esto supone una descripci´on del servicio web con informaci´on suficiente para que de forma automatizada se puedan descubrir, invocar, componer y monitorizar la ejecuci´on de servicios. Al ser una ontolog´ıa OWL, este lenguaje tiene las aportaciones de los contenidos web descritos en OWL. Concretamente tiene una sem´antica bien definida, con lo que permite definir objetos y relaciones entre ellos, incluyendo clase, relaciones de subclase, restricciones de cardinalidad, etc. Adem´as, incluye el formato de tipos de XML. La ontolog´ıa tiene como elemento principal la clase Service y consta de tres partes o sub-ontolog´ıas: ServiceProfile: describe qu´e hace el servicio. Es como una entrada de p´aginas amarillas para un servicio. Especifica la funcionalidad que proporciona, las entradas y salidas; y las precondiciones y efectos. ServiceModel: especifica el modelo de procesos del servicio, es decir, c´omo se ejecuta. Su funci´on es facilitar la composici´on, ejecuci´on y monitorizaci´on autom´atica de servicios. ServiceGrounding: describe los detalles de c´omo se accede al servicio. Normalmente se especifica un protocolo de comunicaci´on, formatos de los mensajes y otros detalles de implementaci´on de las comunicaciones. Cabe destacar que un servicio s´olo puede tener un ServiceModel pero puede tener varios ServiceProfiles yServiceGroundings. En la actualidad, las arquitecturas orientadas a servicios ofrecen un marco ideal para aportar flexibilidad e independencia a los SMA abiertos. Adem´as, el ´area de la 2.2. SERVICIOS WEB Y SISTEMAS MULTIAGENTE 25 computaci´on orientada a servicios y los SMA se est´an acercando cada vez m´as. Desde el punto de vista de los servicios web, ´estos pueden ser una buena soluci´on para las tareas que se realicen cuando son necesitados de forma est´atica. El problema surge cuando aparece la necesidad de trabajar en un entorno cambiante donde aparecen nuevos servicios y deben ser descubiertos, compuestos o adaptados a diferentes ontolog´ıas. Este problema puede ser resuelto mediante la combinaci´on de los servicios web y los SMA, ya que estos ´ultimos ofrecen inteligencia y capacidad organizativa, adem´as de la automatizaci´on del descubrimiento y composici´on de servicios. Por lo tanto, como ya se ha comentado, los SMA y la computaci´on orientada a servicios se adaptan perfectamente debido al uso de ontolog´ıas, modelos de proceso, coreograf´ıa y directorios de descripciones. La idea de integrar organizaciones y agentes como proveedores de servicios ya ha sido estudiada por diversos grupos de investigaci´on. La causa de esto es el creciente inter´es de la industria en el uso de servicios web est´andar para crear sistemas complejos y reutilizables. As´ı pues, el principal esfuerzo se concentra en integrar los agentes con los servicios web permitiendo redirecci´on, agregaci´on, integraci´on o prop´ositos administrativos en los servicios [12]. En base a esta idea existen dos lineas de investigaci´on: integraci´on directa de servicios web y agentes mediante intercambio de mensajes, y la consideraci´on de agentes como matchmakers para descubrimiento y composici´on de servicios. Un matchmaker [14] es un agente que empareja solicitantes de servicios con proveedores mediante la equiparaci´on de solicitudes con servicios anunciados por agentes. A diferencia de los mediadores y brokers, un matchmaker simplemente devuelve una lista (valorada) ordenada de agentes que proporcionan el servicio solicitado. La integraci´on directa de servicios web y agentes se ha estudiado desde tres puntos de vista distintos: Utilizaci´on de entidades intermediarias entre los agentes y los servicios web. Dentro de esta linea se encuentran la arquitectura Web Service Integration Gateway Service (WSIG) [13] y AgentWeb Gateway [18]. Agentes con interfaz de comunicaci´on directa con los servicios web. Con este 32 CAP´ ITULO 3. THOMAS Tipo Meta-servicio Descripci´on RegisterProfile Crea una nueva descripci´on de servicio (perfil) RegisterProcess Crea una implementaci´on particular (proceso) para un servicio Registro ModifyProfile Modifica un perfil de servicio existente MofifyProcess Modifica un proceso de servicio existente DeregisterProfile Elimina una descripci´on de servicio Alcance RemoveProvider Elimina un proveedor de un proceso de servicio SearchService Busca un servicio (o composici´on de servicios) que satisface los requisitos del usuario Descubrimiento GetProfile Obtiene la descripci´on (perfil) de un servicio espec´ıfico GetProcess Obtiene la implementaci´on (proceso) de un servicio espec´ıfico Tabla 3.1: Meta-servicios del agente intermediario SF los componentes estructurales (roles, unidades y normas) y de los componentes de ejecuci´on (agentes participantes, roles que ´estos juegan y unidades organizativas activas). Las organizaciones est´an estructuradas mediante unidades organizativas que representan grupos de entidades (agentes u otras unidades). Los componentes que forman una unidad persiguen un objetivo com´un. Las unidades organizativas tienen una topolog´ıa interna que impone control y restricciones a las relaciones entre los agentes. Existe una unidad llamada “virtual” en la plataforma THOMAS que ha sido definida para representar el “mundo” del sistema en el que los agentes participan por defecto. Las organizaciones son creadas dentro de esta unidad y ´estas, a su vez, pueden estar compuestas de m´as unidades. Cabe destacar que los roles se definen dentro de cada unidad y representan la funcionalidad requerida para alcanzar el objetivo de la unidad. Adem´as pueden tener normas asociadas para controlar las acciones de los roles (i.e. qu´e servicios pueden solicitar u ofrecer los agentes que est´an jugando un rol determinado; permisos para acceder a determinados recursos). En conclusi´on, los agentes pueden adoptar roles din´amicamente dentro de las unidades, con lo cual el OMS controla todo 3.4. KERNEL DE LA PLATAFORMA 33 este proceso y cu´ales son las entidades que juegan un rol en cada instante. El agente intermediario OMS usa la siguiente informaci´on: UnitList: guarda las unidades existentes junto con sus objetivos, topolog´ıa y unidad superior. RoleList: almacena la lista de roles en cada unidad y sus atributos (accesibilidad, visibilidad, posici´on y herencia). El atributo accesibilidad indica si un rol puede ser adoptado por un agente. Visibilidad indica si los agentes pueden obtener informaci´on sobre el rol. Posici´on concreta si es un supervisor, un subordinado o miembro de la unidad. La herencia indica el rol padre. NormList: guarda las normas definidas en el sistema. EntityPlayList: describe la asociaci´on <entidad,unidad,rol>. Es decir, qu´e roles han sido adoptados por una entidad (agente) dentro de cada unidad. Los servicios que ofrece el OMS se clasifican como estructurales y din´amicos. Los servicios estructurales son los que modifican la estructura y la normativa de la organizaci´on. Por su parte, los din´amicos permiten a los agentes entrar o abandonar la organizaci´on de forma din´amica, as´ı como la adopci´on de roles. Se puede observar un lista completa de los servicios del OMS en la tabla 3.2. 3.4. Kernel de la plataforma El Kernel de la plataforma es el encargado de proporcionar los servicios usuales requeridos en una plataforma multiagente. As´ı pues, es el responsable de gestionar el ciclo de vida de los agentes incluidos en las distintas organizaciones y tambi´en permite tener un canal de comunicaci´on para facilitar la interacci´on entre entidades. Adem´as, el Kernel tambi´en ofrece conectividad segura y los mecanismos necesarios para proporcionar interconectividad entre dispositivos. Los servicios ofrecidos deben ser heredados de FIPA con algunas modificaciones. Los servicios del Kernel necesitados en una infraestructura THOMAS se clasifican en cuatro tipos: (i) Registro: permiten a˜nadir, modificar y eliminar agentes nativos de la 34 CAP´ ITULO 3. THOMAS Tipo Subtipo Meta-servicio Descripci´on RegisterRole Crea un nuevo rol dentro de una unidad RegisterNorm Incluye una nueva norma dentro de una unidad Registro RegisterUnit Crea una nueva unidad dentro de una organizaci´on DeregisterRole Elimina un rol de una unidad DeregisterNorm Elimina una norma espec´ıfica DeregisterUnit Elimina una unidad de una organizaci´on Estructural InformAgentRole Indica los roles adoptados por un agente InformMembers Indica las entidades que son miembros de una unidad QuantityMembers Provee el n´umero de miembros actuales en una unidad Informaci´on InformUnit Provee la descripci´on de una unidad InformUnitRoles Indica los roles definidos dentro de una unidad InformRoleProfiles Indica los perfiles asociados a un rol InformRoleNorms Indica las normas dirigidas a un rol AcquireRole Solicita la adopci´on de un rol concreto dentro de una unidad Din´amico Compuesto LeaveRole Solicita el abandono de un rol Expulse Fuerza a un agente a abandonar un rol espec´ıfico Tabla 3.2: Meta-servicios del agente intermediario OMS 3.5. IMPLEMENTACI ´ ON DE LA PLATAFORMA THOMAS 35 Tipo Servicio Descripci´on Register Registra un nuevo agente en la plataforma Registro Deregister Elimina el registro de un agente Update register Modifica la informaci´on de un registro de agente Agent Search Solicita informaci´on sobre un agente registrado Descubrimiento Get Description Obtiene la descripci´on de la plataforma Suspend Suspende la ejecuci´on de un agente concreto Gesti´on Activation Activa la ejecuci´on de un agente concreto suspendido Comunicaci´on Send Env´ıa un mensaje a cualquier agente de la plataforma o de fuera de ella Tabla 3.3: Servicios del Kernel de la plataforma (PK) plataforma; (ii) Descubrimiento: servicios para obtener alguna informaci´on sobre los agentes activos de la plataforma; (iii) Gesti´on: servicios para controlar el estado de activaci´on de los agentes de la plataforma; (iv) Comunicaci´on: servicios para comunicar agentes en la plataforma y fuera de ella. La relaci´on completa de los servicios del Kernel se puede observar en la tabla 3.3. Puesto que la propuesta THOMAS no persigue desarrollar un nuevo kernel para plataformas multiagente, los servicios requeridos a nivel de kernel pueden ser proporcionados por distintas plataformas conocidas. As´ı pues, se debe elegir una plataforma que cumpla los servicios m´ınimos comentados anteriormente y adem´as tiene que ofrecer un mecanismo de comunicaci´on que proporcione compatibilidad con FIPA. La plataforma elegida por la propuesta THOMAS para facilitar todo esto es JADE. 3.5. Implementaci´on de la plataforma THOMAS El marco de ejecuci´on de THOMAS [22] est´a basado en JADE1(Java Agent DEvelopment Framework), que es una plataforma de c´odigo abierto y libre para el 1http://jade.tilab.com/ 36 CAP´ ITULO 3. THOMAS Figura 3.2: Estructura de la implementaci´on de la plataforma THOMAS desarrollo de sistemas multiagente, implementada completamente en lenguaje Java. JADE simplifica la creaci´on de sistemas multiagente ya que cumple con las especificaciones FIPA2(Foundation for Intelligent Physical Agents) y proporciona un conjunto de herramientas gr´aficas que ayudan en las fases de desarrollo y depuraci´on. Adem´as, la plataforma permite la distribuci´on entre distintas m´aquinas, incluso usando distintos sistemas operativos, y la configuraci´on puede ser controlada con una interfaz de usuario remota. Los servicios de THOMAS est´an implementados como servicios web sem´anticos. Se usa Apache Axis2/Java3como motor de los servicios web y cada servicio tiene una descripci´on sem´antica en OWL-S4[4] y su correspondiente en WSDL[7]. En el documento WSDL, las operaciones y los mensajes est´an descritos de forma abstracta y despu´es se concreta un protocolo de red y el formato de los mensajes. El documento OWL-S detalla las propiedades y capacidades de un servicio web de forma interpretable por el ordenador. Esta descripci´on facilita la automatizaci´on de las tareas del servicio web, incluyendo descubrimiento, ejecuci´on, composici´on e interoperabilidad. En la figura 3.2 se puede observar la estructura de la implementaci´on de la plataforma THOMAS. Todos los meta-servicios del SF y del OMS est´an registrados en el SF, y tambi´en 2http://www.fipa.org/ 3http://www.jaxmag.com/itr/online artikel/psecom,id,747,nodeid,147.html 4http://www.w3.org/Submission/2004/SUBM-OWL-S-20041122/ 3.5. IMPLEMENTACI ´ ON DE LA PLATAFORMA THOMAS 37 los servicios de agentes y organizaciones. Para cada servicio registrado en el SF deben existir dos documentos OWL-S, uno con la descripci´on del perfil y otro con la del proceso y el grounding. La raz´on de tener dos documentos es para evitar redundancia, ya que en el caso que exista m´as de un proveedor con distintas implementaciones, el servicio concreto tendr´ıa un “perfil” y varios “procesos” (uno por cada implementaci´on distinta). Los componentes OMS y SF est´an implementados como agentes JADE. La l´ogica de estos agentes se ha desarrollado usando la API OWL-S de Mindswap5, que a su vez, utiliza una API de Java para programar el acceso a la lectura, ejecuci´on y escritura de las descripciones de servicios OWL-S. Cuando el agente intermediario OMS o SF recibe un mensaje de petici´on FIPA de un cliente, utiliza la API OWL-S para acceder a la descripci´on del servicio en OWL y ejecuta el correspondiente servicio web. La ejecuci´on de un servicio implica el acceso a la informaci´on del proceso incluida en la descripci´on del servicio. El SF debe ser capaz de registrar y gestionar los servicios prove´ıdos por agentes externos. Para que estos servicios sean entendidos por una m´aquina, la informaci´on sem´antica se a˜nade con descripciones OWL-S y la ontolog´ıa especificada en OWL para los par´ametros. Para manejar toda la informaci´on sem´antica en OWL se usa JENA6. Entre otras cosas, JENA ofrece una interfaz para guardar la informaci´on de forma persistente en una base de datos. Adem´as, tambi´en se usa SPARQL7como lenguaje de consultas, con el cual se toma la descripci´on de lo que la aplicaci´on quiere, en forma de consulta, y se obtiene la informaci´on solicitada. En la figura 3.3 se puede observar la interacci´on entre el SF, un agente cliente y los servicios web. Como se ha comentado en la secci´on correspondiente al OMS, los meta-servicios que ofrece este componente de la plataforma se ocupan de la gesti´on de las organizaciones y tambi´en dispone de servicios informativos. La implementaci´on de estos meta-servicios considera el mantenimiento de la estructura organizativa y las normas que regulan el acceso. As´ı pues, cuando se hace una petici´on de un servicio al OMS el proceso seguido es el siguiente: 5http://www.mindswap.org/2004/owl-s/api/ 6http://jena.sourceforge.net/ontology/index.html 7http://www.w3.org/TR/rdf-sparql-query/ 38 CAP´ ITULO 3. THOMAS Apache Tomcat (Axis 2) SF Agent SF services: RegisterProfile RegisterProcess GetProfile GetProcess SearchService AddProvider ... Client Agent API OWL-S MindSwap Jade Jade OWL-S Service Descriptions MySQL database .war SPARQL JENA FIPA Request Protocol Figura 3.3: Interacci´on del SF con un agente cliente y los servicios web 1. Validaci´on de las entradas del meta-servicio. 2. An´alisis del contexto normativo para determinar si el agente cliente tiene una posici´on en la organizaci´on que le permita hacer la petici´on. 3. Si corresponde, el OMS provee el meta-servicio pedido. 4. Si el estado organizativo cambia como resultado del servicio ejecutado, se actualiza adecuadamente. Para la comprobaci´on de la compatibilidad del objetivo del meta-servicio que se ejecuta con las normas existentes, y para la actualizaci´on posterior a los cambios sobre la organizaci´on que puede provocar un meta-servicio, existen dos procesos. ´ Estos est´an implementados como servicios internos del OMS y son ejecutados por un proceso general de gesti´on de la normativa. Cap´ıtulo 4 Dise˜no e Implementaci´on de la Aplicaci´on En este cap´ıtulo se explicar´an detalladamente todos los aspectos de la aplicaci´on desarrollada. En primer lugar, se mostrar´an de forma te´orica las implicaciones de la ejecuci´on de los meta-servicios de la plataforma THOMAS y de los servicios tur´ısticos implementados. Todo ello por medio de posibles escenarios que se pueden presentar durante el funcionamiento de la aplicaci´on. Seguidamente, se explicar´a la implementaci´on del sistema desde el aspecto de la interfaz gr´afica de usuario y de los detalles de la implementaci´on de la aplicaci´on. As´ı pues, se comentar´a la interfaz gr´afica de usuario detallando los elementos por los que est´a formada y sus posibles usos. M´as adelante, se detallar´an aspectos t´ecnicos de la implementaci´on para poder tener una idea de c´omo se han desarrollado los procesos internos de la aplicaci´on a nivel de c´odigo fuente. Finalmente, se har´a una validaci´on de la plataforma THOMAS a trav´es de la aplicaci´on desarrollada, comprobando y mostrando al lector que efectivamente se pueden reproducir los escenarios y que se cumple el objetivo de ejecutar servicios de gesti´on tur´ıstica. 4.1. Caso de Estudio Con el objetivo de mostrar las funcionalidades de la plataforma THOMAS, se ha dise˜nado una aplicaci´on para gestionar servicios tur´ısticos. Esta aplicaci´on muestra un ejemplo de agencia de viajes donde existen clientes (particulares, empresas o agencias de viajes) y proveedores (cadenas de hoteles y compa˜n´ıas a´ereas). Con lo cual, los servicios que se pueden ofrecer y solicitar quedan acotados al sector tur´ıstico. Cada proveedor puede ofrecer los servicios libremente respetando las restricciones que im39 40 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.1: Estructura de la organizaci´on Travel Agency pone la plataforma. As´ı pues, es necesario crear una organizaci´on virtual llamada Travel Agency (que ser´a una unidad dentro de la unidad principal “virtual” de la plataforma) donde agrupar todos los roles relacionados con la agencia de viajes. En la organizaci´on Travel Agency hay tres roles disponibles: Customer,Provider yPayee. El rol Customer es el que solicita servicios, como b´usqueda y reserva de hoteles y vuelos, siendo el rol Provider el que ofrece estos servicios. El otro rol presente en la organizaci´on es Payee, el cual representa a una entidad financiera que se encarga de ofrecer un mecanismo de pago. Sin embargo, este es un rol interno de la organizaci´on y no se tiene en cuenta en la aplicaci´on desarrollada. Por otra parte, dentro de la organizaci´on Travel Agency hay dos unidades llamadas HotelUnit yFlightUnit, que est´an dedicadas a agrupar agentes interesados en ofrecer o solicitar servicios relacionados con hoteles y vuelos respectivamente. En este caso, dentro de HotelUnit existen dos roles, HotelCustomer y HotelProvider, que son una especializaci´on de los roles generales Customer yProvider de la Travel Agency. De la misma forma, en la unidad FlightUnit est´an presentes los roles FlightCustomer yFlightProvider. La representaci´on de toda la estructura de la organizaci´on se puede observar en la figura 4.1 y en las tablas 4.1 y 4.2. Por simplicidad todos los roles y las unidades se registran al iniciar la aplicaci´on. Esto se hace introduci´endolos directamente en la base de datos de la plataforma. La raz´on es tener todos los roles y unidades disponibles cuando se inicia el sistema para ahorrar al usuario todo el proceso de registro. Adem´as, cuando se inicia la aplicaci´on 4.1. CASO DE ESTUDIO 41 Nombre de unidad Unidad superior Objetivo Tipo Virtual —— —— Flat TravelAgency Virtual ReserveTravel Congregation HotelUnit TravelAgency ReserveHotel Flat FlightUnit TravelAgency ReserveFlight Flat Tabla 4.1: Contenido inicial de la UnitList Rol Unidad Visibilidad Posici´on Acceso Herencia Customer TravelAgency Public Member External —— Provider TravelAgency Public Member External —— Payee TravelAgency Private Member External —— HotelCustomer HotelUnit Public Member External Customer HotelProvider HotelUnit Public Member External Provider FlightCustomer FlightUnit Public Member External Customer FlightProvider FlightUnit Public Member External Provider Tabla 4.2: Contenido inicial de la RoleList ya est´an presentes los agentes proveedores y cliente, con lo cual, se puede considerar que la organizaci´on ya est´a creada. De todas formas, en cualquier momento se pueden registrar o eliminar roles y unidades mediante las opciones disponibles en las barras de men´u de los agentes. Para la aplicaci´on desarrollada, se han implementado un conjunto de servicios tur´ısticos con el objetivo de demostrar la viabilidad de la plataforma THOMAS para la gesti´on de cualquier tipo de servicio web en el entorno de un sistema multiagente. Estos servicios de gesti´on tur´ıstica intentan reflejar la realidad de lo que ofrecen las agencias de viajes actuales, como es la b´usqueda y reserva de hoteles y vuelos. Los servicios desarrollados son: Search Hotel,Reserve Hotel,Search Flight yReserve Flight. Estos servicios est´an destinados a ser prove´ıdos por los agentes proveedores presentes en la aplicaci´on, es decir, HotelProvider yFlightProvider. En las tablas 4.3 y 4.4 se encuentra toda la informaci´on referente a ellos: descripci´on, roles que deben poseer el cliente y el proveedor, entradas y salidas. Para entender el funcionamiento de la aplicaci´on desarrollada es necesario aclarar 48 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.5: Escenario de registro de un proceso Figura 4.6: Escenario de registro de un cliente Como se puede observar en la figura 4.6, el primer paso que realiza el agente es buscar el servicio que le interesa mediante la llamada al meta-servicio Search Service con el prop´osito deseado (mensaje 1). Teniendo en cuenta que la b´usqueda del servicio ha tenido ´exito (mensaje 2), se invoca un Get Profile (mensaje 3) para obtener el perfil del servicio. Una vez conseguido este perfil (mensaje 4), se puede consultar el rol o roles que debe poseer un agente para poder ejecutar el servicio. As´ı pues, los roles necesarios en este escenario para invocar el servicio deseado por el cliente son Customer de la unidad TravelAgency yHotelCustomer de la unidad HotelUnit. Por lo tanto, se hacen las llamadas pertinentes al meta-servicio AcquireRole (mensajes 5 y 7) para obtener los roles necesarios, que en este caso, se han podido adquirir sin ning´un problema (mensajes 6 y 8). En conclusi´on, el agente se ha convertido en cliente de las unidades TravelAgency y HotelUnit, con lo que tiene acceso a la ejecuci´on de los servicios pertenecientes a estos ´ambitos. 4.1. CASO DE ESTUDIO 49 Figura 4.7: Escenario de petici´on de servicio 4.1.5. Petici´on de servicio El siguiente escenario (figura 4.7) es uno de los m´as relevantes ya que se trata de la petici´on y ejecuci´on de un servicio de gesti´on tur´ıstica, lo que es uno de los principales objetivos de la aplicaci´on. El primer paso para ejecutar un servicio es encontrar un perfil que se adapte a las necesidades del cliente. Para ello se utiliza el meta-servicio del SF Search Service especificando el prop´osito del servicio que quiere ejecutar el cliente (mensaje 1). Una vez obtenido un perfil adecuado a las peticiones del cliente (mensaje 2), se hace una llamada al meta-servicio Get Process (mensaje 3) para obtener los proveedores de la implementaci´on del servicio. Previamente, un agente proveedor hab´ıa registrado un proceso, con lo cual, la respuesta tiene ´exito devolviendo el proveedor del servicio que se quiere ejecutar (mensaje 4). As´ı pues, el agente cliente ya puede hacer la petici´on de servicio al proveedor, facilitando las entradas correspondientes (mensaje 5). Cabe destacar que el agente cliente debe estar en posesi´on de los roles requeridos para poder ejecutar el servicio, como se ha visto en escenarios anteriores. Finalmente, el agente proveedor le devuelve al cliente el resultado de la ejecuci´on del servicio (mensaje 6). 50 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.8: Escenario de registro de una nueva unidad 4.1.6. Creaci´on de una nueva unidad Uno de los logros m´as importantes de la plataforma THOMAS es su gesti´on organizativa. As´ı pues, el meta-servicio b´asico para registrar nuevas unidades organizativas es Register Unit. Normalmente, la finalidad de registrar una nueva unidad es agrupar un conjunto de roles con un objetivo com´un. En este escenario se muestra de forma sencilla el registro de una nueva unidad, aunque podr´ıa haber un proceso previo mucho mayor para llegar a registrarla. En la figura 4.8 se puede ver el ejemplo de este escenario. Antes de la ejecuci´on del mismo, se ha tenido que crear la unidad TravelAgency dentro de la unidad principal virtual, que ya est´a creada por defecto dentro de la plataforma. Con lo cual, se puede hacer la llamada al meta-servicio Register Unit con los argumentos adecuados (mensaje 1). El OMS responde al agente solicitante del meta-servicio indicando el ´exito de la ejecuci´on (mensaje 2). En este caso, se registra la unidad RestaurantUnit dentro de TravelAgency con la finalidad de albergar los roles relacionados con la gesti´on de servicios sobre b´usqueda y reserva de restaurantes. En el siguiente escenario se ver´a la continuaci´on de este con el registro de algunos roles dentro de la unidad creada. 4.1.7. Creaci´on de nuevos roles Este sencillo escenario (figura 4.9) se puede considerar una continuaci´on del anterior, ya que despu´es del registro de una nueva unidad lo m´as l´ogico es introducir nuevos roles dentro de ella. As´ı pues, previamente al escenario que se explica a continuaci´on, la unidad RestaurantUnit ya ha sido registrada. Una vez introducidos dentro del contexto previo al escenario, el agente puede hacer la llamada al meta-servicio del OMS Register Role. En el primer caso, los argumentos de la llamada son para registrar un rol (RestaurantCustomer) perteneciente a la 4.1. CASO DE ESTUDIO 51 Figura 4.9: Escenario de registro de nuevos roles unidad RestaurantUnit dedicado a los clientes de ´esta, especializando el rol Customer de la TravelAgency. El mensaje 3 es tambi´en una llamada a Register Role, pero en este caso se registra igualmente otro rol dentro de RestaurantUnit para los proveedores, RestaurantProvider, que especializa a Provider. En ambas llamadas el OMS responde con un mensaje avisando de que se ha tenido ´exito en el registro de los roles (mensajes 2 y 4). 4.1.8. Expulsi´on de un agente En un entorno din´amico y cambiante en los que puede trabajar la plataforma THOMAS, siempre pueden existir agentes con objetivos contrarios a la organizaci´on o directamente clasificables como maliciosos. Para estos casos, se hace necesario disponer de herramientas para poder eliminar las amenazas y garantizar la seguridad del sistema. As´ı pues, el OMS ofrece un meta-servicio de expulsi´on de agentes. En este escenario (figura 4.10) se representa c´omo un agente de gesti´on de pagos (PayeeAgent) advierte un comportamiento fraudulento por parte del agente Agent. Antes de que ocurrieran los hechos, el agente malicioso hab´ıa adquirido el rol de cliente en la agencia de viajes. Por lo tanto, PayeeAgent hace una llamada al meta-servicio Expulse del OMS para expulsar a Agent, es decir, para que se le quite el rol Customer de la TravelAgency (mensaje 1). El meta-servicio Expulse se ejecuta con ´exito y Agent pierde el rol, con lo cual queda expulsado de la organizaci´on y ya no puede utilizar ning´un meta-servicio o servicio. 52 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.10: Escenario de expulsi´on de un agente malicioso Figura 4.11: Escenario de registro de una norma 4.1.9. Registro de una norma En la plataforma THOMAS se ha incluido un sistema de normas mediante el cual se pueden controlar las acciones de los agentes y establecer restricciones. Con lo cual, existe un meta-servicio que ofrece el OMS para registrar normas. En el escenario de la figura 4.11 hay un agente de gesti´on de pagos llamado PayeeAgent. En este caso, el agente ha adquirido el rol Payee dentro de la organizaci´on TravelAgency, y se quiere establecer que s´olo haya un gestor de pagos. Con lo cual, registra una norma que no permite a ning´un agente adquirir el rol Payee. Como se puede ver en el mensaje 1, se especifican dos argumentos: un identificador de la norma y la norma en cuesti´on. Concretamente, la norma que se registra proh´ıbe cualquier mensaje de tipo Request en el que haya una petici´on del meta-servicio Acquire Role con el rol Payee como argumento. Puesto que el meta-servicio Register Norm del OMS tiene ´exito, se obtiene un mensaje Inform notific´andolo (mensaje 2). 4.2. IMPLEMENTACI ´ ON DEL SISTEMA 53 4.2. Implementaci´on del Sistema En esta secci´on se explicar´a c´omo se ha implementado el sistema. Primeramente, se detallar´a la interfaz gr´afica de usuario que se ha dise˜nado y sus funcionalidades. Por otra parte, se comentar´a la implementaci´on de todo el sistema desde un punto de vista m´as t´ecnico, entrando en ciertos detalles de c´odigo fuente. 4.2.1. Interfaz Gr´afica de Usuario En la aplicaci´on desarrollada se ha dise˜nado e implementado una interfaz gr´afica de usuario para los distintos componentes existentes. Puesto que el lenguaje elegido para implementar la aplicaci´on ha sido Java, se ha utilizado el paquete javax.swing1para el desarrollo de la interfaz gr´afica de usuario. Este popular paquete de Java ofrece un conjunto de m´etodos y herramientas para la creaci´on de componentes gr´aficos para el tipo de interfaz deseada. En esta secci´on se explican detalladamente las distintas partes de la interfaz en la que se han implementado los siguientes elementos: Interfaz para agentes de tipo cliente Interfaz para agentes de tipo proveedor Interfaces para servicios y meta-servicios Visor del agente intermediario OMS Visor del agente intermediario SF 4.2.1.1. Interfaces para agentes, servicios y meta-servicios El esquema de dise˜no que se ha seguido para los agentes de tipo cliente y proveedor ha sido similar, dado que la mayor´ıa de las funciones que realizan son las mismas. Las diferencias s´olo residen en algunos servicios distintos que puede ejecutar cada tipo de agente. Cabe destacar que aunque estas interfaces est´an dise˜nadas concretamente para cada tipo de agente, no dejan de ser agentes generales de la plataforma THOMAS, con lo cual podr´ıan ejecutar cualquier tipo de servicio. Teniendo en cuenta esto, ambas interfaces disponen de una barra de men´u id´entica donde se puede llamar a cualquier 1http://java.sun.com/javase/6/docs/api/javax/swing/package-summary.html 54 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.12: Interfaz gr´afica de usuario para agentes de tipo cliente Figura 4.13: Interfaz gr´afica de usuario para agentes de tipo proveedor servicio disponible de la plataforma THOMAS. Con este dise˜no se consigue m´as generalidad en la aplicaci´on y mayor libertad para el usuario. En las figuras 4.12 y 4.13 se puede observar la interfaz para los agentes de tipo cliente y la interfaz para los agentes de tipo proveedor respectivamente. Como se puede ver, ambas constan de una barra de men´u en la parte superior, un conjunto de botones y listas desplegables en la parte central, y una barra de estado en la parte inferior. Primeramente se describir´a la barra de men´u existente tanto en la interfaz para agentes de tipo cliente como en la de agentes de tipo proveedor. Despu´es se explicar´a la parte central de ambas interfaces y las diferencias entre ellas, as´ı como las razones de dichas diferencias. Finalmente se comentar´a la funci´on de la barra de estado. 4.2. IMPLEMENTACI ´ ON DEL SISTEMA 55 Figura 4.14: Ejemplo de ventanas de ejecuci´on de servicios La barra de men´u est´a compuesta por dos entradas: OMS ySF. La primera de las entradas recoge todos los servicios del OMS que se pueden invocar, y la segunda engloba los servicios relativos al SF. Las entradas de la barra de men´u dan acceso a una serie de submen´us que al final llegan a alguna opci´on cuyo nombre coincide con un servicio de la plataforma. Al pulsar sobre esta opci´on se abrir´a la ventana correspondiente al servicio solicitado, en la que ser´an proporcionadas por el usuario las entradas requeridas para el servicio a ejecutar. En este tipo de ventanas siempre existir´a un bot´on para llamar al servicio y otro bot´on de cancelaci´on. Se pueden observar distintos ejemplos concretos de estas ventanas en la figura 4.14. La entrada de men´u OMS consta de tres submen´us: Structural Services,Informative Services yDynamical Services. El submen´u Structural Services est´a compuesto, a su vez, por dos submen´us. El primero es Register Services (figura 4.15) y en ´el se encuentran las opciones Register Role,Register Unit yRegister Norm, las cuales dan acceso a la ventana concreta donde se especifican las entradas del servicio al que se pretende llamar. El segundo submen´u de Structural Services es Deregister Services (figura 4.16), el cual engloba las opciones contrarias al anterior submen´u, es decir, Deregister Role,Deregister Unit y Deregister Norm. Al igual que con los otros servicios, al pulsar en cualquiera de estas opciones se abre una nueva ventana con las entradas que se deben introducir correspondientes al servicio que se desea ejecutar. 56 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.15: Submen´u Register Services del submen´u Structural Services Por otra parte, el submen´u Informative Services (figura 4.17) da acceso directo a las opciones de los servicios informativos, ´estos son: Inform Agent Role,Inform Members,Quantity Members,Inform Unit,Inform Unit Roles,Inform Role Profiles y Inform Role Norms. Al pulsar sobre cualquiera de estas opciones se abre la ventana correspondiente al servicio con el mismo nombre, esta ventana cuenta con los campos concretos de entrada que deben ser rellenados por el usuario. El ´ultimo submen´u de OMS es Dynamical Services (figura 4.18). ´ Este re´une las opciones Acquire Role,Leave Role yExpulse, que dan acceso a las ventanas concretas para cada servicio, con las entradas adecuadas a ´este. El men´u SF est´a compuesto por dos submen´us: Register Services yDiscovery Services. El primer submen´u del SF, Register Services (figura 4.19), est´a referido a los meta-servicios del SF encargados del registro de servicios. Por ello, engloba las siguientes opciones: Register Profile,Register Process,Modify Profile,Modify Process yDeregister Profile. Cada una de estas opciones da acceso a la ventana correspondiente (ejemplos en la figura 4.14) con las entradas del meta-servicio solicitado que debe rellenar el usuario. 4.2. IMPLEMENTACI ´ ON DEL SISTEMA 57 Figura 4.16: Submen´u Deregister Services del submen´u Structural Services Figura 4.17: Submen´u Informative Services 64 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.26: Ventana del servicio Search Hotel Figura 4.27: Ventana del servicio Search Flight Figura 4.28: Ventana del servicio Reserve Hotel 4.2. IMPLEMENTACI ´ ON DEL SISTEMA 65 Figura 4.29: Ventana del servicio Reserve Flight Figura 4.30: Ventana de advertencia de error de introducci´on, causada por tener el campo Country vac´ıo del servicio Search Hotel ejecutado con anterioridad. En el caso de Reserve Flight, los campos completados si se ha hecho previamente un Search Flight son: Flight Company, Date,City To,Hour Departure yHour Arrive. Por otra parte, en todas estas ventanas para la ejecuci´on de los servicios tur´ısticos se comprueba que las entradas a introducir por el usuario est´en correctamente rellenadas siguiendo el formato correcto en cada caso. Si no es as´ı, cuando se intenta hacer la llamada al servicio mediante el bot´on correspondiente, la aplicaci´on avisa de la incorrecci´on (figuras 4.30, 4.31 y 4.32) y el usuario debe enmendar el error para poder seguir con la ejecuci´on de dicho servicio. Si la llamada al servicio tiene ´exito se devuelven los resultados en una ventana informativa (figuras 4.33 y 4.34, notificando el resultado de un Search Hotel y de un Reserve Hotel respectivamente) y tambi´en se notifica que el resultado es satisfactorio a trav´es de la barra de estado. A continuaci´on, se explicar´an los botones que forman la parte inferior de la interfaz de agentes de tipo proveedor puesto que todos los elementos comunes con la interfaz de agentes de tipo cliente ya han sido detallados. Estos botones exclusivos para los agentes de tipo proveedor est´an relacionados con la gesti´on de perfiles y procesos de servicios. La raz´on de que los agentes de tipo cliente no posean en su interfaz estos 66 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.31: Ventana de advertencia de error de formato, causada por una incorrecci´on en el campo Category que debe ser un entero Figura 4.32: Ventana de advertencia de error de formato, causada por una incorrecci´on en el campo Date que debe ser de tipo fecha (aaaa-mm-dd) Figura 4.33: Ventana informativa despu´es del ´exito de la ejecuci´on del servicio Search Hotel Figura 4.34: Ventana informativa despu´es del ´exito de la ejecuci´on del servicio Reserve Hotel 4.2. IMPLEMENTACI ´ ON DEL SISTEMA 67 Figura 4.35: Ventana de ejecuci´on del servicio Register Profile botones reside en que no est´an pensados para proveer servicios, s´olo para solicitarlos, y con lo cual no tiene sentido poder acceder a registrar perfiles y procesos. A pesar de esto, como ya se ha comentado anteriormente con otros casos, mediante las barras de men´u el agente de tipo cliente podr´ıa utilizar todos los servicios relacionados con la gesti´on de perfiles y procesos, ya que se podr´ıa dar la circunstancia de que un cliente fuera a su vez proveedor de alg´un servicio. El primero de los botones de la parte inferior de la interfaz para agentes de tipo proveedor es Register Profile. Al pulsar sobre ´este aparece una ventana (figura 4.35) en la que se puede seleccionar el perfil que se desea registrar en el SF. La selecci´on se realiza mediante la lista desplegable etiquetada como Service Profile en la que existen un conjunto de opciones con los perfiles que puede registrar el agente con el que se trabaja. La caja de texto etiquetada como Service Purpose contiene el prop´osito del servicio que se registrar´a con el perfil seleccionado, as´ı pues, este prop´osito es el que se utilizar´a para la b´usqueda del servicio mediante Search Service. Adem´as, se cambia autom´aticamente seg´un el perfil seleccionado en la lista desplegable superior, por lo tanto no es editable por el usuario. A pesar de que s´olo se permite el registro de ciertos perfiles mediante el bot´on de la interfaz, el usuario siempre puede utilizar las opciones de la barra de men´u para ejecutar el meta-servicio Register Profile con los argumentos deseados. Sin embargo, esta opci´on es m´as desaconsejable ya que se pueden provocar fallos por la inexperiencia del usuario o por la mala introducci´on de alg´un argumento. De esta forma, la aplicaci´on ofrece robustez, desde el punto de vista de su utilizaci´on m´as intuitiva, y flexibilidad al poder usar los meta-servicios con los argumentos que desee un usuario avanzado. Una vez se ha pulsado el bot´on Register Profile de la ventana del meta-servicio con el mismo nombre, se ejecuta la llamada con los argumentos seleccionados. Si la llamada tiene ´exito, la aplicaci´on avisar´a al usuario con un mensaje informativo (figura 4.36) y tambi´en mediante la barra de estado. Por el contrario, si no se ha podido 68 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.36: Ventana informativa despu´es del ´exito de la ejecuci´on del meta-servicio Register Profile Figura 4.37: Ventana de ejecuci´on del meta-servicio Deregister Profile registrar el perfil, la aplicaci´on notificar´a este hecho de igual forma, es decir, mediante un mensaje informativo correspondiente e informaci´on pertinente en la barra de estado. A la derecha del bot´on Register Profile se encuentra el bot´on Deregister Profile. La misi´on de este ´ultimo es dar acceso a la ejecuci´on del meta-servicio de su mismo nombre. As´ı pues, al pulsarlo se accede a la ventana de la figura 4.37 en la que se encuentran los perfiles registrados en el SF. En caso de no existir ning´un perfil de servicio registrado aparecer´ıa un mensaje de aviso como el de la figura 4.38 informando al usuario. Una vez se ha abierto la ventana con los perfiles registrados, el usuario debe seleccionar el que est´a interesado en eliminar del registro del SF. As´ı pues, se pulsar´ıa sobre el bot´on Deregister Profile para hacer la llamada al meta-servicio del mismo nombre con el perfil seleccionado como argumento. Como es habitual en la aplicaci´on, se informar´a al usuario del ´exito o no de la operaci´on mediante una ventana informativa y a trav´es de la barra de estado. El primer bot´on presente en la ´ultima l´ınea de botones de la interfaz para agentes de tipo proveedor es Register Process. El uso de ´este provoca la ejecuci´on de una ventana (figura 4.39) donde se puede elegir el identificador del servicio del que se desea registrar una implementaci´on. De forma similar a la ventana de Register Profile, se Figura 4.38: Ventana de aviso de que no hay ning´un perfil registrado 4.2. IMPLEMENTACI ´ ON DEL SISTEMA 69 Figura 4.39: Ventana de ejecuci´on del servicio Register Process Figura 4.40: Ventana informativa despu´es del ´exito de la ejecuci´on del meta-servicio Register Process dispone de una lista desplegable con la que se selecciona el identificador del servicio, y dependiendo de esta selecci´on, el cuadro de texto inferior cambiar´a su contenido con el modelo de implementaci´on correspondiente, con lo cual, no es editable por el usuario. Adem´as, los identificadores de servicio que aparecer´an como opciones para registrar el proceso ser´an solamente aquellos cuyo perfil haya sido registrado previamente. Cuando se pulse sobre el bot´on Register Process se har´a la llamada a este meta-servicio con los argumentos seleccionados en la ventana. Tanto si tiene ´exito como si no, la aplicaci´on nos avisar´a mediante una ventana informativa (´exito en la ejecuci´on, figura 4.40) y tambi´en se notificar´a en la barra de estado. La intenci´on de este dise˜no es la misma que en la ventana de Register Profile, facilitar al usuario el uso de la aplicaci´on para que no se cometan equivocaciones en la introducci´on de argumentos. Al igual que en otros casos, si se desea hacer un registro de un proceso distinto a los que se ofrecen por defecto s´olo hay que acceder al meta-servicio Register Process desde la barra de men´u y facilitar los argumentos deseados. Para poder eliminar un proveedor de una implementaci´on de servicio, existe el meta-servicio del SF Remove Provider. Con lo cual, el bot´on destinado a este metaservicio tiene el mismo nombre y est´a situado a la derecha de Register Process. Cuando se pulsa, si no hay ning´un proceso registrado aparecer´a una ventana de aviso como la de la figura 4.41. Por el contrario, si ya se ha registrado alg´un proceso se mostrar´a una ventana como la de la figura 4.42 en la que se podr´a elegir cualquiera de los procesos registrados en el SF. Una vez elegido el proceso que se desea eliminar del registro del SF se debe pulsar el bot´on Remove Provider de la ventana para hacer la llamada al meta-servicio hom´onimo. Como es habitual en la aplicaci´on, se informar´a al usuario de 70 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.41: Ventana de aviso de que no hay ning´un proceso registrado Figura 4.42: Ventana de ejecuci´on del meta-servicio Remove Provider si la operaci´on ha tenido ´exito mediante una ventana informativa y la barra de estado. Cabe destacar que si el proceso que se elimina era el ´ultimo que proporcionaba el servicio de un perfil determinado, dicho perfil tambi´en ser´a eliminado del registro del SF. Por lo tanto, al eliminar el ´ultimo proveedor de una implementaci´on de servicio se provoca la eliminaci´on del perfil que le corresponde. Es necesario aclarar que este es un mecanismo autom´atico presente en la plataforma THOMAS y que no tiene nada que ver con la aplicaci´on desarrollada. Finalmente, la barra de estado, tanto en la interfaz para agentes de tipo cliente como en la de los agentes de tipo proveedor, sirve para informar al usuario de qu´e servicio se est´a ejecutando o del resultado que ha devuelto. Es decir, tal y como se ha visto a lo largo de esta secci´on, ofrece la utilidad t´ıpica en este tipo de componente para una aplicaci´on. 4.2.1.2. Visores del OMS y del SF Para comprender el funcionamiento de la plataforma THOMAS y poder observar la informaci´on que tiene registrada internamente, se han implementado dos visores para los agentes intermediarios OMS y SF. Es necesario aclarar que cualquier aplicaci´on real desarrollada sobre la plataforma s´olo tendr´ıa acceso a esta informaci´on por medio de los meta-servicios informativos que ofrece el OMS. Sin embargo, en este caso se ha optado por acceder directamente a la base de datos de THOMAS para obtener la informaci´on de forma r´apida y directa, y no provocar un tr´afico de mensajes que podr´ıa saturar el canal de comunicaci´on. As´ı pues, el prop´osito de estos visores es mostrar al usuario los datos que se consideran interesantes para observar c´omo funciona la plataforma THOMAS y la gesti´on de los meta-servicios que realizan los agentes inter- 4.2. IMPLEMENTACI ´ ON DEL SISTEMA 71 Figura 4.43: Visor del agente intermediario OMS mediarios OMS y SF. Cabe destacar que ambos visores est´an directamente vinculados con el agente intermediario al que representan. Por ello obtienen los datos directamente. El visor del OMS est´a compuesto por tres tablas principales, tal y como se puede observar en la figura 4.43. La primera tabla es Unit List, es decir, la lista de unidades registradas en el OMS. Se pueden ver las organizaciones que hay presentes en la plataforma junto con sus atributos: tipo, objetivo y unidad superior. La segunda tabla contiene la lista de roles, Role List. De igual forma que en la tabla anterior, se muestran los roles registrados en el OMS junto con sus atributos, que son: posici´on, acceso, visibilidad, herencia y unidad. Finalmente, la tercera tabla muestra la Entity Play List, es decir, la lista de los roles que poseen los agentes en la plataforma. As´ı pues, los campos que componen esta tabla son: identificador de rol, identificador de unidad e identificador de entidad o agente. Con el objetivo de mostrar al usuario los perfiles y procesos registrados en el SF se ha creado un visor para este agente intermediario. En la figura 4.44 se puede observar el visor del SF al inicio de la ejecuci´on del sistema. Por esta raz´on se encuentra vac´ıo ya que no se ha registrado ning´un perfil ni proceso todav´ıa. El visor est´a compuesto principalmente por dos tablas: Profiles List yProcesses List. Tal y como su nombre indica 72 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.44: Visor del agente intermediario SF Figura 4.45: Visor del agente intermediario SF con perfiles y procesos consultados la primera de ellas es una lista de los perfiles registrados y la segunda otra lista con los procesos registrados. Adem´as, ambas tablas disponen de una columna etiquetada como Times Consulted, que es un contador de las veces que se ha consultado el perfil o proceso en cuesti´on. Se entiende una consulta de un perfil la ejecuci´on del meta-servicio Get Profile sobre ese perfil. Por su parte, una consulta a un proceso se hace mediante el meta-servicio Get Process. En la figura 4.45 se puede ver el visor del SF con algunos perfiles y procesos registrados que han sido consultados. 4.2.2. Implementaci´on de la Aplicaci´on M´as all´a de la interfaz gr´afica de usuario que se ha explicado anteriormente, es necesario detallar el desarrollo de la aplicaci´on desde el punto de vista de su funcionamiento interno. A continuaci´on, se comenta de forma general el conjunto de m´etodos implementados. 4.2. IMPLEMENTACI ´ ON DEL SISTEMA 73 4.2.2.1. Implementaci´on de los agentes y sus interfaces Todo el funcionamiento de la aplicaci´on va estrechamente ligado a la interfaz gr´afica, ya que a trav´es de los componentes de que dispone el usuario se ejecutan las funciones de la aplicaci´on. El c´odigo implementado se divide en distintas clases de Java agrupando los m´etodos necesarios. Se han desarrollado clases auxiliares para la creaci´on de las interfaces gr´aficas necesarias seg´un el caso, como las ventanas que aparecen para ejecutar los distintos servicios o las propias interfaces para los agentes de tipo cliente y proveedor. El objetivo de estas clases auxiliares es dividir el c´odigo en distintas partes para no concentrarlo todo en una misma clase. As´ı pues, las principales clases que se han implementado son la de agentes de tipo cliente (ClientAgent) y la de agentes de tipo proveedor (ProviderAgent). Ambas clases son bastante similares ya que comparten muchos m´etodos y variables, aunque existen diferencias debidas a la naturaleza de cada tipo de agente y tambi´en relacionadas con las distintas interfaces gr´aficas de que disponen. Tanto la clase ClientAgent como la ProviderAgent, desarrolladas para incluir agentes de tipo cliente y proveedor en la aplicaci´on, extienden a la clase jade.core.Agent. Con lo cual, en el m´etodo setup() es donde se concentra la acci´on. Concretamente, en la implementaci´on realizada se ubican todos los Action Listeners de la interfaz gr´afica de usuario dentro de este m´etodo. Es necesario aclarar que un Action Listener se ejecuta cuando se produce un evento sobre el componente en el cual se ha creado. Se han incluido en el setup() porque este m´etodo es el encargado de configurar las acciones del agente y se ejecuta cuando ´este es iniciado. As´ı pues, cuando entre en ejecuci´on el agente despu´es de su creaci´on, los Action Listeners se iniciar´an y quedar´an a la espera del evento que los active para ejecutar el c´odigo que alberguen. El funcionamiento b´asico de la mayor´ıa de los Action Listeners que se han a˜nadido a los botones de la interfaz, tanto en el cliente como en el proveedor, consiste en crear y mostrar una nueva ventana correspondiente al servicio o meta-servicio que se desea ejecutar. En otros casos, como el bot´on Search Service, se obtiene el valor de la lista desplegable correspondiente y se hace directamente una llamada al servicio con este par´ametro. Volviendo a los Action Listeners que muestran una nueva ventana, tras la creaci´on de ´esta se hace una llamada al servicio o meta-servicio cuando el usuario pulse el bot´on pertinente y haya rellenado todos los campos de entrada correctamente. En estas ventanas nuevas que aparecen, tambi´en existe un Action Listener en el bot´on de llamada al servicio o meta-servicio para controlar cu´ando se utiliza, y que los campos est´en rellenados adecuadamente. 80 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON 4.3. Validaci´on de la plataforma THOMAS Una vez desarrollada la aplicaci´on de gesti´on de servicios tur´ısticos, se puede analizar la validez de la plataforma THOMAS sobre la que se ha basado este trabajo. Para ello, se mostrar´a al lector la ejecuci´on de los escenarios explicados en el caso de estudio (secci´on 4.1) mediante la aplicaci´on desarrollada. Esto permitir´a conocer el conjunto de funcionalidades que se utilizan en la aplicaci´on para reproducir los escenarios y comprobar el correcto funcionamiento de la plataforma THOMAS. El objetivo es demostrar la viabilidad del desarrollo de software sobre dicha plataforma y validar la ejecuci´on de los servicios y meta-servicios. 4.3.1. Registro de los agentes como miembros de la plataforma THOMAS La aplicaci´on de gesti´on de servicios tur´ısticos desarrollada est´a ´ıntimamente ligada a la plataforma THOMAS. Esto es debido a que tanto los agentes intermediarios de THOMAS como los agentes de la aplicaci´on comparten el mismo marco de ejecuci´on en la plataforma JADE. Adem´as, los visores del OMS y del SF que se han implementado para mostrar informaci´on al usuario dependen directamente del OMS y del SF. Con lo cual, se ha a˜nadido c´odigo fuente en estos agentes intermediarios. Esto significa que la plataforma no es independiente de la aplicaci´on, aunque en un caso real y t´ıpico, no existir´ıan los visores y la independencia ser´ıa total. Puesto que el marco de ejecuci´on de los agentes de la aplicaci´on y de la plataforma THOMAS es compartido, se lanzan todos al mismo tiempo. La aplicaci´on dispone de un agente cliente (Client) y dos agentes proveedores: HotelProvider yFlightProvider. Como ya se ha comentado anteriormente, la primera acci´on que realizan los agentes de la aplicaci´on es registrarse en la plataforma THOMAS. Para ello, hacen una llamada al meta-servicio Acquire Role para obtener el rol member dentro de la unidad virtual. Cabe destacar que esta adquisici´on del rol se hace autom´aticamente ya que es b´asico pertenecer a THOMAS para poder empezar a utilizar sus meta-servicios. En la figura 4.46 se observa que en la barra de estado del agente cliente se est´a haciendo una petici´on a Acquire Role al iniciar la aplicaci´on. Esta es la imagen que ofrecen los agentes durante un breve periodo de tiempo al inicio de su ejecuci´on. 4.3. VALIDACI ´ ON DE LA PLATAFORMA THOMAS 81 Figura 4.46: Agente cliente solicitando Acquire Role al inicio de la ejecuci´on As´ı pues, cuando los tres agentes hayan podido adquirir con ´exito el rol de miembros en la organizaci´on virtual de THOMAS, se ver´a esta informaci´on en la tabla Entity Play List del visor del OMS (figura 4.47). Con este resultado, se puede ver que el escenario de registro de agentes en la plataforma THOMAS (figura 4.3) se ha podido ejecutar sin problema en todos los agentes presentes en la aplicaci´on. 4.3.2. Registro de proveedores y servicios Antes de que el cliente pueda utilizar alg´un servicio tur´ıstico, ´estos deben ser registrados por parte de los agentes proveedores presentes en el sistema. Para poder proveer un servicio tur´ıstico en la aplicaci´on se deben seguir unos pasos determinados. B´asicamente, es necesario registrar el perfil del servicio y despu´es el proceso o implementaci´on del mismo. Con el registro del perfil se consigue que cualquier agente interesado en el servicio pueda buscarlo mediante el meta-servicio Search Service del SF. Por otra parte, el registro del proceso supone ser el proveedor del servicio con la implementaci´on registrada. Esto significa que a partir de ese momento, cualquier agente puede saber qui´en ofrece el servicio y enviarle una petici´on para utilizarlo. A continuaci´on se detalla c´omo seguir estos pasos en la aplicaci´on. Primeramente se necesita registrar el perfil correspondiente al servicio que se desea proveer. Antes de hacerlo es obligatorio adquirir el rol o roles necesarios para ser proveedor del servicio. Con lo cual, se utilizar´a el bot´on Acquire Role de la interfaz que da acceso a la ventana en la que se elige el rol a adquirir. En este caso se obtendr´a el rol Provider de la TravelAgency y despu´es, dependiendo de si se trata del agente 82 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.47: Visor del agente intermediario OMS despu´es de que los agentes hayan adquirido el rol member en virtual Figura 4.48: Visor del agente intermediario OMS despu´es de que el agente HotelProvider haya adquirido los roles Provider de la TravelAgency yHotelProvider de la HotelUnit 4.3. VALIDACI ´ ON DE LA PLATAFORMA THOMAS 83 Figura 4.49: Mensaje de advertencia de necesidad de registrar un perfil antes que un proceso Figura 4.50: Ventana de ejecuci´on del servicio Register Profile HotelProvider oFlightProvider, se adquirir´a el rol HotelProvider de la HotelUnit o el rol FlightProvider de la FlightUnit. Por lo tanto, si tomamos como ejemplo el agente HotelProvider, se puede ver en la tabla Entity Play List del visor del OMS de la figura 4.48 que se han obtenido los roles necesarios. As´ı pues, en este punto se podr´ıa dar por concluido el escenario de registro de un proveedor de hoteles (figura 4.4), ya que se han adquirido los roles que acreditan al agente como tal. Cuando ya se han obtenido los roles, se puede registrar el perfil del servicio a proveer. Para ello se utiliza el bot´on Register Profile del agente proveedor en cuesti´on. Cabe destacar que si se intenta registrar un proceso antes de haber registrado un perfil, la aplicaci´on nos avisar´a de que no es posible (con un mensaje como el de la figura 4.49). Esto ocurre porque se controla que s´olo se puede registrar un proceso cuyo perfil ya haya sido registrado. Si el agente proveedor ya ha registrado alg´un perfil, se dar´a la opci´on de registrar el proceso correspondiente al perfil ya registrado, pero no otros sin registrar. Con lo cual, al pulsar el bot´on Register Profile aparecer´a la ventana de la figura 4.50 con los perfiles que se pueden registrar seg´un el agente proveedor. En el caso del HotelProvider ser´an los servicios relativos a la b´usqueda y reserva de hoteles, y en el caso del FlightProvider estar´an disponibles los servicios relativos a la b´usqueda y reserva de vuelos. As´ı pues, se elegir´a el perfil que se desee registrar y se pulsar´a el bot´on correspondiente en la ventana. Si la operaci´on tiene ´exito, la aplicaci´on lo notificar´a adecuadamente y aparecer´a en el visor del SF el perfil que se acaba de registrar (ejemplo en la figura 4.51). Una vez se ha registrado el perfil del servicio, es posible registrar el proceso del mis- 84 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.51: Visor del agente intermediario SF con un perfil registrado Figura 4.52: Ventana de ejecuci´on del servicio Register Process mo con el agente proveedor correspondiente. Para ello se debe pulsar el bot´on Register Process de la interfaz del agente proveedor y en la ventana que aparece (figura 4.52) seleccionar el perfil registrado previamente. Con lo cual, al pulsar el bot´on de la ventana se registrar´a una implementaci´on del perfil seleccionado y el agente se convertir´a en proveedor de este servicio. La aplicaci´on informar´a al usuario de si la operaci´on tiene ´exito o no, y en caso afirmativo se podr´a ver el proceso registrado en el visor del SF (ejemplo en la figura 4.53). Por lo tanto, se ha conseguido reproducir con ´exito el escenario de registro de un proceso (figura 4.5). A partir de este momento, el agente cliente ya dispone de un servicio que puede utilizar. Para que el resto de servicios tur´ısticos est´en disponibles en la aplicaci´on se Figura 4.53: Visor del agente intermediario SF con un perfil y un proceso registrados 4.3. VALIDACI ´ ON DE LA PLATAFORMA THOMAS 85 Figura 4.54: Agente cliente despu´es de encontrar el servicio Search Hotel deben seguir los pasos que se acaban de detallar. En resumen, desde el agente proveedor se deben adquirir los roles necesarios, registrar el perfil del servicio y el proceso o implementaci´on del mismo. 4.3.3. B´usqueda y utilizaci´on de servicios tur´ısticos Cuando ya se dispone de servicios tur´ısticos registrados y con proveedores que pueden servirlos, el cliente puede buscarlos para su utilizaci´on. A continuaci´on se explicar´an los pasos a seguir para encontrar un servicio tur´ıstico que desee el cliente y hacer la petici´on pertinente para su uso. Lo primero que debe hacer un cliente para utilizar un servicio es buscarlo mediante el meta-servicio Search Service del SF. En la interfaz del agente cliente de la aplicaci´on existe una lista desplegable etiquetada como Services Purposes en la que se debe elegir el prop´osito del servicio a buscar. Una vez elegido se puede pulsar el bot´on Search Service con el que se hace la llamada al meta-servicio del mismo nombre. Si existe un perfil de servicio registrado en el SF con el prop´osito que se buscaba aparecer´a en la siguiente lista desplegable etiquetada como Found Services. En caso contrario la aplicaci´on avisar´a de que no se ha encontrado ning´un perfil con dichas caracter´ısticas. En la figura 4.54 se puede ver el agente cliente despu´es de haber encontrado el servicio Search Hotel. En este momento se pueden realizar dos acciones: obtener el perfil del servicio, o el proceso y proveedor del mismo. El perfil del servicio se obtendr´a sin problema con Get Profile, ya que si no existiera no se hubiera encontrado con el meta-servicio Search 86 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.55: Visor del agente intermediario OMS despu´es de que el agente Client haya adquirido los roles Customer de la TravelAgency yHotelCustomer de la HotelUnit Service. Por otra parte, si no se ha registrado ning´un proceso referente al perfil del servicio, no se encontrar´a nada al llamar al meta-servicio Get Process. En caso que s´ı exista alg´un proceso registrado, esta llamada al meta-servicio del SF devolver´ıa el proceso en cuesti´on y el proveedor del mismo. De todas formas, la acci´on que se debe realizar primero es obtener el perfil del servicio, mediante el meta-servicio Get Profile, con el objetivo de consultar los roles que hay que poseer para convertirse en cliente del mismo. As´ı pues, para este caso se debe poseer el rol Customer de la TravelAgency y el rol HotelCustomer de la HotelUnit. Con lo cual, se hacen las llamadas pertinentes al meta-servicio Acquire Role del OMS con el bot´on del mismo nombre disponible en la interfaz del agente. Una vez obtenidos los roles necesarios (en la figura 4.55 se puede observar el visor del OMS con los roles registrados para el agente Client) , ya se puede solicitar la ejecuci´on del servicio. En este punto, el escenario de registro de un cliente (figura 4.6) se ha reproducido con ´exito. As´ı pues, ya se puede pasar al siguiente escenario sobre la petici´on del servicio. Para ello hay que obtener mediante el meta-servicio Get Process el proceso del servicio y el proveedor del mismo, en caso de que se haya registrado. Si hay un proveedor que ha registrado el proceso pertinente, el agente cliente quedar´a como en la figura 4.56. Se puede observar que en la lista desplegable Found Processes &Providers aparece el nombre del proceso del servicio Search Hotel y el 4.3. VALIDACI ´ ON DE LA PLATAFORMA THOMAS 87 Figura 4.56: Agente cliente despu´es de obtener el proceso y el proveedor del servicio Search Hotel Figura 4.57: Ventana del servicio Search Hotel proveedor del mismo, HotelProvider. Finalmente se ha obtenido el proveedor del servicio y la implementaci´on o proceso que ofrece. Por lo tanto, el agente cliente ya puede hacer la petici´on de servicio al proveedor utilizando el bot´on Execute Service con la opci´on correspondiente seleccionada en la lista desplegable. Al apretar el bot´on, aparece una ventana con las entradas para rellenar del servicio a ejecutar (figura 4.57). Una vez se hayan completado correctamente todas las entradas se podr´a hacer la llamada al mismo enviando la petici´on al proveedor. En la figura 4.58 se puede ver una imagen del agente Sniffer de la plataforma JADE. Se ha capturado el flujo de mensajes enviados entre los agentes cliente y proveedor. En total se han enviado tres mensajes: FIPA Request para la petici´on de servicio del cliente al proveedor, Agree del proveedor al cliente aceptando proveer el servicio y el Inform del proveedor al cliente notificando el resultado del servicio. Cuando se recibe el resultado de la ejecuci´on del servicio, el agente cliente lo muestra para que el usuario lo pueda ver (figura 4.59). Con lo cual, se ha finalizado el escenario de petici´on de servicio con ´exito (figura 4.7). 88 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Figura 4.58: Ventana del agente Sniffer de JADE capturando los mensajes enviados entre el cliente y el proveedor HotelProvider Figura 4.59: Ventana informativa despu´es del ´exito de la ejecuci´on del servicio Search Hotel 4.3. VALIDACI ´ ON DE LA PLATAFORMA THOMAS 89 Figura 4.60: Ventana del meta-servicio Register Unit con los campos rellenados para registrar la unidad RestaurantUnit 4.3.4. Otros meta-servicios Una vez se han mostrado las funcionalidades t´ıpicas y m´as utilizadas se puede pasar a probar el funcionamiento de otras cuestiones que se pueden encontrar en la aplicaci´on. A continuaci´on, se utilizar´an los meta-servicios para registrar y eliminar unidades, roles y normas, as´ı como para expulsar agentes. Puesto que estas funcionalidades no son las m´as utilizadas en el sistema, no disponen de ning´un bot´on en las interfaces de los agentes. Pero est´an contempladas en las barras de men´u. Una de las ventajas de la plataforma THOMAS es su gesti´on de las organizaciones virtuales. Para ello, se ha creado un sistema de registro y mantenimiento de unidades organizativas y roles. En alg´un momento de la vida del sistema podr´ıa ser necesario registrar una nueva unidad con sus correspondientes roles para incluir otra organizaci´on en la plataforma. As´ı pues, se podr´ıan utilizar los meta-servicios Register Unit yRegister Role del OMS. En la aplicaci´on desarrollada se ha incluido la posibilidad de utilizar estos meta-servicios mediante las opciones de la barra de men´u. Para registrar una nueva unidad organizativa se puede usar la barra de men´u de cualquiera de los agentes de la aplicaci´on. La opci´on se encuentra en OMS, Structural Services,Register Services. Con lo cual, pulsando sobre Register Unit se abrir´a una ventana con las entradas a facilitar. En esta ventana se podr´ıan rellenar las entradas del meta-servicio como se ve en la figura 4.60. As´ı pues, ejecutando la llamada al metaservicio y en caso de que tenga ´exito, aparecer´ıa reflejada la nueva unidad en el visor del OMS como se puede ver en la figura 4.61. En este punto se habr´ıa ejecutado con ´exito el escenario de creaci´on de una nueva unidad (figura 4.8) explicado en la secci´on 4.1. 96 CAP´ ITULO 4. DISE ˜ NO E IMPLEMENTACI ´ ON DE LA APLICACI ´ ON Cap´ıtulo 5 Conclusiones y Trabajos Futuros 5.1. Conclusiones A lo largo de los cap´ıtulos anteriores se ha mostrado el trabajo realizado para este proyecto. Primeramente, se ha hecho un estudio de la plataforma THOMAS para adquirir un nivel de comprensi´on adecuado y tener la capacidad de desarrollar una aplicaci´on que utilice los mecanismos que ofrece la plataforma. Una vez superado este obst´aculo se ha planteado un dise˜no para la aplicaci´on, en el que la principal intenci´on ha sido facilitar el uso de la misma al usuario y mostrar de forma transparente c´omo funciona la plataforma THOMAS. Finalmente se ha implementado la aplicaci´on siguiendo las directrices de la plataforma para obtener un buen funcionamiento y demostrar que es viable desarrollar y adaptar software con THOMAS. Con lo cual, se puede afirmar que se han cumplido los objetivos planteados al inicio de este trabajo. Adem´as, dada la complejidad inherente al desarrollo de software basado en sistemas multiagente y servicios web, se puede afirmar que ha sido posible implementar una aplicaci´on robusta y flexible. Por una parte, la dificultad que entra˜na tratar con una plataforma de SMA que incluye servicios web a los que se debe acceder de forma concreta, y teniendo en cuenta que se trabaja normalmente con cadenas de caracteres, hay que destacar el buen funcionamiento de la aplicaci´on debido a la acotaci´on realizada y las ayudas proporcionadas al usuario. Es decir, limitando las opciones disponibles en algunos casos para no provocar fallos causados por la inexperiencia del usuario en el funcionamiento del sistema. Por otra parte, dada la limitaci´on de algunos contenidos que se pueden considerar m´as intuitivos, la aplicaci´on ofrece un conjunto de opciones a trav´es de las barras de men´u con las que el usuario avanzado dispone de un control y una flexibilidad total para el uso de todos los meta-servicios que ofrece la plataforma. 97 98 CAP´ ITULO 5. CONCLUSIONES Y TRABAJOS FUTUROS Es importante destacar que mediante el desarrollo de la aplicaci´on de gesti´on de servicios tur´ısticos se ha podido demostrar la validez de la plataforma THOMAS para desarrollar aplicaciones basadas en ella. Con las pruebas realizadas y la propia aplicaci´on queda constancia de que los meta-servicios y mecanismos de THOMAS funcionan correctamente y cumplen sus objetivos. A modo de resumen, a continuaci´on se muestran las aportaciones de este trabajo: Dise˜no de interfaces gr´aficas de usuario para agentes de tipo proveedor y cliente. Se ha realizado un estudio para obtener un dise˜no c´omodo e intuitivo para el usuario. La intenci´on es facilitar la comprensi´on al usuario de los meta-servicios de la plataforma THOMAS y de su utilizaci´on general. Dise˜no de visores para los agentes intermediarios OMS y SF de la plataforma THOMAS. Esto ha implicado a˜nadir c´odigo fuente a ambos agentes, con lo que se ha dotado a la plataforma de nuevos mecanismos para la visualizaci´on de su actividad. Implementaci´on de agentes para la aplicaci´on. Se ha implementado la gesti´on de los eventos que provoca el usuario a trav´es de la interfaz gr´afica, as´ı como las funcionalidades para informar y guiar al usuario durante la ejecuci´on. Adem´as, se ha incluido un sistema de comunicaci´on para el env´ıo y la recepci´on de mensajes entre los agentes. Implementaci´on de servicios web de gesti´on tur´ıstica. Se han desarrollado cuatro servicios web relacionados con la gesti´on tur´ıstica que son utilizados por la misma aplicaci´on. Aplicaci´on para la gesti´on de servicios tur´ısticos. Con el dise˜no y la implementaci´on de todos los componentes que forman la aplicaci´on se ha obtenido un producto final ejecutable y novedoso. Estudio y validaci´on de la plataforma THOMAS. Primeramente se ha analizado c´omo es y c´omo funciona la plataforma comprendiendo sus mecanismos y metaservicios. Seguidamente, se ha comprobado el funcionamiento de la plataforma recreando escenarios en los que est´an implicados todos los meta-servicios de THOMAS. Finalmente, se ha podido demostrar que es viable desarrollar software 5.2. TRABAJOS FUTUROS 99 sobre dicha plataforma ya que sus mecanismos y meta-servicios funcionan correctamente. 5.2. Trabajos futuros Para finalizar, despu´es de todo el trabajo realizado, aun se pueden plantear mejoras y nuevos retos a tener en cuenta en el futuro. Se proponen trabajos futuros para la aplicaci´on desarrollada y para la plataforma THOMAS. As´ı pues, como trabajos futuros referentes a la aplicaci´on desarrollada sobre gesti´on de servicios tur´ısticos, se pueden hacer las siguientes propuestas: Ampliaci´on de la aplicaci´on para poder incluir agentes situados en ubicaciones remotas. As´ı pues, cualquier agente que cumpliese con los requisitos m´ınimos podr´ıa entrar a formar parte del sistema y ofrecer sus servicios. Implementaci´on de servicios de gesti´on tur´ıstica que extraigan informaci´on real a trav´es de la web y act´uen de forma inteligente. En los servicios de b´usqueda se deber´ıa establecer una conexi´on con un gestor apropiado para encontrar hoteles y vuelos reales con disponibilidad. Complementariamente se tendr´ıa la opci´on de hacer una reserva de los hoteles o vuelos encontrados. La b´usqueda y reserva se podr´ıan hacer como servicios simples y tambi´en juntarlos en un servicio compuesto. Adem´as, habr´ıa que tener en cuenta la inclusi´on de cierta inteligencia en los servicios para poder clasificar y tratar con todos los datos extra´ıdos de las b´usquedas. Adaptaciones a las pr´oximas versiones de la plataforma THOMAS. Como ya se ha comentado, la plataforma se encuentra en desarrollo. Por lo tanto, se hace necesario adaptar la aplicaci´on a los cambios y nuevas funcionalidades que puedan incluir las nuevas versiones de la plataforma THOMAS. Por otra parte, desde el punto de vista de la plataforma THOMAS, se pueden proponer los siguientes trabajos y mejoras: Comprobaci´on de los roles que posee un agente antes de permitir la ejecuci´on de un servicio. El funcionamiento de la plataforma est´a pensado para que un agente 100 CAP´ ITULO 5. CONCLUSIONES Y TRABAJOS FUTUROS pueda utilizar un servicio si posee los roles que se exigen. Este mecanismo de comprobaci´on aun no se encuentra en funcionamiento en la plataforma THOMAS y es bastante necesario. Composici´on de servicios. Ser´ıa ´util disponer de meta-servicios compuestos por otros meta-servicios simples. De esta forma ser´ıa m´as ´agil la actividad con la plataforma. Un ejemplo podr´ıa ser la fusi´on del meta-servicio Search Service con Get Profile yGet Process. As´ı pues, se podr´ıa obtener directamente el perfil y proceso del servicio que se haya encontrado con mayor ´ındice de coincidencia. Tolerancia a fallos. Se ha observado durante el desarrollo de este trabajo que la plataforma THOMAS es poco tolerante a fallos o ejecuciones err´oneas. Con lo cual, si hay comportamientos inesperados o alg´un argumento incorrecto en un meta-servicio se puede causar la detenci´on de alg´un agente intermediario. Inteligencia en los servicios web. La plataforma THOMAS podr´ıa disponer de alg´un servicio de ejemplo que tuviera mecanismos que incorporasen inteligencia artificial y b´usqueda inteligente en la web. Esto servir´ıa para que cualquier usuario o desarrollador pudiera ver el potencial de la plataforma y lo que se puede realizar. Ejecuci´on de agentes remotos. Podr´ıa existir alg´un ejemplo real en el que se puedan ejecutar agentes ubicados en distintas m´aquinas para demostrar que es viable esta opci´on. Bibliograf´ıa [1] E. Argente, V. Juli´an, and V. Botti. Mas modelling based on organizations. In 9th Int. Workshop on Agent Oriented Software Engineering (AOSE08), volume 5386, pages 16–30. Springer-Verlag, 2008. [2] C. Caceres, A. Fernandez, S. Ossowski, and M. Vasirani. Role-based service description and discovery. In International Joint Conference on Autonomous Agents and Multi-Agent Systems, 2006. [3] C. Carrascosa, A. Giret, V. Julian, M. Rebollo, E. Argente, and V. Botti. Service oriented multi-agent systems: An open architecture. In Autonomous Agents and Multiagent Systems (AAMAS), pages 1–2, 2009. [4] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl, 2001. [5] J. Dang and M. Hungs. Concurrent multiple-issue negotiation for internet-based services. In IEEE Internet Computing, volume 10 - 6, pages 41–49, 2006. [6] M. Dastani, V. Dignum, and F. Dignum. Role-assignment in open agent societies. In 2nd Int. Joint Conference on Autonomous Agents and Multi-agent Systems, pages 489–496, 2003. [7] M. Dean and G. Schreiber. OWL Web Ontology Language Reference. Editors, W3C Recommendation. http://www.w3.org/TR/owl-ref/, 2004. [8] M. Esteva, J. Rodriguez, C. Sierra, P. Garcia, and J. Arcos. On the formal specification of electronic institutions. In Agent Mediated Electronic Commerce, volume 1991, pages 126–147, 2001. [9] F. Garijo. Tecnolog´ıa de agentes: Experiencias y perspectivas para el desarrollo de nuevos servicios y aplicaciones. In Bole.tic, volume 24, pages 1–9, 2002. 101 102 BIBLIOGRAF´ IA [10] A. Giret, V. Julian, M. Rebollo, E. Argente, C. Carrascosa, and V. Botti. An open architecture for service-oriented virtual organizations. In Seventh international Workshop on Programming Multi-Agent Systems. PROMAS 2009, pages 23–33, 2009. [11] J. Gonzalez-Palacios and M. Luck. Towards compliance of agents in open multiagent systems. In Software Engineering for Multi-Agent Systems V, Lecture Notes in Computer Science. Springer, 2007. [12] D. Greenwood and M. Calisti. Engineering web service - agent integration. In IEEE International Conference on Systems, Man and Cybernetics, volume 2, pages 1918–1925, 2004. [13] D. Greenwood, M. Lyell, A. Mallya, and H. Suguri. The ieee fipa approach to integrating software agents and web services. In AAMAS ’07: Proceedings of the 6th international joint conference on Autonomous agents and multiagent systems, pages 1–7, ACM, New York, NY, USA, 2007. [14] Ana Mas. Agentes Software y Sistemas Multi-Agente. Conceptos, Arquitecturas y Aplicaciones. Pearson. Prentice Hall, 2005. [15] T.˜ Nguyen and R. Kowalczyk. Ws2jade: Integrating web service with jade agents. Centre for Intelligent Agents and Multi-Agent Systems, Swinburne University of Technology, 2005. [16] G. M. P. O’Hare and Nicholas R. Jennings. Foundations of Distributed Artificial Intelligence. John Wiley & Sons, Inc., New York, NY, 1996. [17] M. Sensoy, C. Pembe, H. Zirtiloglu, P. Yolum, and A. Bener. Experiencebased service provider selection in agent-mediated e-commerce. In Engineering Applications of Artificial Intelligence, volume 3, pages 325–335, 2007. [18] MO. Shafiq, A. Ali, HF. Ahmad, and H. Suguri. Agentweb gateway - a middleware for dynamic integration of multi agent system and web services framework. In 14th IEEE International Workshops on Enabling Technologies (WETICE 2005), pages 267–270, Link¨oping, Sweeden, 2005. IEEE Computer Society. [19] Y. Shoham. Agent-oriented programming. In Artificial Intelligence, volume 60(1), pages 51–92, 1993. BIBLIOGRAF´ IA 103 [20] K. Sycara, M. Paolucci, J. Soudry, and N. Srinivasan. Dynamic discovery and coordination of agent-based semantic web services. In IEEE Internet Computing, volume 8 - 3, pages 66–73, 2004. [21] K. Sycara, S. Widoffand, M. Klusch, and J. Lu. Larks: Dynamic matchmaking among heterogeneous software agents in cyberspace. In Jounal on Autonomous Agents and Multi-Agent Systems, 1982. [22] E. Del Val, N. Criado, M. Rebollo, E. Argente, and V. Julian. Service-oriented framework for virtual organizations. In International Conference on Artificial Intelligence (ICAI), volume 1, pages 108–114. CSREA Press, 2009. [23] LZ. Varga and ´ A. Hajnal. Engineering web service invocations from agent systems. In Multi-Agent Systems and Applications III, 3rd International Central and Eastern European Conference on Multi-Agent Systems, CEEMAS 2003, volume 2691, pages 626–635, Prague, Czech Republic, June 16-18, 2003. Proceedings, Springer, Lecture Notes in Computer Science. [24] M. Wooldridge. An introduction to Multiagent Systems. John Wiley and Sons Ltd, 2002. [25] F. Zambonelli, N. Jennings, and M. Wooldridge. Developing multiagent systems: The gaia methodology. In ACM Transactions on Software Engineering and Methodology, volume 12, pages 317–370, 2003.