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 ...................................................................................................42
2.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......................................................................................56
2.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 ..................................................................................................71

OWL 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 ...............................................................................................93

UNSPSC (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 ....................................................................... 126
2.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 Figuras

FIG. 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.

Pgina
EJEMPLO 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.

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

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 <nombre>, 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 <businessService> contiene una estructura <categoryBag>. Podemos encontrarnos esta estructura tambin junto con los elementos <businessEntity> y <tModel>.

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 <tModel> 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 <businessEntity> y <tModel> Al igual que ocurra con las categorizaciones, podemos utilizar los identificadores como parte una bsqueda cuando enviamos los mensajes de peticin <find_business> o <find_tModel>. Los identificadores estn vinculados a las estructuras <businessEntity> y <tModel> mediante la estructura <identifierBag>.

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

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 diferentes lugares geogrficos puedan ser combinados fcilmente para proveer servicios integrados.

Por otra parte, no son numerosos pero si importantes los problemas que presentan los servicios web y el paradigma SOA. En general, el mayor limitante de la tecnologa de los servicios web es su rendimiento. Comparado con otros modelos de computacin distribuida como RMI, DCOM o CORBA, la prestacin de esta solucin es baja. Este problema viene ocasionado por el uso de XML como lenguaje para la codificacin de mensajes. En particular, el problema radica en la necesidad de parsear y componer los ficheros XML, lo cual requiere mayor capacidad computacional y hace que las aplicaciones se ejecuten ms lentamente. Como resultado del esfuerzo por resolver este limitante, la W3C cre en 2003 el grupo de trabajo para la caracterizacin binaria de XML (XML Binary Characterization Working Group), en el 2005 se transformo en el grupo de trabajo para el intercambio eficiente de XML (Efficient XML Interchange Working Group), actualmente es una nota de grupo

68

existiendo varios borradores de trabajo y en el 2009 se propuso un candidato a recomendacin (Efficient XML Interchange (EXI) Format 1.0).

El objetivo final es el desarrollo de una especificacin de un formato de codificacin que permita el intercambio eficiente de documentos XML. Otro de los inconvenientes de los servicios web es que el grado de madurez de algunas de sus especificaciones no puede compararse con el grado de desarrollo de estndares abiertos en computacin distribuida como CORBA.

Disponiendo de todos los componentes que constituyen la tecnologa de servicios web, cualquiera podra hacer uso de los servicios ofrecidos por todos los servicios web disponibles en internet. Sin embargo, y a medida que la web crece en tamao y diversidad, cada vez es ms necesaria la automatizacin de aspectos relacionados con los servicios web como el descubrimiento, la seleccin, la composicin y la invocacin. De hecho, una de las principales ventajas de esta tecnologa es la posibilidad de componer de forma dinmica servicios utilizando componentes software independientes y reutilizables.

2.4

SERVICIOS WEB SEMANTICOS

2.4.1 Introduccin Aunque los servicios web permiten la comunicacin entre diferentes plataformas y sistemas operativos, carecen de contenido semntico. Teniendo en cuenta que las ontologas permiten la descripcin semntica de cualquier dominio del conocimiento, la incorporacin de ontologas del dominio de los servicios a los servicios web da lugar a los servicios web semnticos.

69

Fig. 14. Evolucin de la Web

Dotar de semntica a los servicios web permite un aumento en su dinamismo facilitando la composicin dinmica o el propio descubrimiento de los mismos, lo cual ha sido un problema en los servicios web tradicionales y han requerido de la intervencin humana para poder ser llevados a cabo.

Con los servicios web semnticos se pretende automatizar todo lo que era semi-automatico en los servicios web tradicionales, esencialmente el descubrimiento, composicin, invocacin e interoperacin de servicios web.

Los servicios web pretenden transformar la web en una infraestructura global para computacin distribuida, integracin de aplicaciones y automatizacin de procesos de negocio. El problema son las tecnologas disponibles que permiten la automatizacin.

Las tareas que hacen posibles los servicios web semnticos son: Descubrimiento automtico del servicio: Localizar automticamente los servicios web que proveen un servicio particular y que se adhieren a las restricciones dadas en la peticin.

70

 Ejecucin automtica del servicio: Ejecutar automticamente un servicio web encontrado por un programa de ordenador o agente. La ontologa de descripcin del servicio debera proveer Apis declarativos para servicios web, necesarios para una correcta ejecucin automtica de estos. Composicin: Equivale a la seleccin automtica, composicin de sw para realizar alguna tarea, dada una descripcin detallada de un objetivo. Se denomina composicin del sw a la tcnica de componer funcionalidades de servicios relativamente ms simples para producir una aplicacin compleja y significante de forma arbitraria. La ontologa de descripcin de servicio debe proveer especificaciones declarativas de los prerrequisitos y consecuencias del uso individual de un servicio, necesarias para la composicin e interoperacin automtica. 2.4.2 Lenguajes de descripcin

Debido a que el conjuntos de servicios web disponibles se amplia, se vuelve cada vez mas importante contar con herramientas automatizadas para ayudar a identificar los servicios que se ajusten a los requisitos de un solicitante.

2.4.2.1 OWL S ( Web Ontology Language for Services)

OWL-S (anteriormente DAML-S) es una ontologa especfica para describir las propiedades y capacidades de un servicio web.

Para que un agente software pueda acceder a un servicio web, es necesaria una descripcin de las capacidades del servicio y de cmo acceder al mismo que sea interpretable por componentes software. Con este propsito se hace

71

uso del concepto de ontologa, en particular del lenguaje ontolgico OWL y de los mecanismos asociados al mismo.

La estructura de esta ontologa viene dada por la necesidad de responder a tres aspectos bsicos de un servicio:

1. Qu necesita el servicio del cliente que lo utiliza y que le proporcionara como respuesta el servicio?. Esto es el perfil del servicio.

2. Que hace el servicio?. Esto es el modelo del servicio. 3. Cmo se usa el servicio?. Esto es el grounding del servicio.

Una caracterstica a destacar en OWL-S es la distincin que hace entre servicios atmicos, simples y compuestos. Los servicios atmicos son aquellos donde un solo 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, no tienen subprocesos.

Los servicios simples proporcionan un mecanismo de abstraccin para proporcionar mltiples puntos de vista del mismo proceso, pueden ser usados para proporcionar una vista de algn proceso atmico, o una representacin simplificada de algunos procesos compuestos. Los servicios compuestos son aquellos que estn constituidos por mltiples servicios primitivos y pueden requerir una interaccin extendida o conversacin con el solicitante, deben tener una propiedad composedOf por la que se indica la estructura de control de la composicin, utilizando un constructor de control. Cada constructor de control, a su vez, se asocia con una propiedad adicional llamada componentes para indicarle al constructor de control anidado desde el cual se compone, y, en algunos casos, su clasificacin.

72

Los constructores de control pueden ser: Sequence: Una lista de construcciones de control para ser hechas en orden. Split: Los componentes de un proceso Split son un conjunto de componentes del proceso que se ejecutarn simultneamente. Split concluye tan pronto como todos los componentes de los procesos han sido programados para su ejecucin. Split + Join: el proceso consiste en la ejecucin concurrente de un montn de componentes del proceso con barreras de sincronizacin. Es decir, Split+Join concluye cuando todos sus componentes han completado los procesos. Con Split y Split+Join, podemos definir los procesos que tienen sincronizacin parcial. Any- Order: Permite a los componentes del proceso (especificados como un conjunto) ser ejecutado en algn orden no especificado, pero no simultneamente. La ejecucin y la terminacin de todos los componentes es requerido. La ejecucin de los procesos en una construccin Any-Order no puede superponerse, es decir, los procesos atmicos no pueden ser ejecutadas simultneamente y procesos compuestos no pueden ser intercalados. Todos los componentes deben ser ejecutados. Al igual que con Split+Join, la terminacin de todos los componentes es requerida. Choice: Pide para la ejecucin de un nico constructor de control un conjunto de Constructores de control (dado por los componentes de la propiedad). Cualquiera de las construcciones de control dadas puede ser elegido para su ejecucin.

73

 If-then-else: El if-then-else es una clase de construccin de control que tiene las propiedades ifCondition, then, y else teniendo diferentes aspectos del if-then-else. Iterate: Iterate es una clase "abstract", en el sentido de que no es lo suficientemente detallada como para ser una instancia en el modelo de proceso process model. Este es definido para servir como una superclase comn de Repeat-While, Repeat-Until, y potencialmente otras construcciones de iteracin que sean necesarios posteriormente. Repeat-While and Repeat-Until: Ambos iteran hasta que se convierte en una condicin falsa o verdadera, siguiendo las familias de lenguajes de programacin.

Fig. 15. Estructura de los procesos

En

esencia,

OWL-S es una

ontologa que

contiene los elementos

fundamentales que caracterizan un servicio y que permite describir las

74

capacidades que sustenta un servicio. A continuacin se puede observar los tres tipos de conocimientos fundamentales que posee esta ontologa de alto nivel para describir un servicio.

Fig. 16. Ontologa de alto nivel de OWL-S

Service Profile

Describe el servicio ofrecido desde tres puntos de vista, la informacin del proveedor, la descripcin funcional del mismo y desde los rasgos que especifican las caractersticas del servicio para que un agente de bsqueda de servicios pueda determinar si un servicio satisface o no sus necesidades.

La informacin del proveedor en esencia describe qu organizacin proporciona el servicio. Tpicamente es informacin de contacto sobre la empresa.

La descripcin funcional bsicamente describe qu hace el servicio en cuanto a qu datos de entrada necesita, qu datos genera, precondiciones que se deben satisfacer y efectos generados. Por ejemplo, un servicio puede requerir como precondicin una tarjeta de crdito vlida, como datos

75

de entrada el nmero de tarjeta y su fecha de vencimiento. Como resultado genera un recibo, y como efecto se efecta el cargo en la cuenta del cliente.

Se concreta en las siguientes propiedades:

hasParameter: Rangos sobre una instancia de parmetros del proceso de la ontologa. Los parmetros son los que participan en la transformacin de la informacin y, por tanto, son diferentes de las condiciones previas y efectos. El nico papel es hacer explcito el dominio de conocimiento.

hasInput: Rangos de los parmetros de entradas.

hasOutput: Rango de los parmetros de salida.

hasPrecondition: Especifica una de las condiciones previas del servicio. hasResult: Especifica uno de los resultados del servicio. Se especifica en qu condiciones se generan los resultados. Por otra parte, el resultado especifica que cambios en el dominio se producirn durante la ejecucin del servicio.

Los rasgos que especifican las caractersticas del servicio son una lista en la que pueden aparecer datos tales como:

serviceParameter: Es una lista de propiedades. Cada propiedad tiene rango ServiceParameter. Tiene las propiedades: serviceParameterName: Nombre del parmetro que puede ser un literal o la URI del parmetro.

76

 sParameter: Apunta al valor del parmetro dentro de alguna ontologa.

serviceCategory: El rango de esta propiedad es la clase ServiceCategory. Esta clase se compone de: categoryName: Es el nombre de la categora, pudiendo ser un literal, o una URI. taxonomy. Puede ser la URI de una taxonoma, la URL donde la taxonoma reside, o un literal cualquiera. Value: Apunta un valor concreto dentro de la taxonoma. Code: El cdigo asociado al tipo de servicio en la taxonoma.

La clase ServiceProfile proporciona una superclase de cada tipo de alto nivel de descripcin del servicio. ServiceProfile asigna la informacin bsica para unir cualquier caso de perfil con un caso de servicio.

Hay una relacin bidireccional entre un servicio y un perfil, de modo que un servicio puede estar relacionado con un perfil y un perfil con un servicio. Estas relaciones se expresan por las propiedades present y presentedBy de la siguiente forma:

Present: Describe una relacin entre una instancia de servicio y una instancia de perfil, que bsicamente dice que el servicio es descrito por el perfil.

presentedBy: Es el inverso de present y especifica que un determinado perfil describe un servicio.

77

Un perfil puede tener como mximo un nombre de servicio y descripcin, pero tantos elementos de informacin de contacto como el proveedor quiera ofrecer.

Fig. 17. Otros atributos

Los atributos adicionales incluyen las garantas de calidad que son proporcionados por el servicio, la posible clasificacin del servicio, y los parmetros adicionales que el servicio desea, puede ser especificados all. Process Model

Especifica cmo es la interaccin entre el cliente y el servicio.

Las precondiciones y los efectos se representan mediante reglas lgicas. Un proceso no deber ser ejecutado a menos que sus precondiciones se cumplan, si se ejecutase sin cumplirse las precondiciones el resultado est indefinido.

78

El lenguaje en el que se van a expresar estas reglas puede ser cualquiera que tenga una representacin textual. Las expresiones lgicas sern de tipo literal o literal XML.

El resultado de la invocacin de un servicio se puede ver como la salida y el efecto, se puede condicionar el resultado del servicio mediante las propiedades inCondition, hasResultVar, withOutput, hasEffect. La propiedad inCondition especifica la condicin bajo la que se produce este resultado y no otro.

Las propiedades withOutput y hasEffect establecen qu sucede cuando la condicin se satisface. La propiedad hasResultVar declara variables usadas en inCondition. Estas variables, llamadas ResultVars, son anlogas a las variables Locals, y sirven para un propsito similar, permitiendo ligar las variables a las precondiciones y usarlas en las declaraciones de salida y efectos.

Service Grounding

Especifica los detalles de cmo se puede acceder al servicio. En general sirve para especificar un protocolo de comunicacin, formato de mensajes y otros detalles especficos del servicio como los nmeros de puertos que deben utilizarse para contactar al servicio.

Adems, debe indicar para cada tipo semntico de entrada o salida especificado en el ProcessModel, un modo no ambiguo para intercambiar elementos de datos de ese tipo con el servicio.

Para poder hacer referencia a WSDL desde OWL-S se crea la clase WSDLGrounding, subclase de ServiceGrounding. Cada instancia de esta

79

clase

contiene

una

lista

de

instancias

de

la

clase

WSDLAtomicProcessGrounding.

Cada una de las instancias de WSDLAtomicProcessGrounding se refiere a elementos de WSDL a travs de las siguientes propiedades:

wsdlVersion. Una URI que indica la versin de WSDL que se usa.

wsdlDocument. La URI del documento WSDL. wsdlOperation. La URI de la operacin WSDL correspondiente a ese proceso atmico. wsdlnputMessage. Un objeto que contiene la URI de la definicin del mensaje WSDL que contiene los valores de entrada de ese proceso atmico. wsdOutputMessage. Como el anterior, pero para los valores de salida. wsdlInputs. Un objeto con una lista de pares de mapeo. Cada par es una instancia de WsdlInputMessageMap. Un elemento del par (expresado con la propiedad wsdlMessagePart) identifica la part del message usando una URI. El otro elemento indica cmo obtener ese part del message a partir de una o ms entradas del proceso atmico OWL-S. WsdOutputs. Como el anterior, pero para los valores de salida. En vez de WsdlInputMessagePart se usa WsdlOutputMessagePart.

80

Fig. 18. Ontologa del proceso de alto nivel

2.4.2.2 WSMO (WEB SERVICE MODELING ONTOLOGY)

Es una ontologa para describir varios aspectos acerca de los servicios web semnticos desarrollada por el WSMO Working Group. Fue la unin de tres grandes proyectos europeos de investigacin en el rea de la web semntica y los servicios web semnticos quienes trabajaron en este modelo: SEKT, DIP y Knowledge Web (SDK).

Se basa en el Web Service Modeling Framework (WSMF) el cual sirve de base conceptual, y separa los elementos que se necesitan para describir servicios en ontologas, servicios web, objetivos y mediadores.

El lenguaje usado para describir todos estos elementos es el Web Service Modeling Language (WSML) o Lenguaje de Modelado de Servicios Web. Este

81

lenguaje provee una sintaxis formal y una semntica para el modelado de ontologas de servicios web.

Tambin se ha desarrollado WSMX (Web Service Modelling eXecution environment) que es el entorno de ejecucin de modelado de servicios web y la implementacin de referencia de WSMO. WSMX es open source y usa WSML como lenguaje interno.

WSMO es totalmente compatible con otras formas de representacin como XML, OWL, etc.

Fig. 19. Elementos de WSMO

Segn WSMO, existen cuatro elementos fundamentales que describen un Servicio Web: Ontologas: Proveen la terminologa y la semntica formal para llevar a cabo la descripcin del servicio. Servicios Web: Proveen una descripcin semntica de los servicios web. Se describen las Capabilities (precondiciones, postcondiciones, requisitos y efectos) e Interfaces (proceso y grounding del servicio).

82

 Objetivos: Los objetivos describen las salidas y efectos esperados tras la invocacin de un servicio. Este elemento facilita la expresin de las necesidades de un usuario y la bsqueda de los servicios que las satisfagan. Mediadores: Buscan maximizar la interoperabilidad entre los servicios, mediante el enlace de diferentes componentes de WSMO.

Cuando las ontologas que describen los conceptos con los que se expresan las postcondiciones y los efectos del servicio, son diferentes de las usadas para expresar las postcondiciones, y los efectos de los goals, se hace uso de los mediators. Existen cuatro tipos de mediadores: OOMediators:

Importan

ontologas

resuelven

posibles

incompatibilidades entre estas como diferencias en representaciones de lenguajes o en conceptualizaciones del mismo domino. GGMediators: Buscan el refinamiento y compatibilidad de objetivos. WGMediator: Se encargan de satisfacer las necesidades entre servicios web y objetivos. WWMediator: Entre Servicios Web. Utilizado en la composicin de servicios.

Los mediadores son usados despus de realizar importaciones de ontologas con el fin de solucionar problemas y malas uniones que se hayan producido al realizar dicha importacin (por ejemplo dos elementos con el mismo nombre definidos en dos ontologas distintas), el uso de los mediators (mediadores) limitan estos problemas.

WSMO permite representar el dominio mediante conceptos (hasConcept), relaciones (has Relations), funciones (hasFuntions) e instancias

83

(hasInstances). Los conceptos representan clases de objetos del mundo, tanto abstracto como real, que tiene propiedades especficas compartidas.

Los miembros de tales clases son llamados instancias del correspondiente concepto. Las relaciones son utilizadas para determinar la relacin entre conceptos. Las Instancias son conceptos que representa un conjunto de objetos del mundo real o abstracto con unas propiedades compartidas especficas. Cada objeto se denomina instancia.

Los servicios web en WSMO son entidades computacionales que son capaces (por invocacin) de conseguir las metas de los usuarios. Un servicio es el valor proporcionado por esta invocacin, segn esto, un mismo Servicio Web es capaz de proporcionar diferentes servicios.

En WSMO la interaccin con un servicio puede conseguirse usando los Servicios Web con WSML, sin embargo WSMO no restringe el uso a WSML sino que puede utilizar cualquier otro lenguaje que soporte los conceptos mencionados anteriormente.

En cuanto a las labores de descubrimiento y seleccin se utilizan las capacidades del servicio, dichas capacidades estn determinadas de acuerdo a si tiene propiedades no funcionales, si usa mediador type {ooMediator, ggMediator}, si tiene variables en comn, si tiene precondiciones, si tiene asuncin, si tiene postcondiciones y efectos. Las precondiciones se refieren al estado requerido antes de la ejecucin del Web Services, actan como un conjunto de estados que al satisfacerlos aseguramos una puesta en marcha correcta y de una manera definida.

Las asunciones describen el estado del mundo que se asume antes de la ejecucin del Servicio Web, en otro caso la correcta disposicin del servicio no queda garantizada.

84

La diferencia entre una precondicin y una asuncin es que las segundas no tienen que verificarse, se asumen sin ms.

Las postcondiciones describen el estado en el que quedar el entorno de ejecucin cuando el Servicio Web se haya ejecutado de manera correcta. En las postcondiciones se establece tambin la relacin entre la informacin proporcionada al servicio y los resultados del mismo.

En WSMO los objetivos (goals) representan las peticiones del cliente. Un Goal usa mediators en las siguientes situaciones: Cuando utiliza terminologas heterogneas pueden aparecer conflictos entre ellas, en estos casos un Servicio Web puede importar ontologas usando mediators. Cuando un Goal reutiliza otro Goal existente, por ejemplo redefinindolo. 2.4.2.3 SWSF (Semantic Web Services Framework)

Es una iniciativa para la definicin de una especificacin ms rica sobre la actual tecnologa de los servicios web que permita mayor automatizacin y flexibilidad en la provisin y uso de servicios.

El marco de trabajo est diseado a su vez con el propsito de soportar la construccin de herramientas y metodologas ms potentes en el entorno de los servicios web, as como promocionar el uso de procesos de razonamiento sobre servicios fundamentados en semntica.

Esta propuesta est compuesta de dos componentes principales: el SWSL (Semantic Web Services Language) y el SWSO (Semantic Web Services

Ontology). SWSL es un lenguaje lgico de propsito general que incluye ciertas

85

caractersticas para hacerlo ms apropiado para las necesidades de la Web y los servicios web semnticos.

Entre estas peculiaridades se incluye el uso de URIs, la integracin de los tipos que forman parte de XML y el uso de mecanismos de importacin y espacios de nombres compatibles con XML. Este lenguaje es el utilizado para especificar las caracterizaciones formales sobre los conceptos relacionados con los servicios web y sus descripciones.

Incluye dos sub lenguajes: SWSL-FOL, basado en lgica de primer orden con extensiones de HiLog y sintaxis de marcos de F-Logic, y se utiliza para expresar la caracterizacin formal de los conceptos relacionados con los servicios web, y SWSL-Rules, basado en el paradigma de programacin lgica, y utilizado para dar soporte al uso de la ontologa de servicios en procesos de razonamiento y en entornos de ejecucin basados en ese paradigma.

La SWSO define un modelo conceptual por el cual los servicios web pueden ser descritos, y una representacin formal o axiomatizacin de dicho modelo. La axiomatizacin completa se implementa en lgica de primer orden utilizando SWSL-FOL, con una semntica de Teora de Modelos que especifica un significado preciso de los conceptos de la ontologa. Esta forma de la ontologa que utiliza lgica de primer orden se denomina First-Order Logic Ontology for Web Services (FLOWS).

Los axiomas de FLOWS se han traducido al lenguaje de reglas SWSL-Rules, obtenindose una ontologa basada en semntica de programacin lgica denominada Rules Ontology for Web Services (ROWS).

FLOWS, al igual que WSMO y OWL-S es una ontologa formal sobre conceptos de servicios, que proporciona un marco de trabajo conceptual para describir y razonar sobre servicios.

86

En FLOWS, un servicio es un objeto conceptual que corresponde a un servicio web y est dividido en tres partes fundamentales: Ontologa de descriptores de servicio: esta ontologa proporciona la informacin bsica acerca de un servicio web de forma similar a lo que podran ser unas pginas amarillas independientes del dominio. Estos descriptores de servicios se utilizan para el descubrimiento automatizado de servicios web. Ontologa de modelo de procesos: Extiende la ontologa de procesos genrica propuesta por PSL para hacer disponibles los conceptos que son tiles en el contexto de los servicios web. Se aaden dos elementos sobre PSL: la nocin estructurada de proceso atmico y una infraestructura para especificar varias formas de flujos de datos. Grounding: Los conceptos de SWSO para la descripcin de servicios y las instanciaciones de estos conceptos para describir un servicio particular, son especificaciones abstractas, de forma que no se ofrecen detalles relacionados con el formato de los mensajes, los protocolos de transporte ni las direcciones de red que son necesarios para hacer uso efectivo de un servicio web.

El propsito de grounding es relacionar estos elementos abstractos con detalles ms concretos, por esto, define correspondencias entre ciertos conceptos de la SWSO a construcciones WSDL que describen la realizacin concreta de esos conceptos. 2.4.2.4 WSDL-S (Web Service Semantics)

WSDL-S define un mecanismo para asociar anotaciones semnticas con Servicios Web que han sido descritos utilizando WSDL.

87

WSDL-S asume la existencia de modelos semnticos del dominio relevante para cada servicio, mantenidos fuera del mbito de los documentos WSDL y que pueden ser referenciados desde un documento WSDL a travs de elementos de extensibilidad ideados como parte de la propuesta WSDL-S.

Fig. 20. Anotacin semntica de los elementos WSDL

El estndar WSDL opera a un nivel sintctico, es decir carece de expresividad semntica necesaria para representar los requisitos y capacidades de los servicios. La semntica mejora la reutilizacin de software y el descubrimiento, facilita la composicin de servicios.

La informacin semntica considerada en WSDL-S incluye definiciones de precondiciones, entradas, salidas y efectos de las operaciones de servicios Web.

WSDL incorporaba, los siguientes constructores para representar descripciones de servicios: interface, operation, message, binding, service yendpoint. De entre estos, solo interface, operation y message tratan con la definicin abstracta de un servicio y son, por tanto, los necesarios para aadir las anotaciones semnticas sobre las descripciones de servicios que permite el

88

descubrimiento, composicin e invocacin dinmica de servicios. Los elementos y atributos de extensibilidad planteados por WSDL-S son los siguientes: Un atributo de extensin denominado modelReference para especificar la asociacin entre una entidad WSDL y un concepto en algn modelo semntico. Este atributo puede aadirse a un tipo complejo, elemento, operacin, as como a los elementos de extensin precondition y effect. Un atributo de extensin denominado SchemaMapping, aadido a los elementos XSD y a los tipos complejos, para manejar diferencias estructurales entre los elementos de diseo de un servicio Web y sus correspondientes conceptos del modelo semntico. Dos elementos, denominados precondition y efect, situados como descendientes de Operation. Estos nuevos elementos se utilizan, principalmente, para el descubrimiento de servicios, y no son estrictamente necesarios para la invocacin de un servicio dado. Un atributo de extensin en el elemento interface denominado category, que consiste en informacin de categorizacin de servicios que puede ser utilizado cuando se publica un servicio en un registro de Servicios Web como UDDI.

Ventajas destacadas de WSDL-S sobre otras, como OWL-S y WSMO, se pueden: Los usuarios pueden describir, de forma incremental, todos los detalles, tanto semnticos como a nivel de operaciones en WSDL, un lenguaje familiar para los desarrolladores.

89

 Al externalizar los modelos semnticos del dominio, WSDL-S permanece independiente del lenguaje de representacin de ontologas que se desee utilizar. Esto permite a los desarrolladores de Servicios Web anotar sus servicios con el lenguaje ontolgico de su eleccin (p.ej., UML, OWL, etc.). Modificar las herramientas existentes actualmente alrededor de la especificacin WSDL para incorporar los elementos propuestos por esta aproximacin es algo sencillo. En todo caso, es ms rpido y fiable que el desarrollo de herramientas implementadas desde cero. 2.4.2.5 SAWSDL ( Semantic Annotation for WSDL and Schema)

Surgi, en Abril de 2006, el grupo de trabajo SAWSDL como parte de la W3C Web Services Activity. El objetivo de este grupo de trabajo es el desarrollo de un mecanismo que permita la anotacin semntica de descripciones de Servicios Web.

Definen un conjunto de atributos de extensin para WSDL y XML Schema que permite la descripcin de semntica adicional de los componentes de WSDL.

Esta anotacin semntica se consigue, al igual que ocurra en WSDL-S, utilizando en WSDL referencias sobre modelos semnticos como, por ejemplo, ontologas. As, SAWSDL no especifica un lenguaje concreto para representar los modelos semnticos, sino que incorpora mecanismos por medio de los cuales es posible referenciar desde documentos WSDL a conceptos de modelos semnticos definidos externamente utilizando anotaciones.

De los elementos que incorpora la especificacin WSDL 2.0 para representar descripciones de servicios (como, Type Definition, Interface, Interface Operation, Interface Fault, Binding, Service y Endpoint), SAWSDL se centra en la anotacin semntica de aquellos que ofrecen una definicin abstracta de un servicio (esto es, Type Definition, Interface, Interface

90

Operation e Interface Fault) para permitir el descubrimiento, composicin e invocacin dinmica de servicios. SAWSDL propone dos constructores bsicos para anotacin semntica: Un atributo de extensin denominado modelReference para especificar la asociacin entre un componente WSDL o XML Schema y un concepto en algn modelo semntico. Es utilizado para anotar definicin de tipos complejos en XML Schema, definicin de tipos simples, declaraciones de elementos y declaraciones de atributos, adems de interfaces, operaciones y efectos en WSDL. Dos atributos de extensin denominados liftingSchemaMapping y loweringSchemaMapping, que se aaden a la declaracin de elementos en XML Schema, definicin de tipos complejos y simples para especificar correspondencias entre datos semnticos y XML. Estas correspondencias se usarn posteriormente durante la invocacin de servicios. 2.4.3 Comparativa entre los lenguajes de descripcin

Tanto WSMO como OWL-S consideran a las ontologas un elemento fundamental para hacer realidad la localizacin, invocacin, monitorizacin y composicin automtica de servicios web. Sin embargo difieren en la forma que establecen para lograr estas tareas. Mientras OWL-S define un conjunto de ontologas que permiten la manipulacin de servicios, WSMO define un modelo conceptual dentro del cual se deben crear las ontologas que permitan administrar los servicios web.

Una de las diferencias ms importantes entre estas dos alternativas es el concepto de mediadores, definido en WSMO para resolver los posibles problemas de heterogeneidad e interoperabilidad. Los mediadores son elementos especiales cuyo objetivo es enlazar componentes heterogneos

91

mediante el mapeo adecuado de cada una de sus partes, las transformaciones necesarias e incluso asociaciones inteligentes o inferencias.

WSMO define las interfaces de orquestacin y coreografa para describir la interaccin entre servicios. En OWL-S cada nivel aporta nuevas caractersticas que aumentan la potencia del lenguaje.

WSDL-S proporciona un mecanismo para anotar el servicio y sus entradas, salidas y operaciones. Adicionalmente consta de mecanismos para especificar y anotar precondiciones y efectos de los servicios web.

En WSDL se asume que los modelos semnticos relevantes para los servicios ya existen. Estos modelos se referencian desde el documento WSDL por medio de elementos de extensibilidad.

Esta aproximacin ofrece varias ventajas.

En primer lugar, los usuarios pueden describir tanto los detalles del nivel semntico como los del nivel de operacin en WSDL, un lenguaje con el que la comunidad de desarrollo est familiarizada.

En segundo lugar, manteniendo externos los modelos de dominio semnticos, los desarrolladores de servicios web pueden anotar sus servicios con cualquier lenguaje ontolgico. Finalmente, es relativamente fcil actualizar las

herramientas relativas a la especificacin WSDL para aadir esta visin semntica.

92

Tabla 3. Fortalezas y debilidades de los lenguajes de descripcin

Modelo WSMO

Ventajas

Desventajas

Manejo de propiedades Se apoya en otras dos no ontologas funcionales, iniciativas para su

importadas, representacin sintctica y su ejecucin. y

precondiciones, postcondiciones efectos. WSDL-S Independiente lenguaje representacin. OWL-S

del Describe

la

funcionalidad

de pero no el comportamiento.

Orientado a descripcin, Dificultad se centra en el detalles.

para Necesita

aadir muy

comportamiento.

buenos agentes.

2.4.4 Estndares de clasificacin 2.4.4.1 UNSPSC (United Nations Standard Products and Services Code).

Es un sistema de cifrado que clasifica productos y servicios para fines comerciales a escala mundial. La gestin y desarrollo de UNSPSC est coordinado por GS1 US y respaldado por la ONU desde 2003. La versin actual de la clasificacin contiene ms de 16.000 trminos.

UNSPSC es una clasificacin jerrquica con cinco niveles. Estos niveles permiten el anlisis mediante la profundizacin o material. Cada nivel en la jerarqua tiene un nmero nico.

93

Segmento XX La agregacin lgica de familias para fines de anlisis Familia XX Un grupo comnmente reconocido de las categoras de productos bsicos relacionados entres s. Clase XX Un grupo de productos que presentan caractersticas comunes Mercancas XX Un grupo de productos o servicios sustitutivos Funcin Empresarial XX La funcin realizada por una organizacin en apoyo de la mercanca.

Todas las entidades estn identificadas con un cdigo de ocho dgitos numricos que indica su ubicacin en la taxonoma. Un sufijo adicional de dos dgitos indica el identificador de una funcin empresarial.

Tabla 4. Ejemplo sistema de clasificacin UNSPSC

2.4.4.2 NAICS (North American Industry Classification System)

NAICS es el estndar utilizado por las agencias federales de estadstica en la clasificacin de los establecimientos comerciales con el propsito de recolectar, analizar y publicar datos estadsticos relacionados con la economa de las empresas EE.UU..

94

NAICS fue desarrollado bajo los auspicios de la Oficina de Gerencia y Presupuesto (OMB), y aprob en 1997 para sustituir a la Clasificacin Industrial Uniforme (SIC) del sistema. Ha sido desarrollado conjuntamente por los EE.UU. Dicha clasificacin es un cdigo de seis dgitos, estos seis dgitos acomodan un largo nmero de sectores y permite flexibilidad en el diseo de subsectores. A cada producto o servicio se le asigna un cdigo de diez dgitos. La estructura de codificacin de productos representa una extensin realizada por la Oficina del Censo de los EE.UU. (U.S. Census Bureau). El sistema de clasificacin opera de modo que la cobertura industrial se hace ms estrecha con la adicin de sucesivos dgitos.

Tabla 5. Ejemplo sistema de clasificacin NAICS

2.4.5 Emparejamiento Semntico

El descubrimiento de servicios, debe estar basado en un emparejamiento semntico de las capacidades y descripciones de los SW. El concepto de emparejamiento semntico consiste en la bsqueda de dos descripciones de servicios con propiedades similares o exactamente las mismas.

95

El proceso de emparejamiento entre servicios ofertados y requeridos se basa en la informacin respecto al servicio, las IOPEs (Inputs, Outputs,

Preconditions, Effects) las cuales estn reflejadas en el perfil del servicio, as como informacin adicional de parmetros de servicio, informacin del proveedor etc.,

En la prctica el cliente debera ya conocer las IOPEs y lo que no sabr es el tipo de proceso, si ser atmico o por el contrario se tratar de una composicin de servicios en cuyo caso habr que realizar pasos intermedios que consultarn el modelo de proceso para identificar el flujo de trabajo desde la entrada a la salida (con la posibilidad de que la salida de un proceso intermediario sea usada como entrada en el siguiente proceso atmico en la secuencia dada) hasta que todos los procesos involucrados sean ejecutados.

Lei y Horrocks [23], describen algunos problemas derivados del diseo de la especificacin de un perfil de servicio. Ellos afirman que mediante ste, se puede dar demasiada informacin acerca de un servicio de tal forma que esto puede dificultar el uso de un razonamiento automtico que procese los emparejamientos entre descripciones semnticas. David Martin [16] como respuesta a este problema, afirma que para solucionarlo se requiere que se den algunas convenciones:

1. Que el proveedor exprese una clase de servicios usando una expresin lo ms general posible. 2. Que el cliente exprese una peticin para encontrar el servicio que desea usando una expresin lo ms especfica que pueda. 3. Cuando un cliente no tenga en cuenta el modo de restringir una propiedad, su peticin deber expresar esta situacin.

Limitando la bsqueda semntica de servicios a estas convenciones se restringe de manera notable su funcionalidad. El uso de anuncios lo ms

96

generales posibles que engloben la mayora de requerimientos dados para un determinado tipo de servicio, dejar fuera bajo estas restricciones a algunos servicios en los que el cliente tambin pueda haber estado interesado, como por ejemplo servicios mucho ms restrictivos o servicios con caractersticas similares pero con distintos valores para las propiedades de las restricciones.

2.4.5.1 Emparejamiento sensible a la calidad

La calidad de servicio se describe como la totalidad de caractersticas de un producto o servicio que son relevantes para su capacidad de satisfacer las necesidades ya establecidas o implcitas4. Para definir la calidad se tienen en cuenta aspectos tales como [30]:

1. Disponibilidad: La disponibilidad se refiere de si el servicio Web est

presente o listo para su uso inmediato.

Los valores ms altos

representan que el servicio est siempre listo para usar, mientras que valores menores indican incertidumbre de si el servicio estar disponible en un momento determinado. Tambin se asocia a la disponibilidad el tiempo de reparacin (TTR). TTR representa el tiempo que se tarda en reparar un servicio que ha fallado. Lo ideal sera valores pequeos para TTR. Accesibilidad: La accesibilidad es el aspecto de la calidad de un servicio que representa el grado en que es capaz de servir a una solicitud de servicio Web. Puede ser expresado como una medida de probabilidad que indica la tasa de xito o el azar de una creacin de instancias de servicios con xito en un punto en el tiempo. Puede haber situaciones en las que un servicio web est disponible pero no accesible,
4

2.

Norma ISO 9000 Sistema de gestin de calidad

97

escalabilidad se refiere a la capacidad de servir constantemente las solicitudes a pesar de las variaciones en el volumen de solicitudes.

3.

Integridad: La integridad es el aspecto de la calidad de cmo el servicio web mantiene la exactitud de la interaccin con respecto a la fuente, la ejecucin adecuada de las transacciones de servicios Web proporcionan la exactitud de la interaccin. Una transaccin se refiere a una

secuencia de actividades a ser tratadas como una sola unidad de trabajo. Todas las actividades tienen que ser completadas para hacer la transaccin con xito. Cuando una transaccin no se completa, todos los cambios realizados se revierten.

4.

Rendimiento: El rendimiento es el aspecto de la calidad de servicio Web, que se mide en trminos de rendimiento y latencia. Valores de mayor rendimiento y menor latencia representan un buen desempeo de un servicio Web. Rendimiento representa el nmero de solicitudes que el servicio Web responde en un determinado perodo de tiempo. La latencia es el tiempo de ida y vuelta entre el envo de una solicitud y la recepcin de la respuesta.

5.

Fiabilidad: La fiabilidad es el aspecto de la calidad de un servicio Web que representa el grado de ser capaz de mantener el servicio y la calidad del servicio. El nmero de fallos por mes o ao representa una medida de la fiabilidad de un servicio Web. En otro sentido, la fiabilidad se refiere a la entrega segura y ordenada de los mensajes enviados y recibidos por los solicitantes de servicios y proveedores de servicios.

6.

Regulador: regulador es el aspecto de la calidad del servicio Web de conformidad con las normas, la ley, el cumplimiento de las normas, y el acuerdo de nivel de servicio establecido. Los servicios Web utilizan una

98

gran cantidad de estndares como SOAP, UDDI y WSDL. La adhesin estricta a las versiones correctas de las normas (por ejemplo, la versin 1.2 de SOAP) por los proveedores de servicios es necesaria para la correcta invocacin de servicios Web de los solicitantes de servicios.
7.

Seguridad: La seguridad es el aspecto de la calidad del servicio Web de proporcionar la confidencialidad y no repudio mediante la autenticacin de las partes involucradas, cifrado de mensajes, y proporcionar control de acceso. Seguridad tiene mayor importancia

debido a que la invocacin de servicios Web se produce a travs de Internet pblico. El proveedor de servicios puede tener diferentes

enfoques y niveles para proporcionar seguridad en funcin del solicitante del servicio.

Los atributos de calidad se especifican en el perfil de la descripcin semntica del servicio, Octavio Martin en [20] utiliza los siguientes atributos de calidad: MMTF: Tiempo medio entre fallos, valor entero expresado en minutos. MTTR: Tiempo medio de recuperacin, valor entero expresado en minutos. RT: Tiempo de respuesta, valor entero expresado en milisegundos. CCODE: Cdigo de pas del cliente, valor enumerado. ETIME: Tiempo transcurrido entre dos invocaciones, valor entero expresado en decimas de segundo.

Para realizar el emparejamiento basado en la calidad del servicio se llevan a cabo los siguientes pasos:

99

1. El cliente solicita el servicio Web determinando que atributos de calidad desea que tenga.

2. El agente QoS (Quality of Service) busca los proveedores de servicios en el UDDI. 3. El agente QoS compara la calidad de servicio ofrecido con la calidad de servicio requerida y utiliza su informacin interna para determinar una calidad de servicio acordado. Este proceso se llama negociacin de QoS. 4. Si la negociacin de QoS ha sido exitosa, el solicitante del servicio y el proveedor de servicio son informados y se construye el enlace para que interacten.

2.4.5.2 Emparejamiento basado en restricciones

La programacin con restricciones es un campo de investigacin de la inteligencia artificial, y est reconocida como una de las direcciones de investigacin estratgicas por la ACM (Association for Computing Machinery) desde 1996.

Un problema de satisfaccin de restricciones (CSP, Constraint Satisfaction Problem) viene dado por un conjunto de variables, dominios finitos y restricciones que establecen relaciones entre dichas variables, de manera que se restringen los valores que pueden tomar. Toda solucin de un CSP consiste en la asignacin de un valor a cada variable, dentro de sus dominios y satisfaciendo todas las restricciones.

Los resolutores de restricciones permiten comprobar si un CSP es satisfactible, es decir, si tiene alguna solucin; tambin permiten obtener todas las soluciones segn una funcin-objetivo.

100

Las tareas de emparejamiento pueden ser expresadas como problemas de satisfaccin de restricciones, de manera que un componente software denominado resolutor encuentre las soluciones que satisfacen dichas restricciones. Un problema de satisfaccin de restricciones, denotado con , es una tupla de la forma (V, D, C) donde: V = {1, . . ., n} es el conjunto finito, no vaco, de variables. D = d1 . . . dn es el dominio del espacio de soluciones, que viene dado por el producto cartesiano de los dominios de las variables, donde di es el dominio finito que corresponde a la variable i con i [1 . . n]. C = {C1, . . ., Cm} es un conjunto de m restricciones sobre los valores que pueden tomar las variables de V en el dominio D.

Para expresar las tareas como restricciones se establecen conjuntos (V) de variables que representen los atributos del servicio web, por ejemplo:

A= {A1,.An} representa los atributos de calidad E= {E1,.. En} representa las entradas S= {S1,Sn} representa las salidas

Se construye el conjunto dominio D, de los valores de los atributos correspondientes a los servicios ofertados por proveedores. Y por ltimo se especifica el conjunto de restricciones con los valores que pueden tomar las variables V en el dominio D.

101

Por ejemplo:

( { A1, A2} , Variables

{ [02], [ 1.3] } , Dominios

{ A1 + A2 < 4, A1 A2 > 1} ) Restricciones

Una vez se ha modelado el sistema con restricciones, el resolutor trata de determinar si es satisfactible construyendo un rbol de bsqueda que tiene dos pasos fundamentales, etiquetado y bsqueda:

El procedimiento de etiquetado estndar establece el orden de asignacin de valores a las variables para encontrar una solucin. La ordenacin de variables es crtica, pues determina el tamao y forma del rbol de bsqueda. Usualmente, los resolutores lo construyen mediante un procedimiento que, por defecto, ordena las variables seleccionando aqulla que tiene el dominio ms pequeo, para reducir el tamao del rbol de bsqueda y descubrir los fallos anticipadamente.

A continuacin, los resolutores aplican una bsqueda en profundidad. Usualmente, a cada variable le asigna un valor de su dominio, entonces aplican la propagacin de restricciones para eliminar los valores que son inconsistentes y reduce el dominio del resto de variables mediante arco-consistencia. El orden de asignacin de valores a la variable de turno, siempre valores en su dominio que no hayan sido eliminados previamente por arco-consistencia, tambin es muy importante. En caso de fallo, el resolutor vuelve un paso atrs reconsiderando la asignacin de la variable actual.

Para optimizar las respuestas se pueden utilizar esquemas hbridos o tcnicas de programacin lineal.

102

2.4.5.3 Emparejamiento basado en acuerdos

Los acuerdos de nivel de servicio (SLA, Service Level Agreement) incluyen elementos como definicin de los servicios, medicin del rendimiento, gestin de los problemas, deberes del cliente, garantas y finalizacin del acuerdo5. En el contexto del emparejamiento de servicios Web solo se tiene en cuenta su definicin.

Existen lenguajes basados en XML para representar la definicin de un servicio web, tales como WSLA (Web Service Level Agreement), WSML (Web Service Management Language) y WSOL (Web Services Offerings Language) , en el mbito de la Web Semntica se destacan OWL-S (OWL for Services) y WSML (Web Service Modeling Language).

Fig. 21. Mapa conceptual de ofertas de acuerdo

5

Acuerdo de nivel de Servico - http://es.wikipedia.org/wiki/Acuerdo_de_nivel_de_servicio

103

WS-Agreement es una especificacin del Foro Global Grid (GGF, Global Grid Forum), que proporciona una estructura para describir ofertas de acuerdo y un protocolo para obtener acuerdos de nivel de servicio.

En los trminos de servicio, el proveedor describe el servicio ofertado mediante una referencia a su WSDL, y el cliente describe los servicios en los que est interesado por medio de palabras claves que indican una cierta funcionalidad.

Los trminos de la garanta estn constituidos principalmente por los objetivos de nivel de servicio a los que cliente y proveedor se comprometen respecto a unos servicios concretos incorporados a la oferta de acuerdo. Un trmino de la garanta est constituido por los siguientes elementos: Alcance Identifica a los trminos de servicio sobre los que se establece el trmino de garanta. Parte Obligada Identifica a la parte que se obliga a cumplir el trmino de la garanta. Objetivo de Nivel de Servicio (SLO, Service Level Objective ) Describe las obligaciones respecto a los trminos de servicio, que suelen expresarse como condiciones sobre las propiedades de servicio que tengan asociadas. Vigencia Indica la condicin que debe cumplirse para que el objetivo se considere vigente. Por ejemplo, pueden indicar perodos temporales que determinan la validez del objetivo en el tiempo. Valores de Negocio Indica la prdida o aumento de valor que a la parte obligada de cumplir el objetivo le supone su cumplimiento o su violacin.

104

La figura muestra un ejemplo de dos ofertas de acuerdo [20].

Fig. 22. Ejemplo de ofertas de acuerdo

Una oferta de acuerdo tiene dos partes claramente diferenciadas: el contexto y los trminos. A su vez, los trminos pueden distinguirse entre los que describen los servicios objeto del acuerdo (trminos de servicio) y los que describen las obligaciones (trminos de la garanta) respecto a dichos servicios.

La figura muestra el acuerdo que finalmente podra establecerse tras seguir un proceso de emparejamiento.

105

Fig. 23. Ejemplo de acuerdo de servicio

2.4.5.4 Emparejamiento basado en grados de similitud

El emparejamiento de servicios ofertados y requeridos se basa en que cuando un agente enva una peticin al matchmaker, ste le devolver como resultado informacin respecto al servicio que empareje con la descripcin dada en el requerimiento. Esta informacin incluir las IOPEs (Inputs, Outputs,

Preconditions, Effects) las cuales estn reflejadas en el perfil del servicio as como informacin adicional de parmetros de servicio, informacin del proveedor etc., que el proveedor del servicio habr comunicado con anterioridad al emparejador.

106

El grado de similitud depende de la relacin entre los conceptos (tomada de las ontologas) que se estn comparando, y generalmente se reduce a la mnima distancia entre ellos en el rbol taxonmico. Los grados de emparejamiento segn Samper en [21] son: Exacto: Los conceptos definidos por el cliente y por el proveedor son los mismos. CsubclaseP: En este caso el proveedor ofrece un concepto ms general que el que pide el cliente. PsubclaseC: El proveedor ofrece un concepto ms restrictivo que el demandado por el cliente. PsubsumeC: El concepto descrito por el cliente se encuentra dentro del subrbol de conceptos descendiente del definido por el proveedor. CsubsumeP: el concepto descrito por el proveedor se encuentra dentro del subrbol de conceptos descendiente del definido por el cliente, es decir, es el caso inverso al anterior. ChermanoP: el concepto proporcionado por el cliente y el del proveedor tienen restricciones en comn en alguna propiedad que ambos poseen, y adems, tanto el concepto ofertado por proveedor como el demandado por el cliente son hijos del mismo padre, es decir, son conceptos hermanos. Fail: cuando no se cumple ningn caso de los anteriores, es decir el concepto del proveedor y el de cliente no tienen relacin alguna.

107

Al obtener el grado de similitud, se procede a ejecutar el servicio ofertado que posea el mejor, lo ideal es un grado exacto.

2.4.6 Formalismos de emparejamiento 2.4.6.1 Lgicas Descriptivas El tratamiento de la mayor parte de lenguajes semnticos utilizados para describir acuerdos de calidad est basado en lgicas descriptivas.

Las principales operaciones que permiten realizar los emparejadores semnticos basados en lgicas descriptivas son: Comprobar la consistencia de una descripcin semntica. Esta operacin se utiliza para comprobar la consistencia de una oferta de acuerdo. Comprobar que una descripcin semntica subsume o es equivalente a otra. La subsuncin es una operacin por la que se comprueba si una descripcin semntica particular se incluye en una descripcin semntica ms general. La relacin de subsuncin permite inferir un grado de emparejamiento semntico, lo que a su vez da soporte a la eleccin del servicio adecuado.

El mayor problema de estos razonadores es que si el lenguaje de lgicas descriptivas es muy expresivo, su tratamiento puede tener una complejidad computacional muy alta e incluso puede ser no-decidible. 2.4.6.2 Lgicas de Primer Orden

En esta propuesta, el espacio de emparejamiento se representa como una teora lgica que se utiliza para formalizar tanto las descripciones semnticas

108

de las ofertas de acuerdo como las obligaciones de prueba que deben establecerse para determinar si hay conformidad.

Una obligacin de prueba se define como una consecuencia lgica entre las frmulas lgicas que representan a las ofertas de acuerdo, para as comprobar la conformidad.

Esta propuesta tambin presenta problemas de la complejidad computacional debido a la amplia expresividad de las descripciones lgicas. 2.4.6.3 Programacin Lineal

Se basa en modelar el problema de encontrar los servicios ptimos para un flujo de trabajo basado en servicios como un problema de programacin lineal

La optimalidad se resuelve como un problema de decisin de mltiples criterios. Se define un agregado para obtener una valoracin global del acuerdo entre una demanda y una oferta segn los criterios de preferencia disponibles. Este agregado se utiliza como funcin-objetivo. 2.4.6.4 Mtodos Ad Hoc

Muchas propuestas resuelven las tareas de emparejamiento mediante sus propios mtodos. En general, desarrollan algoritmos basndose en estructuras de datos tradicionales. Entre ellos, destacan los que plantean algoritmos de optimacin mediante clculo de matrices y similares, para obtener diferentes grados de emparejamiento. La expresividad de estas propuestas es mucha menor comparada con aqullas que utilizan formalismos subyacentes ms avanzados.

109

2.5

MODELADO DE PROCESOS

2.5.1 Introduccin Durante muchos aos el principal uso de las computadoras en las organizaciones fue la automatizacin de las actividades individuales dentro de las mismas, en los ltimos aos se ha tratado de ver a la organizacin como un todo. Existen un sin nmero de metodologas, notaciones para anlisis y diseo ya consolidadas (por ej. UML), as como herramientas de desarrollo cada vez ms potentes.

Todo ello, sumado a la necesidad de las organizaciones de poder adaptarse rpidamente a los cambios en los procesos internos que experimentan, ha motivado que se est produciendo un cambio de orientacin que apunta hacia los procesos de negocio.

El inters de las organizaciones ya no est limitado al desarrollo de software que automatice determinadas actividades individuales, sino que por el contrario, tienen como objetivo final la automatizacin de todo el proceso de negocio, ya que de ello depende en gran parte su competitividad. Surgen, por lo tanto, nuevas necesidades de capturar, modelar, ejecutar y monitorizar los procesos de negocio, vistos como un conjunto de

procedimientos o actividades enlazadas, cuya realizacin permite alcanzar un cierto objetivo o meta en el contexto de una organizacin.

Un proceso de negocio se puede ver como un conjunto estructurado de tareas, que contribuyen colectivamente a lograr los objetivos de una organizacin. Los procesos de negocio de una organizacin son parte de su cultura. Se registran y difunden en manuales de procedimientos, diagramas de flujo y hasta en forma verbal. Son la base operativa de una empresa y el xito de la misma depende fuertemente de la eficiencia con que sean gestionados. Una mala gestin de los procesos trae aparejados altos costos, baja productividad, e

110

inadecuados tiempos de respuesta tanto frente a las oportunidades como a las amenazas.

Como respuesta al problema del modelado de procesos de negocio dentro de una organizacin, en la dcada del 90 surge la tecnologa de workflow. Esta tecnologa permiti representar total o parcialmente los procesos de negocio en un formato entendible por una maquina. 2.5.2 Procesos de Negocio

Un proceso de negocio es un conjunto de tareas relacionadas lgicamente llevadas a cabo para lograr un resultado de negocio definido.

Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una funcin sea aplicada. Cuando una funcin es aplicada a las entradas de un mtodo, tendremos ciertas salidas resultantes.

Es una coleccin de actividades estructurales relacionadas que producen un valor para la organizacin, sus inversores o sus clientes. Es el proceso a travs del que una organizacin ofrece sus servicios a sus clientes. Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio.

Los procesos poseen las siguientes caractersticas:

1. Pueden ser medidos y estn orientados al rendimiento

2. Tienen resultados especficos 3. Entregan resultados a clientes o stakeholders

111

4. Responden a alguna accin o evento especfico

5. Tienen previamente establecido un inicio y un fin de proceso dentro de un espacio determinado.

6. Las actividades deben agregar valor a las entradas del proceso.

Hay tres tipos de procesos de negocio:

1. Procesos estratgicos: Estos procesos dan orientacin al negocio. Por ejemplo, "Planificar estrategia", "Establecer objetivos y metas".

2. Procesos sustantivos: Estos procesos dan el valor al cliente, son la parte principal del negocio. Por ejemplo, Repartir mercancas 3. Procesos de apoyo vertical u horizontal: Estos procesos dan soporte a los procesos centrales. Por ejemplo, Registrar los hechos econmicos, Dar Soporte/Servicio tcnico.

Los procesos de negocio consisten en subprocesos, decisiones y actividades. Un subproceso es parte de un proceso de mayor nivel que tiene su propia meta, propietario, entradas y salidas. Las actividades son partes de los procesos de negocio que no incluyen ninguna toma de decisin ni vale la pena descomponer. Por ejemplo, Responde al telfono, Haz una factura

Un proceso de negocio es usualmente el resultado de una reingeniera de procesos. Hammer y Champy definen a la reingeniera de procesos como la reconcepcin fundamental y el rediseo radical de los procesos de negocios

112

para lograr mejoras dramticas en medidas de desempeo tales como en costos, calidad, servicio y rapidez 6 .

Visto desde otro punto de vista la reingeniera es la respuesta a preguntas fundamentales para la buena optimizacin de los procesos de trabajo.

A su vez es muy importante debido a que busca llegar al origen de las cosas, es decir no solo mejorar los procesos de una empresa sino recrearlos. La reingeniera tiene cinco metas principales las cuales son:

1. Identificacin de procesos estratgicos.

2. Categorizacin de procesos para rediseo. 3. Desarrollo de visin para creacin de procesos. 4. Creacin y rediseo de procesos. 5. Preparacin y prueba de nuevos procesos.

Dentro de los cambios radicales que genera el aplicar reingeniera a los procesos de negocio, se destacan: Planeacin estratgica. Gestin de calidad total. Reestructuracin organizacional.

El modelado de procesos es usado para capturar, documentar y redisear procesos de negocio.

Institute of Industrial Engineers, "Ms all de la Reingeniera", CECSA, Mxico, 1995

113

2.5.3 Workflow

Workflow es un conjunto de uno o ms procedimientos o actividades directamente ligadas, que colectivamente realizan un objetivo del negocio, normalmente dentro del contexto de una estructura organizacional que define roles funcionales y relaciones entre los mismos.

Es el estudio de los aspectos operacionales de una actividad de trabajo: cmo se estructuran las tareas, cmo se realizan, cul es su orden correlativo, cmo se sincronizan, cmo fluye la informacin que soporta las tareas y cmo se le hace seguimiento al cumplimiento de las tareas.

Una aplicacin de Flujos de Trabajo (Workflow) automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecucin del proceso, incluyendo el seguimiento del estado de cada una de sus etapas y la aportacin de las herramientas necesarias para gestionarlo.

Se pueden distinguir tres tipos de actividad: Actividades colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado comn. Tiene entidad el trabajo de cada uno de ellos en s mismo. Actividades cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto particular, estableciendo los mecanismos de

cooperacin entre ellos. No tiene entidad el trabajo de ninguno de ellos si no es visto desde el punto de vista global del resultado final. Actividades de coordinacin.

114

El propsito de los sistemas de workflow es: Acercar personas, procesos y mquinas, con el objeto de reducir tiempo y acelerar la realizacin de un trabajo. Permitir el trabajo en equipo desde diferentes lugares fsicos. Facilitar la automatizacin de los flujos de trabajo entre procesos. Permitir integrar los procesos de la empresa, rediseados de acuerdo con ayuda de nuevas estrategias.

En un workflow, la informacin, tareas y documentos pasan de un participante a otro, para que se realicen una serie de acciones de acuerdo a un conjunto de reglas de negocio. Los sistemas que dan soporte a la definicin del flujo de trabajo y a su posterior ejecucin, se denominan Workflow Management System (WMS). 2.5.4 Sistema de Gestin del Flujo del Trabajo ( Workflow Management System)

Un sistema de gestin de flujo de trabajo es un sistema informtico que define, crea y gestiona una serie de tareas dentro de una organizacin para producir un resultado final o los resultados, permite definir diferentes flujos de trabajo para los diferentes tipos de trabajo o procesos.

Los WMS pueden ser implementados de diferentes formas como resultado de la utilizacin de diferentes tecnologas y plataformas. Pueden ir desde un pequeo grupo de trabajo a una gran organizacin. No obstante, todos los WMS exhiben ciertas caractersticas comunes.

En el nivel ms alto, todos los WMS pueden ser caracterizados por proveer tres reas de funcionalidad:

115

 Funciones de tiempo de Construccin (Build-time functions): Dedicadas a la definicin y modelado de un proceso junto con todas sus actividades concernientes. Funciones de control en tiempo de ejecucin (Run-time control functions: Controlan el proceso en el ambiente de ejecucin, llevando a cabo cada tarea (o actividad) definida como parte del proceso. Funciones de interaccin en tiempo de ejecucin (Run-time interaction): Interactan con los usuarios o aplicaciones externas para que los participantes del proceso puedan llevar a cabo sus tareas.

Fig. 24. Caracterizacin de los WMS por la WfMC

2.5.5 Modelo de referencia de Workflow

El Modelo de Referencia propuesto por la WfMC intenta reunir las caractersticas comunes a cualquier WMS, de manera de poder alcanzar la

116

interoperabilidad entre ellos, a travs de estndares comunes para cada una de las funciones que se puedan realizar.

Debido a que el objetivo de la WfMC es definir estndares y guas globales para el desarrollo de WMS, su documentacin es de carcter genrico y no describe en detalle ningn WMS en particular, sino que brinda un marco general para la construccin de los mismos.

En primer lugar, el modelo identifica las distintas reas funcionales para luego desarrollar las especificaciones para la implementacin de las mismas, asegurndose la interoperabilidad entre distintos WMS y su integracin con otras aplicaciones informticas.

Fig. 25. Modelo de referencia de WfMC

El componente central es el Servicio de Ejecucin del Workflow (Workflow Enactment Service) que se encarga de crear, gestionar y ejecutar cada una de las instancias del modelo de flujo de trabajo.

En este componente se encuentra el motor del WMS que proporciona la ejecucin de cada instancia de workflow. En caso de estar en un entorno de

117

ejecucin de flujo de trabajo distribuido, pueden existir diferentes motores de flujo de trabajo que controlen distintas partes de la ejecucin del proceso.

La comunicacin de este componente con el resto se realiza a travs de lo que la WfMC denomina WAPI (Workflow Apis), es decir, la interfaz para la programacin de aplicaciones de flujo de trabajo.

Otro de los componentes es el de Herramientas de Definicin del Proceso (Process Definition Tools) o flujo de trabajo, las cuales permiten modelar, describir y documentar un determinado flujo de trabajo o proceso de negocio. Estas herramientas pueden ser totalmente informales (lenguaje natural, lpiz y papel) o mucho ms sofisticadas y formalizadas. Se debe especificar la lgica del proceso, las actividades que lo componen, los participantes humanos, aplicaciones invocadas, datos utilizados, etc.

La interfaz 1 permite la comunicacin entre este componente y el servicio de ejecucin del flujo de trabajo. La distincin de ambos componentes aporta claros beneficios, entre los que se destaca la separacin entre el entorno de ejecucin y el de definicin. De este modo, es posible almacenar en un repositorio la informacin sobre la definicin del proceso y sta ser accedida por distintos entornos de ejecucin para ejecutarlo completamente o de forma distribuida.

La interfaz 1 se encarga por tanto del intercambio de informacin entre el componente que permite la definicin del proceso y el propio servicio de ejecucin del flujo de trabajo. Esta interfaz hace necesaria la definicin de un metamodelo bsico, en el que se identifique el conjunto mnimo de entidades para la definicin de un proceso, permitiendo el intercambio de informacin entre ambos componentes.

El componente denominado Aplicaciones Cliente del Workflow (Workflow Client Applications), representa las entidades de software utilizadas por el usuario

118

final en aquellas actividades que requieren participacin humana para su realizacin. Si este componente se separa de lo que es el propio componente de ejecucin, es necesaria una interfaz (interfaz 2) que defina y maneje claramente el concepto de lista de trabajos (o worklist), como una cola de trabajo asignado a un usuario o a un grupo de usuarios por el propio motor de ejecucin del flujo de trabajo.

El componente Aplicaciones Invocadas (Invoked Applications) representa software o aplicaciones ya existentes que un WMS puede utilizar para la realizacin de ciertas actividades, teniendo en cuenta que, en principio, dichas aplicaciones se pueden encontrar en cualquier plataforma o lugar de la red. La interfaz 3 permite la comunicacin entre este componente y el servicio de ejecucin del flujo de trabajo, no slo a nivel de invocacin del mismo, sino de transformacin de datos en formatos entendibles por ambos componentes.

Una posible solucin se obtiene a travs de lo que se denomina agente aplicacin, de modo que el servicio de ejecucin del flujo de trabajo se comunica con las funciones estndar de dicho agente aplicacin y ste define interfaces especficas para cada tipo de aplicacin invocada.

La interoperabilidad entre WMS est representada por el componente denominado Otros Servicios de Ejecucin de Workflow (Other Workflow Enacment Systems), siendo la interfaz la que permite dicha comunicacin. En este caso, la WfMC ha desarrollado un conjunto de escenarios de interoperabilidad que van desde la conexin a nivel de actividades simples hasta todo un completo intercambio de definicin de procesos y datos.

Finalmente, el componente Herramientas de Administracin y Monitorizacin (Administration & Monitoring Tools) permite que distintos servicios de ejecucin de flujo de trabajo compartan las mismas funciones de administracin y monitorizacin del sistema, como pueden ser, por ejemplo, la gestin de

119

usuarios, el control de los recursos y la supervisin del estado de todo el proceso. 2.5.6 Especificacin de un Workflow

La aparicin masiva de numerosos WMS puso en evidencia aun ms la falta de un modelo formal universal para la especificacin de un proceso de negocio. Esto dificulta de sobremanera la comparacin de las diferentes tecnologas y herramientas. Afortunadamente la especificacin de un workflow puede ser explicada en sentido general desde diferentes perspectivas: Perspectiva de Control de Flujo: describe actividades y su orden de ejecucin mediante diferentes constructores que permiten controlar el flujo de ejecucin (joins, splits, secuencias paralelismo, etc.). Estas actividades se pueden ver como unidades atmicas de trabajo. Perspectiva de Datos: describe los datos (documentos, objetos, etc.) que fluyen entre las diferentes actividades. Estos datos tambin pueden ser variables locales que definen pre y pos condiciones en la ejecucin de tareas. Perspectiva de Recursos: muestra una visin ms orientada al negocio, describiendo el proceso en funcin de las responsabilidades que tienen las diferentes personas o dispositivos en la ejecucin de una determinada tarea. Perspectiva Operacional: muestra las acciones elementales que se realizan dentro de las actividades, tales como invocar un determinado servicio de una aplicacin con determinados datos.

Si bien todas las perspectivas presentan una visin diferente del mismo sistema, la perspectiva de control de flujo provee un mejor panorama para la

120

especificacin de un workflow describiendo ms ampliamente el proceso en s mismo.

La perspectiva de datos solo se apoya en la mencionada anteriormente, mientras que la operacional es ms bien complementaria. 2.5.7 Composicin de servicios

La

composicin no solo permite modelar el proceso de negocio sino que

tambin maximiza las potencialidades que SOA brinda a travs de la integracin de datos y aplicaciones. La composicin de servicios implica encontrar un mecanismo que permita a dos o ms de ellos cooperar entre s para resolver requerimientos que van ms all del alcance de sus capacidades individuales.

Algunos de los requisitos bsicos que se deben cumplir son: Interacciones asincrnicas con servicios: De manera de dar la posibilidad de crear procesos que transcurran durante largos perodos de tiempo. Interacciones

simultneas

entre

servicios:

Esto

introduce

el

procesamiento en paralelo lo cual redunda en un aumento considerable de la eficiencia. Manejo de excepciones: Un proceso basado en mltiples servicios puede fallar en su ejecucin si al menos uno de sus componentes falla. Se debe tener en cuenta la ocurrencia de errores y proveer mecanismos para manejarlos.

121

 Integridad

transaccional:

Un

proceso

de

larga

duracin

puede

eventualmente fallar, en este caso puede requerirse que parte de las acciones ya efectuadas se deshagan.

Dos trminos comnmente usados para referirse a la colaboracin entre servicios son orquestacin con la y coreografa. pero Ambos estn se enfocan directamente en aspectos

relacionados

composicin

complementarios de la interaccin entre servicios. 2.5.8 BPM (Business Process Management)

El BPM, con sus enfoques evolucionados y sus tecnologas asociadas, se ha erigido como el componente crtico que proporciona a las organizaciones la agilidad y flexibilidad necesarias para responder de forma rpida y productiva a las nuevas oportunidades, a los cambios de mercado y a la legislacin y normativas vigentes. En un entorno donde el enfoque de Las 3 C (comunicacin, colaboracin y coordinacin) ya se ha convertido en algo normal como paradigma de modo de trabajo inter e intra empresas, es necesario recurrir a tecnologas que orquesten los procesos, organizacin, sistemas, clientes, colaboradores y otros entes externos.

Sin embargo, para ser completamente efectivo, BPM no debe enfocarse simplemente como un conjunto ms de herramientas informticas, sino como un entorno en el que una visin centrada en los procesos de la empresa sea el medio para comunicar las necesidades del negocio a toda la organizacin.

122

Fig. 26. BPM como entorno de orquestacin entre personas, procesos y sistemas

BPM es una metodologa empresarial cuyo objetivo es mejorar la eficiencia a travs de la gestin sistemtica de los procesos de negocio, que se deben modelar, automatizar, integrar, monitorizar y optimizar de forma continua. Como su nombre sugiere, BPM se enfoca en la administracin de los procesos del negocio.

A travs del modelado de las actividades y procesos puede lograrse un mejor entendimiento del negocio y muchas veces esto presenta la oportunidad de mejorarlos. La automatizacin de los procesos reduce errores, asegurando que los mismos se comporten siempre de la misma manera y dando elementos que permitan visualizar el estado de los mismos. La administracin de los procesos permite asegurar que los mismos se ejecuten eficientemente, y la obtencin de informacin que luego puede ser usada para mejorarlos. Es a travs de la informacin que se obtiene de la ejecucin diaria de los procesos, que se

123

puede identificar posibles ineficiencias en los mismos, y actuar sobre las mismas para optimizarlos.

Beneficios que se obtendrn al implementar BPM: Mejora del rendimiento y productividad del trabajo de todos los integrantes. Mejora de los tiempos de respuesta, reduccin de costes y aumento en la calidad y eficiencia en la operativa de la organizacin. Mejor calidad y servicio al cliente. Crecimientos y apertura de nuevos canales de forma rpida y minimizando el aumento de recursos. Mayor agilidad y flexibilidad de la informtica que soporta el negocio. Coordinacin, comunicacin y cooperacin independiente de la hora y situacin geogrfica. Mejora contina en los procesos: La estandarizacin de los mismos fomenta su replanteamiento de una manera distinta, ms estructurada y menos jerrquica, eliminando aquellos pasos que no aportan valor de negocio. Aumento de la sinergia entre la gestin de la informacin (documentos, formularios, contenidos web, datos de sistemas corporativos, etc.) y los flujos de trabajo. Completa auditora y trazabilidad de los procesos.

Las soluciones de BPM consisten en una serie de componentes relacionados que incluyen la capa de modelizacin, un entorno de ejecucin, la conectividad

124

tpicamente proporcionada a travs de servidores de integracin, capacidades de optimizacin y simulacin, as como la habilidad para monitorizar y realizar anlisis orientados al Business Intelligence sobre procesos y eventos particulares. A continuacin se describen ms en detalle cada una de las funcionalidades: Modelado de Procesos: Este componente permite el diseo grfico de los procesos de negocio, de forma que pueda ser utilizada por los usuarios de negocio sin necesidad de conocimientos tcnicos de programacin. Estas herramientas utilizan diferentes formatos de representacin de los procesos de negocio (formatos propietarios). Motor

de

orquestacin

de

Workflow:

Tambin

denominado

genricamente como motor BPM, este componente toma instrucciones de ejecucin a partir de un repositorio que contenga el modelado del proceso. Debe ser capaz de controlar a lo largo del tiempo (das, semanas o incluso meses) el estado de cada una de las tareas de las diferentes instancias de cada proceso, es decir, debe ser capaz de gestionar el estado del proceso. En caso de interrupcin de la ejecucin de un proceso, debe ofrecer mecanismos de recuperacin y

reanudacin. Motor de Reglas: Este componente est muy relacionado con el motor de ejecucin (muchas veces est englobado dentro del mismo) y permite definir reglas de negocio o condiciones basadas en parmetros asociados al proceso (por ejemplo, un importe, el puesto del participante, etc.). En funcin del resultado de ejecucin de la condicin el proceso evolucionar de manera diferente. Servidor de Integracin: Este componente implementa los interfaces con las diferentes aplicaciones o sistemas con los que se interacta a lo largo del proceso. El motor de ejecucin utiliza los servicios de este

125

componente,

bien

para

obtener

informacin

bien

para

incluirla/actualizarla en los sistemas afectados. Este componente debe ofrecer las funcionalidades bsicas de los productos EAI: conectores, mensajera, reglas de transformacin y enrutamiento, etc. Monitorizacin y anlisis de procesos: Los productos de esta categora ofrecen la posibilidad de analizar datos en tiempo real de ejecucin de los procesos de negocio, permitiendo identificar problemas en la ejecucin de los procesos como cuellos de botella, fallos de un sistema, etc. y tomar las acciones correctoras que sean necesarias. Ofrecen indicadores predefinidos pero tambin permite desarrollar nuevos indicadores definiendo cmo se calculan, mecanismos de extraccin de la informacin de origen, periodo de refresco, etc. Algunas herramientas ofrecen un interfaz visual de anlisis de los indicadores tipo Cuadro de Mando, permitiendo realizar anlisis propios de este tipo de sistemas (drill-down) para analizar la causa de un problema.

Simulacin / optimizacin: Permiten analizar el resultado de la introduccin de modificaciones en el diseo de los procesos, ofreciendo valores de costes en esfuerzo, valores econmicos, etc. Algunos productos permiten realizar las simulaciones con datos reales.

2.5.9 Estndares para la ejecucin de procesos

2.5.9.1 BPMN (Business Process Modeling Notation) BPMN fue desarrollado por BPMI (Business Process Management Initiative) y actualmente es mantenida por OMG (Object Management Group), luego de la fusin de las dos organizaciones en el ao 2005. Su versin actual es la 1.2 y hay una versin futura propuesta, la 2.0.

126

Su principal meta es proveer una notacin estndar fcil y clara para todos los usuarios de negocios: para los analistas de negocios que crean los borradores inciales de los procesos, para los desarrolladores tcnicos responsables de implementar la tecnologa que realizar esos procesos, y finalmente para el personal de negocios que administra y monitorea esos procesos.

As, BPMN hace de puente entre el diseo de procesos de negocio y la implementacin siendo una notacin grfica para expresar procesos de negocios en un Business Process Diagram (BPD) capaz de representar complejos procesos.

Otra meta, pero no menos importante, es asegurar que los lenguajes XML diseados para la ejecucin de procesos de negocio, tales como BPEL4WS (Business Process Execution Language for Web Services), puedan ser visualizados con una notacin orientada al negocio. Este lenguaje grfico puede ser mapeado sobre lenguajes como BPML y BPEL4WS.

La especificacin define la notacin y la semntica de un Business Process Diagram (BPD) e intenta representar la conjuncin de las mejores prcticas dentro de la comunidad para el modelado de procesos de negocio.

Un BPD est formado por un conjunto de elementos grficos. Estos elementos habilitan el fcil desarrollo de diagramas simples que sern familiares para la mayora de analistas de negocio (diagrama de flujo). Los elementos fueron elegidos para ser distinguibles los unos de los otros y para usar formas familiares para la mayora de modeladores.

Las cuatro categoras bsicas de elementos son: Objetos de flujo

Los tres objetos de flujo son:

127

Evento: un evento se representa con un crculo. Es algo que pasa durante el curso del proceso de negocio. Estos eventos afectan al flujo del proceso y suelen tener una causa (trigger) o un impacto (resultado). Los eventos representados con un crculo con centro abierto permiten a los marcadores internos diferenciar diferentes triggers y resultados. Hay tres tipos de eventos, basados en cuando afectan al flujo: Start , Intermediate, y End.

Fig. 27. Eventos

Actividad: una actividad se representa con un rectngulo redondeado y es un trmino genrico para el trabajo que hace una compaa. Una actividad puede ser atmica o compuesta. Los tipos que hay son: Task y Sub-Process. El Sub-Process se distingue por una pequea marca de suma en la parte central inferior de la figura.

Fig. 28. Actividad

Gateway (compuerta): una gateway se representa por la tpica figura de diamante y se usa para controlar la divergencia o

128

convergencia de la secuencia de flujo. As, esto determina las tradicionales decisiones, as como la creacin de nuevos caminos, la fusin de estos o la unin. Los marcadores internos indicarn el tipo de control de comportamiento.

Fig. 29. Gateway

Objetos de conexin

Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto bsico de la estructura de un proceso de negocio. Hay tres objetos conectores que hacen esta funcin. Estos conectores son:

Sequence Flow: el flujo de secuencia se representa por una lnea slida con una cabeza de flecha slida y se usa para mostrar el orden (la secuencia) en el que las diferentes actividades se ejecutarn en el Proceso.

Fig. 30. Sequence Flow

Message Flow: el flujo de mensaje se representa por un lnea discontinua con una punta de flecha hueca y se usa para mostrar el flujo de mensajes entre dos participantes del proceso separados (entidades de negocio o roles de negocio). En BPMN, dos pools separadas en el diagrama representan los dos participantes.

129

Fig. 31. Message Flow

Association: una asociacin se representa por una lnea de puntos con una punta de flecha de lneas y se usa para asociar datos, texto, y otros artefactos con los objetos de flujo. Las asociaciones se usan para mostrar entradas y salidas de las actividades.

Fig. 32. Association

Swimlanes (Carriles de piscina)

Muchas metodologas de modelado de procesos usan el concepto de swimlanes como un mecanismo para organizar actividades en categoras separadas visualmente para ilustrar diferentes capacidades funcionales o responsabilidades. BPMN soporta los swimlanes con dos constructores principales. Los dos tipos de objetos swimlanes son:

Pool: una pool representa un Participante de un Proceso. Adems acta como un contenedor grfico para particionar un conjunto de actividades desde otros pools, normalmente en el contexto de B2B.

130

Lane: una lane es una sub-particin dentro de un pool y extiende la longitud del pool, verticalmente u horizontalmente. Las lanes se usan para organizar y categorizar actividades.

Fig. 33. Pool y Lane

Las pools se usan cuando un diagrama implica dos entidades de negocio o participantes separados y estn fsicamente separados en el diagrama. Las actividades dentro de pools separadas se consideran procesos auto contenidos. As, el flujo de secuencia no debe cruzar el lmite de un pool. El flujo de mensajes se define como el mecanismo para mostrar las comunicaciones entre dos participantes, y, de este modo debe conectar dos pools (o los objetos dentro de las pools).

Las pistas (lanes) estn ms estrechamente relacionadas con las metodologas tradicionales de las swimlanes. Las pistas se suelen usar para separar las actividades asociadas con la funcin o rol de una compaa especfica. El flujo de secuencia puede cruzar los lmites de las pistas

131

dentro de un pool, pero el flujo de mensajes no puede ser usado entre objetos de flujo en pistas de mismo pool.

Artefactos: Objetos de Datos, Grupo, Anotacin

BPMN fue diseado para permitir a los modeladores y las herramientas de modelado un poco de flexibilidad a la hora de extender la notacin bsica y a la hora de habilitar un contexto apropiado adicional segn una situacin especfica, como para un mercado vertical (por ejemplo, seguros o banca). Se puede aadir cualquier nmero de artefactos a un diagrama como sea apropiado para un contexto de proceso de negocio especfico. Hay tres tipos de artefactos BPD predefinidos, los cuales son:

Data Object: los objetos de datos son un mecanismo para mostrar como los datos son requeridos o producidos por las actividades. Estn conectados a las actividades a travs de asociaciones.

Fig. 34. Data Object

Group: un grupo es representado por un rectngulo redondeado con lnea discontinua. El agrupamiento se puede usar

documentacin o anlisis, pero no afecta al flujo de secuencia.

132

Fig. 35. Group

Annotation: las anotaciones son mecanismos para que un modelador pueda dar informacin textual adicional.

Fig. 36. Annotation

2.5.9.2 YAWL (Yet Another Workflow Language)

Es un lenguaje de workflow basado en los patrones de Workflow. Este lenguaje est soportado por un sistema de software que incluye un motor de ejecucin y un editor grfico.

El lenguaje y su sistema de soporte fueron desarrollados originalmente por investigadores de la Universidad Eindhoven de Tecnologa y la Universidad Queensland de Tecnologa. Consecuentemente, varias organizaciones tales como Grupo InterContinental de Hoteles, first:telecom y ATOS Worldline se han unido a esta iniciativa y el sistema YAWL est ahora disponible como software Open source software bajo la licencia LGPL.

133

Los hitos tras YAWL fueron definir un lenguaje de workflow que soportaran todo (o la mayora) de los Patrones de Workflow y que tuvieran una semntica formal. Observando que las Redes de Petri se acercaba bastante a dar soporte a la mayora de los Patrones de Workflow, los desarrolladores de YAWL decidieron tomar Redes de Petri como un punto de partida y extender esta formalizacin con tres constructores principales, nombrado or-join, grupos de cancelacin, y actividades multi-instancia.

Estos tres conceptos estn llamados a soportar cinco de los Patrones de Diseo que no fueron incluidos directamente en las Redes de Petri, llamados agrupados de sincronizacin, discriminador, N-fuera-de-M join, instancia mltiple instance con conocimiento no a-priori y caso de cancelacin. En suma a esto, YAWL aade algunos elementos sintcticos a las Redes de Petri de forma que sea posible capturar intuitivamente otros Patrones de Diseo tales como opcin simple (xor-split), simple sincronizacin (xor-join), y multiple opcin (or-split).

Durante el diseo del lenguaje, puso de manifiesto que algunas de las extensiones que fueron aadidas a Petri nets eran difciles e incluso imposibles de recodificar en sencillo Petri nets.

Como resultado, la semntica formal original de YAWL est definida como un Sistema de transiciones etiquetado y no en trminos de Petri nets. El hecho de que YAWL est basado en semntica formal ha puesto en marcha la implementacin de distintas tcnicas parar analizar procesos YAWL. En particular, el sistema YAWL incluye una herramienta de anlisis esttico llamada WofYAWL. 2.5.9.3 ebXML (eBusiness XML)

En 1999 se inici el proyecto Electronic Business XML (ebXML) con el objetivo de crear un mercado global electrnico nico. Una iniciativa

134

patrocinada por el United Nations Centre for Trading Facilitation en Electronic Business (UN/CEFACT) y la Organization for the Advancement of Structured Information Standards (OASIS). Segn sus propios autores La visin de ebXML es la creacin de un mercado electrnico global en el que puedan contactar empresas de cualquier tamao y localizacin geogrfica para llevar a cabo negocios mediante el intercambio de mensajes XML 7, ebXML se compone de cinco especificaciones distintas, cada una de ellas desarrollada de manera independiente: Messaging. Este servicio de mensajera se responsabiliza del transporte, enrutado y empaquetamiento de los datos de negocio en un formato estndar, si bien ebXML no define ningn formato concreto. Los mensajes ebXML usan una versin mejorada de SOAP2 que permite incluir ficheros adjuntos con contenido binario (usando empaquetado MIME). Este servicio tambin abarca las cuestiones relativas a la seguridad, los llamados Security Services, que incluyen la generacin y verificacin de firmas digitales, la autenticidad y autorizacin relativa a un mensaje, etc. Adems existe soporte para garantizar la fiabilidad del intercambio de los mensajes y el tratamiento de errores. Business Processes. Definidos los documentos de negocio, podemos especificar los procesos que los manejan, es decir, capturar de manera sistemtica el flujo de datos en el intercambio de informacin. Para ello, se utiliza la metodologa UMM (UN/CEFACT Modeling Methodology) que a su vez se apoya UML3 (Unified Modeling Language) como lenguaje de modelado y la plasma luego en XML. As se refleja el conocimiento en un formato estndar, bajando hasta el nivel de detalle necesario y de manera independiente de la implementacin tcnica.

http://www.ebxml.org/specs/qrROAD.pdf

135

Aquellos procesos de negocio

muy comunes, correspondientes a

empresas del mismo sector, pueden ser definidos por una organizacin (o consorcio), ayudando de esta manera a la interoperabilidad. Trading Partner Profiles and Agreements: Otra caracterstica

importante de ebXML es la representacin, de manera sistemtica, de las capacidades de una empresa para hacer los negocios

electrnicamente; CPP (Collaboration Protocol Profile). Los CPPs proporcionan a las compaas un formato XML comn para listar las industrias, los procesos de negocio, los mensajes, y las tecnologas de intercambio de datos que pueden usar. Las empresas, usando sus CPP, llegan a acuerdos que son reflejados en un CPA (Collaboration Protocol Agreement). Para reflejar cuestiones no tcnicas de tipo legal pueden usar un TPA (Trading Partner Agreement).

Registries and Respositories: En los repositorios se almacenan los registros ebXML, que contienen los CPPs. Estas funciones son claves para las compaas que usan ebXML, y que pretenden expandirse a nuevos campos o que buscan nuevos compaeros de negocio. Core Components. Permiten identificar de manera nica los diferentes trminos que utilizan las empresas para relacionarse. La unificacin pretende abarcar tanto a empresas que pertenezcan a diferentes mbitos como a las que estn, dentro del mismo mbito, pero en un nivel distinto. Si algn tipo de documento no corresponde a las necesidades, pueden modificarse los tipos existentes o crear nuevos tipos vlidos. Estos componentes bsicos (Core Components) pueden tener diferente nivel de complejidad. Los ms bsicos son comparables con el concepto informtico de tipo de datos, por ejemplo un componente nombre que

136

debe ser una cadena de caracteres alfanumricos, ste ser a su vez componente de estructuras ms complejas como una direccin o una cuenta bancaria. Los componentes disponen de informacin de contexto: dnde se engloban y con qu papel, de esta manera se pueden agregar complejidad. para crear objetos de informacin de mayor

La idea es maximizar la reutilizacin de elementos predefinidos y llegar as a un compromiso ptimo entre las necesidades de personalizacin que requiere una relacin comercial entre dos empresas y el esfuerzo requerido para definirla. Resulta ms sencillo estandarizar tipos de documentos de mayor nivel si sus componentes bsicos se encuentran estandarizados.

2.5.9.4 BPEL (Business Process Execution Language)

Es un estndar que permite la realizacin de una manera comprensiva la optimizacin de procesos de negocio.

BPEL es una herramienta que proporciona flexibilidad a los negocios al sustituir o aumentar ciertos aspectos de un proceso sin la afectacin de los sistemas que estn trabajando bien. Por ejemplo, una compaa puede cambiar su abastecedor de servicio del almacn sin la afectacin de su sistema de gerencia de la orden, aun cuando ambos pueden ser participantes en varios procesos del negocio.

Conocido tambin como WS-BPEL, surgi cuando IBM y Microsoft realizacin un lenguaje de procesamiento del negocio, combinando dentro de este WORKFLOW, WSFL (Web Services Flow Lenguaje) y XLANG, conocida en ese momento como BPEL4WS (lenguaje de proceso de la ejecucin del negocio para los servicios del

137

Web). BPEL4WS 1.0, sali al mercado en Agosto de 2002 por IBM, BEA, Microsoft, SAP, y los sistemas de Siebel.

Despus de BPEL4WS 1.0, una mejora de menor importancia 1.1 fue lanzada en Mayo de 2003 y sometida oficialmente al OASIS (Organization for the Advancement of Structured Information Standards).

2.5.9.5 WS-BPEL (Web Services Business Process Execution Language)

WS-BPEL 2.0 (Lenguaje de Ejecucin de Procesos de Negocio con Servicios Web), es un lenguaje estandarizado por OASIS para la composicin de servicios web. Est desarrollado a partir de WSFL y XLANG, ambos lenguajes orientados a la descripcin de servicios Web. Bsicamente, consiste en un lenguaje basado en XML diseado para el control centralizado de la invocacin de diferentes servicios Web, con cierta lgica de negocio aadida que ayuda a la programacin en gran escala (programming in the large). Antes de su estandarizacin se denominaba BPEL4WS.

Fig. 37. rbol genealgico de WS-BPEL

138

WS-BPEL define un conjunto de actividades y procesos: Actividades: Intercambio de mensajes o transformacin de resultados intermedios.

Actividades bsicas Invoke: Invocacin de operaciones one-way o requestresponse en un servicio web. Receive: Permite el bloqueo de un proceso a la espera de llegada de un mensaje.

Response: Permite enviar un mensaje en respuesta a un mensaje recibido previamente. Wait: Permite la espera durante un tiempo del proceso. Assign: Permite copiar datos de un lugar a otro. Throw: Permite indicar que ha ocurrido un error. End: Permite finalizar la orquestacin de la instancia en curso. Actividades Estructuradas Sequence: Define un orden secuencial de tareas. Switch: Permite seleccionar un camino en particular en base a una condicin.

139

 While: Permite repetir un grupo de tareas mientras se cumpla una determinada condicin.

Procesos: Resultado de la composicin, consiste en un conjunto de actividades.

WS-BPEL trata todos los estados como una coleccin de tipos de mensajes WSDL. Esa coleccin de mensajes que constituyen un estado es lo que se llama contenedor. Los mensajes de un contenedor pueden ser los enviados o recibidos con clientes o servicios externos; incluso los utilizados internamente por el proceso para computacin temporal de los mismos. Asimismo, la comunicacin se define a travs de los PortType de los WSDL.

WS-BPEL sostiene la idea de un contenedor para cada tarea en el flujo definido, cada uno de los cuales tiene una definicin de esquema. As, un mensaje se corresponde a un contenedor, que bsicamente es un servicio web con informacin adicional sobre como procesarlo, posibles pre-condiciones y post-condiciones.

Fig. 38. Proceso definido en WS-BPEL

140

Todos los accesos a datos y manejos de los mismos en WS-BPEL son definidos utilizando estndares como XPath y XSLT, adems de basarse en los contratos de servicios establecidos por medio de los WSDL. Durante la ejecucin de un proceso se pueden establecer ms de una conversacin con servicios externos, por lo que es necesario establecer mecanismos a nivel de aplicacin para corresponder los mensajes y conversaciones con las instancias de procesos que sean objetos de los mismos. Para ello, WS-BPEL ofrece lo que se conoce como Correlation Sets o Grupos de Correlaciones. Estos son conjuntos de propiedades, que juntos sirven para definir una conversacin a nivel de aplicacin dentro de una instancia de proceso. Bsicamente son identificadores nicos de instancias de proceso, que permite saber en todo momento que instancia corresponde a qu mensaje recibido o enviado a travs del mismo. WS-BPEL puede ser utilizado tanto para orquestacin de servicios (llamadas a procesos ejecutables; entendiendo como tal las llamadas a servicios y la especificacin de como se llevan a cabo) como para coreografa de servicios (llamadas a procesos abstractos; entendiendo como tal los mensajes pblicos a intercambiar entre dos o ms partes).

141

CAPITULO III

TRABAJOS RELACIONADOS

Algunos de los trabajos de investigacin ms destacados que han estudiado o propuesto diferentes mtodos para la descripcin, composicin y

emparejamiento de servicios web semnticos son:

ONTOLOGIAS PARA SERVICIOS WEB SEMANTICOS DE INFORMACION DE TRAFICO: DESCRIPCION Y HERRAMIENTAS DE EXPLOTACION Jos Javier Samper Zapater Universidad de Valencia, Valencia Espaa. Tesis Doctoral Julio, 2005

Presenta la propuesta de un modelo de integracin basado en Web Semntica para el desarrollo de SW de informacin de trfico, este modelo fue construido con las siguientes caractersticas: Los SW de trfico estn descritos semnticamente empleando lenguajes de ontologas. Diferentes ontologas que describen los diversos dominios de conceptos que se emplean en el sistema. Un componente encargado de realizar el emparejamiento de la peticin de servicio realizada por un posible cliente con todos los servicios disponibles. Permite la construccin de los perfiles de SW requeridos.

142

Los actores del sistema son: Cliente o Usuario: es la persona que usa el sistema. Agente cliente: agente con el rol de cliente. Representa al usuario dentro de la plataforma, y proporciona al agente la descripcin del servicio que busca. Proveedor: empresa, organizacin o persona que anuncia un servicio en la plataforma mediante un agente proveedor. Agente proveedor: agente con el rol de proveedor de servicio web, representa al proveedor dentro de la plataforma. Agente emparejador: agente que tiene el rol de matchmaker, es el encargado de emparejar en funcin de su proximidad semntica, descripciones de servicios recibidas de clientes con descripciones de servicios anunciados por los proveedores. Facilitador de directorio (DF): agente incluido en las plataformas que cumplen el modelo FIPA que se utiliza para facilitar las tareas de administracin de los agentes. Cumple la funcin de pginas amarillas. Servicio(s) Web: servicios web externos a la plataforma y que son representados dentro de ella por agentes proveedores. Emparejador de servicios: emparejador de servicios basado en la descripcin semntica de sus capacidades, y que ser utilizado por el agente emparejador.

143

Los casos de uso pueden ser observados de forma grfica en la figura:

Fig. 39. Diagrama de casos de usos.

144

SISTEMA BASADO EN TECNOLOGIAS DEL CONOCIMIENTO PARA ENTORNOS DE SERVICIOS WEB SEMANTICOS (SEMMAS) Francisco Garca Snchez Universidad de Murcia, Murcia Espaa Tesis Doctoral Julio, 2007

Presenta la propuesta de un modelo para relacionar agentes inteligentes y servicios web semnticos de forma no intrusiva. El sistema esta constituido por siete agentes, cuatro bases de conocimiento que contienen las ontologas necesarias y tres interfaces para interaccionar con entidades externas al sistema: consumidores de servicios, proveedores de servicios y desarrolladores de software.

Fig. 40. Arquitectura del sistema

Descripcin de los agentes:

145

1. Customer

Agent:

Acta

como

representante

de

los

usuarios

consumidores de servicios. 2. Discovery Agent: Es el encargado de buscar en los repositorios de SWS aquellos que satisfagan un objetivo dado. 3. Selection Agent: es el responsable de seleccionar los servicios mas apropiados entre aquellos pertenecientes a una lista de servicios dada. 4. Porvider Agent: acta como representante de los proveedores de servicio. 5. Service Agent: acta como representante de los servicios disponibles. 6. Broker Agent: es el responsable de resolver los problemas de interoperabilidad que puedan surgir en las comunicaciones que tienen lugar los restantes agentes. 7. Framework Agent: es el encargado de monitorizar el estado de los agentes en todo momento, as como controlar las interacciones entre los restantes componentes del sistema.

Descripcin de las bases de conocimiento: 1. Ontologa de aplicacin y del dominio: la de aplicacin contiene el conocimiento esencial para poder modelar una aplicacin en particular, la del dominio constituye la conceptualizacin del dominio particular con el que trabaja la plataforma.

2. Ontologa de conocimiento local de agentes: contiene, para cada agente, el conocimiento que este dispone acerca de su entorno, la tarea que tiene encomendada y los mecanismos y recursos de que dispone para satisfacer dicha tarea.

146

3. Ontologa de negociacin: contiene los elementos que constituyen todo mecanismo de negociacin, el protocolo de negociacin y la estrategia. 4. Ontologa de servicios web semnticos: en esta base de

conocimiento de encuentran almacenadas las descripciones semnticas de las capacidades de los servicios web.

Fig. 41. Infraestructura del sistema

Las tareas que lleva a cabo el sistema para lograr su objetivo son: Descubrimiento: consiste en encontrar los SW apropiados para resolver un objetivo procedente de la necesidad de un solicitante, para esto se hace uso de una ontologa, realizada con OWL-S o WSMO, que modela los objetivos a satisfacer por los componentes del entorno en cada momento, mas concretamente, el descubrimiento de realiza haciendo corresponder las salidas esperadas por el objetivo con las salidas que produce el servicio.

147

 Composicin: Se utiliza un algoritmo que tiene como entrada el objetivo que representa las necesidades del usuario, primero se realiza la bsqueda de los servicios que corresponden con dicho objetivo y si se encuentra alguno, entonces el mtodo termina, en caso de no encontrar ningn servicio apropiado para el objetivo inicial, este se descompone en sub objetivos, que sern nuevamente procesados para encontrar servicios que los satisfagan.

Seleccin: este mecanismo se basa en un proceso de negociacin donde, adems de las propiedades no funcionales de descripciones semnticas de los servicios, se tienen en cuenta las preferencias establecidas por los usuarios finales y las que opcionalmente, hayan podido incluir los proveedores. Invocacin: la lleva a cabo el agente Service Agent. Monitorizacin: al comenzar la ejecucin, tanto el agente representante del usuario, como los representantes de los servicios, comienzan el proceso de monitorizacin por el que cada parte asegura que la otra parte implicada esta cumpliendo lo establecido en el contrato. Negociacin: en tiempo de ejecucin, los agentes adoptan un acuerdo sobre el uso de uno u otro mecanismo de negociacin (esto es, protocolo y estrategia) segn la ontologa de negociacin. Mediacin: es un mecanismo mediante el cual los problemas de incompatibilidad son solucionados.

148

EMPAREJAMIENTO

AUTOMATICO

DE

SERVICIOS

WEB

USANDO

PROGRAMACION CON RESTRICCIONES Octavio Martin Diaz Universidad de Sevilla, Sevilla Espaa. Tesis Doctoral Septiembre, 2007

Propone un marco de trabajo HDM( Holistic Decision Maker) con tres niveles de abstraccin que proporciona el soporte para la automatizacin de las tareas de emparejamiento.

Fig. 42. Niveles del marco de trabajo HDM

A continuacin se explican los niveles de abstraccin: 1. Modelo Abstracto: En este nivel se describen las tareas de emparejamiento utilizando la teora de conjuntos para darles una semntica formal. Las ofertas de acuerdo tienen una estructura abstracta que incluye el conjunto de atributos y sus dominios, los predicados que representan a los objetivos y determinan las regiones de acuerdo, los criterios de preferencias y las probabilidades de ocurrencia que caracterizan a los atributos no- controlables.

149

2. Modelo Operacional: en este nivel se define el soporte operacional del emparejamiento de servicios. Este modelo tiene dos partes; el tratamiento especifico de la consciencia temporal y la interpretacin de las tareas de emparejamiento como problemas de satisfaccin de restricciones (CSP) o como problemas de optimacin (CSOP).

Los CSP y CSOP correspondientes a las tareas del emparejamiento se obtienen transformando las ofertas de acuerdo, de manera que sus diferentes partes, tales como atributos, dominios, predicados, criterios de preferencia y probabilidades de ocurrencia, se transforman, respectivamente, en variables, dominios, restricciones y funciones objetivos, segn sea el caso. Los CSP y CSOP se escriben en lenguaje OPL.

El aspecto temporal consta de un algoritmo de proyeccin temporal que apoya a los resolutores de restricciones en las tareas de

emparejamiento con consciencia temporal. 3. Modelo de Implementacin: Este nivel proporciona la implementacin del modelo, el resolutor de restricciones utilizado es OPL-Studio de ILOG, el cual es un entorno de desarrollo integrado para la resolucin de restricciones, que incluye un componente COM para que pueda ser utilizado desde las aplicaciones. El resolutor lleva a cabo las tareas de emparejamiento mediante la construccin de un rbol de bsqueda que tiene dos pasos fundamentales, etiquetado y bsqueda.

El procedimiento de etiquetado establece el orden de asignacin de valores a las variables para encontrar una solucin.

A continuacin, el resolutor aplica una bsqueda en profundidad. A cada variable se le asigna un valor de su dominio, entonces aplican la

150

propagacin de restricciones para eliminar los valores que son inconsistentes y reduce el dominio del resto de variables mediante arcoconsistencia. UN MODELO DE PLANIFICACION INCREMENTAL PARA SERVICIOS WEB SEMANTICOS Jaime Alberto Guzman Luna, Demetrio Arturo Ovalle Carranza Universidad Nacional de Colombia, Medelln- Colombia. Documento de propuesta, GIDIA (Grupo de Investigacin y Desarrollo en Inteligencia Artificial) Diciembre, 2007

La propuesta de INDIGO se conforma de varios mdulos para pre procesar la informacin, planificar y ejecutar de manera incremental una composicin de servicios Web. Toma como entrada un tiempo de respuesta del sistema un conjunto de servicios OWLS disponibles una descripcin parcial del dominio de la Web y una consulta de planificacin expresadas mediante ontologas OWL.

El sistema retorna al usuario el resultado correspondiente a la ejecucin de una secuencia de un plan de servicios compuesto que satisface el objetivo consultado.

La arquitectura de INDIGO consta de un Convertidor de especificaciones OWLS a PDDL, el planificador para llevar a cabo una planificacin incremental de los servicios Web y el ejecutor para inicializar el problema de planificacin y ejecutar de manera concurrente cada una de las acciones que son planteadas por el planificador, como se observa en la figura.

151

Fig. 43. Arquitectura del sistema INDIGO

INDIGO primero convierte las ontologas del dominio y de la consulta, junto con las descripciones de los servicios implementadas respectivamente en OWL y OWLS, a las descripciones equivalentes del problema y el dominio en el lenguaje PDDL usando un convertidor de especificaciones.

La descripcin del dominio contiene la definicin de todos los tipos, predicados y acciones, mientras la descripcin del problema incluye todos los objetos, el estado inicial, y el estado objetivo.

Ambas descripciones son usadas por el planificador de Inteligencia Artificial de INDIGO para crear un plan de composicin de manera incremental el cual cuando sea ejecutado concurrentemente logre solucionar la consulta dada. Es

152

as, como un operador PDDL del dominio de planificacin corresponde a un perfil del servicio (service profile ) en OWLS ya que tanto el operador y el perfil, en esencia, describen un patrn o plantilla de cmo una accin o una instancia de un servicio Web debera ser vista.

Fig. 44. Diagrama de secuencias del funcionamiento de INDIGO

El ejecutor inicia el proceso de planificacin envindole las especificaciones del dominio, el estado y los objetivos en el formato PDDL, para lo cual el sistema de planificacin realiza el clculo de la primera accin (a0) y luego de un tiempo de espera el ejecutor realiza una peticin de esta primera accin al planificador, quien le entrega la especificacin de la misma.

Luego de esto, el ejecutor lleva a cabo la ejecucin de esta accin a0, para lo cual toma un tiempo en dicha ejecucin, el cual es aprovechado por el planificador para calcular la segunda accin del plan. Cuando el ejecutor termina de ejecutar la primera accin solicita al planificador la segunda accin y se repite el proceso hasta que se alcancen todos los objetivos solicitados.

153

SISTEMA MULTIAGENTE PARA LA COMPOSICION DE SERVICIOS WEB SEMANTICOS Jorge Giraldo Plaza, Jaime Guzman Luna, Albert Ledesma Castillo Universidad Nacional de Colombia, Medelli Colombia. Articulo Mayo, 2008

MAS-CommonKADS, es una metodologa de propsito general para el desarrollo de SMA.

El usuario del sistema declara los objetivos que desea se lleven a cabo, y activa el proceso de composicin.

Fig. 45. Arquitectura general del SMA

154

El sistema permite: Describir Objetivos, lo cual permite identificar cules son las caractersticas del servicio web compuesto mediante una tcnica de relacin de objetivos Componer Servicio, permite definir la secuencia de servicios que se debern ejecutar para alcanzar los objetivos solicitados por el usuario. Ejecutar Servicio, este caso se orienta a la ejecucin de la secuencia de servicios que representa al servicio web compuesto generado por el sistema.

Los agentes que conforman el sistema y que permiten realizar los anteriores casos de uso, son: Agente Usuario, ste est asociado con el caso de uso Describir Objetivos y representa la interfaz con la cual interactan los actores humanos para ingresar los objetivos. Agente TraductorA, el cual est asociado al caso de uso Componer Servicios; Selecciona y transforma la descripcin OWLS de los servicios disponibles en el repositorio en el contexto del problema y genera los archivos que definen un problema de planificacin en el lenguaje PDDL. Agente Compositor, est tambin asociado al caso de uso Componer Servicios y es el encargado de generar la secuencia de ejecucin de servicios (plan). Agente TraductorB, asociado al caso de uso Ejecutar Servicio, permite transformar la secuencia de ejecucin en un servicio web compuesto OWLS.

155

 Agente Ejecutor, asociado al caso de uso Ejecutor Servicio, realiza el proceso de ejecucin del servicio web compuesto OWLS.

El sistema se complementa con varios sistemas externos; uno es el SimPlanner, que es un planificador IA independiente del dominio, el cual es controlado a travs del Agente compositor. Otro es el sistema ejecutor, que emplea parte de la API OWL-S, provee de manera programtica lectura, escritura y ejecucin de documentos OWL-S. Es controlado a travs del Agente Ejecutor.

El repositorio de servicios web, registra los servicios y permite al Agente TraductorA acceder a sus descripciones.

El usuario interacta con una interfaz grfica, controlada por el Agente usuario, la cual permite ingresar los objetivos y ejecutar la orden de inicio del proceso de composicin. Para ello, debe generarse una definicin del problema (estado inicial y estado objetivo), as el planificador conoce los objetivos que persigue.

En la siguiente figura, se detalla la interfaz grfica asociada al agente Usuario, la cual se compone de varias listas desplegables que se van activando de acuerdo al nmero de objetivos o condiciones inciales que necesiten. Tiene como evento principal Componer Servicio. Una vez se genera esta orden, los objetivos son enviados al agente TraductorA, para que se generen los archivos PDDL que representan el problema de composicin como un problema de planificacin.

156

Fig. 46. Interfaz Grafica del Agente Usuario

ANALISIS DE LAS TECNOLOGIAS EXISTENTES PARA LA DESCRIPCION, COMPOSICION Y EJECUCION AUTOMATICA DE SERVICIOS WEB SEMANTICOS Delvis Mirllan Ortiz Bermejo Universidad de Pamplona, Pamplona - Colombia. Trabajo de grado Mayo, 2009

Este trabajo realiza un estudio sobre las tecnologas existentes para la descripcin, composicin y ejecucin automtica de los servicios web semnticos.

157

Para realizar la descripcin semntica de los servicios se requieren de ontologas de descripcin. Dentro de las ontologas para descripcin de servicios hay dos principales que son WSMO y OWL-S.

Con la descripcin semntica del servicio se logra crear una base de conocimiento.

En ella se distinguen dos partes: Tbox y Abox. El Tbox contiene el conocimiento normativo (terminolgico) en forma de una terminologa y es construido a travs de declaraciones que describen propiedades generales de conceptos. El Abox contiene conocimiento extensional o factual (aserciones sobre objetos), especfico para los individuos del dominio de discurso.

Posterior a la creacin de la base de conocimiento se requiere de un sistema de inferencia que se utiliza para poder razonar sobre la base de conocimiento.

Hay muchos estilos de razonador automatizado y diferentes algoritmos de razonamientos. Jena incluye soporte para una variedad de razonadores a travs de la API de inferencia. Para comunicarse con el razonador se requiere una interfaz, dicha interfaz es DIG que est compuesta de una interfaz DIG central, la cual cubre los servicios bsicos y un nmero de extensiones, proporcionando servicios adicionales de razonamiento o extendiendo la expresividad del DIG central.

Para hacer posible los Servicios Web Semnticos, es necesario describir el dominio mediante una ontologa, de dicha ontologa se extrae la informacin mediante el razonador. Para la bsqueda de servicios es necesaria la utilizacin de un emparejador semntico, existe una versin inicial de dicho algoritmo y fue propuesto por Paolucci, este algoritmo fue retomado por Samper quien lo modific, de cuatro a siete grados de emparejamiento y tuvo en cuenta otras funcionalidades del servicio como la categora y la calidad.

158

Fig. 47. Diagrama de secuencia del prototipo desarrollado 159

Para aplicar el algoritmo de emparejamiento se evala cada Servicio Web Semntico de acuerdo a la categora de bsqueda del usuario, si se encuentra una categora se procede a obtener un grado de emparejamiento evaluando la descripcin en el orden de los grados.

Despus de evaluar todas las descripciones se procede a seleccionar la que tenga mayor grado de emparejamiento, en caso de no haber un empate, se ejecuta el servicios web relacionado en dicha descripcin y en caso de encontrar un empate se procede a seleccionar el que tenga mejor calidad y en caso de que tengan la misma calidad, se ejecuta cualquiera.

Algunos de los artculos ms destacados que han estudiado diferentes mtodos para el diseo y gestin de procesos de negocio son:

GESTION DE PROCESOS DE NEGOCIO SEMANTICOS Noelia Prez Crespo, henar Muoz de Frutos, David de Francisco marcos, Javier Martnez Elicegui. Artculo, Telefnica Investigacin y Desarrollo 2007

SUPER (Semantics Used for Process management within and between EnteRprises), es un proyecto financiado por la Comunidad Econmica Europea que trata de aunar la disciplina BPMS con la tecnologa semntica con el fin de resolver los problemas en la gestin de los procesos de negocio.

160

Fig. 48. Arquitectura de SUPER

La arquitectura de SUPER define el conjunto de herramientas y componentes necesarios para seguir todo el ciclo de vida de los procesos de negocio. Mientras que las herramientas se centran en la fase de modelado, anlisis y monitorizacin, los componentes se utilizan durante todo el ciclo de vida del proceso de negocio, para proporcionar las funcionalidades requeridas para conseguir la flexibilidad de los procesos de negocio. Estas herramientas y componentes estn apoyadas por el uso de los Servicios Web Semnticos (tecnologa WSMO), los cuales son resultado de la investigacin de proyectos europeos anteriores.

INTEGRACION DE PROCESOS DE NEGOCIO BASADOS EN SERVICIOS WEB: COREOGRAFIA Y SATISFACCION DE RESTRICCIONES Jorge Giraldo, Jaime Guzman, Demetrio Ovalle. Artculo de la revista de Ingenieras Universidad de Medelln, Medelln Colombia Abril, 2008

En este trabajo se busca proponer una solucin para automatizar la especificacin de una coreografa de servicios web en el lenguaje WSCDL a

161

partir de un grupo de servicios web y un conjunto de objetivos; as se pretende modelar, con base en restricciones, las interacciones entre los servicios que componen la coreografa.

ONTOLOGIA PARA RELACIONAR PROCESOS DE NEGOCIO Y SU REALIZACION COMO SERVICIOS Andrea Delgado, Ignacio Garcia - Rodriguez de Guzman. Universidad de la Republica, Montevideo Uruguay Universidad de Castilla La Mancha, Ciudad Real, Espaa. Articulo 2009

La ontologa general propuesta se define en base a paquetes de alto nivel que agrupan conceptos relacionados, los que se muestran en la figura:

Fig. 49. Ontologa de alto nivel para Procesos de Negocio Orientados a Servicios

Cada uno de los paquetes definidos se compone de elementos agrupados por temtica en cada sub-ontologa, adems de los paquetes correspondientes a las sub-ontologas se muestran las relaciones entre stas. As, la sub-ontologa de ejecucin de Procesos de Negocio se corresponde con la de Modelado de

162

Procesos de Negocio: los elementos de la segunda estn relacionados con elementos de la primera.

La sub-ontologa de Modelado Orientado a Servicios, se obtiene de la de Modelado de Procesos de Negocio: a partir de elementos de la segunda se obtienen elementos de la primera como un modelo de servicios que se corresponde con un modelo de procesos de negocio.

Por otro lado, los elementos en la sub-ontologa de ejecucin de Procesos de Negocio usan elementos en la de ejecucin Orientada a Servicios, una ejecucin de un PN invocar ejecucin de servicios asociados a las actividades del flujo. Las otras tres sub-ontologas aplican sobre las anteriores, as, la sub-ontologa de Medicin de Procesos de Negocio integra medidas para modelos y ejecucin de PN, y elementos adaptados de la Ontologa para medicin de Software (SMO).

La sub-ontologa de Anlisis de Procesos de Negocio utiliza elementos de la de Medicin y especficos de la ejecucin de PN, definiendo otros para analizarlos, como Process Mining para anlisis de logs generados en la ejecucin. La subontologa de Simulacin de Procesos de Negocio define elementos que permiten simular y comprender diversos aspectos de los modelos en forma previa a su ejecucin

163

CAPITULO IV 4 4.1 PROTOTIPO DESARROLLADO Arquitectura del Sistema

Fig. 50. Arquitectura del sistema

El principal objetivo de este trabajo es disear e implementar un prototipo que logre automatizar los procesos de negocio mediante el uso de los servicios web semnticos, para cumplir esta meta se diseo un sistema que se encuentra constituido por una aplicacin de usuario, tres procesos, dos repositorios de ontologas y una interfaz DIG, a continuacin se hace una breve descripcin de los componentes:

Aplicacin de Usuario: Es una interfaz web que permite al consumidor seleccionar un dominio especifico y un proceso de negocio a ejecutar.

164

 Repositorio de Ontologas de Dominio: En este repositorio se almacenan las ontologas necesarias para describir los diferentes tipos de dominio. Repositorio Ontologas OWL-S: En este repositorio se almacenan las ontologas construidas con OWL-S que describen a los servicios web disponibles. DIG: Permite realizar el razonamiento necesario sobre las ontologas de dominio y las ontologas OWL-S. Composicin: Este proceso recibe la solicitud del consumidor, y extrae del repositorio de ontologas de dominio la ontologa de acuerdo al dominio especificado por el consumidor para realizar la composicin de servicios que satisfaga el proceso de negocio solicitado. Emparejamiento: Este proceso recibe la composicin de servicios, y para cada uno de ellos busca la mejor opcin comparando su descripcin con las descripciones semnticas de los servicios

disponibles que se encuentran en el repositorio de ontologas OWL-S. Ejecucin: Este proceso ejecuta la composicin de servicios

emparejados que integran al proceso de negocio solicitado y entrega el resultado al consumidor a travs de la interfaz de usuario.

4.2

Repositorio de Ontologas de Dominio

Para llevar a cabo la composicin de servicios que satisfagan un proceso de negocio es necesario crear un repositorio donde se almacenen ontologas correspondientes a cada dominio.

165

Estas ontologas deben tener una estructura bsica, la siguiente figura muestra dicha estructura vista como un modelo entidad-relacin:

Fig. 51. Modelo Entidad-Relacin para Ontologas de Dominio

Dentro de un proceso de negocio existen funcionalidades que se representan por roles y pueden ser asociados servicios web para realizar dichas funcionalidades. Cada funcionalidad tiene un conjunto de entradas y/o salidas, donde una salida puede ser entrada para otra funcionalidad dentro del proceso de negocio.

Para detallar los campos necesarios en cada entidad, se presenta el modelo relacional en la siguiente figura.

166

Fig. 52. Modelo Relacional para Ontologas de Dominio

Las caractersticas de las entidades son: Proceso: Posee dos campos, el identificador del proceso de negocio y la clasificacin, en este trabajo se utilizo la clasificacin propuesta por UNSPSC [7]. Funcionalidad: Posee dos campos, el identificador de la funcionalidad y la fornea del proceso de negocio al que representa. Rol: Posee cuatro campos, las dos forneas de la funcionalidad y proceso al que pertenece, el nombre y el orden en el que se ejecuta en un proceso de negocio especifico. Salida: Posee cuatro campos, el identificador, la fornea de la funcionalidad a la que pertenece, la fornea del campo que la describe y el nombre. Entrada: Posee cinco campos, la fornea de la funcionalidad a la que pertenece, el campo que la describe, el nombre, el tipo de entrada [teclado, proceso] y si es tipo proceso, la fornea de la salida de la que se debe tomar el valor.

167

 Campo: Posee dos campos, el identificador y el nombre. Teniendo clara la estructura que deben tener las ontologas, se procede a convertir las entidades en clases, los atributos en instancias y las relaciones en propiedades. Los componentes del modelo ontolgico propuesto son:

CLASES

Fig. 53. Clases para las Ontologa de Dominio

PROPIEDADES

Fig. 54. Propiedades para las Ontologa de Dominio

168

 INSTANCIAS

Fig. 55. Instancias de la Clase Rol para una Ontologa de Dominio

Las clases se relacionan entre s a travs restricciones realizadas con propiedades. Las restricciones creadas en el modelo ontolgico propuesto son:

Fig. 56. Restricciones para las Ontologas de Dominio

169

4.3

Repositorio de ontologas OWL-S

Para llevar a cabo el emparejamiento de los servicios que componen un proceso de negocio es necesario crear un repositorio donde se almacenen ontologas correspondientes a las descripciones semnticas de los servicios web disponibles. 4.3.1 Creacin de un servicio web

Para crear los servicios web se utilizo NetBeans IDE 6.58. Los pasos bsicos para crear servicios web en NetBeans son: Crear una aplicacin web

Iniciar NetBeans IDE 6.5 Seleccionar Archivo Proyecto Nuevo Java Web Web Application Colocarle nombre a la aplicacin. Clic en siguiente Verificar que el servidor seleccionado sea GlassFish V2 y el campo Java EE Versin este seleccionado con Java EE 5. Terminar Crear un servicio web

Clic derecho sobre la raz del nodo de la aplicacin web Seleccionar Nuevo Web Service

Netbeans IDE 6.5

http://download.netbeans.org/netbeans/6.5/beta

170

Fig. 57. Crear un Servicio Web

Colocarle nombre al servicio web y al paquete Clic en Terminar Observe que el servicio web se ha creado exitosamente ya que se agrego un nuevo nodo a la aplicacin web. En el Tab Source se puede apreciar el cdigo del servicio web. En el Tab Design se pueden agregar las operaciones de manera grfica. Agregar una Operacin

Seleccione el Tab Design Clic en Add Operation Asignar nombre a la operacin. Seleccionar el tipo de la variable de retorno. Agregar los parmetros de entrada con su respectivo tipo.

171

Fig. 58. Agregar una operacin a un servicio Web

Clic en Aceptar. Si regresamos al Tab Source podemos observar que se ha generado el cdigo de la operacin adicionada. Acceder a una base de datos (Opcional)

Para poder acceder a una base de datos y realizar consultas sobre ella, se debe agregar una nueva conexin de base de datos, para esto se deben realizar en la pestaa Prestaciones los siguientes pasos:

Clic derecho en el nodo Base de Datos Seleccionar Nueva Conexin de Base de Datos Llenar los campos

172

Fig. 59. Llenar los campos para la nueva conexin de base de datos

Clic en Aceptar Seleccione el esquema public. Clic en Aceptar Se puede observar al expandir el nodo Base de datos que se ha creado una nueva conexin a la base de datos.

Fig. 60. Nueva Conexin de base de datos creada

Ahora se puede hacer uso de la conexin establecida con la base de datos, de la siguiente manera: Ubicarse en el Tab Source

173

Clic derecho en la clase principal del archivo Java del Servicio Web

Fig. 61. Insertar cdigo para la conexin con una base de datos

Seleccione Insertar Cdigo Use Database En el cuadro de dialogo que aparece, frente a Reference, hacer clic en el botn Add. Frente a Project Data Sources, hacer clic en el botn Add. Asignar un nombre para JNDI Name. Seleccionar en el cuadro Database Connection, la conexin que se cre anteriormente.

Fig. 62. Insertar Codigo de Use Database

174

Clic en Aceptar En el cuadro de dialogo Add Data Source Reference, asignar un nombre al campo Reference Name. Clic en Aceptar En el cuadro de dialogo Choose Database clic en Aceptar

Se puede observar que se ha generado el cdigo necesario para acceder a la base de datos. Se escribe la implementacin de la operacin y tenemos creado el servicio web.

Fig. 63. Cdigo Java del Servicio Web creado

Clic derecho sobre la raz del nodo de la aplicacin web Deploy Clic derecho sobre el nodo del servicio web Test Web Service

175

Se abrir una pgina web para probar el servicio web creado, tambin podemos obtener la direccin del WSDL, necesaria para la descripcin del servicio.

http://localhost:8080/Tienda_Electronica/AlmacenService?WSDL

4.3.2 Descripcin semntica de los servicios Web

Las dos tecnologas destacadas para realizar la descripcin semntica de servicios web son WSMO y OWL-S.

WSMO tiene en cuenta ms aspectos de descripcin que OWL-S, adems cuenta con cuatro tipos de mediadores para solucionar problemas que se presenten, pero OWL-S tiene una coreografa claramente definida mediante procesos simples, atmicos y compuestos. Permite una sola forma de interactuar con el servicio invocndolo mediante el WSDL, mientras que WSMO no tiene coreografa definida ni forma de interactuar con el servicio por s solo, necesita de otros entornos para poder invocar servicios.

OWL-S posee tres elementos fundamentales que caracterizan un servicio y permiten describir sus capacidades: Service Model Service Grounding Service Profile

176

Por estas razones, en este trabajo, la descripcin se llevo a cabo mediante el plugin OWL-S9 para Protg10, para configurarlo basta con descargarlo, copiarlo en la carpeta pluggins de Protg (C:\Archivos de programa\Protege\plugins), ejecutar Protg y activarlo como se muestra en la figura:

Fig. 64. Habilitar el plugin OWL-S en Protg

Para generar la descripcin a travs del documento WSDL del servicio web, se selecciona el icono Generate OWL-S instances from a WSDL Document que se encuentra en la ventana del plugin OWL-S.

OWLS-S Protg-OWL Editor

http://protege.stanford.edu/plugins/owl/download.html http://protege.stanford.edu/

10

177

Fig. 65. Importando WSDL para generar la descripcin semntica de un SW.

En el campo Enter URL, se copia la direccin del WSDL del servicio web a describir, automticamente se generan las operaciones que contiene el servicio.

Fig. 66. Informacin del WSDL importado

178

Se puede guardar esta descripcin en un archivo .owl para su posterior procesamiento. Al cerrar esta venta podemos observar que se ha generado la descripcin del servicio web, y podemos modificar o agregar informacin.

Fig. 67. Elementos de las descripcin semntica generados

Tambin se puede realizar la descripcin manualmente, para esto se debe seguir un orden: 1. process:Process: se describe el servicio como un proceso simple , atmico o compuesto, en este trabajo se describen como procesos atmicos ya que la composicin es un proceso separado ms complejo. En el editor individual se especifica el nombre del proceso, sus entradas y sus salidas.

179

Fig. 68. Editor Individual de process:Process

2. grounding:WsdlGrounding .Aqui se especifica la informacin necesaria para poder acceder al servicio, los campos requeridos son

grounding:owlsProcess :Nombre del proceso

grounding:owlsOperation : Nombre de la operacin del process

WSDL Inputs: Entradas

WSDL Ouputs: Salidas

grounding:wsdlDocument: Direccion del documento WSDL

180

Fig. 69. Editor individual de grounding:WsdlGrounding

3. profile:Profile. Aqu se especifican los campos correspondientes al proceso en general; entradas, salidas, categora, clasificacin,

precondiciones, resultados e informacin adicional.

Fig. 70. Editor individual de profile:Profile

181

4. service:Service, aqu se crea el servicio que une al grounding, process y profile, se establece que el servicio es descrito por el process, presentado por el profile y soportado por el grounding.

Fig. 71. Editor Individual de service:Service

De esta manera se lleva a cabo la descripcin semntica de todos los servicios web que contendr el repositorio de ontologas OWL-S. 4.4 DIG

Para poder razonar sobre las ontologas y adquirir el conocimiento necesario para el desarrollo del prototipo, se utilizo la interfaz DIG. La interface DIG fue desarrollada por The DL Implementation Group (DIG)11. Esta interfaz permite tener acceso a razonadores de DL a travs de editores de ontologas. Para ello utiliza un protocolo basado en HTTP PUT/GET y XML, que le permite describir los conceptos y las relaciones en una ontologa.
11

http://dl.kr.org/dig/

182

El razonador utilizado fue Pellet12.

Es un razonador open source para OWL-DL construido en JAVA. El ncleo de este razonador est basado en los algoritmos de razonamiento Tableaux (tablas semnticas).

En la Figura podemos observar la arquitectura de Pellet, en la que destaca el razonador basado en clculo de Tableaux, la flexibilidad con la que Pellet puede ser incluido con otros sistemas (a travs de interfaces apropiados), en este trabajo se incluyo en la interfaz DIG, para aumentar sus funcionalidades, y la posibilidad de resolver consultas realizadas en el lenguaje SPARQL.

Fig. 72. Arquitectura de Pellet

Para poder razonar con Pellet hay que cargar la ontologa, los axiomas sobre clases (suclases, clases equivalentes axiomas disjuntos) son colocados en el componente TBox y las aserciones sobre los individuos (tipo y afirmaciones sobre propiedades) se almacenan en el componente ABox.

12

http://www.mindswap.org/2003/pellet/

183

El objetivo de este razonador es chequear la satisfactibilidad de un Abox con respecto a un TBox mediante mensajes declaraciones XML que definen un modo de comunicacin tell/ask.

El protocolo de envo de mensajes consta de peticin y respuesta mediante documentos XML, el servidor usar el elemento raz del mensaje para determinar el tipo de mensaje.

Usando la interfaz DIG se envan las bases de conocimiento al servidor DIG mediante declaraciones tells y luego se usa el modo de comunicacin asks para inferir informacin desde el razonador.

La interfaz DIG consta de las siguientes clases: DIGConstants:En esta clase se establecen las diferentes constantes y su valor. DIGErrors: En esta clase se establecen los diferentes tipos de errores que pueden ocurrir. ElementList: Esta clase permite crear una lista de nodos.

PelletDIGServer: Esta clase permite crear el puerto por donde se va a escuchar (8081 para pellet), crear el contexto, y empezar el servidor. DIGHandler: Esta clase posee una serie de mtodos que permiten obtener y establecer la base de conocimiento. DIGResponse: Esta clase permite crear el documento de respuesta. DIGTellHandler : Esta clase permite crear un lista con los elementos que tiene el documento tell, obtener el nombre de cada elemento y adicionarlos a la base de conocimiento.

184

 DIGAskHandler: En esta clase se verifica si la base de conocimiento es consistente, se obtienen los elementos de la etiqueta asks con su nombre e id, se determina el tipo y de acuerdo a la etiqueta se llama al mtodo adecuado. PelletDIGReasoner: En esta clase se establecen los tipos de ask y tell que se soportan, mediante el mtodo public Document process( Document cmd ) se procesa el documento comparando el valor de la etiqueta con las DIGConstants para llamar al mtodo adecuado y retornar el resultado, el mtodo public Document getIdentifier() permite adicionarle un id al documento de respuesta, public String newKB() permite establecer la nueva uri, public KnowledgeBase newKB( String newURI) permite asignarle la nueva uri a la base de conocimiento.

185

Fig. 73. Diagrama de secuencia Interfaz DIG

186

4.5

Composicin

El proceso de composicin se encarga de buscar los servicios necesarios para satisfacer un proceso de negocio especfico. El algoritmo principal recibe el nombre del proceso de negocio que el cliente especific, crea un rbol que tiene como raz dicho proceso, llama al mtodo procesando que se encarga de llevar a cabo la composicin y por ultimo invoca un mtodo (rbol.mostrar(rbol)) que realiza un recorrido postorden sobre el rbol generado para obtener la secuencia de los servicios a ejecutar.

Fig. 74. Mtodo composicin principal

El mtodo procesando lleva a cabo los siguientes pasos: Busca en la ontologa de dominio correspondiente, los servicios que componen el proceso de negocio especificado por el cliente. Busca la informacin correspondiente a dichos procesos, tales como clasificacin, funcionalidad a la que pertenece, orden en que se ejecuta, entradas, salidas, etc. Ordena el vector de roles de acuerdo al orden en que deben ejecutarse. Agrega los servicios al rbol.

187

 Recorre el vector de roles llamndose recursivamente de tal forma que realice la composicin para todos los roles encontrados.

Fig. 75. Mtodo Composicin Procesando

El mtodo encargado de buscar los servicios utiliza la interfaz DIG y el razonador Pellet para inferir conocimiento sobre la ontologa de dominio, lo primero que hace es cargar el archivo Newkb.xml, utilizado para indicar que se requiere crear una nueva base de conocimiento, luego de obtener una nueva uri mediante el mtodo newKB() de la clase PelletDIGReasoner para

188

asignarla tanto a la base de conocimiento como a los documentos tell y ask cargados previamente en memoria, se crea un documento que contiene la consulta para obtener los servicios que posee el proceso recibido, se llama al mtodo process tanto para el tells como para el asks, guardando las respuestas que devuelve en los archivos Respuesta_Tell.xml y Respuesta_Ask.xml, siendo este ultimo el que contiene los servicios buscados.

Fig. 76. Mtodo Buscar servicios

El resultado de la composicin es un rbol N-Ario de los servicios que componen el proceso de negocio.

189

Fig. 77. rbol N-Ario de composicin de servicios

4.6

Emparejamiento

El proceso de emparejamiento consiste en buscar para cada servicio, resultado de la composicin, la mejor opcin publicada en el repositorio de ontologas OWL-S.

El algoritmo de emparejamiento usado est basado en la propuesta realizada por Jos Javier Samper Zapater [21], quien plantea un sistema de emparejamiento basado en la semntica descrita en el perfil (Profile) de los servicios y en la utilizacin de los registros UDDI para mantener descripciones de los servicios. Un emparejamiento entre un anuncio y una peticin de servicio consiste en emparejar todas las salidas de la peticin con las del anuncio; y todas las entradas del anuncio con las de la peticin, calculando grados de similitud.

El algoritmo de emparejamiento tiene un coste considerable ya que intenta emparejar la descripcin del servicio con cada uno de los proveedores

190

disponibles, y para hacer esto cada una de sus entradas y/o salidas se contrasta con todas las de cada proveedor para encontrar la que ms se le parezca semnticamente. Por esta razn, se incluye un filtrado anterior al emparejamiento, cuya finalidad es descartar proveedores que no cumplan unas determinadas caractersticas definidas tambin en los perfiles de la ontologa, y de este modo reducir el tiempo de ejecucin.

El filtrado est basado en la categora de servicio, campo que se encuentra en la descripcin del servicio obtenida de la ontologa de dominio. Servir al sistema emparejador para obtener del repositorio de ontologas OWL-S aquella lista de servicios que pertenezcan a la categora que posee el servicio a emparejar.

De la lista resultante, combinar todas las posibles parejas y aplicar sobre ellas los diferentes grados de similitud para los parmetros funcionales y calcular los pesos relativos para: Parmetros funcionales correspondientes a salidas Parmetros funcionales correspondientes a entradas Parmetros no funcionales

El clculo de pesos relativos a las entradas y parmetros no funcionales se har siempre que el grado de similitud de una pareja en cuanto a sus salidas sea positivo, es decir, que tengan alguna salida en comn.

El riesgo de obtencin de falsos positivos o negativos ser menor dependiendo de la precisin en la descripcin de la ontologa de dominio.

191

4.6.1 Obtencin del grado de emparejamiento para parmetros funcionales

Se calculan siete grados de emparejamiento explicados a continuacin, en orden descendente de importancia. Exacto: Los conceptos definidos por el cliente y por el proveedor son los mismos. CsubclaseP: Dentro del rbol de la taxonoma de conceptos la distancia entre el concepto demandado por el cliente y el ofrecido por el proveedor es igual a 1, siendo por tanto, el descrito por el cliente, subclase directa del que proporcion el proveedor. En este caso el proveedor ofrece un concepto ms general que el que pide el cliente. El concepto del cliente es ms restrictivo pero est incluido en el que proporciona el proveedor.

Fig. 78. Grafo que representa el caso CsubclaseP

PsubclaseC: el concepto descrito por el proveedor es subclase directa del que pide el cliente, es decir, el proveedor ofrece un concepto ms restrictivo que el demandado por el cliente.

192

Fig. 79. Grafo que representa el caso PsubclaseC

PsubsumeC: el concepto descrito por el cliente se encuentra dentro del subrbol de conceptos descendiente del definido por el proveedor, se considera que conceptos a distancias mayores o iguales a 3 niveles no tienen prcticamente relacin semntica, por ello se fijo la profundidad mxima en dos niveles, por lo que solo se comprueba si el concepto definido por el cliente es como mximo nieto del concepto del proveedor. .

Fig. 80. Grafo que representa el caso PsubsumeC

CsubsumeP: El concepto descrito por el proveedor se encuentra dentro del subrbol de conceptos descendiente del definido por el cliente, es decir, es el caso inverso al anterior, aqu tambin se limita a dos niveles de profundidad la comprobacin de si el concepto demandado por el cliente incluye (subsume) al ofertado por el proveedor.

193

Fig. 81. Grafo que representa el caso CsubsumeP

ChermanoP: El concepto proporcionado por el cliente y el del proveedor tienen restricciones en comn en alguna propiedad que ambos poseen, y adems, tanto el concepto ofertado por proveedor como el demandado por el cliente son hijos del mismo padre, es decir, son conceptos hermanos.

Fig. 82. Grafo que representa el caso ChermanoP

Fail: Cuando no se cumple ningn caso de los anteriores, es decir el concepto del proveedor y el de cliente no tienen relacin alguna.

194

Fig. 83. Obtencin del grado de emparejamiento para parmetros funcionales

En la figura se observa el pseudocdigo del mtodo que calcula el grado de emparejamiento.

4.6.1.1 Obtencin del grado de emparejamiento para salidas

En la siguiente figura se observa el pseudocdigo correspondiente al grado de emparejamiento de los parmetros funcionales correspondientes a las salidas, segn el grado obtenido se asigna un peso que va desde 0 cuando el grado es fallo; no hay relacin entre el servicio del proveedor y la peticin del cliente, y 6 que se asigna cuando lo que el proveedor ofrece es igual a lo que el cliente busca.

195

Fig. 84. Asignacin de pesos para los grados de emparejamiento de las salidas

4.6.1.2 Obtencin del grado de emparejamiento para entradas

Si el valor de la variable peso.salidas para el emparejamiento en proceso es igual a cero, se descarta el servicio del proveedor; de lo contrario se procede a calcular el grado de emparejamiento y el peso para las entradas, en la siguiente figura se observa el pseudocdigo.

196

Fig. 85. Asignacin de pesos para los grados de emparejamiento de las entradas

4.6.2 Obtencin del grado de emparejamiento para parmetros no funcionales

Los parmetros no funcionales tambin aportan informacin semntica al servicio web, por lo cual deben ser tenidos en cuenta. El parmetro a tener en cuenta en este trabajo es el de nombre del servicio, el cual aportara un valor a la variable peso.otros igual a 3 si el nombre del

197

servicio que se est emparejando es igual al nombre del servicio ofrecido por un proveedor.

4.6.3 Seleccin del mejor servicio emparejado

A medida que se van calculando los pesos para los diferentes tipos de parmetros, se va insertado de manera ordenada el servicio emparejado en una lista. La ordenacin utilizada da ms importancia al peso de las salidas, ya que lo ms importante es que el cliente obtenga lo que quiere, que debe ser lo que le proporciona el proveedor mediante las salidas del servicio.

A continuacin se compara la suma de los pesos obtenidos con los parmetros de tipo no funcional, posteriormente, se compara el peso de las entradas, ya que stos se consideran parmetros menos importantes para poder encontrar el SW que aporte lo que el cliente busca, son solamente valores de entrada antes de ejecutar el servicio y obtener de esta manera el beneficio, producto o informacin que el cliente espera en realidad, es decir, las salidas.

El proceso de ordenacin se inicia con la comparacin entre la pareja recin encontrada y la de la cabeza de la lista. Si el resultado es false, querr decir que el peso no es mejor, por lo que no se habr encontrado una mejor solucin, y por tanto deber compararse con el resto de la lista e insertarse en el lugar adecuado, mas sin embargo el registro de esta nueva pareja servir para realizar un sistema tolerante a fallos, ya que en el caso de un fallo en el uso del servicio obtenido como mejor solucin, se podr recurrir al uso de informacin provista por el elemento siguiente de la lista.

La siguiente figura muestra el pseudocdigo para el mtodo ordenar.

198

Fig. 86. Mtodo para ordenar los servicios segn el peso obtenido del emparejamiento

El proceso de emparejamiento inicia luego de llevarse a cabo la composicin de servicios, recibe como entrada un vector con la descripcin de los servicios a emparejar, el cual va recorriendo y formando parejas entre las descripciones contenidas y las extradas del repositorio de ontologas OWL-S. Para la descripcin extrada se consulta los valores de los parmetros a utilizar en el emparejamiento, lo primero que se compara es la categora, si la descripcin extrada (servicio ofertado por un proveedor) posee la misma categora que la descripcin del vector (peticin del cliente), se sigue el proceso, de lo contrario, se procede a emparejar con otra descripcin la peticin del cliente. Luego de este filtrado, se calcula el peso para insertar el servicio en una lista ordenada, al final se selecciona el servicio que este en la primera posicin de la lista (el ms optimo).

199

Fig. 87. Diagrama de flujo para algoritmo de emparejamiento

Para calcular el peso de una pareja de servicios, lo primero que se hace es obtener el grado de emparejamiento correspondiente a las salidas, si el peso obtenido es mayor que cero se procede a calcular el grado de emparejamiento correspondiente a las entradas y el peso de los parmetros no funcionales.

200

Fig. 88. Diagrama de flujo para el clculo de los pesos

4.7

Ejecucin

201

CAPITULO V 5 CASOS DE PRUEBA

202

CAPITULO VI 6 VIABILIDAD

Para determinar la viabilidad de incorporar servicios web semnticos en la automatizacin de procesos de negocio es necesario hacer una comparacin entre el procedimiento utilizado actualmente para componer procesos de negocio y los resultados obtenidos del prototipo desarrollado.

Este captulo muestra el procedimiento de las dos soluciones para un proceso de negocio especfico, y al final compara los resultados obtenidos, ventajas y desventajas, sacando una conclusin de viabilidad.

6.1

Diseo del proceso de negocio

El proceso de negocio a utilizar como caso de prueba, consta de cinco aplicaciones web y siete servicios web: Ventas Obtener datos cliente Almacn Comprobar Stock Peticin Contabilidad Facturar Distribucin Entregar Pedido Pago Online Comprobar crdito cliente Pago

203

Fig. 89. Proceso de negocio

Las aplicaciones web representan las reas que conforman la empresa, y los servicios web las tareas que llevan a cabo dichas reas, a continuacin se explica con detalle cada aplicacin web.

Ventas: Esta rea se encarga de recibir las peticiones de los clientes, se comunica con Almacn para comprobar el stock y hacer la peticin, y con Pago Online para comprobar el crdito de un cliente. Almacn: Esta rea se encarga de hacer la comprobacin del stock del producto solicitado, y de realizar la peticin de dicho producto, siempre y cuando haya stock disponible y el cliente tenga crdito suficiente.

204

 Contabilidad: Esta rea realiza la facturacin del producto a comprar, y se comunica con Pago Online para efectuar el pago. Distribucin: Esta rea genera una orden de entrega del producto y la registra en su base de datos. Pago Online: esta rea se encarga de consultar el crdito de un cliente y efectuar el pago para que la compra se formalic.

Fig. 90. Diagrama de flujo Proceso de Negocio

205

6.2

Desarrollo de los servicios web

Los pasos para crear un servicio web se encuentran en el capitulo cuatro numeral 4.3.1. Creacin de un servicio web. A continuacin se especifican los servicios web para el proceso de negocio venta de libros.

Obtener datos cliente

Este servicio web recibe el ISBN del libro a comprar, las unidades y el cdigo del cliente, devuelve los datos del cliente previamente consultados en la base de datos Libros, tabla persona.

Fig. 91. Tabla Persona de la base de datos Libros

Comprobar Stock

Este servicio web recibe el ISBN del libro a comprar y las unidades, y retorna el precio del libro si hay stock suficiente, consultando la base de datos Libros, tabla libro.

206

Fig. 92. Tabla libro de la base de datos Libros

Peticin

Este servicio web recibe el ISBN del libro a comprar y las unidades, y retorna true si se hizo efectiva la peticin, actualizando el campo cantidad disponible asociado al libro solicitado.

Facturar

Este servicio web recibe el cdigo del cliente, el ISBN del libro, precio y unidades a comprar, y retorna el cdigo de la factura generada y almacenada en la tabla factura.

Fig. 93. Tabla factura de la base de datos libros

Entregar Pedido

Este servicio web recibe el cdigo de la factura y la direccin de entrega, y retorna los das de entrega de la peticin, la cual es registrada en la tabla pedido.

207

Fig. 94. Tabla pedido de la base de datos libros

Comprobar crdito cliente

Este servicio web recibe la cedula del cliente, nmero de tarjeta de crdito, contrasea de la cuenta, precio del libro y unidades. Y retorna true si el saldo es suficiente o false en caso contrario, consultando la base de datos saldo.

Fig. 95. Fig. 96. Tabla saldo de la base de datos libros

Pago

Este servicio web recibe la cedula del cliente y el total de la factura, y retorna true si se hizo efectivo el pago, actualizando el saldo del cliente, o false en caso contrario.

208

6.3

Desarrollo del proceso de negocio con BPEL

Al presente existen varios estndares para modelar procesos de negocio, los ms destacados son BPMN y BPEL. Para desarrollar el caso de prueba explicado anteriormente se instalo el plugin OpenESB 2.2 13 en NetBeans. OpenESB es un proyecto open source que implementa un motor Enterprise Service Bus (ESB) basado en la especificacin Java Business Integration (JBI), el cual permite desarrollar aplicaciones de tipo SOA y ponerlas en ejecucin. Luego de instalar OpenESB, al crear un nuevo proyecto en el IDE NetBeans, se puede observar que se dispone de la categora SOA: Los tipos de proyectos que se pueden disear e implementar son:

Composite Application. Sirve para aadir otros proyectos SOA y servicios web. Cada proyecto incluido se denomina componente o mdulo, y son desplegados juntos en el contenedor JBI. Su interaccin en runtime implementar una funcionalidad de negocio de SOA.

BPEL Module. Sirve para modelar grficamente procesos de negocio que involucran varios servicios web u otros recursos, su finalidad es la orquestacin de servicios para realizar composicin de estos.

XSLT Module. Permite realizar transformacin de los mensajes XML que se enrutan a travs del Bus a otros tipos.
13

https://open-esb.dev.java.net/Downloads.html

209

 Data Mashup Module. Permite

combinar varias fuentes de datos y

presentarlo al servicio consumidor en un formato normalizado, como si fuese un nico recurso.

Intelligent Event Processing Module. Permite capturar, combinar, agregar, filtrar, almacenar, etc. caractersticas de Arquitecturas

Orientadas a Eventos segn nuestros intereses de negocio.

6.3.1 Crear un modulo BPEL

Clic en Archivo Proyecto Nuevo SOA BPEL Module Siguiente

Colocar un nombre al proyecto (en este caso ModuloVenta) Terminar.

Fig. 97. Crear un Modulo BPEL

210

 Expandir el nodo ModuloVenta, se crearan ocho carpetas para almacenar en ellas los descriptores (WSDL), del proceso de negocio en s, y de los siete servicios web necesarios para crear el proceso de negocio.

Clic derecho sobre Process Files Nuevo Otro Otro Carpeta Siguiente

Fig. 98. Crear Nueva Carpeta

Colocarle un nombre a la carpeta (en este caso DescriptorBPEL) Clic en Terminar. De igual manera se crean las carpetas ServicioPedido, ServicioStock, ServicioFactura, ServicioCliente. ServicioEntrega, ServicioCredito, ServicoPago,

211

Fig. 99. Carpetas

6.3.2 Generar descriptor del proceso BPEL

Un proceso BPEL se expone al resto como si se tratara de un servicio web, por ello debe tener su propio descriptor WSDL. Clic derecho sobre DescriptorBPEL Nuevo WSDL Document

Se

le

asigna

el

nombre

al

archivo

WSDL

(en

este

caso

VentaLibrosWSDL).

Clic en Siguiente Se llenan los campos, con las variables de entrada y de salida que tendr el proceso de negocio.

Clic en Siguiente.

Clic en Terminar.

212

Fig. 100. Definicin de la operacin del servicio y sus argumentos

6.3.3 Importar WSDL de los servicios web involucrados Las aplicaciones web creadas deben estar desplegadas sobre el servidor GlassFish previamente arrancado.

Se puede acceder a los WSDL de los servicios web en las URL: http://localhost:8081/Ventas/Obtener_datos_clienteService?WSDL

213

http://localhost:8081/Pago_Online/Comprobar_credito_clienteService?WSDL http://localhost:8081/Pago_Online/PagoService?WSDL http://localhost:8081/Almacen/Comprobar_stockService?WSDL http://localhost:8081/Almacen/PeticionService?WSDL http://localhost:8081/Contabilidad/FacturarService?WSDL http://localhost:8081/Distribucion/Entregar_pedidoService?WSDL

Todo proceso BPEL necesitara los contratos WSDL de los servicios que utilice, para poder invocarlos. Para importar los WSDL se hace lo siguiente: Clic derecho sobre la carpeta ServicioCliente Nuevo Otro XML External WSDL Document(s) Siguiente Se

introduce

la

URL

del

descriptor

del

servicio

web

Obtener_datos_cliente

Fig. 101. Importar WSDL del Servicio Web Obtener_datos_cliente

214

Se repiten los pasos con las restantes carpetas y sus respectivos descriptores. El proyecto quedara:

Fig. 102. Importar los WSDL de los Servicios Web a utilizar

6.3.4 Disear el proceso BPEL

Clic derecho en ModuloVenta Nuevo BPEL Process

Asignar nombre ( ProcesoVenta en este caso) Terminar Doble clic sobre ProcesoVenta.bpel Ubicarse en el Tab Design Arrastar el descriptor VentaLibrosWSDL.wsdl a la izquierda del diagrama

215

Fig. 103. Insertar la interfaz WSDL del proceso BPEL

Pulsar sobre la representacin del WSDL introducido y en el icono Edit para acceder a las propiedades, cambiar el nombre por defecto (PartnerLink1) a VentaLibros -> Aceptar

Fig. 104. Crear enlace al descriptor BPEL

216

 De igual manera se introducen los descriptores de los servicios web utilizados, pero a la derecha del diagrama, como proveedores de servicios. Se le cambian los nombres asignados por defecto (PartnerLinks) por nombres distintivos, para facilitar su identificacin dentro del proceso de negocio, como se hizo con el enlace al descriptor BPEL. El proceso quedara de la forma:

Fig. 105. BPEL con los servicios proveedores (PartnerLinks)

Utilizar las paletas del editor BPEL de NetBeans

217

Fig. 106. Paleta del editor de BPEL

Esta paleta contiene actividades para el manejo de servicios web, actividades bsicas y actividades estructuradas:

Web Service

Invoke: Se utiliza para invocar una operacin dentro de un servicio web.

Receive: Usada para describir el participante que contiene la entrada del proceso, el servicio web que se encarga de la interfaz del proceso.

Reply: Usada para devolver el mensaje de respuesta al servicio que representa al proceso.

218

Parther Link: Agrega un participante del proceso (por ejemplo un servicio web proveedor). Basic Activities

Assign: copia datos entre variables; asigna datos a una variable desde otra.

Empty: No hace nada. Wait: Permite la espera durante un tiempo del proceso.

Throw: Permite indicar que ha ocurrido un error. ReThrow: Vuelve a indicar que ha ocurrido un error. Exit: Termina la ejecucin de una instancia del proceso de negocio.

Compensate: Invoca el controlador compensador de un cierto mbito. Structured Activities

Sequence: Se utiliza para crear una secuencia la cual puede contener una o ms actividades.

If: Se utiliza para implementar un comportamiento condicional. While: Se utiliza para llevar a cabo una ejecucin repetitiva de una o varias actividades mientras se cumpla una condicin.

RepeatUntil: Ejecuta una o varias actividades mientras se cumpla la condicin.

219

Flow: Permite la ejecucin paralela y termina cuando todas las actividades contenidas se acaben.

ForEach: Ejecuta n+1 veces las actividades que incluye. Pick: Espera por un mensaje o un tiempo de evento.

Scope: Contenedor de un conjunto de actividades, variables y controladores.

El flujo de actividades para el proceso de negocio propuesto es:

220

Fig. 107. Proceso de negocio con BPEL

6.3.5 Desplegar el modulo BPEL en el ESB

En OpenESB, todo modulo de la categora SOA se despliega en el contenedor de JBI de una Composite Application. Para esto se debe crear en NetBeans un proyecto de este tipo. Clic en Archivo Proyecto Nuevo SOA Composite Application Asignarle

un

nombre

la

aplicacin

(en

este

caso

AplicacionLibroOnline). Clic en Terminar.

Se deben aadir los mdulos SOA que componen la aplicacin, para esto se extiende el nodo de la aplicacin creada. Clic derecho sobre JBI Modules Seleccionar Add JBI Module

Fig. 108. Aadir modulo SOA

Seleccionar el proyecto ModuloVenta Clic sobre Add Project JAR Files

221

Compilar los proyectos introducidos seleccionando Clean and Build, haciendo clic derecho sobre el nombre del proyecto ApicacionLibroOnline. El resultado se puede observar en el editor CASA (Composite Application Service Assembly)

Fig. 109. Editor de OpenESB para composicin de aplicaciones (CASA)

Guardar y desplegar el proyecto

222

El proceso BPEL ser un servicio web publicado en una URL.

Para probar el proceso de negocio se puede hacer un test unitario con jUnit desde el proyecto AplicacionLibroOnline, carpeta Test. Clic derecho en la carpeta Test New Test Case Siguiente Seleccionar ModuloVenta DescriptorBPEL VentaLibrosWSDL.wsdl Siguiente Seleccionar VentaLibrosWSDLOperation Clic en Terminar

Se generara un caso de prueba, al cual se le deben ingresar los datos de entrada.

Fig. 110. Test Case Input

Clic derecho en el Test TestCase1(nombre por defecto del caso de prueba) creado anteriormente Run.

Se puede observar que se genero un mensaje con la respuesta del proceso de negocio.

223

Fig. 111. Mensaje de respuesta para el proceso de negocio

6.4

Desarrollo del proceso de negocio con el prototipo desarrollado

Falta

224

CAPITULO VII 7 CONCLUSIONES

225

OBSERVACIONES Y RECOMENDACIONES.

226

REFERENCIAS

9.1

Referencias Web

[1] Nickolas Kavantzas, David Burdett, Gregory Ritzinger, Tony Fletcher, Yves Lafon, Charlton Barreto. Web Services Choreography Description Language Versin 1.0. W3C Candidate Recommendation. [En lnea] 09 de Noviembre de 2005. http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/. [2] David Martin, Mark B., Jerry H., Ora Lassila, Dres M., Sheila M., Srini N., Massimo P., Bijan P., Terry P., Evre S., Naveen S. y Katia Sycara. OWL-S: Semantic Markup for Web Services. W3C Member Submission. [En lnea] 22 de Noviembre de 2004. http://www.w3.org/Submission/OWL-S/. [3] Jos de Brujin, Christoph B., Jhon D., Dieter F., Martin H., Uwe Keller., Michael K., Birgitta K., Jacek K., Ruben L., Holger L., Eyal Oren., Axel P., Dumitru R., James S. y Michael S. Service Modeling Ontology (WSMO). W3C Member Submission. [En lnea] 03 de Junio de 2005.

http://www.w3.org/Submission/WSMO/. [4] Steve B., Abraham B., Harold B., Benjamn G., Michael G., Richard H., Michael K., David M., Sheila M., Deborah M., Jianwen Su y Said Tabet. SWSF Application Scenarios. W3C Member Submission. [En lnea] 09 de Septiembre de 2005. http://www.w3.org/Submission/SWSF-Applications/. [5] Rama A., Joel F., John M., Meenakshi N., Marc-Thomas S., Amit S. y Kunal Verma. Web Service Semantics WSDL-S. W3C Member Submission. [En lnea] 07 de Noviembre de 2005. http://www.w3.org/Submission/WSDL-S/. [6] Joel Farrell, Holger Lausen. Semantic Annotations for WSDL and XML Schema. W3C Recommendation. [En lnea] 28 de Agosto de 2007. http://www.w3.org/TR/sawsdl/. [7] UNSPSC. The United Nations Standard Products and Services Code. [En lnea] 2010. http://www.unspsc.org/Defaults.asp.

227

[8] NAICS Association. North American Industry Classification System. [En lnea] 2007. http://www.naics.com/. [9] Proceso de Negocio. [En lnea] Septiembre de 2010.

http://es.wikipedia.org/wiki/Proceso_de_negocio. [10] Reingeniera de Procesos. [En lnea] 2010.

http://es.wikipedia.org/wiki/Reingenier%C3%ADa_de_Procesos. [11] Flujo de Trabajo. [En lnea] 2010.

http://es.wikipedia.org/wiki/Flujo_de_trabajo. [12] Sistema de Gestion de Flujo de Trabajo. [En lnea] 2010.

http://www.giro.infor.uva.es/oldsite/docproy/wfs/gestionflujo.htm. [13] Workflow. [En lnea] 2010.

http://en.wikipedia.org/wiki/Workflow#Workflow_Management_System. [14] Business Process Management Notation. [En lnea] 2010.

http://es.wikipedia.org/wiki/Business_Process_Management_Notation. [15] WS-BPEL. [En lnea] 2010. http://es.wikipedia.org/wiki/WS-BPEL. [16] Martin, David. Lista de Servicios Web. [En lnea] Agosto de 2003. http://lists.w3.org/Archives/Public/www-ws/2003Aug/0029.html. [17] Puebla, Ivn Garca. Tutorial de BPEL con OpenESB. [En lnea] 2009. http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=introduccionBPEL-openesb.

228

9.2

Referencias Bibliogrficas

[18] Barrientos, Manuel Snchez. Introduccin a BPMN. [19] Cesar de la Torre, Roberto Gonzlez. Arquitectura SOA con tecnologa Microsoft. Espaa : Krasis Press, 2008. [20] Diaz, Octavio Martin. Emparejamiento automatico de Servicios Web usando programacion con restricciones. Universidad de Sevilla : s.n., 2007. [21] Algoritmo de emparejamiento de perfiles en Servicios Web Semanticos. Jos Javier Samper, Eduardo Carrillo, Juan Jos Martnez. UNAB Colombia: Revista Colombiana de Computacin, 2005. [22] Juan Carlos Daz, Jaime Abuin, Carlos Magadan y dems. Business Process Management: El negocio en el centro de los sistemas. Madrid : s.n., 2006. [23] Lei Li, Horrocks Ian. A software Framework For Matchmaking Based on Semantic Web Technology. Twelfth International World Wide Conference : ACM, 2003. [24] Len, Keilyn Rodrguez Perojo y Rodrigo Ronda. Web Semntica: un nuevo enfoque para la organizacin y recuperacin de informacin en la Web. 2005. [25] Maigre, Riina. Web Services Composition with WS-BPEL and OWL-S. 2006. [26] Peis Redondo, Eduardo, Hassan Montero, Yusef. Ontologas, metadatos y agentes: recuperacin semntica de la informacin. Campus de la Cartuja, Universidad de Granada Espaa : s.n., 2003. [27] Prez, Juan Ramn Prez. Servicios Web: Orquestacin y Coreografas. Universidad de Oviedo : s.n., 2007.

229

[28] Prez, Laura Grande. Revisin de los estndares ebXML, RossetaNet y BizTalk para aplicaciones de comercio electrnico. Universidad de Salamanca, Salamanca, Espaa : s.n., 2005. [29] Sols, Santiago Mrquez. La web semntica. 2007. [30] Anbazhagan Mani, Arun Nagarajan. Entendiendo la calidad de servicio para los servicios Web . Espaa : s.n., 2002.

230

10 GLOSARIO

231

Presupuesto econmico, gastos personales y fuentes de financiacin.

232

11 Presupuesto econmico.

Presupuesto de Medios Bsicos.

Descripcin de equipos Nombre Cant. Costo Costo Proveedor Observacion es

unitario ($) Total ($) Ordenador clon, 1 Intel Quad GHz, Core de 2 2.38 DDR2 2.000.000 2.000.000 Autor T.G.

1GB, HDD 240 GB, entre otros accesorios. TOTAL 2.000.000

Descripcin de servicios Nombre Cant. Costo Costo Proveedor Observacion es Telefnica Telecom TOTAL 95.000 Internet Domiciliario.

unitario ($) Total ($) Internet 1 95.000 95.000

233

Presupuesto para Gastos Personales.

Descripcin de gastos de sostenimiento (Mensual) Nombre Cant. Costo Costo Proveedor Observacion es

unitario ($) Total ($) Alimentacin Hospedaje Otros TOTAL 1 1 X 170.000 120.000 100.000 170.000 120.000 100.00 390.000

Fuentes de financiacin. Todos los gastos son cubiertos por Pedro Elas Caldern y Mara Doris Hernndez, mis padres.

234