Status hub used by autonomic application servers

• US 7,512,949 B2
• Filed: 09/03/2003
• Issued: 03/31/2009
• Est. Priority Date: 09/03/2003
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Creamer, Thomas E., Moore, Victor S., Katz, Neil A., Hilf, Bill H.
• Primary Examiner(s): An; Meng-Ai
• Assistant Examiner(s): To; Jennifer N
• Application Number:
  US10/654,094
• Publication Number:
  US 20050050138A1
• Time in Patent Office: 2,036 Days
• Field of Search: 718100-105, 709/238, 709201-203, 709223-226
• US Class Current: 718/105
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/1008 based on parameters of servers, e.g. available memory or workload monitoring of computer activity G06F11/30
• CPC Class Codes: H04L 67/1012 based on compliance of requirements or conditions with available server resources

Abstract

A method for serving applications including receiving a component status publication and acquiring a client request. The component status publication can specify a usage level for an application component. A server response for the client request can be selected from among a multitude of possible server responses based at least in part upon the component status publication. Each possible server response can differentially utilize application components. The client request can be response to by conveying the selected server response.

Claims

1. A method for serving applications comprising the steps of:

receiving from a centralized location at least one component status publication generated based upon activity information specified in at least one component usage message generated by at least one application component, each said component status publication specifying a usage level for the application component, wherein each said component usage message is generated after a predetermined period of time and is automatically delivered to the centralized location, wherein said component message specifies the activity information for the application component, and wherein the activity information specifies at least one among a number of users accessing the corresponding application component, a number of requests received by the corresponding application component within the predetermined time interval, and a rate at which resources of the corresponding application component are used, wherein said component status publication specifies a state of said at least one application component, wherein said centralized location determines the state based upon at least one of said component usage messages, wherein responsive to an overload condition, said centralized location adjusts the specified state of said application component in said component status publication from a steady-state to an overload-state, and wherein responsive to an end of said overload condition, said centralized location adjusts the specified state from the overload-state to the steady-state;

acquiring a client request to execute one or more computing tasks, wherein said computing tasks include at least one among a data processing task and a data management task;

selecting a server response for said client request from among a plurality of possible server responses to execute said computing tasks based at least in part upon said component status publications, wherein each possible server response differentially utilizes application components to execute said computing tasks, and wherein said selecting further comprising;

determining that a server response to execute said computing tasks can be provided using either one of said external components or one of said local components;

comparing an usage level of said external component specified in said component status publication with a predetermined usage threshold value; and

if said usage threshold value is exceeded, using said local component to provide said server response for executing said computing tasks, otherwise using said external component to provide said server response for executing said computing tasks; and

responding to said client request with said selected server response.

2. The method of claim 1, further comprising the step of registering each of said application components with the centralized location that publishes said component status publications.

3. The method of claim 1, further comprising the steps of:

specifying within said centralized location a usage message format; and

,

formatting said component usage messages in accordance with said usage message format.

4. The method of claim 3, said method further comprising the steps of:

receiving said client request and said at least one component status publication in a control layer;

calling from within said control layer a data method contained within an application layer; and

,

activating at least one of said application components responsive to said calling step.

5. The method of claim 1, said selecting step further comprising:

identifying said plurality of server responses for said client requests;

for each of said server responses for executing said computing tasks, determining a required utilization for each application component that generates said server response;

comparing said required utilizations with available application component capacity, wherein said available application component capacity is determined at least in part from said component status publications; and

,

selecting said server response based at least in part upon said comparing step.

6. The method of claim 1, said selecting step further comprising:

if said application component is in said overload-state, selecting the server response that limits usage of said application components which triggered said overload condition.