Acceder - Departamento de Lenguajes y Ciencias de la Computación

Técnicas de Web Semántica para la
Adaptación Dinámica de Componentes y Servicios
José L. Pastrana1, Ernesto Pimentel1, Miguel Katrib2
1
ETSI Informática, Universidad de Málaga,Campus de teatinos s/n,
29071 Málaga, España
{pastrana, ernesto}@lcc.uma.es
2 Facultad de Matemática y Computación, Universidad de La Habana, San Lázaro y L,
VEDADO, Ciudad de la Habana, Cuba
[email protected]
Resumen. La Web semántica es un área pujante en la confluencia de la Inteligencia Artificial y las tecnologías Web que propone introducir descripciones explícitas sobre el significado de los recursos, para permitir que las propias máquinas
tengan un nivel de comprensión de la Web suficiente como para hacerse cargo de
una parte, la más costosa, rutinaria, o físicamente inabarcable, del trabajo que actualmente realizan manualmente los usuarios que navegan e interactúan con la
Web: seleccionar qué información es relevante al usuario y cuál no. A partir de la
situación actual de la Web y sus limitaciones, en este artículo se aprovechan las
técnicas y avances en este campo para ser utilizada en la adaptación de servicios
de componentes distribuidos y más en concreto en el campo de componentes implementados como servicios Web. Dichas técnicas de análisis semántico aplicado
a la Web pueden ser usadas para adaptar el nombre de los servicios, los parámetros de los mismos y más aun, es posible adaptar el componente que realiza el
servicio.
1 Introducción
En los últimos años está de moda el uso del término Web semántica, pero ¿qué es la
Web semántica? Según [1] La Web semántica es una extensión de la Web actual en
la cual la información es dada con un significado bien definido, lo que permite un
mejor trabajo en cooperación entre hombres y computadoras. La Web semántica
propone superar las limitaciones de la Web actual mediante la introducción de descripciones explícitas del significado, la estructura interna y la estructura global de
los contenidos y servicios disponibles en la WWW. Frente a la semántica implícita,
el crecimiento caótico de recursos, y la ausencia de una organización clara de la
Web actual, la Web semántica aboga por clasificar, dotar de estructura y anotar los
recursos con semántica explícita procesable por máquinas. Según el consorcio W3C
la Web semántica nos aporta un marco común que permite que los datos sean compartidos y reutilizados a través de las aplicaciones, las empresas y las personas. La
Web tradicional podemos verla como un grafo (informalmente llamado tela de araña) de recursos de información enlazados entre sí. Sin embargo, dichos enlaces no
aportan ninguna información ni representan relaciones entre los diferentes recursos,
lo que hace que podamos tener resultados no deseados a la hora de realizar búsquedas en dicha red de recursos.
Figura 1. Esquema de Web Tradicional.
Supongamos que para ir al Workshop del IDEAS’06 deseamos buscar información
en Google e introducimos en el buscador la siguiente cadena “viaje a la plata en argentina”. Para empezar, obtenemos 1.160.000 resultados, lo cual para un humano es
una cifra de enlaces de información difícil de procesar (al menos si desea llegar a
tiempo al evento). Si nos paramos a analizar los resultados obtenidos, encontraremos que hay muchos que pueden ser interesantes para nosotros, pero que también
hay gran cantidad de enlaces que no satisfacen nuestras necesidades. Por ejemplo,
como podemos ver en la Figura 2, tenemos enlaces de viajes como “ARGENTINA La Plata - Alojamientos, hoteles, información general” y otros que se refieren a
hechos históricos como “Argentina: Viaje al pasado: Los Virreinatos”.
Figura 2. Resultados de una búsqueda en la Web Tradicional .
La solución a estos problemas es La Web Semántica: una Web extendida, dotada de
mayor significado en la que cualquier usuario en Internet podrá encontrar respuestas
a sus preguntas de forma más rápida y sencilla gracias a una información mejor definida. Al dotar a la Web de más significado y, por lo tanto, de más semántica, se pueden obtener soluciones a problemas habituales en la búsqueda de información gracias a la utilización de una infraestructura común, mediante la cual, es posible compartir, procesar y transferir información de forma sencilla. Esta Web extendida y
basada en el significado, se apoya en lenguajes universales que resuelven los problemas ocasionados por una Web carente de semántica en la que, en ocasiones, el
acceso a la información se convierte en una tarea difícil y frustrante.
2 Funcionamiento de la Web Semántica
Supongamos que la Web tiene la capacidad de construir una base de conocimiento
sobre las preferencias de los usuarios y que, a través de una combinación entre su
capacidad de conocimiento y la información disponible en Internet, sea capaz de
atender de forma exacta las demandas de información por parte de los usuarios en
relación, por ejemplo, a reserva de hoteles, vuelos, médicos, libros, etc.
Si esto ocurriese así en la vida real, el usuario, en su intento, por ejemplo, por encontrar información sobre su viaje a La Plata en Argentina, obtendría unos resultados
exactos sobre su búsqueda. Sin embargo, como puede verse en la figura 2, la realidad
es otra y la información obtenida es muy variada y se mezclan resultados deseados
con resultados no deseados. El paso siguiente por parte del usuario es realizar una
búsqueda manual entre esas opciones que aparecen, con la consiguiente dificultad y
pérdida de tiempo. Con la incorporación de semántica a la Web los resultados de la
búsqueda serían exactos. Todo ello a través de una Web en la que los datos pasan a
ser información llena de significado. El resultado final sería la obtención de forma
rápida y sencilla de todos los vuelos y hoteles a La Plata en Argentina.
La forma en la que se procesará esta información no sólo será en términos de entrada y salida de parámetros sino en términos de su semántica. La Web Semántica como infraestructura basada en metadatos aporta un camino para “razonar” en la Web,
extendiendo así sus capacidades. No se trata de una inteligencia artificial mágica que
permita a las máquinas entender las palabras de los usuarios, es sólo la habilidad de
una máquina para resolver problemas bien definidos, a través de operaciones bien
definidas que se llevarán a cabo sobre datos existentes bien definidos.
Para obtener esa adecuada definición de los datos [3], la Web Semántica utiliza RDF
y OWL, dos estándares que ayudan a convertir la Web en una infraestructura global
en la que es posible compartir, y reutilizar datos y documentos entre diferentes tipos
de usuarios.
RDF proporciona información descriptiva simple sobre los recursos que se encuentran en la Web y que se utiliza, por ejemplo, en catálogos de libros, directorios,
colecciones personales de música, fotos, eventos, etc.
OWL es un mecanismo para desarrollar temas o vocabularios específicos en los que
asociar esos recursos. Lo que hace OWL es proporcionar un lenguaje para definir
ontologías estructuradas que pueden ser utilizadas a través de diferentes sistemas.
Las ontologías, que se encargan de definir los términos utilizados para describir y
representar un área de conocimiento, son utilizadas por los usuarios, las bases de
datos y las aplicaciones que necesitan compartir información específica, es decir, en
un campo determinado como puede ser el de las finanzas, medicina, deporte, etc. Las
ontologías incluyen definiciones de conceptos básicos en un campo determinado y
la relación entre ellos.
3 RDF: El Marco de Descripción de Recursos
RDF son las siglas en inglés de Resource Description Framework (RDF [8]), que es
un lenguaje para la representación de información a cerca de los recursos disponibles en la Web. Está particularmente pensado para representar metadatos sobre recursos disponibles en la Web. Recursos tales como, por ejemplo, el título, autor, y
fecha de modificación de una página Web, derechos de propiedad, disponibilidad de
algún recurso compartido, etc. Sin embargo, generalizando el concepto de recurso
Web, también se puede usar RDF para representar información a cerca de las cosas
que pueden ser identificadas en la Web, aún cuando no puedan ser recuperadas directamente de la misma. Por ejemplo, incluir información a cerca de los productos
disponibles en una tienda on-line (especificaciones, precios, disponibilidad,etc), o
incluso, la descripción de las preferencias de los usuarios a la hora de solicitar información.
RDF ha sido pensado para situaciones en que esta información necesita ser procesada por aplicaciones , en vez de sólo ser mostrada al usuario. Por ello, RDF ofrece un
marco común para expresar esta información de forma que pueda ser intercambiada
entre diferentes aplicaciones sin pérdida de significado. Al ser un marco común,
puede ser usado por los diseñadores de aplicaciones junto con las herramientas de
procesamiento y análisis del mismo que se incorporan a dicho marco. Esta capacidad
de intercambiar la información hace que una información pueda pasar y estar disponible de unas aplicaciones a otras para las cuales, inicialmente, no se había pensado o
ni siquiera se habían creado.
RDF se basa en la idea de la definición de identificadores Web (llamados Identificadores Uniformes de recursos, Uniform Resource Identifiers, o URL ), identificar
las cosas a través de dichos identificadotes y describir los recursos en términos de
propiedades simples y valores de las propiedades. Esto posibilita representar sentencias simples en RDF como un grafo de nodos y arcos representando los recursos,
sus propiedades y valores. Además, RDF, nos ofrece una sintaxis basada en XML y
llamada RDF/XML para el almacenamiento e intercambio de dicha información.
Por ejemplo, en el código siguiente1, podemos ver la representación de la oración
“Hay una persona identificada en http://www.lcc.uma.es/~pastrana/ cuyo nombre es
José Luis Pastrana y cuya dirección de correo electrónico es [email protected]”.
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdfsyntax-ns#"xmlns:contact=
"http://www.w3.org/2000/10/swap/pim/contact#">
<contact:Person rdf:about=
"http://www.lcc.uma.es/~pastrana" >
<contact:fullName>José Luis Pastrana</contact:fullName>
<contact:mailbox rdf:resource= "mailto:[email protected]"/>
</contact:Person>
</rdf:RDF>
Al igual que HTML, RDF/XML es procesable automáticamente y al usar URL’s
puede enlazar porciones de información a través de la Web. Sin embargo, y al contrario con lo que ocurre con el hipertexto convencional, las URL’s de RDF pueden
referirse a cualquier cosa identificable, incluso cosas que no se pueden recuperar
directamente en la Web (tales como la persona José Luis Pastrana). RDF también
puede describir coches, negocios, personas, eventos, etc. Además, las propiedades
de RDF, tienen URL’s para identificar de forma precisa las relaciones existentes
entre los elementos enlazados.
4 OWL: El Lenguaje de Ontologías Web del W3C
Según [9], una ontología define los términos a utilizar para describir y representar un
área de conocimiento. Las ontologías son utilizadas por las personas, las bases de
datos, y las aplicaciones que necesitan compartir un dominio de información (un
dominio es simplemente un área de temática específica o un área de conocimiento,
tales como medicina, fabricación de herramientas, bienes inmuebles, reparación
automovilística, gestión financiera, etc.). Las ontologías incluyen definiciones de
conceptos básicos del dominio, y las relaciones entre ellos. Básicamente, codifican
el conocimiento de un dominio y también el conocimiento que extiende los dominios. En este sentido, hacen el conocimiento reutilizable.
OWL es un lenguaje de Ontologías Web (Ontology Web Language). Antes de la
aparición de OWL, por lo general, se han estado utilizado lenguajes y herramientas
para desarrollar ontologías destinadas a comunidades específicas (especialmente
para ciencias y aplicaciones específicas de comercio electrónico), que no fueron
definidos para ser compatibles con la arquitectura de la World Wide Web en general, y la Web Semántica en particular. OWL rectifica esto proporcionando un lengua-
je que utiliza la conexión proporcionada por RDF para añadir las siguientes capacidades a las ontologías:
•Capacidad de ser distribuidas a través de varios sistemas
•Escalable a las necesidades de la Web
•Compatible con los estándares Web de accesibilidad e internacionalización
•Abierto y extensible
Entre los usos más comunes, hoy en día, de las ontologías en la Web caben destacar:
las Reglas de categorización utilizadas para mejorar la búsqueda en los portales
Web, las búsquedas basadas en contenido para medios no textuales en las colecciones multimedia, la organización taxonómica automatizada de datos y documentos
para la administración de Sitios Web corporativos, la explicación de partes y la
administración explícita de restricciones a la hora de la realización de la documentación de diseño, la expresión de las preferencias y/o intereses de los usuarios y el
mapeo de contenidos entre sitios Web en el desarrollo de agentes inteligentes, la
composición y descubrimiento de Servicios Web o la administración de derechos y
control de acceso en el uso y desarrollo de servicios Web y computación ubicua.
OWL extiende RDF para permitir la expresión de relaciones complejas entre diferentes clases RDF, así como una mayor precisión en las restricciones de clases y
propiedades específicas. Esto incluye:
•Los recursos para limitar las propiedades de clases con respecto a número y
tipo.
•Los recursos para inferir qué elementos que tienen varias propiedades son
miembros de una clase en particular.
•Los recursos para determinar si todos los miembros de una clase tendrán una
propiedad en particular, o si puede ser que sólo algunos la tengan.
•Los recursos para distinguir entre relaciones uno-a-uno, varios-a-uno o uno-avarios, permitiendo que las "claves externas" de las bases de datos puedan
representarse en una ontología.
•Los recursos para expresar relaciones entre clases definidas en diferentes documentos en la Web.
•Los recursos para construir nuevas clases a partir de uniones, intersecciones y
complementos de otras.
•Los recursos para restringir rangos y dominios para especificar combinaciones
de clases y propiedades.
OWL nos ofrece 3 sublenguajes cuyo nivel de expresión es creciente a fin de que
podamos utilizar el que más se adecue a nuestras necesidades: OWL Lite, OWL DL y
OWL Full.
•OWL Lite ofrece soluciones a usuarios cuya necesidad principal es una clasificación jerárquica y simple de restricciones.
•OWL DL (description logics) ofrece soluciones a usuarios que quieren la
máxima expresividad que garantice que todas las conclusiones sean compu-
tables (todos los cálculos terminarán y en un tiempo finito). Incluye todas
las construcciones de OWL pero sólo pueden ser usadas bajo ciertas restricciones
•OWL Full ofrece soluciones a usuarios que desean la máxima expresividad y la
libertad sintáctica de RDF, a cambio de no ofrecernos ninguna clase de garantías computacionales.
Veamos un ejemplo de una ontología para el vino escrita en OWL.
<owl:Class rdf:ID="vino">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
<rdfs:label xml:lang="es">vino</rdfs:label>
<rdfs:label xml:lang="en">wine</rdfs:label>
<rdfs:label xml:lang="fr">vin</rdfs:label>
...
</owl:Class>
5 Adaptación Dinámica de Componentes y Servicios con OWL
La ingeniería del Software basada en componentes (Component-Based Software
Engineering o CBSE) centra sus esfuerzos en el desarrollo y construcción de aplicaciones software gracias a la integración de componentes software previamente
existentes. Así, la técnica clásica de desarrollo de sistemas escribiendo código se ve
complementada por el ensamblaje de componentes existentes. Por tanto, uno de los
máximos objetivos perseguidos por la CBSE es la flexibilidad y facilidad de mantenimiento de los sistemas software. Algunos de esos sistemas serán tan críticos que
su mantenimiento debe realizarse “al vuelo” lo que no permite parar todo el sistema,
modificar y reiniciar todo el sistema.
5.1 El Problema de la Adaptación
Adaptar aplicaciones basadas en componentes se reduce a la posibilidad de adaptar
uno (o más) componentes en tiempo de ejecución, o lo que es lo mismo, desconectar un componente y sustituirlo por otro nuevo (una nueva versión) [4]. Una adaptación dinámica puede ser necesaria debido a múltiples razones que podemos clasificar en 4 categorías: correctivas, adaptativas, de extensión y de perfeccionamiento.
Una adaptación correctiva elimina fallos de comportamiento del componente que se
está ejecutando, reemplazándolo por una nueva versión que tiene la misma funcionalidad pero que funciona correctamente. Cuando lo que hacemos en una adaptación
adaptativa, lo que se realiza es una adaptación de la aplicación en respuesta a cambios del entorno (hardware, sistema operativo, etc.). Otra clase de adaptación es la
adaptación por extensión en la que se añaden nuevas funcionalidades al sistema mediante la adicción de nuevos componentes. Por último, las adaptaciones de perfec-
cionamiento se realizan para mejorar la aplicación aun cuando esta funciona correctamente, reemplazando un componente por otro que ha sido optimizado.
Independientemente de la razón o el motivo de la adaptación, se pueden identificar
diferentes tipos de adaptación: adaptaciones de arquitectura, adaptaciones de implementación, adaptaciones de interfaces y adaptaciones de localización.
Las adaptaciones de arquitectura se producen cuando la adaptación afecta a la estructura de la aplicación y pueden ser realizadas añadiendo nuevos componentes,
eliminando algunos de los ya existentes o modificando las conexiones entre ellos.
Las adaptaciones de implementación son motivadas por motivos de rendimiento,
corrección o cambios del entorno que no fueron tenidos en cuenta en la implementación de un (o varios) componente(s) determinado(s). Un claro ejemplo de este
tipo de adaptación se vivió en Europa con el cambio monetario al euro.
Las adaptaciones de interfaces se producen cuando se modifica la lista de servicios
ofrecidos por un componente, bien sea añadiendo o eliminando funcionalidad de un
componente dado.
Las adaptaciones de localización se corresponden con los cambios de migración de
componentes de un lugar a otro por motivos de balanceo de carga, costos de hosting,
etc. El cambio, si bien no afecta a la arquitectura, ni a las interfaces, ni a la funcionalidad de la aplicación, afecta a las comunicaciones entre los diferentes componentes
del sistema.
A la hora de realizar una adaptación se deben satisfacer muchos requisitos, pero los
más importantes a tener siempre en cuenta son la consistencia, el rendimiento y el
grado de automatización. La consistencia concierne a la aplicación usada para adaptar la aplicación actual en tiempo de ejecución. Dicha aplicación que realice las
adaptaciones debe ser altamente prioritaria. Sin embargo, eso no debe suponer que
dicha aplicación de adaptación tenga todo tipo de derechos para hacer lo que quiera y
cuando quiera, ya que la operación de adaptación debe preservar la consistencia de la
misma. El tema del rendimiento se refiere a la duración de la adaptación y al número
de componentes afectados que deben ser mínimos. Y por ultimo, el grado de automatización es un punto importante, ya que representa la capacidad de una aplicación
de adaptarse a si misma; esto es posible cuando la aplicación tiene información relevante en tiempo de ejecución y es capaz de procesarla de manera que la propia aplicación se adapte a las circunstancias en tiempo de ejecución. Este es el punto de
vista de nuestra propuesta y vamos a ver cómo es posible usando OWL suministrar
una información processable automáticamente para adaptar peticiones de servicios
en tiempo de ejecución.
5.2 Una Solución al problema de Adaptación de Servicios en Tiempo de
Ejecución
Como se comentó anteriormente, la adaptación de una aplicación basada en componentes, generalmente, implica desconectar dicho componente de la aplicación y
conectar a la misma una nueva versión del componente. Básicamente, podemos encontrarnos 2 tipos de aplicaciones basadas en componentes: las aplicaciones en las
que todos los componentes están físicamente en la misma máquina y se enlazan
juntos para formar un ejecutable y aquellas en las que los componentes están distribuidos a través de la red. En la presente propuesta supondremos que estamos trabajando con un sistema en que los componentes están distribuidos en cualquier punto y
accesibles a través de la red, ya que es un caso más general y el caso de tener componentes locales puede ser simulado situando todos ellos en la misma dirección.
Cuando se realiza una modificación en un componente o se sustituye por otro, esto
se hace de forma transparente al componente que requiere los servicios del modificado. El problema surge cuando, pese a ofrecer una misma funcionalidad, la interfaz
del componente es diferente y la invocación del servicio no se corresponderá con la
invocación original. Esto supondría que el sistema dejara de funcionar. La solución
que proponemos se basa en adaptar la invocación del servicio desde el llamante mediante el uso de una ontología que permita al llamante saber cuál de los servicios
ofrecidos es el que deseamos o necesitamos y cómo debemos llamarlo a partir de la
información que tenemos, todo ello realizado en tiempo de ejecución.
En ese proceso de adaptación podemos encontrar 3 tipos de conflictos (no excluyentes entre sí):
•Conflicto de Nombre: ocurren cuando el nombre de un determinado servicio
no coincide con el nombre que tenía anteriormente.
•Conflicto de Parámetros: ocurre cuando un determinado servicio utiliza parámetros con tipos u orden diferentes a los que utilizaba originalmente.
•Conflicto de Composición: es el más difícil de solucionar y se produce cuando
un determinado servicio se transforma en la composición de varios servicios nuevos (o viceversa).
La idea de usar técnicas de Web semántica y concretamente el uso de ontologies
para resolver este problema, surge de que el problema es similar: razonar y procesar
el conocimiento y la información que tenemos para proporcionar al usuario aquello
que realmente desea.
La gramática usada en el lenguaje natural es muy amplia y compleja, sin embargo, la
gramática de la invocación de servicios es mucho más sencilla y mejor definida y su
análisis nos permite distinguir entre los determinados elementos de la misma. Una
invocación típica podría ser como muestra la Figura 3
Figura 3. Gramática de la Invocación de un Servicio.
De esta manera, usando una ontología podremos saber qué servicios son equivalentes, qué complementos son equivalentes o los tipos de los mismos e incluso qué
posibles sujetos (componentes que realizan un servicio) podrían ser equivalentes
con la consecuencia utilidad para la tolerancia a fallos.
5.3 Uso de OWL para Implementar la Adaptación
Dentro del conjunto características que permite OWL Lite tenemos las relacionadas
con equivalencias (Equality y Inequality), que nos van a permitir establecer qué
conceptos son equivalentes y cuáles no. En nuestra propuesta usaremos las equivalencias de clase, propiedad y la identidad: equivalentClass, equivalentProperty y sameAs.
•equivalentClass : esta característica nos permite establecer clases de
componentes que son equivalentes. Por ejemplo, la clase coche es equivalente a la clase automóvil.
•equivalentProperty: esta característica nos permite establecer propiedades equivalentes. Por ejemplo, tiene un jefe podría ser una propiedad
equivalente a tiene un superior.
•sameAs: esta característica nos permite definir sinónimos de un individuo,
Por ejemplo, José es lo mismo que Pepe.
Utilizando estas propiedades, estableceremos que dos servicios son sustituibles para
ser adaptados si son el mismo (sameAs) o son una propiedad equivalente (equivalentProperty) y dos tipos, dos nombres o dos componentes son sustituibles
para ser adaptados si son el mismo (sameAs) o son de una clase equivalente
(equivalentClass).
6 Trabajos Relacionados
Analicemos las diferentes propuestas que tienen similitudes a la nuestra y las razones que nos han llevado a tomar una opción u otra:
OWL-S es una ontología para describir Servicios Web representados en OWL.
OWL-S establece tres nociones de alto nivel [5]:
•El Perfil de Servicio. Incluye información para el anuncio y publicación de
servicios y que es usado para la localización del servicio Web deseado por
parte de un cliente.
•El Modelo de Servicio. Contiene la información relativa a la descripción de la
funcionalidad de un servicio y está concebida como un proceso.
•La Base del Servicio. Nos da los detalles concernientes al acceso al servicio,
es decir, el cómo pasar de lo abstracto a la utilización concreta de un servicio.
Figura 4. Nociones de Alto Nivel de OWL-S
El uso OWL-S puede ser una mejora importante en nuestra propuesta, sin embargo,
en una primera versión se ha querido optar por un modelo más simple. Sin embargo,
las características del perfil de servicio relativas a los parámetros pueden ser muy
útiles en el proceso de adaptación. No obstante, las características que se incluyen
en las tres nociones de OWL-S no son suficientes para discernir entre dos servicios
para asber si son equivalentes o no.
WSMO [2] (Web Service Modeling Ontology) presenta una ontología para la descripción de servicios Web semánticos, expresados en un lenguaje nuevo (WSML)
que es compatible con XML, y OWL. Propone una ontología basada en la utilización
de cuatro componentes: Objetivos, Mediadores, Servicios Web y Ontologías. Debido a que la descripción de los servicios se realiza mediante una ontología que puede
ser especificada en cualquier lenguaje (aunque se recomienda WSML-Core) hemos
preferido no usar esta metodología aunque nuestra propuesta pudiera ser incorporada
a la misma.
METEOR-S [7] centra su objetivo en la integración de tecnologías de servicios Web,
tales como WSBPEL (Web Services Business Process Execution Language), WSDL
(Web Service Description Language) y UDDI (Universal Description, Discovery and
Integration) con tecnologías de Web semántica para poder automatizar la tarea de
publicación, descubrimiento, descripción y control de flujo de los servicios Web.
Sin embargo, METEOR-S carece de un modelo conceptual para la descripción de
servicios y aspectos relacionados con estos, lo que nos haría complicado pode discernir entre servicios que sean equivalentes y los que no lo sean.
7 Detalles de Implementación
A la hora de realizar una implementación de la propuesta hemos asumido que nuestros componentes distribuidos serán servicios Web implementados usando el lenguaje C# bajo la plataforma Microsoft .NET. Microsoft .NET es un conjunto de
tecnologías software desarrolladas para la conexión e intercambio de información
entre personas, sistemas y dispositivos. Esto permite un nivel sin precedentes de
integración de software a través del uso de Servicios Web XML, mediante el cual
todo tipo de aplicaciones pueden relacionarse e interoperar a través de Internet.
Un Servicio Web no es muy diferente de una aplicación tradicional cliente-servidor.
Básicamente, un cliente necesita datos o un servicio y para ello realiza invocaciones
al servidor. Bajo este punto de vista, los servicios Web no ofrecen nada nuevo al
mercado del software. Sin embargo, la mayor diferencia y lo que ha hecho que se
convierta en una herramienta en auge viene dada del hecho de que los Servicios Web
utilizan tecnologías, lenguajes y protocolos estándar como son HTTP, XML, SOAP,
etc., lo que hace posible su interoperatibilidad con cualquier plataforma (propietaria
o no) y con cualquier tecnología que respete los estándares antes mencionados. La
plataforma Microsoft .NET facilita el trabajo de “fontanería” o bajo nivel a la hora de
usar y desarrollar servicios Web, pero no existe ningún problema ni limitación en su
uso y accesos a través de cualquier otra plataforma, lenguaje o aplicación que siga
los mismos estándares.
La forma habitual de invocar un servicio proporcionado por un servicio Web es usar
una clase intermediaria (proxy) que es generada automáticamente por la utilidad
wsdl. Sin embargo, si queremos ser capaces de modificar nombres, parámetros,
tipos, etc. de las llamadas en tiempo de ejecución necesitaremos ser capaces de
construir los mensajes correspondientes para dichas invocaciones en tiempo de
ejecución. Para ello lo que tendremos en un intermediario genérico que realizará las
llamadas a partir de cadenas de caracteres que le pasaremos como argumentos y que
serán el resultado de las adaptaciones. En el código siguiente pueden verse algunos
detalles del mismo.
// setup the request
WebRequest webRequest=WebRequest.Create(webServiceURL);
HttpWebRequest httpWebRequest =
(HttpWebRequest)webRequest ;
httpWebRequest.Method = "POST" ;
httpWebRequest.ContentType = "text/xml" ;
httpWebRequest.Headers.Add("SOAPAction: "+soapAction) ;
Stream sendStream = httpWebRequest.GetRequestStream();
// put Request text into the request stream
StreamWriter sw = new StreamWriter(sendStream);
sw.Write (soapEnvelope);
sw.Close ();
// make the request and get the response.
WebResponse webResponse = null;
StreamReader streamReader = null ;
string result ;
try
{ webResponse = httpWebRequest.GetResponse () ;
Stream rs = webResponse.GetResponseStream();
streamReader = new StreamReader (rs) ;
result = streamReader.ReadToEnd () ;
}
7.1 La Adaptación
El problema que estamos abordando se produce cuando al realizar una invocación del
servicio deseado, en vez de obtener el resultado de la misma, obtenemos una excepción. Esta excepción puede deberse a que el servicio no exista en el componente
remoto o a que dicho componente no está disponible. Si bien en la propuesta actual
sólo nos hemos implementado una adaptación para el primero de los problemas, y
supondremos que el componente remoto está disponible, la adaptación del sujeto
que realiza el servicio sería sencilla y similar a lo que hemos realizado, ya que sólo
habría que buscar en la red o mediante UDDI un componente que según nuestra ontología fuera el mismo (sameAs) o fuera de una clase equivalente (equivalentClass).
Centrémonos ahora en el problema que estamos abordando y supongamos que tras la
solicitud de un servicio obtenemos una excepción indicando que dicho servicio no
está disponible. Y tengamos en cuenta el contexto de nuestra implementación en el
que los componentes remotos son servicios Web. En este caso el componente que
desea el servicio ejecutará de forma automática y en tiempo de ejecución las siguientes tareas:
1. Descargar el nuevo interfaz del componente remoto (ver código 4).
2. De los servicios ofrecidos por el nuevo componente buscar aquel que, según la ontología que disponemos, sean igual (sameAs) o sea propiedad
equivalente (equivalentProperty).
3. Completar la llamada usando como parámetros los que sean los mismos
(sameAs) o son de una clase equivalente (equivalentClass) de entre
los que tenemos de la llamada original.
4. Si el paso 3 no fuera posible ser completado se busca un nuevo servicio
candidato y se repite el paso 3.
Si hubiera servicios equivalentes pero no se pudiera completar ninguno por falta de
información, se completaría con valores por defecto (null, “”, 0, ‘’) salvo
que en la ontología haya definido algún valor equivalente al “nulo” para un tipo determinado.
8 Conclusiones y Trabajos futuros
El trabajo realizado aprovecha las técnicas y avances realizados en el campo de la
Web semántica para la adaptación de servicios de componentes distribuidos y más
en concreto en el campo de componentes implementados como servicios Web.
Dichas técnicas de análisis semántico aplicado a la Web, como se ha podido ver,
pueden ser usadas para adaptar el nombre de los servicios, los parámetros de los
mismos, e incluso, el componente que realiza el servicio.
La experiencia relatada a lo largo del trabajo actual son los comienzos de un trabajo
que pretende seguir con el estudio de esta vía y su inclusión en el marco de arquitectura propuesta por los autores en ediciones pasadas de IDEAS [6] para el desarrollo y
coordinación de componentes software, de manera que todo esté integrado en una
herramienta automática que sea capaz de generar aplicaciones software a partir de la
composición de componentes previos, su coordinación y su adaptación de manera
que minimice los problemas de mantenimiento y evolución a lo largo de la vida del
sistema.
Referentes
1. Berners-Lee T., Hendler J., Lassila O., The Semantic Web, Scientific American,
http://www.scientificamerican.com/article.cfm?articleID=00048144-10D2-1C7084A9809EC588EF21&catID=2, 2001.
2. Domingue, J., Cabral, L., Hakimpour, F., Sell D., Motta, E. IRS III: A Platform and Infrastructure
for Creating WSMO-based Semantic Web Services. Proceedings of the Workshop on WSMO
Implementations (WIW 2004) Frankfurt, Germany, September 29-30, 2004
3. Hendler J.,Berners-Lee T., Miller E., Integrating applications on the Semantic Web, Journal
IEEE Japan, 122(10):676-680, 2002.
4. Ketfi A., Noureddine B., Pierre-Yves C. Dynamic updating of component-based applications.
SERP'02, Las Vegas, Nevada, USA, 2002.
5. Martin D., Burstein M., Hobbs J., Ora L., McDermott D., McIlraith S., Narayanan S., Paolucci
M., Parsia D., Payne T., Sirin E., Srinivasan N., Sycara K., OWL-S: Semantic Markup for Web
Service. W3C Member Submission 22 November 2004.
6. Pastrana J.,Pimentel E.,Katrib M., Adaptación y Reutilización de Componentes Distribuidos,
en: 8° Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software.
IDEAS?05, Universidad Técnica Federico Santa María , Valparaíso, Chile,2005
7. Verma K., Sivashanmugam K., Sheth A., Patil A., Oundhakar S., Miller J., METEOR-S WSDI:
A Scalable Infrastructure of Registries for Semantic Publication and Discovery of Web Services,
Journal of Information Technology and Management, Special Issue on Universal Global Integration, Vol. 6, No. 1 (2005) pp. 17-39. Kluwer Academic Publishers
8. W3C Recommendation, RDF Primer,http://www.w3.org/TR/2004/REC-rdf-primer-20040210
9. W3C Recommendation, OWL Web Ontology Language. Use Cases and Requirements,
http://www.w3.org/TR/2004/REC-webont-req-20040210/.