JPH08255141A - Computer network and its operating method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system for tracking a service object inside a computer and the realization method. SOLUTION: Service object location services 28-32 are provided inside first and second computers inside a computer network domain 12. The first computer executes a client application and the second computer executes a service application. The service object location service of the first computer maps the service object to a location inside the second computer by a name. The service object location service inside the first computer also connects a substituting object inside the first computer with a target object by using a remote method activation process and the location of the service object on the second computer provided by the service object location service of the first computer.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an object-oriented programming method in a computer, and more particularly to a system for arranging (tracking) service objects in a computer network and a method for implementing the system.

[0002]

2. Description of the Related Art A computer network has a plurality of computers arranged in an organized manner. In order for a computer network to work, a network operating system and a computer operating system are required for each computer in the network. UNIX and Windows NT
Is an example of a known operating system. These operating systems include versions that implement network functions and versions that run on stand-alone computers. Network protocols such as TCP / IP implement the interface between operating systems.

Object-oriented programming techniques are
It provides the basis for configuring application programs for computer systems. An object is defined as data associated with a code packet that performs a particular function or service. Objects are combined to form an application program. AT & T Cooperative Framework (COOPERATIVE FRAMEWORKS)
Provides a library of classes from which objects are created to facilitate the development of application programs.

The distributed processing framework class library provides remote method invocation (RMI) functionality to AT & T cooperative framework programmers for client-server and peer-to-peer.
It provides an object-oriented mechanism for configuring peer systems. RMI is an application
Allows a method or function of an object in a remote system or another process to be invoked as if the object were local to the calling application. The basic mechanism used to implement RMI is an object pair known as a surrogate and target. These objects respectively represent the client part and the server part in the distributed object. Surrogates and targets are co-operative frameworks CfSurrogate and C
The decentralized nature of an object realized by deriving a new class from the fTarget base class includes a surrogate object that is the initiator and a target that is the corresponding object. The target object resides in the CfService object that represents the available services.

The RMI process is described in "NCR Proposal: Object Request Brokers by the Object Management Group," Volume 1, February 25, 1991, as part of the CORBA 1.0 architecture standard.

[0006]

A program composed of a combination of objects is designated to be executed on a stand-alone computer or by a computer in a computer network. When this kind of application program is executed in a computer network, it is desirable that a plurality of simultaneous accesses to the services realized by this application program are possible.
Access requires knowledge of where the service is located, that is, a means of translating into a network location that represents the name of the service object.

In another system, the naming or location service is separate from the network transport mechanism, and the naming service that translates the service name into a location is first invoked and then given that service. It relies on the application program to call the transport mechanism individually to bind to the location. Examples of other naming services include X. 500 directory, and DCE (Distributed Computing Environment) cell directory service. If the application uses a separate directory service (ie, naming service), the application itself must support name-based locating services. If the located service becomes unavailable, the client application is notified, and the client application uses the naming service to find another location that provides the desired service, Connect with this new location.

Thus, it is tightly integrated with the object transport mechanism, eliminating the complexity of tracking the services offered by an application, and yet another service in which the same service as the one that suddenly becomes unavailable is present. There is a need for a service object locating system and a method of implementing the same that provides a high degree of reliability to the system by automatically switching to a location.

[0009]

In accordance with the present invention, there is provided a system and method for tracking (locating) service objects within a computer network. The system according to the invention comprises service object location services in first and second computers in a computer network domain. The service object location service of the first computer has a name service that maps service objects by location to locations in the second computer. The service object location service of the first computer is a proxy object in the first computer by utilizing a remote method invocation process for the location of the service object on the second computer provided by the service object location service of the first computer. To the target object that exists in the service object.

The first computer executes a client application having a client object. Quarantine objects contain proxy objects. The second computer executes a service application having a service object. The service object contains the target object.
The service object location service of the first computer provides the location when the service object is requested by the proxy object by name only.

The service object location service of the second computer shares a list of services in its computer domain with the service object location service of the first computer. If the first computer is the primary server, its service object location service also has a list of services in other domains.

Accordingly, one object of the present invention is to provide a system and method for locating service objects within a computer network.

Another object of the present invention is to provide a service object locating system and method that is highly fault tolerant (ie, reliable).

Another object of the present invention is the existing object transport mechanism (eg, the distributed processing framework of the AT & T Cooperative Framework).
It is an object of the present invention to provide a system and method for locating a service object in a computer network that can be integrated with and is not a separate function that must be invoked by an application to retrieve a service.

[0015]

BEST MODE FOR CARRYING OUT THE INVENTION As shown in FIG. 1, a network unit 10 according to the present invention includes domains 12, 14
, And has a plurality of domains connected to each other. A domain is defined as a cluster of servers and services and is not restricted to local area networks (LANs) or other network architectures. Domains 12 and 14
Has primary servers 16 and 18 and auxiliary or backup servers 20-22 and 24-16, respectively. The network unit 10 preferably uses a network operating system such as UNIX or Windows NT and TCP / IP. TCP / IP is used to remove the structural limitation of the network.

The servers 16-26 each have a Service Object Location Service (SOLS) 28 within the random access memory (RAM) of their respective servers.
Execute -38. The SOLS 28-38 implements SOLS between the servers 16-26 as a whole.

The primary purpose of SOLS 28-38 is to provide service location information quickly. For performance reasons, the service information is currently RAM4
Stored at 0-50. SOLS 28-38
Service name and corresponding domain 12 and 14 respectively
Manages service registries 64-74, including the respective locations registered with. In addition, the registries 64 and 70 of the primary servers 16 and 18
Manages service information regarding all domains of the network unit 10. Thus, the location of a particular service is SOLS 28 by searching its corresponding service registry and then the service registry of the primary server in its domain.
Can be found by any of -38.

The service is the service registry 64-7.
It is one of the features of the invention that the mapping in 4 allows access by name rather than its location. This mapping maps the name of the service to a physical location accessed as a network address.

The fact that a plurality of service subjects are executed on different servers is another feature of the present invention. This feature provides a fault tolerant (ie reliable) system.
Services can be moved, which allows flexibility in server management. Access to services is not lost while the server is undergoing maintenance.

The domain information is preferably fixed disk drives 52-62 at each of the servers 16-26.
It is maintained in the domain configuration file in. Each domain configuration file defines a domain and the members that belong to that domain.

Domain configuration file 5
2-62 has a standard Microsoft Windows initialization file (.ini) format and contains a domain name and a list of servers belonging to domains 12 and 14. The list of servers in each of domains 12 and 14 is ordered. For example, the first server in domain 12 is primary server 16, followed by auxiliary servers 20 and 22. The order of the auxiliary servers 20 and 22 is the primary server 16
Defines which of the servers 20 and 22 will take over the primary server in the event of a failure. When the auxiliary server takes over the primary server, its role is to manage service information for all domains in the network unit by periodically communicating with other primary servers on other domains.

Domain configuration file 5
The format of 2-62 is as follows: [Domains] Domains = domain1, domain2 domain1 = server1, server2 domain2 = server3, server4, server5

Here, "server1" is the primary server for "domain1" (domain 12), and "server3" is "
It is the primary server for domain2 "(domain 14). If server3 goes down, server4 in domain2
And server5 takes over the primary server in that order.

The primary servers 16 and 18 periodically download service locations from each other. The auxiliary servers 20-22 and 24-26 are arranged to periodically download the service location from the primary server of their respective domain if higher reliability and data inconsistency are required. It The auxiliary servers 20-22 and 24-26 "ping" their respective primary servers 16 and 18 for the purpose of determining whether the primary servers 16 and 18 are functioning. If the primary server was not working, the servers 20-22 and 24-26 would
Corresponding configuration file 52-
Ping the auxiliary server listed at 62. The default value for the download interval is preferably every 15 minutes at startup, but can be adjusted using the system initialization file.

The operation of the SOLS 28-38 will now be described from the programmer's point of view according to FIGS. 3 and 4.
For the sake of brevity, the two servers 16 and 20
And only the respective SOLS 28 and 30 are shown.

FIG. 3 starts with START 80. In step 82, SOLS 28 registers service object 100 in registry 64 of server 16 (FIG. 4).

The service objects in the service application 112 are constructed using the following format related to the distributed processing framework of the AT & T Cooperative Framework: CfService :: CfService (const char * name, DWORD stack
= 32768, WORD usrVar = 0); CfService :: CfService (const char * name, SERVICESTAT
E state, DWORD stack = 32768, WORD usrVar = 0);

By constructing a CfService object, an entry is added to the registry 64 with the location information needed to connect to that service. The registry 64 knows how to distribute this information to other servers in the domain. The target name is not registered in the registry 64. It is not needed to connect with that Service Object. Only the location of the service is needed. This allows a very large number of target objects to be registered without affecting the performance of SOLS 28-38.

When the CfService object is destroyed, the registration information is deleted from the server 16-26. S
The OLS 28 handles the abnormal termination (crash) of the service object, and handles the CfService from the network unit.
Delete objects automatically.

In step 86, if SOLS 34 (FIG. 2) on server 18 has searched SOLS 28 on server 16 (after the normal time interval), SOLS 28.
Notifies the SOLS 34 in the server 18 of the domain 14 that the registered service object is available from the server 16.

In step 88, if the SOLS 30 is arranged at start-up to periodically download the local domain service information in order to achieve higher reliability and data consistency.
Updates registry 66 to include the service objects available from server 16.

In step 90, client object 104 receives a request for service 100 by name from client application 110 (FIG. 4) running on server 20.

In step 92, the client object 10 of the client application 110 is
4 constructs a proxy object 106 to the service requested by name only (FIG. 4).

Proxy object 1 for the named service and its target object
Due to the unspecified configuration of 06 location, SOLS
30 initiates a search for the location of its service object (here service object 100).

In step 93, determining the location includes configuring another proxy object 108 by the client object 104 and instructing a remote method invocation (RMI) process between the proxy object 108 and the SOLS 30 in step 94. Has been. This second proxy object 108 is automatically configured by the distributed processing framework of the AT & T Cooperative Framework for the purpose of resolving the location of named service objects. There is no need for the user to connect the proxy object directly to SOLS. The following configuration functions are used to create a proxy object: CfSurrogate :: CfSurrogate (const char * target, const
char * svc, const char * mach = (char *) NULL, const c
har * dom = (char *) NULL, WORD usrVar = 0);

For the purpose of triggering a call to SOLS, the user may generate a CfSurrogate configuration call with a NULL argument instead of serverName "mach". For example, to connect to a target on a server in a domain, CfSurrogate (targetName, svcName, / * mach * / (char *) N
ULL)

The best service search algorithm is used to find the location of the target object. SOLS 30 first attempts to find a matching service on local server 20, then attempts to find a matching service on any of servers 16 and 22 in local domain 12, and finally a server in remote domain 14. Attempt to find a matching service on any of 18, 24, and 26.
However, SOLS only contacts up to two registries. That is, the local server 20
The above registry 66 and the registry 64 on the primary server 16 if a service object location on the server in the remote domain is required.

To configure the target object on any server in the specified domain, the following command is used: CfSurrogate (targetName, svcName, / * mach * / (char *) N
ULL, domainName);

SOLS 30 attempts to find this target and service only in the defined domain.

To connect to one of the many registered principals for a service on a specified server in a specified domain, the following command is used: CfSurrogate (targetName, serverName, svcName, domai
nName);

If both the server name and domain name of the requested object are specified, the local SOL
SOL on the specified domain and server, not S
S is contacted. This allows the local SO
The rejection of connections for services whose location in the LS registry has not yet been updated is prevented. The second proxy object 108 directs the RMI process to the SOLS on the server where the requested service resides, from which of some possible registered principals for the named service object on that server. Get a network address for one of them. The first proxy object 106 then directs the RMI to the requested service and target objects on the defined domain and server.

SOLS 30 returns the location information needed to construct the CfSurrogate object 106. When the SOLS 30 fails to search for the matching service object and target object, the CfSurrogate object becomes invalid. The user can then use "CfSurroga" to verify that SOLS 30 was able to find the location and that CfSurrogate object 106 was properly bound to the appropriate target object.
You must call the te :: connected () "method.

The same procedure uses CfSurrogate :: connect ()
Applied when using the method: void CfSurrogate :: connect (const char * target, cons
t char * svc, const char * mach = (const char *) NULL,
const char * dom = (const char *) NULL);

Here, the "mach" position has been nulled, which triggers the SOLS 30 to find an appropriate target object that is exactly the same as the CfSurrogate configuration function.

Creating the CfSurrogate object 106 is not directly setting up a session between the proxy object 106 and the target object 102. These two objects are only connected. When CfExchange (a machine-to-machine object stream sequence) is first created, an attempt is made to send data to the target object 102. In the event of an error in data transmission indicating that the server 16 is unreachable, SOLS 30 attempts to return another location from the registry 66.

No user intervention is required to cause SOLS 30 to find a new location. Finding a new location if the previous location fails CfExchange is a fully automated task.

In step 96, SOLS 30 checks registry 66 and selects the server on which the service is running. It is assumed here that SOLS 30 selects server 16, but another server offering the same service may also be selected.

In step 98, the client object 104 receives the service from the server 16 to the server 20.
Directs the RMI process between the proxy object 106 and the target object 102 for provision to the application program executing above.

The above description relates to one embodiment of the present invention, and those skilled in the art can think of various modifications of the present invention, but all of them are within the technical scope of the present invention. Included in.

[0050]

As described above, according to the present invention, it is tightly integrated with the object transport mechanism, eliminating the complexity of locating the services provided by an application, and suddenly becoming unavailable. There is provided a service object locating system and a method for realizing the same, which gives a higher reliability to the system by automatically switching to another location where the same service exists.

[Brief description of drawings]

FIG. 1 is a block diagram showing a network unit used in a system according to the present invention.

FIG. 2 is a block diagram showing a network unit used in the system according to the present invention.

FIG. 3 is a flowchart showing the operation of the system according to the present invention.

FIG. 4 is a block diagram showing components involved in connecting a client application to a service.

[Explanation of symbols]

10 network unit 12, 14 domain 16, 18 primary server 20, 22, 24, 26 server 28, 30, 32, 34, 36, 38 service object location service 40, 42, 44, 46, 48, 50 RAM 52, 54 , 56, 58, 60, 62 Configuration file 64, 66, 68, 70, 72, 74 Registry 100 Service object 102 Target object 104 Client object 106, 108 Proxy object 110 Client application 112 Service application

Claims (2)

[Claims] 1. A first computer in a computer network for executing a client application having a client object and having a service object location service, wherein the previous client object includes a proxy object and a service having a service object. A second computer running an object and having a service object location service connected to the service object location service of the first computer, wherein the service object comprises a domain comprising a target object And the service object location service of the first computer stores the service objects by name. A name service that maps to a location in a second computer, the service object location service of the first computer connecting the proxy object and the target object with a remote method invocation process and the service object location of the first computer. Connecting with the location of the service object on the second computer provided by a service, the location being the service of the first computer when the service object is requested only by the name by the proxy object. A computer network characterized by object location services. 2. A method of locating a service object in a network entity, comprising: (A) storing a service object including a target object in a first computer within the network entity; Mapping the service object by name by a second computer to a location in the first computer; (C) executing an application program containing a client object by the second computer; (D) the second computer. Configuring a proxy object in the client object with a service object location service in (E) the service object with the proxy object Requesting only by name, (F) providing the location of the service object to the proxy object on the second computer by the service object location service in the second computer, (G) remote Connecting the proxy object in the second computer with the target object in the first computer using a method invocation process and the location of the service object on the first computer by the second computer. A method for operating a computer network, comprising: