System and method for determining and manipulating configuration information of servers in a distributed object environment

We claim:

1. A computer system for accessing and manipulating configuration information about a server program within the computer system, comprising:

at least one persistent server administrator object associated with the server program, and stored within the computer system and externally to the server program, and including:

a plurality of machine readable storage structures adapted to contain configuration information of the server program;

a plurality of machine executable structures adapted to access and manipulate the machine readable storage structures without starting up the server program as a server process in the computer system, the machine readable storage structures updated to include selected configuration information during registration of the server program.

2. The computer system of claim 1 further comprising:

at least one client object executing as a client process;

wherein the server administrator object is adapted to receive invocations of the machine executable structures from a client object, and in response to the invocations, to provide selected configuration information to the client object.

3. The computer system of claim 1 further comprising:

at least one client object executing as a client process; and

a basic object adapter communicatively coupled between the client object and the server program and adapted to provide the client object access to objects within the server program, the basic object adapter further adapted to store execution configuration information of the server program to invoke the server program in response to a request from the client object;

wherein the server administrator object is adapted to receive invocations of the machine executable structures from a client object, and in response to the invocations, to update the execution configuration information of the server program stored in a basic object adapter.

4. The computer system of claim 1, further comprising:

a primary storage adapted to store the server process including objects and data; and

a processing unit adapted to execute a server and object methods, each executed server or object method being a process in the primary storage.

5. The computer system of claim 4, wherein selected ones of the structures of the server administrator object further comprise:

a process identification structure adapted to determine a process identifier of the server program process by the processing unit without invoking the server program if the server program is not currently executing; and,

a structure adapted to store the process identifier.

6. The computer system of claim 1, wherein selected ones of the structures of the server administrator object further comprise:

a name structure adapted to determine a name for the server program, and a structure adapted to store the name;

a host name structure adapted to determine a computer name of the host computer including the associated server program, and a structure adapted to store the computer name; and

an execution definition structure adapted to determine an execution definition structure containing at least a current pathname for the server program, and a structure adapted to store the execution definition.

7. The computer system of claim 6, wherein the execution definition structure is further adapted to establish a current program definition including a current set of command line arguments and a current set of environment parameters to be used with the server program when the server program is executed, and is coupled to a structure adapted to store the current program definition.

8. The computer system of claim 7, wherein selected ones of the structures of the server administrator object further comprise:

a structure adapted to store a saved program definition for the server program, the saved program definition including a backup pathname of the server program, a backup set of command line arguments, and a backup set of environment parameters; and,

a structure adapted to restore the current program definition with the saved program definition.

9. The computer system of claim 6, wherein the execution definition structure is further adapted to determine a pathname of a data directory associated with the server program.

10. The computer system of claim 1, wherein selected ones of the structures of the server administrator object further comprise:

a structure adapted to determine whether the server program associated with the server administrator is executing without invoking the server program if the server is not currently executing; and,

a structure adapted to store a value indicative of whether the server program is executing.

11. The computer system of claim 1, wherein selected ones of the structures of the server administrator object further comprise:

a structure adapted to establish a hold down value in an execution definition of the server program used to invoke the server program; and,

a structure adapted to store the hold down value.

12. The computer system of claim 1, wherein the machine executable structures of the server administrator object further comprise:

a structure adapted to interpose an executable application for the server program when the server program is invoked; and,

a structure adapted to store a program definition for the executable application, including a pathname for the executable application, and a set of command line arguments.

13. The computer system of claim 1, wherein:

the server program further includes a machine executable deallocation structure adapted to automatically deallocate idle objects within the server program when the server is executing as a process, the machine executable deallocation structure operating according to selected ones of the machine readable storage structures in the server administrator object;

wherein the selected ones of the machine readable storage structures include:

a first attribute that enables or disables the machine executable deallocation structure;

a second attribute that establishes a cycle time for the machine executable deallocation structure; and,

a third attribute that establishes an maximum time interval for which the server program can be idle, such that the server program is automatically shutdown by machine executable deallocation structure after a time interval equal to or exceeding the maximum time interval;

and wherein selected ones of the machine executable structures of the server administrator object establish selected ones of the first, second, and third attributes.

14. The computer system of claim 1, wherein:

the computer system includes a machine executable logging structure adapted to log information regarding the execution of the server program, the machine executable logging structure operating according to selected ones of the machine readable storage structures in the server administrator object;

wherein the selected ones of the machine readable storage structures include:

a first attribute that enables or disables logging by an operating system process; and

a second attribute that identifies at least one log file used by the machine executable logging structure to store information, and that establishes a maximum file size for the log file;

and wherein selected ones of the machine executable structures of the server administrator object establish selected ones of the first, and second attributes.

15. The computer system of claim 1, wherein selected ones of the machine readable storage structures of the server administrator object further include:

a structure adapted to store an interval value indicative of a frequency for the server program to send a signal to the server administrator to indicate that the server program is currently executing; and,

a structure adapted to store a maximum value indicative of a maximum number of signals that the server administrator may not receive prior to initiating a process to determine whether the server program is currently executing.

16. The computer system of claim 1, wherein:

the server program further includes at least one tracing facility;

the computer system further includes a machine executable tracing structure adapted to output conditional information according to at least one tracing facility in the server program; and

selected ones of the machine executable structures of the server administrator object further comprise:

a structure adapted to define a tracing configuration including a tracing facility and a set of trace flags, and a structure adapted to store the tracing configuration; and,

a structure adapted to update the tracing facilities in the server program with tracing facilities stored in the server administrator.

17. The computer system of claim 16, wherein selected ones of the machine executable structures include:

a structure that enables at least one trace flag in a specified tracing facility; and,

a structure that disables at least one trace flag in a specified tracing facility.

18. The computer system of claim 1, wherein selected ones of the machine executable structures include:

a structure adapted to store an identification of each object interface provided by the server program; and,

a structure adapted to store an identification of each object implementation in the server program that implements an object interface.

19. A method for determining and manipulating current configuration information for a server program on a host computer, the method comprising the steps of:

creating an instance of a persistent first object in the host computer;

associating the first object with the server program during installation of the server program, the first object having access to current configuration information of the server program;

receiving by the first object a request from a client for current configuration information about the server program;

executing the first object on the host computer without invoking the server program when the server program is not executing as a process on the host computer to obtain the current configuration information; and

returning the current configuration information to the client.

20. The method of claim 19, further comprising the step of:

storing in the first object current configuration information upon registration of the server program; and

updating selected stored current configuration information each time the server program is executed as a process on the host computer.

21. The method of claim 19, further comprising the steps of:

receiving by the first object a request from a client for current process information about the server program; and

invoking from the first object a second object internal to the server program to obtain the process information.

22. The method of claim 19, wherein the first object is a server administrator object.

23. The method of claim 19, further comprising the steps of:

determining an execution definition for the server program; and,

storing the execution definition in the first object.

24. The method of claim 23, wherein the execution definition includes a program definition, the method further comprising the steps of:

storing a saved program definition for the server program in the first object;

altering the execution definition to provide a new program definition, and,

restoring the saved program definition into the execution definition.

25. The method of claim 23, further comprising the steps of:

storing a hold down value in the execution definition; and

suppressing execution of the server program according to the hold down value when the server program is invoked by a client.

26. The method of claim 19, further comprising the steps of:

invoking a pseudo object to determine if the server program is currently executing;

returning a process identifier if the server program is executing; and,

storing a value indicating that the server program is executing.

27. The method of claim 19, further comprising the steps of:

storing a program definition for an executable application in an execution definition of the server program in the first object; and

interposing the executable application according to the program definition when the server program is invoked by a client.

28. The method of claim 19, further comprising the steps of:

storing in the first object an attribute for enabling or disabling a process for automatically deallocating idle objects within the server;

storing in the first object an attribute for establishing a cycle time for the process;

storing in the first object an attribute for establishing a maximum time interval for which the server program can be idle before the server program is shutdown by the process; and

shutting down the server program when the maximum time interval is equaled or exceeded.

29. The method of claim 19, further comprising the steps of:

storing in the first object an attribute for enabling or disabling logging by an operating system process;

storing in the first object an attribute for identifying at least one log file for storing information; and,

storing in the first object an attribute for establishing a maximum file size for the log file.

30. The method of claim 19, further comprising the steps of:

storing in the first object an interval value indicative of a frequency for the server program to send a signal to the first object to indicate that the server program is currently executing;

storing in the first object a maximum value indicative of a maximum number of signals that the first object may not receive prior to initiating a process to determine whether the server program is currently executing; and

initiating a process from the first object to determine whether the server program is currently executing if the first object does not receive a number of signals equal to or exceeding the maximum number of signals.

31. The method of claim 19, further comprising the steps of:

determining a tracing configuration including at least one tracing facility and a set of trace flags in the server;

storing in the first object the tracing configuration; and

periodically updating the tracing facilities in the server program with tracing facilities stored in the first object.

32. The method of claim 31, further comprising the step of:

selectively enabling at least one trace flag in a specified tracing facility in the first object.

33. The method of claim 19, further comprising the steps of:

storing in the first object an identification of each object interface provided by the server program; and,

storing in the first object an identification of each object implementation in the server program that implements a object interface.

Description Submit all comments and votes

BACKGROUND

1. Field of Invention

This invention relates to the field of object oriented application and operating systems development, and more particularly, to methods and systems for performing administrative operations on object oriented applications operating in a distributed object programming environment.

2. Background of Invention

Client-server computing is the predominant model for the management of computing resources, typically on a network of distributed computers. Servers are computers and application programs executing thereon that provide various functional operations and data, upon request. Clients are computers and applications that request such services. While clients and servers may be distributed in various computers on a network, they may also reside in a single computer, with individual applications providing client or server functions, or both.

In a client-server system based on a object oriented development environment, a client is code that invokes or manipulates an object, and the object that is invoked is the server. A server provides a number of interfaces to clients for invoking various objects within the server that provide functionality requested by a client. Each of the objects may have multiple implementations, or object code that executes the functionality of the code when an instance of the object is created by the server. Thus, a particular interface, when used by a client to invoke an object, will result in the execution of a particular implementation for the object that is invoked. When the server or one of its objects is invoked, the server will operate in accordance with certain configuration information, such as the location of its data directory, the executable pathname, and the like. In a client-server system, it is desirable to be able to determine and manipulate the configuration information for a server available on the network without consuming system resources by invoking the server.

Information about a server can be classified into two categories. Dynamic information arises out of a particular process that is executing a server, such as its process identifier, how many objects are active within the server, and the like. This information is dynamic because it depends on a current executing process which is transient. Static information is information that does not devolve from a particular execution or process. This includes external information such as the identify of the host computer of where the server is installed, its pathname, its execution definition, and internal information, such as the identity and description of the object interfaces and implementations the server provides, and the setup of various application programming interfaces used by the server, such as the identity and configuration of tracing facilities available in the server, log file configurations, and reaping functions.

Conventionally, systems administrators have various software tools for determining the configuration and related information about servers on various computers on a network. However, these administrative tools require that the server be executing as a process for any information to be obtained, and thus require an inactive server to be started up, merely to obtain or manipulate configuration and similar information. Such startup procedures limit the flexibility of the administrative tools, and require unnecessary consumption of computer resources. This is particularly the case where a client needs to determine configuration information for a large number of servers on the network.

Similarly, network managers use network management tools to determine the state of network resources, such as routers, bridges, printers, file servers, disk drives, workstations and the like. With conventional network management tools, such as tools compliant with the SNMP or CMIP standards, individual managed objects are associated with each network device. The network manager can query and configure networked devices through manipulation of the managed object associated with each device. These managed objects however, are limited to conveying information at the device level, and do not query or manipulate object level information for individual processes, particularly for servers running on workstations and similar processing units. For example, SNMP tools currently do not determine the interfaces implemented by a given server on a particular workstation. Thus, these tools do not provide adequate level of granularity for use by a systems administrator of a client-server system built on a distributed object programming environment.

Additionally, SNMP and CMIP tools require the network device associated with each managed object to be operating and available on the network in order for the managed object to determine and configure the state of the network device. Conventional managed objects are unable to automatically startup their associated network devices, and thus if the network device crashes or its otherwise terminated, the managed object and the SNMP tool is unable to provide information about the network device. This is because the managed objects do not have information about the startup configuration of the network devices, as the managed objects operate on the assumption that the associated network devices are already operating. Thus, these tools would also require the servers to be executing in order for any information to be obtained. Similarly, with low level protocols, like RPC, no information is stored about pathnames, configuration information or the like for servers, again, preventing an RPC agent from starting a networked server, or providing process level information.

In conventional systems where the processes created by an application all reside in a common address space, typical system administrative tools require providing an explicit reference to the host machine and the process or processes for which information is requested. In a distributed object programming environment, however, a client invokes a server through an object reference, without having information as to where the invoked object resides in the system, that is, without specifically knowing the computer where the invoked object is stored or where its running. Rather, the client passes the object reference through an object request broker which locates the server, and passes back any output from the server to the client. To the user, the client and server, and any group of distributed objects, behave transparently as an integrated application, even though the objects may be distributed in various computer systems. One standard for the distributed object programming is the Common Object Request Broker Architecture (CORBA), specified by the Object Management Group. In this environment, conventional system administrative tools are shielded from the actual implementation of the server, and do not have a mechanism for obtaining unified access to the internal structure of a server, particuarly its configuration setup. While such information may be available in various objects in various parts of the environment, such as naming services, and the like, there is no unified object that provides this information access efficiently.

Accordingly, it is desirable to provide a method and system for obtaining and manipulating configuration information about servers on computers in a distributed object programming environment without starting up the servers, and where only an object reference to the server is available to clients.

SUMMARY OF THE INVENTION

The present invention overcomes the foregoing limitations by associating with each server a persistent stored object known as a server administrator. The server administrator stores various types of information that can be known about the server without starting up the server, such as its execution definition, name, location, and various internal configuration information, such as the object interfaces and implementations supported by the server. Because the server administrator is persistent, it maintains the configuration information even when the server is not executing. This allows the configuration information to be manipulated by clients via the server administrator, which also provides various methods for changing and updating the configuration information.

The presence of a server administrator simplifies the discovery of what services the server provides through the object interfaces and implementations. In the absence of this information stored in the server administrator, clients would have to start up the server to obtain this information. This process can be extremely time and resource intensive, particularly where a client is attempting to determine this information for every server on the network. Storing interface and implementation information in an object, such as the server administrator, external to the server, means that this information can be obtained without starting up the server.

The server administrator also provides for unified storage of startup configuration for the server, allowing a client to obtain and manipulate the startup configuration for many different servers by accessing their respective server administrators which may be stored in a common naming context.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a system of distributed computers for using server administrator objects;

FIG. 2 is an illustration of the organization of a host computer supporting various servers;

FIG. 3 is a flowchart one embodiment of a process of registering a server with a persistent associated server administrator object;

FIGS. 4a and 4b are data flow diagrams of the call architecture for obtaining information about a server without starting up the server;

FIG. 5 is a flowchart of one embodiment of a process for interposing an application for the server;

FIG. 6 is a flowchart of one embodiment of a process for updating tracing facilities in the server; and

FIG. 7 is an illustration of one embodiment of a user interface for obtaining information about servers and host machines.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to FIG. 1 there is shown a hardware view of a system 100 for determining and manipulating configuration information for servers on distributed computers in a distributed object programming environment. The system 100 includes a number of host computers 101 connected along a network 103. Each host computer 101 includes secondary storage 107 for long term storage of implementation code and data for servers and clients, and the like, an input device 109 and an output device 115 for receiving and outputting commands and data into the system 100, and an addressable memory 113 for storing server and client implementation code during execution by a processor 111. During execution by the processor 111, servers exist as processes in the addressable memory 113. Also coupled to the network 103 are a number of clients 105. Each client 105 is an object executing as a process in a remotely situated computer similar in structure to a host computer 101, or alternatively, existing as separate processes in any of the host computers 101. Each client 105 requests services or data from servers (not shown) in host computers 101 on the network 103. The host computers 101 may be realized by most general purposes computers, such as a SPARCstation.TM. computer manufactured by Sun Microsystems, Inc. of Mountain View, Calif. Any other general purpose computer may also be adapted for use with the invention. Each host computer 101 executes a general purpose operating system, such as Sun Microsystems' Solaris.RTM. operating system. In addition, each host computer 101 is part of an object request broker environment, satisfying the CORBA standards set by the Object Management Group in The Common Object Request Broker: Architecture and Specification, Rev. 1.2, OMG TC Document Number 93-12-43, available by anonymous ftp to omg.org. Other equivalent environments for distributed object systems may also be used. In the preferred embodiment, the object request broker environment is Sun Microsystems' Project DOE (Distributed Objects Everywhere).

Referring now to FIG. 2, there is shown a logical view of system 100, particularly illustrating the configuration of addressable memory 113 in any of the host computers 101 during runtime operation of various servers. The addressable memory 113 of each host computer 101 includes a number of executable objects for performing various functions, including user application functions, such as word processing, database management, graphics design, CAD engineering, software development, financial management, and the like, and operating system functions, such as memory management, resource allocation, storage management, and system accounting information, and network interfacing with remote clients and hosts.

More particularly, host computer 101 includes a number of servers 201, each providing a particular type of functionality to clients 105 distributed on the network 103 (or locally executing in the host computer 101). Each server 201 in the host computer 101 includes a number of objects 209, each of which encapsulates data associated with the object 209 and its state, and executable code for implementing functional operations, or methods of the object 209 on the data or other objects 209. An object 209 is manipulated by clients 105 or other objects 209 through an interface definition that specifies the operations, attributes, and exceptions that an object 209 provides. The objects 209 are distributed objects, distinguished from conventional objects in object oriented programming languages in that the interface of an object 209 is defined in an interface definition language, which is then mapped to an implementation language, such as C++ or C. This allows objects 209 to have multiple implementations in various languages, while still maintaining a consistently defined interface. A client 105 does not have to have any information about the underlying implementation of the object 209, but merely has to have the interface for the object 209. The objects 209 are distributed in that a client 105 may invoke an object 209 existing anywhere on the network 103, including in the address space of a client 105, or any number of host computers 101, by using a naming server 227 and the various BOAs 225 on the host computers 101.

Facilitating communication the clients 105 and the host computers 101 is a basic object adapter 225, or BOA. The BOA 225 comforms to the requirements for the basic object adapter specified in CORBA. The BOA 225 provides an interface for clients 105 to access object implementations of objects 209 included in servers 201 on various host computers 101 distributed on network 103. Object implementations are actual code which implements an object 209. In order to efficiently manage the addressable memory 113 of the host computer 101, the BOA 225 maintains records indicating which servers 201 are active and inactive, and in each server 201, which objects 209 are active or inactive, and which implementations of object methods are also active or inactive. In this way the BOA 225 can readily manage memory resources in the addressable memory 113 on an as-needed basis, allocating memory to active servers 201, objects 209 and implementations, and deallocating memory from inactive entities. The BOA 225 includes a daemon for managing and responding to invocations from clients 105 for objects 209 in the various servers 201 of the host computer 101. The daemon of the BOA 225 automatically starts up a server 201 in the host computer 101 to service an incoming call to an object 209 if the server 201 is not running. The BOA 225 receives a request from a client 105 for an object 209 in a server 201, the client 105 passing the object reference to the BOA 225. The BOA 225 determines whether there is an active implementation of the object 209 or method and if so, the BOA 225 passes the request to the object 209, otherwise, the BOA 225 retrieves the implementation code for the object 209 from secondary storage 107, starts a new process for the invoked object, executing the implementation with the processor 111. The BOA 225 will also manage deactivation of objects 209 and implementations that are no longer being used, or that are explicitly terminated by a client 105 or server 201, reclaiming resources allocated to the object 209 and updating any persistent attributes or data of the object 209.

Coupled to the host computer 101 by the network 103 is a naming server 227. The naming server 227 maintains a name space directory 229 including number of naming contexts, each of which includes a set of name bindings. A name binding is an association between an arbitrary object name, and an object reference uniquely identifying an object 209 within a server 201 and further identifying the server 201, and host computer 101 including the object 209. The naming server 227 provides methods for binding a name to an object reference so that the object 209 associated with the object reference can be accessed from the name, and for resolving names provided by clients 105 in order to provide an object reference to a client 105. With an object reference, a client 105 can directly invoke a server 201 or any object 209 within a server 201. The naming server 227 provides clients 105 with a service that allows access to distributed servers 201 before the client 105 has an object reference. Multiple naming servers 227 may be supported, with clients 105 transparently accessing various naming servers 27 on the network 103. In the preferred embodiment, a naming server 227 is included in each host computer 101, and supports objects 209 within the host computer 101; multiple naming servers 227 then work in conjunction to provides clients 105 with object references for local objects 209.

A factory object 211 may be associated with each object 209, for performing a single method that is called by a client 105 to create a new instance of the type of object 209. The factory object 211 is registered in the name space directory 229 of the naming server 227, which is accessed by clients 105 for obtaining object references. Each factory object 211 includes a static create member function that creates a new object 209 of the type specific to the factory object 211, and returns an object reference to the new object 209. An initialize function is provided in created object 209 to perform any needed initialization on the object's state. Typically there is only one instance of a factory object 211 implementation for each object 209 in the server 201. The instance of each factory object 211 is created when the server 201 is installed in the host computer 201 and registered in the naming server 227. An object 209 need not have an associated factory object 211, for example, where the object 209 is not public and available only to the server 201, or where the server 201 is designed to have a single instance of a particular type of object 209.

For each server 201 on the host computer 101 there is a persistent server administrator 203 object that is instantiated from a server administrator class. Each server administrator 203 maintains configuration information for the particular server 201 associated with the server administrator 203, including information that can be known whether or not the server 201 is executing. This allows system administrative tools to determine the state of the server 201 without having to start up the server 201 as a process in the host computer 101. Throughout the remainder of this disclosure, references to "the server" and "the server administrator" refer to one server 201 and its associated server administrator 203, and it is understood that the functionality described for these respective entities applies to each respective server 201 and server administrator 203 in the host computer 101.

A server administrator 203 is created by a server administrator factory 205 when a server 201 is installed on the host computer 101. A server 201 is installed using conventional installation techniques, such as executing the server 201 using the name of the server 201 along with a--install command line argument. During this execution, the server 201 will create a new server administrator 203. FIG. 3 shows a flowchart of one method by which a new server administrator 203 is associated with a server 201.

First, the server 201 is executed 301 during the installation process. The server 201 searches 303 for an existing server administrator 203 object by accessing the naming server 227 for the host computer 101, and traversing the name space directory 229. The server 201 determines 305 whether a server administrator 203 object exists with the appropriate name. If no associated server administrator 203 object is located in the host computer 101, the server 201 accesses 307 the server administrator factory 205 via an object reference stored in the naming server 227.

The server 201 will invoke 309 the create method of the server administrator factory 205, instantiating a new server administrator 203 object, and obtaining an object reference for the new server administrator 203. The server 201 will then store 311 a binding of the object reference and an object name for the server administrator 203 in the naming server 227; the object name should uniquely identify the server administrator 203 as associated with the particular server 201. Typically the object name will have the following format:

where host.sub.-- computer.sub.-- name is the literal string name provided to the host computer 101 including the server 201, and the server.sub.-- name is specified by the developer of the server 201.

The server 201 will set 313 various execution related configuration information in the appropriate structures of the server administrator 203, as further described below. This information preferably includes the name of the host computer 101 where the server 201 is installed, the name of the server 201 and any aliases for executing multiple instances of the server 201, the path name of any data directory the server 201 uses for storing and accessing local data and resources, and the program definition. The data directory information allows the operating system or other administrative layer to administer the files in the data directory, for example, providing backup services. The data directory is used to issue a change directory command after the server 201 is executed so that the identified directory becomes the current directory. The saved program definition is the pathname, command line arguments, and environmental variables used when the server 201 is started up.

Normally, the program definition is stored in the BOA 225 as a part of the execution definition. In the BOA 225, any change to the program definition is permanent and undoable, and thus previous configurations of the program definition are not saved. However, it is typically necessary to alter the program definition for administrative reasons, for example, to attach a debugger to the server 201 for debugging, or to execute various functions from a shell program. Conventionally, once the