Abstract: In one embodiment, a method includes receiving, from a client system of a first user of the communication system, an input from the first user to access a card-stack interface, generating a card cluster comprising a plurality of cards, each card comprising a suggested query referencing a query-domain and one or more query-filters, wherein each query-filter references one or more objects associated with the communication system, and wherein each card in the card cluster is ranked within the card cluster based on a predicted click-thru rate (CTR) for the card based on one or more user-engagement factors, and sending, to the client system in response to the input from the first user, the card-stack interface for display to the first user, wherein the card-stack interface comprises the card cluster, the cards of the card cluster being ordered based on the rankings associated with the cards.

Abstract: In one embodiment, a method includes receiving, from a client system of a first user of the communication system, an input from the first user to access a card-stack interface, generating a card cluster comprising a plurality of cards, each card comprising a suggested query referencing a query-domain and one or more query-filters, wherein each query-filter references one or more objects associated with the communication system, and wherein each card in the card cluster is ranked within the card cluster based on a predicted click-thru rate (CTR) for the card based on one or more user-engagement factors, and sending, to the client system in response to the input from the first user, the card-stack interface for display to the first user, wherein the card-stack interface comprises the card cluster, the cards of the card cluster being ordered based on the rankings associated with the cards.

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: 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: 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: The present invention provides for a channel model capable of generating a runtime communication channel with pluggable modular channel components. These channel components implement one of a set of standard interfaces that allow processing details of communication semantics between components to be represented in a polymorphic way. A message and corresponding communication semantics are recursively passed through the channel components using the standard interface, thereby abstracting other modules and components from specific implementation details of how the communication semantics are performed. The message may then be sent to the next appropriate module for further processing, or the processing may be completed at that particular component or module. Note also that the message can also be de-multiplexed on the service side in a similar fashion as that described above.

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 sending computer system can identify one or more available network resources at one or more network computers by sending a request for services using Simple Object Access Protocol (SOAP) over User Datagram Protocol (UDP). In particular, the sending computer system prepares a SOAP message that includes a request for available resources. The sending computer system then encapsulates the SOAP message into a user datagram, and sends the user datagram to one or more identifiable computer systems on the network. In one implementation, the sending computer system sends the user datagram to a multi-cast Uniform Resource Identifier (URI). The receiving computer system receives the message through UDP, unpacks the message, and responds to the SOAP message request. Accordingly, the sending computer system can query multiple computer systems in an efficient manner without necessarily incurring the overhead otherwise associated with connection-oriented communication.

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 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 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: 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.