Arquitectura orientada a servicios, para la colaboración de procesos interorganizacionales

Texto completo

(1)TECNOLÓGICO DE MONTERREY. Biblioteca. Cimpue Ciudad de Méi:i.;.o. INSTUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY Campus Ciudad de México Escuela de Graduados en Ingeniería y Arquitectura Maestría en Ciencias Computacionales. ARQUITECTURA ORIENTADA A SERVICIOS PARA LA COLABORACIÓN DE PROCESOS INTERORGANIZACIONALES. AUTOR: Héctor Mendoza Soriano Director de Tesis: Dr. José Martín Molina Espinosa. México D.F., Noviembre 2011.

(2) Dedicatoria. Para mi Familia.

(3) Agradecimientos. A ti que siempre estas a mi lado. 11.

(4)

(5) Resumen. El presente trabajo propone una alternativa de solución a un problema relacionado con el eBusiness. Los WFMS (Work Flow Management System), que hoy en día dan soporte a las empresas para administrar y controlar sus procesos de negocio, fueron creados para satisfacer únicamente las necesidades internas de las empresas, es decir, no están preparados para dar soporte a los procesos de negocio interorganizacionales que se dan en una organización virtual.. La propuesta consiste en llevar a cabo la construcción de una arquitectura para soportar un modelo de colaboración interorganizacional orientado a servicios, por medio del uso de un conjunto de tecnologías y estándares abiertos que hoy en día tienen amplia difusión gracias al uso de Internet. Para llevar a cabo la implementación, primero se realizó una investigación para conocer los principales enfoques que han tratado de resolver el problema de la interconexión de procesos de negocio. Se consultaron los diferentes trabajos y se seleccionó un modelo orientado a servicios el cual, desde el punto de vista del autor del presente trabajo, cubre los requerimientos que plantea la colaboración de procesos de negocio en una organización virtual.. Después de seleccionar el modelo, la siguiente tarea fue diseñ.ar una arquitectura orientada a servicios la cual proporciona el soporte y las facilidades que se requieren para permitir que los Workflows de las empresas suscritas en una organización virtual colaboren de manera dinámica, es decir, sin algún tipo de comunicación previa entre los potenciales socios de negocio.. 111.

(6) Contenido 1 Introducción ............................................................................................................................... 8. 2. 1.1. Antecedentes ....................................................................................................................... 8. 1.2. Motivación ........................................................................................................................ 11. 1.3. Relevancia ........................................................................................................................ 12. 1.4. Definición del Problema ................................................................................................... 14. 1.5. Objetivo ............................................................................................................................ 17. 1.6. Alcance ............................................................................................................................. 18. 1. 7. Estructura de la Investigación ........................................................................................... 19. Estado del Arte y de la Práctica ............................................................................................... 21 2.1. Colaboración de Procesos Interorganizacionales ............................................................. 21. 2.2. Interoperabilidad entre Workflows ................................................................................... 23. 2.3. Modelos de Colaboración Orientados a Servicios ............................................................ 29. 2.4. Análisis del Estado del Arte y de la Práctica .................................................................... 39. 3 Marco Teórico ......................................................................................................................... 44 3.1. Workflow Management Systems...................................................................................... 44. 3.2. Arquitecturas de Interoperabilidad ................................................................................... 46. 3.3. Arquitecturas Orientadas a Servicios ............................................................................... 50. 3.4. Servicios Web ................................................................................................................... 53. 3.4.1 4. WSDL ...................................................................................................................... 58. Propuesta de Solución: Análisis y Disefio ............................................................................... 64 4.1. Describir el Servicio ......................................................................................................... 67. 4.2. Publicar el Servicio ........................................................................................................... 70. 4.3. Descubrir el Servicio ........................................................................................................ 73. 4.4. Negociar Perfil y Contrato de Visibilidad ........................................................................ 74. 4.5. Envolver el Servicio ......................................................................................................... 79. 4.5.1. Definición de Servicios como Servicios Web ......................................................... 80 IV.

(7) 4.5.2. Web Services Basic Profile ..................................................................................... 81. 4.5.3. Definición del Contrato Electrónico ........................................................................ 86. 4.5.4. Generación del Contrato .......................................................................................... 92. 4.6. Desplegar el Servicio ........................................................................................................ 93. 4.6.1. Generación del Proxy .............................................................................................. 93. 4.6.2. Desplegar el Servicio ............................................................................................... 95. 4. 7 Monitorear el Servicio ...................................................................................................... 96 5 Implementación de la Arquitectura ......................................................................................... 99 5.1. Caso de Estudio ................................................................................................................. 99. 5.1.1. Descripción del Workflow ..................................................................................... 101. 5.1.2. Definición del API del proceso ............................................................................. 103. 5.2. Generación del Perfil del Servicio y Contratos de Visibilidad ....................................... 104. 5.2.1. Generación del conjunto de contratos de visibilidad ............................................. 104. 5.2.2. Definición del Perfil del Servicio .......................................................................... 108. 5.3. Envolver y Desplegar el Servicio ................................................................................... 109. 5.3.1. Definición del contrato a partir del Perfil del Servicio .......................................... 110. 5.3.2. Generación del contrato con WSDL. ..................................................................... 113. 5.3.3. Generación del Proxy ............................................................................................ 121. 5.3.4. Despliegue del servicio .......................................................................................... 123. 6 Resultados e Interpretación ................................................................................................... 124 7 Conclusiones .......................................................................................................................... 128. V.

(8) Lista de Tablas. Tabla 2.1: Modelo de Colaboración vs Implementación Workflow ............................................. 29 Tabla 4.1 Estándares relacionados con los Web Services ............................................................. 82 Tabla 4.2 Perfil del servicio vs Contrato Electrónico .................................................................... 90 Tabla 5.1 Funciones y Eventos del Workflow seleccionado ....................................................... 103 Tabla 5.2 Perfil del Servicio vs Contrato SOA Mayorista .......................................................... 110 Tabla 5.3 Perfil del servicio vs Contrato SOA Línea Aérea ....................................................... 111. vi.

(9) Lista de Figuras. Figura 2.1 Capas involucradas en la definición de Políticas de Cooperación ............................... 34 Figura 2.2 Capaz aplicativas genéricas .......................................................................................... 36 Figura 2.3 Meta modelo ................................................................................................................ 37 Figura 3.1 Vista tridimensional de un Workflow .......................................................................... 44 Figura 3.2 Modelo de referencia de la Workflow Management Coalition.................................... 46 Figura 3.3 Particiones de un Workflow ......................................................................................... 48 Figura 3.4 SOA: Roles y operaciones........................................................................................... 51 Figura 4.1 Diagrama de despliegue del sistema............................................................................ 65 Figura 4.2 Casos de uso del modelo de colaboración interorganizacional.. .................................. 66 Figura 4.3 Estructura lógica de un proceso y de un servicio ......................................................... 68 Figura 4.4 Estructura lógica de servicios atómicos y compuestos ................................................ 70 Figura 4.5 Estructura lógica de los registros de servicios............................................................. 71 Figura 4.6 Estructura lógica del contrato de visibilidad ................................................................ 75 Figura 4.7 Componentes del framework JAX-WS ........................................................................ 95 Figura 4.8 Modelo de Interacción de Servicios............................................................................. 96 Figura 5.1 Cadena de valor de la industria Turística................................................................... 100 Figura 5.2 Workflow Viaje-Avión .............................................................................................. 102 Figura 5.3 Interacción de servicios desplegados ......................................................................... 123. Vll.

(10) CAPÍTULO 1 1 Introducción 1.1. Antecedentes. Muchas organizaciones han adoptado el uso de herramientas computacionales para modelar y automatizar sus procesos de negocio, e.g., sistemas de administración de workflows, herramientas de administración de proyectos, agendas compartidas, Etc. Hoy en día, los Workflow Management Systems 1 (WFMS) son ampliamente usados por las empresas ya que. proveen una forma eficiente para modelar y ejecutar una secuencia de actividades de trabajo que soportan a los proceso de negocio. El uso de un WFMS asegura una administración de procesos estandarizada y bien estructurada dentro de las organizaciones.. Para enfrentar los nuevos y cada vez más complejos proyectos que hoy en día tienen lugar, las empresas necesitan trabajar conjuntamente entre ellas sin importar las barreras fisicas, lo que ha traído consigo el surgimiento de las Organizaciones Virtuales. Una organización virtual es una alianza temporal que engloba a un grupo de socios de negocio distribuidos en tiempo y espacio a lo largo de un medio ambiente empresarial distribuido con la fmalidad de compartir recursos y competencias para alcanzar un objetivo en común (Punia y Saxena, 2004).. 1. Para efectos del presente trabajo, wt Workflow es considerado wt flujo de trabajo. Un Workflow Management System es considerado Wl sistema que sirve para administrar flujos de trabajo.. 8.

(11) Una característica importante de las organizaciones virtuales es que tienen la habilidad de hacer y deshacer asociaciones entre varios socios de negocio de manera dinámica. Se entiende por dinámica la creación de un mercado electrónico donde participan empresas que requieren de algún servicio (consumidores) y empresas que los ofrecen (proveedores). Esta necesidad de "colaboración" entre los socios de negocio más allá de sus fronteras empresariales ha dado como resultado el surgimiento de procesos interorganizacionales.. Para ampliar el contexto de lo que significa un proceso interorganizacional, se usarán las diferentes clasificaciones que describe Van Der Aalst (1999) dentro del comercio electrónico (eCommerce). El comercio orientado al consumidor (Business-to-Commerce) comprende aplicaciones tales como compra y venta de productos, pm1ales bancarios, es decir, aquellas aplicaciones dirigidas al consumidor. El comercio orientado a los negocios (Business-toBusiness) por otro lado, comprende aplicaciones tales como distribución de productos, transferencia de fondos y pago de proveedores, procesos aduanales o facturaciones, es decir, aplicaciones donde intervienen procesos de negocio a través de la interacción de sus workflows. Este tipo de interacción da origen a los procesos interorganizacionales.. En un principio los WFMS, diseftados para soportar procesos dentro de una unidad de negocio, satisfacían las necesidades de las organizaciones. Sin embargo, con la aparición de las organizaciones virtuales ha surgido la necesidad de extender las capacidades de los WFMS para soportar los procesos interorganizacionales. En este sentido, uno de los principales problemas a resolver es el relacionado con la interoperabilidad. A este respecto, la WorkFlow Managment. 9.

(12) Coalition2 ha trabajado en la definición de estándares de interoperabilidad para poder eliminar los problemas derivados de la falta de homogeneidad que se presentan al tratar de interconectar workflows de diferentes vendedores.. Durante los últimos afios se han realizado diversas investigaciones que han dado como resultado modelos y arquitecturas para soportar procesos interorganizacionales. Entre las investigaciones más importantes que existen relacionadas con la interconexión de procesos se encuentran las siguientes: •. Comunicación de procesos basada en el intercambio de mensajes asíncronos que hacen uso de paradigmas como el de publicar y suscribir.. •. Coordinación de eventos por medio de lenguajes para la sincronización de procesos.. •. Marcos de trabajo de interoperabilidad para interfaces y estructuras de datos de procesos.. •. Control de acceso y concurrencia con espacios de datos compartidos.. •. Modelos transaccionales para la ejecución y administración de datos de los workflows.. •. Intercambio de servicio por medio de la definición de un contrato.. Hoy en día, la demanda de servicios flexibles y eficientes en el mundo de los negocio, es cada vez más urgente dentro de un mercado que se vuelve cada vez más agresivo y competitivo. Las empresas tienen que ser más dinámicas, en términos de colaboración, con sus socios de negocio incluso con sus competidores.. 2. WfMC.- Organización global fundada en 1993 formada por desarrolladores, consultores, analistas, universidades y grupos de investigación involucrados en la creación de estándares de procesos.. 10.

(13) Al comparar cada una de las investigaciones listadas anteriormente, se concluyó que el intercambio de servicios es el enfoque que soporta de mejor manera la colaboración dinámica de procesos empresariales, es decir, de los procesos interorganizacionales (Baina, Benali, & Godart, 2006). Gracias a la solidez al realizar la abstracción de los procesos a interconectar, los servicios. son los más apropiados para construir modelos de colaboración de procesos empresariales genéricos y de alto nivel independientemente de las particularidades de cada workflow. Además, gracias a que ofrece un paradigma a alto nivel, los servicios pueden ser extendidos en contraposición con el resto de los modelos y arquitecturas.. 1.2. Motivación. En una economía orientada a brindar servicios, las organizaciones públicas y privadas están optando por agrupar sus sistemas, procesos, áreas y funciones en servicios que puedan ser fácilmente utilizados por la propia organización y por otras organizaciones. Esto permite la integración y construcción de aplicaciones a partir de la conjunción de varios servicios, facilitando la interoperabilidad y la colaboración de procesos de negocio.. Hoy en día muchas empresas han cambiado sus modelos de negocio orientándolos cada vez más a servicios. Es por ello que conceptos como SOA (Service Oriented Architecture) ha tomado mucha importancia los últimos aiios debido a las ventajas que proporciona: incrementa la calidad de los servicios, es fundamentalmente autónoma, se basa en estándares abiertos, soporta la diversidad de vendedores, fomenta la interoperabilidad, promueve la federación, Etc. 11.

(14) Debido a esta tendencia en el ámbito de los negocios electrónicos y en la industria en general, surge el interés del autor para realizar este trabajo. La aplicación de los conceptos de análisis y diseño de sistemas bajo un enfoque orientado a servicios será un tema crucial en los próximos años en el contexto de las organizaciones virtuales ya que facilitará y hará más eficiente los negocios electrónicos a través de Internet.. 1.3. Relevancia. El eBusiness b·adicional, que usa Electronic Data Interchange (EDI), se mueve rápidamente a Internet. Más aún, los negocios electrónicos han cambiado de relaciones estáticas y perdurables a relaciones dinámicas y temporales. Se entiende por relación dinámica la interconexión de procesos empresariales sin tener establecida una relación comercial previa de un proceso de negocio determinado, es decir, no se ha establecido algún tipo de comunicación o contrato. Explicado en términos computacionales, una relación dinámica significa que una empresa que desea interconectar su workflow con el workflow de otra empresa, tiene que descubrir y decidir en conjunto con su contraparte un contrato de interconexión en ''tiempo de ejecución".. Al igual que la tendencia en la interacción entre socios de negocio cambia de convenios estáticos a convenios dinámicos, la tendencia en el diseño de sistemas computacionales se mueve de arquitecturas rígidas a arquitecturas flexibles. Esto se observa en muchos aspectos, desde aplicaciones a nivel sistema operativo, como es el caso del Computo Gris, hasta colecciones 12.

(15) (suites) de aplicaciones de negocios. Lo que se busca son sistemas flexibles y dinámicos que sean más simples y más baratos de configurar, mantener y cambiar. Además de esto, se busca cambiar de una integración basada en tecnologías propietarias a una integración basada en tecnologías estándares.. Otro requerimiento importante de los negocios electrónicos que debe ser considerado en el diseño de sistemas computacionales, es que los sistemas deben ser capaces de encontrar automáticamente recursos en la red en el momento y en la forma que sean necesarios sin la intervención del usuario. Esto libera a las personas de tal manera que les permite concentrarse más en sus clientes y en su negocio en lugar de ocuparse y preocuparse en la complejidad de la tecnología que usa.. Los cambios en los sistemas computacionales permitirán que las empresas se adapten mejor a las necesidades de un mercado cambiante, de tal forma que les permita colaborar para competir no a nivel de organizaciones individuales, sino entre cadenas de valor de socios de negocio. Por ejemplo, para satisfacer las exigencias de un proceso de negocio complejo, las pequeñas y medianas empresas (Pymes) pueden formar alianzas y colaborar para satisfacer un objetivo en común.. 13.

(16) 1.4. Definición del Problema. El problema relacionado con la colaboración de procesos de negocio es extenso y para su estudio se ha dividido en las siguientes categorías (Dustdar, Mehandjiev, Gall y Tata, 2005):. •. La descripción fonnal de procesos colaborativos.. •. La verificación de consistencia de procesos colaborativos.. •. La construcción de modelos y arquitecturas para procesos colaborativos.. •. La infraestructura requerida para procesos colaborativos.. A continuación se describen brevemente cada una de estas categorías:. Descripción formal: Uno de los problemas que se enfrenta, considerado como uno de los principales retos en el área de cómputo orientado a servicios, es la definición de lenguajes y modelos para la descripción de coreografias. Una coreografia define la fonna de colaboración entre los servicios que interactúan, dicho de manera más precisa, especifica un contrato que contiene una definición global de las condiciones y restricciones bajo las cuales los mensajes son intercambiados en una conversación de servicios.. Verificación de consistencia: La verificación de consistencia se basa en la premisa de propagar cierta infonnación local a los socios de negocio hasta que el objetivo que se persigue es alcanzado. Sin embargo, saber qué infonnación debe ser propagada y cómo representar esta infonnación es un problema aún sin resolver.. 14.

(17) Construcción de modelos y arquitecturas: Contar con un modelo o arquitectura flexible, eficiente y amigable para hacer posible la colaboración de servicios, se ha convertido en una necesidad apremiante a medida que el mercado exige a los socios de negocio ser más competitivos. A este respecto, una arquitectura orientada a servicios (arquitectura SOA) es un paradigma de cómputo distribuido prometedor, que ofrece soluciones extensibles, flexibles y compatibles con sistemas legados.. Infraestructura requerida para procesos colaborativos: La globalización en los negocios y la creciente colaboración entre las organizaciones, ha generado la necesidad de proporcionar una infraestructura que soporte los procesos interorganizacionales. Por ejemplo, las redes punto a punto 3 (P2P) son apropiadas para ambientes colaborativos, no obstante, las implementaciones actuales no brindan el soporte para la verificación de consistencia, la cual es requerida en modernos y complejos modelos de colaboración.. La revisión anterior ha sido con el fin de ubicar al lector sobre el problema que trata de resolver el presente trabajo, i.e., el problema relacionado con la construcción de modelos y arquitecturas que den soporte a los procesos colaborativos interorganizacionales. A partir de esto, surge la siguiente pregunta: ¿Cómo puede construirse una arquitectura que soporte un proceso de colaboración interorganizacional y que satisfaga los siguientes requerimientos?:. 3. Una red P2P (peer to peer) se refiere a una red que no tiene clientes ni servidores fijos, sino una serie de nodos que se comportan simultáneamente como clientes y como servidores de los demás nodos de la red.. 15.

(18) •. Que sea flexible.. •. Que sea dinámica.. •. Que soporte ambientes heterogéneos.. •. Que preserve la privacidad y autonomía de cada organización.. •. Que integre procesos de negocio preestablecidos.. •. Que haga uso de tecnologías estándares.. Para dar respuesta a las preguntas anteriores es necesario responder a su vez las siguientes preguntas: ¿Cómo representar los servicios que cada empresa puede ofrecer o requerir dentro de un proceso interorganizacional? ¿De qué manera se pueden mostrar esos servicios a las demás organizaciones a fin de poder identificar un posible socio con competencias (conocimiento, habilidades, experiencia, Etc.) complementarias? ¿Cómo representar un conjunto de reglas que describan los roles, responsabilidades y datos que serán intercambiados entre socios de negocio?. Existen ya algunas arquitecturas que dan respuesta a los problemas que se plantean. No obstante, estas soluciones no satisfacen por completo los requerimientos.. Por ejemplo, uno de los. problemas que se presenta con las arquitecturas actuales, e.g. aquellas que emplean CORBA4, es que el intercambio de información entre los participantes del proceso resulta demasiado. 4. Common Object Request Broker Architecture. Es un estándar que establece una platafonna de desarrollo de sistemas distribuidos que pennite la invocación de métodos remotos bajo un paradigma orientado a objetos.. 16.

(19) complejo. Otro problema es que los datos intercambiados requieren ser codificados en un formato específico lo que impacta la facilidad con la que interoperan las empresas.. 1.5. Objetivo. Construir una arquitectura aplicativa que soporte un modelo de colaboración interorganizacional orientado a servicios existente, a fm de permitir a los socios de negocio de una organización virtual colaborar a través de Internet.. Para que esta arquitectura pueda soportar el modelo debe cumplir con los siguientes requerimientos: •. Permitir la colaboración de manera dinámica. i.e., que cada socio de negocio pueda unirse o dejar la organización virtual en cualquier momento, ya que la colaboración se establece de acuerdo a las necesidades de negocio, roles y competencias de cada participante.. •. Conservar la autonomía de los workflows locales.. •. Conservar la confidencialidad de los workflows locales, i.e., reducir su visibilidad tanto como sea posible para evitar mostrar el workflow local completo.. •. Brindar flexibilidad. i.e., no debe requiere la definición de un workflow global.. •. Soportar la heterogeneidad de las organizaciones.. •. Permitir la integración de procesos de negocio preestablecidos sin necesidad de modificarlos.. •. Brindar confianza 5 entre los socios de negocio. 5. Confianza desde el punto de vista técnico.. 17.

(20) 1.6 Alcance. Las actividades a desarrollar en el presente trabajo son las siguientes:. •. La selección de un modelo de colaboración interorganizacional a partir de sus atributos y ventajas.. •. La definición de los componentes lógicos de la arquitectura propuesta.. •. La selección de los componentes de la arquitectura (tecnología, estándares y principios de diseño).. •. La combinación de los componentes de la arquitectura para llevar el perfil del servicio del modelo de colaboración a un contrato de servicios, i.e., la definición de un contrato electrónico a partir del perfil del servicio.. •. La implementación de los servicios a partir del contrato obtenido.. 18.

(21) l. 7. Estructura de la Investigación. El Capítulo 1 proporciona una introducción al trabajo de investigación, se explica la motivación personal, la relevancia del tema, se plantea el problema que se pretende resolver, el objetivo general y particular, así como las actividades que están dentro del alcance del presente trabajo.. El Capitulo 2 estado aborda el estado del arte y de la práctica con relación al tema de investigación. Se describen los diferentes enfoques que se han propuesto para resolver el problema de la interconexión de procesos de negocio, abarcando varios modelos de colaboración y arquitecturas para soportar estos modelos.. En el Capitulo 3 se incluyen conceptos y definiciones que ayudarán a tener un meJor entendimiento del tema tratado.. El Capitulo 4 describe la manera en la que se pretende resolver el problema. Para conseguir esto, el problema se divide en varios casos de uso y en cada uno de ellos se realiza el análisis de los conceptos derivados del modelo de colaboración y se realiza un disefto funcional que da como resultado la definición de los componentes de una arquitectura conceptual y una arquitectura tecnológica.. 19.

(22) El Capitulo 5 describe los pasos que se llevaron a cabo para la construcción de la arquitectura propuesta en el capitulo anterior. Se inicia con la selección de un caso de estudio y a partir de éste se desarrolla la implementación de los servicios hasta el despliegue de los mismos.. El Capitulo 6 muestra los resultados obtenidos a partir del sistema creado para demostrar la interacción de los servicios implementados en el capítulo anterior.. El Capítulo 7 finalmente describe las conclusiones a las que se llegaron incluyendo las limitaciones y las actividades pendientes que pueden ser abordadas en trabajos futuros.. 20.

(23) CAPÍTUL02 2 Estado del Arte y de la Práctica. 2.1 Colaboración de Procesos Interorganizacionales. El rápido crecimiento en la automatización de procesos de negocio ha traído consigo el desarrollo de numerosas herramientas para soportar el trabajo colaborativo y satisfacer las necesidades de las empresas: Workflows, Agendas Compartidas, Sistemas de Control de Revisión y Configuración, Etc. En este sentido, el desarrollo de nueva~ soluciones para interconectar y coordinar procesos de negocio es un tema de gran importancia, ya que las soluciones que existen son en su mayoría estáticos, dependen de lenguajes de definición y platafonnas específicas y están orientados a cubrir las necesidades internas de las empresas (Baina, Benali y Godart, 2001).. Por lo que respecta a los sistemas de administración de flujos de trabajo (Workflow Management System), en los últimos afios se han desarrollado investigaciones para tratar de mejorar el soporte para la interconexión de procesos genéricos. Dichas investigaciones han tratado de solucionar el problema relacionado con el conocimiento y la fonnalización del flujo de trabajo cuando se tratan de interconectar procesos de diferentes empresas, es decir, el conocimiento y la fonnalización del flujo de trabajo que se genera más allá de los límites de las empresas y que por lo tanto no puede ser administrado y controlado por un solo WfMS. 21.

(24) Dentro de las soluciones que se han desarrollado se encuentran aquellas que se basan en:. •. Espacios de datos compartidos.. •. Mecanismos de envío de mensajes.. •. Paradigmas de publicar y suscribir eventos.. •. Invocación remota de objetos.. •. Extensión de protocolos de transferencia.. La característica de este tipo de soluciones es que utilizan tecnologías propietarias y que por lo tanto no son estándares para todos los socios de negocio. Existen también investigaciones que han tratado de resolver el problema relacionado con el control que debe existir cuando se interconectan procesos como es el caso de los protocolos transaccionales o de los mecanismos de interacción basados en eventos.. 22.

(25) 2.2. Interoperabilidad entre Workflows. De acuerdo con Tata y Chebbi (2004), cuando se trata de interconectar procesos de negocio de diferentes empresas, la interoperabilidad entre sus Wt:M:S (Work:flow Management Systems) es la clave para soportar procesos interorganizacionales. Para efectos de este trabajo, por interoperabilidad se entiende como la habilidad que tienen dos o más sistemas computacionales para intercambiar información.. Varios grupos de trabajo han propuesto diferentes soluciones al problema de la interoperabilidad, uno de estos grupos es la Wt:M:C (Workflow Management Coalition. La Wt:M:C es una organización encargada de estandarizar todo lo relacionado (:n el campo de los Workflow. Esta organización ha definido cinco interfaces funcionales que todo WFMS debe tener.. De las cinco interfaces, dos están relacionadas directamente con el tema de la interoperabilidad:. La interfaz uno incluye un modelo común para la definición del proceso llamado XPDL {XML Process Definition Language) el cual utiliza XML (eXtensible Markup Language) para el intercambio de información entre procesos (Toe Workflow Management Coalition, 2008).. En el caso de la interfaz cuatro, la Wt:M:C(Workflow Management Coalition) ha definido WAPI4 (Workflow Application Programming Interface) con el fin de soportar la interoperabilidad entre 23.

(26) Workflows. En este contexto, la WFMC propuso el Wf-XML (Workflow eXtensible Markup Language) como un protocolo de interoperabilidad basado en XML.. Paralelamente, el OMG (Object Management Group) ha definido el protocolo jFlow el cual toma en cuenta los requerimientos de interoperabilidad entre diferentes implementaciones de Workflows en w1 ambiente distribuido orientado a objetos. Otro grupo de investigación integrado por Hewlett Packard, Netscape y SUN, ha propuesto SWAP (Simple Access Protocol) como. wia. solución para soportar la interoperabilidad entre servidores que ejecutan Workflows, el cual utiliza a su vez el protocolo HTIP (Hypertext Transfer Protocol) y XML (eXtensible Markup Language) para el intercambio de datos.. Existen otras soluciones que tratan de resolver el problema de la interoperabilidad entre Workflows como la composición/orquestación 6 de Web Se,rvices que emplean diferentes lenguajes como XLANG y WSFL (Web Services Flow Language) de IBM, WSCI (Web Services Choreography Interface) de SUN, BPEIAWS (Business Process Execution Language for Web Services) de IBM, Microsoft y BEA.. Salah, Mahmoud y Nacer (2005), definen tres niveles de interoperabilidad los cuales deben ser atendidos para hacer posible la colaboración entre diferentes modelos de Workflows:. 6. Una orquestación especifica un proceso ejecutable que implica el intercambio de mensajes con otros sistemas, de tal manera quelas secuencias de intercambio de mensajes son controlados por el diseñador de orquestaciones.. 24.

(27) •. Interoperabilidad Sintáctica: se relaciona con la diversidad de formalismos que existen para describir los aspectos del workflow. La elección de un formalismo en comparación con otro puede tener un gran impacto en la compresión del modelo.. •. Interoperabilidad Semántica: tiene que ver con los diferentes conceptos que cada modelo de workflow ofrece para administrar los aspectos del proceso para el cual ha sido diseftado.. •. Interoperabilidad de Control: tiene que ver con la. ejecución del workflow que es distribuido en varias partes que funcionan de mar1era autónoma y sobre diferentes plataformas.. Salah et al. (2005) mencionan que, no obstante que algunos enfoques resuelven el problema de la interoperabilidad a nivel sintáctico, no existe una semántica para las entidades y conceptos que son manipulados durante la colaboración de los procesos de negocio, es decir, existe la necesidad de una interoperabilidad semántica la cual asegure que el consumidor y el proveedor tienen un entendimiento común del significado de los servicios y datos intercambiados. Debido a que cada workflow es autónomo, es decir, cuenta con su propio meta-modelo, su propio lenguaje de modelado y su propio motor de ejecución, la manera en la que pueden ser integrados es registrando sus modelos (interfaces) en un modelo común. Es por ello que proponen una arquitectura basada en un meta-modelo obtenido a partir de la comparación de los diferentes formalismos (lenguajes) que existen en el campo de los workflows.. 25.

(28) Por lo tanto, este meta-modelo contiene los elementos que son comunes a todos los modelos de workflows (actividades y artefactos) y deja de lado aspectos como los recursos y su asignación, la comunicación entre los actores, Etc. Este modelo de datos común está representado por una base de datos que comparten todos los workflows.. Para resolver el problema de la interoperabilidad de control, Salah et al. (2005) proponen el uso del paradigma publicar y suscribir, ya que desde su punto de vista es el más apropiado como mecanismo de interacción, ya que por un lado este paradigma permite el envío de notificaciones de ciertos eventos (publicar) sin la necesidad de especificar algún receptor; por otro lado, permite recibir notificaciones de los eventos suscritos, es decir, de aquellos eventos que son del interés del receptor. Posteriormente y en respuesta a estos eventos, el receptor tomará una o varias acciones, donde cada acción corresponde a la ejecución de un método.. Para la administración de los eventos, Salab et al. (2005) emplean un manejador de eventos local, un manejador de eventos global y un servidor de conexiones. El manejador de eventos local es el encargado de recibir la lista de eventos y parámetros que el workflow desea notificar a los demás workflows. También es el encargado de notificar esa lista al s,ervidor de conexiones. El servidor de conexiones es el encargado de registrar las notificaciones que envían los workflows. Finalmente el manejador de eventos global es el encargado de propagar los eventos a cada uno de los workflows que se encuentran suscritos en el servidor de conexiones.. Salah et al. (2005) emplean CORBA como plataforma de interoperabilidad para la implementación de la arquitectura que propone. De esta manera, los workflows pueden. 26.

(29) interactuar gracias a los servicios que brinda el ORB (Object Request Broquer), el cual permite enviar y recibir solicitudes y respuestas de manera transparente entre los workflow (clientes) y el manejador de eventos global/ servidor de conexiones (servidor).. Además de usar CORBA para resolver el problema de la interoperabilidad de control, se usa para resolver el problema de la interoperabilidad sintáctica, ya que es a través del IDL (Interface Description Language) como se describen los elementos del modelo común y el modelo de datos de los workflows en ténninos de atributos y métodos. La idea subyacente en el enfoque de Salah. et al. (2005), es la de construir un workflow global, i.e., un workflow que involucre a varias organizaciones.. Por su parte, Punia y Saxena (2004) utilizan un enfoque público-privado, en el cual dos o más organizaciones se unen para crear un nuevo proceso para ser integrado con sus procesos existentes. Este nuevo proceso es común a todos los socios y tiene una interfaz con cada uno de los procesos privados de cada empresa. Los procesos privados son internos y únicos para cada organización y son manejados independientemente mientras q¡ue el proceso público es común y estándar para todos.. Punía y Saxena (2004) describen diferentes modelos que las organizaciones virtuales pueden adoptar para colaborar entre si:. 27.

(30) •. Modelo de colaboración jerárquico, en el cual una organización inicia el proceso y decide la manera en la que el resto de los workflows llevarán a cabo el flujo de trabajo. A su vez, esta categoría se puede dividir en las siguientes subcategorizas:. •. o. Centralizado. o. Participativo. o. Descentralizado.. Modelo de colaboración de mercado, en el cual la organización que inicia el flujo de trabajo puede seleccionar un proveedor de servicio.. •. Modelo de colaboración Ad-hoc, en el cual no hay un patrón predefinido y el flujo se lleva a cabo a voluntad de la organización en un momento determinado.. Punia y Saxena (2004) describen también diferentes formas en las que una organización virtual puede implementar un Workflow Interorganizacional. Esta implementación dependerá de la combinación de actividades y tareas que conformarán el flujo de trabajo.. •. Integración de subprocesos: este tipo de implementación requiere que cada una de las organizaciones involucradas liguen sus subprocesos internos creando un nuevo proceso que se extiende a todas las organizaciones.. •. Proceso público: este tipo de implementación requiere que cada organización ligue sus subprocesos internos a un proceso público y común a todas las organizaciones.. •. eMarketplace: se establece un mercado de servicios, donde las organizaciones que quieren hacer uso de un servicio realizan ofertas y las organizaciones que desean vender algún servicio responden a las ofertas que pueden satisfacer.. 28.

(31) Punia y Saxena (2004) proponen un método que busca ayudar a las organizaciones virtuales a seleccionar la forma en la que pueden implementar su Workflow interorganizacional. Esta selección depende del modelo de colaboración elegido y de las necesidades de cada participante. La Tabla 2.1 indica cuales es el tipo de implementación más recomendado.. Tabla 2.1: Modelo de Colaboración vs Implementación Workflow. (Punia y Saxena, 2004) Modelo. Centralizado. Tipo de implementación del Workflow Integrado. Público. ~. ~. Participativo. ...J. Descentralizado. ...J. eMarketplace. Mercado. ...J. Ad-hoc. 2.3. Modelos de Colaboración Orientados a Servicios. El intercambio de servicios es un paradigma de colaboración a alto nivel basado en paradigmas de colaboración desarrollados previamente, e.g., producción (dataspace sharing), comunicación (formato de mensaje común, invocación de métodos remotos, mensajes de notificación, conocimiento de grupos) y coordinación (sincronización, verificación de coherencia).. 29.

(32) Uno de los objetivos de los modelos de interacción de servicios es permitir la colaboración de los procesos a través de una vista parcial de sus recursos permitiendo de esta manera el acceso a un conjunto de métodos y eventos propios del proceso.. Un enfoque que trata de resolver el problema de colaboración entre workflows fue propuesto en la arquitectura CrossFlow (Hoffner, Ludwing, Grefen y Aberer, 2000). CrossFlow fue un proyecto de investigación europeo cuyo propósito consistió en extender las capacidades de los Workflows Management Systems para dar soporte a la administración de Workflows dentro de las organizaciones virtuales establecidas dinámicamente. El objetivo era contar con un sistema basado en el paradigma proveedor-consumidor (outsourcing) que permitiera especificar, construir y ejecutar flujos de trabajo más allá de los límites de una organización.. La idea principal de la arquitectura Crossflow es combinar la manera estándar de describir servicios y contratos con las tecnologías matchmaking para crear un mercado virtual para proveer y consumir servicios. Bajo este contexto, varios proveedores pueden anunciar sus servicios en el mercado mientras los consumidores pueden buscar un proveedor de servicios compatible acorde a sus requerimientos, todo esto especificado a través de un contrato.. El contrato electrónico, el cual es el resultado de los acuerdos entre los socios de negocio, especifica completamente la cooperación que tendrá efecto entre los socios. Dicho de otra manera, provee una vista común de los servicios que serán proporcionados, incluyendo el monitoreo y puntos de control. Posteriormente, las especificaciones realizadas en el contrato son 30.

(33) usadas para configurar dinámica y automáticamente la infraestructura necesaria, tanto del proveedor como del consumidor para la entrega o ejecución del servicio. La arquitectura CrossFlow proporciona una solución end-to-end, incluyendo toda la funcionalidad desde el establecimiento del contrato hasta la ejecución de los servicios.. El ciclo de vida. de un Crossflow pasa por las siguientes fases:. 1. La creación del contrato específico que define la relación de negocio entre los socios. 2. La creación de la infraestructura dinámica para la entrega del servicio y la liga de los componentes de cada organización 3. La entrega del servicio incluyendo el monitoreo y control interorganizacional.. En la Fase 1 el sistema Crossflow actúa como una plataforma de comercio electrónico cuyo propósito es establecer una relación contractual entre dos o más socios de negocio. La fase 2 proporciona la transición entre la definición del contrato y la fase de ejecución. En la fase 3 el sistema Crossflow actúa como un avanzado WfMS.. Un enfoque más ha sido abordado en el proyecto BPEL (Business Process Execution Language) el cual proporciona una notación en XML (eXtensible Markup Language) para especificar el comportamiento de los procesos de negocio basado en servicio:; web (Alvex et al. 2007). BPEL define un modelo y una gramática para describir el comportamiento de un proceso de negocio con base en las interacciones entre el proceso y sus socios. También define la lógica necesaria. 31.

(34) para que los diferentes servicios que interactúan en el proceso puedan trabajar de manera coordinada para alcanzar un objetivo en común.. La motivación de los autores de BPEL para desarrollar este ,::stándar de orquestación para web services, fue la necesidad de solucionar el problema que enfrenta la integración de procesos de negocio, ya que desde su punto de vista, para modelar un proceso de negocio es necesario satisfacer requisitos como portabilidad, interoperabilidad, flexibilidad, composición de procesos a partir de servicios existentes, proporcionar diferentes vistas del proceso a diferentes partes, soportar múltiples conversaciones statefull y contemplar mecanismos de compensación para el manejo de errores.. La interacción con cada socio se da a través de interfaces y la estructura que encapsula esta relación es llamada "partnerLink". Una relación entre un proceso y un socio de negocio es típicamente peer-to-peer, donde el socio de negocio puede representar un consumidor o un proveedor de un servicio para el proceso, es decir, pueden existir varios roles. La noción de "partnerLink" es usada para modelar la conversación peer-to-peer entre el proceso y los socios y a su vez, define la forma de esa relación por medio de un "portType".. Klai y Tata (2005) proponen un modelo de colaboración inspirado en SOA (Arquitectura Orientada a Servicios), que consiste básicamente en tres pasos: a) workflow advertisement, b). workflow interconnection y e) workflow cooperation. Este enfoque surge a partir de la idea de construir un workflow interorganizacional a partir de la colaboración de varias organizaciones que cuentan con workflows preestablecidos. Su investigación se basa en la descripción de las 32.

(35) actividades que interactúan con actividades externas al proceso de negocio, dicho de otra manera, la descripción de lo que ellos llaman las "interfaces" de cada worktlow. Un worktlow puede tener más de una interfaz y cada una soporta la interacción con un socio de negocio diferente.. A continuación se describe brevemente cada uno de estos paso:,.. a) Wor/efl,ow Advertisement.-. Para construir el workflow interorganizacional, cada. organización debe anunciar, dentro de un registro común, la descripción de las actividades ofrecidas, así como la descripción de las actividades requeridas por cada uno de los worktlows. Para preservar la privacidad de cada organización, sólo se muestra parte del worktlow de una organización a sus socios de negocio estableciendo varios niveles de visibilidad. El objetivo es describir la colaboración de los procesos de negocio, es decir, la interacción de actividades entre los worktlows participantes sin especificar la estructura interna de cada uno de ellos. b) Wor/efl,ow Interconnection.- Para la interconexión de los worktlows, cada organización identificará a su potencial socio usando un mecanismo de correspondencia (matching). c) Wor/efl,ow Cooperation.- Este mecanismo se basa en lo que se denomina "Políticas de cooperación" 7 las cuales constituyen un conjunto de co111tratos que se defmen a partir de dos aspectos: A partir de la manera en la que se comparten los datos A partir de la manera en la que se sincronizan las actividades. 7. Cooperación entre empresas significa interconectar y coordinar sus procesos de negocio.. 33.

(36) Estas políticas de cooperación describen un conjunto de escenarios de interacción a diferencia de los acercamientos clásicos que definen un workflow para especificar las interacciones entre los procesos de negocio.. ¿Por qué políticas de cooperación? Tata y Klai (2005) mencionan que la interacción entre los procesos de negocio en una organización virtual no pueden ser especificadas "in advance" y por la ausencia a priori de control de punta a punta del proceso de negocio. Por tal motivo, la definición de políticas de cooperación se realiza en función de lo siguiente:. Políticas de Cooperación Vista Pública (Actividades Virtuales) Workflow Cooperativo (Actividades Cooperativas) Workflow Interno (Actividades Reales). Figura 2.1 Capas involucradas en la definición de Políticas de Cooperación.. •. Políticas de Cooperación: Se definen a partir de vistas públicas, i.e., a partir de un wrapper, un proxy, un. adapter o un process service.. •. Vista Pública: Está compuesta por un conjunto de actividades virtuales y el flujo de control entre éstas.. •. Workflow Cooperativo: Está compuesto de actividades cooperativas que están conectadas a una o varias actividades reales, lo que permite establecer el :nivel de visibilidad que se desea exponer.. 34.

(37) •. Workflow Interno: Está compuesto de las actividades reales que ejecutan las tareas del proceso de negocio.. El proceso que describe Tata y Klai (2005) para establecer políticas de cooperación incluye las siguientes actividades:. 1. Establecer un contrato de acceso sobre los datos compartidos en la vista pública. 2. Establecer un contrato de flujo de datos. 3. Definir la vista pública. 4. Definir las políticas de cooperación.. Formalmente, este modelo se representa de la siguiente forma:. M = (PS, D, CL) Donde: PS es el conjunto de servicios D es el conjunto de documentos compartidos y CL es el conjunto de contratos de cooperación. Baina, Tata y Benali (2003) proponen un modelo inspirado también en SOA para la interconexión dinámica de procesos de negocio. Por interconexión dinámica se entiende que varios workflows heterogéneos de diferentes organizaciones coexisten sin ningún conocimiento previo entre los socios de negocio. Una organización que quiera interconectar su workflow de 35.

(38) manera dinámica con el workflow de otra organización, tendrá que descubrir y decidir conjuntamente un contrato de interconexión en tiempo de ejecución. Este modelo enriquece el paradigma clásico de SOA (publicar, buscar y conectar) al agregar una etapa de negociación con la cual el paradigma se extiende a publicar, buscar, negociar y conectar.. Baina et al. (2003) mencionan que este modelo permite a las empresas estructurar, clasificar y comparar servicios con el objetivo de seleccionar dinámicamente algún proveedor de entre aquellos que ofrecen servicios similares al requerido. Una vez identificado y seleccionado al proveedor, la colaboración de sus procesos de negocio se consigue por medio de un mecanismo que consiste en envolver los servicios (wrapping) para ejecutarlos posteriormente.. El modelo contiene los siguientes elementos: un meta modelo, un conjunto de estructuras y un mecanismo de interconexión dinámico. El meta modelo considera tres niveles de abstracción y por lo tanto está estructurado en tres capas (Figura 2.2).. Process service (WSDL, IDL, Etc.) Workflow process application (WFMS specific) Process skeleton (BPEL, Java, C#, etc.). Figura 2.2 Capaz aplicativas genéricas. (Baina et al, 2006).. 36.

(39) El meta modelo (Figura 2.3) permite la creación de un proceso interorganizacional, el cual representa un "Workflow de Workflows" cuya administración está distribuida entre todas las empresas que forman la organización virtual.. Le l ' n K l l ! S D ~. [¡WfMS. ". ". 1. adminilba. 1..n. e¡...,._. j. »Hn. es l a ~ rBUbclo de. C.l'nlcll!SD. 1. 1. 2..n. 1. delega su .,;ecuci6n •. r. ". tt. 'f. e¡ Pruce._l'nlveido. [:_Empresa. C.ktlwldad. esla compuesto de. ~r ~por. 1..n. 1. C. P r , x e m _ ~ es llevada a cabo por. 11. 1. 1. 1. [¡Espado. 0..1. 0..1.. e¡ Senrim_~. es intffl:onédado a. 1. -. ,.. C. SenlldoJ'ronWD. ". 'v". ~. ,. 0..1. c. Espado_requerillo. e¡ Espado_~. ,.. ,.. D..n. ~e.Servido. ~. /'_. congrega. " Figura 2.3 Meta modelo (Baina et al., 2006). Por lo que respecta a las estructuras, el modelo considera a los procesos como servicios 8 los cuales pueden ser modelados como objetos y por lo tanto poseen una categoría, un perfil 9,. 8. Un servicio es visto como una entidad de software que abstrae la funcionalidad y semántica de un proceso específico. Posee una categoría, un perfil y un contrato de visibilidad. 9. Un perfil representa la abstracción funcional de un proceso, i,e., describe su estructura. De esta manera es posible la clasificación, indexación, comparación y búsqueda de procesos-servicios.. 37.

(40) además de toda la funcionalidad conocida (herencia, sobrecarga, etc.). Estos servicios poseen también un API y derechos de acceso sobre esta API (contrato de visibilidad).. La parte dinámica del modelo de Baina et al. (2001 ), comprende las siguientes etapas:. Publicación del servicio.- Tiene que ver con la comunicación de la descripción del proceso de negocio a otras empresas. Para ello, los servicios de cada empresa son publicados en repositorios llamados "services spaces". Cada empresa suscrita posee vistas de los services spaces de otras empresas y cada vista es actualizada después de cada evento de publicación.. Localización del serv1c10.- Consiste en aplicar algoritmos. que permiten la evaluación y comparación de servicios. El descubrimiento es simétrico, esto significa que tanto el servicio "requester" como el "provider" pueden descubrir servicios.. Negociación del servicio.- Permite decidir dinámicamente y adaptar todos los parámetros de interconexión de los servicios a ser interconectados (perfil, contrato de visibilidad, accesibilidad del grafo del proceso, etc.). Para llevar a cabo la negociación se utiliza un método genérico (Munier, Baina y Benali, 2000) que consiste en utilizar agentes inteligentes. Durante este proceso de negociación se construye un conjunto de posibles solucione:s (Contrato de Interconexión). Al final, el servidor lleva a cabo alguna acción con base en la solución selecciona por el cliente (Contrato de Visibilidad).. 38.

(41) El contrato de interconexión representa una de las alternativas del conjunto de contratos de visibilidad que el proveedor del servicio puede proporcionar al consumidor. El conjunto de contratos de interconexión puede ser aplicado como una táctica para asegurar la convergencia en la negociación de los contratos de visibilidad. De esta manera, durante la etapa de negociación el proveedor de servicio puede proponer al consumidor un determinado contrato de interconexión. Si el consumidor rechaza este contrato, el proveedor puede seleccionar el siguiente contrato de interconexión.. El contrato de visibilidad obtenido representa un subconjunto dd API (Application Proe;ramming Interface) general del proceso. Cada elemento de este contrato de visibilidad representa una restricción o un derecho de acceso a los métodos o eventos del API del proceso.. Interconexión del servicio.-Para realizar este paso, se utiliza un modelo de interconexión de procesos a partir de la interacción de servicios (Baina, Benali y Godart, 2001 ).. 2.4 Análisis del Estado del Arte y de la Práctica. Se ha revisado la forma en la que cada autor ha tratado de dar respuesta a los requerimientos que plantea la colaboración de procesos de negocio dentro de una organización virtual. Toca ahora discutir porqué algunas alternativas son más apropiadas, desde el punto de vista del autor del. 39.

(42) presente trabajo, para resolver el problema que se plantea al inicio de este trabajo de investigación.. La primera clasificación que podemos hacer de los trabajos revisados es la siguiente: aquellos que proponen modelos de colaboración estáticos y aquellos que plantean modelos de colaboración dinámicos. Como se mencionó anteriormente, por dinámico se entiende la colaboración de empresas dentro de una organización virtual, es decir, la interconexión de workflows heterogéneos sin haber establecido previamente algún tipo de comunicación.. Las premisas de los trabajos que proponen un modelo de colaboración estático son las siguientes:. lnteroperabilidad semántica, es decir, lograr que todos los workflows que participan en la organización virtual compartan un modelo común, para ello proponen arquitecturas basadas en un meta-modelo. El hecho de que todos los workflows compartan un meta-modelo, materializado a través de una base de datos, es bastante complicado si pensamos que los participantes se encuentran distribuidos en tiempo y espacio, lo que conlleva a problemas de disponibilidad, desempeflo y seguridad.. Interoperabilidad sintáctica y de control, es decir, que todos los workflows que participan en la organización virtual logren interconectarse, para lo cual proponen arquitecturas distribuidas y paradigmas ba-,ados en eventos. Algunas de las tecnologías usadas para la implementación de estas arquitecturas son propietarias y no son ampliamente utilizadas por la mayoría de las organizaciones 40.

(43) En el caso de los trabajos que proponen un modelo de colaboración dinámico se siguen las pre1D1sas:. lnteroperabilidad semántica, no es necesario un modelo común, ya que el concepto principal es el de proveer y consumir servicios. Aquí lo que se busca es la creación de contratos para definir la manera en la que interactúan los servicios (roles y responsabilidades) y el nivel de visibilidad que se requiere, es decir, que parte del workflow será mostrado a los participantes.. lnteroperabilidad sintáctica y de control, la premisa es la creación dinámica de la infraestructura para el despliegue de los servicios a través del uso de arquitecturas orientadas a servicios y tecnologías abiertas y de amplia difusión.. Con relación a este último punto, se proponen dos tipos de modelos de colaboración de procesos a través de la interacción de servicios.. En el primer caso, Chebbi et al. (2005), Tata (2002), Tata y Chebbi (2004) y Tata y Klai (2005) elaboran un modelo de colaboración que describe las interfac1~s de cada workflow participante y la interacción de estas interfaces dando como resultado un workflow interorganizacional. Por medio de estas descripciones es como se consigue la publicación y la interconexión. Para describir los roles y responsabilidades de los participantes y los niveles de visibilidad de cada uno de ellos, se propone el uso de políticas de cooperación (conjunto de contratos). Estas políticas de cooperación representan un conjunto de escenarios de interacción, los cuales se basan en un modelo transaccional. 41.

(44) En el segundo caso, Munier et al. (2000), Baina, Benali y Godart (2001), Baina, Tata y Benali (2003), y Baina, Benali y Godart (2006) proponen un modelo para la interconexión de servicios basado en los métodos y los eventos de las instancias de:l proceso. Mezcla el modelo de subprocesos anidados de la WfMC con la interconexión basada en outsoursing. De esta manera, el modelo de subprocesos anidados es enriquecido con descubrimiento, negociación y envolvimiento dando como resultado un contrato de visibilidad. Para implementar este modelo se emplea una tecnología llamada CORBA (Common Object Request Broker Architecture) que hace posible la construcción de sistemas distribuidos.. De todos las enfoques que los autores han empleado para resolver el problema, el enfoque orientada a servicios es el más genérico, ya que permite hacer una abstracción funcional de un proceso (o parte de un proceso) de una organización. Dicho de otra manera, permite mostrar particularidades de un proceso sin revelar por completo su estructura completa, cumpliendo de esta manera con el requerimiento de confidencialidad.. Como hemos visto, el objetivo que persiguen los trabajos es hacer posible la interoperabilidad entre los workflows, desde el punto de vista semántico, sintáctico y de control.. Los modelos estáticos se basan en modelos de interoperabilidad que requiere un control centralizado del workflow (Capacity Sharing), o requieren la partición del workflow donde cada partición es ejecutada secuencialmente (chained execution) o en paralelo (Loosely coupled) por. 42.

(45) algún socio de negocio o requieren que la descripción del workflow sea replicada a todos los socios de negocio (case transfer).. ¿Qué es posible resolver con servicios web? La clave en la selección del modelo de Baina, Benali y Godart (2001) es que su modelo se basa en la subcontratación de subprocesos, es decir, un socio de negocio subcontrata a otros socios de negocio para llevar a cabo parte de su proceso de negocio. De esta manera, el control es distribuido entre los socios de negocio participantes. Esta forma de interoperabilidad es la arquitectura subyacente de los servicios web, por esta razón, es factible implementar el modelo orientado a servicios de Baina et al. (2001) utilizando tecnologías asociadas a los web services.. Como se verá más adelante, el uso de los web services permite resolver el problema de la interoperabilidad a nivel sintáctico y de control, que es uno de los problemas que se propone resolver en este trabajo, el problema de la interoperabilidad semántica lo resuelve el modelo de Baina et al. (2001 ).. 43.

(46) CAPÍTUL03 3 Marco Teórico 3.1 Workflow Management Systems. La Figura 3 .1 muestra las tres dimensiones que tiene un workflow: ( 1) la dimensión instancia (case), (2) la dimensión proceso y (3) la dimensión recursos.. Dimensión Recurso. Recurso. .1-------~. actividad = caso + tarea + recurso. Tarea ¡___,_____J___. Dimensión Proceso. Dimensión caso. Figura 3.1 Vista tridimensional de un Work:flow (Van Der Aalst, 1999). La dimensión instancia significa que todas las instancias son manejadas individualmente. Desde el punto de vista del work:flow, las instancias no tienen influencia una sobre otra. En la dimensión 44.

(47) proceso, se especifican las tareas y el flujo a lo largo de estas tareas. En la dimensión recursos, los recursos son agrupados en roles y unidades organizacionales.. Podemos decir que los puntos que se muestran en la vista de tres dimensiones constituyen un workflow, donde cada punto representa o bien un work ítem (instancia+ tarea) o una actividad (instancia+ tarea+ recursos).. Se puede decir también, que la administración de un workflow es el pegamento entre las instancias, las tareas y la organización. Por lo tanto, un wo:rkflow management system es un sistema capaz de manejar grandes volúmenes de instancias de acuerdo a un flujo de trabajo predefinido de algún proceso.. Muchos usuarios y vendedores de estos sistemas, se han unido a la WfMC para identificar características comunes de estas herramientas, estandarizar terminología, así como para definir interfaces y arquitecturas estándar.. Uno de los primeros resultados de la WfMC fue el. establecimiento de un modelo de referencia.. 45.

(48) Herramientas de Definición de Procesos. Interfaz 1 API del Workflow. Interfaz 5. Interfaz 4. Servicio de Promulgación de Workflow. Herramientas de Administración y Monitoreo. Otros Servicios de Promulgación. Motor de Ejecución. 1-----. L __ _ __ _ J . . _ _. Interfaz 2. Interfaz 3 Aplicaciones Cliente del Workflow. Aplicaciones Invocadas. Figura 3.2 Modelo de referencia de la Workflow Management Coalition. 3.2 Arquitecturas de Interoperabilidad A continuación se exploran, desde el punto de vista conceptuall, las arquitecturas que pueden soportar la interoperabilidad de Workflows Interorganizacionales (Van Der Aalst, 1999).. l. Distribución de Capacidad (Capacity Sharing) Partición Vertical 2. Ejecución Encadenada (Chained Execution) Partición Vertical/Horizontal 3. Subcontratación (Subcontracting) Partición Horizontal 4. Transferencia de Instancias del Proceso (Case Transfer) Partición Vertical 5. Transferencia de Instancias del Proceso Extendida (Extended Case Transfer) Partición Vertical 6. Acoplado débilmente (Loosely Coupled) HP. 46.

(49) La única forma de interoperabilidad en la que no se necesita partir el workflow es la Distribución de Capacidad. Las otras cinco formas parten el workflow de alguna manera.. Básicamente existen dos dimensiones de partición: Vertical y Horizontal. En la partición vertical las instancias del proceso son distribuidas entre varios socios de negocio pero el proceso no es dividido en partes. En la partición horizontal el proceso es dividido en partes sin distribuir las instancias del proceso a los socio de negocio, incluso varios socios de negocio pueden estar trabajando sobre la misma instancia al mismo tiempo.. Entre las ventajas de la participación vertical podemos mencionar que en cualquier momento la instancia completa del proceso reside en un mismo lugar, evitando de esta manera los problemas de concurrencia. Otra ventaja es que la interacción entre los servicios entregados por cada socio de negocio es simple, el único mecanismo que se requiere es un swap-in/swap-out.. Entre las desventajas se puede mencionar que la misma descripción del proceso tiene que ser distribuida entre todos los socios de negocio involucrados. El grado de paralelismo es reducido debido a que una misma instancia no puede ser procesada por dos organizaciones al mismo tiempo.. La partición horizontal permite el procesamiento en paralelo de una instancia por múltiples organizaciones al mismo tiempo. Sin embargo, el costo para coordinar una partición horizontal es alto, ya que se necesita mantener relaciones causales entre las tareas de las diferentes. 47.

(50) organizaciones, es más dificil de manejar las excepciones y pueden ocurrir todo tipo de problemas de concurrencia.. Arquitectura de transferencia extendida, particiona el workflow en la dimensión vertical (caso). = Arquitectura débilmente acoplada, particiona el workflow en la dimensión horizontal (proceso). Figura 3.3 Particiones de un Workflow (Van Der Aalst, 1999). ¿Qué formas de interoperabilidad son útiles para el eBusiness?. La distribución de capacidad asume que hay un WFMS centralizado, por lo tanto, no es. apropiado para el eBusiness ya que el control no se distribuye entre los diferentes socios de negocio.. La ejecución encadena sólo es útil en aplicaciones donde el proceso está compuesto de partes. ordenadas secuencialmente, siendo ejecutada cada parte por un socio de negocio diferente. Sin embargo, en las aplicaciones eBusiness las interacciones entre los socios de negocio son mucho más complejas. 48.

(51) Aún cuando la subcontratación es útil en el contexto del eBusiness, sólo puede ser aplicada en un medio ambiente con una clara estructura jerárquica ,~ntre los socios de negocio. La arquitectura es bastante convencional, ya que para el socio de negocio situado en el nivel más alto, el proceso subcontratado puede ser visto como una tarea normal.. Si se emplea la Transferencia de Instancias del Proceso Extendida, todos los socios de negocio comparten un proceso común pero las instancias son dirigidas de un socio a otro. Una política de transferencia es empleada para determinar cuándo transferir las instancias de un socio a otro.. En un entorno acoplado débilmente, cada socio de negocio tiene un workflow privado el cual es conectado al workflow de otro socio. El mecanismo de comunicación usado para interactuar es un mecanismo asíncrono. Los workflows acoplados débilmente operan esencialmente independientes, pero deben sincronizarse en cierto punto para asegurar la correcta ejecución de todo el proceso interorganizacional.. 49.

(52) 3.3. Arquitecturas Orientadas a Servicios. En una Arquitectura Orientada a Servicios todos los componentes de software son modelados como servicios. La premisa de la arquitectura es que todas las tareas o procesos de negocio que se pretende automatizar, son disefiados como servicios para ser consumidos en una red.. En SOA el disefio se enfoca en la interfaz de los servicios ya que el diseñ.ador no construye un programa, i.e., una unidad funcional para un propósito solamente. En lugar de eso el diseñ.ador construye un servicio que tiene una interfaz bien definida y que potencialmente puede ser usada en múltiples contextos de negocio. Esto da como resultado el poder construir aplicaciones débilmente acopladas, ya que son integradas a nivel de interfaz y no a nivel de implementación. Esto permite mayor flexibilidad porque las aplicaciones son construidas para trabajar con cualquier implementación de la interfaz y no para tomar ventaja de alguna característica o implementación en particular.. La Figura 3.4 muestra los principales roles en una arquitectura SOA: un solicitante del servicio,. un proveedor del servicio y un registrador del servicio. Toda arquitectura SOA también incluye tres operaciones: publicar, localizar y conectar. A continuación se da una breve explicación de cada uno de los roles y operaciones.. 50.

(53) Serv1ce. ----........J Descrlption Service Registry. WSDl + UDDf. Publlsh. Servíce. Description Blnd Service Reque~tor - - - - - - - Service P1ovider. SOAP. Service. Figura 3.4 SOA: Roles y operaciones. Erl, T. (2006).. El proveedor del servicio es responsable de crear la descripción del servicio y desplegarla en un medio ambiente de ejecución para pennitir que otras entidades puedan acceder al servicio a través de la red a partir de la publicación de su descripción en uno o más registradores de servicios.. El solicitante del servicio es responsable de buscar la descripción del servicio publicada en uno o más registros para luego usar esta descripción para conectarse o invocar el servicio proporcionado por el proveedor.. El registrador del servicio es responsable de anunciar la descripción del servicio enviado por el proveedor del servicio a fin de que el requirente del servicio pueda buscar la descripción que. 51.