Abstract: An ad-hoc discovery protocol improves reliability, security and scalability of multicast and server-based discovery. In switching from multicast to server-based discovery, the discovery client is made responsible for multicast suppression, and not discoverable devices with services. Messages include message identifier and time-to-live parameters to detect recast queries and avoid duplicating replies. A device's announcement message includes endpoint identifier, configuration number and stateless boot time parameters to detect changed device configuration and rebooted state for refreshing cached device and service descriptions. Paging parameters allow a discovery client to control the number of discovery responses returned at a time from a discovery server.

Abstract: The integration of two runtimes. The integration may be accomplished via the sharing of all or a portion of the environments of each of the runtimes with each other. For instance, as one runtime executes a particular application, control may be passed at an appropriate point to the second runtime. The second runtime may pass control back to the first runtime at an appropriate time. This passing of control between runtimes may happen perhaps a number of times during the execution of the application. The applications might be expressed entirely declaratively in a manner that integrates both runtimes as the application executes. Thus, the application may take advantage of the strengths of each runtime at the appropriate time.

Abstract: Implementations are described and claimed herein to detect an invalid policy that may reside in a cache at a client. An expired policy is removed from cache and a current policy is requested. Otherwise the cached policy may be used. The client indicates which policy it is using by generating a policy digest, including, in compressed form, one or more assertions. If the host determines the policy digest is invalid, the host issues an invalid digest fault. If the policy digest is valid, but the assertions included in the policy digest are invalid, the host issues an invalid policy fault. In either case, the client is notified that the cached policy is no longer valid and that a current policy should be requested.

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: 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: Bookmarking of tokens in a set of streaming tokens, each representing an instantiation instruction or instantiation context. A navigator receives a set of streaming tokens, and provides the tokens to the instantiation manager. However, if the navigator receives an instruction to bookmark a particular token, the navigator buffers the set of streaming instructions at least beginning at the bookmarked token (and possible even earlier if there were prior bookmarks). The navigator replays the set of streaming tokens beginning at a bookmark in response to an instruction from an instantiation manager. The instantiation manager receives the set of streaming tokens. If the instantiation manager is not presently capable of handling the instruction of a particular token, the instantiation manager instructs the navigator to bookmark the particular token.

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: A universal plug and play (UPnP) device makes itself known through a set of processes—discovery, description, control, eventing, and presentation. Following discovery of a UPnP device, an entity can learn more about the device and its capabilities by retrieving the device's description. The description includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. The description is written by a vendor, and is usually based on a device template produced by a UPnP forum working committee. The template is derived from a template language that is used to define elements to describe the device and any services supported by the device. The template language is written using an XML-based syntax that organizes and structures the elements.

Abstract: A universal plug and play (UPnP) device makes itself known through a set of processes—discovery, description, control, eventing, and presentation. Following discovery of a UPnP device, an entity can learn more about the device and its capabilities by retrieving the device's description. The description includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. The description is written by a vendor, and is usually based on a device template produced by a UPnP forum working committee. The template is derived from a template language that is used to define elements to describe the device and any services supported by the device. The template language is written using an XML-based syntax that organizes and structures the elements.

Abstract: Systems and methods for using endpoint references in a publish-subscribe system are described. In one aspect, an endpoint reference is created by a component of the pub-sub system. The endpoint reference includes an endpoint address and one or more contexts. Each context is directed to a respective component of the pub-sub system. Each context is transparent to the respective component, and selectively opaque to all other pub-sub system components.

Abstract: A universal plug and play (UPnP) device makes itself known through a set of processes-discovery, description, control, eventing, and presentation. Following discovery of a UPnP device, an entity can learn more about the device and its capabilities by retrieving the device's description. The description includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. The description is written by a vendor, and is usually based on a device template produced by a UPnP forum working committee. The template is derived from a template language that is used to define elements to describe the device and any services supported by the device. The template language is written using an XML-based syntax that organizes and structures the elements.

Abstract: An ad-hoc discovery protocol improves reliability, security and scalability of multicast and server-based discovery. In switching from multicast to server-based discovery, the discovery client is made responsible for multicast suppression, and not discoverable devices with services. Messages include message identifier and time-to-live parameters to detect recast queries and avoid duplicating replies. A device's announcement message includes endpoint identifier, configuration number and stateless boot time parameters to detect changed device configuration and rebooted state for refreshing cached device and service descriptions. Paging parameters allow a discovery client to control the number of discovery responses returned at a time from a discovery server.

Abstract: A universal plug and play (UPnP) device makes itself known through a set of processes-discovery, description, control, eventing, and presentation. Following discovery of a UPnP device, an entity can learn more about the device and its capabilities by retrieving the device's description. The description includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. The description is written by a vendor, and is usually based on a device template produced by a UPnP forum working committee. The template is derived from a template language that is used to define elements to describe the device and any services supported by the device. The template language is written using an XML-based syntax that organizes and structures the elements.