Abstract:
The present invention provides a solution for sharing server generated output to satisfy requests for content originated by different clients. More specifically, a server side resource can analyze a content request and compare this request to a set of active request handling operations. When one of the active operations is capable of satisfying a discrete portion of the content request, an association can be established between the active operation and the content request. When the active operation produces results, these results are returned to satisfy a request of an original client as well as to satisfy a request of a client that issued the content request. The solution can be implemented in a variety of environments, including one where asynchronous server-side operations are conducted by different server-side resources for a single request context.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This continuation-in-part application claims the benefit of U.S. patent application Ser. No. 11/843,038 filed Aug. 22, 2007, and the benefit of U.S. patent application Ser. No. 11/846,423 filed Aug. 28, 2007, both of which are incorporated by reference herein. 
     
    
     BACKGROUND 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates to HTTP request handling and, more particularly, to re-using asynchronous server-side results generated for a request context of one client to satisfy a request context of a different client. 
         [0004]    2. Description of the Related Art 
         [0005]    U.S. patent application Ser. No. 11/846,423 entitled “Method and Apparatus for Client-Side Aggregation of Asynchronous Fragmented Requests” disclosed a solution for client side aggregation of asynchronous context-sensitive request operations in a single application server environment. A concept of client-side content aggregation is extended by U.S. patent application Ser. No. 11/843,038, entitled “Client-Side Aggregation of Context-Sensitive Request Results Where Results for Aggregation are Asynchronously Produced by Multiple Servers” which teaches client-side aggregation of context-sensitive request results where results are asynchronously handled by multiple servers. 
         [0006]    With the advent of asynchronous request dispatching, one or more application servers can handle simultaneous, asynchronous requests for different requesting clients. A possibility arises that two or more of these concurrently handled requests to produce identical content. For example, a first client can request a portal page, which includes a default news portlet. The news portlet can include dynamically generated content produced by a server in response to an asynchronous request for the portlet content. Soon after, a second client can request a portal page, which also includes the default news portlet. By default, a separate asynchronously request for the news portlet information will be initiated and have to be handled separate from the request for the first client. This scenario results in two concurrent requests ultimately rendering the same content, which represents a duplication of effort at multiple layers (e.g., thread creation, duplicate response output, unnecessary request processing, and the like). 
       SUMMARY OF THE INVENTION 
       [0007]    The present invention provides a solution for sharing server generated output to satisfy request for content originated by different clients. More specifically, a server side resource can analyze a content request and compare this request to a set of active request handling operations. When one of the active operations is capable of satisfying a discrete portion of the content request, an association can be established between the active operation and the content request. When the active operation produces results, these results are returned to satisfy a request of an original client as well as to satisfy a client that issued the content request. The solution can be implemented in an environment where asynchronous server-side processes are used to handle a single request context, where each asynchronous process represents an operation able to be shared by multiple clients. Additionally, the asynchronous server-side processes can execute within multiple servers for a single request context, yet still produce results shared by multiple clients. 
         [0008]    The present invention can be implemented in accordance with numerous aspects consistent with the material presented herein. For example, one aspect of the present invention can include a server-side request handling system that includes a set of programmatic instructions stored in a machine readable medium, which cause the machine to re-use asynchronous server-side processing results generated for a request context of one client to satisfy different request context of a different client. 
         [0009]    Another aspect of the present invention can include a server-side request handling system that includes an active operations table and an operation handler. The active operations table can be stored in a machine readable medium that is accessible by the operation handler. The active operations table can store records for operations currently executing to produce results for received requests. The operation handler can be a software program stored in a machine readable medium and executed by a server-side resource that is configured to receive a request, to execute an operation, and to produce a result for the request. The operation handler can add records to the active operations table for each operation that the operation handler executes. The operation handler can remove records from the active operations table after executed operations have produced results. Before executing an operation to handle a received request, the operation handler can query the active operations table to determine whether a currently executing operation is able to handle the received request. When the query indicates that a currently executing operation is able to handle the received request, the received request can be associated with the currently executing operation so that results from the currently executing operation are used to handle a multiple requests. The multiple requests can include the received request and an original request for which the currently executing operation was initiated. 
         [0010]    Still another aspect of the present invention can include a method for sharing processed server results. In the method, a first request can be received for processing. An operation can begin executing for the first request. A second request can be received for processing while the operation is still executing. The second request can be associated with the executing operation. Execution of the operation can complete that produces a result. The produced result can be utilized to satisfy the first request and the second request. 
         [0011]    It should be noted that various aspects of the invention can be implemented as a program for controlling computing equipment to implement the functions described herein, or as a program for enabling computing equipment to perform processes corresponding to the steps disclosed herein. This program may be provided by storing the program in a magnetic disk, an optical disk, a semiconductor memory, or any other recording medium. The program can also be provided as a digitally encoded signal conveyed via a carrier wave. The described program can be a single program or can be implemented as multiple subprograms, each of which interact within a single computing device or interact in a distributed fashion across a network space. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]    There are shown in the drawings, embodiments which are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. 
           [0013]      FIG. 1  is a schematic diagram of a system in which server-side results are shared by multiple request issuing clients in accordance with an embodiment of the inventive arrangements disclosed herein. 
           [0014]      FIG. 2  is a flow diagram showing a set of messages exchanged in a system that shares results among multiple requesting clients in accordance with an embodiment of the inventive arrangements disclosed herein. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0015]      FIG. 1  is a schematic diagram of a system  100  in which server-side  102  results are shared by multiple request issuing clients  110 ,  112  in accordance with an embodiment of the inventive arrangements disclosed herein. In system  100 , two or more clients  110 ,  112  can issue requests  120 ,  122  to a server-side  102  resource  130 . The second request  122  can be issued when the first request  120  is still being processed. At least a portion of the results produced for request  120  can be identical to results needed to satisfy request  122 . Instead of redundantly and individually handling two approximately concurrent requests  120 ,  122  for the same content, system  100  executes a single operation that produces results that are shared by client  110  and client  112 , 
         [0016]    For example, each request  120 ,  122  can be for content related to a user customizable portal, where each portal includes a default news related portlet. Content for the news portlet can be dynamically generated content that will produce identical or nearly identical results  160  for both requests  120 ,  122 . When request  122  is received by resource  130 , an operation that produces news portlet content for client  110  can be active. This active operation can he detected, when processing for request  122  is initiated, and instead of issuing a separate thread/process for handling the news portlet content for request  122 , the active thread/process for this content for request  120  can be identified and linked to the second request  122 . The news portlet results  160  from the active operation can be conveyed to both clients  110  and  112 . 
         [0017]    A process flow  150  for the result sharing system  100  is shown by steps  160 - 182 . The request handling process can begin when a server resource (i.e., resource  130 ) receives a request, as shown by step  160 . In step  162 , the request (i.e., request  120 ,  122 , or  147 ) can be logged in an active operation table (i.e. table  135 ) or other memory space. In step  164 , request handling operations can be initiated. In step  166 , another request can be received for handling. The new request can be similar to a request currently being handled by an active operation, which causes the process to proceed from step  168  to step  170 , or can be different than currently active operations, which causes the process to proceed from step  168  to step  162 . 
         [0018]    In step  170  when a similar request is in the process of being handled, a result for the active operation handling the original request can also be associated with the new request. In step  172 , when another request is received the process can proceed to step  166 , where the request is received and handled. Otherwise, the process can progress from step  172  to step  174 , where a check can be conducted to see if an active operation has produced results. If no results have been produced, the process can again check for more requests in step  172 . When results are produced, the method can progress from step  174  to step  176 , where the results can be optionally cached. This step can be implemented for a system designed to convey cached results to clients under a deterministic set of conditions, such as when a processing time out limit is reached. 
         [0019]    In step  178 , all requests that are satisfied by the produced results can be determined along with requesting client addresses. In one implementation, this information can be obtained by querying the active operation table. In step  180 , all entries in the active operation table associated with the results can be removed. In step  182 , produced results can be conveyed to the requesting client(s). The process can repeat for other requests, which is shown by the process proceeding from step  182  to step  172 . 
         [0020]    It should be appreciated that although a specific embodiment is expressed in system  100 , the request handling process  150  can be performed by any server-side  102  system. The represented embodiment is one in which a singe request context is able to be asynchronously handled by one or more resources  130 , which deliver results  146 ,  148  to a result server  140 , which in turn conveys results  160  to clients  110 - 112 . Additionally, in the shown embodiment, the clients  110 - 112  can asynchronously aggregate the received content  160  for a request context. In a different embodiment (not shown), server-side  102  aggregation of content can occur. In still another embodiment (not shown) a single resource  130  (e.g., a Web server) can handle requests (i.e., using an included/accessible handler  132  and table  135 ) and can directly deliver shared results  160  to multiple clients  110 - 112  without using the result service  140 . Further, in different contemplated arrangements of system  100 , the shared result  160  can either fully satisfy the requests  120 ,  122  or can satisfy only a common portion of the requests  120 ,  122  (e.g., the requests  120 ,  122  can both reference a common portlet or other shared result segment). 
         [0021]    Referring to the illustrated embodiment of system  100 , an implementation is shown that is capable of client-side  104  aggregation of content asynchronously handled by multiple server-side resources  130 . As shown, when an operations handler  132  receives a request  120 ,  122 , and/or  147  it can consult an active operations table  135  to determine if an already executing operation exists that can satisfy the new request. For example, requests of table  135  can be identified by a unique identifier Req-AA, Req_AB, and Req_AC, which are linked to the same executing operation (e.g., an operation with an identifier of Oper_FF). When no currently executing operation satisfies the new request, a new entry can be added to the table  135  (i.e., an entry for a request identified by Req_BB), and a new operation can be initiated (i.e., an operation identified as Oper_GG). As soon as results are produced  146 ,  148 , these results can be recorded in table  135  for dissemination to clients  110 - 112 , shown by conveying response  160  to clients  110 - 112 . The table  135  can include numerous other fields (not shown) such as requestor address, request authorization code, and the like, which can be used to ensure delivery of results to authorized clients  110 - 112 . 
         [0022]    As used in system  100 , the resources  130  can be part of a computing system capable of handling Hypertext Transfer Protocol (HTTP) requests from a network and of providing HTTP responses to these requests. Each of the resources  130  can be associated with a Uniform Resource Identifier (URI) used for resource  130  identification when conveying HTTP requests. The HTTP responses can include static and dynamic content. In one embodiment, an initial response produced by a request receiving resource  130  can include static content and one or more placeholders. Placeholder content can be produced by different resources  130 , which receive request  147 , which results in dynamic content. Each resource  130  can include numerous optional features, such as authentication support, encrypted channel support (e.g., HTTPS support through Transport Layer Security (TLS) technologies, Secure Sockets Layer (SSL) technology, and the like), content compression and decompression support, and the like. Each of the resources  130  can allocate resources to process a received request  120 ,  122 ,  147  and can release these resources once that resource&#39;s processing tasks are completed. That is, a time period in which any of the resources  130  is used to handle a request context can be less than a total time needed to handle the request context. The resources  130  can be implemented within physical machines as well as virtual computing devices, such as those provided through visualization solutions (e.g., VMWARE, MS VIRTUAL SERVER, and the like). 
         [0023]    The result service  140  can be a server-side  102  software program able to handle HTTP and other RESTful messages. A RESTful message is a message conforming to the Representational State Transfer (REST) software architecture. A REST architecture provides a uniform interface exists that includes a few basic primitive commands (e.g., HTTP GET, HTTP PUT, HTTP POST, HTTP DELETE). REST based solutions simplify component implementation, reduce the complexity of connector semantics, improve the effectiveness of performance tuning, and increase the scalability of pure server components. 
         [0024]    The result service  140  can be implemented as a servlet, a JAVA Server Page (JSP), an Active Server Page (ASP), an Enterprise Java Bean (EJB), an Enterprise Service Bus (ESB) service, and the like. The service  140  can be associated with a URI to which the resources  130  can convey results  146 ,  148  and to which the clients  110 - 112  can convey content requests. The result distribution service  140  can reside within resource  130 , or any other computing component. When the service  140  is associated with a component other than the one addressed in the original HTTP request, then system  100  must implement measures to ensure that the URLs of the service  140  are available to the resources  130  and the clients  110 - 112 . 
         [0025]    Each of the clients  110 - 112  can be any computing device capable of sending HTTP request  120 ,  122  and capable of rendering responses to these requests. For example, the client  110 - 112  can include a personal computer, a notebook computer, a mobile computing device, a smart phone, a personal data assistant. (PDA), an embedded computing device, an electronic gaming system, and the like. Client  110 ,  112  can include a browser, which handles HTTP communications. The browser can be linked to an interface with which a user interacts with client  110 ,  112 . The interface can be a graphical user interface (GUI), a multi-modal interface, a voice user interface (VUI), and the like. Interface can include content and placeholders. 
         [0026]    The various components of system  100  can be communicatively linked via a network (not shown). The network can include components capable of conveying digital content encoded within carrier waves. The content can be contained within analog or digital signals and conveyed through data or voice channels and can be conveyed over a personal area network (PAN) or a wide area network (WAN). The network can include local components and data pathways necessary for communications to be exchanged among computing device components and between integrated device components and peripheral devices. The network can also include network equipment, such as routers, data lines, hubs, and intermediary servers which together form a packet-based network, such as the Internet or an intranet. The network can further include circuit-based communication components and mobile communication components, such as telephony switches, modems, cellular communication towers, and the like. The network can include line based and/or wireless communication pathways. 
         [0027]    The data store  142  and other data stores (not shown) linked to resources  130  or clients  110 ,  112  can be physically implemented within any type of hardware including, but not limited to, a magnetic disk, an optical disk, a semiconductor memory, a digitally encoded plastic memory, a holographic memory, or any other recording medium. Data store  142  can be a stand-alone storage unit as well as a storage unit formed from a plurality of physical devices which may be remotely located from one another. Additionally, information can be stored within the data store  142  in a variety of manners. For example, information, such as table  135 , can be stored within a database structure or can be stored within one or more files of a file storage system where each file may or may not be indexed for information searching purposes. Information stored in data store  142  can also be optionally encrypted for added security. 
         [0028]      FIG. 2  is a flow diagram  200  showing a set of messages exchanged in a system that shares results among multiple requesting clients in accordance with an embodiment of the inventive arrangements disclosed herein. The flow diagram  200  can be performed in the context of system  100  or any other client-server system, where client requests are handled asynchronously by one or more server resources. 
         [0029]    In diagram  200 , a client  208  can convey a request  230  to a server  212 . The server  212  can determine  232  whether an active operation is currently executing that is capable of handling the request  230 . This can be done by querying  234  an active operations table  216  and receiving results  234  in response. When no active operations satisfy the request  230 , the request and/or operations to be executed to handle the request  230  can be logged in the active operations table  216 . The handling operations can then be initiated  238 . 
         [0030]    While this operation is executing, another request  240  can be conveyed from client  210  to server  212 . The server  212  can determine  242  whether an active operation is currently executing that is capable of handling the request  240 , which is performed by querying  244  table  21 . 6  an receiving a response  244 . In diagram  200 , requests  230  and  240  can be substantially identical and can be satisfied by executing the same programmatic operations. Therefore, a message  246  to add request  240  to a result delivery queue can be conveyed to table  216 . Eventually, the initiated process  238  can produce results  248 . These results can be conveyed  250  to a result delivery service  214 . When the server  214  does not have an active auto-delivery feature, the clients  208  and  210  must send messages to service  214  requesting results  254 ,  256 . 
         [0031]    When an auto delivery feature  252  exists or when requests  254 ,  256  are received, the result service  214  can query  258  the active operations table to determine which clients  208 ,  210  are to receive  260  the results. The querying  258  can also remove entries form the table  216  relating to the client  208 ,  210  and/or the operations/results (if all clients that are to receive the results have queried the table  216 ). The caveat is provided because clients  208 ,  210  can asynchronously query service  214  for the results in one contemplated configuration. The service  214  can then convey the result  262 ,  264  to the requesting clients  208 ,  210 . 
         [0032]    The present invention may be realized in hardware, software, or a combination of hardware and software. The present invention may be realized in a centralized fashion in one computer system or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. 
         [0033]    The present invention also may be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form. 
         [0034]    This invention may be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope of the invention.