Handling deferrable network requests

Abstract

Embodiments of the present invention provide methods, computer program products, and systems. The embodiments of the present invention can embed deferrable network request data in a header of a preferred carrier network request to identify the network request as deferrable and send it to a remote server. The embodiments of the present invention can receive a carrier network request with the deferrable network request data embedded in the carrier network request header. The embodiments of the present invention can then parse the embedded data from the header into a separate request message for performing an action at a server.

Description

[Technical Field]

[0001] The present invention relates to handling network requests, and more particularly to handling deferrable network requests. [Background technology]

[0002] Network requests, in the form of Hypertext Transfer Protocol (HTTP) requests, are used to communicate between clients and servers in a networked environment. An HTTP request method from a client indicates a desired action to be performed at a server for a given resource. The resource is identified by a request Uniform Resource Locator (URL), and each request method implements a distinct semantic. For example, web applications typically execute code within a browser to send or retrieve data and then send an HTTP request back to the server.

[0003] While many HTTP requests must be processed immediately by the server, some requests are less time-sensitive and may be deferrable. An example of a deferrable request is a request to track data for user analytics. This data is useful to developers in understanding user behavior, but is not critical to the immediate functionality of the web application.

[0004] The information contained in such HTTP requests is typically very small compared to the overhead involved in HTTP requests (headers, cookies, etc.), and developers often need to design strategies for handling failures of such calls.

[0005] Therefore, such extra requests often lead to inefficiencies in network traffic and resource usage. Summary of the Invention

[0006] According to a first aspect of the present invention, there is provided a computer-implemented method for handling deferrable network requests, the method being executed in a user agent of a client and including intercepting and identifying a network request as deferrable, and embedding data of the deferrable network request into a header of a preferred carrier network request for transmission to a remote server.

[0007] This has the advantage of reducing the number of network requests by waiting for a non-deferrable network request that may carry one or more deferrable network requests in its header.

[0008] The method may include storing data of the deferrable network requests in a local cache at the client in the form of aggregate data of target destinations and request message data of the deferrable network requests, identifying a preferred carrier network request, and embedding the aggregated data of the deferrable requests in a header of the carrier network request. The method may include embedding the aggregated data of each of the multiple deferrable requests in one of multiple headers of the carrier network request. The preferred carrier network request may not be deferrable and may have sufficient space for the deferrable request data.

[0009] Identifying the network request as deferrable may include intercepting the network request message and determining whether the request network message is being sent to a host in a list of predefined deferrable destinations. The method may also include obtaining from the server a predefined header name for use when embedding the deferrable request data in a header.

[0010] The method may include batch transmitting the cached deferrable network request data when the cache reaches a predetermined size or upon exiting from the user agent, the batch transmitting selecting the cached deferrable network request as a carrier network request and adding the other cached deferrable request data to one or more headers of the carrier network request.

[0011] The method may include receiving a carrier network response having embedded data of the response to the deferrable network request within a header of the carrier network response, and parsing the embedded data from the header into a separate response message for performing an action at a client.

[0012] The method may include, for each deferrable network request added to the preferred carrier network message, marking the deferrable network request as in progress and updating the deferrable network request when a successful response is received.

[0013] According to another aspect of the present invention, there is provided a computer-implemented method for handling deferrable network requests, the method being executed at a server and including receiving a carrier network request having embedded data of the deferrable network request in a header of the carrier network request, and parsing the embedded data from the header into a separate request message for performing an action at the server.

[0014] The embedded data of the deferrable network request may be aggregate data of the target destination and the request message data of the deferrable network request, and parsing the embedded data may form a separate request message to the target destination.

[0015] The method may include receiving a batch of deferrable network requests for individual processing at a server.

[0016] The method may include intercepting and identifying a deferrable network response and embedding data of the deferrable network response in a header of a preferred carrier network response for transmission back to the client. The method may include storing data of the deferrable network response in a local cache at the server in the form of aggregate data of a target destination of the deferrable network response and response message data, identifying a preferred carrier network response, and embedding the aggregate data of the deferrable response in a header of the carrier network response. The method may include embedding the aggregate data of each of a plurality of deferrable responses in one of a plurality of headers of the carrier network request.

[0017] The method may further include sending from the server a predefined header name for use by the user agent when embedding the deferrable request data in a header of the carrier network request.

[0018] The method may receive a batch of deferrable network requests for individual processing at the server, in the form of the deferrable network requests as carrier network requests and other cached deferrable request data provided in one or more headers of the carrier network requests.

[0019] According to a further aspect of the present invention, there is provided a system for handling deferrable network requests, the system comprising a client system having a processor and a memory configured to provide computer program instructions to the processor for performing functions of components: a request intercept component for intercepting the network request; a deferrable request identification component for identifying the network request as deferrable; and a header embedding component for embedding data of the deferrable network request into a header of a preferred carrier network request for transmission to a remote server.

[0020] The client system may include a deferrable request storage component for storing data of the deferrable network request in a local cache at the client in the form of aggregate data of the target destination of the deferrable network request and the request message data, and a carrier request identification component for identifying a preferred carrier network request.

[0021] The client system may include a batch sending component for batch sending cached deferrable network request data when the cache reaches a predetermined size or upon exit from the user agent, and a batch receiving component for receiving batch responses to the deferrable network requests.

[0022] The client system may include a carrier response receiving component for receiving a carrier network response having embedded data of the response to the deferrable network request in a header of the carrier network response, and a response parsing component for parsing the embedded data from the header into a separate response message for performing an action at the client.

[0023] According to another aspect of the present invention, there is provided a system for handling deferrable network requests, the system comprising: a server system having a processor and a memory, the memory configured to provide computer program instructions to the processor to perform functions of components: a carrier request receiving component for receiving a carrier network request having embedded data of the deferrable network request in a header of the carrier network request; and a request parsing component for parsing the embedded data from the header into a separate request message for performing an action at a server.

[0024] The server system may include a response intercepting component for intercepting the network response, a deferrable response identifying component for identifying the deferrable network response, and a header embedding component for embedding data of the deferrable network response within a header of a preferred carrier network response for transmission back to the client.

[0025] The server system may include a deferrable response storage component for storing data of the deferrable network response in a local cache at the server in the form of aggregate data of the target destination of the deferrable network response and the response message data, and a carrier response identification component for identifying a preferred carrier network response.

[0026] The server system may include a batch request receiving component for receiving a batch of deferrable network requests for individual processing at the server, and a batch response sending component for sending a batch of cached deferrable network response data at the server once the cache reaches a predetermined size.

[0027] According to another aspect of the present invention, there is provided a computer program product for handling deferrable network requests, the computer program product comprising a computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a processor to cause the processor to intercept and identify a network request as deferrable and embed data of the deferrable network request into a header of a preferred carrier network request for transmission to a remote server.

[0028] The computer readable storage medium may be a non-transitory computer readable storage medium, and the computer readable program code may be executable by a processing circuit.

[0029] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of this specification. The invention, both as to organization and method of operation, together with its objects, features, and advantages, may best be understood by reference to the following detailed description when read in conjunction with the accompanying drawings.

[0030] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings: [Brief explanation of the drawings]

[0031] [Figure 1] 1 is a schematic diagram of an exemplary embodiment of a method according to the present invention; [Figure 2] 4 is a flow chart of an exemplary embodiment of another aspect of a method in a client according to the present invention; [Figure 3A] 4 is a flow diagram of an exemplary embodiment of a method aspect in a server according to the present invention; [Figure 3B] 4 is a flow diagram of an exemplary embodiment of a method aspect in a server according to the present invention; [Figure 4] FIG. 1 is a block diagram of an exemplary embodiment of a server system according to an aspect of the present invention. [Figure 5] FIG. 10 is a block diagram of an exemplary embodiment of a client system according to another aspect of the present invention. [Figure 6] FIG. 1 is a block diagram of one embodiment of a computer system or cloud server in which the present invention may be implemented. [Figure 7] 1 is a schematic diagram of a cloud computing environment in which the present invention may be implemented. [Figure 8] 1 is a diagram of an abstraction model layer of a cloud computing environment in which the present invention may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0032] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous features.

[0033] A method and system for handling deferrable network requests are described. Network requests in the form of Hypertext Transfer Protocol (HTTP) requests are used for communication between clients and servers in a network environment. An HTTP request method from a client indicates a desired action to be performed at a server for a given resource. The resource is identified by a request Uniform Resource Locator (URL), and each request method implements distinct semantics.

[0034] The described method embeds data of a deferrable request (e.g., a lightweight routine request) within the header of a non-deferrable request (e.g., a functional request) from a client. The header may then be extracted on the server side, and the request data is sent to a destination location on the server side. Corresponding methods are also provided for returning a response of a deferrable request in a reply header of a non-deferrable request.

[0035] 1, a schematic diagram 100 illustrates an exemplary embodiment of a client 110 and a server 120, where HTTP requests and responses are exchanged between the client 110 and the server 120. In this example, a user agent 130 (e.g., a web browser) on the client 110 sends requests to resources 140, 142 (e.g., web applications) on the server 120.

[0036] In a typical request, client 110 sends an HTTP request message to server 120, and server 120, which provides resources 140, 142 such as HTML files and other content or performs other functions on behalf of client 110, returns a response message to client 110. The response includes completion status information about the request and may include the requested content in its message body.

[0037] A web browser is one example of a user agent (UA) 130. Other types of user agents 130 include indexing software used by search providers (web crawlers), voice browsers, mobile applications, and other software that accesses, consumes, or displays web content.

[0038] The deferrable request handling system 150, 155 is provided in the form of a server deferrable request handling component 150 and a client deferrable request handling component 155. The client component 155 may be code provided by the server component 150 to be downloadable or executable on the client 110 to provide functionality complementary to the server component 150. The client component 155 includes or has access to a deferrable request data cache 156 local to the client 110 for caching deferrable requests, as described further below. The server component 150 includes or has access to a deferrable response data cache 152 local to the server 120 for caching deferrable request responses, as described further below.

[0039] The client deferrable request handling system 155 intercepts requests at the client 110 and determines whether the request is deferrable or whether it is non-deferrable and should be sent immediately. If the request is deferrable, it may be cached in the deferrable request data cache 156 until it is combined with a header 170 of a carrier request message 160 and sent in the form of a subsequent non-deferrable request. Several deferrable request messages may be sent in multiple headers 170 of a carrier request message 160.

[0040] A non-deferrable request message acting as a carrier request message 160 may be sent with its own request data 161 and deferrable request data 171 embedded within a header 170 of the carrier request message 160. When such a message is received at the server 120, the server deferrable request handling system 150 handles the carrier message request data 161 and separates the deferrable request data 171, handling the deferrable request data 171 separately.

[0041] Once the deferrable request data 171 has been acted upon and the deferrable response data 191 is available, the deferrable response data 191 may be cached in a deferrable response data cache 152 local to the server 120 to await a carrier response message 180 and deliver the carrier response message 180 to a client deferrable request handling system 155 in the user agent 130 of the client 110.

[0042] A non-deferrable response message may act as a carrier response message 180 and may be sent with its own response data 181 and deferrable response data 191 embedded in the header 190 of the carrier response message 180. When such a message is received at the client 110, the client deferrable request handling system 155 handles the carrier message response data 181 and separates the deferrable response data 191, handling the deferrable response data 191 separately.

[0043] Further details of exemplary embodiments of the methods at the server and client are provided below.

[0044] A request message contains a request line that specifies the request method and requests a specified resource from the server, request header fields, a blank line, and an optional message body.

[0045] HTTP defines request methods that may be the subject of a request message to indicate a desired action to be performed by the server 120 on an identified resource 140, 142. Examples of request methods include, but are not limited to, methods for identifying and / or resolving errors (e.g., a TRACE HTTP request), receiving status notifications (e.g., a STATUS HTTP request), retrieving information (e.g., a GET HTTP request), transmitting data (e.g., a POST HTTP request), deleting pre-defined information (e.g., a DELETE HTTP request), establishing a communication flow (e.g., a CONNECT HTTP request), describing communication options (e.g., an OPTIONS HTTP request), creating a new resource or replacing a resource (e.g., a PUT HTTP request), making partial modifications to a resource (e.g., a PATCH HTTP request), and requesting headers for a resource (e.g., a HEAD HTTP request).

[0046] Some request messages may be considered deferrable if they are not time-sensitive and do not need to be processed immediately by the server. One example is tracking data for user analytics. Such tracking data is useful to developers in understanding user behavior, but is not critical to the immediate functionality of the web application. On the other hand, request messages related to the functionality of the web application are non-deferrable.

[0047] HTTP headers allow clients and servers to pass additional information with an HTTP request or response. Custom, proprietary headers may have an "X-" prefix. This additional information, in the form of a message destination and data, is used in the manner described for data associated with a deferrable request message. The server then handles the request data by extracting the header information and sending the request data to the message destination.

[0048] The non-deferrable request message forms a carrier request message having a header containing the destination and data of the deferrable request message. The carrier request message and the deferrable request message may be associated with different request methods.

[0049] Referring to FIG. 2, a flow diagram 200 illustrates an exemplary embodiment of the described method performed at the client 110 by the client deferrable request handling system 155.

[0050] The client deferrable request handling system 155 may receive 201 code for a client-side user agent, such as a web browser or client application, that sends an HTTP request message to a server with the server deferrable request handling system 150. The client deferrable request handling system 155 may be provided, for example, as a browser extension for intercepting deferrable HTTP requests and caching deferrable request data. The client deferrable request handling system 155 may intercept HTTP requests at the native browser network level or patch calls to "fetch" or XMLHttpRequest functions used by the client application.

[0051] The client deferrable request handling system 155 may obtain (202) a predefined header name to use when sending a deferrable request message embedded within the header of another request message. For example, the predefined header name may be obtained by the client deferrable request handling system 155 making a REST call to the server. In the case of a custom header, the client may call a known server route, e.g., / api / getDeferrableHeader, which responds with the name of the header to be used for that session (which may be generated, for example, using a universally unique identifier). Alternatively, a fixed predefined header name may be used for all such messages.

[0052] A method at the client may detect (203) a new HTTP request message to be sent to the server, and the method determines (204) whether the request message is deferrable. Whether a request is deferrable may depend on the request's destination hostname and / or path. A request message may be determined to be deferrable (204) by checking whether the request message is being sent to a host in a preconfigured list. The list may be maintained by the server and exposed to clients via a REST interface.

[0053] Additionally, a request message may only be deferrable if it is below a given size: the size of the request header fields is typically between 200 bytes and 2 kbytes, and the deferrable request data must fit within the request header.

[0054] If the request message is deemed deferrable, the method may determine whether the cache of deferrable request messages exceeds a given limit (205). If the cache does not exceed the given limit, the new deferrable request message is aggregated (206) into a format that includes the request destination and data and stored in the cache (207). The method then ends (213) for this request message, and the method may loop (203) to detect new request messages.

[0055] If the cache is determined to exceed a given limit (205), the cached deferrable request data may be sent as a batch request message (208) to clear the cache or make room in the cache. A special request may be made to send a batch request message (208) to which the cached requests are attached, treated like non-deferrable requests. One of the deferrable requests may be selected as the carrier request for other deferrable requests in the cache. For each deferrable request added to the carrier message header, the deferrable request is marked as "in progress / sent." A special request may be made to a custom route provided by the server, and the server returns an empty response. Once space is available in the cache, additional deferrable request data may be stored.

[0056] If the request message is determined not to be deferrable (204), it may be determined (209) whether the request message is suitable as a carrier message for a deferrable request message. For example, whether there is space in the request message to carry one or more deferrable request messages in one or more headers. If there is not enough space or there is another reason the request message does not carry a deferrable request message, the method may send (212) the request message without carrying a deferrable request message. The method may then end (213) for this request message and loop (203) to detect new request messages.

[0057] If the request message is suitable as a carrier message, the method may check whether the request message data is in the cache (210). If there is no cached request message data, the method may send the request message (212). If there is cached request message data, the destination and data of the cached aggregated request are added to the header fields of the carrier request message (211). Multiple deferrable requests may be attached to a single carrier message, and multiple deferrable requests may be attached via separate headers, e.g., "X-Deferrable-Data," then "X-Deferrable-Data-2," "X-Deferrable-Data-3," etc. For each deferrable request added to the carrier message header, the deferrable request is marked as "in progress / sent."

[0058] Once the deferrable request message data has been added to one or more header fields of the message request, the request message may be sent 212. The method may then end 213 for this request message and loop 203 to detect new request messages.

[0059] When a user navigates away from a user agent 130, such as a web application or web browser, the cached data for all deferrable request data that has not yet been sent is sent as a separate special batch request. The method may issue the special batch request in a manner similar to the "cache full" scenario described above. As described above, this special batch may have multiple deferrable requests attached to it.

[0060] Below is an example of the format of the request message:

[0061] Deferrable Requests: POST https: / / datacollectionresource / tracking {... tracking data ...}

[0062] Normal request: POST https: / / domain.com / api / flows / flow1 / start {... request data ...}

[0063] Single combined request: POST https: / / domain.com / api / flows / flow1 / start {... request data ...} With the following additional headers: X-Deferrable-Data:{ destination: https: / / datacollectionresource / tracking data: {... trackingdata...}, method: 'POST'}

[0064] The deferrable data provided in the header requires all parameters required by the original request. In the simplest case, this may be just a method or a combination of a method and a body, but it may also include all properties defined by the request fetch interface.

[0065] When a new HTTP response message is received at client 110, it is determined whether the response message includes a deferrable response in its header. If so, a successful deferrable response is extracted and sent to each requestor, and the deferrable request is removed from deferrable request data cache 156.

[0066] Referring to FIG. 3A, a flow diagram 300 illustrates an exemplary embodiment of the described method performed at the server 120 by the server deferrable request handling system 150.

[0067] The server deferrable request handling system 150 may provide code for a client-side user agent, such as a web browser or client application, to send an HTTP request message to the server 120 (301).

[0068] The server deferrable request handling system 150 may provide a predefined header name to use when sending a deferrable request message embedded within the header of another request message (302). For custom headers, the client may call a known server route, e.g., / api / getDeferrableHeader, which responds with the name of the header to be used for that session (which may be generated, for example, using a universally unique identifier). Alternatively, a fixed predefined header name, e.g., "X-Deferrable-Data", may be used for all such messages.

[0069] The server deferrable request handling system 150 may receive a request that includes one or more headers with a defined header name and in which aggregated deferrable request data is embedded within the one or more headers (303). The aggregated deferrable request data may combine the target destination of the deferrable request with the data of the deferrable request. The method may parse the embedded aggregated deferrable request data from the header (304) and send the extracted data to the target destination provided in the aggregated deferrable request data (305).

[0070] Responses from deferrable requests may be cached at server 120 (306), and when a non-deferrable request returns a response, any deferrable request responses in the cache may be added in the reply headers (307). The client side may then extract and process the deferrable request responses appropriately.

[0071] Referring to FIG. 3B, a flow diagram 320 illustrates further details of an exemplary embodiment of the described method performed at the server 120 by the server deferrable request handling system 150.

[0072] A method at the server may detect a new HTTP response message to be sent to the client (321), and the method determines whether the response message is a response to a deferrable request and is therefore also deferrable (322). A response message may be determined to be deferrable by checking whether the response is to a request message sent to a host in a preconfigured list maintained by the server (322).

[0073] If the response message is deemed deferrable, the method may determine whether the cache of deferrable response messages exceeds a given limit (323). If the cache does not exceed the given limit, the new deferrable response message is aggregated (324) into a format that includes a response destination and response data and stored in the cache (325). The method then ends (326) for this response message, and the method may loop (321) to detect new response messages.

[0074] If the cache is determined to exceed a given limit (323), the cached deferrable response data may be sent as a batch response message (327) to clear or make room in the cache. A special response may be made (327) to send a batch response message that is treated like a non-deferrable response, with the cached response appended. Once space is made in the cache, additional deferrable response data may be stored.

[0075] If it is determined (322) that the response message is not deferrable, it may be determined (328) whether the response message is suitable as a carrier response message for a deferrable response message. For example, whether there is space in the response message to carry one or more deferrable response messages in one or more headers. If there is not enough space or there is other reason that the response message does not carry a deferrable response message, the method may send (331) the response message without carrying a deferrable response message. The method may then end (326) for this response message and loop to detect (321) a new response message.

[0076] If the response message is suitable as a carrier response message, the method may check whether there is response message data in the cache (329). If there is no cached response message data, the method may send the response message (331). If there is cached response message data, the destination and data of the aggregated form of the cached response are added to the header fields of the carrier response message (330). Multiple deferrable responses may be attached to a single carrier message, and multiple deferrable responses may be attached via separate headers, e.g., "X-Deferrable-Data," then "X-Deferrable-Data-2," "X-Deferrable-Data-3," etc.

[0077] Once the deferrable response message data has been added to one or more header fields of the message response, the response message may be sent 331. The method may then end 326 for this response message and loop 321 to detect new response messages.

[0078] Referring to FIG. 4, a block diagram illustrates a client computer system 400 in which a client deferrable request handling system 155 may be provided for use by a user agent 130 at the client computer system 400 .

[0079] The server includes circuitry for performing the functions of the described components, which may be at least one processor 401, a hardware module, or a software unit running on at least one processor. Multiple processors may be provided that execute parallel processing threads, allowing for parallel processing of some or all of the components' functions. Memory 402 may be configured to provide computer instructions 403 to the at least one processor 401 to perform the functionality of the components. A client deferrable request handling system 155 may be provided by the server to execute on the client computer system 400 in conjunction with the server deferrable request handling system 150.

[0080] The client deferrable request handling system 155 may include a request interception component 411 for intercepting network requests at the native browser network level or at the user agent 130 as a function of a client application. The client deferrable request handling system 155 may include a deferrable request identification component 412 for identifying network requests as deferrable. The deferrable request identification component 412 may include a list search component 413 for searching a server-provided pre-configured list of destination host names for which the request may be deferrable.

[0081] The client deferrable request handling system 155 may include a deferrable request storage component 414 for storing data of deferrable network requests in a local deferrable request data cache 156 at the client computer system 400, and an aggregation component 418 for aggregating data of deferrable requests as a combination of target destination and request message data.

[0082] The client deferrable request handling system 155 may include a carrier request identification component 415 for identifying a suitable carrier network request and a header embedding component 416 for embedding aggregate data for each of the multiple deferrable requests from the cache 156 into multiple headers of the carrier network request. The header embedding component 416 may obtain a predefined header name from the server to use when embedding the deferrable request data into the header.

[0083] The client deferrable request handling system 155 may include a batch request sending component 417 for batch sending cached deferrable network request data when the cache reaches a predetermined size or when it exits the user agent.

[0084] The client deferrable request handling system 155 may also include components for handling responses received in response carrier messages, including a carrier response receiving component 421 for receiving a carrier network response with embedded data of the response to the deferrable network request in a header of the carrier network response, and a response parsing component 422 for parsing the embedded data from the header into separate response messages for action at the client by a response handling component 423. A batch response receiving component 424 may also be provided for receiving and handling batch responses to the deferrable network requests.

[0085] Referring to FIG. 5, a block diagram illustrates a server computer system 500 in which the server deferrable request handling system 150 is provided.

[0086] The server includes circuitry for performing the functions of the described components, which may be at least one processor 501, a hardware module, or a software unit running on at least one processor. Multiple processors may be provided that execute parallel processing threads, allowing for parallel processing of some or all of the component's functionality. Memory 502 may be configured to provide computer instructions 503 to the at least one processor 501 to perform the component's functionality.

[0087] The server deferrable request handling system 150 may include a carrier request receiving component 521 for receiving a carrier network request with embedded data of the deferrable network request in a header of the carrier network request, and a request parsing component 522 for parsing the embedded data from the header into separate request messages for action by a request handling component 523 at the server computer system 500. The server deferrable request handling system 150 may include a batch request receiving component 524 for receiving a batch of deferrable network requests for individual processing at the server computer system 500.

[0088] The server deferrable request handling system 150 may include a response interception component 511 for intercepting network responses and a deferrable response identification component 512 for identifying deferrable network responses, for example, by searching a server-provided pre-configured list of destination host names for which responses may be deferrable using a list search component 513.

[0089] The server deferrable request handling system 150 may include a deferrable response storage component 514 for storing data of deferrable network responses in a local deferrable response data cache 152 at the server computer system 500. An aggregation component 518 may aggregate deferrable response data of target destinations and response message data of deferrable network responses for storage in the cache 152.

[0090] The server deferrable request handling system 150 may include a carrier response identification component 515 for identifying a preferred carrier network response and a header embedding component 516 for embedding data of the deferrable network response within a header of the preferred carrier network response for transmission back to the client.

[0091] The server deferrable request handling system 150 may include a batch response sending component 517 for sending a batch of cached deferrable network response data once the cache reaches a predetermined size at the server.

[0092] 6 illustrates a block diagram of components of a computing system that may be used for server computer system 400 or client computer system 500 in accordance with one embodiment of the present invention. It should be understood that FIG. 6 is provided as an example of one implementation only and is not intended to imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may also be made.

[0093] The computing system may include one or more processors 602, one or more computer-readable RAMs 604, one or more computer-readable ROMs 606, one or more computer-readable storage media 608, device drivers 612, read / write drives or interfaces 614, and network adapters or interfaces 616, all interconnected through a communications fabric 618. The communications fabric 618 may be implemented to have any architecture designed to pass data and / or control information between processors (such as microprocessors, communications and network processors), system memory, peripheral devices, and any other hardware components in the system.

[0094] One or more operating systems 610 and application programs 611, such as server deferrable request handling system 150 and client deferrable request handling system 155, are stored in one or more computer-readable storage media 608 for execution by one or more of processors 602 through one or more of respective RAMs 604 (which typically include cache memory). In the illustrated embodiment, each of computer-readable storage media 608 may be a magnetic disk storage device such as an internal hard drive, a CD-ROM, a DVD, a memory stick, magnetic tape, a magnetic disk, an optical disk, a semiconductor storage device such as RAM, ROM, EPROM, flash memory, or any other computer-readable storage medium capable of storing computer programs and digital information according to embodiments of the present invention.

[0095] The computing system may also include a R / W drive or interface 614 for reading from and writing to one or more portable computer-readable storage media 626. Application programs 611 on the computing system may be stored on one or more portable computer-readable storage media 626 and read via the respective R / W drive or interface 614 and loaded into the respective computer-readable storage media 608.

[0096] The computing system may also include a network adapter or interface 616, such as a TCP / IP adapter card or a wireless communications adapter. Application programs 611 on the computing system may be downloaded to the computing device from an external computer or external storage device via a network (e.g., the Internet, a local area network, or other wide area or wireless network) and the network adapter or interface 616. From the network adapter or interface 616, the program may be loaded into the computer-readable storage medium 608. The network may include copper wire, fiber optic, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0097] The computing system may also include a display screen 620, a keyboard or keypad 622, and a computer mouse or touchpad 624. The device driver 612 interfaces to the display screen 620 for imaging and to the keyboard or keypad 622, computer mouse or touchpad 624, and / or display screen 620 for alphanumeric entry and pressure sensing of user selections. The device driver 612, R / W drive or interface 614, and network adapter or interface 616 may comprise hardware and software stored in the computer-readable storage medium 608 and / or ROM 606.

[0098] The present invention may be a system, method, and / or computer program product at any possible level of integration of technical details, and may include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0099] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as raised structures in grooves with instructions recorded thereon, and any suitable combination of the above. As used herein, computer-readable storage media should not be construed as being ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through fiber optic cable), or electrical signals transmitted over electrical wires.

[0100] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0101] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer as a standalone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry.

[0102] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0103] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable medium, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions implementing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, and can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0104] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to create a computer-implemented process that causes the computer, other programmable apparatus, or other device to perform a series of operational steps, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0105] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be accomplished as a single step, or may be executed concurrently, substantially concurrently, partially, or fully in a time-overlapping manner, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified functions or actions or a combination of dedicated hardware and computer instructions.

[0106] Cloud Computing Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0107] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0108] The features are as follows: On-Demand Self-Service: Cloud consumers can unilaterally provision computing capabilities, such as server time and network storage, automatically as needed, without the need for human interaction with the service provider. Broad network access: Functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). Resource Pooling: Provider computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated as required. Consumers generally have no control or knowledge of the exact location of the provided resources, although there is location independence in that it may be possible to identify the location at a higher level of abstraction (e.g., country, state, or data center). Rapid Flexibility: Capabilities can be quickly and flexibly provisioned, sometimes automatically, to rapidly scale out and quickly release to rapidly scale in. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased at any time and in any quantity. Service Metering: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services they utilize.

[0109] The service model is as follows: Software as a Service (SaaS): The ability to offer consumers the use of a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). With the possible exception of limited user-specific application configuration settings, the consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functions. Platform as a Service (PaaS): The capability offered to consumers to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, such as the network, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the application hosting environment configuration. Infrastructure as a Service (IaaS): The capability offered to consumers to provision processing, storage, network, and other basic computing resources on which they can deploy and run any software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do control the operating systems, storage, deployed applications, and sometimes have limited control over selected network components (e.g., host firewalls).

[0110] The deployment model is as follows: Private Cloud: Cloud infrastructure is operated exclusively for an organization. This cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises. Community Cloud: Cloud infrastructure is shared by multiple organizations to support a specific community of shared interests (e.g., mission, security requirements, policies, and compliance considerations). This cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises. Public Cloud: Cloud infrastructure is available to the general public or large industry groups and is owned by organizations that sell cloud services. Hybrid Cloud: A cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are tied together by standardized or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).

[0111] Cloud computing environments are service-oriented with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0112] Referring now to FIG. 7, an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, can communicate. The nodes 10 may communicate with each other. They may be physically or virtually grouped in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described herein above (not shown). This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service without requiring the cloud consumer to maintain resources on their local computing device. It should be understood that the types of computing devices 54A-54N shown in FIG. 7 are intended to be exemplary only, and that the computing node 10 and cloud computing environment 50 can communicate with any type of computerized device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0113] Referring now to Figure 8, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 7) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 8 are intended to be exemplary only, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0114] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0115] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0116] In one example, the management layer 80 may provide the following functions: Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides allocation and management of cloud computing resources to ensure requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-allocation and procurement of cloud computing resources anticipated for future requests according to SLAs.

[0117] The workload tier 90 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and request latency processing 96.

[0118] The computer program product of the present invention comprises one or more computer-readable hardware storage devices having computer-readable program code stored thereon, said program code being executable by one or more processors to perform the methods of the present invention.

[0119] The computer system of the present invention comprises one or more processors, one or more memories, and one or more computer-readable hardware storage devices, the one or more hardware storage devices containing program code executable by the one or more processors via the one or more memories to implement the methods of the present invention.

[0120] While the description of various embodiments of the present invention has been presented for illustrative purposes, this description is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements beyond those found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0121] Improvements and modifications can be made to the foregoing without departing from the scope of the present invention.

Claims

1. 1. A computer-implemented method comprising: intercepting, by a user agent of a client, a network request and identifying it as deferrable; embedding said deferrable network request data within a header of a preferred carrier network request for transmission to a remote server; 20. A computer-implemented method comprising:

2. storing the data for the deferrable network request in a local cache at the client in the form of an aggregate of a target destination and request message data for the deferrable network request; Identifying a preferred carrier network requirement; embedding the aggregate data of the deferrable request within the header of the carrier network request; The computer-implemented method of claim 1 further comprising:

3. The computer-implemented method of claim 2 , further comprising embedding the aggregated data for each of a plurality of deferrable requests in one of a plurality of headers of the carrier network request.

4. The computer-implemented method of claim 1 , wherein the preferred carrier network request is not deferrable and has sufficient space for the deferrable request data.

5. 2. The computer-implemented method of claim 1, wherein identifying a network request as deferrable comprises intercepting a network request message and determining whether the request network message is being sent to a host in a list of predefined deferrable destinations.

6. The computer-implemented method of claim 1 , further comprising obtaining a predefined header name from a server for use when embedding deferrable request data within the header.

7. 3. The computer-implemented method of claim 2, further comprising: batch transmitting cached deferrable network request data when the cache reaches a predetermined size or upon exiting from the user agent, wherein the batch transmitting selects a cached deferrable network request as a carrier network request and adds other cached deferrable request data to one or more headers of the carrier network request.

8. receiving a carrier network response with embedded data of a response to the deferrable network request within a header of the carrier network response; parsing the embedded data from the header into a separate response message for performing an action at the client; and The computer-implemented method of claim 1 , comprising:

9. for each deferrable network request added to the preferred carrier network message, marking said deferrable network request as in progress; and updating said deferrable network request when a successful response is received. The computer-implemented method of claim 1 further comprising:

10. 1. A computer-implemented method comprising: receiving, at a server, a carrier network request having embedded data of a deferrable network request in a header of the carrier network request; parsing the embedded data from the header into a separate request message for performing an action at the server; and 20. A computer-implemented method comprising:

11. 11. The computer-implemented method of claim 10, wherein the embedded data of a deferrable network request is aggregate data of a target destination and request message data of the deferrable network request, and parsing the embedded data forms a separate request message to the target destination.

12. Intercepting and identifying deferrable network responses; embedding data of said deferrable network response within a header of a preferred carrier network response for transmission back to the client; The computer-implemented method of claim 10 further comprising:

13. storing the data of the deferrable network response in a local cache at the server in the form of an aggregate of target destinations and response message data of the deferrable network response; Identifying a preferred carrier network response; embedding the aggregate data of the deferrable response within the header of the carrier network response; The computer-implemented method of claim 12 further comprising:

14. 14. The computer-implemented method of claim 13, further comprising embedding the aggregated data for each of a plurality of deferrable responses in one of a plurality of headers of the carrier network request.

15. 11. The computer-implemented method of claim 10, further comprising transmitting from the server a predefined header name for use by a user agent when embedding deferrable request data in the header of a carrier network request.

16. 11. The computer-implemented method of claim 10, further comprising receiving a batch of deferrable network requests for individual processing at the server in the form of the deferrable network requests as carrier network requests and other cached deferrable request data provided in one or more headers of the carrier network requests.

17. 1. A computer program product comprising: one or more computer-readable storage media; and program instructions stored on the one or more computer-readable storage media, the program instructions comprising: program instructions for intercepting network requests and deferrable requests; program instructions for identifying the intercepted network request as deferrable; program instructions for embedding data of the deferrable network request within a header of a preferred carrier network request for transmission to a remote server; 1. A computer program product comprising:

18. The computer program product is a client system further comprising program instructions stored on the one or more computer-readable storage media, the program instructions comprising: program instructions for storing the data of the deferrable network request in a local cache at the client in the form of aggregate data of a target destination and request message data of the deferrable network request; program instructions for identifying components for identifying preferred carrier network requirements; 20. The computer program product of claim 17, further comprising:

19. The program instructions stored on the one or more computer-readable storage media include: program instructions for transmitting cached deferrable network request data when said cache reaches a predetermined size or upon exit from said user agent; program instructions for receiving batch responses to deferrable network requests; 20. The computer program product of claim 18, comprising:

20. The program instructions stored on the one or more computer-readable storage media include: program instructions for receiving a carrier network response having embedded data of a response to the deferrable network request within a header of the carrier network response; program instructions for parsing the embedded data from the header into a separate response message for performing an action at the client; 20. The computer program product of claim 17, further comprising:

21. 1. A computer system comprising: A server system having a processor and a memory, said memory comprising components: a carrier request receiving component for receiving a carrier network request with embedded data of the deferrable network request in a header of the carrier network request; a request parsing component for parsing the embedded data from the header into a separate request message for performing an action at the server; a computer system configured to provide computer program instructions to said processor for performing the functions of

22. The server system, a response intercept component for intercepting a network response; and a deferrable response identification component for identifying a deferrable network response; a header embedding component for embedding data of the deferrable network response within a header of a preferred carrier network response for transmission back to the client; 22. The computer system of claim 21, comprising:

23. The server system, a deferrable response storage component for storing the data of the deferrable network response in a local cache at the server in the form of aggregate data of a target destination and response message data of the deferrable network response; a carrier response identification component for identifying a preferred carrier network response; 23. The computer system of claim 22, comprising:

24. The server system, a batch request receiving component for receiving a batch of deferrable network requests for individual processing at the server; a batch response transmission component for transmitting a batch of cached deferrable network response data when the cache reaches a predetermined size at the server; 22. The computer system of claim 21, comprising:

25. 1. A system for handling deferrable network requests, comprising: A client system having a processor and a memory, said memory comprising: a request intercept component for intercepting network requests; and a deferrable request identification component for identifying network requests as deferrable; a header embedding component for embedding data of the deferrable network request into a header of a preferred carrier network request for transmission to a remote server; a system configured to provide said processor with computer program instructions for performing the functions of

Images