Method of determining the timing for reclaiming a remote object

Details Method of determining the timing for reclaiming a remote object Method of determining the timing for reclaiming a remote object

1998-11-25

2003-03-18

Courtenay, III, St. John (Department: 2151)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

Reexamination Certificate

active

06535928

ABSTRACT:

TECHNICAL FIELD OF THE INVENTION
This invention is related in general to the field of object-oriented technologies and distributed computing. More particularly, the invention is related to a method of determining the timing for reclaiming a remote object.
BACKGROUND OF THE INVENTION
In object-oriented programming, real world objects are modeled by software objects that have encapsulated therein special procedures and data elements. In object-oriented programming jargon, procedures are referred to as methods. To avoid having to redefine the same methods and data members for each and every occurrence of an object, object-oriented programming provides the concept of classes. An inheritance structure of one or more levels of increasingly more specialized classes is created to provide templates that define the methods and variables to be included in the objects of each class. Therefore, an object belonging to a class is a member of that class, and contains the special behavior defined by the class. In this manner, each object is an instance of a defined class or template and the need to redefine the methods and data members for each occurrence of the object is eliminated.
With the rise of distributed systems, client/server computing, and internet/intranet interactions, inter-node communications between applications have become a prerequisite. Early operating systems lacked support for inter-application communications, forcing software developers to write custom code to perform remote procedure call (RPC) for each and every application that needed remote communications.
Microsoft™ has developed DCOMT™ (Distributed COM) to support inter-application communications across networked computer systems. Another technology standard for inter-object communications is CORBA™ (Common Object Request Broker Architecture) established by the Object Management Group (OMG) sponsored by more than 660 companies, including Digital Equipment Corporation™, Hewlett Packard™, IBM™, and Sun Microsystems, Inc™. CORBA defines how messages from one object to another are to be formatted and how to guarantee delivery. The messaging in CORBA is performed by object request brokers (ORBs). ORBs receive messages to determine the location of the receiving object, route the message, and perform all necessary platform and language translations. In object technology, a message is typically a request sent to an object to change its state or return a value. The object has encapsulated methods to implement the response to the received messages. Through technologies such as DCOM™ and CORBA™, objects can communicate with remote objects residing in other computer platforms connected by a network. However, a serious drawback of these objects under the conventional ORB technology is that they do not support the concept of mobility and therefore cannot move around the network to other computer platforms.
Enter the concept of agents. Agents are defined as specialized objects that possess the characteristic of autonomy. Autonomy is the ability to program an agent with one or more goals that it will attempt to satisfy, even when it has moved into a network onto other platforms and has lost all contact with its creator. General Magic, Inc.™ of Sunnyvale, Calif. has developed a set of interpreted object-oriented computer instructions called Telescript™. By using Telescript™ computer instructions, an agent may move from one place to another place by specifying the destination address, name, and/or class. However in Telescript™, agents cannot communicate remotely across the network. In other words, Telescript agents must occupy the same place in order for them to interact. Further, in order for two agents to interact, they must travel to a pre-established place known to both agents. This presents some very serious restrictions to the ability for agents to communicate with one another.
Another agent technology called Aglets™ has been introduced by IBM™. A significant difference between Aglets™ and Telescript™ is that Aglets is based on Java™, Sun Microsystems Inc.'s computer programming language. Although Aglets™ allows agent movement across the network, the destination must be a pre-established place known to the agent as in Telescript™. Further, Aglets™ agents also may not communicate remotely across the network with regular Java method invocation syntax. Again, these serious restrictions make Aglets™ very inflexible in inter-agent communications.
SUMMARY OF THE INVENTION
Accordingly, there is a need for explicitly specifying a lifespan property for an object or agent and to provide a way to dynamically alter its lifespan.
In accordance with the present invention, a method of determining the timing of reclaiming a remote object is provided which eliminates or substantially reduces the disadvantages associated with prior ORB and agent technologies.
In one aspect of the invention, a method for determining the timing for reclaiming a remote object according to the teachings of the present invention includes the step of first creating a remote object of a virtual object. The remote object has a default death criteria. The virtual object may send a lifespan message to change the death criteria of the remote object to the remote object. The remote object is reclaimed in response to the death criteria being met.
In yet another aspect of the invention, the lifespan message may be a liveForever message that prevents the remote object from being reclaimed for an indefinite amount of time; a dieAt(time) message that allows the remote object to be reclaimed when the current time is equal to the time parameter in the message; a dieAfter(time) message that allows the remote object to be reclaimed when the elapsed time since the receipt of the remote object is greater than the time parameter in the message; and a dieIfQuietFor(internal) message that allows the remote object to be reclaimed when the remote object has not received any messages for a period greater than the interval parameter of the message.
In another aspect of the invention, a method for determining the timing for reclaiming a remote object includes the step of creating a remote object of a virtual object, initializing a last-message-time variable for the virtual object to a current time, and also initializing a last-message-time variable for the remote object to the current time. Further, a pulse variable of the virtual object is initialized to a predetermined value, and a time-to-die variable of the remote object is initialized to the same predetermined value. The virtual object's last-message-time variable is reset to the current time every time the virtual object sends a message to the remote object. The virtual object's last-message-time variable is periodically compared with the pulse variable. If the last-message-time variable is greater than the pulse variable, a heartbeat is sent to the remote object, and the remote object's last-message-time variable is reset to the current time every time the remote object receives a message or a hearbeat. The remote object's time-to-die value is periodically compared with the last-message-time variable, and the remote object is reclaimed in response to the elapsed time since the last-message-time variable being greater than the time-to-die variable.


REFERENCES:
patent: 5341478 (1994-08-01), Travis et al.
patent: 5432924 (1995-07-01), D'Souza et al.
patent: 5603031 (1997-02-01), White et al.
patent: 6026415 (2000-02-01), Garst et al.
patent: 6138251 (2000-10-01), Murphy et al.
(no author given), “Life Cycle Service Specification”,CORBA Object Services Specification, Chp. 6, OMG, http://cgi.omg.org/docs/formal/97-02-11.pdf, pp. 6-1 through 6-62, Feb. 11, 1997.

Affiliated with

Also associated with

Rating

Method of determining the timing for reclaiming a remote object 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 of determining the timing for reclaiming a remote object, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of determining the timing for reclaiming a remote object will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3036828