Abstract: Activity callbacks in a continuation-based runtime. At framework-definition time, a framework activity is authored. The framework activity may have an environmental logic portion the processes input or output parameters whose values will be supplied to and/or received from an activity callback. The framework activity also includes a callback invocation portion that, during execution time, will actually provide parameter value(s) to and/or receive parameter value(s) from the activity callback. The framework activity serves as a framework that operates with any activity callback that has one or more characteristics. Such activity callbacks may not even be defined at framework-definition time. Instead, the framework activity may be used multiple times in the same applications, or in different applications to thereby provide core framework functionality, while allowing application developers to plug in activity callbacks that meet the custom needs of the application.

Abstract: Technologies for enabling a continuation based runtime to accept or reject external stimulus and, in addition, to determine if an external stimulus may be valid for processing at a later point in execution.

Abstract: Declarative definition and composition of activities of a continuation based runtime. When formulating such a declarative activity of a continuation-based runtime, the activity may be formulated in accordance with a declarative activity schema and include a properties portion that declaratively defines one or more interface parameters of the declarative activity, and a body portion that declaratively defines an execution behavior of the declarative activity. The declarative activities may be hierarchically structured such that a parent declarative activity may use one or more child activities to define its behavior, where one or more of the child activities may also be defined declaratively.

Abstract: Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination.

Abstract: Allowing a continuation based runtime to resolve different types of location expressions, value expressions, and/or locations. This may be accomplished using a different class for each particular type. The location expression classes may each have a common method used for all of the location expression classes. The value expression classes may each have a common method, and the locations may also each have a common method. This allows the resolution of such location and value expressions to be treated in a unified fashion regardless of the type of location expression, or the type of value expression. Also, the location may be treated in a unified manner regardless of the type of location.

Abstract: Dispatching an incoming message from a queue into message transfer session(s) from which message consumers may draw messages. The message is reversibly received from the queue, whereupon a context of a message is identified. If the context correlates to an existing message transfer session, the message is ultimately assigned to a message transfer session. If the context does not correlate to an existing message transfer session, a new message transfer session is created, and the message is assigned to that new message transfer session. Upon receiving an acknowledgement of successful processing of the message, the removal of the message from the queue-like communication medium is assured. Upon receiving an acknowledgement of unsuccessful processing of the message, the message is restored to the queue-like communication medium.

Abstract: A continuation based runtime participates in transactions that are not generated by the continuation based runtime, but rather are generated externally to the continuation based runtime. The continuation based runtime marshals in transaction data related to the pre-existing externally generated transaction. In one embodiment, the continuation based runtime itself may not do this, but perhaps may use a transaction enabled activity. Once the activity marshals in the data, the activity may request that the continuation based runtime enlist in the transaction, whereupon the continuation based runtime may then register and the transaction may be performed in the context of the continuation based runtime.

Abstract: Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination.

Abstract: Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination.

Abstract: Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination.

Abstract: Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination.

Abstract: Transport independent redirection. If a client computing system were to request a service from a service computing system, the service may determine whether or not the client should request the service from yet another service. If the client should request the service from the other computing system, the original service (or its intermediary) generates and transmits a transport-independent redirect message to the client. The client may then issue the request to the new service specified in the redirect response. The redirect message is not limited to a particular type of transport protocol. In addition, the redirect may be made possible in any number of message exchange patterns, not just request-response.

Abstract: Selectively modifying a message delivery requirement of a datagram message at an intermediary network node between an origin and a destination. A message delivery requirement is defined for a particular message. The message delivery guarantee defines how to transmit the particular message. A downgrading intent of the particular message is provided for the message at the origin. The downgrading intent of the particular message indicates that the message delivery requirement can be bypassed. The defined message delivery guarantee, the network delivery requirement, and the provided downgrading intent of the particular message are processed at the intermediate network node. The message delivery requirement of the particular message is ignored based on the provided downgrading intent. The message is delivered via a network protocol according to the provided downgrading intent.

Abstract: Described is a data model used in a continuation based runtime that executes activities. The data model provides for declaring parameters to define data flow direction (in, out or both in and out) with respect to activities. The model further allows for the declaring of variables to provide for data storing and sharing between activities that are in scope, based on a tree relationship between activities. In one aspect, an activity tree includes a topmost parent composite activity and at least one child activity of that topmost parent composite activity. Variables are associated with one or more composite activities of the tree, and the ancestral relationships between composite activities and (non-composite) child activities determine the in-scope access to variables. Arguments such as binding expressions may bind variables to an activity's parameters.

Abstract: Technologies for enabling a continuation based runtime to accept or reject external stimulus and, in addition, to determine if an external stimulus may be valid for processing at a later point in execution.

Abstract: Activity callbacks in a continuation-based runtime. At framework-definition time, a framework activity is authored. The framework activity may have an environmental logic portion the processes input or output parameters whose values will be supplied to and/or received from an activity callback. The framework activity also includes a callback invocation portion that, during execution time, will actually provide parameter value(s) to and/or receive parameter value(s) from the activity callback. The framework activity serves as a framework that operates with any activity callback that has one or more characteristics. Such activity callbacks may not even be defined at framework-definition time. Instead, the framework activity may be used multiple times in the same applications, or in different applications to thereby provide core framework functionality, while allowing application developers to plug in activity callbacks that meet the custom needs of the application.

Abstract: Dispatching an incoming message from a queue into message transfer session(s) from which message consumers may draw messages. The message is reversibly received from the queue, whereupon a context of a message is identified. If the context correlates to an existing message transfer session, the message is ultimately assigned to a message transfer session. If the context does not correlate to an existing message transfer session, a new message transfer session is created, and the message is assigned to that new message transfer session. Upon receiving an acknowledgement of successful processing of the message, the removal of the message from the queue-like communication medium is assured. Upon receiving an acknowledgement of unsuccessful processing of the message, the message is restored to the queue-like communication medium.

Abstract: Transport independent redirection. If a client computing system were to request a service from a service computing system, the service may determine whether or not the client should request the service from yet another service. If the client should request the service from the other computing system, the original service (or its intermediary) generates and transmits a transport-independent redirect message to the client. The client may then issue the request to the new service specified in the redirect response. The redirect message is not limited to a particular type of transport protocol. In addition, the redirect may be made possible in any number of message exchange patterns, not just request-response.

Abstract: A continuation based runtime that participates in transactions that are not generated by the continuation based runtime, but rather are generated externally to the continuation based runtime. The continuation based runtime marshals in transaction data related to the pre-existing externally generated transaction. In one embodiment, the continuation based runtime itself may not do this, but perhaps may use a transaction enabled activity. Once the activity marshals in the data, the activity may request that the continuation based runtime enlist in the transaction, whereupon the continuation based runtime may then register and the transaction may be performed in the context of the continuation based runtime.

Abstract: Declarative definition and composition of activities of a continuation based runtime. When formulating such a declarative activity of a continuation-based runtime, the activity may be formulated in accordance with a declarative activity schema and include a properties portion that declaratively defines one or more interface parameters of the declarative activity, and a body portion that declaratively defines an execution behavior of the declarative activity. The declarative activities may be hierarchically structured such that a parent declarative activity may use one or more child activities to define its behavior, where one or more of the child activities may also be defined declaratively.