Abstract: A cooling fan and an electronic device are provided. The cooling fan comprises a plurality of blades disposed in a circumferential direction of a rotating shaft. The plurality of blades includes a first blade and a second blade. A windward surface of the first blade includes a first alignment part and a first offset part. The first alignment part is aligned with a windward surface of the second blade, and the first offset part and the windward surface of the second blade are arranged in a staggered manner.

Abstract: A cooling fan and an electronic device are provided. The cooling fan comprises a plurality of blades disposed in a circumferential direction of a rotating shaft. The plurality of blades includes a first blade and a second blade. A windward surface of the first blade includes a first alignment part and a first offset part. The first alignment part is aligned with a windward surface of the second blade, and the first offset part and the windward surface of the second blade are arranged in a staggered manner.

Abstract: Interfaces for a continuation-based runtime. Some embodiments described herein are directed to a framework using continuation based runtime interface that pertain to an infrastructure for enabling the creation of a wide variety of continuation-based programs that perform a wide-array of tasks. The infrastructure provides a foundation for building continuation-based, declarative applications of various scale and complexity.

Abstract: Interfaces for a continuation-based runtime. Some embodiments described herein are directed to a framework using continuation based runtime interface that pertain to an infrastructure for enabling the creation of a wide variety of continuation-based programs that perform a wide-array of tasks. The infrastructure provides a foundation for building continuation-based, declarative applications of various scale and complexity.

Abstract: Namespace for continuation-based runtime. Some embodiments described herein are directed to a framework using continuation based runtime namespaces that pertain to an infrastructure for enabling the creation of a wide variety of continuation-based programs that perform a wide-array of tasks. The infrastructure provides a foundation for building continuation-based, declarative applications of various scale and complexity. In some embodiments, the associated application programming interfaces (APIs) are factored into a hierarchy of namespaces in a manner that balances utility, usability, extensibility, and versionability.

Abstract: Embodiments allow developers to use HTTP message abstractions inline within their Web API methods to directly access and manipulate HTTP request and response messages. A hosting layer is provided for in-process, in-memory and network-based services. Message handlers and operational handlers may be combined to create a message channel for asynchronous manipulations of the HTTP requests and response. A formatter may be used on the server or client for consuming HTTP and providing desired media types.

Abstract: Embodiments allow developers to use HTTP message abstractions inline within their Web API methods to directly access and manipulate HTTP request and response messages. A hosting layer is provided for in-process, in-memory and network-based services. Message handlers and operational handlers may be combined to create a message channel for asynchronous manipulations of the HTTP requests and response. A formatter may be used on the server or client for consuming HTTP and providing desired media types.

Abstract: Namespace for continuation-based runtime. Some embodiments described herein are directed to a framework using continuation based runtime namespaces that pertain to an infrastructure for enabling the creation of a wide variety of continuation-based programs that perform a wide-array of tasks. The infrastructure provides a foundation for building continuation-based, declarative applications of various scale and complexity. In some embodiments, the associated application programming interfaces (APIs) are factored into a hierarchy of namespaces in a manner that balances utility, usability, extensibility, and versionability.

Abstract: A message handling computing system that provides security across even transport-independent communication mechanisms, and which allows for convenient extension of security to different security token types, and may provide end-to-end security across different transport protocols. The message handling computing system includes a message handling component configured to send and receive network messages having security tokens. The message handling component interfaces with an expandable and contractible set of security token managers through a standardized application program interface. Each security manager is capable of providing security services for messages that correspond to security tokens of a particular type. A security token plug-in component registers new security token managers with the message handling component.

Abstract: A sending computer system generates a message and creates one or more security tokens to encrypt portions of the message. The computer system includes in the message a markup language identifier for the one or more security tokens used for encryption, and includes identification of the value type used to create the tokens. The computer system then serializes at least the portion of the message that identifies the one or more security tokens, without serializing other portions of the message that aid relaying of the message to a receiving computer system. A receiving computer system deserializes at least the portion of the message that identifies the one or more security tokens, and then uses deserialized token data to decrypt encrypted portions of the message. Each created security token can be made with customized data and fields, and can be made with a customized value type.

Abstract: The present invention provides for maintaining security context during a communication session between applications, without having to have executable code in either application for obtaining or generating a security context token (SCT) used to secure the communication. On a service side, a configuration file is provided that can be configured to indicate that automatic issuance of a SCT is enabled, thereby allowing a Web service engine to generate the SCT upon request. On the client side, when a message is sent from the client application to the service application, a policy engine accesses a policy that includes assertions indicating that a SCT is required for messages destined for the Web service application. As such, the policy engine requests and receives the SCT, which it uses to secure the message.

Abstract: A mechanism for performing role-based authorization of the one or more services using security tokens associated with received service request messages. This role-based authentication is performed regardless of the type of security token associated with the received service request messages. Upon receiving a service request message over the network for a particular service offered by the service providing computing system, the service providing computing system accesses a security token associated with the received service request message. Then, the computing system identifies one or more roles that include the identity associated with the security token, and correlates the roles with the security token. These correlated roles are then used to authorize the requested service. This mechanism is performed regardless of the type of the security token.

Abstract: The present invention provides for maintaining security context during a communication session between applications, without having to have executable code in either application for obtaining or generating a security context token (SCT) used to secure the communication. On a service side, a configuration file is provided that can be configured to indicate that automatic issuance of a SCT is enabled, thereby allowing a Web service engine to generate the SCT upon request. On the client side, when a message is sent from the client application to the service application, a policy engine accesses a policy that includes assertions indicating that a SCT is required for messages destined for the Web service application. As such, the policy engine requests and receives the SCT, which it uses to secure the message.

Abstract: A mechanism for performing role-based authorization of the one or more services using security tokens associated with received service request messages. This role-based authentication is performed regardless of the type of security token associated with the received service request messages. Upon receiving a service request message over the network for a particular service offered by the service providing computing system, the service providing computing system accesses a security token associated with the received service request message. Then, the computing system identifies one or more roles that include the identity associated with the security token, and correlates the roles with the security token. These correlated roles are then used to authorize the requested service. This mechanism is performed regardless of the type of the security token.

Abstract: A message handling computing system that provides security across even transport-independent communication mechanisms, and which allows for convenient extension of security to different security token types, and may provide end-to-end security across different transport protocols. The message handling computing system includes a message handling component configured to send and receive network messages having security tokens. The message handling component interfaces with an expandable and contractible set of security token managers through a standardized application program interface. Each security manager is capable of providing security services for messages that correspond to security tokens of a particular type. A security token plug-in component registers new security token managers with the message handling component.

Abstract: A sending computer system relays a message or a processing request through one or more configurable routers prior to the message or request reaching an ultimate destination. A client at the sending computer system can indicate a routing preference for the message or request, and a module can supplement or override the routing preference by adding or deleting a router from a router list contained within the message or request. This change can be done based on router data, as well as based on content within the message. One or more intermediate routers along the routing path can perform a similar function as the module. The ultimate destination, or receiving computer system, verifies that it is the appropriate recipient of the message or request, and then accepts the data associated with the message or request. This has application to many types of messaging systems, including simple object access protocols.

Abstract: A sending computer system generates a message and creates one or more security tokens to encrypt portions of the message. The computer system includes in the message a markup language identifier for the one or more security tokens used for encryption, and includes identification of the value type used to create the tokens. The computer system then serializes at least the portion of the message that identifies the one or more security tokens, without serializing other portions of the message that aid relaying of the message to a receiving computer system. A receiving computer system deserializes at least the portion of the message that identifies the one or more security tokens, and then uses deserialized token data to decrypt encrypted portions of the message. Each created security token can be made with customized data and fields, and can be made with a customized value type.

Abstract: A messaging transport writer is provided that efficiently packages a massage and multiple message attachment streams into a single transport stream, based on a specified encapsulation format. For example, a packaging writer is provided that takes the message and multiple attachments and streams them directly into the single transport stream, without first coping them into a buffer prior to encapsulation. The encapsulation information is streamed into the transport stream on the fly, i.e., as the message and attachment streams are also being written to the transport stream.