GB2432234A

GB2432234A - Networked data storage system

Info

Publication number: GB2432234A
Application number: GB0522768A
Authority: GB
Inventors: Mark Emerson; Rurik Turton
Original assignee: XYNCHRON Ltd
Current assignee: XYNCHRON Ltd
Priority date: 2005-11-09
Filing date: 2005-11-09
Publication date: 2007-05-16
Also published as: GB0522768D0

Abstract

A networked data storage system comprising a plurality of servers and a plurality of data sets respectively accessible by said servers, wherein each server is configured such that, in response to a request for access to data from a client, if the data is not in its respective data set, the server sends a request for access to the data to another server. Preferably the requests are sent in XML format.

Description

Networked data storage system

Description

The present invention relates to networked data storage system.

One of the main reasons for networking computers is to enable a plurality of computers to share a file system. In such a system, client computers mount remote file systems using protocols such as Server Message Block (SMB) and Network File System (NFS).

The present invention seeks to provide an improved networked data storage system.

According to first aspect of the present invention there is provided a networked data storage system comprising a plurality of servers and a plurality of sets of data respectively accessible by said servers, wherein each server is configured such that, in response to a request for access to data from a client, if the data is not in its respective data set, the server sends a request for access to the data to another server.

Consequently, the data accessible via a particular server is expanded and data can be transferred between servers transparently. Thus, data can be navigated independently of the physical location of data and does not require any knowledge of where the data is located.

The request may include an identifier for identifying data in a data set and each server may be configured to determine whether the data identified in the request is in the data set accessible by said server. Each server may be configured to process a Hypertext Transfer Protocol (HTTP) request received from the client and to prepare an HTTP response.

Each server may be configured to prepare a responseto the client which includes said data in eXtensible Markup Language (XML) format.

Case: PJP/48727GB1 This helps to provide flexibility in the manner in which data is handled while also preserving structure and relationship information.

Each server may be configured to receive a response from another server including said data and to prepare a response to the client which includes said data.

The system may further comprise a directory server. Each server may be configured such that, if the data is not in its respective data set, the server sends a request to the directory server for a list of servers which are accessible to said data set in which said data is included. Each data set may include at least one data object, each data object having a respective identifier. Allocation of the identifiers may be controlled by the directory server. The identifiers may be assigned by the directory server. A server may be configured to send a request for authorisation to use a given identifier and the directory server may be configured to determine whether the given identifier is available. The directory server may be configured to maintain a list of identifiers Each server may comprise means for processing the request from a client, meansfor providing a record of the data sets accessible to the server and means for interfacing with storage storing said data sets.

The request processing means may be configured to check whether the client is authotised. The request processing means may be configured to select an interfacing means from a plurality of interfacing means. The request processing means may be configured to update the record after the data has been accessed.

The record providing means may be configured to store a list of accessible data set.

The record providing means may be configured to store data for accessing the accessible data set. The record providing means may be configured to store metadata for describing the accessible data set. The record providing means may be configured to store data for describing a status of the accessible data set.

Each data set may comprise at least one data object. The data object may include a reference to at least one other data object. The data object may be accessible to a first one of said servers and wherein said other data object may be accessible to a second one of said servers. At least some of said data sets may be stored in eXtensible Markup Language (XML) format. At least a first set of data may conform to a schema. At least a second set of data may conform to another, different schema.

The system may further comprise at least one client and the at least one client may configured to apply a schema to data and to transmit said data conforming to the schema to one of said servers.

According to a second aspect of the present invention there is provided a server having access to a set of data configured such that, in response to a request for access to data from a client, if the data is not in its data set, the server sends a request for access to the data to another server.

The data set may be stored on said server.

According to a third aspect of the present invention there is provided a server configured such that, in response to a request, from a client, to store data, said server is configured to send a request, to a directory server, to be authorised to use or to be assigned an identifier for said data and, in response to receiving authorisation or an identifier, to store said data and said identifier.

According to a fourth aspect of the present invention there is provided an object manager having access to a set of data configured such that, in response to a request for access to data from a client application, if the data is not in its data set, the server sends a request for access to the data to another object manager.

According to a fifth aspect of the present invention there is provided a directory server for providing a directory service to a plurality of servers, said directory serverconfigured to receive, from a server, a request to be authorised to use or to be assigned an identifier for identifying a data object, to transmit a authorisation or an identifier to the server and to store a list of identifiers.

According to a sixth aspect of the present invention there is provided a method in a data processing apparatus comprising receiving a request for access to data from a client, determining whether said data is in a data set, sending a request for access to the data to another server.

According to a seventh aspect of the present invention there is provided a computer program which, when executed by a data processing apparatus, causes the data processing apparatus to perform the method.

According to a eighth aspect of the present invention there is provided a computer readable medium storing thereon the computer program.

Embodiments of the present invention will now be described, by way of example, with reference to the accompanying drawings in which: Figure 1 is a schematic block diagram of an embodiment of a networked data storage system according to the present invention and clients connected to the system via a network; Figure 2 is a functional block diagram of the networked data storage system and clients shown in Figure 1; Figure 3 is an example of a data object; Figure 4 illustrates a request sent from a client to an object manager; Figure 5 illustrates a response sent from an object manager to a client; Figure 6 is a first example of index data object; Figure 7 is a second example of an index data object; Figure 8 is a functional block diagram of an object manager; Figure 9 illustrates data stored in a registry of the object manager shown in Figure 8; Figure 10 illustrates a record stored in the registry shown in Figure 9 for an object; Figure 11 illustrates, in more detail, a first part of the record shown in Figure 10; Figure 12 illustrates, in more detail, a second part of the record shown in Figure 10; Figure 13 illustrates, in more detail, a third part of the record shown in Figure 10; Figure 14 illustrates data stored in a directory; Figure 15 illustrates, in more detail, an entry for a server in the directory shown in Figure 14; Figure 16 is a process flow diagram of a method of storing object data; Figure 17 is a process flow diagram of a method of retrieving object data Figure 18 is process flow diagram of a method of processing a request for object data from another server; Figure 19 is a process flow diagram of a method of conducting a search; and Figure 20 is a schematic block diagram of the server shown in Figures 1 and 2.

Networked data stora,ge 1)/stem 1 Referring to Figure 1, an embodiment of a networked data storage system 1 in accordance with the present invention includes a plurality of server computers 2 (which may also be referred to simply as "servers") and a directory server computer 3 connected by a network 4. Preferably, the network 4 is the Internet. However, the network 4 may be an intranet. Client computers 5 (which may also be referred to simply as "clients") can access the networked data storage system 1, preferably via the network 4, although another, different network (not shown) may be used.

The servers 2 are geographically distributed.

Referring to Figure 2, each server computer 2 executes an object manager 6 for, among other things, storing, managing and retrieving data comprised in sets of data objects 7 (or other data container) for applications 8 executed by client computers 5. Each object manager 6 manages a given set of objects 7, hereinafter referred to as a "space". As will be described in more detail later, the objects 7 are transmitted, and preferably stored, in eXtensible Markup Language (XML) format, and are identified using a space identifier 21 (Figure 4) and an object identifier 22 (Figure 4) based on an XML schema. The directory server computer 3 executes a directory 9 providing a list of object managers 6 and their respective spaces. The directory server computer 3 also executes a directory administrator 10 for controlling the directory 9.

In this example, each data object 7 comprises a specification of a system, a sub-system and/or a piece of equipment, such as a water pump, comprised in the system or sub-system. The networked data storage system 1 can be used for storing files relating to an engineering project. An example of a data object 7, file 73, is shown in Figure 3. The file 73 is a datasheet including project data and site data. However, the project data and site data can be stored separately. A data object 7 may relate to apparatus (or equipment), people, organisations and abstract entities.

Communication between a first application 8 and a first object manager 6 will be given as an example of communication between any application 8 and any object manager 6.

The first application 8 sends a request 12 to the first object manager 6, for example to retrieve a first data object The first data object is uniquely identified and is identified, in part, by a space. If the first object manager 6 manages the first data object then it retrieves the first data object and sends a response 13, including the first data object 7, back to the first application 8.

Ef the request 12 is to retrieve a second data object 2 and the first object manager 6 does not manage the space for the second data object 2, then the first object manager 6 ascertains which other object manager 6 manages the second data object The first object manager 6 may send a request 14 for a list of object managers 6 for a given space to the directory 9. The directory 9 returns a list 15 of object managers 6 for the given space. In this case, a second object manager 62 manages the second data object The first object manager 6 sends a request 16 to the second object manager 62 to retrieve the data object The second object manager 62 retrieves the second data object and returns a response 17, including the second data object to the first object manager 6. The first object manager 61 sends response 13, including the first data ob)ect back to the first application 8.

Thus, although an application 8 addresses its request 12 for a uniquely identified data object 2 to one object manager 6, other object managers 6 can be used to retrieve the data object 2* Thus, the first object manager 6 serves as an agent for the application 8 within a peer-to-peer network.

Object managers 6 and applications 8 are configured to communicate according to a communication protocol, preferably Hypertext Transfer Protocol (HTTP).

Extensions to HTTP, such as Web-Distributing, Authoring and Versioning (WebDAV) protocols may be used.

The request 12 is handled at packet level, for example using Transmission Control Protocol/Internet Protocol (TCP/IP).

Request 12 Referring to Figure 4, the request 12 is preferably in the form of an HTTP POST.

The request 12 specifies a type of operation 18 to be preformed. Operations may include create a new object with data supplied by the application, write new data supplied by the application to an existing object, read an object with given identifier and return data to client, delete an existing object having a specific identifier, return an index of objects belonging to a given space or return a list of objects meeting specified query criteria. Other operations may be performed.

The request 12 may also specify one or more variables including user identification 19, object identification 20, in the form of a space identifier 21 and object identifier 22, data 23 to be stored, an object state 24 to be set by successful request, a number of levels of child objects to be returned by the request, a list of criteria 26 to be satisfied as part of a query and an instruction 27 as to whether to include remote parts of the system in a read or query. Other variables may be specified.

In a given period of time, an application 8 preferably addresses its requests 12 to a single object manager 6, such as the first object manager 6. However, in other periods of time, the application 8 may address its requests 12 to another object manager 6, for example the second object manager 62.

Requests 12 are addressed to object managers 6 using Internet Protocol (IP) network addresses. A port address may optionally be used. Object managers 6 monitor requests 12, process the requests 12 and sends corresponding responses 13.

Responses 13 Referring to Figure 5, the response 13 preferably complies with HTTP format and comprises a header 28 and, optionally, message content 29, for example: RTTP/1.1 Status-code Reason-phrase Content-type: text/xml; charsetISO-8859-4 Other headers as required by HTTP custom headers <?xml vereion="]..O" ?> <obj ect_root_element> The data for the object found c/obj ect_root_element > If the response 13 returns object data, then the message content 29 comprises object data in XML format. If the request 12 does not require the return of object data, then message content 29 is empty.

The header 28 may include an HITP status code for specifying a result of the request 12. The status code 30 may be:

-OK

201 -Success 401 -Access denied 403 -Invalid 404 -Not found 409 -Conflict 500 -Server error 501 -Requested invalid or not implemented The header 27 may also an error code 30, an error message 31, a version 32 of object, an identity 33 of a remote object manager that returned data and a state 34 of an object in the system.

As explained earlier, the object managers 6 send HTTP requests 12 and return HTTP responses 13. Therefore, the object managers 6 provide at least this function of a web server. Furthermore, object managers 6 may provide other functions of a web server. Preferably, the object managers 6 include the functions of a typical web server.

Data content The object managers 6 are intended to store data which are capable of being expressed in XML format, which conform to the general requirements imposed on XML formats and which are consistent with a set of XML schema descriptions.

Applications 8 and/or client computers 5 apply a schema to data. A single schema may be used, although plural schemas can be used and object managers 6 can store data conforming to different schemas.

XML schema provide a means for defining the structure, content and semantics of XML documents. In this example, the object managers 6 use data typing and namespace features of XML schema 1.1 and further details may be found on the World Wide Web Consortium website at www.3g.org.

The schema allows for the identification of data entities defined in separate files at a level of granularity appropriate to the domain covered by the schema. Typically these entities will correspond to objects in the real world, such as items of equipment, organisations, etc. and are referred to as data objects.

By an appropriate level of granularity, we mean that the data in the file fully specifies the entity for a given application.

The schema provides for a unique identifier 47 (Figure 11) for each data object 7.

These unique identifiers are qualified by a space identifier 48 (Figure 11) which places a data object 7 in a space or set of objects. An object identifier 49 (Figure 11) need only be unique within this space. The combination of a space and object identifier 48, 49 (Figure 11) is used when storing or retrieving objects and is used to record information relevant to each object.

-10 -The schema also provides for data objects to contain other data objects or to refer to other data objects by means of space and object identifier 48, 49 (Figure Ii). For example, in Figure 3, a reference 48, to another data object (not shown) is embedded in data object 73. This allows for a hierarchy of objects providing descendants to a given object. Such a hierarchy may express physical or logical relationships between objects or be used to organise data into a navigable tree structure.

The schema also provides a mechanism for lists or indexes of objects to be returned as self-contained XML documents.

Referring to Figure 6, an example of a data object 74 which provides an index is shown. The data object 74 serves, for example, to organise data into collections and to provide bookmarks. The data object 74 does not specify relationships between objects.

Referring to Figure 7, another example of a data object 7 which provides a relationship is shown. The data object 75 refers to an organization and gives the relationship a context, in this case, that of a contractor.

In this embodiment of the invention, a Capital Facilities Industry XML (cEIXML) schema, such as Approved Public Release v2.0 (19 July 2004), is used and reference is made to www.cfixml.org.

Object managers 6 Referring to Figure 8, each object manager 6 includes a core function 35 for, among other things, interpreting requests 12, performing data management and preparing responses 13, a registry 36 for storing information about data objects 7, a plurality of data access components 37 proving respective standard interfaces between the core function 35 and storage 38 and an administration function 39 for maintaining the object manager configuration and providing an administrator with a browser interface for configuring the object manager 6. -11 -

Each object manager 6 has its own registry 36 and no other object manager 6 may read or write data to that registry 36. The registry 36 is configured to record information about data objects 7 and how they are stored. The registry 36 is implemented as a table in a relational database (not shown) and can be queried using SQL or other relational tools.

Referring to Figure 9, the registry 36 stores a record 40 for each data object 7 and, optionally, a record 41 for each data object 7 contained within or referred to by another object 7. These objects 7 are referred to as "parent" and "child" objects respectively. The registry 36 also stores a list 42 of space identifiers used by the object manager 6. The registry 36 may also store a cached list 43 of object managers 7 for other spaces. As will be explained later, this can help to speed up retrieval of a data object 7 by avoiding the need to obtain a list from directory 9.

Referring to Figure 10, each record 41, 42 includes data 44 for accessing a data object 7, metadata 45 relating to the data object 7 for assisting in searches and administrative data 46 relating to the object.

Referring to Figure 11, the access data 44 includes an object identifier 47 which comprises a space identifier 48 and an object identifier 49, schema 50 and/or namespace within schema where a data object 7 is defined, a type 51 of object (as defined in schema), a version 52 of schema used to create or validate an object, an identify 53 of data access layer component used to store an object and thus to be used to retrieve the object, and a data access layer parameter 54.

In order to enhance queries and provide the ability to analyze rapidly overall object status, certain data fields are held in the registry 36 for each data object 7. These fields are those attributes of objects, as defined in the schema, which are common to all objects or major classes of objects.

Referring to Figure 12, the metadata 45 may include a name 55 of a data object 7, a description 56 of the data object 7 (usually provided by a user or application), an -12 -identification 57 of the function of the data object 7, a user-defined status 58 of the object (i.e. object status within a business process) and identification 59 of the software that created the data object 7.

Referring to Figure 13, the administrative data 46 includes a state 60 of the data object 7 for deterrriining which operations are permitted, such as normal (read/write), read-only and deleted, a number 61 of times the object has been updated, a date and optional time 62 when the object was last updated, a number 63 of times the data object 7 has been read and a date and option time 64 the object was last read.

The data access layer components 37 are used for retrieving, modifying or storing data objects 7 in storage 38. Each object manager 6 may have one or more of these components 37, forming a data access layer (not shown). Data objects 7 can be stored in different storage formats and in different media, including text files, relational database management systems, such as SQL server, MySQL and ORACLE, object-oriented or Native XML Databases and other proprietary database systems. Several data access layer component 37 may exist which use the same underlying mechanism. For example, two data access layer component 37 may both store data as text files, but each might use a different convention for naming or creating the text files.

There is no requirement to lock multiple records in the data access layer for data that is accessed via the system.

Each data access layer component 37 communicates with only one core function 35.

However, plural data access layer components 37 may use the same database or other storage 38. Object data 7 is distinguished by the data access layer components 37 reading or writing the object data 7, for example using tables.

Each data object 7 is identified as belonging to a space and the registry 36 stores a list 44 of space identifiers. Each space identifier 48 (Figure 11) is used by only one object manager 6. An object manager 6 requests use a given space identifier 48 -13 - (Figure 11) from the directory 3. If directory 3 fmds that the given space identifier 48 (Figure 11) is available, then it grants permission and records that the given space identifier 48 (Figure 11) has been allocated. If another object manager requests use of the same given space identifier 48 (Figure 11), the directory 3 refuses the request. Thus, once an object manager 6 has added a space identifier 48 (Figure 11) to its list 44 of space identifiers, other object managers 6 may not use that identifier 48 (Figure 11).

Each data access layer component 37 need not use XML text as the format in which to store data. For example, the data access layer component 37 can retrieve object data in another format and convert the object data into XML format before sending to the core function 35. For example, if a data warehouse is used, then attributes and elements of data objects 7 may be stored in separate database fields.

Each object manager 6 has an administration function 39 for allowing an administrator (not shown) to configure the object manager 6, such as authorising users, viewing logs of system activity, adding new DAL components and editing the list of authorised space identifiers. The administration function 39 can be accessed through a browser (not shown).

Directoy 9 To permit object managers 6 to locate each other within the system 1, a directory service is provided.

Referring to Figure 14, the directory 9 maintains a list 64 of active object managers 6. Each entry 65, 652, 6Sf, in the list 64 includes the identity 66 of an object manager, network address 67 and identities 68, 682, 68f of one or more spaces.

Spaces may be identified using a Uniform Resource Identifier (URI), such as a Uniform Resource Locator (URL).

The identity of an object manager need not be constrained by the XML standards and could be any suitable ID, for example, created on object manager installation.

-14 -For example, a suitable format may be a 128-bit Globally Unique ID (GUID), which is commonly used to uniquely identify applications., Object managers 6 and directory 9 are configured to communicate according to a communication protocol, preferably Hypertext Transfer Protocol (HTTP).

An object manager 6 may send a request (not shown) to the directory 9 to register an object manager resulting in the addition of the object manager 6 to the list 64 of currently accessible object managers. As explained earlier, the object manager 6 may send a request 14 to the directory 9 to get object manager list, i.e. a list of object managers managing objects in a specified space.

The directory 9 has an administration function 10 for allowing an administrator (not shown) to configure the directory 9, such authorising users, viewing logs of activity, editing the list of registered object managers and refreshing the list of object managers by querying each registered object manager. If an object manager does not respond, it can be removed from the list 64.

Operation of object managers 6 will now be described in more detail: Creating a new object Referring to Figures 2, 4, 5, 8 and 16, an example of a method of creating a data object 7 is illustrated.

The core function 35 receives a request 12 from an application 8 (step SI). The request 12 specifies that the operation to be performed is to create a new object with data supplied and includes data 23 in XML format.

The core function 35 extracts the user identification 19 from the request 12 (step S2) and checks whether the user and/or the application has the right to create an object (step S3). If the user and/or the application is not authorised, then a status code "401" and an error message "Insufficient rights" are set (step S4).

-15 -if the user and/or the application is authorised, then the core function 35 extracts the XML data 23 from the request 12 (step S5) and checks whether the data 23 is in the correct format (step S6). If the data 23 is not in the correct format, then a status code "403" and an error message "Validation error" are set (step S7).

If the data 23 is in the correct format, then the core manager 35 forwards the data 23 to a data access layer component 37 to create a data object 7 (step S8).

If the data access layer component 37 cannot store the data 23, then it returns an error (not shown). Otherwise, the data access layer component 37 stores the data 23 as a data object 7 and returns an object identifier 47 (Figure 11) and a space identifier 48 (Figure 11). The core function 35 checks whether the data 23 was successfully stored

(step S9).

If the data 23 was unsuccessfully stored, then a status code "500" and an error message "Error creating object" are set (step Sb).

If the data was successfully stored, then a status code "201" and a message "OK" are set (step SI 1). The core function 35 receives the object identifier and a space identifier (step S12) and creates a record 40 in the registry 36 (step S13).

The core function 35 prepares a response 13 (step S14). The response 13 includes header 28 which includes a status code 30 and an error message 31. When creating a data object 7, the header 28 confirms whether the data object 7 was successfully created. Thus, the content of the response can be empty.

The core function 35 sends the response 13 to the application 8 (step S15).

Ret7eving an object Referring to Figures 2, 4, 5, 8 and 17, an example of a method of retrieving a data object 7 is illustrated.

-16 -The core function 35 receives a request 12 from an application 8 (step S16). The request 12 specifies that the operation to be performed is to read an object and includes a space identifier 21 and object identifier 22.

The core function 35 extracts the user identification 19 from the request 12 (step S17) and checks whether the user and/or the application has the right to read an object (step S18). If the user and/or the application is not authorised, then a status code "401" and an error message "Insufficient rights" are set (step S19).

If the user and/or the application is authorised, then the core function 35 extracts the space identifier 21 and object identifier 22 from the request 12 (step S20) and checks whether the identifiers 21, 22 ate in the correct format (step S21). If the identifiers 21, 22 are not in the correct format, then a status code "404" and an error message "Object not found" are set (step S22). However, steps S21 and S22 may be omitted.

If the identifiers 21, 22 are in the correct format, the core function 35 checks whether the object to which the request relates is under the management of the object manager 7 or another object manager 7 by referring to the registry 36 (steps S23 & S24).

If the core function 35 finds the space identifier 21 in the list 42 of space identifiers, then the core function 35 sends the space identifier 21 and object identifier 22 to the data access layer component 37 (step S25).

The data access layer component 37 converts the space identifier 21 and object identifier 22 into a data storage location identifier (not shown) retrieves the data object 7, if necessary, converts the data object into XML format and passes data object 7 to the core function 35.

The core function 35 receives the data 7 and updates the record in the registry 36, in particular data regarding the number 63 of times the object has been read (Figure 13) and the time/date 64 the object was last read (Figure 14) (step S26).

-17 -Once the data 7 has been successfully retrieved, a status code "201" and a message "OK" are set (step S27).

The core function 35 prepares a response 13 (step S28). The response 13 includes header 28, which includes a status code 30 and an error message 31, and data 29 which is in XML format.

The core function 35 sends the response 13 to the application 8 (step S29).

If the core function 35 does not fmd the space identifier 21 in the list 42 of space identifiers, then the core function 35 prepares and sends a request to the directory 9 (step S30 & S31).

As described earlier, if the directory 9 receives the request 14 and sends a response including the list of object managers 6 for the space.

The core function 35 receives the list and determines which object managers 6 for the space (step S32). The core function 35 prepares and sends a request 16 to the listed object managers 7 (step S33 & S34).

The object manager 6 managing the data object 7 receives the request 16 and returns the data object 7 in a response 17.

The core function 35 receives the response 17 (step S35) and forwards the data to the application, for example as described in steps S27 to 29 above.

Retnewn object data for another object manaser Referring to Figures 2, 4, 5, 8 and 18, an example of a method of providing a data object 7 for another object manager 6 is shown.

The core function 35 receives the request 16 from another object manager 7 (step S36). -18-

If the identifiers 21, 22 are in the correct format, the core function 35 checks whether the object to which the request relates is under the management of the object manager 6 or another object manager 6 by referring to the registry 36 (steps S37 & S38).

If the core function 35 finds the space identifier 21 in the list 42 of space identifiers, then the core function 35 sends the space identifier 21 and object identifier 22 to the data access layer component 37 (step S39).

The data access layer component 37 converts the space identifier 21 and object identifier 22 into a data storage location identifier (not shown) retrieves the data object 7, if necessary, converts the data object into XML format and passes data to the core function 35.

The core function 35 receives the data 7 and updates the record in the registry 36, in particular data regarding the number 63 of times the object has been read (Figure 13) and the time/date 64 the object was last read (Figure 14) (step S40).

The core function 35 prepares and sends a response 17 to the requesting object manager 7 (steps S41 and S42).

Searching Referring to Figures 2, 4, 5, 8, and 19, an example of a method of conducting a search is shown.

The core function 35 receives a request 12 from an application 8 (step S43). The request 12 specifies that the operation to be performed is to return a list of objects meeting specified query criteria. For example, the query might specify that the object manager 6 return data objects 7 of type "CentrifugalPump" and updated before 1/1/04 and that those objects must contain the element <service> with a value of "Closed Cooling Water".

-19 -The core function 35 extracts the user identification 19 from the request 12 (step S44) and checks whether the user and/or the application has the right to create an object (step S45). If the user and/or the application is not authorised, then a status code "401" and an error message "Insufficient rights" are set (step S46).

If the user and/or the application is authorised, then the core function 35 extracts the query criteria 26 from the request 12 (step S47) and may check whether the criteria 26 are in the correct format (step S48). If the criteria 26 are not in the correct format, then a status code "404" is set (step S49). The header may include reasons for the failure of the search.

The core function 35 searches through records 40, 41 having access data 44, metadata 45 and/or administrative data 46 which match the criteria 26 (step S50).

For each object matching the criteria, the space and object identifiers 47, 48 are retrieved. The core function 35 sends the space identifier 21 and object identifier 22 to the data access layer component 37 (step S51).

The core function 35 receives the data object 7 and updates the record in the registry 36, in particular data regarding the number 63 of times the object has been read (Figure 13) and the time/date 64 the object was last read (Figure 14) (step S52).

Once the data 7 has been successfully retrieved, a status code "201" and a message "OK" are set (step S53).

The core function 35 prepares a response 13 (step S54). The response 13 includes header 28, which includes a status code 30 and an error message 31, and data 29 which is in XML format.

-20 -The core function 35 sends the response 13 to the application 8 (step S55).Searches can be performed using the contents of the registry 36. Thus, the data access layer component 37 need not select, or access, a data object 7.

However, searching can be performed using the contents of data objects 7. This provides more powerful searching functionality. For example, a search can specify a pump made of cast iron, which is specified by an element within the XML description of the pump and which is not held in the registry 36.

Referring to Figure 20, the server 2 includes a processor 70, memory 71 storing the object manager application 6 and an input/output (I/O) interface 72 which are connected via a bus 73. The I/O interface 72 is connected to a user input 73, a display 74, storage 38 and network interface 75. Storage 38 may include one or more hard disk drives and/or one or more optical disc drives. The directory server 3 may be similar to the server 2 shown in Figure 20, except that it runs different software. A server 2 and the directory server 3 may be provided by a single server (not shown) running two sets of software.

It will be appreciated that many modifications may be made to the embodiment hereinbefore described. For example, the object manager and storage need not be provided in the same computer.

Claims

-21 -Claims 1. A networked data storage system comprising: a plurality

of servers; and a plurality of sets of data respectively accessible by said servers, wherein each server is configured such that, in response to a request for access to data from a client, if the data is not in its respective data set, the server sends a request for access to the data to another server.

2. A system according to claim 1, wherein the request includes an identifier for identifying the data and each server is configured to determine whether the data identified in the request is in the data set accessible by said server.

3. A system according to claim I or 2, wherein each server is configured to process a Hypertext Transfer Protocol (HTTP) request received from the client and to prepare an HTTP response.

4. A system according to any preceding claim, wherein each server is configured to prepare a response to the client which includes said data in eXtensible Markup Language (XML) format.

5. A system according to any preceding claim, wherein each server is configured to receive a response from another server including said data and to prepare a response to the client which includes said data.

6. A system according to any preceding claim, further comprising: a directory server.

7. A system according to claim 6, wherein each server is configured such that, if the data is not in its respective data set, the server sends a request to the directory server for a list of servers which are accessible to said data set in which said data is included.

-22 - 8. A system according to claim 6 or 7, wherein said each data set includes at least one data object, each data object having a respective identifier.

9. A system according to claim 8, wherein allocation of said identifiers is controlled by said directory server.

10. A system according to claim 9, wherein said identifiers are assigned by said director server.

11. A system according to any one of claims 8 to 10, wherein a server is configured to send a request for authorisation to use a given identifier and the directory server is configured to determine whether said given identifier is available.

12. A system according to any one of claim 8 to 11, wherein said directory server is configured to maintain a list of identifiers.

13. A system according to any preceding claim, wherein each server comprises: means for processing the request from a client; means for providing a record of the data set accessible to the server; and means for interfacing with storage storing said data set.

14. A system according to claim 13, wherein the request processing means is configured to check whether the client is authorised.

15. A system according to claim 13 or 14, wherein the request processing means is configured to select first interfacing means from a plurality of interfacing means.

16. A system according to any one of claims 13 to 15, wherein the request processing means is configured to update the record.

17. A system according to any one of claims 13 to 16, wherein the record providing means is configured to store a list of accessible data set.

-23 - 18. A system according to any one of claims 13 to 17, wherein the record providing means is configured to store data for accessing the accessible data set.

19. A system according to any one of claims 13 to 18, wherein the record providing means is configured to store metadata describing the accessible data set.

20. A system according to any one of claims 7 to 19, wherein the record providing means is configured to store data for describing a status of the accessible data set.

21. A system according to any preceding claim, wherein each data set comprises at least one data object.

22. A system according to claim 21, wherein said data object includes a reference to at least one other data object.

23. A system according to claim 22, wherein said data object is accessible to a first one of said servers and wherein said other data object is accessible to a second one of said servers.

24. A system according to any preceding claim, wherein at least some of said data sets are stored in eXtensible Markup Language (XML) format.

25. A system according to any preceding claim, wherein at least a first set of data conforms to a schema.

26. A system according to claim 25, wherein at least a second set of data conforms to another, different schema.

27. A system according to any preceding claim, further comprising: at least one client, wherein the at least one client is configured to apply a schema to data and to transmit said data conforming to the schema to one of said servers.

-24 - 28. A server having access to a set of data configured such that, in response to a request for access to data from a client, if the data is not in its data set, the server sends a request for access to the data to another server.

29. A server according to claim 28, wherein the set of data is stored on said server.

30. A server configured such that, in response to a request, from a client, to store data, said server is configured to send a request, to a directory server, to be authorised to use or to be assigned an identifier for said data and, in response to receiving authorisation or an identifier, to store said data and said identifier.

31. An object manager having access to a set of data configured such that, in response to a request for access to data from a client application, if the data is not in its data set, the server sends a request for access to the data to another object manager.

32. A directory server for providing a directory service to a plurality of servers, said directory serverconfigured to receive, from a server, a request to be authorised to use or to be assigned an identifier for identifying a data object, to transmit a authorisation or an identifier to the server and to store a list of identifiers.

33. A method in a data processing apparatus comprising: receiving a request for access to data from a client; determining whether said data is in a data set; sending a request for access to the data to another server.

34. A computer program which, when executed by a data processing apparatus, causes the data processing apparatus to perform a method according to claim 33.

35. A computer readable medium storing thereon a computer program according to claim 34.