Methods and apparatus for managing collections of objects

Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

Reexamination Certificate

active

06353860

ABSTRACT:

BACKGROUND OF THE INVENTION
The present invention relates to the fields of distributed computing systems, client-server computing and object-oriented programming. More specifically, the present invention teaches methods, apparatus and data structures for managing collections of related objects.
Object oriented programming methodologies have received increasing attention over the past several years in response to the increasing tendency for software developed using traditional programming methods to be delivered late and over budget. This stems from the fact that traditional programming techniques that emphasize procedural models and “linear” code tend to be difficult to design and maintain in many circumstances. Generally, large programs created using traditional methods are “brittle”. That is, even small changes can effect numerous elements of the programming code. Thus, minor changes made to the software in response to user demands can require major redesign and rewriting of the entire program.
Object oriented programming strategies tend to avoid these problems because object methodologies focus on manipulating data rather than procedures; thus providing the programmer with a more intuitive approach to modeling real world problems. In addition objects encapsulate related data and procedures so as to hide that information from the remainder of the program by allowing access to the data and procedures only through the object's interface. Hence changes to the data and or procedures of the object are relatively isolated from the remainder of the program. This provides code that is more easily maintained as compared to code written using traditional methods, as changes to an object's code do not affect the code in the other objects. In addition, the inherent modular nature of objects allows individual objects to be reused in different programs. Thus, programmers can develop libraries of “tried and true” objects that can be used over and over again in different applications. This increases software reliability while decreasing development time, as reliable programming code may be used repeatedly.
However, the full promise of object oriented methodologies, especially the advantages afforded by their modularity, have yet to be achieved. A basic goal of modular systems is to provide efficient utilization of resources, yet, due to the modularity of objects, there exists an inherent potential for redundant resources and overlap in functionality. As a first example, imagine a scenario wherein two text objects (e.g. word processing documents) contain similar or identical data such as text formatting information or portions of the actual text. In this first commonplace example there is an inherent redundancy as separate objects contain identical portions of data.
In order to present additional example of the disadvantages of current distributed object operating environments, some further background discussion will now be presented. In general, distributed objects are resident in computer processes executing on computer systems. As is well known to those skilled in the art, computer processes provide a common framework under which computer systems function. By way of analogy, a computer process may be thought of as a domain within a computer system.
In actuality, a computer process typically includes an address space (i.e. a portion of memory allocated to only the process), a set of file descriptors, a process identification number, and one or more threads of execution (often referred to as threads). As is familiar to those skilled in the art, a single thread of execution is essentially a sequential flow of the point of execution through a process. Multi-threaded systems allow for multiple threads to run concurrently in a single process. For a more detailed description of threads, multithreaded processes, and principles of concurrency, please see “Concurrency Within DOE Object Implementations” by Dr. Robert Hagmann, Version 0.91, May 27, 1993, published by SunSoft and incorporated herein by reference in its entirety. For another detailed description, please see “Multithreaded Programming Guide” published 1994 by SunSoft and incorporated herein by reference in its entirety.
As a direct result of the framework of computer processes, all entities residing under a single process will share resources (i.e. memory and files). Thus multiple target objects residing in a single process will have efficient communication with one another.
Furthermore, data can be loaded into memory that all objects residing in the single process will have access to. However, programmers may have other motivations (beyond efficient transport and data sharing) which negate the advantages gained by having many objects in a single process. For instance, different objects will have different objectives and may rely on different assumptions about the process. Programmers must be able to keep objects within separate processes, thereby preventing conflict between and maintaining the integrity of objects within separate processes. As a case in point, an object in a first server process may go into an error condition and begin chaotically writing within its server process memory. Nevertheless, objects running in separate server processes will remain intact since these processes have their own memory, files, and flow control. These motivations generate a need for orderly, multi-process distributed object operating environments. Ideally there should be a mechanism by which programmers can determine the process within which their specific object will reside.
As is well known those skilled in the art, objects must be activated within their host process prior to serving clients. In addition, a first server object responding to the call of a first client will often in turn call a second server object which may in turn call a third server object (and so on). Thus multiple objects may be activated in response to a single call. If it is known a priori that this is the case, a mechanism which enabled multiple object activations in response to a single call may decrease the overhead associated with multiple single instance object activations. However, in current distributed object frameworks, there is no such mechanism.
While some of the abovementioned inefficiency could be eliminated within existing frameworks, the optimization of resources within current distributed systems often comes only at the expense of great programming effort. This is, in effect, antithetical to other goals of distributed object systems. Efforts to further extend the advantages of object oriented programming techniques must be directed towards improving efficiency in the utilization of all resources, including memory, processing power, and network bandwidth. What is needed is a straight forward framework in which the potential for overlap, redundancy, and unnecessary overhead within distributed objects can be easily eliminated. This will require a distributed object having a structure which will allow for a different, more efficient utilization of resources, including the capability to associate collections of objects based upon the resources which these objects share. Moreover, effective methods for managing these collections of objects will be required.
SUMMARY OF THE INVENTION
To achieve the foregoing and other objectives and in accordance with the purpose of the present invention, methods, apparatus and data structures for managing collections of objects are described. In one aspect of the invention, an object that is intended for use in a distributed object operating environment has a structure including a group designation, a coactivation designation and a co-process designation. The group designation is arranged to identify a group to which the object belongs. The group is defined as a collection of objects which share a common persistent state. The co-activation designation is arranged to identify a co-activation set to which the object belongs. The co-activation set is a collection of objects which are to be activated at the same time. The co

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Methods and apparatus for managing collections of objects does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Methods and apparatus for managing collections of objects, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and apparatus for managing collections of objects will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2860145

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.