BRIEF DESCRIPTION OF DRAWINGS
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will be understood best by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
FIG. 1 depicts an exemplary computer network;
FIG. 2 depicts an exemplary memory on a computer containing the Fragment Aggregator;
FIG. 3 depicts a flowchart of a Fragmented Dispatcher;
FIG. 4 depicts a flowchart of an Application Helper;
FIG. 5 depicts a diagram of a fragmented request being dispatched to isolated web applications using the prior art; and
FIG. 6 depicts a diagram of a fragmented request being dispatched to isolated web applications using a surrogate and the fragment aggregator.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
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 Aggregator.”
Additionally, the Fragment Aggregator is described below with reference to an exemplary network of hardware devices, as depicted in FIG. 1. A “network” comprises any number of hardware devices coupled to and in communication with each other through a communications medium, such as the Internet. A “communications medium” includes without limitation any physical, optical, electromagnetic, or other medium through which hardware or software can transmit data. For descriptive purposes, exemplary network 100 has only a limited number of nodes, including workstation computer 105, workstation computer 110, server computer 115, and persistent storage 120. Network connection 125 comprises all hardware, software, and communications media necessary to enable communication between network nodes 105-120. Unless otherwise indicated in context below, all network nodes use publicly available protocols or messaging services to communicate with each other through network connection 125.
Fragment Aggregator 200 typically is stored in a memory, represented schematically as memory 220 in FIG. 2. The term “memory,” as used herein, includes without limitation any volatile or persistent medium, such as an electrical circuit, magnetic disk, or optical disk, in which a computer can store data or software for any duration. A single memory may encompass and be distributed across a plurality of media. Further, Fragment Aggregator 200 may reside in more than one memory distributed across different computers, servers, logical partitions or other hardware devices. The elements depicted in memory 220 may be located in or distributed across separate memories in any combination, and Fragment Aggregator 200 may be adapted to identify, locate and access any of the elements and coordinate actions, if any, by the distributed elements. Thus, FIG. 2 is included merely as a descriptive expedient and does not necessarily reflect any particular physical embodiment of memory 220. As depicted in FIG. 2, though, memory 220 may include additional data and programs. Of particular import to Fragment Aggregator 200, memory 220 may include Web Applications 230, Fragment Markup and Assembly Engine 240, and Response Cache 250 with which Fragment Aggregator 200 interacts. Web Applications 230 perform tasks by responding to requests. Fragment Markup and Assembly Engine 240 fragments requests intended for Web Applications 230. Fragment Markup and Assembly Engine 240 may be an ESI engine. Response Cache 250 is a temporary storage for responses to dispatched fragments. Fragment Aggregator 200 has two components: Fragment Dispatcher 300 and Application Helper 400. The Fragment Dispatcher 300 in this example operates on a surrogate computer responsible for propagating requests to network 100. Application Helper 400 operates on a web application server in conjunction with Fragment Markup and Assembly Engine 240 and Web Applications 230.
FIG. 3 is a flowchart depicting the logic of Fragment Dispatcher 300. Fragment Dispatcher 300 starts when an initial request is made by a client (310). Fragment Dispatcher 300 appends the initial request with a metadata protocol header (312). The protocol header initializes the context propagation. Fragment Dispatcher 300 dispatches the initial request to web applications 230 (314). Fragment Dispatcher 300 receives a response to the initial request (316), and determines if web applications 230 made a normal response or a deferred response (318). A normal response is sent to the client (338) and Fragment Dispatcher 300 ends (340). A deferred response occurs when web applications 230 require other isolated web applications to execute the request. Fragment Markup and Assembly Engine 240 splits the initial request into a sequence of fragments to be run on other isolated web applications 230. Application Helper 400 appends each fragment with metadata protocol headers identifying which web application should run the fragment (see FIG. 4). Additional metadata provided by Application Helper 400 specifies sequence information and whether each fragment requires specific attributes or contexts in order to execute properly. An attribute sent as a response to a fragment can be appended as a context when dispatching a subsequent fragment. In the case of a deferred response, web applications 230 may execute one or more fragments as part of the response, such as setting an initial attribute.
If at step 318, a determination is made that a response is a deferred response, Fragment Dispatcher 300 reads the initial response information in each fragment's metadata protocol header (320) and saves the information to response cache 250 (322). Fragment Dispatcher 300 iterates through each fragment in sequence, using the sequencing and context information in the metadata protocol headers (324).
If an attribute or other context needs to be added to a fragment (326), Fragment Dispatcher 300 adds the context (328), which may have been saved in response cache 250, before dispatching the fragment to web applications 230 (330). In other words, Fragment Dispatcher 300 adds metadata referencing updates to context from previous fragment responses within the scope of the logical request. In addition to adding attributes and contexts, Fragment Dispatcher 300 may add other information to the metadata protocol header, such as terminating context propagation with the final fragment or including any delegated security credentials from the original client necessary to access an isolated web application. Fragment Dispatcher 300 receives the response from web applications 230 (332) and determines whether there are more fragments left to dispatch (334). If there are more fragments, Fragment Dispatcher 300 goes to step 320, and if not, (the final fragment has been dispatched) aggregates all the responses stored in response cache 250 (336), sends the combined response to the client (338), and stops (340).
FIG. 4 is a flowchart depicting the logic of Application Helper 400. Application Helper 400 starts whenever web application 230 receives a request or fragment from Fragment Dispatcher 300 (410). Application Helper 400 determines if it is a new request or a request fragment (412). New requests are passed to web applications 230 (414) and web applications 230 returns a response (416). Application Helper 400 determines if web applications 230 returned a full response or a deferred response (418). A deferred response occurs when web applications 230 require other isolated web applications to execute the request. Fragment Markup and Assembly Engine 240 splits the initial request into a sequence of fragments to be run on other isolated web applications 230. If web applications 230 returns a full response, Application Helper 400 sends the response to Fragment Dispatcher 300 (420) and stops (448). If web applications 230 returns a deferred response, Application Helper 400 determines the sequence for running the fragments if necessary, and any context or attributes required to execute each fragment (422). Application Helper 400 identifies which isolated web applications 230 will run each fragment (424). Application Helper 400 adds metadata containing all the sequence, context, attribute and web application information to the fragments (426), returns the fragments to Fragment Dispatcher 300 (see FIG. 3) (428) and stops (448).
If at step 412, Application Helper 400 receives a dispatched fragment rather than a new request from Fragment Dispatcher 300, Application Helper 400 reads the metadata for the dispatched fragment (432), and determines whether context is included in the fragment (434). If context is included, Application Helper 400 extracts context from the metadata (436), and goes to step 438. If context is not included, Application Helper 400 goes to step 438 where it passes the fragment and any context to the application (438). Next, Application Helper 400 receives a fragment response from web application 230 (440) and determines whether context is included (442). If so, it adds context to the metadata (444) and goes to step 446. If context was not included, Application Helper 400 goes to step 446 where it sends a fragment response to Fragment Dispatcher 300 (446) and stops (448).
FIG. 5 depicts the prior art propagation of a fragmented request. In the prior art, Application A 560, Application B 570, and Application C 580 are physically and logically isolated from each other. In order to process a fragmented request from a client, each application must communicate with each other. This direct communication may violate the isolation rules in the application's programming. Numeral 501 represents an initial request made by a client. Numeral 502 represents web application A 560 setting an initial attribute “xa” in response to the client request, but determining that it needs content from web application B 570 and web application C 580 to fully execute the original client request. Numeral 503 represents web application A 560 communicating the need for content from other web applications with Fragment Markup and Assembly Engine 240. Fragment Markup and Assembly Engine 240 runs on the same application server as web application A 560. 505 represents Fragment Markup and Assembly Engine 240 splitting the initial request into four fragments (XA, YA, YB and YC) and sending the fragments back to Application A 560. Numeral 506 represents web application A 560 executing a response to fragment YA using the initial attribute “xa” associated with fragment XA.
Numeral 507 represents web application A 560 dispatching fragment YB with attribute “xa” to web application B 570. Numerical 508 represents web application B 507 setting attribute “yb” in response to fragment YB and attribute “xa.” Numeral 509 represents web application B 570 sending the response to fragment YB with attributes “yb” to web application A 560. Numeral 510 represents web application A 560 receiving the response. Numeral 511 represents web application A 560 dispatching fragment YC with attributes “xa” and “yb” to web application C 580. Numeral 512 represents web application C 580 performing required actions using attributes “xa” and “yb” in response to fragment YC. Numeral 513 represents web application C 580 sending the final response attribute “yc” to web application A 560. Numeral 514 represents web application A 560 receiving the response and aggregating the response with the previous responses. Numeral 515 represents web application A 560 sending the combined response “xa,” “ya,” “yb” and “yc” to the client.
FIG. 6 depicts propagation of a fragmented request using the Fragment Aggregator. As in FIG. 5 above, Application A 660, Application B 670, and Application C 680 are physically and logically isolated from each other. Surrogate computer 650 dispatches a fragmented request from a client, and aggregates the responses from each application. Each isolated application only communicates with the surrogate, and not with each other. The indirect communication preserves the isolation rules in each application's programming. Numeral 601 represents an initial request made by a client. Numeral 602 represents a Fragment Dispatcher 300 running on Surrogate 650 that appends the initial request with a metadata protocol header to initialize the context propagation. Numeral 603 represents surrogate 650 dispatching the initial request to web application server A 660. At Numeral 604, Fragment Markup and Assembly Engine 240 on web application A 660 splits the initial request into four fragments (XA, YA, YB and YC). Sequencing information is added to the metadata protocol headers of each fragment. Web application A 660 sets an initial attribute “xa” then executes a response to fragment YA containing attribute “ya” using the initial attribute “xa.” Numeral 605 represents sending a deferred response containing the four request fragments and the attributes “xa” and “ya” back to Surrogate 650. Numeral 606 represents Surrogate 650 saving the attributes to response cache 250.
Numeral 607 represents Surrogate 650 dispatching fragment YB with attribute “xa” to application server 680. Numerical 608 represents web application B 670 setting attribute “yb” in response to the fragment YB and attribute “xa.” Numeral 609 represents web application B 670 sending the response with attribute “ya” to Surrogate 650. Numeral 610 represents Surrogate 650 receiving the response and saving the response to response cache 250. Numeral 611 represents Surrogate 650 dispatching fragment YC with attributes “xa” and “ya” to web application C 680. Fragment YC also contains metadata protocol header information to terminate context propagation. Numeral 612 represents web application C 680 performing required actions using attributes “xa” and “yb” in response to fragment YC. Numeral 613 represents web application C 680 sending the final response with attribute “yc” to Surrogate 650. Numeral 614 represents surrogate 650 receiving the response with attribute “yc” and aggregating the response with the previous responses in response cache 250. Numeral 615 represents surrogate 650 sending the combined response “xa,” “ya,” “yb” and “yc” to the client.
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.
Patent Application
20080028086
