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: 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: 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 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: 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: A listener operating in user-mode can dispatch control of a client connection to a listener without exposing system memory or other sensitive services or components. For example, a client component requests access to a network component through connection with a user-mode listener. Based on information contained in the client request, the listener passes a call to an application program interface, which returns a first set of data that includes user-mode contextual information. The listener passes this first set of data to the requested network component. Another call is made to an application program interface, which includes the first set of data, and a request for socket duplication. The application program interface returns control of the requested socket to the network component, such that the network component and the client component communicate directly through the requested socket in user-mode.

Abstract: A plurality of message processors exchange public and secret information. Based on the exchanged information, each message processor computes a key sequence such that any one of a plurality of keys may be derived from the key sequence depending on key derivation data. A first message processor generates key derivation data that can be used to derive a particular key from among the plurality of keys. The first message processor sends a security token that includes the generated key derivation data to express to at least one other message processor how to derive the particular key from the computed key sequence. At least a second message processor receives the security token expressing how to derive the particular key from the computed key sequence. The first and/or second message processors apply the key derivation data to the computed key sequence to derive the particular key.

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 provided herein support large messages by formatting at least a portion of the message in the form of a transport stream. More specifically, embodiments provide a SOAP model that can stream an object for a message without loading the entire message into an intermediate buffer. Accordingly, one embodiment supports loading SOAP headers into memory, yet streaming the body. This would allow, for example, large attachments (e.g., a video file) to accompany the SOAP message in the body, while still supporting random access to message headers. Accordingly, embodiments provide a SOAP data model that allows a developer to create an object and specify whether or not portions of the message should be buffered or streamed.

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: A program product characterizes a set of information to determine common characteristics among subsets of the set of information. The program product includes computer instructions which obtain characteristic data that describe characteristics of an entity. For example, the characteristic data may include titles of individuals within an organization. The computer instructions also obtain a set of information associated with the entity (e.g. a set of e-mail messages, Web pages, business memoranda, etc.) The computer instructions identify key terms within the set of information and classify the set of information into at least first and second subsets. In addition, the computer instructions characterize the first subset as more important than the second subset, based on the key terms and the characteristic data. For example, a subset of documents associated with officers of a company may be characterized as more important than a subset of documents associated with temporary employees.

Abstract: A plurality of message processors exchange public and secret information. Based on the exchanged information, each message processor computes a key sequence such that any one of a plurality of keys may be derived from the key sequence depending on key derivation data. A first message processor generates key derivation data that can be used to derive a particular key from among the plurality of keys. The first message processor sends a security token that includes the generated key derivation data to express to at least one other message processor how to derive the particular key from the computed key sequence. At least a second message processor receives the security token expressing how to derive the particular key from the computed key sequence. The first and/or second message processors apply the key derivation data to the computed key sequence to derive the particular key.