ONTOLOGÍAS PARA LA DESCRIPCIÓN DE SERVICIOS WEB: DAML-S (OWL-S) 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 ontologia 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 ServiceProfile, que nos sirve para definir que es lo que el servicio necesita del usuario a agente. La clase Service es descrita (describedby) por ServiceModel, en el que explica como trabaja el servicio (como debe usar los inputs, el flujo de datos en un servicio compuesto etc.). La clase Service es soportada (supports) por ServiceGrounding, nos indicara como debe de ser invocado el servicio. La figura 1 representa la ontología de servicios asociada: Recurso Web proporciona Servicio Web soportado presentado por descrito por Grounding Servicio Profile Servicio Que proporciona el servicio Web Process Servicio Como se accede al servicio Como funciona el servicio Figura 1 Ontología de servicios Web DAML-S [Mar02b] Esta ontología DAML-S presenta dos restricciones de cardinalidad en sus propiedades: Un servicio web puede ser descrito como mucho por un ServiceModel Un ServiceModel debe de 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). A continuación se describen cada una de estas clases, ya que cada una aporta un conocimiento o información diferente acerca del servicio web. 1.1. Service Profile El objetivo principal del Service Profile (ver figura 2) es poder determinar si un servicio coincide con las necesidades de una determinada petición. Por tanto, el Service Profile puede ser usado para popularizar los registros de servicios, automatizar el descubrimiento de estos y su selección (emparejamiento). El Profile de DAML-S no se desarrolló orientado hacia ninguna arquitectura de almacenamiento, pero el tipo de almacenamiento seleccionado para almacenar Profiles debe de soportar consultas y un motor de búsqueda semántico. 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 que 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, y conjunto de atributos no funcionales que proveen información adicional sobre las necesidades del servicio (QoS, región donde se aplica el servicio etc.). Veamos ahora a un sumario de la clase y las propiedades del Profile: serviceProfile: Es la clase que nos sirve para representar a los Profiles. Cuando queramos representar un servicio debemos instanciar esta clase. Dos relaciones entre el servicio y el profile: presents (relaciona una instancia del servicio con una instancia de Profile, “el servicio es descrito por este perfil”) y presentedBy (inversa de la anterior). serviceName: nombre que damos al servicio que ofrecemos (solo se puede dar un nombre). textDescription: descripción del servicio de forma que puede ser leída por el humano. Se puede aprovechar para introducir keys para mejorar la búsqueda como explicaremos más adelante. contactInformation: información sobre el proveedor del servicio, es una instancia de la clase Actor. Actor: clase que reúne las propiedades que se debe definir de la información de contacto del proveedor. Estas propiedades son: name (nombre de la persona o departamento del proveedor), title (cargo en el proveedor), phone, fax, email, physicalAdress (dirección del proveedor) y webURL. Parámetros de funcionalidad: son los componentes más importantes del Profile ya que son los que especifican de verdad las capacidades del servicio que queramos proveer. Estos parámetros se dividen en dos grupos: los que indican la transformación de información y los que producen un cambio de estado debido a la ejecución. Los que indican la transformación de información son los inputs (información que el servicio pide al usuario) y los outputs (información que devolverá el servicio). Los que indican el cambio de estado son las precondiciones que se deben cumplir antes de ejecutar el servicio y los efectos que se tiene al ejecutar el servicio (Ej.: al comprar un libro el efecto sería el cargo en la tarjeta de crédito). Por tanto el servicio transformará las entradas de los usuarios u otros servicios en salidas, pero además puede requerir que algunas precondiciones se cumplan y puede dar lugar a efectos que cambien el estado del servicio o de la gente/servicios que interactúan con él. Los parámetros en DAML-S son1: 1 ParameterDescription: es la clase que utilizamos para identificar, dar valor semántico y referenciar en el process model todas las IOPE’s (Inputs, Outputs, Preconditions, Effects). Por lo tanto tiene tres propiedades: parameterName (identificar), restrictedTo (da un valor semántico) refersTo (da la referencia en el Process Model). Para representar las precondiciones y los efectos se recomienda en OWL-S un lenguaje de reglas como SWRL [SWRL04] para poder definirlos pero, en DAML-S se definen como los inputs y outputs. Input: especifica una entrada del servicio. Es una instancia de la clase Parameterdescription donde definimos el identificador del input, a que clase o valor semántico tiene y a que input se refiere en el Process. Output: especifica una salida del servicio. Es una instancia de la clase Parameterdescription donde definimos el identificador del output, a que clase o valor semántico tiene y a que output se refiere en el Process. Precondition: especifica una precondición del servicio. Es una instancia de la clase Parameterdescription donde definimos el identificador de la precondición, a que clase o valor semántico tiene y a que precondición se refiere en el Process. Effect: especifica un efecto del servicio tras su ejecución. Es una instancia de la clase Parameterdescription donde definimos el identificador del efecto, a que clase o valor semántico tiene y a que efecto se refiere en el Process. Se debe tener en cuenta que la descripción de efectos/salidas proporciona la posibilidad de que el servicio pueda ser usado por otros. Tal y como afirman algunos autores la descripción de los efectos/salidas se convierte en crucial cuando hablamos de la composición de servicios y deja de ser relevante en la descripción de servicios atómicos, donde basta con la especificación de entradas y salidas. La cuestión clave reside en la determinación de la necesidad de efectos en aquellos servicios que sólo aportan información.2 Atributos o parámetros no funcionales: son atributos que no son obligatorios ponerlos en todos nuestros servicios, pero sirven para definir alguna propiedad más. Suelen utilizarse para que los propios proveedores añadan las características especiales que creen ofrecen sus servicios Web. Se pueden añadir más a los ya definidos por DAML-S gracias a otras propiedades definidas para la clase Profile, pero los principales son: serviceCategory: Es una clase en el que se define un nombre y un código a cada una de las categorías de servicio. Sirve para clasificar nuestro servicio. Inicialmente existen dos clasificaciones de servicios que nos pueden servir para rellenar estos parámetros, la clasificación NAICS [NAICS04] y la UNSPSC. QualityRating: Información adicional para el usuario acerca de la calidad del servicio que se le provee (las estrellas de los servicios de hotel, los tenedores de restaurantes etc ). GeographicRadius: Sirve para indicar en que región o país es efectivo el servicio que ofrecemos (por ejemplo un servicio de venta de libros que solo quiere vender a la región de Valencia). Para definir un profile de un servicio Web, debemos de instanciar la clase Profile aquí definida, que completaremos dando valores a las propiedades que describen las capacidades de nuestro servicio. 2 En el caso de servicios que ofrezcan información de tráfico a un usuario, después de la ejecución del servicio, el usuario dispondrá del conocimiento requerido, pero este cambio de estado no es un cambio tangible y por la tanto no queda muy claro la posibilidad de su uso en el proceso de descubrimiento de un servicio o en la composición, donde las precondiciones de unos servicios se conviertan más tarde en precondiciones de otros. Figura 2 Service Profile Ontology [Mar02b] 1.2. Service Model Responde a la segunda de las cuestiones anteriores, es decir, a “como funciona el servicio”, es decir, describe que sucede cuando un servicio se lleva a cabo. El servicio Web que queramos modelar será un ejecutable o un CGI o cualquier aplicación que sea accesible por web. La perspectiva del servicio Web se vio desde DAML-S como un proceso. Desde este punto de vista definieron el Process Model con las propiedades y parámetros apropiados para permitir representar y modelar todos los servicios Web que se pueden dar en el mundo real. El Process Model se subdivide en dos componentes: Process Model: Describe el servicio en términos de sus componentes o subprocesos. Cada proceso puede ser visto como un único componente o como un conjunto de procesos que se especifican mediante un conjunto de estructuras de control. 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. Ambos componentes serían usados para automatizar las tareas de invocación, composición, interoperación y monitorización. El Process Model es conocido como Ontología Proceso y el ControlModel como Ontología de Control de Proceso. 1.2.1. Process Model Este componente fue preparado teniendo en cuenta muchas de las fuentes de las que debe proveer información (inteligencia artificial, sistemas distribuidos, estándares en modelización de procesos, modelización de verbos semánticos y eventos, etc.), así como su uso para poder definir cualquier servicio con independencia del dominio al que pertenezca. La principal entidad de esta ontología es la clase Process (ver figura 3) y donde resulta necesario definir las propiedades adecuadas para especificar los inputs necesarios para poder hacer la invocación del servicio, así como los outputs que generara el servicio tras su ejecución. Además de estos parámetros, puede ser que se necesiten que ciertas precondiciones se cumplan antes de pedir o invocar el servicio, por lo que es necesario definirlas como un parámetro más del process y análogamente tras la ejecución del servicio además de los outputs es posible que se puedan tener efectos. Tanto los efectos como los outputs pueden tener condiciones asociadas, porque puede ser que se den una salida u otra dependiendo del resultado de la ejecución del servicio. Estas IOPE’s son subpropiedades de parameter (que es la propiedad que tiene asociada la clase Process), y en principio no se les da ningún tipo de restricción a ninguna clase concreta, ni de cardinalidad, aunque según el tipo de process que vayamos a definir se pueden definir si es necesario. Figura 3 Service Model Ontology [Mar02b] El Process de los servicios web se puede subdividir (son clasificadas en la ontología como subclases) en tres tipos de procesos: Atomic, Simple, Composite. Proceso Atómico (Atomic): Son aquellos que son directamente invocables (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. Para cada proceso atómico, se debe de proveer un “grounding” que habilite a un cliente que solicita el servicio para construir los mensajes. Proceso Simple (Simple): No son invocables y no son asociados con un “grounding”, pero como los anteriores, son concebidos para poder ser ejecutados en un solo paso. Los procesos simples son usados como elementos de abstracción; un proceso simple puede ser usado para proporcionar una vista de algún proceso atómico o una representación simplificada de algún proceso compuesto. En el primero de los casos el proceso simple es realizado por (realizedBy) el proceso atómico; en el segundo caso, el proceso simple es expandido a (expandsTo) el proceso compuesto. Proceso Compuesto (Composite): Son aquellos que son descomponibles en otros (no descomponibles o compuestos) procesos; su descomposición puede ser especificada mediante el uso de constructores tales como Sequence, Split, Split + Join, Choice, Unordered, Condition, If-Then-Else, Iterate, Repeat-While y Repeat-Until. Es decir, mediante DAML-S es posible especificar servicios compuestos por procesos que se ejecutan uno tras otro (sequence), concurrentemente ( Split ), concurrentemente y con sincronización parcial ( Split + Join ), cíclicamente hasta terminar y controlando el flujo de ejecución mediante una estructura if-then-else o repeat-until etc. 1.2.2. Control Model Un process se instancia cuando va a ser ejecutado. Para controlar y monitorizar esta ejecución desde DAML-S se quiere escribir una subontología para permitir a agentes Web interpretar la ejecución. Sus características principales deberán ser: o o o Proveer unas reglas de mapping entre los inputs y precondiciones y los correspondientes outputs. Proporcionar un modelo de estado temporal de la ejecución de un servicio compuesto (para conocer por donde va la ejecución). Proporcionar unos mensajes de representación del estado de la ejecución, para que pueda ser monitorizada. Estos mensajes deben incluir successful, failed and interrupted para que un agente los entienda y reaccione con la rutina adecuada. 1.3. Service Grounding El 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ómicos). DAML-S no incluye una construcción abstracta para la definición de los mensajes, pero esta implícitamente declarado si entendemos que los inputs y los outputs de un proceso atomic serán el contenido de los mensajes. Los mensajes concretos son especificados explícitamente en un grounding, de tal manera que la función principal es la de mostrar como las entradas y salidas (abstracción) de un proceso atómico se concretan mediante el uso de mensajes que transportan estas entradas y salidas en algún formato que permita dicha transmisión. Como el área de concretización de mensajes ya estaba bastante avanzado en la investigación se optó desde la coalición por usar WSDL, debido al gran apoyo que la industria le está dando. 1.3.1 La relación entre DAML-S y WSDL El concepto de grounding de DAML-S es consistente con el concepto de enlazado (binding) de WSDL, por lo que con la ayuda de la extensibilidad de los elementos que posee WSDL y la idea de grounding que se tenía en DAML-S se pueden combinar ambas para el grounding de un proceso atomic. El trabajo de DAML-S/WSDL grounding es primero definir en WSDL los mensajes y operaciones por los que un proceso atómico es accedido, y entonces especificar las correspondencias entre procesos atómicos DAML-S y operaciones WSDL y por otra parte, entre el conjunto de entradas y salidas de un proceso atómico DAML-S y mensajes WSDL (ver figura 4). Figura 4 Conexión DAMLS-WSDL [Mar02b] Por un lado, la definición de procesos en DAML-S permite describir de forma abstracta cuáles son los parámetros (inputs, outputs) que intervienen en un servicio Web, ofreciéndonos la posibilidad de expresar estos parámetros con las capacidad y expresividad semánticas que nos permiten las clases y mecanismos del lenguaje de ontologías DAML + OIL (mejores que las que ofrece los tipos de XML Schema usado por WSDL). Por otro lado, WSDL nos ofrece una infraestructura bastante avanzada y desarrollada para el intercambio de mensajes por la Web utilizando diferentes protocolos y mecanismos. Tanto WSDL como la subontología de Grounding de DAML-S son necesarios para la definición del grounding de un servicio. Ambos lenguajes no abarcan la misma materia, pero coinciden en ciertos puntos haciéndolos compatibles. Esta zona donde ambos lenguajes coinciden es aquella parte de los mensajes WSDL llamado “abstract types” que sirven para especificar los inputs y outputs de un servicio. Si WSDL emplea en su descripción normal los tipos del XML Schema, ahora se puede enlazar a las clases de DAML+OIL para cada uno de los inputs y outputs.. Por lo tanto, los mensajes de WSDL, en la parte de abstract types emplean clases de DAML+OIL que después son confiadas a las estructuras que enlazan con el formato de los mensajes. Se sintetiza la conexión entre DAML-S y WSDL en los siguientes tres puntos: Un proceso atómico de DAML-S se corresponde con un operation de WSDL. Se distinguen diferentes casos: Un proceso atómico con inputs y outputs se corresponde con una operation de WSDL del tipo request-response. Un proceso atómico con inputs pero sin outputs se trata de una operation one-way. Un proceso atómico con outputs pero sin inputs se corresponde con una operation notification. Un proceso compuesto con inputs y outputs, donde los outputs son devueltos después de haber sido recibidos los inputs, se corresponde con una operation solicit-response. El conjunto de inputs y de outputs de una descripción de un proceso DAML-S, se corresponden con el concepto de mensajes correspondiente de una operation WSDL. Los tipos o clases DAML+OIL a las que pertenecen los inputs y outputs de un proceso DAML-S se corresponden con la parte de abstract type de una especificación de un mensaje en WSDL. Por tanto, cuando se construye un grounding de un servicio, deberemos de hacer uso de ambos lenguajes, y deberemos de especificar la conexión que existe entre ambos, al igual que hacer el mapeo de los inputs y outputs descritos en el proceso DAML a los inputs y outputs que se utilizaran para formar el mensaje WSDL. Por lo tanto es importante identificar en un servicio cuáles son los procesos atómicos, los inputs y outputs que tendrá y la especificación correspondiente de los tres puntos, señalados antes a WSDL. 1.3.2 Grounding de un servicio Web con WSDL y SOAP DAML-S es una ontología escrita en DAML + OIL, un lenguaje basado en XML, y como ya ha sido expuesto, el grounding de un proceso descrito en DAML-S se puede enlazar con una descripción WSDL. En la definición de los servicios Web se recomienda que se emplee el protocolo SOAP para el intercambio de mensajes, utilizando como mecanismo de trasporte HTTP. El grounding de un proceso DAML-S con enlazado WSDL y SOAP, obliga a definir la descripcion del servicio en WSDL con todas sus partes (types, message, operation, port type, binding y service). WSDL especifica tipos (campo types) abstractos usando XML Schema así como la definición de clases OWL o DAML + OIL. Si el tipo es una clase se puede definir completamente en esta parte del mensaje o puede ser definido en un fichero aparte indicando aquí un enlace a esa definición mediante la etiqueta DAML-S-parameter. Las extensiones que incluyeron los desarrolladores de DAML-S a la especificación de la sintaxis del lenguaje WSDL son las siguientes: En la definición del mensaje WSDL, el atributo DAML-S-parameter / OWL-sparameter para indicar la descripción completa del input u output correspondiente del servicio con la del mensaje. Este atributo es empleado si el tipo del input o output es una clase de DAML + OIL u OWL Si el tipo es una clase DAML + OIL, se señalará con el atributo encodingStyle la dirección del lenguaje que se emplea para representar este tipo. En nuestro caso es “http://www.daml.org/2001/03/daml+oil.daml” para conceptos de este lenguaje y la correspondiente para conceptos OWL. Todas las partes del mensaje que empleen este atributo servirá para indicar el lenguaje utilizado para que sea instanciado. En cada operación WSDL definida, el atributo DAML-S-process / OWL-sprocess nos sirve para enlazar con el process atómico definido. 1.3.3. La clase DAML-S Grounding La subontología de DAML-S orientada a grounding esta destinada a enlazar con la descripción WSDL del servicio, es decir, enlazar las diferentes partes descritas en el proceso DAML-S con las partes de un mensaje WSDL. Se definien dos clases principales en esta subontología: WSDLGrounding y WSDLAtomicProcessGrounding. La primera clase sirve para identificar el grounding del servicio y que a la vez posee propiedades de instancias de la otra clase que identifican los diferentes procesos atómicos que componen el servicio. Cada instancia de WSDLAtomicProcessGrounding posee propiedades propias para indicar cada una de las partes de un mensaje WSDL a que parte o propiedad de un proceso se corresponde. Estas propiedades y su correspondencia son: wsdlVersion: una URI que indica la versión de WSDL que se emplea. wsdlDocument: una URI a un documento WSDL a la que se refiere el grounding del servicio. wsdlOperation: la URI del correspondiente operation de la descripción WSDL del proceso atómico dado. wsdlInputMessage: la URI que apunta a la definición del mensaje que contiene todos los inputs del proceso. wsdlInputs: un objeto que contiene una pareja de mapping, una por cada input del mensaje de input definido en la descripción WSDL. Cada pareja es una instancia de la clase WSDLInputMessageMap. Un elemento de la pareja es la URI que identifica parte del mensaje WSDL, y la otra es la propiedad input definida para ese proceso a la que se refiere. wsdlOutputMessage: análogo a la de inputs pero respecto a los outputs. wsdlOutputs: como la clase análoga de inputs, solo que ahora para definir las parejas de la URI de la parte del mensaje WSDL y la URI del output del proceso es WSDLOutputMessageMap. Se puede observar que cuando hemos definido el grounding y los mensajes de entrada y salida del servicio, hemos empleado inputs y outputs, nunca inputs u outputs condicionales. Esto es debido a que la versión WSDL 1.1 que es la empleada, no permite que un servicio tenga definidas salidas condicionadas al resultado de la ejecución del servicio. Es una limitación que desde DAML-S y WSDL se tratará de resolver. REFERENCIAS [Ank02] The DAML Services Coalition: Ankolenkar Anupriya, Bustein Mark, Hobbs Jerry R, Lassila Ora, Martin David L., McDermott Drew, McIlraith Sheila A., Narayanan Srini, Paolucci Massimo, Payne Terry R. and Sycara Katia. DAMLS-S: Web Service Description for the semantic Web. Appeared in The First International Semantic Web Conference (ISWC), 2002. [DAMLS05] “Semantic Web Services Home Page” http://www.daml.org/services. Última vez accedido el día 31/01/2005 [Mar02b] Martin David. DAML-S: Bringing Semantics to Web Services, AAAI Workshop, July 2002 [NAICS04] NAICS: North American Industry Classification Systems. http://www.census.gov/epcd/www/naics.html Última vez accedido el día 06/09/2004 [SWRL04] “SWRL 0.6: Semantic Web Rules Languages” http://www.daml.org/2004/04/swrl/rules-all.html Última vez accedido el día 04/07/2004