Sie sind auf Seite 1von 34

Mobile Agent Based System

The technology of mobile agents obtained recently more importance not only because of its capacity of developing and building a distributed, heterogeneous, and interoperable systems, but also because of its robustness development of mobile and communication network as well. However, there are few works dealing with the methods and tools of analysis and design of the mobile agents systems. Furthermore, the mobile systems have introduced new concepts as: migration, cloning and the locations.

Page 1

Mobile Agent Based System

An agent is defined as a person whose job is to act for, or manage the affairs of, other people. In the context of computers, software agents refer to programs that perform certain tasks on behalf of the user. Imagine that you want to go on a trip to a new holiday destination. You contact your travel agent program and describe your preferences and your constraints (such as how much money you are willing to spend, when you want to travel, etc.). The travel agent program suggests where you can spend your holidays after consulting several information sources such as tourist guides and flight schedules and verifying the availability of airline tickets and hotel rooms. When you confirm your destination, the program books the flight tickets and reserves the hotel rooms for you. Thus the software agent acts as your personal assistant. Software agents have the following properties, which distinguish them from other programs: Intelligence: Software agents employ techniques from the field of artificial intelligence, which empower them with a fair degree of intelligence and common sense. For example, the travel agent program should realize that people generally do not prefer travelling by flights that depart or arrive at the airport late in the night and the agent should avoid booking tickets on such flights. The travel agent program should be smart enough to bargain and arrange the trip so that the overall expenditure for the trip is as low as possible without compromising on the users preferences. Autonomy: The agents themselves decide the sequence of actions to be performed to achieve the users task. This autonomy enables agents to operate without requiring human intervention. Once the specifications are given to the travel agent, it should be able to proceed on its own to arrange the trip for the user without requiring the user to constantly monitor the agent. Responsiveness: Agents perceive their environment (which may be the Internet, a collection of other ends, etc.) and respond in a timely fashion to

Page 2

Mobile Agent Based System

changes that occur in it. At the same time, agents should not simply act in response to their environment; they should be able to exhibit opportunistic, goal-oriented behaviour and take the initiative when appropriate. Communicative Ability: Software agents should provide a user friendly interface so that the user can easily interact with the agent. Agents are social entities and often communicate and collaborate with one another in order to complete their tasks. For example, the travel agent program of one user must be able to communicate with other travel agents to find out about hotels which customers disliked and avoid such hotels.

Adaptability: Agents learn about the users behaviour and adapt themselves to suit the user. Consider a search agent that retrieves information for the user from the Internet. The search agent should be able to learn about the type of information the user is interested in and adapt it to deliver only the relevant Information to the user. Software agents can be classified as static agents and mobile agents. Static agents achieve their goal by executing on a single machine. On the other hand, mobile agents migrate from one Computer to another in the network and execute on several machines. Mobility increases the functionality of the mobile agent and allows the mobile agent to perform tasks beyond the scope of static agents. For example, a travel agent program may visit

Page 3

Mobile Agent Based System

several hosts such as an airline reservation system, a hotel resources host, etc. in order to achieve its function. This eliminates the need to have all the relevant databases on one host. This article gives the architecture of mobile agents and tradeoffs involved in using them. History A software agent according to Wikipedia is "a piece of autonomous or semi-autonomous pro active and reactive, computer software. Many individual communicative software agents may form a multi-agent system." The idea of software agents has been around for many years - I will not propose that they are my idea. Software agents originally were discussed in the 70 and in the mid 90 briefly gained some momentum but then stalled. Proponents at the time claimed they would revolutionize the software industry. For various reasons beyond the scope of this article they have not. When the idea came about to make them mobile I have not been able to determine. I first came upon the idea myself in 1997, but I suspect others had already considered the idea prior to this. Since then I have been preoccupied with pesky things like employment, family, and the usual whims of life. Recently I have had time to work on some academics, and mobile agents are something I have always wanted to revisit.

Page 4

Mobile Agent Based System

Focus on Mobility
Most discussions on agents focus on their autonomy, intelligence, and interaction. These are all worthy topics, however I will focus on mobility and how this feature of mobile agents can be used to build systems. Note that most agents are not mobile, and mobility in agents is a feature of its own.

Remoting versus Mobile Agents

Remoting includes network based RPCs (Remote Procedure Calls), DCOM, .NET remoting, TCP servers, web services, and most service oriented architectures. In remoting an already existing object is controlled remotely. The object only exists on the server but is controlled by a proxy class on the client that exposes an interface. Data is sent to the server, and results are returned.

Page 5

Mobile Agent Based System

With mobile agents the actual implementation moves. This makes it easier to deploy newer objects as they do not have to be pre deployed and installed before their use. Mobile agents are simply created, and essentially self deploying.

Page 6

Mobile Agent Based System

To match the remoting scenario, the object would return a value, or return itself. However mobile agents are much more flexible and have a variety of options. The scenario I presented is a typical client server system. I would not recommend deploying remoting agents from the client to the server in enterprise applications as it creates deployment issues which for years we have strived to eliminate. Do not assume that this is a common scenario with mobile agents as it would be a shame to move backwards in time regarding deployment. While I have presented this scenario purely to demonstrate how it differs from remoting, there are scenarios in which this pattern is useful which I will cover in the future. A more common scenario in client server or even n-tier systems would be as shown next:

Page 7

Mobile Agent Based System

This pattern has some very unique capabilities that may not be immediately obvious. I will cover this in more detail in the future, but as an exercise you may wish to consider the implications of this pattern.

No Single Solution
A unique feature of mobile agents is there is no one "configuration", but there are dozens. In the future I will spend significant time on covering various scenarios. For now, I want to stress that the patterns and examples I will demonstrate here are not what mobile agents are limited to. Some patterns have disadvantages and to think that all patterns of mobile agents have these problems will quickly convince you that mobile agents may be interesting, but are not useful.

No Client, No Server
In traditional designs there are designated clients, and designated servers. Tasks are always initiated by a client, performed by a server, and data returned to the client.

Page 8

Mobile Agent Based System

When there are only two tiers, it's very obvious which computer plays which role.

Even in n-tier designs, each relationship defines a role. In an example three tier design, the middle tier is both a client and a server. Whether it is a client or a server, depends on which relationship is examined.

With mobile agents, instead of splitting code into two pieces, all code exists in one object and the object moves about as needed. Because the objects themselves move, there is no client server relationship. Each computer is merely another peer. The mobile agent may have a home, or return data to its caller, but this relationship is completely dynamic and applies only to a particular choice of the agent, not the overall design.

Page 9

Mobile Agent Based System

As network administrators or developers, we still think of certain computers as servers. Why do we think of them as servers? Because they are in the server room and not on someone's desk. But to the mobile agents, they are just another host.

Mobile agents can certainly function in such an environment, and such "servers" are often used to distribute mobile agents, but in the software sense of the word, they are no longer "servers", but more akin to "birth places", "breeding grounds", "nests", or "hives". Mobile agents do not require servers however to operate, and can use any computer as a base.

Items not covered

There are many topics related to mobile agents that will not be covered in this article. This article is already rather long, and covering all of them could easily be the topic of a book. Such items are authentication, advanced routing, and other such topics. This article is an overview and introduction, although a basic introduction to security using gateways is included.

Page 10

Mobile Agent Based System

Advantages of Mobile Agent Technology

Single Code Base
In a client server example such as a web service, two pieces of code are necessary. The web service server and the client proxy. The client proxy usually is auto generated but it must be regenerated and redeployed to match changes or to take advantage of new functionality. In addition, all data must be marshalled across method calls and reprocessed on the other side.

With mobile agents, the creation, modification and deployment is greatly simplified because there is only one set of source code. The complete object moves, including data, instead of only data.

No Interposes Communication

Page 11

Mobile Agent Based System

Because mobile agents exist in one object, not split between a client and a server, no interposes communication is required. In client server designs, significant effort is put forth to marshal data between the two parts, and to manage state. With mobile agents, none of this is required and thus significantly decreases development time.

No Deployment
Because objects are autonomous and able to move around, there is no need to deploy the objects. Simply tell the mobile agents where to go.

Easily Modified
Mobile agents are easily modified as all source code and thus logic is contained in one place.

Disadvantages of Mobile Agent Technology

No technology or framework is without disadvantages and mobile agents are no exception. In this section I will discuss the disadvantages.

Because mobile agents send not only data, but code, more network bandwidth is required. This is often offset or even reduced to lower level than without mobile agents by the fact that data can be processed at various locations in the network. The code portion of mobile agents can also be cached, reducing the bandwidth to just the data portion. Most mobile agents however do require more bandwidth than sending raw unprocessed data. Compression can help as can efficient routing. A basic .NET assembly is 16 kilobytes. If mobile agents are each put into their own assembly then code generally is not that large and the impact to the network is negligible, if even measurable.

Concepts and Terms


Page 12

Mobile Agent Based System

In my implementation, I have called these mobile agents "tarakans", which is Russian for cockroach. The proper plural in Russian is actually tarakani, but the English pluralisation of tarakans will suffice for discussion. I will not cover their implementation in this article. Instead this article will focus on concepts and discussion. Another article will present the tarakan framework with examples and usage. The tarakan framework will be released as open source and can be used for academic or commercial use. Within this text, the terms tarakan and mobile agents are often used interchangeably. Host A host is any computer that supports the execution of tarakans. Spawn Spawning is the process of moving a copy of a tarakan to another host. Spawning makes a copy and the copy is moved to another host, and the current tarakan continues to exist. To perform a move, the current tarakan is simply terminated after it is spawned. Tarakans are not automatically terminated after spawning because often the tarakan continues with its task locally, or is spawned to multiple locations. Home Some patterns of tarakans have a home host. The home host is the originating host that tarakans return results to, or physically return to as tarakans. Sometimes the home host is a server class computer that spawns many tarakans, and some or all of the tarakans return to later. Other times the home is a desktop class computer that spawns a single tarakan.
Page 13

Mobile Agent Based System

With mobile agents, it's already been discussed that there are no permanent clients or servers and that such roles are dynamic. Tarakans however support the concept of a gateway host. A gateway host is used for easy distribution and to implement security in a tarakan network.

Gateways can also provide directory services for tarakans guiding them where to go to perform their tasks.

Security using Gateways

There are many ways to secure mobile agents; this article will not cover them in detail. This section however will provide a basic overview of a core security concept, security using gateways. If all hosts accept any tarakan without access control, havoc can certainly take hold quickly by abuse from desktop users, hackers, or even viruses. One way to control this is by using gateway hosts. Each host is configured to only accept tarakans from gateway hosts, trusted hosts, or tarakans initiated by a gateway.

Page 14

Mobile Agent Based System

Not Permitted

This migration is not permitted because it comes from an untrusted host.


This migration is permitted because the two hosts have a trust relationship. Permitted

Page 15

Mobile Agent Based System

This migration is permitted because although the second hop came from a host, the tarakan was originated from the gateway.


This migration is permitted because the gateway has allowed it to be relayed and it is now considered a gateway initiated tarakan. Gateways can enforce policies regarding relaying. In more advanced configurations, hosts may provide two classes of service, one for tarakans originated from gateways and other trusted hosts, and a more restrictive execution host for tarakans from other hosts.

Page 16

Mobile Agent Based System

Examples of Mobile Agent Based System

In this section I will discuss many possible patterns and example solutions for using mobile agents. As I stated before, there is no single solution, and there are certainly more patterns than I will present here. Do not let your designs be constrained by these patterns. In some examples, I will present a more traditional approach first for comparison. In such cases, it is provided merely for comparison and very likely it is not the only solution available. There are usually many ways to solve a problem. Some examples have corresponding code examples that I will post later. In the future, all examples will have corresponding code to match the example.

Data Collection
Scenario A corporate environment exists but the exact specifications of each machine are not known. To facilitate better deployment, data needs to be gathered about each machine regarding the operating system, the latest service pack installed, installed memory, and other similar statistics. This is not a one time inventory and should be kept up to date. In addition over time, new information will need to be obtained such as checking for specific software, software versions, etc. It is not known what items might need to be checked for in the future. Traditional

Page 17

Mobile Agent Based System

In addition, since the requirements state that the requirements will change and will require new deployment, the MSI must install a process or redeploy on a regular basis to allow updates to be deployed to the clients. Implementation

Page 18

Mobile Agent Based System

The mobile agent example performs the same tasks, yet is easier to create, debug and update. Data Collection - Larger Data A mixed environment of laptops and desktops exists. The laptops are mobile and not always connected to the corporate network. Users enter their time worked with project codes, dates, and other information into Excel spreadsheets.

Page 19

Mobile Agent Based System

Close observers will notice that this is very similar to the previous example. The key difference is that instead of returning a result, the object is moved back to home. The reason for this is that the data to be returned is more complex, and also because the data will be acted upon by the agent after return. By keeping the code that is executed on both computers in one object, the design is greatly simplified. Network Mapping A network exists of multiple segments with many firewalls, routers and proxies. A quick and live manner of mapping the network is required. Tarakans easily allow mapping across firewalls and proxies. Some hosts are only reachable by other hosts and the tarakans can detect this.

Page 20

Mobile Agent Based System

Page 21

Mobile Agent Based System

The tarakans are given a maximum hop value so that they do not continue on forever. This maximum hop value determines the maximum number of hops between hosts that they will make before self termination. Tarakans are allowed to visit a machine multiple times as they may reach the machine by multiple routes, and this information is recorded and analyzed. Searching The network needs to be searched for a specific criteria. However this criteria often changes and cannot be encapsulated into a predefined set of parameters. One time a computer with Russian language support may be needed, in another a computer with an old copy of Microsoft Office may be needed, yet in another a computer with a 486 processor may be needed. As you can see, the possibilities are endless and cannot be predetermined. For searching, the Tarakans start out on a host computer. From that host computer, they are spawned to a list of known computers to that host. This list of known computers is carried with each Tarakan. At each computer they reach, they perform the following steps: e In this example it is possible and even likely that multiple tarakans will visit the same machine. This would cause not only duplicate results to be returned to the home, but also unnecessary network bandwidth and processors to be used. This is addressed using local storage. Each time a tarakan visits a host, it leaves an entry in the local storage using its initial instance identifier which was created on the first host. Each tarakan then checks the local storage to see if this host has already been visited by this type of tarakan. This entry is made with an expiration mark so that the local storage does not become cluttered. Finding Resources to Complete a Task A computer has a task to accomplish, but it does not have the resources to accomplish it. There are many scenarios that fit this pattern so I shall

Page 22

Mobile Agent Based System

present a common one here as an example. A user wants to print a document. Normally the user manually selects a printer. In corporate networks, browsing for a printer often brings up dozens of not hundreds of printers, and choosing one can be quite a daunting task. For laptop users who plug into various networks, manual selection is a must and each network may have numerous printers.

Page 23

Mobile Agent Based System

This implementation is a little more complex than the previous ones. Because of this I have not been able to fit all the steps in the diagram and instead will discuss them. First the client requests a printer tarakan from the gateway. It does this instead of storing the printer object locally because it allows the administrator to update the tarakan. Some preferences could be applied after the tarakan returns, however pulling it first allows client side functionality to be downloaded as well. For example, if the administrator wants to enforce a restriction of a 100 page limit this can be communicated to the user immediately on the client before the tarakan leaves. Once the tarakan is received, the attributes of the print job are set. In this example, the document type is grey scale, there are 150 pages, and the desired quality is medium. Other attributes such as paper size, priority and proximity could be used. The tarakan is then pushed back to the gateway. At the gateway the tarakan obtains a list of printers available. Only static properties such as capability (colour, black and white, etc.) and location are stored in the directory. Dynamic properties such as current load, ink levels, and paper status are not available in the directory. Using the directory, the tarakan is able to eliminate the plotter based on its static properties. Once it has this list, it can begin to spawn to each printer one at a time to interrogate it and determine its usefulness and eliminate printers in other buildings or on other floors. In this example, the sampling might go like this:

Ink jet - Can print grey scale, has ink, but it's currently out of paper. Laser printer - Meets our requirements, has a low cost per page. Impact Dot Matrix - Used for form and carbon copy prints. Can print but will not meet desired quality and is loaded with form feed carbon copy paper. Plotter - Plotter is skipped based on information from directory. Colour Laser printer - Meets our requirements, but cost of printing is higher.

Page 24

Mobile Agent Based System

The tarakan then returns to home. It may select a printer automatically, or present the user with the most suitable ones and let the user make a final decision. It may also report that no printers are available and the user may re-dispatch the tarakan to find printers on an adjacent floor. The tarakan might also take into account the current queue of the printer. If a printer has 500 pages queued, it may decide to exclude it. This tarakan was not the real printer tarakan - it was merely a resource finding tarakan. Now that a printer has been selected, the print job tarakan is spawned. The print job tarakan is spawned directly to the printer but it does not render locally. It saves network bandwidth by rendering directly on the printer and carrying the source with it. When it has successfully printed, it sends back a notification tarakan to home. Distributed Processing A network exists with anywhere from a few desktop computers to thousands. The desktop computers are utilized during the work day, but are idle at lunch and outside of working hours. This provides 16 hours of idle time per work day, and 48 hours of idle time on weekends. Each desktop also has periods of inactivity during the work day, and most desktops utilize on average <5% of the CPU with CPU usage only being used in spurts. Developer machines are more heavily utilized but still only consume CPU usage in spurts. Using agents, tasks requiring a lot of processing must be custom built to distribute the load between computers. Such schemes exist such as SETI, and others, but each requires a central server, remoting, and a custom installation. With agents, any number of needs can take advantage of distributed processing in idle times by simply creating one agent and giving it a piece of data to work on. Most applications that can take advantage of distributed processing are video and audio encoding, large numerical calculations, and the like. Very few businesses have such needs, but there are business cases for distributed processing. Data analysis and data mining are common in enterprises and are ideal to be run during off peak hours. Advanced data analysis often is queued to run at off peak hours anyways to avoid excessive load on the

Page 25

Mobile Agent Based System

database during working hours. Because a single machine often cannot analyze all the data in one night or even a weekend, it is often broken into several nights. By using mobile agents, the load can easily be distributed among many machines and what otherwise would require many days or even weeks to accomplish can be done faster. Disconnected Processing Laptops are connected in the morning each day and then taken into the field. Sometimes they are reconnected to the corporate network in the evening, but often not until the next morning. Laptops bring back data from the field and processing of the data requires a significant amount of time. Requests can also be made that cannot be serviced immediately. A sales force might collect data throughout the day. When they return they want to connect just long enough to offload the data, but not wait for the data to be processed. Requests for advanced research on customers can also be dispatched. When they reconnect the next morning, any errors are reported and the results of any requests returned. Traditional Traditional designs of this scenario use queuing, often MSMQ. In fact mobile agents in this scenario could utilize a queuing system for their transport. Pushing Processing servers are set up to handle processing for clients. The advantages are that of a typical n-tier design. The servers are closer to the data, have more power, and more memory. The desktops therefore can be on a slower connection, and have lesser processors and lesser memory. For operations, the desktop computers push mobile agents to processing servers. The mobile agents are then load balanced across the processing servers. The advantage with this scenario is extremely simplified deployment and easier versioning. While each desktop must be deployed to, only one tier

Page 26

Mobile Agent Based System

must be deployed and there is never a version mismatch between tiers, because each desktop completely contains the application. Yet logically, it is still an n-tier design. Servers can also handle a variety of tasks, not simply fixed designations. Users can create their own uses for servers without the need to install any software on the server. This is a very useful way for a set of servers to support a variety of applications. Because enterprises focus on few versions, and centralized control, this pattern is not common in the enterprise. However outside the enterprise it is very common. Spam is becoming ever pervasive, as are viruses. Spam and virus scanning is often performed both on the mail server and on the mail client. Performing scanning on the server requires the owner of the server to maintain the definitions. While the server owners are usually diligent in keeping definitions up to date, it leaves the user with no choice of software. Many ISPs implement spam solutions that interfere with users wishes and the users have little or no configuration options other than to turn them off. Performing scanning on the client allows the user to choose software that suits their needs precisely and to configure it as needed. However it requires that all mail is downloaded first. With spam becoming so prevalent, it is not unusual for spam to consume more than 25% of a mailbox's messages. By using mobile agents, each user can choose their own spam control and virus protection. The mobile agents have full access to the user's mail box and can control and filter messages on the server saving the user bandwidth because only the unfiltered messages are downloaded. Users could also customize the mobile agents to prioritize, reroute, or to perform any task desired. Hold and Store

Page 27

Mobile Agent Based System

Hold and store can be used to run mobile agents on a regular basis. Since mobile agents can be moved across a network, they can also be hibernated to disk. An agent therefore can be moved to a computer and hibernated, but awoken once per day, or at some other interval. Scenario 1 In a corporate environment, users often install prohibited software. The urge to lock down users' machines is the natural one, however this often restricts the users too prohibitively. In fact I have seen a few corporations lock down developers' machines and remove their local administrator rights. This of course makes development very difficult, if not impossible for most developers' needs. A mobile agent can be dispatched to watch for prohibited software without disabling the machine to a point that unusable for the person's needs. It might be determined that ICQ is not permitted. But then later the company decides to also prohibit Skype and other new programs that emerge. Since there is no easy way to detect all programs by a set of simple criteria, a mobile agent allows the criteria to be easily expanded and programs to be detected in whatever manner is required. Scenario 2 A virus scanner is also an ideal candidate for a hold and store mobile agent. Virus scanners are regularly updated. Often the update includes only a definition update, but since viruses are constantly evolving, very frequently the actual implementation of the virus scanner needs to be updated as well. This makes mobile agents an ideal solution. In an enterprise, the mobile agents can be pushed each time an update is required. Outside the enterprise, existing mobile agents can check for newer versions and pull newer versions if they exist. Move from User to User Mobile agents are also extremely useful in tasks that require input from many sources.

Page 28

Mobile Agent Based System

Scenario This scenario uses user input, however other scenarios may rely on non user input based resources. In most enterprises, to purchase items, people must be involved. First the user must create a request with information about the vendor and product desired. From there, it must to go to their manager for approval. Next it must go to a purchasing agent. After the purchasing agent creates the purchase order, it is sent back to the user for confirmation. If the user approves it, it will then go to the mail room; else it will go back to the purchasing agent. Because so many points are involved, most enterprises today have not automated such processes. Instead, they rely on Word, Excel and PDF documents relayed by e-mail. This process however is often very inconvenient for users, and because many processes are manual, steps in the process often break down.

With mobile agents, the mobile agent can move from location to location, either by its normal transport or by email. When it reaches each machine, it notifies the user of the action required and prompts the user for input. When the input is satisfactory, it packs up and moves to the next user. Business Logic Mobile agents as I have demonstrated so far have many uses. However there is one that I believed has been overlooked and is of great use to enterprises, and that is in the client side validation of business logic. As discussed in my earlier articles, an ultimate 3-tier application would distribute the business logic as follows:

Page 29

Mobile Agent Based System

In practice the above scenario is rare because it would require too many validations to be sent to the business layer or provide for a user interface that does not properly inform the user of when certain data fields are valid or not. Because of this a fair portion of the business logic which is related to validation, enabling and disabling of fields, etc., is copied to the client as shown next:

Page 30

Mobile Agent Based System

This is of course a practical decision and a known trade off. With mobile agents this could be addressed by sending down a mobile agent. The mobile agent not only brings the data, but advanced support for client side validation and input logic. Let's consider an example. An input screen exists to input an address. In the address, there are fields for state, post code, and country. The state field however is required only if the country is USA or Canada. For other countries the state is optional. If all logic is kept in the business layer, this requires a call to the server with an attempted post to insert the record. Only then can it return and tell the user that a field is missing. This is not only slower, but is not as clear for the user. The client application itself does not know that the state field can be required. If this information is kept in the client application, when the requirements change, the client application must be redeployed. Some frameworks are even rule based and send down with data certain rules about the data. However even simplistic and common rules such as this cannot be conveyed in their limited meta data. With mobile agents, this validation logic can easily be built in to the data as validation code. Although it executes on the client, since it is stored on the business layer, it is still considered part of the business layer and the 0-1000 ratio can easily be kept. Let's consider a more complex yet common need, validation of post codes. Each country of course has its own format for post codes, and occasionally the rules change. With the validation of phone numbers, the rules very often change. Typically post codes are validated on the server against data tables. Certainly I am not proposing that these data tables be downloaded in each mobile agent, this would be very inefficient. However, with mobile agents,

Page 31

Mobile Agent Based System

the format such as length and characters used in the post code can be easily validated in the client application. If the rules change for a given country, it's simply a matter of updating the mobile agent in the business layer. Some frameworks attempt to download complete clients when changes occur. This however creates bandwidth as well as installation issues. Since mobile agents are small and internal, they can easily be changed and even cached, without creating large bandwidth requirements or installation conflicts.

Mobile agent technology can offer a new paradigm for communication over heterogonous network channels. A number of advantages of using mobile agent computing paradigms have

Page 32

Mobile Agent Based System been proposed and identified. These advantages include: overcoming network latency, reducing network load, executing asynchronously and autonomously, adapting dynamically,

operating in heterogeneous environments, and having robust and fault-tolerant behaviour. However, the security and standardising issues still represent a significant obstacle. The main conclusion which can be drawn from our findings and investigation is that mobile agent technology has the potential in increasing the performance of networks as well as for software adopting MAs. Due to its nature of being a futuristic technology from the programming environment perspective a lot of work is still required before the average programmer can build applications based on the mobile agent technology paradigm in an easy manner.


Page 33

Mobile Agent Based System

Page 34