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: Mechanisms for providing requested data items in a request-driven enumeration session while retaining control over how much inter-message context information is retained by the data provider. Upon receiving a request for the data items, the data provider identifies a portion of the data items to be provided in the first response along with context information that reflects that the first portion of information has been provided. The data provider then makes a determination of how much of the context is to be provided to the data receiver system, and then provides that appropriate context information to the data receiver. Furthermore, the data provider provides a response that includes the first portion of the data items. The data receiver includes this first provided context information in the second request for the next portion of the data items, allowing continuity in the data transfer session.

Abstract: The present invention provides a mechanism that allows an administrative event to trigger or cause the generation of a dynamic web service during initialization of legacy application components. Similar to other types of static tooling approaches, the dynamic approach—as supported herein—uses available metadata describing an interface for communicating with legacy components. Rather than generating and manifesting the web service via tooling on a one time or occasional bases, however, example embodiments provide for the generation of the web service by the supporting infrastructure as a standard part of application initialization. Upon stopping the application, a termination sequence is provided that stops the corresponding dynamic web service and deletes the web service description used to generate the dynamic web service. Accordingly, every time the application is started the available metadata will need to be consulted and a consistent service will be built on-the-fly.

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: A nominal type framework can be configured to efficiently correlate different nominal types together based on a minimum set of common type shapes or structures. In one implementation, a developer identifies a number of different nominal types of interest (source types), and identifies the minimum set of common type shapes to be accessed by an application program. The minimum set of common type shapes can then be used to create an intermediate type (target type) to which each of the other different source types can be mapped. For example, one or more proxies can be created that map shapes of the one or more source types to corresponding shapes of the created target type. The application program created by the developer, in turn, can access, operate on, or otherwise use the mapped data of each different source type through a single target type.

Abstract: A common data type structure can be used to correlate access requests between applications that implement data in accordance with different types or type structures. In one implementation, a common data structure includes schemes for operations, sequences, records, and atoms (i.e., undefined). The system can then map any type structure to the schemes of the common data structure. In operation, a request for data by an application can involve identifying one or more proxies used by an application to map the data to the common data structure. The proxies map the data to the common data structure based on the shape of the data (to the extent it can be identified). The proxies then can return one or more data structures that comprise the identified mapping information. The application can then perform operations directly on the received data structures.

Abstract: Component domains used to define a binding between various components associated with the component domain. The component domain tracks the various services to be imported by each component, and tracks the various services exported by each component. At runtime, rather than at compile time, the various interrelations between the components are bound using the service import and export data. Accordingly, depending on the components available and their characteristics, the bindings may differ. This permits applications to be much more flexible.

Abstract: Component domains used to define a binding between various components associated with the component domain. The component domain tracks the various services to be imported by each component, and tracks the various services exported by each component. At runtime, rather than at compile time, the various interrelations between the components are bound using the service import and export data. Accordingly, depending on the components available and their characteristics, the bindings may differ. This permits applications to be much more flexible. In one implementation, the binding is performed iteratively. For example, if after one iteration of binding service imports to service exports, some components may expand the services that they export, or the services that they desire to import.

Abstract: The transfer of raw data from a source data structure to a target data structure that represent the same item. During the data transfer, if there is a given field in the target data structure that does not correspond to a field supplied by the source data structure, the transfer mechanism determines whether or not it is mandatory that the source data structure supply the field. If it is mandatory, the transfer fails. Otherwise, the transfer continues. If there is field of the source data structure that does not correspond to a field of the target data structure, the transfer mechanism determines whether or not it is mandatory that the target data structure have the field. If it is mandatory, the transfer fails. Otherwise, the corresponding data may be provided to a residual field of the target data structure dedicated for unknown data.

Abstract: Information can be retrieved by a requesting computer system from a responding computer system using a SOAP-based get operation. In one implementation, a requesting computer system identifies an endpoint reference for content at a responding computer system. The requesting computer system then creates a SOAP get message for retrieving the content, where the message can include one or more constraints for receiving the content, and sends the message to the responding computer system using any appropriate transport protocol. The responding computer system receives the message, determines an extent to which the content can be provided, and creates a response message that relates to the first message. In one implementation, the reply can include an error message, at least a portion of the content, and, in some cases, another endpoint reference for retrieving the rest of the requested content.

Abstract: Determining compatibility of data structures. A method may be practiced in a computing environment. The method includes accessing a first type defined in a mark-up object. The first type includes a first structure including a first plurality of fields. A second type defined in a mark-up object is accessed. The second type includes a second structure including a second plurality of fields. The first structure and the second structure are compared. Based on the comparison, a determination is made that the first type is compatible with the second type.

Abstract: Embodiments provide an architecture to enable composite, autonomous composite applications and services to be built and deployed. In addition, an infrastructure is provided to enable communication between and amongst distributed applications and services. In one or more embodiments, an example architecture includes or otherwise leverages five logical modules including connectivity services, process services, identity services, lifecycle services and tools.

Abstract: Embodiments provide an architecture to enable composite, autonomous composite applications and services to be built and deployed. In addition, an infrastructure is provided to enable communication between and amongst distributed applications and services. In one or more embodiments, an example architecture includes or otherwise leverages five logical modules including connectivity services, process services, identity services, lifecycle services and tools.

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: An architecture that leverages support for markup language operations, e.g., extensible markup language (XML) queries, via a lightweight application program interface (API). The API defines an object model that can simplify construction of XML values in languages that do not natively support XML. The novel aspects of the described innovation can enable query languages to be factored into general operations (e.g., mapping, filtering, sorting, and/or projection of functions) on collections on one hand, and a set of domain specific operations (e.g., navigation, construction and modification) on the elements of these collections on another hand. The subject API can support creation of XML data that is node centric (e.g., context-free). Accordingly, nodes do not have to be constructed within the context of a document. Additionally, aspects can enable expression-oriented interface mechanisms as opposed to the imperative statement-oriented style interfaces used in connection with traditional interface mechanisms (e.

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: Embodiments described herein provide a user with the ability to vary the encoding of a message object rather than being bound to a specific one, e.g., the text encoding for SOAP messaging. Accordingly, a message encoding factory is provided that is responsible for mapping a message object (e.g., SOAP Infoset) into raw octets suitable for wire transmission. By encapsulating the notion of a message encoder factory abstractly, embodiments allow users to vary the encoding of an Infoset without varying the programming model (or any other aspect of the system that uses message). In other words, embodiments herein separate the transport (e.g., TCP, HTTP, etc.) from the encoding, which allows users to use any number of encoding mechanisms-even their own proprietary ones.

Abstract: Embodiments described herein provide for a message contract programming model, which is a mechanism for service developers to control the processing, layout, and creation of messages (e.g., SOAP) without losing the benefits of a strongly-typed data contract model. Such programming model is based on attributes, which can be used to define the action or operations, headers, and body parts components of a message. These attributes may be used on a type annotated with message contract or on a service operation to control the manner in which the message (e.g., SOAP) is constructed from a service process, process parameters, and/or return values. The use of the message contract in conjunction with a message formatter as defined herein provides for many advantageous features and embodiments described herein.

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: A method includes advertising a policy characterizing communication properties supported by a node. The policy may be distributed to another node in response to a request for the policy. Policy expressions in the policy include one or more assertions that may be grouped and related to each other in a plurality of ways. A system includes a policy generator for generating at least one policy characterizing properties of a node. A policy retriever retrieves a policy from another node and a message generator generates a message to the other node, wherein the message conforms to the policy from the other node.