The present invention relates generally to object-oriented computer programs using distributed objects and, more particularly, to a distributed object architecture where an object on a local computer may create a sub-class of an object on a remote computer and thereafter function as a combined object by automatically, systematically communicating messages from the sub-class to object in a ripple up, return down fashion.
As stated in background section of U.S. Pat. No. 5,481,721, here paraphrased and embellished, an object is a programming unit that groups together a data structure (instance variables) and the operations (sometimes called member functions, methods, functions, or procedures) that can use or affect the data. Thus, an object consists of data and one or more operations or procedures that can be performed on that data. The joining together of data and operations into a unitary building block is called xe2x80x9cencapsulationxe2x80x9d. In object-oriented programming, operations that can be performed on the data are often referred to as xe2x80x9cmethods.xe2x80x9d An object can be instructed to perform one of its operations when it receives a xe2x80x9cmessagexe2x80x9d. A message is a command or instruction to the object to execute a certain method. It consists of a method selection (name) and arguments that are sent to the object. The message does not instruct the object how to perform the method. It is only necessary to request that the object execute the method.
Object-oriented programming is being brought to the forefront because the widespread adoption of network technologies and standardized communication protocols has provided nearly universal connectivity. The result of such universal connectivity is an immense number of computers that are connected together in local area networks, or Intranets, and a global network of such networks known as the Internet. Universal connectivity exposes users and application programs to vast amounts of data, much of which is unstructured. At the same time, universal connectivity has opened the possibility of using distributed functionality when designing and writing application programs. The encapsulation of data and functionality that is inherent in the object-oriented programming paradigm has resulted in this paradigm being chosen to address the problem of distributed functionality.
There are presently two popular frameworks for distributed object computing: (1) the Distributed Component Object Model (DCOM) supported by Microsoft, and (2) the Common Object Request Broker Architecture (CORBA) supported by a consortium of hardware and software companies called the Object Management Group.
FIG. 1 shows a typical prior art approach to executing an object. In order to provide flexibility at compile time, the object""s xe2x80x9cinterfacexe2x80x9d is maintained separately from the object""s xe2x80x9cimplementation.xe2x80x9d A standard mechanism such as an intermediate table relates the object""s interface to the object""s implementation. During compilation, the name of each member function is correlated with the corresponding binary code that implements the member function that will be invoked with the intermediate table. The intermediate table is often called a vector table, or xe2x80x9cV-tablexe2x80x9d. The implementation consists of executable class code that is written in the developer""s language of choice. Generally, because the compiler has to keep track of how the executable class code of each member function manipulates memory stacks, and the like, it is a practical necessity that all of the member functions be written in the same language at the same time. It is not practical, in other words, to provide member functions written in different languages or to modify, enhance (add functionality), or xe2x80x9cswap-outxe2x80x9d a member function on the fly, much less do so with an object that is distributed across a computer network or across computer languages.
An object is ultimately accessed at run-time by using a pointer to the object. The pointer contains the address of the V-Table that in turn contains more pointers (called xe2x80x9cinterfacesxe2x80x9d) to the object""s member functions. The sizes of the V-Table and executable class code are fixed when the description of the object is compiled. At runtime, an invocation of a particular member function results, with the help of the V-Table, in the execution of the corresponding code. A member function (e.g. Member Function 3) is called by first obtaining the interface pointer for the 3rd interface in the V-Table whose address can be accessed from the object pointer. The interface pointer thus obtained is the memory address of the code within the object that implements Member Function 3. If additional member functions are added to the object at a later time, then the executable class code must be recompiled and the V-table must be recreated. The executable class code implementing the member functions must be modified to include the additional member function. The V-Table must be modified to reflect the new sizes and starting locations of the member function code. When generating code for a program that will use the object, the compiler must be aware of the location within the V-Table (but not in the object itself) of the member function that is being called.
There are certain standard object functions that are desirable in an an object-oriented language:
xe2x80x9cFunction Name Overloadingxe2x80x9d
Function Name Overloading refers to situation where two member functions have the same name, but are differentiated from one another by the number of parameters, type of parameters, or both. In FIG. 1, for example, member function 2 and member function 3 might have the same name, but different implementations. When a compiler is generating a call to that name, the compiler will have to use the parameter list for each member function of that name to determine which V-Table entry to hardcode into the caller""s code. In other words, the compiler must be aware of the location within the V-Table of the member function that is being called, and of the parameters that are used by each of the member functions when it is compiling the program that will use the object.
Inheritance
Inheritance is a mechanism for creating a new class from an existing class. The existing class is called the base class and the new class is called the derived class. In FIG. 2, a derived class was created that contains a new version of Member Function 4, and a new function, Member Function 5. The new version of Member Function 4 is said to override the version of Member Function 4 that exists in the base class. When creating code for the derived class, the compiler will create new executable code and a new interface table that contains the code and interfaces for both the base class and the derived class. The base class itself, however, will not have to be re-compiled as long as its binary representation and interface description are available.
If a second derived class is created from the same base class, and this derived class also overrides Member Function 4, then there are now two derived classes, each with its own version of Member Function 4. Note that the first three entries in the V-Tables for the two derived classes would be the same, while the entry in the V-Table for Member Function 4 will be in the same relative location in the V-Tables. A caller calling a member function can use the same method invocation for Member Function 4 for either of the derived classes, but the actual code executed will depend on which derived class is being used. The ability for different classes that are derived from the save base class to respond to the same method invocation is called polymorphism.
Prior distributed object architectures require some method of remote invocation in order to permit one computer (client) to interact with an object located on another computer (server). The known distributed object architectures are overly complex because the objected-oriented languages like C++ have their roots in conventional programming languages like C. In particular, the existing distributed object architectures assume that what you really want to do is run a program some place else just as if you ran it on your own system. If you adopt this assumption, then you have to make sure that everything that can be done on the remote system can be done on own system. In other words, you have to make sure that a remote member function can run on a local computer just like it was a local member function.
At least one of these prior art approaches uses a byte stream to communicate between client and server. Nonetheless, all of the distributed component architectures known to this inventor offer complicated solutions to providing remote execution rather than elegant solutions to simply get the data from a remote source.
Static Remote Object Invocation
FIG. 3 relates to a typical static invocation where a xe2x80x9cclient stubxe2x80x9d (discussed below) is compiled such that the available interfaces are fixed at the time of compilation. This is the known architecture that relies on a byte stream.
Static invocation involves the creation of a client stub on the client computer that has the same interfaces as the remote object. The client stub is an object in its own right and it will support the standard mechanism for relating the interface of an object to the implementation of the object (e.g. a V-Table). When the client invokes a particular member function in the client stub, the stub will participate in a process called marshalling and create a byte stream that contains an identifier of the function and the data associated with all of the function""s required parameters. If the server computer has a different architecture than the client computer, the marshalling process may also convert the data making up the byte stream into some standard format (e.g. modifying the byte order, and so on).
The byte stream is then transferred via some communications protocol to the server computer where, as suggested by the right side of FIG. 3, it is converted back into the member function and associated parameters of the server object. The member function on the server object is then called in whatever standard way objects are invoked and called on the server computer. Note that the language in which the remote server object is written does not have to be the same as the language in which the client object is written because the marshalling converts member function calls and data into a language and computer architecture standard format.
Dynamic Remote Object Invocation
In dynamic invocation, no client stub is required. Instead, the client program can determine the member functions and parameters of the remote object dynamically, and then call the marshalling code directly to create the byte stream and send it to the server side stub.
Notwithstanding the industry""s efforts to support and develop distributed object applications such as DCOM and CORBA, it remains difficult to create and use objects across computer hardware and computer language boundaries. There remains a need, therefore, for an improved method of creating and using a sub-classed object that spans multiple computers in a networked computing system
In a first aspect, the invention resides in a method of processing a request message from a calling computer program in a distributed object computing system containing a hierarchy of objects distributed across computers, said method comprising the steps of: successively providing the request message to a next-highest object beginning with a lowest-most object and progressing toward a highest-most object; and checking each object provided with the request message to determine if it is to respond to the request message; and, if it is to respond, creating a response message; and returning the response message to the calling computer program by successively providing the response message to a next-lowest object until it reaches the lowest-most object.
In a second aspect, the invention resides in a method of deriving a sub-class from a remote objects contained on a remote computer and from local objects contained on a local computer to produce a hierarchy of objects distributed across the local and remote computers, said method comprising the steps of: providing an object table with a data structure for holding a plurality of object records that point to target objects; and populating the object table beginning with a lowest-most object corresponding to an object on the local computer and ending with a highest-most object that contains a pointer to the lowest most object in an object table on the remote computer so that logically the two object tables act as a single object table.
USPTO Backgrounds
USPTO Backgrounds