Patent Application
20070226292
The invention relates generally to computer data processing, and particularly to ensuring that independently dispatched fragments of a request execute with the required context.
Clients use distributed computer environments to perform a variety of tasks across multiple applications. For a typical task, a client sends a request to a distributed computer environment, which returns a response to the client. While this seems simple enough, there are actually several intermediate steps involved in executing such a request. First, a user or an application initiates the client request by sending the request to a surrogate computer (hereafter “surrogate”), which is a computer that acts as an intermediary between the client and the distributed computer environment. The surrogate may perform such tasks as verifying the client's security credentials and determining which resource on the distributed computer environment is appropriate for executing the client's request. Second, the surrogate forwards the request to the appropriate resource on the client's behalf. Third, after the request executes on the resource, the response returns to the surrogate, which sends the response to the client.
Certain fragment markup and assembly technologies, such as EDGE SIDE INCLUDE (ESI), DELTA ENCODING, and other fragment markup and assembly engines allow for the fragmentation of requests under certain circumstances in the surrogates. Often, requests can be split into multiple smaller tasks, or “fetches” and distributed across multiple resources. After all the fetches are executed, the fragmented responses are reassembled and returned to the client. Fragmentation allows for more efficient use of resources and for lower cycle-times on a distributed computer environment. However the use of these technologies does not yield correct results when these fragments have to use context associated with the logical request. For example, consider the following scenario. A client makes a request which passes along attribute X. The request asks a first application(A) to set attribute Y, and then uses a second application(B) to perform a database lookup using both attributes X and Y. The request can be fragmented into two parts: “set Y” and “perform database look-up.” The first application that calculates Y associates this attribute with the request context, this context needs to be available when the code for the second application executes for the database look-up to succeed. As long as there is no fragmentation and the request executes sequentially in a single execution thread, the context is available to both the applications. If the fragments are dispatched independently to different execution environments from the surrogate, the context set by application A is not available to the fragment executing in Application B.
The Fragment may execute in the sequence defined by the logical application, but since the context is associated with the execution environment of the fragments and is lost after each fragment executes, the updates to the context are not available for proper execution of subsequent fragments.
A Fragment Context Preserver ensures that independently dispatched fragments of a request execute with a required context. The Fragmented Context Preserver has two components, a Fragmented Request Preserver and a Request Context Helper. A Fragmented Request Preserver program runs on a surrogate attached to a client computer and distributed computer environment, and a Request Context Helper runs on each application server on the distributed computer environment. The Fragmented Request Preserver adds an attribute to each fragment of a request to indicate the beginning, middle and end of a logical request. When a client sends a request to a distributed computer environment, the Fragmented Request Preserver adds metadata to the request, indicating that it is a new logical request, then forwards the request to an application on a server in the distributed computer environment. If the application server chooses not to execute the entire request at once, the Request Context Helper at the application server will split the request into fragments and send the request fragments back to the surrogate as a “deferred response.” The deferred response may include a partial response to the initial request, such as setting an attribute needed to execute a subsequent fragment.
The Request Context Helper will embed any updates to the context in an opaque serialized form in the response. The updated context can be secured so that only authorized Request Context Helper can read the context. The Fragmented Request Preserver at the surrogate dispatches each fragment with any opaque updates received from prior fragment responses for the logical request in sequence and receives the responses for each fragment. The Request Context Helper at the application server securely retrieves any updates to the context that were sent with a fragment request, deserializes the updates and makes the context available in the execution environment prior to execution of the fragment. The Fragmented Request Preserver at the surrogate also adds metadata to the last fragment indicating that the sequence of fetches is over. This allows the Request Context Helper at the application server to release any resources held for the duration of the logical request. The Fragmented Request Preserver combines all the responses including cached fragments and forwards them to the client. By ensuring that the fragments have the updated context the Fragmented Request Preserver allows for fragmentation of requests that set and get attributes across multiple applications.
The principles of the present invention are applicable to a variety of computer hardware and software configurations. The term “computer hardware” or “hardware,” as used herein, refers to any machine or apparatus that is capable of accepting, performing logic operations on, storing, or displaying data, and includes without limitation processors and memory; the term “computer software” or “software,” refers to any set of instructions operable to cause computer hardware to perform an operation. A “computer,” as that term is used herein, includes without limitation any useful combination of hardware and software, and a “computer program” or “program” includes without limitation any software operable to cause computer hardware to accept, perform logic operations on, store, or display data. A computer program may, and often is, comprised of a plurality of smaller programming units, including without limitation subroutines, modules, functions, methods, and procedures. Thus, the functions of the present invention may be distributed among a plurality of computers and computer programs. The invention is described best, though, as a single computer program that configures and enables one or more general-purpose computers to implement the novel aspects of the invention. For illustrative purposes, the inventive computer program will be referred to as the “Fragment Context Preserver.”
Additionally, the Fragment Context Preserver described below with reference to an exemplary network of hardware devices, as depicted in
Fragment Context Preserver 200 typically is stored in a memory, represented schematically as memory 220 in
If at step 318, a determination is made that a response is a deferred response, Fragmented Request Preserver 300 determines whether the response is not in response cache 250 and is cacheable (320). In other words, some responses, referred to as eligble responses, are cacheable and are cached along with their context metadata, and this step is different from temporarily storing fragment responses until they are aggregated with the scope of a logical request. The reason for this determination is to set two conditions that must be satisfied before a response can be saved to the response cache as an eligible response. First, the same response must not be previously saved to the response cache, and the response must be capable of being saved. These conditions prevent duplicate response from being save in the response cache, and prevents attempts at saving responses that cannot be saved. An example of a response that cannot be saved is a command rather than discrete data. It the response is cacheable, Fragmented Request Preserver 300 saves any initial response information, such as attributes, to response cache 250 (322). If the response is not cacheable, Fragmented Request Preserver 300 iterates through fragments in sequence, using the sequencing and context information in the metadata protocol headers (324).
If an attribute or context needs to be added to a fragment (326), Fragmented Request Preserver 300 adds the context (328), which may have been saved in response cache 250, before dispatching the fragment to target applications 230 (330). In other words, Fragmented Request Preserver adds metadata referencing updates to context from previous fragment fetches within the scope of the logical request. In addition to adding attributes and contexts, Fragmented Request Preserver 300 may add other information to the metadata protocol header, such as terminating context propagation with the final fragment. Fragmented Request Preserver 300 receives the response from target applications 230 (332) and determines whether there are more fragments left to dispatch (334). If there are more fragments, Fragmented Request Preserver 300 goes to step 320, and if not, (the final fragment has been dispatched) combines all the responses stored in response cache 250 (336), sends the combined response to the client (338), and stops (340).
Numeral 507 represents Surrogate 550 dispatching fragment 1 with attribute X to application server 580. Numerical 508 represents application server 420 setting attribute “Y” in response to the fragment 1 and attribute X. Numeral 509 represents application server 580 sending the response with attributes X and Y to Surrogate 550. Numeral 510 represents Surrogate 550 receiving the response and saving the response to response cache 250. Numeral 511 represents Surrogate 550 dispatching fragment 2 with attributes X and Y to application server 580. Fragment 2 also contains metadata protocol header information to terminate context propagation. Numeral 512 represents application server 580 performing required actions using attributes X and Y in response to fragment 2. Numeral 513 represents application server 580 sending the final response to Surrogate 550. Numeral 514 represents surrogate 550 receiving the response and combining the response with the previous responses in response cache 250. Numeral 515 represents surrogate 550 sending the combined response to the client.
In an embodiment, the Fragment Context Preserver can increase communication security and efficiency of the distributed computer environment by only including the least amount of relevant metadata related to sequence and attributes and by encoding and decoding the information contained in the metadata.
A preferred form of the invention has been shown in the drawings and described above, but variations in the preferred form will be apparent to those skilled in the art. The preceding description is for illustration purposes only, and the invention should not be construed as limited to the specific form shown and described. The scope of the invention should be limited only by the language of the following claims.
