Electrical computers and digital processing systems: multicomput – Network computer configuring
Reexamination Certificate
1999-01-29
2002-04-02
Dinh, Dung C. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Network computer configuring
C707S793000, C713S001000
Reexamination Certificate
active
06366954
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates generally to computer software and computer network applications. More specifically, it relates to client-server applications and the transfer and arrangement of configuration data among components or storage areas in a computer network.
A conventional computer network involves connecting a series of personal computers commonly referred to as clients, to one or more server computers. Client computers are generally self-sufficient and contain within their resident memory much of the information needed to run user applications and communicate with a network. This includes information about their own configuration with regard to software and hardware capabilities and requirements. A client computer typically access network servers for a variety of reasons, such as accessing network software applications, email, retrieving and storing information on a network database, or accessing the Internet. However, information specific to a particular client computer generally resides on that client computer. This information can include, for example, the memory specifications and bus types, additional processors, and other hardware specifications. Since client computers are relatively self-sufficient and store their own configuration information (as opposed to storing such data on a server), the task of managing configuration and user data in addition to end user application data on a client computer has become increasingly burdensome.
While it is possible to propagate minor upgrades or fixes to applications residing on a network server to the client computers, any significant upgrade or fix, or installation of a new application that effects every client requires that each client computer be accessed and updated individually by a network administrator. With the increasing number of computers being connected to networks, ranging in the tens of thousands in some enterprises, the burden of installing major revisions or upgrades to application software or to general configuration software has become expensive, inefficient, and time-consuming. In addition, because most client computers are self-sufficient, it is difficult for users using different client computers at different locations to maintain personal preferences regarding applications and configuration data. That is, even though a user can install personal preferences as defaults on their normally-used client computer, it is burdensome to replicate these defaults on other client computers without changing defaults on those computers.
As described above, in a conventional network configuration, the process of installing new software or new applications is a static process. In such a configuration, the configuration information for each client is defined on each client machine. Thus, the network administrator statically defines each configuration on each client. In a conventional computer network, configuration information for each particular subsystem or client is hardcoded in the particular client. Furthermore, with conventional network configurations using self-sufficient clients connected to network servers, application maintenance, such as installing major upgrades to software, where the upgrade requires access to a subsystem's configuration, normally requires that the network be “brought down” to perform the maintenance.
With conventional computer networks that have multiple clients and a server in which the server contains information, that is needed by a client for various reasons, in many cases all the data on the server needed by or relevant to the client is moved from the server to the client. This can typically involve moving large amounts of data, much of which may not be used or is not necessary for the client to operate. Transferring all the data to the client is inefficient and increases network traffic. In addition, the client must have sufficient memory and storage to store all information relating to that particular client from the server. For example, devices such as PDAs and smart cards which do not have large storage capacities cannot contain in resident memory all necessary information, including configuration information that might be relevant to that particular device.
Another component of many conventional enterprise-wide networks are directory and naming services. Such services are used to store configuration and mapping information relating to network users and hardware components. This information is needed by users and components in a network to perform certain functions that require network services. Some widely used directory services are DNS (Directory Name Service), AD (Active Directory) used in the Windows NT® environment, and NIS in the Unix environment. A newer and powerful directory service that uses more current technology is the Lightweight Directory Access Protocol or LDAP, which is being used more widely in enterprise networks for directory services.
FIG. 1
is a block diagram depicting how a client accesses data in an LDAP directory service. A client computer
102
in an enterprise environment
104
has an LDAP access module or add-on
106
. When client
102
needs to access an LDAP directory
108
, it does so directly using module
106
shown by line
110
.
LDAP directory
108
is essentially a software server having a database and a software daemon (not shown). The database segment, which contains all the configuration and related data can be described functionally as a table
112
having two columns. One column contains an attribute and the second column contains one or more actual values. The attribute can be of any data category, for example, representing a user name, a logon name, a department, or hardware identifier. One advantage of directory services is the flexibility it gives network administrators to store any type of data that may need to be accessed by users or components in the network. One or more values can be associated with an attribute. For example, an attribute representing user-specific settings can have several values associated with it all, those values residing in the same value entry, separated by some type of delimiter. The structure and organization of LDAP directory
108
is well known in the field of computer network administration.
The information stored in these existing directory services, referred to as legacy systems, would have to be accessible to client computers in an enterprise network. Thus, any type of configuration repository that addresses the problems discussed above regarding the management of application and configuration data in expanding networks would have to accommodate or have access to configuration data on legacy systems such as LDAP directory services. A configuration server capable of providing client computers with configuration and user-specific data in an efficient manner must be able to exchange data with existing directory services containing configuration data.
Therefore, it would be desirable to have a system which supports distributed management of client and user configurations by storing such configuration information at a central repository. This would allow a network administrator to manage subsystem configurations from the server, and to propagate all types of changes to applications from a server. Furthermore, it would be desirable to have the central repository access legacy systems for configuration data rapidly, with minimum overhead processing, and have it done transparent to the client computers.
SUMMARY OF THE INVENTION
According to the present invention, methods, data structures, and computer readable media are disclosed for communicating data between a configuration server schema and a network directory service. In one aspect of the invention, an extension to a directory service enabling a mapping between a directory service attribute and a configuration server property is described. A directory service entry includes multiple shadow attributes where each shadow attribute corresponds to a particular directory service attribute. The particular directory servic
Saulpaugh Tom
Slaughter Gregory L.
Traversat Bernard A.
Beyer Weaver & Thomas LLP
Dinh Dung C.
Sun Microsystems Inc.
LandOfFree
Method and data format for exchanging data between a Java... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and data format for exchanging data between a Java..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and data format for exchanging data between a Java... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2820182