Web Services Architect : Articles : Web Services and Mobile Intelligent Agents
Web Services Architect

Register for e-mail updates:

 

Web Services and Mobile Intelligent Agents

Combining Intelligence with Mobility

John Fou

Printer-friendly version

How can we combine the automation provided by mobile intelligent agents, with the location and platform agnostic features of Web Services? Clearly we would need to make our mobile agents platform agnostic as well, but is that all? What constitutes a mobile agent, and how can we say it has artificial intelligence? The answers to these questions should become clear in this article.

What is an Intelligent Agent?

The first question we must answer is what entities are we dealing with? Web Services we will take as a given (see other articles for description/definition/further discussion), but we cannot do the same for mobile agents. Let's take a simple definition of an agent to start with:

"An agent is a piece of software that has the capacity to autonomously conduct its work."

How can we characterize an agent? Is there anything to distinguish one agent from another? To answer these questions, we can say that there are two types of agent: property agents and action agents.

A property agent is distinguished by the knowledge and data it holds, such as a product catalog, or customer information. An action agent, on the other hand, has a set of governing rules by which it must act, in accordance with its intelligence, and can perform such tasks as product promotion or product configuration. Property agents can be thought of as nouns, while action agents are verbs. Both types of agent have expert knowledge of enterprise functions (their intelligence), and are capable of coordinating their actions with those of other agents, through the use of rules and intelligence implemented by their developers.

An agent also operates with a high degree of freedom, to the extent that there is no direct intervention on the part of human operators. Because of this autonomy, an agent must have some kind of control over its own actions and internal state. This control and access is again provided by the rules-based intelligence with which the agent is programmed. Each agent should also have specific domain knowledge, allowing the system to survive if one agent fails.

It is well nigh essential for agents to be able to interact with other agents, to take advantage of more specialized information they may hold. This communication has to take place through some mechanism, which can be XML documents or proprietary messages from Message Oriented Middleware (MQSeries, JMS, Jabber, etc.). As we would expect, for our agents to function in a Web Services context, they would have to be able to process and consume SOAP messages.

One key advantage of this ability for social interaction is that the agents can form a domain agent society. Basically, this acts like a user group for programmers - if the agent doesn't have the answer itself, it will ask other members of the domain agent society. Security would have to be factored into any society such as this, since a company wouldn't necessarily want its agents answering all the queries they get. If our mobile agents had a way to describe their capabilities to other agents, there would be no need for the potentially costly process of the agent trying to work out which other agents to trust. A convenient way of doing this is to use WSDL.

Because of all this potential communication, there would be a need to speed up the discovery of the agent we want. For this purpose, we can implement a property agent to be a Yellow Pages agent. Like a directory, this agent would have a list of names for all the agents it knows, along with their specialties. Alternatively, with Web Services enabled mobile agents, we could use UDDI to provide the directory services.

But how does the information get into the agent, you might ask. An agent will have knowledge fed into it as it is created. As time passes, the knowledge the agent holds may become obsolete. To minimize this, there are two approaches to creating a learning agent: passive learning, and active learning. An active agent will continually retrieve new information, without external prompting, while a passive agent will need to have the new information supplied to it, like re-fuelling a car.

What is a Mobile Agent?

What, then, does it mean for an agent to be a mobile agent? This is a simpler question to answer - at it's most basic level we can say that an agent is mobile if we don't need to know where in the system it resides. Thus, a mobile agent could be found on a desktop computer, a mobile device such as a PDA, or even in the depths of a server. All we need to know is how to find the agent, and how to communicate with it. Once we have this conceptual framework in place, we have the abstraction and flexibility required to design our system.

How mobile is a mobile agent, though? Currently, in order to move from one system to another, or even to communicate amongst themselves, mobile agents need a common platform on which to operate. Thus, in order for our mobile agents to be useful to our business partners (and to ourselves by operating with our partners), we have to share a platform with our partners, something we cannot guarantee being able to do. Even with the best developers in the world, this will take time. In order for intelligent agents to communicate, they would need to share a common language - the best candidate for this would be XML, or SOAP.

Mobile Agents and Web Services

With the advent of Web Services, we can develop mobile agents that can exist on an Intranet, or even in the deeper waters of the Internet. How? Because exposing our mobile agents as Web Services means that we can take advantage of the already existing network infrastructure and communication protocols provided by the Internet. As we expose our existing mobile agents as Web Services, or write future agents to take full advantage of the situation, not only do we make it easy for ourselves, but also quicker and more convenient.

Mobile intelligent agents can be developed to the Web Services standard using SOAP, WSDL, and UDDI. The mobile intelligent agents are Web Services ready so they can be plugged into this network and serve its knowledge. Using WSDL give the agent the ability to describe it's capacity, invaluable if it is to become part of a domain agent society.

As if the ability to use the Internet to further the reach of our mobile agents wasn't enough, there are companies dedicated to providing networking facilities for Web Services. With Web Services essentially moving components onto the Internet, it makes sense for companies to provide technology that will ease this process. Using such facilities, we can launch our mobile agents into the wider world should we desire. Companies such as Grand Central and Flamenco Networks are providing these Web Services network solutions.

Advantages of using Web Services

As well as making it easy for our mobile agents to be truly mobile, Web Services can provide other important benefits. The following list represents the key additional benefits:

  1. Conservation of Enterprise bandwidth
  2. Reduction in latency
  3. Conflict Knowledge Credibility Management
  4. Support for Dynamic Deployment
  5. Improved decision support workflow

Enterprise bandwidth is conserved through the use of mobile agents due to the reduction in network traffic they enable. Rather than pass numerous requests across the network, we can send a mobile agent to the site requiring processing; once there, the agent can conduct the operation, and return to the server only the information that actually needs to be returned. Of course, there will be a point when it isn't efficient to use a mobile agent, like when the process involves only two or three network calls.

Our mobile agents would ideally reside on a Web Services network. If a user requests knowledge from a mobile agent very frequently, the Web Services network can intelligently save this knowledge into a cache. So when a user asks the same questions, the Web Service cache will broadcast it for mobile agent if there is nothing new in the request.

A Web Services network will host many mobile agents, each of which will have expert knowledge in a particular area. The Web Services network will also need intelligence to be able to tell which agent has the best knowledge or if the knowledge conflicts with that of another agent. The Web Services network will judge and pick the best by its own intelligence and broadcast to the requesting agent.

As you would expect, mobile agents can aid in the dynamic deployment of new components in a Web Service. Additionally, a mobile agent can act as a remote controller in a process, allowing decision support workflow to be improved.

With our mobile agents residing in a Web Services network, many of our infrastructure concerns are handled for us. When a user requests certain knowledge, the Web Service network will route this message to a mobile agent. The network determines which is the nearest agent that has the knowledge requested, and routes the query by the quickest path.

Summary

Arming agents with knowledge, the means to communicate that knowledge, acquire more knowledge, and become mobile enables us to automate more areas of inter- and intra- business communication. Once we reach a business agreement with a potential partner, we could then use mobile intelligent agents to conduct further business with a minimum of human contact, thus speeding up the process.

John Fou is the co-founder of E-Dynamic Inc., a strategic technical consulting firm focused on enterprises' value chain, and reengineering processes. E-Dynamic has developed and sold a cutting-edge financial supply chain software package to Lucent. E-Dynamic's clients include Lucent Technology, Delta Airlines and Motorola.

Printer-friendly version

Keep up to date with all the new articles and features on Web Services Architect:
Register for e-mail updates


How useful is this article?
What's wrong and right about it?
What are your suggestions for taking it further?
Your views keep Web Services Architect focused.

E-mail us at feedback@WebServicesArchitect.com, or complete this form.
Note: fields marked * are compulsory.

Comments *:

E-mail *:

Job title:

First name:

Last name:

Allow Web Services Architect to display all or part of this message in an online forum.
I have read and agree to the terms and conditions.