Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-07-11
2001-06-26
Banankhah, Majid A. (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06253252
ABSTRACT:
BACKGROUND OF THE INVENTION
RELATED APPLICATION
The following related U.S. applications are hereby incorporated by reference: U.S. application Ser. No. 08/680,270 entitled “Method and Apparatus for Describing an Interface Definition Language-Defined Interface, Operation, and Data Type” by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/678,681 entitled “Method and Apparatus Using Parameterized Vectors For Converting Interface Definition Language-Defined Data Structures into a Transport and Platform Independent Format” by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/678,298 entitled “Data Structure Representing An Interface Definition Language Source File” by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/680,203 entitled “Method and Apparatus for Transporting Interface Definition Language-Defined Data Structures Between Heterogeneous Systems” by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/678,295 entitled “Method and Apparatus for Performing Distributed Object Calls” by A. Schofield filed Jul. 11, 1996; U.S. application Ser. No. 08/680,266 entitled “Method and Apparatus for Performing Distributed Object Calls using Proxies and Memory Allocation” by A. Schofield filed Jul. 11, 1996.
1. Field of the Invention
The present invention relates to a method and apparatus for making asynchronous object calls and asynchronous object implementations in client applications and server applications, respectively.
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 model. 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 that 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 returns a response to the client, if necessary. 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 implementation 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 application, starting the server application 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 definitional 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 and the parameters to those operations.
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, for example, to formulate 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 general, computer systems use one of three communication styles: (1) One-way communication; (2) Synchronous Communication; and (3) Asynchronous communication. If a client application in a distributed object system invokes a one-way request, the application sends the request and continues with other work without checking to see if the request was completed. The request truly would go only one way; the application sends the request to the server, but nothing ever returns from the server. If a client application invokes a synchronous communication request, the application transfers control to the ORB and cannot do anything until the request completed or failed. Synchronous communication are most appropriate when, an application needed to send and complete requests in a certain order and the operations were of short duration. If an application invokes an asynchronous object call, the application does not wait for the request to complete before it continued with other work. In time-critical situations, asynchronous communication is the preferred style for object calls. Similarly, the implementations of objects in server applications could benefit if asynchronous communication were efficiently
Banankhah Majid A.
Caldwell Pat
Thompson & Knight LLP
LandOfFree
Method and apparatus for asynchronously calling and... 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 asynchronously calling and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for asynchronously calling and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2470201