MX2008011910A

MX2008011910A - Control de falla asincronico en programas centricos de procedimiento.

Info

Publication number: MX2008011910A
Application number: MX2008011910A
Authority: MX
Inventors: Mayank Mehta; Akash J Sagar; Dharma Shukla; Bob Schmidt; Karthik Raman; Nathan Talbert
Original assignee: Microsoft Corp
Priority date: 2006-03-30
Filing date: 2007-02-21
Publication date: 2008-09-29
Also published as: US20070234129A1; KR20080106567A; CA2644370A1; EP2013716A1; WO2007120391A1; JP2009532760A; US7739135B2; CN101416156B; RU2008138701A; EP2013716A4; CN101416156A; BRPI0708917A2; JP5297370B2

Abstract

Se describe manejo de falla asincrónico para un flujo de trabajo. Se define un autómata de estado para una actividad en el flujo de trabajo. El autómata de estado incluye al menos un estado de ejecución, un estado defectuoso, y un estado cerrado y clasifica un tiempo de vida de ejecución de la actividad. La actividad se define para incluir artículos de trabajo e incluye una jerarquía de ejecución para los artículos de trabajo. Cada artículo de trabajo incluye una operación para ejecutar una porción de la actividad. Cada artículo de trabajo es transitado al estado de ejecución. La operación incluida de los artículos de trabajo transitados se ejecuta en el estado de ejecución. Uno o más de los artículos de trabajo transitados se identifican en respuesta al evento defectuoso como una función de la jerarquía de ejecución y la operación incluida. El evento defectuoso se controla asincrónicamente al transitar uno o más de los artículos de trabajo identificados al estado defectuoso mientras se ejecuta la operación incluida de los artículos de trabajo transitados restantes.

Description

CONTROL DE FALLA ASINCRONICO EN PROGRAMAS CENTRICOS DE PROCEDIMIENTO ANTECEDENTES Se han desarrollado programas orientados a procedimiento o céntricos de procedimiento para permitir el procesamiento de eventos de mundo real de moldeado de instrucciones complejos. Los programas céntricos de procedimiento reflejan procedimientos de mundo real e interacciones de espejo entre entidades de mundo real. Los sistemas existentes intentan delinear problemas de negocio a flujos de trabajo de nivel superior al moldear el problema de negocio. Sin embargo, los flujos de trabajo de mundo real varían en una variedad de dimensiones tales como (a) ejecución y complejidad de moldeado, (b) reconocimiento de la estructura del flujo en tiempo de diseño, (c) estáticamente definido o ad-hoc/dinámico, (d) facilidad de crear y editar el flujo en varios puntos de su ciclo de vida, y (e) asociación débil o fuerte de lógica de negocio con el procedimiento de flujo de trabajo de núcleo. Los modelos existentes fallan al acomodar todos estos factores. Además, la mayoría de los modelos de flujo de trabajo existentes se basan en aspectos basados en lenguaje (por ejemplo, BPEL4WS, XLANG/S y WSFL) o aspectos basados en aplicación. Los aspectos basados en lenguaje son lenguajes de flujo de trabajo de nivel superior con un grupo cerrado de construcciones predefinidas que ayudan a modelar el procedimiento de flujo de trabajo al usuario/programador. Los lenguajes de flujo de trabajo transportan toda la información semántica para el grupo cerrado de construcciones para permitir que el usuario construya un modelo de flujo de trabajo. Sin embargo, los lenguajes no son extensibles por los desarrolladores y representan un grupo cerrado de primitivos que constituyen el modelo de flujo de trabajo. Los lenguajes se unen a recopilador de lenguaje transportado por el vendedor de sistema de flujo de trabajo. Sólo el vendedor de producto de sistema de flujo de trabajo puede extender el modelo al extender el lenguaje con un nuevo grupo de construcciones en una versión futura del producto. Esto frecuentemente requiere mejorar el recopilador asociado con el lenguaje. Además, los lenguajes usualmente no exponen declarativamente o definen funciones u operaciones que pueden utilizarse fácil y eficientemente por otros programas. Los aspectos basados en aplicación son aplicaciones que tienen las capacidades de flujo de trabajo dentro de la aplicación para resolver un problema específico de dominio. Estas aplicaciones no son verdaderamente extensibles ni tienen un modelo programable. Además, con los aspectos existentes, los problemas de complejidad, conocimiento previo, flujos de trabajo dinámicos, facilidad de creación, y resistencia de asociaciones con una lógica de negocio y flujos de trabajo de núcleo que no se dirigen adecuadamente. No hay estructuras de diseñador de flujo de trabajo extensible, adaptables, y re-alojables disponibles para construir diseñadores de flujo de trabajo visuales para modelar diferentes clases de flujos de trabajo. Los sistemas existentes carecen de una experiencia de diseño de flujo de trabajo de estilo de desarrollo de aplicación rápido (RAD) que permiten a los usuarios diseñar gráficamente el procedimiento de flujo de trabajo y asociar la lógica de negocio en un lenguaje de programación de elección del desarrollados También, los procedimientos de flujo de trabajo tratan con asuntos ortogonales y enredados de corte que separan múltiples pasos de un modelo de procedimiento de flujo de trabajo. Por ejemplo, mientras se diseñan partes de procedimiento de flujo de trabajo para participar en transacciones de larga duración, otras partes del mismo procedimiento se diseñan para ejecución concurrente o para acceso a un recurso compartido. Debido a fallas de diseño, los sistemas existentes fallan al proporcionar espaciado de secuencias de ejecución que permiten a los usuarios diseñar ejecución sincrónica o espaciada de actividades. Incluso otras porciones del mismo procedimiento de flujo de trabajo requieren rastreo, mientras otras porciones controlan excepciones de nivel de negocio o de aplicación. No hay una necesidad de aplicar ciertos comportamientos a una o más porciones de un procedimiento de flujo de trabajo. Algunos aspectos de moldeo de flujo de trabajo son imprácticos ya que requieren una descripción basada en flujo completa de un procedimiento de negocio completo que incluye todas las excepciones e intervenciones humanas. Algunos de estos aspectos proporcionan una funcionalidad adicional mientras surgen excepciones, mientras otros aspectos emplean exclusivamente un acercamiento basado en limitación en lugar de un acercamiento basado en flujo para moldear un procedimiento en negocio. Los sistemas existentes implementan el acercamiento basado en flujo o basado en limitación. Tales sistemas son demasiado inflexibles para modelar muchas de las situaciones de negocio comunes. Estos sistemas también carecen de la capacidad de controlar asincrónicamente excepciones o cancelaciones.

BREVE DESCRIPCION DE LA INVENCION Las modalidades de la invención permiten falla asincrónica o manejo seccional al tener un estado defectuoso en un tiempo de vida de ejecución de definición autómata de una actividad en el flujo de trabajo. Al tener el estado defectuoso, aspectos de la invención permiten a los desa rrol ladores o programa diseñar declarativamente programas para control de excepción o de falla para que las porciones de programa o la actividad puedan estar en un manejo de falla en el estado defectuoso mientras otras porciones de programa o la actividad pueden no afectarse por la excepción o el evento de falla. Las modalidades alternativas de la invención permiten la propagación o transmisión de una notificación de manejo de falla.

Incluso en otra modalidad alternativa, tal propagación o transmisión de la notificación puede suprimirse o inhibirse. Además, una modalidad alternativa adicional responde a la entrada de un usuario para controlar operaciones de pos-falla o pos-excepción. Esta breve descripción se proporciona para introducir una selección de conceptos en una forma simplificada que además se describe posteriormente en la descripción detallada. Esta breve descripción no pretende identificar características clave o características esenciales del tema reclamado, ni pretende utilizarse como un auxiliar al determinar el alcance del tema reclamado. Otras características en parte serán evidentes y en parte se señalarán aquí posteriormente.

BREVE DESCRIPCION DE LOS DIBUJOS La Figura 1 es un diagrama de bloques que ilustra un paradigma de programación existente. La Figura 2 es un diagrama de bloques ilustrativo que ilustra una virtualización de una estructura de trabajo de diseño de flujo de trabajo de acuerdo con una modalidad de la invención. La Figura 3 es un diagrama ilustrativo que ilustra un flujo de trabajo ilustrativo de acuerdo con una modalidad de la invención. La Figura 4 es un diagrama que ilustra un ambiente de cómputo ilustrativo de un sistema para procesar actividades de flujo de trabajo de acuerdo con una modalidad de la invención.

La Figura 5 es un diagrama que ilustra una estructura jerárquica de una actividad de flujo de trabajo de acuerdo con una modalidad de la invención. La Figura 6 es un diagrama que ilustra un estado ilustrativo autómata que describe tiempo de vida de ejecución de una actividad de acuerdo con una modalidad de la invención. Las Figuras 7A a 7E son diagramas de bloques que ilustran un manejo asincrónico de eventos defectuosos o un flujo de trabajo de acuerdo con una modalidad de la invención. La Figura 8 es un diagrama de flujo que ¡lustra un método para manejar asincrónicamente un evento defectuoso o una actividad de un flujo de trabajo de acuerdo con una modalidad de la invención. La Figura 9 es un diagrama de bloques que ilustra un medio legible por computadora ilustrativo en el cual pueden almacenarse aspectos de la invención. El Apéndice A ilustra una implementación ilustrativa para elevar declarativamente una excepción de acuerdo con una modalidad de la invención. Caracteres de referencia correspondientes indican partes correspondientes a través de los dibujos.

DESCRIPCION DETALLADA Haciendo referencia primero a la Figura 1, un diagrama de bloques ilustra un paradigma de programación existente para diseñar programas para actividades céntricas de procedimiento, tal como un flujo de trabajo. Por ejemplo, el diagrama muestra un modelo de virtualización de nivel tres de un paradigma de programa existente con un nivel de un ambiente de ejecución manejado que es el nivel superior y una unidad de procesamiento que es el nivel inferior. En este sistema de diseño de programación, incluso en el nivel de ambiente de ejecución manejado, programas, especialmente programas céntricos de procedimiento que controlan procedimientos de flujo de trabajo, carecen de la capacidad y eficiencia para acomodar interacciones complejas entre procedimientos en un flujo de trabajo. Se sabe por aquellos expertos en la técnica que ciertas limitaciones se asocian con diseñar programas de software o aplicación. En este ejemplo, al escribir un programa de software de sistema operativo 104, los códigos de programación o rutinas son dependientes del tipo de configuración de unidades de procesamiento 102, que son específicas al tipo de arquitectura de cómputo (por ejemplo, compatible con IBM®, computadoras de APPLE®, y otros sistemas), u otras limitaciones. Además, los lenguajes de programación típicamente necesitan identificar exactamente y utilizar estructuras de datos tal como pilas, bultos, base de secuencia, u otras estructuras específicas de hardware para el sistema operativo 104 para funcionar apropiadamente. Al tratar con procedimientos de flujo de trabajo complejos, las aplicaciones existentes utilizan un concepto de un ambiente de ejecución manejado 106 (por ejemplo, un ambiente de tiempo de funcionamiento en donde los programas pueden compartir funciones o clases orientadas objeto común) en donde los programas escritos en un lenguaje de programación pueden llamar a funciones en otros programas escritos en un lenguaje de programación diferente. En tal ambiente de ejecución, estos programas en diferentes lenguajes de programación se recopilan a un lenguaje intermedio tal como el ambiente de ejecución manejado 106 puede exponer parámetros, argumentos, o esquemas o funciones a los diferentes programas para que los programas puedan interactuar unos con otros. Mientras este ambiente de ejecución 106 crea un ambiente de ejecución común entre programas, el ambiente de ejecución 106 incluye varios requerimientos estrictos que pueden no ser adecuados para controlar la complejidad y capacidad de programas céntricos de procedimiento. Por ejemplo, el ambiente de ejecución 106 requiere que los programas se confirmen a un formato de archivo específico. El ambiente de ejecución 106 también requiere que las funciones u operaciones en los programas utilicen un grupo de fijo de funciones o una clase de funciones definidas por el ambiente de ejecución 106. Las modalidades de la invención se construyen en un fundamento extensible o estructura de trabajo 202 en la Figura 2 para superar las desventajas del modelo de programación existente. Al permitir que los programas escritos en cualquier lenguaje de programación y compuestos en cualquier formato de archivo, los aspectos de la invención permiten a los desarrolladores de programa diseñar programas con funciones específicas sin comprometer sus funcionalidades y especificaciones. Al definir actividades, tal como tareas de flujo de trabajo o procedimientos, como la clase de base para ejecutarse en la estructura de flujo de trabajo, los desabolladores pueden fácil y eficientemente construir códigos de operación específicos de dominio (por ejemplo, ambientes de ejecución específicos tal como programas en la industria de salud, industria financiera, o similares) (denominados aquí "op-código") sin adherirse a el grupo de funciones o clases de actividades fijas rígidas, codificadas fuertemente, inflexibles en el ambiente de ejecución existente. Además, el fundamento de flujo de trabajo que representa aspectos de la invención es un tiempo de funcionamiento basado en continuación en capas en la parte superior de cualquier estructura de trabajo existente (por ejemplo, cualquier ambiente de ejecución manejado, ambiente de sistema operativo, o nivel de unidad de procesamiento de hardware). Los aspectos de la invención liberan a la limitación de definir actividades en un formato de archivo particular al permitir diseños de flujo de trabajo en cualquier forma o representación (por ejemplo, un cuadro de flujo, un diagrama, una descripción numerada, o similares) mientras las actividades en el flujo de trabajo pueden construirse de la representación de los diseños de flujo de trabajo. Además, la estructura o fundamento de flujo de trabajo es capaz de controlar falla o excepción elevada de un nivel inferior (por ejemplo, OS) o funciones que surgen de excepción escritas en otros 1 o formatos (por ejemplo, lenguaje intermedio). La Figura 3 ilustra una vista simple de un flujo de trabajo 300 de acuerdo con una modalidad de la invención. Por ejemplo, el flujo de trabajo 300 puede ser un flujo de trabajo para procesar una orden de compra, o este flujo de trabajo de orden de compra 300 puede incluir procedimientos o actividades tal como recibir una orden de compra, enviar confirmación a un cliente, aprobar la orden de compra por un administrador, o similares. El flujo de trabajo 300 puede iniciar desde un punto de partida 302. Por ejemplo, el punto de partida 302 para un grupo de trabajo de orden de compra puede ser recibir una orden de un cliente. El flujo de trabajo 300 también puede incluir una declaración condicional 304 (tal como una "declaración IF" o una "declaración WHILE"), y puede subdividirse en declaraciones condicionales adicionales 306 y 308. El flujo de trabajo 300 también puede incluir una estructura paralela 310, que además incluye una o más secuencias o actividades 312. Por ejemplo, la estructura paralela 310 incluye actividades, tal como revisar el inventario y actualizar los embarques disponibles, que se procesan en paralelo. En el ejemplo mostrado, las actividades tal como "Enviar correo electrónico" y "Obtener aprobación" puede procesarse en paralelos. En "dejar caer actividades aquí" 316, un usuario además puede agregar o complementar más actividades en el flujo de trabajo 300. Para completar el flujo de trabajo 300, los procedimientos o actividades concluirán en un paso o punto completo 314.

En una modalidad, las actividades puede distribuirse jerárquicamente en una estructura de árbol (ver Figura 5) 500 u otras secuencias de ejecución. Por ejemplo, una actividad puede ser una actividad compuesta en la cual la actividad incluye más de un artículo de trabajo asociado con este. En otra modalidad, una colección de actividades puede ser una actividad de compuesto. Un método de actividad u operación puede estar en un nodo de raíz 502 con dos hijos o nodos de hoja 504 y 506. Los métodos u operaciones de actividad en los nodos hijo 504 y 506 (por ejemplo, articulo de trabajo_1 y artículo de trabajo_2, respectivamente) pueden ejecutarse de acuerdo con la estructura jerárquica. Además, los nodos hijo 504 y 506 también pueden incluir otros nodos hijo que tienen artículos de trabajo respectivos para ejecutarse. En otra modalidad, las actividades incluyen uno o más de los siguientes tipos: una actividad simple, actividad de contenedor y actividad de raíz. En esta modalidad, existe una actividad de raíz en el modelo, y ninguna o cualquier cantidad de actividades simples o actividades de contenedor dentro de la actividad de raíz. Una actividad de contenedor puede incluir actividades simples o de contenedor. El procedimiento de flujo de trabajo completo puede utilizarse como una actividad para construir procedimientos de flujo de trabajo de orden superior. Además, una actividad puede ser interrumpible o no interrumpible. Una actividad compuesta no interrumpible o no interrumpible. Una actividad compuesta no interrumpible no incluye actividades interrum pibles . Una actividad no interrumpible carece de servicios que pueden causar que la actividad se bloquee. Además, al ejecutar actividades y los artículos de trabajo incluidos en las actividades, la estructura de flujo de trabajo o un contexto o ambiente de ejecución define un alcance o límite para cada uno de los artículos de trabajo. Este alcance o límite incluye y expone información (por ejemplo, en la forma de datos, metadatos, o similares) tal como los datos o recursos compartidos para accederse por los artículos de trabajo, propiedades asociadas, controladores, limitaciones e interacciones entre agentes autómatas. También, cada actividad puede configurarse por un código de usuario en cualquier lenguaje de programación. Por ejemplo, el código de usuario puede representar lógica de negocio o aplicación o reglas escritas en un dominio específico o ambiente de ejecución. Cada actividad puede soportar ganchos de pre-intercepción y ganchos de pos-intercepción en la ejecución en el código de usuario. Cada actividad tiene semánticas y comportamiento de ejecución de tiempo de funcionamiento asociados (por ejemplo, manejo de estado, transacciones, control de evento y control de excepción). Las actividades pueden compartir estados o recursos con otras actividades. Además, las actividades pueden ser actividades primitivas o agrupadas en una actividad compuesta. Una actividad primitiva o básica no tiene subestructura (por ejemplo, actividades hijo), y de esa forma es un nodo de hoja en una estructura de árbol. Una actividad compuesta contiene subestructura (por ejemplo, es el padre de una o más actividades hijo). La Figura 4 es un diagrama que ilustra un sistema 400 para procesar actividades de flujo de trabajo de acuerdo con una modalidad de la invención. El sistema 400 incluye un procesador 402, que puede ser una unidad de procesamiento o una colección de unidades de procesamiento. El sistema 400 también incluye un área de almacenamiento o memoria 404 para almacenar datos accesibles por el procesador 402. En una modalidad, el sistema 400 puede ser una computadora que tiene uno o más procesadores o unidades de procesamiento (por ejemplo, procesador 402) y una memoria de sistema (por ejemplo, área de memoria 404) que tiene otros componentes para acoplar varios componentes de sistema que incluyen la memoria de sistema al procesador 402. En un ejemplo, el área de memoria 404 puede incluir medios legibles por computadora, ya sea medios volátiles, no volátiles, removibles, o no removibles, implementados en cualquier método o tecnología para almacenamiento de información tal como instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos. Por ejemplo, los medios de almacenamiento por computadora incluyen RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, CD-ROM, discos versátiles digitales (DVD) u otro almacenamiento de disco óptico, cassettes magnéticos, cinta magnética, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que puede utilizarse para almacenar la información deseada y que puede accederse por el sistema 400. La memoria 404 también puede incluir medios de comunicación que representan instrucciones legibles por computadora, estructuras de datos, módulos de programa, u otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte e incluyen cualquier medio de entrega de información. Aquellos expertos en la técnica están familiarizados con la señal de datos modulada, que tiene una o más de sus características establecidas o cambiadas de tal forma para codificar información en la señal. Los medios por cable, tal como red por cable o conexión por cable directa, y medios inalámbricos, tal como acústicos, RF, infrarrojos, y otros medios inalámbricos, son ejemplos de medios de comunicación. Combinaciones de cualquiera de los anteriores también se incluyen dentro del alcance de medios legibles por computadora. Por ejemplo, el área de memoria 404 almacena una pluralidad de actividades 406 para procesar en un flujo de trabajo (por ejemplo, el flujo de trabajo 300). Cada uno de la pluralidad actividades 406 incluye uno o más artículos de trabajo, y los artículos de trabajo pueden organizarse en una estructura jerárquica tal como una estructura de árbol (ver Figura 5). Al procesar la pluralidad de actividades 406, el procesador 402 accede o ejecuta un programador 408, que se configura para establecer un grupo organizado de actividades. Por ejemplo, el procesador 408 accede a los artículos de trabajo en la pluralidad actividades 406 a través de un componente o un grupo de instrucciones ejecutables por computadora tal como el programador 408 para formar o para almacenar los artículos de trabajo 422 a una fila 410. Un distribuidor 412, accesible por el procesador 402, distribuye los artículos de trabajo 422 para ejecución. Por ejemplo, un artículo de trabajo 422-1 puede incluir un método de actividad o una operación de actividad 424, rutina, o una colección de códigos para realizar una función de "solicitar entrada de un usuario". Uno o más otros métodos de actividad, operaciones de actividad, rutinas, o códigos pueden incluirse en cada uno de los artículos de trabajo 422 sin apartarse del alcance de la invención. Una vez que se distribuyen los artículos de trabajo 422 por el distribuidor 412, el procesador 402 ejecuta cada uno de los métodos 424 en los artículos de trabajo 422 en 414. En el ejemplo del artículo de trabajo 422-1, el procesador 402 puede proporcionar un usuario a través de una interfase de usuario (Ul) para ingresar la información solicitada o datos. En otra modalidad, el procesador 402 puede conectarse a o acceder a una fuente de datos externa para solicitar entrada del usuario. Al término del método de actividad u operación de actividad 424, el procesador 402 concluye la ejecución de los artículos de trabajo 422 en 416. En una modalidad, el procesador 402 pasiva el estado de ejecución de artículos de trabajo en 418 a un almacenamiento de datos 420. En otra modalidad, el procesador 402 ejecuta los artículos de trabajo 422 de acuerdo con un estado autómata mostrado tal como el autómata mostrado en la Figura 6, que es un diagrama que ilustra una autómata de estado ilustrativo 600 que describe estados de procesamiento de artículos de trabajo asociados con una actividad de acuerdo con una modalidad de la invención. En una modalidad, el autómata de estado 600 define un tiempo de vida de ejecución de una actividad. En un ejemplo, el autómata de estado 600 puede incluir un estado iniciado, un estado de ejecución, y un estado cerrado (como se muestra en la Figura 4). En otra modalidad, el autómata de estado 600 incluye un estado iniciado 602, un estado de ejecución 604, un estado de cancelación 606, un estado defectuoso 608, un estado de compensación 610, y un estado cerrado 612. Por ejemplo, el autómata de estado 600 describe un flujo de procedimiento de ejecución de artículos de trabajo (por ejemplo, artículos de trabajo 422) en una actividad de flujo de trabajo. El articulo de trabajo 422-1, como se ilustró en la Figura 4, primero se inicia cuando se forma en la fila 410. El artículo de trabajo 422-1 después se quita de la fila o se remueve de la fila 410 al distribuidor 412 antes de ejecutarse en el estado de ejecución (por ejemplo, el estado de ejecución 604 en la Figura 6). Dependiendo de los parámetros o condiciones durante la ejecución del artículo de trabajo 422-1, el artículo de trabajo 422-1 puede proceder al estado de cancelación 606 (por ejemplo, el estado de cancelación 426 en la Figura 4) o el estado defectuoso 608. En una modalidad, el artículo de trabajo 422-1 puede proceder del estado de cancelación 606 al estado defectuoso 608. En una modalidad alternativa, el estado de compensación 610 describe un grupo de operaciones o funciones para realizarse cuando ocurrió la falla o excepción. Por ejemplo, supongamos que ocurre una excepción durante la ejecución de un artículo de trabajo (por ejemplo, artículo de trabajo 422-1 ), tal como un parámetro para una función que falta. El sistema 400 transita el articulo de trabajo 422-1 al estado defectuoso 608. Al hacer eso, el sistema 400 también realiza una colección de basura (por ejemplo, remover la porción previamente ejecutada de las operaciones de la memoria cache o memoria, valores de parámetros restablecidos, o similares) operaciones en el estado de compensación 610 antes de transitar el artículo de trabajo 422-1 al estado cerrado 612. Por ejemplo, los artículos de trabajo en el estado de compensación 610 pueden activar operaciones tal como recuperar datos que se utilizaron previamente para ejecutar otros artículos de trabajo. El estado cerrado 612 indica que la ejecución de la actividad (por ejemplo, actividad 500 en la Figura 5) se completó.

En una modalidad, el autómata de estado 600 establece relación entre artículos de trabajo en una actividad compuesta. Por ejemplo, una de las reglas de relación puede incluir que, antes de transitar al estado cerrado 612 los métodos o artículos de trabajo en el nodo de raíz del árbol de actividad, todos los artículos de trabajo en los nodos hijo deben estar en el estado iniciado 602 ó el estado cerrado 612. Otra regla puede requerir que, con el fin de transitar a los artículos de trabajo en el nodo hijo del árbol de actividad al estado de ejecución 604, el artículo de trabajo en el nodo de raíz ya debe estar en el estado de ejecución 604. En otra modalidad, uno o más estados adicionales pueden definirse en el autómata de estado 600 sin apartarse del alcance de las modalidades de la invención. Haciendo referencia después a las Figura 7A y 7E, los diagramas de bloques ilustran control asincrónico de eventos defectuosos en un flujo de trabajo de acuerdo con una modalidad de la invención. Para propósitos de simplistas solamente y sin limitaciones, la Figura 7A muestra una actividad compuesta 702 que incluye tres artículos de trabajo hijos organizados en una estructura de árbol: transacción_1 704, transacción_2 706, y transacción_3 708. Como se ilustró, la actividad de raíz 702 incluye un método para "escribir texto en la presentación". Los métodos de actividad u operaciones para los artículos de trabajo anteriores también incluyen lo siguiente: Transacción_1 704: {INSERTAR TEXTO ("1 Y 2"); CONTROLAR FALLA (); } Transacción_2 706: {INSERTAR TEXTO ("3 Y 4"); CONTROLAR FALLA (); } Transacción_3 708: {INSERTAR TEXTO ("5 Y 6"); PAUSA 180 SEGUNDOS; INSERTAR TEXTO ("FIN"); } En la Figura 7B, la transacción_1 704, la transacción_2 706, y la transacción_3 708 transitan al estado de ejecución 710. Como se ilustró, la transacción_1 704 ejecuta las operaciones incluidas al insertar textos ("1 y 2") en la presentación (por ejemplo, una interfase de usuario 428) a un usuario 430. Mientras esta en el estado de ejecución 710, un evento defectuoso 722 ó una excepción ocurrió. El evento defectuoso 722 puede incluir una notificación de advertencia para datos faltantes, una falla de ejecución, o un acceso inexacto para un almacenamiento de datos, o similares. En este ejemplo, la transacción_1 704 incluye una función de controlar Falla () 716 para controlar el evento de falla 722. En una modalidad, la función de controlar Falla 716 parece una función de "atrapar" para control de falla en otros ambientes de ejecución, tal como un sistema operativo o un ambiente de ejecución manejado. Como tal, la propagación de falla o distribución a la función de controlar Falla 716 ó el controlador de "atrapar" es asincrónico. Con la ocurrencia del evento de falla 722, la transacción_1 704 transita a un estado defectuoso 712, y la transacción_1 704 transita a un estado cerrado 714. En una modalidad, al responder al evento defectuoso 722, la función de controlar Falla () 716 se llama y se coloca en una fila (no mostrada) para procesamiento.

Con este protocolo bien definido para propagación de excepción y control, las modalidades alternativas pueden controlar múltiples excepciones, y múltiples excepciones pueden programarse mientras la propagación de excepciones puede separarse con la ejecución de programa normal. En la Figura 7C, la transacción_2 706 y la transacción 708 están en el estado de ejecución 710. Similar a la ejecución de la transacción_1 704, la transacción_2 706 ejecuta las operaciones incluidas. En este ejemplo, los textos ("3 y 4") se insertan en la presentación. Además, la transacción_2 706 también incluye una función de control de Falla () similar como la función de controlar Falla () 716 en la transacción_1 704 para controlar el evento defectuoso 722. En una modalidad alternativa, la función de controlar Falla () 716 puede propagar o transmitir una notificación 720 a los artículos de trabajo restantes en el estado de ejecución 710 como una función de la jerarquía de ejecución o la estructura jerárquica de ejecución de la actividad. Por ejemplo, mientras la transacción_1 704 está en un estado defectuoso 712, la función de controlar Falla () 716 puede propagar la notificación 720 (por ejemplo, una función de "arrojar") para que la función de controlar Falla () de la Actividad_1 702 padre pueda controlarse como si la notificación 720 fuera un evento defectuoso o una excepción. En una modalidad, la actividad hijo puede limitar el objetivo de la función de arrojar a su padre en el árbol de actividad. En otra modalidad, el control de excepción puede estar altamente asociado con o unido a la estructura similar a árbol de actividades. Al establecer el estado defectuoso 712 para controlar eventos de falla, las modalidades de la invención permiten control de falla asincrónico o control de excepción, y los artículos de trabajo restantes o actividades en el estado de ejecución 710 continúan ejecutándose. Además, otras modalidades alternativas permiten la programación de eventos de falla de control. Por ejemplo, al responder a la notificación 720, la transacción_ 2 706 puede colocarse en una fila de programador 718 antes de transitar al estado de falla 712. En otra modalidad, la notificación 720 puede suprimirse para que otros artículos de trabajo o actividades en el estado de ejecución 710 continúen ejecutándose. En una modalidad, la transacción_1 704 transita a un estado cerrado 714 después de propagar o transmitir la notificación 720. Incluso en otra modalidad, la preparación de falla y controlar la supervivencia y espacio a través de ciclos de pasivación. En la Figura 7D, la transacción_3 708 se ejecuta en el estado de ejecución 710. Por ejemplo, las operaciones incluidas de la transacción_3 708 insertan los textos "(5 y 6") y pausa 180 segundos antes de insertar el texto ("FIN") en la presentación. Las operaciones incluidas sin embargo, no incluyen funciones para control defectuoso. Como tal, con el término de las operaciones incluidas, la transacción_3 708 transita al estado cerrado 714 en la Figura 7E. Además, la transacción_2 706 también transita al estado cerrado 714 después de sacarse de la fila de la fila de programador 718 al estado defectuoso 712. Sin limitaciones, el Apéndice A ¡lustra una implementación ilustrativa de elevar declarativamente una excepción de acuerdo con una modalidad de la invención. En una modalidad, los programadores o desarrolladores pueden diseñar un controlador de falla o controlar un tipo particular de eventos de falla o excepciones. Incluso en otra modalidad, los artículos de trabajo o actividades en el flujo de trabajo pueden incluir una función o ser incapaces de controlar eventos defectuosos. En esta modalidad, el ambiente de ejecución de flujo de trabajo controla los eventos defectuosos. Incluso en otra modalidad, pueden proporcionarse una o más operaciones de control de pos-falla al usuario a través de la Ul 428 al usuario 430 en la Figura 4. Mientras las Figura 7A a 7E ilustran instantáneas del estado o partes de ejecución del autómata de estado secuencialmente (por ejemplo, las transacciones se ejecutan secuencialmente), los artículos de trabajo en el estado de ejecución pueden procesarse simultánea o substancialmente de forma simultánea sin apartarse del alcance de la invención. La Figura 8 es un diagrama de flujo que ilustra un método para controlar asincrónicamente un evento defectuoso para una actividad de un flujo de trabajo de acuerdo con una modalidad de la invención. Por ejemplo, el método ilustrado en la Figura 8 puede representarse como instrucciones ejecutables por computadora para almacenarse en un medio legible por computadora como se muestra en la Figura 9. Por ejemplo, una máquina de estado 902 define un autómata de estado (por ejemplo, autómata de estado 600) para una actividad en 802, y el autómata de estado incluye al menos un estado de ejecución un estado defectuoso, y un estado cerrado. Un componente de actividad 904 define la actividad para incluir una pluralidad de artículos de trabajo en 804. La actividad definida tiene una jerarquía de ejecución de una secuencia de ejecución (por ejemplo, una estructura de árbol) para la pluralidad de artículos de trabajo. Cada uno de los artículos de trabajo que incluyen una operación para ejecutar una porción de la actividad. Un componente de programador 906 transita a cada uno de los artículos de trabajo al estado de ejecución en 806. Un componente de ejecución 908 ejecuta operación incluida de los artículos de trabajo transitados en el estado de ejecución en 808. En 810, un componente de identificación 910 identifica uno o más de los artículos de trabajo transitados en respuesta al evento defectuoso basándose en la jerarquía de ejecución y la operación incluida. En 812, un controlador de falla 912 controla asincrónicamente el evento de falla al invocar una operación de control de falla (por ejemplo, la función de Control de falla () 716) en uno o más artículos de trabajo identificados para transitar uno o más artículos de trabajo identificados al estado defectuoso mientras se ejecuta la operación incluida de los artículos de trabajo transitados restantes no identificados en respuesta al evento defectuoso por el componente de identificación. En una modalidad, el controlador de falla 912 controla asincrónicamente el evento defectuoso al transitar uno o más artículos de trabajo identificados al estado defectuoso. Incluso en otra modalidad, el controlador de falla 912 controla asincrónicamente el evento defectuoso al formar uno o más artículos de trabajo identificados en una fila de programador (por ejemplo, fila de programador 718). En una modalidad alternativa, el medio legible por computadora 900 además incluye un componente de propagación de falla 914 para transmitir una notificación de uno o más artículos de trabajo identificados a los artículos de trabajo transitados restantes como una función de la jerarquía de ejecución de la actividad. La notificación 720 indica que uno o más artículos de trabajo identificados están en el estado defectuoso. En una modalidad adicional, el medio legible por computadora 900 además incluye un componente de transición 916 para transitar los artículos de trabajo transitados restantes del estado de ejecución al estado defectuoso en respuesta a la notificación transmitida. El medio legible por computadora también puede incluir un componente de compensación 918 para recuperar o compensar datos asociados con la actividad como una función del control asincrónicamente del evento defectuoso incluso en otra modalidad alternativa. Un componente de inhibición también puede ser parte del medio legible por computadora 900 para suprimir la transmisión de la notificación a los artículos de trabajo transitados restantes.

Aunque se describió en conexión con un ambiente de sistema de cómputo ilustrativo, tal como el sistema 400 en la Figura 4. las modalidades de la invención son operacionales con numerosos otros ambientes o configuraciones de sistemas de cómputo de propósito general o de propósito especial. El ambiente de sistema de cómputo no pretende sugerir ninguna limitación al alcance de uso o funcionalidad de cualquier aspecto de la invención. Además, el ambiente de sistema de cómputo no debe interpretarse como teniendo ninguna dependencia o requerimiento que se relaciona con cualquiera o combinación de componentes ilustrados en la ambiente operativo ilustrativo. Ejemplos de sistemas de cómputo bien conocidos, ambientes, y/o configuraciones que pueden ser adecuados para uso con aspectos de la invención incluyen, pero no se limitan a, computadoras personales, computadoras de servidor, dispositivos móviles o portátiles, sistemas de multiprocesador, sistemas a base de microprocesador, cajas de tv por cable, electrónica de consumidor programable, teléfonos móviles, PCs de red, minicomputadoras, macrocomputadoras, ambientes de cómputo distribuidos que incluyen cualquiera de los sistemas o dispositivos anteriores, y similares. Las modalidades de la invención pueden describirse en el contexto general de instrucciones ejecutables por computadora, tal como módulos de programa, ejecutados por una o más computadoras u otros dispositivos generalmente, los módulos de programa incluyen, pero no se limitan a, rutinas, programas, objetos, componentes y estructuras de datos que realizan tareas particulares o implementan tipos de datos abstractos particulares. Los aspectos de la invención también pueden practicarse en ambientes de cómputo distribuidos en donde las tareas se realizan por dispositivos de procesamiento remoto que se enlazan a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programa pueden localizarse tanto en medios de almacenamiento por computadora local y remota que incluyen dispositivos de almacenamiento de memoria. En operación, el sistema 400 ejecuta instrucciones ejecutables por computadora tal como aquellas ilustradas en las figuras, tal como Figura 8, para implementar aspectos de la invención. El orden de ejecución o desempeño de las operaciones en las modalidades de la invención ilustradas y descritas aquí no es esencial, al menos que se especifique de otra forma. Es decir, las operaciones pueden realizarse en cualquier orden, a menos que se especifique de otra forma, y las modalidades de la invención pueden incluir operaciones adicionales o menores que aquellas descritas aquí. Por ejemplo, se contempla que ejecutar o realizar una operación particular antes, contemporáneamente con, o después de otra operación está dentro del alcance de aspectos de la invención.

Las modalidades de la invención pueden implementarse con instrucciones ejecutables por computadora. Las instrucciones ejecutables por computadora pueden organizarse en uno o más componentes o módulos ejecutables por computadora. Los aspectos de la invención pueden implementarse con cualquier número y organización de tales componentes o módulos. Por ejemplo, los aspectos de la invención no se limitan a las instrucciones ejecutables por computadora específicas o los componentes o módulos específicos ilustrados en la figuras y descritos aquí. Otras modalidades de la invención pueden incluir diferentes instrucciones o componentes ejecutables por computadora que tienen más o menos funcionalidad que la ilustrada y descrita aquí. Cuando se introducen elementos de aspectos de la invención a las modalidades de los mismos, los artículos "un", "uno", "el", y "dicho" pretende significar que existen uno o más de los elementos. Los términos "que comprenden", "que incluye", y "que tiene" pretenden ser inclusivos y significar que puede haber elementos adicionales diferentes a los elementos enlistados. Al haber descrito aspectos de la invención en detalle, será evidente que son posibles modificaciones y variaciones sin apartarse del alcance de aspectos de la invención como se definió en las reivindicaciones anexas. Mientras pueden hacerse varios cambios en las construcciones, productos, y métodos anteriores sin apartarse del alcance de aspectos de la invención, se pretende que todo el tema contenido en la descripción anterior y mostrado en los dibujos anexos debe interpretarse como ilustrativo y no en un sentido limitante.

APENDICE A <misActividades: Secuencia x:Nombre = "m¡FlujodeTrabajo" x:Clase = "miAp.m¡Flujodetrabajo" xmlns:misActividades = " http://esquemas.com/misActividades" xmlns = x"http:// esquemas, microsoft.com/winfx/2006/xaml" xmlns = "http://esquemas.microsofr.com/winfx/2006/xaml/flujode trflujo"> <misActividades:EscribirLinea Texto = "Uno"/> <misAct¡v¡dades:Escr¡b¡rl_ínea Texto = "Dos"/> <ArrojarActividad Ti pode Falla = "{x: Tipo ExcepcióndeOperaciónlnválida}'7> <misActividades:EscribirLínea Texto = "Código lnalcanzable"/> <Actividad de Controladores de F a 11 a > <Actividad de Controlador de Falla Tipo de Falla = "x{:Tipo Excepción de Operación Inválida} "> <misActividades:EscribirLínea Texto = "Tres'7> </Actividad de Controlador de Fa I la > <Actividad de Controlador de Falla Tipo de Falla = "{x: Tipo Excepción Descargada de dominio Ap}"> <misActividades: EscribirLínea Texto = " Cuatro"/> </Actividad de Controlador de F a 11 a > </Actividad de Controladores de F a 11 a > </mísActividades:Secuencia> <misActividades: Secuencia x:Nombre = "miflujodeTrabajo" x:Clase = "miAp.m¡FlujodeTrabajo" xmlns:misActividades = "http://esquemas.com/rriisActividades'' xmlns:x = "http://esquemas.microsoft.com/winfx/2006/xamr xmlns = ''http://esquemas.microsoft.com/winfx/2006/xaml/flujode trabajo"> <misActividades: EscribirLínea Texto = "Hola Mundo"/> <ArrojarActi vidad Tipo de Falla = "{x:Tipo Excepción de Operación lnválida}"/> <misActividades: EscribirLínea Texto = "Código No Alcanzable"/> </mis Actividades:Secuencia>

Claims

REIVINDICACIONES

1.- Un método para controlar asincrónicamente un evento defectuoso (722) para una actividad de un flujo de trabajo, dicho método comprende: definir un autómata de estado (600) para una actividad (702), dicho autómata de estado (600) incluyendo al menos un estado de ejecución (604), un estado defectuoso (608), y un estado cerrado (612), dicho autómata de estado (600) clasificando un tiempo de vida de ejecución de la actividad (702); definir la actividad (702) para incluir una pluralidad de artículos de trabajo (422), dicha actividad definida (702) tiene una jerarquía de ejecución (500) para la pluralidad de artículos de trabajo (422), cada uno de los artículos de trabajo (422) incluye una operación para ejecutar una porción de la actividad (702); transitar cada uno de los artículos de trabajo (422) al estado de ejecución (604) ; ejecutar la operación incluida de los artículos de trabajo transitados (422) en el estado de ejecución (604); identificar uno o más de los artículos de trabajo transitados en respuesta al evento defectuoso (722) como una función de la jerarquía de ejecución (500) y la operación incluida; y controlar asincrónicamente el evento defectuoso (722) al transitar a uno o más artículos de trabajo identificados (422) al estado defectuoso (608) mientras se ejecuta la operación incluida de los artículos de trabajo transitados restantes no identificados en respuesta al evento defectuoso (608).

2. - El método de acuerdo con la reivindicación 1 , en donde controlar asincrónicamente el evento defectuoso (722) comprende invocar una operación de control de falla en uno o más artículos de trabajo identificados (422).

3. - El método de acuerdo con la reivindicación 2, en donde invocar la operación de control de falla comprende formar una fila de uno o más artículos de trabajo identificados en una fila de programador (718). 4 - El método de acuerdo con la reivindicación 1, que además comprende propagar una notificación (720) de uno o más artículos de trabajo identificados (422) a los artículos de trabajo transitados restantes (422) como una función de la jerarquía de ejecución (500) de la actividad (702), dicha notificación (720) indicando que uno o más de los artículos de trabajo identificados (422) están en el estado defectuoso (608). 5. - El método de acuerdo con la reivindicación 4, que además comprende transitar los artículos de trabajo transitados restantes (422) del estado de ejecución (604) al estado defectuoso (608) en respuesta a la notificación propagada (720). 6. - El método de acuerdo con la reivindicación

4. que además comprende suprimir la propagación de la notificación (720) a los artículos de trabajo transitados restantes (422). 7.- El método de acuerdo con la reivindicación 1, que además comprende proporcionar operaciones a un usuario para control de pos-falla en respuesta a uno o más artículos de trabajo identificados (422) que transitan al estado defectuoso (608). 8 - El método de acuerdo con la reivindicación 1, en donde uno o más medios legibles por computadora tienen instrucciones ejecutables por computadora para realizar el método de acuerdo con la reivindicación 1. 9.- Un sistema (400) para asincrónicamente controlar eventos defectuosos (722) en un flujo de trabajo, dicho sistema (400) comprende: un almacenamiento (404) para almacenar datos asociados con artículos de trabajo de una actividad (406) en el flujo de trabajo, dicha actividad (406) teniendo una jerarquía de ejecución (500) para los artículos de trabajo (422), cada uno de los artículos de trabajo (422) incluyen una operación para ejecutar una porción de la actividad (406); un procesador (402) configurado para ejecutar instrucciones ejecutables por computadora para: definir un autómata de estado (600) para la actividad (406), dicho autómata de estado (600) incluyendo al menos un estado de ejecución (604), un estado defectuoso (608), y un estado cerrado (612), dicho autómata de estado (600) clasificando un tiempo de vida de ejecución de la actividad (406); transitar cada uno de los artículos de trabajo (422) al estado de ejecución (604); ejecutar la operación incluida de los artículos de trabajo transitados (422) en el estado de ejecución (604); identificar uno o más de los artículos de trabajo transitados (422) en respuesta a un evento defectuoso (608) basándose en la jerarquía de ejecución (500) y la operación incluida; y controlar asincrónicamente el evento defectuoso (722) al transitar uno o más artículos de trabajo identificados (422) al estado defectuoso (608) mientras se ejecuta la operación incluida de los artículos de trabajo transitados restantes (422) no identificados en respuesta al evento defectuoso (722). 10. - El sistema (400) de acuerdo con la reivindicación 9, en donde el procesador (402) se configura para controlar asincrónicamente el evento defectuoso (722) utilizando uno o más del siguiente método: al invocar una operación de control de falla en uno o más artículos de trabajo identificados (422), y al formar una fila de uno o más artículos de trabajo identificados (422) en una fila de programador (718). 11. - El sistema (600) de acuerdo con la reivindicación 9, que además comprende un componente para propagar una notificación (720) de uno o más artículos de trabajo identificados a los artículos de trabajo transitados restantes (422) como una función de la jerarquía de ejecución (500) de la actividad (406), dicha notificación (720) indicando que uno o más de los artículos de trabajo identificados (422) están en el estado defectuoso (608). 12.- El sistema (400) de acuerdo con la reivindicación 11, que además comprende un componente para transitar los artículos de trabajo transitados restantes del estado de ejecución (604) el estado defectuoso (608) en respuesta a la notificación propagada (720). 13. - El sistema (400) de acuerdo con la reivindicación 9, que además comprende un componente para compensar datos de recuperación asociados con la actividad del almacenamiento (404) como una función del control asincrónicamente del evento defectuoso (722) por el procesador (402). 14. - El sistema (400) de acuerdo con la rei indicación 9, que además comprende un componente para suprimir la propagación de la notificación (720) a los artículos de trabajo transitados restantes (422). 1

5. - Uno o más medios legibles por computadora (900) que tienen componentes ejecutables por computadora para controlar asincrónicamente un evento defectuoso (722) en un flujo de trabajo, dichos componentes ejecutables por computadora comprenden: una máquina de estado (902) para definir un autómata de estado (600) para una actividad (406), dicho autómata de estado (600) incluye al menos un estado de ejecución (604), un estado defectuoso (608), y un estado cerrado (612), dicho autómata de estado (600) clasificando un tiempo de vida de ejecución de la actividad (406); un componente de actividad (904) para definir la actividad (406) para incluir una pluralidad de artículos de trabajo (422), dicha actividad definida (406) teniendo una jerarquía de ejecución (500) para la pluralidad de artículos de trabajo (422), cada uno de los artículos de trabajo (422) incluye una operación para ejecutar una porción de la actividad (406); un componente de programador (906) para transitar cada uno de los artículos de trabajo (422) al estado de ejecución (604); un componente de ejecución (908) para ejecutar la operación incluida de artículos de trabajo transitados (422) en el estado de ejecución (604) ; un componente de identificación (910) para identificar uno o más de los artículos de trabajo transitados en respuesta al evento defectuoso (722) basándose en la jerarquía de ejecución (500) y la operación incluida; y un controlador de falla (912) para controlar asincrónicamente el evento defectuoso (722) al invocar una operación de control de falla en uno o más artículos de trabajo identificados (422) para transitar uno o más artículos de trabajo identificados (422) al estado defectuoso (608) mientras se ejecuta la operación incluida de los artículos de trabajo transitados restantes (422) no identificados en respuesta al evento defectuoso (722) por el componente de identificación (910). 1

6.- El medio legible por computadora (900) de acuerdo con la reivindicación 15, en donde el controlador de falla (912) forma una fila de uno o más de los artículos de trabajo identificados (422) en una fila de programador (718) para transitar uno o más artículos de trabajo identificados al estado defectuoso (608). 17 - El medio legible por computadora (900) de acuerdo con la reivindicación 15, que además comprende un componente de propagación de falla (914) para transmitir una notificación (720) de uno o más artículos de trabajo identificados (422) a los artículos de trabajo transitados restantes (422) como una función de la jerarquía de ejecución (500) de la actividad (406), dicha notificación (720) indicando que uno o más artículos de trabajo identificados (422) está en el estado defectuoso (608). 18. - El medio legible por computadora (900) de acuerdo con la reivindicación 17, que además comprende un componente de transición (916) para transitar los artículos de trabajo transitados restantes del estado de ejecución (604) al estado defectuoso (608) en respuesta a la notificación transmitida (720). 19. - El medio legible por computadora (900) de acuerdo con la reivindicación 15, que además comprende un componente de compensación (918) para recuperar datos asociados con la actividad (406) como una función de controlar asincrónicamente el evento defectuoso (608). 20. - El medio legible por computadora (900) de acuerdo con la reivindicación 15, que además comprende un componente de inhibición (920) para suprimir la transmisión de la notificación 720 a los artículos de trabajo transitados restantes.