Electrical computers and digital processing systems: multicomput – Distributed data processing – Processing agent
Reexamination Certificate
1997-11-13
2001-05-15
Dinh, Dung C. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Processing agent
Reexamination Certificate
active
06233601
ABSTRACT:
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
Not applicable
BACKGROUND OF THE INVENTION
The present invention is generally related to network computing, and more particularly to mobile objects.
Mobile objects that are transmitted across a computer network are known. Mobile objects are comprised of code and data, both of which are transmitted across the computer network. Technologies such as client-server protocols, remote procedure call protocols, and distributed object technologies are employed to transmit mobile objects across the computer network. These technologies implement either a “push” model or a “pull” model, both of which have drawbacks.
In a “pull” model the code for an executing object is downloaded from a network source such as a web server. When a particular portion of code becomes necessary for operation, that portion of code is first sought on the local filesystem. If the local filesystem does not include that portion of the code, a network request is sent to another computer in the network in order to prompt transmission of that portion of code to the local computer. However, as different classes of sub-objects are created, a separate network request must be sent to retrieve code for each class. In the case of a Hyper-Text Transfer Protocol (“HTTP”) request, each request must re-establish a Transmission Control Protocol/Internet Protocol (“TCP/IP”) socket connection to the web server. Thus, when downloading a large number of classes, a large number of connections must be established and a large amount of network overhead is incurred.
Another drawback associated with the pull model is that as an object travels, the code which enables the object to operate must be re-downloaded at each computer. More particularly, when the object arrives at each a destination computer, the object downloads any code which is required but not present on the local filesystem, even if that code was downloaded at the previous destination computer. Previously downloaded code is not cached. Network overhead is incurred as a consequence.
In a “push” model the code for an executing object is carried with the mobile object. Prior to launching the mobile object, all of the code that will be needed by the object is identified. The code is packaged with the agent and pushed around the network to each destination computer. While the push model reduces network requests in comparison with the pull model, network overhead is still incurred because of the relatively large amount of code that is pushed to every destination computer. In some cases the object will push code for classes that are no longer needed. For example, an agent may create an instance of a particular class of object only in very exceptional circumstances. In such a case it is inefficient for the object to push the code for this class.
Another limitation of known mobile objects is difficulty in examining and predicting destination information. Known mobile objects initiate travel by performing a subroutine call. The method is sometimes given a name such as “go” or “moveTo,” and the caller is responsible for specifying a name or Uniform Resource Locator (“URL”) indicating the destination computer for the mobile object. When the travel method is called, the execution of the mobile object is halted and the mobile object is converted into a network transmittable form. On the destination computer the mobile object is restored from the network form and restarted. This restart can either occur on the instruction directly following the call to the travel method, or at the beginning of some known method.
BRIEF SUMMARY OF THE INVENTION
In order to provide efficient mobility of code for a mobile agent object (“agent”), a “mobile codebase” object is constructed. The mobile codebase travels with the agent and serves as a repository of code for classes that facilitate agent operation. When the agent is launched, the launcher specifies a list of related classes. These classes are retained in the mobile codebase. The launcher also specifies a Uniform Resource Locator (“URL”) that points to a network source (“home codebase”) from which code can be downloaded. If the agent is required to instantiate an object comprising code that is not in the mobile codebase, a network request is sent to the home codebase to retrieve that code. Code that is downloaded in this manner is retained in the mobile codebase.
The combination of the mobile codebase and home codebase improve agent operation and reduce network overhead. In a preferred embodiment an agent is launched with a mobile codebase that is preloaded with classes which are certain to be needed. Classes that are unlikely to be needed are stored in the home codebase. Thus the agent with mobile codebase and home codebase provide the desirable features of the push and pull models without the undesirable network overhead incurred by transmitting unneeded classes around the network or re-downloading code.
Agent travels are defined by an itinerary data structure. The itinerary is composed of a list of destinations, each of which includes: (1) the hostname of a destination computer on the network to which the agent should travel, and (2) the name of a method that the agent should execute when the agent arrives at the destination computer. An agent is allowed to modify its itinerary. When an agent modifies its itinerary, the agent owner is automatically notified, thus allowing the owner to “follow” the agent wherever it may travel.
The itinerary provides advantages related to agent and network management. Inspection of the agent itinerary reveals where the agent has travelled and where the agent may travel in the future. Since the itinerary is a standard data structure, an observer ran depend on it to be present. Further, since the itinerary is a separate data structure from the agent, the observer does not need special knowledge of the internal structure of the agent in order to examine the itinerary.
REFERENCES:
patent: 5701484 (1997-12-01), Artsy
Joosen et al. “On Flexible Support for Mobile Objects”, IEEE proceedings of IWOOOS 1996. pp.3-7.*
Aglets Specification (1.0), Version 0.60, May 20, 1997.*
Chess et al. “Itinerant Agents for Mobile Computing” IBM Research Report RC 200010 (Mar. 27, 1995).*
Lawton “Agents to roam the Internet”, SunWorld, Oct. 1996. (http://www.sunworld.com/sunworldonline/swol-10-1996/swol-10-agent_p.html).*
Tim Finin, “Mobile Agents—UMBC AgentWeb”, http:www.cs.umbc.edu/agents/mobile/.*
George Lawton, “Agents to roam the Internet,” SunWorld, Oct. 1996. http://www.sunworld.com/sunworldonline/swol-10-1996/swol-10-agent_p. html.*
Danny B. Lange and Yariv Aridor, “Agent Transfer Protocol—ATP/0.1”, IBM Tokyo Research Laboratory, Mar. 19, 1997. http://www/trl.ibm.co.jp/aglets/atp.htm.*
Weiyi Li and David G. Messerschmitt, “Java-To-Go—Intinerative computing Using Java,” Sep. 10, 1996. http://ptolemy.eecs.berkeley.edu/dgm/javatools/java-to-go/.
Brinkman Dirk
Dinh Dung C.
Mitsubishi Electric Research Laboratories Inc.
LandOfFree
Itinerary based agent mobility including mobility of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Itinerary based agent mobility including mobility of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Itinerary based agent mobility including mobility of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2516756