Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-07-11
2001-11-20
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S203000, C709S230000
Reexamination Certificate
active
06321273
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to the execution of remote procedure calls on networked computer systems. More particularly, the present invention is a method and apparatus for ensuring correct parameter ordering when a remote procedure call is made between heterogeneous platforms.
BACKGROUND OF THE INVENTION
The networking of computers has, in recent years, become increasingly common. For example, Automated Teller Machines, or ATMs, represent one type of commonly used computer network. Computer networks are also used to schedule air travel reservations and to link computers within offices and factories. Recently, with the rise of the world wide web, computer networking has gained an acceptance and notoriety which would have been difficult to imagine, even in the recent past.
Historically, computers have been networked to perform specialized tasks. For example, ATM networks were constructed to handle the day-to-day financial transactions of bank customers. Other computer networks were constructed to help companies track inventory or employee records. These types of specialized computer networks were efficiently implemented using a simple client/server model. In this model, a number of client processes, usually running on remote computers and terminals, requested services and information from one or more server processes. The server processes, which often executed on a centralized mainframe, would process the requests from the client processes and provide the required information and services.
Simple client/server computer networks have proven to be well suited to the performance of specialized and well defined tasks. Increasingly, however, specialized computer networks are being combined into larger, heterogeneous networks which offer a range of different services. For example, there is obvious utility in having a single computer network within a bank which coordinates the actions of not only the bank's ATMs, but also the computers that process the bank's financial records. In fact, it is easy to see that networking all of a bank's computers might provide the bank with certain advantages, and that linking the banks network to a larger network, such as the internet, could provide the bank's customers with the ability to perform some transactions from their home computers.
Unfortunately, when compared to simple client/server networks, heterogeneous computer networks have been found to be much more difficult to design and implement. This is due, of course, to the variety of computer types, operating system types and communication protocols which must be supported. It is also due, in part, to the fact that, in heterogeneous networks, there is no single centralized server. Instead, many servers provide different services and servers are often clients of other servers. As a result, when a new service or protocol is added to a heterogeneous network, it often has to be integrated into many different systems.
Distributed object computing is a method for reducing the complexity involved in the design, implementation and maintenance of computer networks. In general terms, distributed object computing is an application of concepts developed in object oriented programming to computer networking. Object-oriented programming, or “OOP”, is based upon a model where programs are written in terms of “objects” which are often abstracted from objects in the real world. Objects are collections of data elements, which may be “private” or “public,” and functions, which may also be “private” or “public.” In object oriented programming, groups of related objects are referred to as an object “class.”
One of the primary goals of object-oriented programming is known as “encapsulation”, or “data hiding.” Generally, encapsulation is the ability of an object to control access to its non-public data and functions. Specifically, direct access to an object's private data and functions is prohibited. Instead, access to private data and functions is provided indirectly through the object's public functions. As a result, an object may perform a particular task without revealing any details of how the task is performed. For example, in an object oriented programming language which does not support complex numbers, it would be possible to define a complex number object. The complex number object would be defined to include a real data element and an imaginary data element. The object could also be defined to have public functions for addition, subtraction and printing of imaginary numbers. Once the object was defined, instances of the object could be added, subtracted and printed without any knowledge of the inner workings of the objects involved.
Distributed object computing applies the paradigm of object oriented programming to computer networking. In a distributed object system, a common description language is used to define classes of objects available within the computer network. A descriptive language is, in some ways, similar to a programming language. Descriptive languages can only be used, however, to define objects and not to actually implement the algorithms associated with those objects. Each object corresponds to a service provided by one or more servers within the network. Clients obtain access to these services by making a request (or “object call”) using one or more of the defined objects. The server which implements the involved objects receives the request and, if possible, carries out the requested operation. Importantly, through encapsulation, the client does not need to know how the request will be carried out by the server.
The Interface Definition Language (IDL), as defined by the Object Management Group (OMG), is an example of an object oriented description language which is specifically directed at the construction and maintenance of computer networks. Using IDL, a programmer defines objects which correspond to services available on the computer network. These objects are included in an IDL source file (or “translation unit”). The IDL source file is processed by an IDL compiler which produces, as output, source files written in a high-level programming language, such as C or COBOL. The IDL output files contain definitions, stubs, and skeletons which correspond to each object originally defined in the IDL source file. The IDL output files are then separately compiled for the client system and the server systems. When compiled for the client systems, the stubs included in the IDL output files become object calls. The client may then request the defined service by calling the stub procedure. When compiled for the server, the skeleton procedures map the defined request to the system of the server. The server may then process the client's object calls by executing the skeleton procedure.
When an object call is made, a list of parameters (often consisting of references to objects), must be transported between client and server. Such object calls may occur between identical systems, but are increasingly likely to be made across heterogeneous platforms using different operating systems, programming languages, and compilers. As a result, there is a possibility that a parameter list generated on a client will be ordered incorrectly for use on the server. For example, most programming languages utilize a stack architecture. Before a procedure is called, each parameter to the procedure to be called is placed on the stack. This works because the calling procedure and the called procedure agree on the order in which parameters will be placed on the stack. If however, the calling procedure ordered the parameters first to last and the called procedure expected that the parameters would be ordered last to first, there would almost undoubtedly be problems. In highly heterogeneous environments, this type of inconsistency, as well as other types of inconsistencies, is commonplace.
One solution to this problem is to provide clients and servers with detailed nowledge of each other. However, with this approach a primary goal of object-oriented computing—enc
724 Solutions, Inc.
Courtenay III St. John
Thompson & Knight LLP
LandOfFree
Method and apparatus using parameterized vectors for... 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 using parameterized vectors for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus using parameterized vectors for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2612100