JP2000122984A - General schema for storing configuration information on client computer and server computer - Google Patents

Abstract

PROBLEM TO BE SOLVED: To disclose a data schema having an (n)-branch tree structure including a data layer, etc., by providing a data framework which can be accessed by an arbitrary client computer among client computers. SOLUTION: A client schema hierarchical structure 103 and a server schema hierarchical structure uses an (n)-branch tree. A root entry 201 is provided at the root of the tree. Further, a 1st level 203 in the client schema 103 is right below the root entry 201 and has name space entries. Then a hierarchical structure, i.e., a data schema for displaying and storing in a system data base the data framework, i.e., a data schema and a relative protocol for exchanging data in the data schema between computers is disclosed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

TECHNICAL FIELD This invention relates to computer software and computer network applications. More particularly, the present invention relates to the exchange of configuration data between client-server applications and multiple computers in a computer network.

[0002]

BACKGROUND OF THE INVENTION One type of conventional computer network is a series of personal computers called clients.
A computer (e.g., a Sun Spark workstation or an IBM personal computer) needs to connect to one or more server computers. Client computers are generally independent and have in their memory most of the information needed to execute user applications and perform network operations. That is, the client computer contains its configuration information regarding both software and hardware functions and requirements. Client computers typically access a network server for a variety of reasons, such as accessing network software applications, sending and receiving email, and retrieving and storing information in network databases. However, in general, information specific to a particular client computer resides on that client computer. This information can include, for example, the memory capacity, the number of data bus types, or hardware specifications, examples of which include the type of data bus or the type of another processor. The client computer is relatively independent and stores its configuration information (thus, this information is not available on the server computer). For this reason, the task of data management and application management on client computers has become a burden.

[0003] While it is possible to propagate small changes or adjustments to applications residing on servers in a network to client computers, any major upgrade or adjustment or installation of a new application requires that all clients This results in requiring each client computer to be accessed and updated by the network administrator. Some companies have tens of thousands of computers connected to the network, and the burden of installing major revisions or upgrades to application software or general configuration software can be expensive. This is an efficient and time-consuming operation. In addition, since most client computers are independent, each user who needs to use multiple client computers, each located in a different location, will have access to application and configuration software.
It is difficult to maintain personal preferences for data. That is, users can install their personal preferences as defaults on client computers that they always use, but without changing the defaults on other client computers. -Can be copied to a computer.

[0004] Another type of computer network
The configuration uses a dumb terminal, typically a "thin" client, connected to the mainframe computer.
In this type of network, almost all processing and data reside on mainframe computers. Shin
The client does not perform any of these activities. In this type of configuration, all information about the client is under the control of the mainframe computer. When the connection between the client and the mainframe is terminated, all processing stops,
The client will not be able to perform all activities.

As mentioned above, in a conventional network configuration, the process of installing new software or a new application is a static process. In this configuration,
Configuration information for each personal computer is defined on each client machine. Therefore, the network administrator must statically define each configuration on each personal computer. In a conventional computer network configuration, the configuration information for each particular subsystem, or client, is hard-coded within the client. In addition, in the case of a traditional network configuration using multiple independent clients connected to a network server, installing a new version or upgrading the software significantly (upgrading requires knowledge of subsystem configuration or subsystem configuration). Application maintenance), which typically requires bringing down the application or network.

In a conventional computer network with a plurality of clients and a server having information that the client needs for various reasons, all the data on the server that the client needs, that is, the client All data on the server is often transferred from the server to the client. Generally, this involves moving large amounts of data. Most of these data are not used by the client, ie they are not required for the operation of the client. Transferring all data to the client is inefficient and increases network traffic. In addition, the client must have sufficient memory and storage to store all information related to itself transferred from the server. For example, devices such as PDAs and smart cards without mass storage cannot store all information in their memory, including configuration information that may be relevant to them.

Therefore, it would be desirable to have a system that supports distributed management of client configurations by storing this type of configuration information in a central repository. This allows the network administrator to manage the subsystem configuration from the server and propagate all changes to the application from the server.
It would be desirable for a network user to be able to log on to each of a plurality of different clients and to have access to the user's personal preferences and profiles on any client on the network. It is further desirable to have a method that allows data to be transferred from a server to a client in an efficient and fully functional manner. In addition, it is desirable to send data to the client in a compact, compact form so that the client does not receive duplicate data.

[0008]

SUMMARY OF THE INVENTION To achieve the objects of the present invention, a method, apparatus and computer readable form a data framework and associated protocols for implementing data storage and exchange between a plurality of computers in a network. Disclose a medium. In accordance with one aspect of the invention, an n including a root node layer, an intermediate node layer, and a data layer for storing configuration data.
A data schema having a branch tree structure is disclosed.
The middle node layer has a number of nodes that contain categorical information about components and various features of the computer network. In the tree structure, each intermediate node and root node has a branch to a plurality of nodes below it. These lower nodes are called child nodes. The data node layer is located at the bottom of the tree and contains the actual unique configuration data for components and other features of the computer network. Certain of the plurality of intermediate nodes and data nodes form a persistent memory area. The actual specific configuration data in the data nodes forming the persistent memory area is modified on a client or server computer and stored on a server computer.
This makes the associated unique information non-volatile and accessible by multiple client computers.

In one embodiment of the present invention, the data schema, ie, the data framework, is a client schema that resides on a client computer.
Includes subcomponents and server schema subcomponents residing on one or more server computers. In another embodiment, user preferences (user settings) and profiles are stored in a server schema. This allows a user on the network to use any one of the plurality of client computers on the network and access their own preferences. In addition, client computer platform and profile information is stored in the server schema. In yet another embodiment, the persistent memory area includes a number of data entries, each data entry having a name, a list of associated nodes, a property name, and an associated property value.

In another aspect of the present invention, a data schema for arranging and storing information about client computers in a computer network having server computers is disclosed. The data schema includes a root node and a number of intermediate node levels with intermediate nodes. Each intermediate node indicates, or stores, categorical information about the computer network and client computers.
Further, the schema contains the actual configuration information corresponding to the categorical information in the intermediate nodes. The categorical and configuration information present on the client computer allows the client computer to adapt to the various profiles and preferences determined when the client computer was started and connected to the network.

In one embodiment, a number of intermediate nodes
The level includes a top intermediate node level having a plurality of top intermediate nodes. Each top intermediate node forms a data space having a number of data entries.
In another embodiment, the data space of the plurality of data spaces, referred to as software data space, is a persistent data space. When the client computer is turned off, i.e., shut down, this persistent data space allows the saving of data entries in the data space.

In another aspect of the present invention, a data schema for arranging and storing configuration information for a number of client computers in a computer network having a server computer storing the data schema is disclosed. I do. The data schema includes a root node and a number of intermediate node levels having a plurality of intermediate nodes. Each intermediate node indicates, or stores, categorical information about the computer network and client computers on the computer network. In addition, the data schema further includes actual configuration information corresponding to the categorical information in the intermediate nodes located within the data level of the data schema. The categorical information and the configuration information reside on the server computer, whereby
Upon receipt of a request from a client computer, it allows the server computer to propagate the client computer profile and preferences.

In one embodiment, a number of intermediate nodes
The level includes a top intermediate node level having a plurality of top intermediate nodes. Each top intermediate node forms a data space having a number of data entries.
In another embodiment, there are two data spaces, a machine data space and a user data space, and these two data spaces are persistent data spaces. When the client computer is turned off, i.e., shut down, these persistent data spaces allow the storage of the data entries contained therein.
In another embodiment, the machine data space stores computer configuration data for a number of computer types residing on a network. The user data space stores user configuration data for a number of registered users for accessing the computer network.

In another aspect of the invention, a method for preparing data for transmission over a computer network is provided.
An apparatus and a computer-readable medium are provided. A data set containing values for the profile and platform of the client computer
Search on computer. In addition, another data set is retrieved on the server computer that contains values for the user preferences and user groups of the user using the client computer. These two data sets are related to each other in that they correspond to a user logging on to a particular client computer. By associating the data items in the two data sets for each property, data item correspondence
e) is formed. A set of rules, including a list of priorities among multiple data categories, is applied to the data item correspondence. The final data set defines the above set of rules as a data item
Obtained by applying to correspondence and transmitted over the network to the target computer. By sending the final data set over the network, the amount of data to send
It is possible to reduce the amount of data when all data sets are transmitted as they are.

[0015] In one embodiment, a connection is established between a client computer and a server computer. The client profile is sent from the client computer to the server computer. In another embodiment, the set of rules includes a preference ranking. This ranking is used to determine which data items to include in the final data set from among the data items respectively included in the first two data sets. In another embodiment, the client computer is a network computer.

In yet another aspect of the present invention, there is provided a method, apparatus and computer readable medium for configuring a computer in a network having a server computer. Establish a connection between the computer with the profile and the server computer. Sending the computer profile to the server; The server then searches for configuration information stored under the control of the server based on the profile. Set the computer configuration based on the configuration information retrieved on the server and sent to the computer. This facilitates centralized management of configuration information by the server computer.

In one embodiment, the profile includes hardware information about the client computer,
And information about the user of the client computer. In another embodiment, the client computer and the server computer exchange software version information used to exchange data between the two computers. The exact version of the software used is determined by the server computer. In yet another embodiment, the client computer is a network computer. In yet another embodiment, the server computer stores configuration information about a number of client computers on the network and users who have registered to use the client computers.

The invention and its further advantages can best be understood from the following description with reference to the accompanying drawings, in which:

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of the present invention will be described in detail below. One example of a preferred embodiment is shown in the accompanying drawings. Although the present invention is described in detail in connection with a preferred embodiment,
This is not intended to limit the invention to one preferred embodiment. On the contrary, the intent is to cover modifications, improvements and equivalents included in the spirit and scope of the invention as defined in the appended claims.

The data framework, ie, the data framework
Schematics and associated protocols for exchanging data in the data schema between computers in a computer network are shown in several figures.
Configuration information and related information
The present invention discloses a hierarchical structure, ie, a data schema, for display and storage in a database. For the purpose of illustrating one embodiment of the present invention, a Java system database (JS for short)
Consider D). In another preferred embodiment, the system database is capable of operation on other types of platforms. JSD of this embodiment
Has at least two major subcomponents:
It is a single subsystem that includes sub-schema called client schema and server schema. In this embodiment, data about the client is stored in a client schema that resides in the client memory. The configuration data for each client is stored in a server schema that resides on a network server. Configuration data is exchanged between two schemas, ie, two hierarchies, through a client / server protocol. The client / server is responsible for retrieving accurate information from the server schema and transferring it to the client schema on the client machine, i.e., entering, and conversely, transferring information from the client schema to the server schema.
Server protocol guaranteed. Configuration information for each client, also called a subsystem, is stored in a server schema. This is in contrast to conventional networks in which configuration information about the client is hard coded, ie, stored, on the client machine. The data schema of the present invention allows a network administrator to manage configuration information for each computer in the network from a central repository, such as a single server. Therefore,
Any software updates, versions, etc. that require knowledge of the subsystem configuration and access to the subsystem configuration
Upgrades or installations of new applications can be made from a central repository and propagated to each client. To perform maintenance aimed at installing or propagating a new upgrade or new version of an application, the user on the client machine does not need to terminate the application and need to bring down the network.

FIG. 1 is a block diagram illustrating components of a computer network configuration, illustrating a system-wide data schema according to one embodiment of the present invention. In the present embodiment, the system-wide data schema will be described as a Java system database JSD (101) composed of the client schema 103 existing on the client machine 105 constituting a part of the network 107.
The server schema 111 resides on a server computer 109 that forms part of the network 107.

FIG. 2 illustrates an n-branch tree structure representing a client schema hierarchy 103 according to one embodiment of the present invention. Client schema hierarchical structure 103
And the server schema hierarchy 111 is shown using an n-branch tree. A root entry 201 is provided at the root of the tree. Root entry 201 contains no data. Further, in this hierarchical structure, the root entry 201 is the only node framework that refers to itself. The set of nodes belonging to the first level 203 of the nodes in the client schema 103 each define a namespace in the generic client schema. The first level 203 in the hierarchy is directly below the root entry 201 and has a plurality of namespace entries.

In this embodiment, there are six namespaces in the generic client schema 103. In another preferred embodiment, more or less namespaces may be provided based on the requirements of a particular network configuration. In this embodiment, the standard top-level JSD client
Namespaces are software (SOFTWARE), device (DEVICE), interface (INTERFACE), software configuration (SOFTWARECONFIGUR)
ATION), an alias (ALIAS) and a temp (TEMP.). For example, the software namespace includes all nodes and data that start at and branch off from node 205. The unique entry belonging to the layer 203 of the hierarchical structure is the root of a subtree forming a unique namespace. All entries belonging to one namespace, such as software,
05 is an entry relating to configuration data of the software application 05. Each entry belonging to the data schema of the present invention consists of a unique name, a list of children (the entry immediately below any entry), and a set of tuples. Each set contains a property name and an associated property value. For example, in a word processing program, the property name is "font" and the property value is Palentin.
o). Similarly, device namespace 20
7 are all entries relating to configuration information of the client machine 105 having the client schema 103. Each entry in the hierarchical structure functions as an entry in the subtree, and also functions as a lower entry, that is, a root of the subtree having child nodes. Each namespace in layer 203 is disclosed in an application referred to as the JAVA SYSTEM DATABASE filed on the same day as the corresponding US application and assigned to the same assignee. The content of this application is disclosed herein with this disclosure.

As shown in FIG. 2, each entry in the tree has a single parent and has several child nodes. A namespace, such as software namespace 209, is a specially designated subtree that contains multiple entries for configuration data on software for a particular client, such as client 105. As shown in FIG. 2, in this embodiment, each namespace is always located immediately below a root entry, also called a super root. In another preferred embodiment, the namespace can be formed at another level of the hierarchy, and the namespace need not be located directly below the root 201. The standard namespace of the JSD schema client is created during the startup of the client computer, ie during the booting procedure. Each namespace of this embodiment is available for all implementations of the Java platform. The six namespaces are well-known namespaces initialized by the Java platform. Other dynamically constructed namespaces may be added to the standard database namespace after initialization.

Each namespace is managed by a default namespace manager. The namespace manager controls how entries are stored and accessed in the namespace. In addition, the namespace manager provides a standard interface for exporting the security, storage and ownership attributes of any entry in the namespace.

For example, software namespace 2
09 has a list of installed system services and / or available system services. Examples of this system service include device drivers, user applications, and user configuration information. The software namespace is the only persistent namespace in the client schema because the server provides a backup store for all entries in the software namespace. A persistent namespace, which has the opposite meaning of a temporary namespace, ie, a persistent entry, is an entry that needs to be stored in a permanent storage location. An example of a persistent entry is configuration information about a user environment that needs to be stored in persistent storage. When the user logs on, it is necessary to search the environment previously saved by the user in order to save the trouble of resetting the environment. A permanent entry is an entry that can be saved to and retrieved from a permanent storage location. When a namespace is created, the permanent namespace and the temporary namespace are statically separated. It is not allowed that the permanent entry exists in the temporary namespace and / or that the temporary entry exists in the permanent namespace. In this embodiment, the permanent entry is stored in the remote JSD server. In the present embodiment, there are four categories: application,
Systems, services, and public exist under the software namespace. In this embodiment using the Java platform, some entries in the software namespace are formed using Java-specific nomenclature, while other entries that are unrelated to Java are named based on the particular application. Formed using the method. In this embodiment, company names such as IBM (IMB), Sun or Lotus are com.IBM,
Given names such as com.Sun and com.Lotus. These company names characterize the company-specific information. The entry name under the company entry is company specific.

As described above, in the present embodiment, the software namespace 209 is the only namespace having permanent storage among the six namespaces.
And other namespaces, such as device namespace 207, have temporary storage. When the client computer is turned off, the entries in these namespaces are lost. This is the case in the present embodiment, because these five temporary namespaces store client computer specific data. In this embodiment, the software namespace contains application configuration information that needs to be saved after the computer is turned off.

[0027] Four categories are provided under the software namespace: applications, systems, services, and public. Taking the application category as an example, the entry com.Ne
tscape 213 has a unique name of a company (eg, Netscape) and is a product of Netscape, Netscape Navigato (Netscape Navigato).
The entry of r) exists under the com.Netscape entry 313. Company specific information 217 about Netscape Navigator exists under the entry 215.

The entries 219, 221 and 223 are entries of other vendors.
It has 15 similar entries each. In this embodiment, the structure of the device namespace 225 indicates some or all of the I / O buses and devices present on the client. In other words, the physical connectivity of buses and devices is represented as a tree of entries. And, in this tree, a particular bus is a parent, and a plurality of leaf entries each include configuration data on a plurality of devices.

In the software namespace, the leaf node levels of the hierarchy have data 227. Data 227 is data unique to the configuration. The data 227 is configured based on the order of specific data within the leaf node level desired by the application (eg, Netscape Navigator). For word processing applications, leaf node entries may include unique information such as fonts, dictionary definitions, and other word processing type configuration data.

The multiple namespaces in the JSD server schema component are persistent storage spaces. That is, these namespaces persist even after the client computer is turned off. In this embodiment, two namespaces exist in the server schema, a machine and a user. FIG. 3 is a block diagram illustrating the structure of a JSD server schema according to one embodiment of the present invention. This block diagram corresponds to the server computer 109 and server schema 11 of FIG.
1 is shown below. Route entry 301 (the route entry 301 is the configuration entry of the present embodiment)
Namespace is also located at the top of the n-branch tree. As mentioned above, two namespaces exist in the server schema. Area 303 is a machine
Represents the machine namespace with node 305.
Area 307 is a user with user node 309
Represents a namespace.

In the present embodiment, the machine namespace 303 is formed by three categories. In another preferred embodiment, based on the platform and requirements of the network, the machine namespace 303
May have more or less than three subcategories. The three categories, namely, sub-ranges, are a platform (Platform) 311 and an identifier (identifi).
er) 313 and profile (315). There are a number of entries under the platform 311 pointing to specific computer manufacturers, such as Sun Microsystems and IBM Corporation. This is shown in detail in FIG.

FIG. 4 is a block diagram showing a tree structure of the machine namespace 303 in the server schema 111. As described above, the vendor specific subrange 401,
403 exists under the category of the platform 311. The number of entries at this level is based on the number of computer manufacturers used in the network. There are a number of entries under each manufacturer, such as com.Sun, as shown by entries 405,407.
Each entry indicates a particular model or type of computer manufactured by the manufacturer. For example, computer
Type JDM1 resides under com.Sun, and computer types NS1000 and NS2000 reside under com.IBM. Under each computer type, or model, is a leaf node 409 that specifies the application configuration for this computer. In the type subcategory, the leaf configuration, ie, the application configuration information in the leaf node, includes all configurations applicable to a particular computer, ie, the computer indicated in the parent entry.

Under the identifier subcategory having the identifier root entry 313, there is an entry including the unique identifier 411 of each computer in the network 107. In this embodiment, the MAC address of each computer is used as a unique identifier. Data 413 below the specific client identifier 411 is specific computer-specific application configuration information corresponding to the client identifier 411. Configuration data 413 under identifier 411
Applies to the specific computer for which the specific user has configured the configuration. Therefore, this configuration data 413 is stored in the platform
Configuration data 409 under category
Can be distinguished. In the present embodiment, a cross-reference (not shown) exists between a plurality of unique identifiers 411 under the identifier category and a plurality of entries under the platform category. That is, there is a reference from a particular identifier to a particular type of computer, ie, a reference. The platform indicated by the specific unique identifier, that is,
This allows the server to determine the type of computer.

Below the profile category having a profile root entry 315 are a plurality of entries that indicate a particular category or use of a computer in the network. Configuration information for a particular profile, which may indicate a department within the enterprise, etc., may be included under the profile sub-category. Examples of these are two nodes 415, 417, which represent profiles of Finance and Sales, respectively. Below the finance node 415,
There is application specific data 419 that contains data about the finance profile. As with references from unique identifiers to platform entries, there are also references from unique identifiers to profile entries (where applicable). That is, if a particular computer has a particular profile, such as a computer used in the accounting department or a computer used only as a receptionist terminal, there is a reference from this computer identifier to the appropriate profile entry.

FIG. 5 is a block diagram illustrating a user namespace according to one embodiment of the present invention. In the present embodiment, the user namespace 307 has two categories: users and groups.
Having. A users node 317 represents the name of each user on the computer network, such as nodes 501, 503, 505. Under each user's node is a unique configuration file containing each user's personal preferences, as shown at 507.
Data exists. For example, in a word processing application, certain user preferences may be the default font and document size. This category allows each user to use any computer on the network 107 and use his or her personal configuration on this computer. For example, if the user launches a word processing program, that user's preferences become defaults instead of the defaults of a normal user of the computer. The other category in the user namespace is a group category with a groups node 319. This category contains entries for specific groups of users. Groups may include various categories. An example of this is a department in a company as shown by nodes 509 and 511, that is, a category that distinguishes each employee in the company from other employees. In this embodiment, there is a reference pointer from each user 503, 505 under user category 317 to one or more specific groups (if appropriate).

In the present invention, data is exchanged between clients and servers in a computer network based on the client / server protocols shown in the figures. Client 105 and server 109 in FIG.
This protocol, shown by arrow 108, is a set of rules and procedures for establishing connections and exchanging data between clients and servers. The server in the present embodiment can exchange data and communicate with external services and storage media using various protocols. The protocols supported by the JSD server are various persistent protocols located at the back end of the server. On the other hand,
To implement data exchange between external entities such as persistent storage, data registries, file servers and data directories and JSD servers, JS
The D server can support a number of different protocols, and the client / server protocol between the JSD client and the JSD server is sufficiently versatile and flexible to support these different protocols. In such situations, the client / server protocol is designed to include a small "footprint". By providing a complicated mechanism for managing a plurality of protocols necessary for communication with an external entity connected to the server, the burden of managing these protocols is not imposed on each client. Therefore, the model detailed above is a two-tire model,
The first tire is the client / server protocol of the present invention between the JSD client and the JSD server, and the second tire is a plurality of protocols supported by the JSD server and various external services and data storage entities.

FIGS. 6-8 are flowcharts illustrating a process for establishing a connection between a client and a server and then exchanging configuration information according to one embodiment of the present invention. In step 601 of FIG. 6, a client computer in the computer network attempts to open a communication link with the network. In this step, the client sends a discovery packet to the network to connect to the server. In this embodiment, this data packet is a DHCP packet containing client information.
(Dynamic Host Configuration Protocol) Discovery packet. Step 9
At 03, the network server receives the discovery packet. In this embodiment, the client computer has a client schema 103, and the server computer has the JSD 101 described in detail in FIG.
Is defined as a whole. In step 605, the server computer sends the IP address of the sender of the discovery packet (the unique identifier 1).
Read two examples). In this embodiment, the IP address is used as a unique identifier of the client sending the data packet. In another preferred embodiment, the MAC
Another identifier, such as an ID, can be used as the unique identifier.

In step 607, the server sends a packet to the client indicating that the client has established a connection with the server. The server substantially informs the client that the client is currently communicating with the server. In step 609, the client sends a negotiation data packet to the server. This step is described in detail in FIG. The purpose of the negotiation packet is to determine the version of software used for communication between the client and server. After confirming the software version,
The client sends its unique profile information to the server in step 611. In many cases,
Typically, this unique profile information is hard-coded into the client's PROM. For example, the client's unique profile information may include the type of computer, such as a Sun JDM1 workstation or an IBM NS1000 computer. After the server receives the profile information from the client, in step 613 of FIG. 3, the server attempts to match this profile with a unique profile in machine namespace 303 under platform subcategory 311. The server schema machine namespace 303 has a platform category 311. The platform category 311 stores specific profile information for a particular type of computer manufactured by the computer manufacturer. In step 613 of FIG. 7, the server looks up the client's profile in the machine namespace. In step 615, the server uses the client unique identifier to determine whether the client has a unique profile.
As mentioned above, within the machine namespace, the category of identifiers includes the unique identifier of every client in the network. If the client has a unique profile, such as receptionist or sales, there is a reference pointer from the unique identifier to the corresponding profile.

In step 617, the server merges, or combines, the profile data (if any) with the platform data. The server then sends the unified data entry, the merged data entry, to the client's software namespace. The process of merging profile data and platform data is detailed in FIGS. In this embodiment, the data for the computer platform is overridden by data in the computer-specific profile (if a computer-specific profile for this computer exists). In step 619, the client occupies the software namespace 209 in its client schema 103 with the coalesced data entry sent from the server. At this point, the client computer boots up
The stage is completed.

In step 621, the user logs on to the client computer, thereby initiating a logon phase. At this point, the username is sent to the server. In step 623, the server accepts the username to search for a configuration in the user namespace 307 in the server schema. As described above, in the present embodiment, the server schema 111 has two namespaces:
It has a machine namespace 303 and a user namespace 307. Under the user namespace there are two categories: users 317 and groups 319. In step 623, the server looks up the user configuration using the username. In step 625 of FIG. 8, by checking the reference pointer from the user entry to an entry in the group category, the server tells the user that the
It is determined whether or not it belongs to the group represented by the node 319. In step 627, the user configuration entry and the group configuration entry are merged into a single user entry and sent to the client. In this embodiment,
The data in the user configuration entry will override any corresponding data in the user group configuration entry. The process of merging the data from the user entry and the data from the group entry is detailed in FIGS. In step 629, the client receives the user entry and, if necessary, overrides the data in the software namespace in the client schema previously occupied by the platform / profile entry. In the present embodiment, step 6
The user configuration entry sent to the client at 27 overrides any corresponding data sent at step 619. In this embodiment, the software namespace in the client schema is the only software namespace that contains persistent data,
It should be noted that only the namespace is occupied by data sent from the server, i.e., data that resides in permanent storage on the server computer, i.e., non-volatile storage. In another preferred embodiment, another namespace may include persistent data based on the requirements of the computer network. Step 63
At 1, the user of the client computer can start a particular application. At this stage, the client computer can start the application by probing the software namespace of the client computer's client schema to obtain the appropriate configuration data for the particular application. At this stage, all configuration data necessary to execute the application on the client computer has been transferred from the server to the client. Further, only configuration data used by the client computer is transferred from the server to the client as a result of the coalescing performed on the server.

FIG. 9 is a flowchart illustrating a process for negotiating, or negotiating, a communication link between a client and a server according to one embodiment of the present invention. This flowchart shows the details of step 609 in FIG. In step 701, the client notifies the server of version information of its software. This version information may further indicate the hardware components of the client. This data is transmitted as data packets over TCP / IP. In this step, the client simply informs the server of the version of the operating software it uses. In step 703, the server looks up this version information and then informs the client of the version of operating software that the server can support. By doing this, the server dictates the version of operating software used to exchange configuration data between the client and the server.

FIG. 10 is a flowchart showing details of steps 617 and 627 of FIG. This flowchart illustrates the process of the present embodiment for merging configuration data on the server for a particular client. The data is coalesced based on the hierarchical structure shown in FIG. 11 because a particular data item in a data entry may be overridden by a corresponding data item in another namespace or category. In step 801, the server enters the platform entry into the platform entry in its machine namespace.
Search from subtree. The platform entry contains specific information about the client computer type. In step 803, the server determines whether the client has a corresponding profile entry by checking if there is a reference pointer from the client machine unique identifier to a particular profile in the profile category. I do. If the client has a profile entry, the server retrieves this profile entry in step 805. In step 805, the values in this profile entry and the platform entry are merged. The values of the properties contained in these profile and platform entries are shown in FIG.
One property is combined based on one hierarchical structure. In this embodiment, values in the profile entry that have matching property values in the platform entry are overridden by the profile entry value. Merging of entries is performed for each property. If it is determined in step 803 that the client does not have a profile entry, control passes to step 807.

At step 807, the server retrieves the user entry from the user namespace in the server schema. In step 809, it is determined whether the logged-on user belongs to any of the groups 319.
The server decides. In step 811, the server searches for a group entry. However, again, the server overrides the value in the group entry with the value in the user entry on a property-by-property basis. Step 8
At 13, the server overrides the value in the profile / platform entry from step 805 with the value in the coalescing user entry. If the server determines in step 809 that the user does not belong to the group, the process moves to step 813. Step 815
In, the coalesced data entry for the user logging on to the client is sent to the client computer and the process is complete.

FIG. 11 is a block diagram illustrating a hierarchical structure used to coalesce data according to one embodiment of the present invention. At the highest rank,
The entry that takes precedence over all other entries is block 8
17 is a user entry shown in FIG. Below this entry, the next highest ranked entry, block 81
There is a user group entry indicated by 9. The value in the property contained in the group entry is
Overridden by the value of the matching property in the entry. Block 821 is a client profile entry. Property values in the group entry override matching property values in the client profile entry. At the bottom of the hierarchical structure of the present embodiment, there is a client platform entry shown in block 823. The value in this entry is overridden by the value of the matching property in any one of the other three categories. In another preferred embodiment, the priority can be changed and more or fewer entries in the hierarchy can be included than the number of entries in the previous embodiment.

One feature of the client / server protocol is called a heartbeat mechanism. That the client or server will be notified when the connection between the client and server is disconnected or interrupted.
Heartbeat mechanism enables. 12 and 13 are flowcharts illustrating a process according to one embodiment of the present invention for periodically transmitting a signal from a server to a client to indicate that the connection between the server and the client is still alive. . Typically,
The heartbeat mechanism is started immediately after the negotiation phase (step 609 in FIG. 9) and continues as long as the connection between the client and server continues. It is an important feature that the client or server is notified when the connection between the client and server is disconnected or interrupted. In step 901, the server sends a data packet to the client. This generally occurs first immediately after the negotiation phase and is transmitted at regular intervals as long as the connection lasts. In this embodiment, the heartbeat daemon runs on both the client and the server and is essentially a single thread within the client / server protocol. In another preferred embodiment, the heartbeat
Daemons can execute on servers or clients and can be multi-threaded processes. The server maintains state information for the connection and includes data such as the time at which the data packet was sent to the client. In step 903, return data from the client
The server determines whether there is a packet, ie, a heartbeat. At step 905, if a heartbeat is present, the data packet from the client is sent to the server. In step 901, after a set time interval (eg, 10 minutes), the server
Send the packet to the client again. In another preferred embodiment, the time interval can be longer,
Alternatively, it can be shorter.

If it is determined in step 903 that the client did not send the data packet back to the server, that is, that no heartbeat exists, the return
To indicate that no data packet exists,
The server uses state information and structure (directory cache). This is performed in step 907. A dirty bit is placed in the structure to indicate that the connection has been broken. In step 909, the server and client attempt a reconnection. At this point, the server checks the dirty bit in its state structure to see if an update on the client is needed. This can occur if the configuration information on the server for the client has changed. In step 911, the server updates the client configuration. The client further has a structure indicating status information similar to the directory cache status structure on the server. The client status structure may then include a dirty bit to indicate whether updates should be sent from the client to the server. Thus, in step 913, the client checks its dirty bit to see if the update should be sent to the server. At step 915, the client updates the server schema. At this point, a reconnection between the client and server is established and after the negotiation phase is completed,
The heartbeat mechanism resumes operation.

Another feature of the client / server protocol of the present invention is the ability to notify a client using this application of a particular application update performed on the server. FIG.
4 is a flowchart illustrating a process for event notification in a client / server protocol according to one embodiment of the present invention. In step 1301, the server schema is updated with application coordination, ie, changes. That is, the server schema is changed by updating the general configuration. In step 1003, to identify clients that use the modified configuration data, ie, clients that may wish to be notified of general configuration changes implemented in the server schema. , The server consults its cache directory. The server cache directory is a list used by clients connected to the server. In step 1005, the server broadcasts the update, ie, the change, to the appropriate clients. In step 1007,
The client determines the client-side application that is affected by the update, i.e., the client determines whether the general configuration update is relevant to itself. In step 1009, the client determines whether the application affected by the update has registered to receive notification of all changes. If the application is registered to receive the notification, control proceeds to step 1011.
In step 1011, the application receives an update notification. At this stage, the process is complete. If the application is not registered to be notified of changes,
That is, the update is ignored, and the operation is continued without being notified.

Another feature of the client / server protocol of the present invention is the ability to guarantee the execution or non-execution of a particular operation. This feature is referred to as the atomicity of the client / server protocol.
Two-phase commit procedure (twtw for updating in client and server schemas)
The client / server protocol performs an o-phase commit procedure. In the first phase, the root of this subtree is locked to update one of the entries in the subtree of the schema. Second
In the phase, one of the entries in the subtree is updated, and then the root of this subtree is unlocked. Locking the root of the subtree prevents other clients or applications from accessing all entries and nodes under the root in the subtree. Another client application that attempts to update an entry in the locked subrange will cause a block or unblock transaction. A transaction is called a block transaction if it waits for an unlock to occur and then the client application wishes to update itself. In this scenario, updates are placed in a queue. If the application does not want to wait for the lock to be removed, the transaction is called a non-blocking transaction and the transaction is returned to the application. Through this mechanism, the client / server protocol performs the requested operation, ie, updates,
That is, it is possible to assure the client application that the transaction is blocked and that the operation is not performed, that is, the transaction is not blocked.

As noted above, the present invention employs various computer-implemented operations involving data stored in computer systems. These operations include (but are not limited to) those requiring physical manipulations of physical quantities. Generally, although not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transferred, combined, compared, and otherwise manipulated. The operations disclosed herein that form part of the present invention are effective machine operations. The operation to be performed is producing,
Identifying, running, determinating
ining), comparing, executing, downloading or detecting.
ng). In particular, it is convenient to indicate these electrical or magnetic signals as bits, values, elements, variables, characters or data, etc., in order to establish a common usage. However, it should be remembered that all of these and similar terms should be associated with the appropriate physical quantities and are merely convenient labels applied to these physical quantities.

The present invention further relates to a device, system or apparatus for performing the above operations.
The system can be specially constructed for the required purpose. Also, the system can be a general purpose computer. A general purpose computer is selectively activated or configured by a computer program stored on the general purpose computer. The above processes are not specific to a particular computer or other computing device. In particular, a program described based on the disclosure content of the present specification can be used with various general-purpose computers. Alternatively, it may be more convenient to create a more specialized computer system to perform the required operations.

FIG. 15 illustrates a general purpose computer system 110 suitable for performing processing in accordance with one embodiment of the present invention.
0 is a block diagram of FIG. FIG. 15 shows one example of a general-purpose computer system. Other computer system architectures and configurations may be used to implement the processes of the present invention. Computer system 1 consisting of various subsystems described in detail below
100 is at least one microprocessor subsystem (also called central processing unit, or CPU) 1
102. That is, the CPU 1102 can be realized by a single-chip processor or a plurality of processors. CPU 1102 is a computer system 1100
Is a general purpose digital processor that controls the operation of Using the instruction retrieved from the memory, the CPU 1
102 controls the reception and manipulation of input data, and the output and display of data on output devices.

The CPU 1102 is a first primary storage device 1 generally comprising a random access memory (RAM).
104 is bidirectionally connected through a memory bus 1108. Further, the CPU 1102 generally includes a second primary storage device 11 comprising a read only memory (ROM).
06 is unidirectionally connected via a memory bus 1108. As is well known in the art, the primary storage device 1104 can be used as a general-purpose storage area and a working memory, and can also be used to store input data and processed data. Further, the CPU 1102
In addition to storing data and instructions for processing the above operations, primary storage 1104 can store programming instructions and data, for example, in the form of threads and processes. In addition, primary storage 1104 is commonly used to transfer data and instructions bi-directionally at high speed over memory bus 1108. Similarly, as is well known in the art, the CPU 1102
The primary storage 1106 generally contains the basic operating instructions, program codes, data, and objects used by the to perform its functions. Based on conditions such as whether data access requires two-way or one-way, primary storage 1104, 1106 may include any suitable computer-readable storage media, as described in more detail below. The CPU 1102 can search and store frequently needed data directly in the cache memory 1110 at a very high speed.

Removable mass storage 1112 provides additional data storage for computer system 1100 and is bidirectionally or unidirectionally connected to CPU 1102 through peripheral bus 1114. For example, certain removable mass storage devices, commonly known as CD-ROMs, store data in the CPU1.
A one-way transmission to 102. On the other hand, a floppy disk may transmit data to CPU 1102 in both directions. Storage device 1112 may further include computer readable media such as magnetic tape, flash memory, signals embodied in a carrier wave, PC cards, portable mass storage devices, holographic storage devices, and other storage devices. Fixed mass storage 1116 provides additional data storage capacity and is bi-directionally connected to CPU 1102 through peripheral bus 1114. The most common example of mass storage 1116 is a hard disk drive. Generally, access to these media is slower than access to primary storage 1104, 1106. The CPU 1102 stores other programming instructions and data which are not frequently used by the mass storage device 1.
112 and 1116 are generally stored. If necessary,
The information held in the mass storage devices 1112 and 1116 can be normally incorporated as a virtual memory constituting a part of the primary storage device 1104 (eg, RAM).

CPU 1102 to storage subsystem
Access to the peripheral bus 11
14 can be used to provide access to other subsystems and devices. In the present embodiment, these are:
A display monitor 1118 and an adapter 1120;
Printer device 1122, network interface 1124, auxiliary input / output device interface 1
126, sound card 1128 and speaker 11
30 as well as other required subsystems.

As shown, by using a network connection, the network interface 11
24 allows the CPU 1102 to connect to another computer, computer network or telecommunications network. In performing the method steps, CPU 1102 receives information, such as data objects or program instructions, from another network through network interface 1124 or transmits information to another network through network interface 1124. obtain. C
Information represented by a sequence of instructions executed by the PU can be transmitted to and received from another network in the form of a computer data signal embedded in a carrier. An interface card or similar device and appropriate software executed by CPU 1102 can be used to connect computer system 1100 to an external network and transfer data based on standard protocols. That is, the method of the present invention can be executed alone on the CPU 1102. On the other hand, by cooperating with a remote CPU that shares part of the processing, the method of the present invention may be performed over a network such as the Internet, an intra network or a local area network. Another mass storage device (not shown) is connected to the network interface 1124.
Through to the CPU 1102.

CPU 1102 for devices such as microphones, touch displays, transducer card readers, tape readers, speech recognizers, handwriting recognizers, biometric readers, cameras, portable mass storage devices and other computers. Auxiliary input / output device interface 1126 represents a general purpose interface and a custom interface that allow data to be sent and received.

To receive input from the keyboard 1136 or the pointer device 1138 and to transmit decoded symbols from the keyboard 1136 or the pointer device 1138 to the CPU 1102, the keyboard controller 1132 connects to the local bus 11.
34, it is connected to the CPU 1102. The pointer device can be a mouse, stylus, trackball or tablet. And the pointer device is effective for interfacing with a graphical user interface.

In addition, embodiments of the present invention provide programs for performing various computer-implemented operations.
A computer storage device having a computer readable medium containing code. Computer readable media is any data storage device that can store data which can be thereafter read by a computer system. Whether the media and program code are specially designed and constructed for the purposes of the present invention;
Or it may be well known to those skilled in the computer software arts. Examples of computer readable media include hard disk, floppy and
Magnetic media such as disks and magnetic tapes, and CD-RO
Optical media such as M disks, magneto-optical media such as optical floppy disks, and application-specific integrated circuits (ASI
C), all but the aforementioned media including, but not limited to, programmable logic circuits (PLDs), specially configured hardware devices such as ROM devices and RAM devices. The computer readable medium may be distributed over a network of coupled computer systems as a data signal embodied in a carrier wave. Thus, the computer readable code can be stored and executed in a distributed form. Examples of program code include machine code formed by a compiler or the like, or a file containing high-level code that can be executed using an interpreter.

Those skilled in the art will recognize that the hardware and software elements described above have standard designs and configurations. Other computer systems suitable for the present invention may include another subsystem or a smaller number of subsystems. Further, the memory bus 11
08, peripheral bus 1114 and local bus 1134 are examples of any interconnection scheme used to link multiple subsystems. For example, a local bus can be used to connect the CPU to fixed mass storage 1116 and display adapter 1120. The computer system shown in FIG. 15 is an example of a computer system suitable for the present invention. Other computer architectures having alternative configurations of subsystems may be used to implement the client or server computer of the present invention. In another preferred embodiment of the present invention,
The client computer is a network computer, ie, NC. In terms of functionality and storage capacity, this computer is a completely independent "fat" client computer that can function as a stand-alone computer, and a server computer, i. Located between dumb clients that depend on.
In yet another preferred embodiment, other than computers with limited memory storage, such as personal digital assistants (PDAs) and handheld computers, the client schema is a smart card capable of running a Java platform and other On non-computing devices, such as smart appliances.

While the invention has been described in some detail for purposes of clarity of understanding, certain changes and modifications may be practiced without departing from the scope of the invention. Further, it should be recognized that there are other ways to implement both the process and apparatus of the present invention. Accordingly, the embodiments disclosed herein are for purposes of illustration and not limitation. Furthermore, the present invention is not limited to the details disclosed herein, but may vary within the scope of the appended claims and equivalents thereof.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating components of a computer network configuration, illustrating a system-wide data schema according to one embodiment of the invention.

FIG. 2 illustrates an n-branch tree structure illustrating a client schema hierarchical structure according to one embodiment of the present invention.

FIG. 3 is a block diagram illustrating the structure of a JSD server schema according to one embodiment of the present invention.

FIG. 4 is a block diagram showing a tree structure of a machine namespace in a server schema.

FIG. 5 is a block diagram illustrating a user namespace according to one embodiment of the invention.

FIG. 6 establishes a connection between the client and the server;
And 1 of the present invention for exchanging configuration information
5 is a flowchart illustrating a process according to one embodiment.

FIG. 7 establishes a connection between the client and the server,
And 1 of the present invention for exchanging configuration information
5 is a flowchart illustrating a process according to one embodiment.

FIG. 8 establishes a connection between the client and the server;
And 1 of the present invention for exchanging configuration information
5 is a flowchart illustrating a process according to one embodiment.

FIG. 9 is a flowchart illustrating a process for negotiating a communication link between a client and a server according to one embodiment of the invention.

FIG. 10 is a flowchart showing details of steps 617 and 627 in FIGS. 7 and 8;

FIG. 11 illustrates one embodiment of the invention used to coalesce data.
FIG. 4 is a block diagram illustrating a hierarchical structure according to one embodiment.

FIG. 12 is a flowchart illustrating a process in accordance with one embodiment of the present invention for periodically transmitting a signal from a server to a client to indicate that the connection between the server and the client is still alive.

FIG. 13 is a flowchart illustrating a process in accordance with one embodiment of the present invention for periodically transmitting a signal from a server to a client to indicate that the connection between the server and the client is still alive.

FIG. 14 is a flowchart of a process for event notification in a client / server protocol according to one embodiment of the present invention.

FIG. 15 is a block diagram of a general computer system suitable for implementing an embodiment of the present invention.

 ────────────────────────────────────────────────── ─── Continuation of the front page (71) Applicant 591064003 901 SAN ANTONIO ROAD PALO ALTO, CA 94303, US A. (72) Inventor Bernard A. Travasat, United States 94109 San Francisco, California, California Street, 2055 Apartment 402 (72) Inventor Tom Saulpo, United States 95120, California San Jose, Brett Harte Drive, 6938 (72) Inventor Jeffrey A. . Schmidt, United States 95006 California Boulder Creek, Lodge Road, 535 (72) Inventor Gregory El.・ Slaughter United States 94306 Palo Alto, Emerson Street, 3326 (72) Inventor William Jay. Tracy 78681 Round Rock, Texas, USA Deepwood Drive, 400 (72) Inventor Steve G. Woodward United States 78750 Texas Austin, Holm Lacey Lane, 10212

Claims (19)

[Claims] 1. A data framework for storing data relating to a computer network including a plurality of client computers connected to at least one server computer, comprising: a root node level; At least one intermediate node level having a plurality of intermediate nodes respectively located below a node level and each storing categorical information regarding the computer network; and being located below the intermediate node level; A plurality of persistent nodes including a data node level for storing a unique value for the computer network; and at least one of the intermediate nodes included in the intermediate node level and the associated unique value stored at the data node level. Data spec Wherein the data in each of the persistent data spaces is modifiable on each of the client computers or the server computer and storable on the server computer, and the associated unique value is A data framework that is non-volatile and accessible by any of the other client computers. 2. The data server of claim 1, further comprising a client data framework residing on the client computer, and a server data framework residing on the server computer.
Framework. 3. The method of claim 2, wherein the user preference is set to the server
Stored in a data framework so that users on the network can access the plurality of client
3. The data framework of claim 2, wherein any one of the computers is used and allows access to its user preferences. 4. The data framework according to claim 1, further comprising a plurality of temporary data areas for storing configuration data obtained when the client computer is enabled. 5. The data framework of claim 2, wherein client platform and client profile information is stored within the server data framework. 6. The data framework according to claim 1, wherein the client computer is a network computer. 7. The plurality of persistent data spaces further include a plurality of data entries, each data entry having a name, a list of associated nodes, a property name, and an associated property value. 1, 2, 4
A data framework according to any one of claims 1 to 6. 8. A data framework for arranging and storing information about a client computer, wherein the client computer is a computer in a network having at least one server computer. The framework comprises a root node, a plurality of intermediate node levels each having at least one intermediate node for storing categorical information associated with the network, and configuration information associated with the plurality of intermediate nodes. The configuration information is associated with and resides on the client computer, thereby enabling a connection between the client computer and a network. A data framework that allows the client computer to adapt to various profiles and preferences determined when the client computer is run. 9. The data framework of claim 8, wherein said plurality of intermediate node levels includes a top intermediate node level having a plurality of top intermediate nodes. 10. The data framework according to claim 9, wherein each of said plurality of top intermediate nodes forms a data space having a plurality of data entries. 11. The data framework of claim 10, further comprising a software data space, a device data space, an interface data space, an alias data space, and a temp data space. 12. The data storage system according to claim 11, wherein said software data space is a permanent data space, which causes the saving of data entries in said data space when said client computer is shut down. Framework. 13. The data framework of claim 12, wherein said software data space is occupied by configuration data from said server computer. 14. A data framework for arranging and storing configuration information for a plurality of client computers, wherein the data framework resides on a server computer in a computer network. A node, a plurality of intermediate node levels each having at least one intermediate node storing categorical information associated with the computer network, and configuration information associated with the plurality of intermediate nodes; The configuration information is associated with the plurality of client computers and resides on the server computer, whereby upon receiving a request from the client computer, the server computer A data framework that allows for the propagation of client computer profiles and pre-fanless. 15. The data framework of claim 14, wherein said plurality of intermediate node levels includes a top intermediate node level having a plurality of top intermediate nodes. 16. The data framework according to claim 15, wherein each of the plurality of top intermediate nodes forms a data space having a plurality of data entries. 17. Machine data space and user
The data framework of claim 16, further comprising a data space. 18. The data framework of claim 17, wherein the machine data space and the user data space are persistent data spaces, which results in non-volatility of data entries in the data space. 19. The machine data space occupied by computer configuration data for a plurality of computer types, and the user data space is occupied by user configuration data for a plurality of network users. 19. The data framework according to 18.