Using Multiple Communication Channels in a Mobile Agent Platform Theodoros E. Athanaileas, Ioannis E. Foukarakis, Dimitra I. Kaklamani, and Iakovos S. Venieris School of Electrical and Computer Engineering, National Technical University of Athens Fax:+30-210-7722291, Tel:+30-210-7722287
[email protected]
Abstract. This paper describes a flexible architecture that enables the adoption of additional communication channels in a mobile agent platform. The architecture extends an already implemented Web Service [1] based mobile agent platform by replacing communication mechanisms with more advanced components, and without modifying the platform’s core components. The proposed architecture uses well-known design patterns to better define its distinguishing parts. Sockets are used as the first alternate to SOAP communication. Finally, the two different communication channels are compared and benchmarked.
1 Introduction During the last years, research on mobile agent platforms has focused on porting existing platforms or developing new platforms for different environments such as mobile devices [3], web servers or even the Grid. These platforms use common communication channels [2], [4], usually dictated by limitations of the runtime environment (i.e. HTTP for mobile devices [6]). Although architectures and agent communication languages [5] have been proposed for enabling interaction with other agent platforms, most platforms rarely use more than one communication channel. This limits the mobile agent technologies, because of the lack of interoperability between platforms running on top of different environments. In order to bypass this problem, we propose a modular architecture that enables the adoption of multiple communication protocols. The existence of these mechanisms is transparent to the core platform, thus minimizing the cost of migrating existing mobile agent applications to the new architecture.
2 The Core Agent Platform The platform described in this paper is based on an already existing platform implemented in Java which makes use of Web Services [7]. Web services are collections of operations covered in modular, self-contained applications that are accessible over a network and generally the Internet, through standardized XML T. Magedanz et al.(Eds.): MATA 2005, LNCS 3744, pp. 316 – 323, 2005. © Springer-Verlag Berlin Heidelberg 2005
Using Multiple Communication Channels in a Mobile Agent Platform
317
messaging. Communication between platform components is achieved by using SOAP (Simple Object Access Protocol) and specifically SOAP-RPC. With SOAPRPC, an object situated on a remote host invokes a method and gets the result when the method returns. The platform has been designed according to the OMG MASIF [8] specification. The concepts of places, agencies and regions used by other existing platforms have been adopted. The region is used for providing directory services. Upon creation, movement, end of execution and other major events in an agent’s life cycle, the object is notified by the agencies that are registered to it, so that it keeps track of all the changes. What is more, an agency or an agent (through its agency) can send queries to the region in order to retrieve information about other agents or other agencies. The main components of the platform are the agencies. Agencies provide the agents with an environment to run and a communication gateway to other agencies and/or agents. Agency objects provide the actual runtime environment for both Stationary and Mobile agents. Their main operations are to create, store, move agents and to allow them to communicate with other platform components. Each agency is divided into places. The concept of places is used in order to provide grouping capabilities for the agents. A place groups the functionality within an agency, encapsulating certain capabilities and restrictions for visiting agents helping this way the administrator and the programmer to separate different agents. A major part of the platform is the workers, who are responsible for performing specific tasks, such as requesting the creation of a new place in an agency or registering an agency to a region. There are two categories of workers: those used for agency-to-agency communication and those used for agency-to-region and vise versa communication. The Workers API acts as a middle-tier between the platform and the communication channel, thus making it possible for another protocol to be easily embedded into the platform communication mechanism.
3 Sockets It is known that a socket is one endpoint of a two-way communication link between two programs running on a network. A socket is bound to a port number so that the communication protocol can identify the application that data is destined to be sent. There are two protocols that can be used for socket programming: UDP [9] (datagram communication) and TCP [10] (stream communication). UDP is an unreliable protocol – there is no guarantee that datagrams sent will be received in the same order by the receiving socket, whereas TCP is a reliable protocol – the packets sent are guaranteed to be received by the receiving socket at the same order in which they were sent. It is more than obvious that for an agent platform – where agents must be reliably transferred – only the use of TCP sockets is acceptable.
4 Sockets vs. Soap Apart from the advantages and comforts that SOAP and Web Services offer in designing distributed applications, there are also some drawbacks that may cause some problems in certain situations.
318
T.E. Athanaileas et al.
First of all, Web Services are based on the HTTP protocol, thus making use of port 80. But this port is also used by any other program which uses the HTTP protocol. This means that security precautions can become complex. It must be noted that SOAP does not make the HTTP protocol less secure than it has always been, but it makes use of it considerably more sophisticatedly than usually and therefore a more sophisticated security model than that usually used for HTTP traffic is demanded. By using plain sockets, security can become a less complex problem. Each platform component can use any non well-known port, which means that it does not have to share its port with any other application, thus making security controls much easier. What is more, the use of Secure Socket Layer (SSL) can be easily imported. The most important disadvantage of using SOAP is lack of performance due to the requirement to parse and transport XML. The use of XML places a heavy burden on the system. Despite the relative simplicity of XML, there are huge memory and CPU requirements compared to other solutions. Generating and parsing XML documents is a time consuming task that also needs a lot of memory compared to the actual data that is in those documents. It must be noted that these documents have to travel across the network. With XML the actual information is only a small part of the total data, which results in a high overhead and wasted network bandwidth. By using plain sockets, we achieve a performance gain. Sockets are flexible and give the ability to implement an application so that only absolutely necessary information is sent over the network, resulting in both higher communication speed and bandwidth efficiency. In order to implement a distributed application, a messagepassing system must be adopted. The messages passed can contain only the necessary data, thus contributing to the efficiency of the application. On the other hand, applications based on SOAP have to transfer whole web pages for each request. The trade-off of using sockets to implement a distributed application such as a mobile agent platform is that both the server-side and the client-side have to provide mechanisms to make the data transferred in the messages useful. This makes the application more sophisticated.
5 Socket Agent Platform Architecture The architecture of the socket platform is depicted in Figure 1. The communication between the components of the Socket Platform is implemented through a message-passing approach. Therefore, we make use of a RequestMessage class which contains all the information needed for the communication. This class has fields that determine the method to be invoked on the target component as well as the method arguments. A ReplyMessage class is used to store the result of the method. An instance of the first class is sent by the client to the server in any communication attempt, while the server sends an instance of the ReplyMessage class to the client when the communication request has been processed. This transaction is made possible by using the Java Serialization feature and object input and output streams.
Using Multiple Communication Channels in a Mobile Agent Platform
319
Fig. 1. The general architecture of the Socket agent platform
5.1 The Server Side In order to achieve an operative platform using sockets, we have made use of a classic multi-threaded socket server, which contains an instance of the Agency or Region class. The server creates a ServerSocket and waits for communication requests. Whenever a communication request is attempted, a new thread is created which reads a serialized object of the RequestMessage class through the socket input stream. Depending on the type of the message, the server chooses the appropriate method of the component to be invoked and the result returned by the method is stored in an instance of the ReplyMessage class, which in turn is sent back to the client. While in a SOAP Platform every component is identified by a URL, in a Socket Platform the identification of a server needs the host address the platform component is running on and the port number the server is attached to. 5.2 The Client Side The client side of the Socket Platform is implemented through the Workers API. The Workers API manages to maximize code reusability, but most importantly it offers a transparent way of communication independently of the protocol used by the platform. This means that using the Workers API along with the add-on of the WorkerFactory discussed later, it is possible to achieve communication with any platform using either SOAP or sockets, or even any other future-supported protocol (such as RMI). The workers are the objects which create the socket connection to the remote host. Whenever there is a need for interaction with a remote platform component, a worker is created. The worker creates the appropriate instance of the RequestMessage class, forwards the message to the server and blocks until a ReplyMessage object is received from the socket input stream. In order to make a connection attempt, the worker only needs the address of the host the Agency or Region is running on and the
320
T.E. Athanaileas et al.
number of the socket the server is attached to. These are the two arguments demanded by any worker, along with other method-specific arguments that some workers may need.
Fig. 2. The architecture of the protocol-independent agent platform
6 Protocol-Independent Platform One of the main objectives of our work was to achieve complete transparency at the interaction between components of the platforms, independently of the platform protocols. In other words, whether the communication attempt is made towards a SOAP platform or a Socket platform or a platform based on any other protocol, the approach should be the same. The architecture of this protocol-independent platform is depicted in Figure 2. In order to achieve this protocol independency, first of all we introduced to the components of the platform an Identifier class which stores information about the protocol as well as the other objects which construct the identification needed to communicate with the component according to each protocol (for example the host address and the port for the Socket platform). The most critical step towards the direction of protocol-independency was finding a way to dynamically choose the right kind of workers for any supported protocol. This means that whenever communication is needed, the component, which possesses only the target Identifier and the arguments for the method to be called in the remote platform, should be able to get the right worker by passing this information to an object. This object is the WorkerFactory discussed in the next paragraph. 6.1 The WorkerFactory Class The WorkerFactory diagram is depicted in Figure 3.
Using Multiple Communication Channels in a Mobile Agent Platform
321
Fig. 3. The WorkerFactory pattern
In this figure, AWorker is the abstract class that all soap workers and socket workers are derived from. The AWorker class implements or defines fields and methods which are common to all worker classes. Every worker class needs to extend the AWorker class. The WorkerFactory is a class that decides which of these subclasses to return depending on the arguments given. It contains a getWorker method which passes some arguments to identify the address as well as the protocol of the target, the arguments of the method to be invoked at the target and the kind of worker to be returned. The method returns the appropriate instance of the class AWorker. It must be noted that which instance is returned does not matter to the programmer since they all have the same methods, but different implementations. The decision about the proper instance of the class is completely up to the WorkerFactory and is made according to the protocol of the target and the kind of worker needed. The other arguments that are passed to the getWorker method are needed only for the instantiation of the worker.
7 SOAP Platform and Socket Platform Comparison In order to benchmark the usage of the two different communication channels, a simple agent was developed. This agent moves between two agencies hosted on different computers. Upon creation, the agent creates a byte array that is used as a payload, migrates to the remote agency and returns. The byte array acts as a way to control the agent’s size in memory. The round trip time is used as a metric for the platform performance. This scenario is repeated several times for various payload
322
T.E. Athanaileas et al.
sizes and average round trip time is taken into account for each payload size. The results from this benchmark can be seen in Figure 4.
Fig. 4. Socket and SOAP comparison
For small payload sizes (1-64 Kbytes), the average round trip time for the two different workers API’s is similar. But for larger payload sizes, sockets are faster than SOAP. As it has been noted earlier, this is expected because of the time required to parse larger XML documents.
8 Conclusions and Future Work In this paper a multi-protocol mobile agent architecture was presented. The current architecture defines endpoints where handlers for different communication channels can be attached, further extending this way the platform. The main advantage of this architecture is that it doesn’t require changes in the core of the platform. Tests run using SOAP and sockets as the communication channel have shown that sockets offer better performance. Our current efforts focus on extending the platform by implementing additional Worker classes conforming to various protocols such as CORBA and RMI.
References 1. W3C consortium, “The Simple Object Access Protocol”, http://www.w3.org/TR/SOAP/ 2. JADE mobile agent platform, http://jade.tilab.com 3. J. Cao, D.C.K. Tse, and A. T.S. Chan, “PDAgent: A Platform for Developing and Deploying Mobile Agent-Enabled Applications for Wireless Devices”, in Proc. 2004 International Conference on Parallel Processing (ICPP'04), August 15 - 18, 2004, Montreal, Quebec, Canada, pp. 510-517
Using Multiple Communication Channels in a Mobile Agent Platform
323
4. M. Aleksy, A. Korthaus and Martin Schader, “CARLA – A CORBA-based Architecture for Lightweight Agents”, in Proc. IEEE/WIC International Conference on Intelligent Agent Technology, October 13 - 17, 2003, Halifax, Canada, p. 111. 5. FIPA 97 Part 2 Version 2.0: Agent Communication Language Specification, http://www.fipa.org/specs/fipa00003 6. LEAP Lightweight Extensible Agent Platform, http://leap.crm-paris.com/ 7. I. E. Foukarakis, A. I. Kostaridis, C. G. Biniaris, D. I. Kaklamani and I. S. Venieris, "Implementation of a Mobile Agent Platform Based on Web Services", Proceedings of the 5th International Workshop on Mobile Agents for Telecommunication Applications (MATA’03), Marrakech, Morocco, October 8–10, 2003, Lecture Notes in Computer Science, Vol. 2881 / 2003, Springer–Verlag, (ISBN 3–540–20298–6), pp. 190–199. 8. OMG MASIF, “Mobile Agent System Interoperability Facility (MASIF) specification”, ftp://ftp.omn.org/pub/docs/orbos/97-10-05.pdf 9. RFC 768, User Datagram Protocol, http://www.rfc-editor.org/rfc/rfc768.txt 10. RFC 793, Transmission Control Protocol, http://www.rfc-editor.org/rfc/rfc793.txt
