Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-08-17
2002-07-23
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06425017
ABSTRACT:
TECHNICAL FIELD
The present invention relates to distributed component-based computer software applications, and more particularly relates to queued method invocations on such applications.
BACKGROUND OF THE INVENTION
In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a business. In these examples, the processing services provided by the server application may update databases of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations. This is sometimes referred to as client/server computing.
In a form of client/server computing sometimes known as “distributed objects,” the server application is developed as a set of components conforming to an object-oriented programming (OOP) model, such as the Microsoft Component Object Model (COM) and Distributed Component Object Model (DCOM), the IBM System Object Model (SOM), the Object Management Group's Common Object Request Broker Architecture (CORBA), and others. Object-oriented programming generally has advantages in ease of programming, extensibility, reuse of code, and integration of software from different vendors and (in some object-oriented programming models) across programming languages.
In object-oriented programming, programs are written as a collection of object classes which each model real world or abstract items by combining data to represent the item's properties with methods (e.g., program functions or procedures) to represent the item's functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance.
Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related methods of the object. In other words, the client programs do not access the object's data directly, but must instead call methods on the object's interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
In client/server computing with “distributed objects,” the client program on the user's computer typically uses “real-time” or synchronous processing mechanisms to remotely invoke methods on the server application's objects that reside on the server computer, such as the remote procedure call (“RPC”). In a typical remote procedure call, object services of the operating system compile an interface definition language description of a server application object to generate a local “proxy” for the server application object on the client computer. The client software invokes methods of the remote server application object by issuing ordinary local procedure calls directly to the proxy. The proxy, in turn, utilizes RPC services to convey the procedure call to the actual server application object on the remote server computer. The RPC services marshal values for call parameters into a network message, and send the message via network protocols to the server computer. At the server computer, the RPC services unmarshal the call parameters and issue the call to the proper server application object method. The RPC services also marshal and unmarshal return values from the server application object method back to the client program via a network message.
The RPC services thus handle all the intricacies of network communications effectively “behind the scene,” such that the client program invokes the remote method in a similar manner to making a local procedure call. Like a local procedure call, execution of the client program is suspended (also known as “blocking”) during the RPC method invocation until the method completes and returns. This results in a synchronous flow of execution among the client program and server application objects.
Although appropriate to many applications, real-time method invocation models like the RPC fail to adequately meet the needs of other applications due to a number of limitations as to availability, network transmission costs, lack of priority, object lifetime, and reference locality.
As to availability, real-time method invocation models require that the server application object is available at the time that the client program issues a call to one of the object's methods. If not available, then the real-time method invocation cannot take place. In reality however, server application objects may not be available due to network failures, or due to the server computer being overloaded with work. In some cases, the server computer may be off-line for a certain duration (e.g., due to upgrades or maintenance), or may only come on line at certain times of the day. Further, if any server application object is not available in “real time,” no part of the work (including by available server application objects) can complete. This problem is exacerbated in the case of complex operations involving multiple nodes (i.e., computers on a network). For example, a process that requires access to four independent objects on separate nodes each available about 90% of the time, is actually available only about 66% of the time (since 90%
4
=65.61%).
Additionally, some client computers are only occasionally connected to a network, and thus unable to issue real-time method invocations for a majority of the time. A good example of such occasionally connected client computers are laptops, notebooks and handheld computers of mobile users, which are estimated to now make up more than 50% of new computer purchases.
The availability requirement of the real-time method invocation model also means that the server computer(s) must be configured with sufficient capacity to handle the peak demands by interactive users of the server application. As a result, the typical system is configured with server computers that are underutilized most of the time, and are still over-utilized at other times (e.g., when actual load exceeds expectations).
For these reasons, the real-time method invocation model is not well suited to computing environments with limited availability, mobile users, large number of nodes, or high variance interactive user loads.
As to network transmission costs, each real-time method invocation via an RPC requires a round-trip network communication which imposes significant network transmission costs, such as processing time for marshaling and unmarshaling of call parameters, processing in the network protocol stack, and transmission time. Moreover, the client may need to invoke many methods of a server application component to perform useful work, thus multiplying the network transmission costs. Modern object-oriented design techniques, in particular, tend to result in many procedure calls with relatively few parameters in each call. A typical such object, for example, is designed such that a client first calls several “property set” methods to set up an operation, and then invokes a method to proc
Al-Ghosein Mohsen
Chopra Gagan
Dievendorff Richard
Helland Patrick J.
Courtenay III St. John
Klarquist & Sparkman, LLP
Microsoft Corporation
LandOfFree
Queued method invocations on distributed component applications does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Queued method invocations on distributed component applications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Queued method invocations on distributed component applications will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2874857