Sunteți pe pagina 1din 8

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)

Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856

Aglets(A Java Based Mobile Agent) And Its Security Issue.


Mr. Rajesh Pandey, Mr. Nidheesh Sharma, Mr. Ramratan Rathore
DR.K.N.MODI INST. OF ENGG. & TECH. MODINAGAR, GHAZIABAD, U.P., INDIA

Abstract : Java offers some inimitable capabilities that are


facilitating the development of mobile agent systems This paper throws light on the mobile agents especially aglets(java based mobile agent), an promising technology that makes it very much easier to design, implement, and maintain distributed systems. Aglets lessen the network traffic, provide an effective means of overcoming network latency, and perhaps most importantly, through their ability to operate asynchronously and autonomously of the process that created them, helps to construct more robust and fault-tolerant. This paper illustrates the technical overview of aglets and their life-cycle. Mobile-agent systems, such as aglets, require high levels of security, because they represent yet another way to transmit a malicious program. This paper discusses various security issues specific to a mobile agent system, possible attacks on aglets and a security model for aglets. Also the potential applications of aglets and reasons for aglet paradigm applicability in multitude scenario is discussed.

1. Introduction
Major existing paradigms for building distributed applications can be classified into two groups. Examples of the first class include traditional RPC and most recently its object cousins RMI and COBRA. For this class of paradigms, functionality of applications are partitioned among participating nodes. Different participants use message-passing to coordinate distributed computation. For the second class of paradigms, namely Agent, computation is migrated toward resources. This type of paradigm is especially useful for applications requesting immediate reaction to incoming streams of real-time data and distributed applications. Aglet is a java-based internet agent. Aglets was originally developed by Mitsuro Oshima and Danny Lange at the IBM Tokyo Research Laboratory. The original name of the project was AWB (Aglets Work Bench) and IBM was responsible for most of the 1.x release. We can use a few phrases to characterize an Aglet: written in pure java, light-weight object migration , built with persistent support, event-driven. The term aglet is indeed a portmanteau word combining agent and applet. Like an applet, the class files for an aglet can migrate across a network. But unlike applets, when an aglet migrates it also carries its state. An applet is code that can move across a network from a server to a client. An aglet is a running Java program (code and state) that can move from Volume 2, Issue 4 July August 2013

one host to another on a network. In addition, because an aglet carries its state wherever it goes, it can travel sequentially to many destinations on a network, including eventually returning back to its original host. The key abstractions needed to leverage mobile agent technology in Internet like open wide-area networks areProxy, Context, Future Reply, Identifier etc are discussed in the coming sections. Java VM doesn't allow to marshal the stack frame of a Thread object. It is impossible to migrate a Thread object to a remote host or to save it to secondary storage while preserving its execution state. Instead, Aglets uses an event model to give programmers a chance to implement an action that emulates the migration. The transport layer is responsible for transporting an agent to the destination in the form of a byte stream that contains class definitions as well as the serialized state of the agent. This paper discusses various facets of aglet computing paradigm that encompasses its technical overview, the communication protocol used for transfer and the security concerns related to aglets.

2. Mobile Agent
Mobile Agent is commonly defined as an independent software program which runs on behalf of a network user. An agent may run when the user is disconnected from the network, even involuntarily and can travel to multiple locations in the network. This mobility greatly enhances the productivity of each computing element in the network and creates a uniquely powerful computing environment well suited to a number of tasks. 2.1Definition of an Agent (End-User Perspective) An agent is a program that assists people and acts on their behalf. Agents function by allowing people to delegate work to them. 2.2 Definition of an Agent (System Perspective) An agent is a software object that is situated within an execution environment; possesses the following mandatory properties: Reactive - senses changes in the environment and acts accordingly to those changes. Autonomous - has control over its own actions. Goal driven - is pro-active; Temporally continuous - is continuously executing Page 107

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856
Agent may possess any of the following orthogonal properties: Communicative -able to communicate with other agents; Mobile - can travel from one host to another; Learning - adapts in accordance with previous experience; Believable - appears believable to the end-user.
Host Context Context Context

Server Process (Engine)

3. Overview of Aglets
Aglet is a java-based autonomous software agent. Major buzzwords that can be used to characterize an Aglet are written in pure java, light-weight object migration , built with persistent support, event-driven.It visits local and remote hosts, and reacts to events and messages.The Java aglet extends the model of network-mobile code made famous by Java applets. An aglet requires a host Java application, an aglet host, to be running on a computer before it can visit that computer. When aglets travel across a network, they migrate from one aglet host to another. Each aglet host installs a security manager to enforce restrictions on the activities of untrusted aglets. Hosts upload aglets through class loaders that know how to retrieve the class files and state of an aglet from a remote aglet host. The Java Aglet Application Programming Interface (JAAPI) is a standard for interfacing aglets and their environment. J-AAPI defines the methods necessary for aglet creation, message handling in the aglet, initialization, dispatching, retraction,deactivation/activation,cloning,and disposing of the aglet.
Network

Figure 1 Major classes and Interfaces of Aglets A proxy is a representative of an aglet. It serves as a shield for the aglet that protects the aglet from direct access to its public methods. A context is an aglet's workplace. It is a stationary object that provides a means for maintaining and managing running aglets in a uniform execution environment where the host system is secured against malicious aglets. A message is an object exchanged between aglets.It allows for synchronous as well as asynchronous message passing between aglets. It is an aglet's travel plan. It provides a convenient abstraction for non-trivial travel patterns and routing. An identifier is bound to each aglet. This identifier is globally unique and immutable throughout the lifetime of the aglet.

Figure 2 Relationship between Host,Server and Context 3.1 Life-Cycle of Aglets Basic operations that govern the life cycle of aglets are-: Creation- The creation of an aglet takes place in a context. The new aglet is assigned an identifier, inserted into the context, and initialized. The aglet starts executing as soon as it has been successfully initialized. Cloning- The cloning of an aglet produces an almost identical copy of the original aglet in the same context. The only differences are the assigned identifier and the fact that execution restarts in the new aglet. Note that execution threads are not cloned. Dispatching- Dispatching an aglet from one context to another will remove it from its current context and insert it into the destination context, where it will restart execution (execution threads do not migrate). We say that the aglet has been pushed to its new context. Retraction- The retraction of an aglet will pull (remove) it from its current context and insert it into the context from which the retraction was requested. Activation and deactivation- The deactivation of an aglet is the ability to temporarily halt its execution and store its state in secondary storage. Activation of an aglet will restore it in a context. Disposal- The disposal of an aglet will halt its current execution and remove it from its current context. Messaging- Messaging between aglets involves sending, receiving, and handling messages synchronously as well as asynchronously.

Figure 3 Life-Cycle of Aglets An aglet occupies the aglet context and can move from this context to others during its execution. Because the runtime system may serve multiple contexts within one Java VM, these contexts can be in the same VM. Dispatching causes an aglet to suspend its execution, serialize its internal state and bytecode into the standard Page 108

Volume 2, Issue 4 July August 2013

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856
form and then to be transported to the destination. On the receiver side, the Java object is reconstructed according to the data received from the origin, and a new thread is assigned and executed. Aglets support persistency of aglet objects. All mobile aglet objects can be persistent in nature, because they must be convertable into a bit-stream; consequently, this stream can be stored in secondary storage. 3.2 Aglets Event and Event Delegation Model Java VM doesn't allow to marshal the stack frame of a Thread object. It is impossible to migrate a Thread object to a remote host or to save it to secondary storage while preserving its execution state. Instead, Aglets uses an event model to give programmers a chance to implement an action that emulates the migration. When an aglet dispatches, the Aglet runtime system issues the corresponding event to notify that it is being dispatched, or it is arriving at the destination.The model allows the programmer to "plug in" customized listeners into an aglet. Listeners will catch particular events in the lifecycle of an aglet and allow the programmer to take action when the aglet is being dispatched. Three kinds of listener exist: Clone Listener- Listens for cloning events. One can customize this listener to take specific actions when an aglet is about to be cloned, when the clone is actually created, and after the cloning has taken place. Mobility Listener- Listens for mobility events. One can use this listener to take action when an aglet is about to be dispatched to another context, when it is about to be retracted from a context, and when it actually arrives in a new context. Persistence Listener- Listens for persistent events. This listener allows the programmer to take action when an aglet is about to be deactivated and after it has been activated. An aglet programmer can implement an action that should be taken in response to these events (dispatch, for instance) regardless of when or by whom an aglet is dispatched.
Clone Events

serialization touches only data on the heap, not the stacks or the program counters. Thus when an aglet is dispatched, cloned, or deactivated, any relevant state sitting on any stack of a running aglet, as well as the current program counter for any thread, is lost. This feature of aglets arises out of the architecture of the JVM, which doesn't allow a program to directly access and manipulate execution stacks. This is part of the JVM's built-in security model. Therefore, before it is serialized, an aglet must place on the heap everything it will need to know to be resurrected properly as a newly activated aglet, a freshly dispatched aglet, or a clone. It can't leave any of this information on the stack, because the stacks won't be reproduced in the aglet's new life. As a result, the aglet host informs an aglet that it is about to be serialized so that the aglet can prepare itself. When the aglet is informed of an impending serialization, it must place onto the heap any information it will need to continue its execution properly when it is resurrected. 3.4 Interaction between aglet and host An aglet interacts with its environment (its aglet host) through an AgletContext object. An aglet can obtain a handle to its context by invoking getAgletContext(), a method it inherits from base class Aglet. The aglet context has methods such as createAglet() and retractAglet(), which allow an aglet to add new aglets (or get an old aglet back) to its local host.

3.5 Interaction between aglets To interact with each other, aglets do not normally invoke each other's methods directly. Instead they go through AgletProxy objects, which serve as aglet representatives. 3.6 Communication The Aglets architecture consists of two APIs and two implementation layers. Aglet API Aglets Runtime Layer - The implementation of Aglet API Agent Transport and Communication Interface Transport Layer The Aglets runtime layer is the implementation of Aglet API, which provides the fundamental functionality such as creation, management or transfer of aglets. This layer defines the behavior of APIs such as Aglet and AgletContext, and can serve multiple AgletContext objects. The transport layer is responsible for transporting an agent to the destination in the form of a byte stream that contains class definitions as well as the serialized state of the agent. This layer is also defined as an API, called Agent Transfer and Communication Interface (ATCI), which allows the Aglets runtime to use the transport layer Page 109

CloneListener MobilityListener

Aglet

Mobility Events

Persistence

Events

PersistenceListener

Figure 4 Relationship Between Aglet and its Listeners 3.3 Serializing an Aglet Object When and aglet is dispatched, cloned or deactivated, it is marshaled into a bit-stream, then unmarshaled later. Aglets uses ObjectSerialization of Java to marshal and unmarshal the state of agents, and tries to marshal all the objects that are reachable from the aglet object. The state of the execution stacks and program counters of the threads owned by the aglet are not serialized. Object Volume 2, Issue 4 July August 2013

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856
in a protocol-independent manner. The implementation of ATCI is responsible for sending and receiving an agent and establishing a communication between agents. The current Aglets implementation uses the Agent Transfer Protocol (ATP), which is an application-level protocol for transmission of mobile agents. ATP is modeled on the HTTP protocol, and can be used to transfer the content of an agent in an agent-system-independent manner. To enable communication between agents, ATP also supports message-passing. When an aglet issues a request to dispatch itself to a destination, the request travels down to the Aglets runtime layer, which converts the aglet into the form of a byte array consisting of its state data and its code. If the request is successful, the aglet is terminated, and the byte array is passed to the ATP layer through the ATCI. The ATP, which is the implementation of ATCI, then constructs a bit stream that contains general information such as the agent system name and agent identifier, as well as the byte array from the Aglets runtime.
Sender Suspend Execution Serialize Agent Encode Data Transfer Data Receiver Resume Execution Deserialize Agent Decode Data Receive Data

Following terms are used to refer to the entities related to ATP communication: Agent. A program that carry out a set of operations on behalf of a user. It does so with some degree of autonomy to satisfy its user's goals. Connection. A transport layer virtual circuit established between two programs for the purpose of communication. Message. The basic unit of ATP communication of a byte stream matching the syntax and transmitted via a connection. Request. An ATP request message. Response. An ATP response message. Message Body. The information transferred as the payload of a request or response. Interpretation of the body content is implementation specific. Sender. The role of an application/system that establishes connections for the purpose of sending requests. Recipient. The role of an application/system that accepts connections in order to service requests and to send back responses. Agent Service. A system capable of acting both as sender and recipient of agents. Proxy. An intermediary agent service which acts as both a recipient and a sender for the purpose of making requests on behalf of other senders. 3.6.2 Communication Process The ATP protocol is based on a request/response paradigm between agent services. Agent service A establishes a connection with agent service B, then sends a request to B and waits for the response. Thus, A acts as a sender (of the request) and B acts as a recipient. A request includes a request line, specifying the request method, the protocol version and the required resource, followed by MIME-like message containing request modifiers, sender information and possible content in its body. A response include a status line, specifying a success or error code and the protocol version, followed by a MIME-like message containing response modifiers, sender information and possible content in its body. ATP is a simple application-level protocol designed to transmit an agent in an agent-system-independent manner. Its request consists of a request line, header fields, and a content. The request line specifies the method of the request, while the header fields contain the parameters of the request. ATP defines the following four standard request methods: Dispatch - The dispatch method requests a destination agent system to reconstruct an agent from the content of a request and start executing the agent. If the request is successful, the sender must terminate the agent and release any resources consumed by it. Retract - The retract method requests a destination agent system to send the specified agent back to the sender. The receiver is responsible for reconstructing and resuming the agent. If the agnet is successfully transfered, the

Network

Figure 5 Mechanism for Aglet Transfer 3.6.1 Aglet Transfer Protocol Aimed at the Internet, ATP offers a simple and platform independent protocol for transferring agents between networked computers. While mobile agents may be programmed in many different languages and for a variety of vendor specific agent platforms (consisting of virtual machines and libraries), ATP offers the opportunity to handle agent mobility in a general and uniform way: A machine hosting agents has an ATP-based agent service which is a component capable of receiving and sending agents from remote hosts via the ATP protocol. The agent service is identified by a unique address, independent of the specific agent platforms supported by the machine. A machine can run multiple agent services. A machine can host different types of agents, provided it supports the corresponding agent platforms. Any agent platform should include a handler of ATP messages. An ATP message carries sufficient information to identify the specific agent platform (at the receiver host) and calling its ATP handler to handle the message.

Volume 2, Issue 4 July August 2013

Page 110

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856
receiver must terminate the agent and release any resources consumed by it. Fetch - The fetch method is similar to the GET method in HTTP; it requests a receiver to retrieve and send any identified information. (normally class files). Message- The message method is used to pass a message to agent identified by agent-id and return a reply value in the response. Although the protocol adopts a request/reply form, it does not lay down any rules for communication scheme between agents. as bypassing controls, exploiting trapdoors, or introducing Trojan horses. A security architecture must therefore confine key security functionality to a trusted core that enforces the essential parts of the security policy. These parts include-: Protecting aglet transfer and communication as required by the security policy, performing the required access control and auditing of aglet execution,preventing (groups of) aglets from interfering with each other or gaining unauthorized access to each others state,preventing aglets from interfering with their hosting aglet system. Additional requirements to be met in some systems include allowing the use of different cryptographic algorithms, keeping the amount of information encrypted for confidentiality to a minimum. Because aglets are Java objects, they have potential access to all Java class files on the host; they also rely on the security of the Java interpreter for their proper execution. Thus, aglet security and Java security go hand in hand. All the security concerns raised about Java also affect the safe execution of aglets. 4.1 Possible attacks on Aglets Eavesdropping-Information is revealed from monitored communications. Intercept/alter-A communicated data item, such as a Java class file, is changed, deleted, or substituted while in transit. In particular, any context visited on the aglets itinerary could strip data added by previous contexts. Replay-A captured copy of a previously sent legitimate aglet is retransmitted for illegitimate purposes. Masquerade- An entity pretends to be a different entity,for example, one aglet pretends to be another. Resource exhaustion-A resource is deliberately used so heavily that service to other users is disrupted. Repudiation-A party to a communication exchange later denies that the exchange took place. 4.2 Security Model For Aglets A security model provides an overall ramework for aglet security supports the flexible definition of various security policies and describe how nd where a secure system enforces these policies.Security policies are defined in terms of a set of rules by one administrative authority. The policies specifyThe conditions under which aglets may access objects; the authentication required of users and other principals, which actions an authenticated entity is allowed to perform, and whether entities can delegate their rights;the communications security between aglets and between contexts, including trust:the degree of accountability required for each security relevant activity. An aglet might be unaware of the security policy of the hosting context and how it is enforced.If so, the user can be authenticated prior to creating the aglet;security is then enforced automatically. Some aglets will need to control Page 111

Figure 6 Standard Request Methods in ATP

4. Security Issues
Security is essential to any mobile agent system because accepting a hostile agent may lead to being harmed your computer or your privacy breaked. Mobile-agent systems, such as aglets, require high levels of security, because they represent yet another way to transmit a malicious program. Before aglets can be used in practice, there must be an infrastructure of aglet hosts that prevent untrusted aglets from doing damage but provide trusted aglets with useful access to the host's resources. The aglet context is typically created by a system having a network daemon that listens for aglets. The daemon inserts incoming aglets into the context. Often, a user interface component will provide a graphical or command line interface to the context. In general, any user can set up a context. Thus, an aglet network potentially includes contexts that not all users trust. There are four security issues specific to a mobile agent system. Protection of the host against aglets Protection of other aglets Protection of the aglet from the host Protection of the underlying network. Serious solutions has been found only for the first two.Security model for the Aglets Workbench also focuses on these two issues, although the model is flexible enough to accommodate eventual solutions to the latter two as well. While developing the model, it was assumed that an aglet system is subject to the fundamental threats of disclosure,modification, denial of use, misuse, abuse, and repudiation.These threats are possible not only when the aglets travel but also when they are in aglet contexts.Attack-ers can perform passive and active attacks utilizing aglets,aglet contexts, or other mechanisms. A secure aglet system must provide services to counter these threats. However, there is no countermeasure if the attacker exploits system flaws or security weaknesses such Volume 2, Issue 4 July August 2013

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856
or influence which policy is enforced by the system on their behalf, but will not enforce it themselves. Others will need to enforce their own security, to control access to their own data, or to audit their own security relevant activities. 4.2.1 Principals and Identities A principal is any entity whose identity can be authenticated by a system that the principal may try to access. A principal can be an individual, a corporation, a daemon thread,or a smart card. An identity consists of a name and possibly other attributes. The aglet security model identifies several principals,each having certain responsibilities and interests, which are as follows-: Aglet-Instantiation of the aglet program itself (thread). AgletManufacturer- Author of an aglet program (human, company,content rating ervice, and so on) . AgletOwner-Individual that launched the aglet (human) or principal that has legal responsibility for the aglets behavior Context- Interpreter that executes aglets (process, thread, and so on) . ContextManufacturer-Author of a context program/product (human,company, etc). ContextMaster-Owner/administrator/operator of the context (human, company etc). Domain-A group of contexts owned by the same authority. DomainAuthority-Owner/administrator/operator of the domain (human, company etc). Aglets and contexts are processes (threads) running on behalf of a user; manufacturers, owners,masters, and authorities are users imposing roles on aglets and contexts that reflect their organizational, functional, or social position. Every aglet has an identifier that is unique over its life time and independent of the context it is executing in.Its value, however, is not known before the aglet has been created and thus not easily accessible for authorization purposes. Therefore, the aglet identity includes its class namea kind of product namefor authentication. The aglet manufacturer produces a well-defined and reliable aglet. It is in the manufacturers interest that no damage can be claimed to have been caused by a malfunctioning aglet. For its own protection, the manufacturer might define terms of liability. The aglet has to rely on the context to carryout compliance.Security preferences also allow the owner to limit the agletscapabilities, for example to specify some global allowance on the maximum number of hops, CPUtime consumption, and so on. Unauthorized parties can be prevented from reading sensitive information held by an aglet while it is in transit between two aglet contexts if the peer contexts agree on the use of cryptography for encryption. When an aglet enters a context, the context receives a reference to it, and the aglet resumes execution in the new Volume 2, Issue 4 July August 2013 context. The aglet can also obtain a reference to the context interface. An aglet uses the context to gain information about its new environment, in particular about other aglets currently active in the context in order to interact with some of them.Contexts have to protect themselves against aglets and aglets must be precluded from interfering with each other. The aglet context establishes a reference monitor, which gives an aglet access to a resource only if it complies with the access control policy instated by the context master. Thus a context establishes a domain of logically related services under a common security policy governing all aglets in that context.

5. Reasons for Aglets Usage


Although mobile agent technology sounds exciting, our interest in mobile agentsshould not be motivated by the technology per se, but rather by the benefits they provide for the creation of distributed systems. So here are seven good reasons for you to start using aglets. 5.1 They reduce the network load.Distributed systems often rely on communications protocols that involve multiple interactions to accomplish a given task. This is especially true when security measures are enabled. The result is a lot of network traffic. Aglets allow you to package a conversation and dispatch it to a destination host where the interactions can take place locally.

Figure 7 Dymically selects proxy site to reduce bandwidth usage 5.2 They overcoming network latency. Critical real-time systems such as robots in manufacturing processes need to respond to changes in their environments in real time. Controlling such systems through a factory network of a substantial size involves significant latencies. For critical real-time systems, such latencies are not acceptable. Aglets offer a solution, since they can be dispatched from a central controller to act locally and directly execute the controller's directions Intelligent enough to move to better site

Figure 8 Reduce Latency Page 112

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856
5.3 They execute asynchronously and autonomously. Often mobile devices have to rely on expensive or fragile network connections. That is, tasks that require a continuously open connection between a mobile device and a fixed network will most likely not be economically or technically feasible. Tasks can be embedded into mobile agents, which can then be dispatched into the network. After being dispatched, the mobile agents become independent of the creating process and can operate asynchronously and autonomously. The mobile device can reconnect at some later time to collect the agent 5.4 They adapt dynamically. Aglets have the ability to sense their execution environment and react autonomously to changes. Multiple mobile agents possess the unique ability to distribute themselves among the hosts in the network in such a wayas to maintain the optimal configuration for solving a particular problem network.An example of this kind of application is a network backup tool that periodically must look at every disk attached to every computer hooked to a network. Here, aglet could roam the network, collecting information about the backup status of each disk. It could then return to its point of origin and make a report. 6.2 Searching and filtering On behalf of a user, a mobile agent could visit many sites, search through the information available at each site, and build an index of links to pieces of information that match a search criterion. 6.3 Monitoring Sometimes information is not spread out across space (on the disks of many different computers hooked to the same network), but across time. New information constantly is being produced and published on the network. Aglets can be sent out to wait for certain kinds of information to become available.For example, an agent could go to a stock market host, wait for a certain stock to hit a certain price, then buy some of it on behalf of its user. 6.4 Targeted information dissemination Another potential use of aglets is to distribute interactive news or advertising to interested parties. 6.5 Negotiating Besides searching databases and files, aglets can gain information by interacting with other agents. If, for example, we want to schedule a meeting with several other people, you could send a mobile agent to interact with the representative agents of each of the people you want to invite to your meeting. The agents could negotiate and establish a meeting time. 6.6 Parallel processing Given that aglets can move from node to node and can spawn subagents, one potential use of mobile agent technology is as a way to administer a parallel processing job. If a computation requires so much CPU time as to require breaking up across multiple processors, an infrastructure of mobile agent hosts could be an easy way to get the processes out there. 6.7 Entertainment In this scenario, aglets represent game players. The agents compete with one another on behalf of the players. Each player would program an agent with a strategy, then send the agent to a game host.

Figure 9 Can dynamically balance load 5.5 They can operate in partial connected mode. Aglets can work in partial connected mode.They need connectivity only to port themselves to remote site.Once they reach the destination then any disconnection does not affect their functionality.

Datase t

Agent continues its task even if the link to its home machine goes down (temporarily).

Datase t Dynamicall y selected proxy site

Datase t

7. Conclusion
Figure 10 Disconnected operation

6. Application of Aglets
6.1 Data collection from many places Aglets have an itinerary and can travel sequentially to many sites. One natural application of aglets, therefore, is collecting information spread across many computers hooked to a Volume 2, Issue 4 July August 2013

Aglet computing paradigm is a promising step towards enlightened future of distributed computing.Since computation is transferred to data site hence many constraints of bandwidth,latency and partial connectivity are properly addressed .has yet to achieve widespread acceptance, and there are significant barriers to be overcome before it does and one of the major issue of concern is security aspect. Page 113

International Journal of Emerging Trends & Technology in Computer Science (IJETTCS)


Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856 References
[1] Mobile Objects and Mobile Agents:The Future of Distributed Computing ? Danny B. LangeGeneral Magic,Inc.Sunnyvale, California, U.S.A [2] Mobile Agents with Java: The Aglet API1 Danny B. Lange General Magic Inc. 420 North Mary Avenue Sunnyvale, CA 94086 U.S.A. [3] Mitsuru Oshima IBM Tokyo Research Laboratory 1623-14 Shimotsuruma, Yamato-shi Kanagawa-ken 242, Japan [4] Mobile Agent Computing A White Paper [5] Building Distributed Application with Aglet This project is listed in the IBM Tokyo Research Lab's aglet homepage by Chong Xu and Dongbin Tao [6] Aglets Specification (1.0) Version 0.60 May 20th, 1997 Author: Mitsuru Oshima and Guenter Karjoth [7] Security Model For Aglets GNTER KARJOTH IBM Research Division, Zurich Research Laboratory Danny B. Lange and Mitusru Oshima IBM Research Division, Tokyo Research Laboratory [8] Security for Mobile Agents: Issues and Requirements, W.M. Farmer, J.D. Guttman, and V. Swarup Proc. 19th Natl Information Systems Security Conf. (NISSC 96), 1996, pp. 591-597. [9] Java-based Mobile Agents by David Wong,Noemi Paciorek, and Dana Moorie

AUTHOR
Rajesh Pandey received M.Tech degree in Information Technology from I.I.P.S-D.A.V.V, Indore in 2008. He has total 6 years experience of teaching including 1 year experience in corporate as a software testing trainer. He is now in Dr. K.N.Modi Institute of Engineering and Technology as asst. Professor in IT Deptt.

Volume 2, Issue 4 July August 2013

Page 114

S-ar putea să vă placă și