GB2388214A - Updating a monitoring agent using a structured document - Google Patents

Abstract

A method of updating an agent in a monitoring system for a computer comprises parsing a structured document consisting of several distinct data portions relating to modules within the monitoring agent and retrieving for each module a sub schema for updating the module. Each agent comprises a host module, 20, which receives the document through a communications module, 22, and is in connection with a plurality of plugin modules 28, 30 and 32. A scheduler module, 26 is also provided in order to schedule monitoring tasks undertaken by the plugin modules. The document may be in a markup language such as XML. The document may be provided across a network either from a common device or from one of a plurality of similar devices. The document may contain configuration or installation information for modules within the agent. The process of parsing the document may use a further schema to validate the contents.

Description

t Monitoring System for General-Purpose Computers This invention relates

to a monitoring system for general-purpose 5 computers, such as computer workstations and servers, connected via a data communications network to common resources.

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 10 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 15 software resources within the network are operating correctly, being used effectively, and within a set of more or less formal rules for network resource utilization. Network resource utilisation may for example be monitored to ensure that the appropriate software licences are in place and that unauthorized software is not being used on the network. It is useful to a 20 network manager to be able to monitor network resource utilization from a remote terminal, without having to monitor the activities at each workstation separately. Systems for remotely monitoring network resource utilization are known. US patent 5,987,135 describes a system and method for controlling 25 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 30 control tasks, such as determining which applications are run, determine the version of installed software and current software fixes, etc.

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. There is therefore typically a need to reduce the amount of 5 monitoring carried out; by making this compromise the impact on the network resources is reduced below an acceptable level. However, the accuracy and completeness of the monitoring process is thereby affected.

It would be desirable to provide a network resource utilisation monitoring system that has the ability to collect and process large amounts of 10 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 I S of customised monitoring modules to such a system.

In accordance with the present invention there is provided a method of monitoring resources on one or more general purpose computers, said method comprising providing a host data processing module and adaptively updating the host module with one or more optional data processing modules, 20 the method comprising processing a document comprising a plurality of separate data portions, said data portions being intended for processing by different data processing modules, the method comprising parsing the document using a schema for validating the contents of the document, wherein the method comprises retrieving, for each of said one or more 25 additional data processing modules, a sub- schema, and building said schema using each said sub-schemes.

The present invention therefore provides a method of carrying out processing of documents used for example for configuration, control and data transfer in the monitoring system. The method provides for an adaptable set of 30 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 utilization, and providing for increased security and reliability. The addition of monitoring functions within the system is furthermore relatively simple.

Further objects, advantages and features of the invention will be 5 apparent from the following more particular description of preferred

embodiments of the invention, as illustrated in the accompanying drawings, in which: Figure 1 is a schematic illustration of components of a network monitoring system, in accordance with an embodiment of the invention; 10 Figure 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; Figure 3 is a schematic illustration of software modules for a general purpose computer and a control console in accordance with an embodiment of 15 the invention; Figure 4 is a flow diagram showing processing carried out during document processing in accordance with an embodiment of the invention; Figure 5 is a schematic illustration of a first type of schema built in accordance with an embodiment of the invention; and 20 Figure 6 is a schematic illustration of a second type of schema built in accordance with an embodiment of the invention.

Referring now to Figure 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 25 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.

The general purpose computers, referred to hereinafter as user stations, may be in the form of conventional personal computers running applications 30 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 5 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 initialization 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 10 monitoring agent 3, 5, 7 installed thereon, to be described below in further detail. 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 15 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 20 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 25 to generate summary reports derived from the monitoring data using in-built

processing, manipulation and reporting functions.

Each monitoring agent 3, 5 7 includes a plurality of components, of which relevant components are shown in Figure 2. An agent host object 20 has a coordinating function, whereby documents containing data to be shared 30 between other modules of the agent is processed and distributed, and whereby data is 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 S module 26 take 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 10 first plugin monitoring module 28 carries out specified monitoring tasks relating to usage of 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 usage of the user software applications installed on the user station, under the control of 15 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. Such a third plugin monitoring module may be used for what it referred to as a software audit, namely for detecting and recording software applications installed on the user station.

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 25 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 30 added, or removed, at a time after installation of the monitoring software platform as and when desired by the network administrator.

( 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 5 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 10 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 15 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).

Figure 3 illustrates several of the agent modules 20, 22, 26, 28, along 20 with counterpart modules 34, 36, 38, 40 installed in the console. The console modules include a console host object 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 25 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.

Each agent module 20, 22, 26, 28 includes a software code part, 30 labelled 20a; 22a; etc., defining the functions carried out by the module when executed, and schema portions, respectively label led 20b, 20c, 20d; 22b, 22c, 22d; etc., whereby 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 20b, 22b, etc., configuration document schema portions, labelled 20c, 22c, etc., and session document schema portions, labelled 20d, 22d, etc. 5 Each console module 34, 36, 38, 40 includes a software code part, labelled 34a; 36a; etc., defining the functions carried out by the module when executed, and schema portions, respectively labelled 34b, 34d; 36b, 36d; etc., whereby the console host 34 performs validation of documents when received for processing thereby, as will be described in further detail below. The 10 schema portions include broadcast document schema portions, labelled 34b, 36b, etc., and session document schema portions, labelled 34d, 36d, etc. The schema portions 20b, 20c, 20d and 34b, 34d 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 15 document received by the respective host. A schema is built using the schema wrapper of the appropriate type along with sub-schemes, which are inserted into the schema wrapper, of the appropriate type. These subschemes are the schema portions 22b, 22c, 22d; etc., and 36b, 36d, etc. stored in the remaining agent modules. Thus, when a new plugin module is installed in a monitoring 20 agent, along with the counterpart plugin module in the console, the appropriate sub-schemes 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.

25 In order to add a new plugin to any agent monitoring system, the network administrator selects the appropriate plugin module addition function on the console side, and the plugin is sent to the appropriate agent monitoring system as a software update which is processed by the agent host 20. On receiving a new software update, the agent host validates the file and stores 30 the plugin in a data store, such as a hard drive, on the computer. A corresponding entry, along with an identifier allowing the plugin module to be launched, is written to the user station's registry for subsequent lookup.

Figure 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 to the console). It should be appreciated that the description hereof also applies to

5 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. Firstly in step 100, the document is received. The document may be received over the network interface or from a local function.

In order to retrieve the sub-schemes, the agent host 20 first queries the 10 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, and proceeds to initialise all monitoring platform modules that are not currently running in the user station, step 102, and queries the respective modules in turn, step 104. Generally, the communications module 22 and the 15 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. After 20 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. Once all the required sub-schemes have been retrieved, the agent host 20 uses the schema wrapper, along with a shared area sub-schema, which is to be described below and which may also be held by 25 the agent host, to structure and build a scheme containing each respective subschema, step 106. The sub-schemes from each module are placed in a predetermined part of the wrapper in the order in which the module identities are retrieved from the registry. Other predetermined ordering of the subschema entries, such as alphabetical ordering, etc. may also be used. Thus, 30 although the wrapper schema does not include actual identifying information B for each plugin module, the final schema is built using input from each of the plugin modules in turn. Once the schema is built, the agent host 20 stores the

( schema in memory. To validate a document, the agent host 20 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. On validation of the document contents, the various different document portions 5 are distributed to the respected agent modules, step 1 10. A similar process is carried out by the console host 34 in building up schemes for processing documents received from agent hosts across the network. Note that the schema building process may be carried out whenever a document is to be processed. More preferably, any required schemes as built on startup of the 10 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.

The eXtensible Mark-up Language (XML) format is used to structure all data sent to and from the console to any monitoring agents and for any temporary data the agents may store locally. XML provides the ability to 15 validate a document against its structure, so allowing the modules to work with the data effectively, without needing to check whether it is correctly formatted before it is used.

This validation is performed using an XML schema, which is an XML document that describes structure. The XML Schema standard, which is 20 incorporated herein by reference, is a working draft of the W3C Schema Working Group, and a description thereof can be found in the document

"XML Schema: Formal Description", W3C Working Draft, 20 March 2001.

A copy can be found at http://www.w3.org/TR/2001/WD-xmlschema-formal 20010320/. For an XML document instance to be validated it must inform the 25 reader which schema should be used. Then the reader will compare every node and leaf of the XML document instance against the XML schema to ensure validity. For the purpose of validating with a given XML schema, an XML reader such as Microsoft_ XML parser version 4.0 may be used.

in this embodiment, there are various parts of the system where data is 30 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 they share the same schema. XML documents sent across the network are compressed and encrypted to increase network transmission speeds and 5 security. In XML documents, elements (or tags) in the documents generally have the form: <name>.. </name The content of the tag is between the 'a' and the '<'. If no content is 10 required, then the end tag can be omitted if the shorten form is used (the second example).

Attributes appear inside the opening tag brackets, thus for example: <:name attribute1='value1'attribute2='value2'.. >... </:name> Generally attributes have string values, but they can have dates, times, 15 or any form, and they can be validated by the XML schemes used.

Element names reside in namespaces. If a tag comes from a particular namespace rather than the default then it may be used as follows: <namespace:name... </namespace:name> In order to use a namespace the namespace has to be declared. There 20 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. The special attribute is "xmins" and is used as follows: canytag... xmins:nnn='mmm'... > 25 where mmm' is the full name of the namespace and 'non' is a shortened namespace name that is used within a document instance to indicate which XML Schema an element belongs to. The 'non' part can be null, in which case the schema is opened up into the default namespace.

A namespace is a logical area in which element and attribute 30 identifiers reside. The identifiers within a namespace must be unique.

Then the next significant line will usually determine what the content of the file is. In the case of an XML schema this line may be as follows: <xsd:schema targetNamespace=monactive:agent:broadcast.

xmins=monactive:agent:broadcast. xmins:xsd =.http:/lwwv.w3.org/200 1 /XMLSchema.> </xml:schema> In any XML document, 'xmins' attributes can be applied to any tag, 5 meaning that from this point on in the XML document, the associated namespace applies.

To allow the description of XML Schemas, the XML standard defines

a standard schema that controls the structure of an XML schema document. In order to use that schema in a document, the document contents must request 10 the namespace to be made available. This is achieved using the directive: xmins:xsd=.http://vv.w3.org/2001/XMLSchema This directive firstly requests the use of a namespace (xmins), and states that it is to be aliased as the 'xsd' (:xsd) namespace, and that the namespace is called 'http://www.w3.org/2001/XMESchema'. This is a URI ( 15 Uniform Resource Identifier). It is the name of the standard schema. By including this schema into the namespace, further schemes may be defined using standard tags that will be understood by an XML compliant engine and interpret the file as an XML schema file.

If schemes are kept in their own namespaces then the tag names will 20 not clash, otherwise, similar tag names in the same namespace could cause a conflict; which tends to be irresolvable.

Usage of Demons' informs the parser that the document includes a further schema in addition, for example: xmins=.monacbve:agent:broadcast 25 Here the word 'monacUve' is at the root of a namespace tree used in this embodiment of the invention. The second level indicates that the entity using the schema is to be a monitoring agent, hence the second level of 'agent,'.

Then within the agent namespace the schema name includes the use for which the monitoring agent is going to put the document. In this embodiment there 30 are three uses; broadcast, configuration and session, i.e. 'broadcast', 'config' and 'session'.

Thus, in this embodiment we define three namespaces: monactive: agent: broadcast monactive:agent:conhg

monactve:agent:se55ions Thus the top-level tag and the attributes associated with it in an exemplary document is: xsd:schema targetNamespace=-monactive:agent:broadcasr... > 5... </xsd:schema The 'schema' tag from the 'xsd' namespace, with a "targetNamespace" attribute with the value 'monactive:agent:broadcast' is a tag that informs the XML parser that an XML schema is being defined, and that the name of the schema is specified in attribute "targetNamespace."

10 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, so that a module can change its own portion of a schema and no other module knows or relies on anything inside it. In order to 15 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 then 'sub-schemes' which each module defines individually given a set of rules.

There are two general forms for the schemes used, namely "flat" and 20 "block" structured.

Figure 5 illustrates the "flat" structured schema in one embodiment once built by the agent host 20 or the console host 34. The configuration and broadcast document schemes follow this general form. The structure of the built schema includes a top level part 200 derived from a broadcast or config 25 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 30 in Figure 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.

f Figure 6 illustrates the 'block" structured schema in one embodiment once built 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 5 to the agent host, and the agent host will gather up these module sessions into one agent session, essentially grouped by 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 was collected. The structure of the built schema includes a top level part 300 derived from a session wrapper schema. The next 10 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 15 plugin parts 312 (only one is shown in Figure 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.

The following section gives examples of broadcast, configuration and 20 session wrapper schemes. The short namespace aliases used are "mab", "mac" and"mas", respectively.

First, an example of a broadcast wrapper schema: . c?xml version=1.0. encoding=.UTF-8?> 25 Cxsd:schema targetNamespace=. monactive:agent:broadcasr xmins=.monactive: agent: broadcast.

xmins:xsd=http:/lvrww w3.org/2001/XMLSchema.> cXsd ele me nt n a me =. broad cast-> <xsd:complexType> 30 cxsd:all> <xsd:element ref--.shared.minOccurs=1. axOccurs=1/> <xsd:element ref=.hosr minOccurs=1 maxOccurs=1/> cXsd element ref=-comms. minOccurs=1. maxOccurs=1/> cxsd:element ref=. scheduler minOccurs=1' maxOccurs=1/> 35..

f </xsd:all> <xsd:attribute name=.checksum use=-required> cxsd:simpleType> <xsd:restriction base=.xsd:string.> 5 <xsd:pattern value=[0-9A-Fl{8}/> </xsd:restriction> c/xsd:simpleType> c/xsd attribute> c/xsd:complexType 1 0 c/xsd:element chsd:schema Note that the element ref section in the middle of the above has the 15 ellipsis. This section is assembled by the agent or console host polling all the remaining plugin modules. The same applies in relation to each of the configuration and session wrapper schemes.

Next, an example of a configuration wrapper schema: 20 = =

<xsd:schema targetNamespace=.monactive:agent:config.

xmins=-monactve:agent:config. xmins:xsd=.http:/lwww.w3.orgl2001/XMLSchema. > cXsd:element name=.config.> 25 <xsd:complexType> <xsd:all> cXsd:element ref=.shared minOccurs=0- maxOccurs=1/> <xsd:element ref=-hosr minOccurs=0 maxOccurs=11> cxsd:eiement ref=comms. minOccurs=0. maxOccurs=1.P 3 0 <xsd:element ref=.scheduler. minOccurs=0 maxOccurs=11> <Ixsd:all> cxsd:attribute name=.checksum. use=.required.> cxsd:simpleType> 3 5 <xsd:restriction base=-xsd:string.> <xsd:pattern value=[0-9A-F]8/> c/Xsd:restriction> Vxsd:simpleTyPe> clxsd:attribute> 40 <Ixsd:complexType> <Ixsd:element c/xsd:schema>

( Next, an example of a session wrapper schema: <?xmi version=1.0. encoding=-UTF-8"?> 5 cxsd:schema targetNamespace="monactive:agent:sessions" xmins=monactive:agent:sessions" mins:xsd=http://www.w3. org/2001/XMLSchema"> <xsd:attribute name=.from. type='xsd:dateTime'/> 10 <xsd:attribute name=to. type='xsd:dateTime't> <xsd:element name=. sessions> cxsd:complexType> <xsd:choice minOccurs='0'maxOccurs='unbounded'> 15 <xsd:element ref=-shared" minOccurs=0/> <xsd:element ref=session minOccu rs=0 maxOccurs=-un bounded"/> </xsd:choice> <xsd:attribute name="checksum use=.required-> <xsd:simpleType> 20 <xsd:restriction base=xsd:string> cXsd:pattem value=10-9A-Fl{8}/> </xsd:restriction> </xsd:simpleType> </xsd:attnbute> 25 </xsd:complexType> </xsd:element> <xsd: e lem en t n a m e='sess ion '> <xsd:complexType> 30 <xsd:choice minOccurs='0'maxOccurs='unbounded'> <xsd:element ref=.host" minOccurs=0. maxOccurs=unbounded-/> <xsd:element ref="comms. minOccurs="0- maxOccurs="unbounded/> <xsd,element ref=scheduler minOccurs=0. maxOccurs=.unbounded/> 3 5 </xsd:choice> cXsd attribute ref=.from. use=.required/> <xsd:attribute ref=.to. use="opbonal. /> </xsd:complexType> c/xsd:element> 40.. c/x5d:schema> All the wrapper schemes above refer to a shared area into which standard form data can be stored. 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. 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 5 connected together using the "id" and a parent id ("pid").

The following section gives an example of a shared subschema: c! shared subschema for any ancestor --> <xsd:element name=shared-> 10 cxsd:cornplexType> cXsd:sequence> cxsd:element ref='sectiont minOccurs=0maxOccurs=-unbounded/> clxsd:sequence> </xsd:complexType> I S c/xSd:element> cXsd e le me n t name =.section"> <xsd:complexType> <xsd:choice> 20 cxsd:element name=-entry maxOccurs="unbounded"> <xsd:complexType> cXsd attribute name="id" type="xsd:lD"/> cxsd:attribute name=.string. type=-xsd:string./> c/xsd:complexType> 2 5 </xsd:element> cXsd element name=-heir. maxOccurs="unbounded> cXSd:complexType> <xsd:attribute name=id type=-xsd: l D"/> cxsd:attribute name =.pid. typexsd:string. defau lt='-'/> 30 cXsd attribute name=-string" type=. xsd:string/> </xsd:complexType> </xsd:element> <xsd:element name=-rel" maxOccurs=unbounded.> <xsd:complexType> 35 cxsd:attribute name=.id. type=. xsd:lD use=.required"/> cxsd:attribute name=.ids. type=-xsd:lDREFS. use=. requiredl> cxsd: attribute name=.string" type="xsd:string. use=optional./> c/xsd:complexType> c/XSd element> 40 </xsd:choice> cXsd attribute name="title. type="xsd:string. use=.required./> cxsd:attribute name-nextid. type="xsd:string. use=.optional"/> cXsd attribute name=divider type=.xsd:string" use="optional-/> </xsd:complexType>

( c/xsd:element> In the shared subschema, "entry" tags allow storage of a simple string of text associated with an "id" that may be referred to later in the document, 5 "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 "ret" 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.

lo The following section gives examples of sub-schemes stored by the agent host module. Firstly, an example of a broadcast sub-schema: cxsd:element name=.host.> I 5 cxsd:complexType> <xsd:all> cXsd element name="upgrade minOccurs=0- maxOccurs='1'> Axed:complexTYPe> cXsd:sequence> 20 <xsd:element name=module"> cxsd:complexType> cXsd attribute name="type use="required.> cxsd simple Type> cxsd:restriction base=-xsd Estrange> 25 cXsd enumeration value="exe-/> cXSd:enumeration value="service-/> cXsd:enumeration value=-host./> cXsd enumeration value=- comms./> <xsd:enumeration value="plugin"/> 30 c/xSd restriction> c/xsd:simpieType> </xsd:attribute> <xsd:attribute name=.name. type=xsd:string. use=-required-/> <xsd:attri bute name ="remote_fi renamed type=xsd:string.

3 5 use="required./> Axed:attribu te name =loca l_filena me" type=. xsd:string.

use=.required"/> </xsd:complexType> </xsd:element> 40 </xsd:sequence> </xsd: complexType>

Vxsd:element> </xsd:all c/xSd complexType> </xsd:element> s 1, 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 which sub-schemes to include in a newly built schema), where they 10 are located (remote_fiename) and what they should be called locally (local_filename). Next, an example of a session subschema: I 5 cXsd element name="host> cxsd:complexType> <xsd:all> c/xsd:all> </xsd:complexType> 20 </xsd:element> In the following section, examples are given of communications module sub-schemes. First, an example of a broadcast subschema: cXsd:element name=.comms-> cxsd:complexType> cxsd all> cXsd:element name='utcserver'> 30 xsd:simpleType> cXsd restriction base='xsd:stnng'> cxsd:pattem value=([0-9]{1, 3\.[0-9]{1,3\.10-9]{1. 3\. 10-9]1,3)1([a ZO-9_1[a ZO-9_.]+)/> </xsd:restriction> 3 5 c/xsd:simpleType> </xsd:element> c/x5d:all> c/xsd:complexType> c/xsd:element>?7?

( Next, an example of a configuration subschema: <xsd:element name="comms> 5 <xsd:complexType> <xsd:all> Cxsd:eiement name='utcserver'> <xsd:simpleType> <xsd:restriction base='xsd:string'> 10 <xsd:pattem value="([0-9]{1,3}\ [0-9]{1,3}\. 10-9]{1.3}\ [0-Ol{1,3})1([a ZO-9 [a ZO-9. |+)/> </xsd:restriction> </xsd:simpleType> </xsd;element> 15 <xsd:element name='broadcast'> <xsd:complexType> <xsd:attribute name='general-modifiedat' type='xsd:datetime'/> <xsd:attribute name='specific-modifiedat'type='xsd:datetime'/> </xsd:complexType> 20 </xsd:element> </xsd:all> </xsd:complexType> </xsd:element>??? 25 Next, an example of a session subschema: <xsd:element name=-comms-> <xsd:complexType> <xsd:all/> 30 | <xsd:attribute name='from'type='xsd:dateTime'/> <xsd:attribute name='to' type-'xsd:dateTime'/> </xsd:complexType> </xsd:element 35 In the following section, an example of a general form and specifc sub- schema variants are given of scheduler module sub-schemes.

Firstly an example of the general form is as follows: <xsd:element name=. scheduler.> 40 <xsd:complexType> cxsd:all> xsd:element name=.schedule>

<xsd;complexType> cXsd sequence> <xsd:element name=at. minOccurs=0. maxOccurs="unbounded-> cxsd:complexType> 5 cxsd:sequence> <xsd:element name=-module.> cxsd:complexType> cxsd:attrdbute name=name type=.xsd:lDREF use=required-/> 10 <xsd:attribute name="event" type=-xsd:string" use =req ui red./> c/xSd:complexType> c/xsd:element> c/xsd:5equence> 15 cXsd attribute name=.when. use=.required.> cxsd:simpleType> cXsd:restriction base=-xsd:string.> <xsd:pattern value= [!+](20[0-9]{2})?([01][0-9'1)?t[o1 23]10-9*])?([0 20 2][0-9'])?([0-9][0-9])?U?/>

c/xsd: restriction > Vxsd:simpleType> c/xsd:attribute> cxsd:aHribute name=.lastranutc. use=optional. default=2001-01 25 01T00:00:00>

cxsd:simpleType> <xsd:restriction base=.xsd:dateTime.> cXsd: minindusive value=200 1-01 01T00:00:00 />

30 Vxsd:restriction> Vxsd:simpleType> </xsd:attribute> c/xsd:complexType> c/xsd:element> 35 </xsd:sequence> cXsd attribute name=mode use=-required.> cxsd:simpleType> cXsd restriction base='xsd:string> <xsd:enumeration value=-replace./> 40 cXsd:enumeration value=.append/> c/xsd:restriction> c/xsd:simpleType> Vxsd:attribute> Vxsd:complexType> 45 c/Xsd:element> Vxsd:all>

( c/xsd:complexType> c/xsd:element> - For the broadcast sub-schema variant, the most important information 5 the scheduler section conveys is the schedule itself. This describes what events happen to named modules at what time.

For the configuration sub-schema variant, the schedule element will define what events are to be fired on which objects at which time.

The plugin module sub-schemes will follow a similar pattern as the 10 existing host, communications and scheduler modules.

In the following section, examples are given of documents structured in accordance with the schmemas defined above. Firstly an example of a broadcast document: 15 <?xmi version=1.0 encoding=.UTF-8?> <mab:broadcast xmins:mab=.monactive:agent:broadcast.

xmlns:xsi=.http://www.w3.org/2001 /XMLSchema-instance xsi:schemaLocation="monactive:agent:broadcast E:\ss\proj\rnartini\wrapper\broadcast.xsd" 20 checksum='01234567'> cmab shared> <section title=.path-> <heir id= p1- string=.c wibble\wobble-/> <heir id=-p2. string=.c:\wibble\wibble-/> 2 5 </section> <section title=file> <entry id=f1. string=file1.exe/> sentry id=.f2. string='file2. exe-/> </section> 30 <section title=apps.> <ret id=a1. ids=-p2 f1. string=.groovy program./> <rel id=-a2" ids=.p1 f2. string=.another groovy program-/> </section> c/m a b: 5 h a red > 35 <mab:host> upgrade> module name='comms'type='comms'remote_filename='abc.def' local_filename='macomms. dll'> </upgrade> 40 <run mode='replace'> <module name=.citrix/>

( </run> c/m a b: host> <mab:comms> cutcserver>hogthrobclutcserver> 5 </mab:comms> cmab:scheduler> cschedule mode='replace'> cat when=+15. lastranutc=200 1-01-01 TOO:OO:OO> cmodU name=.citrix" event="checksessions-/> I O Vat c/Schedule> Vmab:scheduler> c/mab:broadcast> 15 Next, an example of a configuration document: c?xml version="1.0. encoding="UTF-8?> cmac:config xmins:mac=monactive:agent:config. xmins:xsi="http://www.w3. orgl2001 /XMLSchema-instance.

2 0 xsi:schemaLocabon="monactive:agent:config E:\ss\proj\martini\wrapper\config.xsd checksum='01 234567'> cmac:5hared> cSecton title='path> <heir id="p1. sthng=-c:\wibble\wobble./> 25 chejr id="p2- string="c:\wibble\wibble-/> c/Section> cSection bUe=file-> centry id=.f1. string="file1.exe/> centrV id=f2. string="file2.exe./> 30 </section> <section title=.apps"> <rel id="a1- ids=.p2 f1. string=- groovy program'/> crel id="a2. ids="p1 f2" string=.another groovy program- /> Vsection> 3 5 </mac:shared> cm a c: host/> cmaC:comms> cutcserver> hoguhrobvutcserver> cbroadcast general-modified-at='2001-1 1-14T11:23' specific-modified-at='2001-11 40 1 4T 11:23'/>

Vmac:comms> cmac;scheduler> cSchedule> <at when=+ 15" lastranutc=200 1-0101 TOO:OO:OO.> 45 <module name=.citrix. event=.checksessions/>

<fat> </schedule> </mac:scheduler> </m ac: con fi g > Next, an example of a session document: <?xml version=1.0 encoding=UTF-8U7> <mas: sess i on xm i n s: ma s = I'm on a ctive: a g ant: ses stone 1 0 xmins:xsi=http://www.w3.org/2001 /XMLSchema-instance xsi:schemaLocation=monactive:agent:session E:\ss\proj\martini\wrapper\session.xsd.

checksum='01234567'> cmas:shared> <section title=path"> 15 <heir id=np1 string=c:\wibble\wobble-/> <heir id=.p2. string="c:\wibble\wibble-/> </section> <section title=file"> <entry id=-fl" string=file1.exe./> 20 Sentry id=.f2- string=file2 exe-/> </section> <section bte=.apps"> crel id=-a1. ids=p2 f1" string=groovy program-/> <rel id=-a2- ids=np1 f2 string=.another groovy program./> 25 </section> </mas:shared> <mas:session mas:from='2002-02-1 OT12:00:00' mas:to='2002-02-1 OT13:00:00'> <mas:host> <pc domain='wibble' hostname='wobblet ip='123.321. 231.312' 30 mac='a9b98ed8c729f9d8c'/> </mas:host> c/maS:session> c/maS session> 35 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 40 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.

Note also, that whilst the above described embodiment uses the XML standard to structure documents, other forms of structuring files or documents 5 may also be used. For example, a proprietary structuring format may be used in place of the XML standard. The term "document" as used herein is intended to include data files and data streams.

Further modifications are also envisaged which fall within the scope of the invention, as set out in the accompanying claims.

Claims (20)

Claims

1. A method of monitoring resources on one or more general purpose computers, said method comprising providing a host data processing S module and adaptively updating the host module with one or more optional data processing modules, the method comprising processing a document comprising a plurality of separate data portions, said data portions being intended for processing by different data processing modules, the method comprising parsing the document using a schema for validating the contents 10 of the document, wherein the method comprises retrieving, for each of said one or more additional data processing modules, a sub-schema, and building said schema using each said sub- schemes.

2. A method according to claim 1, comprising holding a wrapper IS schema, and building said schema using a structure specified by said wrapper schema.

3. A method according to claim 1 or 2, wherein said document includes a schema reference whereby said schema is identified during the 20 parsing of the document.

4. A method according to claim 1 or 2, wherein said document is a mark-up structured document.

25

5. A method according to any preceding claim, comprising holding said sub-schemes in association with said data processing modules, and retrieving said sub-schemes by reference to said data processing modules.

6. A method according to any preceding claim, comprising 30 receiving said document from a data processing device across a data communications network.

7. A method according to claim 6, comprising receiving said document from a common processing device at one of a plurality of similar data processing devices in the network.

5

8. A method according to claim 7, comprising receiving said document at each of said plurality of similar data processing devices and processing the document in each of said similar data processing devices.

9. A method according to claim 7 or 8, wherein said document 10 comprises configuration data for configuring the operating parameters of one or more of said plurality of modules.

10. A method according to claim 7, 8 or 9, wherein said document comprises a data relating to a new data processing module to be installed on 15 said one or more similar data processing devices.

11. A method according to claim 10, comprising installing said new data processing module on said one or more similar data processing devices.

1 2. A method according to claim 11, comprising receiving a further document comprising a plurality of separate data portions, said data portions being intended for processing by different data processing modules including said new data processing module, the method comprising parsing 25 the document using a further schema for validating the contents of the further document, wherein the method comprises retrieving, for said new data processing module, a new sub-schema, and building said further schema using said new sub-schema.

30

13. A method according to claim 6, comprising receiving said document from one of a plurality of similar data processing devices at a common processing device.

(

14. A method according to claim 13, comprising generating a report including data from each of said similar data processing devices.

5

15. A method according to any of claims 1 to 5, comprising processing said document at a data processing device, and retrieving said document from storage local to said data processing device.

16. A method according to any preceding claim, wherein said data 10 processing modules comprise one or more modules for monitoring usage of software resources in a data processing system.

17. A method according to any preceding claim, wherein said data processing modules comprise one or more modules for monitoring usage of 15 hardware resources in a data processing system.

18. A method according to any preceding claim, wherein said data processing modules comprise one or more modules for detecting and recording software applications installed in a data processing system.

19. Computer software adapted to carry out the method of any preceding claim.

20. A data processing system adapted to carry out the method of 25 any ofclaims I tol8.