KR20010034515A - Method and system for facilitating access to a lookup service - Google Patents

Abstract

A method and system are provided that facilitate access to a service through a lookup service. Lookup services define network directories of services and store references to these services. A client requesting the use of a service on the network accesses a lookup service that returns stub information that facilitates user access to the service. The client uses this stub information to access the service.

Description

METHOD AND SYSTEM FOR FACILITATING ACCESS TO A LOOKUP SERVICE}

In modern "enterprise" computing, interfaces to many personal computers, workstations, and other devices such as mass storage systems, network printers, and public telephone systems are typically interconnected to one or more computer networks. Personal computers and workstations are used to perform processing in conjunction with data and programs that users can store in network mass storage subsystems. In such a configuration, a personal computer / workstation that acts as a client typically downloads data and programs from a network mass storage subsystem for processing. The personal computer or workstation also allows the processed data to be uploaded to a mass storage subsystem for storage, to a network printer for printing, to a telephony interface for transmission over a public telephone system, and the like. In such a configuration, the network mass storage subsystem, network printer, and telephony interface act as servers because they are available to service requests from all clients in the network. By configuring the network in this way, the server is easily used by all personal computers / workstations in the network. Such networks can spread over a fairly wide range of personal computers / networks interconnected by communication links such as wires or optical fibers.

In addition to downloading information from the server for processing, the client processes the program and, in conjunction with any "parameter" information provided by the client, remotely processes the processing by the server computer of certain routines and procedures (generally "procedures"). Can be initialized with After the server has processed the procedure, it provides the client with the results of the processing that can later be used for that processing operation. Typically, in such a "remote procedure call", the program will use a local "stub" that, when invoked, sends a request to the server that implements a particular procedure, receives the results, and provides it to the program. . Conventionally, stubs must be compiled into a program if the information needed to call a remote procedure must be determined at compile time rather than each time the program is executed. Since the stub available to the client's program is static, the closest thing that can be determined for the program when it is compiled should be provided. Thus, errors and inefficiencies may occur due to inconsistencies between the stubs provided in the program and the remote procedure requirement invoked when the program is executed.

The present invention relates generally to data processing systems, and more particularly, to a method and system for facilitating access to a lookup service.

The invention has been particularly pointed out in the claims. The above and other advantages of the present invention can be better understood by referring to the following detailed description with reference to the accompanying drawings.

1 is a diagram of an embodiment of the present invention that obtains "stub" information that allows a program running in one address space to invoke the processing of a remote method or procedure in another address space, dynamically loads it, and facilitates its use. A functional block diagram of a computer network including a structure constructed according to.

2 and 3 are flow charts illustrating operations performed by the structure shown in FIG. 1, FIG. 2 illustrates operations performed in connection with obtaining stub information and dynamically loading it, and FIG. 3 a remote method. Or an operation performed in connection with the use of stub information to invoke the processing of a procedure.

4 illustrates a lookup service according to the present invention.

5 is a flow chart illustrating a method for adding a stub to a lookup service according to the present invention.

6 is a flow chart illustrating a method for retrieving stubs from a lookup service by a system in accordance with the present invention.

A program running in one address space invokes the processing of a method or procedure in another address space to obtain stubs and dynamically execute stubs that are executed by the program when needed and rather than statically determining when the program is compiled. Novel and improved systems and methods are provided that facilitate loading with. Indeed, the stub to be loaded can be obtained from the resource providing the remote method or procedure, and the stub can accurately define the calling condition of the remote method or procedure. Because stubs can be found and loaded dynamically while the program is running, rather than statically determined when the program is compiled, run-time errors that can result from a mismatch between the provided stub and the preconditions of the method or procedure being called. And inefficiency can be minimized. In an alternative embodiment of the invention, the stub is obtained from a lookup service that provides access to the subs defined in the lookup service.

In summary, methods and systems in accordance with alternative embodiments of the present invention facilitate access to services via lookup services. Lookup services define network directories of services and store references to these services. A client requesting the use of a service on the network accesses a lookup service that returns stub information that facilitates user access to the service. The client uses this stub information to access the service.

1 illustrates a configuration of a computer network 10 that includes a configuration that facilitates dynamic loading of "stub" information that allows a program running in one address space to remotely invoke the processing of a method or procedure in another address space. Schematically, this method and procedure here represents a network service. Referring to Fig. 1, the computer network 10 includes a plurality of client computers 11 (I) to 11 (N) (collectively referred to as reference numeral 11 (n)), and a plurality of server computers 12 (I) to 12 (M)) (collectively referred to by reference number 12 (m)). All of these are interconnected in a network represented by communication link 14. In addition, the network 10 may include at least one name server computer 13 whose purpose may be connected to the communication link 14 described below. As conventionally, at least some of the client computer 11 (n) is in the form of a personal computer or computer network, each of which is typically a system unit, a video display unit, and an operator input device such as a mouse and a mouse (both of them) (Not shown). Server computer 12 (m) and naming computer 13 also typically include a system unit (not shown), and may also include a video display unit and an operator input device.

The client computer 11 (n), server computer 12 (m) and name server computer 13 are all conventional storage program computer architectures. The system unit generally includes processing, memory, disk and / or tape storage devices and mass storage devices, and network interface devices 15 (n) and 16 (m) for interfacing each computer to the communication link 14. Other elements (not shown separately) included. The video display unit enables the computer to display processed data and processing status to the operator, and the operator input device allows the operator to input data and control processing by the computer. Computers 11 (n) and 12 (m) and 13 are informed via respective network interface devices 15 (n) and 16 (m) with respect to each other via communication link 14 in the form of messages. Send it.

In one embodiment, network 10 is a computer 12 (m) in which one or more computers shown in FIG. 1 operate as servers, and as computer 11 (n), other computers shown in FIG. 1 as clients. It consists of a working "client-server" configuration. In one aspect, one server computer 12 (m) may store a copy and data of a program available for retrieval by the client computer via communication link 13 for use in its processing operation as a "file server". It can include a mass storage device. At times, the client computer 11 (n) may also store data on the server computer 12 which can later be retrieved by it (the client computer that has stored the data) or by another client computer for use in its processing operations. have. In addition, one or more server computers 12 (m) perform any processing operation in response to a remote request from client computer 11 (n) as a "computer server" and, in the next processing, process those processing results (i.e., It returns to the requesting client computer 11 (n) for use by the requesting client computer 11 (n). In either case, the server computer may generally be similar to the client computer 11 (n) comprising a system unit, a video display unit and an operator input device, and used for data processing operations by the operator in a manner similar to the client computer. It may be possible. Optionally, at least some of the server computers may include processing only, memory, mass storage and network interface elements for receiving and processing retrieval, storage or remote processing requests from client computers, and the generation of responses thereto. Can be. The client computer 11 (n) may also perform the described operations as performed by the server computer 12 (m), and similarly the server computer 12 (m) may also perform the client computer client 11 The operations described may be performed as performed by (n)).

The network represented by the communication network 14 may be digital, for example, in a local area network (LAN) and broadband network (WAM), public telephone systems, the Internet, and various components that are typically maintained within individual businesses. The client computer 11 (n), the server computer 12 (m), and the name server computer 13, including other networks capable of transferring data, can communicate. The network may use any of a number of communication media, including, for example, wireless, optical fiber, wireless links, and / or other media for carrying signals representing information, typically among the various computers shown in FIG. Can be implemented. As described, each of the computers typically includes a network interface that connects each computer to the communication link 14 and enables transmission and reception of information therethrough.

The system according to the invention facilitates the acquisition and dynamic loading of "stub" information, so that programs operating in one address space are called by remote methods in different address spaces that can be loaded on the same computer or on different computers. Or you can call the procedure's processing. "The Java ^TM Language Specification" (Addison-Wesley, 1996) by James Gosling, Bill Joy, Guy Steele, incorporated herein by reference and processed in connection with the execution environment provided by a Java virtual machine (hereinafter Reference is made to a program provided in the Java ^TM programming language, as described in "Java ^TM Language Specification". The Java virtual machine is also described in "The Java Virtual Machine Specification" (Addison-Wesley, 1996) by Lindholm and Yellin, which are incorporated herein by reference. As described in the Java Language Specification, programs in the Java programming language define "classes" and "interfaces". Classes are used to define one or more methods or procedures, each of which can be called as a reference to an interface. A class can be associated with and extend a "super-class", in this respect unifying all the interfaces and methods of a super-class, and also including ancillary interfaces and / or methods. A class may also have one or more super-classes (and thus include the super-classes of each of its sub-classes), each super-class uniting and possibly extending their respective super-class.

An interface provides a mechanism by which a set of methods can be declared. In this regard, the interface identifies each method declared by the interface by name, for example, and the argument (s) to be provided to the method is the data type (s), the data of the return value to be returned by the method. Identifies the type (s) and the identifier for the exception that may be thrown during processing of the method. A class indicates that a particular interface can be implemented, and that in this respect the connection contains program code that will be used to handle all the methods declared in the interface. Also, different classes will have the same code that they can implement the same interface, and that each will have program code that will be used to handle all the methods declared in the interface, but the program code provided to each class for use in processing the method is the same method. This is different from the program code provided for other classes used to handle. Thus, the interface provides a mechanism by which a set of methods can be declared without providing an indication of the procedure to be used to handle any method. An interface can be declared independent of the methods that can be called using the interface or the specific class that implements the method. In this sense, the class that invokes the method, and the class that actually implements the method, do not need to share a common super-class.

During processing of the Java program, as described in Java Virtual Machine Name, the client computer 11 (n) provides an execution environment 20 for interpreting the Java program. The Java virtual machine includes a class loader 21 under the control of the control module 19, and while the program is running, an execution environment of a program for executing an instance of the class collectively shown in FIG. You can link to In this operation, the control module 19 effectively enables the class loader to retrieve non-instantiated classes, collectively indicated by reference 23, and assigns them as class instances 22 to each class ( As the method implemented by 23 is called, it links to the address space of the execution environment at runtime of the Java program. In addition, the class loader 21 may discard any instance 22 of the class in order not to be needed or to conserve memory. If the class instance 22 has been discarded, it can later be reloaded by the class loader 21 later if necessary.

The system according to the present invention facilitates remote invocation of methods implemented by classes on server computer 12 (m) by a program running in execution environment 20 by client computer 11 (n). Provide configuration. In the execution of the method, server computer 12 (m) will also provide an execution environment 24 for processing Java methods under the control of control module 28. In this operation, the Java virtual machine providing the execution environment 21 dynamically links an instance of class 26, under the control of the control module 28, to allow the method to be processed in the execution environment 24. Class loader 25 (which may be similar to class loader 21), and instances of other classes (collectively denoted by reference numeral 26) that may be needed to handle remotely invoked methods. In this operation, the control module 28 retrieves the non-instantiated class for the method to be called by the class loader 25 from a plurality of non-instantiated classes collectively represented by reference number 27 and initializes (ie Non-instantiated classes that provide methods, and efficiently enable them to link to the execution environment as class instances 26. In addition, the class loader 25 may discard the class instance 26 when the processing of the method is finished. It should be appreciated that if the class instance 26 has been discarded then it can be reloaded later by the class loader 25 as needed.

If provided, the structure of the name server computer 13 will generally not be described separately as it is similar to that of the server computer 12 (m).

In order to facilitate the remote invocation of the method, the control module 19 of the execution environment 21 of the client computer executes the execution environment 21 in which the various class instances 22 including the class instance invoking the remote method are being processed. It utilizes one or more stub class instances, which are provided as part of and are collectively represented by reference numeral 30. Each stub class instance 30 is an instance of a non-instantiated stub class 31, where the server computer 12 (m) allows the server computer 12 (m) to be " exported " It is possible to maintain the de-instantiated class 27 and the various class instances 26 that the computer 12 (m) makes available to the client computer 11 (n) for use in remote invocation of the methods provided by it. The de-instantiation stub class 31 provides declarations for the complete set of interfaces for a particular remote de-instantiation class 27 that implements the remote method to be invoked, and also provides access to the remote method (s) implemented by the remote class. Provide or call a method that facilitates When it is initialized and provided to the execution environment 20 of the client computer 11 (n) as a stub class instance 30, the non-instantiated stub class 31 is a control module of the execution environment 20 of the calling Java program ( By providing the information required by 19), when a remote method implemented by an associated class is called by a Java program executing in a particular execution environment, the remote method will be processed and the return value (s) will be passed to the calling Java program. Will be provided. In one embodiment, the configuration in which the stub class instance may be provided to the execution environment 20 is similar to that described in the patent application by Waldo et al.

Incidentally, the server computer 20 is a skeleton 20 identifying the particular classes and methods exported by the server computer 12 (m), and how to load each class and provided by it. Provides information about whether to initiate the processing of a particular method. Incidentally, the server computer 12 (m) includes a lookup service 400 for registering a service on a network. The lookup service 400 is described below.

When a class instance invokes a remote method maintained by the server computer 12 (m), it is used for the various parameters to the stub class instance 30 for the remote method, that is, what value the remote method will use in its processing. Will give you the value of. If the remote method is implemented on the same computer as the calling Java program, when the calling Java program invokes the remote method, the computer establishes an execution environment similar to the execution environment 20 and loads the class loader of the execution environment. Able to load and initialize a class that implements this method as a class instance similar to class instance 22, and to handle the remote method using the values of the parameters provided by the class instance invoking the remote call. After the processing of the method completes, the execution environment in which the remote method is processed will provide the result to the stub class instance 30 for the remote method called to provide to the particular class instance 22 that invoked the remote method. .

If computer 11 (n) and server computer 12 (m) run on different physical computers, similar operations will be performed. In this case, in response to the remote call, the client computer 11 (n), which processes the calling class instance 22, controls the control module 19 for the execution environment 20 for the calling class instance 22. Under the control of a), through a network represented as the communication link 14, using a suitable stub class instance 30, the remote method enables the server computer 12 (m) to implement a class that implements the remote method. Establish an execution environment 24 for the server, and communicate with a server computer 12 (m) that uses a class loader 25 to load an instance of the class as a class instance 26. In addition, the client computer 11 (n) will also provide the server computer 12 (m) with any necessary parameter values using the appropriate stub class instance 30 via the network 14. The server computer 12 (m) then processes the remote method using the parameter values provided in this way and is transmitted over the network to the client computer 11 (n), in particular to the appropriate stub class instance 30. Will result in result (s). After the client computer 11 (n) receives the result value (s) from the network, it will supply them to the class instance 22 that calls for its processing.

In either case, when the control module 19 of the execution environment 20 of the client computer determines that a reference to the remote object has been received, if it determines that the stub class instance 30 does not exist when receiving the reference, This is for example an attempt to obtain a stub class instance 30 from a server computer 12 (m) that implements a remote method, and for the class instance 22 that the stub class instance 30 calls, the execution environment ( Enable to load dynamically in 20). References to remote objects may be received, for example, as return values of other remote method calls or as parameters received during other remote method calls. The stub class instance can be dynamically loaded into the execution environment in a manner similar to that used to load class instances 22 in the execution environment 20. The execution environment 20 is provided with a stub class loader 33 which, under the control of the control module 19, attempts to find and load the stub class instance 30 as required by the class instance 22 processed in the execution environment. . The location of the particular server computer 12 (m) that maintains the class that implements the method to be called remotely can be included in the call from the invoking class instance or other mechanism maintained by the client computer 11 (n). It may be known to the stub class loader 33 (not shown).

However, if the stub class loader 33 is not informed which server computer 12 (m) maintains a class that implements a method that can be called remotely, then the server name computer 13 can be used to identify the server. Provide identification. This identification may have any identifier that may be used to identify server computer 12 (m), or other resources available on network 14 and to which server computer 12 (m) may respond. . For example, the identifier shown may include a network address identifying a server computer and / or a resource, or if the network 14 is or includes the internet, for example to identify a resource available over the internet. It includes an identifier for the World Wide Web that can provide an identification or "Uniform Resouce Locator" that provides a unified mechanism. The server computer 12 (m), which implements the remote method in response to a request from the client computer client 11 (n), is configured to allow the client computer client 11 (n) to enable the remote call to be initiated. It provides a stub class instance 30 that can be loaded into the execution environment 21.

As mentioned above, if the stub class loader 33 does not know which server computer 12 (m) implements a remote method that can be invoked (thus, which computer provides stub class code for remote calls) Which, under the control of the control module 19, obtains an identification from the nameserver computer 13. In this operation, stub class loader 33 can use the previously provided default stub class provided for use in such a case. When used by a Java program, the default class stub enables the computer processing the calling Java program to communicate with the nameserver computer 13 to obtain information that can be used to invoke the remote method. This behavior is essentially the same as invoking a remote method to be handled by the nameserver computer 13, including parameters identifying the class and method to which the remote method is to be called remotely, enabling the nameserver computer 13 Identification of a server computer 12 (m) capable of handling methods for the requesting client computer client 11 (n) and for communicating with the server computer 12 (m) and invoking specific methods. Have them provide other information that may be possible. Resources (such as classes and methods not shown) that the name server computer 13 is "exported" resources, ie classes and methods available to the client computer client 11 (n) connected to the network 14, and exported resources. It will be appreciated that it will retain information such as the identification of the particular server computer 12 (m) that provides such resources useful to the client computer 11 (n) for use.

It will be appreciated that the name server computer 13 can create and maintain exported resource tables in a variety of ways known in the art. For example, the name server computer 13 may periodically broadcast a request for the exported resource information through the network 14 to which various server computers 12 (m) that can maintain the exported resources can respond. Can be. In this case, the name server computer 13 may establish its exported resource table based on the response from the server computer 12 (m). Optionally, each of the various server computers 12 (m) capable of maintaining the exported resources may periodically broadcast information about the exported resources that it maintains, and the name server computer 13 may be from the server computer. Based on the broadcast of, the exported resource table can be updated. In addition, the exported resource table of the nameserver computer may be set by the system administrator and may be fixed until the operator updates it.

In either case, the information provided by the name server computer 13 in response to the request initiated by the default stub may, for example, provide a computer 12 (m) that can provide a class that implements the remote method to be called. Identification, specific information requiring the computer (i.e., the computer executing the remote method) to provide the requested stub class code, and the like. After receiving the information from the name server computer 13, under the control of the control module 19, the computer client 11 (n), which processes the calling Java program, uses the information to execute the computer (i.e., the remote method). By communicating with the executing computer), the stub class can be obtained, and then the method can be called as described above.

Against this background, the client computer 11 (n), server computer 12 (m), and a name server associated with obtaining and dynamically loading stub class instances when a reference to a remote method is received as needed. Operations performed by (13) will be described with reference to the flowchart described in FIG. Further, operations performed by the client computer 11 (n) and the server computer in association with remote invocation of the method using a stub class instance will be described with reference to the flowchart shown in FIG. Referring first to FIG. 2, upon receiving a reference to a remote method, the execution environment control module 19 determines whether there is an appropriate stub class instance in the execution environment 20 to facilitate invocation of the remote method initially. (Step 100). If the control module 19 determines that such a stub class instance 30 for the remote method exists in the execution environment, it may include other actions (step 101). However, if the control module 19 determines in step 101 that such a stub class instance is not present in the execution environment 20 for the remote method, the control module 19 may turn the stub class loader 33 on. Will attempt to find and load the stub class instance 30 for the class to handle the remote method. In this case, the control module 19 is initially responsible for the resource locator identifying the server computer 12 (m) where the call from the class instance 22 or the other resource holding the class for the method to be called. It will be determined whether or not such a resource locator is provided to the stub class loader 33 (ie, the control module 19) or the stub class loader (step 102). If the control module 19 responds affirmatively in this step, the stub class loader 33 is enabled, initiating communication with the identified server computer 12 (m) and the stub class for the class and method to be called. Proceeding to step 103, obtaining an instance (step 103). When the stub class loader 33 receives the stub class instance 30 from the server computer 12 (m), it causes the stub class instance 30 to initialize the remote method call in step 100, the class instance 22. Will load into the execution environment 20 for. After the stub class instance 30 for the referenced remote method is loaded into the execution environment, the method will be invoked as described below with respect to FIG. 3.

Returning to step 102, if the control module 19 calls a resource locator that identifies the server computer 12 (m) that the call from the class instance 22 maintains, or another resource that maintains the class for the called method. If not included, (ie, control module 19) or stub class loader 33 determines that such a resource locator has not been provided, a "class not found" exception may be displayed, At this time, the control module 19 may call the exception handler. The exception handler may perform any of a number of recovery operations, including, for example, merely notifying the control module 19 that the remote method could not be found, to determine subsequent actions.

Optionally, the control module 19 may use a resource locator from the nameserver computer 13, or network 14 (collectively the nameserver in FIG. 1), using a call, for example a default stub class instance 30. May attempt to obtain other resources provided by the computer 13). The call to the default stub class instance 30 may include the identification of the class and method to be called, and the name of the nameserver computer 13m. Using the default stub class instance 30, the control module 19 enables the computer client 11 (n) to enable communication with the name server computer 13 to maintain the classes and methods to be called. The identifier for the server computer 12 (m) is obtained (step 110). Communication from the default stub class instance 30, if associated with the class and method to be called remotely, the method must enable the name server computer to provide an identification for the server computer 12 (m), or Optionally, it will respond to a remote method call by providing an indication that no server computer 12 (m) is identified as being associated with the class and method. During the communication phase in step 110, the default stub class interface 30 will provide, as parameter values, an identification of the class and method to be called.

In response to communication from the default stub class instance 30, the nameserver computer 13 processes the request as a remote method (step 111), and the resulting information is associated with the class and method to be invoked remotely. An identification of the server computer 12 (m), or optionally, an indication indicating that no server computer 12 (m) is identified as being associated with the class and method. After ending the method, the namesub computer 13 will initiate communication with the default stub class instance 30 to provide result information to the default stub class instance 30 (step 112).

After receiving the result information from the name server 13, the default stub class instance will pass the result information to the stub class loader 33, under the control of the control module 19 (step 113). The stub class loader 33 then identifies that the resulting information from the name server computer is an identification for the server computer 12 (m), or that no server computer 12 (m) is associated with the class. It is determined whether or not an indication is included (step 114). If the stub class loader 33 determines that the resulting information includes an identification for the server computer 12 (m), this (i.e. stub class loader 33) is invoked on the classes and methods that can be called. In order to obtain a stub class instance, the process will return to step 101 of initiating communication with the identified server computer 12 (m). On the other hand, if the stub class loader 33 has provided an indication in step 114 that the name server computer 13 is not identified as being associated with classes and methods to which any server computer 12 (m) can be invoked. , A "Class not found" exception may be displayed (step 115), and the exception handler is called as described above.

As described above, the stub class instance 30 retrieved and loaded as described with reference to FIG. 2 may be used for remote invocation of the method. The operations performed by the client computer client 11 (n) in connection with the remote invocation of the method will be described with reference to the flowchart of FIG. As shown in FIG. 3, when class instance 22 invokes a method, control module 19 initially verifies that stub class instance 30 exists in the execution environment for the remote method to be invoked (step 120). ). If a positive result is obtained in step 120, the stub class instance 30 will be used for the remote call and provide a parameter value that will be used to process the remote method in the remote call (step 121). The stub class instance 30 for the remote method that can then be called is used to initiate communication with the server computer 12 (m) that maintains the class for the remote method (step 122), and in the process, Passing parameter values to be used for processing will be passed. If the server computer 12 (m) to process the method is the same physical computer as the client computer 12n calling the method, the communication will be in the execution environment being processed within the physical computer. On the other hand, if the server computer 12 (m) to process the method is a physical computer different from that of the client computer 12n invoking the method, the communication is performed by each network interface 15 (n) of the client computer and the server computer. ) And 16 (m)), and through the network 14.

In response to the communication from the stub class instance in step 122, server computer 12 (m) establishes an execution environment 24 for the class that maintains the method that can be called as needed, and the Skelton ( The information provided by 32 is used to create a class instance 26 for that class (step 123). The server computer 12 (m) will then process the method with respect to the parameter value provided by the stub class instance 30, under the control of the control module 28 (step 124). After completing the processing of the method, the server computer 12 (m) also under the control of the control module 28 initiates communication with the stub class instance 30 of the client computer, providing the result information to the stub class instance. Will be done (step 125). Similar to what is described above with respect to step 102, if the server computer 12 (m) that processed the method is the same physical computer as the client computer 12n that invoked the method, then it is being processed within the physical computer. May be within execution environment 24 and 20. On the other hand, if the server computer 12 (m) that handled the method is a physical computer different from the client computer 12n invoking the method, communication is via the respective network interfaces 16m and 15n of the server computer and the client computer. And via the network 14. When the stub class instance 30 receives the result information from the server computer, it provides the result information to the class instance 22 that initiated the remote method call (step 126), and the class instance 22 receives the control module 19 Processing will continue.

Returning to step 120, if it is determined that the control module 19 does not have a stub class instance 30 suitable for the remote method that can be called in this step, it calls the exception handler at this point (step 127). In this case, the selected erotic recovery operation can be performed.

The method and system according to the present invention provide many advantages. In particular, the present invention allows a program running in one execution environment to remotely invoke the processing of a method in another execution environment, thereby facilitating dynamic loading of the stub to be executed and loaded by the program when needed. One system and method are provided. In a system where stubs are compiled into a program and statically determined when the program is compiled, stubs are supported by remote references received by the program, and there is a mismatch between the stubs provided to the program and the conditions of the remote procedure called when the program is run. A subset of the actual set of remote interfaces can be implemented that can result in errors and inefficiencies.

In such a dynamic stub loading system and method, since the stub being loaded can be obtained from a particular resource that provides a remote method, the exact set of interfaces can be defined to provide a program that the stub invokes at runtime. Eliminate runtime incompatibilities caused by inconsistencies between the provided stub and the condition of the remote method being called.

It will be appreciated that many modifications can be made to the configuration as described above. For example, although the execution environment 20 has been described as obtaining and loading stub class instances to facilitate the invocation of the remote method when a reference to the remote method is received, the stub when the remote method is initially called You will notice that a class instance can be obtained and loaded. Obtaining and loading a stub class instance for a remote method when a reference to it is received means that (I) the stub class instance will exist in the execution environment when the remote method is actually called, and (ii) if the appropriate stub class instance If it is not found, it would have the advantage of being notified early to the program or operator. On the other hand, getting and loading a stub class instance for a remote method when the method is about to be called does not require finding and loading the stub class instance even when a reference to it is received, and if the method is not actually called, the correct stub class This will result in delaying the call until an instance can be found.

It will be appreciated that the system according to the invention may consist entirely or in part of special purpose hardware or general purpose computer system, or any combination thereof in which part thereof may be controlled by a suitable program. Any program may comprise or store part of the system in whole or in part in a conventional manner, or may be provided in whole or in part to the system via a network or other mechanism to convey information in a conventional manner. In addition, the information provided by the operator using an operator input element (not shown) that may be directly connected to the system or that may convey information to the system via a network or other mechanism to convey information in a conventional manner. Can be manipulated and / or controlled by.

Alternative embodiment of the present invention

Although embodiments according to the present invention for dynamically retrieving and loading stubs as described above have been described, alternative embodiments according to the present invention are also described. Objects load and retrieve objects in a lookup service that contain code (stub information) to facilitate communication with a particular service or that the object contains code that performs a service. Although an alternative embodiment has been described as downloading an object from a lookup service representing a stub, as described above, the technique described below may equally apply to downloading an object that actually performs the service. Lookup services define directories of a network of services and store references to these services. A user who requires the use of a service on the network accesses a lookup service that returns stub information that facilitates the user's access to the service.

The lookup service is incorporated herein by reference, co-filed with the present invention and described in co-pending US patent application entitled "Dynamic Lookup Service in a Distributed System", assigned to the applicant of the present invention. Likewise, it may include a subset of all services available in the network called "Djinn." "Djinn" refers to a logical grouping of one or more services or resources provided by a network. Devices connected to the network can be dynamically added to Djinn themselves or dynamically removed from Djinn themselves. When added, the device can provide more than zero its services to Djinn and can use all the services currently provided by Djinn. The services provided by Djinn are defined by a lookup service that provides a common way to find and use services for Djinn.

Lookup services are an essential part of the infrastructure for Djinn or other computer networks that provide a range of services. The primary means for a program to find services available within Djinn is to provide a stub that allows users and administrators to discover and interact with services in Djinn.

Reference is now made to FIG. 4, which illustrates the lookup service 400 in detail. Server computer 12 (m) also includes a lookup service 400 as described below. As shown in FIG. 1, lookup service 400 located on server 12 (m) maintains a collection of "service items" 410-418. Each service item 410-418 represents an instance of a service available within Djinn, and each service item 410 is a service ID 402 that uniquely identifies the service item, code that programs usage to access the service. A stub 404 that provides a, and a set of attributes 406 that describe the service.

Upon registering a new service with the lookup service 400, the lookup service assigns a new service item 400 with a unique service ID 402, typically a number. This service 402 may later be used to access a particular service while avoiding unnecessary searches or finding some matching service item in the query.

When a new service is created (ie, a new device is added to Djinn), the service itself provides a lookup service 400, providing a stub 404 to be used by the client, thereby providing a service and attributes associated with the service ( Access the initial set of 406. For example, the printer will include attributes that indicate speed (pages per minute), resolution (dots per inch), color, and duplex printing is supported. The lookup service manager (not shown) may also add new attributes, such as the physical location of the service and its common name. Incidentally, if a service encounters some problems that require administrative attention, such as a printer that runs out of toner, the service may add an attribute indicating what the problem is. In one embodiment according to the present invention, the attribute is stored as a multi-entry and is a current mooring US patent entitled "Method and System for In-place Modifications In A Database", incorporated herein by reference. Using the multi-templates and techniques described in the application, additions, modifications and deletions of the attributes can be made.

An individual set of attributes is represented as an instance of a class, where each attribute is a field of that class. An example of a property set for a printer is as follows:

public class Printer {

Integer ppm; // pages per minute

Integer dpi; // dot resolution per inch

Boolean duplex; // support duplex printing

Boolean color; // color or black only

}

The class provides strong typing of both sets and individual attributes.

The attributes of the service item 410 may also be represented as a set of attributes. Attribute 406 of service item 410 may include multiple instances of the same class, as well as multiple instances of different classes. For example, the attribute 406 of the service item 410 may include multiple instances of the Name class + instances of the Location, Type class, or various other service specific classes, each instance giving a common name for the service in a different language. Can have. Some examples of attributes added to describe a printer can be Name, Type, or Location:

public class Name implements Entry {

String name; // user friendly name of the service

String description; // free form description of service

String language; // language used above (ie English, French)

}

public class Type implements Entry {

String type; // general type of service

String vendor; // provider of service

String model; // model number / name of the product

String version; Product version number

}

public class Location implements Entry {

Integer floor; // which layers provide services

String building; // what buildings can enter

String room; // what room you can enter

}

In this example, the attribute 406 of the service item 406 will be a set of attributes that include a Printer, Type, and Location class instance where each class includes its own individual attributes. However, it should be understood that the scheme used for the attribute is not limited to these examples.

Programs that require a particular type of service (including other services) can use lookup service 400 to find stubs that can be used to access the service. Matching can be made based on the type of service as well as the specific attributes attached to the service. For example, a printer can be searched by requesting a stub type corresponding to a client desired service or by requesting any attribute, such as a specific location or print speed. In one embodiment according to the present invention, the attribute is stored as a multi-entry and the matching of attributes is entitled "Method and System For Multi-Entry and Multi = Template Matching In A Database" which is incorporated by reference of the present invention. As described in the currently pending US patent application, it can be accomplished using a multi-template.

Access to lookup services using dynamic stub loading and retrieval

Referring again to FIG. 4, a service 400 corresponding to the service is registered with the lookup service 400 and used by the client computer client 11 (n) to access the method remotely. This stub 404 may also be a "smart proxy." Smart proxy code with built-in stubs helps clients implement stubs and methods to be called remotely. Smart proxies also perform some local operations for efficiency before or after invoking the stub. For example, smart proxies contain code to cache information, so if a client requests it again instead of going back to the server to get the information, it can cache the answer and return it quickly. If the situation has requested this, the smart proxy can also transform the parameter received from the client to another type and then send the modified type. The smart proxy concept has been assigned to the Applicant's assignee and is currently pending under the heading "Downloadable Smart Proxies for Performing Processing Associated with a Remote Rrocedure Call in a Distrubuted System", filed on the same date and incorporated herein by reference. It is described in detail in US Patent Application No.

5 is a flow chart illustrating the steps used in a system for adding a service stub to a lookup service in accordance with the present invention. When the device joins the network, it typically registers a service with a lookup service (step 500). Upon registration of lookup service 400, the device supplies a stub 404 to the lookup service, which may also provide an attribute 406 associated with the lookup service (step 502). In response, lookup service 400 assigns a number to a unique service ID 402, typically a service registered as a lookup service, as previously described above (step 504). Once the device supplies the stub 404 and attributes 406 to the lookup service 400, and the lookup service assigns a unique service ID 402, the device completes service registration with the lookup service (step 506). . After the service is registered with the lookup service 400, the client may obtain stub information necessary to access the registered service using the lookup service.

6 is a flow chart illustrating the steps used by the system and method for downloading a service item from a lookup service in accordance with the present invention. In one embodiment, client computer client 11 (n) sends a service request with lookup service 400 to server 12 (m) (step 600). The request originates from the remote method call of the class instance 22 on the client computer client 11 (n), and the requested service is sent to the remote server as the exemplary device 38 resides on the server 12 (I). Can reside In one embodiment in accordance with the present invention, client computer client 11 (n) may request one or more services from lookup service 400. The client's request is in the form of a particular service ID 402, type of stub 404 or a set of attributes 406 or any combination thereof (step 602). In response to the request, control 19 instructs stub class loader 33 to find the corresponding stub 404 from server 12 (m). To this end, the control 19 enables the stub class loader 33 to obtain a stub 404 for the service to be obtained by initiating communication with the server 12 (m).

Upon receipt of the request from the client computer 11 (n), the control 28 in the server 12 (m) retrieves the lookup service 400 for the stub 404 corresponding to the requested service (step). 604). If a match is found, control 28 returns a null value (steps 606 and 608). Otherwise, if the stub 404 corresponding to the service is found that the client computer 11 (n) is attempting to access, the server 12 (m) returns the stub to the client loader 33 on the client computer. (Step 612). If one or more stubs are found that match the client's request (step 610), in an embodiment in accordance with the present invention, any stubs in the stub are returned (step 616). In another embodiment where the client requests one or more services, server 12 (m) returns the requested number of stubs with that attribute (steps 614 and 618).

When stub 404 is received by stub class loader 33, the stub class loader loads it into execution environment 20. After loaded, service 38 may be called remotely. Invoking remote processing of service 38 using the stub information is performed in the same manner as previously described with reference to FIG. 3.

In general, class instance 22 may use stub 404 to access service 38 on server 12 (I). When the class instance 22 requests the use of the service 38 corresponding to the returned stub 404, the control 19 verifies that the stub 404 exists in the execution environment 20. If so, the class instance 22 may then use the stub 404 to initiate communication with the server 12 (I) maintaining the service 38, and the parameter to the service 38 for implementation. Will be delivered.

Lookup service implementations are one application of dynamic loading and retrieval of stub information that enables a program running in one address space to invoke the processing of a procedure in another address space. This embodiment using dynamic stub loading for a lookup service receives stub information so that a client can easily use the service directly. Unlike the previous lookup service, the lookup service according to the present invention returns the code necessary to access the service directly. By using dynamic loading of stub information in this way, the client can receive all the modes necessary to facilitate the use of the service on the remote server.

The foregoing description is limited to specific embodiments of the present invention. Thus, various modifications and variations can be made. It is an object of the appended claims to cover such and other modifications and variations as come within the spirit and scope of the invention.

Claims (27)

A method of accessing a network service associated with a lookup service in a data processing system, the method comprising: Receiving a request by a lookup service to access one of the network services; And Returning a code that facilitates access to the one network service. 2. The method of claim 1, further comprising accessing the network service using the returned code. 2. The method of claim 1, wherein returning the code further comprises returning a stub. The method of claim 1 wherein returning the code comprises returning a smart proxy. 2. The method of claim 1, wherein said receiving comprises receiving a request to access said one network service such that said one network service is identified by a type of service. The method of claim 1, wherein the receiving step includes receiving a request to access the one network service such that the one network service is identified by a service identification number. The method of claim 1, wherein the receiving step includes receiving a request to access the one network service such that the one network service is identified by an attribute of the one network service. 2. The method of claim 1, wherein returning the code comprises returning a plurality of stubs associated with a plurality of network services that match the request. The method of claim 8, wherein returning the plurality of stubs comprises returning an attribute associated with each stub. A lookup service in a data processing system having a plurality of services, the method comprising: Sending a request to the lookup service to access one of the services; And In response to the request, receiving a code that facilitates use of the one service. 11. The method of claim 10, further comprising accessing the one service using the received code. 11. The method of claim 10, wherein receiving a code comprises receiving a stub that facilitates access to the one service. The method of claim 10, wherein receiving a code comprises receiving a smart proxy that facilitates access to the one service. 1. A method in a data processing system having a lookup service having a client, wherein the first computer has a client and service stubs used to access an associated service. Sending, by the client, a request to the lookup service identifying one of the associated services to be accessed; Receiving the request by the lookup service; Searching for a lookup service for the identified service; Returning the service stub associated with the identified service to the client; Receiving the service stub by a genital client; Loading the service stub into the client's address space such that the service stub is available to invoke the identified service; And Accessing the identified service using the stub by the client. The method of claim 14, The transmitting step includes transmitting a request for one or more services to be returned, The returning step further includes returning one or more stubs to the client in response to the request. 15. The method of claim 14, wherein said retrieving comprises returning a null value if no service matching the request is found. In a distributed system having a plurality of network services, A server computer with a lookup service having a stub to facilitate access to the network service; And A client having a program for sending a request to a lookup service for one of the stubs corresponding to one of the network services, receiving the stub, and using the received stub to access the one network service Distributed system with a computer. 18. The distributed system of claim 17 wherein the client computer utilizes a remote procedure call mechanism to receive the stub. 1. A system having a lookup service, wherein the first computer has a client and the second computer has service stubs used to access an associated service, the system comprising: Means for a client to send a request to the lookup service identifying one of the associated services to be accessed; Means for receiving the request by the lookup service; Means for searching a lookup service for the identified service; Means for returning the service stub associated with the identified service to the client; Means for receiving the service stub by the client; Means for loading the service stub into the client's address space such that the service stub is available to invoke the identified service; And Means for accessing the identified service using the stub by the client. A computer readable medium comprising instructions for controlling a data processing system to access a network service included in a lookup service, the computer readable medium comprising: This method, Receiving a request by a lookup service to access one of the network services; And Returning a code to facilitate access of the one network service. 21. The computer readable medium of claim 20, further comprising accessing the network service using the returned code. 21. The computer readable medium of claim 20, wherein returning further comprises returning a stub. 21. The computer readable medium of claim 20, wherein returning comprises returning a smart proxy. A computer readable medium comprising instructions for controlling a data processing system to access a network service included in a lookup service, the computer readable medium comprising: This method, Sending a request to the lookup service to access one of the services; And In response to the request, receiving a code that facilitates use of the one service. 25. The computer readable medium of claim 24, further comprising accessing the one service using the received code. 25. The computer readable medium of claim 24, wherein receiving the code comprises receiving a stub that facilitates access to the one service. 25. The computer readable medium of claim 24, wherein receiving the code comprises receiving a smart proxy that facilitates access to the one service.