Patent Application
20150156094
Identity manager systems enable large enterprises to automate life cycle management of user roles, identities, and access rights. These systems automate the creation, modification, re-certification, and termination of user privileges throughout the entire user cycle. Identity manager systems provide user accounts to authorized users on one or more resources to which identity manager resource adapters are connected. Identity management provides administration from a client interface in a Web browser that communicates through an HTTP server and application server using embedded HTTP transport.
In such large systems, under heavy load, user interfaces (UIs) can freeze and become unresponsive. When dealing with unavailable resources, end users might be unable to complete even the most basic of tasks (e.g., search, modify object, etc.).
An approach is provided for an information handling system to convey user interface functionality based upon a backend server load. The approach receives, over a computer network, a request from a client that utilizes a user interface. The approach further identifies a current resource utilization of a backend server resource that corresponds to the request and then transmits an indicator to the user interface with the indicator conveying the current resource utilization. In response to an overload condition being detected at the backend server resource, the approach transmits a substitute task recommendation to the user interface as a possible alternative request instead of the received request.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings, wherein:
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer, server, or cluster of servers. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The following detailed description will generally follow the summary of the invention, as set forth above, further explaining and expanding the definitions of the various aspects and embodiments of the invention as necessary. To this end, this detailed description first sets forth a computing environment in
Northbridge 115 and Southbridge 135 connect to each other using bus 119. In one embodiment, the bus is a Direct Media Interface (DMI) bus that transfers data at high speeds in each direction between Northbridge 115 and Southbridge 135. In another embodiment, a Peripheral Component Interconnect (PCI) bus connects the Northbridge and the Southbridge. Southbridge 135, also known as the I/O Controller Hub (ICH) is a chip that generally implements capabilities that operate at slower speeds than the capabilities provided by the Northbridge. Southbridge 135 typically provides various busses used to connect various components. These busses include, for example, PCI and PCI Express busses, an ISA bus, a System Management Bus (SMBus or SMB), and/or a Low Pin Count (LPC) bus. The LPC bus often connects low-bandwidth devices, such as boot ROM 196 and “legacy” I/O devices (using a “super I/O” chip). The “legacy” I/O devices (198) can include, for example, serial and parallel ports, keyboard, mouse, and/or a floppy disk controller. The LPC bus also connects Southbridge 135 to Trusted Platform Module (TPM) 195. Other components often included in Southbridge 135 include a Direct Memory Access (DMA) controller, a Programmable Interrupt Controller (PIC), and a storage device controller, which connects Southbridge 135 to nonvolatile storage device 185, such as a hard disk drive, using bus 184.
ExpressCard 155 is a slot that connects hot-pluggable devices to the information handling system. ExpressCard 155 supports both PCI Express and USB connectivity as it connects to Southbridge 135 using both the Universal Serial Bus (USB) the PCI Express bus. Southbridge 135 includes USB Controller 140 that provides USB connectivity to devices that connect to the USB. These devices include webcam (camera) 150, infrared (IR) receiver 148, keyboard and trackpad 144, and Bluetooth device 146, which provides for wireless personal area networks (PANs). USB Controller 140 also provides USB connectivity to other miscellaneous USB connected devices 142, such as a mouse, removable nonvolatile storage device 145, modems, network cards, ISDN connectors, fax, printers, USB hubs, and many other types of USB connected devices. While removable nonvolatile storage device 145 is shown as a USB-connected device, removable nonvolatile storage device 145 could be connected using a different interface, such as a Firewire interface, etcetera.
Wireless Local Area Network (LAN) device 175 connects to Southbridge 135 via the PCI or PCI Express bus 172. LAN device 175 typically implements one of the IEEE 0.802.11 standards of over-the-air modulation techniques that all use the same protocol to wireless communicate between information handling system 100 and another computer system or device. Optical storage device 190 connects to Southbridge 135 using Serial ATA (SATA) bus 188. Serial ATA adapters and devices communicate over a high-speed serial link. The Serial ATA bus also connects Southbridge 135 to other forms of storage devices, such as hard disk drives. Audio circuitry 160, such as a sound card, connects to Southbridge 135 via bus 158. Audio circuitry 160 also provides functionality such as audio line-in and optical digital audio in port 162, optical digital output and headphone jack 164, internal speakers 166, and internal microphone 168. Ethernet controller 170 connects to Southbridge 135 using a bus, such as the PCI or PCI Express bus. Ethernet controller 170 connects information handling system 100 to a computer network, such as a Local Area Network (LAN), the Internet, and other public and private computer networks.
While
The Trusted Platform Module (TPM 195) shown in
Web site 305 includes user interface backend server process 310 that processes requests received from the user interface. Process 310 identifies the backend server resources that will be utilized to fulfill the received request. Process 310 retrieves a current resource load, or utilization, corresponding to the various resources that will be utilized from memory area 340 that is maintained by various monitoring servers 330. As shown, monitoring servers 330 receive monitor data from resource provider servers 320 and update the state of backend server resources by writing the utilization data to memory area 340.
If the user interface backend server detects an overload condition pertaining to a resource needed to fulfill the client's request, the user interface backend server sends a user interface response back to the client with the user interface response indicating a current resource utilization of the backend server resource. In addition, when an overload condition is detected, the user interface backend server can suggest an alternative request that the user can make instead of the original request with the user interface backend server previously identifying the alternative request as being a request that utilizes resources that are more readily available. The user at the client machine may decide to execute the original request, however the user will understand that the request may take some time to process given the overload condition that currently exists with regard to the backend server resource. On the other hand, the user may decide to make an alternative request, such as the request that was suggested by the user interface backend server, knowing that the alternative request is likely to be completed in less time than the original request would have taken to complete. The user interface backend server transmits requests, some of which may be modified requests as described above, to resource provider servers 320. The resource provider servers execute the request and utilize the backend server resources. The resource provider servers send responses back to the client based upon the submitted request.
At step 425, the user interface process receives fulfillment data from the web site. The fulfillment data includes an indicator that conveys the current resource utilization corresponding to the backend server resource that is needed to process the request. In one embodiment, a visual cue, such as a color code, etc., is used to convey the current resource utilization in a graphical manner.
The user interface process determines if an overload condition currently exists with regard to the backend server resource (decision 430). If an overload condition currently exists, the decision 430 branches to the “yes” branch to handle the overload. The user interface process next determines if an alternate request suggestion was received from the web site (decision 440). For example, while performing search for a list of persons, the user may specify a search criteria that fetches all users who last name is “Smith.” After the server receives the search request, if the server determines it is over loaded, it may suggest an alternative that may result in a smaller number of users returned, such as “[A-M}* Smith.” If an alternate request suggestion was received, then decision 440 branches to the “yes” branch whereupon the user of the user interface is prompted as to whether the user would like to use the suggested modified request instead of the original request (decision 450). If the user would like to use the suggested modified request, then decision 450 branches to the “yes” branch whereupon, at step 460, the user interface process transmits the alternate request to the web site for processing.
Returning to decisions 440 and 450, if either an overload condition exists but an alternate request was not received (decision 440 branching to the “no” branch) or if the user does not accept the alternate request that was suggested by the web site (decision 450 branching to the “no” branch), then a decision is made by the user as to whether the user wishes to change the original request based on the overload condition that is currently in effect (decision 470). If the user wants to change the original request, then decision 470 branches to the “yes” branch whereupon, at step 480, the user interface receives a modified request that is input from the user and processing loops back to transmit the modified request to the web sit.
On the other hand, if either no overload condition was indicated by the website (decision 430 branching to the “no” branch) or if the user decides not to modify the request even though an overload condition has been noted (decision 470 branching to the “no” branch), then the user interface transmits the request to the web site for processing.
On the other hand, if the received request is not a bulk request, then decision 515 branches to the “no” branch where the process handles the non-bulk request. At step 525, the process checks the usage of backend server resources that are needed to handle the received request. As shown, monitor servers 330 monitor the various backend server resources and post the current state of such resources to memory area 340. The process reads this memory area containing the current state of backend server resources to check the current usage of the backend server resources. A decision is made by the process as to whether, based on the current resource usage level, the resource is overloaded (decision 530). In one embodiment, the process decides whether the resource is overloaded by comparing the resource usage level with a threshold. If the resource is not overloaded, the process branches to the “no” branch whereupon, at step 535, the process does not send an overload indicator to the user interface. On the other hand, if the resource is overloaded, then the process branches to the “yes” branch for further resource overload processing.
At step 540, the process identifies an extent of the overload, such as whether the overload condition is a major overload, a medium overload, or a minor overload. In one embodiment, process identifies the extent of the overload based on previous executions of tasks under similar system conditions and circumstances. In this embodiment, step 540 utilizes historical data from data store 565 that includes performance of past tasks as well as resources utilized during past performances as well as resource requirements data from data store 570 that includes the resources required to execute various tasks. At step 545, the process transmits an indicator, such as a graphical indicator (e.g., color, highlight, message, etc.) that conveys the extent of the resource overload being experienced by the backend server.
Because the resource is identified as overloaded, at step 550, the process identifies one or more substitute tasks, or requests, that the user might want to request as alternatives to the original user request. The process stores these substitute tasks in memory area 555. At step 560, the process checks the resources needed to perform each of the substitute tasks. In one embodiment, the process performs step 560 by utilizing the historical data from data store 565 as well as resource requirement data from data store 570. At step 575, the process filters out any of the substitute tasks that are unacceptable either because the substitute tasks utilize too many system resources or because the substitute tasks require resources that are also in an overload condition. The process stores substitute tasks that are not filtered (acceptable tasks or requests) in memory area 580. A decision is made by the process as to whether there are any acceptable substitute tasks that remain after the filtering (decision 585). If there are one or more substitute tasks, then the process branches from decision 585 to the “yes” branch whereupon, at step 590, the process transmits the identified substitute tasks (requests) to the user interface as possible alternative requests that the user can make instead of the original request. On the other hand, if there are no substitute tasks remaining after the filtering, then the process prs from decision 585 to the “no” branch whereupon, at step 595, no substitute, or alternative tasks, are sent to the user interface as possible alternatives to the user's original request.
A decision is made by the process as to whether the bulk request can be fulfilled at the present time given the resource utilizations (decision 620). If the request can be fulfilled at the present time, then decision 620 branches to the “yes” branch whereupon, at step 625, the process handles the bulk request. On the other hand, if the process determines that the request cannot be fulfilled in a timely manner at the present time, then decision 620 branches to the “no” branch for further processing.
At step 630, the process sends and indication to the user interface that the original bulk request cannot be fulfilled a the present time. In one embodiment, the indication also includes a time estimate corresponding to one or more of the requests included in the bulk request. A bulk request can include any number of request subsets. At step 640, the process selects the first of such subsets. In one embodiment, the process selects the subsets from the largest subset to the smallest subset. The selected subset of the bulk request is stored in memory area 650. At step 660, the process checks the current usage level of resources needed to fulfill the selected subset as well as calculates a time estimate of the amount of time needed to fulfill the selected subset. As previously described, the process checks current resource levels by reading data from memory area 340 that is updated by monitoring servers 330. In addition, the time estimate is calculated by utilizing historical data from data store 565 with the historical data having a record of past tasks performed under various operating conditions as well as the resources that were used and the time such tasks took to perform under such operation conditions. The process further obtains the resources needed by the various tasks from resource requirements data store 570. The estimated amount of time needed to execute the selected subset is added to memory area 650.
A decision is made by the process as to whether the selected subset of tasks (requests) can be fulfilled at the present time given the resource utilization (decision 670). If the selected subset can be fulfilled at the present time, then decision 670 branches to the “yes” branch whereupon, at step 675, the process notes the immediate availability of the selected subset in memory area 650. On the other hand, if the selected subset cannot be fulfilled at the present time, then decision 670 branches to the “no” branch whereupon the process bypasses step 675.
A decision is made by the process as to whether there are more subsets to process (decision 680). If there are more subsets to process, then decision 680 branches to the “yes” branch which loops back to select and process the next subset of the request. This looping continues until there are no more subsets to process, at which time decision 680 branches to the “no” branch whereupon, at step 690, the process transmits the subset of bulk requests, time estimates, and the indication of whether such subsets are available immediately from memory area 650 to the user interface. In this manner, the user can select subsets to be processed based upon the time estimates and indicators of which subsets are available for immediate handling by the backend server.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, that changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.
