Você está na página 1de 8

Generacin semi-automtica de servicios web

Jos Mara Fuentes, Miguel ngel Corella, Pablo Castells, Mariano Rico
Universidad Autnoma de Madrid Escuela Politcnica Superior, Campus de Cantoblanco, 28049 Madrid {chema.fuentes, miguel.corella, pablo.castells, mariano.rico}@uam.es

Resumen
La disponibilidad de una masa crtica de servicios web, semnticos o no, es una necesidad importante para la experimentacin e innovacin en estas tecnologas emergentes. En este artculo se presenta Federica, una plataforma para la automatizacin de la creacin de servicios web a partir de aplicaciones web. Federica genera descripciones WSDL aumentadas con informacin semntica de los servicios. El sistema genera adems una implementacin de los mismos, que enlaza los mtodos de stos con llamadas a la aplicacin web original, de forma que los servicios se puedan ejecutar de forma inmediata.

1. Introduccin
La convergencia de las tecnologas de la web semntica [11] y los servicios web se ha identificado como una gran oportunidad de progreso para ambos campos [13]. Con los servicios web, la web semntica pasa de ser una red de informacin a una red de funcionalidades. A su vez las tecnologas de la web semntica proporcionan descripciones conceptuales de los servicios web, de forma que stos puedan ser objeto de anlisis, razonamiento y manipulacin automtica por parte de agentes software. Los estndares para la descripcin de servicios web sin ontologas, SOAP [8], WSDL [3] y UDDI [12], han despertado altas expectativas pero han tenido una adopcin desigual en la industria del software. Ms recientemente se han desarrollado lenguajes y plataformas adicionales para la creacin y procesamiento de servicios web con semntica ms explcita, basada en ontologas, entre los que destacan OWL-S [1], WSMO [2], y ms recientemente SWSL (ver en http://www.daml.org/services/swsl/materials/). Una de las barreras actuales para el avance de los servicios web semnticos es la falta de una masa crtica de servicios web, semnticos o no,

implementados y disponibles tanto para el anlisis de problemas, como para su uso como batera de pruebas, necesarios para la investigacin y desarrollo de tecnologa y el avance de nuevas propuestas. La investigacin que aqu se presenta, tiene como fin la automatizacin parcial de la creacin de servicios web semnticos a partir de aplicaciones existentes en la web. Se trata de generar descripciones de servicios a partir del anlisis automtico de la interfaz web de las aplicaciones (formularios, controles de entrada, informacin de salida), de forma que al ejecutar los servicios generados se produzca la ejecucin sobre la aplicacin real. Este esfuerzo hacia la generacin semiautomtica de servicios, responde a una doble motivacin. Por un lado, facilitar la creacin de una coleccin de casos de uso reales con posibilidad de ejecucin, para anlisis y prueba de cara a abordar distintos problemas de investigacin abiertos en este campo (tales como el descubrimiento, composicin e invocacin automtica de servicios), y por otro, ayudar a la transicin desde la web actual, en la que un gran nmero de aplicaciones estn hoy ya en funcionamiento, hacia una web de servicios web y servicios semnticos. La generacin de descripciones funcionales, a partir de la informacin implcita en la interfaz de acceso a la funcionalidad, es un problema inherentemente difcil, que abordamos en dos niveles: sintctico y semntico. El nivel sintctico consiste en generar descripciones WSDL. El nivel semntico, ms ambicioso, consiste en obtener un conjunto de propiedades semnticas de los servicios. Este documento est estructurado de la siguiente manera. En la seccin 2, mostramos los antecedentes encontrados en relacin con el trabajo planteado. A continuacin, se describir el proceso completo que llevamos a cabo para la generacin de descripciones WSDL a partir de aplicaciones web, la puesta a punto de servicios web que implementan las descripciones genera-

das, el enlace de dichos servicios con las aplicaciones como base de su funcionalidad y las posibilidades ofrecidas para su ejecucin. En la seccin 4, explicamos el enriquecimiento de las descripciones WSDL con la descripcin de aspectos semnticos. La seccin 5 describe el estado actual del desarrollo de nuestra propuesta. Finalmente, se expondrn las conclusiones del trabajo presentado y la previsin de trabajo futuro.

las aplicaciones web, en las descripciones WSDL de los servicios. En 3.2 se describe la funcionalidad que se le da a dichas descripciones. Y por ltimo, en 3.3 y 3.4, mostraremos las posibilidades de ejecucin de los servicios web creados. 3.1. Anlisis y extraccin de descripciones Para el anlisis y descripcin automtica de la funcionalidad ofrecida por una aplicacin web, el sistema que proponemos toma como entrada inicial la URL de la pgina web de acceso a la aplicacin. Adems, se requiere la introduccin de un nombre, que se utilizar para identificar el servicio creado dentro del banco de pruebas. El cdigo fuente que devuelve la URL de acceso a una aplicacin web incluye por lo general: Contenido de carcter meramente informativo para el usuario (ttulos, instrucciones, logotipos, publicidad, etc.), as como elementos de navegacin web, junto con detalles que definen la apariencia, estilo, y diseo de pgina. Elementos de interfaz que permiten al usuario acceder a la funcionalidad ofrecida por la aplicacin web. Considerando que el contenido denominado informativo aporta informacin de muy diversos tipos, difcilmente procesable, para generar las descripciones WSDL, nuestra propuesta slo utilizar la informacin ofrecida por los elementos de la interfaz de la aplicacin web. En lenguaje HTML, el mecanismo usual para la interaccin con el usuario, son los formularios. Es por ello, que nuestra plataforma se basar nicamente en los formularios de las aplicaciones web para la generacin de las descripciones de los servicios. Ahora bien, HTML permite la inclusin de otros elementos externos que pueden contener parte de la interaccin con el usuario (p.e. Javascript). En nuestro caso, no se tendrn en cuenta estos elementos, aunque consideramos que se podra utilizar la informacin contenida en ellos aadiendo mdulos que permitiesen su anlisis (p.e. parseadores de Javascript, etc.). La generacin automtica de las descripciones WSDL, por tanto, se basa en el anlisis de los formularios de interfaz con la aplicacin, a partir del cual se definen los diferentes mtodos a ofrecer por el servicio web generado. Este proceso se lleva a cabo mediante los siguientes pasos:

2. Trabajo relacionado
La idea de la generacin automtica de servicios web a partir de aplicaciones web ha sido tratada con anterioridad. Por su relevancia y relacin con nuestra propuesta, comentaremos el trabajo desarrollado en [5] y [10]. La principal diferencia entre la propuesta comentada en [5], radica en los objetivos finales de dicha generacin. En nuestro caso, adems de crear servicios web que permitan el acceso y uso de aplicaciones web, el objetivo es generar informacin semntica que proporcione una descripcin ms potente de los servicios creados y, por tanto, de las aplicaciones web en las que se basan. Mientras, en el trabajo realizado en [5], no se persigue mejorar la potencia de los servicios Web, sino hacer uso de las tecnologas actuales. Esto permite que su trabajo incluya la utilizacin de ms aspectos relacionados con los servicios web (en el momento actual), como, por ejemplo, la publicacin y posterior bsqueda de servicios dentro de registros UDDI. En nuestro caso, la utilizacin de nuevas descripciones semnticas permitirn el desarrollo de nuevos procedimientos, ms potentes y ricos, de bsqueda y descubrimiento de servicios web. Las diferencias entre nuestra propuesta y la descrita en [10] son todava ms obvias, debido a la evolucin de la tecnologa desde el momento de su propuesta. En nuestro caso, la generacin es automtica y los wrappers generados son servicios web, mientras que en [10] la generacin de descripciones es manual y los wrappers generados son aplicaciones Java.

3. Generacin de descripciones bsicas


En los siguientes apartados, explicaremos el proceso que se lleva a cabo para la generacin de los servicios. En 3.1 trataremos la transformacin de

<form action=/search name=f> ... <table cellspacing=0 cellpadding=0> <tr> <td width=25%>&nbsp;</td> <td align=center> <input type=hidden name=hl value=es> <input type=hidden name=ie value="ISO-8859-1"> <input maxLength=256 size=55 name=q value=""><br> <input type=submit value="Bsqueda en Google" name=btnG> <input type=submit value="Voy a Tener Suerte" name=btnI> </td> ... </tr> <tr> <td colspan=3 align=center> <font size=-1>Bsqueda: <input id=all type=radio name=meta value="" checked> ... <input id=lgr type=radio name=meta value="lr=lang_es" > ... <input id=cty type=radio name=meta value="cr=countryES" > ... </font> </td> </tr> </table> </form>

2 3

<?xml version="1.0" encoding="ISO-8859-1"?> <wsdl:types> <simpleType name="hlEnumeration"> <restriction base="xsd:string"> 1 <enumeration value="es" /> </restriction> </simpleType> <simpleType name="btnGEnumeration"> <restriction base="xsd:string"> <enumeration value="Bsqueda en Google" /> 3 <enumeration value="" /> </restriction> </simpleType> <simpleType name="metaEnumeration"> <restriction base="xsd:string"> <enumeration value="" /> <enumeration value="cr=countryES" /> 4 <enumeration value="lr=lang_es" /> </restriction> </simpleType> </schema> </wsdl:types> <wsdl:message name="fRequest"> 1 <wsdl:part name="hl" type="tns1:hlEnumeration" /> <wsdl:part name="ie" type="tns1:ieEnumeration" />

2 <wsdl:part name="q" type="xsd:string" /> 3 <wsdl:part name="btnG" type="tns1:btnGEnumeration" /> <wsdl:part name="btnI" type="tns1:btnIEnumeration" /> 4 <wsdl:part name="meta" type="tns1:metaEnumeration" />

Google Home Page


5

<wsdl:portType name="GoogleSearchIF"> <wsdl:operation name="f" parameterOrder="hl ie q btnG btnI meta "> <wsdl:input name="fRequest" message="impl:fRequest" /> <wsdl:output name="fResponse" message="impl:fResponse" /> </wsdl:operation>

</wsdl:portType> </definitions>

Generated WSDL
Figura 1. Ejemplo de descripcin WSDL generada a partir de Google

1. Se define un servicio con un nico wsdl:portType para toda la aplicacin. 2. Utilizando un parser de HTML, se extraen los formularios del cdigo fuente devuelto por la URL de acceso a la aplicacin. 3. Se crea un wsdl:operation para cada uno de los formularios encontrados en la pgina. 4. Para cada wsdl:operation se define un wsdl:message de entrada y uno de salida. 5. Para cada uno de los formularios, se identifican los controles HTML de tipo input, select y textarea como entradas para el servicio, es decir como elementos wsdl:part del wsdl:message de entrada. 6. Segn el tipo y caractersticas del control HTML, se asigna un tipo de dato a cada entrada (wsdl:part) del servicio, definiendo un nuevo tipo XML Schema en algunos casos. En la

Tabla 1 se muestra la correspondencia de tipos segn el control de entrada. 7. El wsdl:message de salida contendr un nico wsdl:part de tipo xsd:string que, cuando se invoque al servicio, contendr el cdigo fuente de la pgina web resultante de la utilizacin del formulario de la aplicacin web. La Figura 1 muestra un ejemplo de la generacin de una descripcin WSDL. En concreto, se ha utilizado como entrada la pgina inicial de Google (http://www.google.es). La Figura 2 muestra la descripcin generada por nuestra plataforma, frente a la descripcin del mismo servicio que proporciona el proveedor para esta aplicacin web. Como puede observarse, nuestras tcnicas obtienen una aceptable aproximacin. Las principales diferencias, en este ejemplo, radican en dos aspectos: los nombres de

<?xml version="1.0" encoding="ISO-8859-1"?> <wsdl:types> <simpleType name="hlEnumeration"> </simpleType> <simpleType name="ieEnumeration"> </simpleType> <simpleType name="btnGEnumeration"> </simpleType> <simpleType name="btnIEnumeration"> </simpleType> <simpleType name="metaEnumeration"> </simpleType> </wsdl:types> <wsdl:message name="fRequest"> <wsdl:part name="hl" type="tns1:hlEnumeration" /> <wsdl:part name="ie" type="tns1:ieEnumeration" /> <wsdl:part name="q" type="xsd:string" /> <wsdl:part name="btnG" type="tns1:btnGEnumeration" /> <wsdl:part name="btnI" type="tns1:btnIEnumeration" /> <wsdl:part name="meta" type="tns1:metaEnumeration" /> </wsdl:message> <wsdl:message name="fResponse"> <wsdl:part name="fResponse" type="xsd:string" /> </wsdl:message> <wsdl:portType name="GoogleSearchIF"> <wsdl:operation name="f" parameterOrder="hl ie q btnG btnI meta "> <wsdl:input name="fRequest" message="impl:fRequest" /> <wsdl:output name="fResponse" message="impl:fResponse" /> </wsdl:operation> </wsdl:portType> </definitions>

<?xml version="1.0"?> <definitions name="GoogleSearch > <types> <xsd:complexType name="GoogleSearchResult> </xsd:complexType> <xsd:complexType name="ResultElement"> </xsd:complexType> <xsd:complexType name="ResultElementArray"> </xsd:complexType> <xsd:complexType name="DirectoryCategoryArray"> </xsd:complexType> <xsd:complexType name="DirectoryCategory> </xsd:complexType> </types> <message name="doGoogleSearch"> <part name="key" type="xsd:string"/> <part name="q" type="xsd:string"/> <part name="start" type="xsd:int"/> <part name="maxResults" type="xsd:int"/> <part name="filter" type="xsd:boolean"/> <part name="restrict" type="xsd:string"/> <part name="safeSearch" type="xsd:boolean"/> <part name="lr" type="xsd:string"/> <part name="ie" type="xsd:string"/> <part name="oe" type="xsd:string"/> </message> <message name="doGoogleSearchResponse"> <part name="return" type="typens:GoogleSearchResult"/> </message> <portType name="GoogleSearchPort"> <operation name="doGetCachedPage"> <input message="typens:doGetCachedPage"/> <output message="typens:doGetCachedPageResponse"/> </operation> <operation name="doSpellingSuggestion"> <input message="typens:doSpellingSuggestion"/> <output message="typens:doSpellingSuggestionResponse"/> </operation> <operation name="doGoogleSearch"> <input message="typens:doGoogleSearch"/> <output message="typens:doGoogleSearchResponse"/> </operation> </portType> </definitions>

Automatically generated WSDL

Manually created WSDL


Figura 2. Descripcin generada automticamente vs. descripcin generada manualmente (para Google)

los parmetros de los mtodos del servicio, y la inclusin de funcionalidad ajena a la ofrecida por los formularios de la aplicacin web (p.e. en Google la funcionalidad Quiso decir). Input HTML text password textarea submit adio checkbox hidden select (seleccin simple) inputs (mismo name) inputs (con atributos value y readOnly) select (seleccin mltiple) Tipo XML Schema xsd:string

3.2. Enlace del servicio con la aplicacin El sistema propuesto genera una implementacin de los servicios web como wrappers de las aplicaciones a partir de las que son generadas las descripciones de los servicios. Para ello se ha implementado un motor de enlace utilizando Axis para la recepcin y envo de los mensajes SOAP, utilizados para la comunicacin con el servicio. Con la herramienta WSDL2Java de Axis, a partir de las descripciones WSDL se genera un conjunto de clases Java vacas que, una vez implementadas, darn a los servicios web la funcionalidad deseada. Finalmente se hace el despliegue del servicio en Axis, de manera que el motor de ste pueda procesar los mensajes SOAP que reciba. El resultado de este proceso, ilustrado de manera grfica en la Figura 3, es un servicio web completamente funcional, cuyas operaciones permiten realizar las mismas tareas que la aplicacin web sobre la que se ha construido.

xsd:string, enumeracin

Array de tipo xsd:string, enumeracin

Tabla 1. Correspondencia de tipos de datos con los tipos de control de entrada de los formularios

Federica Web Server


Web App
HTML

HTML Parser

Page Description

Semantic Generator

Semantic Descriptions

WSDL Generator

WSDL

Service Generator

HTTP Request

Deploy Service

HTML

Tomcat Server Web Service Client


Axis Server Deployed Service
SOAP Request SOAP Response

Deployed Service

Figura 3. Proceso de generacin de servicios con la aplicacin propuesta

3.3. Ejecucin de los servicios generados Con lo explicado anteriormente, se puede obtener un gran nmero de aplicaciones web accesibles como servicios web, con todas las ventajas de interoperabilidad que dicho acceso permite. Adems de ello, con el propsito de probar la validez de los servicios generados, depurar y mejorar el sistema, nuestro entorno permite la generacin automtica de un cliente con interfaz web, para la invocacin de cada servicio. Para ello se ha integrado el sistema Jacinta [9], que se describe brevemente en el apartado 3.4. Otra de las finalidades del entorno de invocacin es el tratamiento de la salida de los servicios generados, para refinar la tipificacin de la respuesta de las aplicaciones. Aunque actualmente, como se ha descrito en el apartado 3.1, la salida de los servicios consiste en la pgina web generada por la aplicacin web en respuesta a las peticiones, sera enormemente til extraer y caracterizar la semntica y datos esenciales de la respuesta, inmersos en la pgina, para lograr una mejor y ms til descripcin del servicio. Lograr este objetivo de forma totalmente automtica es, en general, enormemente difcil. Sin embargo, resulta ms viable con ayuda de un usuario o administra-

dor de servicios, dando un soporte interactivo en el entorno para que el usuario seleccione los fragmentos relevantes dentro de la pgina de respuesta de las aplicaciones. Este objetivo es parte de nuestro trabajo futuro. 3.4. Integracin con Jacinta Con el propsito de probar la validez de los servicios generados, como cliente de nuestro sistema hemos utilizado el sistema Jacinta [9], desarrollado tambin en nuestro grupo de trabajo. Jacinta es un agente software especializado en la interaccin con usuarios humanos y capaz, a su vez, de utilizar servicios web tradicionales (basados nicamente en WSDL) de forma semntica. Los administradores de Jacinta disponen de herramientas para relacionar los elementos de una ontologa con elementos de visualizacin e interaccin y con los elementos de los ficheros WSDL, de forma que el Servicio Web queda anotado semnticamente con informacin relativa a la presentacin de la funcionalidad a un usuario final. Utilizando esta informacin, junto con la descripcin WSDL, Jacinta genera automticamente un mecanismo de interaccin entre un usuario humano y el servicio web. En el caso de la presente propuesta, en principio Jacinta prescinde

de cualquier informacin adicional sobre cmo debe ser la interfaz, y genera una por defecto. No obstante, un diseador puede utilizar las posibilidades que ofrece Jacinta para definir la semntica de presentacin si as lo desea, para mejorar la interfaz generada. El diseo modular de Jacinta permite que sus distintos mdulos puedan activarse o desactivarse, de forma que, por ejemplo, pueda ser utilizado nicamente para el tratamiento de los resultados devueltos por los servicios web, como es el caso de la interaccin con WSMX [4], GODO [7], u otros [6]. Sin embargo, cuando la interaccin es con la plataforma aqu presentada, no slo utiliza todos sus mdulos como si se comunicase con servicios web basados en WSDL, sino que a diferencia de estos, puede obtener informacin semntica que habitualmente no proporcionan los WSDL, aadida por los administradores de los servicios generados y la obtenida de manera automtica.

La asignacin manual de etiquetas a los mtodos y parmetros del servicio, de manera que estn ms orientados al uso humano. La recomendacin de tipos de input HTML para la futura interaccin de usuarios con el servicio. Por lo que respecta a la clasificacin de servicios, a partir de una taxonoma como las utilizadas en los directorios UDDI (p.e. UNSPSC), y un conjunto de descripciones WSDL clasificadas con dicha taxonoma, nuestro sistema deduce la clasificacin de un nuevo servicio mediante una medida de similitud entre la descripcin WSDL del servicio y las categoras de la taxonoma. La similitud entre una descripcin WSDL s y una categora C se calcula como:

sim( s, C ) = max sim( s, t )


tC

4. Descripciones semnticas de servicios


Como ya se ha expuesto en secciones anteriores, el horizonte de nuestra investigacin contempla la obtencin de descripciones con ms informacin semntica acerca de los servicios web, que la que puede ofrecer un lenguaje de descripcin como WSDL. El universo de propiedades semnticas de un servicio, susceptibles de ser descritas, es enormemente amplio. De hecho la definicin de un modelo semntico general para este fin es an, en nuestra apreciacin, un problema abierto. En consecuencia hemos delimitado, respecto a la semntica a generar, un conjunto restringido de caractersticas representables. El conjunto considerado hasta el momento incluye la descripcin de parmetros y la clasificacin de servicios. Por lo que respecta al primer aspecto, contemplamos: La atribucin de clases de una ontologa a los tipos de parmetro. Por ahora esta capacidad se aplica a tipos enumerados, como pases, aeropuertos o tipos de divisa. Condiciones adicionales sobre los parmetros, como la delimitacin de rangos para los valores, o la precisin numrica, obtenidas a partir de la monitorizacin de la interaccin de un usuario humano con el servicio.

Es decir, como la mxima similitud entre s y los servicios clasificados en la categora C. Nuestra previsin de trabajo futuro contempla la experimentacin con otras funciones, como el promedio u otras ms elaboradas. La similitud entre dos descripciones s y t se calcula mediante heursticas que miden la coincidencia entre los tipos de parmetros, otorgando mayor relevancia a los tipos ms especficos o poco frecuentes (por ejemplo, la coincidencia en un tipo divisa se considera ms significativa que en el tipo string). Si bien estas medidas de similitud son muy aproximadas, en la prctica alcanzan un grado de acierto razonable, y en ltimo trmino dan lugar a un ranking de potenciales clasificaciones, que el usuario puede utilizar para seleccionar la correcta. Para la representacin de la informacin semntica, se precisan extensiones de la expresividad de WSDL. Por otro lado, la generalidad de OWL-S y WSMO hace que la representacin de informacin relativamente simple se convierta en una tarea muy compleja. Por ello, hemos decidido definir una ontologa propia, que extienda y complemente la expresividad de WSDL, pero que haga la representacin de semntica ms sencilla que con OWL-S y WSMO, y se eviten las dificultades computacionales de estos lenguajes. La Figura 4 muestra grficamente nuestra ontologa. No descartamos la utilizacin futura de lenguajes como OWL-S y WSMO. De hecho, y a medida que estos lenguajes sigan madurando, prevemos que nuestra ontologa ir creciendo y ganando en generalidad tambin, de manera que,

xsd:string

ws dlN

am

lab

el

xsd:string

xsd:string

ws d

lNa me

eter aram hasP

WebService

hasM etho d

el lab

xsd:string

label xsd:string

Parameter

has

Par am

wsdlName
eter

Method
hasInputMessage hasOutputMessage

xsd:string

Input

Output
f ro mM es sa

po rtT yp e

xsd:string

ge

Message

xsd:string wsdlName

HTMLInput
lue lVa htm
htm lCon trol

HTMLOutput
out put Loc atio n

labe l

xsd:string

xsd:string

xsd:string

xsd:string

Class Type

SubClassOf Property

Figura 4. Ontologa para la descripcin semntica de servicios web

en algn momento, se puedan orientar nuestras tcnicas hacia alguno de estos lenguajes.

5. Estado del desarrollo


El trabajo descrito en las secciones 3.1 y 3.2, referente a la generacin automtica de servicios web funcionales a partir de aplicaciones web, est completamente desarrollado. Este prototipo, de nombre Federica, est pblicamente accesible en la siguiente URL: http://rhadamanthis.ii.uam.es:8080/federica/ El prototipo se encuentra en fase de prueba y mejora. La diversidad de las aplicaciones web, y los estilos de programacin de las pginas web a la hora de codificar su funcionalidad, hacen que para alcanzar unos niveles amplios de xito de un sistema como el nuestro, basado en el anlisis del cdigo fuente, se necesite una fase dilatada de pruebas y ajustes. De especial inters para nuestras pruebas son las aplicaciones web para las que, de forma directa o por similitud, existe un servicio web definido y pblicamente disponible, que permite comparar y evaluar el resultado de nuestro sistema. As por ejemplo, nuestras pruebas preliminares con portales de bsqueda como Google y

Yahoo, o de cambio de moneda, como XE Currency Converter, Oanda y X-Rates.com, han dado resultados satisfactorios. La integracin con Jacinta, descrita en el apartado 3.4, es trabajo en curso en el momento de escribir este artculo. Entretanto, para ejecutar y probar los servicios web que se generen, tal como se describe en el apartado 3.3, se ha desarrollado provisionalmente un mecanismo ms simple, menos general, que no obstante permite generar clientes funcionales con interfaz web. La generacin de informacin semntica descrita en la seccin 4 se ha llevado a cabo en una primera implementacin, actualmente en fase de prueba.

6. Conclusiones
El trabajo presentado ofrece una plataforma para la creacin semi-automtica de servicios web, y su posterior utilizacin. Dicha plataforma permite crear una masa crtica de servicios, de tamao considerable, con poco esfuerzo, que podr ser utilizada para otras lneas de investigacin sobre las tecnologas de los servicios web: servicios semnticos, clasificacin automtica, bsqueda,

invocacin, composicin, generacin automtica de interfaces, etc. Entre las tecnologas actuales para la descripcin de servicios web (WSDL / SOAP / UDDI), y la visin de los servicios web semnticos, existe un gran salto an por resolver, y difcil de salvar. La propuesta de una ontologa de servicios propia, frente a lenguajes actuales como OWL-S y WSMO, responde a una aproximacin ms realista a la descripcin semntica de servicios. Nuestras descripciones irn creciendo a medida que aumente la informacin semntica que seamos capaces de extraer. Nuestro trabajo propone as una estrategia ascendente (bottom-up), complementaria al enfoque descendente (top-down) de OWL-S y WSMO, con el propsito comn de acercar ambos extremos en los niveles de abstraccin. Por lo que respecta al trabajo futuro o en curso, como ya se ha indicado en la seccin anterior, a partir de los resultados alcanzados hasta aqu, nuestro trabajo necesita una labor de pruebas ms exhaustiva, ampliando el conjunto de aplicaciones web para nuestra experimentacin. Es nuestro objetivo as mismo profundizar y extender la adquisicin automtica de informacin semntica, identificando nuevos aspectos susceptibles de descripcin automtica, y mejorando el funcionamiento del sistema para los ya contemplados. Otro de los aspectos a mejorar en nuestro trabajo actual es la caracterizacin de la salida de los servicios, actualmente consistente en la cadena de caracteres correspondiente a la pgina web de respuesta de la aplicacin original. En este sentido, estamos complementando el entorno con herramientas de administracin de servicios que permitan a usuarios avanzados utilizar, editar y manipular las descripciones generadas por nuestra plataforma. Y entre estas posibilidades, la ms avanzada es la definicin interactiva y refinamiento de los parmetros de salida de los servicios. Esta extensin del entorno se basar en la seleccin por parte del usuario, de los valores de salida del servicio dentro de las respuestas HTML devueltas por la aplicacin, a partir de lo cual el sistema deber identificar automticamente el modo de acceder a estos valores dentro de la pgina web, y el tipo de los datos. Para esto ltimo, el sistema podr crear los tipos XML Schema apropiados, de manera que las descripciones WSDL sean ms precisas.

Referencias
[1] D. Martin et al. OWL-S: Semantic Markup for Web Services, v1.1, 2004. [2] D. Roman, H. Lausen, U. Keller, J. de Brujin, C. Bussler, J. Domingue, D. Fensel, M. Hepp, M. Kifer, B. Knig-Ries, J. Kopecky, R. Lara, E. Oren, A. Polleres, J. Scicluna, M. Stollberg. Web Service Modeling Ontology (WSMO), 2005. [3] E. Christensen et al. Web Service Description Language (WSDL) 1.1, 2001. [4] E. Oren et al. Overview and Scope of WSMX, 2004. [5] H-H. Pham. B2B with Toshiba Web Service Gateway. Proceedings of Recherche Informatique Vietnam & Francophonie 2004 (RIVF 2004). pp. 137 142. [6] J.M. Gmez, M. Rico, F. Garca, C. Acua. The Semantic Web Service Tetrahedron: Achieving integration with Semantic Web Services. Accepted for publication. 5th International Conference on Web Engineering (ICWE2005). Sydney, Australia. [7] J. M. Gmez, M. Rico, F. Garca, C. Bussler. GODO: Goal Driven Orchestration for semantic web services.. In Proc. Workshop on WSMO Implementations (WIW) 2004, volume 113, ISSN 1613-0073, Frankfurt, 99339Germany, September 2004. [8] M. Gudgin, M. Hadley, N. Mendelsohn, J-J, Moreau, H. F. Nielsen. SOAP Version 1.2 Part 1: Messaging Framework, 2003. [9] M. Rico, P. Castells. Jacinta: a mediator agent for human agent interaction in semantic web services. In Proc. of Intl. Semantic Web Conf. (ISWC 2004), Selected Posters. Hiroshima, Japan, November 2004. [10] A. Sahuguet, F. Azavant. WysiWyg Web Wrapper Factory (W4F). Unpublished. 1999. [11] T. Berners-Lee et al. The Semantic Web. Scientific American, May 2001. [12] UDDI: The UDDI Technical White Paper, 2004. [13] V. Y. Terziyan, O. Kononenko. Semantic Web Enabled Web Services: State-of-the-art and Industrial Challenges. In Proc. International Conference on Web Services, 2003 (ICWS 2003), pp. 183-197.

Você também pode gostar