UNIVERSIDAD DE PAMPLONA FACULTAD DE INGENIERAS Y ARQUITECTURA DEPARTAMENTO DE INGENIERAS ELCTRICA ELECTRNICA SISTEMAS Y TELECOMUNICACIONES PROGRAMA INGENIERA DE SISTEMAS

TRABAJO DE GRADO PRESENTADO PARA OPTAR POR EL TITULO DE

INGENIERA DE SISTEMAS

TEMA:

AUTOMATIZACION DE PROCESOS DE NEGOCIO USANDO SERVICIOS WEB SEMANTICOS.

AUTOR: Leidy Paola Caldern Hernndez. DIRECTOR: Ing. Jorge Omar Portilla Jaimes. DIRECTOR DEL PROGRAMA: Msc. Ing. Prof. Orlando Maldonado.

PAMPLONA N. S. COLOMBIA DICIEMBRE 2010

UNIVERSIDAD DE PAMPLONA FACULTAD DE INGENIERAS Y ARQUITECTURA DEPARTAMENTO DE INGENIERAS ELCTRICA ELECTRNICA SISTEMAS Y TELECOMUNICACIONES PROGRAMA DE INGENIERA DE SISTEMAS TRABAJO DE GRADO PRESENTADO PARA OPTAR POR EL TITULO DE INGENIERA DE SISTEMAS. TITULO AUTOMATIZACION DE PROCESOS DE NEGOCIO USANDO SERVICIOS WEB SEMANTICOS FECHA DE INICIO DEL TRABAJO: FEBRERO 2010 FECHA DE TERMINACIN DEL TRABAJO: MAYO 2010

NOMBRES Y FIRMAS DE AUTORIZACIN:

_________________________________ ___________________________________ LEIDY PAOLA CALDERON HERNANDEZ Ing. JORGE OMAR PORTILLA JAIMES Autor Trabajo de Grado Director Trabajo de Grado _________________________________ Msc. Ing. ORLANDO MALDONADO Director de Programa

JURADO CALIFICADOR:__________________________________ Msc. Lic. LUIS A. ESTEBAN VILLAMIZAR Presidente ____________________________ MAURICIO ROJAS Oponente

________________________________________ MARITZA DEL PILAR SANCHEZ DELGADO Secretario

PAMPLONA COLOMBIA DICIEMBRE 2010

UNIVERSIDAD DE PAMPLONA FACULTAD DE INGENIERAS Y ARQUITECTURA DEPARTAMENTO DE INGENIERAS ELCTRICA ELECTRNICA SISTEMAS Y TELECOMUNICACIONES PROGRAMA DE INGENIERA DE SISTEMAS ACTA DE CALIFICACIN DE TRABAJO DE GRADO EL JURADO CALIFICADOR CONFORMADO POR: (Nombres y apellidos) PRESIDENTE: _________________________________________________ OPONENTE: ________________________________________________ SECRETARIO: _________________________________________________ EN SU SESIN EFECTUADA EN ___________________________________ A LAS _____ HORAS, DEL DIA_____DEL MES ______DEL AO__________

TERMINADAS SUS DELIBERACIONES HA LLEGADO A LAS SIGUIENTES CONCLUSIONES: PRIMERA CONCLUSIN: En correspondencia con el artculo 35 pargrafo segundo del reglamento estudiantil, emitido en el acuerdo No. 186 del 02 de diciembre del ao 2005, del Concejo Acadmico Superior de La Universidad de Pamplona.OTORGAR LA CALIFICACIN DE: EXCELENTE APROBADO INCOMPLETO

FIRMAR EN LA CALIFICACIN

AL TRABAJO DE GRADO TITULADO:___________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _______________

DEL AUTOR: _________________________________________________________ DIRECTOR: ___________________________________________________________

SEGUNDA CONCLUSIN: RECOMENDAR:

No. 1. 2. 3.

DESCRIPCIN Recomendar para presentar en eventos cientficos. Recomendar para publicacin. Incluir en el fondo bibliogrfico de la Universidad de Pamplona.

ACEPTABLE SI NO

4. 5. 6. 7. 8. 9. 10.

Recomendar para ser continuado en otros trabajos. Recomendar para patente. Recomendar continuar como trabajo de maestra. Recomendar para meritorio. Recomendar para laureado. Recomendar continuar como trabajo de doctorado. Otras.

Otras:

TERCERA CONCLUSIN: OTORGAR EL TITULO DE INGENIERA _______________________________________________________________

Firmas del jurado:

________________________ ______________________ _____________________ PRESIDENTE OPONENTE SECRETARIO

DEDICATORIA FALTA

PENSAMIENTOS

FALTA

AGRADECIMIENTOS FALTA

RESUMEN

Este trabajo de grado presenta una alternativa de solucin automatizada para llevar a cabo la ejecucin de procesos de negocio mediante el uso de servicios web semnticos.

El documento consta de siete captulos, en

el captulo I

se presenta la

justificacin y objetivos del trabajo, el captulo II contiene el marco terico, en el cual se detallan los temas necesarios para cumplir con el objetivo propuesto, en el captulo III se exponen algunos trabajos afines, el captulo IV describe el prototipo desarrollado y explica sus tres procesos principales; composicin, emparejamiento y ejecucin de servicios web semnticos de tal forma que satisfagan las tareas necesarias para llevar a cabo un proceso de negocio especifico, el capitulo V muestra funcionamiento del prototipo desarrollado con algunos casos de prueba, en el captulo VI se determina la viabilidad de

incorporar servicios web semnticos en la automatizacin de procesos de negocio, basado en los resultados obtenidos del prototipo implementado, y el captulo VII contiene las conclusiones, observaciones y recomendaciones, referencias y glosario.

ABSTRACT

TABLA DE CONTENIDO

NDICE DE FIGURAS ..............................................................................................................................13 NDICE DE TABLAS ................................................................................................................................13 LISTA DE ANEXOS .................................................................................................................................17 CAPITULO I ...........................................................................................................................................18 1.1 INTRODUCCIN ...................................................................................................................18 1.2 JUSTIFICACION .....................................................................................................................19 1.3 NECESIDADES Y PROBLEMAS ................................................................................................20 1.4 DELIMITACION .....................................................................................................................21 1.4.1 Objetivo general. .............................................................................................................21 1.4.2 Objetivos especficos. .......................................................................................................21 CAPITULO 2 ..........................................................................................................................................22 2 MARCO TEORICO .........................................................................................................................22 2.1 SOA: ARQUITECTURA ORIENTADA A SERVICIOS .....................................................................22 2.1.1 Definicin.........................................................................................................................22 2.1.2 Diseo y desarrollo de SOA ...............................................................................................25 2.1.3 Elementos de SOA ............................................................................................................30 2.1.4 Ventajas de una arquitectura orientada a servicios...........................................................34 2.2 WEB SEMANTICA..................................................................................................................35 2.2.1 Antecedentes ...................................................................................................................35 2.2.2 Fundamentos de la web semntica...................................................................................36 2.2.3 Arquitectura de la web semntica ....................................................................................38 2.2.4 Tecnologas y Lenguajes ...................................................................................................422.2.4.1 URI ....................................................................................................................................... 42 2.2.4.2 XML...................................................................................................................................... 43 2.2.4.3 Ontologas ............................................................................................................................ 44 2.2.4.4 Lenguajes para representacin de ontologas ........................................................................ 46 2.2.4.4.1 RDF (Resource Description Framework) ............................................................................ 46 2.2.4.4.2 RDF Schema ..................................................................................................................... 47 2.2.4.4.3 OWL (Web Ontology Language) ........................................................................................ 49 2.2.4.4.4 WSML( Web Services Modeling Language) ........................................................................ 50

2.2.5 Ventajas e inconvenientes ................................................................................................52 2.3 SERVICIOS WEB ....................................................................................................................55 2.3.1 Introduccin.....................................................................................................................55 2.3.2 Arquitectura de los servicios web......................................................................................562.3.2.1 2.3.2.2 2.3.2.3 WSDL (Web Service Description Language)............................................................................ 57 SOAP (Simple Object Access Protocol) ................................................................................... 59 UDDI (Universal Description, Discovery and Integration) ........................................................ 60 Coreografa .......................................................................................................................... 65 Orquestacin ........................................................................................................................ 66

2.3.3

Orquestacin y Coreografa ..............................................................................................64

2.3.3.1 2.3.3.2

2.3.4 Ventajas e Inconvenientes ................................................................................................67 2.4 SERVICIOS WEB SEMANTICOS ...............................................................................................69

2.4.1 2.4.2

Introduccin.....................................................................................................................69 Lenguajes de descripcin ..................................................................................................71OWL S ( Web Ontology Language for Services)..................................................................... 71 WSMO (WEB SERVICE MODELING ONTOLOGY)...................................................................... 81 SWSF (Semantic Web Services Framework) ........................................................................... 85 WSDL-S (Web Service Semantics) .......................................................................................... 87 SAWSDL ( Semantic Annotation for WSDL and Schema) ......................................................... 90

2.4.2.1 2.4.2.2 2.4.2.3 2.4.2.4 2.4.2.5

2.4.3 2.4.4

Comparativa entre los lenguajes de descripcin ................................................................91 Estndares de clasificacin ...............................................................................................93UNSPSC (United Nations Standard Products and Services Code). ............................................ 93 NAICS (North American Industry Classification System).......................................................... 94 Emparejamiento sensible a la calidad .................................................................................... 97 Emparejamiento basado en restricciones ............................................................................ 100 Emparejamiento basado en acuerdos.................................................................................. 103 Emparejamiento basado en grados de similitud................................................................... 106 Lgicas Descriptivas ............................................................................................................ 108 Lgicas de Primer Orden ..................................................................................................... 108 Programacin Lineal ........................................................................................................... 109 Mtodos Ad Hoc................................................................................................................. 109

2.4.4.1 2.4.4.2

2.4.5

Emparejamiento Semntico .............................................................................................95

2.4.5.1 2.4.5.2 2.4.5.3 2.4.5.4

2.4.6

Formalismos de emparejamiento ................................................................................... 108

2.4.6.1 2.4.6.2 2.4.6.3 2.4.6.4

2.5 MODELADO DE PROCESOS.................................................................................................. 110 2.5.1 Introduccin................................................................................................................... 110 2.5.2 Procesos de Negocio ...................................................................................................... 111 2.5.3 Workflow ....................................................................................................................... 114 2.5.4 Sistema de Gestin del Flujo del Trabajo ( Workflow Management System) .................... 115 2.5.5 Modelo de referencia de Workflow................................................................................. 116 2.5.6 Especificacin de un Workflow ....................................................................................... 120 2.5.7 Composicin de servicios ................................................................................................ 121 2.5.8 BPM (Business Process Management) ............................................................................ 122 2.5.9 Estndares para la ejecucin de procesos ....................................................................... 1262.5.9.1 2.5.9.2 2.5.9.3 2.5.9.4 2.5.9.5 BPMN (Business Process Modeling Notation) ...................................................................... 126 YAWL (Yet Another Workflow Language) ............................................................................. 133 ebXML (eBusiness XML) ...................................................................................................... 134 BPEL (Business Process Execution Language) ....................................................................... 137 WS-BPEL (Web Services Business Process Execution Language) ............................................ 138

CAPITULO III .......................................................................................................................................142 3 TRABAJOS RELACIONADOS ........................................................................................................142

CAPITULO IV .......................................................................................................................................164 4 PROTOTIPO DESARROLLADO .....................................................................................................164 4.1 ARQUITECTURA DEL SISTEMA ..................................................................................................... 164 4.2 REPOSITORIO DE ONTOLOGAS DE DOMINIO .................................................................................. 165 4.3 REPOSITORIO DE ONTOLOGAS OWL-S......................................................................................... 170 4.3.1 Creacin de un servicio web ........................................................................................... 170 4.3.2 Descripcin semntica de los servicios Web .................................................................... 176 CAPITULO V ........................................................................................................................................187

5 6 7

CONCLUSIONES..........................................................................................................................225 OBSERVACIONES Y RECOMENDACIONES. ..................................................................................226 REFERENCIAS .............................................................................................................................227 7.1 7.2 REFERENCIAS WEB .................................................................................................................. 227 REFERENCIAS BIBLIOGRFICAS.................................................................................................... 229

8 9

GLOSARIO ..................................................................................................................................231 PRESUPUESTO ECONMICO. .....................................................................................................233

NDICE DE FIGURAS FigurasFIG. 1. FIG. 2. FIG. 3. FIG. 4. FIG. 5. FIG. 6. FIG. 7. FIG. 8. FIG. 9. FIG. 10. FIG. 11. FIG. 12. FIG. 13. FIG. 14. FIG. 15. FIG. 16. FIG. 17. FIG. 18. FIG. 19. FIG. 20. FIG. 21. FIG. 22. FIG. 23. FIG. 24. FIG. 25. FIG. 26. FIG. 27. FIG. 28. FIG. 29. FIG. 30.

PginaEJEMPLO DE INTERACCIN ENTRE SERVICIOS......................................................................22 ELEMENTOS DE UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) ................................30 COLABORACIONES EN SOA ..................................................................................................32 PAGINA HTML EN LA WEB ACTUAL ......................................................................................37 PAGINA WEB CON METADATOS ..........................................................................................37 COMPARACIN ENTRE LA WEB ACTUAL Y LA WEB SEMNTICA ..........................................38 ESTRUCTURA DE LA WEB SEMNTICA POR BERNERS-LEE ....................................................39 MAPA CONCEPTUAL DE LA WEB SEMNTICA ......................................................................41 VARIANTES DE WSML ..........................................................................................................52 ARQUITECTURA DE LOS SERVICIOS WEB..............................................................................57 ESTRUCTURA DE SOAP ........................................................................................................59 RELACIN ENTRE ORQUESTACIN Y COREOGRAFA DE SW.................................................64 EJEMPLO DE COREOGRAFA.................................................................................................65 EVOLUCIN DE LA WEB .......................................................................................................70 ESTRUCTURA DE LOS PROCESOS..........................................................................................74 ONTOLOGA DE ALTO NIVEL DE OWL-S ................................................................................75 OTROS ATRIBUTOS ..............................................................................................................78 ONTOLOGA DEL PROCESO DE ALTO NIVEL ..........................................................................81 ELEMENTOS DE WSMO ........................................................................................................82 ANOTACIN SEMNTICA DE LOS ELEMENTOS WSDL...........................................................88 MAPA CONCEPTUAL DE OFERTAS DE ACUERDO ................................................................103 EJEMPLO DE OFERTAS DE ACUERDO ..................................................................................105 EJEMPLO DE ACUERDO DE SERVICIO .................................................................................106 CARACTERIZACIN DE LOS WMS POR LA WFMC ...............................................................116 MODELO DE REFERENCIA DE WFMC ..................................................................................117 BPM COMO ENTORNO DE ORQUESTACIN ENTRE PERSONAS, PROCESOS Y SISTEMAS ....123 EVENTOS ...........................................................................................................................128 ACTIVIDAD ........................................................................................................................128 GATEWAY ..........................................................................................................................129 SEQUENCE FLOW ...............................................................................................................129

13

FIG. 31. FIG. 32. FIG. 33. FIG. 34. FIG. 35. FIG. 36. FIG. 37. FIG. 38. FIG. 39. FIG. 40. FIG. 41. FIG. 42. FIG. 43. FIG. 44. FIG. 45. FIG. 46. FIG. 47. FIG. 48. FIG. 49. FIG. 50. FIG. 51. FIG. 52. FIG. 53. FIG. 54. FIG. 55. FIG. 56. FIG. 57. FIG. 58. FIG. 59. FIG. 60. FIG. 61. FIG. 62. FIG. 63.

MESSAGE FLOW.................................................................................................................130 ASSOCIATION ....................................................................................................................130 POOL Y LANE .....................................................................................................................131 DATA OBJECT.....................................................................................................................132 GROUP ..............................................................................................................................133 ANNOTATION ....................................................................................................................133 RBOL GENEALGICO DE WS-BPEL ...................................................................................138 PROCESO DEFINIDO EN WS-BPEL .......................................................................................140 DIAGRAMA DE CASOS DE USOS. ........................................................................................144 ARQUITECTURA DEL SISTEMA............................................................................................145 INFRAESTRUCTURA DEL SISTEMA ......................................................................................147 NIVELES DEL MARCO DE TRABAJO HDM ............................................................................149 ARQUITECTURA DEL SISTEMA INDIGO ...............................................................................152 DIAGRAMA DE SECUENCIAS DEL FUNCIONAMIENTO DE INDIGO .......................................153 ARQUITECTURA GENERAL DEL SMA...................................................................................154 INTERFAZ GRAFICA DEL AGENTE USUARIO ........................................................................157 DIAGRAMA DE SECUENCIA DEL PROTOTIPO DESARROLLADO ...........................................159 ARQUITECTURA DE SUPER .................................................................................................161 ONTOLOGA DE ALTO NIVEL PARA PROCESOS DE NEGOCIO ORIENTADOS A SERVICIOS ....162 ARQUITECTURA DEL SISTEMA............................................................................................164 MODELO ENTIDAD-RELACIN PARA ONTOLOGAS DE DOMINIO.......................................166 MODELO RELACIONAL PARA ONTOLOGAS DE DOMINIO ..................................................167 CLASES PARA LAS ONTOLOGA DE DOMINIO .....................................................................168 PROPIEDADES PARA LAS ONTOLOGA DE DOMINIO ..........................................................168 INSTANCIAS DE LA CLASE ROL PARA UNA ONTOLOGA DE DOMINIO ................................169 RESTRICCIONES PARA LAS ONTOLOGAS DE DOMINIO ......................................................169 CREAR UN SERVICIO WEB ..................................................................................................171 AGREGAR UNA OPERACIN A UN SERVICIO WEB ..............................................................172 CREAR UNA NUEVA CONEXIN DE BASE DE DATOS ........ ERROR! MARCADOR NO DEFINIDO. LLENAR LOS CAMPOS PARA LA NUEVA CONEXIN DE BASE DE DATOS .............................173 NUEVA CONEXIN DE BASE DE DATOS CREADA ................................................................173 INSERTAR CDIGO PARA LA CONEXIN CON UNA BASE DE DATOS...................................174 INSERTAR CODIGO DE USE DATABASE ...............................................................................174

14

FIG. 64. FIG. 65. FIG. 66. FIG. 67. FIG. 68. FIG. 69. FIG. 70. FIG. 71. FIG. 72.

CDIGO JAVA DEL SERVICIO WEB CREADO........................................................................175 HABILITAR EL PLUGIN OWL-S EN PROTG .......................................................................177 IMPORTANDO WSDL PARA GENERAR LA DESCRIPCIN SEMNTICA DE UN SW. ...............178 INFORMACIN DEL WSDL IMPORTADO.............................................................................178 ELEMENTOS DE LAS DESCRIPCIN SEMNTICA GENERADOS.............................................179 EDITOR INDIVIDUAL DE PROCESS:PROCESS .......................................................................180 EDITOR INDIVIDUAL DE GROUNDING:WSDLGROUNDING .................................................181 EDITOR INDIVIDUAL DE PROFILE:PROFILE..........................................................................181 EDITOR INDIVIDUAL DE SERVICE:SERVICE..........................................................................182

15

NDICE DE TABLAS Tablas Pgina

TABLA 1. TABLA 2. TABLA 3. TABLA 4. TABLA 5.

TAXONOMAS DE CATEGORIZACIN. ..............................................................................63 TIPOS DE IDENTIFICADORES SOPORTADOS. ....................................................................64 FORTALEZAS Y DEBILIDADES DE LOS LENGUAJES DE DESCRIPCIN..................................93 EJEMPLO SISTEMA DE CLASIFICACIN UNSPSC ...............................................................94 EJEMPLO SISTEMA DE CLASIFICACIN NAICS ..................................................................95

16

LISTA DE ANEXOS Anexos Pgina

17

CAPITULO I

1.1

INTRODUCCIN

Los servicios web han logrado que la Web pase de ser un simple repositorio de informacin a una fuente de servicios accesibles desde cualquier lugar, pero la gran cantidad de servicios publicados y la inexistencia de informacin procesable por las maquinas hace inviable en tiempo y eficiencia que sea un usuario humano el que determine los servicios necesarios para satisfacer una necesidad, debido a esto se hace uso de la Ingeniera Ontolgica, la cual permite incluir informacin adicional que describe el contenido de los documentos, para implantar los servicios web semnticos.

Por otra parte, hoy da las organizaciones basan su estrategia en los procesos de negocio. Con la definicin explicita y el seguimiento de la ejecucin de los procesos se busca obtener resultados que pueden llegar a ser medidos y mejorados de manera constante.

Implementar los procesos de negocio mediante servicios web semnticos resulta provechoso ya que se beneficia de la descripcin de los servicios para su bsqueda automtica y el control centralizado de la invocacin de diferentes servicios con cierta lgica de negocio aadida.

18

1.2

JUSTIFICACION

Actualmente existe gran cantidad de datos publicados en la Web, lo cual dificulta a los usuarios la bsqueda de informacin, para darle solucin a esta problemtica se origino la web semntica, la cual propone incluir informacin que describa los contenidos que se publiquen en la web facilitando as su bsqueda.

De igual manera ocurre con los servicios web; cada vez se encuentran disponibles una gran cantidad de estos dificultando al usuario la bsqueda del servicio web adecuado, surgiendo de este modo los servicios web semnticos, que consisten en la fusin de los servicios web tradicionales y las tecnologas empleadas en la web semntica, que permiten a la maquina interpretar la informacin usando ontologas. Esta tecnologa permite describir los servicios web con contenido semntico de forma que el descubrimiento, composicin y ejecucin de servicios se pueda realizar de forma automtica por parte de entidades software.

Por otra parte, tenemos los procesos de negocio; que son un conjunto de tareas relacionadas lgicamente llevadas a cabo para lograr un resultado de negocio definido. Actualmente los procesos de negocio se llevan a cabo de forma manual, por lo cual son lentos e imprecisos.

Si se utiliza los servicios web semnticos para efectuar las tareas en los procesos de negocio se obtiene gran beneficio ya que no se necesitara intervencin humana, disminuyendo el tiempo de ejecucin de un negocio y garantizando las mejores elecciones, en otras palabras; el proceso de negocio se vuelve automtico.

19

1.3

NECESIDADES Y PROBLEMAS

A pesar de que en la actualidad existen en las organizaciones gran cantidad de equipos de cmputo y sus tecnologas asociadas, aun estos siguen utilizndose nicamente como herramientas auxiliares de almacenamiento y transmisin de informacin. Con el paso del tiempo han surgido nuevas tecnologas que posibilitan la implementacin de procesos autnomos dentro de la maquina, los cuales pueden llegar a evitar la utilizacin de grandes cantidades de trabajo y esfuerzo humano.

Generando as, considerables incrementos en la productividad de las organizaciones. Sin embargo, en este instante tales tecnologas no son del todo difundidas, lo cual presenta un grave problema ya que la masificacin en la automatizacin de los procesos de negocio se ha visto obstaculizada.

20

1.4

DELIMITACION

1.4.1 Objetivo general.

-

Utilizar los servicios web semnticos para automatizar procesos de negocio.

1.4.2 Objetivos especficos.

-

Estudiar las tecnologas existentes que permitan la automatizacin de procesos de negocio a travs de los servicios web semnticos.

-

Disear e implementar un prototipo que automatice un proceso de negocio usando servicios web semnticos.

-

Determinar la viabilidad de incorporar servicios web semnticos en la automatizacin de procesos de negocio, basados en los resultados obtenidos del prototipo implementado.

-

Elaborar un artculo cientfico donde se plasme el conocimiento adquirido.

21

CAPITULO 2 2 2.1 MARCO TEORICO SOA: ARQUITECTURA ORIENTADA A SERVICIOS

2.1.1 Definicin La arquitectura orientada a servicios es un paradigma para organizar y utilizar capacidades distribuidas que pueden estar controladas bajo diferentes propietarios e implementadas bajo diferentes tecnologas.

La arquitectura orientada a servicios define la base para que un conjunto de servicios independientes puedan colaborar entre s dando lugar a procesos de negocio ms complejos.

Fig. 1. Ejemplo de interaccin entre servicios

SOA permite la creacin de sistemas altamente escalables que reflejan el negocio de la organizacin, a su vez brinda una forma bien definida de

22

exposicin e invocacin de servicios, lo cual facilita diferentes sistemas propios o de terceros.

La definicin del consorcio OASIS propone que SOA es un paradigma para organizar y utilizar capacidades distribuidas que pueden encontrarse bajo el control de diferentes dominios de propiedad. Proporciona un mecanismo uniforme para ofrecer, descubrir, interaccionar con y usar las capacidades para producir los efectos deseados de forma consistente con precondiciones y expectaciones medibles1.

Posee las siguientes capas de software: Aplicaciones bsicas: Sistemas desarrollados bajo cualquier arquitectura o tecnologa, geogrficamente dispersos y bajo cualquier figura de propiedad. De exposicin de funcionalidades: donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (servicios web). De integracin de servicios: Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboracin. De composicin de procesos: que define el proceso en trminos del negocio y sus necesidades, y que vara en funcin del negocio. De entrega: donde los servicios son desplegados a los usuarios finales.

1

http://www.oasis-open.org/committees/download.php/19679/soa-rmcs.pdf

23

SOA proporciona una metodologa y un marco de trabajo para documentar las capacidades del negocio y puede dar soporte a las actividades de integracin y consolidacin. SOA es una forma de arquitectura de sistemas distribuidos que est caracterizada generalmente por las siguientes propiedades:

Vista lgica: El servicio es una vista abstracta y lgica de programas reales, bases de datos, procesos de negocio, etc., definida en trminos de que hace (nada se define respecto al como se hace) y, normalmente, llevando a cabo una operacin de la lgica de negocio.

Orientado a mensajes: El servicio est formalmente definido como un intercambio de mensajes entre entidades suministradoras de servicios y entidades en si (estructura interna, lenguaje de programacin, estructura del proceso, etc.). Esta caracterstica cobra mayor importancia cuando se pretende interaccionar con sistemas heredados (legacy systems) ya que, al abstraerse de cualquier conocimiento relacionado con la estructura interna de una entidad software, cualquier componente software que permita ser accedido por medio de un sistema basado en mensajes, podr ser utilizado por medio de servicios.

Orientado a la descripcin: Un servicio se describe a travs de metadatos procesables por el ordenador. La descripcin da soporte a la naturaleza pblica de SOA: solo aquellos detalles que se exponen pblicamente y que son importantes para la utilizacin del servicio, deben ser incluidos en la descripcin.

Granularidad: Los servicios tienden a utilizar pocas operaciones con mensajes relativamente largos y complejos.

24

Orientado a la red: Los servicios tienden a ser orientados hacia el uso sobre una red de comunicaciones, aunque este no es un requisito indispensable.

Independiente de la plataforma: Los mensajes se envan en un formato estandarizado e independiente de la plataforma XML.

2.1.2 Diseo y desarrollo de SOA

La metodologa de modelado y diseo para aplicaciones SOA se conoce como Diseo y anlisis orientado a servicios o SOAD (Service-oriented analysis and design).SOAD es una metodologa de diseo para desarrollo de sistemas muy agiles en un modelo cliente/productor donde se abstrae la implementacin de el proceso actual, de manera que el servicio provisto pueda ser modificado o cambiado sin afectar al cliente. Bsicamente se debe estructurar un contrato de servicios que debe contener los siguientes componentes:

Encabezado Nombre del servicio Versin del contrato del servicio Propietario: Persona o equipo encargados del servicio. RACI

Responsable de los entregables del contrato/servicio.

25

Accountable (Dueo): Nivel mximo de escalamiento en trminos del contrato/servicio.

Consultado: Quien debe ser consultado antes de tomar cualquier accin sobre el presente contrato/servicio.

Informado: Quien debe ser informado sobre cualquier decisin o accin que se vaya a tomar sobre el presente contrato/servicio.

Tipo: Es el tipo de servicio, ayuda a distinguir en que capa residir: Datos

Procesos Funcionalidad

Presentacin Funcionalidad

Requerimientos

funcionales:

Indica

especficamente

la

funcionalidad que este servicio debe proveer. El lenguaje debe permitir la generacin de casos de prueba sobre funcionalidad.

Operacin del servicio: Se debe definir en trminos de que parte de la funcionalidad se provee (mtodos usados, acciones etc.).

26

Invocacin: Indica los medios como se invoca o llama al servicio, este puede ser URL, interface, triggers etc. Pueden existir mltiples caminos para invocar un mismo servicio.

Requerimientos no funcionales, tales como:

Seguridad: Roles, mecanismos de invocacin etc.

Calidad del servicio: Determina el nivel de tolerancia de fallos del servicio. Transaccionales: Es este servicio capaz de realizar gran cantidad de transacciones? Cuantas? Bajo qu condiciones?

ANS (Acuerdos de nivel de servicios) o SLA: Determina la mxima latencia permitida para el servicio bajo la cual se pueden realizar acciones.

Semntica: define el glosario de trminos usados en la descripcin e interfaces del servicio.

Procesos: describe los procesos (si existen) relacionados con el contrato de servicios.

La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementacin. Para que un proyecto SOA tenga xito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son

27

orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en trminos de planificacin, herramientas e infraestructura.

Cuando se hace referencia a una arquitectura orientada a servicios se trata de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estndares relacionados a los servicios web:

XML: Un lenguaje de etiquetas para describir datos en mensajes en formato de documento. HTTP o HTTPS: Protocolo para solicitar o responder mensajes entre clientes y servicios. SOAP: Protocolo para intercambiar mensajes basados en XML en una red de computadores, usualmente usando HTTP. WSDL o Lenguaje de descripcin de servicios web: Servicio basado en XML que describe las interfaces pblicas, protocolos y formato de mensajes, requeridos para interactuar con un servicio web. UDDI o Descripcin, descubrimiento e Integracin Universal: Registro basado en XML para publicar descripciones de servicios (WSDL) y permitir su descubrimiento.

Un sistema SOA no necesariamente necesita utilizar estos estndares para ser orientado a servicios pero es altamente recomendable su uso. En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayora de las definiciones de SOA identifican la utilizacin de Servicios Web (empleando SOAP y WSDL) en su

28

implementacin, no obstante se puede implementar SOA utilizando cualquier tecnologa basada en servicios. Por otro lado, la implementacin ideal de un servicio exige resolver algunos inconvenientes tcnicos inherentes a su modelo: Los tiempos de llamado no son despreciables, gracias a la comunicacin de la red, tamao de los mensajes, etc. Esto necesariamente implica la utilizacin de mensajera confiable. La respuesta del servicio es afectada directamente por aspectos externos como problemas en la red, configuracin, etc. Estos deben ser tenidos en cuenta en el diseo, desarrollndose mecanismos de contingencia que eviten la parlisis de las aplicaciones y servicios que dependen de l. Comunicaciones no confiables, mensajes impredecibles, reintentos, mensajes fuera de secuencia, etc.

A su vez, cuando se usan mltiples servicios para implementar un sistema, es muy fcil que la comunicacin entre estos se salga de control. Por ejemplo, se puede tener un servicio que llama a otros seis servicios, algunos de los cuales llaman a otros servicios, y de esta manera, muy fcilmente el sistema se vuelve inmanejable. De esta forma, un sistema grande puede terminar con mltiples dependencias. Detectar un problema de rendimiento o funcionalidad se puede volver muy complicado.

Segn esto, si no se cuenta con una estrategia adecuada, se puede llegar a una implementacin donde exista una explosin de dependencias entre los diferentes servicios.

Una solucin a este problema es extraer los aspectos de procedimiento de varios servicios dentro de uno dedicado, llamado servicio de negocio. As, un

29

servicio de negocio centraliza la definicin del proceso, disminuyendo las dependencias entre servicios y las aplicaciones clientes, ayudando a su vez a facilitar la administracin del sistema. 2.1.3 Elementos de SOA

Esta arquitectura presenta una forma de construir sistemas distribuidos que entreguen a la aplicacin funcionalidad como servicios para aplicaciones de uso final u otros servicios. En la figura 2 se muestra el stack de la arquitectura y los elementos que podran observarse en una arquitectura orientada a servicios.

Fig. 2. Elementos de una arquitectura orientada a servicios (SOA)

Como se puede observar, se diferencias dos zonas en el stack, una que abarca los aspectos funcionales de la arquitectura y otra que abarca aspectos de calidad de servicio. Funciones:

Transporte: es el mecanismo utilizado para llevar las demandas de servicio desde un consumidor de servicio hacia un proveedor

30

de servicio, y las respuestas desde el proveedor hacia el consumidor.

Protocolo de comunicacin de servicios: es un mecanismo acordado a travs del cual un proveedor de servicios y un consumidor de servicios comunican que est siendo solicitado y que est siendo respondido. Descripcin de servicio: es un esquema acordado para describir que es el servicio, como debe invocarse, y que datos requiere el servicio para invocarse con xito. Servicios: describe un servicio actual que est disponible para utilizar. Procesos de negocio: es una coleccin de servicios, invocados en una secuencia particular con un conjunto particular de reglas, para satisfacer un requerimiento de negocio. Registro de servicios: es un repositorio de descripciones de servicios y datos que pueden utilizar proveedores de servicios para publicar sus servicios, as como consumidores de servicios descubrir o hallar servicios disponibles. Calidad de Servicio

Poltica: es un conjunto de condiciones o reglas bajo las cuales un proveedor de servicio hace el servicio disponible para

consumidores. Seguridad: es un conjunto de reglas que pueden aplicarse para la identificacin, autorizacin y control de acceso a consumidores de servicios.

31

Transacciones: es el conjunto de atributos que podran aplicarse a un grupo de servicios para entregar un resultado consistente. Administracin: es el conjunto de atributos que podran aplicarse para manejar los servicios proporcionados o consumidos.

Las colaboraciones en SOA siguen el paradigma find, bind and invoke, donde un consumidor de servicios realiza la localizacin dinmica de un servicio consultando el registro de servicios para hallar uno que cumpla con un determinado criterio. Si el servicio existe, el registro proporciona al consumidor la interfaz de contrato y la direccin del servicio proveedor.

El siguiente diagrama ilustra las entidades (roles, operaciones y artefactos) en una arquitectura orientada a servicios donde estas colaboran.

Fig. 3. Colaboraciones en SOA

Cada entidad puede tomar el rol de consumidor, proveedor y/o registro: Un consumidor de servicios es una aplicacin, un modulo de software u otro servicio que requiere un servicio, y ejecuta el servicio de acuerdo a un contrato de interfaz.

32

Un proveedor de servicios es una entidad direccionable a travs de la red que acepta y ejecuta consultas de consumidores, y publica sus servicios y su contrato de interfaces en el registro de servicios para que el consumidor de servicios pueda descubrir y acceder al servicio. Un registro es el encargado de hacer posible el descubrimiento de servicios, conteniendo un repositorio de servicios disponibles y permitiendo visualizar las interfaces de los proveedores de servicios a los consumidores interesados.

Las operaciones son: Publicar: para poder acceder a un servicio se debe publicar su descripcin para que un consumidor pueda descubrirlo e invocarlo. Descubrir: un consumidor de servicios localiza un servicio que cumpla con un cierto criterio consultando el registro de servicios. Ligar e Invocar: una vez obtenida la descripcin de un servicio por parte de un consumidor, este lo invoca de acuerdo a la informacin en la descripcin del servicio.

Finalmente, los artefactos en una arquitectura orientada a servicios son: Servicio: un servicio que est disponible para el uso a travs de una interfaz publicada y que permite ser invocado por un consumidor de servicios. Descripcin de servicio: una descripcin de servicio especfica la forma en que un consumidor de servicio interacta con el proveedor de servicio, especificando el formato de consultas y respuestas desde el

33

servicio. Esta descripcin tambin puede especificar el conjunto de precondiciones, post-condiciones y/o niveles de calidad de servicio (QoS). 2.1.4 Ventajas de una arquitectura orientada a servicios

Exponer procesos de negocio como servicios es la clave a la flexibilidad de la arquitectura. Esto permite que otras piezas de funcionalidad (incluso tambin implementadas como servicios) hagan uso de otros servicios de manera natural, sin importar su ubicacin fsica. As un sistema evoluciona con la adicin de nuevos servicios y su mejoramiento, y donde cada servicio evoluciona de una manera independiente.

La arquitectura orientada a servicios (SOA) resultante, define los servicios de los cuales estar compuesto el sistema, sus interacciones, y con qu tecnologas sern implementados. Las interfaces que utiliza cada servicio para exponer su funcionalidad son gobernadas por contratos, que definen claramente el conjunto de mensajes soportados, su contenido y las polticas aplicables.

SOA es una filosofa que establece un marco de diseo de software basado en mdulos flexibles que pueden ser reutilizados, y que funcionan sobre cualquier plataforma de hardware y sistema operativo permitiendo un mayor

aprovechamiento del cdigo, creando aplicaciones que respondan ms rpido a las necesidades del negocio y a las oportunidades del mercado. La filosofa busca solucionar las necesidades de servicios que demandan los usuarios basados en las aplicaciones que ya tiene la empresa.

Los principales beneficios que puede obtener una organizacin que adopte SOA son:

34

Mejora en los tiempos de realizacin de cambios en procesos. Facilidad para evolucionar a modelos de negocios basados en tercerizacin. Facilidad para abordar modelos de negocios basados en colaboracin con otros entes (socios, proveedores). Poder para reemplazar elementos de la capa aplicativa SOA sin disrupcin en el proceso de negocio. Facilidad para la integracin de tecnologas disimiles. 2.2 WEB SEMANTICA

2.2.1 Antecedentes La aparicin de la WWW se puede situar en 1989 cuando Tim Berners-Lee presento su proyecto de World Wide Web en el CERN (suiza), con las caractersticas esenciales que perduran en nuestros das, y cambio radicalmente el modo en que la gente recopila informacin y accede a esta. Hoy en da, la WWW se ha convertido en un gigantesco repositorio de informacin en continuo crecimiento y al que se puede acceder desde cualquier punto con el nico requisito de disponer de un navegador web. Actualmente se encuentran indexadas ms de 20 billones de pginas2 por los distintos buscadores existentes, de forma que la bsqueda de un dato concreto se ha convertido en uno de los mayores cuellos de botella de la WWW. Un clsico ejemplo para presentar este problema es el de la bsqueda de informacin concerniente a la isla de Java; si escribiramos en un buscador cualquiera la consulta Java nos apareceran cientos de miles de pginas que

2

http://www.worldwidewebsize.com/

35

nada tienen que ver con lo que el usuario est buscando realmente, la isla de Java, si no que la mayora se referirn al lenguaje de programacin JavaTM.

La principal limitacin de la web actual es el hecho de que las tecnologas que la conforman no son capaces de capturar, o representar formalmente, la semntica del contenido presentado. La web semntica surgi con el propsito de restringir estos efectos nocivos causados por el crecimiento del nmero de pginas publicadas en la WWW. 2.2.2 Fundamentos de la web semntica

El trmino Web Semntica fue presentado al dominio pblico tras la publicacin del artculo The Semantic Web aparecido en Scientific American en mayo de 2001 y del que fueron coautores Tim Berners-Lee, James Hendler y Ora Lassila.

En este articulo se establecen diversos escenarios imaginarios en los que agentes software son capaces de realizar numerosas tareas accediendo al contenido de diferentes paginas de la WWW. Los autores sealan que para que este escenario sea factible, debera cambiar la manera de representar contenido en la web para incluir una semntica bien definida que permitiese a componentes software acceder al mismo.

La web semntica aade metadatos semnticos a los datos publicados en la WWW de forma que las entidades software puedan procesar el contenido de forma similar a como lo hacen los humanos. El termino metadato se refiere a ofrecer datos sobre datos, de forma que el significado de los datos es capturado.

36

Fig. 4. Pagina HTML en la Web actual

Una entidad software puede hacer bsquedas basadas en palabras clave que identifiquen palabras como fisioteraputico, horas de consulta, etc., pero tendr problemas para identificar al personal y distinguir entre los fisioterapeuta y la secretaria. La web semntica propone modificar la forma en que se presentan los contenidos en la Web de modo que no solo se indique informacin para formatear el contenido, sino que tambin se incluya informacin que describa este contenido.

Siguiendo el ejemplo de la figura 4, el cdigo quedara como se presenta a continuacin. Esta representacin mediante metadatos hace mucho ms sencillo para las maquinas el procesamiento de informacin.

Fig. 5. Pagina Web con metadatos

37

En la siguiente figura se puede observar la evolucin que ha tenido lugar en cuanto a la estructuracin de los contenidos en la Web tradicional y en la Web Semntica. Si la conexin entre recursos en la Web tradicional se produce a travs de enlaces nicamente entendibles por usuarios humanos (aunque no en todos los casos), la estructura de la Web Semntica se basa en relaciones semnticas que son capaces de interpretar tanto humanos como entidades software.

Fig. 6. Comparacin entre la web actual y la web semntica

La aproximacin de la Web Semntica a la estructuracin de la informacin se basa en la utilizacin de ontologas como mecanismo para la representacin del conocimiento. Las ontologas se utilizan para aportar un vocabulario que describa las relaciones entre diferentes trminos, permitiendo a los sistemas computarizados (y a los humanos) interpretar su contenido flexiblemente y sin ambigedades. 2.2.3 Arquitectura de la web semntica

El desarrollo de la Web Semntica se est produciendo en forma de capas, de modo que el desarrollo de nuevas capas se realice sobre las ya existente.

38

Fig. 7. Estructura de la Web Semntica por Berners-Lee

Berners-Lee propone un esquema de siete capas sobre la web semntica, el cual le permitir dejar de ser una coleccin de documentos para convertirse en una base de conocimientos, cada una de estas capas le aporta una serie de funcionalidades a la siguiente de abajo hacia arriba:

En la primera capa se encuentran los Unicode y las URI, los primeros permiten que la informacin de la web semntica pueda expresarse en cualquier idioma y las URI permiten de forma inequvoca identificar cada recurso en internet. La segunda capa ofrece los mecanismos bsicos que permiten a los distintos participantes comunicarse entre s, utilizando como sintaxis comn el lenguaje XML, los nombres de espacio y un esquema XML para definir la estructura de los documentos. En ella se encuentran agrupadas las diferentes tecnologas que posibilitan la comunicacin entre agentes.

RDF Resource Description Framework + RDF Schema: RDF ofrece la posibilidad de definir sentencias basadas en tripletas de la forma sujetopredicado-valor, que permiten establecer descripciones sobre recursos. RDF Schema (RDFS) amplia a RDF mediante una capa semntica de mayor expresividad, que incorpora entre otras caractersticas, relaciones de herencia y restricciones.

39

Las ontologas permiten clasificar la informacin. Esta capa permite extender la funcionalidad de la Web Semntica agregando nuevas propiedades y clases para describir los recursos.

Una capa lgica que permita realizar consultas e inferir conocimiento, donde entraran en juego las ontologas y los agentes software. Las demostraciones permite ejecutar las reglas de la capa de lgica y comprobar su validez.

Las firmas digitales permiten a las diferentes capas, garantizar que la informacin intercambiada entre agentes o agentes y usuarios, se haga de forma confidencial e integra.

Y por ltimo la capa de seguridad permite asignar niveles de fiabilidad a determinados recursos, de forma comprobable posteriormente por los agentes, para lo que se usarn firmas digitales y redes de confianza.

40

Fig. 8. Mapa conceptual de la Web Semntica

41

2.2.4 Tecnologas y Lenguajes 2.2.4.1 URI Los URI (Uniform Resource Identifier), cuyo subconjunto ms conocido son los URL (Uniform Resource Locator), es una cadena corta de caracteres que proporcionan el mecanismo para identificar de forma inequvoca cualquier recurso en la red: artculos, imgenes, sonidos, etc.

Con la web semntica, los URIs cumplirn adems con la funcin de identificadores de objetos del mundo real. Cualquier objeto podr ser identificado mediante un URI: nuestro microondas tendr una URI asociado, el URI de nuestra web personal o de nuestra direccin e-mail nos identificara a nosotros, la funcin que realizamos en nuestro trabajo se expresara mediante un URI.

Una URI consta de las siguientes partes: Esquema: Nombre que se refiere a una especificacin para asignar los identificadores, eg. Urn:, tag:, cid: . en algunos casos tambin identifica el protocolo de acceso al recurso, por ejemplo http:, mailto:, ftp:. Autoridad: Elemento jerrquico que identifica la autoridad de nombres (por ejemplo //es.wikipedia.org). Ruta: Informacin usualmente organizada en forma jerrquica, que identifica al recurso en el mbito del esquema URI y la autoridad de nombres (e.g. /wiki/Uniform_Resource_Identifier). Consulta: Informacin con estructura no jerrquica (usualmente pares clave=valor) que identifica al recurso en el mbito del esquema URI y la autoridad de nombres. El comienzo de este componente se indica mediante el carcter ?.

42

Fragmento: Permite identificar una parte del recurso principal, o vista de una representacin del mismo. El comienzo de este componente se indica mediante el carcter #. 2.2.4.2 XML

XML (lenguaje de marcas extensible)

es un metalenguaje extensible de

etiquetas desarrollado por el World Wide Web Consortium (W3C) que ofrece informacin.

XML no ha nacido slo para su aplicacin en Internet, sino que se propone como un estndar para el intercambio de informacin estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de clculo y casi cualquier cosa imaginable.

La tecnologa XML busca dar solucin al problema de expresar informacin estructurada de la manera ms abstracta y reutilizable posible. Que la informacin sea estructura quiere decir que se compone de partes bien definidas, y que esas partes se componen a su vez de otras partes, dichas partes se llaman elementos, y se las seala mediante etiquetas. Una etiqueta consiste en una marca hecha en el documento , que seala una porcin de este como un elemento. Un pedazo de informacin con un sentido claro y definido. Las etiquetas tienen la forma , donde nombre es el nombre del elemento que se est sealando.

XML tiene cuatro secciones: Comentarios: A modo informativo para el programador que han de ser ignorados por el procesador. Secciones CData: Es una construccin en XML para especificar datos utilizando cualquier carcter sin que se interprete como marcado XML.

43

No confundir con 2 (#PCDATA) que es para los elementos. Permite que caracteres especiales no rompan la estructura. Elementos: Los elementos XML pueden tener contenido(mas elementos, caracteres o ambos), o bien ser elementos vacios. Referencias a entidades: XML hace referencia a objetos que no deben ser analizados sintcticamente segn las reglas XML, mediante el uso de entidades. Las entidades pueden ser Internas o externas, Analizadas o no analizadas y generales o parametrizadas.

El lenguaje XML tiene la ventaja de ser extensible con la adicin de nuevas etiquetas, de modo que se pueda continuar utilizando sin complicacin alguna, adems no es necesario crear un analizador especfico para cada versin de lenguaje XML, esto posibilita el empleo de cualquiera de los analizadores disponibles y de esta manera se evitan bugs y se acelera el desarrollo de aplicaciones, y si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarla.

2.2.4.3 Ontologas

Una ontologa es un sistema de representacin del conocimiento que contiene un vocabulario de conceptos as como las relaciones entre estos conceptos. Las ontologas definen de forma estndar los trminos y sus relaciones dentro de un determinado dominio o rea del conocimiento, formando redes jerrquicas semnticas.

44

El conocimiento en ontologas se formaliza usando seis tipos de componentes: Las clases pueden ser algo sobre lo que se dice algo, como por ejemplo un tipo de objeto, la descripcin de una tarea, funcin, etc. Las clases en la ontologa se suelen organizar en taxonomas. Los atributos representan la estructura interna de los conceptos. Atendiendo a su origen, los atributos se clasifican en especficos y heredados; los especficos son aquellos propios del concepto al que pertenecen, mientras que los heredados vienen dados por las relaciones taxonmicas en las que el concepto desempea el rol de hijo y, por tanto, hereda los atributos del padre. Los atributos vienen caracterizados por el dominio en el cual pueden tomar valor. Las relaciones representan un tipo de interaccin entre los conceptos del dominio. Se definen como cualquier subconjunto de un producto de n conjuntos. Entre los distintos tipos de relaciones posibles se encuentran las relaciones taxonmicas (es_un) y las mereolgicas o partonomicas (parte_de) como relaciones binarias ms destacadas. Las funciones son un tipo especial de relaciones en las que el n-simo elemento de la relacin es nico para los n-1 precedentes. Los axiomas son expresiones que son siempre ciertas. Pueden ser incluidas en una ontologa con muchos propsitos, tales como definir el significado de los componentes ontolgicos, definir restricciones complejas sobre los valores de los atributos, argumentos de relaciones, etc., verificando la correccin de la informacin especificada en la ontologa o deduciendo nueva informacin. Las instancias son las ocurrencias en el mundo real de los conceptos. En una instancia todos los atributos del concepto tienen asignado un valor concreto.

45

Las ontologas describen toda la informacin necesaria para automatizar los descubrimientos, las composiciones y las ejecuciones. 2.2.4.4 Lenguajes para representacin de ontologas

2.2.4.4.1 RDF (Resource Description Framework) RDF es un lenguaje para la representacin de la informacin sobre los recursos en la web definido con una semntica bsica que puede representarse mediante XML.

El modelo de datos de RDF est basado en tripletas, cada una de las cuales est formada por: Sujeto: Identifica al recurso (persona, lugar o cosa) que la sentencia escribe. Un recurso RDF puede ser cualquier cosa en un modelo de datos (documento, usuario, producto, etc.). A cada recurso se le asigna un identificador nico en forma de URI. Predicado: Representa una propiedad (nombre, ciudad, titulo, color, forma, caracterstica) del sujeto (persona, lugar o cosa). Al igual que los sujetos, cada propiedad viene identificada por medio de una URI nica. Objeto: Especifica el valor (Pedro, Madrid, azul, duro) para la propiedad (nombre, ciudad, titulo, color, forma, caracterstica) del sujeto (persona, lugar o cosa).

La informacin almacenada por medio de tripletas RDF se puede representar a partir de grafos.

46

2.2.4.4.2 RDF Schema

Es una extensin semntica de RDF. Un lenguaje para representar informacin en la Web que provee un vocabulario XML a travs del cual expresar clases y sus relaciones, al tiempo que se definen propiedades y se asocian las mismas con clases. De este modo RDFS facilita mejoras en los procesos de bsqueda y permite hacer inferencias.

Las clases definidas por RDFS pueden representar casi cualquier categora de cosas, como pginas web, gente, tipos de documentos, conceptos abstractos, etc.

Las clases bsicas son: rdfs:Class. Permite declarar recursos como clases para otros recursos. rdf:Resource. Es la clase a la que pertenecen todos los recursos. rdfs:Literal. Es la clase de todos los valores literales, cadenas y enteros. rdfs:Datatype. Es la clase que abarca los tipos de datos definidos en el modelo RDF.

Las clases que definen relaciones son: rdfs:subClassOf. Es una instancia de rdf:Property que permite definir jerarquas. Relaciona una clase con sus superclases. rdfs:subPropertyOf. Es una instancia de rdf:Property que permite definir jerarquas de propiedades.

47

Las clases que representan restricciones de propiedades son: rdfs:domain. Es una instancia de rdf:Property que especifica el dominio de una propiedad P, rdfs:Property. Esto es, la clase de los recursos que aparecen como objetos en las tripletas donde P es predicado. rdfs:range. Es una instancia de rdf:Property que especifica el rango de una propiedad P, rdfs:range. Esto es, la clase de los recursos que aparecen como objetos en las tripletas donde P es predicado.

Otras clases: rdfs:ContraintResource. rdfs:ContraintProperties. rdfs:seeAlso. rdfs:isDefinedBy. rdfs:label. Rdfs:comment.

Los recursos que pertenecen a una clase son llamados instancias, una clase es cualquier recurso que tenga un tipo (rdf: type) como propiedad cuyo valor sea un recurso rdfs: Class.

48

2.2.4.4.3 OWL (Web Ontology Language)

OWL es un lenguaje de marcado para publicar y compartir datos usando ontologas en la WWW que tiene como objetivo facilitar un modelo de marcado construido sobre RDF y codificado en XML3.

El Lenguaje de Ontologas para la Web, recomendacin del W3C,

est

diseado para usarse cuando la informacin contenida en los documentos necesita ser procesada por programas o aplicaciones, en oposicin a situaciones donde el contenido solamente necesita ser presentado a los seres humanos.OWL puede usarse para representar explcitamente el significado de trminos en vocabularios y las relaciones entre aquellos trminos. Esta representacin de los trminos y sus relaciones se denomina una ontologa. En realidad, OWL es una extensin del lenguaje RDF y emplea las tripletas de RDF, aunque es un lenguaje con ms poder expresivo que este.

Algunas de las posibilidades adicionales que proporciona el vocabulario de OWL sobre el de sus predecesores son: Definicin de clases mediante restricciones sobre propiedades, valores o cardinalidad. Definicin de clases mediante operaciones booleanas sobre otras clases: interseccin, unin y complemento. Relaciones entre clases (p. eje. Inclusin, disyuncin, equivalencia). Propiedades de las relaciones (p. eje. Inversa, simtrica, transitiva). Cardinalidad. Igualdad y desigualdad de clases.3

http://es.wikipedia.org/wiki/OWL

49

Clases enumeradas.

Estas caractersticas mejoran el poder expresivo del lenguaje pero tambin limitan la capacidad de los razonadores para inferir nuevo conocimiento a partir de unas sentencias dadas. En particular no se puede garantizar ni la

completitud computacional, que el razonador encuentre todas las conclusiones validas, ni la decidibilidad computacional, que se obtenga la respuesta para cualquier entrada en un periodo de tiempo finito. Esto llevo a la creacin de tres variantes de OWL que presentan diferentes estados en la relacin expresividad/decidibilidad. De menor capacidad expresiva y mayor eficiencia de razonamiento a mayor capacidad expresiva y menor eficiencia de

razonamiento, estos son: OWL Lite: La versin ms simple para los programadores principiantes, permite la jerarqua de clasificacin y restricciones simples. OWL DL: Esta versin tiene todo el vocabulario

OWL completo, es el

indicado para los usuarios que requieren el mximo de expresividad, mientras conservan completamente la propiedad de ser computable (se garantiza que todas las conclusiones son computables) y resoluble (todos los clculos terminaran en tiempo finito). OWL Full: Esta versin tambin incluye todo el vocabulario OWL pero en este caso no hay limitaciones para explotar todo su potencial, permite la mxima expresividad y ofrece la libertad sintctica de RDF pero no asegura la propiedad de ser computable. 2.2.4.4.4 WSML( Web Services Modeling Language)

WSML o lenguaje de modelado de servicios web, es una familia de lenguajes de representacin para la web semntica recomendado por el W3C que provee

50

una sintaxis formal y una semntica para el modelado de ontologas de servicios web (Web Service Modeling Ontology WSMO-).

WSML se especifica en trminos de una sintaxis normativa legible por seres humanos, tambin tiene una sintaxis XML y RDF para el intercambio sobre la web y para la interoperabilidad con aplicaciones basadas en RDF. Tambin es posible el mapeo entre ontologas WSML y ontologas OWL para interoperar con ontologas OWL por medio de un subconjunto semntico comn de OWL y WSML.

WSML est basado en diferentes lgicas formales: Lgica de descripcin Lgica de primer orden Lgica de programacin

Cada una de ellas, se usan para el modelado de servicios de la web semntica. WSML consta de un nmero de variantes basadas en estas diferentes lgicas formales: WSML-Core: se basa en la interseccin de la lgica descriptiva SHIQ y lgica de Horn, basado en programas lgico-descriptivos. Es la variante de WSML que ofrece menor expresividad. Entre las caractersticas principales de este lenguaje, destacan los conceptos, atributos, relaciones binarias y las instancias. Tambin se permite la jerarqua de concepto y relaciones, y se da soporte a los tipos de datos. WSML-DL: captura la lgica descriptiva SHIQ(D), una parte muy importante de la variante DL de OWL. Adems, incluye una extensin en

51

los tipos de datos basada en OWL-DL que permite el uso de tipos de datos ms complejos. WSML-Flight: Es una extensin de WSML-Core que proporciona un lenguaje de reglas muy expresivo. Aade caractersticas como metamodelado, restricciones y negacin no-montona. WSML-Flight se basa en una variante de programacin lgica de F-Logic y es equivalente semnticamente a Datalog con desigualdad y negacin estratificada. WSML-Rule: Extiende WSML-Flight con ms caractersticas

provenientes de la programacin lgica como el uso de smbolos de funcin y reglas inseguras. WSML-Full: Unifica WSML-DL y WSML-Rule bajo el soporte de la logia de primer orden y con extensiones para soportar la negacin nomontona de WSML-Rule.

Fig. 9. Variantes de WSML

2.2.5 Ventajas e inconvenientes

Entre las ventajas que pretende aportar la Web Semntica podemos destacar las siguientes:

52

Ahorro de tiempo en el procesado de los datos (tiempo de bsqueda, gestin de la informacin, etc.): la mayor parte de las tareas relativas al procesado de datos podrn realizarse por parte de componentes software automatizado y sin requerir, en muchos casos, intervencin humana. Resultados ms adecuados de bsqueda: se mejorara la precisin de las bsquedas en Web, debido a que el contenido de las pginas Web estar anotado semnticamente y, por tanto, los motores de bsqueda sern capaces de obtener aquellos resultados que ms se adecuen a la consulta del usuario. En particular, los motores de bsqueda podrn buscar paginas que se refieran a un determinado concepto de una ontologa, al contrario de lo que ocurre ahora, devolviendo todas aquellas pginas que contienen una palabra clave que, en muchos casos, es ambigua.

Mejora de la comunicacin entre servicios web: la comunicacin entre distintos componentes y servicios, sobre todo en aquellos casos en los que los componentes no han sido diseados para trabajar

conjuntamente, ha sido siempre fuente de problemas en cuanto a la interoperabilidad debido, principalmente, a la ambigedad del lenguaje. El uso de ontologas compartidas (y, posiblemente, mapeadas con otras ontologas) propuesto por la web semntica, solventa el problema en la comunicacin entre servicios web gracias a que esta comunicacin se produce utilizando conceptos pertenecientes a una ontologa.

La web semntica mantiene los principios que han contribuido al xito de la web actual, como son los principios de descentralizacin, comparticin, compatibilidad, mxima facilidad de acceso y contribucin, o la apertura al crecimiento y uso no previstos de antemano. Sin embargo existen ciertos

53

problemas que deben solucionarse para alcanzar todo el potencial que se le supone a la web semntica.

En primer lugar, la aparicin de la web semntica supondr mayor trabajo para los creadores de pginas web ya que estas debern estar anotadas semnticamente. Por tanto, es crtico el desarrollo de herramientas que permitan a usuarios no experimentados la creacin de pginas para la nueva web semntica con la misma facilidad con la que estos lo pueden hacer para la web tradicional. Adems en relacin con la necesidad de usar reglas de inferencia, aunque se han utilizado mucho en el rea de la I.A. no han funcionado del todo bien salvo en el caso de dominios muy especficos y limitados.

Otro de los inconvenientes de la web semntica son los efectos que puede producir en relacin a la privacidad y la censura. En la actualidad, las tcnicas de anlisis de textos utilizadas por los gobiernos para controlar los contenidos de la web son vulnerables a simples modificaciones de palabras (usando, por ejemplo, metforas) o al uso de imgenes en vez de texto consiguiendo, de esta forma, limitar las posibilidades de censura.

En la web semntica sera mucho ms sencillo controlar la creacin y visualizacin de contenidos web. Adems, la aplicacin de propuestas como FOAF (Friend of a Friend), que permite la definicin semntica de perfiles de usuario y redes sociales, supondra una limitacin severa al anonimato en la web. Si los investigadores en web semntica son capaces de eliminar esta problemtica, no cabe duda de que esta tecnologa supondr una clara evolucin con respecto a la web tradicional.

54

2.3

SERVICIOS WEB

2.3.1 Introduccin Un servicio es la evolucin en complejidad de un componente distribuido, y se diferencian en: Mucho menos acoplados con sus aplicaciones cliente que los componentes. Menor granularidad que los componentes. No son diseados e implementados necesariamente como parte de una aplicacin end-to-end. Son controlados y administrados de manera independiente. Expone su funcionalidad a travs de protocolos abiertos e

independientes de plataforma. Incluso arriesgando el rendimiento y consumo de recursos. Son transparentes de su localizacin en la red, de esta manera garantizan escalabilidad y tolerancia a fallos.

Generalmente los servicios incluyen tanto lgica de negocios como manejo de estado (datos) relevantes a la solucin del problema para el cual fueron diseados. Un servicio funciona como una aplicacin independiente, teniendo sus propias reglas de negocio, datos, procedimientos de administracin y operacin. Expone toda su funcionalidad utilizando una interfaz basada en mensajes.

Los servicios web comunican aplicaciones, permiten que las aplicaciones compartan informacin y que adems invoquen funciones de otras aplicaciones independientemente de cmo se hayan creado las aplicaciones, cual sea el

55

sistema operativo o la plataforma en que se ejecutan y cuales los dispositivos utilizados para obtener acceso a ellas. La comunicacin se caracteriza por el intercambio de mensajes XML y por ser independientes del protocolo de comunicacin. Para lograr esta independencia el mensaje XML se envuelve de manera apropiada para cada protocolo gracias a la creacin del protocolo de transporte SOAP. Una definicin precisa de servicio web seria la emitida por el W3C: una aplicacin software identificada por una URI, cuyas interfaces y vinculaciones son capaces de ser definidas, descritas y descubiertas como artefactos XML. Un SW soporta la interaccin con otros agentes software mediante el intercambio de mensajes basado en XML a travs de protocolos basados en Internet.

Los servicios web permiten a las compaas publicar componentes y servicios en un directorio en el que otras aplicaciones web pueden buscar e implementar nuevos servicios a travs de una llamada. 2.3.2 Arquitectura de los servicios web

Las soluciones previas a la tecnologa de los servicios web tenan una serie de problemas, principalmente de interoperabilidad. As, mientras unas se restringan a unas plataformas concretas, otras no eran flexibles en cuanto al lenguaje de programacin. El uso de soluciones propietarias supona problemas ya que imposibilitaba la interaccin entre los elementos elaborados de acuerdo con las distintas soluciones y, lo que es peor, su uso global estaba fuertemente restringido por los cortafuegos que bloqueaban los puertos por lo que se comunicaban estos componentes. Por tanto la solucin radicaba en encontrar un conjunto de estndares que fueran aceptados mundialmente para construir una tecnologa que fuese ms

56

acorde a la visin de Internet. XML y HTTP constituyen la base sobre la que se ha desarrollado la tecnologa de los servicios web. .

Fig. 10. Arquitectura de los Servicios Web

La arquitectura de los servicios web se fundamenta en tres estndares principales: 2.3.2.1 WSDL (Web Service Description Language).

Formato XML, recomendado por el W3C, que se utiliza para describir la interfaz publica de los servicios web, es decir, los requisitos del protocolo y los

formatos de los mensajes necesarios para interactuar con los servicios listados en su catalogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan despus al protocolo concreto de red y al formato del mensaje.

57

En esencia, WSDL es un contrato entre el proveedor del servicio y el cliente mediante el que el proveedor del servicio indica:

Que funciones se pueden invocar Que tipos de datos utilizan esas funciones. Que protocolo de transporte se utilizara para el envi y recepcin de los mensajes (generalmente por medio de mensajes SOAP). Como acceder a los servicios ( Generalmente mediante URL).

Un documento WSDL se compone de un conjunto de definiciones. Encontramos un elemento definitions en la raz y diversas definiciones en su interior. Los servicios son definidos utilizando seis elementos principales: types: proveen definiciones de los tipos de datos utilizados para describir los mensajes intercambiados. message: representa una definicin abstracta de los datos que estn siendo transmitidos. Un mensaje se divide en una serie de partes lgicas, cada una de las cuales se asocia con alguna definicin de algn sistema de tipos. porType: es un conjunto de operaciones abstractas. Cada operacin hace referencia a un mensaje de entrada y uno de salida. binding: especifica un protocolo concreto y las especificaciones del formato de los datos de las operaciones y los mensajes definidos por un porType en concreto.

58

port: Especifica una direccin para un binding, para as definir un nico nodo de comunicacin. service: se utiliza para unir un conjunto de puertos relacionados.

En el entorno de los servicios web, tiene como limitacin que no se describe el formato y el papel o rol del mensaje en la interaccin de los servicios web. Tiene como ventajas la flexibilidad, ya que est abierta a nuevos elementos, pero tambin una restriccin desde el punto de vista de los servicios web, ya que no hay una semntica para las secuencias de mensajes, la correlacin y el contenido. 2.3.2.2 SOAP (Simple Object Access Protocol)

Es un protocolo de servicios web que define la manera de comunicar dos objetos por medio del intercambio de mensajes basados en XML facilitando en comparacin con otros protocolos la lectura de los mensajes y contando con las ventajas del uso de XML, fue creado por Microsoft, IBM y otros y est actualmente bajo el auspicio de la W3C.

SOAP especifica el formato del mensaje que accede e invoca a los objetos, en vez de especificar los objetos en s. Los mensajes SOAP son bsicamente transmisiones de direccin nica emisor-receptor.

Fig. 11. Estructura de SOAP

59

Un mensaje SOAP es un documento XML que consta de los siguientes elementos: Envelope (sobre): define un marco de referencia general para expresar que es lo que contiene el mensaje, quien debe recibirlo, y si es opcional u obligatorio. Header (cabecera): es opcional y contiene meta informacin referente al mensaje, contiene la informacin referente del receptor y un conjunto de opciones de entrega. Body (cuerpo): contiene la informacin de la llamada y de la respuesta.

Los objetivos principales de SOAP son: Establecer un protocolo de invocacin de servicios remotos, basado en protocolos estndares de Internet: HTTP para la transmisin y XML para la codificacin de datos. Independencia de plataforma, lenguaje de desarrollo e implementacin. 2.3.2.3 UDDI (Universal Description, Discovery and Integration)

Catalogo de negocios de Internet, el registro en el catalogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por OASIS) entroncada en el contexto de los servicios web. Provee un mtodo estandarizado para la publicacin y el descubrimiento de informacin sobre los SW. Una organizacin puede registrar tres tipos de registro UDDI: Paginas blancas: constituida por informacin bsica de contacto e identificadores de la empresa, incluyendo el nombre de la empresa, informacin dentro de un

60

direccin, informacin de contacto. Esta informacin permite a otros descubrir los SW de una empresa basndose en la identificacin del negocio. Pginas amarillas: consiste en informacin que describe al SW mediante diferentes categorizaciones o taxonomas. Esta informacin permite descubrir SW basndose en esta categorizacin. Paginas verdes: consiste en informacin tcnica que describe el comportamiento y las funciones soportadas por un SW. Esta informacin incluye punteros que, entre otras cosas, indican donde estn ubicados los SW.

UDDI tiene diferentes usos dependiendo de la perspectiva del que lo use. Desde la perspectiva de un analista de negocios, UDDI ser similar a un motor de bsqueda de Internet para procesos de negocio. EL analista podr echar una ojeada a uno o ms registros UDDI para ver los diferentes negocios que exponen sus SW y las especificaciones de esos servicios.

Para la interaccin con los registros UDDI, existe una API que permite a los desarrolladores de software publicar los servicios en los registros y realizar consultas sobre los registros para descubrir servicios realizando bsquedas segn los criterios necesarios.

Las principales estructuras (elementos XML) de alto nivel son las siguientes: BusinessEntity. Contiene informacin bsica de la empresa: persona de contacto, una clasificacin de la empresa conforme a alguna de las taxonomas definidas, as como una descripcin en lenguaje natural de las actividades de la empresa.

61

PublisherAssertion. Una empresa puede declarar su relacin con otras empresas, por ejemplo, como socios o como clientes. BusinessService. Este elemento muestra los servicios ofrecidos por una empresa. Estos servicios pueden ser servicios web o no. Una BusinessEntity se compone de uno o varios elementos businessService, y un elemento businessService puede ser usado por varios elementos BusinessService. BindingTemplate. Este elemento contiene referencias a descripciones tcnicas (por ejemplo, URLs apuntando a manuales tcnicos) y a las URL de acceso de los servicios web. tModel. Este elemento describe la manera de interactuar con el servicio web y su comportamiento. Entre sus datos se encuentra la URL donde se encuentra el documento WSDL. Tambin pueden aparecer aqu las categoras en las que se puede englobar el servicio.

Cuando dentro de un negocio nace la necesidad de utilizar SW, se presenta el problema de localizar ese SW que satisfaga de manera eficiente esa tarea para la que ser requerido. Es bastante difcil conseguir que un programa, por s solo, descubra y use dinmicamente esos SW. Es por esto, que se presenta otra opcin ms asequible, y es que los propios analistas utilicen portales especiales que interroguen a los registros UDDI en busca de SW, de forma que la bsqueda se hace menos compleja.

La categorizacin permite que los datos en un registro UDDI sean asociados con una industria, un producto o un conjunto de cdigos geogrficos. De esta forma, se obtiene a priori un conjunto de criterios por los que realizar las bsquedas en el registro, adems de organizar de una forma sencilla y eficiente las grandes cantidades de datos que hay en el registro UDDI.

62

Para la categorizacin existe el elemento contiene una estructura . Podemos encontrarnos esta estructura tambin junto con los elementos y .

Existen diferentes sistemas de categorizacin para usar con el registro UDDI:

Tabla 1. Taxonomas de Categorizacin.

Cada taxonoma de categorizacin se registra como una estructura dentro de UDDI. Cada categorizacin tendr un nombre tModel y un UUID para referenciarlo.

Un identificador es una propiedad utilizada para identificar unvocamente un negocio o una especificacin. Se pueden aplicar a las estructuras y Al igual que ocurra con las categorizaciones, podemos utilizar los identificadores como parte una bsqueda cuando enviamos los mensajes de peticin o . Los identificadores estn vinculados a las estructuras y mediante la estructura .

Esta ltima estructura puede tener uno o ms estructuras a su vez, que proveen el nombre, el valor y la referencia del UUID del

63

para poder localizar ms informacin. Actualmente, slo hay propuestos dos esquemas de identificacin incorporados a los nodos operadores, estos son:

Tabla 2. Tipos de Identificadores soportados.

2.3.3 Orquestacin y Coreografa

La combinacin de SW para la implementacin de procesos de alto nivel, requiere de diversos estndares que nos permitan modelar las posibles interacciones entre los servicio. Los trminos de orquestacin y coreografa tratan de describir aspectos relacionados con la creacin de procesos de negocio que involucran varios SW.

Fig. 12. Relacin entre Orquestacin y Coreografa de SW.

64

2.3.3.1 Coreografa

Permite trazar las secuencias de mensajes que se suceden entre todas las partes participantes del proceso de negocio.

La coreografa puede entenderse como un proceso pblico y no ejecutable: es pblico porque define el comportamiento comn y globalmente visible entre los diferentes participantes en una interaccin; 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 interaccin que deben ser cumplidas por las entidades participantes.

Fig. 13. Ejemplo de Coreografa

En la figura se puede observar la interaccin entre dos entidades que siguen el siguiente modelo: primero se enva la orden de compra en un sentido, luego se enva una confirmacin a la orden y finalmente se enva una factura de compra, estas ltimas en el otro sentido.

Con la coreografa lo que realizamos es componer servicios para permitir la colaboracin entre negocios, de forma en que se definan la forma en la que mltiples participantes colaboran entre pares (peer-to-peer), como parte de una

65

operacin o transaccin de negocio duradera, que se realiza mediante el intercambio de mensajes tanto sncronos como asncronos y que requiere una descripcin formal de los protocolos de intercambio de mensajes y que debe estar visible para cada participante que interviene dentro de la coreografa.

Los lenguajes ms interesantes que permiten la definicin de coreografas son los siguientes: WSCDL : Web Service Choreography Description Language, se utiliza para describir colaboraciones punto a punto entre participantes, mediante la definicin de un punto de vista global y del comportamiento comn y complementario que puede observarse en el orden de intercambio de los mensajes entre los participantes a fin de conseguir cumplir un determinado objetivo de negocio comn. WSCI: Web Service Choreography Interface, describe como las operaciones de un servicio web, definidas a travs de su documento WSDL pueden ser coreografiadas en el contexto del intercambio de mensajes en el cual los servicios web participan. IRS-III: Internet Reasoning Service es un framework de trabajo para el desarrollo de aplicaciones basadas en el uso de Servicios Web Semnticos. Existen dos implementaciones la II y la III, la diferencia entre ambos es que la implementacin II sigue el estndar del framework UPML desarrollado dentro del proyecto IBROW, mientras que la implementacin III se basa en la anterior pero con el objetivo de crear servicios que cumplan con el estndar WSMO. 2.3.3.2 Orquestacin

Permite disear procesos de negocio ejecutables que pueden interactuar tanto con SW internos como externos.

66

Este tipo de proceso puede entenderse como privado y ejecutable: privado porque la definicin de la lgica del proceso es hecha enteramente por un participante en la interaccin; y ejecutable porque tiene un comportamiento de conversin de entradas en salidas y tiene efectos en el mundo real.

La orquestacin de servicios web se basa en un modelo centralizado en el cual las interacciones no se realizan directamente entre los servicios web sino que existe una entidad encargada de definir la lgica de interaccin. BPEL, El lenguaje BPEL permite definir la lgica de orquestacin entre los diferentes servicios web. La entidad encargada de la orquestacin es el director, que no es otro que el motor de ejecucin BPEL.

Con la orquestacin lo que realizamos es componer servicios para generar un nuevo proceso de negocio y puede usarse de dos formas distintas: para preparar la informacin que se intercambia en la ejecucin de una coreografa o como la invocacin siguiendo unas determinadas reglas a un servicio web.

Es un sistema jerrquico en el que la idea de proceso Web organiza la manera de invocar a otros mediante un flujo de control que determina qu invocar y cuando hacerlo. La orquestacin debe verse como algo atmico en s mismo, ya que lo que se ve es el proceso de negocio como tal. 2.3.4 Ventajas e Inconvenientes

La aplicacin de arquitecturas orientadas a servicios y, ms concretamente, su implementacin a travs de Servicios Web, conlleva numerosas ventajas de las que pueden beneficiarse los sistemas desarrollados. Una de las mayores ventajas de la tecnologa de los Servicios Web es la utilizacin de protocolos de transporte estndar como HTTP. Esta medida permite el paso de mensajes entre servicios sin necesidad de preocuparse por los sistemas de seguridad y,

67

en particular, los cortafuegos de las distintas organizaciones. En general, el uso de protocolos estndar facilita la interoperabilidad entre plataformas de distintos fabricantes.

Por otro lado, los servicios web aportan interoperabilidad entre aplicaciones software con independencia de su implementacin, del lenguaje de programacin utilizado y de la plataforma en que estn instaladas. Esto ha provocado que esta tecnologa se utilice, cada vez con ms frecuencia, para permitir el uso de sistemas heredados por parte de las nuevas aplicaciones que se desarrollan en el mbito de una organizacin.

Por su parte, la independencia con respecto a la implementacin aporta flexibilidad al sistema, de forma que se puede modificar la implementacin del servicio sin necesidad de actualizar su descripcin. Adems, los servicios web permiten que servicios y software de diferentes compaas ubicadas en