Re-using asynchronous server-side results generated for a request context of one client to satisfy a request context of a different client

CROSS-REFERENCE TO RELATED APPLICATIONS

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

1. Field of the Invention

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.

2. Description of the Related Art

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.

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

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.

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.

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.

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.

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

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.

<figref idref="DRAWINGS">FIG. 1</figref> 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.

<figref idref="DRAWINGS">FIG. 2</figref> 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

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of a system <b>100</b> in which server-side <b>102</b> results are shared by multiple request issuing clients <b>110</b>, <b>112</b> in accordance with an embodiment of the inventive arrangements disclosed herein. In system <b>100</b>, two or more clients <b>110</b>, <b>112</b> can issue requests <b>120</b>, <b>122</b> to a server-side <b>102</b> resource <b>130</b>. The second request <b>122</b> can be issued when the first request <b>120</b> is still being processed. At least a portion of the results produced for request <b>120</b> can be identical to results needed to satisfy request <b>122</b>. Instead of redundantly and individually handling two approximately concurrent requests <b>120</b>, <b>122</b> for the same content, system <b>100</b> executes a single operation that produces results that are shared by client <b>110</b> and client <b>112</b>,

For example, each request <b>120</b>, <b>122</b> 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 <b>160</b> for both requests <b>120</b>, <b>122</b>. When request <b>122</b> is received by resource <b>130</b>, an operation that produces news portlet content for client <b>110</b> can be active. This active operation can he detected, when processing for request <b>122</b> is initiated, and instead of issuing a separate thread/process for handling the news portlet content for request <b>122</b>, the active thread/process for this content for request <b>120</b> can be identified and linked to the second request <b>122</b>. The news portlet results <b>160</b> from the active operation can be conveyed to both clients <b>110</b> and <b>112</b>.

A process flow <b>150</b> for the result sharing system <b>100</b> is shown by steps <b>160</b>-<b>182</b>. The request handling process can begin when a server resource (i.e., resource <b>130</b>) receives a request, as shown by step <b>160</b>. In step <b>162</b>, the request (i.e., request <b>120</b>, <b>122</b>, or <b>147</b>) can be logged in an active operation table (i.e. table <b>135</b>) or other memory space. In step <b>164</b>, request handling operations can be initiated. In step <b>166</b>, 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 <b>168</b> to step <b>170</b>, or can be different than currently active operations, which causes the process to proceed from step <b>168</b> to step <b>162</b>.

In step <b>170</b> 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 <b>172</b>, when another request is received the process can proceed to step <b>166</b>, where the request is received and handled. Otherwise, the process can progress from step <b>172</b> to step <b>174</b>, 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 <b>172</b>. When results are produced, the method can progress from step <b>174</b> to step <b>176</b>, 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.

In step <b>178</b>, 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 <b>180</b>, all entries in the active operation table associated with the results can be removed. In step <b>182</b>, 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 <b>182</b> to step <b>172</b>.

It should be appreciated that although a specific embodiment is expressed in system <b>100</b>, the request handling process <b>150</b> can be performed by any server-side <b>102</b> system. The represented embodiment is one in which a singe request context is able to be asynchronously handled by one or more resources <b>130</b>, which deliver results <b>146</b>, <b>148</b> to a result server <b>140</b>, which in turn conveys results <b>160</b> to clients <b>110</b>-<b>112</b>. Additionally, in the shown embodiment, the clients <b>110</b>-<b>112</b> can asynchronously aggregate the received content <b>160</b> for a request context. In a different embodiment (not shown), server-side <b>102</b> aggregation of content can occur. In still another embodiment (not shown) a single resource <b>130</b> (e.g., a Web server) can handle requests (i.e., using an included/accessible handler <b>132</b> and table <b>135</b>) and can directly deliver shared results <b>160</b> to multiple clients <b>110</b>-<b>112</b> without using the result service <b>140</b>. Further, in different contemplated arrangements of system <b>100</b>, the shared result <b>160</b> can either fully satisfy the requests <b>120</b>, <b>122</b> or can satisfy only a common portion of the requests <b>120</b>, <b>122</b> (e.g., the requests <b>120</b>, <b>122</b> can both reference a common portlet or other shared result segment).

Referring to the illustrated embodiment of system <b>100</b>, an implementation is shown that is capable of client-side <b>104</b> aggregation of content asynchronously handled by multiple server-side resources <b>130</b>. As shown, when an operations handler <b>132</b> receives a request <b>120</b>, <b>122</b>, and/or <b>147</b> it can consult an active operations table <b>135</b> to determine if an already executing operation exists that can satisfy the new request. For example, requests of table <b>135</b> 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 <b>135</b> (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 <b>146</b>, <b>148</b>, these results can be recorded in table <b>135</b> for dissemination to clients <b>110</b>-<b>112</b>, shown by conveying response <b>160</b> to clients <b>110</b>-<b>112</b>. The table <b>135</b> 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 <b>110</b>-<b>112</b>.

As used in system <b>100</b>, the resources <b>130</b> 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 <b>130</b> can be associated with a Uniform Resource Identifier (URI) used for resource <b>130</b> 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 <b>130</b> can include static content and one or more placeholders. Placeholder content can be produced by different resources <b>130</b>, which receive request <b>147</b>, which results in dynamic content. Each resource <b>130</b> 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 <b>130</b> can allocate resources to process a received request <b>120</b>, <b>122</b>, <b>147</b> and can release these resources once that resource's processing tasks are completed. That is, a time period in which any of the resources <b>130</b> is used to handle a request context can be less than a total time needed to handle the request context. The resources <b>130</b> 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).

The result service <b>140</b> can be a server-side <b>102</b> 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.

The result service <b>140</b> 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 <b>140</b> can be associated with a URI to which the resources <b>130</b> can convey results <b>146</b>, <b>148</b> and to which the clients <b>110</b>-<b>112</b> can convey content requests. The result distribution service <b>140</b> can reside within resource <b>130</b>, or any other computing component. When the service <b>140</b> is associated with a component other than the one addressed in the original HTTP request, then system <b>100</b> must implement measures to ensure that the URLs of the service <b>140</b> are available to the resources <b>130</b> and the clients <b>110</b>-<b>112</b>.

Each of the clients <b>110</b>-<b>112</b> can be any computing device capable of sending HTTP request <b>120</b>, <b>122</b> and capable of rendering responses to these requests. For example, the client <b>110</b>-<b>112</b> 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 <b>110</b>, <b>112</b> can include a browser, which handles HTTP communications. The browser can be linked to an interface with which a user interacts with client <b>110</b>, <b>112</b>. 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.

The various components of system <b>100</b> 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.

The data store <b>142</b> and other data stores (not shown) linked to resources <b>130</b> or clients <b>110</b>, <b>112</b> 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 <b>142</b> 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 <b>142</b> in a variety of manners. For example, information, such as table <b>135</b>, 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 <b>142</b> can also be optionally encrypted for added security.

<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram <b>200</b> 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 <b>200</b> can be performed in the context of system <b>100</b> or any other client-server system, where client requests are handled asynchronously by one or more server resources.

In diagram <b>200</b>, a client <b>208</b> can convey a request <b>230</b> to a server <b>212</b>. The server <b>212</b> can determine <b>232</b> whether an active operation is currently executing that is capable of handling the request <b>230</b>. This can be done by querying <b>234</b> an active operations table <b>216</b> and receiving results <b>234</b> in response. When no active operations satisfy the request <b>230</b>, the request and/or operations to be executed to handle the request <b>230</b> can be logged in the active operations table <b>216</b>. The handling operations can then be initiated <b>238</b>.

While this operation is executing, another request <b>240</b> can be conveyed from client <b>210</b> to server <b>212</b>. The server <b>212</b> can determine <b>242</b> whether an active operation is currently executing that is capable of handling the request <b>240</b>, which is performed by querying <b>244</b> table <b>21</b>.<b>6</b> an receiving a response <b>244</b>. In diagram <b>200</b>, requests <b>230</b> and <b>240</b> can be substantially identical and can be satisfied by executing the same programmatic operations. Therefore, a message <b>246</b> to add request <b>240</b> to a result delivery queue can be conveyed to table <b>216</b>. Eventually, the initiated process <b>238</b> can produce results <b>248</b>. These results can be conveyed <b>250</b> to a result delivery service <b>214</b>. When the server <b>214</b> does not have an active auto-delivery feature, the clients <b>208</b> and <b>210</b> must send messages to service <b>214</b> requesting results <b>254</b>, <b>256</b>.

When an auto delivery feature <b>252</b> exists or when requests <b>254</b>, <b>256</b> are received, the result service <b>214</b> can query <b>258</b> the active operations table to determine which clients <b>208</b>, <b>210</b> are to receive <b>260</b> the results. The querying <b>258</b> can also remove entries form the table <b>216</b> relating to the client <b>208</b>, <b>210</b> and/or the operations/results (if all clients that are to receive the results have queried the table <b>216</b>). The caveat is provided because clients <b>208</b>, <b>210</b> can asynchronously query service <b>214</b> for the results in one contemplated configuration. The service <b>214</b> can then convey the result <b>262</b>, <b>264</b> to the requesting clients <b>208</b>, <b>210</b>.

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.

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.

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.