Abstract:
Computer monitoring system and corresponding processes. One example provides a host data processing module; adaptively updates the host module with one or more additional data processing modules; and processes a document comprising a plurality of separate data portions, said data portions being intended for processing by different data processing modules, the document processing comprising parsing the document in accordance with a plurality of rules so as to validate the document, wherein the method comprises retrieving a subset of rules, in respect of at least one said data processing module, and building said plurality of rules from said subset. The present invention therefore provides a method of carrying out processing of documents using an adaptable set of data processing modules which act on different portions of the document. A single document can then be sent and/or stored on behalf of and/or processed by the plurality of data processing modules, thereby increasing efficiency of processing and network resource utilisation.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application is a continuation of International Application No. PCT/GBO3/01869, filed May 1, 2003, entitled “Monitoring System for General Purpose Computers”, which claims priority under 35 U.S.C. 119 to Great Britain Application No. 0210242.4, filed May 3, 2002, entitled “Updating a Monitoring Agent Using a Structured Document.” The entire contents of these applications are hereby incorporated by reference. 
     
    
     FIELD OF THE INVENTION  
       [0002]     This invention relates to a monitoring system for general-purpose computers, such as computer workstations and servers, connected via a data communications network to common resources.  
       BACKGROUND  
       [0003]     In a typical private computer network, a plurality of computer workstations will be connected to common resources in the network. The workstations may be ones themselves having a fully operative application execution environment, such as a conventional personal computer running applications on a native operating system, such as Microsoft Windows™, or may be thin client computers using the resources of a network server, such as a Citrix™ server, to run application sessions on their behalf. Typically, a network manager will be tasked with ensuring that both the hardware and software resources within the network are operating correctly, being used effectively, and within a set of more or less formal rules for network resource utilisation. Network resource utilisation may for example be monitored to ensure that the appropriate software licences are in place and that unauthorised software is not being used on the network. It is useful to a network manager to be able to monitor network resource utilisation from a remote terminal, without having to monitor the activities at each workstation separately.  
         [0004]     Systems for remotely monitoring network resource utilisation are known. U.S. Pat. No. 5,987,135 describes a system and method for controlling and monitoring remote distributed processing systems from one or more control processing systems by downloading agent-application programs from the control processing systems to remote control middleware modules on the distributed processing systems, where the control processing systems have a library of available agent-applications for carrying out various monitoring and control tasks, such as determining which applications are run, determine the version of installed software and current software fixes, etc.  
         [0005]     In known systems, monitoring is typically carried out repeatedly and continually on the network. Depending on the type and frequency of monitoring carried out, the amount of data generated and resources used can be relatively large. As a result there is often a conflict between, on the one hand, a need to reduce the amount of monitoring carried out in order to reduce the impact on network resources to an acceptable level, and on the other hand, a need to gather monitoring data at regular intervals in order to generate an accurate and complete assessment of network resource utilisation.  
         [0006]     It would be desirable to provide a network resource utilisation monitoring system that has the ability to collect and process large amounts of data in a secure and reliable fashion whilst reducing the impact on network resources. It would also be desirable to provide such a system having the capability to add new monitoring functions with relative ease and reliability. Preferably, the system should be adaptable such that generic monitoring and control functions are provided by such a system whilst allowing the addition of customised monitoring modules to such a system.  
       SUMMARY OF THE INVENTION  
       [0007]     According to one aspect of the invention there is provided a method of monitoring processes on one or more general purpose computers, said method comprising: 
        providing a host data processing module;     adaptively updating the host module with one or more additional data processing modules; and     processing a document comprising a plurality of separate data portions, said data portions being intended for processing by different data processing modules, the document processing comprising parsing the document in accordance with a plurality of rules so as to validate the document,     wherein the method comprises retrieving a subset of rules, in respect of at least one said data processing module, and building said plurality of rules from said subset.        
 
         [0012]     Each adaptable data processing module thus performs some processing (e.g. of a task) in accordance with a different portion of the validated document. Since these data portions are embedded within a single document, an advantage of embodiments of the invention is that a single document can be sent and/or stored on behalf of and/or processed by the plurality of data processing modules, thereby increasing efficiency of processing and network resource utilisation.  
         [0013]     In at least one embodiment of the invention the plurality of rules is embodied in a schema and each subset of rules is provided by a sub-schema. In one arrangement the document, schema and sub-schema are specified using the eXtensible Mark-up Language (XML), thus enabling the document to conveniently include a reference to the plurality of rules intended to be used for parsing this document. The reference is identified during the parsing of the document, which means that the rules used to validate the document are explicitly linked to the document itself.  
         [0014]     Conveniently the method includes holding a framework for the plurality of rules, and building said plurality of rules using a structure specified by said framework. In the case where the plurality of rules is a schema, the framework may be a schema wrapper.  
         [0015]     Further objects, advantages and features of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings. 
     
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0016]      FIG. 1  is a schematic illustration of components of a network monitoring system, in accordance with an embodiment of the invention;  
         [0017]      FIG. 2  is a schematic illustration of software components in a monitoring agent for a general-purpose computer, in accordance with an embodiment of the invention;  
         [0018]      FIG. 3  is a schematic illustration of software modules for a general-purpose computer and a control console in accordance with an embodiment of the invention;  
         [0019]      FIG. 4  is a flow diagram showing processing carried out during document processing in accordance with an embodiment of the invention;  
         [0020]      FIG. 5  is a schematic illustration of a first type of schema built in accordance with an embodiment of the invention; and  
         [0021]      FIG. 6  is a schematic illustration of a second type of schema built in accordance with an embodiment of the invention. 
     
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0022]     Referring now to  FIG. 1 , in accordance with one embodiment of the invention, a data processing system includes a monitoring software platform installed on a plurality of general-purpose computers  2 ,  4 ,  6  connected via a data communications network  8  to a common control unit  10 . The data communications network  8  may take the form of a private network, a public network (such as the Internet), or a virtual private network.  
         [0023]     The general purpose computers, referred to hereinafter as user stations, may be in the form of conventional personal computers running applications on a native operating system, such as Microsoft Windows™ or may be network servers, such as Citrix™ servers, providing the resources to thin client workstations (not shown) to run application sessions on their behalf, or may take the form of other types of data processing device such as handheld devices including personal digital assistants (PDAs), smartphones, etc. The user stations  2 ,  4 ,  6  each have user software applications installed thereon, such as word processing software, web browser applications, e-mail applications, image processing applications, and various other types of known user applications which are executed on the user stations in response on start-up of the user station, or when selected by the user from an initialisation menu provided by the user station. Each user station  2 ,  4 ,  6  also includes a monitoring software platform application in the form of an adaptable monitoring agent  3 ,  5 ,  7  installed thereon, to be described below in further detail.  
         [0024]     The control unit  10 , which may for example take the form of a network server with an associated management terminal (not shown) is provided with a database  12  for storing data sent to the console  10  by each of the monitoring agents  3 ,  5 ,  7 . The control unit also includes monitoring software platform applications in the form of a control console  14 , to be described in further detail below, and a reporting console  16  installed thereon. Note that the functions of the control unit may be distributed over a plurality of physical data processing units, which may be located remote from one another and connected via network links. The control console  14  interoperates with the monitoring agents  3 ,  5 ,  7  under the instruction of a network administrator to retrieve selected monitoring data from the user stations  2 ,  4 ,  6  and to input the data into the database  12 . The reporting console  16  is used by the network administrator to present and manipulate the monitoring data and to generate summary reports derived from the monitoring data using in-built processing, manipulation and reporting functions.  
         [0025]     Each monitoring agent  3 ,  5   7  includes a plurality of components, of which relevant components are shown in  FIG. 2 . An agent host object  20  has a coordinating function, whereby documents containing data to be shared between other modules of the agent are processed and distributed, and whereby data are collected from the other modules for the purpose of collecting and storing persistent state, held in local state store  34  (which is part of the local storage capabilities of the user station; it may for example form part of a hard drive storage medium provided in the user station) and for posting collected monitoring data to the control unit  10 . A communications module  22  handles the delivery of information to and from the control unit  10 . A scheduler module  26  takes schedule information from the agent host  20 , which is in turn received from the console  14 , and builds a schedule that is used to trigger events in the agent, such as initialising a module and instructing the module to carry out a specified monitoring task at scheduled date/times, and triggering the posting of monitoring data to the console  14  at scheduled date/times. A first plugin monitoring module  28  carries out specified monitoring tasks relating to the hardware components of the user station, under the control of scheduler  26  and agent host  20 . A second plugin monitoring module  30  carries out specified monitoring tasks relating to the user software applications installed on the user station, under the control of scheduler  26  and agent host  20 . A third plugin monitoring module  32  carries out further specified monitoring tasks relating to user station, under the control of scheduler  26  and agent host  20 . The plugin monitoring modules  28 ,  30 ,  32  are examples of a plurality of customised plugin modules that may be installed on the user station by the network administrator, using console  14 , to adapt the agent to specific monitoring. The plugin monitoring module(s) may be written by the platform developer or a third party developer using an application programming interface (API) provided with the monitoring software platform, whereby the generic control functions, such as the scheduling and communications functions, of the platform are reused. Thus, while only three plugin monitoring modules are described herein, it should be understood that the agent may include more such modules, and that any such modules may be added, or removed, at a time after installation of the monitoring software platform as and when desired by the network administrator.  
         [0026]     When instructed by the network administrator to transmit configuration data and/or software updates to an agent on a user station  2 ,  4 ,  6 , the console  14  generates a broadcast document, structured as an XML document, containing a plurality of document portions for processing and distribution to various of the different agent modules by the agent host  20 . When storing persistent state in the form of configuration data for various of the different agent modules, the agent host  20  generates a configuration document containing a plurality of document portions containing configuration data from various of the different agent modules and stores the same in local state store  34 , for subsequent processing and redistribution to the different agent modules by the agent host. This is carried out for example periodically and/or during the shut down procedures for the user station. When posting monitoring data to the console, agent host  20  generates a session document containing a plurality of document portions containing monitoring data from several of the different agent modules, and posts the document to the console  14  via communications module  22 . This is carried out at scheduled date/times, preferably during relatively inactive periods of network usage (e.g. around midnight).  
         [0027]     An embodiment of the invention will now be described in more detail, with reference to  FIG. 3 , which illustrates several of the agent modules  20 ,  22 ,  26 ,  28  as installed in one of the monitoring agents  3 ,  5 ,  7 , along with counterpart modules  34 ,  36 ,  38 ,  40  installed in the control console  14 . The console modules include a console host  34 , a console communications module  36 , a console scheduler module  38 , and a console plugin module  40 . The counterpart modules construct document portions for transmission to respective agent modules on each user station  2 ,  4 ,  6 , under the control of rules in the console  14 , and instructions received from the network administrator, and are used to validate respective document portions received from respective agent modules on each user station  2 ,  4 ,  6 , and process the received monitoring data for storage in database  12 .  
         [0028]     Each agent module  20 ,  22 ,  26 ,  28  includes a software code part, labelled  20   a;    22   a;  etc., defining the functions carried out by the module when executed, and schema portions, respectively labelled  20   b,    20   c,    20   d;    22   b,    22   c,    22   d;  etc., and the agent host  20  performs validation of documents when received for processing thereby, as will be described in further detail below. The schema portions include broadcast document schema portions, labelled  20   b,    22   b,  etc., configuration document schema portions, labelled  20   c,    22   c,  etc., and session document schema portions, labelled  20   d,    22   d,  etc.  
         [0029]     Each console module  34 ,  36 ,  38 ,  40  includes a software code part, labelled  34   a;    36   a;  etc., defining the functions carried out by the module when executed, and schema portions, respectively labelled  34   b,    34   d;    36   b,    36   d;  etc., and the console host  34  performs validation of documents when received for processing thereby, as will be described in further detail below. The schema portions include broadcast document schema portions, labelled  34   b,    36   b,  etc., and session document schema portions, labelled  34   d,    36   d,  etc.  
         [0030]     The schema portions  20   b,    20   c,    20   d  and  34   b,    34   d  stored in the agent host  20  and the console host  34  are referred to herein as schema wrappers. These define the structure of a schema used to validate a given type of document received by the respective host. A schema is built using the wrapper schema of the appropriate type along with sub-schemas, which are inserted into the schema wrapper, of the appropriate type. These sub-schemas are the schema portions  22   b,    22   c,    22   d;  etc., and  36   b,    36   d,  etc. stored in the remaining agent modules.  
         [0031]     In order to add a new plugin to any one or more of the monitoring agents  3 ,  5 ,  7 , the network administrator selects an appropriate plugin module addition function on the console side, and the plugin is sent to the appropriate one or more monitoring agents  3 ,  5 ,  7  as a software update which is processed by the agent host  20 . On receiving a new software update, the agent host  20  validates the received file and stores the plugin in a data store, such as a hard drive, on the user terminal  2 ,  4 ,  6 . A corresponding entry, along with an identifier allowing the plugin module to be launched, is written to the registry of that user terminal  2 ,  4 ,  6  for subsequent lookup. Thus, when a new plugin module is installed in a monitoring agent, its corresponding sub-schemas are made available for incorporation in a schema built by the respective host in order to validate a document received which contains a portion including data for processing by the new plugin module (or its counterpart plugin module in the console).  
         [0000]     Processing of Documents  
         [0032]      FIG. 4  shows steps carried out by the agent host  20  in order to process a received document. The document may be a broadcast document, a configuration document, or a session document (to be transmitted by the monitoring agent  3 ,  5 ,  7  to the console  14 ). It should be appreciated that the description hereof also applies to the console host  34  in relation to the processing of received broadcast documents (to be transmitted to one or more monitoring agents) or session documents.  
         [0033]     Firstly in step  100 , the document is received. The document may be received over the network interface or from a local function. As described above, in order to validate the received document, a schema, comprising a schema portion corresponding to the type of received document (broadcast, session, configuration) and sub-schema portions, is created. Thus, in order to create the validating schema, the agent host  20  needs to retrieve the relevant sub-schemas.  
         [0034]     Accordingly, the agent host  20  first queries the registry of the user station on which it runs to obtain the list of entries identifying the currently stored agent platform modules and its current plugin modules. The agent host  20  then proceeds to initialise all monitoring platform modules that are not currently running in the user station, at step  102 , and queries the respective modules in turn, at step  104 , requesting their respective sub-schemas. After receiving their responses, the agent host  20  may transmit an instruction (not shown as a separate step) to each plugin module not currently carrying out a monitoring task to close down. Generally, the communications module  22  and the scheduler module  26  are left running along with the agent host  20  whilst the user station is operative, since their functionality may be called upon at any time. On the other hand, plugin modules are generally closed down by the scheduler module  26  after carrying out their scheduled monitoring tasks, to reduce user station resource utilisation by the monitoring system.  
         [0035]     Once all the required sub-schemas have been retrieved, the agent host  20  uses the wrapper schema (schema portions) to build, at step  106 , a schema containing the sub-schemas retrieved at step  104 . This step essentially involves placing the retrieved sub-schemas from each module in a predetermined part of the wrapper. The sub-schemas can be inserted in an order corresponding to the order in which the module identities are retrieved from the registry, or in accordance with alphabetical ordering, etc. Thus, although the wrapper schema does not include actual identifying information for each plugin module, the final schema is built using input from each of the plugin modules in turn.  
         [0036]     Once the schema is built, the agent host  20  stores the built schema in memory. To validate a document, the agent host  20  then uses a document validation function provided by a parser used by the agent host  20  to validate the entire document contents using the freshly built schema, at step  108 . On validation of the document contents, the various different document portions are distributed to the respected agent modules, step  110 . A similar process is carried out by the console host  34  in building up schemas for processing documents received from agent hosts across the network (e.g. session documents). Note that the schema building process may be carried out whenever a document is to be processed. More preferably, any required schemas are built on start-up of the user station or the console system, and stored for use until the station or system is shut down, or a new plugin module is loaded.  
         [0037]     In one arrangement the document received at step  100  may be an eXtensible Mark-up Language (XML) document, while the schema created at step  106  may be an XML schema and the parser used in step  108  to validate the created schema may be an XML parser. The XML Schema standard, which is incorporated herein by reference, is a working draft of the W3C Schema Working Group. A description of this standard can be found in the document “XML Schema: Formal Description”, W3C Working Draft, 20 Mar. 2001, and a copy can be found at http://www.w3.org/TR/2001/WD-xmlschema-formal-20010320/. For the purpose of validating a document in accordance with a given XML schema (here step  108 ) an XML reader such as Microsoft™ XML parser version 4.0 may be used. As is known in the art, for an XML document to be validated it must inform the reader which schema should be used; accordingly the documents received at step  100  include an identifier corresponding to the schema subsequently created at step  106 .  
         [0038]     In this embodiment, there are various parts of the system where data are exchanged and/or stored, namely the broadcast document sent from the console to a monitoring agent, the local configuration document and locally-stored session history for the monitoring agent, and the document that is posted from the monitoring agent to the console. The posted document is a latest available version of the locally-stored session document; hence both the locally stored and posted session documents share the same schema. XML documents sent across the network can be compressed and encrypted to increase network transmission speeds and security.  
         [0000]     Defining Bespoke XML Schema  
         [0039]     The schema portions and sub-schemas used to create the schema at step  106  will now be described in more detail.  
         [0040]     In XML documents, elements (or tags) in the documents generally have the form: 
        &lt;name&gt; . . . &lt;/name&gt;       
 
         [0042]     The content of the tag is between the ‘&gt;’ and the ‘&lt;’. If no content is required, then the end tag can be omitted.  
         [0043]     Attributes appear inside the opening tag brackets, thus for example: 
        &lt;:name attribute1=‘value1’ attribute2=‘value1’ . . . &gt; . . . &lt;/:name&gt;       
 
         [0045]     Generally attributes have string values, but they can have dates, times, or any form, and they can be validated by the XML schemas used.  
         [0046]     Element and attribute identifiers reside in namespaces. If a tag comes from a particular namespace rather than the default then it may be used as follows: 
        &lt;namespace:name&gt; . . . &lt;namespace:name&gt;       
 
         [0048]     In order to use a namespace the namespace has to be declared, and the identifiers within a namespace must be unique.  
         [0049]     There is a special floating attribute that can be applied anywhere within the document, but often is on the root element, setting the scene for the whole document. This attribute is “xmlns”; in any XML document, ‘xmlns’ attributes can be applied to any tag, meaning that from this point on in the XML document, the associated namespace applies. The “xmlns” attribute is used as follows: 
        &lt;anytag . . . xmlns:nnn=‘mmm’ . . . &gt;    where ‘mmm’ is the full name of the namespace and ‘nnn’ is a shortened namespace name that is used within a document instance to indicate which XML Schema an element belongs to. The ‘nnn’ part can be null, in which case the schema is opened up into the default namespace.        
 
         [0052]     The XML standard (referenced above) defines a standard schema that controls the structure of an XML schema document; for a document to make use of that schema, the document contents must request its associated namespace to be made available. This is achieved by including the following in the XML file: 
        xmins:xsd=“http.//www.w3.org/2001/XMLSchema”       
 
         [0054]     This firstly requests the use of a namespace (xmlns), secondly states that it is to be aliased as the ‘xsd’ (:xsd) namespace, and thirdly defines the namespace as ‘http://www.w3.org/2001/XMLSchema’ (which is a URI (Uniform Resource Identifier)). By including this schema in the namespace, further schemas may be defined using standard tags that will be understood by an XML compliant engine and interpret the file as an XML schema file.  
         [0055]     Further, bespoke schemas, can be defined by including a further “xmins” reference in the XML file: 
        xmlns=“monactive:agentbroadcast”       
 
         [0057]     In this example, the xmlns reference comprises three levels: the word ‘monactive’ defines the root of a namespace tree; the second level indicates that the entity using the schema is to be a monitoring agent; and the third level indicates the use for which the monitoring agent is going to put the document (in this example broadcast use).  
         [0058]     In this embodiment there are three uses; broadcast, configuration and session, i.e. ‘broadcast’, ‘config’ and ‘session’, and there are therefore three namespaces: 
        monactive:agent:broadcast     monactive:agent:config     monactive:agent:sessions        
 
         [0062]     Thus, in an exemplary document, the top-level tag and the attributes associated therewith could comprise: 
        &lt;xsd:schema targetNamespace=“monactive:agent:broadcast” . . . &gt; . . . &lt;/xsd:schema&gt;       
 
         [0064]     The ‘schema’ tag from the ‘xsd’ namespace, with a “targetNamespace” attribute having a value ‘monactive:agent:broadcast’ informs the XML parser that an XML schema is being defined, and that the name of the schema is specified in attribute “targetNamespace” (i.e. monactive:agent:broadcast)  
         [0065]     Because of the adaptability of the monitoring agents by means of the addition (and/or removal) of plugin modules, the present invention provides a system whereby a schema can be both known in order to validate the documents, but unknown, such that a module can change its own portion of a schema while no other module knows about, or relies on, anything inside it. In order to allow a flexible architecture, the present invention employs what is referred to herein as a ‘wrapper schema’, which at the highest level sets out an overall structure of a schema, and ‘sub-schemas’ which are inserted into the wrapper and are defined by each module defines in accordance with a set of rules.  
         [0066]     There are two general forms for the schemas used, namely “flat” and “block” structured.  
         [0067]      FIG. 5  illustrates an example of a “flat” structured schema created at step  106  by the agent host  20  or the console host  34 . The configuration and broadcast schemas follow this general form. The structure of the built schema includes a top level part  200  derived from a broadcast or config wrapper schema. The next level down includes a shared part  202  derived from a shared sub-schema, including a section part  204  in the next level of the hierarchy, a host part  206  derived from a host sub-schema, a comms part  208  derived from a comms sub-schema  208 , a scheduler part  210  derived from a scheduler sub-schema, and one or more plugin parts  212  (only one is shown in  FIG. 5 ) corresponding to each plugin module and derived from each respective submodule schema. Each plugin part may include a section part  214  structured in the same manner as the section part  204  appearing in the shared part  202 .  
         [0068]      FIG. 6  illustrates an example of a “block” structured schema created at step  106  by the agent host  20  or the console host  34 . The session schema follows this general form. Each module can write its own session data many times in the same agent session. Over time a module will write many sessions to the agent host, and the agent host will gather up these module sessions into one agent session, essentially grouped in accordance with the time they were written to the agent host. Thus, each block part includes a description of the time period over which the session data were collected. The structure of the built schema includes a top level part  300  derived from a session wrapper schema. The next level down includes a shared part  302  derived from a shared sub-schema, including a section part  304  in the next level of the hierarchy, and a session part  305  having in the next level of the heirarchy a host part  306  derived from a host sub-schema, a comms part  308  derived from a comms sub-schema  308 , a scheduler part  310  derived from a scheduler sub-schema, and one or more plugin parts  312  (only one is shown in  FIG. 6 ) corresponding to each plugin module and derived from each respective submodule schema. Each plugin part may include a section part  314  structured in the same manner as the section part  304  appearing in the shared part  302 .  
         [0069]     The following section gives examples of broadcast, configuration and session wrapper schemas created at step  106  in accordance with their respective schema wrappers. The short namespace aliases used are “mab”, “mac” and “mas”, respectively.  
         [0070]     First, an example of a broadcast wrapper schema:  
                                                                                                                                                                                                         WRAPPER SCHEMA 1 (broadcast)                                    &lt;?xml version=“1.0” encoding=“UTF-8”?&gt;            &lt;xsd:schema targetNamespace=“monactive:agent:broadcast”                xmlns=“monactive:agent:broadcast”           xmlns:xsd=“http://www.w3.org/2001/XMLSchema”&gt;                &lt;xsd:element name=“broadcast”&gt;   200                &lt;xsd:complexType&gt;                &lt;xsd:all&gt;                &lt;xsd:element ref=“shared” minOccurs=“1” axOccurs=“1”/&gt;   202           &lt;xsd:element ref=“host” minOccurs=“1” maxOccurs=“1”/&gt;   206           &lt;xsd:element ref=“comms” minOccurs=“1” maxOccurs=“1”/&gt;   208           &lt;xsd:element ref=“scheduler” minOccurs=“1” maxOccurs=“1”/&gt;   210           ...   212                &lt;/xsd:all&gt;           &lt;xsd:attribute name=“checksum” use=“required”&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=“xsd:string”&gt;                &lt;xsd:pattern value=“[0-9A-F]{8}”/&gt;                &lt;/xsd:restriction                &lt;/xsd:simpleType&gt;                &lt;/xsd:attribute&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;           ...            &lt;/xsd:schema&gt;                  
 
         [0071]     Note that the element ref section in the middle of wrapper schema 1 comprises an ellipsis. This section is assembled by the agent or console host polling all the remaining plugin modules (in other words, this section comprises data corresponding to the sub-schemas retrieved at step  104 ). The same applies in relation to each of the configuration and session wrapper schemas.  
         [0072]     Next, an example of a configuration schema wrapper:  
                                                                                                                                                                                                 WRAPPER SCHEMA 2 (configuration)                                    &lt;?xml version=“1.0” encoding=“UTF-8”?&gt;            &lt;xsd:schema targetNamespace=“monactive:agent:config”                xmlns=“monactive:agent:config”           xmlns:xsd=“http://www.w3.org/2001/XMLSchema”&gt;                &lt;xsd:element name=“config”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:all&gt;                &lt;xsd:element ref=“shared” minOccurs=“0” maxOccurs=“1”/&gt;           &lt;xsd:element ref=“host” minOccurs=“0” maxOccurs=“1”/&gt;           &lt;xsd:element ref=“comms” minOccurs=“0” maxOccurs=“1”/&gt;           &lt;xsd:element ref=“scheduler” minOccurs=“0” maxOccurs=“1”/&gt;           ...                &lt;/xsd:all&gt;           &lt;xsd:attribute name=“checksum” use=“required”&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=“xsd:string”&gt;                &lt;xsd:pattern value=“[0-9A-F]{8}”/&gt;                &lt;/xsd:restriction&gt;                &lt;/xsd:simpleType&gt;                &lt;/xsd:attribute&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;           ...            &lt;/xsd:schema&gt;                  
 
         [0073]     Next, an example of a session wrapper schema:  
                                                                                                                                                                                                                                                                                       WRAPPER SCHEMA 3 (session)                                    &lt;?xml version=“1.0” encoding=“UTF-8”?&gt;            &lt;xsd:schema targetNamespace=“monactive:agent:sessions”                xmlns=“monactive:agent:sessions”           mlns:xsd=“http://www.w3.org/2001/XMLSchema”&gt;                &lt;xsd:attribute name=“from” type=‘xsd:dateTime’/&gt;           &lt;xsd:attribute name=“to” type=‘xsd:dateTime’/&gt;                &lt;xsd:element name=“sessions”&gt;   300                &lt;xsd:complexType&gt;                &lt;xsd:choice minOccurs=‘0’ maxOccurs=‘unbounded’&gt;                &lt;xsd:element ref=“shared” minOccurs=“0”/&gt;   302           &lt;xsd:element ref=“session” minOccurs=“0” maxOccurs=“unbounded”/&gt;   305                &lt;/xsd:choice&gt;           &lt;xsd:attribute name=“checksum” use=“required”&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=“xsd:string”&gt;                &lt;xsd:pattern value=“[0-9A-F]{8}”/&gt;                &lt;/xsd:restriction&gt;                &lt;/xsd:simpleType&gt;                &lt;/xsd:attribute&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;           &lt;xsd:element name=‘session’&gt;                &lt;xsd:complexType&gt;                &lt;xsd:choice minOccurs=‘0’ maxOccurs=‘unbounded’&gt;                &lt;xsd:element ref=“host” minOccurs=“0” maxOccurs=“unbounded”/&gt;   306           &lt;xsd:element ref=“comms” minOccurs=“0” maxOccurs=“unbounded”/&gt;   308           &lt;xsd:element ref=“scheduler” minOccurs=“0” maxOccurs=“unbounded”/&gt;   310           ...   312                &lt;/xsd:choice&gt;           &lt;xsd:attribute ref=“from” use=“required”/&gt;           &lt;xsd:attribute ref=“to” use=“optional”/&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;           ...                &lt;/xsd:schema&gt;                      
 
         [0074]     All three wrapper schemas above refer to a shared area into which standard form data can be stored: 
        &lt;xsd:element ref=“shared” minOccurs=“0”/&gt;       
 
         [0076]     Referring to the shared sub-schema set out below, in the shared area, simple text strings scan be stored in an entry section. A string is given an “id” which is used to refer to it (see parts in italics). A group of text strings can be related together using a relation section and optionally associated with another text string. A hierarchical construct can be represented as a string divided into substrings by a divider, and the substrings connected together using the “id” and a parent id (“pid” . . . see parts in italics).  
                                                                                                                                                                                                                                                                                                 SHARED SUBSCHEMA                                &lt;!-- shared subschema for any ancestor −−&gt;            &lt;xsd:element name=“shared”&gt;   202, 302                &lt;xsd:complexType&gt;                &lt;xsd:sequence&gt;                &lt;xsd:element ref=‘section’ minOccurs=“0” maxOccurs=“unbounded”/&gt;                &lt;/xsd:sequence&gt;                &lt;/xsd:complexType&gt;            &lt;/xsd:element&gt;            &lt;xsd:element name=“section”&gt;   204, 214, 304, 314                &lt;xsd:complexType&gt;                &lt;xsd:choice&gt;                &lt;xsd:element name=“entry” maxOccurs=“unbounded”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:attribute name=“id” type=“xsd:ID”/&gt;           &lt;xsd:attribute name=“string” type=“xsd:string”/&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;           &lt;xsd:element name=“heir” maxOccurs=“unbounded”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:attribute name=“id” type=“xsd:ID”/&gt;           &lt;xsd:attribute name=“pid” type=“xsd:string” default=‘˜’/&gt;           &lt;xsd:attribute name=“string” type=“xsd:string”/&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;           &lt;xsd:element name=“rel” maxOccurs=“unbounded”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:attribute name=“id” type=“xsd:ID” use=“required”/&gt;           &lt;xsd:attribute name=“ids” type=“xsd:IDREFS” use=“required”/&gt;           &lt;xsd:attribute name=“string” type=“xsd:string” use=“optional”/&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;                &lt;/xsd:choice&gt;           &lt;xsd:attribute name=“title” type=“xsd:string” use=“required”/&gt;           &lt;xsd:attribute name=“nextid” type=“xsd:string” use=“optional”/&gt;           &lt;xsd:attribute name=“divider” type=“xsd:string” use=“optional”/&gt;                &lt;/xsd:complexType&gt;            &lt;/xsd:element&gt; ...                  
 
         [0077]     These “entry” tags allow, in the XML document being validated, storage of a simple string of text associated with an “id” that may be referred to later in the document, while “heir” tags allow storage of hierarchical strings, like paths or URLs. An “id” is associated with a string, “parented” refers to another “heir” that belongs in front of this string in the hierarchy being modelled. A “rel” tag allows any “IDREF”s to be related together as attribute “id”s and optionally bound to another string. The “IDREF”s and the string form a unique pair.  
         [0078]     The following section gives examples of subschemas stored by the agent host module which are inserted into the wrapper schema at the appropriate position (e.g. referring back to Wrapper schema 1, occurrence of &lt;xsd:element ref=“host” minOccurs=“1” MaxOccurs=“1”/&gt; causes the following instance of the host subschema to be inserted into the wrapper).  
         [0079]     Firstly an example of the host subschema corresponding to the broadcast wrapper schema is presented:  
                                                                                                                                                                                                                                                                                                     HOST SUBSCHEMA 1 (broadcast)                                    ...                &lt;xsd:element name=“host”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:all&gt;                &lt;xsd:element name=“upgrade” minOccurs=“0” maxOccurs=‘1’&gt;                &lt;xsd:complexType&gt;                &lt;xsd:sequence&gt;                &lt;xsd:element name=“module”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:attribute name=“type” use=“required”&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=“xsd:string”&gt;                &lt;xsd:enumeration value=“exe”/&gt;           &lt;xsd:enumeration value=“service”/&gt;           &lt;xsd:enumeration value=“host”/&gt;           &lt;xsd:enumeration value=“comms”/&gt;           &lt;xsd:enumeration value=“plugin”/&gt;                &lt;/xsd:restriction&gt;                &lt;/xsd:simpleType&gt;                &lt;/xsd:attribute&gt;           &lt;xsd:attribute name=“name” type=“xsd:string” use=“required”/&gt;           &lt;xsd:attribute name=“remote_filename” type=“xsd:string”            use=“required”/&gt;                &lt;xsd:attribute name=“local_filename” type=“xsd:string”            use=“required”/&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;                &lt;/xsd:sequence&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;                &lt;/xsd:all&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;           ...                      
 
         [0080]     The “upgrade” element is an optional element in a broadcast document. It lists the new modules to download, what the name is (which also identifies what other plugin sections there are in the schema), where they are located (remote_filename) and what they should be called locally (local_filename).  
         [0081]     Next, an example of a host subschema corresponding to a session wrapper schema:  
                                                                                           HOST SUBSCHEMA 2 (session)                                    ...                &lt;xsd:element name=“host”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:all&gt;           &lt;/xsd:all&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;           ...                      
 
         [0082]     In the following section, examples are given of communications module subschemas. First, an example of a communications module subschema corresponding to the broadcast schema wrapper:  
                                                                                                                                                                       COMMS SUBSCHEMA 1 (broadcast)                                    &lt;xsd:element name=“comms”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:all&gt;                &lt;xsd:element name=‘utcserver’&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=‘xsd:string’&gt;                &lt;xsd:pattern value=“([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})|([a-zA-            Z0-9_][a-zA-Z0-9_.]+)”/&gt;                &lt;/xsd:restriction&gt;                &lt;/xsd:simpleType&gt;                &lt;/xsd:element&gt;                &lt;/xsd:all&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;???                      
 
         [0083]     Next, an example of a communications subschema corresponding to a configuration schema wrapper:  
                                                                                                                                                                                                               COMMS SUBSCHEMA 2 (configuration)                                    &lt;xsd:element name=“comms”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:all&gt;                &lt;xsd:element name=‘utcserver’&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=‘xsd:string’&gt;                &lt;xsd:pattern value=“([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})|([a-zA-            Z0-9_][a-zA-Z0-9_.]+)”/&gt;                &lt;/xsd:restriction&gt;                &lt;/xsd:simpleType&gt;                &lt;/xsd:element&gt;           &lt;xsd:element name=“broadcast”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:attribute name=‘general-modified-at’ type=‘xsd:datetime’/&gt;           &lt;xsd:attribute name=‘specific-modified-at’ type=‘xsd:datetime’/&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;                &lt;/xsd:all&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;???                      
 
         [0084]     Next, an example of a communications subschema corresponding to a session schema wrapper:  
                                                                                       COMMS SUBSCHEMA 3 (session)                                    &lt;xsd:element name=“comms”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:all/&gt;                &lt;xsd:attribute name=‘from’ type=‘xsd:dateTime’/&gt;           &lt;xsd:attribute name=‘to’ type=‘xsd:dateTime’/&gt;                &lt;/xsd:complexType&gt;            &lt;/xsd:element&gt;                  
 
         [0085]     In the following section, an example of a general form and specific subschema variants are given of scheduler module subschemas. Firstly an example of the general form is as follows:  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 SCHEDULER SUBSCHEMA 1 (general)                                    &lt;xsd:element name=“scheduler”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:all&gt;                &lt;xsd:element name=“schedule”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:sequence&gt;                &lt;xsd:element name=“at” minOccurs=“0” maxOccurs=“unbounded”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:sequence&gt;                &lt;xsd:element name=“module”&gt;                &lt;xsd:complexType&gt;                &lt;xsd:attribute name=“name” type=“xsd:IDREF”            use=“required”/&gt;                &lt;xsd:attribute name=“event” type=“xsd:string”            use=“required”/&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;                &lt;/xsd:sequence&gt;           &lt;xsd:attribute name=“when” use=“required”&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=“xsd:string”&gt;                &lt;xsd:pattern value=           “[@+](20[0-9]{2})?([01*][0-9*])?([0123*][0-9*])?([0-            2*][0-9*])?([0-9][0-9])?U?”/&gt;                &lt;/xsd:restriction&gt;                &lt;/xsd:simpleType&gt;                &lt;/xsd:attribute&gt;           &lt;xsd:attribute name=“lastranutc” use=“optional” default=“2001-01-            01T00:00:00”&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=“xsd:dateTime”&gt;                &lt;xsd:mininclusive value=“2001-01-            01T00:00:00”/&gt;                &lt;/xsd:restriction&gt;                &lt;/xsd:simpleType&gt;                &lt;/xsd:attribute&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;                &lt;/xsd:sequence&gt;           &lt;xsd:attribute name=“mode” use=“required”&gt;                &lt;xsd:simpleType&gt;                &lt;xsd:restriction base=“xsd:string”&gt;                &lt;xsd:enumeration value=“replace”/&gt;           &lt;xsd:enumeration value=“append”/&gt;                &lt;/xsd:restriction&gt;                &lt;/xsd:simpleType&gt;                &lt;/xsd:attribute&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;                &lt;/xsd:all&gt;                &lt;/xsd:complexType&gt;                &lt;/xsd:element&gt;                      
 
         [0086]     For the broadcast subschema variant, the most important information that the scheduler section conveys is the schedule itself. This defines which events happen to named modules at what time.  
         [0087]     For the configuration subschema variant, the schedule element will define what events are to be fired on which objects at which time.  
         [0088]     The plugin module subschemas will follow a similar pattern as the existing host, communications and scheduler subschemas.  
         [0089]     In the following section, examples are given of documents structured in accordance with the schemas defined above. Firstly an example of a broadcast document:  
                                                                                                                                                                                                                                                                                                                           BROADCAST DOCUMENT                                    &lt;?xml version=“1.0” encoding=“UTF-8”?&gt;            &lt;mab:broadcast xmlns:mab=“monactive:agent:broadcast”                xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”           xsi:schemaLocation=“monactive:agent:broadcast            E:\ss\proj\martini\wrapper\broadcast.xsd”                checksum=‘01234567’&gt;                &lt;mab:shared&gt;                &lt;section title=“path”&gt;                &lt;heir id=“p1” string=“c:\wibble\wobble”/&gt;           &lt;heir id=“p2” string=“c:\wibble\wibble”/&gt;                &lt;/section&gt;           &lt;section title=“file”&gt;                &lt;entry id=“f1” string=“file1.exe”/&gt;           &lt;entry id=“f2” string=“file2.exe”/&gt;                &lt;/section&gt;           &lt;section title=“apps”&gt;                &lt;rel id=“a1” ids=“p2 f1” string=“groovy program”/&gt;           &lt;rel id=“a2” ids=“p1 f2” string=“another groovy program”/&gt;                &lt;/section&gt;                &lt;/mab:shared&gt;           &lt;mab:host&gt;                &lt;upgrade&gt;                &lt;module name=‘comms’ type=‘comms’ remote_filename=‘abc.def’            local_filename=‘macomms.dll’&gt;                &lt;/upgrade&gt;           &lt;run mode=‘replace’&gt;                &lt;module name=“citrix”/&gt;                &lt;/run&gt;                &lt;/mab:host&gt;           &lt;mac:comms&gt;                &lt;utcserver&gt;hogthrob&lt;/utcserver&gt;                &lt;/mac:comms&gt;           &lt;mab:scheduler&gt;                &lt;schedule mode=‘replace’&gt;                &lt;at when=“+15” lastranutc=“2001-01-01T00:00:00”&gt;                &lt;module name=“citrix” event=“checksessions”/&gt;                &lt;/at&gt;                &lt;/schedule&gt;                &lt;/mab:scheduler&gt;            &lt;/mab:broadcast&gt;                  
 
         [0090]     Next, an example of a configuration document:  
                                                                                                                                                                                                                                                                   CONFIGURATION DOCUMENT                                    &lt;?xml version=“1.0” encoding=“UTF-8”?&gt;            &lt;mac:config xmlns:mac=“monactive:agent:config”                xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”           xsi:schemaLocation=“monactive:agent:config E:\ss\proj\martini\wrapper\config.xsd”           checksum=‘01234567’&gt;                &lt;mac:shared&gt;                &lt;section title=“path”&gt;                &lt;heir id=“p1” string=“c:\wibble\wobble”/&gt;                &lt;heir id=“p2” string=“c:\wibble\wibble”/&gt;                &lt;/section&gt;           &lt;section title=“file”&gt;                &lt;entry id=“f1” string=“file1.exe”/&gt;                &lt;entry id=“f2” string=“file2.exe”/&gt;                &lt;/section&gt;           &lt;section title=“apps”&gt;                &lt;rel id=“a1” ids=“p2 f1” string=“groovy program”/&gt;           &lt;rel id=“a2” ids=“p1 f2” string=“another groovy program”/&gt;                &lt;/section&gt;                &lt;/mac:shared&gt;           &lt;mac:host/&gt;           &lt;mac:comms&gt;                &lt;utcserver&gt;hogthrob&lt;/utcserver&gt;           &lt;broadcast general-modified-at=‘2001-11-14T11:23’ specific-modified-at=‘2001-11-            14T11:23’/&gt;                &lt;/mac:comms&gt;           &lt;mac:scheduler&gt;                &lt;schedule&gt;                &lt;at when=“+15” lastranutc=“2001-01-01T00:00:00”&gt;                &lt;module name=“citrix” event=“checksessions”/&gt;                &lt;/at&gt;                &lt;/schedule&gt;                &lt;/mac:scheduler&gt;            &lt;/mac:config&gt;                  
 
         [0091]     Next, an example of a session document:  
                                                                                                                                                                                                                 SESSION DOCUMENT                                    &lt;?xml version=“1.0” encoding=“UTF-8”?&gt;            &lt;mas:session xmlns:mas=“monactive:agent:session”                xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”           xsi:schemaLocation=“monactive:agent:session E:\ss\proj\martini\wrapper\session.xsd”           checksum=‘01234567’&gt;                &lt;mas:shared&gt;                &lt;section title=“path”&gt;                &lt;heir id=“p1” string=“c:\wibble\wobble”/&gt;           &lt;heir id=“p2” string=“c:\wibble\wibble”/&gt;                &lt;/section&gt;           &lt;section title=“file”&gt;                &lt;entry id=“f1” string=“file1.exe”/&gt;           &lt;entry id=“f2” string=“file2.exe”/&gt;                &lt;/section&gt;           &lt;section title=“apps”&gt;                &lt;rel id=“a1” ids=“p2 f1” string=“groovy program”/&gt;           &lt;rel id=“a2” ids=“p1 f2” string=“another groovy program”/&gt;                &lt;/section&gt;                &lt;/mas:shared&gt;                &lt;mas:session mas:from=‘2002-02-10T12:00:00’ mas:to=‘2002-02-10T13:00:00’&gt;                &lt;mas:host&gt;                &lt;pc domain=‘wibble’ hostname=‘wobble’ ip=‘123.321.231.312’            mac=‘a9b98ed8c729f9d8c’/&gt;                &lt;/mas:host&gt;                &lt;/mas:session&gt;            &lt;/mas:session&gt;                  
 
         [0092]     Whilst the above description gives specific examples of embodiments of the invention, it should be noted that the invention is not limited to the embodiments of the invention set out above; further embodiments of the invention are envisaged. For example, in addition to or instead of the monitoring functions described, agent modules may conduct control functions in relation to the user stations, namely instead of passively monitoring the functioning of the user station, the modules may be used to install user software, alter settings, remove undesirable software, etc. on the user station.  
         [0093]     Note also, that whilst the above described embodiment uses the XML standard to structure documents, other forms of structuring files or documents may also be used. For example, a proprietary structuring format may be used in place of the XML standard.  
         [0094]     Further modifications are also envisaged which fall within the scope of the invention, as set out in the accompanying claims.