Patent Application
20080155641
The method and system relate to data storage and retrieval systems and more particularly, to managing activities of database systems through the use of policies.
Database systems are increasingly used for storage, organization, and accessing data.
Although such systems are useful, database systems 10 and database applications 18 used in conjunction with such systems 10 have grown in complexity. This increasing complexity has made it difficult to maintain the database system 10 and to optimize the performance of the database system 10. Improving the maintenance and efficiency of the database system 10 is particularly important because many businesses depend on the efficiency of their database systems 10.
Database maintenance and tuning is typically performed by one or more database administrators. A database administrator may be faced with a multitude of issues in order to optimize the performance of the database system 10. For example, in order to address performance issues, the database administrator monitors queries and deals with critical performance issues for the queries as these issues arise; tune query execution; tune access path generation for the database system; carry out data collection arid reporting; tune the database system's 10 configuration parameters; limits the use of resources so that sufficient resources remain; perform auditing of the database system 10; prioritize execution of queries; regulate access control and authorization; manage the use of resource; and perform other functions related to management and timing of the database system. Thus, the database administrators may control aspects of the database system 10 in order to maintain and tune the database system 10.
Although database administrators exist, such database tuning and diagnostic experts are scarce. Moreover, such skills are difficult and time consuming to acquire. Furthermore, the tuning and diagnostic tasks may be time consuming. The scarcity of experts and the time consuming task itself left most database systems 10 vulnerable to performance, availability, and maintenance problems. In an enterprise setting, a sub-optimal performance of the database system 10 might cause a loss or revenue or cash due to penalties for not being able to fulfill contractual agreements. At the extreme, the effect could be catastrophic for mission critical applications.
Because of the issues in relying solely on skilled database administrators, vendors of the database system 10 are generally obliged to provide tools (not specifically shown) for improving management of the database system 10. These conventional tools are provided as part of the database system 10. Typically such conventional tools aid in diagnosing, monitoring, and tuning database queries. These conventional tools may increase the effectiveness of the customers in maintaining and tuning the database system, thereby reducing the total cost ownership.
Although such conventional tools improve the ability of database administrators to manage database systems, even with the help of such conventional tools, maintenance and tuning may still be difficult. In particular, such conventional tools typically focus on global solutions. Such global solutions may not be available. The complexities of the database system 10 as well as the variety of applications 18, user(s) 19, and queries have also increased. A global solution that accounts for this increased complexity and the varying needs of applications 18 and users 19 may be difficult or impossible to attain. In addition, in some cases, solutions for a small and isolated context are more appropriate for certain problems.
Applications 18, as well as needs of user(s) 19, may vary widely. Consequently, a variety of data accessing patterns may be present. Tuning and optimization criteria for one application 18 or user 19 may not necessarily apply to other applications 18 or user 19. Moreover, criteria for activities such as tuning or optimization for different applications 18 and/or user(s) 19 might be contradictory. Optimizing the database system 18 for one application 18 or user 19 may negatively impact other applications' 18 or users' 19 use of the database system 10. Thus, an effort to fix one optimization problem might end up in creating other problems. Moreover, a system configuration parameters setup for a group of statements might not be compatible with the setup for other groups. Consequently, a generally optimum setup may be difficult to configure. A specific monitoring type focusing on a selected group of statements is often required to diagnose potential problems for these statements. Thus, different sets of database requests may each require individual monitoring. Due to the complexity of the database engine, an optimization patch that is applicable to solve a problem in a group of applications, might causes problem for other applications. Striking a balance in attaining global optimization satisfying all applications 18, queries, and/or users 19 may, therefore, be difficult even with conventional tools.
Accordingly, what is needed is a more unified method and system for addressing the multitude of issues faced by current database administrators. The present invention addresses such a need.
A method, computer-program product, and system for managing a computer system are described. In one aspect, the system includes a policy manager for defining and storing a policy. The policy is a declarative statement of a directive to be carried out by the computer system. The system also includes a policy executor that is coupled with the policy manager and that is for determining whether the policy covers a request to the computer system. In this aspect, the system further includes a policy enforcer, coupled with the policy executor, for utilizing the computer system to carry out the directive for the policy if the policy covers the request. In another aspect, the computer system is a database system. In this aspect, the policy manager also stores the plurality of policies in a table, resolves conflicts between the plurality of policies, and performs a look-up for each of the plurality of policies. The policy executor receives database requests and determines whether each of the database requests is within the scope of at least one of the plurality of policies. In this aspect, the policy enforcer utilizes the database engine to carry out the directive for each the plurality of policies covering each of the database requests. In another aspect, the method includes defining the policy, storing the policy, determining whether a computer system request is covered by the policy, and carrying out the directive for the policy if the computer system request is covered by the policy. In another aspect, the method is used in connection with a computer system that is a database system. In this aspect, the method includes defining a plurality of policies provided by at least one of an authorized user and an application. Each of the policies corresponds to a group and includes a scope, at least one action, and at least one parameter. The action(s) correspond to a directive to be carried out by the plurality of policies, storing the plurality of policies in a table, and determining whether each of a plurality of database requests are within the scope of at least one of the plurality of policies. In this aspect, the method also includes performing a look-up for each policy having a scope within which one of the database requests is. The method also includes the database engine carrying out the directive for each policy corresponding to each of the database requests. In another aspect, computer-program product includes a program for managing performance in a computer system. In this aspect, the program includes instructions for defining the policy, storing the policy, determining whether a computer system request is covered by the policy, and carrying out the directive for the policy if the computer system request is covered by the policy. In another aspect, the computer system is a database system and the program includes instructions for receiving a plurality of policies from at least one of an authorized user and an application. Each of the policies corresponds to a group and includes a scope, at least one action, and at least one parameter. The action(s) correspond to the directive to be carried out by the database system. In this aspect, the program also includes instructions for resolving conflicts between the plurality of policies, storing the plurality of policies in a table, and determining whether the each of a plurality of database requests are within the scope of at least one of the plurality of policies. In this aspect, the method also includes performing a look-up for each policy having a scope within which one of the database requests is. The program also includes instructions for the database engine to carry out the directive for each policy covering to each of the database requests.
According to the method and system disclosed herein, management of the computer system, for example maintenance and tuning of a database system, are facilitated through the use of policies.
The method and system relate to database systems. The following description is presented to enable one of ordinary skill in the art to make and use the method and system and is provided in the context of a patent application and its requirements. Various modifications to the embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the method and system are not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.
A method and system for managing performance of a computer system are described. The method and system include defining and storing a policy using a policy manager. The policy is a declarative statement of a directive to be carried out by the computer system. The method and system also include using a policy executor to determine whether a request to the computer system is covered by the policy. The method and system further include utilizing the computer system to carry out the directive for the policy if the request is covered by to the policy, through a policy enforcer.
The method, system, and computer-program product will be described in terms of a database system. One of ordinary skill in the art will, however, recognize that the method, system, and computer-program product may be utilized with other analogous computer systems. The method, system, and computer-program product are also described in the context of particular database systems. However, one of ordinary skill in the art will recognize that other database systems may be used with the method and system described herein. The method, system, and computer-program product will also be described in terms of a system having certain components performing particular functions. However, one of ordinary skill in the art will recognize that a system having additional and/or different components may be used. The method and system are also described in the context of methods having certain steps. However, one of ordinary skill in the art will recognize that other consistent methods having different and/or additional steps that might be performed in another order may be used. The method and system are also described in the context of specific policies belonging to certain groups and having certain scopes, actions, and parameters. However, one of ordinary skill in the art will readily recognize that additional and/or different policies belonging to additional and/or different groups and having additional and/or different scopes, actions, and/or parameters may be used.
The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
To more particularly describe the present invention, refer to
The system 100 is a framework that is used in connection with policies. A policy is a declarative means for expressing directives to be carried out by the underlying database system 10′, particularly the database engine 14′. The policies are thus preferably declarative in nature as opposed to procedural. This property may provide some degree of flexibility in defining polices independent of the execution engine. For example, a policy for a database system 10′ and implemented using the system 100 might include, but is not limited to one of the following:
Each policy belongs to a group. The groups correspond to the types of activities which the database system 10′ undertakes based on the policy. Stated differently, the group is a domain or area of applicability of database activities that the policy may govern. These groups might include but are not limited to activities such as:
Each policy also includes a scope, one or more actions that correspond to the directive(s), and parameters that further specify the action(s) to be taken. The scope indicates the context in which the policy should take effect. The scope, therefore, determines the extent and level of the policy impact. The scope may thus be useful for isolating a problem or solution areas. In the database system 10′, the scope may include the whole database system 10′, a specific application, a group of statements, or an individual statement only. Group of statements in a scope can be selected based on various statement properties, for example, authorization ID, IP address from where the statement is submitted, plan name, collection name, package name, transaction name, and so forth. For example, the scope might include but is not limited to a particular application or applications, a particular query, a set of queries, or all queries of the database system 10′.
The action specifies the task to be taken when the policy is in effect. In addition, the action taken reflects the directive of the policy. For example, an action might be an executable task such as
Force parallelism with degree 5;
Generate a plan without star join;
Generate a plan with start join;
Force the optimizer to use optimization hints;
Override certain configuration parameters;
Monitor the execution of certain queries; and
Limit the resource usage of certain queries.
The system 100 uses policies to make the database system 10′ perform specific actions under specific circumstances. Through the use of policies, an action taken can focus changes to affect only a specific statement, a group of statements, applications, or the whole database system 10′. Thus, policies dictate the actions, which the underlying database system 10′ is to carry out under certain circumstances set by the policy. These directives may modify the default behavior of the database system 10′ to obtain the desired goals. Based upon their directives, policies may have broad implications for a wide variety of database activities or may be very specific.
For example,
The group 152 includes policies and activities. The policies P1, P2, P3, P4, and P5 and activities A1, A2, A200, and A201 shown are also related to tuning. The activities A1 and A2 are specified as being within the scope 156 of the policy P1. Thus, A1 and A2 are queries and/or statements that are related to tuning and within the scope 156 of the policy P1. Policies P2, P3, P4, and P5 also have activities (not shown) which fall within their scope. In addition, in the group 152, the activities A200 and A201 are not yet regulated by policies. Consequently, the activities A200 and A201 are related to tuning, but do not fall within the scope of existing policies.
Using the framework described herein, for example the system 100, additional policies may be added to the system 150. These additional policies might be added to an existing group such as the group 152 or 154, or may be part of a new group (not shown). The system 100 not only allows such additional policies to be defined, but also resolves any conflicts between existing policies and additional policies, and allows policies to be implemented for activities falling within their scope, as discussed below.
The system 100 includes policy manager 110, policy executor 120, and policy enforcer 130 and can be considered an extension of the underlying database engine 14′. The policy manager 110 defines policies, stores policies, and performs look-ups for policies. In a preferred embodiment, the policy manager 110 also resolves any conflicts between policies. The policy executor 120 receives database requests, such as queries or statements, and determines whether the database requests fall within the scope of the policies. The policy enforcer 130 utilizes portions of the underlying database system 10′ to carry out the directive for the policy if the database request is covered by the policy.
Referring to
The policies are stored preferably using the policy manager 110, via step 204. Step 204 preferably includes the policies being read from the input media, discussed above, by the policy manager 110 and stored. In one embodiment, any conflicts between the policies provided in step 202 and/or pre-existing policies of overlapping scope are also resolved in step 204. However, in a preferred embodiment, conflict resolution is performed when the policy is activated. In one embodiment, the policies may not be in effect, or activated, unless specified by the authorized user 19′ and/or application(s) 18′. Some or all of the policies may be activated in step 206. In a preferred embodiment, conflict resolution is thus performed in step 206. Once activated, the policies control the behavior of the database system 10′ under certain conditions.
Database requests are received, via step 208. The database requests may include a request for any activity performed by the database system 10′. Thus, database requests may include queries or statements provided to the database system 10′. In a preferred embodiment, the database requests are part of an input stream that may be provided from user(s) 19′ or one or more of the application(s) 18′ through the UI 12′.
The database requests are analyzed to determine whether some portion of the policies covers the one or more of the database requests, via step 210. Step 210, therefore, determines whether any of the database requests falls within the scope of any of the policies. Stated differently, it is determined in step 210 whether any of the database requests is affected by any of the policies. In a preferred embodiment, step 210 is performed by the policy executor 120. In particular, the policy executor 120 preferably reads the input stream(s) including the database requests and calls the policy manager 110 to perform a policy look-up to determine if the database requests match the scope of one or more of the policies.
If a database request is not covered by any policy, then the method 200 is terminated for that database request. As a result, the query or statement in the database request is executed normally by the database system 10′. However, if one or more database requests is covered by one or more of the policies, then the directives of the policies are carried out, via step 212. In addition, the database request is executed. This is preferably accomplished through the policy enforcer 130. The policy enforcer 130 selects the appropriate actions for the appropriate policies and utilizes the database system 10′, particularly the database engine 14′, to perform the actions.
Thus, using the system 100 and the method 200, policies may be provided by user(s) 19′ and/or application(s) 18′ and implemented where appropriate. The system 100 and method 200 thus provide flexible mechanism to affect the default behavior of the underlying database system 10′ towards achieving specific goals. The system 100 and method 200 may define, manage, and enforce policies related in different groups in a consistent manner. Any conflicts that arise between policies may be identified and resolved. Further, using the method 200 and system 100, it is determined whether any policies affecting the current execution scope (e.g. the database requests) and only these policies cause actions to be undertaken. Through the system 100 and method 200, policies can be used to isolate a problem into a more specific context, upon which either general or customized solutions are derived. Moreover, the user 19′ may be able to customize solutions to be applicable only for a specific scope, thereby eliminating interference between solutions. Furthermore, the declarative nature of a policy expression gives the user 19′ some degree of flexibility in defining policies independent from the database engine 12′. Moreover, the system 100 and method 200 allow for a policy framework that is open, flexible, extensible, and allows more policy domains to be added without disrupting the existing support. Because the system 100 and method 200 perform no additional functions when a database request is not within the scope of a policy, additional overhead used by the system 100 and method 200 may be limited. Although described in the context of the database system 10′ the system 100, method 200, and corresponding policies may be applicable to other computer systems and/or applications.
To more particularly describe one embodiment of the method and system, refer to
The system 100′ includes the policy manager 110′, policy executor 120′, and policy enforcer 130′ having functions that are analogous to the policy manager 110, policy executor 120, and policy enforcer 130, respectively. In addition, the policy manager 110′ includes a policy definition block 112 and a policy look-up block 114. The policy definition block 112 preferably processes and performs conflict resolution between policies. The policy definition block 112 also stores policies in a memory such as a policy cache 113 or policy tree. The policy look-up block 114 is used to look up policies to which database requests provided to the policy executor 120′ correspond. Also shown are policy activation 160, statement cache 162, push-out manager 164, reports 165, and query warehouse 166. In one embodiment, the statement cache 162, push-out manager 164, and query warehouse 166 are incorporated into the system 100′. In one embodiment, the statement cache 162, push-out manager 164, and query warehouse 166 are preferably part of the extended database system 10″. In one embodiment, the query warehouse 166 is an optional component and may be provided as an additional feature. However, for ease of discussion, they have been depicted separately in
One or more policies for use in managing the database system 10″ are defined, preferably by a policy manager 110′, via step 252. Step 252 is analogous to the step 202 of the method 200 depicted in
Processing is performed on the policies, via step 254. This processing is preferably performed using the policy definition block 112. The processing includes analyzing the policies to perform consistency checking. This consistency checking determines whether there are conflicts between the policies and/or conflicts with preexisting policies having an overlapping scope. Any conflicts are resolved. If a conflict cannot be resolved, an error message may be provided. The policies are stored by the policy definition block 112, via step 256. The policy definition block 112 preferably stores the policies in tables. In one embodiment, a table corresponds to a particular set of policies.
The policies may then be activated, via step 258. Also in step 258, the policies are read into memory and stored, preferably as a policy tree or policy cache 113. The policy activation block 160 preferably activates the policies. In such an embodiment, the user 19″ (through the UI 12″) and/or application 18″ invokes the policy activation block for a particular set of policies. In a preferred embodiment, policy consistency checking and conflict resolution between policies, if any, might be done under policy activation block 258. Once activated, the policies control the behavior of the database system 10″ under certain conditions.
Database requests are received, via step 260. The database requests may include a request for any activity performed by the database system. In a preferred embodiment, the database requests are part of an input stream that may be provided from a user 19″ through the UI 12″ or from one or more of the application(s) 18″. Thus, the system 100′ preferably accesses the input stream to the database system 10″ from users 19″ via the UI 12″ and/or the application(s) 18″.
The database requests are analyzed to determine whether the one or more of the database requests are covered by some portion of the policies, via steps 262-268. In step 262, the policy executor 120′ preferably examines each database request. The policy executor 120′ calls the policy look-up block 114, via step 264. The policy look-up block 114 requests a look-up of the appropriate policy in the memory, which may be a policy tree or policy cache 113, by the policy definition block 112, via step 266. Based on this look-up and the database requests being examined, it is determined whether there is a match between the database requests and the scope of any of the active policies, via step 268. In steps 262-268, the policy executor 120′ may compare database requests with the statement cache 162 if necessary. If there is no match, then no policy is invoked and the method 250 terminates. Consequently, the underlying database engine 14″ may process the database request in a conventional manner.
However, if one or more database requests are covered by one or more of the policies, then the directives of the policies are carried out, via step 270. This is preferably accomplished through the policy enforcer 130′. In particular, the underlying database engine 14″ may process the database request in a conventional manner. However, in addition, the policy executor 120′ invokes the policy enforcer 130′. The policy enforcer 130′ would select the appropriate actions for the policies to which the database requests correspond and utilize the database system 10″, particularly the database engine 14″, to perform the actions.
The system 100′ and method 250 may be further understood with reference to specific examples. However one of ordinary skill in the art will readily recognize that the method 250 and system 100′ are not limited to such an example. Suppose a user 19″ wishes the following policies to apply to a database system: (1) monitor myPersonnel application and report the statistics for performance tuning; (2) monitor myERP application only for spikes in query execution time, where the particular execution time is either 250% greater or lower than the average execution time, and generate a detailed report when this happens; (3) limit the execution time of all queries defined under plan name P1, collection name COL1, and package name PKG1, to maximum of two minutes; stop the execution when this threshold is reached and generate a detailed report; and (4) monitor the execution time of all query run by authorized ID Tom submitted from IP address 9.30.45.50, and generate a report if the execution time exceeds 1 minutes. For simplicity only four policies are defined in this example. However, one of ordinary skill in the art will readily recognize that another number of policies having different directives may be used.
After defining these policies, they are input to and received by the system 100″ in step 252. Also in a preferred embodiment, step 252 is performed by a specific command that calls the policy manager 110′. In turn, the policy manager 110′ invokes the policy definition block 112 to read the policies being input in step 252. These policies would be processed and stored by the policy definition block 112 in steps 254 and 256. The policy definition block may also perform consistency checking and conflict resolution between policies, if any, in step 254. The policy definition 112 uses these verified policies to serve a look-up request from policy look-up 114. Therefore, to improve look-up performance, the verified policies may be stored as an efficient data structure in a cache, such as the policy cache 113, managed by policy definition block 112. Such a configuration may make the look-up process more efficient. In a preferred embodiment, these policies could be expressed in tabular form using a high level notation such as shown in Table 1.
Note that policies 1, 2, and 4 are apparently in a group having to do with monitoring, while policy 3 is in a group having to do with resource limits. The data collection and reporting group complements the other groups by supporting the specification of the desired level of granularity for the report. In the example above, the granularity of the report is allowed to vary to a maximum of 15. The scopes of the policies include applications, plan with collection and package, and authorization ID with IP address. However, other scopes based on different criteria may also be used.
In this example, the policies are normalized and represented in two database tables. The profile tables are used to represent the scope applicable for a set of actions, whereas the actions and parameters are recorded in the profile attributes table. Two additional analogous history tables may be used by the system 100′ and the method 250 to record the history of which policies are active at any given time period. This policy history maybe used for diagnostics and might be shipped directly to the service team with other associated information. As can be seen in Table 1, the actions associated with the four policies are: MONITOR normal query execution; MONITOR exceptions such as ASUTIME, SPIKE, and CARDINALITY; LIMITS the resource usage, such as CPU; set various system optimization parameters, such as STAR JOIN, MINIMUM START JOIN TABLES, PAGES THRESHOLD; and provide specific optimization hints. Note that the actions for either the same or different groups can be added without interfering with the existing policies. Further, the actions for policies are not limited to those described herein, but could include other and/or additional actions.
In a preferred embodiment, after step 256, the policies are stored in tables in the policy definition block 112 but not yet activated. Stated differently, the system 100′ is not activated yet. Instead, explicit activation and deactivation commands are used to avoid an inadvertent increase in overhead due to the system 100′ and method 250. Thus, in step 258 a user 19″ activates the policies of Table 1. The user 19″ preferably invokes policy activation block 160 to activate the policy in step 258. In a preferred embodiment, a specific command is provided for activating the policies, and another particular command for deactivating the policies. In addition, other commands may be used to check if the policy is active and report additional information. In a preferred embodiment, the policies are activated by the policy activation 160 calling the policy manager 110′. In one embodiment, the policy manager 110 may also perform consistency checking and conflict resolution between policies, if any, in step 258.
Once the policies are activated, the database requests, which are provided to the policy executor 120′ and, in steps 262-266, are examined to determine whether a match with any scope of any of the policies is found. To do so, the policy executor 120′ calls the policy look-up block 114 to determine whether there is an active policy affecting the current request or query. If so, the specific policy, for example policy 1, will affect this database request. Consequently, through step 270 the actions of policy 1 will be carried out. Thus, in addition to the database system 10″ processing the database request, the policy executor 120′ invokes the policy enforcer 130′ to carry out the MONITOR action. If another of policy 1, 2, 3, and 4 were found to match a database request, then the action for that policy would be carried out by the policy enforcer 130′. As a result, the query is monitored and a report with granularity level three is produced. In the embodiment shown, the report generation is initiated by a report generator 141 in the extension of database engine 14″ and produced by the push-out manager 164. Such a report might be directed to a file, a stream, a database table, an active listener, a pipe, an e-mail, a queue, or other output media. In addition, the report may be further processed as part of the query warehousing facility 166, if such a facility is provided. In the example above in which the monitor action is performed and the report of granularity level three provided, the report might be realized into several tables.
Thus, the system 100′ and method 250 enjoy substantially the same benefits as the system 100 and method 200. In particular, policies may be provided by user(s) 19″ and/or application(s) 18′ and implemented where appropriate. The system 100′ and method 250 thus provide for a policy framework that is open, flexible, extensible, and allows more policy domains to be added without disrupting the existing support. Moreover, because the system 100′ and method 250 perform no additional functions when a database request is not within the scope of a policy, additional overhead used by the system 100′ and method 250 may be limited. Although described in the context of the database system 10′, the system 100′, method 250, and corresponding policies may be applicable to other computer systems and/or applications.
A method and system for managing a database system are described. The method and system have been described in accordance with the exemplary embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and any variations would be within the spirit and scope of the method and system. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.
