Abstract:
Use of a smart proxy as a wrapper around a stub in a distributed system. Instead of receiving a stub as a result of a remote procedure call, a caller receives a smart proxy including the stub as an embedded object. The smart proxy performs predefined processing associated with a remote procedure call, the processing possibly occurring before, during, or after a response to the call.

Description:
REFERENCE TO RELATED APPLICATIONS  
         [0001]    The following identified U.S. patent applications are relied upon and are incorporated by reference in this application as if fully set forth.  
           [0002]    Provisional U.S. Patent Application No. ______, entitled “Distributed Computing System,” filed on Feb. 26, 1998.  
           [0003]    U.S. patent application Ser. No. ______, entitled “Method and System for Leasing Storage,” bearing attorney docket no. 06502.0011-01000, and filed on the same date herewith.  
           [0004]    U.S. patent application Ser. No. _______, entitled “Method, Apparatus, and Product for Leasing of Delegation Certificates in a Distributed System,” bearing attorney docket no. 06502.0011-02000, and filed on the same date herewith.  
           [0005]    U.S. patent application Ser. No. ______, entitled “Method, Apparatus and Product for Leasing of Group Membership in a Distributed System,” bearing attorney docket no. 06502.0011-03000, and filed on the same date herewith.  
           [0006]    U.S. patent application Ser. No. ______, entitled “Leasing for Failure Detection,” bearing attorney docket no. 06502.0011-04000, and filed on the same date herewith.  
           [0007]    U.S. patent application Ser. No. ______, entitled “Method for Transporting Behavior in Event Based System,” bearing attorney docket no. 06502.0054-00000, and filed on the same date herewith.  
           [0008]    U.S. patent application Ser. No. ______, entitled “Deferred Reconstruction of Objects and Remote Loading for Event Notification in a Distributed System,” bearing attorney docket no. 06502.0062-01000, and filed on the same date herewith.  
           [0009]    U.S. patent application Ser. No. ______, entitled “Methods and Apparatus for Remote Method Invocation,” bearing attorney docket no. 06502.0102-00000, and filed on the same date herewith.  
           [0010]    U.S. patent application Ser. No. ______, entitled “Method and System for Deterministic Hashes to Identify Remote Methods,” bearing attorney docket no. 06502.0103-00000, and filed on the same date herewith.  
           [0011]    U.S. patent application Ser. No. ______, entitled “Method and Apparatus for Determining Status of Remote Objects in a Distributed System,” bearing attorney docket no. 06502.0104-00000, and filed on the same date herewith.  
           [0012]    U.S. patent application Ser. No. ______, entitled “Suspension and Continuation of Remote Methods,” bearing attorney docket no. 06502.010-00000, and filed on the same date herewith.  
           [0013]    U.S. patent application Ser. No. ______, entitled “Method and System for Multi-Entry and Multi-Template Matching in a Database,” bearing attorney docket no. 06502.0107-00000, and filed on the same date herewith.  
           [0014]    U.S. patent application Ser. No. ______, entitled “Method and System for In-Place Modifications in a Database,” bearing attorney docket no. 06502.0108, and filed on the same date herewith.  
           [0015]    U.S. patent application Ser. No. ______, entitled “Method and System for Typesafe Attribute Matching in a Database,” bearing attorney docket no. 06502.0109-00000, and filed on the same date herewith.  
           [0016]    U.S. patent application Ser. No. ______, entitled “Dynamic Lookup Service in a Distributed System,” bearing attorney docket no. 06502.0110-00000 and filed on the same date herewith.  
           [0017]    U.S. patent application Ser. No. ______, entitled “Apparatus and Method for Providing Downloadable Code for Use in Communicating with a Device in a Distributed System,” bearing attorney docket no. 06502.0112-00000, and filed on the same date herewith.  
           [0018]    U.S. patent application Ser. No. ______, entitled “Method and System for Facilitating Access to a Lookup Service,” bearing attorney docket no. 06502.0113-00000, and filed on the same date herewith.  
           [0019]    U.S. patent application Ser. No. ______, entitled “Apparatus and Method for Dynamically Verifying Information in a Distributed System,” bearing attorney docket no. 06502.0114-00000, and filed on the same date herewith.  
           [0020]    U.S. patent application Ser. No. 09/030,840, entitled “Method and Apparatus for Dynamic Distributed Computing Over a Network,” and filed on Feb. 26, 1998.  
           [0021]    U.S. patent application Ser. No. ______, entitled “An Interactive Design Tool for Persistent Shared Memory Spaces,” bearing attorney docket no. 06502.0116-00000, and filed on the same date herewith.  
           [0022]    U.S. patent application Ser. No. ______, entitled “Polymorphic Token-Based Control,” bearing attorney docket no. 06502.0117-00000, and filed on the same date herewith.  
           [0023]    U.S. patent application Ser. No. ______, entitled “Stack-Based Access Control,” bearing attorney docket no. 06502.0118-00000, and filed on the same date herewith.  
           [0024]    U.S. patent application Ser. No. ______, entitled “Stack-Based Security Requirements,” bearing attorney docket no. 06502.0119-00000, and filed on the same date herewith.  
           [0025]    U.S. patent application Ser. No. ______, entitled “Per-Method Designation of Security Requirements,” bearing attorney docket no. 06502.0120-00000, and filed on the same date herewith.  
         FIELD OF THE INVENTION  
         [0026]    The present invention relates to a system and method for transmitting objects between machines in a distributed system and more particularly relates to transmission of a representation of a remote object including code for local processing.  
         BACKGROUND OF THE INVENTION  
         [0027]    Distributed programs which concentrate on point-to-point data transmission can often be adequately and efficiently handled using special-purpose protocols for remote terminal access and file transfer. Such protocols are tailored specifically to the one program and do not provide a foundation on which to build a variety of distributed programs (e.g., distributed operating systems, electronic mail systems, computer conferencing systems, etc.).  
           [0028]    While conventional transport services can be used as the basis for building distributed programs, these services exhibit many organizational problems, such as the use of different data types in different machines, lack of facilities for synchronization, and no provision for a simple programming paradigm.  
           [0029]    Distributed systems usually contain a number of different types of machines interconnected by communications networks. Each machine has its own internal data types, its own address alignment rules, and its own operating system. This heterogeneity causes problems when building distributed systems. As a result, program developers must include in programs developed for such heterogeneous distributed systems the capability of dealing with ensuring that information is handled and interpreted consistently in different machines.  
           [0030]    However, one simplification is afforded by noting that a large proportion of programs use a request and response interaction between processes where the initiator (i.e. program initiating a communication) is blocked out until the response is returned and is thus idle during this time. This can be modeled by a procedure call mechanism between processes. One such mechanism is referred to as the remote procedure call (RPC).  
           [0031]    RPC is a mechanism for providing synchronized communication between two processes (e.g., program, applet, etc.) running on the same machine or different machines. In a simple case, one process, e.g., a client program, sends a message to another process, e.g., a server program. In this case, it is not necessary for the processes to be synchronized either when the message is sent or received. It is possible for the client program to transmit the message and then begin a new activity, or for the server program&#39;s environment to buffer the incoming message until the server program is ready to process a new message.  
           [0032]    RPC, however, imposes constraints on synchronism because it closely models the local procedure call, which requires passing parameters in one direction, blocking the calling process (i.e., the client program) until the called procedure of the server program is complete, and then returning a response. RPC thus involves two message transfers, and the synchronization of the two processes for the duration of the call.  
           [0033]    The RPC mechanism is usually implemented in two processing parts using the local procedure call paradigm, one part being on the client side and the other part being on the server side. Both of these parts will be described below with reference to FIG. 1.  
           [0034]    [0034]FIG. 1 is a diagram illustrating the flow of call information using an RPC mechanism. As shown in FIG. 1, a client program  100  issues a call (step  102 ). The RPC mechanism  101  then packs the call as arguments of a call packet (step  103 ), which the RPC mechanism  101  then transmits to a server program  109  (step  104 ). The call packet also contains information to identify the client program  100  that first sent the call. After the call packet is transmitted (step  104 ), the RPC mechanism  101  enters a wait state during which it waits for a response from the server program  109 .  
           [0035]    The RPC mechanism  108  for the server program  109  (which may be the same RPC mechanism as the RPC mechanism  101  when the server program  109  is on the same platform as the client program  100 ) receives the call packet (step  110 ), unpacks the arguments of the call from the call packet (step  111 ), identifies, using the call information, the server program  109  to which the call was addressed, and provides the call arguments to the server program  109 .  
           [0036]    The server program receives the call (step  112 ), processes the call by invoking the appropriate procedure (step  115 ), and returns a response to the RPC mechanism  108  (step  116 ). The RPC mechanism  108  then packs the response in a response packet (step  114 ) and transmits it to the client program  100  (step  113 ).  
           [0037]    Receiving the response packet (step  107 ) triggers the RPC mechanism  101  to exit the wait state and unpack the response from the response packet (step  106 ). RPC  101  then provides the response to the client program  100  in response to the call (step l 05 ). This is the process flow of the typical RPC mechanism modeled after the local procedure call paradigm. Since the RPC mechanism uses the local procedure call paradigm, the client program  100  is blocked at the call until a response is received. Thus, the client program  100  does not continue with its own processing after sending the call; rather, it waits for a response from the server program  109 .  
           [0038]    The Java™ programming language is an object-oriented programming language that is typically compiled into a platform-independent format, using a bytecode instruction set, which can be executed on any platform supporting the Java virtual machine (JVM). This language is described, for example, in a text entitled “The Java Language Specification” by James Gosling, Bill Joy, and Guy Steele, Addison-Wesley, 1996, which is incorporated herein by reference. The JVM is described, for example, in a text entitled “The Java Virtual Machine Specification,” by Tim Lindholm and Frank Yellin, Addison Wesley, 1996, which is incorporated herein by reference. Java and Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.  
           [0039]    Because the JVM may be implemented on, any type of platform, implementing distributed programs using the JVM significantly reduces the difficulties associated with developing programs for heterogenous distributed systems. Moreover, the JVM uses a Java remote method invocation system (RMI) that enables communication among programs of the system. RMI is explained in, for example, the following document, which is incorporated herein by reference: Remote Method Invocation Specification, Sun Microsystems, Inc. (1997), which is available via universal resource locator (URL) http://wwwjavasoft.com/products/jdk/1.1/docs/guide/rmi/spec/rmiTOC.doc.html.  
           [0040]    [0040]FIG. 2 is a diagram illustrating the flow of objects in an object-oriented distributed system  200  including machines  201  and  202  for transmitting and receiving method invocations using the JVM. In system  200 , machine  201  uses RMI  205  for responding to a call for object  203  by converting the object into a byte stream  207  including an identification of the type of object transmitted and data constituting the object. While machine  201  is responding, to the call for object  203 , a process running on the same or another machine in system  200  may continue operation without waiting for a response to its request.  
           [0041]    Machine  202  receives the byte stream  207 . Using RMI  206 , machine  202  automatically converts it into the corresponding object  204 , which is a copy of object  203  and which makes the object available for use by a program executing on machine  202 . Machine  202  may also transmit the object to another machine by first converting the object into a byte stream and then sending it to the third machine, which also automatically converts the byte stream into the corresponding object.  
           [0042]    The communication between these machines sometimes involves, for example, repeated calls for the same information. These calls are made to a local proxy, which acts as a surrogate for the remote object in the address space of the client. Such a proxy will service the call by making a network request to the server object. Repeated calls to the same server object through a proxy can generate considerable network traffic, increasing the time and expense of obtaining the information. Accordingly, a need exists for a technique that reduces the amount of network communication in, for example, such a case.  
         SUMMARY OF THE INVENTION  
         [0043]    A method consistent with the present invention transmits a request for a particular object A response to the request is received, the response including code used to construct a representation of the requested object, the construction creating an object for processing calls to the object, local to the requesting object, using the representation.  
           [0044]    Another method consistent with the present invention receives at a machine a request for a particular object. A response to the request is transmitted, the response including first code for constructing a representation of the object and including an indication of second code for processing, such that the construction creates an object for processing calls to the object, local to the requesting object, using the representation.  
           [0045]    An apparatus consistent with the present invention transmits a request for a particular object. The apparatus receives a response to the request, the response including code used to construct a representation of the requested object, the construction creating an object for processing calls to the object, local to the requesting object, using the representation.  
           [0046]    Another apparatus consistent with the present invention receives at a machine a request for a particular object. The apparatus transmits a response to the request, the response including first code for constructing a representation of the object and including an indication of second code for processing, such that the construction creates an object for processing calls to the object, local to the requesting object, using the representation.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0047]    The accompanying drawings are incorporated in and constitute a part of this specification and, together with the description, explain the advantages and principles of the invention. In the drawings,  
         [0048]    [0048]FIG. 1 is a diagram illustrating the flow of call information using an RPC mechanism;  
         [0049]    [0049]FIG. 2 is a diagram illustrating the transmission of objects in an object-oriented distributed system;  
         [0050]    [0050]FIG. 3 is a diagram of an exemplary distributed processing system that can be used in an implementation consistent with the present invention;  
         [0051]    [0051]FIG. 4 is a diagram of an exemplary distributed system infrastructure;  
         [0052]    [0052]FIG. 5 is a diagram of a computer in a distributed system infrastructure shown in FIG. 4;  
         [0053]    [0053]FIG. 6 is a block diagram of a distributed network for use in downloading smart proxies;  
         [0054]    [0054]FIG. 7 is a flow chart of a process for downloading smart proxies within, for example, the distributed network shown in FIG. 6; and  
         [0055]    [0055]FIG. 8 is a flow chart of a process for changing the processing performed by a smart proxy. 
     
    
     DETAILED DESCRIPTION  
     Overview  
       [0056]    Instead of receiving a proxy that only makes network requests to the object for which it is a surrogate, a machine in a distributed system receives a smart proxy. Such a proxy can respond to calls on the object for which it is a surrogate without making any network calls to increase program efficiency, or perform processing before making a network call or after the completion of the network call to increase program functionality. The term proxy generally refers to code or other mechanism used to act as a surrogate for a remote object in the address space of a machine,  
         [0057]    Systems transferring stubs and associated smart proxies may use a variant of an RPC or RMI, passing arguments and return values from one process to another process each of which may be on different machines. The term “machine” is used in this context to refer to a physical machine or a virtual machine. Multiple virtual machines may exist on the same physical machine. Examples of RPC systems include distributed computed environment (DCE) RPC and Microsoft distributed common object model (DCOM) RPC. A memory stores the stub and associated smart proxy, and this memory may include secondary sources such as a disk or receiving objects from the Internet.  
       Distributed Processing System  
       [0058]    [0058]FIG. 3 illustrates an exemplary distributed processing system  300  which can be used in an implementation consistent with the present invention. In FIG. 3, distributed processing system  300  contains three independent and heterogeneous platforms  301 ,  302 , and  303  connected in a network configuration represented by network cloud  319 . The composition and protocol of the network configuration represented by cloud  319  is not important as long as it allows for communication of the information between platforms  301 ,  302  and  303 . In addition, the use of just three platforms is merely for illustration and does not limit an implementation consistent with the present invention to the use of a particular number of platforms. Further, the specific network architecture is not crucial to embodiments consistent with this invention. For example, another network architecture that could be used in an implementation consistent with this invention would employ one platform as a network controller to which all the other platforms would be connected.  
         [0059]    In the implementation of distributed processing system  300 , platforms  301 ,  302  and  303  each include a processor  316 ,  317 , and  318  respectively, and a memory,  304 ,  305 , and  306 , respectively. Included within each memory  304 ,  305 , and  306 , are applications  307 ,  308 , and  309 , respectively, operating systems  310 ,  311 , and  312 , respectively, and RMI components  313 ,  314 , and  315 , respectively.  
         [0060]    Applications  307 ,  308 , and  309  can be applications or programs that are either previously written and modified to work with, or that are specially written to take advantage of, the services offered by an implementation consistent with the present invention. Applications  307 ,  308 , and  309  invoke operations to be performed in accordance with an implementation consistent with this invention.  
         [0061]    Operating systems  310 ,  311 , and  312  are typically standard operating systems tied to the corresponding processors  316 ,  317 , and  318 , respectively. The platforms  301 ,  302 , and  303  can be heterogenous. For example, platform  301  has an UltraSparc® microprocessor manufactured by Sun Microsystems, Inc. as processor  316  and uses a Solaris® operating system  310 . Platform  302  has a MIPS microprocessor manufactured by Silicon Graphics Corp. as processor  317  and uses a Unix operating system  311 . Finally, platform  303  has a Pentium microprocessor manufactured by Intel Corp. as processor  318  and uses a Microsoft Windows 95 operating system  312 . An implementation consistent with the present invention is not so limited and could accommodate homogenous platforms as well.  
         [0062]    Sun, Sun Microsystems, Solaris, Java, and the Sun Logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. UltraSparc and all other SPARC trademarks are used under license and are trademarks of SPARC International Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.  
         [0063]    Memories  304 ,  305 , and  306  serve several functions, such as general storage for the associated platform. Another function is to store applications  307 ,  308 , and  309 , RMI components  313 ,  314 , and  315 , and operating systems  310 ,  311 , and  312  during execution by the respective processor  316 ,  317 , and  318 . In addition, portions of memories  304 ,  305 , and  306  may constitute shared memory available to all of the platforms  301 ,  302 , and  303  in network  319 . Note that RMI components  313 ,  314 , and  315  operate in conjunction with a JVM, which is not shown for the purpose of simplifying the figure.  
       Distributed System Infrastructure  
       [0064]    Systems and methods consistent with the present invention may also operate within a particular distributed system  400 , which will be described with reference to FIGS. 4 and 5. This distributed system  400  is comprised of various components, including hardware and software, to (1) allow users of the system to share services and resources over a network of many devices; (2) provide programmers with tools and programming patterns that allow development of robust, secured distributed systems; and (3) simplify the task of administering the distributed system. To accomplish these goals, distributed system  400  utilizes the Java programming environment to allow both code and data to be moved from device to device in a seamless manner. Accordingly, distributed system  400  is layered on top of the Java programming environment and exploits the characteristics of this environment, including the security offered by it and the strong typing provided by it.  
         [0065]    In distributed system  400  of FIGS. 4 and 5, different computers and devices are federated into what appears to the user to be a single system. By appearing as a single system, distributed system  400  provides the simplicity of access and the power of sharing that can be provided by a single system without giving up the flexibility and personalized response of a personal computer or workstation. Distributed system  400  may contain thousands of devices operated by users who are geographically disperse, but who agree on basic notions of trust, administration, and policy.  
         [0066]    Within an exemplary distributed system are various logical groupings of services provided by one or more devices, and each such logical grouping is known as a Djinn. A “service” refers to a resource, data, or functionality that can be accessed by a user, program, device, or another service and that can be computational, storage related, communication related, or related to providing access to another user. Examples of services provided as part of a Djinn include devices, such as printers, displays, and disks; software, such as programs or utilities; information, such as databases and files; and users of the system.  
         [0067]    Both users and devices may join a Djinn. When joining a Djinn, the user or device adds zero or more services to the Djinn and may access, subject to security constraints, any one of the services it contains. Thus, devices and users federate into a Djinn to share access to its services. The services of the Djinn appear programmatically as objects of the Java programming environment, which may include other objects, software components written in different programming languages, or hardware devices. A service has an interface defining the operations that can be requested of that service, and the type of the service determines the interfaces that make up that service.  
         [0068]    Distributed system  400  is comprised of computer  402 , a computer  404 , and a device  406  interconnected by a network  408 . Device  406  may be any of a number of devices, such as a printer, fax machine, storage device, computer, or other devices. Network  408  may be a local area network, wide area network, or the Internet. Although only two computers and one device are depicted as comprising distributed system  400 , one skilled in the art will appreciate that distributed system  400  may include additional computers or devices.  
         [0069]    [0069]FIG. 5 depicts computer  402  in greater detail to show a number of the software components of distributed system  400 . One skilled in the art will appreciate that computer  404  or device  406  may be similarly configured. Computer  402  includes a memory  502 , a secondary storage device  504 , a central processing unit (CPU)  506 , an input device  508 , and a video display  510 . Memory  502  includes a lookup service  512 , a discovery server  514 , and a Java runtime system  516 . The Java runtime system  516  includes the Java RMI system  518  and a JVM  520 . Secondary storage device  504  includes a Java space  522 .  
         [0070]    As mentioned above, distributed system  400  is based on the Java programming environment and thus makes use of the Java runtime system  516 . The Java runtime system  516  includes the Java API libraries, allowing programs running on top of the Java runtime system to access, in a platform-independent manner, various system functions, including windowing capabilities and networking capabilities of the host operating system. Since the Java API libraries provides a single common API across all operating systems to which the Java runtime system is ported, the programs running on top of a Java runtime system run in a platform-independant manner, regardless of the operating system or hardware configuration of the host platform. The Java runtime system  516  is provided as part of the Java software development kit available from Sun Microsystems, Inc. of Mountain View, Calif.  
         [0071]    JVM  520  also facilitates platform independence. JVM  520  acts like an abstract computing machine, receiving instructions from programs in the form of bytecodes and interpreting these bytecodes by dynamically converting them into a form for execution such as object code, and executing them. RMI  518  facilitates remote method invocation by allowing objects executing on one computer or device to invoke methods of an object on another computer or device. Both RMI and the JVM are also provided as part of the Java software development kit.  
         [0072]    Lookup service  512  defines the services that are available for a particular Djinn. That is, there may be more than one Djinn and, consequently, more than one lookup service within distributed system  400 . Lookup service  512  contains one object for each service within the Djinn, and each object contains various methods that facilitate access to the corresponding service. Lookup service  512  is described in U.S. patent application entitled “Method and System for Facilitating Access to a Lookup Service,” which was previously incorporated herein by reference.  
         [0073]    Discovery server  514  detects when a new device is added to distributed system  400 , during a process known as boot and join (or discovery), and when such a new device is detected, the discovery server passes a reference to lookup service  512  to the new device so that the new device may register its services with the lookup service and become a member of the Djinn. After registration, the new device becomes a member of the Djinn, and as a result, it may access all the services contained in lookup service  512 . The process of boot and join is described in U.S. patent application entitled “Apparatus and Method for providing Downloadable Code for Use in Communicating with a Device in a Distributed System,” which was previously incorporated herein by reference.  
         [0074]    A Java space  522  is an object repository used by programs within distributed system  400  to store objects. Programs use a Java space  522  to store objects persistently as well as to make them accessible to other devices within distributed system  400 . Java spaces are described in U.S. patent application Ser. No. 08/971,529, entitled “Database System Employing Polymorphic Entry and Entry Matching,” assigned to a common assignee, and filed on Nov. 17, 1997, which is incorporated herein by reference. One skilled in the art will appreciate that an exemplary distributed system  400  may contain many lookup services, discovery servers, and Java spaces.  
       Data Flow in a Distributed Processing System  
       [0075]    [0075]FIG. 6 is a block diagram of an object-oriented distributed network  600  connecting machines  601  and  606 , such as computers or virtual machines executing on one or more computers, or the machines described with reference to FIGS. 3, 4, and  5 . Network  600  transmits proxies, some of which may be smart proxies. A smart proxy includes code for performing processing associated with a call. For example, a smart proxy may perform a caching operation for read-only data for later reference. When a call is made for that data, the smart proxy may obtain it locally and provide it to a user without making another call for the data, which may occur transparent to the user. An example of such read-only data is a particular installation time. The first time a call is made for the installation time, for example, a smart proxy locally caches that value, and when a subsequent call is made for the installation time, the smart proxy locally retrieves the value.  
         [0076]    Another example of smart proxy processing involves use of a serialized object for transmitting data to a data bank storing information. In this example, a call is made to a smart proxy, which receives an object, serializes the object on the client machine into an array of bytes, and transmits the array of bytes to a server. The server only stores the serialized object, avoiding the requirement to download code, and it provides a key for the object to the client machine. When the client machine wants to retrieve the data, the smart proxy transmits the key to the server, receives in response the serialized object, reconstructs the object, and provides it the user.  
         [0077]    Other examples of uses of smart proxies include processing for debugging, call logging, and monitoring system performance. Another example involves the use of a smart proxy for local data verification, as explained in U.S. patent application filed on even data herewith, assigned to a common assignee, and entitled “Apparatus and Method for Dynamically Verifying Information in a Distributed System,” which is incorporated herein by reference. Many other uses for smart proxies are possible for performing processing associated with a call.  
         [0078]    Network  600  includes a client machine  601  containing RMI  602  and associated code  603 . A server machine  606  includes RMI  607  and remote object  608 . In operation, RMI  602  transmits a call or request  609  to RMI  607 , requesting a particular stub object. RMI  607  returns a response  610  including requested stub  605  embedded within a smart proxy  604 . The response may be transmitted as a stream. Streams used in the Java programming language, including input and output streams, are known in the art and an explanation, which is incorporated herein by reference, appears in, for example, a text entitled “The Java Tutorial: Object-Oriented Programming for the Internet,” pp. 325-53, by Mary Campione and Kathy Walrath, Addison-Wesley, 1996.  
         [0079]    The response may include information so that client machine  601  can reconstruct the stub object in smart proxy  604 . When a set of object types is limited and is the same on machines  601  and  606 , a receiving machine typically requires the object&#39;s state and a description of its type because the object&#39;s code is already present on all network machines. Alternatively, machine  606  uses RMI  607  to provide more flexibility, allowing code to be moved when necessary along with information or the object&#39;s state and type. Additionally, a transmitting machine may include in the object an identification of the type of object transmitted, the data constituting the state of the object, and a network-accessible location in the form of a URL for code that is associated with the object. URLs are known in the art and an explanation, which is incorporated herein by reference, appears in, for example, a text entitled “The Java Tutorial: Object-Oriented Programming for the Internet,” pp. 494-507, by Mary Campione and Kathy Walrath, Addison-Wesley, 1996.  
         [0080]    When client machine  601  receives response  610 , it identifies the type of transmitted object. Machine  601  contains its own RMI  602  and code  603  for processing of objects, and it may create stub object  605  using the object type, the state information, and code for the object. If code for the object is not resident or available on machine  601  and the stub object does not contain the code, RMI  602  may use a URL from the object to locate the code and transfer a copy of the code to client machine  601 . Because the code is bytecodes and is therefore portable, client machine  601  can load the code into RMI  602  to reconstruct the object. Thus, client machine  601  can reconstruct an object of the appropriate type even if that kind of object has not been present on the machine before.  
         [0081]    When creating stub object  605 , RMI  602  does not necessarily know that the stub is itself a smart proxy  604 . Smart proxy  604  may perform processing at client machine  601  before or after response  610  and may supply all processing without resorting to call  609  to the object for which the proxy acts. Therefore, smart proxy  604  may perform all processing locally when client machine  601  makes a call or request  611  to invoke a method on smart proxy  604 . These proxies are downloadable by the same methods as disclosed in U.S. patent application Ser. No. 08/950,756, filed on Oct. 15, 1997, and entitled “Deferred Reconstruction of Objects and Remote Loading in a Distributed System,” which is incorporated herein by reference.  
       Transmission of Smart Proxies  
       [0082]    [0082]FIG. 7 is a flow chart of a process  700  for downloading and using smart proxies within, for example, the distributed network shown in FIG. 6. A client machine transmits a call or request for a particular object (step  701 ), and a server machine receives the call (step  702 ). In response, the server machine returns a smart proxy with an embedded stub (step  703 ), and the proxy acts as a representation of the requested object. After receiving the smart proxy, the client machine invokes a method on it (step  704 ). According to the code within the smart proxy, the client machine containing the smart proxy determines if preprocessing is required (step  705 ). If so, the processing is performed locally by the client machine using the smart proxy (step  706 ).  
         [0083]    The client machine then determines if the method called on the smart proxy may be serviced locally (step  707 ). If so, the client machine performs the local processing for the call (step  711 ). If not, the client machine calls the remote object (step  708 ). The remote processing is performed (step  709 ), and the result of the remote processing is returned to the client machine (step  710 ).  
         [0084]    The client machine determines, according to code in the smart proxy, if post-processing as a result of the call is required (step  712 ). If so, it locally performs the post-processing using code in the smart proxy (step  713 ). The smart proxy then returns the method call result (step  714 ) in response to the call on the smart proxy in step  704 .  
         [0085]    [0085]FIG. 8 is a flow chart of a process  800  for changing the processing performed by a smart proxy. When processing is invoked (step  801 ), a client machine determines if updated processing is required (step  802 ). Such information may be contained within the smart proxy itself in that it may determine when or under what particular circumstances it requires updated processing code. If updated processing is required, the code for that processing is downloaded and the smart proxy is updated at the client machine to perform that processing (step  803 ). The smart proxy then performs at the client machine the processing according to the updated code (step  804 ).  
         [0086]    Machines implementing the steps shown in FIGS. 7 and 8 may include computer processors for performing the functions, as shown in FIGS. 3, 4,  5 , and  6 . They may include modules or programs configured to cause the processors to perform the above functions. They may also include computer program products stored in a memory. The computer program products may include a computer-readable medium or media having computer-readable code embodied therein for causing the machines to perform functions described above. The computerreadable media may include computer data signals embodied in a carrier wave and representing sequences of instructions which, when executed by a processor, cause the processor to securely address a peripheral device at an absolute address by performing the method described in this specification. The media may also include a data structure for use in performing the method described in this specification.  
         [0087]    Although the illustrative embodiments of the systems consistent with the present invention are described with reference to a computer system implementing the Java programming language on the JVM specification, the invention is equally applicable to other computer systems processing code from different programming languages. Specifically, the invention may be implemented with both object-oriented and nonobject-oriented programming systems. In addition, although an embodiment consistent with the present invention has been described as operating in the Java programming environment, one skilled in the art will appreciate that the present invention can be used in other programming environments as well.  
         [0088]    While the present invention has been described in connection with an exemplary embodiment, it will be understood that many modifications will be readily apparent to those skilled in the art, and this application is intended to cover any adaptations or variations thereof. For example, different labels or definitions for the smart proxies may be used without departing from the scope of the invention. This invention should be limited only by the claims and equivalents thereof.