Client-server system with central application management and using fully qualified class names of object-oriented applications for determining

Description Submit all comments and votes

TECHNICAL FIELD

The invention relates generally to the fields of personal computing and networking. Specifically, it relates to the new and evolving field of network computing, in which desktop computer users use a personal computer, possibly diskless, connected to a network such as a corporate intranet, the Internet, or to an network or Internet Service Provider (ISP) to gain access to applications which are then executed on the desktop computer. More specifically, the invention relates to server-based storage of software preferences (configuration data) for software retrieved from a server and executing at the desktop computer.

BACKGROUND OF THE INVENTION

The field of network computers is presently in its infancy. However, it is expected to evolve rapidly, especially in the corporate environment, for a number of reasons. The expectation is that as companies and possibly individual users reach hardware and software upgrade points, it will be more efficient and less expensive to move to this new field, rather than upgrade in the traditional way with disk equipped computers and locally stored and administered software applications. For example, in the corporate environment, a user can be connected to a corporate intranet, using, for example, the TCP/IP and HTTP protocols of the Internet, and download software applications as they are needed directly from a network server to the desktop computer. An application is executed on the desktop in the traditional manner by the user to perform useful work. An advantage of this configuration is that network computers are substantially less expensive than traditional disk equipped computers. It might also cost less to purchase the required number of software licenses for users, rather than purchase individual copies of software for each user. Certainly, the software administration problems that attend large numbers of corporate users will be substantially reduced. At the present time, each user of a disk equipped computer or workstation often is effectively his or her own system administrator, a role that often consumes excessive resources due to lack of expertise. It is expected to be a great advantage to eliminate this problem by effectively offloading the problem to a small number of server administration experts, rather than having many users struggle with the problems of software installation, upgrades and computer administration.

As mentioned above, this vision of the future of personal computing is presently in its infancy. As a result, there are presently many problems and deficiencies with existing systems.

Typically, in network computer systems, an administrator creates user profiles that are stored on a network server. The profiles may contain different types of information, such as user desktop preferences and user permissions for access to different software applications that might reside on the server. When a user logs onto the system, the user identifies him or herself to the server, the server locates the profile for the user and transmits it to the user computer where it is used to configure the computer and generate a desktop. The desktop might include a number of icons representing applications to which the user presumably has access. The profile likely also contains other attributes of the computer and desktop, such as for example, the background color of the desktop, or character fonts and point sizes used on the desktop, or data file search paths, etc. that are unique to the user. The profiles may be user modifiable or non-modifiable.

In an environment in which users can modify their own profiles, a modified profile is uploaded back to the server at log-off time, where it is stored for retrieval the next time the user logs-on. In some prior art systems, to the best of our knowledge, the users can generate on their desktops any configuration of application icons they wish, whether or not they exist on the server, and whether or not a user actually has access permission to an application on the server. The Lotus Workplace Desktop (previously called Kona Desktop) system is an example of this type of operation. In other systems, the server presents a list to the user of all applications that the server has, from which the user can pick. In this case, there is no

guarantee that the user actually has access permission to an application that is selected from the list for inclusion on the desktop. The Sun Hot Java Views system is an example of this type of system. In other words, the prior art systems do not correlate between what the user can configure for the set of desktop application icons and applications to which the user actually has permission access. In such a case, when the user clicks on a icon to execute an application, an error message may occur (such as an unauthorized access message) if access permission is not present, or in a worse case, the user's computer may crash.

Another limitation with existing art is that a flat data structure is used to model users, user groups, terminals and groups of terminals. Modeled after a common scheme for managing user access to computer resources, known network computer implementations (e.g., Lotus Administration Facility for Desktops, Microsoft Windows NT Profiles and Policies, and Sun Hot Java Views) implement a flat "groups" structure on the server for managing software preferences (or attributes) in various contexts. A "context", as used here, refers to an individual user, user group, terminal, or terminal group. Any grouping structure for managing software preferences on the server allows an administrator to define preference attributes for different groups of users as well as for individual users. However, flat systems are inflexible in many environments, especially in environments having large numbers of users. It is desirable to provide an administrative tool supporting the organization of preference information into a hierarchical structure.

Another limitation with existing systems is that they are limited in the ways that administrators and users have to perform user configuration of workstation desktops. For example, administrators are presently required to configure user preferences using configuration programs that are separate from, but associated with, a user application. It is desirable to allow vendors to provide only a single application. To require only an end user application from a vendor necessitates that the central management facility be able to execute the end user application in a context of a user or user group. The prior art does not allow this administrative flexibility of operation. In other words, in the prior art, to the best of our knowledge, an administrator does not have the ability to run a user application in the context of a user to set preferences for that user and application. Further, in the art, an administrator cannot run a user application to set preferences in the context of a group of users.

Still another limitation in the prior art known to the inventors is the manner in which the prior art partitions server permanent storage space to guarantee that a unique space is reserved for storing user preferences related to the different applications on the server. To the knowledge of the inventors, the problem of preventing collisions in the storage of preference information for different applications in object-oriented systems, in which an object can be queried for its fully qualified class name which uniquely identifies and differentiates it from other classes, is solved by having a first central authority assign a unique designation that applies to a vendor and by then having a second authority at the vendor assign a second designation relative to the first designation for each vendor application. For example, vendor A might be assigned the designation vendorA by the first authority and that designation is guaranteed to be unique within the architecture for which the first authority is acting. The second authority at vendor A then assigns the second designation for each of its applications within that architecture. For example, one of vendor A's applications might be designated-vendorA.App1; another might be designated vendorA.App2. The art maps the unique designation for each application in a system to a location in permanent storage of the system to guarantee that preference data for the different applications do not collide in storage. An application, when running, informs the network computer server of its unique storage location and it is the responsibility of the server to partition an area at the starting location according to a context (user, user group, terminal or terminal group) for storing preference information so as not to collide with preference information in a different context. Clearly, this manner of administering storage space is awkward and undesirable. It is desirable to devise a method to automatically generate unique storage locations for storing preference information for the afore mentioned object-oriented applications, without resorting to the requirement of having central authorities assign unique designations for the purpose of preventing collisions in the storage of preference information and without coding storage location information into an application.

Still another limitation in the art lies in the lack of any provision to migrate existing applications and hardware into the new environment of the centrally managed network computing world without requiring changes to the existing hardware and applications. Existing hardware, a terminal for example, in a networked environment, gets its configuration information at boot-up time from a file in a specific format located on a server. The terminal is programmed to know how to access its configuration file. The terminal uses a unique identifier to access the file from the server. The unique identifier is often the media access control (MAC) address of the terminal. However, in a new centrally managed environment involving protocols and API's that are different from that to which the terminal is designed, the terminal cannot access preference information in the new environment, the terminal can only access its configuration file in the way for which it is designed. This is a serious problem, because there are many such existing devices in use. The inability to use them in new systems impedes substantially the incentives for users to migrate to the new systems.

Still another limitation in the prior art concerns the interface between an administrator and the configuration management system. When configuring software within an administration facility to configure preference information for various users and user groups, and terminals and terminal groups, the administration software launches in the context (user, user group, terminal or terminal group) set by the Administrator who is running the facility. When the Administrator changes the context that the application is running under, the application needs to be relaunched to load configuration information for the new context. The process of relaunching software each time a context is changed is time consuming and inconvenient for an administrator, especially in systems with many users. In such systems, it is expected that an administrator will change contexts many times while configuring an application.

SUMMARY OF THE INVENTION

The system described herein provides a common repository for configuration information for users and applets in a client-server environment. This is referred to as client profile management. The system allows users to roam, that is, to log-in from any computer in the system at any time and have it configured automatically at run time according to the preferences stored for the user at the server. The preferred embodiment is a Java (Java is a Trademark of Sun, Inc.) based system and the client computers use a web browser interface arranged to execute Java applications. Thus, in the preferred embodiment, user applets and the desktop applet are assumed to be Java applets. However, it is not intended to limit the invention to a Java environment. Preferences for the locally stored applications might be stored locally in the traditional manner, while preferences for the server-based applets might be handled in the way described herein.

The invention automatically determines a unique storage location for storing preference information for an object-oriented application, without resorting to the requirement of having a central authority assign a unique designation for the application and without requiring the coding of storage location information into the application.

In the preferred embodiment, the system comprises a network which interconnects a server and a plurality of user stations. The server stores a plurality of object-oriented end user applications for downloading to user stations and it further stores configuration preferences for the end user applications in the context of different groups and users. A profile manager is provided at an administrators station. The profile manager is arranged to execute a configuration application for an end user application, whereby the administrator can specify configuration preferences for the end user application in the context of different groups and system users. When a set of configuration preferences is to be saved on the server, a unique location on the server for storing the configuration preferences is determined for the end user application in a selected context by retrieving the fully qualified class name of the end user application from an object on the administrator's station which represents the configuration application. The fully qualified class name uniquely identifies and differentiates the class from other classes. The fully qualified class name is combined with the selected context to form a key. The key is then mapped in a prescribed manner to generate the unique storage location address for the application and context.

BRIEF DESCRIPTION OF THE DRAWING

In the Drawing,

FIG. 1 shows an illustrative network and user stations, including an administrator's station, in which the invention might be practiced;

FIG. 2 shows an illustrative block diagram form of the administrator's station in communication with a server, and components of the administrator's station and the server for providing the central profile management and preference administration;

FIG. 3 shows one illustrative hierarchical organization of user groups and users of a system. The illustrative hierarchical organization might also contain individual terminals and terminal groups; however, these are omitted for simplicity;

FIG. 4 shows one illustrative listing of individual users and the group priority order that is used to determine a set of preferences from the hierarchical organization of FIG. 3 that apply to a user and a specific application executed by the user;

FIG. 5 shows a more detailed view of the administrator's station and server of FIG. 2;

FIG. 6 shows an illustrative view of the software objects at a user's terminal, including a user application and the API between the application and other components, that cooperate to establish the user preferences during execution of the application as the user's terminal;

FIGS. 7 through 8 show illustrative operations at both a user's terminal and a server for user log-on and initially establishing the user's desktop, including desktop preferences, at the user terminal;

FIGS. 9 through 11 show illustrative operations at both an administrator's terminal and a server for administrator user log-on, establishment of the administrator's desktop, and, by way of example, the selection of an application and a context for configuration; the example also illustrates a context change during configuration the user's desktop and the resulting operations; and

FIGS. 12 through 24 show a variety of actual administrator screen snapshots in various phases of application administration, including building of a hierarchy of which FIG. 3 is a representation of an example of, the creation and deletion of users, etc. the establishment of application preferences for applications, and context changes during preference establishment.

DETAILED DESCRIPTION

The system described herein provides a common repository for configuration information for all users and applets in a client-server environment. This is referred to as client profile management. The system allows users to roam, that is, to log-in from any computer in the system at any time and have it configured automatically at run time according to the preferences stored at the server. The preferred embodiment is a Java (Java is a Trademark of Sun, Inc.) based system and the client computers use a web browser interface arranged to execute Java programs.

The terms "applet" and "servlet" are established terms in the Java programming language art and will be used herein, since the terms have meaning to those skilled in this art. "Applet" refers to an independent software module that runs within a Java enabled web browser. Servlet refers to a software module that resides on a Java enabled web server. It is to be understood that the use of the terms "applet" and "servlet" herein is not intended to limit the invention in any way. For clarification, the phrase "configuration applet" is used herein to refer to a software module used to configure preferences for an end user software application such as a word processor, a database manager, etc. Since software applications are also "applets" in the Java environment, the phrase "user applet" or just "applet" is used herein to refer to an end user application.

In the preferred embodiment, user applets and the desktop applet are assumed to be Java applets. However, it is understood that the invention is not limited to a Java environment. The invention can be used in any client-server system. For example, if desired, the system could be designed to use proprietary communication protocols and applications written and compiled in any desired programming language. Further, even in the preferred Java based environment, disk-based computers might access some applications locally, and other applets from the server. Preferences for the locally stored applications might be stored locally in the traditional manner, while preferences for the server-based applets might be handled in the way described herein. Preferably, however, preferences for locally stored applications are stored on the server using the Profile Management Properties API in addition to the preferences for server based applets described herein.

A simple Application Program Interface (API) allows applets written to the API to easily store and retrieve preference data when the applet is executed by a user or administrator. Applet permissions and user preferences can be defined based on group memberships and individual identity.

Client profile management includes the following services:

Log-on support--mapping to a user profile;

User support--the administrative ability to create user identifications and provide services and preferences directly to users;

User groups support--the administrative ability to create hierarchical groups of users and provide services and preferences based on group memberships;

User applet context transparency--automatic determination of the context of user applet execution. That is, the determination of the user and/or group profiles that apply to a user applet execution and the automatic establishment of the profile environment;

User applet preferences repository--context-sensitive server storage for user applet configuration data;

Dynamic user applet preferences inheritance--hierarchical load-time coalescence of user applet preferences via the object-oriented principal of inheritance; and

User applet access control--control of user applet execution based on group default membership privileges. The administrator can override default group privileges and permit or deny additional access privileges for individual users.

Profile management provides a framework through which these tasks are performed. Some tasks are supported by profile management directly, e.g. user/group management, applet lists, context switching, preference inheritance, etc., while configuration services specific to user applets are usually supported by separate configuration applets invoked by a system administrator within the client profile management environment. Some end user applets might provide the configuration capability as part of the end user applet. If this is the case, the administrator can run the end user applet (as opposed to a separate configuration applet) in the context of individual users and groups to set the configuration preferences for those users and groups.

FIG. 1 shows one high level view of an intended environment for practicing

the invention. A network 100 is provided for interconnecting a plurality of user stations, such as desktop personal computers 102, mobile laptop computers 104, workstations 106 (e.g., RISC computers), an administrator's station 108 and a server 110. In one embodiment, network 100 might be a local area network. In another embodiment, network 100 might include wide area networking for entities such as corporations that have geographically displaced sites that are still included within the system. There is no intent to limit the environment in which the invention might be practiced; indeed, a network of any type that interconnects many types of stations is envisioned.

A high-level diagram of the profile management administrative operating environment is shown in FIG. 2. An administrator client network computer 200 is represented on the left of the Fig. and a server 202 for the system is on the right. The client and server communicate via a network represented as 203. The particular example of FIG. 2 assumes that the client computer is a system administrator's computer.

Profile manager 206 on the client side allows the administrator to configure user applet preferences at both user and group levels. The administrator can create new users and group hierarchies, add users to different groups, specify applet permissions for each group and for individual users. And the administrator can configure applets in the context of an individual user or a group. The administrator can add, delete and reset passwords for users. Profile management support is transparent to the general user. The administrator can invoke the profile manager 206 in the context of any user or group. Only the administrator can change from his/her context to administer clients (users) and groups. The server will not allow a user without administrative authority to switch context. When a request comes into the server, it will query the authenticated ID of the user trying to access this function. If the user does not possess administrative authority, (i.e., is not a member of the AllUsers.Administrator group), the Profile Manager Servlet 214 will reject the request.

Profile manager 206 invokes other applets, such as applet1 (208), as shown in FIG. 2. In this example, applet1 might be the administrative applet for configuring preferences related to user desktops. Or applet1 could be a configuration utility related to an end user applet, such as editors, word processors, databases, etc. It is preferred, but not required, that configuration applets such as 208 exist as modules separate from their corresponding user applets. In the context of FIG. 2, Applet1 is typically a configuration applet for a user applet; the administrator runs the configuration applet applet1 under a group context to set group preference and permission defaults, or in a user context to customize user applet configurations for an individual. By implementing applet1 as a module separate from its user applet, performance is enhanced, since the configuration applet1 will likely be small compared to the user applet. Also, separate configuration applets allow the administrator to control the end users ability to configure the user applet.

Traditional stand-alone computers store user applet configuration information locally in association with its the user applet. Traditional stand-alone Java based computers store user applet configuration information using the format provided by the java.util.Properties class. Both arrangements require that the user applet specify the name of a local file in which to store configuration information related to the user applet. In other words, a relationship is required between the computer and the user applet loaded on it. Profile management as described herein provides the familiar capabilities of a real java.util.Properties object plus additional facilities supporting user-roaming capabilities and seamless pluggability into a powerful administrative framework (the Profile Manager).

ProfileManagementProperties P 210 is a properties object for applet1 and provides an API between Applet1 and the server that allows the server to determine where to store configuration information for applet1 in the context of users and groups. The ProfileManagementProperties object class provides all of the functionality of the java.util.properties class with the further ability to provide create, save, and retrieve the configuration information for software from permanent storage. Storing such information in a central location makes management of user and group configurations possible. When a user is in the role of administrator, ProfileManagementProperties 210 allows the administrator to configure the user applet corresponding to configuration applet1, or to configure applet1 if applet1 is an end user applet, and store the configuration information in the proper place on the server in the proper context. This allows the establishment of a relationship between the user applet and the user, rather than between user applet and computer as in traditional systems. ProfileManagementProperties 210 is an extension of the java.util.Properties class. The extension allows the key/value pairs of preference information of a Properties object to be associated with a key, as opposed to a stream, as with java.util.Properties. This, in turn, allows application developers to use the key to specify a unique location relative to a context for preference information, rather than a file name and path. ProfileManagementProperties 210 determines the key automatically. The generation of the key is discussed more in connection with FIGS. 8 and 9. By modeling ProfileManagementProperties 210 after the java.util.Properties class, the system can take advantage of preference inheritance through recursive class-default evaluation. Thus, this extended class provides a "group default" capability by accumulating preferences starting at a current context, as discussed with respect to FIG. 3, and traversing up the contextual hierarchy for defaults.

Server 202 includes a database 212 that stores user data and group data, such as user and group preferences and user applet access permissions. Webserver 218 represents a typical web server with support for Java applets. Profile Manager servlet 214 maps user and group identifications to preference data. It also maintains an access control list to manage user access to applications on the server.

User and group preferences are stored as a tree hierarchy, as shown in FIG. 3. All users of the system automatically belong to the top group AllUsers. All users belong to the AllUsers group; this group contains the default preferences for some or all user applets on the server. In FIG. 3, it is assumed that the server contains at least three user applets, identified as App3, App4 and App5. As indicated in the AllUsers group, the default background (BG) for App3 is BG=blue. Other illustrative preferences labeled as x, y and z are shown to have the default values of 1, 2 and 3 respectively. The terms x, y and z are intended to represent any desired preference and the values 1, 2 and 3 are arbitrary and used merely to illustrate the point. The x preference might for example be the screen font for the desktop; the value x=1 might call for a default font of Times-Roman. Similarly, the default preferences for App4 for all users are BG=gray, x=2, y=2 and z=2.

The default values in the AllUsers group can be modified in any desired way for other contexts, such as for other user groups and individual users. By way of example, in addition to the context of AllUsers in FIG. 3, four other groups (GroupX, GroupY, GroupY1 and GroupY2) are shown. Additionally, two individuals User1 and UserN are shown. Users can be members of more than one group. In FIG. 3, User1 is a member of AllUsers, GroupX and GroupY1; UsenN is a member of AllUsers and GroupY2. If a user is a member of more than one group (another group in addition to AllUsers), then the groups are prioritized for the purpose of selecting the preferences for a given applet for that user. The administrator configures the group priorities for a user. Group priority is illustrated in FIG. 4. In FIG. 4, User1 has GroupX (identified by the fully qualified name of AllUsers.GroupX for his or her highest priority group. User1's next highest priority group is GroupY1 (AllUsers.GroupY.GroupY1). User1's lowest priority group is the AllUsers group. When a user, say User1, requests to run an applet say App3, the preferences are coalesced from the tree of FIG. 3 according to the group or groups to which the user belongs and the user applet is configured on the user desktop accordingly.

The first step in coalescing preferences for any context is to get the defaults. The defaults for a user, if there are any, is the coalesced set of preferences for the applet from the highest priority group from which preference information for the applet can be obtained. The defaults for a group, if there are any, is the coalesced set of preferences for the applet from the groups parent (i.e., The AllUsers group is the parent of AllUsers.GroupX). If a group has no parent (i.e., the top level AllUsers group), there are no defaults for that group. To coalesce the preferences for an applet at a context, the preferences for the applet explicitly stored at the context, overwrite the default preferences for the applet for the context. Thus, to coalesce preferences into the default set for an applet in a group context, recursive calls are made from each group node up to the AllUsers group requesting each parents set of preferences for the applet. Please refer to FIG. 3 to illustrate the following example. For example, if the context is Allusers.GroupY.GroupY1, a call is made to the parent of GroupY1, which is GroupY, requesting its default preferences for the applet. GroupY1 makes a recursive call to its parent, which is AllUsers. AllUsers has no parent, so AllUsers returns it set of preferences for the applet to