Figure 1: Interfaces
Dominic Cooney [HREF1], d.cooney@qut.edu.au
Paul Roe [HREF2], p.roe@qut.edu.au
Centre for Information Technology Innovation, Queensland University of Technology [HREF3], GPO Box 2434, Brisbane QLD 4001 Australia.
Mobile agents are an excellent technology for implementing Web services. Within a set of federated Web services, mobile agents can reduce bandwidth requirements and mitigate the effects of high-latency network connections. This paper presents a model for implementing Web services with mobile agents where agents are free to move between cooperating Web servers to implement the service functionality. This paper presents a distributed searching service, and a distributed parallel information filtering service that take advantage of agent mobility. Our mobile agent Web services present typical WSDL interfaces, so mobile agent functionality can be consumed from legacy clients, and federated services can be gradually migrated to a mobile agent implementation.
A mobile agent is a discrete bundle of program code and data that can move between hosts. A mobile agent is somewhat like an object, in that has identity and state. A mobile agent is also like a process, in that it contains threads of execution and encapsulates data within a definite boundary (for a process, within an address space). Because mobile agents have threads and program code, they tend to be autonomous entities, unlike relatively passive objects that have methods invoked on them.
A mobile agent can move to a host and then interact with it locally. Interacting locally:
These good features are in contrast to those of remote procedure calls (RPC) and Java RMI [1]. Mobile agents also imply support for mobile code and concurrency, which are powerful capabilities.
Because of their good features, we would like to leverage the advantages of mobile agents in implementing Web services. The contribution of this paper is to propose a model of implementing Web services using mobile agents, where:
In Section 3.4 we show two non-trivial Web services implemented using our prototype. These services take advantage of the roaming ability of mobile agents.
We discuss the broader implications of our design and suggest some directions for future research in Section 4 and give some concluding remarks in Section 5.
In implementing Web services with mobile agents, some issues are quintessential to one discipline or the other. For example, the granularity of the unit of mobility is exclusively a mobile agent-related issue, while marshalling data to and from SOAP messages is exclusively a Web service-related issue. Other issues, such as security or transactions, are common to Web services and mobile agents. Addressing these issues will involve integrating the work in each area into a consistent whole. This section describes three design issues that exist at the boundary of mobile agents and Web services: service provision, request-agent mapping, and agent communication.
Traditionally Web services are static and relatively long-lived at a network endpoint. In contrast, a mobile agent may exist only fleetingly on a particular host. The first question in providing Web services with mobile agents is how a service is described. Web Services Description Language (WSDL) [2] describes services as operations on messages at a particular network end-point, with bindings to concrete protocols and message formats.
It would be possible to simply require the programmer to provide a WSDL description of any mobile agents. How requests to the service described in the WSDL are mapped to a mobile agent is discussed in Section 2.2. .NET's extensible metadata system means the programmer can annotate methods with metadata from which WSDL is generated automatically.
An alternative method of service provision would be to allow agents to provide and revoke 'ad-hoc' services by identifying a network endpoint and a bundle of methods that requests should be dispatched to. This meshes well with the dynamic flavour of mobile agent-based computing, however it is at odds with Web services which provide stable interfaces at a given endpoint.
Like an object in object-oriented programming, a mobile agent is an identifiable, discrete unit. The problem this introduces is one of mapping a Web service request to a particular mobile agent that fulfils that request. Because agents and objects both have a concept of identity, this problem is analogous to that of delivering service requests to object instances in services with object-oriented implementations. For example, Apache SOAP deployment descriptors [3] can map Web service requests to Java objects that have a per-request, per-HTTP session (if the underlying SOAP transport is HTTP), or per-application lifetime. Furthermore, individual EJB stateful session beans can be addressed via unique URNs. These URNs are discovered by clients when they call the bean's create method. .NET Remoting [4] is similar, where an object may be a singleton, or have a per-request or per-client lifetime. In these systems, no one discipline is mandated, but the service provider chooses which semantics are appropriate.
We can use a one-to-one mapping between services and mobile agents. In this scheme, all requests to a service are delivered to one 'singleton' agent. This single request, single agent model is complex because of the plethora of design choices for when the mobile agent moves away from the service endpoint. Requests could be queued or forwarded to the mobile agent's new location, the service could be torn down, or a new mobile agent could be instantiated to replace the old.
An alternative is to create a new mobile agent for each incoming request. This will limit the lifetime of a particular mobile agent to the length that a request takes to fulfil. However it is a simple model because multiple, concurrent requests can easily be handled by creating more mobile agents. In this scheme, the viability of the Web service is not threatened if a particular mobile agent moves away.
Although inter-agent communication is ostensibly a mobile agent issue, the introduction of another communication mechanism (that is, the Web service method call) may make it desirable to revisit the inter-agent communication with the goal of unifying the mechanisms. However there is a firm requirement that a Web service implemented with mobile agents should potentially look like any other Web service, and this is at odds with the inter-agent communication mechanisms of some mobile agent systems, such as communication via a shared tuple-space.
It is also reasonable to expect that a mobile agent may want to consume a Web service. It would be useful if legacy Web services could be surfaced so as to appear to the mobile agent developer merely as another mobile agent, albeit a long-lived, non-moving one.
This section offers a fairly bald description of our prototype implementation. The important implications of the design are left until Section 5. We choose this approach so we can illustrate a set of design decisions within the scope described in Section 2.
In our prototype implementation the methods of a class that the programmer annotates with the WebMethod metadata attribute form the description of a Web service. This is the same way a programmer nominates a method to be part of an ordinary, static Web service in .NET. No other special metadata is required, nor does the programmer have to extend a particular type.
Services are deployed by means of another, ordinary Web service called AgentService (see Figure 1). AgentService accepts and loads an assembly (the unit of deployment in .NET) and Web service stubs are created for any types that contain service methods. In a single assembly there may be several types containing service methods. Although the types may be related, our implementation publishes them as separate, independent services. Clients then reference these services directly.
A specific agent service is given a URL that combines the URL of the agent service and the name of the type that defines the service. So, for example, the AgentService at http://www.bar.com/AgentService/AgentService.asmx would publish the service defined in the MyType class at http://www.bar.com/AgentService/services/MyType.asmx. This means there is ample opportunity for name collisions amongst services.
In the prototype implementation, it is the stub Web service generated by the AgentService that accepts incoming SOAP messages. The stub delegates to an agent host, which handles the task of directing the request to a particular mobile agent. The agent host does this by first creating a 'context' for handling the request. Mobile agents inhabit contexts, and it is through the membrane of the context that an agent communicates with the agent host. An instance of the type that defines the service method is created within the context. Although everything within a context really constitutes an agent, it is the instance of the particular type that the programmer identifies as 'the agent'. This is because typically any other objects are mostly merely data, created and manipulated by the instance of the 'agent type'.
After the agent is created, it runs. By virtue of the separation the context provides, the agent is free to move away from its current host while the method is executing. The act of stopping a running agent, moving it to a new host, and restarting it requires process migration. Any reasonable mobile agent environment will support process migration, and we have reused a framework that provides a process migration service for .NET [5].
The host waits for the agent to return and publish a result. When this happens, the result is communicated back to the client via the Web service stub. This process is illustrated in Figure 2.
The operation of the Web service stub and agent host act to deliver a method invocation to a mobile agent. The programmer can take the abstract view that SOAP requests are handled directly by a mobile agent. In future diagrams we illustrate SOAP requests and responses going and coming directly to and from a mobile agent.
Our environment strictly limits inter-agent communication. Agents can do late-bound invocations of services provided by other agents. These method invocations can be done synchronously or asynchronously. Asynchronous method invocations are done in the usual .NET idiom whereby a 'begin' method returns a result handle whose actual value is collected later by a call to a corresponding 'end' method.
In this way, mobile agents can not get a direct reference to another mobile agent. Instead, a mobile agent can merely start another mobile agent by invoking a service method, and subsequently collect the result. Unlike normal .NET asynchronous result handles, a mobile agent result handle is 'durable' in that it survives even when an agent migrates to a different host.
A mobile agent could deliver its service return value to host other than the one that the agent was started on. The expectation in this circumstance is that the invoking agent would eventually migrate to that host to collect the result. The usefulness of this feature is limited in that an agent cannot tell whether it was instantiated to service a Web service request or a request from another agent, and for Web service requests to be completed, a mobile agent must migrate 'home' to deliver its result.
It is important to note that inter-agent service invocations are optimised by our runtime environment. So although the semantics the programmer observes are virtually indistinguishable from a Web service invocation, the runtime cost incurred is very low-- basically that of a late-bound method call. It also means that inter-agent service invocations do not tie up any underlying network resources, so unlike a call to a legacy Web service, inter-agent service invocations are truly asynchronous and disconnected.
We now turn our attention to three services implemented with mobile agents. The first is a simple "Hello World" service that moves to a remote computer, records the computer's host name, and subsequently returns to its original location to return a friendly greeting. The C# source code for this service is:
[WebMethod] public string GetGreeting(string name, string hostToVisit) { string home = (MobileContext.Host as IAgentHost).Uri; MobileContext.MigrateTo(hostToVisit); string result = "Hello, " + name + " from " + Environment.MachineName + "!"; MobileContext.MigrateTo(home); return result; } Note the WebMethod attribute on the GetGreeting method. The presence of this attribute means that an AgentService receiving this type will create a service that includes a GetGreeting method. The implementation of GetGreeting takes two parameters: a name, and the name of an agent host to visit. The agent records its current host, because it needs to return there later. The agent then moves to the host specified in hostToVisit. At the point that MigrateTo is invoked, the state of the agent is saved and transmitted to the specified host. At the new host, the state of the agent is restored, and execution continues on the next line, where the agent then generates a string, including the name of its new host. It then returns home to deliver its result.
Invoking this service returns a SOAP response similar to the following:
<?xml version="1.0" encoding="utf-8" ?><string xmlns="http://tempuri.org/"> Hello, John Q. Citizen from SIDESHOW-MARGE!</string>
Although this is a toy example, our other two example services are just increasingly complicated variations on this basic theme, where an agent that moves away, performs some work, and comes back to deliver its result.
One key reason for sending an agent to a remote host is to access the host's data locally and do some filtering or searching, and only return with relevant results. Accessing data locally, instead of across the network, is fast and reduces bandwidth requirements. With these advantages in mind, our second sample service is one that searches the file systems of remote computers.
Because multiple computers are necessarily involved, the search service dispatches multiple mobile agents, one to each computer, to perform the search in parallel. As illustrated in Figure 3, a client makes a SOAP request that nominates search terms, and identifies the computers to search. A single, controlling mobile agent asynchronously invokes one searching agent for each nominated computer. The searching agents then migrate to their targets and perform the requested search locally, while the controlling agent waits on their respective result handles. As their searches complete, the searching agents migrate back. The controlling agent collates their results and returns them to the client.
The computers the client nominated to search do not need the search agent service installed. Instead, the service is installed on-demand the first time a search agent migrates to a particular computer. The only requirement is that the computer is running the generic agent service, to accept the agent in the first place.
Our third example service is broadly similar to the search service. It parallelises a request to filter stock market data, farms out portions of work to other computers, and then aggregates the result. The stock agent is more complex, because it uses the services of another agent to discover peers that are available to do work. The stock agent also allows the client to customise the behaviour of the service, by providing code that implements the filtering discipline.
A Windows application, illustrated in Figure 4, consumes the stock-filtering service. The graphical client application allows the user to enter an arbitrary condition based on over seventy fields of data, such as price, earnings per share, and the price/earnings ratio. When the user clicks Search, the expression is compiled into an assembly. The client sends the assembly to the search service.
The stock agent screen-scrapes the stock ticker symbols of all of the listed companies on the Australian Stock Exchange (ASX) from a Web site. The search agent then retrieves a list of computers that are available to do work. It does this by querying the peer agent service. The peer agent service is also implemented with mobile agents. Basically, the peer agent service maintains a registry of computers that are available to accept agents.
The stock agent divides the list of ticker symbols amongst the available computers, and asynchronously invokes a worker agent to go to each computer to perform a portion of the work. Each worker agent accepts a list of ticker symbols, the filtering code, and the name of the computer it should use. It moves to the nominated computer, downloads the data for its list of ticker symbols, and applies the filter to each record. When the filtering is complete, it returns to its original host with the reduced set of results.
The stock agent aggregates the results of the worker agents as they return, and send the data back to the client, which displays the results in a table (see Figure 4).
Considering how the stock market data filtering service accepts some arbitrary mobile code that implements the filtering discipline, which is used to filter data on "worker" computers via another "directory" agent, it is easy to see how the prototype framework could be reused to implement a generalised "computation service". This is the goal of distributed computing projects such as G2 [6]. To implement such a service, it would be useful to have some concept of a "higher-order agent", one which can structure and direct computation, the details of which are provided by another agent that represents a computing task. This capability may useful beyond high-performance parallel distributed computing applications.
The guiding principle of our design was to choose the simplest approach possible. By simple, we mean the alternative that involved few extra concepts and was the most natural match to Web services. A deliberately simple design allows us to clearly see the effect of introducing mobile agents to the implementation of Web services. This section evaluates the implications of our design.
Our model of service provision is simple for programmers to use, and familiar to anyone who has implemented static Web services in .NET. Although the intention is that an administrator would deploy a Web service, because mobile agents are transferred via the AgentService, it is possible for programs to deploy the services they expect to use. For example, the stock market data-filtering application could have compiled and deployed a Web service specialised to a particular filter, instead of relying on anonymous mobile code to implement the filter. This approach would have been appropriate if other parties were expected to reuse a particular filter.
Although a client can exploit the flexibility mobile agents provide, legacy clients are also well supported. This is because the client is apparently invoking an ordinary Web service. It does not need to be aware that the service is implemented with mobile agents. This means mobile agent-backed Web services can be deployed in a piecemeal fashion and interoperate seamlessly with legacy clients. This is an excellent way to access the advantages of mobile agent technology, while controlling the implementation risk.
An exciting indication of this work is that existing federated Web services could be progressively replaced by a mobile agent implementation. Precisely because we restrict inter-agent communication so severely, there is no distinguishable difference to the mobile agent programmer between invoking a method on a mobile agent or a legacy Web service. Once sets of related Web services are all using a mobile agent implementation, it may be possible to erase some of the boundaries between the services and consolidate functionality within fewer kinds of mobile agents. An optimising compiler for a set of Web services may be able to do this automatically.
There is no means of service revocation in the prototype; nor does the prototype distinguish between when an assembly is being deployed by an administrator with the intent of making a service available, and when an assembly is transmitted to support the continued execution of an existing mobile agent. This means that in a network of computers running the prototype environment, a particular Web service may ultimately be available on every computer as mobile agent migration causes the definition of the service to spread promiscuously amongst the hosts. This would not be appropriate for a production environment, where service availability should be tightly controlled.
Our method of mapping results to a fresh instance of a type limits the potential for a particular instance to accumulate data over time; yet being able to accumulate data is a precondition for adaptive, intelligent agents. The reason we chose to create a new object to handle each request is because handling many requests with a particular agent introduces the problem of handling concurrent requests (for example, by requiring the programmer to implement a design that supports multiple threads, or by marshalling method calls onto a single thread) and queuing or redirecting calls when the particular mobile agent migrates to a remote host. In our prototype, agents can interact with some external store. For example, PeerAgent instances on a host share data via static variables.
Once an agent has posted a result, it goes out of scope and is eligible for garbage collection. By limiting inter-agent communication and mobile agent references in the way that we have, we avoid the need to do complex distributed garbage collection. We still need some scheme to dispose of results. Because result handles can be shared, a single result may be collected by multiple agents. Some results may never be collected because an agent has failed, or never intended to collect the result. The most likely scheme to address this issue is to assign return values an expiring lease so that, if a result is not collected within a limited time, the agent host releases the result.
Mobile agents are not a uniquely enabling technology for distributed computing, but the aggregate benefit they offer over remote procedure calls is compelling [7]. It is surprising, then, that practical issues in implementing Web services with mobile agents have escaped serious investigation. Some early work suggests integrating user-interactive mobile agents into Web servers [8]; recent work is more concerned with ontologies and the semantic Web [9, 10].
Communication is sensitive issue in mobile agent systems, more so than in traditional settings, since mobile agent systems imply many autonomous entities which the cost of communicating with may sometimes be very cheap (when the agent is co-located) and sometimes be very high (when the agent is on a different host). An agent framework typically endorses a particular discipline for communication, for example, via a shared tuple space in the MARS agent environment [11]. Mobile agents can interoperate with other systems if the systems can be surfaced in the agent environment's communication idiom. For example, XMARS [12] presents a unified view of different data sources that mobile agents can interact with.
Ontological languages for agent communication, such as KQML [13], attempt to imbue meaning to agent communication. DAML-S [14] supports rich descriptions of Web services, including how a service operates in terms of concurrent processes that split and join. DAML-S specifications are thus suggestive of how Web services can be implemented with mobile agents [15]. Although DAML-S specifications can be 'compiled' to Lisp S-expressions [16], DAML-S operates at a considerably higher level of abstraction than our prototype, which leverages language and library elements that will be familiar to contemporary programmers.
The Open Grid Services Architecture [17] has an architecture for managing 'transient' Web service interfaces to grid computing services. These Web services are created by persistent Web service factories. When the transient Web service is created via a factory, its life time is determined in advance and published with the transient service. This approach could be integrated into our model, with the generic AgentService acting as a factory.
Our prototype implementation and sample applications confirm that mobile agents are useful for implementing Web services. Clients can readily consume mobile agent functionality as though it was an ordinary Web service. When a mobile agent wants to consume a service, it is possible to transparently invoke either a legacy or mobile-agent backed Web service by doing dynamically-bound method invocations. A set of legacy Web services can be gradually replaced by a mobile agent-based implementation, which may be more amenable to optimisation.
This work was supported by a grant from Microsoft Research.
Dominic Cooney and Paul Roe © 2003. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.