Abstract: Declaratively canceling execution of an activity. A state automaton for an activity is defined, and the state automaton includes an executing state, a canceling state, and a closed state and classifies an execution lifetime of the activity. The activity includes work items and organizes the work items in an execution hierarchical structure. The work items are transitioned from the executing state to the closed state indicating a completion of executing the each work item of the activity. Upon having one of the work items being transitioned to the closed state, a cancellation request is transmitted to the work items currently in the executing state. The executing work items are identified as a function of the transmitted cancellation request and the execution hierarchical structure of the defined activity. The execution lifetime of the activity is canceled by transitioning the identified work items from the executing state to the canceling state.

Abstract: Asynchronous fault handling for a workflow. A state automaton for an activity in the workflow is defined. The state automaton includes at least an executing state, a faulting state, and a closed state and classifies an execution lifetime of the activity. The activity is defined to include work items and includes an execution hierarchy for the work items. Each work item includes an operation for executing a portion of the activity. Each work item is transitioned to the executing state. The included operation of transitioned work items is executed in the executing state. One or more of the transitioned work items are identified in response to the faulting event as a function of the execution hierarchy and the included operation. The faulting event is asynchronously handled by transitioning the one or more identified work items to the faulting state while executing the included operation of the remaining transitioned work items.

Abstract: Implementing synchronization among threads in a workflow. A memory area stores a plurality of work items in a scheduler queue. The work items are associated with an activity in the workflow, and each work item is associated with a thread. A processor is configured to assign a synchronization handle to each of the work items. The synchronization handle indicates a particular shared resource to be accessed by the work items. A token value is computed for each work item based on the assigned synchronization handle and the work items in a hierarchy in the activity. The work items are sorted in a synchronization queue based on the token value associated with each work item. The processor sequentially executes each of the sorted work items in the synchronization queue to serialize the access to the particular shared resource and effects a synchronous execution of the threads associated with the work items.

Abstract: Providing data bound workflow activities to model messaging between a workflow instance and a workflow host. The workflow author associates a data source with each data bound activity in a workflow without specifying details of the underlying messaging technology. The data bound activity in the workflow instance communicates with a data source service in the workflow host to exchange data.

Abstract: Workflow debugging. A debug engine integrated with an external development tool debugging framework sets breakpoints directly on workflow activities and stops execution of the workflow at each of the breakpoints. The state of the workflow activity at the breakpoint is displayed. The debug engine extracts source code of the workflow for debugging at the source code level.

Abstract: Large messages in the form of hierarchically structured documents are processed in a streaming fashion using the ultimate consumer read requests as the driving force for the processing. The messages are partitioned into fixed length segments. The segments are processed in pipeline fashion. This processing chain includes simulating random access of hierarchical documents using stream transformations, mapping streams to a transport's native capabilities, composing streams into chains and using pipeline processing on the chains, staging fragments into a database and routing messages when complete messages have been formed, and providing tools to allow the end user to inspect partial messages.

Abstract: Large messages in the form of hierarchically structured documents are processed in a streaming fashion using the ultimate consumer read requests as the driving force for the processing. The messages are partitioned into fixed length segments. The segments are processed in pipeline fashion. This processing chain includes simulating random access of hierarchical documents using stream transformations, mapping streams to a transport's native capabilities, composing streams into chains and using pipeline processing on the chains, staging fragments into a database and routing messages when complete messages have been formed, and providing tools to allow the end user to inspect partial messages.

Abstract: An ink-enabled user interface for building a componentized workflow model. A touch screen display device allows each step of the workflow to be modeled as an activity that has metadata to describe design time aspects, compile time aspects, and runtime aspects of the workflow step. A user selects and arranges the activities via the touch screen device to create the workflow via user interfaces or application programming interfaces. The metadata associated with each of the activities in the workflow is collected to create a persistent representation of the workflow. Users extend the workflow model by authoring custom activities.

Abstract: A user interface for building a componentized workflow model. Each step of the workflow is modeled as an activity that has metadata to describe design time aspects, compile time aspects, and runtime aspects of the workflow step. A user selects and arranges the activities to create the workflow via the user interface. The metadata associated with each of the activities in the workflow is collected to create a persistent representation of the workflow. Users extend the workflow model by authoring custom activities.

Abstract: Building a componentized workflow model. Each step of the workflow is modeled as an activity that has metadata to describe design time aspects, compile time aspects, and runtime aspects of the workflow step. A user selects and arranges the activities to create the workflow via user interfaces or application programming interfaces. The metadata associated with each of the activities in the workflow is collected to create a persistent representation of the workflow. Users extend the workflow model by authoring custom activities. The workflow may be compiled and executed.

Abstract: Building a componentized workflow model via an application programming interface. Each step of the workflow is modeled as an activity that has metadata to describe design time aspects, compile time aspects, and runtime aspects of the workflow step. A user selects and arranges the activities to create the workflow via the application programming interfaces. The metadata associated with each of the activities in the workflow is collected to create a persistent representation of the workflow. Users extend the workflow model by authoring custom activities. Users also compile the workflow via the application programming interface.

Abstract: Transport agnostic pull mode messaging service enables clients of diverse types to send and receive messages to one another while guaranteeing delivery of messages. Client specific adapters connect to a server and pull messages waiting for them in a queue. Clients may specify themselves as the recipients of the pulled messages, or specify another client as a recipient. This allows users of diverse types of clients to communicate and provides users with greater flexibility regarding how, when, and where they view their messages.

Abstract: The present invention relates to systems and methods that facilitate pulling and/or receiving data from a client and posting the data for access by subscribing systems. The systems and methods include a message agent that generates a connection instance that can store connection-related information such as data conveyance state, data identification, and connection identification. Access to the connection instance can be provided to a machine, which can utilize the information to lock the connection and connection instance and begin pulling or receiving data from the client. As the machine pulls or receives data, the data can be published and the connection instance can be concurrently updated to reflect the present state of data conveyance. The information within the connection instance can be utilized to re-establish of severed connection, and to dynamically float the connection between machines to dynamically balance load, ensure reliability and recover from errors.

Abstract: The present invention provides a novel technique for Web-based asynchronous processing of synchronous requests. The systems and methods of the present invention utilize a synchronous interface in order to couple with systems that synchronously communicate (e.g., to submit queries and receive results). The interface enables reception of synchronous requests, which are queued and parsed amongst subscribed processing servers within a server farm. Respective servers can serially and/or concurrently process the request and/or portions thereof via a dynamic balancing approach. Such approach distributes the request to servers based on server load, wherein respective portions can be re-allocated as server load changes. Results can be correlated with the request, aggregated, and returned such that it appears to the requester that the request was synchronously serviced. The foregoing mitigates the need for clients to perform client-side aggregation of asynchronous results.

Abstract: The present invention supports the design of a process using a drawing surface that specifies the process with underlying programmatic constructs. In response to a user's command, a construct corresponding to a shape is selected from a palette and inserted onto a design region that shows the specified process. The command is verified to be consistent with semantics of an associated process type. If so, a visual image of the specified process is updated. If not, an indicator is generated in a proximity of a relevant portion of the visual image in order to help the user resolve the inconsistency. The user is able to correct errors before generating computer-executable instructions from a high-level code emission. Computer-executable instructions are also generated from high-level code emission. A process engine is cognizant of the associated high-level lines of code and an infrastructure knowledge base while executing the computer-executable instructions.

Abstract: Large messages in the form of hierarchically structured documents are processed in a streaming fashion using the ultimate consumer read requests as the driving force for the processing. The messages are partitioned into fixed length segments. The segments are processed in pipeline fashion. This processing chain includes simulating random access of hierarchical documents using stream transformations, mapping streams to a transport's native capabilities, composing streams into chains and using pipeline processing on the chains, staging fragments into a database and routing messages when complete messages have been formed, and providing tools to allow the end user to inspect partial messages.