EMBEDMENT AND RECONCILIATION 4a Embedment

Para poder hacer uso de un servicio Web, un agente software necesita una descripción del servicio que sea interpretable por un computador, y el medio por el cual es accedido. El uso de DAML+OIL o posteriormente OWL proporciona el marco de trabajo apropiado para poder desarrollar esto. A continuación se describirá este tipo de ontologías basándonos en la especificación en el primero de los lenguajes [Ank02], [DAMLS05].

Un servicio descrito con DAML-S permite a un agente software localizar, invocar, interoperar y monitorizar dicho servicio. DAML-S proporciona respuesta a las principales preguntas que cabe plantearse a la hora de describir un servicio Web:

• ¿Qué es lo que el servicio requiere de los usuarios, u otros agentes y que les proporciona?

• ¿Cómo funciona el servicio?

• ¿Cómo se puede utilizar el servicio?

Atendiendo a estas cuestiones anteriormente planteadas se hace necesario el desarrollo de una ontología de orden superior de servicios en la que aparecen determinados conceptos que intentan responder a estas preguntas.

La ontología de servicios fue estructurada considerando las funcionalidades arriba descritas. Esto dio lugar a tres subontologías reunidas en una cuarta que sirve para identificar el servicio como un concepto Service y que permite relacionar los tres tipos de conocimientos del servicio descritos por las otras tres.

La clase Service es el punto de referencia para poder anunciar un servicio Web. Esta clase Service tienen tres propiedades presents, describedby, supports donde los rangos de estas propiedades son las tres clases asociadas para representar cada parte de un servicio: ServiceProfile, ServiceModel, ServiceGrounding respectivamente. Cada vez que queramos anunciar un servicio, deberemos de instanciar cada una de estas clases.

• La clase Service es presentada (presents) por Service Profile, que nos sirve para definir qué es lo que el servicio necesita del usuario o agente.

• La clase Service es descrita (describedby) por Service Model, en el que explica cómo trabaja el servicio (cómo debe usar los inputs, el flujo de datos en un servicio compuesto etc.).

• La clase Service es soportada (supports) por Service Grounding, nos indica cómo debe ser invocado el servicio.

Service Profile responde a la primera de las preguntas, es decir a “qué es lo que el

servicio requiere de los usuarios, u otros agentes y qué cosas proporciona el servicio a ellos”. Service Profile provee una forma de describir los servicios ofrecidos por los proveedores y los servicios necesitados por los solicitantes. Esencialmente, es una pequeña descripción de lo que hace el servicio, describiendo el servicio como una función de tres tipos básicos de información:

• especificación comprensible para un humano del servicio, que contiene información sobre la organización que provee el servicio y participantes,

• especificación de las funcionalidades que proporciona el servicio en términos de parámetros (entradas, salidas, precondiciones y efectos).

• conjunto de atributos no funcionales que proveen información adicional sobre las necesidades del servicio (QoS, región en la que se aplica el servicio etc.).

Service Model responde a la segunda de las cuestiones anteriores, es decir, a “cómo

funciona el servicio”. Describe que sucede cuando un servicio se lleva a cabo. El SW que queramos modelar será un ejecutable o un CGI o cualquier aplicación que sea accesible por web. La perspectiva del SW se vio desde DAML-S como un proceso, así pués el Service Model se especializa en un Modelo de Proceso integrado por dos componentes:

• Process Model: Describe el servicio en términos de sus componentes o subprocesos. El servicio es descrito en términos de sus entradas, salidas, precondiciones y efectos.

• Control Model: permite al agente monitorizar la ejecución del servicio seleccionado.

El Service Grounding de un servicio sirve para especificar como acceder al servicio (formato de mensajes, protocolo de interacción, direccionamiento y transporte). Se puede ver como una correspondencia o mapeo entre la especificación abstracta y la concreta, de aquellos elementos de descripción del servicio que son requeridos para la interacción con el servicio (entradas y salidas de los procesos atómicos18).

La figura 4.19 representa la ontología de servicios asociada:

18

Proceso atómico es áquel que es directamente invocable (previo paso de mensajes de forma apropiada), no tienen subprocesos y se ejecutan en un solo paso, desde la perspectiva del cliente. Es decir, toman un mensaje de entrada, se ejecutan y devuelven un mensaje de salida.

Figura 4.19 Ontología de servicios Web DAML-S [Mar02b]

Esta ontología DAML-S presenta dos restricciones de cardinalidad en sus propiedades:

• Un SW puede ser descrito como mucho por un ServiceModel

• Un ServiceModel debe estar asociado por al menos un ServiceGrounding

En principio para describir un servicio Web se necesitarán las tres propiedades para hacerlo correctamente, pero no se indica ninguna restricción respecto una cardinalidad mínima para las propiedades presents, described by, ni máxima cardinalidad para las propiedades presents, supports (un servicio podrá ser representado de diferentes formas, así como ser usado o invocado de diferentes formas si se quiere).

Una exposición detallada de las ontologías de descripción de servicios, puede ser encontrada en el documento denominado “Ontologías necesarias para la descripción

de servicios Web” en la URL http://robotica.uv.es/tesis/javi/document.html y en el CD-

ROM que acompaña esta memoria.

4.7.4.1 Diferencias entre DAML-S 0.9 y OWL-S 1.0

La versión 1.0 ofrece un número de refinamientos en el Service Profile y en el Process Model. Las mejoras sobre DAML-S 0.9 incluyen: clarificación y simplificación de los parámetros de descripción de la capacidad (es decir, entradas, salidas, condiciones previas y efectos), una integración más ajustada con el modelo de proceso (Process Model), y de una mejor organización / modularidad de los constructores del perfil (Profile). Los constructores en el Process son ahora los mismos que en el Profile. [Mar04].

Existe una diferencia en la definición de un proceso según se emplee la ontología de DAML-S versión 0.9 u OWL-S 1.0. En la versión 0.9, los procesos de un servicio Web son entendidos como subclases de la clase atomic o composite, mientras que en

OWL-S 1.0, se describe a los procesos como instancias de dichas clases. Este cambio de mentalidad, tratar ahora los procesos como instancias, surgió de diferentes reuniones del comité de DAML-S y discutidas por los propios desarrolladores y miembros de DAML- S como David Martin en el foro de W3C sobre SW [Mar03b]. En la comunicación se muestran las ventajas que tiene representar los procesos como instancias o como clases. La ventaja de los procesos como instancias se resume en que permite ser más concreto en la descripción, facilidad para leer y entender un proceso. Parece más intuitivo entender los procesos como instancias, además de que al definir procesos como clases se deben usar constructores difíciles de ser soportados; mientras que las ventajas de tener los procesos como clases son la elegancia con la que quedan representadas, una sensación de mejor aprovechamiento del razonamiento con DL y la posibilidad de tener instancias como trazas de ejecuciones del servicio.

A su vez en OWL-S 1.0 se plantean la necesidad de representar las condiciones19 mediante dos lenguajes de reglas: SWRL, bajo desarrollo en W3C y DRS [McD04], descrito por Drew McDermott en un apéndice de OWL-S 1.0 Release. Sin embargo dejan en manos del modelador la tarea de decidir sobre la adopción de uno u otro.

Se pueden observar las diferentes especificaciones para los SWS de tráfico creados en la URL http://robotica.uv.es/tesis/javi/sws.html y en el CD-ROM que acompaña esta memoria.