Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-12-18
2002-08-20
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06438616
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of Invention
The invention relates generally to methods and apparatuses for locally invoking objects in distributed object systems. More particularly, the invention relates to methods and apparatuses for efficiently enabling local object references to be created and invoked within a distributed object system.
2. Description of the Relevant Art
A computing environment in which objects are located on different computers linked by a network is typically referred to as a client-server computing environment. Some of the computers act as providers of services or functionality to other computers. The providers of service or functionality are known as “servers” and the consumers of the service or functionality are called “clients.” The client-server model may also be generalized to the case where distinct programs running on the same computer are communicating with one another through some protected mechanism and are acting as providers and consumers of services or functionality.
Attempts to provide such a distributed system have been made using object-oriented methodologies that are based upon a client-server model in which server objects provide interfaces to client objects that make requests to server objects. Typically, in such a distributed system, the servers are objects consisting of data and associated methods. The client objects obtain access to the functionalities of the server objects by executing calls on them, which calls are mediated by the distributed system. When the server object receives a call, it executes the appropriate method and transmits the result back to the client object. The client object and server object communicate through an Object Request Broker (ORB) which is used to locate the various distributed objects and to establish communications between objects. Distributed objects may exist anywhere in a network, as for example, in the address space of the client, in multiple address spaces on the client machine, and in multiple machines across the network.
The software industry has responded to the need for a distributed object technology by forming the Object Management Group (OMG). The goal of the OMG is to define the Object Management Architecture (OMA), which has four major components: the Object Request Broker (ORB), Object Services, Common Facilities, and Application Objects. The Object Request Broker provides basic object communications and management services, thereby forming the basis of a distributed object system. A standard for an Object Request Broker is contained in the Common Object Request Broker Architecture (CORBA) specification from the OMG, Revision 2.0, updated July 1996, which is incorporated herein by reference in its entirety. The CORBA specification generally defines an object model on top of a programming language, e.g., C++ or Java™ (developed by Sun Microsystems, Inc. of Palo Alto, Calif.), in which server objects have references which may be exported to clients. Within the object model, clients and servers are “roles,” and are typically not mutually exclusive tasks for a single program. Instead, a program may be both a client and a server.
Within an object-based system such as a distributed object system, a single server object may be accessed by multiple clients.
FIG. 1
a
is a diagrammatic representation of two clients which are arranged to invoke a single server object in accordance with prior art. A first client
104
is essentially a program which is running in a first process
108
. First client
104
may invoke a server object
112
that is running in a second process
116
. A non-local invocation may be performed on object
112
by first client
104
. Object
112
may be an object defined under the CORBA specification. When invoked, object
112
is arranged to service a request from first client
104
. A request from first client
104
is typically marshaled for transport to object
112
, and unmarshaled once it is received by object
112
. A second client
120
, which is within second process
116
and, hence, is in the same process as object
112
, may also invoke object
112
. An invocation on object
112
by second client
120
is a local invocation.
Since first client
104
and second client
120
are arranged such that they may invoke object
112
at substantially the same time, it is generally necessary to synchronize calls to object
112
. In other words, calls to object
112
must typically be synchronized in order to prevent threads associated with first client
104
and second client
120
from operating concurrently on object
112
. Calls to object
112
may be synchronized by object managers included within a distributed object system, as will be appreciated by those skilled in the art. Synchronization processes which are used to synchronize calls to object
112
from first client
104
and second client
120
are often expensive and time-consuming, as synchronization processes require substantial computational overhead and processing.
Object
112
may generally support a variety of different features, e.g., object
112
may create object references outside of second process
116
. In general, an object reference
124
may be created by object
112
such that object reference
124
is associated with client
104
. Reference
124
includes a pointer
126
to a client representation reference
128
which, in turn, includes a pointer to object
112
. Reference
124
is utilized by client
104
in order to invoke object
112
. As will be appreciated by those skilled in the art, reference
124
may remain constant. However, object
112
, which services client
104
, may change over time, e.g., object
112
may have a life span which is less than the life span of second process
116
. Hence, “invoking” on reference
124
may cause a new object to be created, if object
112
no longer exists. By way of example, object
112
may represent any row in a data base, and reference
124
may refer to a particular row in the data base. As such, reference
124
is essentially “bound” to an object that represents a particular row in the data base. Therefore, each time reference
124
is invoked, an associated object must generally be “looked up,” or otherwise located. Whenever the row referred to by reference
124
is referenced, a new object which represents the row is created in the event that object
112
is no longer alive.
First process
108
and second process
116
are often separated by a computer network. Since the overhead associated with network communications is often relatively high, the overhead associated with synchronizing calls to object
112
, as well as the overhead associated with locating object
112
based on reference
124
, is relatively insignificant when compared to the overhead associated with network communications.
An object within a process may also be invoked by multiple clients which are within the same process. Specifically, an object may be such that it is accessible only to clients which are within the same process, e.g., the server process, as the object. An object that is accessible only to clients within the same process may be a locality-constrained object, which is an object associated with portable object adapters (POAs) as specified in standards issued by the OMG, e.g., OMG document orbos/97-04-14, chapter
3
, which is incorporated herein by reference in its entirety. With reference to
FIG. 1
b
, the invocation of an object by clients within the same process as the object will be described in accordance with prior art. A servant object
154
is present within a process
158
, and is unable to create object references outside of process
158
. These object references are then considered to be locality-constrained, as they are bound to the process that created them. A number of clients
162
, each of which has an associated object reference (not shown) relating to object
154
, within process
158
may simultaneously attempt to invoke object
154
.
When client
162
a
invokes object
154
, invocation requests associated with client
162
Callsen Christian J.
Cavanaugh Ken M.
Beyer Weaver & Thomas LLP
Bullock, Jr. Lewis A.
Courtenay III St. John
Sun Microsystems Inc.
LandOfFree
Method and apparatus for fast, local corba object references 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 fast, local corba object references, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for fast, local corba object references will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2897292