Patent application number | Description | Published |
20080291909 | MESSAGE DELIVERY DOWNGRADING ANNOTATIONS - Selectively modifying a message delivery requirement of a datagram message at an intermediary network node between an origin and a destination. A message delivery requirement is defined for a particular message. The message delivery guarantee defines how to transmit the particular message. A downgrading intent of the particular message is provided for the message at the origin. The downgrading intent of the particular message indicates that the message delivery requirement can be bypassed. The defined message delivery guarantee, the network delivery requirement, and the provided downgrading intent of the particular message are processed at the intermediate network node. The message delivery requirement of the particular message is ignored based on the provided downgrading intent. The message is delivered via a network protocol according to the provided downgrading intent. | 11-27-2008 |
20080294971 | TRANSPARENT ENVELOPE FOR XML MESSAGES - Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination. | 11-27-2008 |
20090049197 | LIGHTWEIGHT ADDRESS FOR WIDELY-DISTRIBUTED ADHOC MULTICAST GROUPS - Delivery of a message over a communications network from a sender based on a single delivery address. The single delivery address is generated as one unit for the message. The single delivery address has a collection of recipient addresses including one or more recipient addresses each identifying at least one recipient of the message. Each of the one or more recipient addresses includes a user level information and a domain level information. The generated single delivery address with the collection of recipient addresses is included in the message. A copy of the message is provided to the identified recipient(s) as a function of the domain level information of the one or more recipient addresses. The message is transmitted over the communications network to the identified recipient(s) recipient based on the collection of recipient addresses. | 02-19-2009 |
20090190585 | Message Processing Engine with a Virtual Network Interface - A message processing engine may intercept outgoing and incoming messages by bridging an interface between a virtual network interface and a physical network interface. The message processing engine may have a raw packet analyzer that may determine if a packet is to be processed based on a policy, and then may decode the packet using a first set of protocols, perform a translation in the decoded state, then encode the packet using the same or a different set of protocols. The message processing engine may be used to perform translations to enable two otherwise incompatible devices to communicate as well as apply various protocols including security protocols to communications with another device similarly configured. In many embodiments, the raw packet analyzer may be a service with administrative privileges, but the decoder, encoder, and translator may be operated with user privileges. | 07-30-2009 |
20090199208 | QUEUED MESSAGE DISPATCH - Embodiments described herein allow a service component author to write service components without having to handle incoming messages being received at any time. This may be facilitated by a message dispatch engine that dispatches messages from the incoming message queue only when the destination service component has indicated that it is ready to receive the message having that context. If the service component is not yet ready for the message, the message dispatch component may lock the message at least until the destination service component indicates that it is now ready to receive the message. Until that time, the message dispatch engine may ignore the locked message when finding messages to dispatch. | 08-06-2009 |
20090271495 | TRANSPORT INDEPENDENT REDIRECTION - Transport independent redirection. If a client computing system were to request a service from a service computing system, the service may determine whether or not the client should request the service from yet another service. If the client should request the service from the other computing system, the original service (or its intermediary) generates and transmits a transport-independent redirect message to the client. The client may then issue the request to the new service specified in the redirect response. The redirect message is not limited to a particular type of transport protocol. In addition, the redirect may be made possible in any number of message exchange patterns, not just request-response. | 10-29-2009 |
20090300647 | Canonicalization of Badly-Formed Messages - The canonicalization of input messages having application specific data into a canonical message format, regardless of whether those native messages are well-formed. When a message is accessed, as long as the message is processable, the message is canonicalized. If the native message is well-formed, then a canonical message is generated that includes the application specific data in a schema understood by the application. On the other hand, if the native message is not well-formed, the canonical message is generated in a manner that the canonical message may be used to access the raw bits of the message, and that includes sufficient information for some downstream processing to determine that the message was not well-formed. That downstream processing may optionally then perform compensatory actions to regain access to the application specific data, and may potentially use information from the canonicalized message to do so. | 12-03-2009 |
20090300652 | QUEUE DISPATCH USING DEFERRED ACKNOWLEDGEMENT - Dispatching an incoming message from a queue into message transfer session(s) from which message consumers may draw messages. The message is reversibly received from the queue, whereupon a context of a message is identified. If the context correlates to an existing message transfer session, the message is ultimately assigned to a message transfer session. If the context does not correlate to an existing message transfer session, a new message transfer session is created, and the message is assigned to that new message transfer session. Upon receiving an acknowledgement of successful processing of the message, the removal of the message from the queue-like communication medium is assured. Upon receiving an acknowledgement of unsuccessful processing of the message, the message is restored to the queue-like communication medium. | 12-03-2009 |
20100082753 | ROLE-INDEPENDENT CONTEXT EXCHANGE - Technologies for conversations between various parties, the conversations including context information that can be persisted to maintain the conversation when the parties or the communications media they communicate over operate intermittently. In such a conversation, any party can embed its view of the context into a message and any party can send the next message regardless of role and regardless of the underlying network, transport, or application message exchange pattern. Such technologies provide for durable services. | 04-01-2010 |
20100162264 | SERVICE VIRTUALIZATION CONTAINER - Service virtualization containers to aggregate service functionality from a plurality of services into an apparent service exhibiting the aggregated functionality. A plurality of service implementations is assigned to a service virtualization container. The container selects some of the service operations from the service implementations. One or more message characteristics are assigned to the service operations in one or more routing tables. A message is received at a service endpoint different from the service endpoints of any of the service implementations. A determination is made of one or more message characteristics. The one or more routing tables are consulted to select a determined service operation based on the message characteristics. The message is routed to the selected service implementation. Embodiments may also include functionality for aggregating metadata from service implementations and providing metadata based on the aggregated metadata to clients requesting metadata from a service virtualization container. | 06-24-2010 |
20100318654 | ROUTING OF POOLED MESSAGES VIA AN INTERMEDIARY - Message intermediation for multiple service instances, while allowing the service instance to control whether messages are processed under a transaction. The message intermediator chooses to dispatch messages among different backend service instances based on any routing rules. The message intermediator performs a peek-lock of message from a forward-end queue, and assigns the message to a service instance. The message is provided into a backward-end queue specific to the assigned service instance. The service instance may then process the message, perhaps under a transaction created at the service instance. Upon completion of processing, the message is deleted in the back-end queue, which causes the forward-end queue to delete the message under the same transaction created by the service instance. Whether or not this deletion at the forward-end is committed or rolled back depends on whether the transaction created at the service instance is committed or rolled back. | 12-16-2010 |
20110078509 | INFERENCE OF CONTRACT USING DECLARATIVE PROGRAM DEFINITION - A declarative program definition. The definition is analyzed to produce an application contract that describes semantics for sending and receiving application messages during the successful execution of operations by the program. In addition, this analysis may also generate local behaviors associated with the local execution of the program. Alternatively or in addition, the analysis may infer secondary contracts regarding the sending and receiving of application messages, even though the full details of the secondary contracts are not present in the declarative program definition. For instance, the secondary contracts might include error contracts or consistency contracts. | 03-31-2011 |
20110093738 | ERROR RECOVERY FOR APPLICATION-LEVEL INTERMEDIARIES - Error handling in the intermediation of one-way transacted messages. Rather than receiving an inbound message under a transaction, the intermediary performs a non-destructive exclusive read of the message from the source outside of a transaction. Routing logic is applied against the content of the message to determine a collection of message consumers to which a copy of the inbound message is to be sent. Then, under a transaction, the copy of the message is attempted to be sent to each destination. If a send of the copy fails, the transaction is rolled back, but the failure is recorded such that the same transmission mechanism is not, or is less likely to be, tried again in subsequent attempts. The principles may apply to a single message to be sent under the transaction, or to multiple messages to be sent under a single transaction. | 04-21-2011 |
20110145684 | TRANSPARENT ENVELOPE FOR XML MESSAGES - Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination. | 06-16-2011 |
20110145685 | TRANSPARENT ENVELOPE FOR XML MESSAGES - Transforming portions of a message to a destination via a communication protocol. A message is received. It is detected whether the received message includes an encoded envelope. The encoded envelope includes a stack defining parameters including information for handling the received message in an original format. If the received message includes the encoded envelope, the defined parameters are transformed to coded parameters in a common format. The coded parameters express the same information for handling the received message in the communication protocol. The encoded envelope is encapsulated in the received message, and the received message in the common format is delivered to the destination. If the received message does not include an encoded envelope, coded parameters are generated in the common format for the received message by encoding addressing information from the received message. The received message having the coded parameters in the common format is delivered to the destination. | 06-16-2011 |
20110153713 | OUT OF ORDER DURABLE MESSAGE PROCESSING - The dispatching of messages from an incoming message pool to service instance(s). Message are received non-destructively and exclusively from the incoming message pool. If a particular service instance receives a message out of order, the processing of the message is deferred without releasing the exclusivity in the incoming message queue. Thus, the target service instance may continue to process one or more other messages until the target service instance is ready to process one or more deferred messages. In this way, messages may be pulled from the incoming message queue for dispatch to service instance(s), while maintaining correct order of processing, even if messages do not arrive into the incoming message queue in the correct order. | 06-23-2011 |
20110219440 | APPLICATION-LEVEL DENIAL-OF-SERVICE ATTACK PROTECTION - The gate guard filtering of incoming application-level requests on behalf of an application. Upon receiving an application request, a token found in the application request may be evaluated by the gate guard. This token may have been previously provided by the application, with instructions that future application requests by the client are to include the token. The gate guard classifies the incoming request as being a member of a subset of one or more application request classes. These identified request classes may be used to determine an admission policy to apply based on the particular subset of one or more request classes corresponding to the application request. The admission policy is then applied to the incoming application request to determine if the application request should be rejected or accepted. As another option, the application request may perhaps even be deferred for future determination of rejection or acceptance. | 09-08-2011 |
20110238921 | ANTICIPATORY RESPONSE PRE-CACHING - Interaction between a client and a service in which the service responds to requests from the client. In addition to responding to specific client requests, the service also anticipates or speculates about what the client may request in the future. Rather than await the client request (that may or may not ultimately be made), the service provides the unrequested anticipatory data to the client in the same data stream as the response data that actual responds to the specific client requests. The client may then use the anticipatory data to fully or partially respond to future requests from the client, if the client does make the request anticipated by the service. Thus, in some cases, latency may be reduced when responding to requests in which anticipatory data has already been provided. The service may give priority to the actual requested data, and gives secondary priority to the anticipatory data. | 09-29-2011 |
20120327934 | Message Processing Engine with a Virtual Network Interface - A message processing engine may intercept outgoing and incoming messages by bridging an interface between a virtual network interface and a physical network interface. The message processing engine may have a raw packet analyzer that may determine if a packet is to be processed based on a policy, and then may decode the packet using a first set of protocols, perform a translation in the decoded state, then encode the packet using the same or a different set of protocols. The message processing engine may be used to perform translations to enable two otherwise incompatible devices to communicate as well as apply various protocols including security protocols to communications with another device similarly configured. In many embodiments, the raw packet analyzer may be a service with administrative privileges, but the decoder, encoder, and translator may be operated with user privileges. | 12-27-2012 |
20130046877 | ROUTING OF POOLED MESSAGES VIA AN INTERMEDIARY - Message intermediation for multiple service instances, while allowing the service instance to control whether messages are processed under a transaction. The message intermediator chooses to dispatch messages among different backend service instances based on any routing rules. The message intermediator performs a peek-lock of message from a forward-end queue, and assigns the message to a service instance. The message is provided into a backward-end queue specific to the assigned service instance. The service instance may then process the message, perhaps under a transaction created at the service instance. Upon completion of processing, the message is deleted in the back-end queue, which causes the forward-end queue to delete the message under the same transaction created by the service instance. Whether or not this deletion at the forward-end is committed or rolled back depends on whether the transaction created at the service instance is committed or rolled back. | 02-21-2013 |
20130138751 | ROLE-INDEPENDENT CONTEXT EXCHANGE - Technologies for conversations between various parties, the conversations including context information that can be persisted to maintain the conversation when the parties or the communications media they communicate over operate intermittently. In such a conversation, any party can embed its view of the context into a message and any party can send the next message regardless of role and regardless of the underlying network, transport, or application message exchange pattern. Such technologies provide for durable services. | 05-30-2013 |
20130282986 | ANTICIPATORY RESPONSE PRE-CACHING - Interaction between a client and a service in which the service responds to requests from the client. In addition to responding to specific client requests, the service also anticipates or speculates about what the client may request in the future. Rather than await the client request (that may or may not ultimately be made), the service provides the unrequested anticipatory data to the client in the same data stream as the response data that actual responds to the specific client requests. The client may then use the anticipatory data to fully or partially respond to future requests from the client, if the client does make the request anticipated by the service. Thus, in some cases, latency may be reduced when responding to requests in which anticipatory data has already been provided. The service may give priority to the actual requested data, and gives secondary priority to the anticipatory data. | 10-24-2013 |
20130290469 | ANTICIPATORY RESPONSE PRE-CACHING - Interaction between a client and a service in which the service responds to requests from the client. In addition to responding to specific client requests, the service also anticipates or speculates about what the client may request in the future. Rather than await the client request (that may or may not ultimately be made), the service provides the unrequested anticipatory data to the client in the same data stream as the response data that actual responds to the specific client requests. The client may then use the anticipatory data to fully or partially respond to future requests from the client, if the client does make the request anticipated by the service. Thus, in some cases, latency may be reduced when responding to requests in which anticipatory data has already been provided. The service may give priority to the actual requested data, and gives secondary priority to the anticipatory data. | 10-31-2013 |