among Heterogeneous Workflow Environments” Discusión del artículo “Sharing Product Data among Heterogeneous Workflow Environments” Markus Bon, Norbert Ritter, Theo Härder Department of Computer Science University of Kaiserslautern - Germany March 2002 María Elena de León - Sandra Sayanes

Puntos a tratar Conceptos previos Tipo de artículo Objetivos Motivación Detalle Técnico Conclusiones Puntos débiles y fuertes Trabajo futuro

¿Qué es un Workflow? Un “Flujo de trabajo” es un método y medio de transferencia de trabajo, basado en reglas empresariales y de asignación de trabajo, según la posición o rol funcional de una persona dentro de una Organización Durante los últimos años se han automatizado muchos procesos, lo cual ha llevado a una mejora en los clásicos procesos de negocios Se compone de actividades (que son los pasos del workflow) y arcos que determinan la precedencia de una actividad con otra

Ejemplo: Ventas de productos Inicio Fin Solicitud de producto Emisión de factura Entregar al cliente Selección de proveedor a proveedor Espera entrega proveedor s/ stock c/ stock Vinculación con otra empresa - Hacer una descripción del funcionamiento de este proceso - Dar clic para mostrar que una de sus actividades se vincula con otro posible Workflow - explicar que ese es el tema del que trata el artículo: en lugar de llamar por teléfono en ese paso podría acceder a la página web del proveedor y hacer la solicitud, disparando un workflow para su empresa; en lugar de llenar esa solicitud en forma manual podría hacerlo mi sistema de workflow.

El artículo.... Tipo de artículo Propuesta teórica (sin justificación) Presenta la problemática existente a la hora de querer integrar workflows de distintos ambientes y sus posibles soluciones No se relaciona con ninguna aplicación en particular 1) Dicen que sus propuestas solucionan el problema pero no hay ningún tipo de justificación con teoremas ni ecuaciones matemáticas. Lo que pasa acá es que todo esto está tratando sobre procesos que pueden ser muy complejos; en ese flujo de venta que vimos ¿qué teorema podríamos aplicar para decir que va a funcionar de tal forma?

Objetivos Lograr la interoperabilidad entre manejadores heterogéneos de flujos de trabajo (WfMS). Permitir que las distintas aplicaciones de workflows compartan datos y cooperen Modificar lo mínimo posible los manejadores locales Realizar un control automático de las dependencias del flujo de datos

Motivación Trabajo conjunto de empresas causa natural para la existencia de ambientes heterogéneos de workflow todas las empresas contribuyen para alcanzar la meta final del negocio y de esta forma cada uno de sus workflows particulares deben interactuar el mantenimiento de las dependencias entre-workflows que se forman escapa al alcance de los manejadores individuales

Detalle Técnico Enfoque general para combinar Workflows Dependencias del flujo de datos Especificación de datos de cooperación Automatización del suministro de datos Enfoque recomendado Protocolos de transferencia 1) Primero presentan un enfoque general de su idea 2,3) Luego se centralizan en las dependencias del flujo de datos y como automatizar su manejo Datos de cooperación son los datos que se intercambian entre los workflows 4,5) Hablan un poco más sobre unos de los enfoques que plantean para lograr esa automatización 6) Y por último mencionan el protocolo que les parece más adecuado para la comunicación entre los distintos Wrokflows

Enfoque general (1) Las diferentes partes de las empresas, con sus respectivos WfMS, se llaman “islas” La idea es intentar conocer las dependencias existentes entre las distintas islas y reemplazar el mantenimiento manual por un mecanismo automático o semi-automático (botton-up) 1) Cada isla con su WfMS tiene sus bases de datos, manejadores de esas bases de datos, roles que participan en los procesos... Los manejadores pueden ser iguales o distintos. 2) Top-down: si se partiera de la idea del workflow global y luego se analizaran las dependencias que habría entre los locales Acá se tienen los workflows locales y de ellos se van a ver las dependencias ...

Enfoque general (2) Para lograr esto es necesario un conocimiento global del proceso completo Su carencia implicaría protocolos complejos y adaptaciones masivas en los WfMS Entonces, se recomienda la existencia de una componente lógica centralizada denominada “Coordinador” 2) La idea es automatizar el manejo de las dependencias pero modificando lo menos posible los WfMS locales

Enfoque general (3) Conocimientos del Coordinador: dependencias entre las actividades de los distintos tipos de workflow actividades origen y destino de la transmisión de datos estado de cada instancia y del proceso global restricciones temporales y manejo de errores autentificación de los sistemas participantes del proceso global 0) El coordinador debe estar informado sobre las dependencias entre los workflows locales para ser capaz de controlar y soportar los resultados de acciones entre las islas asociadas. 1) distintos “tipos” de Workflow: es porque unos tendrán determinadas actividades o pasos y otros otras Después del último punto: Todo este conocimiento ayuda al coordinador a cumplir sus tareas y ser un mediador confiable y neutral.

Enfoque general (4) Tareas del Coordinador: autentificación de los procesos que pretenden intercambiar información monitoreo del proceso global y de cada uno de los locales participantes suspender o cancelar los workflows locales si no se cumplen las restricciones en caso de fallas, realizar el manejo de excepciones 0) Va a ser responsable de todo esto

Dependencias entre datos (1) Principal problema: proveer a las aplicaciones datos producidos por fuentes externas Las dependencias del flujo de datos afectan en dos niveles de procesamiento: nivel de tipo nivel de instancia Nivel de tipo: se identifican dependencias entre distintos tipos de workflow en las distintas islas Nivel de instancia: se materializan esas dependencias en trabajos que están corriendo en base a esos tipos de workflow

Dependencias entre datos (2) Ejemplo WfT1 es un “tipo” de workflow, WfT2 otro DfD1 es una dependencia que indica que los datos salida de la actividad WfA115 son requeridos como entrada en la actividad WfA213 del otro workflow - estos datos requeridos no están indicados en la especificación del flujo WfT2 entonces, ahora se necesita una especificación de las dependencias del flujo entre-workflows --> pasar a la siguiente transparencia

Dependencias entre datos (3) Esto es visto desde el nivel de instancia: el paso del 1º workflow lo que hace es llamar a alguna aplicación que se va a conectar con un manejador, y lo mismo pasa con la actividad del otro workflow Son las aplicaciones las que están compartiendo los datos

Dependencias entre datos (4) Especificación de dependencias tipos de workflow involucrados actividades vinculadas por las dependencias descripción apropiada de los datos de cooperación nombre del origen de datos y especificación de la forma de acceso para extraer los datos de cooperación Sigue en la próxima

Dependencias entre datos (5) Especificación de dependencias (cont) mecanismo utilizado para transportar esos datos de la isla origen a la destino nombre del destino de datos y especificación de la operación que debe realizarse para integrarle los datos de cooperación Al final: Toda esta especificación es un requisito para el correcto funcionamiento de la cooperación

Dependencias entre datos (6) Mantenimiento de la cooperación: El WfMS debe registrar las nuevas instancias que se inicien en el registro del Coordinador Necesidad de la asistencia de un usuario experto para indicar las instancias de cooperación 0) Además esa cooperación debe “mantenerse”, entonces... 2) Cómo es la asistencia de usuario? - Cuando se crea una instancia nueva, el coordinador genera una lista especificando las dependencias entre datos referidas al tipo de workflow de esa instancia dando el rol origen o destino. - Para cada par (dependencia-rol) se genera la lista de potenciales colaboradores con las instancias que están ejecutándose y aún no tienen colaborador asignado. - El Coordinador ofrece dicha lista al usuario para que seleccione el colaborador correspondiente a la instancia creada o indique que el mismo todavía no se ha iniciado.

Especificación de datos También es necesaria una especificación de la granularidad de los datos que van a cooperar Se necesita conocimiento sobre dicha granularidad tanto para la zona origen como para la zona destino --> Usuario Lenguaje para la especificación: XML 2) Generalmente la especificación de la estructura de los datos tiene una estructura jerárquica, tipo árbol, donde se van creando distintos niveles según los componentes; pueden existir documentos describiendo la geometría de los datos, etc. Hay que tomar la parte significativa de esa estructura y por eso se necesita al usuario experto 3) El lenguaje debe - ser simple para una especificación sencilla y eficiente - debe tener constructores que permitan describir la relevancia de los datos, ser descriptivo - deben poder describirse los niveles de jerarquía - debe ser extensible porque se va a utilizar con sistemas heterogéneos XML cumple con todo esto

Automatización del suministro de datos Se tienen 2 enfoques para la automatización de suministro de datos: Nivel de Tipos de Workflow Extensión de los tipos de workflow origen y destino Agregando actividades para suministrar datos Nivel de Aplicaciones de Workflow Direccionando las operaciones de acceso de datos desde la aplicación de workflow destino al PDMS del origen

Nivel de Tipos de Workflow (1) Identificar y extraer los datos del PDMS origen, mapeando la especificación de datos de cooperación a las operaciones de acceso del PDMS origen. Convertir, empaquetar y transferir los datos de cooperación desde el origen al destino. Integrar los datos de cooperación, mapeando la especificación de éstos a las operaciones de acceso del PDMS destino.

Nivel de Tipos de Workflow (2) Actividades a agregar: Identificar Extraer Convertir Empaquetar Transferir Integrar (adaptando el tipo de workflow destino) Se requiere sincronización de Workflow global a cargo del coordinador.

Nivel de Aplicaciones de Workflow Los datos de cooperación se mantienen en el PDMS origen. Se deben proveer mecanismos de acceso remoto a datos: Con algún objeto proxy almacenado en el PDMS local que tenga interfaces que hagan transparente el acceso remoto. Filtro de operaciones de acceso a datos de la aplicación destino. En el origen, cada operación referida a datos de cooperación es redireccionada al PDMS remoto. Este enfoque no es elegante ya que se necesita un filtro externo

Problemas de los enfoques Maria Elena de Leon: Problemas de los enfoques Traducción de llamadas de las APIs del PDMS destino a las del PDMS origen Estas llamadas pueden llevar a un cruce de bordes del sistema. Cuando las islas están protegidas con firewalls se dificulta *Las llamadas a las APIs se traducen de las del PDMs objetivo a las del fuente que son semánticamente equivalentes. Las islas frecuentemente están protegidas por firewalls El tiempo se incrementa porque los datos de cooperación se encuentran en el fuente. Incremento del tiempo de espera para usuarios remotos

Sistemas Manejadores de Datos (PDMS) (1) El uso de PDMS idénticos en ambas islas es favorable porque: Misma API Mismo modelo de representación de datos No hay necesidad de mapeo de datos de cooperación

Sistemas Manejadores de Datos (PDMS) (2) Si se usan PDMS diferentes: Hay que hacer mapeo de datos El mapeo anterior es prerrequisito para la transferencia de datos Para la propagación de datos proveer un generador de actividades de transferencia y un humano para el mapeo Los datos de cooperación deben ser mapeados del modelo de datos del PDMS fuente al del objetivo Para la propagación de datos es más factible proveer un generador que genere actividades de transferencia desde la especificación de dependencia del flujo de datos y que exista un experto humano que haga el mapeo, antes que tener un generador para reescribir las operaciones de acceso de datos del PDMS objetivo.

Acceso a Datos de Cooperación Los datos se pueden acceder con permisos de : solo lectura o lectura/escritura. Solo Lectura: más simple porque no existen cambios a ser propagados Lectura/Escritura: más difícil ya que se deben propagar las modificaciones hechas por la aplicación destino al origen

Control de Acceso (1) El acceso no autorizado debe ser prevenido tanto en el origen como en el destino. Transferencia de Datos (nivel de tipo de workflow) Miembro con permiso al menos de lectura en el PDMS destino para la actividad de extracción Miembro con permiso de inserción en el PDMS origen para la actividad de integración

Control de Acceso (2) ESTA ES LA PEOR SOLUCIÓN Propagación de Acceso (nivel de aplicación) El miembro responsable de la aplicación destino debe ser registrado en el origen y garantizarle derechos suficientes Las islas fuentes son diferentes entornos ESTA ES LA PEOR SOLUCIÓN

Enfoque recomendado Vemos que el enfoque de Nivel de Automatización por Tipos de Workflow es menos problemático ya que los sistemas de Manejo de Workflows son más fácilmente adaptables que las Actividades de Workflow SE APOYA EL PRIMER ENFOQUE

Automatización por Adaptación de Tipos de Workflow Se considerará: Idénticos PDMS en origen y destino Acceso de solo lectura por la aplicación destino Las actividades de WF originales y las operaciones de acceso a datos permanecen incambiadas

Transferencia de Datos de Cooperación (1) La actividad de extracción de datos a ser provista debe ser incorporada al WfT11 directamente después de WfA115 . La nueva actividad de integración debe ser integrada en WfT21 antes de WfA213. Este proceso de adaptación es muy fácil y puede ser ejecutado en todos los WfMs. Actividad Destino Actividad de Extracción Actividad Origen Actividad de Integración

Transferencia de Datos de Cooperación (2) Existen 6 fases para la transferencia de Datos: 1- Inicializar Wf1 y Wf2. El coordinador es informado y toma la información necesaria para relacionar las partes cooperativas. 2- La aplicación fuente produce datos y los almacena en su PDMS local (PDMS1) 3- La aplicación de exportación identifica y extrae los datos cooperativos usando la especificación de datos y crea un archivo de traspaso. 4- El archivo es transferido de una isla a la otra. EL coordinador provee la información sobre la ubicación del objetivo. 5- La aplicación de importación extrae los datos de cooperación y los almacena en el PDMS local (PDMS2) 6- La aplicación objetivo comienza su trabajo usando la copia local para acceder a los datos.

Aplicaciones de Importación y Exportación Importación - Existen 3 enfoques: 1 - Extracción de datos en algún tipo de formato propio del PDMS 2 - Usando interfaces SQL 3 - Combinación de las anteriores Exportación La aplicación para insertar datos es más fácil porque no hay mapeo adicional Los datos son directamente integrados llamando a la API del PDMS 1) 1) Extraer el árbol producto a un archivo. 2) Filtrar el árbol de acuerdo a la especificación de datos cooperativos. 3) Obtener la dirección del objetivo por medio del coordinador y enviar el archivo - Generando sentencias SQL basadas en la estructura del árbol. - Los resultados se empaquetan en un archivo de transferencia usando un formato neutral (por ejemplo usando XML) 3) Usando interfases SQL para crear una representación interna de todo el árbol. Las operaciones son ejecutadas usando el árbol creado en memoria principal. Del lado del objetivo la aplicación para insertar los datos es más fácil ya que los PDMS son iguales entonces no hay mapeo adicional Los datos son directamente integrados llamando a la API del PDMS

Control de Acceso Altos costos en tiempo Es importante garantizar derechos de acceso suficientes (pero estrictos) para las actividades de importación y exportación y para la aplicación destino Para la codificación y autentificación: Técnicas que usen pares de claves asimétricas Altos costos en tiempo

Protocolos de transferencia Maria Elena de Leon: Protocolos de transferencia La comunicación entre las islas requiere de protocolos de comunicación: Protocolos binarios como TCP (sincrónicas) Encolado de mensajes (asincrónica) Llamadas a procedimientos remotos (RPC) Los firewalls dificultan las cosas para los protocolos CORBA o RMI Usar SOAP es mucho más lento que CORBA o RMI pero está la ventaja de que puede evitar el problema de los firewall ya que usa el puerto 80. Ejemplo: Una aplicación de exportación prepara los datos de cooperación a transferir. El servlet enmascara los datos como carga útil en un mensaje SOAP. Este mensaje es trasmitido usando HTTP. En la isla objetivo, otro servlet desenmascara los datos de cooperación para el procesamiento siguiente. SOAP es el adecuado Los mensajes SOAP: usan HTTP se envían a través del puerto 80

Conclusiones Los autores están satisfechos con su trabajo Se logran cumplir los objetivos de plantear posibles soluciones a la problemática de la interoperabilidad entre workflows permitir la cooperación automatizar el control de las dependencias del flujo de datos Estas son las conclusiones que figuran en el propio artículo

Puntos débiles ? No se define lo que es un workflow ni sus conceptos relacionados (actividades, por ej.) Se parte de la idea de que ya existen los workflows automatizados y que deben integrarse no se plantea la posibilidad de que en algún caso no este definido 1,2) En realidad lo débil no es no tener estas cosas porque es un artículo que ya parte del conocimiento de lo que es un workflow y de que ya existen los procesos automáticos en las empresas... El punto débil es el no hacer referencia a ninguna otra fuente de donde sacar esa información. Una persona nueva en el tema no podría entenderlo

Puntos débiles (1) Menciona la existencia de un “componente lógico centralizado” llamado “coordinador” y sus responsabilidades pero no hace ninguna mención sobre qué es realmente ese coordinador Hay una referencia a un documento anterior de los autores que no está disponible en Internet Hay un resumen en alemán Esto sí, nos parece que hubiese sido bueno aclarar un poco más si ya tienen pensado exactamente qué es el Coordinador, si es un programa que ellos piensan hacer o algo que ya existe.... Como que ahí queda una nebulosa porque hablan de que tiene que “conocer” varias cosas y que tiene varias responsabilidades pero...¿qué es?

Puntos débiles (2) Se detalla una solución asumiendo el caso más simple acceso de solo lectura para no transferir modificaciones y PDMS idénticos No se menciona cómo se resolverían los problemas con los casos más complicados Todo es teoría y no se tiene la certeza de que funcione o no

Puntos fuertes Trata un problema real que, con el avance de la informática en las empresas y la necesidad de trabajar junto con otras para adquirir mayor competitividad, se acerca cada vez más. Es un artículo muy nuevo y todavía queda mucho por delante para avanzar en el tema Es un punto de partida para análisis más profundos con casos concretos

Trabajo futuro Probar los conceptos planteados en un ambiente real de trabajo Aplicar las propuestas planteadas en distintos escenarios Adquirir mayor experiencia en la interoperabilidad de workflows Ellos saben que los planteamientos que hicieron son todos teóricos y ahora tienen pensado llevarlos a la práctica

Relación con conceptos de Interoperabilidad (1) Arquitectura de integración Sistema federado fuertemente acoplado En este caso NO se realiza un esquema común Heterogeneidad  En todo el artículo se menciona su existencia y se respeta 1) En el SFA existe un super usuario que conoce todo lo de los sistemas locales y determina los datos de exportación; en este caso está el coordinador quien también conoce los sistemas de workflow locales y es el encargado de controlar el funcionamiento del workflow global

Relación con conceptos de Interoperabilidad (2) Autonomía de diseño  se menciona una modificación sobre los manejadores locales existencia del coordinador Autonomía de comunicación ? al no conocer el coordinador en detalle no queda claro si existen pedidos del mismo para que los manejadores locales pueden llegar a decidir cuándo responderlos 1) Por un lado se habla de que cada isla, junto a su WfMS tiene determinadas bases de datos, manejadores de datos, aplicaciones, etc --> por este lado existiría autonomía de diseño Pero a la hora de integrar se van a modificar esos manejadores, entonces se pierde la autonomía Además el coordinador seguramente necesite determinado “diseño” para trabajar 2) Habría que conocer bien cuál es la forma de trabajo del coordinador, si hace pedidos o toma el mismo los datos, por ejemplo

Relación con conceptos de Interoperabilidad (3) Autonomía de ejecución  La ejecución de una actividad no interfiere en la de otra La actividad de integración requiere los datos de la de extracción Autonomía de participación  es el usuario quien determina los datos de cooperación al realizar la especificación de dependencias 1) Si los datos de salida de una actividad son entrada para otro workflow están afectando su funcionamiento 2) Los manejadores no son quienes decidir qué compartir

Gracias... Preguntas ?