Documente Academic
Documente Profesional
Documente Cultură
Web Site: www.ijettcs.org Email: editor@ijettcs.org, editorijettcs@gmail.com Volume 2, Issue 4, July August 2013 ISSN 2278-6856
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
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
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
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.
Page 110
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
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 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
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
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.
Page 114