Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-04-30
2002-03-05
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06353859
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates in general to the data processing field. More specifically, the present invention relates to the field of object-oriented programming techniques and mechanisms in a distributed object environment.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time computers have become indispensable in many fields of human endeavor including engineering design, machine and process control, and information storage and access. In the early days of computers, companies such as banks, industry, and the government would purchase a single computer which satisfied their needs, but by the early 1950's many companies had multiple computers and the need to move data from one computer to another became apparent. At this time computer networks began being developed to allow computers to work together.
Computer networks are capable of performing jobs that no single computer could perform and they allow low cost personal computer systems to connect to larger systems to perform tasks that such low cost systems could not perform alone. In order for computer systems to cooperate in a network to perform some complex job, software must be developed which efficiently delegates parts of the chore or tasks to different computers in the network. One of the recent advances in the field of software development has been the emergence of object oriented programming technology.
The goal of using object-oriented programming is to create small, reusable sections of program code known as objects that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a group of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
Typically, object-oriented (OO) processes within object-oriented software programs create and use objects to accomplish the required or desired goals of the program. A typical OO software process creates an object or group of objects which are accessible by other objects within that process. Sometimes one object in one process may need to access another object in a different process. OO processes may reside in a number of different locations in a networked computing environment. For example, two processes may reside on the same computer system, or they may reside on different computer systems that are geographically remote from each other and coupled by a communication link. When objects are distributed in different processes and need to intercommunicate with each other, this environment is known as a distributed object environment. A distributed object environment, as used herein, means any hardware and software configuration and/or combination that allows an object in a first process to access an object in a second process. Examples of known distributed object systems include: 1) a first process and a second process residing on the same computer; 2) a first process and a second processes residing on different computer workstations in a local area network (LAN); and 3) a first process and a second process residing on computers in geographically remote locations that are interconnected using a wide area network (WAN). As technology progresses, other distributed object systems will, no doubt, be developed, and the present invention expressly encompasses all types of distributed object systems, whether now known or developed in the future.
When a process creates an object, the process is the “home” location of the object. When a process needs to access an object that it did not create, it must either access the object in its home location, or it must access a copy of the object within its own process. Access to an object in its home location by a different process is accomplished by creating a proxy object within the different process that references the object in its home location. The proxy is instantiated as a member of a class that supports the same interface as the object for which it is a proxy, but the methods on the proxy object simply call the methods on the object that exists in the other process. An access to an object by invoking methods on a proxy object that, in turn, invokes remote method calls to the real object in its home location is known as “home access”.
The speed of an access to a remote object may be enhanced by copying the remote object to the local process. An access to a copy of an object by invoking methods on a local copy of the object is known as “local access”. However, copying objects gives rise to the issue of data integrity between the different copies of the objects.
Data integrity is a difficult problem in distributed object systems that allow multiple copies of the same object to exist. If the data in one object in its home location is changed and the data in a copy of the same object is changed by a local process, it may be impossible to reconcile the differences between the home object and the local copy. This problem is most often solved by locking certain parts of the object and allocating access to only one copy of an object at a time. This solution requires significant resources and complexity in controlling the data locking, and also creates new problems. For example, any changes to a local copy of an object must be propagated back to the home copy. Another problem is the latency that results from an object waiting to access an object that is locked by another object. In addition, when an object is accessed, any subsequent accesses to that object must access the same object to assure the integrity of the data in the object across the entire transaction. Without a mechanism for allowing more efficient accesses to distributed objects, the computer industry will never fully realize the benefits of object-oriented programs in distributed object environments.
DISCLOSURE OF INVENTION
According to the present invention, an access mechanism and method for accessing objects in a distributed object system manages object accesses and causes all accesses within one transaction to be to either the home object or the local copy, whichever is accessed first. When an object is accessed for the first time in a given transaction, the requested access is granted. For example, if home access is requested to an object in a different process, a proxy is created to access the object in its home location. When the object is subsequently accessed within the same transaction, the access mechanism ensures that the same access is used to assure that changes are not being made to a home object and a local copy or to more than one local copy simultaneously. In an alternative embodiment an exception may be generated if the requested access cannot be provided.
REFERENCES:
patent: 5488723 (1996-01-01), Baradel et al.
patent: 5560005 (1996-09-01), Hoover et al.
patent: 5644771 (1997-07-01), Endicott et al.
patent: 5734902 (1998-03-01), Atkins et al.
patent: 5787280 (1998-07-01), Joseph et al.
“Life Cycle Services Specification”, OMG TC Document 93.7.4, pp. 1-21, Jul. 1993.*
“SOMobjects Developer Toolkit: Users Guide”, IBM, chapter 9 pp. 1-24, Jun. 1993.*
Stevenson et al., “Client-Server Interactions in Multi-Server Operating Systems: The Mach-US Approach”, School of Computer Science Carnegie Mellon University, pp. 1-15, Sep. 1994.*
Object Management Group, “CORBA Security Draft”, OMG Document No. 95-9-1, p. 166, Sep. 1995.*
Julin, “Naming Facilities for Operating System Emulation in Mach 3.0”, School of Computer Science, Carnegie Mellon University, pp. 1 and 3.*
Object Management Group, “ORB Interoperability”, OMG Document No. 94-3-3, p. 20, Mar. 1994.*
Triantafillou et al., “Multiclass Replicated Data Mangement: Exploiting Replication
McKeehan Michael D.
Tost Andre
Voldal Erik E.
Courtenay III St. John
Fourson Gary Scott
Martin Derek P.
Martin & Associates LLC
LandOfFree
Object-oriented apparatus and method for controlling... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Object-oriented apparatus and method for controlling..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object-oriented apparatus and method for controlling... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2877553