System and method for distributed data collection and storage

[0002] The present application is the subject of U.S. provisional application Ser. No. 60/077,140 filed Mar. 6, 1998.

[0003] 1. Technical Field of the Invention

[0004] The present invention relates to complex information technology systems (IT) and, in particular, to a system and method for retrieving, storing and propagating data indicative of system component states.

[0005] 2. Background and Objects of the Invention

[0006] With the increasing use of computers, particularly personal computers (PCS), both in business and in the home, computers have become an integral tool of most information technology (IT) workers in a wide variety of fields. Another technological development facilitating the pervasiveness of computers in society is the growing interlinkage of computers, either locally in a Local Area Network (LAN) and/or remotely, such as through dedicated lines or via the World-Wide Web or Internet.

[0007] As networks of computers and peripheral devices grow in size and the interlinkages multiply, however, inter-component incompatibilities arise, manifesting themselves in a variety of ways, both obvious and subtle. To analyze the behavior of the various interacting resources within an IT system, large amounts of monitoring data are needed to duplicate or model system state conditions. Armed with sufficient monitoring data, a system administrator can model particular system state behaviors to analyze component failures and the reasons therefor, as described in assignee's co-pending patent applications entitled “System and Method for Generating Performance Models of Complex Information Technology Systems”, U.S. Ser. No. 09/036,393U.S. Pat. No. 6,311,175, filed Mar. 6, 1998, and “System and Method for Model Mining Complex Information Technology Systems”, U.S. Ser. No. 09/036,394pending filed Mar. 6, 1998, both of which are and incorporated herein by reference.

[0008] As set forth in more detail in the aforedescribed co-pending patent applications, various system characteristics may be examined and performance data generated therefrom. For example, in a large network of computers and peripherals, some key characteristics include network bandwidth, processor speed, memory, database query speed, etc. Since large amounts of such data measurements are necessary to adequately model system (or subsystem) performance, one problem with existing monitoring or measuring techniques is that the data collection mechanism itself consumed significant resources, interfering with system operation and, therefore, skewing the data measurements.

[0009] It is, accordingly, an object of the present invention that the acts of data measurement consume minor amounts of resources and, therefore, influence the system monitoring as little as possible.

[0010] It is also an object of the present invention to provide an adaptable monitoring and data collection system and method so that new components may be more easily integrated (and old ones removed) into the existing system.

[0011] It is another object of the present invention to provide a robust monitoring and data collection system and method which continues to operate despite failures in various subsystems.

[0012] It is a further object of the present invention that the system and method collect time-related system state data in a computer network from a variety of different types of system components.

[0013] It is a still further object of the present invention that the system and method store the same aforementioned monitoring data in a variety of storage facilities, preferably storing the data in a consistent record structure.

[0014] It is another object of the present invention that the system and method record and store computer network component time-related state data in a flexible manner, optimizing the collection and storage of such data.

[0015] It is yet another object of the present invention that the system and method record and store the aforementioned computer network component time-related state data across components in a modular manner, such that loss of specific components does not impair the functionality of other components holding the data.

[0016] It is a still further object of the present invention that the system and method record and store the computer network component time-related state data in a manner allowing scalability, so that overall system effectiveness is not governed by the size or complexity of the underlying system infrastructure.

[0017] It is another object of the present invention that the system and method record and store the aforementioned computer network component time-related state data such that effective means for querying the stored state data is not a condition of knowledge of the manner in which queried data is collected or stored.

[0018] The present invention is directed to a system and method for automatically and adaptively capturing, recording, and retrieving large amounts of complex Information Technology (IT) system component state data in a distributed, hierarchical manner. Monitored components include virtually any element in an IT system, including hardware, e.g., routers, hard drives, etc., and software, e.g., databases, operating system kernels, etc. In a preferred embodiment, collection and storage elements, or objects, are logically arranged in a hierarchical manner such that data collected may be propagated up in the hierarchy. Similarly, querying of such data is performed in a hierarchial manner, e.g., queries are propagated down and results propagated up. Propagation of collected data through the storage system is performed in a manner to optimize system performance. Uniformity in the collection and storage scheme allows easy expansion of the collection and storage system, and thus the underlying IT system infrastructure.

[0019] A more complete understanding of the system and method of the present invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:

[0020] FIG. 1 is an example hierarchial arrangement of Collection Objects which are used in one embodiment of the present invention;

[0021] FIG. 2 is an example configuration of Collector and Saver Objects within the Collection Objects shown in FIG. 1;

[0022] FIG. 3 is a detailed characterization of a Collector Object and other objects classified according to functionality;

[0023] FIG. 4 illustrates an exemplary Sampler Object class and other classes with associated functionality;

[0024] FIG. 5 illustrates an exemplary Saver Object class and other classes with associated functionality;

[0025] FIG. 6 illustrates a chronology of operations for implementing Collector Object data collection and storage pursuant to an embodiment of the present invention;

[0026] FIG. 7 illustrates an object modeling technique chronology of an example of query processing; and

[0027] FIG. 8 illustrates a propagation and storage chronology of a SampleList by an Internal Collection Object.

[0028] The present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0029] As discussed, when considering a large, inter-linked network of computers, routers, and many other devices, each of which run various applications thereon, numerous system resources are consumed, e.g., network bandwidth, processor cycles, memory, etc. At a higher level of system usage, applications utilize databases, shared file systems and other resources. The inter-relations between the myriad components, i.e., the behavior of the total system (or portions thereof) are complicated and difficult if not impossible to predict. To study such a complex IT system, large amounts of time-related monitoring data must be collected, preferably on an automatic basis and stored for analysis. It should be understood that the monitoring data can originate from reading existing statistics, e.g., by querying Simple Network Management Protocol (SNMP) agents, or from taking direct measurements.

[0030] With reference now to FIG. 1 of the drawings, there is shown a sample tree, designated generally by the reference numeral 10, having a number of nodes therein, each generally referred to herein as a collection object (CO) and each generally representing a hardware component or software application used to collect data. As is apparent from FIG. 1 and inherent in a tree-type structure, the respective nodes are arranged hierarchically, which is a preferred embodiment of the present invention. At the lowest level or tier, i.e., a leaf level, the individual leaf nodes or collection objects, designated by the reference numerals 12A-E, retrieve the aforementioned data by taking measurements, e.g., by executing programs to collect the data or by reading statistics, such as SNMP or operating system kernel statistics.

[0031] At an intermediate level or tier, the individual collection objects, designated within FIG. 1 by the reference numerals 14A and 14B, retrieve data from the collection objects below them in the tree hierarchy, i.e., CO 14A from COs 12A and 12B, and CO 14B from COs 12C-E, respectively. Similarly, at the top level or tier, a root node 16 collects data from all of the lower-level nodes, i.e., directly from the intermediate COs 14A and 14B and indirectly from the leaf COs 12A-E. It should be understood that multiple intermediate level nodes may be employed in such a hierarchical manner.

[0032] Although the preferred node topology is tree-shaped or hierarchical, it should be understood that the system and method of the present invention may be adapted for different topologies pursuant to other methodologies. For convenience and ease of discussion, however, only tree-shaped, hierarchical structures such as shown in FIG. 1 will be described hereinafter.

[0033] Collection Objects used in practicing the system and method of the present invention include a variety of physical and logical devices, which run within an existing computer network and other communication devices. For example, the leaf node collection objects 12A-E may periodically launch programs to ascertain disk space availability on respective servers, returning time-dependent percentage values for the servers. This periodic data sampling is preferably stored in a memory, file or database, e.g., memory 18A in CO 12A. After a given time interval, which may be predetermined, contingent upon particular events or random, the stored data is propagated upward, e.g., from CO 12A to CO 14A.

[0034] It should be understood that all of the collection objects have substantially the same capabilities despite their physical and logical differences: retrieve data from a target, which may be another CO in the case of a non-leaf node, store the data and potentially propagate the data. It should therefore be understood that the internal or parent COs 14A, 14B and 16 operate substantially the same as the aforedescribed leaf COs 12A-E, i.e., collecting data from their respective children, and possibly performing additional operations on the gathered data. With reference again to FIG. 1 for example, intermediate CO 14A may compute the total disk space availability among its children COs, i.e., COs 12A and 12B. Alternatively, CO 14A may compute an aggregate value of a series of stored data, e.g., the number of database queries, or a minimum, maximum, average, etc. of the values stored in a given CO, all of its children COs or a combination of COs. In a preferred implementation where a large amount of data is collected, all of the collected and stored data is not necessarily propagated upwards from the lower-level subservient COs or kept for future use. Instead, resources at each level may be optimized by storing only the most recently collected data at the leaf COs and only averages thereof propagated upwards.

[0035] It should be understood that in preferred embodiments of the present invention each component is modelled from the field of distributed object computing and each performs a specific, well-defined task. The components or objects, i.e., the COs, communicate by message exchange, also known as calling a method of an object. In this manner, messages may be sent to objects running on different computers connected via a network, such as illustrated in FIG. 2 and discussed further herein.

[0036] When analyzing performance criteria pertaining to the data stored in the COs, queries are preferably first directed to the highest level, i.e., the root node or CO 16 in the tree structure shown in FIG. 1. For example, a query on the amount of system disk space availability may be available in a memory 22 within the root CO 16 itself and computed directly. If not, the query may be forwarded to respective COs therebelow, e.g., to a memory 20A in CO 14A and a memory 20B in CO 14B to ascertain the requisite information for the query, the sum being the requested value. It should, of course, be understood that the root CO 16 may contain a partial answer and a further query may be made to either of COs 14A and 14B to complete the needed information, the partial results being combined at the root CO 16. Likewise, if further information is required, the query could interrogate one or more of the leaf COs 12A-E (and respective memories 18 therein) to obtain the pertinent information.

[0037] In view of the hierarchial data structure illustrated in FIG. 1, it should be understood that when the requisite information for a query is stored or cached at the root CO 16, minimal query time is achieved. For example, the root CO 16 may contain therein, e.g., in the memory 22, the desired disk space availability information without resort to further queries downward and consequent delay. The cost for achieving such enhanced performance, however, is increased usage of storage space within the memory 22 of the root CO 16, and the cost of the network and processing bandwidth for periodically propagating that information to the root node. Conversely, resources in the upper levels of the tree are not consumed if no collected data samples are propagated, i.e., the data stays resident in the respective leaf COs 12A-E, such as in memory 18A, or in the intermediate COs 14A and 14B. It should, of course, be understood that the response times to the aforementioned query to root CO 16 will be longer since the query must be propagated down to the leaves 12A-E and the answers percolate back up.

[0038] Through balancing the data within the respective multi-level COs and determining which data to store and which to propagate, system resources (network, storage and computational power) and performance at both data collection and query time may be optimized. Furthermore, by organizing the informational data collection and propagation to avoid potential performance bottlenecks and wide dependencies, subsystem failures of a particular leaf CO 12 or intermediate CO 14 need not incapacitate the entire network, allowing the system to continue operations despite particular component problems.

[0039] With reference now to FIG. 2, there is illustrated a preferred embodiment of the aforedescribed collection objects as used in an interlinked network of three computers, generally designated by the reference numerals 24, 26 and 28. As shown in the figure, computer 24, which may be termed herein a root computer, is connected to two child or leaf computers 26 and 28, corresponding to the aforedescribed tree nomenclature discussed in connection with FIG. 1. In a preferred embodiment of the present invention, computer 24 includes therein an internal collector object 30 and a saver object 32, the parameters and functionality of which are described in more detail hereinafter. A collection object in a preferred embodiment of the present invention contains at least one (plurality) of discrete collector objects and one saver object. Computers 26 and 28 include therein respective collector objects 34A-C, 36A and 36B and saver objects 38 and 40, respectively. As shown in the figure, collector objects 34A-C share saver object 38 and collector objects 36A and 36B share saver object 40. Five targeted attributes to be monitored are illustrated, i.e., targets 42A-C, 44A and 44B, each of which monitor respective device attributes or characteristics, and each of which are, in turn, monitored by the aforementioned respective collector objects 34A-C, 36A and 36B, which collect sample data from the respective targets 42A-C, 44A and 44B.

[0040] As shown in FIG. 2, target data from the respective targets are sampled by the appropriate collector object monitoring that target, e.g., CO 34C sampling target 42C. The targeted attributes being monitored may include disk space availability, as discussed above, database query response time, number of hard disk accesses on a given server, a router's throughput and many other system and component performance criteria. The acquired data samples propagate up from a particular target to the collector object and the saver object associated therewith. For example, in computer 26 a target value for target 42A propagates up (through collector object 34A) to the associated saver object 38, which in turn is monitored by the internal collector object 30 of computer 24 and the sampled data may pass thereto from the saver object 38. Finally, the internal collector object 30 of computer 24 may pass the data on to the saver object 32 therein.

[0041] It was earlier discussed that the targeted attribute to be monitored with a collection object may be any number of performance values. It is therefore apparent that the Collector Objects monitoring these events will have differing functionalities, these functionalities governed by the targeted attribute for which the given Collector Object is designed to monitor.

[0042] With reference now to FIG. 3, there is shown a particular Collector Object 46 with a more detailed characterization of how it is defined and classified according to its functionality. Collector Object 46 is shown in FIG. 3 along with its associated components. The class or group of components uniquely defines a specific class of object. For example, in a preferred embodiment, the components defining the collector object 46 are itsID, itsSamplelnterval, itsSampler, and itsSaver, the latter of which is an identifier stored within the Collector Object 46 that records which saver object the collected data will be sent to and stored within. Another member of the collector class depicted in FIG. 3 and shown in Collector Object 46 is the collector identifier, entitled itsId, which is a unique string labeling a specific Collector Object. Another member of the collector class, itsSampleInterval, specifies the time interval over which samples are to be recorded at the target, which may constitute either a real number or integer value, which value may be used as a counter between consecutive collection/storage events. The final member of the collector class is itsSampler, which denotes the Sampler Object that actually samples the raw system data. It is important to note that the respective collector objects do not actually sample the data itself, and the collector and saver objects may often be considered as one object for simplicity of discussion. A Retrieve function is also defined for the Collector Object 46 by which a SampleList of data is acquired.

[0043] With further reference to FIG. 3, there is shown an Internal Collector Object 48, which is derived from the aforedescribed Collector Object 46, such as may be used with the Internal Collector Object 30 in FIG. 2. As shown in FIG. 3, a member, or element, of the Internal Collector Object 48 is labeled itsSource, which is of type Saver, referring to the source Saver Object from which the Internal Collector Object 48 extracts data using the aforementioned Retrieve function. For example, in the Internal Collector Object (ICO) 30 shown in FIG. 2, the itsSource member of ICO 30 references Saver Object (SO) 38 or Saver Object 40 since SO 38 and SO 40 contain the sampled data which the Internal Collector Object 30 is responsible for propagating upward to the root SO 32. Therefore, the value assigned to itsSource in the ICO 30 would be a unique identifier of one of the Saver Objects 38 or 40.

[0044] With reference again to FIG. 3, a container class, denoted CollectorList 50, is also illustrated. The CollectorList 50 is responsible for holding a group of collector objects, requiring a number of associations between a single CollectorList and multiple Collector Objects. The CollectorList is also responsible for the creation of the aforedescribed Collector Objects and Internal Collector Objects by use of its own functional members, CreateLeaf and CreatelnternalNode. The CreateLeaf function of the CollectorList 50 creates leaf collector objects. CreateLeaf inputs enabling creation of a leaf Collector Object, i.e., a Collector 46, include: a Collector Object name or identifier (itsID), an interval over which the Collector Object is to sample data from its target (itsSamplelnterval), a specified Sampler Object (itsSampler), and a Saver Object to which the Collector Object stores its sampled data (itsSaver).

[0045] The CreatelnternalNode member of the CollectorList 50 is responsible for creating Internal Collector Objects, such as ICO 30 in FIG. 2, where the Internal Collector Object is distinguished from the Collector Object in that the Internal Collector Object takes an intermediate position within the hierarchy of Collector Objects while those objects specifically referred to as Collector Objects take position as a leaf within the hierarchy, as described hereinbefore in connection with FIGS. 1 and 2. CreateInternalNode member inputs for the creation of the aforementioned Collector Object 46 include: the Collector Object Name (itsID), sample interval (itsSampleInterval), the designated Sampler Object (itsSampler), a Saver Object to which sampled data is to be saved (itsSaver) and a Saver Object from which the sampled data is from (itsSaver), and an optional Filter Object 52 through which sampled data may be filtered before saving to the Saver Object.

[0046] The association of the Filter Object 52 with the Collector Object is also illustrated in FIG. 3. A given Collector Object 46 may have either zero or one associations with a given Filter Object 52. The filter class shown in FIG. 3 is the base class from which potentially numerous filter classes may be derived, only one of which, a MinMaxFilter class 54, is illustrated. In general, a filter object computes a new list of data from a given input of sampled data. In other words, at times it may be more advantageous to store (in Store Objects) aggregation functions or the like of the sampled data rather than the raw sampled data itself, which could consume large amounts of storage. A filter object may, therefore, be used to meet this need. The MinMaxFilter 54 shown in FIG. 3 may, for example, compute the minimum and maximum values from a data sample. Other common filters used may include filters to convert the sampled data into average values, median values, modal values, or any other numerical derivative, as generally illustrated by an alternative filter 55 in FIG. 3.

[0047] The funtionability of a leaf Collector Object may be better understood with inspection of the following pseudo-code for such an object:

[0048] while true

[0049] begin

[0050] sleep (itsInterval);

[0051] val=itsSampler.TakeSample( );

[0052] Sample sample=(itsID, currentTime, val);

[0053] itsSaver.Store(sample);

[0054] end

[0055] As set forth in the above pseudo-code, the Collector Object will sleep, or remain idle, during the time interval ItsInterval, which has preferably been set to the desired sampling period of the specific Collector Object. When this interval expires, itsSampler takes a dedicated sample and assigns this value to the variable val. The next step of the example code attaches the Collector Object unique identifier (itsID) and the time of the sampling (currentTime) event to the sampled data val. These combined values are then stored in an object of type Sample 62, which is an aggregate of an id of type string, itsValue of type Value 58 and itsInterval of type Interval 56, as illustrated in FIG. 4.

[0056] The attachment of such delimiting information for the sample value may be accomplished by any number of common methods, including the use of a relational database or array storage techniques, as is understood in the art. The sampled value val with the attached information is then assigned to the array type variable sample and subsequently stored in member itsSaver. Such a cycle would complete and repeat after a duration defined in the sampling interval itsInterval with each subsequent sample given a new record in a database in the appropriate storage device.

[0057] Example pseudo code for the exemplary operation of an internal node, such as the Internal Collector Object 30 in FIG. 2, is given below:

[0058] while true

[0059] do

[0060] sleep (itsInterval);

[0061] if (this internal node has a Filter object) then begin

[0062] itsSaver.StoreRows(

[0063] itsFilter.compute(

[0064] itsSource.Retrieve(itsID, forever-interval)));

[0065] end

[0066] else begin

[0067] itsSaver.StoreRows(itsSource.Retrieve(itsID,

[0068] forever-interval));

[0069] end

[0070] itsSource.ClearRows(itsID, 0);

[0071] end

[0072] In this example, the ICO sleeps for an itsInterval length of time.

[0073] With reference again to FIG. 4, there is illustrated exemplary Sampler classes and associated classes, such as used in FIG. 3. For example, the Interval class 56 used in CreateInternalNode has two numerical members, begin and end, both of type Timestamp, which in this exemplary embodiment is a 32-bit unsigned integer used to measure a number of seconds relative to a specific point in time; however, the exact format, whether signed or unsigned and the precise number of bits is inconsequential with regard to the scope of the present invention so long as the Timestamp type is useful for measuring elapsed time durations.

[0074] With further reference to FIG. 4, the Value class 58 has a member itsValue of type Type, which is a union type data that can be assigned any basic Simple Network Management Protocol (SNMP) value, i.e., string, integer, counter, gauge, etc., and the additional values of Null indicating absence of an assigned value, a boolean value, indicating a true or false condition, or float, indicating, in the exemplary embodiment, a 32-bit floating point number.

[0075] A SampleList class 60 is a container class containing objects of the type Sample 62, also shown in FIG. 4, which essentially contains three separate values concurrently, as previously discussed: an identification of type String (id), a value of type Value (itsValue) obtained from the actual sampling of a target component, and an interval of type Interval (ItsInterval). The identification of a monitor, a Collector Object/Sample Object combination, is designated with a string containing the path name of the monitor, this path name defined by the monitor location within the collection hierarchy. Such a method is well known and similar to methods in which directories and files are named in a file system such as a Unix file system and merits no further discussion herein.

[0076] A Sampler class 64 depicted in FIG. 4 is the Sampler base class. One method is defined in the given sampler base class 64 for sampling data, i.e., a TakeSample( ) command, which returns data of type Value 58. Three example classes that could be derived from the sampler base class 64 are also shown in the figure, e.g., an ExecSampler class 66 has as members: itsCommandLine of type string and the TakeSample command of type Value 58. The ExecSampler 66 executes the itsCommandLine command and interprets the value returned to be value of type itsType, that can be found in its base class sampler 64.

[0077] An SNMPSampler 68 class reads a value from an existing SNMP agent. The agent from which the SNMPSampler 68 reads this value is specified by SNMPSampler 68 members: itsCommunity, itsHost, and itsSNMPAddress, each of type String. An IndirectSNMPSampler 70 class is itself derived from the SNMPSampler 68 class as shown in FIG. 4. The Indirect SNMPSampler 70 effects a sampling of targeted data by reading an SNMP array of values defined by member itsListAddr, a String type. The array of SNMP addresses read from itsListAddr is then compared to the itsTarget value and a match is found between the itsTarget value and a value held in the itsListAddr array. Since the itsListAddr is an array, an index number of the method element between the itsListAddr and itsTarget is then used to direct the IndirectSNMPSampler to the appropriate address where the TakeSample member is invoked. Further classes may be derived from the Sampler 64 class, as indicated by the open association 72.

[0078] With reference now to FIG. 5, there is illustrated a Saver class 74 and its associated classes. The class Saver 74 is itself an abstract base class that specifies valid members that may be used for restoring and retrieving data samples. The Saver 74 class member itsCollectorList stores a list of references to specific Collector Objects that store information in the Saver 74. For example, the Store command is used to store a single value of type Sample 62. The Store command uses the Sample's ID and Interval as key values. The StoreRows command is used to store a SampleList 60. The ClearRows command clears the stored samples from a monitor, the specific monitor specified by the identifier anId. Sampled data not to be removed from invocation of the ClearRows command are specified by the LeaveSome delimiter. The Retrieve command retrieves a SampleList, i.e., the SampleList to be retrieved specified by monitor identification anld and a time interval over which the SampleList is to include, this interval specified by an identifier anInterval. Transfer is a method to copy samples from the current Saver Object to another Saver Object, the recipient Saver Object being specified by the Saver identifier aSaver.

[0079] Three example Saver classes derived from the Saver 74 abstract base class are shown in FIG. 5. MemorySaver 76 may store samples in main memory. FileSaver 78 is an example Saver class that may store samples in a file. OracleSaver 80 is a Saver class that may store samples in an Oracle database. Other Saver classes may be derived from the Saver 74 abstract base class as shown by the open class association 82.

[0080] With reference now to FIG. 6, there is illustrated an event chronology depicting the taking and storing of samples by a give Collector Object set forth in the present invention. The objects involved in taking and storing of samples include a Collector Object 84, a Sampler Object 86, and a Saver Object 88. The event is initiated at the Collector Object 84, which sends a TakeSample command 90 to the Sampler Object 86, instructing the Sampler Object 86 to take a sample. The Sampler Object 86 then sends a target specific command to read a sample depicted herein as ReadSample 92. The appropriate target 94 then forwards the requested sampled data Value 96 back to the Sampler Object 86 and then on to the Collector Object 84 by a return path 98. The Collector Object 84 then adds a TimeStamp and a monitor identifier (anId) to the sampled data. Discrete sampled data and corresponding TimeStamp and monitor identifier are then forwarded 100 to the aforementioned Saver Object 88 in the form of a Sample 62 value. The data is then stored in a physical storage device 102 by an appropriate path 104 linking the Saver Object 88 and the Storage Device 102.

[0081] With reference now to FIG. 7, there is illustrated an object modeling technique chronology of the processing of a query, e.g., to root node 16 in FIG. 1. Such a query is initiated by a User 106, who starts the query by issuing a Retrieve command 108 to a root the Collector Object 110, which is atop the Collector Object hierarchy. This object selects a particular Collector Object to forward the query to by reading the first component of the name, or identifier, in the query message. Once the query is received by the aforementioned particular Collector Object, the query is then forwarded to a Saver Object 112 associated with that particular Collector Object. Saver Object 112 then formulates a store-specific query in the form of a Retrieve command 114 and sends the Retrieve command 114 to a Store Object 116 associated therewith, which in this example does not contain the data concerning the query. Store Object 116 then sends a message 118 to the Saver Object 112 indicating that the queried data is not located at the corresponding Store Object 116.

[0082] Saver Object 112 sends a message 120 to the Collector Object 110, which then redirects 121 the query to another Collector Object one level lower in the Collector Object hierarchy, in this case another Collector Object 122. Collector Object 122 then forwards a Retrieve command 124 to a Saver Object 126 associated with the Collector Object 122. Saver Object 126 subsequently forwards a Retrieve command 128 to a Store Object 130, which contains the data being queried. This data, SampleList, is then forwarded via a return message 132 back to the Saver Object 126, which in turn forwards (step 134) the SampleList to the Collector Object 122, which then propagates (step 136) the SampleList up a level in the hierarchy to the aforementioned Collector Object 110, where the SampleList is finally returned (step 138) to the User 106, via the CollectorList object (not shown).

[0083] With reference now to FIG. 8, there is illustrated a propagation and storage chronology of a SampleList by an Internal Collector Object. In particular, the objects involved in this event include an Internal Collector Object 140, Saver Objects 142 and 144, and optionally a Filter Object 146. The event is initiated with the ICO 140 executing a Retrieve command 148 directed towards the aforementioned Saver Object 142 located a level lower in the hierarchy to retrieve a SampleList therefrom. The Saver Object 142 executes a Retrieve command 150 on a physical Store Object 152. The SampleList is then sent (step 154) from the Store Object 152 to the Saver Object 142, where the SampleList is then returned (step 156) to the ICO 140. The event may end here, or an aggregation function may be derived from the retrieved SampleList by use of the aforementioned Filter Object 146. If data filtering is invoked, the ICO 140 forwards (step 158) the SampleList to the Filter Object 146, which then performs or computes an aggregation function on the SampleList, at which time the SampleList is most likely altered in some manner. The new SampleList is then returned (step 160) to the ICO 140 where it is sent to a targeted Saver Object, i.e., the aforementioned Saver Object 144, by execution of a Store command 162. Saver Object 144 then saves (step 164) the data at a physical Store Object 166.

[0084] Although preferred embodiments of the system and method of the present invention have been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.