XML-based Mobile Agents Robert Steele University of Technology,Sydney P O Box 123 Broadway NSW 2007 Australia
[email protected]
Tharam Dillon University of Technology,Sydney P O Box 123 Broadway NSW 2007 Australia
[email protected]
Abstract Current mobile agent systems are based on agent architectures that are partially or fully implementation programming language-specific. Mobile agent implementation in a specific programming language has usage limitations as the inter agent communication and agent migration to other agent hosts needs support for the same language. Widely used Java-based agents have an advantage of easy agent migration through bytecode transfer but this also imposes the requirement of a Java Virtual Machine (JVM) on each agent host where agents can migrate to. To achieve a truly system independent and agent system architecture independent solution, here we propose a XML-based mobile agent architecture. This paper presents a mobile agent system design based on the use of XML-based agent code, the UDDI registry for agent registration and lookup/discovery and XML Web Service calls for mobile agent intercommunication and migration. This will also facilitate industry to have easier and less risky adaptation from existing agent system implementation.
Keywords: XML, mobile agents, UDDI, web services, agent architecture
1.
Introduction
The widespread use of networked applications and the Web is based on distributed computing. Distributed systems are implemented with such distributed computing technologies as TCP/IP (connectionoriented approach), UDP (connectionless approach), remote method calls etc. In distributed computing the usual form of communication between server and client consists of a request from the client to the server and then the server carries out processing to generate the desired results. The mobile agent approach extends
Parth Pandya Yuri Ventsov University of University of Technology,Sydney Technology,Sydney P O Box 123 P O Box 123 Broadway Broadway NSW 2007 Australia NSW 2007 Australia
[email protected] [email protected] the network computing mechanism by transferring executable code to the server (including its state (data) and behavior (execution logic)) where it is then executed. Mobile agents can be defined as a “computing paradigm in which a program, in the form of a software agent, can suspend its execution on a host computer, transfer itself to another agent-enabled host on the network, and resume execution on the new host.” [8]. Mobile agent systems provide the benefits of agent migration, multi-agent communication and negotiation. Such characteristics are well suited to mobile enterprise environments where co-ordinated distributed tasks can be carried out without a continuous wireless connection with mobile devices in the system. This paradigm can also help software development and deployment speed and flexibility in fields like e-commerce, network management and mobile computing [15]. However the lack of a standardized programming model prevents the widespread deployment of this potentially useful technology [13]. Programming language specific mobile agent systems presume a common execution environment and architecture to support agent migration. Mobile agent systems presume the existence of an architecture in which the same executable code can move from one machine to another and still be able to run. Typically, as the format of executable files are tied to the details of the underlying platform i.e. the specific hardware and/or operating system combination, executable files can not move from machine to machine while still being able to run unmodified on each. However Java, and in particular its Java Virtual Machine (JVM) provides a common execution environment sitting on top of the underlying platform and mostly hiding it. This allows Java bytecode programs to be migrated from one machine to another without recompilation. However such bytecode-implemented agents still assume a Java environment: the presence of a JVM. These implementations of mobile agent systems limit
Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’05) 0-7695-2315-3/05 $ 20.00 IEEE
the usage of the mobile agent system by supporting same technology implementations only. To get the benefits of truly mobile agent systems, interportability between various language implementations, like C++, Java, .Net framework etc, should be supported. As Kotz and Rus describe [10], the identification of key features like persistence, resource allocation, orphan detection, state capture, security, communication and co-ordination are important to make the efficient use and successful deployment of mobile agents. As [13] suggests there is a need for a coherent and flexible set of standards, to achieve the inter-operability. To achieve this we utilize a set of established XML-related [3, 4] standards such as UDDI [16] and XML Web services [14, 17] to support XML-based mobile agents. Here the use of XML based agents, allows the capture of data and logic in the form of XML and thus allows easy communication between different technology and language-based agent systems. The proposed mobile agent capability to call Web Services adds to the benefit of supporting and re-using existing implementations. Traditional agent-based system deployment of multi-agent systems becomes complex due to the lack of agreed definitions, duplication of effort and incompatibility [9]. In Section 2 we introduce related work and in Section 3 we describe the mobile agent system architecture, including agent addressing, lookup/discovery, migration, messaging and delivery. Section 4 explains the way agents can be encoded in XML, Section 5 provides a discussion and Section 6 concludes the paper.
multiple command messages to the server. White [18] describes this as a technical advantage while the ability to have system customization is described as a strategic advantage. Despite of all these advantages the independent development, lack of agreed definitions, lack of common standards and compatibility have hindered mobile agent deployment [13]. Aglets [13] are one of the best-known mobile agent projects that extend Java. It uses the two layered model dedicated to runtime operations and communication. The top level handles the serialization-deserialization, class loading and transfer, reference management, Garbage Collection and persistence management. While the second or communication layer handles the creating & migration of agents. At the end of an Aglet migration it is executed from scratch but it can restore its state [7]. Due to its extension and support for Java mechanism the project from IBM Tokyo research laboratory is widely used [7]. The agent system architecture, proposed in this paper, based on top of the Web Services standards can give value-added advantages by making the solution available to use for any language implementation. The XML based messaging and agent representation, Web Service calls for inter agent communication and migration, UDDI registry lookup to locate the agent can be used for any language implementation like C++, Java, .NET framework etc. This also allows the sharing of functionality across the business partners, internal and external users [11].
2.
The Object Management Group (OMG) Mobile Agent System Interoperability Facility (MASIF) (2000) defines the four main concerns about agent interoperability. 1. A standard way to create, suspend, resume and termination. 2. A common mobility infrastructure to support multi agent communication and migration to other mobile systems. 3. Standardized mechanism for naming and addressing agents and agent systems. 4. Standardized location syntax for finding agents. The use of a XML-based agent representation and UDDI provides ready ways to achieve the above. In our proposal each agent offers a Web service interface itself. That is, it has a set of operations that can be called (collectively a Web service(s)) for which there is a corresponding Web Services Description
Background
As Wong [19] describes, in early distributed systems, process migration allowed applications to migrate the entire address space between computers. This gave the benefit of reducing the network bandwidth usage but the limitation to send back the entire process to send the data back was the main drawback. Remote evaluation programming and mobile objects were being adopted for the systems to fulfill these needs. Mobile objects can migrate from one computer to another computer while carrying the executable code and data in the form of execution environment specific objects. Wong also states the main advantages of this approach include agent autonomy, ability to adapt to changes in program state and network environment and an asynchronous mode of communication. Agent systems also improve the performance of the system by sending the agent to the host and avoiding sending
3.
Mobile Agent Architecture
Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’05) 0-7695-2315-3/05 $ 20.00 IEEE
Language (WSDL) file. This service is how external entities communicate with the agent. The life-cycle of the system execution is described below to explain further how this will work. We assume an underlying computing infrastructure where some of the computing hosts are mobile devices with wireless connectivity (See Figure 2). In this scenario the mobile device end-user initiates a request and an agent migrates from the mobile device to the service provider server. Each server in the system hosts an agent container. Once the agent migrates to the server the connection with the mobile device is terminated. From this point the agent itself communicates with other agents and makes Web Service calls to gather and prepare the required information or perform the requested tasks. At the end of its tasks, the gathered information or result of the assigned task is sent back to this originating server. Fundamentally agents and containers will be addressed via a URL. In this way, a unified, universally used and already deployed addressing mechanisms is utilized. Each agent, to achieve unique identification, will be assigned a unique ID by the container when it migrates from the mobile device and this ID will be incorporated into the unique URL that an agent will have at any point of time in its lifecycle (see Section 3.1). The mobile agent then registers itself with the UDDI registry and makes an entry there, which represents its current location on that host. This registration will involve publishing to UDDI the WSDL file that describes the set of operations the agent provides. The unique ID assigned to the agent is used as the ‘service name’ in the UDDI registry. This enables other agents to identify and discover the agent through the service name. Each time the agent migrates to another host this UDDI entry gets updated so the next messages sent to this agent gets delivered to its current host/ location. When an agent wants to communicate with another agent it can invoke an operation or operations on that agent. Such a call might typically be preceded by a UDDI lookup to determine the target agent’s current address/ URL. Assigning a unique identification to agents and making is available for other agents and containers can make it possible to find and negotiate with agents easily. The user identification part of the unique ID can be used to send back the results to the mobile device where the agent was initiated (See Section 3.1). Containers also provide services that can be addressed with a unique URL to allow agents to communicate with containers. Usage of UDDI to store the addresses of agents and containers will help in making the system simpler due to widespread support and usage by industry. It
will also be useful for inter-agent messaging to make sure that the message is delivered at the correct place even in the event of an agent migrating.
3.1.
Agent Addressing
In multi-agent systems a unique identification for each agent is required. In the proposed system the unique ID of the agent will be a combination of the originating host’s IP address (a hexadecimal representation of it) and a locally unique 16 bit ID (a hexadecimal representation of it) assigned by the container. See Figure 1a for an example. When an agent is created it is assigned a 16 bit Local Unique ID and this is freed up when the agent is destroyed. This implies that a host can have a maximum of over 65,000 generated agents outstanding at any one time. IP Address of originating host: Local Unique ID 32 bits 16 bits e.g. 132.25.8.1 e.g. 60.192 (hex) 84190801 (hex) 3CC0 48 bit Unique agent ID (Service name used in UDDI) 841908013CC0 Figure 1a Example Unique agent ID (Service Name) When the agent from Figure 1a is currently at host www.it.uts.edu.au, it might have for example the following URL (in the element in the WSDL file in UDDI): http://www.it.uts.edu.au/841908013CC0/ Figure 1b Example Unique URL of agent at a given time Agents can be of different types, which we will refer to as different applications. Each type or application will have a unique application ID. This information will be stored in each agent of this type but will not be part of the agent unique ID. The container itself has a unique ID: 000000000000. This allows addressing of the container and its services by agents. The unique agent ID will also be used as the service name for the UDDI registry entry. When an agent first migrates to a host it then registers itself as a service present on that host with the UDDI registry. Its registered URL consists of the host name with the agent’s unique ID appended (see Figure 1b). The registration will involve uploading a WSDL file with this service name to the UDDI registry. This WSDL file will allow other agents to lookup the services the agent provides. The service name and operations
Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’05) 0-7695-2315-3/05 $ 20.00 IEEE
(abstract part of the WSDL file) will remain the same throughout the agent’s lifetime while the port field (implementation part of WSDL) will be updated as the migration occurs. This will allow the system to change just the port field to the new URL describing the new location of the agent and leaving all other fields unchanged. As this agent migrates a new UDDI registry entry is not created, but rather the existing registry entry is modified. This addressing scheme allows the same agent to maintain the same unique ID across its lifetime but to still have a unique Web address at any given time depending on its current agent host.
made to update the UDDI registry by changing its location URL in the element. The other tags such as message, types and binding can stay the same after each migration. This design provides a way to deliver the messages to the agent. The message delivery, by other agent or agent host, to the agent is always done after finding out the current location of the agent from the UDDI registry. This mechanism helps in sending out the messages to the agent’s current location. Each agent will also have one incoming queue on which other agents and containers deliver the messages. This is also useful when the agent migrates.
Figure 2 Agent Addressing and Registration Figure 3 Agent Lookup
3.2.
Lookup/discovery
Each agent and each container will be registered to the UDDI registry. To get the benefits of the Web Services standardization efforts and to avoid the redesign of another lookup service we propose to use the UDDI registry. One of the challenging areas for the multi-agent communication is to locate the agent at a specific given time and deliver the message (see Figure 3). As Duego [6] discusses, the advantages and usability of agent design and how frequent migration behavior of the agent can causes a communication problem. The Home-Proxy and Follower-Proxy type of models for multi-agent communication require the mobile agent to update the ‘Home’ about its current location. Both of the models described by Deugo, fall short in providing the reliable and efficient communication mechanism that mobile agents should possess. For the UDDI registry to keep the agent location on a “as-now” state for message delivery, the agent should update the UDDI registry about its location upon migration. At the end of migration when the agent resides at the new host, the UDDI API call is
3.3.
Migration
In the case of the agent migration the agent and containers works together to provide scalable design for message delivery. Before the agent starts its migration it stores the messaging queue with the originating container. This is used to receive the messages sent to the agent whilst it is migrating and it hasn’t reached its destination. When the agent reaches the destination host it updates the UDDI registry to change its location related entry. At this point another call is made to the old host and the old host delivers the messages received for the agent to its messaging queue at the new location. The updated UDDI registry entry will also provide new location information to other agents and containers. The migration of the agent is handled by the agent host (see Figure 4). Here we assume that the hosts, which are sending and receiving the agents, have standard migrateIn() and migrateOut() services. The migrateOut() service has two parameters: the unique ID of the agent to be migrated and the URL/ uniqueID
Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’05) 0-7695-2315-3/05 $ 20.00 IEEE
of the destination container. The migrateIn() service has two parameters: the XML agent to be migrated and the unique ID of the container sending the agent. The initiation of the migration can be from the agent itself or by an authorized party (such as the originating server). Migration is triggered by calling of the migrateOut() service on the container currently hosting the agent. When the container’s migrateOut() service is called, the agent is suspended. After this the migrateOut() service implementation places the agent into the input parameter for a migrateIn() service call for the destination server to start the migration.
Figure 5a Messaging (while migrating)
Figure 4 Agent Migration Here the whole agent is passed as an input parameter to the migrateIn() service on the destination host. Before migrating the agent’s state must be saved. While suspending the agent prior to the migration the internal state of the agent is stored in a data section of the message to the destination container. After the current state is stored the agent will be stored on to the secondary storage As the agent itself is XML code and the data values are also represented in XML there is not a serialization problem in relation to preparing the agent for transmission. On the destination end the migrateIn() service receives the agent and then resumes the agent.
3.4.
Messaging
Messaging or inter-agent communication in the multi-agent system requires synchronization, especially when the agent is migrating. All of the agents will negotiate and communicate with each other through use of Web Services. We propose the design in which the agent which sends the message (sender agent) firstly locates the current location of the receiving agent through UDDI.
Figure 5b Messaging (after migration) Then the sender agent sends the message which is then put on the in-coming queue of the receiving agent. In the case of the receiving agent initiating migration at this time, the message delivery can be a problem. To resolve this, part of the functionality of the migrateOut() service that the agent calls is to instruct the container to start receiving messages on behalf of the agent. At this stage the UDDI registry has information that the agent resides on this host so all the agents or containers who sends messages to this
Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’05) 0-7695-2315-3/05 $ 20.00 IEEE
agent will be delivered to the container-maintained queue for that agent. When the agent finishes the migration it updates its location related information to the UDDI registry (Figure 5b). At this stage the old host sends the series of messages to the agent on the new host and the agent’s in-coming queue receives the messages whilst maintaining ordering. Once this is done the queue on the old host is removed as in the future messages will be delivered to the agent on the new host as the agent has updated the UDDI registry.
3.5.
Delivery
The delivery of the retrieved information (task results) to the mobile device can have two types of delivery mechanism. Either the agent containing the information can be sent back to the mobile device as soon as the agent gets the required information. This can be considered the ‘push’ mechanism in which the information is pushed to the device. The other alternative to the ‘push’ mechanism is the ‘pull’ or ‘on request’ delivery mechanism. This second approach adds the benefits to users by allowing them to retrieve the information when needed. The push approach can be quite useful in the presence of mobile network problems and to avoid the situation in which the user has to initiate the data transfer again and again due to connection loss.
4.
XML Agent Structure
The agent should contain the data and EventCondition-Action rules to encode agent logic as an XML file. The data can reside in the element followed by the Event-ConditionAction rules in the
section. The Event can be defined as the incoming operation call for the agent. A call to the agent’s service triggers the event and can take optional parameters to the call. The Condition part of the agent contains just the IF statements to check the values of the data fields and determines the Action call. The Action part of the agent contains either the value assignment to the data variable or can have a call to another Web Services. The expected WSDL can have the following type of structure (Figure 6). We provide as an example a setData service implementation (see Figure 7). The functionality of the setData operation in the example WSDL is to assign new values to limit data variables inside the agent. Other agents can call this Web Service. Figure 7 provides an example of the XML-based agent
implementation and how this simple service could be implemented via XML statements. Figure 6 Example WSDL
Figure 7 Example XML-based Agent code
5.
Discussion and Future Work
The MASIF standards which proposes a standard way to design agent systems assumes the Java execution environment and supports CORBA for naming and locating facilities. The agent architecture proposed here distributes the functionalities across an XML representation of the agent, use of UDDI and use of Web Services calls. This paper addresses the four issues put forward by the MASIF framework. Further work must be done to provide even further details of migration, addressing and messaging techniques for XML-based mobile agents. Currently a prototype is under construction and will be further developed. Further work is also being carried out to further define the syntax and semantics of the XML-encoded agent implementation. Other aspects that will be included into the future system are provision for security,
Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’05) 0-7695-2315-3/05 $ 20.00 IEEE
efficient execution of agent code and efficient messaging between agents and their local container. One of the main advantages of the proposed architecture is to re-use the existing agent systems. The XML-based agent system can be put on top of existing systems to support interaction with other language implemented agent systems. Use of existing and well standardized technologies like XML, the UDDI registry and Web Services allows the organization to start implementing the agent system with more confidence due to well known and adopted technologies. The use of WSDL for each type of agent will also provide the benefit of allowing more agent-to-agent and agent-to-host portability. Each application ported on the agent system will be identified with a unique ID and can have different type of agents related to this. The difference in the type of agent will allow support for different input and output parameters for the processing.
6.
[6]
[7]
[8]
[9]
[10]
Conclusion
The XML-based agent structure and the use of Web Service standards can allow a truly implementation independent agent system which can potentially allow multi-agent communication and agent migration across virtually all agent systems. The use of standardized technology will also allow utilization of the benefits from standardization activities in the fields of Web Services and the Semantic Web. In this paper we describe techniques for agent representation, addressing, migration, results delivery, intercommunication and lookup and discovery based on existing XML and Web service standards. The use of such standards and the ongoing cross-vendor and cross-organization standardization efforts in these areas will facilitate a more readily adoptable and ubiquitous mobile agent framework.
7.
[5]
References
[11] [12]
[13]
[14] [15]
[16] [17]
[1] Baralis E., CS, Paraboschi S. 1998, 'Compile-Time and Runtime Analysis of Active Behaviors', IEEE Transactions on knowledge and data engineering, vol. 10, no. 3, pp. 353-70. [2] Boley, H., Tabet, S. and Wagner, G. Design Rationale of RuleML: A Markup Language for Semantic Web Rules. In International Semantic Web Working Symposium (SWWS), 2001. [3] Consortium, W. W. W. 2000a. Extensible markup language (XML) 1.0. Available at http://www.w3.org/ TR/REC-xml [4] Consortium, W. W. W. 2000b. Resource description framework (RDF) schema specification 1.0. Available at
[18]
[19]
http://www.w3.org/TR/2000/CR-rdf-schema20000327/ Consortium, W. W. W. 2001. XML Schema Part 0: Primer. Available at http://www.w3.org/TR/ xmlschema-0/ Deugo D. 2001, 'Mobile Agent Messaging Models', Autonoumous Decentralized Systems, 5th International Symposium on 26-28 March 2001, pp. 278-86. Fuggetta A., PG, and Vigna G., May 1998, 'Understanding Code Mobility', IEEE Transactons on Software Engineering, vol. 24, no. 5, pp. 34262. Jansen W., KT 1999, NIST Special Publication 800-19 – Mobile Agent Security, viewed 5 November 2004 http://csrc.nist.gov/publications/nistpubs/80019/sp800-19.pdf. Kendall E.A., KV, Suresh C.B. and Pathak C.V. 2000, 'An Application Framework for Intellgent and Mobile Agents', ACM Computing Surveys, vol. 32, no. 1. Kotz D., GR, and Rus D. 2002, 'Future Directions for Mobile Agent Research', IEEE Distributed Systems, http://dsonline.computer.org/0208/f/kot_print.htm. Langdon C.S. July 2003, 'The state of Web services', IEEE Computer, vol. 36, no. 7, pp. 93-4. Lam, P., Ye, L., Chan, H., 2004, Business-toConsumer and Business-to-Business Mobile AGent-based Internet Commerce System (MAGICS), In Proc. of IEEE International Conference on Systems, Man and Cybernetics, Oct 10-13, The Hague, Netherlands, 2004. Schoeman M. and Cloete E. 2003, 'Architectural Components for the Efficient Design of Mobile Agent Systems', ACM International Conference Proceeding Series, pp. 48-58. SOAP 1.1 Technical Report, http://www.w3.org/TR/SOAP/, W3C, 2000. Steele, R., A Web Services-based System for Adhoc Mobile Application Integration, IEEE Intl. Conf. on Information Technology: Coding and Computing '03, 2003. UDDI.org: Universal Description, Discovery and Integration for the Web. http://www.uddi.org. Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl White J. 1996, Mobile Agents White Paper, http://www.carc.aist.go.jp/~masatomo/mobile/Whi te/whitepaper.html#Introduction. Wong D., PN, Moore D., 1999, 'Java-based mobile agents', Communications of the ACM, vol. 42, no. 3, pp. 92-102.
Proceedings of the International Conference on Information Technology: Coding and Computing (ITCC’05) 0-7695-2315-3/05 $ 20.00 IEEE
