estado del arte - peruti.files.wordpress.com · estado del arte proyecto batuta - generador de...

Estado Del Arte Proyecto Batuta - Generador de Aplicaciones Orquestadoras

Facultad de Ingeniería - Universidad de la República

Pablo Alvez, Patricia Foti, Marco Scalone

Junio 2006.

Índice 1 Introducción ....................................................................................................................................4

1.1 Propósito ...................................................................................................................................4

1.2 Alcance........................................................................................................................................4

1.3 Definiciones, acrónimos y abreviaciones ...........................................................4

1.4 Organización del documento ..........................................................................................4

2 SOA: Arquitectura Orientada a Servicios ....................................................................5

2.1 Introducción............................................................................................................................5

2.2 Antecedentes............................................................................................................................5

2.3 Ventajas de una arquitectura orientada a servicios .................................5

2.4 Diseño basado en SOA.........................................................................................................6

2.5 Elementos de SOA ..................................................................................................................6

3 Web services ....................................................................................................................................9

3.1 Introducción............................................................................................................................9

3.2 Tecnologías asociadas ....................................................................................................10

3.2.1 WSDL ....................................................................................................................................10

3.2.2 SOAP ....................................................................................................................................10

3.2.3 UDDI ....................................................................................................................................10

4 Web Services Semánticos ........................................................................................................12

4.1 Introducción..........................................................................................................................12

4.2 OWL ...............................................................................................................................................13

4.2.1 Lenguajes de consultas .........................................................................................14

4.3 OWL-S ..........................................................................................................................................14

4.3.1 Clase Service Profile............................................................................................16

4.3.2 Clase ServiceModel...................................................................................................17

4.3.3 Clase ServiceGrounding .........................................................................................18

4.4 WSMO.............................................................................................................................................19

5 Modelado de procesos ...............................................................................................................21

5.1 Introducción..........................................................................................................................21

5.2 ¿Qué es un Proceso de Negocio? ...............................................................................21

5.3 ¿ Qué es un workflow ? ..................................................................................................22

5.4 Workflow Managment System...........................................................................................22

5.5 Modelo de referencia de Workflow ..........................................................................23

5.6 Especificación de un Workflow .................................................................................25

5.6.1 Patrones de Workflows............................................................................................26

5.7 Business Process Management ......................................................................................26


Versión 1.2.1 Pág. 3

5.8 Composición de Servicios .............................................................................................27

5.9 Estándares ..............................................................................................................................28

5.9.1 Organizaciones ............................................................................................................28

5.9.2 Estándares para la notación de procesos.................................................28

5.9.3 Estándares para la ejecución de procesos ..............................................30

6 MDA: Arquitectura Dirigida por Modelos.....................................................................32

6.1 Introducción..........................................................................................................................32

6.2 BPDM.............................................................................................................................................32

7 Herramientas ..................................................................................................................................33

7.1 Herramientas de Gestión de Procesos de Negocio.........................................33

7.1.1 Emerging Technologies Toolkit ........................................................................33

7.1.2 WebSphere ........................................................................................................................34

7.1.3 Microsoft BizTalk Server 2004 ........................................................................34

7.1.4 JBoss jBPM......................................................................................................................35

7.1.5 Bea WebLogic Platform ISV Edition ...............................................................35

7.1.6 Process Modeler for Microsoft Visio™ ........................................................35

7.2 Herramientas para desarrollo....................................................................................35

7.2.1 MatchMaker......................................................................................................................36

7.2.2 Jena ....................................................................................................................................36

7.2.3 Protègè .............................................................................................................................36

7.2.4 Racer..................................................................................................................................36

7.2.5 OWL-S API ........................................................................................................................36

7.2.6 ActiveBpel......................................................................................................................37

8 Referencias .....................................................................................................................................38



1 Introducción

1.1 Propósito El propósito de este documento es relevar y sintetizar información sobre las disciplinas, los conceptos y las tecnologías más importantes para el desarrollo del proyecto Batuta.

1.2 Alcance El documento recoge los principales resultados obtenidos de la investigación del estado actual de las áreas de interés para el proyecto en desarrollo.

1.3 Definiciones, acrónimos y abreviaciones Ver Glosario [1].

1.4 Organización del documento El documento se organiza en un conjunto de secciones cada una de las cuales presenta el estudio de un concepto, herramienta o tecnología de particular interés para el desarrollo del proyecto.

Comienza con una introducción a las nociones básicas de la Arquitectura Orientada a Servicios (SOA) y los beneficios que este tipo de arquitectura provee en el contexto del proyecto. Siguiendo esta línea se presentan las tecnologías en el área de los web services y web services semánticos. En la sección 5 se brinda una introducción al Modelado de Procesos, presentando las características inherentes y su evolución a través del tiempo, desde las organizaciones con mayor auge en este sentido. Por último, en la sección 7 se hace una recorrida por las herramientas más reconocidas en la industria que permiten realizar la gestión de procesos de negocio.



2 SOA: Arquitectura Orientada a Servicios

2.1 Introducción La Arquitectura Orientada a Servicios (Service-Oriented Architecture, SOA) es un concepto de arquitectura de software que define la utilización de servicios como construcciones básicas para el desarrollo de aplicaciones.

Es una arquitectura de una aplicación donde las funcionalidades se definen como servicios independientes, con interfaces invocables bien definidas, que pueden ser llamadas en secuencias dadas para formar procesos de negocios.

2.2 Antecedentes En las últimas décadas los departamentos de IT de las empresas han construido una infraestructura que actualmente soporta en gran medida la operación de sus empresas y sus clientes. El resultado de este proceso, ha sido la creación y mantenimiento de un número considerable de aplicaciones al interior de las empresas, cada una responsable de sus propias tareas [2].

Los negocios exigen crear aplicaciones cada vez más complejas, con menos tiempo y presupuesto que antes. En muchos casos crear estas aplicaciones requiere de funcionalidades ya antes implementadas como parte de otros sistemas. En este punto los arquitectos de software se pueden enfrentar a dos opciones:

• Tratar de reutilizar la funcionalidad ya implementada en otros sistemas. Una labor difícil de realizar, debido a que estas no fueron diseñadas para integrarse, encontrándose implementadas sobre plataformas y/o tecnologías incompatibles entre ellas.

• Re-implementar la funcionalidad requerida ("reinventar la rueda"). Aunque implica mas tiempo de desarrollo, es en la mayoría de los casos la más fácil y segura.

Aunque no sea la más acertada a largo plazo, la segunda opción es la más escogida. Esto trae como resultado:

• Funcionalidad replicada en varias aplicaciones.

• Dificultad de migración de los sistemas internos, al haber múltiples conexiones desde sistemas que dependen de estos para su funcionamiento.

• Al no haber una estrategia de integración de aplicaciones, se generan múltiples puntos de falla, que pueden detener la operación de todos los sistemas muy fácilmente.

• Es un modelo generalmente poco escalable.

• El inconveniente final es una pobre respuesta al cambio. Las aplicaciones siguen siendo concebidas desde un principio como islas independientes.

2.3 Ventajas de una arquitectura orientada a servicios Una estrategia de aplicaciones empresariales debe facilitar su integración.

Exponer procesos de negocio como servicios es la clave a la flexibilidad de la arquitectura. Esto permite que otras piezas de funcionalidad (incluso también implementadas como servicios) hagan uso de otros servicios de manera natural, sin importar su ubicación física. Así un sistema evoluciona con la adición 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 que tecnologías serán 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 políticas aplicables.

2.4 Diseño basado en SOA La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implantación. Para que un proyecto SOA tenga éxito, los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware1 para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura [3].

Por otro lado, la implementación ideal de un servicio exige resolver algunos inconvenientes técnicos inherentes a su modelo:

• Los tiempos de llamado no son despreciables, gracias a la comunicación de la red, tamaño de los mensajes, etc. Esto necesariamente implica la utilización de mensajería confiable.

• La respuesta del servicio es afectada directamente por aspectos externos como problemas en la red, configuración, etc. Estos deben ser tenidos en cuenta en el diseño, desarrollándose los mecanismos de contingencia que eviten la parálisis 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 múltiples servicios para implementar un sistema, es muy fácil que la comunicación 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 fácilmente el sistema se vuelve inmanejable. De esta forma, un sistema grande puede terminar con múltiples dependencias. Detectar un problema de rendimiento o funcionalidad se puede volver muy complicado.

Según lo expresado, si no se cuenta con una estrategia adecuada, se puede llegar a una implementación donde exista una explosión de dependencias entre los diferentes servicios.

Una solución a este problema es extraer los aspectos de procedimiento de varios servicios dentro de uno dedicado, llamado servicio de negocio. Así, un servicio de negocio centraliza la definición del proceso, disminuyendo las dependencias entre servicios y las aplicaciones clientes, ayudando a su vez a facilitar la administración del sistema.

2.5 Elementos de SOA Esta arquitectura presenta una forma de construir sistemas distribuidos que entreguen a la aplicación funcionalidad como servicios para aplicaciones de uso final u otros servicios.

En la figura 1 se muestra el stack de la arquitectura y los elementos que podrían observarse en una arquitectura orientada a servicios.

1 El middleware es un módulo intermedio que actúa como conductor entre sistemas permitiendo a cualquier usuario de sistemas comunicarse con varias fuentes de información u otros sistemas que se encuentran conectadas por una red.



Figura 1 Elementos de una arquitectura orientada a servicios (SOA)

Como se puede observar, se diferencian dos zonas en el stack, una que abarca los aspectos funcionales de la arquitectura y otra que abarca aspectos de calidad de servicio. A continuación se describen los elementos brevemente:

• Funciones

o Transporte: es el mecanismo utilizado para llevar las demandas de servicio desde un consumidor de servicio hacia un proveedor de servicio, y las respuestas desde el proveedor hacia el consumidor.

o Protocolo de comunicación de servicios: es un mecanismo acordado a través del cual un proveedor de servicios y un consumidor de servicios comunican qué está siendo solicitado y qué está siendo respondido.

o Descripción de servicio: es un esquema acordado para describir qué es el servicio, cómo debe invocarse, y qué datos requiere el servicio para invocarse con éxito.

o Servicios: describe un servicio actual que está disponible para utilizar.

o Procesos de Negocio: es una colección de servicios, invocados en una secuencia particular con un conjunto particular de reglas, para satisfacer un requerimiento de negocio.

o 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 para descubrir o hallar servicios disponibles.

• Calidad de Servicio

o Política: es un conjunto de condiciones o reglas bajo las cuales un proveedor de servicio hace el servicio disponible para consumidores.

o Seguridad: es un conjunto de reglas que pueden aplicarse para la identificación, autorización y control de acceso a consumidores de servicios.

o Transacciones: es el conjunto de atributos que podrían aplicarse a un grupo de servicios para entregar un resultado consistente.

o Administración: es el conjunto de atributos que podrían aplicarse para manejar los servicios proporcionados o consumidos.

En [4] se puede encontrar una descripción más detallada.

Las colaboraciones en SOA siguen el paradigma find, bind and invoke, donde un consumidor de servicios realiza la localización dinámica de un servicio consultando el registro de

Funciones

Re

gis

tro

de S

erv

icio

Calidad de Servicio

Segu

rida

d

Tra

nsacc

ión

Adm

inis

trac

ión

Polí

tica

Procesos de Negocio

Descripción de Servicio

Servicio

Protocolo de Comunicación

Transporte



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 dirección del servicio proveedor.

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

Figura 2 Colaboraciones en SOA

Cada entidad puede tomar el rol de consumidor, proveedor y/o registro:

• Un consumidor de servicios es una aplicación, un módulo de software u otro servicio que requiere un servicio, y ejecuta el servicio de acuerdo a un contrato de interfaz.

• Un proveedor de servicios es una entidad direccionable a través 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 de servicios 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 descripción 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 descripción de un servicio por parte de un consumidor, éste lo invoca de acuerdo a la información en la descripción del servicio.

Finalmente, los artefactos en una arquitectura orientada a servicios son:

• Servicio. Un servicio que está disponible para el uso a través de una interfaz publicada y que permite ser invocado por un consumidor de servicios.

• Descripción de servicio. Una descripción de servicio especifica la forma en que un consumidor de servicio interactuará con el proveedor de servicio, especificando el formato de consultas y respuestas desde el servicio. Esta descripción también puede especificar el conjunto de pre-condiciones, pos-condiciones y/o niveles de calidad de servicio (QoS).

En [4] se puede encontrar una descripción más detallada.

Consumidorde

Servicios

Proveedorde

Servicios

Registrode

Servicios

Descripciónde Servicio

Servicio

Descripciónde Servicio

PublicaDescubre

Liga e Invoca



3 Web services

3.1 Introducción Al contrario de las arquitecturas orientadas a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables [3].

Un servicio es la evolución 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 diseñados e implementados necesariamente como parte de una aplicación end-to-end.

• Son controlados y administrados de manera independiente.

• Expone su funcionalidad a través de protocolos abiertos e independientes de plataforma. Incluso arriesgando el rendimiento y consumo de recursos.

• Son transparentes de su localización en la red, de esta manera garantizan escalabilidad y tolerancia a fallos.

Tienen sus propias políticas de escalabilidad, seguridad, tolerancia a fallos, manejo de excepciones, configuración, etc.

Generalmente, los servicios incluyen tanto lógica de negocios como manejo de estado (datos), relevantes a la solución del problema para el cual fueron diseñados. La manipulación del estado es gobernada por las reglas de negocio. Un servicio funciona como una aplicación independiente, teniendo sus propias reglas de negocio, datos, procedimientos de administración y operación. Expone toda su funcionalidad utilizando una interfaz basada en mensajes. La comunicación hacia y desde el servicio, es realizada utilizando mensajes y no llamadas a métodos. Estos mensajes deben contener o referenciar toda la información necesaria para ser entendidos.

Los web services comunican aplicaciones, permiten que las aplicaciones compartan información y que además invoquen funciones de otras aplicaciones independientemente de cómo se hayan creado las aplicaciones, cuál sea el sistema operativo o la plataforma en que se ejecutan y cuáles los dispositivos utilizados para obtener acceso a ellas. La comunicación se caracteriza por el intercambio de mensajes XML y por ser independientes del protocolo de comunicación. Para lograr esta independencia, el mensaje XML se envuelve de manera apropiada para cada protocolo gracias a la creación del protocolo de transporte SOAP (Simple Object Access Protocol).

El lenguaje WSDL (Web Services Description Languaje), expresado en XML, describe cómo acceder al servicio, de qué funciones dispone, qué argumentos necesita y qué devuelve cada uno.

La otra tecnología fundamental implicada es UDDI (Universal Description, Discovery, and Integration). UDDI es un directorio de servicios web donde se puedan publicar los servicios ofrecidos, dar características del tipo de servicio, y realizar búsquedas.

En resúmen, SOAP define un protocolo XML para la interoperabilidad básica entre servicios, WSDL introduce un lenguaje común para describir servicios y UDDI provee la infraestructura requerida para publicar y descubrir servicios programáticamente. Juntas, estas especificaciones permiten a las aplicaciones interactuar siguiendo un modelo débilmente acoplado e independiente de la plataforma subyacente.



3.2 Tecnologías asociadas

3.2.1 WSDL

El lenguaje de descripción de servicios web, Web Services Definition Language, (WSDL) nació en septiembre de 2000 de la mano de Microsoft, IBM y Ariba. Se basa en los lenguajes de definición NASSL44 (Network Accesible Services Specification), de IBM, y SCL45 (SOAP Contract Language) de Microsoft. En Marzo de 2001, estas compañías, con el apoyo de algunas otras, enviaron la versión WSDL 1.146 al W3C, donde fue publicado como una nota por lo que formalmente no es un estándar del W3C.

La especificación de WSDL (1.1) no ha cambiado en absoluto desde su aparición, a pesar de haber un grupo de trabajo del W3C dedicado a WSDL que tiene borradores con diversas mejoras [5].

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

• Qué funciones que se pueden invocar

• Qué tipos de datos utilizan esas funciones

• Qué protocolo de transporte se utilizará para el envío y recepción de los mensajes (típicamente, pero no únicamente, mensajes SOAP).

• Cómo acceder a los servicios. En esencia, mediante qué URL se utilizan los servicios.

3.2.2 SOAP

SOAP (Simple Object Access Protocol), es un protocolo simple para el intercambio de información estructurada en un entorno distribuido y descentralizado. Utiliza XML para definir un framework extensible de mensajería proveyendo un formato de mensaje que puede ser intercambiado sobre una variedad de protocolos subyacentes. El framework fue diseñado para ser independiente de cualquier modelo de programación o cualquier semántica específica de alguna implementación [6].

3.2.3 UDDI

UDDI, “Universal Description, Discovery and Integration”, es un elemento central del grupo de estándares involucrados en la tecnología web services. Es el mediador a través del cual se conocen los posibles clientes con los proveedores de los servicios. Define un método estándar para publicar y descubrir servicios en el contexto SOA.

La especificación de UDDI nació casi a la vez que la de WSDL, de la mano de las mismas compañías, pero no ha llegado nunca al W3C. La versión actual es la 3.0, especificación que data de agosto de 2003, siendo gestionada por OASIS. La implementación de estas especificaciones se denomina “Registro UDDI”, el cual proporciona un conjunto de servicios web de registro y consulta via SOAP.

El propósito funcional de un registro UDDI es la representación de datos y metadatos acerca de servicios web. Tanto para ser usado en una red pública como dentro de la infraestructura interna de una organización, un registro UDDI ofrece un mecanismo basado en estándares para clasificar, catalogar y manejar servicios web de forma de que puedan ser descubiertos y consumidos por otras aplicaciones.

Varios registros UDDI se pueden agrupar para formar un UBR (UDDI Business Registry) con la idea de que se apliquen las mismas políticas de autenticación, cifrado, o se balancee la carga de trabajo.



Los UDDI y los UBR pueden ser públicos o privados. Los privados permiten el registro de los servicios web sólo a sus miembros, añadiendo, por lo general, ciertas medidas de seguridad. Sin embargo, permiten la consulta de sus registros por cualquier usuario. La mayor parte de los UDDI y UBR existentes son privados.

Las empresas que implementan registros UDDI facilitan en general herramientas gráficas (vía Web o locales) para interactuar con el registro así como APIs para integrar con las aplicaciones.

3.2.3.1 Estructuras de datos en UDDI

La información almacenada en un registro UDDI es un conjunto de las denominadas “estructuras de datos UDDI”. Estas estructuras, en XML, definidas en la especificación, son las que el cliente intercambiará con el registro UDDI. Cada instancia de estas estructuras se identifica de manera única con un identificador denominado UUID (Universal Unique Identifier) [7].

Las principales estructuras (elementos XML) de alto nivel son las siguientes:

• BusinessEntity. Contiene información básica de la empresa: persona de contacto, una clasificación de la empresa conforme a alguna de las taxonomías definidas, así como una descripción en lenguaje natural de las actividades de la empresa.

• PublisherAssertion. Una empresa puede declarar su relación con otras empresas, por ejemplo, como socios o como clientes. Cada una de estas relaciones se modela como una PublisherAssertion.

• 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 técnicas (por ejemplo, URLs apuntando a manuales técnicos) y a las URL de acceso de los servicios web. Cada elemento BusinessService puede tener uno o varios elementos BindingTemplate.

• 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. También pueden aparecer aquí las categorías en las que se puede englobar el servicio (pueden ser distintas de las que podían aparecer en BusinessEntity).



4 Web Services Semánticos

4.1 Introducción Aunque los web services tradicionales permiten la comunicación entre diferentes plataformas y sistemas operativos, carecen de contenido semántico. Estos indican qué estructuras de datos se intercambian entre los clientes y los proveedores de los servicios sin especificar su significado (semántica). Teniendo en cuenta que las ontologías permiten la descripción semántica de prácticamente cualquier dominio del conocimiento, la incorporación de ontologías del dominio de los servicios a los web services da lugar a los web services Semánticos.

Dotar de semántica a los web services permite un aumento del dinamismo de los mismos, aspecto este del que siempre adolecieron. Por ejemplo, la composición dinámica de servicios, o el propio descubrimiento de los mismos, siempre han sido problemas difíciles para los web services tradicionales y han requerido de la intervención de humanos. El paradigma de los web services semánticos pretende automatizar todo lo que era semi-automático (en el sentido de requerir intervención humana) en los web services tradicionales, esencialmente el descubrimiento, composición, invocación e interoperación de web services. La muestra la evolución de los web services.

Figura 3 Evolución de los web services

Los principales componentes de la Web Semántica son los metalenguajes y estándares de representación. En la figura 4 que sigue se muestra el stack de tecnologías donde se describe la función y relación de cada uno de estos componentes de la web semántica:

Din

am

ism

o

Tiempo

Estático

Dinámico

Automático

Web inicial

(Páginas

Web actual(Aplicaciones

Web Semántica(RDF(S), OWL ...)

Servicios Web

(WSDL, SOAP, UDDI)

Servicios WebSemánticos



Figura 4 Stack de tecnologías para la web semántica

A continuación se presenta una introducción a OWL cómo lenguaje para representar ontologías y luego se muestran las dos ontologías para web services más sobresalientes: OWL-S y WSMO.

4.2 OWL Web Ontology Language (OWL) [8], desarrollado por el Web Ontology Working Group de la W3C proporciona un lenguaje para definir ontologías estructuradas que pueden ser utilizadas a través de diferentes sistemas. Las ontologías, se encargan de definir los términos utilizados para describir y representar un área de conocimiento. Las ontologías incluyen definiciones de conceptos básicos en un campo determinado y la relación entre ellos.

OWL es la evolución de DAML+OIL [9], construido sobre RDF y RDF-Schema, ampliando el vocabulario en los siguientes aspectos:

• Definición de clases mediante restricciones sobre propiedades, valor o cardinalidad.

• Definición de clases mediante operaciones booleanas sobre otras clases: intersección, unión y complemento.

• Relaciones entre clases, por ejemplo inclusión, disjunción, equivalencia

• Propiedades de las relaciones, por ejemplo inversa, simétrica, transitiva

• Cardinalidad. Por ejemplo, “únicamente una”.

• Igualdad y desigualdad de clases.

• Igualdad y desigualdad de instancias.

• Clases enumeradas

Sin embargo, esta ampliación de expresividad hace que los razonadores puedan llegar a situaciones en las que no se pueda garantizar que: el razonador encuentre todas las conclusiones que debería encontrar (completitud computacional), y que se realicen todos los cálculos en un tiempo finito (“decidibilidad” computacional). Es así que se crearon tres “niveles” de OWL:

apor ta la sintaxis superfi cia l pa ra los documentos

estructurados, pero sin dota r les de n inguna restr i cción sobre e l signi fi cado

XML

XMLSchema

es un lenguaje para de f in i r la es t ruc t ura de los doc um ent os XM L

OWL

RDFSchema

RDF

añade más vocabulario para describir propiedades y

clases: tales como relaciones entre clases, cardinalidad, igualdad, tipologías de propiedades más complejas, caracterización de propiedades (por ejemplo simetría) o

es un vocabulario para describir las propiedades y las clases de los recursos RDF, con una semántica para establecer jerarquías de generalización entre dichas

propiedades y clases

es un modelo de datos para los recursos y las relaciones que se puedan establecer entre ellos. Aporta una

semántica básica para este modelo de datos que puede representarse mediante XML



• OWL Lite. Limita, por ejemplo, las restricciones de cardinalidad que se pueden poner, permitiendo sólo valores de cardinalidad de 0 ó 1.

• OWL DL. Tiene la máxima expresividad de la que se puede garantizar completitud y decibilidad computacional. Un ejemplo de limitación de este nivel es que una clase puede ser subclase de muchas otras, pero no puede ser a la vez instancia de ninguna otra clase.

• OWL Full. Máxima expresividad, pero sin garantías computacionales. Los niveles de

OWL garantiza que los niveles más descriptivos son extensiones de los inferiores.

4.2.1 Lenguajes de consultas

La Web Semántica dispone de tecnologías de descripción de los contenidos, como RDF y OWL, pero para que la Web Semántica sea una realidad, precisa de un lenguaje de consulta estándar y de un protocolo de recuperación. Algunas organizaciones han estado trabajando en este sentido y aquí se comentarán dos de los lenguajes más destacados.

4.2.1.1 RDQL

A falta de alcanzar un acuerdo sobre un estándar comúnmente aceptado, se han consolidado de facto distintas iniciativas particulares tal como RDF Data Query Language (RDQL) [10] desarrollado por Hewlett Packard.

RDQL es un lenguaje de consulta, similar a SQL para las bases de datos, que permite expresar búsquedas complejas sobre un grafo RDF mediante una sintaxis declarativa sencilla. Por ejemplo, la cláusula SELECT define las variables que se requieren mostrar en el conjunto resultante. La cláusula WHERE define un patrón de subgrafo en términos de variables y constantes.

4.2.1.2 SPARQL

SPARQL es un acrónimo recursivo1 del inglés SPARQL Protocol and RDF Query Language. Se trata de una recomendación para crear un lenguaje de consulta dentro de la Web semántica.

Las especificaciones de SPARQL son Candidatas a Recomendación del W3C [11]. En Abril de 2006 la W3C anuncia el paso de las especificaciones de SPARQL a candidatas a recomendación. El Lenguaje de Consulta SPARQL para RDF especifica la sintaxis para la composición, concordancia y experimentación. El Protocolo SPARQL para RDF describe el acceso remoto de datos y la transmisión de consultas de los clientes a los procesadores. El Formato XML de resultados de consultas SPARQL se utiliza para los resultados de la búsqueda.

4.3 OWL-S Como se mencionó anteriormente el WSDL expone como invocar un web service, esto quiere decir, qué parámetros recibe, de qué tipo y cuales retorna, pero no dice nada acerca del significado de cada parámetro, y mucho menos el web service en sí. OWL-S [12] permite publicar de forma declarativa las propiedades y cualidades de un servicio, brindando la posibilidad de descubrir e invocar servicios de forma automática así como componerlos teniendo en cuenta su descripción semántica.

1 Un acrónimo recursivo es un acrónimo en el que la primera letra del mismo hace referencia al propio acrónimo. El ejemplo más conocido de acrónimo recursivo es GNU, que significa GNU's Not Unix (GNU no es Unix).



OWL-S es una ontología específica para describir las propiedades y capacidades de un web service. La estructura de esta ontología viene dada por la necesidad de responder a tres aspectos básicos de un servicio:

1. ¿Qué necesita el servicio del cliente que lo utiliza (humano/s o agente/s) y qué le proporcionará como respuesta el servicio? Esto se denomina el perfil del servicio.

2. ¿Qué hace el servicio? Esto es el modelo del servicio

3. ¿Cómo se usa el servicio? La respuesta a esta pregunta es el grounding del servicio.

Visto de otra manera un cliente podría descubrir dinámicamente el servicio gracias a su perfil, y utilizarlo gracias a la información del grounding. Por otro lado el modelo describe el flujo de tareas y un posible camino de ejecución. Es por esto que se dice que el servicio es descrito por su modelo, el cual permite a su agente consumidor:

• Realizar un análisis detallado de cómo el servicio cumple con sus necesidades.

• Componer la descripción de un servicio desde múltiples web services que cumplen una tarea específica.

• Coordinar las tareas de múltiples agentes.

• Monitorear la ejecución del web service.

OWL-S es la evolución de DAML-S. Actualmente, OWL-S está en su versión 1.1 ya definitiva desde noviembre de 2004. Desde la versión 1.1 agrega la capacidad de incorporar reglas en un lenguaje denominado SWRL1. También mejora, respecto de la versión 1.0, la capacidad de especificar el workflow entre el cliente y el servicio web gracias a un flujo de datos entre procesos más detallado. Este proyecto es dirigido por el comité SWSL (Semantics Web Services Language) del SWSI (Semantic Web Services Initiative). Esta organización coordina internacionalmente el desarrollo de los web services semánticos. Es importante acotar que, además del desarrollo de OWLS, el SWSI es un foro de trabajo para la convergencia de OWL-S con WSMO/WSML.

Desde el punto de vista de OWL, el lenguaje en el que está escrita esta ontología, el servicio se representa por la clase Service. Se usará una instancia de esta clase para representar cada servicio concreto. Ver figura 5. Las propiedades presents, describedBy y supports son propiedades de la clase Service. Las clases ServiceProfile, ServiceModel y ServiceGrounding son los respectivos rangos de estas propiedades, por lo que, en una instancia concreta de Service, el valor de la propiedad presents será una clase derivada de ServiceProfile, el valor de la propiedad describedBy será una clase derivada de ServiceModel, y el valor de la propiedad supports será una clase derivada de Service-Grounding. Esta ontología presenta sólo dos restricciones de cardinalidad:

1. Un servicio puede ser descrito, como mucho, por un ServiceModel.

2. Un ServiceGrounding debe estar asociado con un único servicio.

1 http://www.daml.org/2003/11/swrl/



Figura 5 Nivel superior de la ontología Service

4.3.1 Clase Service Profile

Describe el servicio ofrecido desde tres puntos de vista, la información del proveedor, la descripción funcional del mismo y desde los rasgos que especifican las características del servicio.

La información del proveedor en esencia describe qué organización proporciona el servicio. Típicamente es información de contacto sobre la empresa. Se concreta en las propiedades serviceName, textDescription y contactInformation. Las dos primeras son de rango cadena y obligatorias. Sin embargo, contactInformation no tiene un rango especificado por lo que puede referirse a otras ontologías.

La descripción funcional básicamente 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 precondición una tarjeta de crédito válida, como datos de entrada el número de tarjeta y su fecha de vencimiento. Como resultado genera un recibo, y como efecto se efectúa el cargo en la cuenta del cliente. Se concreta en las siguientes propiedades:

• hasParameter

• hasInput

• hasOutput. Se refiere a la salida generada. No confundir con resultado, definido más adelante.

• hasPrecondition

• hasEffect. Diferencia entre salida y efectos: la salida sólo producen cambios en el estado del agente que invoca el servicio, mientras que los efectos tienen consecuencias reales.

Los rasgos que especifican las características del servicio son una lista en la que pueden aparecer datos tales como clasificación del servicio (como las taxonomías usadas en UDDI), una medida de la calidad del servicio ofrecido, o cualquier otra información (tiempo de respuesta, disponibilidad geográfica del servicio, etc.). Como se puede intuir estos parámetros podrían usarse para incluir nociones de calidad de servicio. Es importante aclarar que es responsabilidad del cliente el uso de esta información, su verificación, y decidir qué hacer con ella. Se concreta en:

• serviceParameter. Es una lista de propiedades. Cada propiedad tiene rango ServiceParameter. La clase ServiceParameter tiene las propiedades:

o serviceParameterName. El nombre del parámetro. Puede ser un literal o la URI del parámetro.



o sParameter. Apunta al valor del parámetro dentro de alguna ontología.

• serviceCategory. El rango de esta propiedad es la clase ServiceCategory. Esta clase se compone de:

o categoryName. Es el nombre de la categoría, pudiendo ser un literal, o una URI.

o taxonomy. Puede ser la URI de una taxonomía, la URL donde la taxonomía reside, o un literal cualquiera.

o value. Apunta un valor concreto dentro de la taxonomía. Puede haber varios.

o code. El código asociado al tipo de servicio en la taxonomía.

4.3.2 Clase ServiceModel

OWL-S define una clase derivada de ServiceModel para describir el modelado de los procesos. Esta clase se llama Proces. Los procesos concretos son clases derivadas de esta clase. Cada proceso descrito es una especificación de cómo es la interacción entre el cliente y el servicio.

Las precondiciones y los efectos se representan mediante reglas lógicas. Un proceso no deberá ser ejecutado a menos que sus precondiciones se cumplan (sean ciertas), si se ejecutase sin cumplirse las precondiciones el resultado está indefinido. El lenguaje en el que se van a expresar estas reglas puede ser cualquiera que tenga una representación textual. Las expresiones lógicas serán de tipo literal o literales XML.

El resultado de la invocación 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 condición bajo la que se produce este resultado y no otro. Las propiedades withOutput y hasEffect establecen qué sucede cuando la condición se satisface. La propiedad hasResultVar declara variables usadas en inCondition. Estas variables, llamadas ResultVars, son análogas a las variables Locals, y sirven para un propósito similar, permitiendo ligar las variables a las precondiciones y usarlas en las declaraciones de salida y efectos.

En OWL-S, los procesos se distinguen en atómicos, simples y compuestos.

• Los procesos atómicos son aquellos directamente invocables, no tienen subprocesos en un solo paso, al menos desde la perspectiva de quien lo invoca.

• Los procesos simples no son directamente invocables. Como los procesos atómicos pueden ser concebidos como que tienen un solo paso de ejecución. Los procesos simples son usados como elementos de un proceso abstracto, pueden ser para mostrar una vista de un proceso atómico, o simplificar un proceso complejo. Se puede decir que un proceso simple es realizado por un proceso atómico o que expanden un proceso compuesto.

• Los procesos compuestos son procesos que se pueden descomponer en otros subprocesos tanto compuestos como no. Está forma de descomponer estos procesos compuestos, está regida por las estructuras de control que a continuación se describen en una tabla.

Constructor Descripción

Sequence Ejecuta una lista de procesos en orden secuencial

Concurrent Ejecuta los elementos de una bolsa de procesos concurrentemente



Split Invoca elementos de una bolsa de procesos

Split+Join Invoca elementos de una bolsa de procesos y los sincroniza

Unordered Ejecuta todos los procesos de una bolsa en cualquier orden

Choice Elige entre dos alternativas y ejecuta un solo proceso

If-Then-Else

Ídem a la clásica estructura de control de todos los lenguajes

Repeat-Until

Idem observación anterior

Repeat-While

Ídem observación anterior

Figura 6 Tabla 1 - Constructores de estructuras de procesos

4.3.3 Clase ServiceGrounding

Las clases ServiceProfile y ServiceModel se consideran especificaciones abstractas en el sentido de que no dan detalles acerca de formato de los mensajes, protocolo usados, URL de acceso al servicio, etc. La misión de la clase ServiceGrounding es proporcionar todos esos detalles. Esta tarea de concretar mensajes y operaciones definidos de manera abstracta ya la realizan los bindings de WSDL. OWL-S aprovecha WSDL y define nuevos puntos de extensión. Además, de aprovechar la relación de WSDL con SOAP y UDDI, permitiendo una extensión sencilla, para añadir contenido semántico a los web services tradicionales.

Para poder hacer referencia a WSDL desde OWL-S se crea la clase WSDLGrounding, subclase de ServiceGrounding. Cada instancia de esta clase contiene una lista de instancias de la clase WSDLAtomicProcessGrounding. Cada una de las instancias de WSDLAtomicProcessGrounding se refiere a elementos de WSDL a través de las siguientes propiedades:

• wsdlVersion. Una URI que indica la versión de WSDL que se usa.

• wsdlDocument. La URI del documento WSDL.

• wsdlOperation. La URI de la operación WSDL correspondiente a ese proceso atómico.

• wsdlnputMessage. Un objeto que contiene la URI de la definición del mensaje WSDL que contiene los valores de entrada de ese proceso atómico.

• 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 cómo obtener ese part del message a partir de una o más entradas del proceso atómico OWL-S. En el caso más sencillo, en el que corresponde directamente con una única entrada OWL-S que tiene un tipo WSDL, basta con poner en el atributo owlsParameter la URI del objeto. En el peor de los casos hay que usar el atributo xsltTransformation para indicar una transformación XSLT que genere el part del message a partir de una instancia del proceso atómico.

• WsdOutputs. Como el anterior, pero para los valores de salida. En vez de WsdlInputMessagePart se usa WsdlOutputMessagePart.



La especificación de estos dos lenguajes son complementarias, OWL-S no sustituye a WSDL. Los lenguajes se solapan en lo que en WSDL se designan como tipos abstractos, que caracterizan las entradas y salidas del servicio. OWL -S provee la capacidad de darle sentido semántico a las definiciones abstractas, mientras que por otro lado no tiene la capacidad de expresar la información de ligado (binding) que tiene WSDL. La muestra la relación entre los componentes del WSDL y los de OWL-S.

Figura 7 Mapeo entre OWL-y WSDL

El trasfondo (grounding) de OWL-S se construye a través de una descripción en un archivo WSDL clásico, donde se agregan las siguientes extensiones:

• En el elemento message, se añade el atributo owl-s-parameter. Se le debe asignar como valor un objeto OWL-S (instancia de la clase Parameter). Alternativamente también se puede declarar la clase OWL en el elemento types.

• En el elemento binding, cuando el elemento part de message hace referencia a un tipo OWL, se debe poner encodingStyle a http://www.w3.org/2002/07/owl (o la versión que corresponda).

• En el elemento operation de binding, se añade el atributo owl-s-process. Se le debe asignar como nombre del proceso atómico OWL-S.

4.4 WSMO Web Service Modeling Ontology (WSMO), es una ontología para describir varios aspectos acerca de los web services semánticos desarrollada por el WSMO Working Group. Fue la unión de tres grandes proyectos europeos de investigación en el área de la web semántica y los web services semánticos 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 ontologías, 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 lenguaje provee una sintaxis formal y una semántica para el modelado de ontologías de servicios web (WSMO). WSML tiene una sintaxis XML y RDF. Es posible el mapeo entre ontologías WSML y ontologías OWL para interoperar con ontologías OWL por medio de un subconjunto semántico común de OWL y WSML1. WSML está basado en diferentes lógicas formales,

1 http://www.wsmo.org/wsml/wsml-syntax

OWL-S

WSDL

Modelo de Proceso

Proceso Atómico

Operación Mensaje

Entradas / Salidas

Binding to SOAP, HTTP, etc.

DL-based Types



llamadas Lógica de descripción (Description Logics), Lógica de Primer Orden (First-Order Logic) y Lógica de Programación (Logic Programming), que se usan para el modelado de Servicios de la Web Semántica. WSML consta de un número de variantes basadas en estas diferentes lógicas formales llamadas WSML-Core, WSML-DL, WSML-Flight, WSML-Rule y WSML-Full. WSML-Core es el núcleo el lenguaje y las otras variantes WSML ofrecen incrementos de expresividad en la dirección de la Descripción Lógica y la Lógica de Programación. Por último, ambos paradigmas se unifican en WSML-Full, la variante más expresiva de WSML [13].

También se ha desarrollado WSMX (Web Service Modelling eXecution environment) que es el entorno de ejecución de modelado de servicios web y la implementación de referencia de WSMO. WSMX es open souce y usa WSML como lenguaje interno.

En WSMO, un objetivo especifica qué quiere el usuario y la descripción del servicio Web define la capacidad que proporciona el servicio. Con WSMO también pueden expresarse las propiedades no funcionales del servicio.

Si bien WSMO presenta un modelo conceptual que promete ser más robusto que OWL-S, esta tecnología aún no se encuentra madura y en la actualidad no cuenta con herramientas que permitan describir y ejecutar web services semánticos, a diferencia de OWL-S.

http://www.wsmo.org/wsml

http://www.w3.org/Submission/WSML/



5 Modelado de procesos

5.1 Introducción Durante muchos años el principal uso de las computadoras en las organizaciones fue la automatización de las actividades individuales dentro de las mismas. La situación actual es distinta, en los últimos años se ha notado un interés cada vez más creciente de poder ver a la organización como un todo. Existen un sin número de metodologías, notaciones para análisis y diseño ya consolidadas (por ej. UML), así como herramientas de desarrollo cada vez más potentes (RAD1, generadores de código, etc.). Todo ello, sumado a la necesidad de las organizaciones de poder adaptarse rápidamente a los cambios en los procesos internos que experimentan, ha motivado que se esté produciendo un cambio de orientación que apunta hacia los procesos organizacionales o procesos de negocio. El interés de las organizaciones ya no está limitado únicamente al desarrollo de software que automatice determinadas actividades individuales, sino que por el contrario, tienen como objetivo final la automatización 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 realización permite alcanzar un cierto objetivo o meta en el contexto de una organización [14].

En el presente contexto el modelado de procesos (BPM – Business Process Modeling2) y las tecnologías asociadas, tales como la Arquitectura Orientada a Servicios (SOA), ofrecen un marco adecuado para abordar el problema, puesto que cubre, al menos parcialmente, estas necesidades. Es imposible hablar de BPM sin hablar de la tecnología de workflow ya que a grandes rasgos BPM se puede ver como una evolución natural de la tecnología de workflow con el fin de adaptarse a las necesidades actuales de los procesos de negocio. Es por eso que en las siguientes secciones se desarrolla más en detalle el concepto de workflow y uno de los principales modelos que se encuentran detrás de él, el Modelo de Referencia, para posteriormente compararlo estableciendo las diferencias y similitudes con BPM.

5.2 ¿Qué es un Proceso de Negocio? Un proceso de negocio se puede ver como un conjunto estructurado de tareas, que contribuyen colectivamente a lograr los objetivos de una organización. Los procesos de negocio de una organización 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 gestión de los procesos trae aparejados altos costos, baja productividad, e inadecuados tiempos de respuesta tanto frente a las oportunidades como a las amenazas. Por esto el modelado de procesos viene siendo objeto de estudio desde hace ya tiempo.

Como respuesta al problema del modelado de procesos de negocio dentro de una organización, en la década del 90 surge la tecnología de workflow. Esta tecnología permitió representar total o parcialmente los procesos de negocio en un formato entendible por una máquina.

1 RAD (Rapid Application Generation) es una metodología que permite reducir el tiempo de desarrollo, la cual utiliza herramientas generadoras de código y se basa en librerías preexistentes.

2 En la bibliografía de referencia también puede encontrarse BPM como abreviación del término Bussiness Prosess Managment (Administración de Procesos de Negocios).



5.3 ¿Qué es un workflow? Workflow Management Coalition (WfMC), una de las principales organizaciones en el mundo que trabaja en temas de workflow, lo define de la siguiente manera: “un conjunto de uno o más 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” [15].

En un workflow, la información, 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 definición del flujo de trabajo y a su posterior ejecución, se denominan Workflow Managment System (WMS).

5.4 Workflow Managment System Un WMS es “un sistema que define, crea y gestiona la ejecución de flujos de trabajo (workflow) mediante el uso de software, siendo capaz de interpretar la definición del proceso, interactuar con los participantes y, siempre que se requiera, invocar el uso de herramientas y aplicaciones” [16]. Ejemplos claros de utilización de los sistemas de workflow pueden ser: la gestión documental, los servicios de gestión de personal (solicitud de las vacaciones, hoja de gastos de desplazamiento, etc.), el control de la producción o los procesos colaborativos.

De la definición anterior se desprenden dos actividades concretas, por un lado la definición del workflow que representa el proceso de negocio y por otro la ejecución del mismo. Si bien el proceso es el componente principal existen también otros aspectos que se deben considerar, tales como la interacción con los usuarios en aquellas tareas que requieren de intervención del mismo y la invocación de servicios externos por parte de las tareas para poder cumplir sus objetivos

Los WMS pueden ser implementados de diferentes formas como resultado de la utilización de diferentes tecnologías y plataformas. Pueden ir desde un pequeño grupo de trabajo a una gran organización. No obstante, todos los WMS exhiben ciertas características comunes. En el nivel más alto, todos los WMS pueden ser caracterizados por proveer tres áreas de funcionalidad:

• Funciones de tiempo de Construcción (Build-time functions), dedicadas a la definición y modelado de un proceso junto con todas sus actividades concernientes.

• Funciones de control en tiempo de ejecución (Run-time control functions), las cuales controlan el proceso en el ambiente de ejecución, llevando a cabo cada tarea (o actividad) definida como parte del proceso

• Funciones de interacción en tiempo de ejecución (Run-time interaction), las cuales interactúan con los usuarios o aplicaciones externas para que los participantes del proceso puedan llevar a cabo sus tareas.



Figura 8 Caracterización de los WMS por la WfMC

En cuanto a investigación, existen diferentes líneas relacionadas con los WMS, que abarcan desde temas relacionados tanto con la definición de flujos de trabajo como con su ejecución. Precisamente, es en la ejecución donde se han invertido más esfuerzos.

El problema de los WMS es que surgieron primero en la industria y más tarde se convirtieron en área de investigación. Esto motivó la aparición en el mercado de numerosos productos, catalogados como WMS, que resuelven problemas concretos pero en los que, en muchas ocasiones, se nota la falta de un marco teórico y fundamentado que permita resolver ciertas limitaciones existentes. Entre ellas se pueden citar problemas de escalabilidad, interoperabilidad, robustez, falta de soporte metodológico al modelado y falta de soporte para el análisis de los resultados de la ejecución. Respecto a los productos existentes en el mercado, no todos entran dentro de la misma categoría, ni todos ellos proporcionan las mismas prestaciones a la hora de modelar o ejecutar un flujo de trabajo (una categorización más completa se puede ver en [14]).

Hay muchos productos comerciales que utilizan diferentes lenguajes y paradigmas pero no existe un consenso general de qué constituye la especificación de un workflow. Se nota claramente la falta de una teoría organizacional universal para esta especificación, que sirva además como base para una comparación más rica de las diferentes herramientas y tecnologías. En la sección 5.6 se da una breve introducción a la especificación de workflows y la utilización de patrones.

5.5 Modelo de referencia de Workflow En 1995 la WfMC publica un documento de referencia titulado “The Workflow Reference Model” [15] que define una serie de conceptos básicos asociados a la arquitectura de los WMS.

El Modelo de Referencia propuesto por la WfMC intenta reunir las características comunes a cualquier WMS, de manera de poder alcanzar la interoperabilidad entre ellos, a través de estándares comunes para cada una de las funciones que se puedan realizar. Debido a que el objetivo de la WfMC es definir estándares y guías globales para el desarrollo de WMS, su documentación es de carácter genérico y no describe en detalle ningún WMS en particular, sino que brinda un marco general para la construcción de los mismos.

En primer lugar, el modelo identifica las distintas áreas funcionales para luego desarrollar las especificaciones para la implementación de las mismas, asegurándose la interoperabilidad entre distintos WMS y su integración con otras aplicaciones informáticas.

Herramientas yAplicaciones IT

Interacción con Herramientas de Aplicación

y Usuarios

Control e Instanciaciónde Procesos

Servicio de Ejecución del Workflow

Cambios en Procesos

Definición deProcesos

Tiempo de Desarrollo

Tiempo de Ejecución

Definición yDiseño de Procesos

Análisis de Procesos de Negocio,Herramientas de Modelado y Definición



Figura 9 Modelo de referencia de WfMC

El componente central es el Servicio de Ejecución 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 ejecución de cada instancia de workflow. En caso de estar en un entorno de ejecución de flujo de trabajo distribuido, pueden existir diferentes motores de flujo de trabajo que controlen distintas partes de la ejecución del proceso. La comunicación de este componente con el resto se realiza a través de lo que la WfMC denomina WAPI (Workflow APIs), es decir, la interfaz para la programación de aplicaciones de flujo de trabajo [16].

Otro de los componentes es el de Herramientas de Definición 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, lápiz y papel) o mucho más sofisticadas y formalizadas (interfaces gráficas con un modelo subyacente bien definido). Se debe especificar la lógica del proceso, las actividades que lo componen, los participantes humanos, aplicaciones invocadas, datos utilizados, etc.

La interfaz 1 permite la comunicación entre este componente y el servicio de ejecución del flujo de trabajo. La distinción de ambos componentes aporta claros beneficios, entre los que se destaca la separación entre el entorno de ejecución y el de definición. De este modo, es posible almacenar en un repositorio la información sobre la definición del proceso y ésta ser accedida por distintos entornos de ejecución para ejecutarlo completamente o de forma distribuida. La interfaz 1 se encarga por tanto del intercambio de información entre el componente que permite la definición del proceso y el propio servicio de ejecución del flujo de trabajo. Esta interfaz hace necesaria la definición de un metamodelo básico, en el que se identifique el conjunto mínimo de entidades para la definición de un proceso, permitiendo el intercambio de información entre ambos componentes. Un ejemplo de este metamodelo es la especificación XPDL [17] de la WfMC.

El componente denominado Aplicaciones Cliente del Workflow (Workflow Client Applications), representa las entidades de software utilizadas por el usuario final en aquellas actividades que requieren participación humana para su realización. Si este componente se separa de lo que es el propio componente de ejecución, es necesaria una interfaz (interfaz 2) que defina y maneje claramente el concepto de lista de trabajos (o

HerramientasDefinición

del Proceso

Workflow API e intercambio de formatos

Servicio de ejecución del Workflow

Interfaz 1

Interfaz 2 Interfaz 3

Interfaz 4

Interfaz 5

Herramientasde Administración

y Monitorización

Aplicaciones Clientedel Workflow

AplicacionesInvocadas

MotorWorkflow

Otros serviciosde ejecución de Workflow

MotorWorkflow



worklist), como una cola de trabajo asignado a un usuario o a un grupo de usuarios por el propio motor de ejecución del flujo de trabajo.

El componente Aplicaciones Invocadas (Invoked Applications) representa software o aplicaciones ya existentes que un WMS puede utilizar para la realización 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 comunicación entre este componente y el servicio de ejecución del flujo de trabajo, no sólo a nivel de invocación del mismo, sino de transformación de datos en formatos entendibles por ambos componentes. Una posible solución se obtiene a través de lo que se denomina agente aplicación, de modo que el servicio de ejecución del flujo de trabajo se comunica con las funciones estándar de dicho agente aplicación y éste define interfaces específicas para cada tipo de aplicación invocada.

La interoperabilidad entre WMS está representada por el componente denominado Otros Servicios de Ejecución de Workflow (Other Workflow Enacment Systems), siendo la interfaz

4 la que permite dicha comunicación. En este caso, la WfMC ha desarrollado un conjunto de escenarios de interoperabilidad que van desde la conexión a nivel de actividades simples hasta todo un completo intercambio de definición de procesos y datos [18].

Finalmente, el componente Herramientas de Administración y Monitorización (Administration & Monitoring Tools) permite que distintos servicios de ejecución de flujo de trabajo compartan las mismas funciones de administración y monitorización del sistema, como pueden ser, por ejemplo, la gestión de usuarios, el control de los recursos y la supervisión del estado de todo el proceso.

5.6 Especificación de un Workflow La aparición masiva de numerosos WMS puso en evidencia aun más la falta de un modelo formal universal para la especificación de un proceso de negocio. Esto dificulta de sobremanera la comparación de las diferentes tecnologías y herramientas. Afortunadamente la especificación de un workflow puede ser explicada en sentido general desde diferentes perspectivas [19]:

• Perspectiva de Control de Flujo: describe actividades y su orden de ejecución mediante diferentes constructores que permiten controlar el flujo de ejecución (joins, splits, secuencias paralelismo, etc.). Estas actividades se pueden ver como unidades atómicas de trabajo.

• Perspectiva de Datos: describe los datos (documentos, objetos, etc.) que fluyen entre las diferentes actividades. Estos datos también pueden ser variables locales que definen pre y pos condiciones en la ejecución de tareas.

• Perspectiva de Recursos: muestra una visión más orientada al negocio, describiendo el proceso en función de las responsabilidades que tienen las diferentes personas o dispositivos en la ejecución 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 aplicación con determinados datos.

Si bien todas las perspectivas presentan una visión diferente del mismo sistema, la perspectiva de control de flujo provee un mejor panorama para la especificación de un workflow describiendo más ampliamente el proceso en sí mismo. La perspectiva de datos solo se apoya en la mencionada anteriormente, mientras que la operacional es más bien complementaria. Es por esto que los estudios se enfocan en la perspectiva de control de flujo.

En general, la mayoría de los lenguajes para workflows cuentan con los constructores básicos pero ni siquiera la interpretación de estos constructores básicos es uniforme.



5.6.1 Patrones de Workflows

Un importante aporte en esta área es el de W.M.P., van der Aalst et al. [19]. Sus investigaciones apuntan a describir los requerimientos para un workflow mediante patrones.

Los patrones son el artefacto ideal para ser usado en este contexto ya que son independientes de las tecnologías y permiten abstraer de los requerimientos específicos del dominio al que se están enfocando. El estudio de [19] tuvo como resultado la identificación de más de veinte patrones que describen el comportamiento de los procesos de negocios. Estos patrones van desde patrones sencillos hasta muy complejos y se pueden organizar en seis grupos y pueden agruparse teniendo la perspectiva del workflow a la que se apunta. A continuación se mencionan algunos de le los patrones de la perspectiva de control de flojo:

• Patrones de control básico

• Patrones de bifurcación y sincronismo avanzados

• Patrones que involucran múltiples instancias

• Patrones estructurales

• Patrones basados en el estado

• Patrones de cancelación

El contar con una especificación de alto nivel como esta permite comparar diferentes productos y tecnologías de modelado de proceso, analizando el soporte que cada una de ellas provee de estos patrones. En el mismo trabajo [19], así como en el sitio web que figura en las referencias se pueden encontrar comparaciones de varios WMS del mercado y de las tecnologías mas difundidas relacionadas con los workflows.

5.7 Business Process Management Si bien la sigla BPM puede tener diferentes significados según el contexto en que se esté manejando, a los efectos del presente documento se referirá a la Gestión de Procesos de Negocios (o Business Process Managment en inglés), salvo que se especifique lo contrario. El concepto de Gestión de Procesos de Negocios engloba todas las actividades que son parte del ciclo de vida de un proceso de negocios, tales como el descubrimiento, diseño, simulación, deployment, ejecución, interacción, monitoreo, control, análisis y optimización del proceso de negocios [20].

BPM surge como la evolución natural de los sistemas de workflow y de los procesos de negocio de las empresas. Esto es debido a que la evolución del término proceso ha cambiado en el interior de las organizaciones; muchos de los procesos de las empresas actuales no se apoyan solo sobre una aplicación o un conjunto de aplicaciones internas, como sucede con los sistemas de workflow tradicionales.

Cada vez más, las necesidades de las empresas se están orientando hacia procesos más complejos que engloban diferentes departamentos, filiales o socios, que pueden incluso estar geográficamente distribuidos. Cada una de estas entidades posee sus propios procesos que pueden ser más o menos heterogéneos y complejos. Para representar este tipo de procesos, se necesitan sistemas más potentes que los actuales sistemas de workflow, los que se conocen como Business Process Management Systems (BPMS). Los BPMS son capaces de suplir las carencias de los sistemas de workflow en el campo de los procesos de negocio: control de las conversaciones de larga duración entre las entidades que forman parte del proceso, control y gestión de diferentes hilos de ejecución, ejecución paralela, control de errores, compensación de transacciones, soporte de datos XML complejos, etc. [21].

No es raro que los conceptos workflow y BPM se confundan pues, además de otras características en común, ambos contienen una representación de un flujo de trabajo (un



workflow desde el punto de vista lógico), es decir, el flujo de trabajo puede ser representado en ambos por algún lenguaje de notación y de especificación. Pero el hecho es que son cosas diferentes. A modo de ejemplo, en general los WMS no cumplen con los requisitos de escalabilidad que requieren las organizaciones hoy en día y en general están limitados a interactuar con aplicaciones dentro de la organización. Por el contrario, BPM no solo define las tareas y el seguimiento de las mismas, sino que tiene como objetivo solucionar el ciclo completo de un proceso de negocio.

5.8 Composición de Servicios Para poder solucionar varios de los problemas mencionados anteriormente, las tecnologías BPM surgieron apoyadas en la arquitectura orientada a servicios (SOA), descripta en la sección 2. Un ejemplo de esto es el problema de distribución y heterogeneidad de sistemas con los que se debe interactuar para completar el proceso de negocio, en este contexto la arquitectura SOA es más que apropiada.

Es así que del modelado de procesos y de la arquitectura orientada a servicios, más precisamente del uso de web services surge un nuevo concepto denominado composición de servicios. Esta composición no solo permite modelar el proceso de negocio sino que también maximiza las potencialidades que SOA brinda a través de la integración de datos y aplicaciones.

La composición de servicios implica encontrar un mecanismo que permita a dos o más de ellos cooperar entre si para resolver requerimientos que van más allá del alcance de sus capacidades individuales. Algunos de los requisitos básicos que se deben cumplir son:

• Interacciones asincrónicas con servicios: de manera de dar la posibilidad de crear procesos que transcurran durante largos períodos de tiempo.

• Interacciones simultáneas 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 múltiples servicios puede fallar en su ejecución si al menos uno de sus componentes falla. Se debe tener en cuenta la ocurrencia de errores y proveer mecanismos para manejarlos.

• Integridad transaccional: un proceso de larga duración puede eventualmente fallar, en este caso puede requerirse que parte de las acciones ya efectuadas se deshagan.

Dos términos comúnmente usados para referirse a la colaboración entre servicios son orquestación y coreografía. Ambos están directamente relacionados con la composición pero se enfocan en aspectos complementarios de la interacción entre servicios. Si bien para los fines de este proyecto el concepto relevante es el de orquestación, vale la pena hacer mención a ambos para de esa forma visualizar sus similitudes y diferencias.

Orquestación

Un proceso se puede considerar una orquestación de servicios cuando es controlado totalmente por una única entidad. Este proceso define completamente las interacciones con los servicios componentes y la lógica requerida para conducir correctamente esas interacciones. Este tipo de proceso puede entenderse como privado y ejecutable ya que solo la entidad que está orquestando el proceso conoce el flujo de control e información que sigue el proceso que se está orquestando. De esta manera se crea un proceso que utiliza diferentes servicios manipulando la información que fluye entre ellos, convirtiendo, por ejemplo, los datos de salida de algunos servicios en datos de entrada de otro. Aquí, cada entidad que participa implementa y controla su propio proceso [22].

Coreografía

Un proceso es una coreografía de servicios cuando define las colaboraciones entre cualquier tipo de aplicaciones componentes, independientemente del lenguaje o plataforma en el que



estén definidas las mismas. Un proceso de coreografía no es controlado por uno solo de los participantes. A diferencia de la orquestación, la coreografía puede verse como un proceso público y no ejecutable. Público porque define un comportamiento común que todas las entidades participantes deben conocer, y no ejecutable porque está pensado para verse más bien como un protocolo de negocio que dicta las reglas para que dichas entidades puedan interactuar entre sí [22].

5.9 Estándares

5.9.1 Organizaciones

Los principales esfuerzos en el desarrollo y promoción de estándares en el campo de los WMS vinieron de parte de la WfMC. Esta es una organización internacional, sin fines de lucro, que se establece en 1993 y reúne a un grupo de vendedores, usuarios, analistas y grupos de investigación. Su principal objetivo es promover el uso de WMS mediante el establecimiento de estándares que faciliten la creación, desarrollo y análisis de estos sistemas.

La WfMC ha definido una serie de estándares entre los que se destaca el Modelo de Referencia [15] que describe la arquitectura básica de un WMS y que junto al de Terminología y Glosario [23], constituyen el material básico de referencia.

Posteriormente, Object Management Group (OMG) también se une a los esfuerzos de la WfMC en la propuesta de estándares. OMG también es una organización internacional sin fines de lucro fundada en 1989, cuyo principal objetivo se centra en promover la teoría y práctica de la tecnología orientada a objetos en el desarrollo de software. En 1997 se inicia un acercamiento hacia los WMSs, y este acercamiento de OMG conlleva a la publicación de una primera especificación, basada en los estándares de la WfMC, que establece requisitos de interoperabilidad entre distintos WMS en un entorno CORBA [16].

Finalmente en agosto de 2000 se crea la Business Process Management Initiative (BPMI.org), otra organización sin fines de lucro que también agrupa a varias instituciones y tienen como misión promover el uso de BPM (Business Process Managment). BPMI.org desarrolla especificaciones abiertas para el diseño, ejecución, mantenimiento y optimización de procesos de negocio. BPMI.org cuenta con una especificación para la notación (BPMN) [24] y un lenguaje de modelado de procesos de negocios (BPML) [25] que se encuentran en su versión 1.0.

Un hecho importante a tener en cuenta es la fusión estratégica entre la BPMI.org y la OMG que se llevó a cabo a fines de junio de 2005. Este acontecimiento es más que importante teniendo en cuenta que dos de las tecnologías de notación más difundidas hoy por hoy son BPMN (de la BPMI.org) y los diagramas de Actividad de UML (de la OMG). Según el comunicado oficial la BPMI.org pasará a ser la fuerza de trabajo de la OMG en el área del modelado de proceso de negocios. En dicho comunicado se mencionan algunos puntos clave en los que se hará hincapié, entre los cuales esta el desarrollo y difusión del lenguaje de notación BPMN.

5.9.2 Estándares para la notación de procesos

La combinación de web services para la implementación de procesos de alto nivel, requiere de diversos estándares que permitan modelar las posibles interacciones entre los servicios. Es así que se introducen los términos de orquestación y coreografía (presentados en la sección 5.8), que tratan de describir aspectos relacionados con la creación de procesos de negocio que involucran varios web services

Existen actualmente lenguajes y estándares específicos para la coordinación de web services. Mucha es la documentación que se encuentra disponible sobre la evolución que ha tenido cada uno. Sin embargo en este estudio se investigan aquellos lenguajes que permitan orquestación de web services y que se encuentran vigentes.



5.9.2.1 BPMN

Business Process Modeling Notation (BPMN) fue desarrollado por BPMI (Business Process Management Initiative) [24]. Su autor es Stephen A. White de IBM, donde el grupo BPMI contribuyó en la especificación. Su principal meta es proveer una notación fácil y clara para todos los usuarios de negocios: para los analistas de negocios que crean los borradores iniciales de los procesos, para los desarrolladores técnicos responsables de implementar la tecnología que realizará esos procesos, y finalmente para el personal de negocios que administra y monitorea esos procesos. Así, BPMN hace de puente entre el diseño de procesos de negocio y la implementación siendo una notación gráfica para expresar procesos de negocios en un Business Process Diagram (BPD) capaz de representar complejos proceso.

Otra meta, pero no menos importante, es asegurar que los lenguajes XML diseñados para la ejecución de procesos de negocio, tales como BPEL4WS (Business Process Execution Language for Web Services), puedan ser visualizados con una notación orientada al negocio. Este lenguaje gráfico puede ser mapeado sobre lenguajes como BPML y BPEL4WS, donde en la misma especificación se le dedican casi 50 páginas al mapeo sobre BPEL.

La especificación define la notación y la semántica de un Business Process Diagram (BPD) e intenta representar la conjunción de las mejores prácticas dentro de la comunidad para el modelado de procesos de negocio.

En junio de 2005, el Business Process Management Initiative (BPMI.org) y Object Management Group™ (OMG™) anunciaron el fusionamiento de sus actividades BPM (Business Process Management) para proveer liderazgo y estándares para esta industria vital y creciente. El grupo combinado se ha nombrado Business Modeling & Integration (BMI) Domain Task Force (DTF). (http://bmi.omg.org).

5.9.2.2 UML

Entre los lenguajes de modelado que define OMG (Object Management Group) [26] el más conocido y usado es sin duda UML (Unified Modeling Language) [27]. UML es un lenguaje gráfico para especificar, construir y documentar los artefactos que modelan un sistema. Fue diseñado para ser un lenguaje de modelado de propósito general, por lo que puede utilizarse para especificar la mayoría de los sistemas basados en objetos o en componentes, y para modelar aplicaciones de muy diversos dominios de aplicación (telecomunicaciones, comercio, sanidad, etc.) y plataformas de objetos distribuidos (como por ejemplo J2EE, .NET o CORBA) [28].

El hecho de que UML sea un lenguaje de propósito general proporciona una gran flexibilidad y expresividad a la hora de modelar sistemas. Sin embargo, hay numerosas ocasiones en las que es mejor contar con algún lenguaje más específico para modelar y representar los conceptos de ciertos dominios particulares. Esto sucede, por ejemplo, cuando la sintaxis o la semántica de UML no permiten expresar los conceptos específicos del dominio, o cuando se desea restringir y especializar los constructores propios de UML, que suelen ser demasiado genéricos y numerosos.

OMG define dos posibilidades a la hora de definir lenguajes específicos de dominio, y que se corresponden con las dos situaciones mencionadas antes: o bien se define un nuevo lenguaje (alternativa de UML), o bien se extiende el propio UML, especializando algunos de sus conceptos y restringiendo otros, pero respetando la semántica original de los elementos de UML (clases, asociaciones, atributos, operaciones, transiciones, etc.).

Cada una de estas dos alternativas presenta ventajas e inconvenientes. Así, definir un nuevo lenguaje ad-hoc permite mayor grado de expresividad y correspondencia con los conceptos del dominio de aplicación particular, obteniéndose de esta forma una solución a medida. Sin embargo, y aún cuando esos nuevos lenguajes ad-hoc se describan con



MOF, el hecho de no respetar el meta-modelo estándar de UML va a impedir que las herramientas UML existentes en el mercado puedan manejar sus conceptos de una forma natural [28].

5.9.3 Estándares para la ejecución de procesos

5.9.3.1 BPEL

Business Process Execution Language for Web Services (BPEL4WS, BPELWS o comúnmente BPEL) [29]define una notación estándar para especificar el comportamiento de un proceso de negocio basándose en web services.

BPEL representa la convergencia de las ideas presentes en las especificaciones Web Service Flow Language (WSFL) [30] de IBM y XLANG [31] de Microsoft. BPEL4WS posibilita una mezcla de modelos de proceso de estructuras de bloque y de grafo, haciendo el lenguaje expresivo al costo de ser complejo.

Al ser un modelo basado en web services los procesos que se describen exportan e importan funcionalidades usando solamente interfaces de web services.

El proceso BPEL define cómo se coordinan múltiples interacciones de servicios para lograr una meta comercial, así como el estado y la lógica necesaria para esta coordinación. También introduce los mecanismos sistemáticos para tratar excepciones y procesamiento de fallas.

BPEL4WS depende de la siguiente especificación de XML-based: WSDL 1.1, XML Schema 1.0, XPath 1.0 y WS-Addressing. El que más influencia tiene es WSDL. En el centro del modelo de proceso está la noción de interacción entre servicios peer-to-peer descriptos en WSDL.

Así como en la especificación de BPMN se define un mapeo desde BPMN hacia BPEL, Keith Mantell de IBM en un artículo publicado en setiembre de 2003, muestra con un ejemplo que es posible el mapeo desde UML hacia BPEL [32].

5.9.3.2 BPML

Business Process Markup Language (BPML), desarrollado por Business Process Management Initiative (BPMI.org), es un lenguaje que permite especificar un modelo abstracto para expresar procesos de negocio y soportar entidades. BPML define un modelo formal para expresar procesos abstractos y ejecutables, incluyendo soporte para actividades de complejidad variada, transacciones y su compensación, manejo de datos, concurrencia, manejo de excepciones y semántica operacional. BPML también provee una gramática en la forma de un XML Schema para habilitar la persistencia e intercambio de definiciones para sistemas heterogéneos y herramientas de modelado [25].

BPML ofrece soporte también para realizar composiciones recursivas a fin de poder construir procesos de negocio que a su vez consten de subprocesos de negocio.

BPML depende de las siguientes especificaciones: XML 1.0, XML-Namespaces, XMLSchema 1.0 y XPath 1.0, WSDL 1.1.

5.9.3.3 YAWL

Yet Another Workflow Language (YAWL) es un sistema de procesamiento de Workflow/business. Este lenguaje toma como punto de partida las redes de Petri [33] y adiciona mecanismos para permitir un soporte más directo e intuitivo de los patrones de workflow identificados en [34]. La motivación que se plantea para utilizar las redes de Petri es que proporciona semántica formal (a pesar de la naturaleza gráfica), se basa en estados en lugar de eventos, y abundan técnicas de análisis. Por otro lado, mejora la



transformación de datos complejos, y la integración de web services. Usa Java, schema, Xpath Query, SOAP y WSDC.

5.9.3.4 ebXML

ebXML fue publicado en 1999 como una iniciativa del UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) y OASIS (Organization for the Advancement of Structured Information Standars).

Es una familia basada en el estándar XML auspiciado por OASIS y UN/CEFACT para los cuales la misión es proveer una infraestructura abierta basada en XML que permita el uso global de información para negocios electrónicos en una forma interoperable, segura y consistente para todos los socios del negocio.

ebXML no es un estándar, es un contenedor para varios estándares de especificación administrados por UN/CEFACT y OASIS: ebXML Servicios de Mensajes, ebXML Registro, ebXML Esquema de Especificación de Procesos de Negocios y ebXML Acuerdo y Perfil de Protocolos de Colaboración, los cuales fueron aprobados por la ISO (Internationl Organization for Standardization) y son parte de la familia de estándares ISO 15000.



6 MDA: Arquitectura Dirigida por Modelos

6.1 Introducción MDA (Model Driven Architecture) [35] es una iniciativa de la OMG que defiende la definición de modelos como elementos de primera clase para el diseño e implementación de un sistema. En MDA, las actividades más importantes pasan a ser las de modelado de los diferentes aspectos de un sistema y la definición de transformaciones de un modelo a otro de forma que puedan ser automatizadas. De esta forma el foco está en definir modelos, no considerando detalles de implementación en una plataforma hasta el final, lo que los hace más portables, adaptables a nuevas tecnologías (por ejemplo, .NET, J2EE, web services) e interoperables con otros sistemas independientemente de la tecnología que utilicen.

MDA define tres niveles conceptuales. En primer lugar, los requisitos del sistema se representan con un modelo independiente de la computación (CIM, Computation Independent Model) que define el sistema en el entorno en el cual va a operar. En el siguiente nivel se encuentra el PIM (Platform Independent Model), un modelo que describe la funcionalidad del sistema, pero omitiendo detalles sobre cómo y dónde va a ser implementado (por ejemplo, el PIM puede ser independiente de la distribución y de la plataforma de objetos en donde se ejecutará, ya sea CORBA, J2EE, .NET, etc.). El objetivo es entonces transformar el PIM en un modelo dependiente de la plataforma final, denominado PSM (Platform Specific Model). De esta forma se consigue una gran independencia entre la descripción de la funcionalidad, y los detalles de implementación propios de la plataforma objetivo.

La ventaja más importante de este enfoque, es el poder definir transformaciones automáticas entre un PIM y distintos PSM, de forma que a partir del modelo PIM del sistema, de la descripción del modelo de la plataforma PSM concreta donde se implementará el sistema, y de una serie de reglas de transformación, se pueda obtener la implementación del sistema de la forma más automatizada posible.

6.2 BPDM La OMG tiene su propio plan de desarrollo para cubrir el modelado de procesos de negocio. Este plan está incluido en la arquitectura MDA. El Business Process Definition Metamodel (BPDM) define un metamodelo para la definición de procesos de negocio, lo que es una plataforma independiente con respecto a definiciones específicas de proceso de negocio. Este metamodelo define una representación abstracta para la especificación de procesos ejecutables de negocio que se ejecutan dentro de una empresa (con o sin intervención humana); y puede colaborar con otro proceso de negocio independiente ejecutando en diferente unidad de negocio o empresa.

Figura 10 Business Process Definition Metamodel

UML 2.0 BPMN Otros

Business Process Definition Metamodel

ProcesosInformación Recursos

BPEL4WSJ2EE Otros



7 Herramientas

7.1 Herramientas de Gestión de Procesos de Negocio Se presentan a continuación algunas de las herramientas comerciales más relevantes que se encuentran disponibles para la definición de procesos de negocio en algún lenguaje gráfico y que permiten la generación de código de orquestación de web services.

7.1.1 Emerging Technologies Toolkit

Como parte de Emerging Technologies Toolkit (ETTK) en el alphaWorks versión 1.1 de IBM, se presenta una herramienta donde a partir de una definición de un proceso en UML (Unified Modeling Language) se generan los archivos BPEL y WSDL correspondientes que implementan el proceso. Esta capacidad es utilizada para resaltar algunos de los beneficios de la iniciativa MDA de OMG: incrementar el nivel de abstracción en el desarrollo, dando mayor productividad, buena calidad, y aislamiento de los cambios en las tecnologías subyacentes.

En el artículo [32], se presenta la herramienta junto a un reducido ejemplo de su funcionamiento. En este se muestra cómo es posible realizar un mapeo entre un perfil UML y conceptos BPEL según la siguiente tabla:

Profile Construct BPEL4WS Concept

<<process>> class BPEL process definition

Activity graph on a <<process>> class BPEL activity hierarchy

<<process>> class attributes BPEL variables

Hierarchical structure and control flow BPEL sequence and flow activities

<<receive>>, <<reply>>, <<invoke>> activities BPEL activities

Figura 11 Mapeo de UML a BPEL

En el alphaWorks de IBM, como parte del ETTK también está disponible un demostrador que apoya un escenario punto a punto desde una herramienta de UML (como Rational XDE [36]) hacia un BPEL4WS (BPWS4J) ejecutable.

La implementación del mapeo se construye como un plug-in de Eclipse (disponible en www-306.ibm.com/software) y toma como entrada para el intercambio de modelos UML, un formato de archivo estándar XMI. Se generan artefactos de BPEL4WS junto con los WSDL requeridos y artefactos de XSD.

Los archivos pueden ser principalmente de dos tipos:

• archivos UML editables con Rose o XDE,

• archivos XML conteniendo la versión XMI del modelo UML, exportados por Rose o XDE.

Los principales pasos son:

• creación y exportación del modelo UML hacia XMI (utilizando Rational Rose o XDE)

• generación de los archivos BPEL, WSDL y XSD (utilizando Eclipse o WebSphere Application Developer), donde debe crear un proyecto java, importar el XMI creado anteriormente, para generar con la opción correspondiente los archivos BPEL, etc. los cuales son incluidos en el proyecto)



• desplegar y ejecutar

7.1.2 WebSphere

WebSphere Application Server 6.0 es la nueva plataforma de IBM para el desarrollo y despliegue de aplicaciones basadas en tecnologías J2EE y SOA. Dispone de un motor transaccional escalable y con un gran rendimiento y trae incorporada una perspectiva para el modelado de los procesos del negocio utilizando BPEL. A continuación se mencionan brevemente los componentes.

Servidores de Aplicación:

• WebSphere Application Server 6.0 Express: servidor de aplicaciones J2EE 1.4 y web services con un licenciamiento por usuarios.

• WebSphere Application Server 6.0: servidor de aplicaciones J2EE 1.4 y web services con un licenciamiento por CPU.

• WebSphere Application Server 6.0 Network Deployment: añade al anterior el balanceo y la tolerancia a fallos. Además incluye un servidor UDDI, un servidor Proxy, un dispatcher TCP/IP y el web services Gateway.

• WebSphere Business Integration Server Foundation 5.1.1: añade al anterior la Coreografía de Procesos (motor BPEL) así como algunas extensiones al modelo de programación J2EE (todavía no estandarizadas).

Herramientas de desarrollo:

• Rational Web Developer 6.0: IDE basado en Eclipse 3.0 para el desarrollo Java, web (sin EJBs), XML, web services y demás...

• Rational Application Developer 6.0: añade al anterior el desarrollo completo J2EE 1.4, profiler Java, automatización de pruebas, UML y desarrollo de portlets1.

• WebSphere Studio Application Developer Integration Edition 5.1.1: añade al anterior, asistentes de generación automática de código JCA de acceso a CICS, IMS, SAP (cualquier backend para el que exista un conector JCA) y el entorno de desarrollo BPEL.

• WebSphere Studio Enterprise Edition 5.1.2: añade al anterior el desarrollo con Cobol, PL/1 y EGL.

7.1.3 Microsoft BizTalk Server 2004

Microsoft BizTalk Server 2004 proporciona capacidades para la integración de aplicaciones y funcionalidades entre las que se encuentran [37]:

• Entorno de desarrollo: totalmente basado en Visual Studio .NET

o Herramientas orientadas a roles de usuarios: motor de reglas de negocio, BAM (Business Activity Monitoring), plantillas de diseño de procesos en Visio, BAS (Business Activity Services) y para la gestión de entidades externas workflow humano.

o Administrador: consola de administración y HAT (Health Activity Tracking) depuración y monitorización de los procesos de negocio en tiempo real.

1 Portlets son componentes reusables de la Web que exhiben información pertinente para usuarios de un portal.



• Motor de reglas de negocio: creación, administración e instalación de reglas de negocio que pueden ser utilizadas por los trabajadores de la información y desarrolladores.

• BAM ('Business Activity Monitoring'): posibilidad de obtener información en tiempo real y modificar los procesos, consultas de datos agregadas, uso de datos de documentos/procesos, complemento de las soluciones de business intelligence de SQL.

• Soporte a estándares: WDSL, XML, XSD, BPEL.

• Mejoras en la escalabilidad horizontal al crear servidores sin estado: ejecución de las orquestaciones 10 veces más rápido que BizTalk 2002, soporte para mensajes de gran tamaño (se supera límite anterior de 4GB).

7.1.4 JBoss jBPM

JBoss jBPM en su versión 3.0 del 25 de junio de 2005 describe al producto como un flexible y extensible sistema de gerenciamiento de workflow. JBoss jBPM es un lenguaje para expresar gráficamente procesos de negocio en términos de tareas, estados de espera para comunicación asincrónica, etc. Su kit disponible para la descarga en http://www.jboss.com/products/jbpm/downloads, así como la documentación asociada, incluye los siguientes componentes [38]:

• jbpm-server: servidor de aplicaciones jBoss.

• jbpm-designer: plug-in de eclipse para describir procesos jBPM gráficamente.

• jbpm-bpel: una referencia para la extensión jBoss jBPM BPEL.

7.1.5 Bea WebLogic Platform ISV Edition

Este es un paquete de software fabricado por Bea Systems en el cual se incluyen distintas soluciones de la familia WebLogic [39]: servidor de aplicaciones, entorno de desarrollo Workshop Java, máquina virtual JRockit, así como versiones específicas de su software de portal e integración. Tiene soporte para procesos BPM y BPEL como estándar para el desarrollo de web services. La suite de Bea busca así simplificar para el ISV la construcción de productos para arquitecturas orientadas a servicio (SOA).

En opinión de los analistas, esta oferta de Bea Systems también responde al avance de otros paquetes servidor de la industria, como la mayor popularidad de JBoss en el ámbito open source o la competencia de WebSphere.

7.1.6 Process Modeler for Microsoft Visio™

Es un producto comercial desarrollado por Itp-Commerce [40] que permite modelar procesos de negocio siguiendo la especificación BPMN (Business Process Modeler Notation), a través de una plantilla que muestra los elementos de BPMN accesible desde Microsoft Visio (www.microsoft.com/latam/office/visio/prodinfo/default.mspx). Soporta 100% la versión 1.0 de la especificación BPMN.

Esta herramienta permite exportar los procesos hacia lenguajes de ejecución tales como BPEL y XPDL, y también permite guardar el diagrama en formato XML.

Si bien es un producto comercial se puede descargar una versión de evaluación desde www.itp-commerce.com.

7.2 Herramientas para desarrollo Observando las tecnologías actuales a considerar para el modelado y ejecución de procesos de negocio, surgen algunos puntos a resolver. En este sentido es que se buscan herramientas



que permitan por un lado, tener un panorama del desarrollo actual y por otro permitan la abstracción de algunos aspectos que no son centrales al proyecto, pero sí necesarios para la realización de la prueba de concepto.

En este documento sólo se comenta el perfil de cada una de las herramientas. La búsqueda se basó en aquellas que se pudieran descargar gratuitamente, preferentemente basadas en java y open source.

Si bien se encontraron muchos proyectos en las área de interés, pocas son las herramientas que se encuentran disponibles y maduras. Por más información consultar las referencias mencionadas.

7.2.1 MatchMaker

MatchMaker es un proyecto de Robotic Institute [41], Carnegie Mellon Univerity, USA con el objetivo de resolver el registro y descubrimiento de servicios web a través de aspectos semánticos.

La herramienta busca aprovechar la proliferación de UDDI en la infraestructura de la tecnología web services y la representación explícita de capacidades de OWL-S. Si bien argumentan que los cambios al registro UDDI y a la API UDDI resultan mínimos y que las extensiones realizadas son compatibles con la API UDDI existente, el hecho de soportar consultas semánticas requiere cambios tanto en la interfaz del registro UDDI como en la API UDDI. El registro UDDI es extendido con un componente denominado ‘capability port’ encargado de recibir y procesar consultas semánticas. Mientras tanto, la clase UDDIProxy de la API UDDI es extendida para enviar y recibir consultas semánticas.

7.2.2 Jena

Jena [42] es un marco de trabajo desarrollado en Java (y para Java), para construir aplicaciones para la web semántica. Provee un ambiente de programación para RDF, RDFS y OWL, incluyendo un motor de inferencia basado en reglas. Es un proyecto OpenSource y crece con la ayuda del programa de web semántica de “HP Labs” [28].

En resumen el framework Jena incluye: una API para RDF, lectura y escritura de documentos en formato RDF/XML, N3 y N-Triples, una API para OWL, almacenamiento persistente y en memoria, y RDQL y SPARQL como lenguajes de consulta para RDF.

7.2.3 Protègè

Protege [43] es un editor de ontologías y bases de conocimiento. Soporta DAML, RDF, RDFS, OWL y otros, permite un fácil manejo en la creación y mantenimiento de ontologías. También es una biblioteca que puede ser utilizada por otras aplicaciones para acceder y mostrar bases de conocimiento. Es un proyecto open source y está desarrollado en Java, por más información consultar las referencias.

7.2.4 Racer

RACER [44] es un motor de inferencia comúnmente llamado razonador utilizado para desarrollo de ontologías y consulta de documentos RDF. Soporta la especificación de ontologías en formatos RDFS/DAML y OWL. Puede interactuar con Protege, por más información consultar las referencias.

7.2.5 OWL-S API

La OWL-S API [45] proporciona un marco de trabajo para Java para el acceso programático a lectura, ejecución y escritura de documentos OWL-S (por más información sobre OWL-S ver sección 4.3) que mantengan descripciones semánticas de servicios. Esta API permite además leer diversas versiones de esta especificación (OWL-S



1.1, OWL-S 1.0, OWL-S 0.9, Daml-S 0,7). Esta API proporciona un motor de ejecución que puede invocar procesos atómicos que contengan un grounding de WSDL.

7.2.6 ActiveBpel

El motor ActiveBPEL [46], creado por Active Endpoints, Inc., es una implementación open source de un motor de BPEL, desarrollado en Java. El motor ActiveBPEL corre en cualquier servelt container estándar, como ser Tomcat.



8 Referencias [1] Proyecto de Grado Batuta – Generador de Aplicaciones Orquestadoras.

Glosario. Facultad de Ingeniería, Universidad de la República,

Uruguay, 2005.

http://www.fing.edu.uy/~pgsoasem/documentos/PG-P2005_0026-Glosario.pdf

[2] José David Parra. Hacia una Arquitectura Empresarial basada en Servicios. Microsoft. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.

asp (2006, Mayo, 21)

[3] Arquitectura orientada a servicios

http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios (2006,

Mayo, 21)

[4] Mark Endrel, Jenny Ang, et al. Patterns: service-Oriented Architecture

and Web Services. IBM. Abril, 2004

http://publib-

b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/sg246303.html?Open

(2006, Mayo, 21)

[5] Web Services Description Language (WSDL), Versión 1.1, W3C Note 15

March 2001.

http://www.w3.org/TR/wsdl (2006, Mayo, 21)

[6] SOAP Version 1.2 Part 1 Messaging Framework, W3C Recommendation.

Junio, 2003

http://www.w3.org/TR/soap12-part1/#intro (2006, Mayo, 21)

[7] UDDI, Introduction to UDDI, OASIS. Octubre, 2004.

http://uddi.org/pubs/uddi-tech-wp.pdf (2006, Mayo, 21)

[8] OWL Web Ontology Language, Reference. W3C Recommendation. Febrero,

2004.

http://www.w3.org/TR/2004/REC-owl-ref-20040210/ (2006, Mayo, 21)

[9] DAML+OIL Reference Description. W3C Recommendation. Diciembre, 2001.

http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218 (2006,

Mayo, 21)

[10] RDQL - A Query Language for RDF. W3C Member Submission. Enero 2004.

http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/ (2006, Mayo, 21)

[11] SPARQL Query Language for RDF. W3C Candidate Recommendation. Abril,

2006.

http://www.w3.org/TR/2006/CR-rdf-sparql-query-20060406/ (2006, Mayo,

21)

[12] OWL-S: Semantic Markup for Web Services,

http://www.daml.org/services/owl-s/1.1/overview/ (2006, Mayo, 21)

[13] Maria Jesús Lamarca Lapuente. Hipertexto: el nuevo concepto de

documento en la cultura de la imagen. Facultad de Ciencias de la

Información, Universidad Complutense de Madrid.

http://www.hipertexto.info/documentos/serv_web.htm (2006, Mayo, 21)

[14] Mª Carmen Penadés Gramaje. Una Aproximación Metodológica al Desarrollo

de Flujos de Trabajo. DSIC - Universidad Politécnica de Valencia,

Enero, 2002.

http://www.dsic.upv.es/docs/bib-dig/tesis/etd-10272003-

001444/Tesis.pdf (2006, Mayo, 21)

[15] David Hollingsworth. `The Workflow Reference Model. Workflow

Managament Coalition, Enero, 1995.

http://www.wfmc.org/standards/model.htm (2006, Mayo, 21)



[16] Workflow Management Coalition Members. Workflow Client API

Specifications (WAPI). Reporte técnico WfMC-TC-1002, WfMC, Julio,

1998.

http://www.wfmc.org/standards/docs/interface2-3.pdf (2006, Mayo, 21)

[17] Workflow Management Coalition Members. XML Process Definition

Language. Reporte técnico WFMC-TC-1025, WfMC, Junio, 2005.

http://www.wfmc.org/standards/docs/2005-06-13%20xpdl%202.zip (2006,

Mayo, 21)

[18] Workflow Management Coalition Members. Workflow Standard-

Interoperability, Abstract Specification. Reporte técnico WFMC-TC-

1012, WfMC, Diciember, 1999.

http://www.wfmc.org/ (2006, Mayo, 21)

[19] W. Aalst and A. van der and B. Hofstede and A. Kiepuszewski. Workflow

Patterns.

http://is.tm.tue.nl/research/patterns/ (2006, Mayo, 21)

[20] Workflow and BPM made practical. JBoss jBPM 3.0

http://docs.jboss.com/jbpm/v3/userguide/ (2005, Setiembre, 22)

[21] Miguel Valdés. Entrevista en javaHispano. Agosto, 2004.

http://www.javahispano.org/text.viewer.action?file=miguel_es (2005,

Abril, 14)

[22] Jaime Andrés Cubillos, et al. Composición Semántica de Servicios Web.

Grupo de Ingeniería Telemática, Universidad de Cauca Colombia.

Noviembre, 2004

www.cintel.org.co/media/temacentral_3_14.pdf (2006, Mayo, 21)

[23] Workflow Management Coalition Members. Terminology & Glossary. Reporte

técnico WFMC-TC-1011, Febrero, 1999.

http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf (2006,

Mayo, 21)

[24] Business Process Management Initiative. Business Process Modelling

Notation. BPMI.org.

http://www.bpmi.org/bpmn-spec.htm (2006, Mayo, 21)

[25] Assaf Arkin. Business Process Modelling Language 2002. OMG, Noviembre,

2002. http://www.bpmi.org/bpml-spec.htm (2005, Julio, 15)

[26] Object Management Group. http://www.omg.org (2006, Mayo, 21)

[27] Unified Modeling Language. OMG.

http://www.uml.org (2006, Mayo, 21)

[28] Lidia Fuentes, Antonio Vallecillo. Una Introducción a los Perfiles

UML. Revista Novatica – Asociación de Técnicos de Informática -

España, Marzo – Abril, 2004. http://www.ati.es/novatica/2004/168/nv168sum.html (2006, Mayo, 21)

[29] WS-BPEL Specification. IBM, Mayo, 2003.

http://www-106.ibm.com/developerworks/library/ws-bpel/ (2006, Mayo,

21)

[30] WSFL Specificacion. IBM Software Group, Mayo 2001.

http://www-3.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

(2006, Mayo, 21)

[31] Satish Thatte. XLANG Specification. Microsoft.

http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm (2006,

Mayo, 21)

[32] Keith Mantell. From UML to BPEL. IBM, Setiembre, 2003.

http://www-128.ibm.com/developerworks/webservices/library/ws-uml2bpel/

(2006, Mayo, 21)



[33] Redes de Petri. Sitio mantenido por el grupo TGI de la Universidad de

Hamburgo, Alemania.

http://www.informatik.uni-hamburg.de/TGI/PetriNets/ (2006, Mayo, 21)

[34] Aalst y Hofstede. YAWL: Yet Another Workflow Language.

http://www.yawl.fit.qut.edu.au/yawldocs/yawlrevtech.pdf (2006, Mayo,

21)

[35] Model Driven Architecture. OMG. http://www.omg.org/mda/ (2006, Mayo, 21)

[36] Rational Rose XDE Developer

http://www-306.ibm.com/software/awdtools/developer/rosexde/ (2006,

Mayo, 21)

[37] Javier Pulido. Biztalk Server 2004: la nueva era del 'e-business'.

Revista Perspectivas, Microsoft, 2004.

http://www.microsoft.com/spain/enterprise/perspectivas/numero_11/n_11_

producto.asp (2005, Abril, 11)

[38] Tom Baeyens. The State of Workflow. Jboss.

http://www.jboss.com/products/jbpm/stateofworkflow (2006, Mayo, 21)

[39] WebLogic Platform ISV

http://e-docs.bea.com/platform/docs81/isv/ (2006, Mayo, 21)

[40] Process Modeler for Microsoft Visio. Itp Commerce.

http://www.itp-commerce.com (2006, Mayo, 21)

[41] MatchMaker

http://www.daml.ri.cmu.edu/matchmaker/ (2006, Mayo, 21)

[42] Jena Framework

http://jena.sourceforge.net/index.html (2006, Mayo, 21)

[43] Protege

http://protege.stanford.edu/ (2006, Mayo, 21)

[44] Racer

http://www.sts.tu-harburg.de/~r.f.moeller/racer/ (2006, Mayo, 21)

[45] OWL-S API, Evren Sirin, MindSwap

http://www.mindswap.org/2004/owl-s/api/ (2006, Mayo, 21)

[46] ActiveBpel

http://www.activebpel.org (2006, Mayo, 21)

estado del arte - peruti.files.wordpress.com · estado del arte proyecto batuta - generador de...

Documents