UNIVERSIDAD TECNICA PARTICULAR DE LOJAdspace.utpl.edu.ec/bitstream/123456789/1706/3/Carrión Jiménez... · 1.2 SOA: Arquitectura orientada a Servicios ... analizar el esquema de

UNIVERSIDAD TECNICA PARTICULAR DE LOJA La Universidad Católica de Loja

ESCUELA DE CIENCIAS DE LACOMPUTACIÓN

“TECNOLOGÍAS DE WEB SEMÁNTICA ORIENTADA AL

DESARROLLO DE SERVICIOS WEB”

PROFESIONAL EN FORMACIÓN Gloria Matilde Carrión Jiménez

DIRECTOR Ing. Samanta P. Cueva

CODIRECTOR Ing. Jorge López

LOJA – ECUADOR

2010

Tesis previa la obtención del

Título de Ingeniero en Sistemas

Informáticos y Computación

Estado del arte Tecnologías de la Web Semántica orientadas al desarrollo de Servicios Web

I

CERTIFICACIÓN

Ing. Samanta Patricia Cueva Carrión

DIRECTORA DE TESIS

CERTIFICA:

Haber dirigido y supervisado el desarrollo del presente proyecto de tesis previo

a la obtención del título de INGENIERA EN SISTEMAS INFORMÁTICOS Y

COMPUTACIÓN, y una vez que este cumple con todas las exigencias y los

requisitos legales establecidos por la Universidad Técnica Particular de Loja,

autoriza su presentación para los fines legales pertinentes.

Loja, Marzo de 2010

……………………………………..……………….

Ing. Samanta Patricia Cueva Carrión


II

AUTORÍA

El presente proyecto de tesis con cada una de sus observaciones, análisis,

evaluaciones, conclusiones y recomendaciones emitidas, es de absoluta

responsabilidad de la autora Gloria Matilde Carrión Jiménez.

Además, es necesario indicar que la información de otros autores empleada

en el presente trabajo está debidamente especificada en fuentes de

referencia y apartados bibliográficos.

...................................................

Gloria Matilde Carrión Jiménez


III

CESIÓN DE DERECHOS

Yo, Gloria Matilde Carrión Jiménez, declaro conocer y aceptar la disposición del artículo 67 del

Estatuto Orgánico de la Universidad Técnica Particular de Loja que en su parte pertinente

textualmente dice: “Forman parte del Patrimonio de la Universidad, la propiedad intelectual de

investigaciones, trabajos científicos o técnicos y tesis de Grado que se realicen a través, o con el

apoyo financiero, académico o institucional (operativo) de la Universidad”.

……………………………………….

Gloria Matilde Carrión Jiménez


IV

DEDICATORIA

Todos las personas tenemos aspiraciones en la vida y una de ellas para mi es terminar la carrera

profesional, que ha sido plasmada con la culminación de la presente investigación que lo

dedico de todo corazón en primer lugar a Dios que siempre ilumina mi vida y me da la

sabiduría necesaria.

A mi papacito Amaro que desde el cielo me ilumina y guía mi camino y mi mamacita María

por su valioso apoyo incondicional que me ha brindado en todo momento.

En especial a mi Esposo Sergio, por su comprensión, apoyo moral y permanente; a mis hijos

Ronin y Cosme quienes han sido para mí una fuente de inspiración y estímulo para culminar

con éxito mi carrera universitaria, quienes han sufrido por no dedicarles mi tiempo como se lo

merecen.

Gloria Matilde


V

AGRADECIMIENTO

Dejo constancia de mis sinceros agradecimientos a la Universidad Técnica Particular de Loja, a

nuestros catedráticos, quienes supieron brindar sus conocimientos con verdadero sentido de

responsabilidad.

Agradezco al Ing. Nelson Piedra, Director de la Escuela de Ciencias de la Computación, quien

nos brindó todo su valioso apoyo y asistencia durante el trayecto de carrera universitaria.

Mi agradecimiento especial a mi directora de tesis Ing. Samanta P. Cueva y al Codirector Ing.

Jorge López por su dedicación a este trabajo, sus conocimientos, sugerencias y por saber

indicarme líneas y caminos a seguir, que han sido cruciales para el desarrollo satisfactorio de la

presente investigación.

Finalmente a mi familia, por haber estado en todo momento animándome a continuar este

camino y saber disculpar la falta de atención a ellos debido al tiempo ocupado en la

investigación y desarrollo de este trabajo.


VI

CONTENIDOS

CERTIFICACIONES I

CESIÓN DE DERECHOS II

AUTORÍA III

DEDICATORIA IV

AGRADECIMIENTO V

CONTENIDOS VI

ÍNDICE DE TABLAS X

ÍNDICE DE FIGURAS XI

CAPÍTULO I: ANÁLISIS DE LAS ARQUITECTURAS BASADAS EN

SERVICIOS Y ARQUITECTURAS DE SERVICIOS WEB

1.1 Introducción 1

1.2 SOA: Arquitectura orientada a Servicios. 2

1.2.1 Principios de la orientación a Servicios 3

1.2.2 Elementos de SOA 4

1.2.3 Beneficios de una Arquitectura basada en Servicios 6

1.2.4 Arquitectura REST 7

1.2.4.1 Restricciones de REST 8

1.2.4.2 Elementos Arquitectónicos de REST 11

1.2.5 OASIS 13

1.3 Arquitectura de Servicios Web 15

1.3.1 Tecnologías Asociadas 15

1.3.1.1 Arquitectura SOAP 15

1.3.1.2 Estándar WSDL 19

1.3.1.3 Estándar UDDI 20

1.3.2 Características de REST y SOAP 24

1.3.3 Diferencias entre REST y SOAP 25


VII

1.4 Esquemas de Intercambio de Mensajes 26

1.5 Orquestación Y Coreografía de Servicios 27

1.6 Agentes y Servicios Web 31

1.6.1 Agentes 31

1.6.2 Servicios Web 33

CAPÍTULO II: WEB SEMÁNTICA

2.1 Introducción 36

2.2 Arquitectura de la Web Semántica 37

2.3 Lenguaje de Marcado 40

2.3.1 XML 41

2.3.1.1 Definición 41

2.3.1.2 Usos 43

2.3.1.4 Espacios de nombres 44

2.3.1.5 XML Schema 46

2.3.1.6 Herramientas 50

2.4 Lenguaje de consulta 53

2.4.1 XQuery 54

2.4.2 RDF 57

2.4.2.1 Características de diseño de un RDF 58

2.4.2.2 Estructura de un RDF 59

2.4.2.3 Diferencias entre XML y RDF 61

2.4.3 RDF Schema 62

2.4.3.1 Características de RDFS 63

2.4.3.1 Limitaciones de RDFS 64

2.4.4 RDF: SPARQL 65

2.4.7 Herramientas existentes 66

2.5 Lógicas de Descripción 72


VIII

2.5.1 Fundamentos 72

2.6 Ontologías como herramienta para la descripción 73

2.6.1 Componentes de una Ontología 74

2.6.2 Clases de Ontologías 75

2.6.3 OWL: Web Ontology Language 76

2.6.4 Herramientas de Web Semántica 78

CAPÍTULO III: SERVICIOS WEB EN LA WEB SEMÁNTICA


3.2 Arquitecturas de Servicios Web Semánticos 85

3.2.1 Conceptos y evolución histórica 85

3.3 Estándares de Servicios Web Semánticos 90

3.3.1 WSMO 90

3.3.1.1 Concepto y Estructura 90

3.3.1.2 Principios de Diseño 92

3.3.1.3 Elementos de WSMO 67

3.3.2 OWL-S 94

3.3.2. 1 Service Profile 96

3.3.2.2 Service Model 97

3.3.2.3 Service Grounding 98

3.3.3 WSDL-S 99

3.3.4 Otros Estándares 101

3.3.4.1 SAWSDL 101

3.3.4.2 SWSF 102

3.3.5 Comparación de Lenguajes 105

3.4 Servicios Web Semánticos para Sistemas Multiagente 107


IX

CAPÍTULO IV: APLICACIONES DE WEB SEMÁNTICA PARA LOS

SERVICIOS WEB DE LA UTPL


4.2 Tendencias de desarrollo de Servicios Web Semánticos 109

4.3 Estrategia para crear Servicios Web Semántica para la UTPL 111

4.4 Aplicaciones para los Servicios Web de la UTPL 122

DISCUSIÓN 129

CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONES

5.1 Conclusiones Generales 134

5.2 Recomendaciones 137

REFERENCIAS BIBLIOGÁFICAS 138


X

ÍNDICE DE TABLAS

Tabla 1. Ventajas y desventajas de SOAP y REST………………………………………………..……….... 24

Tabla 2. Diferencias entre SOAP y REST……………………………………………………………………….…. 25

Tabla 3. Herramientas que trabajan con XML …………………………………………………….….………..51

Tabla 4. Partes de una expresión RDF……………………………………………………………..…………….... 60

Tabla 5. Diferencias entre XML y RDF…………………………………………………………………..…..……. 61

Tabla 6. Estándares de Ontologías para Web Semántica……………………………………….….…… 79

Tabla 7. Comparación de herramientas de Ontologías…………………………………………...….……83

Tabla 8. Comparación de Lenguajes de Servicios Web Semánticos………………………...……..106

Tabla 9. Estrategia de desarrollo de un SWS…………………………………………………………………..112

Tabla 10. Metodología para Crear una Ontología…………………………………………………………..113

Tabla 11: Metodología de desarrollo de ontología a utilizar…………………………………………..114

Tabla 12 Descripción de las capacidades e Interfaces de los Web Services de WSMO…..116

Tabla 13. Descripción de Modelo de Contexto de Ontología…………………………………………..117

Tabla 14. Elemento de la Ontología de Contenido…………………………………………………………..118

Tabla 15. Tipos de Mediadores de más utilizados en WSMO…………….…………………………. 120


XI

ÍNDICE DE FIGURAS

Fig. 1. Funcionamiento básico de un SOA………………………………………………………………….…..17

Fig. 2 Arquitectura de Web Semántica……………………………….………………………………………..38

Fig 3. Grafo de una expresión RDF.………………………………………………………………………………. 60

Fig.4. Ejemplo de RDF Shema……………………………………………………………………………………….. 63

Fig. 5. Arquitectura de Sésáme……………………………………………………………………………….……… 67

Fig. 6. Evolución de la Web Tecnologías participantes en los SWS…………………………………..86

Fig. 7. Dimensiones de Servicios Web Semánticos…………………………………………………………. 88

Fig. 8. Elementos de WSMO……………………………………………………………………………….…………. 92

Fig.9. Ontologías de Alto nivel OWL-S…………………………………………………………………………… 96

Fig. 10. Anotación Semántica de los elementos WSDL-S…………………………………………………99

Fig. 11. Modelo Ontología WSMO…………….……………………………………………………………….…117

Fig. 12. Arquitectura de la Propuesta…………………………………………………………………………….124

Fig.13 Descripción del Servicio en WSMO………………………………………………………………………127

ANÁLISIS DE LAS ARQUITECTURAS BASADAS EN

SERVICIOS Y ARQUITECTURAS DE SERVICIOS WEB


1

CAPÍTULO I

ANÁLISIS DE LAS ARQUITECTURAS BASADAS EN SERVICIOS Y

ARQUITECTURAS DE SERVICIOS WEB

1.1 INTRODUCCIÓN

En los últimos tiempos gracias a la tecnología de Internet que ha tenido un avance significativo;

el ser humano cada vez quiere realizar una mayor cantidad de tareas con menos esfuerzo, las

mismas que se trasladan desde su origen físico hasta el usuario final a través de internet; ésta

tecnología se conoce como Servicios Web.

Según el W3C define a los Servicios Web como: “Un conjunto de aplicaciones o tecnologías con

capacidad de interoperar en la Web a través del uso de estándares abiertos. Estas aplicaciones

intercambian datos entre sí con el objetivo de ofrecer servicios; los mismos que son ofrecidos

por proveedores remotos y los usuarios solicitan el servicio llamando a estos procedimientos a

través de la Web”. [1]

En la primera fase se aborda lo relacionado a las arquitecturas orientadas a servicios y

arquitectura de servicios Web dando a conocer algunas definiciones, descripción de los

estándares que intervienen, características, diferencias entre arquitecturas para luego enfocar

como intervienen el de intercambio de mensajes que se lleva a cabo en la orquestación y

composición de los servicios Web.

Actualmente la mayoría de los Servicios Web utilizan la arquitectura de Servicios SOAP (Simple

Object Access Protocol), pero existen otras arquitectura para servicios Web denominada REST

(Representational State Transfer) y OASIS (Organization for the Advancement of Structured

Information Standards). Las organizaciones OASIS y W3C son los comités responsables de la

arquitectura y reglamentación de los Servicios Web.


2

El objetivo primordial de este capítulo se centra en analizar los protocolos y las tecnologías que

constituyen los estándares de los Servicios Web, arquitecturas orientadas a servicios como SOA

y REST así como las tecnologías asociadas a éstos como son: SOAP, WSDL, UDDI. Para luego

analizar el esquema de intercambio de mensajes que se da en la composición y orquestación

de Servicios y como intervienen los agentes en el descubrimiento de Servicios Web.

1.2 SOA: ARQUITECTURA ORIENTADA A SERVICIOS

Básicamente la Arquitectura Orientada a Servicios (Service Oriented Architecture), hace

referencia a un concepto de arquitectura de software que especifica la utilización de servicios

para dar soporte a los requerimientos del usuario, dicha arquitectura nos permite la creación

de sistemas altamente escalables que satisfacen las necesidades de la organización y a su vez

brinda una forma estándar de publicar e invocar los servicios para facilitar la interacción entre

diferentes sistemas propios o de terceros independientemente de la plataforma utilizada.

SOA es una arquitectura que básicamente está orientada a un conjunto de servicios tanto de

negocio como tecnológicos que interactuando entre sí nos proporcionan la lógica necesaria

para construir aplicaciones de una manera rápida y cumpliendo con los principios de la

Orientación a Servicios. Además SOA proporciona una serie de guías y recomendaciones para

conseguir los objetivos que se impone una organización a la hora de desarrollar aplicaciones.

Por ello esta arquitectura surge de la necesidad de mejorar la integración e interoperabilidad

entre aplicaciones; cuyo fin o propósito es la convergencia entre el desarrollo e integración

que minimice las limitaciones entre aplicaciones. [2]

SOA es una plataforma basada en estándares que contiene funciones básicas como servicio de

mensajería, Servicios Web, enrutamiento inteligente y transformación de datos para conectar y

coordinar la interacción de aplicaciones de empresas. Dentro de la arquitectura de SOA la


3

funcionalidad se implementa en pequeños componentes autónomos reutilizables

denominados Servicios.

1.2.1 PRINCIPIOS DE LA ORIENTACIÓN A SERVICIOS

Los Principios orientados a servicios según Thomas Erl [3] son:

�� “Los Servicios deben ser reusables”: Los servicios deben estar orientados a la reutilización

de los mismos dentro de la aplicación o en un domino de aplicaciones incrementando de

esta forma la productividad de la empresa.

�� “Los Servicios deben proporcionar un contrato formal”: Los servicios deben proporcionar

un contrato en el que consten: el nombre del servicio, forma de acceso, funcionalidades,

datos de entrada de cada una de las funcionalidades y los datos de salida. Por ello para

acceder al servicio se lo realizará mediante el contrato logrando así la independencia y para

los Servicios Web se concreta mediante la definición de interfaces con WSDL1

�� “Los Servicios deben tener bajo acoplamiento”: Los servicios tienen que ser independientes

los unos de los otros. Este bajo acoplamiento hace que los servicios puedan ser

reutilizables en su totalidad.

�� “Los Servicios deben permitir la composición”: Todo servicio debe ser construido pensando

en ser utilizado para construir otros servicios genéricos de más alto nivel, el cual estará

compuesto de servicios de más bajo nivel. En el caso de los Servicios Web, esto se logrará

mediante el uso de los protocolos para orquestación (WS-BPEL)2 y coreografía (WS-CDL)3.

1 WSDL (Web Service Dscription Languaje).- Define una gramática para describir los Servicios de La red.

2 WS-BPEL(Business Process Execution Language) Es un estándar utilizado para componer múltiples servicios,

sincrónicos y asincrónicos, dentro de flujos de proceso colaborativos y transaccionales. 3 WS-CDL(Web Services Choreography Description Language) Es un lenguaje basado en XML que describe

colaboraciones punto a punto entre participantes.


4

�� “Los Servicios deben de ser autónomos”: Los Servicios debe tener su correspondiente

entorno de ejecución; lo que permitirá ser reutilizable desde el punto de vista de la

plataforma de ejecución.

�� “Los Servicios no deben tener estado”: Un servicio no debe guardar ningún tipo de

información porque se pueden producir problemas de inconsistencia de datos. La solución,

es que un servicio sólo contenga lógica, y que toda información esté almacenada en otro

sistema de información de cualquier tipo.

�� “Los Servicios deben poder ser descubiertos”: Esta característica es muy relevante para que

el servicio sea descubierto y pueda ser utilizado, evitando las creaciones repetidas de

servicios con las mismas funcionalidades. En los Servicios Web, el descubrimiento se logrará

publicando los interfaces de los servicios en registros UDDI4.

Cuando se desarrollan aplicaciones SOA es necesario tener en cuenta siempre estos

principios, ya que nos guiarán para tomar ciertas decisiones de diseño complejas. Todos los

principios guardan cierta relación y todos coinciden en la reusabilidad.

1.2.2 ELEMENTOS DE SOA

Existen diferentes elementos SOA los mismos que está agrupados en dos grupos: Unos que

abarca los aspectos funcionales de la arquitectura y otros que abarcan aspectos de calidad de

servicio: Los elementos funcionales comprenden: Transporte, Protocolo de comunicación,

Descripción del Servicio, Servicio, Proceso de Negocio, Registro de Servicios. En lo que se

refiere a la calidad de servicio comprende lo siguiente: Política, Seguridad, Transacciones,

Administración. A continuación se detalla cada uno de ellos:

4 UDDI(Universal Description, Discovery and Integration) Es un estándar para registrar y descubrir Web Services.


5

Aspectos Funcionales de la Arquitectura

� “Transporte”: Mecanismo utilizado para llevar las demandas de servicios desde un

consumidor de servicio hasta un proveedor de servicio y las respectivas respuestas entre

ellos.

� “Protocolo de comunicación de servicio”: Mecanismo mediante el cual un proveedor de

servicios y un consumidor de servicios notifica que está siendo solicitado y por ende

recepta la respuesta.

� “Descripción del servicio”: Es un esquema utilizado para describir qué servicio es, cómo se

le puede invocar, y qué datos son necesarios para realizar su invocación.

� “Servicio”: Es la implementación del servicio, que describe un servicio actual que está

disponible a utilizar.

� “Proceso de Negocio”: Es una colección de servicios invocados en secuencia, con un

conjunto particular de reglas para satisfacer los requisitos de negocio.

� “Registro de Servicios”: Consiste en un repositorio de descripciones de datos y servicios

que pueden utilizar proveedores de servicios para publicar los mismos, así como

consumidores de servicios para descubrir servicios disponibles.

Aspectos de la Calidad de Servicio

� “Política”: Es la agrupación de todas las reglas por medio de las cuales el proveedor de

servicio hace el mismo servicio disponible para los consumidores.

� “Seguridad”: Son las reglas a utilizar para la identificación, autorización, control de acceso,

integridad de los mensajes y la confidencialidad de los mismos.

� “Transacciones”: Son todos los atributos que se pueden utilizar a un grupo de servicios para

dar un resultado consistente y efectivo.

� “Administración”: Administración o Gestión viene a ser el conjunto de atributos que

pueden aplicarse para manejar los servicios ofrecidos.


6

1.2.3 BENEFICIOS DE UNA ARQUITECTURA ORIENTADA A SERVICIOS

(SOA)

Una vez analizada la arquitectura SOA se concluye que ofrece variedad de beneficios los

mismos que están relacionados a integrar aplicaciones a través del uso adecuado de

tecnologías cuyas bondades se resume en los siguientes aspectos:

� Reusabilidad: Es un factor importante para la integración de aplicaciones y sistemas nuevos

o los existentes para compartir información y datos entre aplicaciones incrementándose

así la calidad del servicio y la productividad de la empresa.

� Interoperabilidad: Hace referencia a la independencia de plataforma de ejecución a la hora

de establecer la comunicación entre el cliente y el servicio para poder entenderse

mutuamente.

� Escabilidad: Las aplicaciones con arquitectura SOA tienden a escalar fácilmente, debido a

que existe menos dependencia entre la aplicación que solicita y el servicio que ésta utiliza;

esto se debe a que los servicios SOA son débilmente acoplados.

� Flexibilidad: Los servicios SOA al ser débilmente acoplados son más flexibles que las

aplicaciones fuertemente acoplados por ende el desarrollo de las aplicaciones son más

productivas, flexibles, seguras y manejables para gestionar procesos a medida que

evolucionan las necesidades de la organización.

� Costo: Reduce costos y tiempo en el desarrollo de aplicaciones por la reutilización de

módulos de aplicaciones y por ende se reduce implícitamente el costo de mantenimiento.

Lo más importante de la arquitectura orientada a servicios es que cada elemento de un SOA

puede ser trasladado, intercambiado y modificado; debido a que los servicios existen de una


7

forma desacoplada, los mismos pueden ser combinados de diferentes formas según las

circunstancias. La posibilidad de crear procesos y componer aplicaciones a partir de estos

servicios junto con la reutilización y la interoperabilidad basada en estándares permite a las

aplicaciones ser flexibles al cambio a medida que evolucionan los requerimientos de la

empresa. [4]

1.2.4 ARQUITECTURA REST

REST (Representational State Transfer) es una arquitectura de aplicaciones Web propuesta por

Roy Fielding en su tesis doctoral (2000) “Architectural Styles and the Design of Network-based

Software Architectures”5, que consiste en un conjunto coordinado de restricciones que

controlan el funcionamiento y las características de los elementos de la arquitectura que

permiten las relaciones de unos elementos con otros.

Ésta arquitectura está diseñada para ofrecer un buen desempeño, escalabilidad y abstracción

de recursos, donde cada petición HTTP contiene suficiente información para dar respuesta a la

petición del usuario, sin necesidad que el cliente o el servidor tenga que recordar cada vez el

estado de su comunicación que se encuentra. Además ofrece escabilidad en la interacción con

sus componentes; de manera que el cliente puede actuar con cualquier servidor HTTP gracias

a la generalidad de interface que posee esta tecnología, que es independiente y compatible

con componentes intermedios.

Cuando se va a realizar una implementación de un Servicio Web REST se debe considerar

cuatro principios fundamentales, los mismos que se detallan a continuación: [5]

� “Utiliza los métodos HTTP de manera explícita”: Este principio se usa para ver la

consistencia en la definición del protocolo. Además establecer una asociación uno-a-uno 5 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm


8

entre las operaciones de crear, leer, actualizar y borrar los métodos HTTP. De acuerdo a

esta asociación: POST (crea un recurso en el servidor), GET (Obtiene un recurso), PUT

(actualiza o cambia el estado de un recurso), DELETE (elimina un recurso).

� “No mantiene estado”: Un servicio sin estado no sólo funciona mejor, sino que además

mueve la responsabilidad de mantener el estado al cliente de la aplicación; el servidor es

responsable de generar las respuestas y proveer una interfaz que le permita al cliente

mantener el estado de la aplicación por su propia cuenta.

� “Expone URIs con forma de directorios” : Las URIs son jerárquicas, a través de un único

directorio raíz se puede ir accediendo a través de los subdirectorios para exponer las áreas

principales del servicio. Una URI no es solamente una cadena de caracteres delimitada por

barras, sino más bien un árbol con subordinados y padres organizados como nodos.

� “Transfiere XML, JavaScript Object Notation (JSON6), o ambos”: tiene que ver con el formato

de los datos que la aplicación y el servicio intercambian en las peticiones/respuestas. Es decir que

vale la pena mantener las cosas simples, legibles por humanos y conectadas. Este servicio es

utilizado por distintos clientes escritos en diferentes lenguajes, corriendo en diversas

plataformas y dispositivos.

1.2.4.1 RESTRICCIONES DE REST

Las restricciones son condiciones que deben cumplirse para que una Arquitectura de Servicios

Web pueda ser considerada tipo REST. Esta arquitectura contiene seis clases de restricciones

según TOMAS, Fielding Roy: [6]

1. Cliente Servidor

6 http://es.wikipedia.org/wiki/JSON


9

2. Sin estado

3. Caché

4. Sistema de capas

5. Interfaz Uniforme

6. Código bajo demanda

1. “Cliente Servidor”: Consiste en separar la parte del cliente y del servidor al inicio para

distinguir la interfaz del usuario del almacenamiento de datos, lo que permite a los

componentes desarrollarse independientemente. De esta manera se mejora la portabilidad de

la interfaz de usuario y también se mejora la escalabilidad porque se simplifica los

componentes del servidor al no tener que implementar las funcionalidades que van

asociadas a la interfaz del usuario.

2. “Sin Estado (Stateless)”: Consiste en que cada petición del cliente debe contener toda la

formación necesaria para que el servidor la comprenda y no necesite mirar ningún dato

almacenado previamente sobre el contexto de la comunicación. El estado de la sesión se

guarda íntegramente en el cliente. Ésta restricción mejora la “visibilidad”, “eficiencia” y

“escabilidad” por las siguientes razones:

La visibilidad mejora en el sentido que el servidor no tiene que ocuparse de mirar en

otros sitios, ni realizar otras operaciones para entender la naturaleza de una petición

simple.

La eficiencia mejora ya que es más fácil recuperarse de errores parciales.

La escabilidad incrementa porque los componentes pueden liberar más rápidamente lo

recursos, ya que no tienen almacenados los estados entre las peticiones.

3. “Caché”: Esta restricción hace referencia a las respuestas de una petición que tiene que ser

etiquetadas como cacheable o no-cacheable. Si una respuesta es cacheable, al cliente caché se


10

le concede permiso para reutilizar la respuesta posteriormente si éste realiza una petición

equivalente. La ventaja de esta restricción es que mejora la eficiencia y escabilidad al

evitar algunas peticiones al servidor y se reducirá el tiempo medio de espera de un conjunto

de interacciones. La desventaja es que los datos obtenidos de caché difieran de los

obtenidos realizando la petición directamente al servidor.

4. “Sistema de Capas”: Permite tener una arquitectura compuesta por capas jerárquicas,

limitando el comportamiento de los componentes porque no pueden ver más allá de la capa

con la que está interactuando. Además se pueden simplificar los componentes trasladando

funcionalidades de uso poco frecuentes hacia sistemas intermedios compartidos.

La desventaja es que se añaden cabeceras y retrasos al procesamiento de datos; pero se puede

reducir este riesgo por los beneficios de usar un caché compartido en los sistemas

intermedios.

5. “Interfaz Uniforme”: Se usa una interfaz uniforme entre los componentes para simplificar la

arquitectura del sistema global y la visibilidad de interacciones se mejora considerablemente.

Las implementaciones se separan de los servicios que ofrecen para lograr la independencia.

Como desventaja se puede considerar la disminución de la eficiencia porque la información

transferida está en una forma estandarizada y no según las necesidades que tenga la aplicación.

El interfaz de REST está creado para ser eficiente con transferencias de datos hipermedios.

Para obtener una interfaz uniforme, REST7 define cuatro restricciones de interfaz:

� Identificación de recursos.

� Manipulación de recursos a través de sus representaciones.

� Mensajes auto-descriptivos.

� Hipermedios como el motor del estado de la aplicación.

7 http://forge.morfeo-

project.org/wiki/index.php/D.3.2_Documento_de_definici%C3%B3n_de_modelos_avanzados_de_comunicaci%C3%B3n_y_composici%C3%B3n_de_recursos#Interfaz_Uniforme


11

6. “Código bajo demanda”: Esta restricción es opcional, consiste en permitir a los clientes tener

la funcionalidad de descargar y ejecutar código en forma de applets y scripts. Esto simplifica el

lado del cliente porque reduce el número de funcionalidades que tiene que tener

implementadas al crearse. Las funcionalidades se pueden descargar posteriormente

aumentando así la extensibilidad del sistema. La principal desventaja de esta restricción es que

reduce la visibilidad y puede influir en la seguridad del sistema.

1.2.4.2 ELEMENTOS ARQUITECTONICOS DE REST

Siguiendo la línea de la Arquitectura REST hasta ahora hemos descrito las restricciones que

utiliza para controlar el funcionamiento y las relaciones entre los elementos que son tres:

componentes, conectores y datos. Ahora se analizará como Roy T. Fielding concibió cada uno

de estos elementos para acoplarse dentro de REST.

� Componente: Es una unidad abstracta de instrucciones software y estados internos que

proporciona una transformación de los datos a través de su interfaz, éstos se comunican

trasfiriendo representaciones de un recurso en un formato que se ajusta a un conjunto de

tipos de datos estándares. Los tipos de datos son seleccionados dinámicamente en base a

las capacidades o requerimientos del receptor y en la naturaleza del recurso. Los

componentes principales de REST son Agente Usuario, Servidor, Gateway (puerta de

acceso) y Proxy.

�� Conector: Mecanismo abstracto que se encarga de la comunicación, coordinación y

cooperación entre componentes. Los conectores principales de REST son Cliente, Servidor y

Caché. Pero existen otros que están en segundo plano y éstos son: Resolver y Túnel.

�� Dato: “Es un elemento de información que se transfiere desde o hacia un componente a

través de un conector”. Por ejemplo cuando seleccionamos un link, la información debe


12

trasladarse desde la localización donde se encuentra hasta donde será utilizado. En cambio

en los procesos distribuidos se mueve el “proceso agente” hasta los datos, en REST se

mueven los datos hasta el proceso.

Usos de la Arquitectura REST

Una vez analizada brevemente la arquitectura REST es necesario enfocar los usos frecuentes

que se le da a esta arquitectura considerando la gama de características que ofrece y el fin para

el que deseamos implementar. En primer lugar tenemos que Amazon es pionera en el uso de

REST, se beneficia de una base de datos con todos los productos que vende, a éstos se acceden

como recursos y no como métodos de búsqueda.

Esta arquitectura se considera apropiada utilizarla en los siguientes casos:

� Cuando necesitemos una representación distinta a XML.

� Cuando los servicios Web no requieran guardar el estado de su interacción.

� Cuando el servicio productor y el servicio consumidor se entienden mutuamente, que

conocen el contexto y el contenido que va a ser comunicado.

� Cuando se pasa tanto contenido como contexto, debido a que no hay una manera

formal de describir las interfaces de servicios Web se ponen de acuerdo las dos partes

en lo que se refiere a esquemas para intercambiar datos y la forma de procesarlos para

que sean comprensibles.

� REST es particularmente útil para dispositivos con escasos recursos como PDAs o

teléfonos móviles, para los que las extensas cabeceras y capas adicionales de elementos

SOAP son excesivas.

� Los servicios Web REST permite un desarrollo ágil, disminuyen la utilización de recursos

(CPU, memoria, ancho de banda, tiempo de desarrollo) al interior de la organización.


13

1.2.5 OASIS

OASIS8(1993) (Organization for the Advancement of Structured Information Standards) es un

consorcio internacional sin ánimo de lucro, que gestiona el desarrollo, la convergencia y la

adopción de los estándares sobre comercio electrónico y sus propios miembros establecen la

agenda técnica de OASIS, utilizando un proceso abierto y ligero, diseñado explícitamente para

fomentar el consenso de la industria y unificar esfuerzos. El consorcio crea estándares abiertos

en los ámbitos de Servicios Web, Seguridad, Comercio-Electrónico y estandarización en el

sector público, así como para mercados de aplicaciones específicas.

Dentro del área de Servicios Web OASIS ha impulsado la interpretación del marco XML y su

traducción a normas útiles para el negocio electrónico con el nombre de ebXML9 (1999), El

proyecto original contempla y proporciona la especificación de cinco capas de datos

sustantivos, que comprendían normas XML para:

� Procesos comerciales

� Componentes de datos fundamentales

� Acuerdos de protocolos de colaboración

� Mensajería

� Registros y almacenes

Objetivo de OASIS

OASIS propone una solución innovadora, que facilita la interoperabilidad, conectividad

transparente al usuario y la distribución de contenidos entre diferentes servicios y ontologías

en todos los ámbitos de relevancia para los usuarios que se apunten a utilizar esta tecnología.

OASIS define la Orientación a Servicios como: 8 http://www.w3c.es/Prensa/2007/nota070130_Webcgm.html

9 ebXML (comercio electrónico utilizando eXtensible Markup Language).


14

“Un paradigma para la organización y uso de funcionalidades que se encuentran distribuidas

en distintos servicios, proporcionando un modo uniforme de ofrecer, descubrir e interactuar

con ellos” [7]

El objetivo de OASIS básicamente está orientado a crear una arquitectura de referencia y

abierta, que está basada en ontologías y servicios semánticos, que permiten una interconexión

simple y rentable de servicios nuevos o ya existentes, en todas las áreas. Tanto la arquitectura

abierta de referencia como las herramientas relacionadas están disponibles en Open Source.

Estándares aprobados

OASIS ha aprobado diferentes estándares entre los cuales tenemos: [8]

�� UDDI 2.0 (Universal Description, Discovery and Integration), Lenguaje para la

descripción de los Servicios Web y es uno de los estándares primordiales en la

arquitectura de Servicios Web junto a XML, SOAP (Simple Object Access Protocol) y

WSDL (Web Services Description Language)

�� BPEL 2.0, Lenguaje diseñado para la composición de Servicios Web

�� Open Document (OASIS Open Document Format for Office Applications): Contiene un

formato abierto de documentos para guardar documentos relacionados con ofimática

como: hojas de cálculo, memorándums, gráficos y presentaciones.

�� DocBook (DocBook), lenguaje de marcado para documentación técnica. Fue diseñado

para elaborar documentación técnica que está relacionada con hardware y software

pero puede ser usado para cualquier documentación de diferente tipo.


15

1.3 ARQUITECTURA DE SERVICIOS WEB

La arquitectura de Servicios Web está enfocada al uso exclusivo de los Web Services, los

cuales comunican aplicaciones permitiendo compartir información, invocan funciones

independientemente de cómo se hayan creado éstas. La comunicación se caracteriza por el

intercambio de mensajes XML y por ser independiente del protocolo de comunicación.

Estos Servicios Web son aplicaciones que utilizan estándares para el transporte,

codificación y protocolo de intercambio de información, que permite la intercomunicación

entre sistemas o aplicaciones de cualquier plataforma. En consecuencia un Servicio Web

hace referencia a un conjunto de tecnologías y estándares de software para el intercambio

de datos entre aplicaciones. Estos estándares son: SOAP, WDSL y UDDI que en las secciones

posteriores se analizarán con detenimiento cada uno de ellos.

1.3.1 TECNOLOGÍAS ASOCIADAS

1.3.1.1 SOAP

SOAP (Simple Object Access Protocol), en Junio del 2003 alcanzó la fase de recomendación

oficial de W3C. SOAP es un protocolo que proporciona un mecanismo para empaquetar

mensajes y permite el intercambio de información en un entorno descentralizado y

distribuido. Además simplifica el acceso a los objetos, permitiendo a las aplicaciones invocar

métodos objetos o funciones, que residen en sistemas remotos. Se basa en XML y describe

un formato de mensajería para la comunicación entre equipos. [9]

SOAP utiliza tecnologías relacionadas con XML para definir un marco de trabajo extensible

para los mensajes y provee una estructura de mensajes capaz de ser intercambiada sobre


16

una gran cantidad de protocolos de soporte. El marco de trabajo está diseñado para ser

independiente de cualquier modelo de programación o cualquier semántica específica de

alguna implementación. SOAP consta de tres partes fundamentales:

� “El SOAP envelope”: Se encarga de definir el marco de trabajo que determina qué se

puede introducir en un mensaje, quién lo debe realizar y si es opcional u obligatoria

esta operación.

� “Las reglas de codificación SOAP”: Define la forma de serialización que utilizará para

encapsular en los mensajes los diferentes tipos de datos.

� “La representación SOAP RPC”: Define un modo de funcionamiento a la hora de realizar

llamadas a procedimientos remotos y la obtención de sus resultados.

El estándar SOAP generalmente es utilizado en un amplio rango de servidores de aplicaciones

que trabajan mediante el modelo de comunicación RPC (Remote Procedure Call). Pero los

Servicios Web basados en SOAP son más utilizados por parte de desarrolladores de software y

analistas al contrario de los Servicios Web basados en RPC. La especificación SOAP menciona

que las aplicaciones deben ser independientes del lenguaje de desarrollo, por lo que las

aplicaciones cliente y servidor pueden estar escritas en cualquier lenguaje disponible.

Procesamiento de SOAP

En este apartado se aborda como SOAP procesa un mensaje y quien interviene en esta tarea.

Primeramente se tiene que SOAP provee un modelo de procesamiento distribuido en el que un

mensaje es originado por un emisor inicial SOAP, y enviado a un receptor final SOAP a través de

más intermediarios o directamente. Este modelo puede soportar muchos Patrones de

Intercambio de Mensajes, incluyendo mensajes unidireccionales, interacciones del tipo

petición/respuesta y conversaciones punto a punto.


17

Este modelo especifica cómo un receptor SOAP procesa el mensaje que le ha llegado; pero no

está contemplado el mantener ningún estado en la comunicación, o el llevar un control de la

correlación de los mensajes. Sería responsabilidad de las características adicionales el definir de

alguna forma este tipo de procesamiento.

Las tecnologías básicas de los Servicios Web; utilizan SOAP como lenguaje de intercambio de

mensajes, WSDL como lenguaje para la descripción de los servicios y UDDI para la publicación

de los servicios Web. A continuación en la figura 1 se muestra la estructura básica de

funcionamiento de SOA.

Fig. 1. Funcionamiento básico de un SOA [tomado de [10]]

Básicamente se identifica tres roles que son: “Consumidor de Servicio, Proveedor de Servicio y

registro de Servicios”. La interacción de cada uno de ellos es como se detalla a continuación:

1. El proveedor del servicio almacena en el registro UDDI el documento de descripción de

este y es el encargado de implementar el servicio Web para ofrecerlo a los consumidores o

clientes.

2. El consumidor del servicio busca en el registro un servicio Web que pueda adaptarse a sus

necesidades. Es decir solicita el servicio y por ende lo consume.

3. Una vez seleccionado el servicio, el cliente lo invoca mediante el envío de un mensaje

SOAP, en el cual se indica la acción a realizar y los datos de entrada que contiene.

4. El servicio Web recibe la petición y ejecuta la funcionalidad, luego para finalizar envía un

mensaje SOAP el proveedor al solicitante con los resultados obtenidos.


18

Cuando utilizar SOAP

Una vez analizada la tecnología de SOAP dentro de lo estándares de la Arquitectura Orientada

a Servicios Web es necesario dar un aporte a cerca de la factibilidad de uso de esta tecnología

para aprovechar todas las bondades que esta nos ofrece; por eso se sugiere utilizar en en los

siguientes casos:

� Cuando se establece un contrato formal para la descripción de la interfaz que el servicio

ofrece, porque al trabajar con lenguaje de Descripción de Servicios Web (WSDL), permite

describir con detalles el servicio Web.

� Cuando la arquitectura necesita manejar procesado asíncrono e invocación. En estos casos,

la infraestructura proporcionada por estándares como WSRM10 y APIs como JAX-WS11 junto

con la asincronía por el lado del cliente nos permitirán el soporte de estas características.

� Cuando el servidor necesite mantener el estado de la conversación.

� Cuando múltiples instancias del proceso comparten la misma operación.

� Cuando el flujo de eventos necesiten ser orquestados y utilizar muchas operaciones con

pocos recursos y el diseño de las aplicaciones requieran ser distribuidas.

� Cuando la arquitectura debe abordar requerimientos complejos como transacciones,

seguridad direccionamiento.

� Cuando la aplicación no necesite estar fuertemente acoplado a ningún protocolo de

transporte.

� Cuando se requiera utilizar cualquier lenguaje de programación.

� Cuando se requiera interoperabilidad entre múltiples entornos

10

WSRM(Windows System Resource Manager) http://technet.microsoft.com/en-us/windowsserver/bb405952.aspx 11

https://jax-ws.dev.java.net/


19

1.3.1.2 WSDL

WSDL (Web Service Definition Languaje), es publicado por el W3C en Marzo 2001, éste

estándar describe la interfaz pública de los Servicios Web. Está basado en XML y describe la

forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes

necesarios para interactuar con los Servicios. WSDL establece un contrato entre el proveedor

de servicio y el consumidor del Servicio, mediante el cual el proveedor de servicios indica los

siguientes puntos dentro del contrato:

� “Las funciones que pueden invocar”.

� “Los tipos de datos que utilizan esas funcione”.

� “El protocolo de transporte que utilizará para el enviar y recibir los mensajes”.

� “Como acceder a los servicios, es decir, mediante que URL se utilizan los servicios”. [11].

Básicamente en un documento WSDL se definen los detalles del servicio como: operaciones,

tipos de datos y protocolo utilizado; y al momento de la definición de documento WSDL, se

genera automáticamente el componente cliente para su invocación remota.

WSDL define una gramática XML orientada a describir en forma estructurada, la funcionalidad

de un Servicio Web y la forma en que esa funcionalidad se hace disponible. Además describe

los servicios de red como colecciones de puntos finales de comunicación capaces de

intercambiar mensajes describiendo las comunicaciones en forma estructurada.

Estructura del documento WSDL

WSDL permite describir en forma abstracta operaciones y mensajes, prescindiendo de las

especificaciones de protocolo y tipos de datos, además vincula las descripciones abstractas a


20

una implementación concreta de protocolos y tipos de datos, permitiendo la reutilización de las

definiciones abstractas.

Una descripción WSDL diferencia dos partes fundamentales al crear un documento, éstas son:

“Parte concreta y parte abstracta” la primera define el "como" y "donde"; y la segunda define

qué hace el servicio a través de los mensajes que envía y recibe. Por esta razón, un documento

WSDL según el W3C utiliza seis elementos en la definición de servicios de red: Types,

messages, portType, Binding, Port, Service ; los mismos que se describe a continuación: [12].

� “Tipos” (Types): Especifican las definiciones de tipos de datos utilizados para describir

los mensajes intercambiados.

� “Mensaje”(messages): Representa una definición abstracta de los datos que están

siendo transmitidos. El mensaje de divide en una serie de partes lógicas, cada una de las

cuales se asocia con alguna definición de algún sistema de tipos.

� “Tipo de Puerto”(portType): Se utiliza para definir un conjunto de operaciones

abstractas. Cada operación hace referencia a un mensaje de entrada y uno de salida.

� “Vinculación”(Binding): Especifica un protocolo concreto y el formato de los datos de

las operaciones para un tipo de puerto determinado.

� “Puerto” (Port): Especifica un punto final único que se define como la combinación de

un enlace y una dirección de red, para así definir un único nodo de comunicación.

� “Servicio” (Service): Es el conjunto de puntos finales relacionados que se utiliza para

unir un conjunto de puertos relacionados.

1.3.1.3 UDDI

Dentro de la Arquitectura de Servicios Web se tiene UDDI12 (Universal Description, Discovery

and Integration), que es uno de los protocolos fundamentales que proporciona una

12

http://triana.escet.urjc.es/apliweb/SOAP-WSDL-UDDI.pdf


21

plataforma estándar e interoperable que permite a las organizaciones y a la aplicaciones

encontrar y usar de forma rápida, fácil y dinámica los Servicios Web a través de Internet.

La versión actual de UDDI es la 3.0 (Agosto, 2003), siendo gestionada por Organization for the

Advancement of Structured Information Standards (OASIS). “La implementación de estas

especificaciones se denomina “Registro UDDI”, el cual proporciona un conjunto de Servicios

Web de registro y consulta vía SOAP. El propósito de un registro UDDI es la representación de

datos y metadatos acerca de Servicios Web. Tanto para ser usado en una red pública como

dentro de la infraestructura interna de una organización, un registro UDDI ofrece un

mecanismo basado en estándares para clasificar, catalogar y manejar servicios web de forma

de que puedan ser descubiertos y consumidos por otras aplicaciones.

UDDI es el estándar básico para la publicación y el descubrimiento de información sobre los

Servicios Web, cuyo propósito es ser accedido por los mensajes SOAP y dar paso a los

documentos WSDL, en donde se describe el protocolo y el formato de mensaje para interactuar

con Servicios Web.

El método utilizado por UDDI para el descubrimiento de Servicios Web consiste en tener un

registro de aquellos servicios que se encuentran distribuidos a través de la Web y en éste

registro distribuido, los negocios y los servicios se describen utilizando un formato XML, para

que los datos estructurados en esos documentos XML sean de fácil búsqueda, análisis y

manipulación.

El modo de operar de este estándar se describe a continuación: los proveedores de los

Servicios Web los publican en el registro UDDI una vez publicados se mantienen allí

apuntadores a la descripción del Servicio Web. UDDI permite a los clientes buscar dicho

registro, encontrar el servicio deseado y extraer sus detalles.


22

El estándar UDDI contiene dos partes fundamentales dentro de una organización las mismas

que son: Reutilización de código y configuración dinámica de aplicaciones. El directorio o registro

es definido como una jerarquía de entidades “business”, “service” y “binding” cuyas descripciones son

expresadas en XML. Entre las características de ésta tecnología se describe las siguientes: [13]

� “Soporte para firma digital”

� “Separación de los datos de una entidad UDDI de los metadatos asociados”.

� “Usos de esquemas de XML”.

� “Soporte de Lenguaje”.

UDDI es un elemento central del grupo de estándares involucrados en la tecnología Servicios

Web. Es el mediador a través del cual se conocen los posibles clientes con los proveedores de

los servicios. Define un método estándar para publicar y descubrir servicios en el contexto SOA

(Alvez, et al., 2006).

Los UDDI se clasifican en: Páginas blancas (información de contactos, listados de organizaciones

y servicios), páginas amarillas (información de industria, clasificación de compañías y servicios

Web de acuerdo a una taxonomía) y páginas verdes (información técnica y especificaciones).

Estructura de Datos con UDDI

Dentro de la arquitectura de Servicios Web, la estructura de datos de UDDI definida por

OASIS contiene cuatro tipos de información: BusinessEntity, BusinessService,

BindingTemplate, tModel . [14]

“BusinessEntity”: Describe al proveedor del servicio Web; es decir, contiene datos como

nombre de la empresa, detalle de contacto, descripción en lenguaje natural de las actividades

de la empresa y otra información de contacto.


23

“BusinessService”: Describe un grupo de Servicios Web relacionados ofrecidos por una

empresa en diferentes direcciones versiones y tecnologías. Una businessEntity se compone de

uno o varios Servicios BusinessService, y un elemento BusinessService puede ser usado por

varios elementos BusinessService y también puede contener elementos de clasificación.

“BindingTemplate”: Describe un único Servicio Web, describe la información técnica para

utilizar el servicio, la misma que puede ser: dirección del servicio, referencias de documentos

describiendo la interfaz u otras propiedades. Cada elemento BusinessService puede tener uno

o varios elementos BindingTemplate.

“tModel”: Representa especificaciones técnicas, metadatos sobre las especificaciones del

documento, el nombre puntero URL, es presentado en forma de un documento WSDL. También

pueden aparecer las categorías en las que se puede elaborar el servicio.


24

1.3.2 CARACTERISTICAS DE REST Y SOAP

Una vez revisadas las arquitecturas de REST y SOAP se puede concluir en algunas ventajas y

desventajas de cada una de ellas, las mismas que se describen a continuación [tabla 1].

VENTAJAS DESVENTAJAS

SOAP -Aprovecha los estándares existentes en la industria (XML, HTTP, SMPT) -Permite interoperabilidad entre múltiples entornos -Los datos como las funciones se describen en XML, lo que hace del protocolo fácil de utilizar y muy sólido. -No se encuentra fuertemente asociado con ningún protocolo de transporte. -Facilidad para utilizar cualquier lenguaje.

- Un cambio en el contrato de un servicio, afecta a todas las implementaciones de los clientes, técnicamente tendrán que regenerar los proxys para cada servicio. - No dispone de un sistema de dirección global. -No hace uso de mecanismos de caché. - No dispone de puertos dedicados para diferentes tipos de modificaciones. -Las instancias del proceso son creadas implícitamente. - Problemas de interoperabilidad.

REST -Soporte universal y simple desde cualquier lenguaje o plataforma. - Funciona con XML pero también con otros formatos (XHTM, JSON). -Mejores tiempos de respuesta y disminución de carga en servidor, gracias al mecanismo caché y los mensajes auto-descriptivos - Facilita desarrollo de clientes al tener menor dependencia del servidor. - Mayor escalabilidad al no requerir mantenimiento de estado - Mayor estabilidad frente a futuros cambios.

- No existen actualmente variedad de herramientas de desarrollo. - Maneja gran número de objetos. -El espacio de nombres (URIs) puede ser con el tiempo y cantidad de información un poco engorroso. -La dirección sintáctica/semántica muy informal (orientadas al usuario).

Tabla1. Ventajas y Desventajas de SOAP y REST13

13 http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1227190,00.html


25

1.3.3 DIFERENCIAS ENTRE REST Y SOAP

Al analizar SOAP y REST se encontraron algunas diferencias enfocadas desde varios puntos de

vista, las cuales se describen en la siguiente tabla [Tabla 2]

CARACTERISTICAS SOAP REST

Soporte de documentos.

Solo soporta XML como documentos de intercambio, basados en el protocolo SOAP

Brinda recursos y variedad de representaciones como: XML, HTML, text, pdf, binario

Definición de Operaciones

Las operaciones se definen en los mensajes.

Las operaciones se definen en WSDL

Definición de protocolo.

Elige un protocolo de transporte apropiado y define las políticas de calidad de Servicio y de Seguridad

Depende directamente del protocolo HTPP, este expone siempre la misma interface a todos los consumidores, mediante operaciones bien definidas: POST, GET, PUT y DELETE

Utilización de Recursos.

Realiza varias operaciones con escasos recursos.

Realiza pocas operaciones con muchos recursos.

Tipos de Componentes.

Componentes fuertemente acoplados.

Componentes débilmente acoplados

Intercambio de Mensajes.

Síncrono y Asíncrono. Síncrono

Mantenimiento de Estado.

Los mensajes contienen sólo datos y el servidor mantiene el estado de la conversación.

Los recursos contienen datos y enlaces y el servidor no mantiene estado de la conversación, el cliente mantiene el estado y no se permite sesiones.

Definición de Operaciones.

Describe las operaciones del servicio en el documento WSDL

Las operaciones se definen en los mensajes

Tabla 2. Diferencias entre SOAP y REST


26

1.4 ESQUEMA DE INTERCAMBIO DE MENSAJES

En este apartado se aborda lo relacionado al intercambio de mensajes que gracias a SOAP y el

protocolo HTTP que son la base tecnológica de la mensajería y del transporte respectivamente,

se lleva a cabo sin inconveniente para prestar un buen servicio al usuario. Es por ello que los

Servicios Web14 se definen a menudo como “síncrono o sin estado”.

� Síncrono: Cuando un consumidor realiza una invocación se envía un mensaje de petición y

a continuación espera una respuesta, lo que se traduce en que el proveedor debe enviar un

mensaje de respuesta.

� Sin estado: Es porque no existe relación alguna entre dos invocaciones consecutivas del

mismo consumidor al mismo proveedor; es decir, cada vez que se realiza una invocación en

la parte servidor, se instancia un componente servidor quien recibirá la petición, la procesa

y devuelve un mensaje de respuesta y allí acaba la invocación; la próxima invocación que se

realice no tendrá relación alguna con la anterior porque se ejecuta en una instancia nueva

del servicio proveedor.

El “sincronismo” y la “ausencia de estados” añaden un conjunto de limitaciones que no

permiten aplicar la tecnología en situaciones que desearíamos por ejemplo transacciones de

larga duración en el que el tiempo de ejecución excede lo razonable para una aplicación online.

Para implementar transacciones de larga duración dentro de la arquitectura de Servicios Web

se requiere utilizar un esquema “asíncrono” de intercambio de mensajes, donde el cliente no

espere por la respuesta de un proveedor, sino que sea éste que al final del proceso informe al

14

http://grids.ucs.indiana.edu/ptliupages/publications/Geoinformatics05_asayar.pdf


27

cliente dicho evento. El esquema de asíncrono debe tomar en cuenta algunas tareas entre las

cuales tenemos: [15]

� Los mensajes deben ser unívocamente identificados, ya que las peticiones y respuestas van

a ser entregadas sin orden a los mismos proveedores y clientes. Por este motivo se necesita

una manera de identificar todos los mensajes que formen parte de un mismo diálogo, a los

que se conoce como conjunto de invocaciones.

� Los mensajes de respuesta pueden ser entregados a los clientes en cualquier momento.

Actualmente existen dos modelos que permiten la entrega asíncrona de mensajes que son

polling y callback

Polling15(Sondeo): Los clientes hacen la invocación del servicio y como respuesta a la

invocación recibe un ticket o identificador, lo que le permite al cliente tener una respuesta en

lo posterior. Luego el cliente tiene que estar continuamente interrogando al servicio Web a la

espera que se produzca una respuesta.

Callback16(retrollamada): El cliente realiza una invocación que finaliza con una respuesta que

indica la aceptación de dicha invocación, así como la recepción exitosa del mensaje

correspondiente. Existen cuatro categorías de invocación asíncrona en relación al intercambio

de mensajes que generen.

� Solo Envío: El cliente envía un mensaje y no espera respuesta (arranque de un proceso)

� Envío y recepción: El cliente envía un mensaje y espera respuesta.

� Recepción y envío: Se recibe un mensaje y se envía una respuesta (punto de vista de un

proveedor de servicios).

� Solo recepción: Se recibe un mensaje y no se envía respuesta(mensajes desatendidos)

15

http://es.wikipedia.org/wiki/Polling 16

http://es.wikipedia.org/wiki/Callback_(programaci%C3%B3n)


28

La construcción de servicios Web asíncronos depende en gran medida de la plataforma y de

los protocolos sobre los que se han desarrollado. Las aplicaciones cliente deberán estar

preparadas para invocar un servicio Web de forma asíncrona.

1.5 ORQUESTACIÓN Y COREOGRAFÍA DE SERVICIOS

ORQUESTACIÓN DE SERVICIOS

En la Arquitectura de Servicios Web una área importante que se debe considerar es la

Orquestación de Servicios; que se da al momento que un solo servicio no satisface las

necesidades del usuario por eso surge la composición de servicios para ofrecer mejores

resultados.

En un análisis de “Orquestación Vs. Coreografía de Servicios” que hace Márquez Santiago

define a la orquestación como: “Un proceso Web es de orquestación de servicios cuando es

controlado totalmente por una única entidad. Ésta define completamente las interacciones

con los servicios componentes, y la lógica requerida para conducir correctamente esas

interacciones. La orquestación, siempre representamos el control del proceso del servicio

desde el punto de vista de una de las partes participantes que intervienen en el mismo”. [16]

El proceso de orquestación de servicios describe el comportamiento que el servicio principal

implementa para realizar un flujo de proceso, y la forma en que un proceso ejecutable

interacciona con servicios internos y externos, el intercambio de mensajes y la lógica.

BPEL4WS17 es un lenguaje de orquestación de servicios.

Con la orquestación de servicios nos permite diseñar procesos compuestos de otros

servicios, dado que una de las partes controla el flujo del proceso. El tipo de proceso puede

entenderse como “privado y ejecutable”:

17

http://xml.coverpages.org/BPML-BPEL4WS-WP.pdf


29

� “Privado”: Porque la definición de la lógica del proceso es hecha enteramente por un

participante en la interacción.

� “Ejecutable”: Porque tiene un comportamiento de conversión de entradas en salidas y

tiene efectos en el mundo real.

Entre algunas de las características o propiedades de la orquestación de servicios se pueden

citar las siguientes:

� La orquestación compone servicios para generar un nuevo proceso y se usa de dos

formas distintas: para preparar la información que se intercambia en la ejecución de una

coreografía o como la invocación siguiendo unas determinadas reglas a un servicio Web.

� La orquestación es un sistema jerárquico en el proceso Web organiza como invocar a

otros servicios mediante un flujo de control que determina qué invocar y cuando

hacerlo.

Una vez revisado la orquestación de servicios se puede decir que la ejecución de un

proceso definido en el lenguaje WS-BPEL18 puede ser ejecutado por un motor BPEL19, que

son los lenguajes propios de orquestación de Servicios.

COREAGRAFÍA DE SERVICIOS

La coreografía de Servicios puede concebirse como un proceso público y no ejecutable: es

público porque define el comportamiento común y globalmente visible entre los diferentes

participantes en una interacción; por otro lado es no ejecutable porque no está pensado

para ser llevado a cabo, sino para actuar como un protocolo de negocio que dicta reglas de

interacción que deben ser cumplidas por las entidades participantes.

Un proceso Web se considera de coreografía de servicios cuando define las colaboraciones

entre más de un servicio para lograr un objetivo común; por lo tanto no se centra en un

servicio en particular sino en un objetivo que tiene que cumplir el flujo de un proceso. Un

18

http://www.espaciosoa.net/2007/02/06/ws-bpel-version-20-casi-lista/ 19

BELP.- Lenguaje de Ejecución de Procesos de Negocio http://www.gestiopolis.com/delta/term/TER430.html


30

proceso de coreografía no es controlado por un solo participante de la interacción; la

coreografía es mucho más colaborativa, porque permite trazar las secuencias de mensajes

que se suceden entre todas las partes participantes del proceso en lugar de centrarse en los

mensajes que intercambian los Servicios Web. [17]

Como retroalimentación se puede decir que la coreografía de servicios describe la

coordinación de servicios desde un punto de vista colaborativo, entre múltiples partes,

donde el control está distribuido. Para describir este tipo de coordinación, se han

desarrollado lenguajes como WSCI20 el cual permite describir el orden de invocación y cómo

las operaciones pueden ser coreografiadas en el contexto de intercambio de mensajes en el

cual los Servicios Web participan; y el estándar del W3C WS-CDL21, que es un lenguaje para

describir escenarios de interacción multi-partes (o coreografías). Algunas características

importantes de la coreografía se describen las siguientes:

� La coreografía se compone de servicios para permitir la colaboración de los participantes

mediante el intercambio de mensajes tanto síncronos como asíncronos y que requiere

una descripción formal de los protocolos de intercambio de mensajes, lo cual debe estar

visible para cada participante que interviene dentro de la coreografía.

� Es un sistema entre pares, muchos participantes pueden colaborar, por tanto es posible

la existencia de varios flujos de control diferentes.

� Se describen interacciones con estado y duraderas.

20

WSCI (Web Service Choreography Interface) lenguaje de descripción de interfaces basado en XML para describir el flujo de mensajes intercambiados por un Web Service participando en interacciones coreografiadas con otros

servicios. http://www.w3.org/TR/wsci/ 21

WS-CDL(Web Services Choreography Description Languag) Lenguaje para la descripción de Coreografías de Servicios Web .- lenguaje basado en XML que describe la colaboración entre pares peer-to-peer http://www.ebpml.org/ws_-_cdl.htm


31

1.6 AGENTES Y SERVICIOS WEB

1.6.1 AGENTES

No existe una definición consensuada de agente, ni un acuerdo en cuanto a las propiedades

que éste debe tener. El diseño de un agente inteligente es una rama de inteligencia artificial y

en este dominio existen varios conceptos entre los cuales podemos citar el propuesto por

Wooldridge y Jennings (1995) y luego adaptada por Wooldridge (2000).

“Un agente es un sistema computarizado que está situado en algún entorno y que es

capaz de actuar de forma autónoma en este entorno para satisfacer sus objetivos de

diseño”

Otra definición de agentes tenemos:

“Los agentes son sistemas computacionales que habitan en entornos dinámicos

complejos, perciben y actúan de forma autónoma en ese entorno, realizando un

conjunto de tareas y cumpliendo objetivos para los cuales fueron diseñados”. (P. Maes)

Entonces se puede decir que un agente es una entidad de software que funciona continua y

autónomamente en un medio particular frecuentemente habitado por otros agentes y

procesos, sin requerir intervención humana.

La diferencia que existe entre los agentes y los programas es la autonomía, lo que implica dos

cosas:

� Los agentes son proactivos actúan siguiendo sus propios objetivos, es decir actúan siempre

y no sólo respondiendo a una acción del usuario. Esta autonomía implica que sean "agentes

situados", es decir, que haya una clara diferencia entre el agente y su entorno.


32

� Los agentes son persistentes o sea, que no se pueden "apagar"; incluso aunque el usuario

no esté interaccionando con ellos, los agentes siguen funcionando, recolectando

información, aprendiendo y comunicándose con otros agentes.

El agente está codificado en un lenguaje de programación que se ejecuta bajo una plataforma y

se puede variar éste agente según la implementación o necesidad que el usuario le dé. Sin

embargo, el servicio Web que implemente un agente será siempre el mismo, es decir, sea cual

sea la implementación que demos a un agente para un Servicio Web determinado, este último

será semánticamente siempre el mismo, lo que variará será el agente. [18]

Una de las ventajas de los agentes es que ayuda a los clientes para escuchar el problema,

buscar en diversos medios y finalmente dar una respuesta al mismo. Este agente puede residir

tanto en la red como en el ordenador del usuario, y además, puede "conocer" los fallos para

tratar de proponer soluciones a los mismos antes de que sucedan.

Características de un Agente Inteligente

Las principales características de un agente inteligente según James Hendler [19] se describen a

continuación:

� “Comunicativo”: El agente debe estar en capacidad de entender los requerimientos,

objetivos y preferencias del usuario para que desempeñe su función eficientemente.

Además capacidad para comunicarse con el entorno a través de las ontologías.

� “Capaz”: Tener capacidad para hacer cosas como encontrar, informar sobre los elementos

que contiene, porque no solo debe limitarse a proporcionar información, sino también

resolver un servicio del usuario.

� “Autónomo”: El agente tiene que interactuar con el entorno y actuar por sí solo tomando

decisiones oportunas dependiendo del nivel de autonomía que se le sea permitida por el

usuario.


33

� “Adaptativo”: Debe ser capaz de irse adaptando y aprendiendo progresivamente del

entorno cosas relacionadas como: preferencias de usuarios, fuentes de información y de

otros agentes través de la comunicación.

1.6.2 SERVICIOS WEB

Un Servicio Web constituye una idea o concepto que debe ser implementado por algún agente.

Un agente ya se describió en el apartado anterior donde se lo considera como una pieza de

software que implementa la funcionalidad que realiza el Servicio Web el mismo que debe estar

capacitado para enviar y recibir mensajes, es decir, que el agente es el encargado de recibir las

peticiones y enviar las respuestas; en cambio el Servicio Web es el conjunto abstracto de

funcionalidades ofrecidas.

Un concepto de Servicio Web según el W3C es: “Una aplicación software identificada por

una URI, cuyas interfaces y vinculaciones son capaces de ser definidas, descritas y

descubiertas como artefactos XML. Un Servicio Web soporta la interacción con otros agentes

software mediante el intercambio de mensajes basado en XML a través de protocolos

basados en Internet”. [20]

En conclusión se puede decir que los Servicios Web son el conjunto de tecnologías y

estándares desarrollados por el W3C para permitir la comunicación entre aplicaciones a través

de la Web sin importar plataformas, sistemas operativos, infraestructura de red, o lenguaje de

programación.

Descubrimiento de los Servicios Web

Para lograr el descubrimiento de los Servicios Web se considera tres aspectos fundamentales:


34

Registros: Los servicios se publican en un registro controlado por el propietario, en el caso de

los servicios Web utilizan el estándar de publicación UDDI (Universal Description, Discovery and

Integration).

Indexación: Los servicios se indexan según criterios de popularidad que el usuario solicite. Por

ejemplo, Google indexa a los servicios de acuerdo las palabras clave de solicitud, aunque

también se podrían introducir los resultados de una indexación en un registro UDDI.

Redes Peer-to-Peer: Los servicios se buscan dinámicamente preguntando a nodos vecinos; si

no conocen dicho servicio, éstos a su vez preguntan a sus nodos vecinos, de esta forma se

propaga la consulta del servicio siguiendo un esquema descentralizado y distribuido. El

lenguaje utilizado es WSPDS22 que realiza el descubrimiento inter-operable y completamente

descentralizado, con capacidad de descubrimiento a nivel semántico.

Relación entre Servicios

Los servicios pueden ser usados por otros servicios u programas; para poder interactuar los

servicios deben estar al tanto de la existencia de cada uno y esto se logra a través del uso de

descripciones de servicios. Una descripción de servicio establece en su forma más básica, el

nombre del servicio y los datos esperados y retornados por el servicio. La forma en que los

servicios usan las descripciones de servicios resulta una relación desacoplada. Por ejemplo un

servicio Uno conoce al servicio Dos porque el servicio Uno posee la descripción del servicio Dos.

De esta forma el servicio Uno tiene toda la información necesaria para comunicarse con el

servicio Dos.

22

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.58.2679


35

Comunicación entre Servicios

La comunicación de servicios se refiere a la forma en que un servicio obtiene la respuesta al

momento que se envía un mensaje, el servicio pierde el control de lo que le sucede al

mensaje. Es por esto que los mensajes deben ser autónomos e incluir suficiente inteligencia

para poder manejar su lógica interna de procesamiento. La utilización de servicios permite

introducir modificaciones en las aplicaciones sin la necesidad de invertir grandes cantidades de

tiempo y dinero. Se consigue de esta forma un enorme valor al poder optimizar y mejorar

continuamente los procesos a medida que las estrategias del negocio cambian.

WEB SEMÁNTICA


36

CAPÍTULO II

WEB SEMÁNTICA

2.1 INTRODUCCIÓN

La Web Semántica es una corriente promovida por el propio inventor de la Web, Tim Berners-

Lee, cuyo fin es lograr que las máquinas puedan entender y utilizar lo que la Web contiene, es

decir la Web Semántica es el futuro de la Web, que facilitará la localización de recursos, la

comunicación entre sistemas y programas. Se la considera como una ampliación de la Web

actual que agrega una estructura y clasificación para captar el significado de los contenidos de

las páginas para que las aplicaciones puedan procesar y relacionar contenidos provenientes de

distintas fuentes; para que del trabajo entre humanos y ordenadores sea más completa. [21].

La Web semántica propone superar las limitaciones de la Web actual y la estructura global de

los contenidos y servicios disponibles, el crecimiento desorganizado de recursos y la ausencia

de una organización clara de la Web actual, la Web semántica se propone clasificar, dotar de

estructura y anotar los recursos con semántica clara procesable por máquinas.

En el dominio de la Web Semántica se dará una descripción de las tecnologías que interviene

en la organización de la Arquitectura de Web Semántica en cada uno de sus niveles como

interaccionan para lograr estructurar la información que sea entendible por los ordenadores,

En este capítulo se revisan conceptos, arquitecturas, estándares, lenguajes de representación

del conocimiento y ontologías.

La Web Semántica implica el desarrollo y uso de lenguajes que faciliten la introducción en la

Web de contenido legible por las máquinas. Se basa en dos conceptos fundamentales:

Descripción y Manipulación del significado de la información. La descripción se refiere a la

semántica, metadatos, y ontologías. La manipulación se refiere a la lógica, motores de

inferencia.


37

2.2 ARQUITECTURA DE LA WEB SEMÁNTICA

Tim Berneers- lee define a la Web Semántica como:

“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, ésta Web extendida y basada en el

significado, se apoya en lenguajes universales que resuelven los problemas ocasionados

por una Web carente de semántica” [22].

La Web Semántica se considera como un conjunto de iniciativas tecnológicas en la que los

ordenadores procesan la información para representarla, encontrarla y gestionarla como si

tuvieran inteligencia. Es una Web que contiene mucha información que relaciona diferentes

recursos e integrar diferentes servicios para solucionar problemas frecuentes como son las

búsquedas en Internet en diversas áreas del conocimiento.

Generalmente los buscadores comunes, proporcionan resultados de acuerdo a palabras claves

que ingresa el usuario, pero no siempre nos da los resultados que esperamos; pero con la Web

semántica se proyecta a la interpretación del significado estructurando la información y a

relacionar varios recursos en la Web para proporcionar un resultado eficiente.

La infraestructura de tecnologías y lenguajes necesarios para la implementación de la Web

Semántica se esquematiza en siete capas o niveles según Tim Berners- Lee en 2001 (Berners-

Lee et al., 2001)) como se muestra a continuación: [fig. 2]


38

Fig. 2 Arquitectura de Web Semántica presentada por Tim Berners-Lee [fig. Tomada de W3C 23

]

La arquitectura de la Web semántica está estructurada por niveles que establecen una

jerarquía entre los mismos. Estos niveles son:

� Nivel de recursos: Consiste en la identificación de recursos distribuidos por la red, (URIs).

� Nivel sintáctico: Definición de lenguajes de etiquetado para añadir semántica a las páginas

Web: XML y XML Shema.

� Nivel de Descripción de Recursos: Descripción de recursos de la red, siendo los recursos

personas, dispositivos, páginas y para ello utiliza el lenguaje RDF basado en XML.

� Nivel de Ontologías: El conocimiento será legible no sólo por las máquinas, sino también va

a ser consensuado y reutilizable a través del uso de ontologías con el lenguaje OWL.

� Resto de niveles: la lógica nos ayuda a inferir conocimiento basado en ontologías, y la

seguridad nos da un cierto grado de confianza con el uso de firmas digitales.

A continuación se describe cada uno de las capas de la arquitectura en forma individual

haciendo referencia el papel que cumple cada una de ellas, basados en el artículo “The

Semantic Web Revisited”.[23]

23

http://www.w3.org/2001/09/21-orf/hagino-sw/slide8-0.html


39

“Unicode”: Es un estándar que permite la codificación de texto para poder utilizar en

cualquier forma e idioma utilizando caracteres y alfabetos internacionales con la certeza que

al obtener la información no aparezcan símbolos extraños.

“URI24” (Uniform Resource Identifier): Es el Identificador Uniforme de Recursos que consiste en

cadenas que permiten acceder a cualquier recurso de la Web. Los URIs son las encargados de

identificar objetos para ser identificados mediante una URI. Cuando dos objetos cuentan con la

misma URI pueden existir colisiones pero el grupo de trabajo del W3C está intentando resolver

este problema.

XML+NS+xmlschema: En esta capa se encuentran agrupadas las diferentes tecnologías que

posibilitan la comunicación entre agentes por eso se la conoce como la capa más técnica de la

Web Semántica. XML25 nos ofrece un formato común para el intercambio de documentos,

Namespaces proporciona un método para cualificar elementos y atributos de nombres usados

en documentos XML asociándolos con espacios de nombres identificados por referencias URIs.

XML Schema26 es un lenguaje que permite describir la estructura y restringir el contenido de

documentos XML.

RDF+rdfschema: Está basada en la capa anterior, define el lenguaje universal con el que

podemos expresar diferentes ideas en la Web Semántica. RDF27 es un lenguaje que define un

modelo de datos para describir recursos mediante tripletas sujeto-predicado-objeto. Los dos

primeros serán URIs y el tercero puede ser URI o un valor literal.

24

http://www.w3.org/Addressing/ 25

http://www.w3.org/XML/ 26

http://www.w3.org/XML/Schema

27

http://www.w3.org/RDF/


40

RDF Schema28 es un vocabulario RDF que nos permite describir recursos mediante una

orientación a objetos. Esta capa no sólo ofrece una descripción de los datos, sino también

cierta información semántica.

Logic (Lógica): Además de ontologías se precisan reglas de inferencia.

Proof (Pruebas): Se intercambiarán pruebas escritas en el lenguaje unificador de la Web

Semántica. Este lenguaje posibilita las inferencias lógicas realizadas a través del uso de reglas

de inferencia.

Trust (Confianza): Hasta que no se haya comprobado de forma absoluta las fuentes de

información, los agentes deberían ser muy prevenidos acerca de lo que leen en la Web

Semántica.

Digital Signature (Firma digital): Utilizada por los ordenadores y agentes para verificar que la

información ha sido ofrecida por una fuente fidedigna.

2.3 LENGUAJE DE MARCADO

Los lenguajes de marcado en el dominio de la Web Semántica son lenguajes para representar

información estructurada, fundamentalmente como texto; es decir cuando almacenamos y

transmitimos información hay que encontrar como representarla en el medio disponible

como soporte, según sea el caso se elige en mayor o menor medida la estructura de la

información. Cuando la información va destinada a ser procesada por un agente inteligente lo

mejor es representar evidentemente su estructura para facilitar su interpretación.

28

http://www.w3.org/TR/rdf-schema/


41

En el ámbito de la Web semántica incluye lenguajes para la representación de ontologías,

parsers, lenguajes de consulta, entornos de desarrollo, módulos de gestión de ontologías,

módulos de visualización y otras herramientas. Dentro de los lenguajes de marcado

revisaremos XML, XML-Shema, RDF, RDF-Shema, y unas herramientas que utilizan estos

lenguajes.

2.3.1 XML

2.3.1.1 DEFINICIÓN

XML ( Extensible Markup Language) Sus siglas significan “Lenguaje de marcado extensible” : es

un metalenguaje extensible de etiquetas desarrollado por el W3C que permite definir la

gramática de lenguajes específicos y a los usuarios diseñar un propio lenguaje de etiquetas

que definirán la manera abstracta la descripción o presentación de la información en una

determinada clase de documento.

Haciendo un poco de historia XML surge de un proceso de revisión de SGML29 realizado por el

consorcio W3C. “XML utiliza la misma notación genérica de marcado, pero evita las

irregularidades detectadas en SGML. Los elementos deben tener siempre marca de terminación

(<x>...</x>) y estar bien anidados. Los elementos sin contenido se pueden representar de

manera abreviada (<z/>). Se introducen las llamadas instrucciones de procesamiento: (<?....?>),

y se mantiene la referencia al tipo de documento mediante (<!DOCTYPE ...>”)” .[24]

La información en un documento XML está estructurada en forma de árbol y para su

visualización efectiva se lo asocia a una hoja de estilo que se encarga de darle un formato

específico y mostrar la información en algún medio determinado, obteniendo distintas

29

http://en.wikipedia.org/wiki/SGML


42

reproducciones del documento tantas hojas de estilos se apliquen, sin alterar el contenido o la

información pura.

XML representa una primera aproximación a la Web Semántica, es el estándar más extendido

hoy día en las aplicaciones de esta línea pre-Web Semántica, pero no permite aún definir

ontologías, XML permite estructurar datos y documentos en forma de árboles de etiquetas con

atributos.

Una vez analizado el lenguaje de marcado XML de diversas fuentes se ha llegado a identificar

algunas bondades que nos ofrece este lenguaje, las mismas que se detalla a continuación:

� XML sirve para dotar de estructura, e incluso de formato a un documento por ser un

lenguaje de marcado para describir datos estructurados.

� Existen las herramientas necesarias para manejar los documentos, en la mayoría de los

lenguajes programación existente.

� Se tiene que definir las etiquetas porque no tiene etiquetas predefinidas.

� La red de internet es un conjunto de relaciones y objetos y XML solo modela documentos

XML.

� Un documento XML presenta su información en una estructura jerárquica, que podemos

ver como un árbol.

� La estructura de un documento puede ser simple o compleja.

� Comprobar que un documento XML esté bien formado y sea válido es muy sencillo, porque

existen herramientas necesarias para extraer y manipular la información contenida en el

documento.

� XML dentro de la estructura interna de un documento tiene dos funciones: el intercambio

de contenido entre aplicaciones y el acceso directo a los contenidos en formato textual

“legible”

�� XML describe la información que se recibe al hacer peticiones a Amazon (buscador).


43

�� Dentro de los servicios SOAP XML permite describir el conjunto de servicios disponibles

en un servidor SOAP, describir el formato de petición para cada uno de los servicios

disponibles y la forma de entrega de la información solicitada.

Así como ofrece unas ventajas también tiene algunas limitaciones que aún no han sido

superadas, entre las cuales se cita las siguientes.

� La interoperabilidad completa no está garantizada.

� Desde el punto de vista semántico no permite reconocer ni los objetos ni las relaciones

existentes en el dominio de interés.

� Sólo facilita la interoperabilidad sintáctica.

� XML aporta la sintaxis superficial para los documentos estructurados, pero sin dotarles

de ninguna restricción sobre el significado.

� No registran la estructura lógica del documento, por lo que no aportan información de

tipo semántico o estructural.

� Cualquier cambio en la presentación del documento implica modificar su marcado; en

su mayoría, son lenguajes específicos de un sistema de procesamiento propietario, lo

cual reduce la «portabilidad» de dichos documentos.

2.3.1.2 USOS

XML se lo usa para la representación digital de los documentos, es decir para transformarlos a

partir de la asignación de una estructura al documento en un tipo de código legible que

entienda la computadora para que sea capaz de almacenar, procesar, buscar, transmitir,

mostrar e imprimir dichos documentos.


44

XML se puede usar para una variedad de trabajos, en diferentes escenarios tecnológicos entre

los cuales se describen a continuación30:

� Comunicación de datos: Es más fácil la comunicación si la información se transfiere en XML,

cualquier aplicación podría escribir un documento de texto plano con los datos que estaba

manejando en formato XML y otra aplicación recibir esta información y trabajar con ella sin

ningún problema.

� Migración de datos: Cuando dos aplicaciones trabajan en formato XML sería muy sencillo

si tenemos que mover los datos de una base de datos a otra

� Aplicaciones Web: Con XML tenemos una sola aplicación que maneja los datos y para cada

navegador o soporte podremos tener una hoja de estilo o similar para aplicarle el estilo

adecuado.

2.3.1.3 ESPACIO DE NOMBRES

Un espacio de nombres XML es un conjunto de nombres identificados por una referencia URI,

que se utilizan en documentos XML como tipos de elemento y nombres de atributo. Los

espacios de nombres XML difieren de los "espacios de nombres" usados convencionalmente en

las disciplinas de programación en que la versión XML tiene estructura interna y no es,

matemáticamente hablando, un conjunto. Los nombres de esquema utilizados en un

documento XML son únicos a fin de evitar la ambigüedad en el significado de las etiquetas. Sin

embargo, si un documento XML hace referencia a múltiples esquemas, existe la posibilidad de

que dos o más de estos contengan el mismo nombre, para diferenciar en el documento un

esquema de otro se le asigna un namespace a cada uno. [25]

Un documento XML puede tener partes diseñadas para distintas aplicaciones lo importante es

que estas partes no choquen entre sí cuando se habla de Web Semántica. Los espacios de

30

http://bitacorahelpdesk.blogspot.com/2008/10/que-es-y-para-que-me-sirve-xml.html


45

nombres (namespaces) facilitan la combinación en un mismo documento de marcas

correspondientes a varios lenguajes de marcado particulares.

La estructura general de un documento XML de acuerdo al W3C31 está formada por tres

partes:

� “Prólogo”: Contiene una secuencia de instrucciones de procesamiento y/o declaración de

tipo de documento (opcional). El prologo está formado por: Una declaración XML, una

declaración de tipo de documento y uno o más comentarios e instrucciones de

procesamiento

� “Cuerpo”: Es un árbol único de elementos marcados, con anidamiento estricto, es decir

debe contener uno y solo un elemento raíz. Además de los elementos, puede contener

comentarios e incluso instrucciones de procesamiento.

� “Epílogo”: Contiene una secuencia de instrucciones de procesamiento (opcional) que por

lo general se las omite.

En XML un nombre simple sólo contiene letras, subrayado y guiones. Los caracteres punto y dos

puntos se usan en nombres cualificados. A continuación se describe como están formados

estos nombres:

� “Inicial � letra _ : �letra, subrayado, dos puntos”.

� “Resto:�letra _: - . � letra, subrayado, dos puntos, guión, punto”.

� “Se diferencia los caracteres mayúsculas y minúsculas”.

Los nombres cualificados contienen un símbolo de dos puntos (:) que divide al nombre en un

prefijo del espacio de nombres y una parte local. El prefijo, que corresponde a la referencia URI,

selecciona un espacio de nombres. La combinación del espacio de nombres URI gestionado

31

http://www.spanish-translator-services.com/espanol/t/Namespaces_in_XML_1.1_SP.htm


46

universalmente y del espacio de nombres propio del documento produce identificadores que

son únicos a nivel universal. Se proporcionan mecanismos para definir el ámbito de los prefijos

y los valores por defecto.

Las referencias URI pueden contener caracteres no permitidos en nombres, de modo que no

pueden utilizarse directamente como prefijos de espacios de nombres. Por tanto, el prefijo de

espacio de nombres actúa como intermediario de una referencia URI. Se utiliza una sintaxis tipo

atributo para declarar la asociación del prefijo de espacio de nombres con una referencia URI.

Estructura Interna de los Espacios de Nombres XML

Espacios de nombres XML es una colección que no contiene elementos repetidos, sin

embargo, al considerar los nombres utilizados en el código XML como un espacio de nombres

de este tipo dificultaría en gran medida su utilidad. La utilización principal de nombres en

documentos XML es permitir la identificación de estructuras lógicas en documentos por parte

de módulos de software tales como: procesadores de búsqueda, motores de representación

basados en hojas de estilo y validadores basados en esquemas.

Las particiones de espacio XML se da para mantener el propósito de los nombres cualificados y

los no cualificados para que sean útiles a dicho objetivo, para ello identificamos los nombres

que aparecen en un espacio de nombres XML según su pertenencia a uno o varios espacios de

nombres tradicionales llamados particiones del espacio de nombres. Las particiones son: de

todos los tipos de elementos, de atributos globales y por tipo de elemento.

2.3.2 XML SCHEMA

XML Schema surge a raíz de la necesidad de jerarquizar y estructurar la información para

almacenarla y tener acceso a ella, es decir, XML Schema trata de la estructura y la semántica


47

de los documentos XML. Los esquemas indican tipos de dato, número mínimo y máximo de

ocurrencias y otras características más específicas. Un esquema se puede definir como una

colección de definiciones de tipos y declaraciones de elementos cuyos nombres pertenecen a

un determinado espacio de nombres llamado espacio de nombres de destino. [26]

XML Schema es una aplicación de XML para modelar la estructura de documentos XML válidos;

provee un significado para definir la estructura, contenido y semántica de los documentos XML

además se expresa en vocabularios compartidos lo que nos permite extraer las reglas hechas

por las personas. Adicionalmente un esquema XML nos permite realizar las siguientes

operaciones dentro de un documento entre las cuales tenemos:

� Definir y organizar los elementos que puede contener un documento XML.

� Definir los atributos y tipo de elementos que puede contener un documento XML.

� Definir el tipo de contenido de un elemento o de un atributo, y especificar el tipo de dato

(entero, una cadena de texto, fecha, boolean).

� Se puede trabajar con varios espacios de nombres

� Permiten crear nuevos elementos y utiliza sintaxis XML

� Permite tipos definidos por el usuario, llamados Arquetipos, dándoles un nombre y que se

pueden emplear en distintas partes dentro del Schema y además extender (herencia) los

arquetipos de un modo específico.

Cuando un documento se hace grande, es aconsejable dividir su contenido entre varios

documentos, esquemas, con el fin de facilitar su mantenimiento, control de acceso y

legibilidad. XML Schema contiene tres recomendaciones establecidas por el W3C las cuales se

describen a continuación: [27]

� XML Schema Part 0: Primer. Es un documento no normativo que pretende ofrecer una fácil

descripción de las funcionalidades de XML Schema y que está orientado a comprender de

forma rápida cómo crear esquemas utilizando el lenguaje XML Schema.


48

� XML Schema Part 1: Structures. Especifica la definición del lenguaje XML Schema y ofrece

las herramientas para describir la estructura. Además permite validar documentos con

varios namespaces.

� XML Schema Part 2: Datatypes. Establece las herramientas para definir los tipos de datos

que se usan en los esquemas XML y en otras especificaciones XML para especificar tipos de

datos sobre elementos y atributos. Los tipos base que se pueden emplear dentro del

esquema de XML son: integer, boolean, string, date, entre otros.

DTDs Versus XML Schema

DTD32 (Definición de Tipo de Documento) se caracteriza por definir los elementos que

constituyen un documento en XML. Es decir un DTD es una especificación y estructuración

necesaria que permite validar el contenido estructural y formal de un documento SGML y XML.

Las bondades que ofrecen los DTD son muchas, entre las cuales se puede citar las siguientes:

� Todos los archivos XML tienen una descripción de su propio formato.

� Distintos grupos de personas puedan ponerse de acuerdo para utilizar una DTD común

para intercambiar datos.

� El programa en uso manipule una norma DTD para verificar que los datos que se reciben

del mundo externo sean válidos.

� Se puede usar la norma DTD para verificar los datos propios.

Lo importante es que la estructura de los documentos que se producen en XML coincida

exactamente con la estructura prevista en la DTD. La actividad más importante que se realiza

32

http://www.sitepoint.com/article/xml-dtds-xml-schema/


49

en este contexto es el mapeo del esquema de la base local de datos a un esquema XML de la

DTD.

Limitaciones de los DTD

Algunas limitaciones en la definición de tipo de documento se describen a continuación:

� Tiene lenguaje propio de escritura, lo que ocasiona problemas a la hora del aprendizaje; no

sólo hay que aprender XML, sino también conocer lenguajes de los DTDs.

� En un DTD no es posible definir un tipo de elemento programático, por ejemplo, declarar un

valor como String o Integer, mientras en un Schema si es posible llevar a cabo este tipo de

declaración.

� Para el procesado de las herramientas, las herramientas y analizadores empleados para

tratar los documentos XML deben ser capaces de procesar los DTDs.

� No permite el uso de namespaces y éstos son muy útiles ya que permiten definir elementos

con igual nombre dentro del mismo contexto, siempre y cuando se anteponga un prefijo al

nombre del elemento.

� Tiene una tipología para los datos del documento considerablemente limitada, no permite

definir un elemento de tipo número, fecha, flotante etc. Sólo presenta variaciones limitadas

sobre cadenas.

� Una DTD no permite definir elementos locales que sólo sean válidos dentro de otros

elementos.

� Cuando se usa DTDs no es posible utilizar más de dos para validar un documento, y si

necesitamos agregar una nueva sección a su información en XML no es válido, se tiene que

rediseñar el DTD para contemplar esta información adicional.

� El mecanismo de extensión es complejo y frágil ya que está basado en sustituciones sobre

cadenas y no hace explicitas las relaciones, es decir, que dos elementos que tienen definido

el mismo modelo de contenido no presentan ninguna relación.


50

Todas las limitaciones antes expuestas son superadas por la especificación XML Schema, por

ser un lenguaje mucho más expresivo y el intercambio de información mucho más robusto.

Ventajas de los XML Schemas

Analizando las características que nos ofrece los XML-Schemas de varias fuentes se ha

encontrado algunas ventajas las mismas que superan las limitaciones de los DTDs, entre las

cuales se citan las siguientes:

� En XML Schema Part 233: Datatypes se definen los tipos base que se pueden emplear dentro

de esquema de XML (byte, integer, boolean, string, date, sequence, etc). Este sistema de

tipos es muy adecuado para importar y exportar sistemas de bases de datos y, sobre todo,

distingue los requerimientos relacionados con la representación léxica de los datos y el

conjunto de información dominante y subyacente.

� En XML es posible utilizar Namespaces al momento de validar documentos XML

permitiendo validar documentos con varios namespaces, esto elimina la restricción

impuesta por los DTDs.

� Permite tipos definidos por el usuario, llamados Arquetipos. Dando un nombre a estos

Arquetipos se pueden utilizar en distintas partes dentro de un Schema.

� Permite agrupar atributos para hacer más comprensible el uso de un grupo de aspectos de

varios elementos distintos, pero con un denominador común que consiste en ir juntos en

cada uno de éstos elementos.

2.3.3 HERRAMIENTAS

En la actualidad existe un gran número de herramientas para el proceso de documentos XML,

así como librerías e interfaces estándar para el desarrollo de nuevas herramientas. En la tabla 3

se mencionan se mencionan algunas de ellas.

33

http://www.programacion.com/tutorial/schemaydtd/2/


51

CATEGORIA HERRAMIENTAS

Interfaces estándar34 DOM: Document Object Model - API orientada a estructura SAX: Simple API for XML - Parsing orientado a eventos

Librerías basadas en las interfaces anteriores que se puede llamar desde diversos lenguajes

libxml, libxsl PerlXML, AdaXML Expat: parser XML

Procesadores XML35 Apache: Xerces (parser), FOP (procesador XSL-FO), ... MSXML (Microsoft) - parser XML, procesador XSLT. Incluído en Internet Explorer 5.0 y posteriores Saxon, xsltproc: procesadores XSLT

Herramientas: Editores XML

XMLnotepad (Microsoft) - editor del árbol de contenido CookTop - editor de texto XML y acceso a MSXML Morphon - editor WYSIWYG de XML, y editor CSS. XXE: Xmlmind Xml Editor - editor WYSIWYG del contenido XML XmlSpy - entorno completo de desarrollo XML

Las aplicaciones que utilizan XML36

AbiWord: Procesador de texto OpenOffice: Paquete de ofimática Netscape/Mozilla/Firefox: Navegador Web Amaya: Navegador WebExplorer 5.0: Navegador Web de Microsoft Tabla 3. Herramientas que trabajan con XML

XML Notepad37: Es un editor de XML gratuito desarrollado por Microsoft; para su utilización es

necesario tener instalado, como mínimo, la versión 4.01 del Explorer y NET Framework 2.0,

aunque sólo se puede aprovechar en su totalidad en la versión 5. Para instalar se necesita

tener Sistema Operativo WinXP/2003/VistaXP/2003/Vista.

XML Notepad es un completo editor de XML de intuitiva interfaz de doble ventana (texto y

estructura de árbol) que proporciona un entorno de trabajo ágil y cómodo para visualizar y

editar documentos en XML. 34

http://www.hipertexto.info/documentos/dom.htm 35

http://www.ulpgc.es/otros/tutoriales/xml/Herramientas.html 36

http://www.ulpgc.es/otros/tutoriales/xml/Navegadores.html 37

http://xml-notepad.softonic.com/


52

Algunas de sus características más destacadas son una práctica herramienta de búsqueda,

soporte para drag-and-drop38, la opción de “undo” infinito o la posibilidad de personalizar

fuentes y colores. XML Notepad trabaja sin problemas con documentos de gran tamaño,

Presentan la estructura del documento XML en forma de árbol, y nos permiten construir

nuestro documento trabajando sobre este árbol y formularios adicionales.

CookTop - editor de texto XML y acceso a MSXML

CookTop39 es un editor de desarrollo para documentos XML, DTDs, y XLST hojas de estilo, se

instala en sistema Operativo Windows/NT4/2000/XP la versión 2.5 y la versión anterior 2.2

desde Windows 95 en adelante, el cual es gratuito.

Morphon - Editor XML WYSIWYG, basado en DTD y CSS

Morphon XML-Editor40: Es un editor XML escrito en Java técnicamente muy intuitivo, siendo

miembro de la familia de los editores WYSIWYG. Permite la creación de documentos XML

basados en DTD (Definición del Tipo de Documento) y en el lenguaje de las hojas de estilo CSS.

Como requisito mínimo se debe tener Java Runtime Environmet. Además del modo de

visualización WYSIWYG41, propone una vista jerárquica para la edición de ficheros XML,

preservando así la integridad de estos documentos.

Morphon XML-Editor es un editor que nos facilita enormemente la tarea de edición XML, con

una opción de pre-visualización del documento por medio de una hoja de estilo XSL y un editor

CSS, que se puede incluso usar de forma independiente para crear directamente CSS para la

Web.

38

Arrastrar y soltar (drag and drop) se refiere a la acción de mover con el ratón objetos de una ventana a otra o entre partes de una misma ventana. 39

http://www.xmlcooktop.com/update/ 40

http://www.morphon.com/tom/ 41

WYSIWYG lo que se está creando con el editor es lo que obtienes luego cuando grabas la página lo usa HTML


53

XMLSpy entorno completo de desarrollo XML

XMLSpy42 es un entorno de desarrollo de IDE (Integrated Development Environment) de Altova

GmbH & Altova que ha sido utilizado en el proyecto COVAX para manejar y simplificar las tareas

de marcación y edición de documentos en XML.

XmlSpy 3.0.7 es un entorno integrado de desarrollo (IDE) para lenguajes de marcado que tiene

todos los aspectos principales de XML, incluyendo edición y validación de XML, Esquemas y

DTDs; edición y transformación de XSL. Este sistema tiene un editor XML con validación que

proporciona cuatro vistas del documento: una Vista mejorada de rejilla para edición

estructurada, una vista de Base de datos / tabla para mostrar elementos repetidos en forma de

tabla, una vista textual con sintaxis coloreada para trabajo a bajo nivel, y una vista de

navegador integrado, que soporta hojas de estilo tanto CSS con XSL y también soporta XML

Schema.

Altova XMLSpy 2008, es un potente editor de archivos XML, cuenta con un entorno de

desarrollo para el modelado, edición, transformación, depuración de XML y las tecnologías

relacionadas con él. Además es un completo editor de XML con una gama de funcionalidades,

ya que además presenta un generador de código, convertidores de archivos, depuradores,

perfiladores, plena integración de bases de datos, soporte para XSLT, XPath, XQuery, WSDL,

SOAP, documentos Office Open XML (OOXML) y mucho más.

2.4 LENGUAJES DE CONSULTA

Siguiendo la línea de la Arquitectura de Web Semántica, una vez que ya se tiene los

documentos estructurados con la ayuda de los lenguajes de marcado; en esta sección se

analizará los lenguajes de consulta, o también denominados sistemas de búsqueda que

42

http://www.xmlspy.com


54

básicamente han adquirido una gran importancia en el uso diario de los ordenadores para el

tratamiento de información. Actualmente la recuperación de información textual lleva consigo

asociada una serie de problemas, que están asociados por las características propias del

lenguaje natural al resultar éste confuso, que aún no han sido resueltos satisfactoriamente.

El uso apropiado de los lenguajes de recuperación o de consulta que se describen más

adelante es muy importante a la hora de recibir los resultados; debido a que los documentos

XML cada vez tienen mayores tamaños, los cuales manejan grandes y complejas colecciones de

datos. Debido a estas limitaciones se hace necesario que surjan nuevos lenguajes que permita

definir de forma rápida y compacta, consultas o recorridos complejos sobre colecciones de

datos en XML, los cuales presenten una respuesta de los nodos que cumplan ciertas

condiciones. Ante esta necesidad surgen lenguajes como: XQuery (lenguaje par realizar

consulta sobre colecciones de datos XML), RDF (marco de descripción de recursos), RDF

Schema (lenguaje que proporciona los elementos básicos para la descripción de vocabularios),

SPARQL(lenguaje de recuperación para RDF/RDFS).

2.4.1 XQUERY

XQuery o XML Query es un lenguaje de consulta que permite encontrar y extraer elementos y

atributos de documentos XML. Es un leguaje de consultas estándar, publicado por el W3C que

utiliza la notación XML para definir consultas y manejar los resultados. Es compatible con XML,

Namespaces, XSLT, XPath y XML Schema porque es supervisado por el W3C.

XQuery está diseñado para escribir consultas sobre colecciones de datos expresadas en XML

que abarca desde archivos XML hasta bases de datos relacionales con funciones de conversión

de registros a XML. “Su principal función es extraer información de un conjunto de datos

organizados como un árbol de etiquetas XML. En este sentido XQuery es independiente del

origen de los datos”. [28]


55

Caracteristicas de XQuery

XQuery43 al ser un lenguaje de consulta ofrece una gama de características que ayudan a

mejorar el sistema de búsqueda de información estructurada de los documentos. Algunas de

ellas se detallan a continuación:

� Es soportado por los principales motores de bases de datos (IBM, Oracle, Microsoft, etc.).

� Está basado en expresiones XPath es decir comparten el mismo modelo de datos,

funciones y operadores. Con estas expresiones podemos recuperar elementos o atributos

XML.

� Permite la unificación de información proveniente de muchas y diversas fuentes es decir es

un interfaz unificador para acceder a datos XML.

� Cada consulta es una expresión que es evaluada y devuelve un resultado, algo parecido que

SQL.

� Es el estándar futuro de las consultas sobre documentos XML por la robustez y flexibilidad

que permite consultar en una variedad de fuentes de información.

Consultas en XQuery

En XQuery las consultas están compuestas por cláusulas de tipos distintos y éstas siguen norma

FLWOR (For, Let, Where, Order y Return). A continuación se detallan cada una de ellas: [29]

� FOR: Vincula una o más variables a expresiones escritas en XPath por cada nodo

recuperado por la expresión creando un flujo de tuplas que se encuentran vinculadas a una

variable.

43

http://www.w3.org/TR/xquery/


56

� LET: Vincula una variable al resultado completo de una expresión y añade vínculos

generados por FOR, en caso de no existir crea una única tupla que contenga dichos

vínculos.

� WHERE: Filtra la información de las tuplas devueltas por FOR o LET, recuperando

únicamente aquellas que cumplen las condiciones dadas por una expresión.

� ORDER: organiza la información recuperada de acuerdo a un criterio dado. Por defecto,

organiza por orden ascendente según el tipo de datos.

� RETURN: Construye el resultado de la consulta, es decir formatea la información de salida.

Esto tiene muchas utilidades ya que se puede convertir la información recuperada a HTML,

PDF, o cualquier otro formato.

Además en XQuery también se admiten expresiones condicionales IF-THEN-ELSE. Esta cláusula

es útil para dar un formato diferente a la salida dependiendo de la información que contiene,

es decir, se puede cambiar la estructura de los nodos en los que se recupera la información

según nos convenga por su contenido. Además dispone de dos cuantificadores existenciales

“EVERY” (recupera aquellas tuplas en las que todos los nodos cumplan la condición) y “SOME”

(recupera aquellas tuplas en las que algún nodo cumpla la condición).

Características técnicas de XQuery

Además de las características generales, este lenguaje debe reunir algunas características

técnicas para ser considerado un lenguaje de recuperación eficiente. Entre la cuales se

mencionan:

� XQuery debe ser independiente del protocolo de acceso a la colección de datos. Una

consulta en XQuery debe funcionar igual al buscar en un archivo local, en un servidor de

bases de datos, en un archivo XML o en un servidor Web.

� Las consultas y los resultados deben respetar el modelo de datos XML y ofrecer soporte

para los namespaces.


57

� Deben ser capaces de soportar XML Schemas, DTD y también capaz de trabajar sin ninguno

de ellos.

� Ser independiente de la estructura del documento es decir trabajar sin necesidad de

conocerla.

� Soportar tipos simples y compuestos de datos: simples (enteros, cadenas), compuestos

(nodos compuestos por varios hijos).

� Las consultas deben soportar la existencia de cuantificadores Universales (para todo) y

existenciales (Existe).

� Las consultas deben soportar expresiones sobre jerarquías y secuencia de nodos.

� Permitir combinar información de múltiples fuentes en una consulta y manipular la

información independientemente del conjunto de datos.

� El lenguaje de consulta debe ser independiente de la sintaxis, es decir que soporte varias

sintaxis para expresar una misma consulta.

2.4.2 RDF

Otro lenguaje de consulta en el dominio de la Web Semántica es RDF44 (Resource Description

Framework) cuyas siglas significa marco de descripción de recursos; es el primer estándar

definido para la Web Semántica desarrollado por W3C en Agosto de 1997 y es el lenguaje que

permite la representación de metadatos, el cual facilitará la interoperabilidad entre sistemas

que intercambian información entendible entre las máquinas. RDF es el lenguaje para la

definición de ontologías en la Web y es el estándar más popular y extendido de la comunidad

de la Web semántica. El elemento de construcción básica en RDF es el “triple” o sentencia, que

consiste en dos nodos (sujeto y objeto) unidos por un arco (predicado), donde los nodos

representan recursos, y los arcos propiedades.

44

http://www.w3.org/TR/rdf-concepts/


58

RDF permite la descripción de contenidos Web de manera que sean entendibles por los

ordenadores. Un modelo típico de archivos RDF son los archivos FOAF45 (amigo de un amigo).

Por ejemplo, un archivo FOAF con el nombre ‘Gloria Carrión’ facilita que el programa perciba

que hay una persona con el nombre de Gloria Carrión que dispone de páginas Web, contactos,

afiliaciones profesionales, y amigos. Estos últimos disponen de sus propios archivos RDF y FOAF

facilitando que la máquina registre todos estos vínculos. Este tipo de seguimiento y correlación

es la clave de la Web Semántica.

RDF está orientado a la creación de metadatos para la descripción de recursos Web y muy

relacionado con XML, ya que RDF permite la especificación de información semántica,

mediante la utilización de XML. Además proporciona un modelo de datos para describir la

semántica de la información de una forma accesible por la máquina. Un objeto se describe

mediante sus propiedades. Este lenguaje puede ser utilizado en diferentes aplicaciones, tales

como: búsquedas, recuperación de recursos, catalogación, bibliotecas digitales, y agentes

inteligentes.

2.4.2.1 CARACTERISTICAS DE DISEÑO DE UN RDF

RDF contiene algunas características que se deben considerar al realizar un diseño RDF las

cuales se describen a continuación: [30]

� “Independencia”: Se refiere a que cualquier organización independiente o una persona

particular puede diseñarla.

� “Intercambio”: Debido a que utiliza el lenguaje de marcas XML para escribir las sentencias

RDF, es una ventaja para poder intercambiar información masivamente.

� “Escalabilidad”: RDF permite representar expresiones basados en un modelo que consta

de tres elementos que son Recurso, propiedad, Valor; esto implica que facilita el manejo y

45

http://www.foaf-project.org/


59

uso de objetos en la búsqueda en grandes volúmenes de información que crece

considerablemente, de ahí la importancia que pueda ser escalable un RDF.

� “Las propiedades son recursos”: Al crecer la información se tendrá elevado número de

recursos para manejar y para buscar cada uno de ellos, pero gracias a esta característica de

que las propiedades puedan a la vez tener sus propias propiedades y ser encontradas y

manipuladas como cualquier otro recurso.

� “Los valores pueden ser recursos”: Los valores de sus propiedades deben incluir recursos;

en el caso de las páginas Web poseen una propiedad llamada “home” que apunte al home

del sitio. El valor de sus propiedades que pueden ser título y autor, también tiene que

contener recursos.

� “Las sentencias pueden ser recursos”: Las sentencias deben tener sus propias

propiedades por ser la Web voluminosa y no tener un estándar para todos los recursos que

existen tenemos que realizar las búsquedas basadas en metadatos de otras personas.

2.4.2.2 ESTRUCTURA DE UN DOCUMENTO RDF

RDF tiene un modelo de datos, el cual nos permite representar expresiones basadas en un

modelo formado por tres elementos: [31]

� Recursos: Son todos los objetos que pueden tener una URI o ser expresados con

expresiones RDF; por ejemplo, una página Web o parte de ésta, también puede ser un

conjunto de páginas Web o los elementos individuales de cada documento XML.

� Propiedades: Son recursos que tienen un nombre y pueden usarse como una propiedad; es

decir, un aspecto específico, atributo o relación que permite describir un recurso.

� Sentencias: Llamadas también expresiones, que consisten en un recurso específico junto

con el nombre de una propiedad, más el valor de ésta formarán una expresión RDF. Estos

tres elementos que forman una expresión son llamados, también: sujeto, predicado y

objeto.


60

En el siguiente ejemplo, se identifican los tres componentes de una expresión RDF y su

representación en el lenguaje RDF.

Gloria Carrión es la autora de la tesis http://www.utpl.edu.ec/~gloriac/tesis.pdf

Las partes de la expresión se muestran en la tabla 4

Sujeto(Recurso) http://www.utpl.edu.ec/~gloriac/tesis.pdf

Predicado(propiedad) Autor

Objeto(literal) “Gloria Carrión”

Tabla 4. Partes de una Expresión RDF

Esta misma expresión se puede representar gráficamente como muestra en la fig. 3, donde los

arcos representan46 las propiedades, los recursos son representados por nodos circulares y los

nodos rectangulares representan los literales (que vienen a ser los valores de la propiedad)

Fig 3. Grafo de una expresión RDF

Además la misma expresión se puede representar a través de un conjunto de términos, la

misma que se quedaría de la siguiente forma.

46

http://www.matem.unam.mx/~grecia/semantic_web/rdf.html


61

2.4.2.3 DIFERENCIAS ENTRE XML y RDF

Una vez analizados los lenguajes de Web Semántica como es XML y RDF se pueden puntualizar

algunas diferencias existentes. En la tabla 5 se describen algunas de ellas.

XML RDF

Lenguaje para modelar datos Lenguaje para especificar metadatos

La escabilidad de los datos es limitada debido a que el orden de los elementos no es adecuado y su mantenimiento es muy difícil y costoso.

Permite la interoperabilidad entre aplicaciones que intercambian información comprensible por la página Web.

El modelo de datos XML es un “árbol etiquetado” que está orientado a marcas de texto y son “menos flexibles” para expresar metadatos.

Posee un modelo muy simple consistente en “arcos etiquetados” y cualquier conjunto específico de declaraciones RDF forma un “grafo” que puede serializarse en XML.

Los esquemas XML tienen una interpretación sintáctica, restringiendo el conjunto de documentos XML que pueden elaborarse. Los esquemas XML se utilizan para modelar documentos XML.

RDF tiene principalmente una interpretación semántica y se utiliza para construir o modelar conocimiento, donde las representaciones basadas en las estructuras de árbol no son suficientes.

[Tabla 5] Diferencias entre XML y RDF

Una de las bondades que ofrece RDF es que es muy útil en situaciones en las que la

información necesita ser procesada por aplicaciones que intercambian información legible por

máquina, más que por humanos. RDF también provee una sintaxis basada en XML, llamada

RDF/XML, para guardar e intercambiar la información. En lo relacionado a los recursos en RDF,

los nodos no son nodos dentro del mismo documento, sino cualquier recurso que tiene un URI,

<?xml version=”1.0”> <rdf:RDF> <rdf:Description about=”http://www.utpl.edu.ec/~gloriac/tesis.pdf”> <s:autor>Gloria Carrión</s:autor> </rdf:Description> </rdf>


62

y por lo general reside fuera del propio documento RDF. Pero a pesar de ofrecer variedad de

ventajas también tiene algunas limitaciones que son:

� Cuando dos documentos pueden usar definiciones diferentes del mismo concepto y no

se puede decidir que son equivalentes.

� Tiene problemas de ambigüedad en la definición de sus elementos.

� No se permite el manejo y/o definición de restricciones de integridad.

� RDF no se ajusta bien a documentos XML.

� Algunas partes de RDF son complejas.

2.4.3 RDF SCHEMA

“RDF SCHEMA es una extensión Semántica de RDF que consiste en un lenguaje primitivo

de ontologías que proporciona los elementos básicos para la descripción de

vocabularios” [32].

RDF- Schema (Resource Description Framework Schema): La versión actual de la

recomendación fue publicada en febrero de 2004 por el W3C: Este lenguaje se utiliza en la

declaración de esquemas RDF. El modelo de datos de RDFS está basado en frames y

proporciona un mecanismo para la definición de clases, objetos, propiedades, relaciones entre

clases y propiedades, restricciones de dominio y rango sobre las propiedades.

Un archivo RDF-S contiene la misma sintaxis y la misma estructura que las que utiliza un RDF es

decir la sintaxis basada en XML y extensible, por lo que los desarrolladores pueden extender

los esquemas de manera independiente; además establece jerarquías de clases dentro de

categorizaciones RDF.


63

Las expresiones RDF-S se construyen a través de un conjunto de términos como: Class,

subClassOf y Property que permiten expresar expresiones acerca de los recursos (clases),

representar sus propiedades y a la vez representar una jerarquía de recursos. Los objetos se

instancian a partir de las clases usando la propiedad type. Las restricciones de las propiedades

podrán ser especificadas usando domain y range [33]. A continuación, se muestra un ejemplo

[Fig. 5] de las clases, propiedades y jerarquía de recursos como se interrelacionan.

Fig. 4 Ejemplo de un RDF-Shema

En la figura anterior se muestra un grafo RDF-S en el cual se define un vocabulario: Documento,

Asignación, Reporte, Tesis y Persona que son definidos como clases y autor que es una

propiedad. Luego la dos instancias “…documento/tesisgloria” y “…utpl.edu.ec/~gloria”.

2.4.3.1 CARACTERISTICAS DE RDFS

Algunas características de RDF Schema47 de acuerdo al W3C se pueden citar las siguientes:

47

http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/


64

� Los elementos son un conjunto de recursos y propiedades para facilitar la definición de

vocabularios.

� Implementa un modelo de datos orientado a objetos.

� La estructura de los RDF-S contiene: clases, instancias, relaciones, propiedades y dominio.

� Permite definir una clasificación de recursos en términos de clases, subclases, propiedades,

etc.

� Establece restricciones sobre las posibles combinaciones.

� Las clases pueden ser subclases de otras.

� El tipo de un recurso debe ser un elemento de una clase. Por ejemplo “property” es un

subconjunto de recursos que son propiedades.

� Las propiedades tienen un rango y un dominio.

� Enriquece las descripciones semánticas.

� Facilita la combinación de sentencias RDF a través de las URIs.

� RDFS no establece cómo una aplicación utilizará la información que RDFS describe.

2.4.3.2 LIMITACIONES DE RDF SCHEMA

A pesar de que RDF Schema es un lenguaje más avanzado que proporciona los elementos

necesarios para describir vocabularios; tiene algunas limitaciones que se describen a

continuación:

� No indica las cardinalidades.

� Restricciones de rangos simples para las propiedades.

� No se pueden derivar tipos por unión e intersección.

� Se necesita relaciones de clases y propiedades más robustas.


65

2.4.4. RDF: SPARQL

SPARQL48 (SPARQL Protocol and RDF Query Language): Es un lenguaje de recuperación para

RDF/RDFS. Esta tecnología de consulta SPARQL permite que las personas pueden centrarse en

la información que quieren, sin tener en cuenta la tecnología de la base de datos o el formato

utilizado para almacenar los mismos; debido a que las consultas en este lenguaje expresan

objetivos de alto nivel, es fácil extenderlos a orígenes de datos inesperados, o se puede

transferir a nuevas aplicaciones. SPARQL está diseñado para un uso a escala de la Web, de tal

forma que permite realizar consultas sobre orígenes de datos distribuidos,

independientemente del formato que se encuentren.

SPARQL básicamente se basa en comparación de patrones gráficos, los mismos que contienen

patrones triples y los patrones triples son como las tripletas RDF, pero con la opción de

unaÉvariable consulta en lugar de un término RDF en las posiciones del sujeto, predicado u

objeto. Al momento de combinar los patrones triples se obtiene un patrón grafico básico,

donde es necesaria una comparación exacta entre gráficos.

Entre las diversas consultas de este lenguaje se pueden diferenciar cuatro tipos de consultas:

SELECT, CONSTRUCT, ASK, DESCRIBE, a continuación se describen cada uno de ellas.

� SELECT: Devuelve todo, o un conjunto de las variables que coinciden con el patrón de

búsqueda solicitado.

� CONSTRUCT: Devuelve un grafo RDF construido por la sustitución de variables en un

conjunto de tres plantillas.

� ASK: Devuelve un valor boolean indicando si los patrones de la consulta coinciden o no

con lo solicitado.

48

http://www.w3.org/TR/rdf-sparql-query/


66

� DESCRIBE: Devuelve un grafo RDF que describe los recursos encontrados.

2.4.7 HERRAMIENTAS EXISTENTES

Existe una variedad de herramientas desarrolladas en el ámbito de Web Semántica y

específicamente que utilizan el lenguaje de consulta RDF y RDF Schema entre ellas se pueden

citar las siguientes: SESAME, JENA, TWINE, CORESE, KOWARI. Seguidamente se describen cada

una ellas detallando algunas características, funcionalidades y técnicas que utilizan.

SÉSÁME

Es un API para Java que presenta un marco de desarrollo para almacenamiento, consulta y

razonamiento con RDF y RDF Schema. Puede ser usado como base de datos RDF y RDF Shema

o como una librería de Java para aplicaciones que necesitan trabajar internamente con RDF. Es

un entorno para desarrollo de aplicaciones en el lenguaje de programación Java para Web

Semántica.

En el framework de Sesame el repositorio de inferencias no es más que un contenedor de

almacenamiento para RDF, el cual puede ser un simple objeto Java en memoria o también una

base de datos relacional; en cualquiera de los dos casos, casi todas las operaciones están

relacionadas con un repositorio. Por ejemplo: cuando se añaden datos RDF se incluyen en un

repositorio; cuando se realiza una consulta se pregunta a un repositorio en particular. [34]

Arquitectura de Sésame

La capa SAIL API (Storage And Inference Layer), es una API interna de Sesame que se abstrae

del formato de almacenamiento usado, si los datos son almacenados en un RDBMS, en

memoria o en ficheros.


67

Luego de la capa SAIL se encuentran los módulos funcionales de Sesame: SeRQL, RQL49 y

RDQL50 Query engines, el módulo administrador y RDF Export. A estos módulos de

funcionalidad se pueden acceder a través de la API de Acceso de Sesame, que consiste en dos

partes separadas: Repository API y el Graph API. Estas dos APIs se complementan la una a la

otra en funcionalidad y en la práctica se suelen usar juntas, las APIs de Acceso de Sesame

proporcionan acceso directo a los módulos de funcionalidad de Sesame, tanto a un cliente

como a un servidor.

Fig.5 Arquitectura de Sesame [tomada de openRDF.ORG51

]

Aunque cada parte del código de Sesame está públicamente disponible y extensible, la mayoría

de los desarrolladores están al principio más interesados en las APIs de Acceso, para poder

establecer comunicación con un modelo RDF de Sesame o contra un repositorio de Sesame

desde su aplicación.

49

http://sesame.aidministrator.nl/publications/rql-babysteps.html. 50

http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/ 51

http://www.openrdf.org/doc/sesame/users/ch07.html#figure-sesame-arch-api


68

Funcionalidades de SeRQL Query Language

Entre las funcionalidades de SeRQL52 tenemos

� Transformación gráfica.

� Soporta RDF Schema.

� Soporta tipos de datos de XML Schema.

� Sintaxis para Path Expressions.

� Opcionalmente, Path Matching.

JENA

Jena53 es un framework desarrollado por HP Lab para manipular metadatos desde una

aplicación java. En la actualidad existen dos versiones:

Jena 1: Tiene soporte para RDF y capacidades limitadas de razonamiento y además permite

crear modelos persistentes que son mantenidos de forma transparente al usuario en una base

de datos relacional.

Jena 2: Incluye una API para el manejo de ontologías, soporta el lenguaje OWL, MySQL,

Oracle, PostgreSQL54.

Entre las principales características de Jena se tienen las siguientes: [35]

� Permite gestionar (añadir hechos, borrarlos y editarlos) todo tipo de ontologías

almacenarlas y realizar consultas contra ellas.

� Soporta RDF, DAML y OWL y es independiente del lenguaje.

� Los recursos no están ligados estáticamente a una clase java particular.

� Los modelos son un conjunto de staments y se pueden realizar las siguientes operaciones

sobre estos: Unión, intersección, diferencia.

52

http://www.geocities.com/recuperacioninformacionorganiza/SeRQL.html 53

http://jena.sourceforge.net/ 54

http://es.wikipedia.org/wiki/PostgreSQL


69

� El API de ontologías de Jena soporta RDF Schema, DAML, OWL. Es independiente del

lenguaje y los recursos no están ligados estáticamente a una clase java en particular.

� Para hacer inferencias debemos crear un modelo inferido a partir de un razonador y a partir

de ahí, todas las consultas que se le hagan al modelo inferido devolverán información

inferida.

Contiene varios componentes como:

� ARP: un parser de RDF.

� API RDF.

� API de Ontologías para OWL, DAML y RDF Schema.

� Subsistema de razonamiento.

� Soporte para persistencia.

� RDQL: Lenguaje de consultas de RDF.

API RDF de Jena

Permite crear y manipular modelos RDF desde una aplicación Java y proporciona clases java

para representar: Modelos, recursos, propiedades, literales, statements. Con el validador OWL

existe la posibilidad de realizar una validación básica de OWL. Esta validación sólo comprueba la

sintaxis, no infiere ni razona. Para validaciones más complejas existe Jena 2, que ofrece soporte

para inferencias y detecta la violación de las restricciones definidas en el RDF Shema por las

instancias.

TWINE

Twine55 es la primera red social de la Web Semántica que permite organizar, compartir y

descubrir información de interés para los usuarios, la misma que está basada en RDF y OWL, lo

55

http://www.twine.com/


70

que le permite encontrar información relevante y significativa para el usuario final. Para

aprovechar al máximo las tecnologías semánticas es necesario utilizar twines para interactuar

con otros usuarios, porque ayudan a conectar con grupos y personas para hacer crecer el

conocimiento sobre el tema de interés.

Los twines son los ovillos de información que tienen como núcleo los intereses del usuario y

alrededor de los cuales se van tejiendo los hilos de contenido relacionados con ellos. En los

ovillos pueden ser públicos o privados, contienen documentos, vídeos, fotos, marcadores,

mensajes, recomendaciones de otros usuarios. No se trata de multiplicar el contenido sin más,

sino más bien de descartar lo irrelevante y seleccionar lo fundamental, y eso es lo que en

principio es capaz de hacer la web semántica. Es fácil crear información, pero es difícil reducirla.

[36]

Nova Spivack máximo responsable de Twine en un artículo “Twine teje la primera Web Social

de la Web Semántica”56 explica sobre la utilidad de la Web Semántica y dice que ésta “no es un

fin en sí mismo sino un medio enfocado a un fin. Lo que debemos tener claro al usar Twine es el

"para qué" lo estamos haciendo”. No se trata de multiplicar el contenido porque nosotros

queremos sino más bien de descartar lo irrelevante y seleccionar lo fundamental, y de eso se

encarga la Web Semántica, porque es fácil crear información, pero es difícil reducirla. Algunas

funcionalidades de esta herramienta son:

� Colección de información estructurada o desestructurada sobre conceptos.

� La búsqueda dentro de Twine posee capacidades semánticas.

� Utiliza ocho conceptos clave: sujeto, objeto, predicado, fecha, confianza, valor,

procedencia, y otros datos estadísticos sobre el tema en sí mismo.

� Pueden hacerse inferencias de predicado a través de cuentas, control de acceso.

� Genera automáticamente conocimiento en la Web.

56

http://www.tendencias21.net/Twine-teje-la-primera-red-social-de-la-web-semantica_a2663.html


71

� Entiende Tags y Links de forma automática.

� Busca y organiza la información de forma automática en la Web.

� Proporciona búsquedas semánticas, descubrimientos o registros de interés del usuario.

� Ayuda a conectar con grupos o personas para hacer crecer el conocimiento sobre

temas de interés.

CORESE

CORESE (Conceptual Resourse Serah Engine): Es una herramienta de desarrollo Web que

consiste en un motor RDF basado en Grafos Conceptuales (GC). La principal funcionalidad de

CORESE es recuperar recursos Web anotados mediante RDF Schema mediante el uso de un

lenguaje de consulta basado en SPARQL y un motor de reglas de inferencia. Se ha introducido la

función XPath para evaluar las expresiones XPath dentro de las preguntas SPARQL, esto

permite extraer la información externa de documentos XML. [37]

KOWARI

Kowari57 es una herramienta de Web Semántica de almacenamiento y recuperación de

ontologías; la misma que consiste en una base de datos escalable y transaccional construida

con el objetivo de almacenar, recuperar y analizar metadatos. Esta herramienta escrita en Java

y de código abierto soporta RDF y OWL. Entre las características más importantes de la

herramienta son:

� Soporte para RDF.

� Soporta diversos modelos de Bases de Datos.

� Lenguaje de consulta SQL

57

http://kowari.org/


72

2.5 LÓGICAS DE DESCRIPCIÓN

2.5.1 FUNDAMENTOS

Siguiendo la línea de la Arquitectura de la Web Semántica tenemos la Lógica de Descripción

que a través de lenguajes conceptos nos ayudan a representar mejor un dominio del

conocimiento haciendo uso de inferencias para la construcción de las ontologías. Es así que

tenemos que las Lógicas Descriptivas o Lógicas de Descripción surgieron en la década de los

ochenta cuyo objetivo inicial de estos lenguajes es dar una semántica formal a los frames y las

redes semánticas. Están conformadas por una familia de formalismos que están bien

determinados y permiten expresar conocimiento estructurado por medio de expresiones de

conceptos y roles.

Dentro de la lógica de descripción se habla de los lenguajes de conceptos que permiten

representar el conocimiento de un dominio por medio de conceptos y roles, así como las

relaciones que existen entre éstos. Las lógicas de descripción en la actualidad se han convertido

en la base fundamental de la Web Semántica para su uso en el diseño de ontologías y se la

considera como una evolución de las redes semánticas y los frames.

La lógica de descripción tiene características muy importantes como los siguientes formalismos:

[38]

� Descriptivo: Conceptos, roles, individuos y constructores.

� Terminológico: Axiomas terminológicos que introducen descripciones complejas y

propiedades de la terminología descriptiva.

� Asertivo: Introduce propiedades de individuos.

� Tienen algoritmos de razonamiento decidibles para inferir nuevo conocimiento a partir de

conocimiento dado.


73

Los elementos que intervienen en la lógica descriptiva son los siguientes:

� Objetos: Los individuos son instancias de los conceptos y se relacionan por medio de un rol.

� Conceptos (clases): Son conjuntos de objetos que asignan un nombre a un grupo de

objetos. Ejm. Padre, madre, persona.

� Propiedades o Roles(relaciones): Son usados para especificar propiedades o atributos de

objetos, es decir asigna un nombre a una relación entre objetos, Ejm. TieneHijo,

EsPadreDe.

� Tipos de datos: Elementos de dominio a los cuales pertenecen los objetos, es opcional.

� Constructores: Relaciona nombres de conceptos y de roles y además crea conceptos

complejos a partir de los atómicos (complex concepts).

� Definiciones de conceptos complejos: Usa los símbolos para declarar conjunto de

igualdades y conjuntos de inclusiones.

2.6 ONTOLOGÍAS COMO HERRAMIENTA PARA LA DESCRIPCIÓN

Dentro de la Arquitectura de la Web Semántica un pilar fundamental son las Ontologías que

ayudan a representar el conocimiento. Las ontologías fueron desarrolladas en el área de

Inteligencia Artificial (IA) para facilitar el intercambio y reuso del conocimiento.

Las ontologías58 según Tom Gruber se crearon con la finalidad de representar de manera

formal y consensuada especificaciones de conceptos que proveen un conocimiento compartido

y común del dominio, como información semántica procesable por las máquinas e

interoperable a través de agentes (organizaciones, individuos y software). Estas proveen una

comprensión compartida y consensuada del conocimiento de un dominio que puede ser

comunicada entre personas y sistemas heterogéneos.

58

http://en.wikipedia.org/wiki/Ontology_(computer_science)


74

Las ontologías y los XML Schema sirven para propósitos diferentes. Las ontologías están

orientadas a especificar teorías de dominio, y los XML Schema para proporcionar restricciones

de integridad para orígenes de información que proviene de documentos y datos

semiestructurados.

2.6.1 COMPONENTES DE UNA ONTOLOGÍA

Los componentes principales de una ontología según Gruber Tom. R. [39] que servirán para

representar el conocimiento en algún dominio son los siguientes:

� Conceptos: Elementos básicos de las tareas del dominio, que por lo general se organizan en

taxonomías. Los conceptos se consideran como ideas básicas que se intentan formalizar y

pueden ser: métodos, planes, clases de objetos, estrategias.

� Instancias: Son elementos específicos de los conceptos que contienen elementos o datos

que describen un concepto y se utilizan para representar objetos determinados de un

concepto.

� Relaciones: Expresan la interacción y enlace entre los conceptos del dominio. Es decir las

relaciones que establecen el tipo de interacción semántica entre los conceptos. Por

ejemplo: subclase-de, parte-de, conectado-a.

� Funciones: Métodos que pueden ser invocados en la instancia específica de un concepto,

donde se identifica un elemento mediante el cálculo de una función que considera varios

elementos de la ontología. Por ejemplo, funciones como: categorizar-clase, asignar fecha.

� Axiomas: Sentencias del modelo que son siempre ciertas. También se conoce como hechos

o teoremas que se declaran sobre relaciones que deben cumplir los elementos de la

ontología es decir los elementos que permiten hacer inferencias que no están explícitas en

la taxonomía de conceptos. Por ejemplo: “Si A y B son de la clase C, entonces A no es

subclase de B”, “Para todo A que cumpla la condición C1, A es B”,


75

Como conclusión podemos decir que las ontologías forman la base de la Web semántica por ser

capaces de definir teorías sobre dominios compartidos y comunes, además permiten que las

personas y las máquinas se comuniquen eficazmente. También hacen posible el acceso,

interoperabilidad y comunicación de contenidos por la red. Por eso se concluye que para que

la Web Semántica funcione, es indispensable que los ordenadores tengan acceso a conjuntos

estructurados de información y conjuntos de reglas de inferencia que puedan utilizar para

realizar el razonamiento automatizado. Uno de los principales objetivos de las ontologías es

facilitar la comunicación de tal forma que dos entidades diferentes se entiendan entre si y

asegurarse que hablan dentro del mismo contexto.

2.6.2 CLASES DE ONTOLOGÍAS

Para clasificar las ontologías algunos autores lo realizan desde diferentes puntos de vista: Por

ejemplo [Mizoguchi, 1995] [40] las clasifica en función de los problemas que resuelven. En el

nivel superior de su clasificación se consideran cuatro categorías.

� Ontologías de contenido: Están construidas para reutilizar su conocimiento, es decir

permiten reutilizar su vocabulario.

� Ontologías de Indexación: Se utilizan cuando los agentes comparten conocimientos a

través de los casos; las ontologías de indexación nos permiten la recuperación de dichos

casos.

� Ontologías de comunicación: Las utilizan los agentes para generar respuestas a preguntas

concretas, vistas como cajas negras de conocimientos.

� Meta-ontologías: Son usadas para representar ontologías.

Otros autores como [Van Heist, 1997] [41] considera el grado de reutilización de las ontologías,

y en el ámbito de la contextualización las clasifica en las siguientes:

� Ontologías de representación: Proporcionan el vocabulario necesario para modelizar otras

ontologías, utilizando determinado modelo de representación del conocimiento.


76

� Ontologías meta-ontología o genérica: Proporcionan términos genéricos como: Estado,

Evento, Acción, Componente; que son reutilizables en diferentes dominios.

� Ontologías de dominio: Son encargadas de expresar conceptos específicos de un

determinado dominio. Por lo general son definidos como especializaciones de conceptos

existentes en ontologías genéricas.

� Ontologías de aplicación: Expresan conceptualizaciones específicas para dominios

particulares; es decir, son especificaciones concretas del dominio que se necesita para

realizar una tarea particular en ese dominio determinado.

El lenguaje de marcado OWL, es la recomendación del W3C como metalenguaje descriptivo de

ontologías, a continuación se analiza dicho estándar.

2.6.3 OWL: Web Ontology Language

Dentro del dominio de Web Semántica existen algunos lenguajes que hacen posible la

representación de una área del conocimiento y uno de ellos es OWL, cuyo lenguaje fue

desarrollado por el W3C Ontology Working Group (WebOnt) para publicar y compartir

ontologías en la Web. El OWL se deriva de DAML+OIL y al igual que este lenguaje, es una

extensión de RDFS. OWL ofrece la posibilidad de escribir ontologías, se diferencia

principalmente de RDF y RDFS en que éstos son lenguajes para definir grafos, mientras que

OWL es un lenguaje que nace específicamente para la creación de ontologías.

OWL se lo conoce también como lenguaje de Ontologías Web; una ontología se encarga de

definir 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 .También incluyen definiciones de conceptos básicos del

dominio, y las relaciones entre ellos, que son útiles para los ordenadores. Además OWL

permite definir una ontología en términos de XML para ser utilizada en la Servicios Web


77

En OWL se definen las clases propiedades e individuos. A las propiedades definidaes en RDFS

(subclase, subpropiedad, dominio, rango), se añaden otras (inverse-of) que significa relación

inversa entre propiedades, un conjunto de axiomas para definir restricciones, cardinalidades de

propiedades de instancia de clase (cardinality), enumeraciones de instancia de clase (uno-de,

one-of) y combinaciones de clase (uniones, interseciones, complementos). [42]

A manera de conclusión se dice que OWL es el lenguaje que posee un mecanismo para

desarrollar vocabularios específicos que asociando los recursos proporciona un lenguaje para

definir ontologías estructuradas que pueden ser utilizadas a través de diferentes sistemas. Y las

ontologías se encargan de definir los términos usados para describir y representar una área de

conocimiento que van a ser utilizadas por los usuarios, las bases de datos y las aplicaciones

que necesitan compartir información específica. OWL se subdivide en tres sublenguajes cada

uno incremental respecto al anterior en capacidad expresiva.

OWL Lite: Permite establecer clasificaciones jerárquicas de conceptos de forma similar a RDFS

además de proveer de mecanismos restrictivos básicos con respecto a la naturaleza de

relaciones como el hecho de asignar cardinalidades por ejemplo enunciar el hecho de que una

persona sólo puede tener un padre o una madre biológico(a).

OWL DL: Proporciona una mayor riqueza expresiva con respecto a OWL Lite garantizando la

computabilidad de cualquier conclusión en un tiempo finito. Debe su nombre a la Lógica

Descriptiva (Description Logics), un campo de investigación de reciente actualidad.

OWL Full: Pensado para usuarios que requieran la máxima expresividad dentro de la libertad

sintáctica de RDF prescindiendo de cualquier garantía computacional en lo que respecta a la

extracción de conclusiones.


78

2.6.4 HERRAMIENTAS DE LA WEB SEMANTICA

Dentro de la línea de la Web Semántica, actualmente se han desarrollado variedad de

herramientas y plataformas que proporcionan servicios para crear y procesar elementos

semánticos. Existen diferentes herramientas en el desarrollo de ontologías que se clasifican

según Goméz Pérez A. en: [43]

Desarrollo de Ontologías. Este grupo contiene herramientas y paquetes integrados que pueden

ser utilizados para construir una nueva ontología a partir de cero. Aparte de las

funcionalidades de edición y navegación, estas herramientas incluyen documentación

importación y exportación de ontologías, a, o desde, diferentes formatos, librerías y motores

de inferencia.

Evaluación de Ontologías. Son utilizadas para evaluar aspectos de consistencia, corrección y

redundancia en el contenido de las ontologías; es decir para asegurar la calidad de las mismas

y evitar problemas posteriores.

Combinación e Integración de Ontologías. Son utilizadas para resolver el problema de fusión y

alineamiento o combinación e integración de diferentes ontologías que pertenecen al mismo

dominio.

Herramienta de Anotación basadas en Ontologías. Herramientas en las cuales el usuario

puede insertar instancias de conceptos y de relaciones en ontologías y mantener semi-

automáticamente la anotación o marcas en páginas Web basadas en ontologías. La mayor

parte de estas herramientas están siendo integradas en un entorno de desarrollo de

ontologías.


79

Almacenamiento y Consulta de Ontologías (motores de inferencia). Estas permiten la consulta

de ontologías de manera sencilla y llevan a cabo inferencias con ellas. Para ello surgieron

lenguajes para consulta de ontologías, como: RDQL, SPARQL, SeRQL.

Herramientas de aprendizaje de ontologías. Estas herramientas son usadas para derivar

ontologías a partir de textos en lenguaje natural de forma semi-automática; utilizando para

ello técnicas en el área de aprendizaje automático y de procesamiento de lenguaje natural.

La parte más complicada en la Web Semántica es el diseño de ontologías que equipare todos

los requerimientos. Elegir una correcta ontología es un elemento crítico de implementación

satisfactoria de proyectos de Web semántica. En la tabla 6 se describen brevemente algunos

de éstos estándares de ontologías

Ontologías Descripción

DublinCore59 El estándar metadato DublinCore es un simple pero eficaz conjunto de elementos para describir una amplia gama de recursos de red es decir provee un simple y estandarizado conjunto de convenciones para describir cosas en línea de manera que sean fáciles de encontrar.

SIOC60 Semantically-Interlinked Online Communities Project es una ontología que expresa la información contenida explicita e implícitamente en discusión de métodos en Internet, como blogs, foros o listas de correo.

FOAF61 The Friend of a Friend ontology (Amigo de un amigo) describe individualmente sus actividades y sus relaciones con otra gente y objetos. FOAF permite la descripción de redes sociales en una distribución de moda.

DOAP62 Description Of A Project (Descripción de un proyecto) es una ontología para describir proyectos open source.

ResumeRDF63

Esta ontología expresa un resumen o currículum vitae (CV) incluyendo información del trabajo, experiencia académica o habilidades.

Tabla 6. Estándares de Ontologías para Web Semántica

59

http://dublincore.org/ 60

http://sioc-project.org/ 61

http://www.foaf-project.org/ 62

http://www.wshoy.sidar.org/index.php?2004/10/13/15-doap-descripcion-de-un-proyecto 63

http://rdfs.org/resume-rdf/


80

En el dominio de Web Semántica existen algunas herramientas software que actualmente

están siendo más extendidas dentro de la clasificación por categoría que se ha mencionado.

Entre las aplicaciones relacionadas con Web Semántica están: PROTÉGÉ, SWOOP, WebODE,

WebONTO, SWeDE. A continuación se describe brevemente cada uno de ellas.

HERRAMIENTA PROTÉGÉ

Protégé64, es una herramienta para el desarrollo de ontologías y sistemas basados en el

conocimiento creada en la Universidad de Stanford. Está desarrollada en JAVA y funciona bajo

la plataforma de Windows. Las aplicaciones desarrolladas con Protégé son usadas en

resolución de problemas y toma de decisiones en dominios particulares. Esta herramienta

emplea una interfaz de usuario que facilita la creación de una estructura de frames con clases,

slots e instancias de una forma integrada. Es una aplicación autónoma con arquitectura

extensible. El núcleo de este entorno es el editor y la herramienta tiene una biblioteca de

extensiones que le da más funcionalidad al entorno de Protégé.

Protégé es un programa informático de tipo Open Source cuya función consiste en la creación,

edición y mantenimiento de ontologías. Permite generar de manera automática el código

fuente de cualquier ontología creada con Protégé en formato RDF/OWL. Este editor de

ontologías de código abierto es útil para construir ontologías sobre RDFS, OWL y XML Schema,

es uno de los editores más utilizados. [44]

Protégé es un marco de trabajo sobre ontologías que utiliza un sistema de plantillas fácil de

usar, donde a partir de las ontologías generadas se crean formularios para llenar los diferentes

campos. Tiene capacidades gráficas que facilitan la edición de ontologías. Protégé incluye dos

tipos de razonadores (clasificadores): FACT y Pellet65.

64

http://protege.stanford.edu/ 65

http://es.wikipedia.org/wiki/L%C3%B3gica_descriptiva


81

SWOOP

SWOOP está basado en la arquitectura de plugins, el cual es un editor de ontologías donde se

destacan: su capacidad para resolver consultas SPARQL y su capacidad por justificar las

inferencias realizadas por su razonador (Pellet), también detecta inconsistencias en ontologías

OWL utilizando el mismo razonador y da soporte a la evolución de ontologías.

Es un editor de ontologías que está inspirado en hipermedia que utiliza la filosofía de uso y

diseño de navegadores Web. Tiene búsqueda semántica; posee complementos para diferentes

presentaciones de sintaxis OWL (Sintáxis abstracta, turtle, RDF/XML, validación), no usa

plantillas. Las vistas que tiene y la navegación de la herramienta son muy buenas, además

cuenta con un tipo de barra de navegación con vistas llamadas formato conciso, que permite

ver los comentarios y definiciones de las aserciones, sintaxis abstracta junto con RDF/XML. [45]

WebODE

WebODE es el equivalente de Web de ODE (Ontology Desing Environment), es una herramienta

útil para modelar el conocimiento usando ontologías. Es una herramienta desarrollada por la

Universidad Politécnica de Madrid y fue la primera herramienta construida con un modelo de

conocimientos independiente del lenguaje en el que se implementan las ontologías. Tiene una

arquitectura extensible y flexible que proporciona traductores a numerosos lenguajes de

implementación de ontologías. Asimismo, tiene tecnología asociada como ODESeW66, que

permite desplegar portales Web basados en ontologías. WebODE tiene algunas de las

características, las más relevantes son las siguientes: [46]

� Soporte para múltiples usuarios e interoperabilidad XML.

� Conceptualización guiada en interfaz y personalizable mediante planillas

� Chequeo completo de la consistencia.

66

http://webode.dia.fi.upm.es/sew/


82

� Edición de taxonomías mediante interfaces basados en formularios y editores gráficos.

� API de acceso a las ontologías desde cualquier aplicación usando RMI o CORBA67.

WebONTO

WebOnto fue diseñado para facilitar la navegación, edición y creación cooperativa de las

ontologías representadas en OCML68 sin sufrir problemas de interfaz asociados con el estándar

del editor básico de HTML. Tiene soporte limitado para manipulación directa de interfaces,

inhabilitado para ocuparse de la comunicación asíncrona (por ejemplo, incapacidad para

enviar sugerencias que le recuerdan al usuario que guarde los datos). Las características

principales de WebOnto son las siguientes: [47]

� Gestión gráfica de ontologías

� Generación automática de instancias a partir de definiciones de clases.

� Inspección de elementos, teniendo en cuenta la herencia de propiedades.

� Chequeo de consistencia.

SWeDE

SWeDE son las siglas de Semantic Web Development Environment. Requiere un plugin para

eclipse 3.1 el cual es un editor para documentos RDF que provee ciertas facilidades como

autocompletar y subrayado de sintaxis en distintos colores lo cual favorece la edición de

documentos facilitando la detección de errores. Tiene un panel que permite navegar fácilmente

el documento sobre el cual se está trabajando y también tiene otra vista diferente a la de

RDF/XML que es la vista de edición que permite ver las clases y las propiedades existentes en el

documento. No tiene búsquedas sobre los documentos y no usa ningún tipo de plantillas.

Utilizan una librería llamada Kasuki, la cual genera clases de Java a partir de las clases

67

http://www.corba.org/ 68

http://technologies.kmi.open.ac.uk/ocml/


83

contenidas en el documento. [48]. En la tabla 7 se describe un resumen de algunas

características técnicas y funcionalidades de éstas herramientas.

PROTÉGÉ SWOOP WebODE WeBONTO SWeDE

Plataforma Independiente Independiente Acceso Web Applet de Java Independiente

Lenguaje Desarrollo

Java Java Java, CORBA, RMI, Minerva

Java Java

Desarrollador SMI(Stanford University)

MIND Lab at University Maryland

Ontologic Group de la UPM

KMI(Open University)

Production/Stable

Versión 3.2.1 2.2.2 2.0.9 2.3 2.0.2

Fecha 2007 18/01/2007 01/11/2003 05/2001 09/05/2005

Licencia Freeware GNU/GPL Acceso gratuito y bajo licencia

Acceso gratuito

BSD licence Mozila Public License

Categoría Desarrollo Desarrollo Desarrollo Desarrollo Desarrollo

Funcionalidades

Los plug-ins están disponibles para importar y/o exportar lenguajes de implementación de ontologías FLogic, Jess, XML, Se le pueden añadir módulos y plugins con otras funcionalidades.

Realiza consultas RDQL. Actúa como un navegador y permite navegar entre clases; aprovecha las URIs de los recursos.

Revisa la consistencia de Ontologías. Permite exportar el conocimiento a diferentes lenguajes de especificación (RDFs, OWL,)

Trabajo colaborativo a través de anotaciones y mensajes; Permite la participación de varios usuarios en el desarrollo de la ontología.

Usa interfaz gráfica. Realiza búsquedas de cadenas de caracteres puntuales. Funciona como navegador y es fácil de utilizar.

Lenguajes de Ontologías

XML, RDFS, OWL, CLIPS69, N-TRIPLES70, N371, TURTLE72

XML, RDFS, OWL, Sintáxis Abstracta, TURTLE

XML, RDFS, OWL, DAML+OIL73 F-logic

RDFS, OCML74,OIL, Ontolingua75

RDF, OWL

Tabla 7. Comparación de herramientas de Ontologías

69

http://es.wikipedia.org/wiki/CLIPS 70 http://www.w3.org/2001/sw/RDFCore/ntriples/ 71

http://www.w3.org/DesignIssues/Notation3 72

http://en.wikipedia.org/wiki/Turtle 73

http://www.daml.org/ 74

http://technologies.kmi.open.ac.uk/ocml/ 75

http://www.alfonsojimenez.com/tag/ontolingua

CAPÍTULO III

SERVICIOS WEB EN LA WEB SEMÁNTICA


84

CAPÍTULO III

SERVICIOS WEB EN LA WEB SEMÁNTICA

3.1 INTRODUCCIÓN

Los Servicios Web Semánticos son una tecnología nueva, que resulta al unirse la Web

Semántica y los Servicios Web con la finalidad de resolver los limitantes de los Servicios Web y

asimilar los conceptos surgidos en la Web Semántica cuyo objetivo es la de aprovechar las

ventajas y restringir las limitaciones en el uso de las dos tecnología de forma individual.

Los estándares de los Servicios Web apoyados en el XML tales como el SOAP, WSDL, UDDI

presentan limitaciones de semánticas explícitas cuando se tiene dos descripciones XML

idénticas puedan significar cosas totalmente distintas, dependiendo del contexto en el cual son

utilizadas. Además no permiten la automatización de ciertos procesos como: descubrimiento,

composición, selección, ejecución y monitorización. Esto limita la capacidad de identificar los

servicios más adecuados para un determinado proceso. Esta necesidad de los Servicios Web ha

llevado a considerar la integración de la semántica con ellos, para ofrecer un mejor servicio

ésta unión es lo que actualmente se conoce como Servicios Web Semánticos, cuya descripción

externa está en un lenguaje que tiene semánticas bien definidas, interpretables por los

ordenadores, estos lenguajes son: OWL-S, WSMO, WSDL-S entre otros.

Para dar solución a las limitaciones de los Servicios Web y de Web la Semántica surgieron los

Servicios Web Semánticos, la idea consiste en describir la funcionalidad de los Servicios Web

tradicionales de forma semántica, de manera que el descubrimiento, selección, composición e

invocación de los mismos puedan ser realizados automáticamente por medio del uso de

agentes inteligentes capaces de procesar la información semántica disponible.


85

Actualmente para el desarrollo de esta tecnología se basan en la descripción semántica de los

Servicios Web. En el presente capítulo se describen las arquitecturas y estándares que

actualmente se están utilizando, los mismos que son: OWL-S WSMO, WSDL-S, SAWSDL, SWSF.

Luego se realiza una comparación de lenguajes tomando en consideración algunas

propiedades de cada uno de ellos.

3.2 ARQUITECTURA DE SERVICIOS WEB SEMÁNTICOS

3.2.1 CONCEPTOS Y EVOLUCIÓN HISTÓRICA

Los Servicios Web Semánticos se pueden definir como una aplicación conjunta de conceptos

de Servicios Web y de Web Semántica para crear Servicios Web Inteligentes. Esta tecnología es

el nuevo paso en la Web, que consiste en describir a los Servicios Web con contenido

Semántico de tal forma que el descubrimiento de Servicios, su composición e invocación se

puedan realizar de forma automática por parte de entidades de software (agentes inteligentes)

capaces de procesar la información semántica disponible.

Las tecnologías actuales de Servicios Web (SOAP, WSDL y UDDI) operan en un nivel sintáctico,

de ahí nace la necesidad que sean personas quienes busquen Servicios Web apropiados para

utilizar en una aplicación, los combinen de tal forma que satisfagan los objetivos de la misma.

El objetivo de los Servicios Web Semánticos es superar esta dependencia en las personas,

proporcionando medios automáticos o semiautomáticos para descubrir, seleccionar y

componer servicios Web para una aplicación, y dando también soporte a la mediación,

ejecución y monitorización.

De acuerdo a D. Fensel, y H. Lausen “Los Servicios Web Semánticos (SWS) se centran en

describir semánticamente las capacidades funcionales de los servicios y la utilización de

un lenguaje formal procesable por las máquinas, permitiendo la localización,

combinación y el uso de los servicios automáticamente”. [49]


86

Con la semántica los Servicios Web incrementaron su dinamismo aspecto en el cual tienen

limitaciones. Por ejemplo, la composición dinámica de servicios, o el propio descubrimiento de

los mismos, siempre han sido problemas difíciles para los Servicios Web tradicionales y han

requerido de la intervención de humanos.

El objetivo de los Servicios Web semánticos pretende automatizar todo lo que era semi-

automático en los Servicios Web tradicionales, esencialmente el descubrimiento, composición,

invocación e interoperación de Servicios Web. La evolución de la Web se puede distinguir en la

Fig.6. , donde se indica las tecnologías aplicadas en relación a la expresividad a nivel sintáctico,

y a la capacidad de integración a nivel dinámico; indicando las tecnologías aplicadas en las

distintas etapas de evolución de la Web.

Fig. 6 Evolución de la Web: tecnologías participantes en los SWS [ Adaptado de Fensel y Bussler, 2002]

En el 2001 se hizo la primera propuesta de DAML_S76 como una ontología que permitía la

descripción semántica de los servicios. Esta ontología estaba desarrollada en el Lenguaje DAML-

OIL y con la evolución de este lenguaje al Lenguaje OWL, esta especificación se convirtió en lo

hoy se conoce como OWL-S. En el 2005 se propuso SWSF77 que propone la utilización de un

conjunto de ontologías para describir servicios que están en OWL-S y también propone un

conjunto de lenguaje para realizar dicha descripción.

76

http://www.sigmod.org/record/issues/0212/SPECIAL/4.Bussler1.pdf 77

http://www.w3.org/Submission/SWSF/


87

Al mismo tiempo Fensel y Bussler proponen WSMF78 (Web Service Modelling Framework) un

enfoque para la descripción de servicios. Este lenguaje fue la base para la creación de WSMO

que no solo consiste en un conjunto de ontologías para la descripción de servicios, sino

también en un conjunto de lenguajes para realizar esta descripción y permitir la creación de

mediadores entre servicios, objetivos y ontologías.

Finalmente la tercera propuesta por IBM denominada WSDL-S en el 2005, esta aproximación

propone el uso de las opciones de extensibilidad de WSDL para la descripción de servicios

Web. Dicha aproximación ha dado lugar en cierta forma a la creación del grupo de trabajo de

anotación semántica de WSDL y XML Schema que ha propuesto SAWSDL que pasó a ser una

recomedación candidata del W3C en enero del 2007.

En la infraestructura de un Servicio Web Semántico, se identifican tres dimensiones:

Actividades, Arquitectura y Ontología de Servicio como lo indica la fig.7.

78

http://www.wsmo.org/papers/publications/wsmf.paper.pdf


88

Fig. 7 Dimensiones de SWS [Adaptado de Christoph, B., Fensel, D., Maedche, A [50]]

Las principales actividades de uso que los Servicios Web Semánticos deben soportar son las

siguientes:

� Publicación de servicios en un registro semántico.

� Descubrimiento automático del servicio relacionado a la petición del servicio y a la

respectiva descripción semántica publicada del servicio.

� Selección de servicios cuando existan varios para que no se produzca conflictos entre los

mismos.

� Composición: Un framework de SWS debe permitir la coreografía de servicios, para que los

resultados de varios servicios se puedan componer y de ésta forma obtener

funcionalidades de alto nivel. Se puede emplear BELP4WS como lenguaje de descripción

de procesos que es utilizado para la composición de servicios.

� Invocación del SWS: validación de los parámetros de entrada contra la ontología del

servicio y ejecución del servicio.


89

� “Despliegue”

� “Gestión de las ontologías”

La arquitectura de los Servicios Web Semánticos define también los componentes

indispensables para cumplir las actividades de uso antes descritas. Estos componentes son:

� “Un Registro que ofrezca los mecanismos necesarios para publicar y localizar los SWS”

� “Un Razonador” para las consultas e interpretación de la descripción semántica de los

servicios.

� “Matchmaker”: Mediador entre el registro y el cliente del servicio en los procesos de

descubrimiento y selección de servicios.

� “Decomposer”: Se encarga de ejecutar la composición de servicios”. Para la

descomposición se ayuda de la colaboración de varios servicios partiendo de la semántica

de la petición realizada trata de descomponerla para obtener el resultado más óptimo.

� “Invocador”: Mediador entre el cliente del servicio y el proveedor, o entre el

descompositor y el proveedor cuando se invoca un servicio.

Una ontología del servicio representa las capacidades del servicio y las restricciones de uso e

integran la semántica del servicio con su descripción. La ontología consta de los siguientes

elementos:

� “Información funcional del servicio”: Entradas, Salidas, Precondiciones, Postcondiciones.

� “Información no funcional”: Categoría, Costo, Calidad del servicio, tipos de Servicios

Atómicos y Compuestos.


90

3.3 ESTÁNDARES DE LOS SERVICIOS WEB SEMÁNTICOS

En la Línea de Servicios Web Semánticos existen estándares ya desarrollados como ontologías

para solventar el problema de la integración de Servicios Web con la Web Semántica. En este

apartado analizaremos los estándares: WSMO, OWL_S, WSDL_S, SAWSDL, SWSF

3.3.1 WSMO

3.3.1.1 CONCEPTO Y ESTRUCTURA

WSMO (Web Service Modeling Ontology) se define como una Ontología para describir aspectos

relacionados con los Servicios Web Semánticos. Sin embargo, WSMO no es exactamente una

ontología, sino un modelo conceptual que define la sintaxis y la semántica que tendrán los

elementos que describen un Servicio Web Semántico. [51]

Este lenguaje fue creado por el Web Semantic Modeling Ontology Group, que toma como

base WSMF (Web Service Modeling Framework)79, del cual obtiene cuatro conceptos básicos:

� Las ontologías que definen la terminología usada por los demás elementos.

� Las metas para expresar los problemas a los que puede hacer frente un servicio Web.

� La descripción de varios aspectos de un servicio Web.

� Los mediadores que resuelvan los problemas de incompatibilidades que se encuentren.

WSMO proporciona un marco completo para la especificación construcción y ejecución de

Servicios Web Semánticos; pero va más allá de proporcionar una ontología para Servicios Web,

está basado en F-logic y no es una capa sobre RDF u OWL.

79

http://www.wsmo.org/papers/publications/wsmf.paper.pdf


91

La estructura del proyecto WSMO está formado por 3 líneas:

� WSML: 80 Definición del lenguaje con f-Logic.

� WSMO: Ontología propuesta para WSML.

� WSMX81: Entorno de ejecución.

3.3.1.2 PRINCIPIOS DE DISEÑO

WSMO ha sido diseñado en base a los siguientes principios:

� Conformidad con la Web: Este lenguaje hereda el concepto de URI (identificador único de

recursos) y mantiene el concepto de espacio de nombres como espacio de información

(Namespaces).

� Consistente y soporta XML y otras tecnologías estandarizadas por el W3C.

� La descripción de los servicios y los datos que se intercambian están basados en ontologías.

� Desacoplado: Cada recurso será independiente; no se debe considerar un posterior uso o

interacción con otros recursos.

� Mediación centralizada: está focalizada al manejo de la heterogeneidad de los datos, las

ontologías, los protocolos y los procesos.

� Separación de las relaciones ontológicas: Guarda diferencia entre los deseos de los usuarios

y los servicios disponibles.

� Descripción frente a implementación: Hace la diferencia respectiva entre la descripción de

un Servicio Web y su tecnología, por eso presenta un modelo de descripción ontológica y

se va adaptando a las tecnologías.

� Ejecución semántica: Tiene el lenguaje WSMX82 que se encarga de verificar la semántica.

80

http://www.wsmo.org/wsml/ 81

http://www.wsmx.org/ 82

http://www.wsmx.org/


92

3.3.1.3 ELEMENTOS DE WSMO

La ontología desarrollada como WSMO está basado en el modelo Conceptual WSFM

propuesto por Fensel & Bussler (2002) para la descripción de Servicios Web Semánticos se

compone de cuatro elementos fundamentales que son: Ontologías, Objetivos, Servicios Web,

Mediadores.

Fig. 8 Elementos de WSMO [Adaptado de Fensel y Busler83

]

Ontologías

Uno de los elementos de WSMO son las ontologías que proporcionan la terminología

empleada por el Servicio, es decir la especificación formal de la información usada por todos

los componentes. Permite la definición de las funciones y reglas sin necesidad de extender el

lenguaje.

El modelo de Ontologías establece que éstas puedan tener, además de sus propiedades no

funcionales, conceptos, relaciones, funciones e instancias de elementos, junto con la

importación de otras ontologías, y de un tipo de mediadores, llamado “ooMediators”, que

permite resolver conflictos entre ontologías. Se pretende que se puedan utilizar ontologías

83

http://www.w3.org/Submission/WSMO/


93

descritas en diferentes lenguajes, siendo los mediadores los responsables en tal caso de realizar

las adaptaciones necesarias.

Objetivos

Los objetivos representan los deseos de los usuarios sobre la funcionalidad requerida o

intensiones que deben ser satisfechas por algún Servicio Web. Cuando los clientes invocan un

Servicio Web éstos describen cual es el problema a resolver. Se expresan en términos de la

ontología.

Servicios Web

La descripción de Servicios Web define los aspectos funcionales y de comportamiento de un

Servicio Web. También se especifica las propiedades no funcionales de los servicios. La

descripción del servicio está formada por sus capacidades (definidas mediante IOPE84) y sus

interfaces que especifican su coreografía (comunicación) y orquestación (usos de otros

servicios).

Mediadores

Describen los elementos encargados de gestionar los problemas de interoperabilidad entre los

elementos anteriores o conectarlos para ofrecer servicios más complejos, permitiendo la

integración de información heterogénea. Los mediadores se utilizan para resolver los

problemas que pueden surgir al trabajar con elementos heterogéneos, de esta forma, los

mediadores desacoplan los distintos elementos en WSMO como si fueran adaptadores entre

piezas de distinto fabricante. Dependiendo de su función existen cuatro tipos de mediadores,

los cuales se describen a continuación:

84

http://www.beautyproductscompared.com/iope-review


94

� “ooMediators”: Se usa cuando se importa una ontología, sirven para alinear dos ontologías

de forma que puedan trabajar juntas, resuelve todas las incompatibilidades que puedan

surgir entre ambas.

� “ggMediators”: Son los encargados de enlazar dos objetivos distintos, de forma que uno se

describa en función de otro. La conexión representa el refinamiento del objetivo destino o

establece una equivalencia si ambos objetivos son intercambiables. Estos mediadores

pueden hacer uso de los ooMediators cuando tengan incompatibilidades entre la

terminología que manejan los objetivos que relacionan.

� “wwMediators”: Define la interoperabilidad entre Servicios Web, se encargan de alinear

unas descripciones de servicio con otras, es decir, son mediadores que conectan dos

Servicios Web y para ello pueden necesitar hacer uso de los ooMediators. La

intermediación puede ser necesaria en los tres niveles: datos, funciones y procesos.

� “wgMediators”: Mediadores que conectan Servicios Web con Objetivos. Para comprobar la

capacidad de un Servicio Web y satisfacer un objetivo (total o parcialmente) se usa un

wgMediator, que también puede requerir hacer uso de los ooMediator.

3.3.2 OWL-S

OWL-S (Web Ontology Language for Services) es una ontología de Servicios Web basada en

OWL y desarrollada por la rama de Servicios Web Semánticos del programa DAML. Añade un

marcado de metadatos en los proveedores de los Servicios Web, permitiendo la descripción de

las propiedades y funcionalidades de cualquier servicio; mediante OWL-S facilita la

automatización de las tareas incluyendo el descubrimiento de servicios, ejecución,

interoperabilidad, composición y monitorización.

Haciendo un poco de historia OWL-S viene originado por la evolución de DAML-S, desarrollado

por la empresa DARPA y lo que utiliza como metalenguaje para especificar modelos de


95

conceptos; DAML+OIL, lenguaje de marcado a partir del cual ha surgido el OWL que es

empleado como base para el desarrollo de las ontologías de OWL-S.

OWL-S (OWL-S, 2004) hace la distinción entre servicios “atómicos” y servicios “compuestos”.

Los servicios atómicos son aquellos en que un sólo programa accesible por la Web (sensor o

dispositivo) es invocado por un mensaje de solicitud, realiza su tarea y posiblemente produce

una única respuesta a la solicitud. En cambio los servicios compuestos son aquellos que están

compuestos por múltiples servicios primitivos y pueden requerir una interacción extendida y

conversación entre el solicitante y el conjunto de servicios que está siendo utilizado.

OWL-S realiza algunas tareas entre las cuales se mencionan: [52]

� “Descubrimiento automático de Servicio Web”: Consiste en automatizar el proceso de

localización de servicios Web. OWL-S permite anunciar de forma declarativa las

propiedades y capacidades de los servicios marcando los servicios mediante OWL-S, la

información necesaria para su descubrimiento se puede especificar con marcado semántico

interpretable por los ordenadores en los sitios Web de servicios. Se puede usar un registro

de servicios o motor de búsqueda de ontologías para localizar los servicios

automáticamente.

� “Invocación automática de un Servicio Web”: Consiste en realizar la ejecución automática

de un Servicio Web por parte de un programa informático o un agente dada una

descripción declarativa del servicio. OWL-S proporciona una API declarativa interpretable

por máquinas que incluye la semántica de los argumentos que se especifican para ejecutar

las llamadas, y la semántica de los mensajes devueltos cuando el servicio responde.

� “Composición e interoperación automática de Servicios Web”: Esta tarea implica

selección, composición e interoperación automática de diversos Servicios Web para realizar

tareas complejas, dada una descripción de alto nivel de un objetivo. Para ello OWL-S


96

proporciona especificaciones expresivas de los prerrequisitos y las consecuencias de la

aplicación de servicios individuales y un lenguaje par describir composiciones de servicios e

interacciones de flujo de datos.

Dentro del dominio de los estándares de los Servicios Web Semánticos OWL-S es una ontología

que abarca tres tipos de conocimientos esenciales: “Service Profiles” orientado a publicitar

lo que el servicio hace, “Service Model” está enfocado a cómo se usa el servicio y “Service

Grounding”, como se interacciona con el servicio, es decir detalles del protocolo de transporte.

En la Fig. 9 se presenta una ontología de alto nivel de OWL-S para describir un Servicio donde

intervienen los elementos antes descritos.

Fig: 9 Ontología de Alto Nivel de OWL-S [tomada de W3C85

]

3.3.2. 1. Service Profile

Service Profile o perfil de Servicio es el que indica lo que un servicio es capaz de realizar de un

modo apropiado, para que un agente de búsqueda de servicios pueda determinar si un servicio

satisface o no sus necesidades. Esta forma de representación incluye una descripción de la

funcionalidad del servicio, las limitaciones en la aplicación del servicio, la calidad del servicio y

85

http://www.w3.org/Submission/OWL-S/


97

los requisitos del que el solicitante debe satisfacer para hacer uso del servicio

satisfactoriamente.

El perfil de cada servicio en OWL-S contiene los siguientes elementos:

� Información del proveedor del servicio: (nombre del servicio, breve descripción textual,

información de contacto)

� Características del Servicio o propiedades: (categoría del servicio y otros parámetros de

libre disposición).

� Funcionalidad del servicio: Transformación realizada entre los datos de entrada y los datos

de salida, precondiciones y efectos del servicio. Es decir se realiza la descripción IOPE86

que consiste en la descripción en términos de entradas (input), salidas (output),

precondiciones (preconditions) y efectos (efects) del servicio”.

3.3.2.2. Service Model

Service Model o modelo de Servicio indica al cliente cómo utilizar el servicio, detallando el

contenido semántico de las solicitudes, las condiciones bajo las cuales se pueden obtener

determinados resultados y donde sea necesaria la descripción del proceso que hay que seguir

para producir dichos resultados.

En OWL-S existen tres tipos de procesos para modelar un proceso de interacción entre el

cliente y el servicio.

� “Atómico”: No tienen subprocesos y están formados por IOPE (Entradas, Salidas,

Precondiciones, Efectos) que pueden ser ejecutados directamente.

86

http://www.beautyproductscompared.com/iope-review


98

� “Compuesto”: Son los que contienen subprocesos. Tienen asociados una estructura de

control (Secuencia, Condición, Iteración, Repetir –Hasta)

� “Simple”: No pueden ser invocados directamente y son usados como un elemento de

abstracción para procesos atómicos y compuestos por eso se los llama abstracción de

procesos atómicos.

El ServiceModel describe cómo se ha de preguntar a un servicio y qué ocurre cuando un

servicio se lleva a cabo. Cuando un servicio es compuesto la descripción suele ser utilizada por

un agente buscador de servicios de cuatro formas distintas.

� Para realizar un análisis en profundidad para saber si un servicio satisface las

necesidades.

� Para componer las descripciones de múltiples servicios con el fin de realizar una tarea

específica.

� Coordinar las actividades de distintos participantes durante el proceso de ejecución del

servicio.

� Monitorizar la ejecución del servicio.

3.3.2.3 Service Grounding

ServiceGrounding: Este elemento especifica los detalles de cómo un agente puede acceder o

invocar un servicio. Además especifica un protocolo de comunicación, formato de mensajes y

otros detalles del servicio como los números de puerto que pueden utilizarse para contactar

con el servicio. Realiza una descripción de relaciones existentes entre la descripción del proceso

y la descripción real de los elementos para interaccionar con el Servicio.

Como el ServiceGrounding especifica cómo acceder e invocar al servicio, éste realiza una

descripción de las relaciones la descripción del proceso realizado por el servicio y la


99

descripción real de los elementos necesarios para interaccionar con el servicio como los

protocolos de comunicación. Además el ServiceGrounding debe indicar para cada tipo

semántico de entrada o salida especificado en el ServiceModel de un modo no confuso para

intercambiar elementos de datos de ese tipo con el servicio. [53]

3.3.3. WSDL-S

WSDL-S (WSDL-S, 2005), este lenguaje permite definir mecanismos para asociar anotaciones

semánticas con Servicios Web que han sido descritos utilizando WSDL. WSDL-S permite que

modelos semánticos de los dominios relevantes para cada servicio, que son mantenidos fuera

de los documentos WSDL puedan ser referenciados desde un documento WSDL a través de

elementos de extensibilidad propuestos por WSDL-S.

WSDL-S proporciona un mecanismo para anotar el servicio, sus entradas, salidas y operaciones.

Además posee mecanismos para especificar y anotar precondiciones y efectos de los servicios

Web. En la fig. 10 muestra como se asocian las anotaciones semánticas con varios elementos

de un documento WSDL- S, referenciando conceptos semánticos de un modelo semántico del

dominio, que puede estar formado por varias ontologías.

Fig. 10. Anotación semántica de los elementos WSDL-S[Tomada de W3C87

]

87

http://www.w3.org/Submission/WSDL-S/


100

En WSDL 2.0 tiene los siguientes constructores para representar las descripciones de los

servicios: interface (portType), operation, message, bindign, service y endpoint (port). Los tres

primeros tratan la definición abstracta del servicio mientras que los tres restantes tratan la

implementación. [54]

WSDL-S se centra en anotar semánticamente la definición abstracta del servicio, (interface,

operation y service). A continuación se describen brevemente los elementos y atributos de

extensión: modelReference, schemaMapping, precondition y effect, Category.

� ModelReference: Es un atributo de extensión que es usado para especificar la asociación

entre una entidad WSDL y un concepto de un modelo semántico. Este atributo puede

añadirse a un tipo complejo, elemento, operación; así como a los elementos de extensión

“precondition y effect”.

� SchemaMapping: Es un atributo de extensión, añadido a los elementos XSD y a los tipos

complejos, para manejar diferencias estructurales entre elementos del esquema de un

Servicio Web y sus correspondientes conceptos del modelo semántico.

� Precondition y effect: Son elementos situados como descendientes o elementos hijos de

“operation”. Las precondiciones y los efectos son usados principalmente para el

descubrimiento de servicios y no son requeridas necesariamente para invocar a un servicio

dado.

� Category: Es un atributo de extensión del elemento interface, contienen información de

categorización de servicios que podría ser usada al publicar un servicio en un registro de

servicios Web como UDDI.

WSDL-S tiene algunas ventajas respecto a las otras como OWL-S y WSMO, las cuales se

detallan a continuación:

� WSDL-S permanece independiente del lenguaje de representación de ontologías que se

desee utilizar al externalizar los modelos semánticos del dominio. Esto permite a los


101

desarrolladores de Servicios Web anotar sus servicios con el lenguaje ontológico de su

preferencia (UML, OWL, etc). Esto permite reutilizar modelos del dominio expresado con

lenguajes del modelado como UML puede acelerar la incorporación de anotaciones

semánticas.

� Los usuarios pueden describir incrementalmente todos los detalles, tanto semánticos como

de operaciones en WSDL, un lenguaje que es muy conocido por la mayoría de los

desarrolladores.

� Es fácil modificar las herramientas existentes actualmente alrededor de la especificación

WSDL para incorporar los elementos propuestos por esta aproximación.

3.3.4 OTROS ESTÁNDARES

3.3.4.1 SAWSDL

SAWSDL Anotaciones Semánticas para WSDL y XML Schema, es una extensión desarrollada

por un grupo de trabajo del W3C que proviene de WSDL. Las anotaciones semánticas pueden

sumarse a los componentes del Lenguaje de Descripción de Servicios Web (WSDL) para ser

utilizadas en la clasificación, descubrimiento, concordancia, composición e invocación de

servicios Web. SAWSDL no especifica un lenguaje concreto para representar los modelos

semánticos, sino que incorpora un mecanismo por medio de los cuales es posible referenciar

desde documentos WSDL a conceptos de modelos semánticos definidos externamente

utilizando anotaciones.[55]

En WSDL 2.0 se incorporó elementos para representar descripciones de servicios como: “Type

definition”, “Interface”, “Interface Operation”, “Interface Fault”, “Binding”, “Service”,

“Endpoint”. SAWSDL se centra en la anotación semántica de aquellos que ofrecen una

definición abstracta de un servicio estos son: “Type definition”, “Interface”, “Interface


102

Operation”, “Interface Fault”; para permitir el descubrimiento, composición, e invocación

dinámica de servicios.

SAWSDL propone dos constructores básicos para anotación semántica, los mismos que se

describen a continuación:

� “modelReference”: Es un atributo de extensión para especificar la asociación entre un

componente WSDL o XML Schema y un concepto en algún modelo semántico. Es utilizado

para anotar la definición de tipos complejos en XML Schema, definición de tipos simples,

declaraciones de elementos y declaraciones de atributos, además de interfaces,

operaciones y defectos en WSDL.

� “liftingSchemaMapping” y “LoweringSchemaMapping”: Son atributos de extensión que se

añaden a las declaraciones de elementos XML, definiciones de tipos complejos y simples

para especificar correspondencias entre datos semánticos y XML. Estas correspondencias

se usarán posteriormente durante la invocación de servicios Web; solucionándose el

problema de la estructura de las entradas y salidas del servicio.

3.3.4.2 SWSF

SWSF88 (Semantic Web Service Framework) es el framework de Servicios Web Semánticos

surge de la propuesta creada por el Semantic Web Service Language Comitee de la SWSI

(Semantic Web Service Initiative),89 para crear un marco de especificación semántico de

servicios Web. Dicha propuesta está publicada en el W3C como elemento importante en

estudio y en el futuro podrá ser recomendado para describir Servicios Web Semánticos.

88

http://www.daml.org/services/swsf/1.0/ 89

http://www.swsi.org/


103

El marco de trabajo está diseñado para soportar la construcción de herramientas y

metodologías en el entorno de Servicio Web, así como proporcionar el uso de procesos de

razonamiento sobre servicios fundamentados en semántica. Básicamente, SWSF está formado

por un lenguaje de definición de ontologías denominado SWSL (Semantic Web Services

Language) y por una ontología denominada SWSO (Semantic Web Services Ontology)90 definida

en dicho lenguaje, que permite la especificación de Servicios Web Semánticos.

SWSL (SWSF- SWSL, 2005)

Es un lenguaje lógico de propósito general que incluye ciertas características para hacerlo más

apropiado para las necesidades de la Web y los Servicios Web Semánticos; las mismas que son:

incluir el uso de URIs, la integración de los tipos que forman parte de XML y el uso de

mecanismos de importación y espacios de nombres compatibles con XML, se lo utiliza para

especificar las caracterizaciones formales sobre conceptos relacionados con los servicios Web y

sus descripciones. SWSL91 incluye a dos sublenguajes: SWSL-FOL, sublenguaje de lógica de

primer orden usado para definir la especificación formal de la ontología del servicio, y SWSL-

Rules, basado en el paradigma de programación lógica y es utilizado para dar soporte al uso

de la ontología de servicios en procesos de razonamiento.

Los lenguajes basados en reglas están más adaptados a las tareas de la programación y se

apoyan en la información por defecto y en la herencia. En contraste a estos lenguajes se

encuentran los basados en lógica de primer orden, más adecuados para especificar las

ontologías del proceso. Ambos tipos de lenguaje no pueden ser utilizados de manera conjunta,

por ello SWSL actúa como puente entre ellos proporcionando la potencia de ambos. En SWSL,

cada uno de los sublenguajes que los componen está estructurado en varios niveles

independientes entre sí.

90

http://www.daml.org/services/swsf/1.0/swso/ 91

http://www.w3.org/Submission/SWSF-SWSL/


104

SWSO (SWSF- SWSO, 2005)

La ontología SWSO fue creada para especificar Servicios Web Semánticos mediante la

utilización del lenguaje SWSL. Esta ontología está expresada en dos formas: la más

comúnmente utilizada, FLOWS (First-order Logic Ontology for Web Services), la ontología

basada en lógica de primer orden que ofrece el lenguaje SWSL-FOL y ROWS, cuyo fundamento

es el lenguaje SWSL-Rules.

FLOWS; se fundamenta y se extiende sobre WSMO y OWL-S, no proporciona una

representación completa de los servicios, sino un modelo abstracto que es fiel al

comportamiento de los servicios, centrándose en el contenido semántico de los mensajes El

objetivo de FLOWS es describir la semántica subyacente de los Servicios Web y la interacción

entre ellos en el mundo real. Además también proporciona mecanismos para modelar el

funcionamiento interno de un Servicio Web. Flows está dividido en tres partes fundamentales:

Ontologías descriptores del servicio (páginas amarillas, Service Profile), Ontología de modelo de

Procesos (noción estructura de proceso atómico, infraestructura para flujos de datos),

Grounding (relacionar especificaciones abstractas).


105

3.3.5 COMPARACIÓN DE LENGUAJES

WSMO y OWL-S consideran a las ontologías como un elemento fundamental para hacer

realidad la localización, invocación, monitorización y composición automática de servicios Web;

pero a pesar de coincidir en esto, difieren en la forma que establecen para lograr la

consecución de sus objetivos. Mientras OWL-S define un conjunto de ontologías que permiten

la manipulación de servicios, WSMO define un modelo conceptual dentro del cual se deben

crear las ontologías que permitan administrar los servicios Web.

El concepto de mediadores, definido en WSMO se usa para resolver los posibles problemas de

heterogeneidad e interoperabilidad. Los mediadores son elementos especiales cuyo objetivo es

enlazar componentes heterogéneos a través del mapeo adecuado de cada una de sus partes,

las transformaciones necesarias, inferencias o a su vez asociaciones inteligentes. WSMO define

las interfaces de orquestación y coreografía para describir la interacción entre servicios.

En la tabla 8 se muestra cuadro resumen de los principales lenguajes de Servicios Web

Semánticos.


106

PROPIEDADES WSMO OWL-S WSDL-S

Tipo de servicio

Atómico(capability) Compuesto(interface)

Atómico(Service profile) Compuesto(Service Model).

Atómico.

Alcance Modelo para descripción y lenguaje para los principales elementos de las tecnologías de servicios web semánticos

Modelo de descripción para describir semánticamente los servicios Web

Anotación semántica de las descripciones WSDL

Elementos de Nivel Superior

Ontología, Objetivos, Servicios Web, Mediadores.

Servicios: Profile, Process Model, Grounding.

Operaciones/descripciones WSDL.

Descripción a nivel de Servicio

Capacidad para proveer y demandar una funcionalidad.

Aspectos no funcionales IOPE para la descripción funcional a nivel de Servicio

Clasificación por palabras claves basada en la ontología.

Descripción a nivel de operación

Interfaces para consumo (coreografía) e interacción (orquestación)

IOPE para procesos Precondiciones y efectos para descripciones WSDL

Lenguaje Estático

WSML OWL WSDL

Integraciones Semánticas

Si Si Si

Soporte para Datos

Si Si Si

Ventajas Manejo de propiedades no funcionales, ontologías importadas, precondiciones, postcondiciones y efectos.

Orientado a descripción, está orientado al comportamiento

Independiente del lenguaje de representación

Desventajas Se apoya en otras dos iniciativas para su representación sintáctica y su ejecución

Dificultad para añadir detalles. Necesita agentes eficientes

Describe la funcionalidad pero no el comportamiento.

Tabla 8. Comparación de Lenguajes de Servicios Web Semánticos


107

3.4 SERVICIOS WEB SEMANTICOS PARA SISTEMAS MULTIAGENTES

La Web Semántica y los Servicios Web Semánticos (SWS) están asociados al concepto de

agente, quien es capaz de sacar provecho de los datos anotados semánticamente en las

ontologías, desde su concepción los SWS se han ligado con los agentes software que son las

entidades capaces de procesar las descripciones semánticas de los servicios; por lo tanto la

tecnología de SWS, el marcado semántico de los servicio Web permite que agentes software

con habilidades adecuadas sean capaces de hacer uso de éstos servicios para satisfacer

objetivos de alto nivel.

Los Servicios Web Semánticos mejoran la capacidad de los agentes software para buscar

servicios personales o particulares y son un importante paso, en la orientación de la

implementación de la Web Semántica. Uno de los principales inconvenientes existentes

actualmente consiste en que en el desarrollo de servicios por diferentes comunidades se

tienden a definir diferentes ontologías para describir tales servicios, por lo que uno de los

principales problemas que surge es la dificultad de conseguir interoperabilidad y la necesidad

de realizar procesos de traducción de ontologías.

Es importante resaltar las tareas que desarrollan los agentes en el proceso de búsqueda de

información que se encuentra anotada semánticamente, pero un agente individual sería capaz

de resolver un problema por sí solo pero esto implicaría: demasiado tiempo, y demasiados

riesgos en cuanto a su fiabilidad al concentrar toda la responsabilidad en un solo agente. De ahí

nace la necesidad de agruparse varios agentes para resolver un problema, ésta agrupación se

la conoce como “Sistemas Multiagente” (SMA), que en la realidad son sistemas basados en

agentes y orientados a la resolución distribuida de problemas. De hecho. Por ello se considera

un estudio de sistemas Multiagente tratado como un sistema de inteligencia artificial en red

donde actúen agentes de manera autónoma en cierto contexto o ambiente y que se

comuniquen a través de ciertos protocolos.

APLICACIONES DE WEB SEMÁNTICA EN

LOS SERVICIOS WEB DE LA UTPL


108

CAPÍTULO IV

APLICACIONES DE LA WEB SEMÁNTICA PARA LOS SERVICIOS WEB DE LA

UTPL

4.1 INTRODUCCIÓN

La integración de sistemas es uno de los grandes retos en la construcción de soluciones

basadas en tecnologías de la información, ésta integración se logra usualmente mediante

soluciones a medida muy costosas para cada par de sistemas. Las tecnologías de Servicios Web

son un conjunto de estándares que permiten definir interfaces de aplicaciones de software

mediante mensajes en formato XML transportados sobre la infraestructura de Internet. Aunque

reducen los costos, los servicios Web en sí mismos no garantizan que dos empresas utilicen las

mismas estructuras de datos o protocolos de negocio, ni proporcionan mecanismos para

resolver posibles problemas.

La falta de descripciones semánticas de los servicios ofrecidos por las organizaciones

obstaculiza la automatización en la localización y uso de los servicios necesarios para llevar a

cabo una actividad de negocio determinada. Los Servicios Web Semánticos (SWS) permiten

definir formalmente los servicios, facilitando su localización y uso automatizados y orientados a

metas.

Actualmente existen variedad de Servicios Web distribuidos por Internet que ofrecen distintas

funcionalidades, éstos servicios ofrecen una gran fuente de información, pero cada Servicio

Web es un elemento aislado del resto, es decir proporcionan la información que tiene

disponible, pero no la relaciona con la información de otros Servicios Web. Para superar estas

limitaciones surge la necesidad de la composición de información de distintos Servicios Web


109

semánticamente relacionados, para obtener una cantidad de información superior a la

proporcionada por separado.

En este capítulo se aborda un análisis de todos los frameworks analizados en el capítulo

anterior, para decidir cuáles de ellos se ajustan a las necesidades de implementación a futuro

de servicios Web semánticos en la UTPL, teniendo como referencia los avances preliminares

que ya se están haciendo en el sitio Web Institucional aplicando herramientas Web 2.0, y de

acuerdo a tecnologías que dan mayor soporte para llevar a cabo la composición de Servicios

Web a nivel semántico.

4.2 TENDENCIAS DE DESARROLLO DE SERVICIOS WEB SEMÁNTICOS

En los capítulos anteriores se ha venido analizando las tecnologías de Servicios Web, Web

Semántica y los diferentes estándares de los Servicios Web Semánticos, entre los cuales están

los siguientes: WSDL-S[54], OWL-S[52], WSMO[51], SAWSDL[55], WSSF92 entre otros, los

mismos que incrementan la potencialidad de los Servicios Web , mediante la asociación de

descripciones semánticas permitiendo que las tareas de búsqueda, descubrimiento,

composición e integración de Servicios Web sean automatizados.

Los Frameworks más importantes son los de OWL-S y WSMO que tienen mayor cantidad de

herramientas creadas y tienen mayor uso actualmente por sus características funcionales que

se acoplan a una descripción efectiva de los Servicios Web Semánticos.

OWL-S describe la semántica de las propiedades funcionales y no funcionales de un servicio,

ésta descripción tiene lugar a través del lenguaje OWL, cuyas capacidades de razonamiento

constituyen la base para el desarrollo de técnicas de correspondencia semántica (semantic

92

http://www.daml.org/services/swsf/1.0/


110

matching) con las que se lleva a cabo el descubrimiento de un servicio y la composición de

coreografías de servicios.

WSMO modela todas las características de un servicio Web y describe semánticamente todos

los elementos que forman parte de la infraestructura necesaria para la publicación, el

descubrimiento, la composición y la invocación de un servicio. En este sentido, WSMO

formaliza los objetivos que tienen los clientes (o usuarios) a la hora de invocar la ejecución de

un servicio, así como los mediadores constituyen un nexo para enlazar todos los componentes

de la infraestructura de servicios.

El modelo propuesto por WSMO contiene todos los puntos clave de una arquitectura para

servicios Web Semánticos y de acuerdo a los principios de diseño SOA, está orientado a la

integración de servicios; incluye un lenguaje de descripción de entidades WSMO llamado

WSML93(Web Services Modeling Language), un entorno de ejecución que implementa el

modelo WSMO llamado WSMX94(Web Services Execution Environment) y un entorno de

desarrollo para su implementación de modelos WSMO llamado WSMT95( The Web Service

Modeling Toolkit).

Para elegir una u otra tecnología se considera algunas diferencias significativas entre las cuales

se tienen:

� OWL-S describe la funcionalidad del servicio (service Profile) pero no separa de lo que un

usuario quiere de la funcionalidad que un servicio puede proporcionar; en cambio WSMO

diferencia entre el Objetivo y descripción de Servicio de Web, lo que significa desacoplar los

puntos de vista del proveedor del servicio y del solicitante.

93

http://www.wsmo.org/wsml/ 94

http://www.wsmx.org/ 95

http://sourceforge.net/projects/wsmt/


111

� WSMO permite indicar propiedades no funcionales en todos y cada uno de los elementos

de la ontología haciendo uso de vocabularios comúnmente aceptados como Dublin Core

(DC) y Friend of a Friend FOAF; mientras que OWL-S solo permite indicar estas propiedades

en la ontología de perfil y no se basa en especificaciones de metadatos estándar.

� WSMO hace una clara distinción entre coreografía y orquestación y permite la definición

de diversos modos de interaccionar con cada servicio en cambio OWL-S no distingue éstos

dos conceptos y la definición de procesos no se basa en un modelo formal.

� Las descripciones WSMO especifican precondiciones, postcondiciones, suposiciones y

efectos de las operaciones de los servicios Web, así como propiedades no funcionales de los

servicios. Un aspecto clave en WSMO es el uso de mediadores para resolver los problemas

de interoperabilidad entre servicios Web en distintos aspectos (terminología utilizada,

patrones de intercambio de mensajes, y relación entre los objetivos de un cliente y las

capacidades que los servicios pueden ofrecer) y lo considera como elemento de primer

nivel en cambio OWL-S es uno de los elementos más criticados.

4.3 ESTRATEGIA PARA CREAR SERVICIOS WEB SEMÁNTICOS PARA LA

UTPL

En diferentes áreas del conocimiento se pueden aplicar los Servicios Web Semánticos, dentro

de las Instituciones como es la UTPL, especialmente el CITTES de Gestión del Conocimiento

está enfocando este estudio con el afán de tener definido un modelo estratégico que pretenda

utilizar la potencia de las tecnologías de Web Semántica para definir las consultas de

información de catálogo96, de recursos educativos y el uso de servicios Web para simplificar y

facilitar el acceso a la funcionalidad de búsqueda semántica, revisión y mantenimiento; que a

corto, mediano o a largo plazo se pueda desarrollar para automatizar las búsquedas de

96

Catálogo: Se refiere a los diferentes documentos científicos creados, libros, memorias de tesis, videos, revistas,


112

información; para ello ya se está aplicando diferentes técnicas, herramientas y tecnologías

Web 2.0 para mejorar los Servicios que ofrece el portal Web Institucional y que a futuro se

puede incluir Servicios Web Semánticos. La estrategia que se propone para la creación de un

SWS es como se describe en la Tabla 9.

Orden Descripción

1 Integrar los procesos Internos en la Web

2 Creación de Ontologías (servicios y recursos)

3 Descripción Semántica de los Servicios Web

4 Publicación y Descubrimiento los Servicios Web Semánticos

5 Selección e Invocación Semántica del Servicio Web

Tabla 9. Estrategia de Desarrollo de un SWS

A continuación se describe cada una de ellas.

1. INTEGRAR LOS PROCESOS INTERNOS EN LA WEB

La Integración de los procesos internos en la Web consiste en crear los “Web Services” con el

objetivo de que la Institución pueda publicar en un repositorio de organizaciones educativas

sus servicios como una “Interfaz” que pueda ser descubierta por otros usuarios. Para ello se

considera integrar las bases de datos que contienen la información necesaria para llevar a cabo

la ejecución de un Servicio Web; donde se considera aplicar las tecnologías de SOAP como

protocolo de comunicación para el intercambio de datos XML en la Web, y WSDL para la

descripción formal de los Web Services, y UDDI para la publicación de éstos Servicios.

Se debería estructurar las publicaciones científicas, documentos, a través lenguajes de

marcado específicos (RDF) para publicarlos en la Web para que éstos puedan ser accedidos por

un buscador semántico que permita extraer su información fácilmente.


113

2. CREACIÓN DE ONTOLOGÍAS

Una vez creados los Web Services (préstamo, reservación de libros), éstos se gestionan a nivel

estático, pero a medida que se va avanzando se proyecta la creación de ontologías que son la

base tecnológica para la interoperabilidad semántica, para describir explicita y formalmente los

conceptos y recursos de dominio para compartir información y reutilizar conocimiento, donde

se describen los recursos y servicios de tal forma que puedan ser localizados eficientemente.

Existen varias metodologías para crear una ontología una de ellas es la propuesta por Natalya

Noy y Deborah McGuiness en el documento “Desarrollo de Ontologías 101: Guía para crear la

primera Ontología”[58] Su enfoque básicamente consiste en abordar de forma sencilla los

puntos importantes que deben se deben considerar y sugerir un procedimiento para

desarrollar la ontología. En la Tabla 10 se describe brevemente los pasos con algunas

características:

PASOS DESCRIPCIÓN

1 Determinar el dominio y el alcance de la ontología

Identificar el dominio que cubrirá la ontología. ¿Para qué se va utilizar la ontología? ¿Qué tipos de preguntas debería responder la ontología? ¿Quién utilizará y mantendrá la ontología?

2 Considerar la reutilización de ontologías existentes

Reutilización de ontologías Reutilización de términos de las ontologías existente

3 Enumerar términos importantes de la ontología

Escribir una lista de los términos que se van a manejar en la ontologías, sus propiedades que poseen.

4 Definir las clases y su jerarquía. Utilizar procesos de desarrollo como: top-down(inicia con definición de conceptos más generales), butoom-up(inicia con definición de conceptos específicos) y combinado

5 Definir las propiedades/slots de las clases.

Diversos tipos de propiedades de las clases, herencia.

6 Definir las relaciones de las clases. Definir cardinalidad, tipo de dato, dominio y rango

7 Crear las Instancias Creación de instancias individuales de clases en la jerarquía

Tabla 10. Metodología para Crear una Ontología


114

Metodología a Utilizar

Tomando como referencia la metodología expuesta por Noy & McGuiness y Methontology se

propone el siguiente proceso de desarrollo que se basa en la construcción de un modelo

conceptual sólido que abarque todos los requerimientos de la ontología a construirse; debido a

que el frameworks WSMO se basa principalmente en un modelo conceptual para especificar los

elementos. Estos pasos son como se detalla en la Tabla 11:

Procesos Descripción

1 Determinar los requerimientos de la ontología

Definir el dominio u objetivo de alcance; definir el área donde se utilizará la ontología, definir los tipos de preguntas que deberá responder la ontología y asignar quién la utilizará y dará mantenimiento a la ontología

2 Reutilizar las ontologías o metadatos existentes

Definir las ontologías reutilizables, es decir la ontologías importadas y además identificar los términos reutilizables de las ontologías existentes.

3 Elaboración del modelo conceptual

Puntualizar los términos importantes de la ontología a través de un glosario de términos. Definir las clases y su jerarquía a través de una lista de clases de la ontología y con la ayuda de un diagrama de clasificación de conceptos. Definir las propiedades de las clases a través de una lista de atributos de clase y un diccionario de clase. Definición de las propiedades funcionales: entradas, salidas, precondiciones, postcondiciones, Asunciones y efectos

4 Implementación del modelo conceptual

Herramienta de implementación Protégé por su portabilidad entre diversas plataformas, su extenso uso y abundante documentación. La Ontología en RDFS u OWL para describir los recursos y Servicios.

5 Valoración de la ontología

Se realiza la verificación de la ontología, y su respectiva validación para ello se puede utilizar un razonador Pellet, para chequear la consistencia de la ontología, obtener automáticamente la clasificación taxonómica y computar los tipos inferidos.

Tabla 11: Metodología de desarrollo de ontología a utilizar


115

3. DESCRIPCIÓN SEMÁNTICA DE LOS SERVICIOS WEB

Para describir semánticamente a los Servicios Web, se considera que la mejor propuesta es

WSMO porque tiene un marco comprensivo para la futura red, contiene elementos y

lenguajes propios para aplicar técnicas centrales de razonamiento lógico, a través del uso de

mediadores que resuelven el problema de interoperabilidad y es muy útil cuando varios

servicios necesitan de orquestación y coreografía para satisfacer el objetivo.

WSMO se basa en cuatro elementos fundamentales como son: Servicios Web, Ontologías,

Objetivos, Mediadores. A continuación se describe cada uno de esto elementos con los

respectivos elementos que contienen:

3.a SERVICIOS WEB (Web Services)

El modelo de servicios Web describe el comportamiento a nivel funcional y a nivel de

comportamiento, a través de un modelo conceptual para describir lo relacionado a:

Propiedades no funcionales, su funcionalidad y las interfaces para obtenerlo. La clase Web

Services contiene:

Class service hasNonFuncionalProperties Propiedades No Funcionales importsOntolgy Ontologías Importadas usesMediators Mediadores Usados hasCapacity Capacidad hasInterface Interfaz


116

En la Tabla 12 se describe las capacidades e interfaces de los Web Services:

PARÁMETROS DESCRIPCIÓN NOTACIÓN

Precondiciones Estado interno antes de incorporar el servicio hasprecondition

CAPACIDADES Asunciones Estado del mundo que se asume ates de la

ejecución hasAsumption

funcionalidad Postcondiciones

Estado interno que se llega después de la ejecución

hasPostcondition

Efectos Estado del mundo que se alcanza al completar

la ejecución hasEffects

INTERFACES Coreografía Cómo interactúa con el servicio haschoreography

Descripción del comportamiento

Orquestación Descompone un servicio en término de la funcionalidad de un tercer servicio externo para cumplir la finalidad.

hasOrchestation

Tabla 12 Descripción de las capacidades e Interfaces de los Web Services de WSMO

3.b ONTOLOGÍAS (Ontolgy)

El modelo de ontologías establece que éstas puedan tener, además de sus propiedades no

funcionales, conceptos, relaciones, funciones e instancias de elementos, junto con la

importación de otras ontologías, y de un tipo de mediadores, llamado ooMediators, que

permite resolver conflictos entre ontologías. Además se usan ontologías descritas en diferentes

lenguajes, siendo los mediadores los responsables de realizar las adaptaciones necesarias.

Para modelar las ontologías con WSMO se considera utilizar dos modelos como se muestra en

la Fig. 11. El modelo de contexto de ontología (ontología de Servicios) y el modelo de contenido

de ontología (ontología de recursos). Esta separación se debe principalmente a que en WSMO

se puede distinguir claramente la información contextual (servicio) de una ontología de su

contenido (recursos) en sí.


117

Fig. 11. Modelo Ontología WSMO97

.

El modelo de contexto de ontología: Recolecta información sobre el contexto de SWS, tal como

la(s) ontología(s) que utiliza, donde estará(n) definidos los conceptos que usa el SWS y

generalmente contiene elementos que se describen en la Tabla 13.

ELEMENTOS DESCRIPCIÓN

NameSpaces Conjunto de símbolos únicos o identificadores

P. No Funcionales

Describen aspectos no funcionales como: el creador, la fecha de creación, descripciones en lenguaje natural.

Ontologías (WOntology): Representa una ontología WSMO; puede representar la que está Importadas siendo modelada o una ontología importada.

WsmoImport: Permite el uso de nombres e identificadores para referir a los miembros de un paquete desde otro namesapce.

Ontolgy: representa cualquier ontología importada (diferente a WSMO

Mediadores WMediator: Representa un mediador de WSMO, por lo general importado o la ontología que lo está usando.

Tabla 13. Descripción de Modelo de Contexto de Ontología

El modelo de contenido de ontología: Representa los elementos propios del SWS tales como las

habilidades o las interfaces. La clase Ontology contiene:

97



118

Class Ontology hasNonFuncionalProperties importsOntolgy usesMediators hasConcept hasRelations hasFuntion hasInstance hasAxioms

Los diferentes elementos constitutivos de la ontología que se está modelando son: Conceptos,

relaciones, funciones, instancias Axiomas, Atributos. En la siguiente tabla se describe cada uno

de ellos.

ELEMENTOS DESCRIPCIÓN NOTACIÓN

Conceptos

Son elementos básicos de la terminología. Son definidos por su jerarquía y caracterización de sus atributos, además contiene expresiones lógicas para refinar la semántica. <<Concept>>

Relaciones

Expresan interdependencia entre conceptos, permiten el refinamiento/reutilización de relaciones, posibilidad de definir parámetros y expresiones lógicas para definir. <<Relation>>

Instancias

Representan a los individuos concretos asignando valor a los atributos de un objeto (enlace a un conjunto de instancias externas). <<Instance>>

Funciones

Es una relación especial con un valor de retorno único y puede usarse para representar y obtener valores de tipos de datos comunes. <<Funtion>>

Axiomas

Son especificaciones como expresiones lógicas que ayudan a formalizar un dominio del conocimiento. Valores etiquetados: axiomsDefinition la expresión lógica del axioma. <<Axiom>>

Atributo

Representan los atributos de un concepto. Los valores etiquetados como Valores Etiquetados ofType: representa la integridad en los valores del atributo cuando la definición no ha sido inferida. <<Att>>

Tabla 14. Elemento de la Ontología de Contenido


119

3.c OBJETIVOS (Goals)

Realiza la descripción de alto nivel del servicio, en términos de las capacidades que

proporciona y mediante qué interfaces se puede acceder a ellas.

Class goal hasNonFuncionalPrperties Propiedades No Funcionales importsOntolgy Ontologías Importadas usesMediators Mediadores utilizados requestCapability Capacidad buscada requestInterface Interface buscada Los objetivos usan la importación de ontologías como mecanismo para definir otros elementos

que son parte del objetivo mientras no sea necesario resolver conflictos. Un objetivo usa

mediadores cuando utiliza terminologías heterogéneas pueden aparecer conflictos entre ellas,

en estos casos un Servicio Web puede importar ontologías usando mediadores.

“RequestCapability” describe la relación de características que al usuario le gustaría tener en el

Servicio Web y con el uso de “requestInterface” se indica la interface que al usuario le gustaría

tener en el Servicio Web y con la cual interactuar.

Los objetivos se caracterizan únicamente por postcondiciones y efectos. La idea es que, dado

un conjunto de servicios descritos en WSML y un objetivo (también escrito en WSML), para

saber qué servicio puede satisfacer el objetivo se comprueba que se cumplan las

postcondiciones y efectos del servicio y del objetivo.

3.d MEDIADORES

Permite realizar la gestión de heterogeneidad en tiempo de ejecución básicamente en tres

niveles: datos (fuente de datos y protocolos de transferencia), funciones (ajuste de objetivos),

procesos (interacciones, protocolos de comunicación). La clase Mediators contiene:


120

Class Mediators hasNonFuncionalPrperties importsOntolgy hasSource hasTraget hasMeditionService

En la siguiente Tabla 15 se describe los tipos de mediadores más utilizados en WSMO

TIPO DESCRIPCIÓN NOTACIÓN

Mediadores de Ontologías (OO)

Realiza la traducción entre ontología que cumple tres funciones: mezcla, alineación y mapeo. <<ooMediators >>

Mediadores entre Objetivos (GG)

Refinamiento/Composición de objetivos; se puede usar un ooMediators para resolver conflictos terminológicos entre objetivos.

<< ggMediators >>

Mediadores entre Servicios (WW)

Define la interoperabilidad de Servicios Web (orquestación), la intermediación la realiza en tres niveles: datos, funciones, procesos. Puede usar un ooMediators para resolver conflictos terminológicos.

<<wwMediators>>

Tabla 15. Tipos de Mediadores de más utilizados en WSMO

4. PUBLICACIÓN Y DESCUBRIMIENTO DE LOS SERVICIOS WEB SEMÁNTICOS

El registro de los SWS se lo puede realizar en un registro semántico a través de un repositorio

de Servicios y de recursos. La tecnología adecuada es UDDI que consiste en un registro global

de servicios Web, diseñado para almacenar de forma estructurada información sobre

empresas y los servicios que estas ofrecen. El descubrimiento automático de los Servicios Web

se realiza en función de la petición del servicio y la descripción semántica publicada; para esta

tarea actúa un agente de descubrimiento.


121

Otra opción para el registro y descubrimiento de Servicios en WSMT98(Web Service Modeling

ToolKit). En WSMT también podemos registrar ontologías, objetivos (goals) y mediadores para

lo cual se debe iniciar el entorno de ejecución WSMX, aunque es un lenguaje más completo en

lo respecta al registro de servicios, pero aún no es un lenguaje maduro que tenga variedad de

herramientas para ejecutarlo. WSMX (Web Services Execution Environment) es una aplicación

que pretende demostrar la viabilidad del uso de WSMO como medio para conseguir el

procesamiento dinámico de Servicios Web.

5. SELECCIÓN E INVOCACIÓN SEMÁNTICA DE LOS SERVICIOS WEB

La selección se da cuando existen conflictos entre varios servicios que satisfagan una petición

para ello debe actuar un Agente de Selección, validando parámetros de entrada y salida contra

la ontología de Servicios. Los mediadores que es uno de los elementos del framework de

WSMO pueden ayudar a resolver conflictos relacionados con la selección.

La Invocación del SWS se ejecutará en base a los parámetros de entrada y salida. En este parte

se debe evaluar o negociar los aspectos de: calidad de servicio, políticas institucionales y

aspectos no funcionales como políticas y protocolos de seguridad creada para este tipo de

Servicios.

Para la seguridad de los Servicios Web se puede aplicar tecnologías como XML Signature99

(firma digital) XML Encription100 (cifrado de segmento de documento XML) y WS-Security101

(proveer seguridad a SOAP).

98

http://www.wsmo.org/TR/d9/d9.1/ 99

http://www.w3.org/TR/xmldsig-core/ 100

http://www.w3.org/TR/xmlenc-core/ 101

http://es.wikipedia.org/wiki/WS-Security


122

Las propiedades no funcionales especificadas en WSMO tratan a cerca de la calidad del

servicio; las ontologías describen modelos de Calidad de Servicios que generalmente están

basados en tres componentes:

� Identificación de serie de Atributos (precio, rendimiento, capacidad, escabilidad).

� Definición de métricas, ligada a valores de cada atributo. (unidades, escalas, rangos).

� Identificación de relaciones para identificar agregaciones de propiedades o

dependencias asimétricas.

A partir de la definición de las ontologías de las propiedades no funcionales, también se puede

establecer los requisitos del usuario en lo que respecta a la calidad del servicio.

4.4 APLICACIONES PARA LOS SERVICIOS WEB DE LA UTPL

Una vez analizadas las diferentes tecnologías de Servicios Web, Web Semántica y Servicios

Web Semánticos, se propone un proyecto de Servicios Web con enfoque semántico que se

podría a futuro implementar en la UTPL, esto es “Servicio Web de catalogación y búsqueda

semántica de los recursos y Servicios de la Biblioteca virtual de la UTPL” esto debido a que los

contenidos de los recursos publicados en el sitio no se encuentra con facilidad al hacer una

consulta particular sobre un determinado tema.

Para el efecto, se propone utilizar conceptos de Web Semántica con el objetivo de mejorar la

búsqueda de los recursos educativos, publicaciones científicas, informes, pdfs, libros, revistas

etc. que se publica a través del sitio. Para lograr el objetivo se propone crear un modelo de

catalogación semiautomática, creando un conjunto de metadatos sobre los diferentes

contenidos de los recursos y Servicios que la biblioteca virtual; los mismos que se irán

organizando formando un catálogo, para lo cual se debe implementar un Servidor de

Catalogación para gestionar la base de conocimiento.


123

El catalogar consiste en crear un registro sustituto (metadato) para grupos de información. El

catálogo de los recursos semánticos debe cumplir con tres funciones básicas:

� Conocer qué recursos hay disponibles.

� Dónde se encuentra cada uno de estos recursos.

� Asociar recursos relacionados.

Se crea un conjunto de metadatos sobre los contenidos de los recursos digitales y páginas

disponibles del sitio (páginas de la misma entidad u organización) organizándolo formando un

catálogo. La utilización de un esquema de metadatos como Dublin Core se puede utilizar, o a su

vez crear un esquema de metadatos específico pensando en las búsquedas o servicios que se

desee mejorar. La parte de navegación de metadatos da acceso al usuario a los recursos,

donde a través de consultas el usuario recupera las descripciones de los recursos gestionados

por el sistema y navega a través de los metadatos semánticos. Para el efecto se considera

diseñar en dos partes: Revisión de catálogo y sistema semántico de consultas.

Revisión Catálogo: La función es revisar y gestionar el catálogo, es decir, la revisión y aceptación

de nuevos documentos, pdfs, libros, entre otros, por los administradores. La arquitectura de

información se debe organizar en los siguientes módulos: Un módulo de organización de los

metadatos, Modulo de indexación y almacenamiento, Modulo de depósito que contiene

objetos e índices.

Sistema semántico de Consultas: La principal funcionalidad consiste en la explotación de

información del repositorio por parte de agentes (humanos, y automáticos). Debe ofrecer la

funcionalidad de búsqueda y navegación en línea de documentos y repositorios semánticos

que estén basados en la ontología de recursos y servicios. Para implementar esta funcionalidad

se considera utilizar las tecnologías de Web semántica. En la arquitectura general de la

propuesta [fig. 12] se describe cada componente que interviene.


124

Fig.12 Arquitectura de la propuesta

Interfaz de Usuario: Se debe desarrollar una Interfaz Web para el acceso a los usuarios, que

permita realizar conexiones con diferentes navegadores Web. Para éste desarrollo se

contempla la tecnología Java basada en la ejecución de Servlets. El usuario debe interactuar

con una interfaz gráfica controlada por el agente usuario (agente de interfaz), para ingresar el

objetivo y ejecutar la orden de inicio del proceso de búsqueda.

Base de Datos: Contendrá las tablas de definición de perfiles de usuarios con las preferencias y

restricciones para habilitar las políticas de acceso al sistema. Es decir contendrá los diferentes

usuarios: Administradores, catalogadores, y usuarios en general.

Ontología: Las ontologías constituyen un elemento tecnológico clave de esta propuesta, son la

base de conocimiento que operan como vocabularios universales de tal forma, que tanto

servicios Web como los agentes comparten la misma interpretación de los términos dentro de

un contexto. Para este proyecto se plantea utilizar Protégé para la creación y edición de

ontologías que ofrece un entorno de trabajo amigable.


125

Sistema Experto basado en Agentes: La función principal de un agente de software es permitir

que a partir de la información contenida en las descripciones, se pueda descubrir servicios

automáticamente, como también invocarlos y componerlos para así monitorizar su ejecución.

Los agentes inteligentes requieren de un ambiente en el cual se cumplan las siguientes

características:

� Una red donde los recursos estén bien identificados.

� Una reserva de todo el conocimiento disponible, es decir, una ontología.

� Una descripción de las preferencias del usuario.

� Capacidad de inferencia.

Los agentes serían los responsables de las siguientes tareas: procesamiento de las consultas

del usuario, despliegue de la información recuperada, búsqueda, filtrado y resumen de grandes

volúmenes de datos, canalización de las solicitudes de búsqueda a la base de datos o a otros

agentes, control de los patrones usados y cambio de información para iniciar una

reorganización de datos y notificar a los usuarios.

En el área de la implementación de agentes mediante ontologías para la representación de la

información se puede utilizar un software desarrollado en una tesis “Arquitectura de un

sistema basado en agentes para la recuperación de recursos de información en un entorno de

educación”102. En el cual se utilizó el lenguaje Resource Description Framework Schema (RDF-S)

para representar la ontología de documentos. En esta arquitectura del sistema se desarrollaron

tres tipos de agentes UserAgent, SearchAgent y OntologyAgent (oSEMA)

User Agent o agente de interfaz se encarga de la interacción con el usuario, es decir enviar

mensajes a los otros agentes, Search Agent se encarga de buscar los metadatos y encontrar

los recursos digitales en los diferentes repositorios (ontologías) que satisfacen el objetivo y

102

http://grad.uprm.edu/tesis/dinosrojas.pdf


126

algunas restricciones de usuario y al mismo tiempo generar una estrategia de búsqueda

asociada al interés del usuario. OntologyAgent se encarga de acceder, modificar y actualizar

la ontología. Procesa todas las peticiones e integra lo encontrado por el agente de búsqueda

para luego seleccionar los mejores recursos de acuerdo al perfil de usuario.

A nivel general se debe tomar en cuenta los siguientes aspectos a la hora de desarrollar la

propuesta.

� Desarrollar un Servicio Web por cada recurso de Información o funcionalidad a que se

quiere tener acceso.

� Diseñar y crear una ontología de recursos y servicios que contenga los conceptos y

relaciones de interés para la aplicación a desarrollar.

� Anotar semánticamente los Servicios Web haciendo uso de la ontología creada y de alguna

de las aproximaciones actuales de Servicios Web Semánticos puede ser OWL-S o WSMO.

� Instanciar los agentes necesarios para recuperar información de las fuentes de datos de los

Servicios Web que han sido descritos Semánticamente, para tener acceso a consultar,

buscar, descargar los recursos digitales.

La estrategia planteada en la sección 4.3 para este SWS específico se puede aplicar para

ejecutar la propuesta. A continuación se describe cada apartado indicando la tecnología

aplicada en cada uno de ellos.

�� Integrar Procesos: Integrar las diferentes aplicaciones y bases de datos que maneja la

Universidad. RRHH, Gestión Académica, Sistema de Biblioteca Zebra, entre otros, para lo

cual se propone la tecnología de Servicios Web basados en SOAP como protocolo de

comunicación para mejorar de búsquedas de recursos digitales. Una Base de conocimiento

donde los recursos se describen utilizando la Ontología y la Integración automática de la

base de Datos Actual a la Base de conocimiento.


127

�� Construir la(s) Ontologías: Para la creación de la ontología se parte de la identificación de

las preferencias de usuario y la categorización de las fuentes documentales existentes la

construcción de un catálogo de recursos y Servicios con capacidades de Web Semántica y

la implementación de la ontología se puede utilizar RDFS u OWL, ya que son lenguajes

estándar recomendados por la W3C para dicho fin (analizados en el capítulo 2), que en la

actualidad es el estándar más maduro, consolidado y extendido en los últimos desarrollos

de proyectos del área de la web semántica. La metodología para el desarrollo de la

ontología se puede utilizar la que se describió en la Tabla 11.

� Descripción semántica de servicio Web: La descripción de los servicios Web a nivel

sintáctico se puede usar WSDL, que es el estándar más conocido en las arquitecturas

orientadas a servicios, pero debido a que este tiene algunas limitaciones, cuando existe la

necesidad de realizar las operaciones de descubrimiento, selección, composición,

negociación, invocación, monitorización y recuperación semiautomática de los servicios

web tradicionales, es viable la utilización de WSMO para efectivizar la descripción

semántica del servicio Web. A continuación [Fig. 13] se esquematiza la descripción del

servicio Web en WSMO.

Fig. 13. Descripción del Servicio Web en WSMO[Tomada de103

]

El servicio-cliente se debe implementar la interfaz de interacción para el consumo del

servicio Web, el comportamiento visible externo, la estructura de comunicación, las partes

básicas (entradas, salidas). Las propiedades No funcionales hacen referencia a la

103

https://poliformat.upv.es/access/content/group/DOC_30796_2006/Slides/serviciosweb_handout.pdf


128

descripción completa del recurso, aspectos de calidad y la gestión de Servicios Web. La

capacidad se refiere a la descripción funcional que involucra la publicidad del servicio Web

y el soporte para el descubrimiento

� Publicación y descubrimiento de los Servicios Web: Se la debe realizar en un registro

semántico para ser localizado fácilmente a través de una consulta de palabras clave. Al

ejecutar una búsqueda de un libro, publicaciones o video, el sistema cuando tiene más de

cinco registros relacionados con dicha búsqueda, debería mostrar un listado organizado por

autor, formato, título, fecha y la biblioteca en donde se encuentra. Un agente accede a los

repositorios de las ontologías (servicios y recursos) donde se han descrito semánticamente

los Servicios Web a través de consultas SPARQL identificando aquellos que puedan ser

válidos para el objetivo. Para que un proveedor pueda publicar su servicio debe facilitar

nombre, categoría, descripción del servicio web y la ubicación del archivo, estas

descripciones deben estar expresadas dentro de la ontología de dominio definida para usar

un lenguaje común y permite con eso, comparar los servicios Web según sus parámetros

� Selección e Invocación del Servicio: se evalúan las precondiciones (tipo de usuario,

Asunciones (disponibilidad), postcondiciones (tipo de servicio), se necesita evaluar las

restricciones de acuerdo a los perfiles de usuario, para que la aplicación ofrezca la

posibilidad de que un alumno por ejemplo reserve un número limitado de ejemplares para

consulta y otro diferente para llevar a la casa, pero lógicamente es que no sean tres del

mismo ejemplar. Se debe crear una interfaz de Usuario para interactuar con los

proveedores de servicios, en este caso sería la UTPL para negociar las condiciones para que

el servicio se ejecute.


129

DISCUSIÓN

Las tecnologías orientadas a Servicios (SOA) se convierten en un proyecto de mucha

relevancia, debido a que se enfoca básicamente a la integración de aplicaciones de tal forma

que genere una ventaja competitiva y se convierta en una estrategia de la organización. Los

Servicios Web son una forma más habitual de implementar SOA, que poseen grandes

beneficios asociados con la granularidad e interoperabilidad entre aplicaciones, es decir, con

la posibilidad de desarrollar componentes de software totalmente independientes que tienen

funcionalidad propia, pero que son capaces de exponer dicha funcionalidad y compartirla con

otros servicios y aplicaciones para lograr crear sistemas más complejos.

Desde este punto de vista, los servicios Web son calificados como una nueva etapa del

desarrollo de los sistemas distribuidos, que permite aprovechar todas las ventajas de trabajar

en ambiente Web, unidas a las de contar con una amplia gama de tecnologías que pueden ser

utilizadas para el desarrollo de los componentes finales.

Dentro del ámbito de Servicios Web se debe tomar en cuenta que están basados en un

conjunto de estándares de comunicación, como XML para la representación de datos, SOAP

para el intercambio de datos, WSDL para describir funcionalidades del Servicio, UDDI para la

publicación y descubrimiento; que ayudan a gestionar un Servicio Web básico a través del

intercambio de mensajes. Pero cuando éste no satisface por completo las necesidades del

usuario se deben componer varios servicios y es ahí donde se debe aplicar la orquestación y

coreografía haciendo uso de algunos lenguajes como: BPEL4WS, WS-BPEL, WS-CDL y con la

ayuda de agentes inteligentes se localiza los servicios Web de manera eficiente para generar

una respuesta a los requerimientos del usuario.

La potencia de la Arquitectura de los Servicios Web tradicionales como es la interoperabilidad

de aplicaciones es un factor muy importante, pero no es suficiente a la hora de realizar tareas

de búsquedas identificación y composición de servicios Web, para lo cual se recurre a la


130

tecnología de Web Semántica como una solución factible para la anotación semántica de los

servicios, estructurando la información para darle un significado y ser fácilmente localizada.

Para lograr ese propósito se requieren lenguajes de marcado apropiados que representen el

conocimiento de las ontologías. En la actualidad mediante anotaciones RDF, RDF Schema se

logra representar algunas facetas sobre conceptos de un dominio que permiten mediante

relaciones taxonómicas, crear una jerarquía de conceptos. Pero se necesitan lenguajes de

marcado (basados en RDF) con mayor expresividad y capacidad de razonamiento para

representar los conocimientos que contienen las ontologías como OWL. Además se debe

aprovechar las herramientas existentes para continuar desarrollando ontologías.

En el dominio de desarrollo de la Web Semántica se puede apreciar, que la capa de ontologías y

de reglas se encuentra en una etapa bastante estable, y las recomendaciones del W3C propone

la creación de ontologías a partir de lenguajes de marcado, siendo el más reciente OWL que

proporciona un lenguaje para definir ontologías estructuradas, para ser utilizadas a través de

diferentes sistemas, que utilizan un vocabulario para describir las propiedades y las clases de

los recursos RDF, estableciendo jerarquías de generalización entre ellas.

En el área educativa dentro de la línea de Web Semántica a futuro permitirá tanto a

docentes-investigadores y profesionales en formación identificar fácilmente los recursos y

servicios con propiedades específicas, que contengan algún tipo de relación con otros. El uso

de reglas semánticas puede ser un soporte valioso al momento de realizar la interpretación y

razonamiento de varios contenidos. Los proveedores de contenidos educativos que utilizan

Web Semántica mejorarían notablemente su gestión, intercambiando, integrando recursos con

otros proveedores de contenidos.

Una de las aplicaciones de Web Semántica de mayor relevancia en el área de gestión de

conocimiento es la generación de portales basados en ontologías, de tal forma que estén

estructurados y descritos semánticamente cada uno de los recursos y servicios que ofrecen,

porque al tener toda la información etiquetada sintáctica y semánticamente facilitará la


131

implementación eficaz de los agentes inteligentes, los mismos que serán capaces de ofrecer

información relevante en función de las necesidades de cada usuario.

Una vez que la información se encuentre etiquetada sintáctica y semánticamente contenidas

en las ontologías, y con el uso de las tecnologías de Servicios Web se puede fusionar a éstas

dos tecnologías para crear los Servicios Web Inteligentes que se caracterizan por llevar a cabo

las tareas de descubrimiento, composición e invocación de forma automática. En la actualidad

existen varios proyectos sobre Servicios Web Semánticos en fase de desarrollo, pero a pesar de

ser una tecnología inicial, se encuentra aún en un punto de partida la investigación en esta

área, donde hay mucha formalización, pero pocas plataformas capaces de ofrecer todas las

funcionalidades demandadas por los servicios Web Semánticos.

La base para proporcionar estas funcionalidades es la anotación semántica de los Servicios

Web, que describe sus precondiciones y postcondiciones, sus entradas y salidas. Existen

algunos frameworks que realizan dichas funcionalidades, pero de diferente manera entre los

cuales tenemos: OWL-S, WSMO, WSDL-S, SAWSDL la utilización de uno u otro dependerá del

objetivo. WSMO hace una diferencia entre el objetivo y la descripción del servicio, tiene

propiedades no funcionales en cada elemento de la ontología, es adecuado utilizar cuando se

requiere implementar orquestación y coreografía de Servicios y define un modelo conceptual

dentro del cual se deben crear las ontologías en cambio OWL-S define un conjunto de

ontologías para la manipulación de servicios. WSDL-S es el más indicado cuando se posee

cierta información sobre la localización de los servicios y SAWSDL incorpora un mecanismo

para referenciar desde un documento WSDL a conceptos de modelos semánticos definidos

externamente utilizando anotaciones.

En las instituciones como la UTPL, existe un creciente interés por el desarrollo de una mejor

coordinación en la administración y la divulgación de los recursos digitales como: objetos de

aprendizaje, trabajos preliminares en formato electrónico, tesis, disertaciones, etc. Pero estas

producciones de investigación digital suelen poseer formatos complejos y no estandarizados.

La comunidad académica deberá promover la adquisición de un mayor conocimiento sobre los


132

métodos de creación, utilización, reutilización y preservación de las actividades de investigación

y aprendizaje en el entorno digital.

Es muy importante que al generar un servicio Web semántico se utilicen datos que posean un

alto contenido semántico y estén altamente estructurados. En lo relacionado a las búsquedas

semánticas se debe encontrar la manera de maximizar sus cambios en enfoques

estructurados, en relación con las grandes cantidades de materiales no estructurados que se

están generando en la Web a partir de las actividades de investigación y aprendizaje.

Con el uso adecuado de medios y tecnologías se lograría promover el acceso a una educación

de calidad para dar accesibilidad al concomimiento con información estructurada y legible, que

pretende apoyar la estrategia de “acceso al conocimiento”, a través de la mejora de los niveles

de búsqueda de recursos digitales publicados en los sitios Web. Por eso el objetivo de ésta

investigación consiste en establecer una estrategia para crear un Servicio Web Semántico

basadas en las tecnologías analizadas para luego plantear una propuesta para la Universidad

que involucre la utilización eficiente de estas tecnologías.

La estrategia que se plantea consiste en: Integrar los procesos internos en la Web (crear los

Web Service), creación de Ontologías, descripción semántica de los Servicios Web, publicación

y descubrimiento de los SWS, selección e invocación semántica del Servicio Web, para lo cual

es necesario el uso adecuado de cada una de las tecnologías, herramientas y metodologías de

desarrollo para llegar a efectivizar el objetivo deseado.

Finalmente se plantea una propuesta con enfoque semántico, que consiste en la creación de un

Servicio Web de catalogación y búsqueda semántica de los recursos y servicios de la Biblioteca

Virtual de la UTPL, para dicho fin, se estructura en dos partes: Revisión de Catálogo (revisión,

gestión, ingreso de documentos) organizando los metadatos estructuralmente, y un Sistema

Semántico de Consulta, para lo cual se plantea una arquitectura, donde la base fundamental

constituye las ontologías que van a contener la descripción semántica de los recursos y

servicios que ofrecerá la biblioteca digital, para lo cual se ha considerado utilizar WSMO que


133

está basado en un modelo conceptual que identifica cuatro elementos: ontologías, objetivos,

descripción de servicios Web y Mediadores para la descripción semántica de los servicios.

Además se propone utilizar un sistema experto basado en agentes que se encargarán del

procesamiento de las consultas, búsqueda de información, filtrado, despliegue de información.

CAPÍTULO V

CONCLUSIONES Y RECOMENDACIONES


134

CAPITULO V

CONCLUSIONES Y RECOMENDACIONES

5.1 CONCLUSIONES GENERALES

� La tecnología de Servicios Web brinda la posibilidad de compartir y reutilizar información

propia de cada organización con grandes beneficios para la sociedad, sin embargo el

desarrollo de los mismos no es tan sencillo a pesar de que cuenta con múltiples

herramientas.

� Para la implementación de una arquitectura orientada a servicios se requiere un alto grado

de conocimiento de los procesos de la empresa y de los servicios que apoyan estos

procesos ya que el éxito de la implementación dependerá mucho de la alineación que

exista entre ambos.

� El éxito de los Servicios Web está orientado al uso de estándares conocidos en los que ya

se tiene confianza como el XML. La interoperabilidad e integración de aplicaciones son una

de las ventajas significativas que a futuro crearán nuevas oportunidades de negocio,

aportando como beneficios el poder compartir datos, aplicaciones y procesos entre

proveedores y clientes sin importar el lenguaje o plataforma de desarrollo.

� Son muchas las expectativas alrededor de los Servicios Web porque el mercado de

aplicación es muy amplio, pero también tiene unos puntos obscuros relacionados con la

seguridad de la organización puede verse comprometida. La ausencia de técnicas de

seguridad estándar es un obstáculo para la adopción de ésta tecnología. Además la calidad


135

de servicio es un parámetro que no queda demasiado claro, pero cuya medida es

fundamental a la hora de desarrollar un servicio Web maduro.

� Las tendencias futuras de la Web Semántica se orientan básicamente a la evolución de los

sitios Web convencionales, hacia portales con significado, permitiendo exponer todo el

conocimiento generado mediante ontologías que permitan el intercambio de información

entre los diferentes sistemas.

� Mientras mayor sea la descripción Semántica y estructuración lógica de los documentos

mayor será la precisión obtenida en la recuperación de información, además gracias a los

axiomas definidos en las ontologías, facilitarán a agentes y a buscadores inteligentes inferir

nuevo conocimiento, recuperando un mayor número de recursos relevantes por cada

consulta dada.

� La gestión del conocimiento en las Instituciones se apoya de herramientas que no siempre

permiten representar de una forma dinámica los conocimientos que se genera en sus

diversos contextos. Las ontologías son una herramienta eficaz para modelar, compartir y

reutilizar conocimiento en las Instituciones y contribuir a las búsquedas inteligentes de un

Servicio Web, haciendo inferencias a partir del conocimiento representado en estos

sistemas.

� Los Servicios Web Semánticos, aún no están muy extendidos en el ámbito educativo, pero

se encuentran en un nivel de madurez suficiente para su utilización, para ello se requiere de

desarrollo de nuevos componentes en las aplicaciones que interactúen con éstos y de una

metodología de desarrollo que se adapte para soportar el desarrollo de éstos nuevos

componentes.

� El problema de los Servicios Web Semánticos desde su concepción es su dependencia de

entidades software de nivel superior con capacidades cognitivas que posean la capacidad


136

de acceder al contenido semántico de las descripciones de los servicios, procesarlo y

entenderlo de manera de hacer un uso eficiente y apropiado de las funcionalidades que

éstos servicios nos brindan.

� Se presenta una estrategia simplificada para el estudio de construcción de un Servicio Web

Semántico basados en WSMO para el sitio Web Institucional de tal forma que se pueda

describir semánticamente los servicios y recursos para acceder de manera semiautomática,

para lo cual se debe realizar eficientemente las tareas de descripción semántica, la creación

de ontologías de recursos y servicios para proporcionar una descripción lógica y formal de

la información que almacenan, y de esta forma puedan ser accedidos e interpretados ya

sea por usuarios o por agentes inteligentes.

� Lo ideal para llevar a cabo un Servicio Web Semántico se requiere contar con medios

tecnológicos para enlazar recursos, los usuarios deben poder acceder a otros servicios de

información de manera transparente, metodologías de desarrollo, agentes personales bien

capacitados, ontologías bien definidas. Sin embargo, existen una serie de problemas que

ponen freno a su rápida expansión, como la disponibilidad, recuperación y adecuación,

autenticidad, utilización protección de la propiedad intelectual, asequibilidad o costos.

� Para aumentar la eficiencia en la búsqueda de recursos digitales de la Biblioteca se

presenta una propuesta de implementación de un servicio Web de catalogación y

búsqueda semántica de recursos y servicios Web, cuyo objetivo es encontrar una menor

cantidad de resultados, pero de mayor relevancia para la búsqueda utilizando un lenguaje

de consulta eficiente que opere a nivel semántico para la explotación del catálogo, además

que facilite el intercambio de información.


137

5.2 RECOMENDACIONES

� Se recomienda diseñar aplicaciones pensando en las futuras posibilidades de integración ya

que introducir conceptos integradores requerirá cambios en los estándares de diseño, la

arquitectura de desarrollo y la manera de pensar del equipo desarrollador.

� Dentro del ámbito del uso de Servicios Web se recomienda que las políticas de Seguridad

se evalúen estrictamente, antes de ejecutar un Servicio Web para identificar de alguna

manera al emisor, caso contrario no se debería aceptar. Hay que ser precavido con el uso

de herramientas que facilitan la creación de Servicios Web debido a los mecanismos de

seguridad aún no están muy consolidados.

� Al crear una ontología se debe considerar los campos o parámetros que interesen realizar

la búsqueda, porque una ontología con demasiados parámetros solo aumenta la

complejidad de la búsqueda que se traduce en mayor dificultad en llenar y mantener los

metadatos, mayor probabilidad de cometer errores en la creación de metadatos, menor

calidad en los resultados de búsqueda.

� Para la implementación de un servicio Web de catalogación y búsqueda semántica se

considera aplicar como plan piloto para la biblioteca de la UTPL ya que se tiene catalogados

los diferentes recursos (libros) que existen y para la búsqueda semántica de éstos se

requiere aplicar las tecnologías estudiadas en la presente investigación para describir

semánticamente los recursos (libros, tesis, entre otros) y servicios (préstamo, reserva).

� Definir un modelo de perfilamiento en la Web, es decir, poder realizar búsquedas

restringiendo los ámbitos de interés a ciertos temas en particular (por ejemplo, artes) y cada

página ser catalogada según una persona con el perfil del área (por ejemplo, un artista), se

podría realizar búsquedas y navegar bajo cierta forma de ver la información, es decir bajo un

perfil particular.

BIBLIOGRAFÍA


138

REFERENCIAS BIBLIOGRAFICAS

�� [1] W3C:(Septiembre, 2008) “Servicios Web : Guía Breve de Servicios Web” Citado

[Octubre, 2008][En Línea] Disponible en:

http://www.w3c.es/Divulgacion/Guiasbreves/ServiciosWeb

�� [2] BARRIS Douglas K. ( 2003) “Web Services and Service-Oriented Architecture” [Citado

Octubre, 2008] [En Línea] Disponible en:

http://books.google.com.ec/books?id=p2fa0KNg5pcC&printsec=frontcover#PPP1,M1

�� [3] THOMAS, Erl (Septiembre, 2004)“Introduction to Web Services Technologies: SOA,

SOAP, WSDL and UDDI” Citada en (Noviembre, 2008) Disponible en:

http://www.informit.com/articles/article.aspx?p=336265

�� [4] LÓPEZ, G.; JEDER, I.; ECHEVERRÍA, A.; FIERRO, P. ( )”Diseño de Aplicaciones con

Arquitectura orientada a Servicios. Modelos de Ciclos de Vida ad-hoc” Reportes

Técnicos en Ingeniería del Software. 9(1): 29-36 ISSN 1667-5002. © CAPIS-EPG-ITBA

Citado en [Diciembre de 2008] [En línea] Disponible en:

http://www.centros.itba.edu.ar/capis/rtis/rtis-9-1/RTIS-9-1-29-36.pdf

�� [5] DE SETA Leonardo (Noviembre,2008) “Introducción a los servicios web RESTful”

[Citado en Diciembre de 2008] [En línea]Disponible en:

http://www.dosideas.com/metodologias/314.html?joscclean=1&comment_id=419

�� [6] TOMAS, Fielding Roy (2000) “Architectural Styles and

the Design of Network-based Software Architectures” [Citado en Diciembre de 2008] [En

línea] Disponible en: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm


139

�� [7] BORILLO Ricardo, GUMBAU José (Junio, 2008) “Arquitecturas orientadas a servicios

para la preservación de objetos digitales” [en línea] [Citado en Diciembre de 2008]

Disponible en: http://xml-utils.com/arquitecturas.pdf

�� [8] Wikipedia Foundation, Inc (Diciembre de 2008) “OASIS (organización)” [en línea]

Citado en Diciembre de 2008] Disponible en:

http://es.wikipedia.org/wiki/OASIS_(organizaci%C3%B3n)

�� [9] DUARTE MORENO Dilia; entre Otros (2005)”Protocolo Simple de Acceso a Objetos”

[en línea] [Citado en Diciembre de 2008] disponible en:

http://www.monografias.com/trabajos29/protocolo-acceso/protocolo-acceso.shtml

�� [10] BARCO Antonio (Junio, 2007) “SOA y los Servicios Web (1)” ” [en línea] [Citado en

Diciembre de 2008] http://arquitecturaorientadaaservicios.blogspot.com/2006/06/soa-

y-los-servicios-web-i.html

�� [11] W3C Recommendation (Junio, 2007) “Web Services Description Language (WSDL)

Version 2.0 Part 1: Core Language” [Citado en Diciembre de 2008] Disponible en:

http://www.w3.org/TR/wsdl20/

�� [12] RODRIGUEZ Wladimir (Abril, 2005) “Arquitectura Orientada a Servicios Clase # 5:

introducción a WSDL” [Citado en Diciembre de 2008] [En línea] Disponible en:

http://web.mac.com/wladimir.rodriguez/WladimirRodriguez/MaterialApoyoSOA_files/5

WSDL.pdf

�� [13] RAMIREZ, Edgar (Octubre, 2008) “UDDI” [Citado en Noviembre de 2008] [En línea]

disponible en: http://edgarramirez.wordpress.com/2008/10/14/uddi/


140

�� [14] RODRIGUEZ Wladimir (Abril,2005) “Arquitecturas Orientadas a Servicios Clase #6:

Introducción a UDDI” [Citado en Diciembre de 2008] [En línea] Disponible en:

http://web.mac.com/wladimir.rodriguez/WladimirRodriguez/MaterialApoyoSOA_files/6

UDDI.pdf

�� [15] RODRIGUEZ Jesús (Enero 2005 ) “Interoperabilidad con Patrones de Intercambio de

Mensajes creados con BEA WebLogic 8.1.3” Microfoft [Citado en Diciembre de 2008] [En

línea]; Disponible en:

http://www.microsoft.com/spain/interop/developers/beaconvwebservices.mspx

�� [16] MARQUEZ SOLIS, Santiago; “Orquestación Vs Coreografía de Servicios”. [Citado en

Diciembre de 2008] [En línea]Disponible en:

http://www.lawebsemantica.com/contents/webSemantica/procesos/orquestacionCore

ografia.html

�� [17] PEREZ PEREZ Juan Ramón(Marzo, 2007); Servicios Web: Orquestación y

coreografías[Citado en Noviembre de 2008] [En línea] Disponible en:

http://www.di.uniovi.es/~juanrp/docencia/ws/orquestacion%20y%20coreografias.pdf

�� [18]GARCIA, Ignacio, entre Otros (Enero, 2005) “Informe Técnico UCLM DIAB- 05 - 01 –

1” Departamento de Informática (Universidad de La Castilla La Mancha España) [Citado

en Noviembre de 2008] [En línea] Disponible en: http://www.info-

ab.uclm.es/descargas/thecnicalreports/DIAB-05-01-1/Servicios%20Web.pdf

�� [19] HENDLER James (Marzo,1999) “Is There an Intelligent Agent in Your Future?

[Citado en Diciembre de 2008] [En línea] Disponible en:

http://www.nature.com/nature/webmatters/agents/agents.html


141

�� [20] GARCIA Ignacio, POLO Macario, RUIZ Francisco, PIATTINE Mario (Enero, 2005)

“Servicios Web” Informe Técnico UCLM DIAB- 05 - 01 – 1, Universidad de Castilla-La

Mancha, España; Departamento de informática [En línea] [Citado Diciembre, 2008]

Disponible en: http://www.dsi.uclm.es/descargas/thecnicalreports/DIAB-05-01-

1/Servicios%20Web.pdfv

�� [21] Berners-Lee, T., Hendler, J., and Lassila, O.(Mayo, 2001). “The Semantic

Web”Scientific American” . [En línea] [Citado Diciembre, 2008]

http://www.ryerson.ca/~dgrimsha/courses/cps720_02/resources/Scientific American

The Semantic Web.html

�� [22] W3C Word Wide Web (julio, 2008) “Guía breve de Web Semántica” [En línea]

[Citado en Noviembre de 2008] Disponible en:

http://www.w3c.es/Divulgacion/Guiasbreves/WebSemantica

�� [23] Nigel Shadbolt, Tim Berners-Lee, and Wendy Hall (Mayo, 2006). “The semantic web

revisited”. IEEE Intel-ligent Systems [En línea] [Citado Diciembre, 2008] Disponible en:

http://dsonline.computer.org/portal/cms_docs_dsonline/dsonline/2006/07/x3096.pdf

�� [24] COLLADO Manuel (Noviembre, 2006) “Introducción a las Tecnologías y Estándares

XML” [En línea] [Citado Diciembre, 2008] Disponible en:

http://lml.ls.fi.upm.es/~mcollado/xml/xml.pdf

�� [25] World Wide Web Recomendation (Agosto,2006), “Namespaces in XML 1.0 (Second

Edition)” [En línea] [Citado en Enero de 2009] Disponible en:

http://www.w3.org/TR/REC-xml-names/


142

�� [26] LAMARCA LAPUENTE María Jesús (Enero, 2009) “DTDs y los XML Schema:

Hipertexto: El nuevo concepto de documento en la cultura de la imagen.” Universidad

Complutense de Madrid(Tesis doctoral) [En línea] Citado en Enero de 2009 Disponible

en: http://www.hipertexto.info/documentos/dtds.htm

�� [27] AOS (Avanced Quality Solution) (Septiembre, 2001) “XML Shema y los DTDs” [En

línea] Citado en Enero de 2009 Disponible en:

http://www.aqs.es/files/Schema_y_DTDs.pdf

�� [28] BURGUÉ DORDA Laura (Abril, 2007) “XQUERY”; Universidad Carlos III de Madrid;

[En línea] [Citado en Enero de 2009] Disponible en:

http://es.geocities.com/lenguajesde_recuperacion/xquery.htm

�� [29] GIL SÁNCHEZ Vanesa (Octubre, 2007) “Recuperación y Organización de la

Información. Lenguaje de recuperación para la Web XQuery” [ En línea] [Citado en

Enero de 2009] Disponible en:

http://es.geocities.com/lenguajes_de_recuperacion/docs/lenguajes_de_recuperacion.d

oc

�� [30] LASSILA, O. y R. Webick.(Octubre ,1999) “Resource Description Framework (RDF)”

Model and Syntax Specification. W3C Recommendation. [ En línea] [Citado en Enero de

2009] Disponible en: www.w3.org/TR/PR-rdfsyntax.

�� [31] ARIZA César, BAPTISTA Ana Alice (2004) “Uso de RDF y bases de datos de etadatos

nativas dentro del proyecto Omnipaper” Universedar de Minho [ En línea] Citado en

Enero de 2009 Disponible en:

http://repositorium.sdum.uminho.pt/bitstream/1822/2249/1/rdfdbnativasXATA2004.p

df


143

�� [32] Colaboradores WIKIPEDIA(Octubre, 2008) “RDF Shema” Editor: Wikipedia,

enciclopedia Libre[ En línea] Citado en Enero de 2009 Disponible en:

http://es.wikipedia.org/w/index.php?title=RDF_Schema&oldid=20665258

�� [33] W3C Recommendation (Febrero,2004) “RDF Vocabulary Description Language 1.0:

RDF Schema” [ En línea] Citado en Enero de 2009 Disponible en: http://www.w3.org/TR/rdf-schema/

�� [34] Aduna B.V., Sirma AI Ltd. (Febrero, 2009) “User Guide for Sesame” [En línea] Citado

en Marzo de 2009 Disponible en:

http://www.openrdf.org/doc/sesame/users/ch01.html

�� [35] SOURCEFORJET.NET ( 2008)“Jena – A Semantic Web Framework for Java” Versión

2.5.7 [En línea] [Citado en Enero de 2009] Disponible en: http://jena.sourceforge.net/

�� [36] EL CAPARAZÓN (Junio, 2008) “Twine, futures desarrollos (cuando la personalización

total en publicidad es contenido)” [En línea] Citado en Enero de 2009 Disponible en:

http://www.dreig.eu/caparazon/2008/06/02/twine-futuros-desarrollos-cuando-la-

personalizacion-total-en-publicidad-es-contenido/

�� [37] INRIA Sophia Antipolis (“Corese Semantic Web Factory: a semantic Web search

engine based on Conceptual Graphs” [En línea] Citado en Enero de 2009 Disponible en:

http://www-sop.inria.fr/acacia/soft/corese/

�� [38] WIKIPEDIA (Noviembre, 2008) “Lógicas de Descripción” [En línea] Citado en Enero

de 2009 Disponible en: http://es.wikipedia.org/wiki/L%C3%B3gica_descriptiva


144

�� [39] GRUBER Thomas .R., (Agosto, 2003)“Towards Principles for the Design of Ontologies

used for Knowledge Sharing”, Proc. Of International Workshop on Formal Ontology,

Padova, Ed N. Guarino, Available as Technical Report KSL-93-94, KnowledgeSystems

Laboratory, Standford University. [En línea] [Citado en Febrero 2009] Disponible en:

http://iir.ruc.edu.cn/pdf/Toward%20Principles%20for%20the%20Design%20of%20Onto

logies.pdf

�� [40] Santiago (Abril, 2005) “Ontologías” [En línea] Citado en Enero de 2009 Disponible

en: http://www.infor.uva.es/~sblanco/Tesis/Ontolog%C3%ADas.pdf

�� [41] RAMIREZ CÉSPEDES Julia (Marzo, 2006) “Las Ontologías como herramienta en la

Gestión de Conocimiento”; Departamento de Bibliotecnología y Ciencia de la

Información; Universidad de la HABANA-CUBA; [En línea] Citado en Enero de 2009

Disponible en: http://www.congreso-

info.cu/UserFiles/File/Info/Info2006/Ponencias/208.pdf

�� [42] Recomendaciones del W3C (Febrero, 2004 ) “Lenguaje de Ontologías Web (OWL)

Vista General” [En línea] Citado en Enero de 2009 Disponible en:

http://www.w3.org/2007/09/OWL-Overview-es.html

�� [43] GÓMEZ PEREZ, Asunción (Mayo ,2002)“A Survey on Ontology Tools”

“OntoWebOntology-based information exchange for knowledge management and

electronic commerce” [En línea] [Citado en Febrero de 2009] Disponible en:

http://www.aifb.uni-karlsruhe.de/WBS/ysu/publications/OntoWeb_Del_1-3.pdf

�� [44] Universidad Politectica de Valencia: Facultad de Informática(Febrero, 2003)

“Introducción a Protégé”SISTEMAS DE REPRESENTACIÓN Y PROCESAMIENTO


145

AUTOMÁTICO DEL CONOCIMIENTO ” [En línea] Citado en Enero de 2009 Disponible en:

http://personales.upv.es/ccarrasc/extdoc/p1_1_parte.pdf

�� [45] MINDSWAP(Abril, 2006) “A Hypermedia-based Featherweight OWL Ontology

Editor” [En línea] Citado en Febrero de 2009 Disponible en:

http://www.mindswap.org/2004/SWOOP/

�� [46] SEMANTIC WEB COMPANY (Diciembre, 2003) “WebODE Ontology Engineeniring

Platform” [En línea] Citado en Febrero de 2009 Disponible en:

http://webode.dia.fi.upm.es/WebODEWeb/index.html

�� [47] AVANCED KNOWLEGDE TECHNOLOGIES (1998) “WebONTO from open University”

[En línea] Citado en Febrero de 2009 Disponible en:

http://www.aktors.org/technologies/webonto/

�� [48] BBN TECHOLOGIES (Septiembre, 2005) “SWeDE” [En línea] Citado en Febrero de

2009 Disponible en: http://owl-eclipse.projects.semwebcentral.org/

�� [49] D. Fensel, H. Lausen, et al., Enabling Semantic Web Services: the Web Service

Modeling Ontology, 2007, XIV, 188 p., 41 illus., Hardcover[En Línea] Citado en [Febrero,

2009]. Disponible en: http://www.amazon.com/Enabling-Semantic-Web-Services-

Modeling/dp/3540345191#reader

�� [50] Christoph, B., FENSEL, D., MAEDCHE, A. (2003) “A Conceptual Architecture for

Semantic Web Enabled Web Services” [En Linea] Citado en [Febrero, 2009]. Disponible

en: http://swws.semanticweb.org/public_doc/D2.1.pdf


146

�� [51] W3C Member Submission (Junio, 2005) “Web Service Modeling Ontology (WSMO)”

[En Linea] Citado en [Febrero, 2009]. Disponible en:


�� [52] W3C Member Submission (Noviembre, 2004) “OWL-S: Semantic Markup for Web

Services” En Linea] Citado en [Febrero, 2009]. Disponible en:

http://www.w3.org/Submission/OWL-S/

�� [53] KOPECKY Jacek entre Otros (Diciembre, 2005) “Semantics Web Services Grounding”

[En Linea] Citado en [Febrero, 2009]. Disponible en:

http://dip.semanticweb.org/documents/Kopecky-Semantic-Web-Services-

Grounding.pdf

�� [54] John Miller, Kunal Verma, entre Otros(Julio, 2004) ” WSDL-S: A Proposal to W3C

WSDL 2.0 Committee” METEOR-S: Semantic Web Services and Processes; University of

Georgia and Authors ; [En Linea] Citado en [Febrero, 2009], Disponible en:

http://lsdis.cs.uga.edu/projects/wsdl-s/WSDL-S.pdf

�� [55] W3C Candidate Recommendation (Enero, 2007) “Semantic Annotations for WSDL

and XML Schema” [En Línea] Citado en [Febrero, 2009] Disponible en:

http://www.w3.org/TR/2007/CR-sawsdl-20070126/

�� [56] Cáceres, P., Marcos, E., Vela, B. A (Agosto, 2003) “MDA-Based Approach for Web

Information System Development, Actas del Workshop in Software Model Engineering”

[En línea] Citado en [Mayo, 2009]. Disponible en http://www.metamodel.com/wisme-

2003/07.pdf


147

�� [57] OMG Object Management Group (Abril, 2009) “Meta-Object Facility,”version 1.4.

[En línea] Citado en [Mayo, 2009] Disponible en:

http://omg.org/technology/documents/formal/mof.htm

�� [58] Noy, Natalya y McGuinness, Debora (2005). “Desarrollo de Ontologías 101: Guía

para crear la primera ontología” Universidad de Stanford, California. [En línea] Citado en

[Agosto, 2009] Disponible en:

http://protege.stanford.edu/publications/ontology_development/ontology101-es.pdf

Documents

UNIVERSIDAD TECNICA PARTICULAR DE LOJAdspace.utpl.edu.ec/bitstream/123456789/1706/3/Carrión Jiménez... · 1.2 SOA: Arquitectura orientada a Servicios ... analizar el esquema de