Electrical computers and digital processing systems: interprogra – Remote procedure call
Reexamination Certificate
1996-07-11
2004-06-15
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: interprogra
Remote procedure call
Reexamination Certificate
active
06751798
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a method and apparatus for performing distributed object calls using proxies on the client side and memory allocation on the server side. Specifically, the method involves the creation of a proxy handle data structure to be associated with a particular object and its associated object reference. On the client side, object calls to the associated object are then made using the proxy handle, thus allowing multiple calls to the same object and eliminating the need to perform certain initialization functions each time the call is made. On the server side, the server allocates memory in a platform-independent manner.
2. Background
Distributed object computing combines the concepts of distributed computing and object-oriented computing. Distributed computing consists of two or more pieces of software sharing information with each other. These two pieces of software could be running on the same computer or on different computers connected to a common network. Most distributed computing is based on a client/server mode. With the client/server model, two major types of software are used: client software, which requests the information or service, and server software, which provides or implements the information or service.
Object-oriented computing is based upon the object model where pieces of code called “objects”—often abstracted from real objects in the real world—contain data (called “attributes” in object-oriented programming parlance) and may have actions (also known as “operations”) performed on it. An object is defined by its interface (or “class” in C++ parlance). The interface defines the characteristics and behavior of a kind of object, including the operations that can be performed on objects of that interface and the parameters to each operation. A specific instance of an object is identified within a distributed object system by a unique identifier called an object reference.
In a distributed object system, a client application sends a request (or “object call”) to a server application. The request contains an indication of the operation to be performed on a specific object, the parameters to that operation, the object reference for that object, and a mechanism to return error information (or “exception information”) about the success or failure of a request. The server application receives the request and carries out the request via a server “implementation.” The implementation satisfies the client's request for an operation on a specific object. The implementation includes one or more methods, which are the portions of code in the server application that actually do the work requested of the implementation. If the implementation is carried out successfully, the server application may return a response to the client. The server application may also return exception information.
To standardize distributed object systems, the Object Management Group (“OMG”), a consortium of computer software companies, proposed the Common Object Request Broker Architecture (“CORBA”). Under the CORBA standard, an Object Request Broker (“ORB”) provides a communication hub for all objects in the system passing the request to the server and returning the response to the client. Commercial ORB's are known in the art and a common type is IBM's System Object Model (“SOM”). On the client side, the ORB handles requests for the invocation of a method and the related selection of servers and methods. When a client application sends a request to the ORB for a method to be performed on an object, the ORB validates the arguments contained in the request against the interface for that object and dispatches the request to the server, starting it if necessary. On the server side, the ORB uses information in the request to determine the best implementation to satisfy the request. This information includes the operation the client is requesting, what type of object the operation is being performed on, and any additional information stored for the request. In addition, the server-side ORB validates each request and its arguments. The ORB is also responsible for transmitting the response back to the client.
Both the client application and the server application must have information about the available interfaces, including the objects and operations that can be performed on those objects. To facilitate the common sharing of interface definitions, OMG proposed the Interface Definition Language (“IDL”). IDL is a definition language (not a programming language) that is used to describe an object's interface; that is, the characteristics and behavior of a kind of object, including the operations that can be performed on those objects.
IDL is designed to be used in distributed object systems implementing OMG's CORBA Revision 2.0 specification, which is incorporated by reference herein. In a typical system implementing the CORBA specification, interface definitions are written in an IDL-defined source file (also known as a “translation unit”). The source file is compiled by an IDL compiler that generates programming-language-specific files, including client stub files, server stub files, and header files. Client stub files are language-specific mappings of IDL operation definitions for an object type into procedural routines, one for each operation. When compiled by a language-specific compiler and linked into a client application, the stub routines may be called by the client application to invoke a request. Similarly, the server stub files are language-specific mappings of IDL operation definitions for an object type (defined by an interface) into procedural routines. When compiled and linked into a server application, the server application can call these routines when a corresponding request arrives. Header files are compiled and linked into client and server applications and are used to define common data types and structures.
In a system implementing the CORBA specification, object calls are made by calling the appropriate client stub function. The parameters to these stub functions typically include the input parameters for the requested operation and the object reference of the object. The CORBA specification, however, has certain performance-related drawbacks. First, each time an object is called, certain configuration operations must be performed. For instance, the object must be validated to ensure its existence. In addition, memory (or another resource) is often allocated for the call. The interface must be determined. Finally, transport of the call is prepared (e.g., opening files, preparing sockets, etc. . . . ). Performing each of these operations prior to each object call can be very time-consuming. In a time-critical application, the overhead associated with each object call can significantly affect performance.
Further, on the server side, performance is affected by the improper allocation and deallocation of memory (“garbage collection”). In many distributed object systems, memory can be allocated for the implementation of an object call. Once the implementation has been performed and the server responds to the call, however, memory is not automatically deallocated. This failure to deallocate memory leads to wasted resources and, therefore, slower performances. In addition, the failure to remove pointers or addresses pointed to by pointers can lead to larger problems, such as system errors and application shutdowns.
Certain systems have attempted to use garbage collection in the implementation of object calls. Those systems, however, use platform-specific methods for deallocating memory. Thus, code portability is often sacrificed in favor of proper memory allocation and deallocation.
Accordingly, a need exists for a method for improving object call performance by eliminating the need to configure an object call each time the same object is called.
Further, a need exists for a platform-independent method for improving object call performance by allocating and deallocating mem
724 Solutions Software Inc.
Follansbee John
Thompson & Knight L.L.P.
LandOfFree
Method and apparatus for performing distributed object calls... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for performing distributed object calls..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for performing distributed object calls... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3306611