AAAAAAAAAAAAAAAAAAAAAAAA ...journaldocs.iberamia.org/articles/491/article...

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARTICULO

Emparejamiento de Servicios Web Semanticos y su aplicacionen el dominio de trafico rodado.

J. Javier Samper, Francisco Matas

Instituto de Robotica, Universitat de ValenciaPolıgono de la Coma s/n,

46980 Paterna, Valencia, Spain.{jsamper,pacoma}@robotica.uv.es

Eduardo Carrillo

Universidad UNABCalle 48 Nro. 39-234,

Bucaramanga, Colombia,[email protected]

Resumen

En este artıculo se describe el sistema multiagente basado en estandares FIPA desarrollado para facilitar, asistir yoptimizar los procesos de anuncio, descubrimiento e invocacion de servicios web semanticos relacionados con lainformacion de trafico rodado. La funcion principal del sistema es proporcionar a sus clientes el servicio web que masse aproxime al que estos esten buscando, basandose para ello en su descripcion semantica mediante lenguaje DAML-S/ OWL-S. Las decisiones tomadas para encontrar el servicio buscado se apoyan en ontologıas DAML / OWL y unaextension de algoritmos de emparejamiento existentes. El sistema fue ideado en principio para ser usado en el area detrafico pero puede ser utilizado en cualquier otro dominio si se hace uso de las ontologıas adecuadas.

Palabras clave: JADE, DAML, OWL, DAML-S, OWL-S, sistemas multiagente, servicios web, web semantica, XML,emparejamiento, matchmaking, matchmaker, emparejador, web, FIPA, WSDL, UDDI.

1. Introduccion

La web inicial estaba caracterizada por la interaccioncon documentos, generalmente disponibles a travesde portales web, pero dentro de su evolucion han sur-gido los servicios web (SW) como un mecanismoque permite interaccion entre aplicaciones. El servicioweb es un componente software que puede procesarun documento XML recibido a traves de alguna com-binacion de protocolos de transporte y de aplicacion

estandar en Internet. En este contexto es muy impor-tante facilitar el proceso de descubrimiento de un ser-vicio que cumpla unas caracterısticas determinadas,y suele estar basado en la busqueda de descripcionesXML de los servicios disponibles. Es ası como se ha-ce por ejemplo en UDDI [32]. Pero debido a la falta deexpresividad de XML, dos descripciones iguales deun SW tienen un significado u otro dependiendo delcontexto en el que se encuentren. Para solucionar estacarencia se creo, a partir de las propuestas de la websemantica, la ontologıa de orden superior DAML-S,

Inteligencia Artificial, Revista Iberoamericana de Inteligencia Artificial. No 30 (2006), pp. 7-23.ISSN: 1137-3601. c©AEPIA (http://www.aepia.org/revista)

8 Inteligencia Artificial Vol. 10, No30, 2006

que mas tarde evoluciono a OWL-S (basadas en loslenguajes de marcado semantico DAML+OIL y OWL(Ontology Web Language) respectivamente [7] [35]para descripcion semantica de las capacidades de losservicios web. Estas ontologıas se utilizan para queagentes software puedan leer esas descripciones y ra-zonar sobre la forma de interactuar con los serviciosque describen, ademas de decidir cuales se acercanmas a sus necesidades. En este artıculo describimosnuestro prototipo de emparejador semantico de servi-cios web y su integracion en una plataforma multi-agente basada en estandares FIPA [11]. En la actua-lidad existen algunas propuestas de integracion paraemparejamiento de SW como las presentadas en [19],[9] y [6]. La arquitectura de integracion descrita en [6]emplea tecnicas de recuperacion de informacion, inte-ligencia artificial e ingenierıa de software para proce-sar la semejanza sintactica y semantica entre descrip-ciones de capacidad de servicios descritos en DAML-S. En nuestro caso tambien se utiliza DAML-S por-que en el momento en que fue desarrollado el sistemano habıa razonadores que funcionasen con OWL-S.La arquitectura propuesta en este trabajo se basa enel uso de sistemas multiagente, en el que un agentedenominado matchmaker o emparejador es el encar-gado de encontrar (de manera similar a un sistema depaginas amarillas) el servicio, simple o complejo queha sido expuesto por un proveedor y que satisface lasnecesidades del cliente a partir de los parametros de-finidos por este.

En el punto 2 se mostrara el dominio del proble-ma a resolver, en el punto 3 se introduciran los con-ceptos basicos para entender el funcionamiento de lasolucion propuesta para resolverlo, en el punto 4 sepresentaran los principales actores de nuestro sistemade emparejamiento, en el punto 5 se dara una visiongeneral del funcionamiento del sistema, en el punto 6se descompondra el sistema en capas par facilitar sucomprension, en el punto 7 se detallara el desplieguedel sistema, en el punto 8 se comentaran las pruebasrealizadas, en el punto 9 se mostrara un caso de usodel sistema y, por ultimo, en el punto 10 se daran al-gunas conclusiones a las que se ha llegado y se ha-blara sobre una posible continuidad del trabajo.

2. Dominio del problema a resol-ver

La difusion de informacion de trafico esta marcadapor la ausencia de vocabularios comunes que puedanser elegidos como nucleo o punto de partida para los

desarrolladores. Esto hace que el proceso de tratar ocompartir informacion entre distintos desarrolladores,incluso pertenecientes a la misma empresa, sea com-plejo, y aun mas si cabe entre diferentes administra-ciones y paıses. Otro problema importante es que lainformacion esta distribuida entre fuentes muy diver-sas, como pueden ser bases de datos y portales web.Ademas, este volumen de informacion distribuida esenorme, por lo que sera necesario tratarla de formaeficiente. El objetivo de nuestro prototipo de sistemafue gestionar esta informacion de trafico y ofrecerla alusuario de la forma mas eficiente, y para alcanzarlo,en primer lugar, se establecio un vocabulario comunsobre los conceptos relacionados con la informacionde trafico, conseguido mediante ontologıas. En segun-do lugar se busco una forma de homogeneizar el acce-so a toda esta informacion heterogenea, disponible enfuentes tan diversas, y se opto por utilizar SW que sir-viesen de intermediarios. En tercer lugar se debıa en-contrar un modo de decidir que SW satisfacıa en me-jor medida las necesidades de un usuario. Ni WSDL[37] ni UDDI [32] son de ayuda para la localizacionde servicios en funcion de lo que estos ofrecen, por loque se opto por describir semanticamente estos servi-cios utilizando DAML-S / OWL-S y se desarrollo unemparejador de estos servicios web semanticos capazde decidir cual de ellos se aproximaba mas al buscadopor el cliente. Este emparejamiento se baso en la pro-ximidad semantica (significado) de los conceptos bus-cados por el usuario y los ofrecidos por estos servi-cios. Ademas, todo esto se integro en una plataformamultiagente basada en estandares FIPA aprovechandoel middleware ofrecido por este tipo de plataformasy su capacidad de interaccion con otras que cumplaneste mismo estandar.

3. Estado del arte

3.1. Ontologıas para descripcionsemantica de servicios

OWL-S ( o DAML-S) define 3 ontologıas para la des-cripcion, invocacion y ejecucion de servicios. La on-tologıa Service Profile es usada para describir y anun-ciar el SW requerido por el usuario y ofertado por elproveedor respectivamente. La ontologıa Service Mo-del es usada para definir el modelo de proceso y ejecu-cion del servicio y nos sirve por tanto para saber comofunciona, y Service Grounding es usada para describircomo acceder al servicio, indicandonos como puedeser usado. Tanto DAML-S como OWL-S nos dan lonecesario para conseguir la representacion semanticade servicios basandose en DAML+OIL y OWL res-

Inteligencia Artificial Vol. 10, No30, 2006 9

pectivamente, los cuales soportan razonamiento sobreinclusion en taxonomıas de conceptos y permiten larelacion entre conceptos pudiendo expresar por ejem-plo que X es parte de Y, o de forma mas general, queexiste una relacion entre X e Y. Aunque tienen limita-ciones, son lo suficientemente expresivos como parapermitir la descripcion de un gran numero de servi-cios y realizar emparejamientos entre ellos.

3.2. Concepto de Servicio Web Semanti-co

La Web no solamente proporciona acceso a conteni-dos sino que tambien ofrece interaccion y servicios(comprar un libro, reservar una plaza en un vuelo, ha-cer una transferencia bancaria, simular una hipoteca).Los servicios web semanticos (SWS) son una lıneaimportante de la Web Semantica, que propone descri-bir no solo informacion sino definir ontologıas de fun-cionalidad y procedimientos para describir SW: susentradas y salidas, las condiciones necesarias para quese puedan ejecutar, los efectos que producen, o los pa-sos a seguir cuando se trata de un servicio compuesto.Estas descripciones procesables por maquinas permi-tirıan automatizar el descubrimiento, la composicion,y la ejecucion de servicios, ası como la comunicacionentre unos y otros.

Los SWS proponen extender las tecnologıas de SWtradicionales, en vıas de consolidacion, con onto-logıas y semantica que permitan la seleccion, integra-cion e invocacion dinamica de servicios, dotandolesası mismo de la capacidad de reconfigurarse dinami-camente para adaptarse a los cambios. Los SWS sonun nuevo paradigma de la computacion, definido ge-neralmente como el surgimiento de las descripcionesde SW con anotaciones de Web Semantica, para fa-cilitar la automatizacion del descubrimiento, compo-sicion, invocacion, y monitorizacion de los serviciosen un ambiente no regulado y caotico como es laWeb [22]. A partir de los esfuerzos de estandarizaciondel W3C y a traves de su grupo de interes SemanticWeb Services Interest Group [25] se esta fomentandola integracion de la tecnologıa de la Web Semanticay el trabajo de otros grupos sobre SW realizado enW3C. Una de las iniciativas mas importantes surgidasa partir de este trabajo ha tomado como base la laborde investigacion realizada por la coalicion DAML-S(DAML for Services), surgida en el ano 2001, la cualpropuso una ontologıa para la descripcion semanticade servicios basada en DAML+OIL (DAML-S), cu-ya ultima version (0.9) fue lanzada en mayo de 2003.A partir de noviembre de 2003 se desarrollo OWL-S,basado en el lenguaje de marcado ontologico OWL .

Actualmente esta iniciativa es el resultado de la unionde otras dos: Semantic Web Services Initiative (SW-SI) [24] y Semantic Web Services Language (SWSL)Committee [26]. OWL-S fue enviado a W3C para sureconocimiento en julio de 2004.

3.3. Emparejamiento

El matchmaking o emparejamiento es un proceso porel cual se emparejan caracterısticas requeridas por unparticipante y las ofrecidas por otro con el objetivode que la entidad encargada de realizar el empareja-miento pueda decidir cual de ellos se aproxima masa lo requerido. Para ello debera conocer los serviciosofrecidos por proveedores y sus caracterısticas, ası co-mo los requerimientos expresados por el cliente. Portanto el proceso general que se sigue en el empareja-miento de servicios ofertados y requeridos se basa enque cuando un agente envıa una peticion al matchma-ker (actor encargado de realizar el emparejamiento)mas tarde, este le devolvera como resultado informa-cion respecto al servicio que empareje con la descrip-cion dada en el requerimiento. El modelo y algoritmode emparejamiento semantico planteado en [28] es elque ha sido utilizado por la mayorıa de investigadorescomo fundamento para sus sistemas.

3.4. Grados de similitud o match

El grado de similitud depende de la relacion (toma-da de las ontologıas) entre los conceptos que se estancomparando, y generalmente se reduce a la mınimadistancia entre ellos en el arbol taxonomico. La fun-cion principal del algoritmo de emparejamiento queusamos consiste en determinar el grado de similitud odistancia semantica entre descripciones de servicios,tomando como base el conjunto de relaciones entreellos.

La denominacion de los grados varıa segun la litera-tura [2],[18],[28],[13]:

Exact: cuando los conceptos tanto en la peti-cion como en el anuncio son equivalentes.

Subclass of : determinado por la relacion sersubclase de. Cuando los conceptos en la peti-cion son subclase (relacion directa) de los delanuncio. (En [28] incluyen como exact mat-ching a este tipo de emparejamiento).

Subsumption: la cual puede ser de dos tipos:


• Plug-in o Contained: cuando los concep-tos en el anuncio A incluyen los de la pe-ticion P. Formalmente, (P ⊆ A). En estecaso, la peticion puede ser satisfecha de-bido a que los conceptos del anuncio, sonmas generales que los de la peticion, y portanto existe la posibilidad de que el clien-te pueda cumplir sus objetivos. Sin em-bargo, no se considera que exista una re-lacion de subclase directa (grado anterior)

• Subsume o Container: cuando los con-ceptos en la peticion incluyen los delanuncio; formalmente, (A ⊆ P). Este tipode emparejamiento no satisface comple-tamente la peticion pero puede ser con-siderado como una solucion parcial vali-da ya que puede permitir al cliente querealizo la peticion ir alcanzando parcial-mente sus objetivos o metas.

Fail ,nul o Disjoint: cuando no hay relacion deinclusion entre los conceptos; formalmente, (A∩ P)⊆ ⊥ .

Los autores de [14] introdujeron nuevos tipos de em-parejamiento que mas tarde fueron adoptados por Liy Horrocks [18] como extension a los anteriormenteexpuestos:

Intersection u Overlap. Si la interseccion de unanuncio A y una peticion P se satisface, es decirson compatibles; formalmente, ¬(A

⋂P ⊆⊥).

3.5. Diferentes sistemas e investigacionesrelacionadas

La base de toda la investigacion relacionada con elemparejamiento semantico de servicios, recae princi-palmente en los estudios de Ingenierıa de Softwarellevados a cabo por Zaremski y Wing en [38] y [39].

Sycara et al. desarrollaron LARKS [27], [29], en elcual los servicios son vistos como frames y sus slotsinput, output, inConstraints y outConstraints pue-den ser usados para describir los atributos esencia-les de un servicio. El proceso de emparejamiento enLARKS realiza tanto emparejamiento sintactico co-mo semantico, y se compone de un conjunto de filtros(independientes entre sı) que progresivamente restrin-gen el numero de anuncios candidatos a ser empare-jados.

En [19] se describe una aproximacion basada en on-tologıas que emplea las caracterısticas de una taxo-

nomıa de proceso. El algoritmo que empareja utili-za la relacion semantica codificada en la ontologıa deproceso al emparejar el modelo del proceso del servi-cio con requerimientos.

La aproximacion usada por [14] para emparejamien-to de servicios es un algoritmo basado en el arboldel subsumcion dado por un razonador de logi-cas descriptivas (DL). Las descripciones del servi-cio son especificadas en DAML+OIL y puesto queDAML+OIL se basa en DL, el razonador de DL esel corazon del algoritmo de emparejamiento. Los di-ferentes tipos de emparejamiento para un servicio Sse definen como:

conceptos equivalentes a S,

subconceptos de S,

superconceptos de S que son incluidos por elconcepto en la ontologıa de descripcion del ser-vicio,

los subconceptos de cualquier superconceptodirecto de S cuya interseccion con S sea satis-factoria.

El equipo Intelligent Software Agents Group de laCarnegie Mellon University (CMU) diseno una arqui-tectura basada en ATLAS (Agent Transaction Lan-guage for Advertising Services), lenguaje basado enDAML, para emparejamiento de servicios [30]. Esteutiliza dos filtros: emparejamiento de atributos fun-cionales para determinar la aplicabilidad de los anun-cios y emparejamiento de funcionalidades de servicio,para determinar si el servicio anunciado empareja elservicio requerido.

De nuevo en CMU [6], el DAML-S Matchmaker em-plea tecnicas de recuperacion de datos, de IA, y deIngenierıa de Software para procesar la semejanzasintactica y semantica entre descripciones de capa-cidad de servicios. Estas investigaciones son las quemas se han tomado como referencia para otros tra-bajos como [28], ya comentado anteriormente, cuyomodelo y algoritmo de emparejamiento semantico hasido utilizado por la mayorıa de investigadores comobase para sus sistemas, y que plantea un sistema deemparejamiento basado en la semantica descrita en elprofile de los servicios y en la utilizacion de los regis-tros UDDI para mantener las descripciones de estosservicios. Estas investigaciones hacen uso de la on-tologıa perfil del servicio y de DAML-S como len-guaje de especificacion para las descripciones del ser-vicio. Se asume que los servicios de la red anunciansus interfaces (inputs/outputs)(IO’s) usando la misma


ontologıa. En este proyecto [28] se aborda la impor-tancia para la clasificacion del emparejamiento de lassalidas. Un emparejamiento entre un anuncio y unapeticion de servicio consiste en emparejar todas lassalidas de la peticion con las del anuncio; y todas lasentradas del anuncio con las de la peticion. El moti-vo por el que la prioridad de los parametros de salida(outputs) es mayor, es debido a que es mas impor-tante el emparejamiento de lo que el cliente esperaobtener como resultado, es decir, la salida del servi-cio en cuestion. Una de las ideas mas importantes queaportan Paolucci et al. en su algoritmo para que tengaun mejor comportamiento, es la de que tanto clientescomo proveedores empleen las mismas ontologıas deconceptos para dar valor semantico a cada uno de losIO’s de sus profiles. De esta manera, se facilita la tareaal motor de inferencia o razonador, porque solo nece-sita que se carguen las ontologıas de conceptos queutilizaron para construir los profiles para poder medirel grado de similitud que tengan los IO’s que definie-sen.Han sido varios los investigadores que han basa-do su sistema de emparejamiento en este algoritmo,anadiendole algunas funcionalidades: Charlie Abela[2] desarrollo un sistema de emparejamiento basadoen el algoritmo que desarrollaron Paolucci et al. Esteautor hace uso de un algoritmo que usa dos operacio-nes de filtrado para realizar el emparejamiento. El pri-mer filtro limita el espacio de busqueda a las restric-ciones definidas por el usuario en la peticion (busque-da por ServiceProvider, ServiceCategory o Service-Name). El segundo filtro es un emparejamiento delas salidas que el usuario define en la peticion, per-mitiendose el uso de un solo filtro o ambos. En elresultado de un emparejamiento pueden darse variosservicios y por tanto se debera crear un rango para es-pecificar cual de ellos es el que mas se ajusta a lasnecesidades del cliente. A veces sera necesaria la in-tervencion de este para poder elegir aquel que consi-dere mas apropiado.

Otra aproximacion fue desarrollada por InformationManagement Group en la University of Manchester[18]. El prototipo descrito de su algoritmo de mat-chmaking tambien se basa en las descripciones deDAML-S. Utiliza el razonador Racer DescriptionsLogics para realizar emparejamientos semanticos en-tre los servicios, y utiliza JADE como plataforma deagentes. Como en el diseno de DALM-S Matchmaker,las peticiones del servicio en DAML-S se emparejancon los anuncios del servicio. Sin embargo, este algo-ritmo de emparejamiento no divide el procedimien-to en varias partes; en su lugar intenta encontrar unemparejamiento semantico directamente de los perfi-les de servicios especificados. En esta aproximacionlos perfiles son tratados como entidades enteras, y sus

componentes no son tratados por separado. Una vezmas al resultado del emparejamiento se le asocia uncierto grado de similitud.

Los brasilenos Ricardo Ferraz, Sofiane Labidi y Ber-nardo Wanghon [23] extendieron el algoritmo de em-parejamiento de Paolucci et al. En este caso el clientedefine las precondiciones que piensa que debe tenerel servicio para que emparejen en el mayor grado po-sible con las que los proveedores introducen en losprofiles, realizando el mismo algoritmo de empareja-miento que el de los IO’s. Incluyeron las precondicio-nes porque consideran que son unos parametros im-portantes a tener en cuenta en las negociaciones. Porejemplo puede darse el caso de SW que incluyan pre-condiciones que negocian el tipo de pago, o el tipode tarjetas de credito que admiten. Sin embargo estetipo de emparejamiento no se ha tenido en cuenta ennuestra propuesta, por la peculiaridad de los serviciosde informacion de trafico, marco en el cual se deci-dio probar nuestra arquitectura.

3.6. Ontologıas en trafico

Actualmente, existen vocabularios o lenguajes quedescriben conceptos y estructuras de datos relaciona-dos con trafico, pero son solo descripciones sintacti-cas, carentes de semantica. Por lo tanto, aunque exis-ten numerosos trabajos y desarrollos que hacen usode lenguajes de marcado XML (difusion de informa-cion, intercambio de informacion, modelado de trafi-co), tras un proceso previo de revision bibliografica,no se encontraron vocabularios que incluyeran ele-mentos semanticos para informacion de trafico vial.Surgio por tanto la necesidad de crear especificacio-nes semanticas (ontologıas) y hacer uso de ellas me-diante la construccion de diferentes prototipos.

¿Por que se necesitan ontologıas de trafico? El trata-miento informatico actual de la informacion de traficoes muy limitado y susceptible de ser mejorado desdedistintos puntos de vista. El esquema de representa-cion debe cumplir los siguientes aspectos:

ser interpretable por el ordenador y facilmenteintercambiable entre aplicaciones.

adherirse en sus aspectos sintacticos a losestandares de representacion de informacionexistentes.

permitir la obtencion de conocimiento noexplıcito a priori.

Si un usuario u operador del sistema necesita conocer


informacion especıfica sobre los accidentes aconteci-dos en una determinada carretera o localizacion, po-siblemente quiera saber detalles sobre los vehıculosimplicados, tipos de vıas etc., y por tanto este tipo deconsulta involucre no solo una base o fuente de co-nocimiento sino varias, de ahı la importancia del usode ontologıas, algunas de cuyas caracterısticas son ladistribucion y la posibilidad de inferir conocimientono explıcito a priori, es decir, podemos ir todavıa maslejos, y preguntar por ciertos elementos que en prin-cipio no han sido establecidos en este dominio, y queformaran parte de una especificacion en otro lugar queno tiene porque ser fısicamente el mismo. Otra carac-terıstica de las ontologıas que se puede explotar esla capacidad de estas para definir sin ambiguedad losconceptos. Gracias a esta, un concepto podra ser de-finido de forma unıvoca, de tal forma que aunque porejemplo, distintas organizaciones determinen diferen-tes significados para un mismo termino, el receptorde la informacion siempre obtendra el significado co-rrecto correspondiente.La construccion del modelo consiste en tres fases:

adquisicion del conocimiento: identificacionde las clases o terminos basicos y sus propie-dades,

definicion: identificacion de las relaciones en-tre las clases y,

especificacion de restricciones: identificacionde las restricciones que limitaran la manera enla que las descripciones pueden ser formadas.

Este proceso sera iterativo, con sucesivos refinamien-tos.

Para abordar el problema del desarrollo de una onto-logıa de trafico rodado se ha planteado la definicionde subdominios que se relacionaran entre sı. En estesentido los subdominios de relevancia que han sidodefinidos son los siguientes:

Clasificacion de Vıas (Autopista Libre, Auto-pista de Peaje, Conexion, Acceso, Ronda etc.)

Clasificacion de Vehıculos (Ciclomotor, Turis-mo, Camion etc.)

Localizacion (Area, Punto, Tramo, Metrica,Sentido etc.)

Geografıa (Poblaciones, Paıses etc.)

Sucesos (Accidentes, Incidentes, Medidas etc.)

Personas (Peaton, Conductor, Titular deVehıculo etc.)

Rutas (Ruta Urbana, Ruta Interurbana etc.)

A su vez hay que destacar la reutilizacion de vocabu-larios ya definidos como FOAF [33]y GEO [34] y laampliacion de otros como Time [3].

Una vez construidas las diferentes subontologıas detrafico se fusionan en una ontologıa de conceptos detrafico llamada (Traffic Ontology) que es la que reunetodos los conceptos principales y sus relaciones.

Los idiomas utilizados para la construccion de las on-tologıas fueron el castellano y el ingles. Para lograrel objetivo de ontologıa multilenguaje se pueden usarvarias tecnicas como describir el mismo conocimien-to en varias ontologıas, cada una en una lengua dis-tinta, manteniendo toda la estructura y semantica des-crita en la ontologıa original, y haciendo uso del ope-rador de equivalencia entre terminos y relaciones. Atraves de un requerimiento de idioma en ingles y apartir de una instancia en castellano, seremos capacesde obtener una definicion en el idioma requerido. Siun cliente interacciona con el sistema, determinandoque el idioma elegido es el ingles, la peticion especifi-cara este requerimiento, de tal forma que la informa-cion resultado sera traducida (en realidad recuperadaen castellano, pero documentada en ingles). Otro pro-blema distinto sera el hecho de recuperar informaciondesde servicios o web Sites de otros paises o adminis-traciones. La solucion a este problema pasa por des-cribir estas Web sites como servicios web especıficos,donde el uso de ontologıas en dicho idioma ayudarantanto en la busqueda como en el resto de tareas. Otraposibilidad es hacer uso de atributos XML:lang en loscomentarios, que posibiliten en una misma ontologıala descripcion de sus terminos en varios idiomas. Sinembargo, esta ultima tecnica no funciona en algunosrazonadores como RACER debido a la limitacion desu lenguaje de requerimientos para acceder a deter-minados campos como rdf:comment de la descripciondel concepto.

4. Emparejador de ServiciosWeb de Informacion de Trafico(ESWIT)

ESWIT es el prototipo desarrollado para introducir lasemantica en el emparejamiento de SW. Se opto poruna aproximacion basada en agentes distribuidos, y seselecciono FIPA como el estandar a seguir. Como en-torno de desarrollo se utilizo JADE [31] (Java Agent


Development Framework), por cumplir lo propuestopor FIPA en su modelo de referencia de administra-cion de agentes [12], donde se establecen los elemen-tos basicos de los que debe constar un sistema mul-tiagente. Debido a que Internet es un entorno abiertodonde los orıgenes de la informacion, los enlaces decomunicacion y los mismos agentes pueden aparecery desaparecer en cualquier momento, existe la nece-sidad de ayudar a los agentes solicitadores (agentesque buscan un servicio determinado) a encontrar a losagentes proveedores. A los agentes que ayudan a lo-calizar a otros agentes se les denomina middle agents(intermediarios). Los autores de [17] identifican dife-rentes tipos de middle agents en Internet, como sonlos matchmakers (servicios de paginas amarillas), obrokers.En este caso se opto por una aproximacion basada enmatchmakers.

Siguiendo el modelo de intermediacion matchmakerse identificaron durante la fase de analisis los siguien-tes actores, que serıan los componentes basicos denuestro sistema:

Cliente o Usuario: es la persona que usa el sis-tema.

Agente cliente: agente con el rol de cliente. Re-presenta al usuario dentro de la plataforma, yproporciona al agente emparejador la descrip-cion del servicio que busca.

Proveedor: empresa, organizacion o personaque anuncie un servicio en la plataforma me-diante un agente proveedor.

Agente proveedor: agente con el rol de provee-dor de servicio web. Representa al proveedordentro de la plataforma.

Agente emparejador: agente que tiene el rol dematchmaker, es el encargado de emparejar enfuncion de su proximidad semantica (grado desimilitud), descripciones de servicios recibidasde clientes con descripciones de servicios anun-ciados por los proveedores.

Facilitador de directorio (DF): agente inclui-do en las plataformas que cumplen el modeloFIPA. Aunque en esta especificacion es opcio-nal, ha sido utilizado en nuestro sistema para fa-cilitar las tareas de administracion de nuestrosagentes, como un componente de tipo paginasamarillas.

Servicio web: servicio web externo a la plata-forma, el cual es representado dentro de ella porun agente proveedor (puede haber mas de uno).

Emparejador de servicios: en funcion de ladescripcion de sus capacidades, basado ensemantica y utilizado por el agente empareja-dor.

5. Vision general del sistema e in-teracciones entre los distintosagentes que lo componen

Las fases que resumen el funcionamiento del sistemason las siguientes:

1. Cuando se anuncia un nuevo servicio, en primerlugar su agente proveedor, representante de es-te servicio dentro de la plataforma, se registraen el DF. A continuacion el DF avisa al agenteemparejador y este solicita al nuevo proveedorla URI (Uniform Resource Identifier) [36] de ladescripcion semantica del servicio que ofrece.

2. Al lanzar un usuario un agente cliente le pa-sa como parametro la URI de la descripcionsemantica del servicio que busca en la plata-forma. Este agente cliente se pone en contactocon el agente emparejador y le proporciona laURI de la descripcion de este servicio. El agen-te emparejador interroga al razonador y con-trasta la descripcion del servicio buscado contodas las de los servicios disponibles, decidien-do que descripcion es la que mas se ajusta alservicio buscado, e informando al agente clien-te de la URI de la descripcion de este servicio.

3. Una vez el agente cliente conoce la descripcionque mas se parece semanticamente al servicioque busca, genera, a partir de ella, la interfazgrafica para recoger los datos de entrada nece-sarios para poder hacer la correcta invocaciondel servicio que describe.

4. Una vez completado el formulario con los da-tos de entrada requeridos, el agente cliente loinvoca directamente con esos datos y recoge elresultado que devuelve.

5. Llegados a este punto el agente cliente vuelve aponerse en contacto con el usuario y le muestrael resultado de la invocacion del servicio.

Para hacer posible estas interacciones es necesario elestablecimiento de comunicaciones entre los distintosagentes que forman parte del sistema. Las principa-les comunicaciones establecidas entre estos agentes


se detallan en los siguientes diagramas AUML [10]de protocolo, todos ellos con actos comunicativos es-tandarizados por FIPA. Estos ejemplos de comunica-cion entre agentes son los que mas se dan durante elfuncionamiento de nuestro sistema.

Figura 1. Emparejador lanzado cuando ya hayproveedores activos

La figura 1 representa al caso en el que el agente em-parejador es lanzado cuando ya hay agentes provee-dores activos en la plataforma.

1. En primer lugar el agente emparejador se regis-tra en el facilitador de directorio.

2. Despues de recibir la notificacion de que el re-gistro se ha realizado sin problemas solicita alfacilitador de directorio ser avisado cada vezque un agente del tipo proveedor se da de al-ta.

3. Una vez solicitado el aviso pregunta al facilita-dor de directorio por todos los agentes de tipoproveedor que ya estan registrados.

4. Cuando recibe la lista de agentes de tipo pro-veedor ya registrados, el agente emparejadorsolicita a cada uno de ellos la URI del profileque describe el servicio al que representa.

Figura 2. Proveedores lanzados despues deemparejador

En la figura 2 se muestra el caso en el que los agen-tes proveedores se lanzan despues de ser iniciado elagente emparejador.

1. Cuando un agente de tipo proveedor aparece enla plataforma lo primero que hace es registrarseen el facilitador de directorio.

2. Como vimos en el diagrama anterior el agenteemparejador solicita ser avisado cuando agen-tes de tipo proveedor se registren, por lo queel facilitador de directorio notificara al agenteemparejador este nuevo registro.

3. El agente emparejador pedira entonces al nue-vo agente proveedor que le de la URI del profileque describe el servicio al que representa.

4. El agente proveedor proporciona al agente em-parejador la URI solicitada en el paso anterior.


Figura 3. Cliente lanzado cuando hay agenteemparejador y proveedores en el sistema

En la figura 3 se puede observar el caso en el que elcliente es lanzado cuando ya hay un agente empareja-dor y agentes proveedores en el sistema.

1. Cuando el cliente es lanzado en la plataforma seregistra en el facilitador de directorio y le pre-gunta cual es el agente emparejador por defec-to.

2. Una vez el cliente conoce que agente empare-jador debe utilizar le pide que empareje la URIdel profile que describe el servicio que buscacon las URIs de todos los servicios disponibles.

3. Cuando el agente cliente recibe la URI del ser-vicio que mas se parece semanticamente al quebusca lo invoca y obtiene el resultado.

6. Descomposicion en capas delsistema

El sistema desarrollado puede descomponerse en laestructura de capas mostrada en la figura 4. Se pue-de observar como la Plataforma Multiagente esta pre-sente en todas las capas aunque no todos los compo-nentes del sistema forman parte de ella. El facilitadorde directorio no ha sido incluido en esta estructura de

capas por ser propio de JADE. El sistema esta for-mado por agentes encargados del emparejamiento deservicios, agentes que representan a clientes dentro dela plataforma y agentes que representan a proveedoresde servicios.

Figura 4. Estructura de capas del sistema.

Trataremos ahora de exponer con mayor detalle cadauna de estas capas y los diferentes elementos que lascomponen.

6.1. Capa Usuario

6.1.1. OntoService

La primera necesidad que surgio fue la de encontraruna herramienta que combinase la visualizacion deontologıas con la creacion de perfiles de busqueda,por lo que se decidio implementar una herramienta,a la que se le llamo OntoService [15], basada en laintegracion de capacidades para definicion de perfilesde servicios Web semanticos con visualizacion y ve-rificacion de consistencia de los conceptos sobre loscuales interaccionarıa un determinado servicio. En lafigura 5 se puede observar la interfaz grafica principalde OntoService.

En relacion con herramientas para descripcion deSWS las principales propuestas que fueron encon-


tradas son A-Match [4] y OWL-S Editor [5] deCarnegie-Mellon University.

La herramienta implementada Ontoservice tiene dosfuncionalidades independientes, a la vez que comple-mentarias. Por un lado es un visualizador/verificadorde ontologıas, las cuales pueden estar descritas indi-ferentemente en el lenguaje DAML+OIL o bien enOWL, y por otro, es una herramienta de busqueda deservicios a partir de un perfil de busqueda generadoautomaticamente.

Figura 5. Interfaz grafica de OntoService.

Se genera el fichero profile a partir de una plantilla,ya que cualquier requerimiento de busqueda se ba-sara exclusivamente en la informacion contenida enel. En esta fase de funcionamiento del sistema solo esnecesario conocer la descripcion del servicio (profile),aun no hace falta saber como usarlo o acceder a el. Elusuario puede almacenar esta plantilla en el disco du-ro o bien, dado que la herramienta puede integrarse enuna plataforma de agentes, realizar el envıo del perfilgenerado a un agente encargado de llevar a cabo labusqueda del SW e incluso lanzar la ejecucion de esteagente.

Utilizamos por tanto Ontoservice para que el clientedefina el servicio que busca, genere el perfil que lodescribe y lance un agente cliente dentro de la plata-forma con este nuevo perfil generado.

Debido a los recursos necesarios para el correcto fun-cionamiento de OntoService se opto por no integrarlodentro de la plataforma y separarlo del agente cliente.

6.1.2. Agente Cliente

Se decidio crear un agente cliente que recibiese unaURI de descripcion del servicio generada por ejem-plo por OntoService en funcion de los datos introdu-cidos por el usuario, pudiendo ser OntoService el quelanzase a este agente dentro del sistema. El agentecliente es por tanto el representante del cliente den-tro de la plataforma. Indica al agente emparejador laURI de la descripcion del servicio que busca. Unavez obtenida la URI de la descripcion semantica delSW que satisfaga sus necesidades, extrae de su archi-vo grounding asociado, la informacion necesaria pararealizar su invocacion. Se consiguio implementar uncliente generico para invocar cualquier servicio, sinnecesidad de recompilar la interfaz grafica cada vez.Ademas, se invoca al servicio dinamicamente, sin ne-cesidad de tener un stub para cada posible servicio.Esto es necesario porque los servicios aparecen y des-aparecen dinamicamente en la plataforma y serıa in-viable tener preparado un cliente para cada uno delos posibles servicios que en algun momento deter-minado puedan estar disponibles. Despues del empa-rejamiento se accede al archivo grounding asociadoal profile con el que el cliente haya sido emparejado,para extraer de el la URI de la descripcion wsdl [37]asociada al servicio. Una vez obtenido el archivo wsdlse procede a la invocacion, y el resultado es mostradoal cliente en una interfaz disenada para ello.

6.2. Capa Planificacion

6.2.1. Agente emparejador (matchmaker)

Este agente emparejador puede servir como alterna-tiva o complemento a UDDI y tiene como principalcaracterıstica el hecho de estar basado en semantica.Para facilitar la construccion de este agente se desa-rrollo un emparejador de descripciones semanticasusado desde nuestro agente emparejador. Este empa-rejador se encarga de recibir URIs de descripciones depeticiones de servicios y contrastar su contenido conlas descripciones de los servicios anunciados para, deesta manera, identificar cual de ellos se acerca mas alas necesidades del cliente. A cada pareja obtenida sele asigna un peso que indica la proximidad semanticaentre los dos conceptos que se relacionan. Este pesose obtiene interrogando a un razonador sobre la je-rarquıa definida por una ontologıa de conceptos quedefine el vocabulario comun a utilizar. Las peticionesde clientes y los nuevos anuncios o bajas de serviciosofrecidos son gestionados dinamicamente. Tanto lasontologıas como las descripciones de servicios utili-zadas estan orientadas a servicios de trafico, pero el


emparejador puede trabajar con cualquier ontologıasin necesidad de hacer modificaciones.

Figura 6. Diagrama de despliegue del emparejadorsemantico.

6.2.2. Algoritmo utilizado por el emparejador

Nuestro emparejador de servicios (matchmaker)esta basado en el algoritmo descrito en el artıculo[28], que es la base de la mayorıa de los ultimos tra-bajos sobre este tema. Su despliegue puede observarseen la figura 6. Este algoritmo, para realizar el empare-jamiento, utiliza principalmente la informacion conte-nida en los profiles DAML-S/OWL-S de las definicio-nes de peticiones de clientes y de anuncios de provee-dores. Aprovecha al maximo las capacidades propor-cionadas por la ontologıa de descripcion de serviciosy constituye una mejora en relacion con propuestasexistentes. La principal aportacion han sido los dife-rentes grados de emparejamiento que permitieran em-parejamientos flexibles, la utilizacion de parametrosno funcionales, ası como los diversos filtros usados,algunos de los cuales no habıan sido considerados entrabajos de otros autores. Las diferencias mas impor-tantes entre nuestro algoritmo y los de trabajos an-teriores se pueden observar en los grados de empa-rejamiento ya que en estos eran demasiado generales,por lo que se propuso una version compuesta por sietegrados de emparejamiento que detallamos a continua-cion, en orden descendente de importancia:

Exacto: los conceptos definidos por el cliente ypor el proveedor son los mismos.

CsubclaseP: dentro del arbol de la taxonomıade conceptos la distancia entre el concepto de-mandado por el cliente y el ofrecido por el pro-veedor es igual a 1, siendo por tanto, el descritopor el cliente, subclase directa del que propor-ciono el proveedor. En este caso el proveedorofrece un concepto mas general que el que pideel cliente. El concepto del cliente es mas restric-tivo pero esta incluido en el que proporciona elproveedor.

PsubclaseC: el concepto descrito por el provee-dor es subclase directa del que pide el cliente,es decir, el proveedor ofrece un concepto masrestrictivo que el demandado por el cliente.

PsubsumeC: el concepto descrito por el clien-te se encuentra dentro del subarbol de concep-tos descendiente del definido por el proveedor.Serıa equivalente al Plugin definido en [28]aunque se diferencia de el en que no permiteque el cliente especifique el nivel de profundi-dad maximo hasta el que llegara la busqueda.Se ha optado por no permitir al cliente espe-cificar esto porque consideramos que concep-tos a distancias mayores o iguales a 3 nivelesno tienen practicamente relacion semantica, de-bido al modo en que se construyen las jerar-quıas de conceptos. Por ello se ha decidido fi-jar la profundidad maxima en dos niveles, porlo que solo se comprueba si el concepto defi-nido por el cliente es como maximo ”nieto”delconcepto del proveedor. De no hacerlo ası, au-mentarıa el riesgo de falsos positivos y por tan-to, podrıamos obtener servicios como validos,cuando la relacion semantica entre el concep-to que se provee y el que pide el cliente es tanlejano semanticamente que no responde a lasexpectativas de este.

CsubsumeP: el concepto descrito por el pro-veedor se encuentra dentro del subarbol de con-ceptos descendiente del definido por el cliente,es decir, es el caso inverso al anterior, y es equi-valente al grado Subsume definido en [28]. Co-mo en el caso anterior, aquı tambien se limita ados niveles de profundidad la comprobacion desi el concepto demandado por el cliente incluye(subsume) al ofrecido por el proveedor.

ChermanoP: el concepto proporcionado por elcliente y el del proveedor tienen restriccionesen comun en alguna propiedad que ambos po-seen, y ademas, tanto el concepto ofrecido por


proveedor como el demandado por el clienteson hijos del mismo padre, es decir, son con-ceptos ”hermanos”.

Fail: cuando no se cumple ningun caso de losanteriores, es decir el concepto del proveedor yel de cliente no tienen relacion alguna.

El motivo de este orden para los casos de subclase, esdecir, porque CsubclaseP es mejor grado que Psub-claseC, es debido a que consideramos mas importanteque el proveedor ofrezca un producto menos restric-tivo que el cliente, ya que en este caso puede sucederque tambien ofrezca lo que solicita el cliente. En casocontrario, si un proveedor ofrece algo mas restrictivoque lo que solicito el cliente, puede que a este no leinterese. El caso del orden entre PsubsumeC y Csub-sumeP es analogo solo que considerando una mayordistancia en el arbol de la taxonomıa de conceptos es-pecificados en la ontologıa.

Tambien realizamos un primer filtrado en funcion delparametro que describe la calidad del servicio busca-do por el cliente para reducir el espacio de busqueda.

Ademas el algoritmo de Paolucci et al. no aprovechaotras propiedades de la descripcion del perfil (profi-le), como son los parametros no funcionales, que tam-bien aportan informacion semantica del SW, por loque uno de los objetivos fue cubrir este vacıo. Nuestroalgoritmo emparejador intenta aprovechar al maximolas posibilidades de profile, con el fin de hacer usode todas las capacidades de los servicios, descritassemanticamente. A continuacion se describe que fil-tros se han desarrollado para los diferentes parametrosno funcionales:

filtro para region: con el se comprobara si elradio geografico dado por el cliente es el mis-mo que el proporcionado por el proveedor.

filtro para calidad de servicio: consiste encomprobar en el repositorio si la calidad queaportan los SW es la misma que la solicitadapor el cliente.

filtro para nombre de servicio: en esta consul-ta se comprueba si el cliente encuentra algunservicio en particular con el nombre que pro-porciono. Este emparejamiento es sintactico, yaque, tal y como esta definida la propiedad ser-viceName en la subontologıa Profile, tiene co-mo rango de valores el datatype String del XMLSchema, con el que solo se pueden hacer com-paraciones sintacticas.

filtro para nombre del proveedor: permitecomprobar si el servicio web lo provee la em-

presa en la que esta interesado el cliente. Aligual que en el anterior, solamente se puedenhacer comparaciones sintacticas.

Estos filtros son utilizados a la hora de asignar pesosa las parejas obtenidas en el emparejamiento, lo queayuda a aumentar la precision a la hora de elegir elservicio mas parecido al buscado.

6.3. Capa Clasificacion

La decision de que servicio se asemeja mas semanti-camente al servicio buscado se realiza consultando unrazonador que infiere sobre ontologıas que acumulanconocimiento sobre el dominio del problema. En es-te proceso intervienen los siguientes elementos queconstituyen esta capa:

6.3.1. Razonador

Como razonador se utilizo BOR [20], el cual esta ba-sado en descripciones logicas y tiene soporte para in-ferencias sobre instancias y sobre conceptos. Este ra-zonador puede ser usado tanto con ontologıas escri-tas en DAML+OIL (con algunas restricciones), comocon ontologıas escritas en la especificacion OWL Li-te. Ademas se puede utilizar como plugin por Sesame[21].

6.3.2. Repositorio

Como repositorio (almacen de ontologıas) se uti-lizo Sesame, debido a que permite anadir y elimi-nar informacion escrita en RDF , y puede almace-nar esta informacion en cualquier base de datos. Sesa-me soporta tres lenguajes de consulta, RQL, RDQL ySeRQL (Sesame RDF Query Language), para accederal conocimiento. Permite la interoperabilidad con unrazonador de DL. Sesame tiene como caracterısticadestacable el poder ser usado con cualquier tipo de ba-se de datos, ya sea relacional, orientada a objeto o dealmacenamiento de tripletas. En nuestro caso se uti-liza Mysql. Para poder utilizar archivos DAML+OILse utilizo el plugin de Sesame llamado SeBOR (Sesa-me+BOR) [20].


6.3.3. Lenguaje de consultas

Las consultas utilizadas para extraer informacion utilpara el emparejamiento fueron realizadas medianteSeRQL .

6.4. Capa de Recursos

Esta capa esta representada exclusivamente por losagentes de tipo proveedor y los servicios web a losque representan.

Figura 7. Diagrama de despliegue del sistema.

6.4.1. Agente Proveedor

Es el mas simple del sistema. El proveedor que quieraanunciar un servicio dentro de la plataforma debe lan-zar este agente pasandole como parametro la URI dela descripcion de ese servicio. Ademas de registrarseen el DF como tipo proveedor, solo debe planificar uncomportamiento que se encargue de enviar la URI delprofile del servicio que represente al agente empareja-dor cada vez que este se lo solicite, siempre siguiendolos actos comunicativos de los diagramas de protoco-lo. En la subcapa inferior de las dos que forman lacapa de recursos estarıan situados los SW anunciados

por los agentes proveedores dentro de la plataforma.Estos SW no estan por tanto integrados dentro del sis-tema multiagente, son servicios web tradicionales.

6.4.2. Servicio Web utilizado en las pruebas

En un escenario de funcionamiento real, el sistemadeberıa tener una serie de SW registrados y poderdecidir, en funcion de los perfiles de servicio que losdescribiesen, cual de ellos es el que mejor satisface alcliente. Para comprobar el correcto funcionamientodel ciclo completo de anuncio, descubrimiento e in-vocacion, hubo que crear un SW de prueba, ya que,hasta donde llego la revision bibliografica, no encon-tramos ninguno relacionado con el area informacionde trafico. Para ello se opto por adaptar la informa-cion referente a previsiones de trafico de la web de laDireccion General de Trafico (DGT) para ser accedi-da a traves de un SW creado por nosotros.

El servicio que implementamos tenıa dos compo-nentes:

Agente Actualizador: La captura de datos dela Web de la DGT y su tratamiento para poderser utilizados desde nuestro SW podrıa habersehecho de muchas formas, pero nosotros opta-mos por que un agente lanzado tambien en laplataforma se encargase de este trabajo. En es-te agente de tipo wrapper se definio una tareacon un temporizador, inicializado al ser lanza-do, el cual periodicamente extrae informacionde la web y la deposita en un repositorio SE-BOR. La extraccion de la informacion se hacecon las librerıas WebL [8] y un script generadopara ellas que convierte los datos extraidos dela web a formato DAML+OIL.

Servicio Prevision del estado del trafico: Paragenerar la estructura basica de nuestro servicioweb se utilizaron las herramientas de ApacheAXIS [1] y se completo con llamadas al codigousado para calcular la prevision a partir de losdatos almacenados en el repositorio SEBOR. Elcontenedor de servlets usado por Axis fue Apa-che Tomcat.

7. Despliegue del sistema

El diagrama de despliegue del sistema con el servicioweb creado por nosotros puede observarse en la figura7.


Se puede apreciar como la plataforma de agentesesta distribuida, existiendo varios contenedores situa-dos en distintos ordenadores que en conjunto for-man el sistema multiagente. Tambien puede obser-varse como la aplicacion OntoService, utilizada paraayudar a la creacion de profiles de servicios buscadospor clientes e iniciar agentes cliente, esta fuera de laplataforma de agentes JADE, siendo por tanto un pro-grama externo a ella. Lo mismo sucede con el servicioweb de informacion sobre previsiones de trafico, quetambien esta fuera de la plataforma y es accesible atraves de un servidor de aplicaciones Apache Tom-cat. Los archivos profile, process, grounding, servicey wsdl utilizados para describir servicios son acce-sibles por Web gracias a servidores web Apache, aligual que los archivos profile que describen serviciosbuscados por clientes. El razonador es accedido por elemparejador y por el servicio web tambien a traves deApache Tomcat. El agente actualizador esta dentro dela plataforma y cada cierto tiempo extrae informacionde la pagina Web de la DGT, pero no interviene enlas tareas de anuncio, descubrimiento e invocacion deservicios web.

8. Pruebas realizadas

Para comparar nuestro algoritmo con el que nos sir-vio como base [28] se implementaron ambos y secomparo su funcionamiento dentro del sistema. Pao-lucci et al. no distinguen grados fraternales, y la in-clusion de comprobaciones de conceptos hermanosera una de las mejoras que anadimos, por esta razon serealizaron pruebas encaminadas a mostrar la precisionde los dos algoritmos a la hora de encontrar concep-tos similares a los buscados por el cliente. Se pudocomprobar que nuestra version tenıa en algunos ca-sos una mayor precision, debido justamente al hechode considerar conceptos con grado de similitud frater-nal. El segundo tipo de pruebas realizadas estuvieronencaminadas a averiguar el tiempo de respuesta delsistema utilizando los dos algoritmos. En este caso seaprecio el aumento de rendimiento gracias al uso delos diversos filtros anadidos a nuestra version. Aun-que nuestro algoritmo en el peor de los casos es mascostoso, debido a las comparaciones necesarias paratener en cuenta las relaciones fraternales en la taxo-nomıa de conceptos, si consideramos un caso tıpicoen el que solo el 20 % de los anuncios pertenezcana la misma categorıa de la peticion, la respuesta deambos es similar teniendo en cuenta tal y como seindico anteriormente, que la precision del nuestro esmayor. La grafica de la respuesta temporal correspon-diente a este caso puede observarse en la figura 8. Paramas informacion sobre las pruebas realizadas puede

consultarse [16].

Figura 8. Pruebas de tiempo en la obtencion deemparejamiento.

Por ultimo, un estudio de factibilidad en el que se re-cojan las opciones y mejoras de este sistema con res-pecto a los actuales sistemas de publicacion y busque-da de informacion de trafico, como la Web, Wap, etc.,permitira obtener como resultado ciertos valores quenos posibiliten establecer una valoracion objetiva delas ventajas de este nuevo sistema en la vida real y suposible aplicacion a traves de las diferentes Adminis-traciones.

9. Caso de uso simple

A continuacion se detalla una de las pruebas del sis-tema realizada para comprobar que el prototipo desa-rrollado era funcional. Las pruebas se realizaron conun profile que describıa al servicio prevision y otro deun servicio ficticio llamado TraficoCatProfile. El pro-file que describıa al servicio prevision fue generadocon la herramienta OntoService, y el agente clientefue lanzado desde esta herramienta pasandole comoparametro la URI del profile generado.

Descripcion del caso de uso:


En primer lugar, se lanzo el contenedor principal de laplataforma, y despues el agente Sniffer de JADE paraespiar las comunicaciones entre los agentes que iban air siendo iniciados. Posteriormente se lanzo el agenteemparejador (al que llamamos Matchmaker) en otrocontenedor (en este caso llamado Container-1). Unavez lanzado el agente matchmaker se inicio el pro-veedor que representaba en la plataforma al servicioprevision. Despues se lanzo otro contenedor con unagente proveedor que representaba al servicio ficticio.El ultimo agente que se inicio fue el agente cliente, alque se le paso como parametro la URI de un profilemas parecido semanticamente a nuestro servicio pre-vision. En la figura 9, que muestra la interfaz graficadel Sniffer, se pueden observar las interacciones entrelos distintos agentes de la plataforma.

Figura 9. Agente Sniffer durante la prueba.

El emparejador, tras contrastar el profile recibido delcliente con todos los que tenıa en su repositorio, de-cidio que el correspondiente a nuestro servicio previ-sion era el que mas se le parecıa semanticamente. Enese momento el agente emparejador notifico al agentecliente la URI del servicio prevision y el agente extra-jo de este profile, ayudandose de un analizador (par-ser), despues que el usuario pulsase sobre el boton ge-nerar, la informacion necesaria para construir dinami-camente una interfaz grafica para que el usuario intro-dujese los parametros necesarios para realizar la in-vocacion. En la figura 10 se puede observar como losparametros eran introducidos en la interfaz generadadinamicamente.

Figura 10. Cuadro de dialogo generado dinamicamente.

En ese momento el cliente obtuvo con el parser elfichero wsdl enlazado con el archivo grounding delservicio, lanzo el invocador dinamico y recogio losresultados de la invocacion para mostrarlas en su in-terfaz grafica, como se puede observar en la figura 11.

Figura 11. Interfaz grafica mostrando el resultado de lainvocacion.

10. Conclusiones y trabajo futuro

Se ha analizado, disenado, implementado y proba-do un sistema multiagente basado en la interaccioncon SWS que constituye una aportacion academica aldesarrollo de la ingenierıa de la web del futuro, la WebSemantica. Teniendo en cuenta la gran inmadurez yfalta de estabilidad y control de compatibilidad haciaatras de las herramientas disponibles actualmente pa-ra los desarrollos de Web Semantica en forma de razo-nadores, bibliotecas, etc., se ha tenido gran dificultadpara conseguir una solucion estable. Aunque se ha lo-grado un prototipo funcional, este esta aun muy lejosde lo deseable para una posible explotacion comer-cial.La plataforma final permite que agentes clientes so-liciten a agentes emparejadores la busqueda de SWacordes con las capacidades semanticas que estanbuscando, para despues poder invocarlos. Para con-seguir esto se ha propuesto un algoritmo de empare-jamiento semantico basado en las caracterısticas quepuede definir un servicio web en el profile de su des-cripcion semantica, el cual puede haber sido especi-ficado mediante la herramienta OntoService. En unfuturo se pretende que el sistema utilice la recomen-dacion de OWL aportada por el W3C [35], por lo quesi BOR no es adaptado para poder utilizarla serıa ne-cesario buscar una alternativa a este razonador.


Actualmente existe una percepcion general por partede la comunidad involucrada en este tipo de sistemasen que los Servicios Web pueden crear nuevas opor-tunidades de negocio y generar beneficios a largo pla-zo. Aunque un elevado numero opina que estos siste-mas aun no estan preparados para entornos de misioncrıtica y produccion. En general, coinciden en resaltarla importancia de los Servicios Web en la comunica-cion de las aplicaciones y Sistemas de Informacion dela empresa. Otro aspecto importante a destacar es laconformidad de estos hacia un conjunto de estanda-res abiertos aceptados por la industria. Los entornosde desarrollo seran fundamentales para proyectos dedesarrollo de Servicios Web y Web Semantica. Lo di-cho anteriormente es totalmente extrapolable a cual-quier proveedor de informacion de trafico rodado, co-mo lo puedan ser las propias Administraciones.

Agradecimientos

Esta investigacion ha sido financiada por el pro-yecto CICYT del Ministerio de Ciencia y Tecno-logıa, de Espana, cuya referencia es TRA2004-06276 / MODAL (’Desarrollo de un sistema de in-tercambio de informacion entre camiones y dis-positivos externos para control de mercancıas me-diante el uso de una infraestructura conceptual ba-sada en ontologıas. ’)

Referencias

[1] Apache. Apache Axis. En:http://ws.apache.org/axis/.

[2] C.Abela; M.Montebello. DAML enabled WebServices and Agents in the Semantic Web. En:WS–RSD’02, Erfurt Germany, October 2002.

[3] Ceccaroni, L. and Ribiere,. Experiences in Mo-deling Agentcities Utility-Ontologies with a Co-llaborative Approach. En: Ontologies in AgentSystems Workshop, Autonomous Agents andMulti-Agent Systems Conference 2002, Bolog-na, Italy, July 2002.

[4] CMU. A-Match. En: http://www-2.cs.cmu.edu/ softagents/a-match/index.html.

[5] CMU. Editor OWL-S. En:http://www.daml.ri.cmu.edu/tools/details.html.

[6] CMU. Matchmaker by CMU. En: http://www-2.cs.cmu.edu/ softagents/.

[7] The DAML Services Coalition. Daml-s:semantic markup for web sevices, 2002.

[8] Compaq. Compaq’s Web Language. En:http://research.compaq.com/SRC/WebL/.

[9] D. Trastour; C. Bartolini and J. Gonzalez-Castillo. A Semantic Web Approach to ServiceDescription for Matchmaking of Services. En:1st Semantic Web Working Symposium, CA.2001.

[10] FIPA. Agent UML. En: http://www.auml.org/.

[11] Foundation for Intelligent Physical Agents. Fipamodeling: Interaction diagrams. Technical re-port, Foundation for Intelligent Physical Agents,Geneva, Switzerland, Julio 2003. preliminar,primera propuesta.

[12] Foundation for Intelligent Physical Agents. Fipaagent management specification. Technical re-port, Foundation for Intelligent Physical Agents,Geneva, Switzerland, Marzo 2004. Standard.

[13] I. Constantinescu, B. Faltings. World WideWeb Consortium Efficient Matchmaking andDirectory Services. En:Technical Report NoIC/2002/77, Noviembre, 2002.

[14] J. Gonzalez-Castillo; D. Trastour and C. Bartoli-ni. Description Logics for MatchMaking of Ser-vices. En: HP Technical Reports. October 30 th, 2001.

[15] J. J. Samper, A Cervera, E. Carrillo. ONTO-SERVICE: Una Herramienta para la Edicionde Perfiles y Visualizacion de Ontologıas enServicios Web Semanticos. WebMedia/LA-Web 2004, the Joint Conference the 2nd LatinAmerican Web Congress and the 10th BrazilianSymposium on Multimedia and the Web. Octu-bre 12-15, Ribeirao Preto, Brasil. Pag 304-306,ISBN 85-7669-010-1.

[16] J. Samper, E. Carrillo,J. Martınez. Algoritmode emparejamiento de perfiles en servicios websemanticos. En: Revista Colombiana de Compu-tacion Volumen 6 numero 1, ISSN 1657-2831,Junio, 2005.

[17] M. Williamson. K. Decker, K. Sycara. Middle-agents for the internet. En: Proc. 15th, IJCAI,Nagoya, Japan., pages 578–583, August 1997.

[18] L. Lei and I. Horrocks. A software Frame-work For Matchmaking Based on Semantic WebTechnology. En: Twelfth International WorldWide Conference (WWW2003), pages 331-339,ACM, 2003.


[19] M. Klein, and A. Bernstein. Searching for Ser-vices on the Semantic Web using Process On-tologies. En: The First Semantic Web WorkingSymposium (SWWS-1). Stanford, 2001.

[20] Ontotext. BOR - a Pragmatic DAML+OILReasoner. En: http://www.ontotext.com/bor/.

[21] Openrdf. Sesame. En: http://www.openrdf.org/.

[22] Payne, T. Lassila, O. Semantic Web Services.En: IEEE Intelligent Systems. Special Issue onSemantic Web Services. 2004.

[23] R. Ferraz; S. Labidi and B. Wanghon. A se-mantic matching method for clustering tradersin B2B Systems.

[24] Semantic Web Services Initiative (SWSI) . En:http://www.swsi.org/.

[25] Semantic Web Services Interest Group. . En:http://www.w3c.org/2002/ws/swsig/.

[26] Semantic Web Services Lan-guage (SWSL) Committee,.http://www.daml.org/services/swsl/.

[27] Sycara, K., Klusch, M., Widoff, S., Lu, J., . Dy-namic Service Matchmaking Among Agents inOpen Information Environments. En: JournalACM SIGMOD Record, 1999.

[28] Paolucci, Massimo Kawamura, Takahiro Payne,Terry R. Sycara, Katia. Semantic matching ofweb services capabilities. En: Proceddings ofthe 1st International Semantic Web Conference(ISWC2002), September 2002.

[29] Sycara Katia, Widoff Seth, Klusch Matthias andLu Jianguo, . LARKS: Dynamic Matchmaking

Among Heterogeneous Software Agents in Cy-berspace. En: In Autonomous Agents and Multi-Agent Systems, 5, 173-203, 2002.

[30] T. R. Payne ; M. Paolucci and K. Sycara. Adver-tising and Matching DAML-S Service Descrip-tions. En: Semantic Web Working Symposium(SWWS), 2001.

[31] Tilab. Java Agent Development Framework. En:http://jade.tilab.com.

[32] Uddi.org. UDDI Universal DescriptionDiscovery and Integration protocol. En:http://www.uddi.org.

[33] W3C. FOAF Vocabulary Specification. En:http://xmlns.com/foaf/0.1/.

[34] W3C. GEO Vocabulary Specification. En:http://www.w3.org/2003/01/geo/.

[35] W3C. OWL Web Ontology Language. En:http://www.w3.org/TR/owl-features/.

[36] W3C. URI Uniform Resource Identificator. En:http://www.w3.org/Addressing/.

[37] W3C. WSDL Web Services Description Lan-guage. En: http://www.w3.org/TR/wsdl.

[38] Zaremski, Amy Moormann and Wing JeannetteM. . Signature matching: a Tool for Using Soft-ware Libraries. 1995.

[39] Zaremski, Amy Moormann and Wing JeannetteM. Specification Matching of Software Compo-nents. 1997.

AAAAAAAAAAAAAAAAAAAAAAAA ...journaldocs.iberamia.org/articles/491/article...

Documents

Transcript of AAAAAAAAAAAAAAAAAAAAAAAA ...journaldocs.iberamia.org/articles/491/article...