7.3 Challenges with Agents

7.3 Challenges with Agents

7.3.1 Technical Hurdles

As discussed above, agents can help in many areas, but there are some hurdles that need to be overcome before software agents can become really useful. Therefore, it is important to discuss these shortly and show how they can be overcome . Most of these challenges are more of a theoretical problem, which can be easily solved .

One of these areas is the performance issue. Current mobile agent systems save network latency and bandwidth at the expense of higher loads on the service machines, since agents are often written in a (relatively) slow interpreted language for portability and security reasons. Another reason is that agents must be injected into an appropriate execution environment upon arrival. Thus, in the absence of network disconnections, agents ( especially those that need to perform only a few operations against each resource) often take longer to accomplish a task than more traditional implementations , since the time savings from avoiding intermediate network traffic is currently less than the time penalties from slower execution and the migration overhead. Fortunately, significant progress has been made on just-in-time compilation (most notably for Java), software fault isolation, and other techniques, which allows agents to execute nearly as fast as natively compiled code. These efforts should lead to a system in which accepting and executing a mobile agent involves only slightly more load than if the service machine had provided the agent's functionality as a built-in, natively compiled procedure. But the natural speed growth of networks and hardware make this point less and less significant over time.

Nearly all mobile agent systems allow a program to move freely among heterogeneous machines. For example, in Java, the code is first compiled into some platform-independent representation called byte-codes, and upon its arrival at the target machine is either further compiled into native code or executed inside an interpreter. For mobile agents to be widely used, however, the code must be portable across mobile-code systems, since it is unreasonable to expect that the computing community will settle on a single mobile-code system. Making code portable across systems will require a significant standardization effort. As Java was developed with agents in mind, it is quite clear that Java is the de facto standard for agents, so standardization is already somewhat at hand.

As discussed above, one of the biggest issues in agent technology is security. It is possible now to deploy a mobile agent system that adequately protects a machine against malicious agents. Viruses are nothing more than malicious agents. Some challenges still remain . First, a technology needs to be established that allows protecting the machines without excessively limiting agent access rights. The agent should also be protected from malicious machines that could try to infuse malicious code into the agent, and protection for groups of machines that are not under single administrative control needs to be implemented. An inadequate solution to any of these three problems will severely limit the use of mobile agents in a truly open environment such as the Internet. Many companies are presently working on solutions that will make agent technology more secure.

7.3.2 Non-Technical Hurdles

Besides the technical challenges discussed above, there remain several non-technical issues that may deter the widespread adoption of mobile-agent technology. Internet sites must have a strong motivation to overcome inertia, justify the cost of upgrading their systems, and adopt the technology. While the technological arguments above are convincing, they are not sufficient for most site administrators. In the end, the technology will be installed only if it provides substantial improvements to the end- user 's experience: more useful applications, each with fast access to information, support for disconnected operation, and other important features.

One problem today in getting mobile agents to the market is to define the appropriate killer application. The "mobile agent" paradigm is in many respects a new and powerful programming paradigm, and its use leads to faster performance in many cases. Nonetheless, most particular applications can be implemented just as cleanly and efficiently with a traditional technique, although different techniques would be used for different applications. Thus, the advantages of mobile agents are modest when any particular application is considered in isolation. TiVo has an agent in it, for example. Anybody can create an agent using any technology he or she wants, but people aren't creating enough of them so far and they don't work together economically and effectively yet, because that part of the architecture hasn't matured. This argument can easily be turned around, as we are approaching a me-centric computing environment. This environment is full of killer applications that require agentsin fact, it will be difficult to find scenarios without agents.

Another problem that may arise is the fact that it is unlikely that any Internet service will want to jump directly from existing client-server systems to full mobile agent systems. A clear evolutionary path from current systems to mobile agent systems must be provided. Our me-centric approach allows for easy transition.

Today "applets" (mobile code) are widely used for better interaction with the user, and the associated commercial technology is improving rapidly (e.g., faster Java virtual machines with just-in-time compilation). From applets, the next step is proxy sites that accept mobile code sent from a mobile client. In all likelihood , such proxies will be first provided by existing Internet service providers (ISPs). Since the sole function of the proxy sites will be to host mobile code, and since the ISPs will receive direct payment for the proxy service in the form of user subscriptions, the ISPs will accept the perceived security risks of mobile code. Once mobile code security is further tested on proxy sites, the services themselves will start to accept "servlets," mobile code sent from the client directly to the server (or from the proxy to the server). Once servlets become widely used, and as developers address the issue of protecting mobile code from malicious servers, services will start to accept mobile agents.

Another critical evolutionary path is the migration of agent technology from intranets to the Internet. Mobile code technologies will appear first in the relatively safe intranet environment. For example, a large company might find mobile agents the most convenient way to provide its employees with a wide range of access to its internal databases. Companies with intranets tend to be early adopters of new (useful) technology, because their administrators have more control over the intranet and the technologies used therein than over the Internet; control means that security is less of a concern, and wide deployment of agent support services can be encouraged. As the technologies mature in intranets, site administrators will become comfortable with them, and their practicality, safety, and potential uses will become clear. Then they will find their way into the Internet.

A final important hurdle is the problem of revenue flow and commercial image. If agents are used instead of Web browsers, the number of human visits to the Web pages will presumably decrease, and the advertisements will not be seen anymore. This means that many sites that offer their service for free (by showing banner ads) need to rethink their revenue streams. A payment component for agent-mediated services will be probable.

All of these hurdles are not impossible to overcome. Actually, many companies have already shown that they can overcome them. Others fail because they ignore these hurdles altogether.