US20050240945A1 - System and method for dynamic generation of remote proxies - Google Patents

Abstract

A software system is disclosed which provides for dynamic generation of remote proxy classes at run time through a distributed object management system16. The software system provides for a client system14and server system12which communicate via distributed object management system16which operates over a distributed computer network to allow communications between client system14and server system12. Any inter-object communication will invoke a remote proxy generation control module34if a remote proxy class23does not already exist for the requested subject object18. A remote proxy generation control module34is provided which first invokes reflection engine36to determine the applicable information of subject class19. Next, a communication enabling module40determines and inserts the appropriate computer code to allow local object20to communicate with subject object18utilizing remote proxy object22. After the system determines what information is required by remote proxy class23, byte code generator42automatically generates the executable code containing remote proxy class23. Finally, class loader46loads remote proxy class23onto the system and creates a new instance which is remote proxy object22.

Description

RELATED APPLICATIONS
• This application is a continuation of pending U.S. application Ser. No. 09/451,507, which is a continuation-in-part application of U.S. application Ser. No. 09/175,079 now U.S. Pat. No. 6,385,661.
TECHNICAL FIELD OF THE INVENTION
• This invention relates in general to the field of software systems, and more particularly to an improved system and method for dynamic generation of remote proxy classes within a distributed object management system.
BACKGROUND OF THE INVENTION
• Object oriented programming is a method of programming which abstracts a computer program into manageable sections. The key to object oriented programming is the concept of encapsulation. Encapsulation is a method by which the subroutines, or methods, that manipulate data are combined with the declaration and storage of that data. This encapsulation prevents the data from arbitrarily being accessed by other program subroutines, or objects. When an object is invoked, the associated data is available and can be manipulated by any of the methods which are defined within the object to act upon the data. The basic component of encapsulation is a class. A class is an abstraction for a set of objects that share the same structure and behavior. An object is a single instance of a class that retains the structure and behavior of the class. Objects also contain methods which are the processes by which an object is instructed to perform some procedure or manipulation of data which it controls. Classes may also be characterized by their interface which defines the elements necessary for proper communication between objects.
• Distributed computing allows an object on one computer system to seamlessly communicate with and manipulate an object contained in a second computer system when these computers are connected with a computer network. This second computer system may also be referred to as another address space. Sophisticated distributed computing systems have removed the communications burden from the computer programs, or objects in an object oriented programming environment, and placed it in a mid-level operating system which purpose is to manage communications across a computer network to facilitate a client's access to and manipulation of data contained on a server system, for example, a computer remote to the user in a different address space.
• Distributed computing and object oriented programming have led to the development of distributed object management systems. When an object on a client computer system requests access to an object which exists only on a server computer system, the distributed object management system steps in to facilitate the communication between the two computer systems and, thus, between the two objects. The distributed object management system removes the requirement of the object on the client system communicating directly with the object on the server system. Instead, current distributed object management systems create a remote proxy object on the client system which models the interface of the object which exists on the server system. The client computer system which requested access to the remote object communicates with the remote proxy object which now exists on the client computer system. Therefore, the client computer system can operate as if it is communicating directly with a local object. The remote proxy object contains the necessary communications information to allow the client computer system to access and manipulate an object which actually exists on the server computer system. Remote proxies allow the client system to disregard the location of the requested object and the communication details.
• A proxy is an object which has an interface and method list identical to another object. However, it does not contain the same detail computer programming. Instead it contains communications requirements which allow the proxy to communicate directly with another object without the knowledge of the first object. Proxies can be used to control access to certain objects. They may also be used to remove the labor of distributed processing communications from local objects. For example, if object A which resides on a first computer system needs to communicate with object B which resides on a second computer system, object A must know the location of object B and have the necessary computer code to initiate communications with object B located on the second computer system. A proxy for object B located on the first computer system allows object A to simply communicate with the proxy of object B as if object B resided on the same computer. The proxy for Object B has all the necessary information and computer code to communicate with the real object B on the second computer system. This type of proxy is known as a remote proxy since it exists on a computer system remote from the computer system which contains the requested object.
• Systems heretofore known have required all possible remote proxies to be built when the software system is initially compiled and loaded onto a computer. This process can be very time consuming and the resultant remote proxies can require large amounts of computer storage. In addition, software system designers must predict every possible remote proxy which may be needed in the future so that it can be built when the software system is loaded. This process does not allow a system to adapt to its usage and environment.
SUMMARY OF THE INVENTION
• Accordingly, a need has arisen for a software system in the area of distributed processing which reduces the time and expense required to build, load and store a distributed object management system.
• According to one embodiment of the present invention, a software system is provided that comprises a client system and server system that communicate via a distributed computer network utilizing a distributed object management system. The distributed object management system also comprises a remote proxy generator to dynamically generate at run time remote proxy classes as needed for inter-object communications within the distributed computer network.
• One important technical advantage of the present invention inheres in the fact that it decreases development time and increases developer productivity since the developer does not have to manually generate the remote proxy classes when the system is initially installed or when the subject class is modified in the future. Other technical advantages include reduced initial system build time and reduced disk storage space required to store the application programs.
BRIEF DESCRIPTION OF THE DRAWINGS
• For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein:
• FIG. 1 is a block diagram illustrating a distributed object management system constructed according to the teachings of the present invention;
• FIG. 2 illustrates a flow chart of a method of determining when dynamic generation of remote proxy classes is needed according to the teachings of the present invention;
• FIG. 3 is a block diagram illustrating dynamic generation of remote proxy classes according to the teachings of the present invention; and
• FIG. 4 illustrates a flow chart of a method of dynamically generating remote proxy classes according to the teachings of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
• Referring toFIG. 1, a distributed processing computer system generally indicated at10 is illustrated that comprises one ormore server systems12 and one ormore client systems14. The client/server computer systems allow for decentralized computing which includes the ability to manipulate data which is resident on a remote system. Theserver system12 andclient system14 may comprise a personal computer, mini computer, main frame computer, or any other suitable computer type device. In a computer network environment, each computer is assigned a unique address. Therefore, if data, code or objects exist on a different computer, it is said to exist in a different address space.
• Theclient system14 requests access to data or services which may be contained onserver system12.Server system12 may then process the request and approve access as requested byclient system14.Client system14 is connected toserver system12 via a distributedobject management system16 operating across a computer network. The distributedobject management system16 handles the communications betweenclient system14 andserver system12. Without distributedobject management system16, distributed processing could not take place sinceclient system14 would not be able to determine the location of or obtain access to the requested data or services. The distributedobject management system16 may comprise Voyager, a distributed network communications system developed by ObjectSpace, Inc., CORBA (Common Object Request Broker Architecture), a technology for inter-object communications developed by a consortium of companies, DCOM, an inter-application communications system for networked computers developed by Microsoft, or any other suitable distributed object management system.
• The present invention teaches a system and method for generating proxies on local systems to facilitate access to objects on remote systems. An object is an instance of a class within the programming methodology of object oriented programming. The present invention may be implemented using the Java language, developed by Sun Micro Systems, Inc., or any other suitable computer language.
• When an object class source code description is created in the Java language, it is stored on a storage device as a java file. Upon compilation, the object class executable code is represented as a class file on the storage device. When an object is needed, a new instance, as prescribed by the class file is created, and it then is referred to as an object.Server system12 may contain one or moresubject objects18 for whichclient system14 may issue a request for access. In such a case,subject object18 is the subject of client system's14 request.Client system14 may contain one or morelocal objects20. It is important to note thatlocal object20 can itself be a subject object, andsubject object18 can itself be a local object depending on what computer, or address space, is making the request for access. For purposes of illustrating the present invention,local object20 andsubject object18 exist in different address spaces. However, bothlocal object20 andsubject object18 could reside on the same computer and still invoke the system and method of the present invention. The present invention is utilized in all inter-object communications regardless of their relative locations.
• Local object20 may request access tosubject object18. This request invokes the distributedobject management system16. In order to isolate the distributed processing communication requirements fromlocal object20, aremote proxy object22 may be created onclient system14.Remote proxy object22 has an interface and list of methods identical tosubject object18.Remote proxy object22 is so named since it may be remote fromsubject object18, and it provides a local representative for an object which may reside in a different address space. Remote proxies in general are responsible for encoding a request and its arguments and for sending the encoded request to the subject object which may exist in a different address space. Remote proxies also hide the location of the subject object from the requesting local object. Therefore, any local object can assume, from an access point of view, that any object it needs is local.Local object20 communicates withremote proxy object22 which then communicates withsubject object18 via distributedobject management system16. By doing this,local object20 is unconcerned with the location ofsubject object18. As far as it is concerned,local object20 is communicating directly with another local object, but in reality, it is communicating withsubject object18 which may reside in a different address space.
• Currently, a system developer must anticipate all necessary remote proxies and create the remote proxy classes. Some distributed object management systems have a utility which augments the build process by allowing remote proxy classes to be built when the system is compiled. Although this process minimizes the system developer's effort, it still involves developer intervention, computer resources and time. Another disadvantage with current distributed object management systems is that these remote proxy classes must be kept in sync with the subject classes as the subject classes and interfaces are modified. Another disadvantage with current distributed object management systems is that all remote proxy classes must be stored on the computer and available for use when needed. This creates high overhead in developer effort, computer storage and processing requirements.
• In contrast, a system constructed using the present invention dynamically generates remote proxy classes as needed at run-time. There are several advantages of this method. The primary advantage is reduced system development time since the system developer does not have to manually generate remote proxy classes when the system is initially compiled or manually regenerate remote proxy classes each time a subject object class is modified. The system of the present invention also reduces computer program storage requirements since remote proxy classes are not a permanent part of the operating environment. It also minimizes compile and load time for the computer program since remote proxy classes do not have to be generated at compile and load time. In order to optimize system performance, generated remote proxy classes remain in memory until the distributed object management system is shut down.
• Referring again toFIG. 1, the dynamic generation of remote proxies may be accomplished by parsing the .class or java file forsubject object18 and creating a .java file forremote proxy object22 which contains the interfaces and methods of thesubject object18. The Java compiler may then be invoked to compile the .java file into a .class file forremote proxy object22. The compiled .class file can then be loaded into the computer system via a class loader which is a standard element in a Java environment. A .class file must be loaded before it is available for use by distributedprocessing computer system10. Once the .class file is loaded, a new instance of the compiled .class file may be created which will beremote proxy object22.
• The process of parsing thesubject object18 class (subject class19) or .java file, creating a source code file forremote proxy class23, compiling, loading, and creating a new instance may be excessively slow at run-time. In order to address this issue, a reflection process may be used onsubject object18 to determine its name, interfaces and list of methods and then to directly generate the byte codes into a .class file,subject class19. The byte codes are the executable code stored in a class file. The class file can then be loaded into the computer system with the class loader. This embodiment eliminates the need to parse the .class file, create a .java source code file, and shell out the .java file to a compiler since the code generation process occurs as part of the dynamic generation of remote proxies. This entire process of dynamic generation of remote proxies will be discussed in detail with reference toFIGS. 2, 3 and4.
• Referring toFIG. 2, the process of determining if a remote proxy is necessary is invoked via a request fromlocal object20 for access tosubject object18. The method begins atstep24 wherelocal object20 onclient system14 requests access tosubject object18 onserver system12. This request could be for any object whether it is local or remote and in a different address space. The system of the present invention generates and utilizes remote proxy objects in all inter-object communication to provide additional processing support. Thus, any communication between objects, regardless of their location, utilizes remote proxy objects. These remote proxy objects act as a middle man between the requested object and the requesting object to provide additional processing functionality which may include increased security.
• Referring again toFIG. 2, the method then proceeds to step26 where the requested object is located on eitherclient system14 orserver system12. The method proceeds to step30 where a determination is made regarding the need for a remote proxy class. Ifremote proxy class23 already exists onclient system14, then the method terminates since remote proxy classes are not removed fromclient system14 until the distributedobject management system16 is shut down. However, ifremote proxy class23 does not exist onclient system14, the method then proceeds to step32 whereremote proxy class23 is generated onclient system14 based on the name, interfaces and methods ofsubject object18 which may reside on eitherserver system12 orclient system14. The method for generating these remote proxies is described in detail with reference toFIGS. 3 and 4.
• FIG. 3 is a functional diagram of the portions of distributedobject management system16 that are used to create remote proxy classes as necessary. Remote proxygeneration control module34 is invoked atstep32 inFIG. 2. When the distributedobject management system16 invokes the remote proxygeneration control module34, the method described previously has already determined that theremote proxy class23 does not yet exist onclient system14. Remote proxygeneration control module34 generatesremote proxy22 onclient system14 solocal object20 can communicate withsubject object18 via distributedobject management system16.
• As previously discussed, in object oriented programming, an object is an instance of a class. Classes may be defined in a class hierarchy where each class inherits the attributes of all of its ancestors. Inheritance is a concept which maps related classes onto each other in a hierarchical way. This allows a descendant of a class to inherit all of its variables and methods from its ancestors as well as create its own. The immediate ancestor of a class is known as its superclass. Therefore, in order to determine all of a class's attributes, all of the class's ancestors, or superclasses, must be determined.
• To fully define a remote proxy for a subject object, remote proxies must be generated for each of the subject object's superclasses. By generating these superclass remote proxies, the remote proxy for subject object will inherit all of the variables and methods of its ancestors, or superclasses. An alternative to generating superclass remote proxies includes adding all of the superclass methods and interface requirements to the remote proxy class. By adding the superclass information to the remote proxy class, the need for generating superclass remote proxies is eliminated.
• Referring again toFIG. 3, remote proxygeneration control module34 first invokesreflection engine36 to determine information regardingsubject class19. The process of reflection operates onsubject class19 which is the Java .class file forsubject object18. Although for illustrative purposes,subject object18 and its Java .class file,subject class19, exist onserver system12,subject class19 could exist on eitherclient system14 orserver system12. Therefore, the dynamic generation of remote proxy classes as described in the present invention could take place on eitherclient system14 orserver system12.
• Reflection is a process that determines what an object can do, how it is defined, and how it communicates with other objects. Reflection mirrors the public view of an object to collect information to facilitate the creation of proxies which resemble objects on the public view, but are very different internally, or privately. The public view of an object represents the information external objects must know in order to communicate with the first object. Proxies need to be reflections, or duplicates on the surface, of objects since proxies perform specific tasks such as controlling access to or communications with the objects they represent. Thus, proxies need to look like the object on the outside, but on the inside, proxies contain unique computer code to accomplish their assigned function. The reflection process is only concerned with determining the public view of an object. Therefore, the information determined by the reflection process includes the following: name; list of implemented interfaces; list of methods; and superclass information.
• Continuing withFIG. 3,reflection engine36 issues queries againstsubject class19, which is the .class file forsubject object18, to determine each ofsubject class19 superclasses, its name, its interfaces, and each of its methods. The results of these queries are temporarily stored within remote proxygeneration control module34 asJClass information38.JClass information38 is a temporary storage area which defines the name, superclasses, interfaces, and methods ofsubject class19.JClass information38 would also include the name, interfaces, and methods of each ofsubject class19 superclasses.
• Ifsubject class19 has superclasses, a remote proxy may be first generated for each superclass using the system and method described with reference to the present invention. After the superclass remote proxies are generated,JClass information38 contains the name, interface, and list of methods forsubject class19. An alternate methodology for providing superclass methods and interfaces for the remote proxy class is to add all superclass method and interface information to the remote proxy class. By doing this, the need for separate superclass remote proxies is eliminated.
• Once the name, interface, methods, and superclass information are determined forsubject class19, acommunication enabling module40 adds to JClassinformation38 the computer code necessary forremote proxy object22 to communicate withsubject object18 via distributedobject management system16. Thecommunication enabling module40 inserts the computer code intoJClass information38 which is the definition of all the information thatremote proxy object22 needs to function within distributedobject management system16.
• Since a remote proxy's purpose is to communicate with a subject object which may exist either in a different address space or in the same address space, the remote proxy contains essentially only the following information: interfaces identical to the subject object; a list of methods identical to the subject object; and computer code necessary for the remote proxy to communicate with the subject object. In an alternate embodiment of the present invention, the remote proxy would contain all of the information mentioned above and the interfaces and methods of all of the subject object's superclasses.
• At this point,JClass information38 contains subject object's18 name, interfaces, methods, and the computer code necessary for communications within distributedobject management system16.JClass information38 could also contain the superclass information forsubject object18. The next function invoked by remote proxygeneration control module34 isbyte code generator42. The purpose ofbyte code generator42 is to directly generate the executable code corresponding to JClassinformation38.JClass information38 is the definition of the Java class of whichremote proxy object22 is an instance. That is,JClass information38 is the definition ofremote proxy class23.Byte code generator42reviews JClass information38 and generates the corresponding byte codes, or executable code, intoremote proxy class23 which is a Java class file. As previously discussed, a Java class file is executable code which defines a Java class.
• Byte code generator42 is a collection of Java classes which are capable of taking the description of the needed proxy class inJClass information38 and directly generating the executable Java code in memory. The function ofbyte code generator42 is similar to that of a Java compiler. Like a Java compiler,byte code generator42 generates executable Java code. However, the inputs are very different. A compiler requires a source code file which is a string of bytes which is the sequence of statements for a Java object definition. The string of bytes is parsed by the Java compiler and translated into executable Java code. In contrast,byte code generator42 takes general information regarding the needed Java object and directly generates executable Java code without the need for the intermediate step of creating a Java source file. This technique yields considerable time savings since several steps are omitted. For example, like a Java compiler,byte code generator42 generates a hexadecimal “CAFEBABE” to indicate to the Java virtual machine that a Java class file begins at that point in memory.Byte code generator42 is constructed in such a way that the byte codes are generated in the sequence required by the Java virtual machine.
• For each Java construct,byte code generator42 writes the appropriate header information and hexadecimal byte codes representing the Java construct into computer memory. Thus, there is a block of code, or hexadecimal bytes, for each Java construct. As described above,JClass information38 contains the computer code necessary for communications within distributedobject management system16.Byte code generator42 translates this communications information into byte codes recognizable to the Java virtual machine. Whenbyte code generator42 terminates, the string of hexadecimal bytes necessary to define the proxy class has been stored in memory asremote proxy class23 which is an executable Java class file.Remote proxy class23 has a unique name which is derived fromsubject class19 name. For example, ifsubject class19 is named “Foo.class”, itsremote proxy class23 name would be “Foo_Proxy.class”.
• Beforeremote proxy class23 can be used, it must be loaded ontoclient system14 utilizing aclass loader46.Class loader46 may comprise any number of suitable programs which exist in typical object oriented programming environments. Theclass loader46 will then createremote proxy object22 which is an instance ofremote proxy class23 generated bybyte code generator42.
• FIG. 4 is a flow diagram that illustrates the process of generating a remote proxy when invoked bystep32 inFIG. 2 and as represented in general by the block diagram inFIG. 3. The method begins atstep48 where thereflection engine38 queriessubject class19 to determine its superclass. The method then proceeds to step50 where a determination is made regarding the existence of a superclass forsubject class19. If a superclass is found forsubject class19, then the method proceeds to step52 where a determination is made regarding the existence of the remote proxy class onclient system14 representing subject class'19 superclass. If a remote proxy class does not exist for subject class'19 superclass, the method proceeds to step54 where the remote proxy class is generated for subject class'19 superclass by recursively invoking the remote proxygeneration control module34. Thus, step54 recursively invokes the method illustrated inFIG. 4.
• Referring to step52, if the remote proxy class does exist onclient system14 for subject class'19 superclass, then the method proceeds to step56 (described below) since remote proxy classes already exist for all of subject object's18 superclasses.
• In an alternate embodiment of the present invention, instead of recursively generating remote proxy classes for each ofsubject class19 superclasses, the interfaces and methods of each ofsubject class19 superclasses are stored inJClass information38 and are later used in the generation ofremote proxy class23. In the alternate embodiment, steps48-54 would not exist in their current form. Instead, these steps would consist of determining the names, interfaces, and methods of all ofsubject class19 superclasses and storing the information inJClass information38.
• Referring to step50 if a superclass does not exist forsubject object18, then the method proceeds to step56 wherereflection engine36 queriessubject class19 to determine subject class'19 name and interface. The method then proceeds to step58 wherereflection engine38 queriessubject class19 regarding its methods.Reflection engine36 issues queries for each of subject class'19 methods until all methods are determined. For each of subject class'19 methods, the software system determines the method name, return type, parameters, and exceptions and stores the information inJClass information38.
• The method then proceeds to step60 wherereflection engine36 createsJClass information38 from the name, interface, and methods information determined insteps56 and58. The method then proceeds to step62 wherecommunication enabling module40 inserts inJClass information38 the computer code, in the form of an expression tree, necessary forremote proxy object22 to communicate withsubject object18 via distributedobject management system16.
• The method then proceeds to step64 wherebyte code generator42 generates the executable code representingJClass information38 intoremote proxy class23. The method then proceeds to step66 whereclass loader46 loadsremote proxy class23 ontoclient system14 where it is now available for use. The method then proceeds to step68 whereremote proxy object22 is generated as a new instance ofremote proxy class23 which was loaded instep66.
• According to the teachings of the present invention, a software system is provided that allows for the dynamic generation of remote proxy classes. The advantages of dynamic generation of remote proxy classes includes reduced system development time, reduced system compile and build time, reduced system modification time, and reduced system storage requirements. Remote proxy classes are generated as needed at run time. Once a remote proxy class is generated, it continues to exist until the system is shut down. Therefore, the software system is only required to generate a particular remote proxy class once during a session of the software system.
• Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (1)

1. A remote proxy generator for dynamic generation of remote proxy classes within an object oriented distributed processing environment, comprising:

a reflection engine operable to determine the name, interfaces, methods and superclass information of a remote object within the object oriented distributed processing environment for use in creating the remote proxy class in response to a request for access to the remote object;

a communications enabling module operable to aid in creating the remote proxy class by inserting within the remote proxy class computer code required for communications between objects within the object oriented distributed processing environment; and

a byte code generator operable to generate the executable computer code representing the determined name, interfaces, methods, superclass information and communications computer code for the remote proxy class.

Images