Abstract: Techniques are described herein that are capable of executing a computer program in accordance with a declarative dynamic control flow in a continuation-based runtime. A declarative dynamic control flow identifies a set of continuations. A representation of logic that corresponds to the declarative dynamic control flow is provided in accordance with execution of the computer program in the continuation-based runtime. The declarative dynamic control flow identifies a set of continuations. Each continuation identifies a respective rule, which defines a respective event, and a respective action, which is to be performed upon occurrence of the respective event. A determination is made that a specified event occurs. The set of continuations is dynamically modified based on occurrence of the specified event.

Abstract: Messages are processed based on a characteristic derived from information in messages, metadata about messages, or other information external to messages. Values for one or more pieces of information are received. At least one of the values for one or more pieces of information is associated with a first message. Queries are received. The queries specify one or more of the pieces of information. At least a portion of the plurality of values for the one or more pieces of information is processed in conjunction with the one or more queries to create one or more normalized characteristics for the first message. The one or more normalized characteristics for the first message are in a same format irrespective of the format of the pieces of information. The first message, and/or other messages, is processed based on at least one of the one or more normalized characteristics.

Abstract: Interaction between a client and a service in which the service responds to requests from the client. In addition to responding to specific client requests, the service also anticipates or speculates about what the client may request in the future. Rather than await the client request (that may or may not ultimately be made), the service provides the unrequested anticipatory data to the client in the same data stream as the response data that actual responds to the specific client requests. The client may then use the anticipatory data to fully or partially respond to future requests from the client, if the client does make the request anticipated by the service. Thus, in some cases, latency may be reduced when responding to requests in which anticipatory data has already been provided. The service may give priority to the actual requested data, and gives secondary priority to the anticipatory data.

Abstract: Embodiments are directed to generating trace events that are configured to report an association between a workflow activity and a message. A computer system receives a message over a communication medium, where the workflow activity includes a unique workflow activity identifier (ID) that uniquely identifies the workflow activity. The message also includes a unique message ID that uniquely identifies the message. The computer system generates a trace event that includes a combination of the unique workflow activity ID and the unique message ID. The trace event is configured to report the association between the workflow activity and the message. The computer system also stores the generated trace event in a data store.

Abstract: Embodiments are directed to interpreting declarative program types at runtime without compiling and mapping between a declarative type and a dynamic runtime type. A computer system accesses a portion of a declarative program, where the declarative program includes fully modeled activity types. The computer system dynamically constructs a dynamic activity type based on one of the fully modeled activity types of the declarative program, where the dynamic activity type is configured for interpretive execution without compilation. The computer system also interpretively executes the dynamically constructed dynamic activity type such that the dynamic activity is executed without compilation.

Abstract: Embodiments described herein provide for allowing processing code of a message to attach state thereto. More specifically, as a SOAP message is processed, various states known as properties (e.g., message security, message identifier, etc.) can be attached to the message for various purposes. In other words, embodiments provide for a properties object that represents a set of processing-level annotations to a message. These properties (representing the processing state of the headers or other portions of the message) can then be used by other component or modules for further processing purposes. Typically, these properties can then be removed (or sustained if desired) prior to transporting the SOAP message on the wire.

Abstract: The dispatching of messages from an incoming message pool to service instance(s). Message are received non-destructively and exclusively from the incoming message pool. If a particular service instance receives a message out of order, the processing of the message is deferred without releasing the exclusivity in the incoming message queue. Thus, the target service instance may continue to process one or more other messages until the target service instance is ready to process one or more deferred messages. In this way, messages may be pulled from the incoming message queue for dispatch to service instance(s), while maintaining correct order of processing, even if messages do not arrive into the incoming message queue in the correct order.

Abstract: Embodiments described herein are directed to allowing a user to extend the functionality of a software code interpretation system. In one embodiment, a computer system receives user-defined conversion rules from a user for converting dynamic language code to continuation-based abstract memory representations. The computer system identifies portions of software code that are to be converted from dynamic language abstract memory representations into continuation-based abstract memory representations, where the identified code portions include undefined, extensible input primitives. The computer system also generates a dynamic, extensible set of output primitives interpretable by a continuation-based code interpretation system using the received conversion rules and converts the identified code portions including the undefined, extensible input primitives from dynamic language abstract memory representations into continuation-based abstract memory representations using the generated set of output primitives.

Abstract: A computer system establishes an execution environment for executing activities in a continuation based runtime including instantiating an activity scheduler configured to perform the following: scheduling activities for execution in the CBR. The activity scheduler resolves the scheduled activity's arguments and variables prior to invoking the scheduled activity using the activity's unique context. The activity scheduler also determines, based on the activity's unique context, whether the scheduled activity comprises a work item that is to be queued at the top of the execution stack and, based on the determination, queues the work item to the execution stack. The computer system executes the work items of the scheduled activity as queued in the execution stack of the established execution environment in the CBR.

Abstract: Routing messages using unreliable routing data. A method includes receiving a message from a computer readable communication medium. Characteristic properties of the message are calculated so as to determine state requirements for a service instance at a service for processing of the message. An attempt is made to acquire an appropriate service instance that satisfies the state requirements for processing the message. A determination is made that attempting to acquire an appropriate service instance that satisfies the state requirements for processing the message is not successful at acquiring an appropriate service instance. As a result, the message is redirected using an unreliable local cache of routing information and without coordination between processing nodes.

Abstract: Persisting execution state of a continuation based runtime program. The continuation based runtime program includes static program data defining activities executed by the program. One or more of the activities are parent activities including sequences of child activities. The continuation based runtime program is loaded. A child activity to be executed is identified based on scheduling defined in a parent of the child activity in the continuation based runtime program. The child activity is sent to a continuation based runtime separate from one or more other activities in the continuation based runtime program. The child activity is executed at the continuation based runtime, creating an activity instance. Continuation state information is stored separate from the static program data by storing information about the activity instance separate from one or more other activities defined in the continuation based runtime program.

Abstract: A declarative program definition. The definition is analyzed to produce an application contract that describes semantics for sending and receiving application messages during the successful execution of operations by the program. In addition, this analysis may also generate local behaviors associated with the local execution of the program. Alternatively or in addition, the analysis may infer secondary contracts regarding the sending and receiving of application messages, even though the full details of the secondary contracts are not present in the declarative program definition. For instance, the secondary contracts might include error contracts or consistency contracts.

Abstract: Interaction between a client and a service in which the service responds to requests from the client. In addition to responding to specific client requests, the service also anticipates or speculates about what the client may request in the future. Rather than await the client request (that may or may not ultimately be made), the service provides the unrequested anticipatory data to the client in the same data stream as the response data that actual responds to the specific client requests. The client may then use the anticipatory data to fully or partially respond to future requests from the client, if the client does make the request anticipated by the service. Thus, in some cases, latency may be reduced when responding to requests in which anticipatory data has already been provided. The service may give priority to the actual requested data, and gives secondary priority to the anticipatory data.

Abstract: The dispatching of messages from an incoming message pool to service instance(s). Message are received non-destructively and exclusively from the incoming message pool. If a particular service instance receives a message out of order, the processing of the message is deferred without releasing the exclusivity in the incoming message queue. Thus, the target service instance may continue to process one or more other messages until the target service instance is ready to process one or more deferred messages. In this way, messages may be pulled from the incoming message queue for dispatch to service instance(s), while maintaining correct order of processing, even if messages do not arrive into the incoming message queue in the correct order.

Abstract: Partitioning continuation based runtime programs. Embodiments may include differentiating activities of a continuation based runtime program between public children activities and implementation children activities. The continuation based runtime program is partitioned into visibility spaces. The visibility spaces have boundaries based on implementation children activities. The continuation based runtime program is partially processes at a visibility space granularity.

Abstract: Embodiments described herein provide for an overall object mode that allows for a single message object to represent multiple messaging formats. A general message object is populated with fields for multiple available messaging formats, which can be appropriately filled with information with fields for both versions 1.1 and 1.2. Depending on which version is being used or desired, the appropriate fields can be populated when creating an instance of the message object. The other fields that do not correspond to that version, however, are left blank.

Abstract: Embodiments described herein provide for a message object that simultaneously exposes an XML view and Type view for a message infoset. In this embodiment, interaction with a message can occur using either an XML or Type application program interface (API), which are synced. More specifically, embodiments herein provide or expose a common set of headers (e.g., SOAP headers) as “typed” properties (e.g., CLR properties), which allow for getting and/or setting a value thereof. In other words, the Type API reads/writes values for typed properties without regard to how the message is encoded with XML. Moreover, the two APIs are synced such that a value can be set using one API and retrieved using the other. For example, an XML API may be used as a writing mechanism for interacting with a value, while the Type API can read that same value, and vise-versa.

Abstract: The present invention provides for an automated, user friendly way of constructing and using a binding object. A developer is presented with and selects binding elements that will ultimately be used to create a runtime communication channel for transporting a message between a client and service endpoint. After receiving the user input, metadata, a channel factory and listener factory are created. The metadata describes binding elements and provides an abstract representation of a protocol stack that implements communication aspects at runtime. The channel factory is configured to use the collection of metadata at runtime to generate the runtime communication channel. Further, the listener factory is configured to accept the runtime communication channel for de-multiplexing the communication aspects in order to process the message at a service endpoint. The present invention also provides for groupings of binding elements and standardized binding objects organized based on industry need.

Abstract: A declarative program definition. The definition is analyzed to produce an application contract that describes semantics for sending and receiving application messages during the successful execution of operations by the program. In addition, this analysis may also generate local behaviors associated with the local execution of the program. Alternatively or in addition, the analysis may infer secondary contracts regarding the sending and receiving of application messages, even though the full details of the secondary contracts are not present in the declarative program definition. For instance, the secondary contracts might include error contracts or consistency contracts.

Abstract: The present invention provides for a channel model capable of generating a runtime communication channel with pluggable modular channel components. These channel components implement one of a set of standard interfaces that allow processing details of communication semantics between components to be represented in a polymorphic way. A message and corresponding communication semantics are recursively passed through the channel components using the standard interface, thereby abstracting other modules and components from specific implementation details of how the communication semantics are performed. The message may then be sent to the next appropriate module for further processing, or the processing may be completed at that particular component or module. Note also that the message can also be de-multiplexed on the service side in a similar fashion as that described above.