La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Sharing Product Data among Heterogeneous Workflow Environments Markus Bon, Norbert Ritter, Theo Härder Department of Computer Science University of Kaiserslautern.

Presentaciones similares


Presentación del tema: "Sharing Product Data among Heterogeneous Workflow Environments Markus Bon, Norbert Ritter, Theo Härder Department of Computer Science University of Kaiserslautern."— Transcripción de la presentación:

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

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

3 ¿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

4 Ejemplo: Ventas de productos Inicio Fin Solicitud de producto Emisión de factura Entregar al cliente Selección de proveedor Solicitud a proveedor Espera entrega proveedor s/ stock c/ stock Vinculación con otra empresa

5 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

6 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

7 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

8 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

9 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)

10 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

11 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

12 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

13 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

14 Ejemplo Dependencias entre datos (2)

15 Dependencias entre datos (3)

16 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

17 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

18 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

19 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

20 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

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

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

23 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

24 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 Incremento del tiempo de espera para usuarios remotos Maria Elena de Leon:

25 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

26 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 Sistemas Manejadores de Datos (PDMS) (2)

27 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

28 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

29 Control de Acceso (2) 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

30 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

31 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

32 Transferencia de Datos de Cooperación (1) Actividad Origen Actividad de Extracción Actividad de Integración Actividad Destino

33 Transferencia de Datos de Cooperación (2)

34 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 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 2 - Usando interfaces SQL 3 - Combinación de las anteriores

35 Control de Acceso 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

36 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 SOAP es el adecuado Los mensajes SOAP: usan HTTP se envían a través del puerto 80 Maria Elena de Leon:

37 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

38 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

39 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

40 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

41 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

42 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

43 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

44 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

45 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

46 Gracias... Preguntas ?


Descargar ppt "Sharing Product Data among Heterogeneous Workflow Environments Markus Bon, Norbert Ritter, Theo Härder Department of Computer Science University of Kaiserslautern."

Presentaciones similares


Anuncios Google