in the following detailed description of exemplary embodiments of the invention , reference is made to the accompanying drawings that form a part hereof , and in which is shown by way of illustration specific exemplary embodiments in which the invention may be practiced . these embodiments are described in sufficient detail to enable those skilled in the art to practice the invention , and it is to be understood that other embodiments may be utilized and that logical , mechanical , electrical and other changes may be made without departing from the spirit or scope of the present invention . the following detailed description is , therefore , not to be taken in a limiting sense , and the scope of the present invention is defined only by the appended claims . the detailed description is divided into multiple sections . a first section provides an overview of the invention at a high level . this is followed by a description of components used to implement the invention in one embodiment . further detail regarding the function of the components is then described . this is followed by a conclusion that describes some potential benefits of the invention . a block diagram in fig1 shows a system generally at 100 that includes the present invention , and generally requesters 110 , a server 115 and a resource 120 . at 110 , a plurality of independent requesters or clients 124 , 126 and 128 are shown . the requesters may be individual personal computers , virtual machines , credit card authentication devices or other type of machine or software that can generate individual and independent requests . such requests are individual and independent in that they may or may not be related to one another , but all are not related to a single transaction and formed by an individual requester . the requesters are coupled via a network connection 130 , such as the internet , ethernet , bluetooth ™ ( a registered trademarke of bluetooth sig , inc . ), or other type of communication medium suitable for communication , to an aggregator 135 in the server 115 . the aggregator 135 is coupled to a resource management system 140 that is a part of resource 120 . resource 120 , in one embodiment is a database management system , which is used to query and manage other transactions involving a database . it should be noted that the resource 120 may also comprise many different types of applications that receive requests , such as check clearing houses , credit card transaction processing systems , banking systems and others as will be apparent upon reading the detailed description . the requests may be requests for information , such as query requests , or may be requesting an action , such as inserts and updates , or actions with respect to other applications . the aggregator 135 comprises a communication layer 170 which handles interprocess communication between the requesters and the server , essentially extracting and encoding requests for transmission . an optional business logic layer 180 receives requests processed by the communication layer 170 and may perform conversions of data types , and identify and / or enforce constraints . it may implement other types of functions such as caching and billing . a resource access layer 190 receives requests and responses . it is responsible for aggregation of requests and matching of responses back to the requests . in the block diagram of fig2 functions performed by the resource access layer 190 are shown in further detail . incoming requests 210 , 212 , 214 and 216 are mapped to a group of methods 220 of the resource access layer . each method a 224 and method b 226 correspond to a particular class of requests . in one embodiment , a class may be a query based on account name . other classes may correspond to particular actions to take with respect to a class of devices . in general , a class is a set of requests that can be converted into an aggregate request that resource 120 can handle . methods can be executed asynchronously , with caller placing call and providing callback entry for completion notification . the method has arguments that comprise request parameters , such as account number in an example below , and an output parameter , such as balance in an account . execution of a method is pended until a specified time lapses or a specified number of calls are pending as indicated at threshold 230 . as indicated , threshold 230 may be a time period , specified number of calls , and may also be a combination of both , such that if a specified number of calls are not received within a determined time , the method is executed anyway at the end of the time . there may be an independent threshold for each method , or the threshold may be the same for each method , or class of requests . in one embodiment , each method is monitored independently for meeting its threshold . when the threshold is met the pending calls are sent for processing to the provider for this method . the provider packages arguments of the pending calls into an aggregated request at a provider 235 , and sent at 238 to a resource management system 240 in the format required . each type of resource management system may have its own custom provider 235 based on the different aggregated requests the system can handle . the provider 235 then sends the aggregated request to the resource management system . the resource management system 240 then processes the aggregated request in a known manner and provides a response back to the resource access layer at 245 . the aggregated response is resolved back to the pending calls and the output parameter at 250 . corresponding methods 260 and 262 are used to complete the calls using callback notification entries . the resource management system 240 supports aggregated requests , and the aggregated requests are designed to provide data in the aggregated response that can be matched to the pending call arguments . it should be noted that software may be implemented in modules which include a wide variety of functions . the flowchart in fig3 may be implemented in modules , objects , and other forms of programming code , such as subroutines , and stored on a computer readable medium such as magnetic disks , optical media and other forms of storage which can be read or perceived by a machine or computer . further computer readable media includes signal carriers on which digital data may be carried between devices . the flowchart in fig3 is discussed with reference to an example representative of a fictional bank with accounts stored in tables in a database . overall , multiple requests for balances on different accounts are aggregated and sent to the database . a response is received and sent back to original requesters . each request results in a call of a method of the class corresponding to the request at 310 . in the example , each request is of the same class . server receives request 1 and calls getaccountbalance method with parameter 111 server receives request 2 and calls getaccountbalance method with parameter 222 server receives request 3 and calls getaccountbalance method with parameter 333 at 320 , the threshold has been monitored as each request is received and method called . the threshold is three in this instance , and is met . pending calls are then scanned and an aggregated query is formulated at 330 . the aggregated query is then sent to database management system 340 , and a result set , such as a table is received from the database management system at 350 . the result set rows are matched to pending call parameters at 360 , and results are sent to corresponding requesters at 370 . balance value of getaccountbalance method with parameter 111 is set to $ 2000 and call - back is called balance value of getaccountbalance method with parameter 222 is set to $ 3232 and call - back is called balance value of getaccountbalance method with parameter 333 is set to $ 600 and call - back is called in one embodiment , the returned table is simple scanned using the original query requests to match the request to the correct information in the table . access to resource management systems , such as database servers , is often a performance bottleneck . the invention aggregates individual and independent request for the resource , reducing the load on the resource management system , and improving overall system throughput . in clustered environments the resource access layer may reside on several computers that all access a single resource ( database ). having multiple entities accessing the single resource can accentuate the performance bottleneck . the present invention may also improve performance in clustered environments . in one embodiment of the present invention , the number of requests between the resource access layer and the resource is reduced . by reducing the number of requests , communication overhead and resource management system per request overhead is reduced . this application is intended to cover any adaptations or variations of the present invention . it is manifestly intended that this invention be limited only by the claims and equivalents thereof . while some embodiments are described in terms of a database management system , it is recognized that resource requests in many other environments may be aggregated to improve performance .