Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-04-21
2001-05-29
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06240466
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.
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, computer systems have evolved into extremely sophisticated devices. Modem computer systems contain relatively complex software that the computer hardware executes in order for the computer system to perform its intended functions. As the complexity of computer hardware and software increases, the need to efficiently and effectively develop new software becomes more acute. Software development costs have continued to rise because complex programs take more time, and hence more money, to produce. Object-oriented programming is one way computer programmers have sought to reduce the time and costs associated with developing complex software.
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 reusable 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 software programs or processes create and use objects to accomplish the required or desired goals of the application software. Most software processes will create an object or group of objects and then use those objects during the lifetime of that particular process. Whenever a new object is to be created in an object-oriented environment, the new object may be created in a location specified explicitly by the system designer. Alternatively, new objects may simply be created in a default physical memory location specified by the system. While this may work reasonably well for some systems and object-oriented processes, it may occasionally lead to some notable system performance and system security problems. Certain objects have an “object affinity” with other objects. This means that in a given system, certain objects tend to be used together and with each other. Therefore, if the objects can be created in the same physical location, the overall system will typically perform better.
The location of related objects becomes an even more important issue in distributed object systems. A distributed object system is a system that has two or more objects in different locations that may communicate with each other. These objects may be in processes running on two completely separate computer systems or may be in different processes running on the same computer system. If a first object, located on a given system (e.g. computer) needs to frequently reference a second object that is located on a different system which is located in a geographically remote location, communication time between the two objects can be greatly and unnecessarily increased because there is a certain amount of communication overhead in every system-to-system communication environment.
Another problem with having objects located on disparate systems is highlighted by examining computer system security concerns. In general, different computer systems will have very different security requirements and capabilities. For example, one computer system server may store data objects in a relational data base which is carefully secured by a system administrator. In this type of system, only certain users have access to the data objects in the data base. In a second system, the server may store data objects in a file system which is accessible to all users of the system. If two separate objects are located on these different systems, it will be necessary to navigate the intricacies of multiple security systems with varying access requirements. This additional overhead will typically increase processing time and decrease system performance. If, on the other hand, all of the objects were located in the same physical memory location, only one security system must be navigated to gain access to all of the objects.
Finally, without regard to system security restrictions, access and availability of system resources can vary greatly from system to system. Some systems and system resources are unavailable for certain periods of time due to system administration procedures and requirements. This means that certain objects located on remote systems may be unavailable to another system due to system level administration requirements such as backup or recovery procedures. The more systems involved in a given processing scenario, the more likely it is that one or more of the systems may be unavailable at any given moment. This may introduce unnecessary delays into the processing model because the first object may have to wait for the second object, which is located on a different system, to become available. If, on the other hand, both objects are located on the same system, then both objects will generally be available to each other at the same time.
Almost all object-oriented software applications will perform better if the objects that are used together are stored “near” each other. It the examples described above, where object affinity exists, it would generally be preferable to create a first object “near” the second object so as to allow more efficient communication. While the desirability of storing objects with object affinity in the same location may be demonstrated, there is presently no efficient or effective way of accomplishing this goal.
As both the complexity and the frequency of communication and transaction processing over networked computer systems increases, the need for better ways of creating and managing objects in object-oriented systems becomes more apparent and more acute. This is especially true as more and more computers are connected by networks such as the World Wide Web and share information across different computer systems. Without a mechanism for creating objects in a way that further reduces operational overhead and logistical performance problems, the computer industry will never fully realize the benefits of object-oriented programming environments.
DISCLOSURE OF INVENTION
According to the present invention, a method for creating new objects “near” existing objects is disclosed. In a preferred embodiment of the present invention, a desirable location for the new object is determined by making a series of observations and system level decisions. By examining the system parameters and creating new objects in physical locations where other, related objects currently reside, system performance in object-oriented systems can be greatly increased.
REFERENCES:
patent: 5379423 (1995-01-01), Mutoh et al.
patent: 5459860 (1995-10-01), Burnett et al.
patent: 5475817 (1995-12-01), Waldo et al.
patent: 5481718 (1996-01-01), Ryu et al.
patent: 5535134 (1996-07-01), Cohn et al.
patent: 5560012 (1996-09-01), Ryu et al.
patent: 5566302 (1996-10-01), Khalidi et al.
patent: 5577251 (1996-11-01), Hamilton et al.
patent: 5590327 (1996-12-01), Biliris et al.
patent: 5604892 (1997-02-01), Nuttall et al.
patent: 5727147 (1998-03-01), Van Hoff
patent: 5761513 (1998-06-01), Yellin et al.
patent: 5787438 (1998-07-01), Cink et al.
unknown, SOMobjects Developer's Toolkit Programmer's Guide, vol. 1: SOM and DSOM, IBM corporation, pp. 91-95, 245-249, 272-275, and 302, Dec. 1996.*
unknown, “The Component Object Model Specification Version 0.9”, Microsoft Corporation, pp. 95-97, Oct. 1995.*
“Joint Object Services Submission: Life Cycle Services Specification”, OMG TC Document 93.7.4, pp. 1-50, Jul. 1993.*
Standard ECMA-149, “Portable Common Tool Environ
McKeehan Michael D.
Munroe Steven J.
Voldal Erik E.
Courtenay III St. John
Fourson Gary Scott
International Business Machines - Corporation
Martin Derek P.
Schmeiser Olsen & Watts LLP
LandOfFree
Object-oriented apparatus and method for determining new... 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 determining new..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object-oriented apparatus and method for determining new... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2568256