Abstract: A system and method of using metrics to control throttling and swapping in a message processing system is provided. A workload status of a message processing system is determined, and the system polls for a new message according to the workload status. The message processing system identifies a blocked instance and calculates an expected idle time for the blocked instance. The system dehydrates the blocked instance if the expected idle time exceeds a predetermined threshold.

Abstract: An XLANG/s compiler detects convoy scenarios during compilation and generates runtime directives to correctly correlate incoming messages with business process instances. A convoy scenario, present in event driven processes, is defined by a correlation set initialized during a receive operation which is provided to a subsequent receive operation. The compiler detects those convoy scenarios by analyzing the control and dataflow of a XLANG/s program. Three convoy patterns are distinguished: (1) activation convoys, (2) uniform sequential convoys, and (3) non-uniform sequential convoys. XLANG/s allows declarative descriptions of convoy scenarios without requiring an understanding of the low-level details supporting their correct execution. Convoy scenarios are processed by statically analyzing a written workflow application to deduce the nature and type of convoy scenarios used by the application. Information is extracted at compile time to support the runtime infrastructure.

Abstract: An XLANG/s compiler detects convoy scenarios during compilation and generates runtime directives to correctly correlate incoming messages with business process instances. A convoy scenario, present in event driven processes, is defined by a correlation set initialized during a receive operation which is provided to a subsequent receive operation. The compiler detects those convoy scenarios by analyzing the control and dataflow of a XLANG/s program. Three convoy patterns are distinguished: (1) activation convoys, (2) uniform sequential convoys, and (3) non-uniform sequential convoys. XLANG/s allows declarative descriptions of convoy scenarios without requiring an understanding of the low-level details supporting their correct execution. Convoy scenarios are processed by statically analyzing a written workflow application to deduce the nature and type of convoy scenarios used by the application. Information is extracted at compile time to support the runtime infrastructure.

Abstract: A XLANG/s compiler recognizes a statement in XLANG/s code to make an assumption as to the success or failure of a specified transaction. The assignment states of variables are tracked and changes to such states are recorded. While processing XLANG/s code, the compiler determines whether the assignment state of a particular correlation, operation or the like is correct for the transaction being performed. If not, the compiler may generate an error message. Moreover, by using declarative assumptions such as if(succeeded(T)) or if(!succeeded(T)), definite-assignment analysis of shared state variables may cross transactional boundaries.

Abstract: Systems and methods that implement interactivity as part of a workflow itself. Data is passed in and out of the workflow to form an interactive workflow, via employing an interactive activity component. Such interactive activity component models suspension points within a workflow definition, wherein user input and associated interaction can be supplied to the workflow during various interactivity breaks that request user input. Such an arrangement enables a controlled/synchronous data exchange between the workflow and a host application associated therewith.

Abstract: Systems and methods that supply workflow management and workflow interaction with a plurality of persistence stores via employing a routing persistence service and an association lookup component. The routing persistence service routes and/or assigns each workflow instance to a corresponding persistence store, and the association lookup component manages caching associations between the workflow instance(s) and the plurality of persistence services. Accordingly, the subject innovation facilitates an extensible and/or pluggable mechanism for concurrent usage of multiple concrete implementations of a generic abstract workflow provider.

Abstract: Systems and methods that objectify view of workflows and management behavior via an access component that supplies access to the real workflow instance. The subject innovation enables custom features to be defined for interaction during run time. For example, custom features (e.g., strongly typed workflow) can include, a method(s), an event(s), a proper(ies), an interface and the like. Accordingly, the workflow can be exposed as an object type or class, wherein new members can be added and the workflow extended.

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: Workflow management for maintaining consistency of persisted state across communicating components via batching of uncommitted work. A workflow component defines a workflow containing work items to be performed by service provider components. The workflow component assigns the work items to the service provider components, and the service provider components acknowledge the assigned work items. The workflow component appends the assigned work items to a work batch. The workflow component creates a transaction containing the batched work items. The workflow component commits to the workflow by requesting the service provider components to perform the work items. The workflow component checks the state of the execution of the work items and stores the state in a persistent storage.

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: A system and method of using metrics to control throttling and swapping in a message processing system is provided. A workload status of a message processing system is determined, and the system polls for a new message according to the workload status. The message processing system identifies a blocked instance and calculates an expected idle time for the blocked instance. The system dehydrates the blocked instance if the expected idle time exceeds a predetermined threshold.

Abstract: A system and method of processing a message in an asynchronous architecture is provided. In the method, a determination is made that a response to a message sent by an instance of software code is to be received, where the response indicates whether the message succeeded or failed. Another determination is made as to whether the response has been received. If the response has not been received, the instance of the software code is stored in memory, thereby suspending the instance. The response is received, the instance resumed and the response is processed.

Abstract: An XLANG/s compiler detects convoy scenarios during compilation and generates runtime directives to correctly correlate incoming messages with business process instances. A convoy scenario, present in event driven processes, is defined by a correlation set initialized during a receive operation which is provided to a subsequent receive operation. The compiler detects those convoy scenarios by analyzing the control and dataflow of a XLANG/s program. Three convoy patterns are distinguished: (1) activation convoys, (2) uniform sequential convoys, and (3) non-uniform sequential convoys. XLANG/s allows declarative descriptions of convoy scenarios without requiring an understanding of the low-level details supporting their correct execution. Convoy scenarios are processed by statically analyzing a written workflow application to deduce the nature and type of convoy scenarios used by the application. Information is extracted at compile time to support the runtime infrastructure.

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: A XLANG/s compiler recognizes a statement in XLANG/s code to make an assumption as to the success or failure of a specified transaction. The assignment states of variables are tracked and changes to such states are recorded. While processing XLANG/s code, the compiler determines whether the assignment state of a particular correlation, operation or the like is correct for the transaction being performed. If not, the compiler may generate an error message. Moreover, by using declarative assumptions such as if(succeeded(T)) or if(!succeeded(T)), definite-assignment analysis of shared state variables may cross transactional boundaries.