WO2000077635A1 - Network proxy for devices with limited resources - Google Patents

Network proxy for devices with limited resources Download PDF

Info

Publication number
WO2000077635A1
WO2000077635A1 PCT/US2000/016080 US0016080W WO0077635A1 WO 2000077635 A1 WO2000077635 A1 WO 2000077635A1 US 0016080 W US0016080 W US 0016080W WO 0077635 A1 WO0077635 A1 WO 0077635A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
computer
lookup
proxy
request
Prior art date
Application number
PCT/US2000/016080
Other languages
French (fr)
Inventor
James H. Waldo
John W.F. Mcclain
Original Assignee
Sun Microsystems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems, Inc. filed Critical Sun Microsystems, Inc.
Priority to EP00941352A priority Critical patent/EP1194846A1/en
Priority to AU56066/00A priority patent/AU5606600A/en
Publication of WO2000077635A1 publication Critical patent/WO2000077635A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services
    • G06F9/548Object oriented; Remote method invocation [RMI]

Definitions

  • the present invention relates generally to data processing systems and. more particularly, to a network proxy.
  • the personal computers and workstations are used by individual users to perform processing in connection with data and programs that may be stored in the network mass storage subsystems.
  • the personal computers/workstations operating as clients, typically download the data and programs from the network mass storage subsystems for processing.
  • the personal computers or workstations will enable processed data to be uploaded to the network mass storage subsystems for storage, to a network printer for printing, to the telephony interface for transmission over the public telephony system, or the like.
  • the network mass storage subsystems, network printers and telephony interface operate as servers, since they are available to service requests from all of the clients in the network.
  • the servers are readily available for use by all of the personal computers/workstations in the network.
  • Such a network may be spread over a fairly wide area, with the personal computers/workstations being interconnected by communication links such as electrical wires or optic fibers.
  • a client In addition to downloading information from servers for processing, a client, while processing a program, can remotely initiate processing by a server computer of particular routines and procedures (generally “procedures"), in connection with certain "parameter” information provided by the client. After the server has processed the procedure, it will provide results of its processing to the client, which the client may thereafter use in its processing operations.
  • the program will make use of a local "stub" which, when called, transfers the request to the server which implements the particular procedure, receives the results and provides them to the program.
  • the stub must be compiled with the program, in which case the information needed to call the remote procedure must be determined at compile time, rather than at the time the program is run.
  • the stub available to the client's programs is static, it may be at best the closest that can be determined should be provided for the program when it (the program) is compiled. Accordingly, errors and inefficiencies can develop due to mismatches between the stub that is provided to a program and the requirements of the remote procedure that is called when the program is run.
  • a new and improved system and method for facilitating the obtaining and dynamic loading of a stub is provided to enable a program operating in one address space to remotely invoke processing of a method or procedure in another address space, so that the stub can be loaded by the program when it is run and needed, rather than being statically determined when the program is compiled.
  • the stub that is loaded can be obtained from the resource providing the remote method or procedure, and so it (the stub) can exactly define the invocation requirements of the remote method or procedure.
  • the stub can be located and dynamically loaded while the program is being run, rather than being statically determined when the program is compiled, run- time errors and inefficiencies which may result from mis-matches between the stub that is provided and the requirements of the remote method or procedure that is invoked can be minimized.
  • the stub is obtained from a lookup service to provide access to a service defined in the lookup service.
  • methods and systems consistent with an alternative embodiment of the present invention facilitate access to a service via a lookup service.
  • a lookup service defines a network's directory of services and stores references to these services.
  • a client desiring use of a service on the network accesses the lookup service, which returns the stub information that facilitates the user's access of the service.
  • the client uses the stub information to access the service.
  • a network proxy is provided that facilitates the integration of orphan services into a network by enabling them to interact with a lookup service that contains an indication of the services that are available on the network.
  • the lookup service acts like a service registry.
  • the network proxy acts as a go between, by registering the orphan services with the lookup service so that clients may access them and by accessing services on behalf of the orphan services.
  • the network proxy integrates orphan services into the network when they otherwise would be incapable of doing so.
  • a method is provided in a data processing system including a service on a device, a service registry, and a proxy.
  • the proxy receives a request from the service to register with the service registry, obtains information that facilitates accessing the service, and stores the information into the service registry.
  • a method for registering a service located on a device in a service registry is provided in a data processing system.
  • the service sends a request for registration in the service registry to a proxy server, whereupon the proxy server registers the service in the service registry to enable a client program to access the service, and the service receives a request from the client program for accessing the service.
  • a method is provided in a data processing system including a client program, a service registry containing a reference to a service on a device, and a proxy server. According to this method, the client program retrieves the reference from the service registry and uses the reference to send a request to access the service to the proxy server.
  • a data processing system comprises a lookup server, a device, and a proxy server.
  • the lookup server includes a memory with a lookup service containing registrations that facilitate access to corresponding services and includes a processor for running the lookup service.
  • the device includes a memory containing an orphan service that requests registration in the lookup service and includes a processor for running the orphan service.
  • the proxy server includes a memory containing a network proxy that receives the registration request from the orphan service and that registers the orphan service in the lookup service and includes a processor for running the network proxy.
  • FIG. 1 is a function block diagram of a computer network including an arrangement constructed in accordance with the present invention for facilitating the obtaining, dynamic loading and use of "stub" information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space;
  • FIGs. 2 and 3 are flow charts depicting the operations performed by the arrangement depicted in FIG. 1, with FIG. 2 depicting operations performed in connection with obtaining and dynamic loading of the stub information and FIG. 3 depicting operations performed in connection with use of the stub information to invoke processing of the remote method or procedure;
  • FIG. 4 is a diagram illustrating a lookup service consistent with the present invention.
  • FIG. 5 is a flowchart illustrating a method of adding a stub to the lookup service consistent with the present invention
  • FIG. 6 is a flowchart illustrating a method for retrieving a stub from a lookup service by systems consistent with the present invention
  • FIG. 7 depicts a data processing system suitable for use with a second alternative embodiment of the present invention
  • FIG. 8 depicts a flowchart of the steps performed when the network proxy depicted in FIG. 7 registers an orphan service with the lookup service depicted in FIG. 7 in accordance with methods and systems consistent with the present invention
  • FIG. 9 depicts a flowchart of the steps performed when the network proxy depicted in FIG. 7 registers an orphan service with the lookup service depicted in FIG. 7 in accordance with an alternative embodiment of the present invention.
  • FIG. 10 depicts a flowchart of the steps performed when the network proxy depicted in FIG. 7 manages resource allocation on behalf of the orphan service.
  • FIG. 1 is a schematic diagram of a computer network 10 including an arrangement for facilitating dynamic loading of "stub" information to enable a program operating in one address space to remotely invoke processing of a method or procedure in another address space, where this method or procedure represents a network service.
  • computer network 10 includes a plurality of client computers 1 1(1) through 11(N) (generally identified by reference numeral l l(n)), a plurality of server computers 12(1) through 12(M) (generally identified by reference numeral 12(m)), all of which are interconnected by a network represented by a communication link 14.
  • the network 10 may include at least one nameserver computer 13, which may also be connected to communication link 14, whose purpose will be described below.
  • the client computers 1 l(n) are in the form of personal computers or computer workstations, each of which typically includes a system unit, a video display unit and operator input devices such as a keyboard and mouse (all of which are not separately shown).
  • the server computers 12(m) and nameserver computer 13 also typically include a system unit (also not separately shown), and may also include a video display unit and operator input devices.
  • the client computers 1 l(n), server computers 12(m) and nameserver computer 13 are all of the conventional stored-program computer architecture.
  • a system unit generally includes processing, memory, mass storage devices such as disk and/or tape storage elements and other elements (not separately shown), including network interface devices 15(n), 16(m) for interfacing the respective computer to the communication link 14.
  • the video display unit permits the computer to display processed data and processing status to the operator, and an operator input device enables the operator to input data and control processing by the computer.
  • the computers l l(n) and 12(m) and 13 transfer information, in the form of messages, through their respective network interface devices 15(n), 16(m) among each other over the communication link 14.
  • the network 10 is organized in a "client-server" configuration, in which one or more computers, shown in FIG. 1 as computers 12(m), operate as servers, and the other computers, shown in FIG. 1 as computers 11 (n) operate as clients.
  • one or more of the server computers 12(m) may, as "file servers,” include large-capacity mass storage devices which can store copies of programs and data which are available for retrieval by the client computers over the communication link 13 for use in their processing operations.
  • a client computer 1 1 (n) may also store data on the server computer 12, which may be later retrieved by it (the client computer that stored the data) or other client computers for use in their processing operations.
  • one or more of the server computers 12(m) may, as “compute servers,” perform certain processing operations in response to a remote request therefor from a client computer 1 l(n), and return the results of the processing to the requesting client computer 1 1 (n) for use by them (that is, the requesting client computers 1 1 (n)) in their subsequent processing.
  • the server computers may be generally similar to the client computers 1 1 (n), including a system unit, video display unit and operator input devices and may be usable by an operator for data processing operations in a manner similar to a client computer.
  • at least some of the server computers may include only processing, memory, mass storage and network interface elements for receiving and processing retrieval, storage or remote processing requests from the client computers, and generating responses thereto.
  • a client computer l l(n) may also perform operations described herein as being performed by a server computer 12(m), and similarly a server computer 12(m) may also perform operations described herein as being performed by a client computer 1 l(n).
  • the network represented by communication link 14 may comprise any of a number of types of networks over which client computers 1 1 (n), server computers 12(m) and nameserver computers 13 may communicate, including, for example, local area networks (LANs) and wide area networks (WANs) which are typically maintained within individual enterprises, the public telephony system, the Internet, and other networks, which may transfer digital data among the various computers.
  • the network may be implemented using any of a number of communication media, including, for example, wires, optical fibers, radio links, and/or other media for carrying signals representing information among the various computers depicted in FIG. 1.
  • each of the computers typically includes a network interface which connects the respective computer to the communications link 14 and allows it to transmit and receive information thereover.
  • Systems consistent with the present invention facilitate the obtaining and dynamic loading of "stub" information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space, which may be located on the same computer as the invoking program or on a different computer.
  • JavaTM programming language as described in James Gosling, Bill Joy, Guy Steele, "The JavaTM Language Specification", Addison- Wesley, 1996, (hereinafter referred to as the "Java language specification"), incorporated herein by reference, which are processed in connection with an execution environment which is provided by a Java virtual machine.
  • the Java virtual machine in turn, is specified in the Lindholm andYellin, "The Java Virtual Machine Specification", Addison- Wesley, 1996, incorporated herein by reference.
  • programs in the Java programming language define "classes” and "interfaces.” Classes are used to define one or more methods or procedures, each of which may be invoked by reference to an interface.
  • a class may be associated with and extend a "super-class,” and in that regard will incorporate all of the interfaces and methods of the super-class, and may also include additional interfaces and/or methods.
  • a class may also have one or more sub-classes (and thus will comprise a super-class of each of its sub-classes), with each sub-class incorporating and possibly extending their respective super-classes.
  • An interface provides a mechanism by which a set of methods may be declared.
  • an interface identifies each method that is declared by the interface by, for example, a name, identities the datatype(s) of argument(s) that are to be provided for the method, the data type(s) of return values that are to be returned by the method, and identifiers for exceptions which can be thrown during processing of the method.
  • a class may indicate that it implements a particular interface, and in that connection will include the program code which will be used in processing all of the methods which are declared in the interface.
  • an interface provides a mechanism by which a set of methods can be declared without providing an indication of the procedure which will be used in processing any of the methods.
  • An interface may be declared independently of the particular class which implements the method or methods which can be invoked using the interface. In that regard, a class that invokes the method and a class that actually implements the method will not need to share a common super-class.
  • a client computer l l(n) provides an execution environment 20 for interpreting the Java program.
  • the Java virtual machine includes a class loader 21 that, under control of a control module 19, can dynamically link instances of classes, generally identified in FIG. 1 by reference numeral 22, into the running program's execution environment while the program is being executed. In that operation, the control module
  • class loader 19 effectively enables the class loader to retrieve uninstantiated classes, which generally identified by reference numeral 23, instantiate them and link them as class instances 22 into the execution environment's address space at the Java program's run time as the methods which the respective classes 23 implement are called.
  • the class loader 21 can discard ones of the class instances 22 when they are not needed or to conserve memory. It will be appreciated that, if a class instance 22 has been discarded, it may be reloaded by the class loader 21 at a later point if it is then needed.
  • Systems consistent with the present invention provide an arrangement which facilitates the remote invocation, by a program executing in an execution environment
  • server computer 12(m) will also provide an execution environment 24 for processing, under control of a control module 28, the Java method.
  • the Java virtual machine which provides the execution environment 21 includes a class loader 25 (which may be similar to the class loader 21) that, under control of the control module 28, can dynamically link an instance of the class 26, to enable the method to be processed in the execution environment 24, and instances of other classes (also generally represented by reference numeral 26) which may be needed to process the remotely-invoked method.
  • the control module 28 effectively enables the class loader 25 to retrieve an uninstantiated class for the method to be invoked, from a plurality of uninstantiated classes which are generally identified by reference numeral 27, instantiate it (that is, the uninstantiated class which provides the method to be invoked) and link it as a class instance 26 into the execution environment.
  • the class loader 25 can discard the class instances 26 when processing of the method has terminated. It will be appreciated that, if class instances 26 has been discarded, it may be reloaded by the class loader 25 at a later point if it is then needed.
  • nameserver computer 13 if provided, is generally similar to that of the server computer 12(m), and will not be separately described.
  • the control module 19 of the client computer's execution environment 21 makes use of one or more stub class instances generally identified by reference numeral 30 which are provided as part of the execution environment 21 in which the various class instances 22, including the class instance which is invoking the remote method, are being processed.
  • Each stub class instance 30 is an instance of an uninstantiated stub class 31, which the server computer 12(m) may maintain for the various class instances 26 and uninstantiated classes 27 which the server computer 12(m) has "exported," that is, which the server computer 12(m) makes available to client computers 1 1 (n) for use in remote invocation of methods provided thereby.
  • An uninstantiated stub class 31 includes declarations for the complete set of interfaces for the particular remote uninstantiated class 27 which implements the remote method to be invoked, and also provides or invokes methods which facilitate accessing of the remote method(s) which are implemented by the remote class.
  • the uninstantiated stub class 31 when it is instantiated and provided to the execution environment 20 of the client computer 1 l(n) as a stub class instance 30, effectively provides the information which is needed by the control module 19 of the execution environment 20 of the invoking Java program, so that, when a remote method that is implemented by its associated class is invoked by a Java program running in a particular execution environment, the remote method will be processed and the return value(s) provided to the invoking Java program.
  • the arrangement by which the stub class instance may be provided to the execution environment 20 is similar to that described in the aforementioned Waldo, et al., patent application.
  • the server computer 12(m) provides a skeleton 32. which identifies the particular classes and methods which have been exported by the server computer 12(m) and information as to how it (that is, the server computer 12(m)) may load the respective classes and initiate processing of the particular methods provided thereby.
  • the server computer 12(m) contains a lookup service 400 for registering services on a network. The lookup service 400 will be discussed below.
  • a class instance When a class instance invokes a remote method maintained by a server computer 12(m), it will provide values for various parameters to the stub class instance 30 for the remote method, which values the remote method will use in its processing.
  • the remote method is implemented on the same computer as the invoking Java program, when the invoking Java program invokes a remote method, the computer may establish an execution environment, similar to the execution environment 20, enable the execution environment's class loader to load and instantiate the class which implements the method as a class instance similar to class instances 22, and process the remote method using values of parameters which are provided by the invoking class instance in the remote invocation.
  • the execution environment in which the remote method has been processed will provide the results to the stub class instance 30 for the remote method that was invoked, which, in turn, will provide to the particular class instance 22 which invoked the remote method. Similar operations will be performed if client computer 11 (n) and server computer
  • the client computer l l(n) that is processing the invoking class instance 22, under control of the control module 19 for the execution environment 20 for the invoking class instance 22, will use the appropriate stub class instance 30 to communicate over the network represented by the communication link 14 with the server computer 12(m) which implements the remote method to enable it (that is, the server computer 12(m)) to establish an execution environment 24 for the class which implements the remote method, and to use the class loader 25 to load an instance of the class as a class instance 26.
  • the client computer l l(n) that is processing the invoking class instance 22
  • the server computer 12(m) under control of the control module 19 for the execution environment 20 for the invoking class instance 22
  • the server computer 12(m) to establish an execution environment 24 for the class which implements the remote method
  • the class loader 25 to load an instance of the class as a class instance 26.
  • the client computer l l(n) the client computer l l(n).
  • the server computer 12(m) will process the remote method using parameter values so provided, to generate result value(s) which are transferred over the network to the client computer 1 1 (n), in particular to the appropriate stub class instance 30.
  • the client computer 1 l(n) will, after it receives the result value(s) from the network, provide them to the invoking class instance 22 for its processing.
  • control module 19 of the client computer's execution environment 20 determines that a reference to the remote object has been received, if it determines that the stub class instance 30 is not present when it receives the reference, it will attempt to obtain the stub class instance 30 from, for example, the server computer 12(m) which implements the remote method, and enable the stub class instance 30 to be dynamically loaded in the execution environment 20 for the invoking class instance 22.
  • a reference to the remote object may be received, for example, either as a return value of another remote method invocation or as a parameter that is received during another remote method invocation.
  • the stub class instance may be dynamically loaded into the execution environment in a manner similar to that used to load class instances 22 in the execution environment 22.
  • the execution environment 20 is provided with a stub class loader 33 which, under control of the control module 19, will attempt to find and load the stub class instances 30 as required by the class instances 22 processed in the execution environment.
  • the location of a particular server computer 12(m) that maintains the class that implements a method to be invoked remotely may be included in the call from the invoking class instance or may be made known to the stub class loader 33 through another mechanism (not shown) maintained by the client computer 1 l(n).
  • the stub class loader 33 may use the nameserver computer 13 to provide that identification.
  • the identification may comprise any identifier which may be used to identify a server computer 12(m) or other resource which is available on the network 14 and to which the server computer 12(m) can respond.
  • Illustrative identifiers include, for example, a network address which identifies the server computer and/or resource, or, if the network 14 is or includes the Internet, an identifier to, for example, a World Wide Web resource which may provide the identification or a "uniform resource locator" ("URL") which provides a uniform mechanism for identifying resources that are available over the Internet.
  • the server computer 12(m) which implements the remote method, in response to a request from the client computer 11 (n) will provide stub class instance 30 which the client computer 1 l(n) may load into the execution environment 21 to thereafter enable the remote invocation to be initiated.
  • the stub class loader 33 may, under control of the control module 19, obtain the identification from the nameserver computer 13. In that operation, the stub class loader 33 may use a previously-provided default stub class which is provided for use in such cases.
  • the default class stub when used by the invoking Java program, enables the computer that is processing the invoking Java program to communicate with the nameserver computer 13 to obtain information which can be used in invoking the remote method.
  • This operation is essentially the same as the invocation of a remote method to be processed by the nameserver computer 13, with the remote method including a parameter identifying the class and method to be remotely invoked, and enabling the nameserver computer 13 to provide the identification of a server computer 12(m) which can process the method to the requesting client computer 1 1 (n) and other information which may be helpful in communicating with the server computer 12(m) and invoking the particular method.
  • the nameserver computer 13 will maintain a table (not separately shown) of "exported" resources, that is, resources, such as classes and methods, that are available to client computers 11 (n) connected to the network 14, and information, such as the identifications of the particular server computers 12(m) which provide those resources, which will be useful to the client computers 1 l(n) in making use of the exported resources. It will be appreciated that the nameserver computer 13 may create and maintain the exported resource table in a number of ways that are known in the art.
  • the nameserver computer 13 may periodically broadcast requests for exported resource information over the network 14, to which the various server computers 12(m) which maintain exported resources may respond; in that case, the nameserver computer 13 may establish its exported resource table based on the responses from the server computers 12(m).
  • each of the various server computers 12(m) which maintains an exported resource may periodically broadcast information as to the exported resources which it maintains, and the nameserver computer 13 can update its exported resource table based on the broadcasts from the server computer.
  • the nameserver computer's exported resource table may be established by a system operator and may be fixed until he or she updates it.
  • the information provided by the nameserver computer 13 in response to a request initiated by the default stub would include such information as, for example, the identification of a computer 12(m) which can provide a class which implements the remote method to be invoked, particular information which the computer (that is, the computer which implements the remote method) will require to provide the required stub class code, and the like.
  • the computer 1 1 (n) that is processing the invoking Java program may, under control of the control module 19, use the information communicate with the computer (that is, the computer which implements the remote method) to obtain the stub class, and may thereafter invoke the method as described above.
  • client computer 1 l(n), server computer 12(m) and, if necessary, nameserver 13 in connection with obtaining and dynamic loading of a stub class instance when a reference to a remote method is received will be described in connection with the flow chart depicted in FIG. 2.
  • client computer 1 1 (n) and server computer in connection with remote invocation of a method using the stub class instance will be described in connection with the flow chart depicted in FIG. 3.
  • the execution environment control module 19 will, when it receives a reference to a remote method, will initially determine whether an appropriate stub class instance is present in the execution environment 20 to facilitate invocation of the remote method (step 100).
  • control module 19 determines that such a stub class instance 30 for the remote method is present in the execution environment, it may continue other operations (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 will use the stub class loader 33 to attempt to locate and load a stub class instance 30 for the class to process the remote method.
  • control module 19 will initially determine whether the invocation from the class instance 22 included a resource locator to identify the server computer 12(m) or other resource which maintains the class for the method to be invoked, or whether it (that is, the control module 19) or the stub class loader 33 otherwise are provided with such a resource locator (step 102). If the control module 19 makes a positive determination in that step, it will sequence to step 103 to enable the stub class loader 33 to initiate communications with identified server computer 12(m) to obtain stub class instance for the class and method to be invoked (step 103).
  • the stub class loader 33 When the stub class loader 33 receives the stub class instance 30 from the server computer 12(m), it will load the stub class instance 30 into execution environment 20 for the class instance 22 which initiated the remote method invocation call in step 100 (step 104). After the stub class instance 30 for the referenced remote method has been loaded in the execution environment, the method can be invoked as will be described below in connection with FIG. 3.
  • control module 19 determines that the invocation from the class instance 22 did not include a resource locator to identify the server computer 12(m) or other resource which maintains the class for the method to be invoked, and further that it (that is, the control module 19) or the stub class loader 33 is not otherwise provided with such a resource locator, a "class not found" exception may be indicated, at which point the control module 19 may call an 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 located and allow it to determine subsequent operations.
  • control module 19 may attempt to obtain a resource locator from the nameserver computer 13 or other resource provided by the network 14 (generally represented in FIG. 1 by the nameserver computer 13). using a call, for example, a default stub class instance 30.
  • the call to the default stub class instance 30 will include an identification of the class and method to be invoked and the name of the nameserver computer 13(m).
  • the control module 19 will enable the computer 1 1 (n) to initiate communications with nameserver computer
  • the communications from the default stub class instance 30 will essentially correspond to a remote method invocation, with the method enabling the nameserver computer to provide the identification for the server computer 12(m), if one exists associated with the class and method to be remotely invoked, or alternatively to provide an indication that no server computer 12(m) is identified as being associated with the class and method.
  • the default stub class interface 30 will provide, as a parameter value, the identification of class and method to be invoked.
  • the nameserver computer 13 In response to the communications from the default stub class instance 30, the nameserver computer 13 will process the request as a remote method (step 1 11), with the result information comprising the identification for the server computer 12(m), if one exists that is associated with the class and method to be remotely invoked, or alternatively an indication that no server computer 12(m) is identified as being associated with the class and method. After finishing the method, the nameserver computer 13 will initiate communications with the default stub class instance 30 to provide the result information to the default stub class instance 30 (step 112).
  • the stub class loader 33 determines whether the result information from the nameserver computer comprises the identification for the server computer 12(m) or an indication that no server computer 12(m) is identified as being associated with the class (step 1 14). If the stub class loader 33 determines that the result information comprises the identification for the server computer 12(m), it (that is, the stub class loader 33) will return to step 101 to initiate communication with the identified server computer 12(m) to obtain stub class instance for the class and method that may be invoked.
  • the stub class loader 33 determines in step 114 that the nameserver computer 13 had provided an indication that no server computer 12(m) is identified as being associated with the class and method that may be invoked, the "class not found" exception may be indicated (step 1 15) and an exception handler called as described above.
  • the stub class instance 30 retrieved and loaded as described above in connection with FIG. 2 may be used in remote invocation of the method. Operations performed by the client computer l l(n) in connection with remote invocation of the method will be described in connection with the flow chart in FIG. 3.
  • the control module 19 may initially verify that a stub class instance 30 is present in the execution environment for remote method to be invoked (step 120). If a positive determination is made in step 120, the stub class instance 30 will be used for the remote invocation, and in the remote invocation will provide parameter values which are to be used in processing the remote method (step 121).
  • the stub class instance 30 for the remote method that may be invoked will be used to initiate communications with the server computer 12(m) which maintains the class for the remote method (step 122), in the process, the passing parameter values which are to be used in processing the remote method will be passed. It will be appreciated that, if the server computer 12(m) which is to process the method is the same physical computer as the client computer 12(n) which is invoking the method, the communications can be among execution environments which are being processed within the physical computer.
  • the server computer 12(m) which is to process the method is a different physical computer from that of the client computer 12(n) which is invoking the method, the communications will be through the client computer's and server computer's respective network interfaces 15(n) and 16(m) and over the network 14.
  • the server computer 12(m) In response to the communications from the stub class instance in step 122, the server computer 12(m), if necessary establishes an execution environment 24 for the class which maintains the method that may be invoked, and the uses the information provided by the skeleton 32 to create a class instance 26 for that class (step 123). Thereafter, the server computer 12(m), under control of the control module 28, will process the method in connection with parameter values that were provided by stub class instance 30 (step 124). After completing processing of the method, the server computer 12(m), also under control of the control module 28, will initiate communications with the client computer's stub class instance 30 to provide result information to the stub class instance (step 125).
  • the communications can be among execution environments 24 and 20 which are being processed within the physical computer.
  • the server computer 12(m) which processed the method is a different physical computer from that of the client computer 12(n) which is invoking the method, the communications will be through the server computer's and client computer's respective network interfaces 16(m) and 15(n) and over the network 14.
  • the stub class instance 30 may provide result information to the class instance 22 which initiated the remote method invocation (step 126), and that class instance 22 can continue processing under control of the control module 19.
  • control module 19 determines in that step that it does not have a stub class instance 30 that is appropriate for the remote method that may be invoked, it may at that point call an exception handler (step 127) to perform selected error recovery operations.
  • Methods and systems consistent with the present invention provide a number of advantages.
  • they provide a new system and method for facilitating dynamic loading of a stub which enables a program that is operating in one execution environment to remotely invoke processing of a method in another execution environment, so that the stub can be loaded by the program when it is run and needed.
  • stubs are compiled with the program, and thus are statically determined when the program is compiled, they (the stubs) may implement subsets of the actual set of remote interfaces which are supported by the remote references that is received by the program, which can lead to errors and inefficiencies due to mismatches between the stub that is provided to a program and the requirements of the remote procedure that is called when the program is run.
  • the stub that is loaded can be obtained from the particular resource which provides the remote method, it (the stub) can define the exact set of interfaces to be provided to the invoking program at run time, thereby obviating run-time incompatibilities which may result from mismatches between the stub that is provided and the requirements of the remote method that is invoked.
  • stub class instances may instead be obtained and loaded when the remote methods are initially invoked.
  • Obtaining and loading of the stub class instance for a remote method when a reference thereto is received will have the advantages that (I) the stub class instance will be present in the execution environment when the remote method is actually invoked, and (ii) if the appropriate stub class instance can not be located, the program or an operator may be notified at an early time.
  • obtaining and loading of the stub class instance for a remote method when the method is to be invoked may result in a delay of the invocation until the correct stub class instance can be found, if the method is in fact not invoked even if a reference to it is received the stub class instance may not need to be located and loaded.
  • a system in accordance with the invention can be constructed in whole or in part from special purpose hardware or a general purpose computer system, or any combination thereof, any portion of which may be controlled by a suitable program. Any program may in whole or in part comprise part of or be stored on the system in a conventional manner, or it may in whole or in part be provided in to the system over a network or other mechanism for transferring information in a conventional manner.
  • system may be operated and/or otherwise controlled by means of information provided by an operator using operator input elements (not shown) which may be connected directly to the system or which may transfer the information to the system over a network or other mechanism for transferring information in a conventional manner.
  • operator input elements not shown
  • an alternative embodiment also consistent with the present invention loads and retrieves objects in a lookup service, where the objects contain code (stub information) for facilitating communication with a particular service or the objects contain code that performs the service.
  • the alternative embodiment is described below as downloading objects from the lookup service that represent stubs, the techniques described below are equally applicable to downloading objects that actually perform the services.
  • a lookup service defines a network's directory of services and stores references to these services. A user desiring use of a service on the network accesses the lookup service, which returns the stub information that facilitates the user's access of the service.
  • the lookup service may contain a subset of all services available in the network, referred to as a "Djinn" as described in copending U.S. Patent Application Serial No. 09/044,931 , entitled “Dynamic Lookup Service in a Distributed System,” assigned to a common assignee, filed on even date herewith, which has been previously incorporated by reference.
  • a “Djinn” refers to a logical grouping of one or more of the services or resources that are provided by a network. Devices connected to the network may either dynamically add themselves to the Djinn or dynamically remove themselves from the Djinn. When added, a device provides zero or more of its services to the Djinn and may utilize all of the services currently provided by the Djinn. The services provided by the
  • Djinn are defined by the lookup service, which provides a common way to both find and utilize the services for the Djinn.
  • the lookup service is a fundamental part of the infrastructure for a Djinn or other computer network offering a range of services. It is the primary means for programs to find services available within the Djinn and is the foundation for providing stubs through which users and administrators can discover and interact with services in the Djinn.
  • Server computer 12(m) also includes a lookup service 400, further described below.
  • the lookup service 400 located on a server 12(m) as shown in FIG. 1, maintains a collection of "service items" 410-418.
  • Each service item 410-418 represents an instance of a service available within the Djinn, and each service item 410 contains a service ID 402 that uniquely identifies the service item, a stub 404 providing code that programs use to access the service, and a collection of attributes 406 that describe the service.
  • the lookup service Upon registering a new service with the lookup service 400, the lookup service gives the new service item 410 a unique service ID 402, typically a number. This service
  • ID 402 can later be used to access the specific service, avoiding unnecessary searching or locating several matching service items upon a query.
  • the service When a new service is created (e.g., when a new device is added to the Djinn), the service registers itself with the lookup service 400, providing a stub 404 to be used by a client to access the service and an initial collection of attributes 406 associated with the service.
  • attributes 406 For example, a printer might include attributes indicating speed (in pages per minute), resolution (in dots per inch), color, and whether duplex printing is supported.
  • the lookup service administrator (not shown) might also add new attributes, such as the physical location of the service and common names for it. Additionally, if a service encounters some problem that needs administrative attention, such as a printer running out of toner, the service can add an attribute that indicates what the problem is.
  • attributes are stored as multi- entries, and the addition, modification and deletion of attributes can be made using multi- templates and the techniques explained in co-pending U.S. Patent Application No. 09/044,839, entitled “Method and System for In-Place Modifications In A Database”, previously incorporated herein.
  • An individual set of attributes is represented as an instance of a class, each attribute being a field of that class.
  • An example of an attribute set for a printer is: public class Printer ⁇ I Inntteeggeerr ppppmm;; / /// pages per minute
  • Boolean color // color or black-only ⁇
  • the class provides strong typing of both the set and the individual attributes.
  • the attributes 406 of service items 410 can also be represented as a set of sets of attributes. Attributes 406 of a service item 410 can contain multiple instances of the same class with different attribute values, as well as multiple instances of different classes. For example, the attributes 406 of a service item 410 might have multiple instances of a Name class, each giving the common name of the service in a different language, plus an instance of a Location class, a Type class, or various other service- specific classes. An example of some added attributes to describe the printer may be the
  • the attributes 406 for this service item 410 would be a set of attributes containing the Printer, Name, Type, and Location class instances, each class containing their own individual attributes.
  • the scheme used for attributes is not constrained by these examples.
  • Programs (including other services) that need a particular type of service can use the lookup service 400 to find a stub that can be used to access the service.
  • a match can be made based on the type of service as well as the specific attributes attached to the service. For example, a client could search for a printer by requesting a stub type corresponding to the service desired or by requesting certain attributes such as a specific location or printing speed.
  • attributes are stored as multi-entries, and a match on attributes can be made using multi- templates, as explained in co-pending U.S. Patent Application No. 09/044,835, entitled "Method and System For Multi-Entry and Multi-Template Matching In A Database", previously incorporated herein. Accessing a Lookup Service Employing Dynamic Stub Loading and Retrieval
  • the stub 404 corresponding to a service is registered in the lookup service 400 and is used by the client computer 1 1 (n) to access the service methods remotely.
  • This stub 404 may also be a "smart proxy.”
  • a smart proxy code within which a stub is embedded, helps the client more efficiently implement the stub and the method to be remotely invoked.
  • a smart proxy often performs some local computation for efficiency before or after it actually calls the stub.
  • a smart proxy may contain code to cache information, so if a client requested it again, instead of going back to the server to get the information, it may have cached the answer and be able to return it quickly. If the situation called for it, a smart proxy might also transform the parameters received from the client into other types and then send the transformed types.
  • FIG. 5 depicts a flowchart illustrating the steps used by systems consistent with the present invention for adding a service stub to the lookup service.
  • a device joins the network, it typically registers a service with the lookup service (step 500).
  • the device Upon registration with the lookup service 400, the device supplies a stub 404 to the lookup service, and it may also give its associated attributes 406 to the lookup service (step 502).
  • the lookup service 400 assigns a unique service ID 402, typically a number as previously stated, to the service registered with the lookup service (step 504).
  • a unique service ID 402 typically a number as previously stated, to the service registered with the lookup service.
  • the device has supplied the lookup service 400 with a stub 404 and attributes 406, and the lookup service has assigned a unique service ID 402, the device has completed registration of the service with the lookup service (step 506).
  • clients can use the lookup service to obtain stub information needed to access the registered services.
  • FIG. 6 depicts a flowchart illustrating steps used by systems and methods consistent with the present invention to download a service item from the lookup service.
  • the client computer l l(n) sends a request for a service to the server 12(m) with the lookup service 400 (step 600).
  • the request originates from the remote method invocation of a class instance 22 on client computer l l(n), and the requested service may reside on a remote server as the exemplary service 38 resides on server 12(1).
  • the client computer 1 l(n) may request one or more services from the lookup service 400.
  • the client's request comes in the form of a specific service ID 402, a type of stub 404, or a set of attributes 406, or any combination thereof (step 602).
  • control 19 directs the stub class loader 33 to locate the corresponding stub 404 from the server 12(m). To do so, the control 19 enables the stub class loader 33 to initiate communication with the server 12(m) to obtain a stub 404 for the service to be obtained.
  • the control 28 in the server 12(m) Upon receipt of the request from the client computer 1 l(n), the control 28 in the server 12(m) searches the lookup service 400 for the stub 404 corresponding to the requested service (step 604). If there are no matches found, the control 28 returns a null value (steps 606 and 608). Otherwise, if it locates the stub 404 corresponding to the service that the client computer 11 (n) is attempting to access, the server 12(m) returns the stub to the stub class loader 33 on the client computer (step 612). If more than one stub was located matching the client's request (step 610), in one embodiment consistent with the present invention, any one of the stubs is returned (step 616). In another implementation where the client requests more than one service, the server 12(m) returns the requested number of the stubs with their attributes (steps 614 and 618).
  • the stub class loader 33 When the stub 404 is received by the stub class loader 33, the stub class loader loads it into the execution environment 20. After it is loaded, the service 38 can be remotely invoked. The use of the stub information to invoke remote processing of the service 38 is performed in the same manner as previously discussed in connection with FIG. 3.
  • the class instance 22 can use the stub 404 to access the service 38 on the server 12(1).
  • control 19 verifies that the stub 404 is present in the execution environment 20. If so. the class instance 22 can then use the stub 404 to initiate communications with the server 12(1) that maintains the service 38, and parameters will be passed to the service 38 for implementation.
  • This lookup service implementation is one application of the dynamic loading and retrieval of stub information to enable a program operating in one address space to invoke processing of a procedure in another address space.
  • This implementation of using the dynamic stub loading on the lookup service allows a client to receive stub information to facilitate use of that service directly.
  • the lookup service consistent with the present invention returns the code needed to access the service directly.
  • Using the dynamic loading of stub information in this way allows the client to receive all the code necessary to facilitate use of the service on a remote server.
  • a network proxy that enables orphan services to utilize the lookup service and become integrated into the network environment previously described.
  • An "orphan service” runs on a device that typically has too little memory to support the JavaTM runtime system, including the Java TM Virtual Machine and Remote Method Invocation (RMI), discussed further below.
  • the network proxy facilitates lookup-service registration and manages resource allocation on behalf of the services.
  • the network proxy thus integrates devices with limited capabilities, as well as their services, into the network environment described above with little retrofitting.
  • FIG. 7 depicts a data processing system 700 suitable for use with this embodiment.
  • Data processing system 700 includes a lookup server 702, a computer 704, a device 706, and a proxy server 708, all of which are interconnected via a network 709.
  • Lookup server 702 includes a memory 710 containing lookup service 400 and JavaTM Runtime System (JRS) 736 and also includes other standard components, such as secondary storage, a CPU, a video display, and an input device.
  • JRS 736 includes the JavaTM Virtual Machine (JVM) 738 and RMI 740.
  • JRS 736, JVM 738, and RMI 740 are provided as part of the JavaTM software development kit available from Sun
  • JVM 738 facilitates platform independence by acting like an abstract computing machine, receiving instructions from programs in the form of byte codes and interpreting these byte codes by dynamically converting them into a form for execution, such as object code, and executing them.
  • RMI 740 facilitates remote method invocation by allowing objects executing on one computer or device to invoke methods of an object on another computer or device.
  • Computer 704 includes a memory 712 containing a client program 714 and JRS 742 and includes other standard components.
  • Device 706 includes a memory 716 containing a protocol stack 720 as well as an orphan service 721 and also includes a CPU 718.
  • Proxy server 708 includes a memory 722 containing a network proxy 726, a protocol stack 728, and JRS 730 and also includes other standard components.
  • Network proxy 726 is responsible for registering orphan service 721 in lookup service 400 so that client program 714 can utilize the orphan service. Additionally, network proxy 726 provides orphan service 721 with access to various other services provided via lookup service 400.
  • Figure 8 depicts a flowchart of the steps performed when the network proxy registers the orphan service with the lookup service so that the client program may utilize it.
  • the first step performed is for the network proxy to obtain a reference to the lookup service (step 802).
  • This step is performed by accessing the discovery server as described in co-pending U.S. Patent Application No. 09/044,939, entitled "Apparatus and Method for Providing Downloadable Code for Use in Communicating with a Device in a
  • the network proxy After obtaining a reference to the lookup service, the network proxy utilizes protocol stack 728 to communicate with the orphan service via protocol stack 720 (step 804). In this step, the network proxy and the orphan service enter into a peer-to-peer communication session using a protocol such as TCP/IP.
  • the orphan service provides the network proxy with sufficient information to construct a stub (or object) for registration in the lookup service as previously described.
  • This information typically stored on the device (e.g., PROM), includes the code for the object, in the form of byte codes, as well as the JavaTM programming language object type.
  • the network proxy registers this object in the lookup service as described above (step 806).
  • the client program may access the lookup service to retrieve the object that was registered (step 808). After retrieving the object, the client program can communicate with and utilize the orphan service by invoking the methods on the object (step 810).
  • the methods of the object registered in the lookup service may communicate directly with the orphan service if the device resides on the same type of network as the client program. Otherwise, if the client resides on a different type of network, the methods may communicate with the network proxy, who will in turn perform a protocol conversion and use the protocol stack to communicate with the orphan service.
  • Figure 9 depicts a flow chart of the steps performed by an alternative embodiment when the network proxy registers the orphan service with the lookup service so that the client program may utilize it.
  • the code for the object is stored remotely with respect to the device. For example, the code may be stored on the proxy server.
  • the orphan service broadcasts a multicast packet to a predefined port on the devices on the network (step 902).
  • the network proxy listens on this port and receives the multicast packet containing a location identifier, such as a URL, indicating a location on the network of where the object is located and the object type.
  • the network proxy responds to the device indicating a successful receipt of the packet (step 904).
  • the network proxy registers the orphan service in the lookup service (step 906).
  • the network proxy may access the object at the specified location and store both the object as well as an indication of its type in the lookup service. Alternatively, the network proxy may store the location identifier and the object type in the lookup service.
  • RMI retrieves the entry in the lookup service, containing the location identifier (e.g., the URL), accesses the object at that location, and returns the object to the client program, as previously described. Later, the client program may access the object that is either stored in or referenced in the lookup service and communicate directly with the orphan service as stated above (step 908).
  • location identifier e.g., the URL
  • Figure 10 depicts a flow chart of the steps performed by the network proxy when managing services on behalf of an orphan service.
  • the first step performed is for the network proxy to receive a request from the orphan service for use of another service identified in the request (step 1002).
  • the network proxy receives the request by listening on the predefined port or by receiving a packet via the protocol stack, depending on the embodiment used. Responsive to this request, the network proxy obtains an object representing the requested service from the lookup service, as previously described, entering into a lease (step 1004).
  • Services in the lookup service are utilized on a lease basis, meaning that the client who is requesting use of the service requests its use for a particular time period, and the service then determines whether it will allow a lease for (1) the entire requested period, (2) less than the entire requested period, or (3) not at all.
  • Leasing of services and resources is further described in copending U.S. Patent Application No. 09/044,923, entitled “Method and System for Leasing Storage,” U.S. Patent Application No. 09/044,838, entitled “Method, Apparatus, and Product for Leasing of Delegation Certificates in a Distributed System," U.S. Patent Application No. 09/044,834, entitled “Method, Apparatus, and Product for Leasing of Group Membership in a Distributed System,” and U.S. Patent Application No.
  • the network proxy may then receive requests from the orphan service to manipulate the object and the network proxy responds by manipulating the object accordingly, thus making use of the requested service (step 1006). In this situation, the network proxy may renew the lease when it is near expiration and may cancel the lease when the orphan service has completed its use of the requested service.
  • aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on or read from other types of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-ROM; a carrier wave from a network, such as the
  • Sun, Sun Microsystems, the Sun logo, JavaTM, and JavaTM-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Abstract

A network proxy is provided that facilitates the integration of orphan services into a network by enabling them to interact with a lookup service that contains an indication of the services that are available on the network. These orphan services typically reside on devices having too little memory to run the components necessary to be integrated into the network. Thus, the network proxy acts as a go between, by registering the orphan services with the lookup service so that clients may access them and by accessing services on behalf of the orphan services. As a result, the network proxy integrates orphan services into the network, when they otherwise would be incapable of doing so.

Description

NETWORK PROXY FOR DEV ICES WITH LIMITED RESOURCES
RELATED APPLICATIONS This application is a Continuation-In-Part of U.S. Patent Application No.09/044,826, filed on March 20, 1998. which is a Continuation-In-Part of U.S. Patent Application No. 08/636.706 filed April 23, 1996, which are both incorporated herein by reference.
The following applications are relied upon and are hereby incorporated by reference in this application.
Provisional U.S. Patent Application No. 60/076,048, entitled "Distributed Computing System," filed on February 26, 1998.
U.S. Patent Application No. 09/044,923, entitled "Method and System for Leasing Storage," filed on March 20, 1998.
U.S. Patent Application No. 09/044,838, entitled "Method, Apparatus, and Product for Leasing of Delegation Certificates in a Distributed System," filed on March 20, 1998.
U.S. Patent Application No.09/044,834, entitled "Method, Apparatus and Product for Leasing of Group Membership in a Distributed System," filed on March 20, 1998. U.S. Patent Application No. 09/044,916, entitled "Leasing for Failure Detection," filed on March 20, 1998. U.S. Patent Application No. 09/044,933, entitled "Method for Transporting
Behavior in Event Based System,"fιled on March 20, 1998.
U.S. Patent Application No. 09/044,919, entitled "Deferred Reconstruction of Objects and Remote Loading for Event Notification in a Distributed System." filed on March 20, 1998. U.S. Patent Application No. 09/044,938, entitled "Methods and Apparatus for
Remote Method Invocation," filed on March 20, 1998.
U.S. Patent Application No. 09/045,652, entitled "Method and System for Deterministic Hashes to Identify Remote Methods," filed on March 20, 1998. U.S. Patent Application No. 09/044,790, entitled "Method and Apparatus for Determining Status of Remote Objects in a Distributed System," filed on March 20, 1998.
U.S. Patent Application No. 09/044,930, entitled "Downloadable Smart Proxies for Performing Processing Associated with a Remote Procedure Call in a Distributed
System," filed on March 20, 1998.
U.S. Patent Application No. 09/044,917, entitled "Suspension and Continuation of Remote Methods," filed on March 20. 1998.
U.S. Patent Application No. 09/044,835, entitled "Method and System for Multi- Entry and Multi-Template Matching in a Database," filed on March 20, 1998.
U.S. Patent Application No. 09/044,839, entitled "Method and System for In- Place Modifications in a Database," filed on March 20, 1998.
U.S. Patent Application No. 09/044,945, entitled "Method and System for Typesafe Attribute Matching in a Database," filed on March 20, 1998. U.S. Patent Application No. 09/044,931, entitled "Dynamic Lookup Service in a Distributed System," filed on March 20, 1998.
U.S. Patent Application No. 09/044,939, entitled "Apparatus and Method for
Providing Downloadable Code for Use in Communicating with a Device in a Distributed
System," filed on March 20, 1998. U.S. Patent Application No. 09/044,932, entitled "Apparatus and Method for
Dynamically Verifying Information in a Distributed System," filed on March 20, 1998.
U.S. Patent Application No. 09/030,840, entitled "Method and Apparatus for Dynamic Distributed Computing Over a Network," filed on February 26, 1998.
U.S. Patent Application No.09/044,936, entitled "An Interactive Design Tool for Persistent Shared Memory Spaces," filed on March 20, 1998.
U.S. Patent Application No. 09/044,934, entitled "Polymorphic Token-Based Control," filed on March 20, 1998.
U.S. Patent Application No. 09/044.915, entitled "Stack-Based Access Control," filed on March 20. 1998. U.S. Patent Application No. 09/044,944, entitled "Stack-Based Security Requirements," filed on March 20, 1998.
U.S. Patent Application No. 09/044,837, entitled "Per-Method Designation of Security Requirements," filed on March 20, 1998. FIELD OF THE INVENTION
The present invention relates generally to data processing systems and. more particularly, to a network proxy.
BACKGROUND OF THE INVENTION
In modern "enterprise" computing, a number of personal computers, workstations, and other devices such as mass storage subsystems, network printers and interfaces to the public telephony system, are typically interconnected in one or more computer networks.
The personal computers and workstations are used by individual users to perform processing in connection with data and programs that may be stored in the network mass storage subsystems. In such an arrangement, the personal computers/workstations, operating as clients, typically download the data and programs from the network mass storage subsystems for processing. In addition, the personal computers or workstations will enable processed data to be uploaded to the network mass storage subsystems for storage, to a network printer for printing, to the telephony interface for transmission over the public telephony system, or the like. In such an arrangement, the network mass storage subsystems, network printers and telephony interface operate as servers, since they are available to service requests from all of the clients in the network. By organizing the network in such a manner, the servers are readily available for use by all of the personal computers/workstations in the network. Such a network may be spread over a fairly wide area, with the personal computers/workstations being interconnected by communication links such as electrical wires or optic fibers.
In addition to downloading information from servers for processing, a client, while processing a program, can remotely initiate processing by a server computer of particular routines and procedures (generally "procedures"), in connection with certain "parameter" information provided by the client. After the server has processed the procedure, it will provide results of its processing to the client, which the client may thereafter use in its processing operations. Typically in such "remote procedure calls" the program will make use of a local "stub" which, when called, transfers the request to the server which implements the particular procedure, receives the results and provides them to the program. Conventionally, the stub must be compiled with the program, in which case the information needed to call the remote procedure must be determined at compile time, rather than at the time the program is run. Since the stub available to the client's programs is static, it may be at best the closest that can be determined should be provided for the program when it (the program) is compiled. Accordingly, errors and inefficiencies can develop due to mismatches between the stub that is provided to a program and the requirements of the remote procedure that is called when the program is run. SUMMARY OF THE INVENTION
A new and improved system and method for facilitating the obtaining and dynamic loading of a stub is provided to enable a program operating in one address space to remotely invoke processing of a method or procedure in another address space, so that the stub can be loaded by the program when it is run and needed, rather than being statically determined when the program is compiled. Indeed, the stub that is loaded can be obtained from the resource providing the remote method or procedure, and so it (the stub) can exactly define the invocation requirements of the remote method or procedure. Since the stub can be located and dynamically loaded while the program is being run, rather than being statically determined when the program is compiled, run- time errors and inefficiencies which may result from mis-matches between the stub that is provided and the requirements of the remote method or procedure that is invoked can be minimized. In an alternative embodiment of the present invention, the stub is obtained from a lookup service to provide access to a service defined in the lookup service.
In brief summary, methods and systems consistent with an alternative embodiment of the present invention facilitate access to a service via a lookup service.
A lookup service defines a network's directory of services and stores references to these services. A client desiring use of a service on the network accesses the lookup service, which returns the stub information that facilitates the user's access of the service. The client uses the stub information to access the service. In a second alternative embodiment of the present invention, a network proxy is provided that facilitates the integration of orphan services into a network by enabling them to interact with a lookup service that contains an indication of the services that are available on the network. In this respect, the lookup service acts like a service registry. These orphan services typically reside on devices having too little memory to run the components necessary to be integrated into the network. Thus, the network proxy acts as a go between, by registering the orphan services with the lookup service so that clients may access them and by accessing services on behalf of the orphan services. As a result, the network proxy integrates orphan services into the network when they otherwise would be incapable of doing so.
In accordance with methods consistent with the present invention, a method is provided in a data processing system including a service on a device, a service registry, and a proxy. According to this method, the proxy receives a request from the service to register with the service registry, obtains information that facilitates accessing the service, and stores the information into the service registry.
In accordance with methods consistent with the present invention, a method for registering a service located on a device in a service registry is provided in a data processing system. According to this method, the service sends a request for registration in the service registry to a proxy server, whereupon the proxy server registers the service in the service registry to enable a client program to access the service, and the service receives a request from the client program for accessing the service. In accordance with methods consistent with the present invention, a method is provided in a data processing system including a client program, a service registry containing a reference to a service on a device, and a proxy server. According to this method, the client program retrieves the reference from the service registry and uses the reference to send a request to access the service to the proxy server. In accordance with systems consistent with the present invention, a data processing system is provided. The data processing system comprises a lookup server, a device, and a proxy server. The lookup server includes a memory with a lookup service containing registrations that facilitate access to corresponding services and includes a processor for running the lookup service. The device includes a memory containing an orphan service that requests registration in the lookup service and includes a processor for running the orphan service. The proxy server includes a memory containing a network proxy that receives the registration request from the orphan service and that registers the orphan service in the lookup service and includes a processor for running the network proxy.
BRIEF DESCRIPTION OF THE DRAWINGS This invention is pointed out with particularity in the appended claims. The above and further advantages of this invention may be better understood by referring to the following description taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a function block diagram of a computer network including an arrangement constructed in accordance with the present invention for facilitating the obtaining, dynamic loading and use of "stub" information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space;
FIGs. 2 and 3 are flow charts depicting the operations performed by the arrangement depicted in FIG. 1, with FIG. 2 depicting operations performed in connection with obtaining and dynamic loading of the stub information and FIG. 3 depicting operations performed in connection with use of the stub information to invoke processing of the remote method or procedure;
FIG. 4 is a diagram illustrating a lookup service consistent with the present invention;
FIG. 5 is a flowchart illustrating a method of adding a stub to the lookup service consistent with the present invention;
FIG. 6 is a flowchart illustrating a method for retrieving a stub from a lookup service by systems consistent with the present invention; FIG. 7 depicts a data processing system suitable for use with a second alternative embodiment of the present invention;
FIG. 8 depicts a flowchart of the steps performed when the network proxy depicted in FIG. 7 registers an orphan service with the lookup service depicted in FIG. 7 in accordance with methods and systems consistent with the present invention; FIG. 9 depicts a flowchart of the steps performed when the network proxy depicted in FIG. 7 registers an orphan service with the lookup service depicted in FIG. 7 in accordance with an alternative embodiment of the present invention; and
FIG. 10 depicts a flowchart of the steps performed when the network proxy depicted in FIG. 7 manages resource allocation on behalf of the orphan service.
DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT
FIG. 1 is a schematic diagram of a computer network 10 including an arrangement for facilitating dynamic loading of "stub" information to enable a program operating in one address space to remotely invoke processing of a method or procedure in another address space, where this method or procedure represents a network service. With reference to FIG. 1 , computer network 10 includes a plurality of client computers 1 1(1) through 11(N) (generally identified by reference numeral l l(n)), a plurality of server computers 12(1) through 12(M) (generally identified by reference numeral 12(m)), all of which are interconnected by a network represented by a communication link 14. In addition, the network 10 may include at least one nameserver computer 13, which may also be connected to communication link 14, whose purpose will be described below. As is conventional, at least some of the client computers 1 l(n) are in the form of personal computers or computer workstations, each of which typically includes a system unit, a video display unit and operator input devices such as a keyboard and mouse (all of which are not separately shown). The server computers 12(m) and nameserver computer 13 also typically include a system unit (also not separately shown), and may also include a video display unit and operator input devices.
The client computers 1 l(n), server computers 12(m) and nameserver computer 13 are all of the conventional stored-program computer architecture. A system unit generally includes processing, memory, mass storage devices such as disk and/or tape storage elements and other elements (not separately shown), including network interface devices 15(n), 16(m) for interfacing the respective computer to the communication link 14. The video display unit permits the computer to display processed data and processing status to the operator, and an operator input device enables the operator to input data and control processing by the computer. The computers l l(n) and 12(m) and 13 transfer information, in the form of messages, through their respective network interface devices 15(n), 16(m) among each other over the communication link 14.
In one embodiment, the network 10 is organized in a "client-server" configuration, in which one or more computers, shown in FIG. 1 as computers 12(m), operate as servers, and the other computers, shown in FIG. 1 as computers 11 (n) operate as clients. In one aspect, one or more of the server computers 12(m) may, as "file servers," include large-capacity mass storage devices which can store copies of programs and data which are available for retrieval by the client computers over the communication link 13 for use in their processing operations. From time to time, a client computer 1 1 (n) may also store data on the server computer 12, which may be later retrieved by it (the client computer that stored the data) or other client computers for use in their processing operations. In addition, one or more of the server computers 12(m) may, as "compute servers," perform certain processing operations in response to a remote request therefor from a client computer 1 l(n), and return the results of the processing to the requesting client computer 1 1 (n) for use by them (that is, the requesting client computers 1 1 (n)) in their subsequent processing. In either case, the server computers may be generally similar to the client computers 1 1 (n), including a system unit, video display unit and operator input devices and may be usable by an operator for data processing operations in a manner similar to a client computer. Alternatively, at least some of the server computers may include only processing, memory, mass storage and network interface elements for receiving and processing retrieval, storage or remote processing requests from the client computers, and generating responses thereto. It will be appreciated a client computer l l(n) may also perform operations described herein as being performed by a server computer 12(m), and similarly a server computer 12(m) may also perform operations described herein as being performed by a client computer 1 l(n).
The network represented by communication link 14 may comprise any of a number of types of networks over which client computers 1 1 (n), server computers 12(m) and nameserver computers 13 may communicate, including, for example, local area networks (LANs) and wide area networks (WANs) which are typically maintained within individual enterprises, the public telephony system, the Internet, and other networks, which may transfer digital data among the various computers. The network may be implemented using any of a number of communication media, including, for example, wires, optical fibers, radio links, and/or other media for carrying signals representing information among the various computers depicted in FIG. 1. As noted above, each of the computers typically includes a network interface which connects the respective computer to the communications link 14 and allows it to transmit and receive information thereover.
Systems consistent with the present invention facilitate the obtaining and dynamic loading of "stub" information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space, which may be located on the same computer as the invoking program or on a different computer.
Reference will be made to programs provided in the Java™ programming language, as described in James Gosling, Bill Joy, Guy Steele, "The Java™ Language Specification", Addison- Wesley, 1996, (hereinafter referred to as the "Java language specification"), incorporated herein by reference, which are processed in connection with an execution environment which is provided by a Java virtual machine. The Java virtual machine, in turn, is specified in the Lindholm andYellin, "The Java Virtual Machine Specification", Addison- Wesley, 1996, 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 may be invoked by reference to an interface. A class may be associated with and extend a "super-class," and in that regard will incorporate all of the interfaces and methods of the super-class, and may also include additional interfaces and/or methods. A class may also have one or more sub-classes (and thus will comprise a super-class of each of its sub-classes), with each sub-class incorporating and possibly extending their respective super-classes.
An interface provides a mechanism by which a set of methods may be declared. In that connection, an interface identifies each method that is declared by the interface by, for example, a name, identities the datatype(s) of argument(s) that are to be provided for the method, the data type(s) of return values that are to be returned by the method, and identifiers for exceptions which can be thrown during processing of the method. A class may indicate that it implements a particular interface, and in that connection will include the program code which will be used in processing all of the methods which are declared in the interface. In addition, different classes may indicate that they implement the same interface, and each will have program code which will be used in processing all of the methods which are declared in the interface, but the program code provided in each class to for use in processing the methods may differ from the program code provided in the other classes which is used in processing the same methods; thus, an interface provides a mechanism by which a set of methods can be declared without providing an indication of the procedure which will be used in processing any of the methods. An interface may be declared independently of the particular class which implements the method or methods which can be invoked using the interface. In that regard, a class that invokes the method and a class that actually implements the method will not need to share a common super-class.
During processing of a Java program, as described in the Java virtual machine specification, a client computer l l(n) provides an execution environment 20 for interpreting the Java program. The Java virtual machine includes a class loader 21 that, under control of a control module 19, can dynamically link instances of classes, generally identified in FIG. 1 by reference numeral 22, into the running program's execution environment while the program is being executed. In that operation, the control module
19 effectively enables the class loader to retrieve uninstantiated classes, which generally identified by reference numeral 23, instantiate them and link them as class instances 22 into the execution environment's address space at the Java program's run time as the methods which the respective classes 23 implement are called. In addition, the class loader 21 can discard ones of the class instances 22 when they are not needed or to conserve memory. It will be appreciated that, if a class instance 22 has been discarded, it may be reloaded by the class loader 21 at a later point if it is then needed.
Systems consistent with the present invention provide an arrangement which facilitates the remote invocation, by a program executing in an execution environment
20 by a client computer 1 l(n), of methods implemented by classes on a server computer 12(m). In executing a method, the server computer 12(m) will also provide an execution environment 24 for processing, under control of a control module 28, the Java method.
In that operation, the Java virtual machine which provides the execution environment 21 includes a class loader 25 (which may be similar to the class loader 21) that, under control of the control module 28, can dynamically link an instance of the class 26, to enable the method to be processed in the execution environment 24, and instances of other classes (also generally represented by reference numeral 26) which may be needed to process the remotely-invoked method. In that operation, the control module 28 effectively enables the class loader 25 to retrieve an uninstantiated class for the method to be invoked, from a plurality of uninstantiated classes which are generally identified by reference numeral 27, instantiate it (that is, the uninstantiated class which provides the method to be invoked) and link it as a class instance 26 into the execution environment. In addition, the class loader 25 can discard the class instances 26 when processing of the method has terminated. It will be appreciated that, if class instances 26 has been discarded, it may be reloaded by the class loader 25 at a later point if it is then needed.
The structure of nameserver computer 13, if provided, is generally similar to that of the server computer 12(m), and will not be separately described. To facilitate remote invocation of a method, the control module 19 of the client computer's execution environment 21 makes use of one or more stub class instances generally identified by reference numeral 30 which are provided as part of the execution environment 21 in which the various class instances 22, including the class instance which is invoking the remote method, are being processed. Each stub class instance 30 is an instance of an uninstantiated stub class 31, which the server computer 12(m) may maintain for the various class instances 26 and uninstantiated classes 27 which the server computer 12(m) has "exported," that is, which the server computer 12(m) makes available to client computers 1 1 (n) for use in remote invocation of methods provided thereby. An uninstantiated stub class 31 includes declarations for the complete set of interfaces for the particular remote uninstantiated class 27 which implements the remote method to be invoked, and also provides or invokes methods which facilitate accessing of the remote method(s) which are implemented by the remote class. The uninstantiated stub class 31 , when it is instantiated and provided to the execution environment 20 of the client computer 1 l(n) as a stub class instance 30, effectively provides the information which is needed by the control module 19 of the execution environment 20 of the invoking Java program, so that, when a remote method that is implemented by its associated class is invoked by a Java program running in a particular execution environment, the remote method will be processed and the return value(s) provided to the invoking Java program. In one embodiment, the arrangement by which the stub class instance may be provided to the execution environment 20 is similar to that described in the aforementioned Waldo, et al., patent application.
In addition, the server computer 12(m) provides a skeleton 32. which identifies the particular classes and methods which have been exported by the server computer 12(m) and information as to how it (that is, the server computer 12(m)) may load the respective classes and initiate processing of the particular methods provided thereby. Additionally, the server computer 12(m) contains a lookup service 400 for registering services on a network. The lookup service 400 will be discussed below.
When a class instance invokes a remote method maintained by a server computer 12(m), it will provide values for various parameters to the stub class instance 30 for the remote method, which values the remote method will use in its processing. If the remote method is implemented on the same computer as the invoking Java program, when the invoking Java program invokes a remote method, the computer may establish an execution environment, similar to the execution environment 20, enable the execution environment's class loader to load and instantiate the class which implements the method as a class instance similar to class instances 22, and process the remote method using values of parameters which are provided by the invoking class instance in the remote invocation. After processing of the method has been completed, the execution environment in which the remote method has been processed will provide the results to the stub class instance 30 for the remote method that was invoked, which, in turn, will provide to the particular class instance 22 which invoked the remote method. Similar operations will be performed if client computer 11 (n) and server computer
12(m) are implemented on different physical computers. In that case, in response to a remote invocation, the client computer l l(n) that is processing the invoking class instance 22, under control of the control module 19 for the execution environment 20 for the invoking class instance 22, will use the appropriate stub class instance 30 to communicate over the network represented by the communication link 14 with the server computer 12(m) which implements the remote method to enable it (that is, the server computer 12(m)) to establish an execution environment 24 for the class which implements the remote method, and to use the class loader 25 to load an instance of the class as a class instance 26. In addition, the client computer l l(n). also using the appropriate stub class instance 30, will provide any required parameter values to the server computer 12(m) over the network 14. Thereafter, the server computer 12(m) will process the remote method using parameter values so provided, to generate result value(s) which are transferred over the network to the client computer 1 1 (n), in particular to the appropriate stub class instance 30. The client computer 1 l(n) will, after it receives the result value(s) from the network, provide them to the invoking class instance 22 for its processing.
In any case, when the control module 19 of the client computer's execution environment 20 determines that a reference to the remote object has been received, if it determines that the stub class instance 30 is not present when it receives the reference, it will attempt to obtain the stub class instance 30 from, for example, the server computer 12(m) which implements the remote method, and enable the stub class instance 30 to be dynamically loaded in the execution environment 20 for the invoking class instance 22. A reference to the remote object may be received, for example, either as a return value of another remote method invocation or as a parameter that is received during another remote method invocation. The stub class instance may be dynamically loaded into the execution environment in a manner similar to that used to load class instances 22 in the execution environment 22. The execution environment 20 is provided with a stub class loader 33 which, under control of the control module 19, will attempt to find and load the stub class instances 30 as required by the class instances 22 processed in the execution environment. The location of a particular server computer 12(m) that maintains the class that implements a method to be invoked remotely may be included in the call from the invoking class instance or may be made known to the stub class loader 33 through another mechanism (not shown) maintained by the client computer 1 l(n).
However, if the stub class loader 33 is not otherwise notified of which server computer 12(m) maintains the class which implements a method which may be invoked remotely, it may use the nameserver computer 13 to provide that identification. The identification may comprise any identifier which may be used to identify a server computer 12(m) or other resource which is available on the network 14 and to which the server computer 12(m) can respond. Illustrative identifiers include, for example, a network address which identifies the server computer and/or resource, or, if the network 14 is or includes the Internet, an identifier to, for example, a World Wide Web resource which may provide the identification or a "uniform resource locator" ("URL") which provides a uniform mechanism for identifying resources that are available over the Internet. The server computer 12(m) which implements the remote method, in response to a request from the client computer 11 (n) will provide stub class instance 30 which the client computer 1 l(n) may load into the execution environment 21 to thereafter enable the remote invocation to be initiated.
As noted above, if the stub class loader 33 does not know which server computer 12(m) implements the remote method which may be invoked (and thus does not know which computer is to provide the stub class code for the remote invocation), it may, under control of the control module 19, obtain the identification from the nameserver computer 13. In that operation, the stub class loader 33 may use a previously-provided default stub class which is provided for use in such cases. The default class stub, when used by the invoking Java program, enables the computer that is processing the invoking Java program to communicate with the nameserver computer 13 to obtain information which can be used in invoking the remote method. This operation is essentially the same as the invocation of a remote method to be processed by the nameserver computer 13, with the remote method including a parameter identifying the class and method to be remotely invoked, and enabling the nameserver computer 13 to provide the identification of a server computer 12(m) which can process the method to the requesting client computer 1 1 (n) and other information which may be helpful in communicating with the server computer 12(m) and invoking the particular method. It will be appreciated that the nameserver computer 13 will maintain a table (not separately shown) of "exported" resources, that is, resources, such as classes and methods, that are available to client computers 11 (n) connected to the network 14, and information, such as the identifications of the particular server computers 12(m) which provide those resources, which will be useful to the client computers 1 l(n) in making use of the exported resources. It will be appreciated that the nameserver computer 13 may create and maintain the exported resource table in a number of ways that are known in the art. For example, the nameserver computer 13 may periodically broadcast requests for exported resource information over the network 14, to which the various server computers 12(m) which maintain exported resources may respond; in that case, the nameserver computer 13 may establish its exported resource table based on the responses from the server computers 12(m). Alternatively, each of the various server computers 12(m) which maintains an exported resource may periodically broadcast information as to the exported resources which it maintains, and the nameserver computer 13 can update its exported resource table based on the broadcasts from the server computer. In addition, the nameserver computer's exported resource table may be established by a system operator and may be fixed until he or she updates it.
In any case, the information provided by the nameserver computer 13 in response to a request initiated by the default stub would include such information as, for example, the identification of a computer 12(m) which can provide a class which implements the remote method to be invoked, particular information which the computer (that is, the computer which implements the remote method) will require to provide the required stub class code, and the like. After receiving the information from the nameserver computer 13, the computer 1 1 (n) that is processing the invoking Java program may, under control of the control module 19, use the information communicate with the computer (that is, the computer which implements the remote method) to obtain the stub class, and may thereafter invoke the method as described above.
With this background, the operations performed by client computer 1 l(n), server computer 12(m) and, if necessary, nameserver 13 in connection with obtaining and dynamic loading of a stub class instance when a reference to a remote method is received will be described in connection with the flow chart depicted in FIG. 2. In addition, operations performed by the client computer 1 1 (n) and server computer in connection with remote invocation of a method using the stub class instance will be described in connection with the flow chart depicted in FIG. 3. With reference initially to FIG. 2, the execution environment control module 19 will, when it receives a reference to a remote method, will initially determine whether an appropriate stub class instance is present in the execution environment 20 to facilitate invocation of the remote method (step 100). If the control module 19 determines that such a stub class instance 30 for the remote method is present in the execution environment, it may continue other operations (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 will use the stub class loader 33 to attempt to locate and load a stub class instance 30 for the class to process the remote method. In that case, the control module 19 will initially determine whether the invocation from the class instance 22 included a resource locator to identify the server computer 12(m) or other resource which maintains the class for the method to be invoked, or whether it (that is, the control module 19) or the stub class loader 33 otherwise are provided with such a resource locator (step 102). If the control module 19 makes a positive determination in that step, it will sequence to step 103 to enable the stub class loader 33 to initiate communications with identified server computer 12(m) to obtain stub class instance for the class and method to be invoked (step 103). When the stub class loader 33 receives the stub class instance 30 from the server computer 12(m), it will load the stub class instance 30 into execution environment 20 for the class instance 22 which initiated the remote method invocation call in step 100 (step 104). After the stub class instance 30 for the referenced remote method has been loaded in the execution environment, the method can be invoked as will be described below in connection with FIG. 3.
Returning to step 102, if the control module 19 determines that the invocation from the class instance 22 did not include a resource locator to identify the server computer 12(m) or other resource which maintains the class for the method to be invoked, and further that it (that is, the control module 19) or the stub class loader 33 is not otherwise provided with such a resource locator, a "class not found" exception may be indicated, at which point the control module 19 may call an 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 located and allow it to determine subsequent operations. Alternatively, the control module 19 may attempt to obtain a resource locator from the nameserver computer 13 or other resource provided by the network 14 (generally represented in FIG. 1 by the nameserver computer 13). using a call, for example, a default stub class instance 30. The call to the default stub class instance 30 will include an identification of the class and method to be invoked and the name of the nameserver computer 13(m). Using the default stub class instance 30, the control module 19 will enable the computer 1 1 (n) to initiate communications with nameserver computer
13 to obtain an identifier for a server computer 12(m) which maintains the class and method to be invoked (step 1 10). The communications from the default stub class instance 30 will essentially correspond to a remote method invocation, with the method enabling the nameserver computer to provide the identification for the server computer 12(m), if one exists associated with the class and method to be remotely invoked, or alternatively to provide an indication that no server computer 12(m) is identified as being associated with the class and method. During the communications in step 110, the default stub class interface 30 will provide, as a parameter value, the identification of class and method to be invoked. In response to the communications from the default stub class instance 30, the nameserver computer 13 will process the request as a remote method (step 1 11), with the result information comprising the identification for the server computer 12(m), if one exists that is associated with the class and method to be remotely invoked, or alternatively an indication that no server computer 12(m) is identified as being associated with the class and method. After finishing the method, the nameserver computer 13 will initiate communications with the default stub class instance 30 to provide the result information to the default stub class instance 30 (step 112).
After receipt of the result information from the nameserver computer 13, the default stub class instance, under control of the control module 19, will pass result information to the stub class loader 33 (step 113). Thereafter, the stub class loader 33 determines whether the result information from the nameserver computer comprises the identification for the server computer 12(m) or an indication that no server computer 12(m) is identified as being associated with the class (step 1 14). If the stub class loader 33 determines that the result information comprises the identification for the server computer 12(m), it (that is, the stub class loader 33) will return to step 101 to initiate communication with the identified server computer 12(m) to obtain stub class instance for the class and method that may be invoked. On the other hand, if the stub class loader 33 determines in step 114 that the nameserver computer 13 had provided an indication that no server computer 12(m) is identified as being associated with the class and method that may be invoked, the "class not found" exception may be indicated (step 1 15) and an exception handler called as described above.
As noted above, the stub class instance 30 retrieved and loaded as described above in connection with FIG. 2 may be used in remote invocation of the method. Operations performed by the client computer l l(n) in connection with remote invocation of the method will be described in connection with the flow chart in FIG. 3. As depicted in FIG. 3, when a class instance 22 invokes a method, the control module 19 may initially verify that a stub class instance 30 is present in the execution environment for remote method to be invoked (step 120). If a positive determination is made in step 120, the stub class instance 30 will be used for the remote invocation, and in the remote invocation will provide parameter values which are to be used in processing the remote method (step 121). Thereafter, the stub class instance 30 for the remote method that may be invoked will be used to initiate communications with the server computer 12(m) which maintains the class for the remote method (step 122), in the process, the passing parameter values which are to be used in processing the remote method will be passed. It will be appreciated that, if the server computer 12(m) which is to process the method is the same physical computer as the client computer 12(n) which is invoking the method, the communications can be among execution environments which are being processed within the physical computer. On the other hand, if the server computer 12(m) which is to process the method is a different physical computer from that of the client computer 12(n) which is invoking the method, the communications will be through the client computer's and server computer's respective network interfaces 15(n) and 16(m) and over the network 14.
In response to the communications from the stub class instance in step 122, the server computer 12(m), if necessary establishes an execution environment 24 for the class which maintains the method that may be invoked, and the uses the information provided by the skeleton 32 to create a class instance 26 for that class (step 123). Thereafter, the server computer 12(m), under control of the control module 28, will process the method in connection with parameter values that were provided by stub class instance 30 (step 124). After completing processing of the method, the server computer 12(m), also under control of the control module 28, will initiate communications with the client computer's stub class instance 30 to provide result information to the stub class instance (step 125). In a manner similar to that described above in connection with step 102, if the server computer 12(m) which processed the method is the same physical computer as the client computer 12(n) which invoked the method, the communications can be among execution environments 24 and 20 which are being processed within the physical computer. On the other hand, if the server computer 12(m) which processed the method is a different physical computer from that of the client computer 12(n) which is invoking the method, the communications will be through the server computer's and client computer's respective network interfaces 16(m) and 15(n) and over the network 14. After the stub class instance 30 receives the result information from the server computer, it may provide result information to the class instance 22 which initiated the remote method invocation (step 126), and that class instance 22 can continue processing under control of the control module 19.
Returning to step 120, if the control module 19 determines in that step that it does not have a stub class instance 30 that is appropriate for the remote method that may be invoked, it may at that point call an exception handler (step 127) to perform selected error recovery operations.
Methods and systems consistent with the present invention provide a number of advantages. In particular, they provide a new system and method for facilitating dynamic loading of a stub which enables a program that is operating in one execution environment to remotely invoke processing of a method in another execution environment, so that the stub can be loaded by the program when it is run and needed. In systems in which stubs are compiled with the program, and thus are statically determined when the program is compiled, they (the stubs) may implement subsets of the actual set of remote interfaces which are supported by the remote references that is received by the program, which can lead to errors and inefficiencies due to mismatches between the stub that is provided to a program and the requirements of the remote procedure that is called when the program is run. However, since, in the dynamic stub loading system and method, the stub that is loaded can be obtained from the particular resource which provides the remote method, it (the stub) can define the exact set of interfaces to be provided to the invoking program at run time, thereby obviating run-time incompatibilities which may result from mismatches between the stub that is provided and the requirements of the remote method that is invoked.
It will be appreciated that a number of modifications may be made to the arrangement as described above. For example, although the execution environment 20 has been described as obtaining and loading stub class instances to facilitate invocation of remote methods when references to the remote methods are received, it will be appreciated that stub class instances may instead be obtained and loaded when the remote methods are initially invoked. Obtaining and loading of the stub class instance for a remote method when a reference thereto is received will have the advantages that (I) the stub class instance will be present in the execution environment when the remote method is actually invoked, and (ii) if the appropriate stub class instance can not be located, the program or an operator may be notified at an early time. On the other hand, obtaining and loading of the stub class instance for a remote method when the method is to be invoked may result in a delay of the invocation until the correct stub class instance can be found, if the method is in fact not invoked even if a reference to it is received the stub class instance may not need to be located and loaded. It will be appreciated that a system in accordance with the invention can be constructed in whole or in part from special purpose hardware or a general purpose computer system, or any combination thereof, any portion of which may be controlled by a suitable program. Any program may in whole or in part comprise part of or be stored on the system in a conventional manner, or it may in whole or in part be provided in to the system over a network or other mechanism for transferring information in a conventional manner. In addition, it will be appreciated that the system may be operated and/or otherwise controlled by means of information provided by an operator using operator input elements (not shown) which may be connected directly to the system or which may transfer the information to the system over a network or other mechanism for transferring information in a conventional manner.
Alternative Embodiment of the Present Invention Although an embodiment consistent with the present invention has been previously described that dynamically retrieves and loads stubs, an alternative embodiment also consistent with the present invention loads and retrieves objects in a lookup service, where the objects contain code (stub information) for facilitating communication with a particular service or the objects contain code that performs the service. Although the alternative embodiment is described below as downloading objects from the lookup service that represent stubs, the techniques described below are equally applicable to downloading objects that actually perform the services. A lookup service defines a network's directory of services and stores references to these services. A user desiring use of a service on the network accesses the lookup service, which returns the stub information that facilitates the user's access of the service.
The lookup service may contain a subset of all services available in the network, referred to as a "Djinn" as described in copending U.S. Patent Application Serial No. 09/044,931 , entitled "Dynamic Lookup Service in a Distributed System," assigned to a common assignee, filed on even date herewith, which has been previously incorporated by reference. A "Djinn" refers to a logical grouping of one or more of the services or resources that are provided by a network. Devices connected to the network may either dynamically add themselves to the Djinn or dynamically remove themselves from the Djinn. When added, a device provides zero or more of its services to the Djinn and may utilize all of the services currently provided by the Djinn. The services provided by the
Djinn are defined by the lookup service, which provides a common way to both find and utilize the services for the Djinn.
The lookup service is a fundamental part of the infrastructure for a Djinn or other computer network offering a range of services. It is the primary means for programs to find services available within the Djinn and is the foundation for providing stubs through which users and administrators can discover and interact with services in the Djinn.
Reference will now be made to FIG. 4, which depicts lookup service 400 in greater detail. Server computer 12(m), also includes a lookup service 400, further described below. The lookup service 400, located on a server 12(m) as shown in FIG. 1, maintains a collection of "service items" 410-418. Each service item 410-418 represents an instance of a service available within the Djinn, and each service item 410 contains a service ID 402 that uniquely identifies the service item, a stub 404 providing code that programs use to access the service, and a collection of attributes 406 that describe the service.
Upon registering a new service with the lookup service 400, the lookup service gives the new service item 410 a unique service ID 402, typically a number. This service
ID 402 can later be used to access the specific service, avoiding unnecessary searching or locating several matching service items upon a query.
When a new service is created (e.g., when a new device is added to the Djinn), the service registers itself with the lookup service 400, providing a stub 404 to be used by a client to access the service and an initial collection of attributes 406 associated with the service. For example, a printer might include attributes indicating speed (in pages per minute), resolution (in dots per inch), color, and whether duplex printing is supported. The lookup service administrator (not shown) might also add new attributes, such as the physical location of the service and common names for it. Additionally, if a service encounters some problem that needs administrative attention, such as a printer running out of toner, the service can add an attribute that indicates what the problem is. In one implementation consistent with the present invention, attributes are stored as multi- entries, and the addition, modification and deletion of attributes can be made using multi- templates and the techniques explained in co-pending U.S. Patent Application No. 09/044,839, entitled "Method and System for In-Place Modifications In A Database", previously incorporated herein.
An individual set of attributes is represented as an instance of a class, each attribute being a field of that class. An example of an attribute set for a printer is: public class Printer { I Inntteeggeerr ppppmm;; / /// pages per minute
Integer dpi; // resolution in dots per inch
Boolean duplex; // supports two-sided printing
Boolean color; // color or black-only } The class provides strong typing of both the set and the individual attributes.
The attributes 406 of service items 410 can also be represented as a set of sets of attributes. Attributes 406 of a service item 410 can contain multiple instances of the same class with different attribute values, as well as multiple instances of different classes. For example, the attributes 406 of a service item 410 might have multiple instances of a Name class, each giving the common name of the service in a different language, plus an instance of a Location class, a Type class, or various other service- specific classes. An example of some added attributes to describe the printer may be the
Name, Type, or Location: public class Name implements Entry {
String name; // the user-friendly name of the service String description; // free-form description of the service
String language; // language (e.g., English, French) used in the above } public class Type implements Entry {
String type; // the general type of service String vendor; // vendor of product that implements the service
String model; // model number/name of product String version; // version number of product
} public class Location implements Entry {
Integer floor; // what floor the service is on String building;// what building it's in String room; // what room it's in
}
In this example, the attributes 406 for this service item 410 would be a set of attributes containing the Printer, Name, Type, and Location class instances, each class containing their own individual attributes. However, it should be noted that the scheme used for attributes is not constrained by these examples.
Programs (including other services) that need a particular type of service can use the lookup service 400 to find a stub that can be used to access the service. A match can be made based on the type of service as well as the specific attributes attached to the service. For example, a client could search for a printer by requesting a stub type corresponding to the service desired or by requesting certain attributes such as a specific location or printing speed. In one implementation consistent with the present invention, attributes are stored as multi-entries, and a match on attributes can be made using multi- templates, as explained in co-pending U.S. Patent Application No. 09/044,835, entitled "Method and System For Multi-Entry and Multi-Template Matching In A Database", previously incorporated herein. Accessing a Lookup Service Employing Dynamic Stub Loading and Retrieval
Referring back to FIG. 4, the stub 404 corresponding to a service is registered in the lookup service 400 and is used by the client computer 1 1 (n) to access the service methods remotely. This stub 404 may also be a "smart proxy." A smart proxy, code within which a stub is embedded, helps the client more efficiently implement the stub and the method to be remotely invoked. A smart proxy often performs some local computation for efficiency before or after it actually calls the stub. For example, a smart proxy may contain code to cache information, so if a client requested it again, instead of going back to the server to get the information, it may have cached the answer and be able to return it quickly. If the situation called for it, a smart proxy might also transform the parameters received from the client into other types and then send the transformed types.
The smart proxy concept is further explained in co-pending U.S. Patent Application No. 09/044,930, entitled "Downloadable Smart Proxies for Performing Processing Associated with a Remote Procedure Call in a Distributed System," assigned to a common assignee, filed on even date herewith, which is hereby incorporated by reference. FIG. 5 depicts a flowchart illustrating the steps used by systems consistent with the present invention for adding a service stub to the lookup service. When a device joins the network, it typically registers a service with the lookup service (step 500). Upon registration with the lookup service 400, the device supplies a stub 404 to the lookup service, and it may also give its associated attributes 406 to the lookup service (step 502). In response, the lookup service 400 assigns a unique service ID 402, typically a number as previously stated, to the service registered with the lookup service (step 504). Once the device has supplied the lookup service 400 with a stub 404 and attributes 406, and the lookup service has assigned a unique service ID 402, the device has completed registration of the service with the lookup service (step 506). After services are registered with the lookup service 400, clients can use the lookup service to obtain stub information needed to access the registered services. FIG. 6 depicts a flowchart illustrating steps used by systems and methods consistent with the present invention to download a service item from the lookup service. In one implementation, the client computer l l(n) sends a request for a service to the server 12(m) with the lookup service 400 (step 600). The request originates from the remote method invocation of a class instance 22 on client computer l l(n), and the requested service may reside on a remote server as the exemplary service 38 resides on server 12(1). In one implementation consistent with the present invention, the client computer 1 l(n) may request one or more services from the lookup service 400. The client's request comes in the form of a specific service ID 402, a type of stub 404, or a set of attributes 406, or any combination thereof (step 602). In response to the request, control 19 directs the stub class loader 33 to locate the corresponding stub 404 from the server 12(m). To do so, the control 19 enables the stub class loader 33 to initiate communication with the server 12(m) to obtain a stub 404 for the service to be obtained.
Upon receipt of the request from the client computer 1 l(n), the control 28 in the server 12(m) searches the lookup service 400 for the stub 404 corresponding to the requested service (step 604). If there are no matches found, the control 28 returns a null value (steps 606 and 608). Otherwise, if it locates the stub 404 corresponding to the service that the client computer 11 (n) is attempting to access, the server 12(m) returns the stub to the stub class loader 33 on the client computer (step 612). If more than one stub was located matching the client's request (step 610), in one embodiment consistent with the present invention, any one of the stubs is returned (step 616). In another implementation where the client requests more than one service, the server 12(m) returns the requested number of the stubs with their attributes (steps 614 and 618).
When the stub 404 is received by the stub class loader 33, the stub class loader loads it into the execution environment 20. After it is loaded, the service 38 can be remotely invoked. The use of the stub information to invoke remote processing of the service 38 is performed in the same manner as previously discussed in connection with FIG. 3.
Generally, the class instance 22 can use the stub 404 to access the service 38 on the server 12(1). When the class instance 22 requires use of the service 38 corresponding to the returned stub 404, control 19 verifies that the stub 404 is present in the execution environment 20. If so. the class instance 22 can then use the stub 404 to initiate communications with the server 12(1) that maintains the service 38, and parameters will be passed to the service 38 for implementation.
This lookup service implementation is one application of the dynamic loading and retrieval of stub information to enable a program operating in one address space to invoke processing of a procedure in another address space. This implementation of using the dynamic stub loading on the lookup service allows a client to receive stub information to facilitate use of that service directly. Unlike previous lookup services, the lookup service consistent with the present invention returns the code needed to access the service directly. Using the dynamic loading of stub information in this way allows the client to receive all the code necessary to facilitate use of the service on a remote server. Second Alternative Embodiment of the Present Invention.
In accordance with a second alternative embodiment of the present invention, a network proxy is provided that enables orphan services to utilize the lookup service and become integrated into the network environment previously described. An "orphan service" runs on a device that typically has too little memory to support the Java™ runtime system, including the Java ™ Virtual Machine and Remote Method Invocation (RMI), discussed further below. To integrate such services into the network environment, the network proxy facilitates lookup-service registration and manages resource allocation on behalf of the services. The network proxy thus integrates devices with limited capabilities, as well as their services, into the network environment described above with little retrofitting.
Figure 7 depicts a data processing system 700 suitable for use with this embodiment. Data processing system 700 includes a lookup server 702, a computer 704, a device 706, and a proxy server 708, all of which are interconnected via a network 709.
Lookup server 702 includes a memory 710 containing lookup service 400 and Java™ Runtime System (JRS) 736 and also includes other standard components, such as secondary storage, a CPU, a video display, and an input device. JRS 736 includes the Java™ Virtual Machine (JVM) 738 and RMI 740. JRS 736, JVM 738, and RMI 740 are provided as part of the Java™ software development kit available from Sun
Microsystems of Mountain View, CA. JVM 738 facilitates platform independence by acting like an abstract computing machine, receiving instructions from programs in the form of byte codes and interpreting these byte codes by dynamically converting them into a form for execution, such as object code, and executing them. RMI 740 facilitates remote method invocation by allowing objects executing on one computer or device to invoke methods of an object on another computer or device.
Computer 704 includes a memory 712 containing a client program 714 and JRS 742 and includes other standard components. Device 706 includes a memory 716 containing a protocol stack 720 as well as an orphan service 721 and also includes a CPU 718. Proxy server 708 includes a memory 722 containing a network proxy 726, a protocol stack 728, and JRS 730 and also includes other standard components. Network proxy 726 is responsible for registering orphan service 721 in lookup service 400 so that client program 714 can utilize the orphan service. Additionally, network proxy 726 provides orphan service 721 with access to various other services provided via lookup service 400. Figure 8 depicts a flowchart of the steps performed when the network proxy registers the orphan service with the lookup service so that the client program may utilize it. The first step performed is for the network proxy to obtain a reference to the lookup service (step 802). This step is performed by accessing the discovery server as described in co-pending U.S. Patent Application No. 09/044,939, entitled "Apparatus and Method for Providing Downloadable Code for Use in Communicating with a Device in a
Distributed System," filed on March 20, 1998, assigned to a common assignee, which has previously been incorporated by reference. After obtaining a reference to the lookup service, the network proxy utilizes protocol stack 728 to communicate with the orphan service via protocol stack 720 (step 804). In this step, the network proxy and the orphan service enter into a peer-to-peer communication session using a protocol such as TCP/IP.
During this session, the orphan service provides the network proxy with sufficient information to construct a stub (or object) for registration in the lookup service as previously described. This information, typically stored on the device (e.g., PROM), includes the code for the object, in the form of byte codes, as well as the Java™ programming language object type. Next, the network proxy registers this object in the lookup service as described above (step 806). After the network proxy registers the orphan service, the client program may access the lookup service to retrieve the object that was registered (step 808). After retrieving the object, the client program can communicate with and utilize the orphan service by invoking the methods on the object (step 810). In this step, the methods of the object registered in the lookup service may communicate directly with the orphan service if the device resides on the same type of network as the client program. Otherwise, if the client resides on a different type of network, the methods may communicate with the network proxy, who will in turn perform a protocol conversion and use the protocol stack to communicate with the orphan service. Figure 9 depicts a flow chart of the steps performed by an alternative embodiment when the network proxy registers the orphan service with the lookup service so that the client program may utilize it. In this embodiment, the code for the object is stored remotely with respect to the device. For example, the code may be stored on the proxy server. Since the code is not stored on the device, a peer-to-peer communication session is not necessary, thus relieving the need for the proxy server to utilize a protocol stack and anything else specific to the device, such as a device driver, and allowing the code to be modified without having to access the device. As a result, if the code were burned in PROM, significant processing would be avoided.
In this embodiment, the orphan service broadcasts a multicast packet to a predefined port on the devices on the network (step 902). The network proxy listens on this port and receives the multicast packet containing a location identifier, such as a URL, indicating a location on the network of where the object is located and the object type. The network proxy then responds to the device indicating a successful receipt of the packet (step 904). After receiving the location identifier and the object type, the network proxy registers the orphan service in the lookup service (step 906). In this step, the network proxy may access the object at the specified location and store both the object as well as an indication of its type in the lookup service. Alternatively, the network proxy may store the location identifier and the object type in the lookup service. In this case, when the client program requests the object from the lookup service, RMI retrieves the entry in the lookup service, containing the location identifier (e.g., the URL), accesses the object at that location, and returns the object to the client program, as previously described. Later, the client program may access the object that is either stored in or referenced in the lookup service and communicate directly with the orphan service as stated above (step 908).
Figure 10 depicts a flow chart of the steps performed by the network proxy when managing services on behalf of an orphan service. The first step performed is for the network proxy to receive a request from the orphan service for use of another service identified in the request (step 1002). In this step, the network proxy receives the request by listening on the predefined port or by receiving a packet via the protocol stack, depending on the embodiment used. Responsive to this request, the network proxy obtains an object representing the requested service from the lookup service, as previously described, entering into a lease (step 1004). Services in the lookup service are utilized on a lease basis, meaning that the client who is requesting use of the service requests its use for a particular time period, and the service then determines whether it will allow a lease for (1) the entire requested period, (2) less than the entire requested period, or (3) not at all. Leasing of services and resources is further described in copending U.S. Patent Application No. 09/044,923, entitled "Method and System for Leasing Storage," U.S. Patent Application No. 09/044,838, entitled "Method, Apparatus, and Product for Leasing of Delegation Certificates in a Distributed System," U.S. Patent Application No. 09/044,834, entitled "Method, Apparatus, and Product for Leasing of Group Membership in a Distributed System," and U.S. Patent Application No.
09/044,916, entitled "Leasing for Failure Detection," all of which have been previously incorporated by reference. The network proxy may then receive requests from the orphan service to manipulate the object and the network proxy responds by manipulating the object accordingly, thus making use of the requested service (step 1006). In this situation, the network proxy may renew the lease when it is near expiration and may cancel the lease when the orphan service has completed its use of the requested service.
Although aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects can also be stored on or read from other types of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-ROM; a carrier wave from a network, such as the
Internet; or other forms of RAM or ROM either currently known or later developed. Sun, Sun Microsystems, the Sun logo, Java™, and Java™-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
The foregoing description has been limited to specific embodiments of the present invention. It will be apparent, however, that various variations and modifications may be made. It is the object of the appended claims to cover these and such other variations and modifications as come within the true spirit and scope of the invention.

Claims

What is Claimed is:
1. A method in a data processing system containing a service on a device, a service registry and a proxy, the method performed by the proxy comprising the steps of: receiving a request from the service to register with the service registry; obtaining information that facilitates accessing the service; and storing the information in the service registry to register the service.
2. The method of claim 1 , wherein the information is an object containing code for communicating with the service.
3. The method of claim 2, wherein the code comprises byte codes suitable for running on an abstract computing machine.
4. The method of claim 1 wherein the information is a location identifier indicating a location of an object containing code for communicating with the service.
5. The method of claim 1 , wherein the receiving step includes: receiving a location identifier indicating a location of an object containing code for communicating with the service, wherein the obtaining step includes retrieving the object from the location, and wherein the storing step includes storing the retrieved object in the service registry.
6. The method of claim 1, further including the steps of: receiving a request to access a resource from the service; and providing the service with access to the resource.
7. The method of claim 6, wherein the service registry contains an object with methods for accessing the resource and wherein the providing step includes the steps of: retrieving the object from the service registry; and invoking a method on the object to facilitate accessing the resource.
8. The method of claim 6 wherein the providing step includes the step of: leasing the resource.
9. The method of claim 8. further including the steps of: accessing the resource on behalf of the service; determining when the lease is near expiration; and renewing the lease when it is determined that the lease is near expiration.
10. A method in a data processing system having a service on a device and a service registry, the method for registering the service in the service registry comprising the steps performed by the service of: sending a request for registration in the service registry to a proxy server, whereupon the proxy server registers the service in the service registry to enable a client program to access the service; and receiving a request from the client program for accessing the service.
11. The method of claim 10 wherein the receiving step includes the step of: receiving the request via the proxy server.
12. A method in a data processing system containing a client program, a service registry containing a reference to a service on a device, and a proxy server, the method comprising the steps performed by the client program of: retrieving the reference from the service registry; and using the reference to send a request to access the service to the proxy server.
13. A method in a data processing system containing an orphan service on a device, a network proxy, a lookup service, and a client program, the method comprising the steps of: sending a request from the orphan service to the network proxy for registration in the lookup service; receiving the request by the network proxy; registering the orphan service in the lookup service by the network proxy; accessing the lookup service by the client program to obtain the registration of the orphan service; and accessing the orphan service by the client program using the registration.
14. The method of claim 13 wherein the sending step includes: sending an object to the network proxy for registration in the lookup service, and wherein the registering step includes: registering the object.
15. The method of claim 13 wherein the sending step includes: sending a location identifier to the network proxy, and wherein the registering step includes registering the location identifier.
16. The method of claim 13 wherein the sending step includes: sending a location identifier to the network proxy, wherein the location identifier identifies the location of an object, and wherein the registering step includes accessing the object using the location identifier and registering the object in the lookup service.
17. The method of claim 13 wherein the client program communicates using a first protocol and the oφhan service communicates using a second protocol, and wherein the accessing the oφhan service step includes: requesting the network proxy to access the oφhan service on behalf of the client program, wherein the request is communicated using the first protocol; converting the request into a format suitable to the second protocol by the network proxy; and sending the request to the oφhan service by communicating to the oφhan service using the second protocol.
18. A data processing system, comprising: a lookup server containing: a memory with a lookup service containing registrations that facilitate access to corresponding services, and a processor for running the lookup service; a device containing: a memory including an oφhan service that requests registration in the lookup service, and a processor for running the oφhan service; and a proxy server containing: a memory containing a network proxy that receives the registration request from the oφhan service and that registers the oφhan service in the lookup service, and a processor for running the network proxy.
19. The data processing system of claim 18 wherein the network proxy registers the oφhan service by storing in the lookup service an object containing methods that facilitate access to the oφhan service.
20. The data processing system of claim 19 further including: a computer containing: a memory with a client program that retrieves from the lookup service the object corresponding to the oφhan service and that invokes the methods to access the oφhan service; and a processor for running the client program.
21. The data processing system of claim 20 wherein the methods access the oφhan service via the network proxy.
22. The data processing system of claim 21 wherein the network proxy performs protocol conversion when accessing the oφhan service on behalf of the client program.
23. The data processing system of claim 18 wherein the memory of the lookup server and the proxy server include the Java™ runtime system, and wherein the lookup service and the network proxy utilize the Java runtime system.
24. A computer-readable medium containing instructions for controlling a data processing system to perform a method, the data processing system containing a service on a device, a service registry and a proxy, the method performed by the proxy comprising the steps of: receiving a request from the service to register with the service registry; obtaining information that facilitates accessing the service; and storing the information into the service registry to register the service.
25. The computer-readable medium of claim 24, wherein the information is an object containing code for communicating with the service.
26. The computer-readable medium of claim 25, wherein the code comprises bytecodes suitable for running on a Java™ Virtual Machine.
27. The computer-readable medium of claim 24 wherein the information is a location identifier indicating a location of an object containing code for communicating with the service.
28. The computer-readable medium of claim 24, wherein the receiving step includes: receiving a location identifier indicating a location of an object containing code for communicating with the service, wherein the obtaining step includes: retrieving the object from the location, and wherein the storing step includes: storing the retrieved object into the service registry.
29. The computer-readable medium of claim 24, further including the steps of: receiving a request to access a resource from the service; and providing the service with access to the resource.
30. The computer-readable medium of claim 29, wherein the service registry contains an object with methods for accessing the resource and wherein the providing step includes the steps of: retrieving the object from the service registry; and invoking a method on the object to facilitate accessing the resource.
31. The computer-readable medium of claim 29 wherein the providing step includes the step of: leasing the resource.
32. The computer-readable medium of claim 31 , further including the steps of: accessing the resource on behalf of the service; determining when the lease is near expiration; and renewing the lease when it is determined that the lease is near expiration.
33. A computer-readable medium containing instructions for controlling a data processing system to perform a method for registering a service located on a device in a service registry, the method comprising the steps performed by the service of: sending a request for registration in the service registry to a proxy server, whereupon the proxy server registers the service in the service registry to enable a client program to access the service; and receiving a request from the client program for accessing the service.
34. The computer-readable medium of claim 33 wherein the receiving step includes the step of: receiving the request via the proxy server.
35. A computer-readable medium containing instructions for controlling a data processing system to perform a method, the data processing system containing a client program, a service registry containing a reference to a service on a device, and a proxy server, the method comprising the steps performed by the client program of: retrieving the reference from the service registry; and using the reference to send a request to access the service to the proxy server.
36. A data processing system containing an oφhan service on a device, a network proxy, a lookup service, and a client program, comprising: means for sending a request from the oφhan service to the network proxy for registration in the lookup service; means for receiving the request by the network proxy; means for registering the oφhan service in the lookup service by the network proxy; means for accessing the lookup service by the client program to obtain the registration of the oφhan service; and means for accessing the oφhan service by the client program using the registration.
PCT/US2000/016080 1999-06-14 2000-06-13 Network proxy for devices with limited resources WO2000077635A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP00941352A EP1194846A1 (en) 1999-06-14 2000-06-13 Network proxy for devices with limited resources
AU56066/00A AU5606600A (en) 1999-06-14 2000-06-13 Network proxy for devices with limited resources

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/332,031 1999-06-14
US09/332,031 US6708171B1 (en) 1996-04-23 1999-06-14 Network proxy

Publications (1)

Publication Number Publication Date
WO2000077635A1 true WO2000077635A1 (en) 2000-12-21

Family

ID=23296420

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/016080 WO2000077635A1 (en) 1999-06-14 2000-06-13 Network proxy for devices with limited resources

Country Status (4)

Country Link
US (1) US6708171B1 (en)
EP (1) EP1194846A1 (en)
AU (1) AU5606600A (en)
WO (1) WO2000077635A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1237083A2 (en) * 2001-02-28 2002-09-04 Sun Microsystems, Inc. System and method for accessing functionality of a backend system from an application server
US6757729B1 (en) * 1996-10-07 2004-06-29 International Business Machines Corporation Virtual environment manager for network computers

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6385661B1 (en) * 1998-10-19 2002-05-07 Recursion Software, Inc. System and method for dynamic generation of remote proxies
JP3833409B2 (en) * 1999-02-05 2006-10-11 株式会社日立製作所 Communication proxy device
US6947965B2 (en) * 1999-11-30 2005-09-20 Recursion Software, Inc. System and method for communications in a distributed computing environment
US6917976B1 (en) * 2000-05-09 2005-07-12 Sun Microsystems, Inc. Message-based leasing of resources in a distributed computing environment
US7401131B2 (en) 2000-05-22 2008-07-15 Verizon Business Global Llc Method and system for implementing improved containers in a global ecosystem of interrelated services
US6922685B2 (en) 2000-05-22 2005-07-26 Mci, Inc. Method and system for managing partitioned data resources
DE10028371B4 (en) * 2000-06-08 2013-01-17 Siemens Aktiengesellschaft Method and arrangement for the secure use of a service
US6754621B1 (en) * 2000-10-06 2004-06-22 Andrew Cunningham Asynchronous hypertext messaging system and method
JP2002124951A (en) * 2000-10-12 2002-04-26 Canon Inc Communication terminal device, service providing system, service utilization method and memory medium
JP2002132739A (en) * 2000-10-23 2002-05-10 Nec Corp Stab retrieval loading system and method, server device, client device and computer readable recording medium
US7434234B2 (en) * 2001-05-04 2008-10-07 Outlooksoft Corporation Method and system for facilitating communications in a network using on demand distribution
US20030140057A1 (en) * 2001-12-18 2003-07-24 Shawn Thomas Method and system for leased asset management
US6925466B2 (en) * 2002-03-22 2005-08-02 Sun Microsystems, Inc. Asynchronous protocol framework
US7962545B2 (en) * 2002-12-27 2011-06-14 Intel Corporation Dynamic service registry for virtual machines
US8151280B2 (en) * 2003-10-27 2012-04-03 Microsoft Corporation Simple and dynamic configuration of network devices
US7873730B2 (en) * 2003-11-10 2011-01-18 International Business Machines Corporation Method and system for collaborative computing environment access restriction and orphan data management
CN1761207A (en) 2004-10-11 2006-04-19 国际商业机器公司 Computer network system and a method for monitoring and controlling a network
US10140049B2 (en) 2012-02-24 2018-11-27 Missing Link Electronics, Inc. Partitioning systems operating in multiple domains
US10181122B2 (en) 2013-10-31 2019-01-15 Cellco Partnership Mobile authentication for web payments using single sign on credentials
US10135805B2 (en) 2013-10-31 2018-11-20 Cellco Partnership Connected authentication device using mobile single sign on credentials
US9628482B2 (en) * 2013-10-31 2017-04-18 Cellco Partnership Mobile based login via wireless credential transfer
KR20200130151A (en) * 2019-05-10 2020-11-18 현대자동차주식회사 Method and apparatus for identifying service entity in machine to machine system

Family Cites Families (148)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2476349A1 (en) 1980-02-15 1981-08-21 Philips Ind Commerciale DISTRIBUTED DATA PROCESSING SYSTEM
US4491946A (en) 1981-03-09 1985-01-01 Gould Inc. Multi-station token pass communication system
US4558413A (en) 1983-11-21 1985-12-10 Xerox Corporation Software version management system
JPH0640302B2 (en) 1984-01-30 1994-05-25 株式会社日立製作所 Schematic / source program automatic generation method
US4823122A (en) 1984-06-01 1989-04-18 Digital Equipment Corporation Local area network for digital data processing system
US4809160A (en) 1985-10-28 1989-02-28 Hewlett-Packard Company Privilege level checking instruction for implementing a secure hierarchical computer system
US4713806A (en) 1986-03-14 1987-12-15 American Telephone And Telegraph Company, At&T Bell Laboratories Communication system control arrangement
US4939638A (en) 1988-02-23 1990-07-03 Stellar Computer Inc. Time sliced vector processing
US5287511A (en) 1988-07-11 1994-02-15 Star Semiconductor Corporation Architectures and methods for dividing processing tasks into tasks for a programmable real time signal processor and tasks for a decision making microprocessor interfacing therewith
US5133075A (en) 1988-12-19 1992-07-21 Hewlett-Packard Company Method of monitoring changes in attribute values of object in an object-oriented database
US5109486A (en) 1989-01-06 1992-04-28 Motorola, Inc. Distributed computer system with network and resource status monitoring
US5088036A (en) 1989-01-17 1992-02-11 Digital Equipment Corporation Real time, concurrent garbage collection system and method
US5297283A (en) 1989-06-29 1994-03-22 Digital Equipment Corporation Object transferring system and method in an object based computer operating system
US5257369A (en) 1990-10-22 1993-10-26 Skeen Marion D Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5557798A (en) 1989-07-27 1996-09-17 Tibco, Inc. Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5187787B1 (en) 1989-07-27 1996-05-07 Teknekron Software Systems Inc Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes
US5218699A (en) 1989-08-24 1993-06-08 International Business Machines Corporation Remote procedure calls in heterogeneous systems
JPH04505977A (en) 1989-12-26 1992-10-15 富士通株式会社 Object-oriented distributed processing system
GB2242293A (en) 1990-01-05 1991-09-25 Apple Computer Apparatus and method for dynamic linking of computer software components
AU628753B2 (en) 1990-08-14 1992-09-17 Digital Equipment Corporation Method and apparatus for implementing server functions in a distributed heterogeneous environment
ATE154850T1 (en) 1990-09-17 1997-07-15 Cabletron Systems Inc NETWORK MANAGEMENT SYSTEM WITH MODEL-BASED INTELLIGENCE
JPH0799497B2 (en) 1990-12-14 1995-10-25 インターナショナル・ビジネス・マシーンズ・コーポレイション Device and method for controlling the use of software
IE910553A1 (en) 1991-02-19 1992-08-26 Tolsys Ltd Improvements in and relating to stable memory circuits
EP0501610B1 (en) 1991-02-25 1999-03-17 Hewlett-Packard Company Object oriented distributed computing system
EP0501613A3 (en) 1991-02-28 1993-09-01 Hewlett-Packard Company Heterogeneous software configuration management apparatus
US5293614A (en) 1991-04-08 1994-03-08 Texas Instruments Incorporated System and method for hard real-time garbage collection requiring a write barrier but no read barrier
US5481721A (en) 1991-07-17 1996-01-02 Next Computer, Inc. Method for providing automatic and dynamic translation of object oriented programming language-based message passing into operation system message passing using proxy objects
DE4131380A1 (en) 1991-09-20 1993-03-25 Siemens Ag METHOD FOR ADAPTING AN OBJECT-ORIENTED APPLICATION
US5319751A (en) 1991-12-27 1994-06-07 Intel Corporation Device driver configuration in a computer system
US5390328A (en) 1992-03-30 1995-02-14 International Business Machines Corporation Data processing system and method for providing notification in a central processor of state changes for shared data structure on external storage
US5412717A (en) 1992-05-15 1995-05-02 Fischer; Addison M. Computer system security method and apparatus having program authorization information data structures
KR100287045B1 (en) 1992-07-06 2001-04-16 존 비. 메이슨 Method and system for naming/binding object
US5307490A (en) 1992-08-28 1994-04-26 Tandem Computers, Inc. Method and system for implementing remote procedure calls in a distributed computer system
JP2524472B2 (en) 1992-09-21 1996-08-14 インターナショナル・ビジネス・マシーンズ・コーポレイション How to train a telephone line based speech recognition system
US5423042A (en) 1992-10-23 1995-06-06 International Business Machines Corporation Remote procedure execution
US5561785A (en) 1992-10-29 1996-10-01 International Business Machines Corporation System for allocating and returning storage and collecting garbage using subpool of available blocks
EP0669020B1 (en) 1992-11-13 1997-04-02 Microsoft Corporation Methods for marshalling interface pointers for remote procedure calls
US5515536A (en) 1992-11-13 1996-05-07 Microsoft Corporation Method and system for invoking methods of an object through a dispatching interface
US5386568A (en) 1992-12-01 1995-01-31 Yamaha Corporation Apparatus and method for linking software modules
EP0602263A1 (en) 1992-12-15 1994-06-22 International Business Machines Corporation User interface program generator
US5560003A (en) 1992-12-21 1996-09-24 Iowa State University Research Foundation, Inc. System and hardware module for incremental real time garbage collection and memory management
US5452459A (en) 1993-01-08 1995-09-19 Digital Equipment Corporation Method and apparatus for allocating server access in a distributed computing environment
DE69429686T2 (en) 1993-02-25 2003-04-30 Sun Microsystems Inc Transaction management in an object-oriented system
US5832593A (en) 1993-04-14 1998-11-10 Minnesota Mining And Manufacturing Company Splice head for insulated telecommunication wires
US5603031A (en) 1993-07-08 1997-02-11 General Magic, Inc. System and method for distributed computation based upon the movement, execution, and interaction of processes in a network
US5844553A (en) 1993-08-30 1998-12-01 Hewlett-Packard Company Mechanism to control and use window events among applications in concurrent computing
US5617537A (en) 1993-10-05 1997-04-01 Nippon Telegraph And Telephone Corporation Message passing system for distributed shared memory multiprocessor system and message passing method using the same
US5455952A (en) 1993-11-03 1995-10-03 Cardinal Vision, Inc. Method of computing based on networks of dependent objects
US5742848A (en) 1993-11-16 1998-04-21 Microsoft Corp. System for passing messages between source object and target object utilizing generic code in source object to invoke any member function of target object by executing the same instructions
US5581704A (en) 1993-12-06 1996-12-03 Panasonic Technologies, Inc. System for maintaining data coherency in cache memory by periodically broadcasting invalidation reports from server to client
AU6702594A (en) 1993-12-17 1995-07-03 Taligent, Inc. Object-oriented distributed communications directory service
US5548726A (en) 1993-12-17 1996-08-20 Taligeni, Inc. System for activating new service in client server network by reconfiguring the multilayer network protocol stack dynamically within the server node
US5594921A (en) 1993-12-17 1997-01-14 Object Technology Licensing Corp. Authentication of users with dynamically configurable protocol stack
AU1522095A (en) 1994-01-05 1995-08-01 Peter J. Covey Dynamic-state, multi-dimensional, multi-media database
US5832219A (en) 1994-02-08 1998-11-03 Object Technology Licensing Corp. Distributed object networking service
US5845090A (en) 1994-02-14 1998-12-01 Platinium Technology, Inc. System for software distribution in a digital computer network
US5392280A (en) 1994-04-07 1995-02-21 Mitsubishi Electric Research Laboratories, Inc. Data transmission system and scheduling protocol for connection-oriented packet or cell switching networks
US5675796A (en) 1994-04-08 1997-10-07 Microsoft Corporation Concurrency management component for use by a computer program during the transfer of a message
US5680617A (en) 1994-05-16 1997-10-21 Apple Computer, Inc. Computer-human interface which provides for user customization of object behavior
EP0684553B1 (en) 1994-05-26 2004-06-16 Sun Microsystems, Inc. Method and apparatus for generating and using short operation identifiers in object oriented systems
US5655148A (en) 1994-05-27 1997-08-05 Microsoft Corporation Method for automatically configuring devices including a network adapter without manual intervention and without prior configuration information
US5680573A (en) 1994-07-12 1997-10-21 Sybase, Inc. Method of buffering data objects in a database
US5778228A (en) 1994-08-16 1998-07-07 International Business Machines Corporation Method and system for transferring remote procedure calls and responses over a network
US5555367A (en) 1994-09-30 1996-09-10 General Electric Company Method and system for generating computer programs for queries formed by manipulating object-oriented diagrams
JP4058118B2 (en) 1994-11-15 2008-03-05 株式会社日立製作所 Program generation system and method
US5577231A (en) 1994-12-06 1996-11-19 International Business Machines Corporation Storage access authorization controls in a computer system using dynamic translation of large addresses
US5644768A (en) 1994-12-09 1997-07-01 Borland International, Inc. Systems and methods for sharing resources in a multi-user environment
US5553282A (en) 1994-12-09 1996-09-03 Taligent, Inc. Software project history database and method of operation
EP0717337B1 (en) 1994-12-13 2001-08-01 International Business Machines Corporation Method and system for the secured distribution of programs
US5677851A (en) 1994-12-15 1997-10-14 Novell, Inc. Method and apparatus to secure digital directory object changes
US5608903A (en) 1994-12-15 1997-03-04 Novell, Inc. Method and apparatus for moving subtrees in a distributed network directory
US5872928A (en) 1995-02-24 1999-02-16 Cabletron Systems, Inc. Method and apparatus for defining and enforcing policies for configuration management in communications networks
EP0735472A3 (en) 1995-03-31 2000-01-19 Sun Microsystems, Inc. Method and apparatus for conspiracy among objects
US5727203A (en) 1995-03-31 1998-03-10 Sun Microsystems, Inc. Methods and apparatus for managing a database in a distributed object operating environment using persistent and transient cache
US5812819A (en) 1995-06-05 1998-09-22 Shiva Corporation Remote access apparatus and method which allow dynamic internet protocol (IP) address management
US5628005A (en) 1995-06-07 1997-05-06 Microsoft Corporation System and method for providing opportunistic file access in a network environment
US5903731A (en) 1995-06-14 1999-05-11 Us West Technologies, Inc. System and associated method for re-engineering a telecommunications network support system with object-oriented translators
US5761656A (en) 1995-06-26 1998-06-02 Netdynamics, Inc. Interaction between databases and graphical user interfaces
US5802367A (en) 1995-07-07 1998-09-01 Microsoft Corporation Method and system for transparently executing code using a surrogate process
US5745703A (en) 1995-07-18 1998-04-28 Nec Research Institute, Inc. Transmission of higher-order objects across a network of heterogeneous machines
US5774551A (en) 1995-08-07 1998-06-30 Sun Microsystems, Inc. Pluggable account management interface with unified login and logout and multiple user authentication services
US5956509A (en) 1995-08-18 1999-09-21 Microsoft Corporation System and method for performing remote requests with an on-line service network
JPH0962526A (en) 1995-08-28 1997-03-07 Fujitsu Ltd Fault resistant rpc system and method therefor
JP2964926B2 (en) 1995-08-29 1999-10-18 富士ゼロックス株式会社 Database management apparatus and method
US5671225A (en) 1995-09-01 1997-09-23 Digital Equipment Corporation Distributed interactive multimedia service system
US5737607A (en) 1995-09-28 1998-04-07 Sun Microsystems, Inc. Method and apparatus for allowing generic stubs to marshal and unmarshal data in object reference specific data formats
US5864862A (en) 1996-09-30 1999-01-26 Telefonaktiebolaget Lm Ericsson (Publ) System and method for creating reusable components in an object-oriented programming environment
US5872973A (en) 1995-10-26 1999-02-16 Viewsoft, Inc. Method for managing dynamic relations between objects in dynamic object-oriented languages
US5860153A (en) 1995-11-22 1999-01-12 Sun Microsystems, Inc. Memory efficient directory coherency maintenance
US6067575A (en) 1995-12-08 2000-05-23 Sun Microsystems, Inc. System and method for generating trusted, architecture specific, compiled versions of architecture neutral programs
US6003763A (en) 1995-12-29 1999-12-21 Visa International Service Method and apparatus for recording magnetic information on traveler's checks
US5745695A (en) 1996-01-16 1998-04-28 Motorola Inc. Radio system with suspension of packet data service during non-data service connection
US5754849A (en) 1996-01-30 1998-05-19 Wayfarer Communications, Inc. Self-describing object providing dynamic manipulation of heterogeneous data values and semantic identity between memory and transmission representations
US5946485A (en) 1996-02-09 1999-08-31 Intervoice Limited Partnership Enhanced graphical development environment for controlling program flow
US5845129A (en) 1996-03-22 1998-12-01 Philips Electronics North America Corporation Protection domains in a single address space
US5706502A (en) 1996-03-25 1998-01-06 Sun Microsystems, Inc. Internet-enabled portfolio manager system and method
US5790548A (en) 1996-04-18 1998-08-04 Bell Atlantic Network Services, Inc. Universal access multimedia data network
US5815709A (en) 1996-04-23 1998-09-29 San Microsystems, Inc. System and method for generating identifiers for uniquely identifying object types for objects used in processing of object-oriented programs and the like
US6226746B1 (en) 1998-03-20 2001-05-01 Sun Microsystems, Inc. Stack-based system and method to combine security requirements of methods
US6185611B1 (en) 1998-03-20 2001-02-06 Sun Microsystem, Inc. Dynamic lookup service in a distributed system
US5978484A (en) 1996-04-25 1999-11-02 Microsoft Corporation System and method for safety distributing executable objects
US5778368A (en) 1996-05-03 1998-07-07 Telogy Networks, Inc. Real-time embedded software respository with attribute searching apparatus and method
US5778187A (en) 1996-05-09 1998-07-07 Netcast Communications Corp. Multicasting method and apparatus
US5835737A (en) 1996-05-10 1998-11-10 Apple Computer, Inc. Method and apparatus for arbitrating access to selected computer system devices
US5889951A (en) 1996-05-13 1999-03-30 Viewpoint Corporation Systems, methods, and computer program products for accessing, leasing, relocating, constructing and modifying internet sites within a multi-dimensional virtual reality environment
US5813013A (en) 1996-06-06 1998-09-22 Microsoft Corporation Representing recurring events
US5768532A (en) 1996-06-17 1998-06-16 International Business Machines Corporation Method and distributed database file system for implementing self-describing distributed file objects
JP3488019B2 (en) 1996-06-17 2004-01-19 株式会社山武 How to reuse parts of configuration tool for control design
US5727145A (en) 1996-06-26 1998-03-10 Sun Microsystems, Inc. Mechanism for locating objects in a secure fashion
SG67354A1 (en) 1996-06-27 1999-09-21 Inst Of Systems Science Nation Computationally efficient method for trusted and dynamic digital objects dissemination
US5809507A (en) 1996-07-01 1998-09-15 Sun Microsystems, Inc. Method and apparatus for storing persistent objects on a distributed object network using a marshaling framework
US5818448A (en) 1996-07-02 1998-10-06 Sun Microsystems, Inc. Apparatus and method for identifying server computer aggregation topologies
US5748897A (en) 1996-07-02 1998-05-05 Sun Microsystems, Inc. Apparatus and method for operating an aggregation of server computers using a dual-role proxy server computer
US5860004A (en) 1996-07-03 1999-01-12 Sun Microsystems, Inc. Code generator for applications in distributed object systems
US5757925A (en) 1996-07-23 1998-05-26 Faybishenko; Yaroslav Secure platform independent cross-platform remote execution computer system and method
US5875335A (en) 1996-09-30 1999-02-23 Apple Computer, Inc. Parameter marshaling techniques for dynamic object-oriented programming languages
US5787425A (en) 1996-10-01 1998-07-28 International Business Machines Corporation Object-oriented data mining framework mechanism
US5974201A (en) 1996-10-01 1999-10-26 Siemens Corporate Research, Inc. Smart image system
US5832529A (en) 1996-10-11 1998-11-03 Sun Microsystems, Inc. Methods, apparatus, and product for distributed garbage collection
US5944793A (en) 1996-11-21 1999-08-31 International Business Machines Corporation Computerized resource name resolution mechanism
US5987506A (en) 1996-11-22 1999-11-16 Mangosoft Corporation Remote access and geographically distributed computers in a globally addressable storage environment
US5892904A (en) 1996-12-06 1999-04-06 Microsoft Corporation Code certification for network transmission
US5884024A (en) 1996-12-09 1999-03-16 Sun Microsystems, Inc. Secure DHCP server
US5787431A (en) 1996-12-16 1998-07-28 Borland International, Inc. Database development system with methods for java-string reference lookups of column names
US5933647A (en) 1997-01-24 1999-08-03 Cognet Corporation System and method for software distribution and desktop management in a computer network environment
US6052761A (en) 1997-01-31 2000-04-18 Hewlett-Packard Company Increment update in an SCI based system
US5815149A (en) 1997-02-19 1998-09-29 Unisys Corp. Method for generating code for modifying existing event routines for controls on a form
US5935249A (en) 1997-02-26 1999-08-10 Sun Microsystems, Inc. Mechanism for embedding network based control systems in a local network interface device
US6061713A (en) 1997-03-12 2000-05-09 Fujitsu Limited Communications system for client-server data processing systems
US5864866A (en) 1997-03-26 1999-01-26 International Business Machines Corporation Apparatus and method for providing externalization in an object-oriented environment
US5890158A (en) 1997-03-31 1999-03-30 International Business Machines Corporation Method, apparatus, and program storage device for sharing objects with a network server and a database server using a common object model
US5999988A (en) 1997-03-31 1999-12-07 Sun Microsystems, Inc. Method and apparatus for generating and employing a run-time generated stub to reference an object in object oriented systems
US6247091B1 (en) 1997-04-28 2001-06-12 International Business Machines Corporation Method and system for communicating interrupts between nodes of a multinode computer system
US6282295B1 (en) 1997-10-28 2001-08-28 Adam Lucas Young Auto-recoverable and auto-certifiable cryptostem using zero-knowledge proofs for key escrow in general exponential ciphers
US5808911A (en) 1997-06-19 1998-09-15 Sun Microsystems, Inc. System and method for remote object resource management
US5878411A (en) 1997-06-27 1999-03-02 International Business Machines Corporation Dependent object class and subclass mapping to relational data store
US5887134A (en) 1997-06-30 1999-03-23 Sun Microsystems System and method for preserving message order while employing both programmed I/O and DMA operations
US5946694A (en) 1997-09-29 1999-08-31 International Business Machines Corporation Apparatus and method for transparent application of service to business objects
US5951652A (en) 1997-10-06 1999-09-14 Ncr Corporation Dependable data element synchronization mechanism
US6061699A (en) 1997-11-03 2000-05-09 International Business Machines Corporation Method and computer program product for extracting translatable material from browser program function codes using variables for displaying MRI
US5999179A (en) 1997-11-17 1999-12-07 Fujitsu Limited Platform independent computer network management client
US6016496A (en) 1997-11-20 2000-01-18 International Business Machines Corporation Method and apparatus for an object-oriented object for retrieving information from local and remote databases
US6009103A (en) 1997-12-23 1999-12-28 Mediaone Group, Inc. Method and system for automatic allocation of resources in a network
US6023586A (en) 1998-02-10 2000-02-08 Novell, Inc. Integrity verifying and correcting software
US6026414A (en) 1998-03-05 2000-02-15 International Business Machines Corporation System including a proxy client to backup files in a distributed computing environment
US6185602B1 (en) 1998-06-29 2001-02-06 Sony Corporation Multi-user interaction of multimedia communication
US6108346A (en) 1998-08-27 2000-08-22 Xiox Corporation Combined synchronous and asynchronous message transmission
US6282568B1 (en) 1998-12-04 2001-08-28 Sun Microsystems, Inc. Platform independent distributed management system for manipulating managed objects in a network

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JASON KRAUSE: "What the Hell is....Jini?", THE INDUSTRY STANDARD, 27 July 1998 (1998-07-27), XP002125806 *
SUN MICROSYSTEMS: "Jini (TM) Architectural Overview", TECHNICAL WHITE PAPER, January 1999 (1999-01-01), XP002152110 *
SUN MICROSYSTEMS: "Jini (TM) Device Architecture Specification", JINI SPECIFICATIONS 1.0, 25 January 1999 (1999-01-25), XP002153332, Retrieved from the Internet <URL:http://www-rohan.sdsu.edu/doc/jini/doc/specs/device-arch/deviceArch.pdf> [retrieved on 20001120] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6757729B1 (en) * 1996-10-07 2004-06-29 International Business Machines Corporation Virtual environment manager for network computers
EP1237083A2 (en) * 2001-02-28 2002-09-04 Sun Microsystems, Inc. System and method for accessing functionality of a backend system from an application server
EP1237083A3 (en) * 2001-02-28 2007-10-17 Sun Microsystems, Inc. System and method for accessing functionality of a backend system from an application server

Also Published As

Publication number Publication date
AU5606600A (en) 2001-01-02
US6708171B1 (en) 2004-03-16
EP1194846A1 (en) 2002-04-10

Similar Documents

Publication Publication Date Title
US6708171B1 (en) Network proxy
US6654793B1 (en) System and method for facilitating dynamic loading of stub information to enable a program operating in one address space to invoke processing of a remote method or procedure in another address space
US6832223B1 (en) Method and system for facilitating access to a lookup service
US6983285B2 (en) Apparatus and method for dynamically verifying information in a distributed system
US9183066B2 (en) Downloadable smart proxies for performing processing associated with a remote procedure call in a distributed system
US6134603A (en) Method and system for deterministic hashes to identify remote methods
US8103760B2 (en) Dynamic provisioning of service components in a distributed system
US8713089B2 (en) Dynamic lookup service in a distributed system
JP4729172B2 (en) Method and apparatus for performing transactions in a stateless web environment that supports a declarative paradigm
JP3853592B2 (en) Distributed web application server
US6604127B2 (en) Dynamic lookup service in distributed system
US9389927B2 (en) Method and apparatus for composite user interface generation
US6560656B1 (en) Apparatus and method for providing downloadable code for use in communicating with a device in a distributed system
US20020046228A1 (en) Method and system for facilitating access to a lookup service
US6629154B1 (en) Method and system for deterministic hashes to identify remote methods
JP2002505466A (en) Remote method invocation method and apparatus
US7089263B2 (en) Apparatus and method for dynamically verifying information in a distributed system
EP1058884A1 (en) Method and system for facilitating access to a lookup service
WO1999044123A1 (en) Downloadable smart proxies for performing processing associated with a remote procedure call in a distributed system
JP2002505478A (en) Deferred Restoration and Remote Loading of Objects for Event Notification in Distributed Systems
KR20010034515A (en) Method and system for facilitating access to a lookup service
WO2000077619A2 (en) Dynamic lookup service in a distributed system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2000941352

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2000941352

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: 2000941352

Country of ref document: EP