Towards the Seamless Integration of Mobile Agents into Servi

Towards the Seamless Integration of Mobile Agents into Service Creation Practice∗ Andreas Kind1, Miltiades E. Anagnostou2, Malamati D. Louta2, Jan Nicklisch1 and Juan Tous1 1

C&C Research Laboratories, Berlin, NEC Europe Ltd. {ak, jan, jtous}@ccrle.nec.de 2 Telecommunications Laboratory, National Technical University of Athens {miltos, mlouta}@cc.ece.ntua.gr

Abstract. Mobile agent technology has been proposed to address complexity problems related with service creation and deployment in today’s open telecommunications domain. However, the integration of mobility into the traditional service creation process should not be decided on an ad-hoc basis. Based on the specific benefits and drawbacks of mobility, careful consideration is required in order to achieve a seamless integration of mobile agents into service creation practice. This paper explains in detail the necessity of a careful introduction of mobility in traditional service creation practices and concludes with a guideline to maximize the temporal and spatial locality of invocations between distributed service components.

1 Introduction Agent-based software components have been proposed to help with service deployment in today's increasingly complex open telecommunications market [12]. The complexity is related to the distributed, heterogeneous and dynamic character of computer networks that provide the infrastructure for differentiated multi-media services. Particularly, agent mobility promises to address the complexity problem with the ability to provide functionality at the time and location it is actually required in the network. Such a just-in-time management of services is similar to an established practice in the management context [1]. Most of the work regarding mobile agent technology applied in the telecommunications domain is driven by the typical advantages that can be identified with agent mobility. Mobile agents have been seen as a programming paradigm that can improve service quality and facilitate the service creation process by reducing communication cost and increasing the dynamic availability of customized functionality [13, 2, 11]. However, in order to benefit from mobile agent technology during service creation and deployment, it has to be carefully considered which service components will be ∗

This work was supported by the Commission of the European Communities within the ACTS Programme (AC325).

implemented as mobile agents. Mobility comes with overhead costs that have to be traded against the potential benefits. Without considering the specific advantages and the existing overhead, mobile agent technology will be difficult to seamlessly integrate into existing service creation practice. This paper proposes and discusses criteria for the successful integration of mobile agent technology into the traditional service creation process influenced by TMN, ODP and TINA. By integration we mean that we address the creation of services which make use of mobile agents. Input for this work comes from the ACTS project MONTAGE (Mobile Intelligent Agents in Accounting, Charging and Personal Mobility Support) [4]. A key objective of the project is to assess the use of mobile intelligent agents in the context of personal mobility. The paper is structured as follows. The next section introduces the programming concept of mobile software agents. Advantages and the overhead that come with mobility are highlighted. Section 3 discusses in detail the requirements for the successful application of mobile agent technology with service creation and deployment. Section 4 will introduce a mathematical framework for dealing with agent mobility. This framework is used in Section 5 to evaluate two service provision examples illustrating the seamless integration of mobile agent technology into service creation practice. The paper concludes with related work and conclusions.

2 Mobile Agents Mobile intelligent agents [14, 6, 5] are software components without a fixed locus of operation. In contrast with mobile objects, agents continue their operation when migrated. Typically, a mobile agent is initialized and sent off to a remote site in order to perform a specific task asynchronously. In multi-agent systems, pursuing the task involves co-operation, collaboration and negotiation with other software agents. A certain degree of autonomy and intelligence allows the agent to operate also in unpredictable or changing environments. Autonomy and intelligence can be linked to the agent’s ability to learn from experience. It should be taken into account that both agent mobility related tradeoffs, which are presented in this section and the qualitative analysis presented in Section 3, are expected to be valid mainly in the first stage of agent usage. Once the agent usage becomes widely accepted, a different service implementation culture with new design rules and motives will most likely emerge. 2.1 Functional Advantages Especially in the context of personal mobility, using an active modeling paradigm can help (from a software engineering point of view) to handle the increasing functional complexity involved with service creation and deployment. For instance, service selection specific functionality, like finding the most appropriate service offer in a distributed market based on a user profile, can be encapsulated in a mobile agent and sent to where services are actually offered by service retailers. The service creation and deployment process can therefore focus on the service key aspects stays thus

separated from service deployment specific issues arising with distributed programming. The problems of distributed service offering can be kept transparent to the service creation and selection process. It has been proposed to turn networks with a fixed switching and packet forwarding functionality into an advanced form of programmable networks by using mobile agents that can be delegated on demand to specific network elements in order to realize integrated services in a highly flexible way [2, 3]. This approach provides not only much more flexibility for the creation and deployment of differentiated services but addresses as well the important aspect of openness. With code mobility, ATM, PSTN/ISDN and IP networks can be turned into distributed computing environments that can be customized for different service and customer requirements accordingly. Beside the software engineering advantage of enhanced encapsulation and the clear separation between the key functionality and the aspects of deployment when on the functional side, mobile agent technology can offer further technical benefits. These potential technical advantages are reduced communication cost, reduced bandwidth usage, the possibility of using remote interfaces and the support for off-line computation. Distributing functionality autonomous agents located at the right position in a network adds another technical advantage, namely scalability. Much more nodes can be controlled without hitting performance limits at the initiating node. The focus within this paper is on the technical aspects, which are typically highlighted to justify the introduction of mobility into the service creation process. The technical advantages identified so far actually have to be regarded as potential advantages, because the overhead does not always outweigh the benefits of using mobility. 2.2 Overhead The overhead incurred by using mobile software components is linked to the following issues: Migration Cost: Before an agent can start execution at a remote site, it has to unregister at the local site, since other components may require the agent’s presence. Then the agent code and state have to be serialized (including nonstandard code and state that may be required for execution at the remote site). The serialized agent can then be transferred to the remote site via a secure communication layer. At the receiving site, the serialized agent has to be deserialized, registered and started. A decryption overhead has to be added in some cases as well. The resulting migration latency can be described as the sum of the times it takes to unregister/register (tmigr-reg), serialize/deserialize (tmigr-serial) and transfer (tmigr-trans): tmigr= tmigr-reg + tmigr-serial + tmigr-trans. Communication Cost: Typically, a software component is not isolated. It uses other software components, as it is used by other software components. Such usage relationships can be identified as flows of control and data between components. In the case of mobile agents, control and data paths to and from components that had been local to the agent before migration become more expensive after migration.

Likewise, control and data paths to and from components in the remote site become cheaper. Typically, remote invocation of operations involves the establishment of an inter-process communication channel over which the invocation request and the passed arguments are transferred. Arguments and return values have to be marshaled and unmarshaled using a serialized, architecture neutral data encoding scheme. The resulting invocation latency depends on the time it takes to marshal/unmarshal (i.e. serialize/deserialize) arguments and to transmit the invocation request and reply1: tinvoc= tinvoc-serial + tinvoc-trans. Reduced Flexibility: An agent can only migrate if its state can actually be serialized. However, not all objects can be serialized. This limitation of serialization comes with semantic and implementation related problems. Normally objects with dynamic scope (e.g. error handlers, dynamic variables, or continuations) and objects that are based on machine dependent representations (e.g. threads, native methods, or streams) cannot be serialized. Consequently, agents that refer to such unserializable objects are themselves not serializable. The flexibility of mobile agents is therefore restricted. Flexibility is further reduced by security measures in the form of sandboxing. In an untrusted environment, the receiving site has to check that migrated software cannot easily misuse resources. This is typically realized with sandboxing: code that has been downloaded is only allowed to execute in a well-defined space. Direct access to native resources (e.g. memory, files system) is not permitted. This section has highlighted the advantages and the typical overhead that comes with agent mobility. Using this information in the following section qualitative requirements for the successful application of mobile software agents with service creation and deployment are presented.

3 Requirements for Using Mobility One of the most important questions with agent-based service creation and deployment is which service components exactly are supposed to be realized as mobile components. In order to avoid inefficiencies and increased development cost the benefits and drawbacks in terms of performance when using agents have to be considered carefully. Figure 1 illustrates a standard situation with distributed service components. Software components B and A1… An are located at a local site (node N1). Component C is located at a remote site (node N2). B and C use interfaces provided for each other as well as B and A1… An are able to invoke operations on each other.

1

The fact that standard compiler optimizations, like inlining and dead-code elimination, cannot be performed with remote invocation is not addressed here.

Fig. 1. Components in distributed sites

Fig. 2. Component B has migrated

Invocation of operations from B on Ai (or vice versa) can be performed locally. If the components are compiled and linked into one executable (total compilation), standard compiler optimizations can further help to optimize the invocation. Invocation of operations from B on C (or vice versa) cannot be performed locally. As described in Section 2.2, the invocation of a remote operation comes with a latency tinvoc. This latency depends on several factors, including the quality of the connection between B and C as well as the size of the argument and result values. In any case, remote invocation is much slower than local invocation. Now considering Figure 2 where component B has moved to the remote site, the invocation costs have been reversed. Invocation of operations from B on C (and vice versa) is much more efficient than remote invocation between Ai and B. Assuming that B has migrated to the remote site dynamically, compiler optimizations mentioned with local invocation in the previous case, are no longer feasible. Figure 3 illustrates in a qualitative way a communication pattern between the software components introduced in Figure 1. In the first phase, local communication between B and Ai dominates the data exchange. In a second phase, the data exchange is dominated by communication between B and C. Finally, the third phase is identical to the first one.

Fig. 3. Quality data exchange

Fig. 4. Qualitative cost of data exchange (B at N1)

When looking at the cost of data exchange in Figure 4, it becomes obvious that the second phase is much more expensive compared with the other two phases because remote invocation is performed. Figure 5 shows the corresponding cost of data exchange when component B is realized as a mobile agent that can migrate in the second phase to the remote site. Here it is assumed that the service creator has an interest in improving the efficiency of service components and therefore tries to

minimize the integral over t of the cost of data exchange between the communicating service components. The breakeven point is reached when the data exchange related to the communication between components B and C as it would be without migrating B has exceeded data exchange during tmigr Figure 5 shows that migration can in fact result in a much reduced cost function.

Fig. 5. Qualitative cost of data exchange with mobility (B at N2)

The following requirements have to be met in order to reach the breakeven point: Communication between the mobile service component and the remote service components should show a high value of temporal locality in terms of data exchange incurred by control and data flow. In other words, there must be a phase in which data exchange is clearly dominated by communication between the mobile and the remote components. Without such domination the performance hit by tinvoc outweighs the performance savings of local communication. Ideally, the migration to and from a remote site triggers the data exchange between the involved components. In order to minimize the tmigr the mobile component should be loosely coupled with other components so that unregistering the component is efficient. Unregistering a component may require waiting until another component has unlocked the component to be moved. If the component does not initiate the migration by itself, pending computations performed by the component have to be terminated. Some of these computations may only be significant in the local context and do not require to be restarted at the remote site. Other computations could be restarted at the remote site (e.g. for location tracking). Loose coupling refers to very much reduced registration costs. Mobile components should be small in size. Since the size of a mobile agent significantly influences tmigr, reduced size can help to meet the breakeven point earlier. It has to be noted that the agent state can in fact be much larger than expected since pointers in the agent state or code may point to other components. This section provided a qualitative discussion on the seamless integration of mobility into service creation practice. The next section will introduce a mathematical framework for dealing with agent mobility. This framework is used in Section 5 to evaluate two service creation examples.

4 Communication Economics of Agent Mobility This section elaborates on moving a mobile agent between two or more nodes or domains in order to minimize communication cost. Assume two different physical nodes N1 and N2 (see Figures 1 and 2). Node N1 contains a collection of fixed components, which will collectively be denoted by the symbol A and a mobile agent B. Node N2 contains another collection of fixed components denoted by C. Assume that a service involves all three components A, B and C. The objective is to define B's mobility plan. The latter is not influenced by communication between fixed parties A and C, which will thus be excluded from our further analysis. Let U (V) denote the total amount of traffic exchanged between A and B (B and C). Let also f denote the traffic caused by each displacement of agent B from N1 to N2 or vice versa. If B is permanently placed in node N1 (N2), the total communication cost is (proportional to) V (U) only. Let us now consider making B mobile.

Fig. 6. Interaction between fixed and mobile components A, B, C

Fig. 7. Graph model for the computation of B’s position

The traffic pattern created by the pairwise interaction of A, B and C is shown in Figure 6. Assuming (without loss of generality) that in the time interval (to, t1) there is interaction only between A and B, the total volume of interaction is denoted by u1. After that there is another time interval (t1, t2), in which there is interaction only between B and C and the total volume of this interaction phase is denoted by v1, and so on. Then U = u1+ u2 + ... and V = v1 + v2 +.... Now B can move close to A or C in each time interval (tk, tk+1). If we neglect B’s displacement cost, B should better be in node N1 (N2) for even (odd) k in this particular example. Assuming that B is in N1 at time t = to, it must remain close to A in (to, t1). At t1 agent B will face a dilemma: To move closer to C or not? If B chooses to stay near A, the interaction between B and C in the interval (t1, t2) will take place remotely and will thus add a cost of v1 units. Instead the agent can move closer to C at a cost of f units, where f is the cost for moving B from N1 to N2. Decisions take place at times to, t1, t2, ... The situation is represented by the graph of Figure 7, whose nodes denote system states, a state being the position of the agent at a given time instant. If at time ti, the agent B is close to A, the system is said to be in state ai (I = 1, 2, ... K, where K

is the number of interaction phases) while it is in state ci if the agent is close to C. Directed edges denote state transitions. A label associated with a transition denotes the required cost. Let us now calculate transition costs. State a2I implies that B is in N1 and an interaction between A and B will follow. B could stay in N1 and interact with A for free or go to N2 for f cost units and interact remotely with A for an additional cost ui+1. Therefore the label of the edge (a2i, a2i+1) is zero, while the label of (a2i, c2i+1) is f + ui+1. All labels on this graph are calculated similarly. The optimal behavior of agent B can now be calculated: add a node z to the graph and connect it at zero cost with nodes aK and cK. By considering the edge labels as distances, the shortest path from a0 to z implies the optimal behavior of agent B, while the total "length" of the path computes the (minimal) total cost. The structure of this graph can be exploited in order to give a set of recursive formulae. If d(n) is the distance between state n and a0, then: d(a0) = 0 d(a1) = d(a0) d(c1) = d(a0) + u1 + f

d(a2i+1) = min{d(a2i), d(c2I) + f )} d(c2i+1) = min{d(a2i) + ui+1+f, d(c2I)+u i+1} d(a2i) = min{d(a2i-1) + vi, d(c2I-1) + f + vi} d(c2i) = min{d(c2i-1), d(a2i-1) + f }

4.1 Example 1 Two simple instances of the problem are presented. In both there are six interaction phases (K = 6). In the first example the remote processing costs are u1 = u2 = u3 = 3, v1 = v2 = v3 = 2 and the agent displacement cost is f = 1. The resulting graph is shown in Figure 8a. State costs (distances) are shown in bold numbers and bold arrows highlight the shortest path. In this example, agent displacement is relatively cheap and B always moves close to fixed components. Thus an oscillation of B between nodes N1 and N2 takes place. In the second example (Figure 8b) costs are different: u1 = u2 = u3 = 1, v1 = v2 = v3 = 5 and f = 3. A displacement is cheaper than remote interaction with C and more expensive than remote interaction with A. Thus B stays close to A until t1 and then moves close to C, where it stays until the end of the service. Different values of u1, u2, u3, v1, v2, v3 can create more complex mobility patterns.

Fig. 8. Shortest path calculation for the examples

This model can be generalized to an arbitrary number of nodes and fixed components. A collection of components Ai (which without loss of generality can be seen as a single compound component) resides in a node Ni and must interact with an agent B in the i'th phase (ti-1, ti) of a service. Therefore the vector of components A = (A1, A2,..., AM) expresses the sequence of interactions of B with fixed components. Agent B may interact with a component more than once and this event is described by allowing Ai = Aj. The cost of remote interaction with Ai depends also on the location of the agent after completing the interaction with Ai-1. Therefore the remote interaction cost is denoted by ui(k, l) where k indicates the current position of the agent, l indicates the location of the remote fixed component and i indicates the interaction phase. Moreover, the cost of a displacement from k to l is denoted by fkl. The generalization of the algorithm, which solves the problem is straightforward and will be omitted for the sake of brevity. Unfortunately this algorithm creates a graph with M × N vertices, where M is the number of interaction phases and N is the number of different nodes hosting the fixed components. 4.2 Example 2 Let us consider a mathematically trivial, but practically interesting instance of the problem. Assume that the agent moves within a sub-network with flat communication charging, i.e. independent of the distance between network nodes. Thus ui(k, l) depends only on the traffic volume created by an interaction phase i and the agent displacement cost fkl = f, i.e. it is constant. It is easy to show that (for a not very small number of interactions) the agent decides to move or not to move close to the component, which is involved in the next interaction phase, only by comparing the displacement cost f with the remote interaction cost ui.

5 Scenarios for Seamless Mobility Integration Two example scenarios are presented in this section to further illustrate the seamless integration of mobile agents into service creation practice. In both cases, agent mobility will be evaluated in terms of the traffic overhead introduced to the network by the agent’s displacement. The essential entities and associations in the following service provision scenarios are inherited from the TINA Architectural Framework as well as from the enhancements introduced in order to support additional personal mobility features [7]. The two service provision scenarios, also referred to as Business Cases, are built on a context, according to which a user may have subscription contracts with a number of retailers (Home Retailers), but may use services promoted by other Retailers (Visited Retailers) as well. Due to techno-economical or administrative reasons, a Retailer offers services to users inside a domain that may be either the Home or a Visited Retailer Domain depending on the user’s physical location. For simplicity, Home Retailer is assumed to be unique for each user-subscribed service.

In this context, we consider the following scenario. A user is looking outside his Home Domain for a specific service and wishes to access and make use of this service. While in a Visited Domain, the user registers to a terminal that can support the same or a similar service and makes a request for the particular service usage. The terminal is supported by a number of retailers and the user is offered the option to select the most appropriate retailer. The Home Retailer maintains user personal information and a set of service subscription data. Part of the subscription data is service specific while the rest can adapt (within pre-specified limits) to user preferences. Each time the user requests a service, the associated set of parameters (i.e., QoS parameters) may be different than defined at previous requests, thus a new search is required in order to find the most appropriate retailer (Business Case I). This paper considers also the case in which a user needs to access and use a service that is not provided by any of the retailers that serve the area the user is currently roaming (Business Case II). While the service could be realized by establishing a direct connection between the user and the Home Retailer, one can take advantage of the mobile agent technology and download a mobile Service Specific Agent (SSA) to the Visited Retailer Domain. The SSA is responsible for the provision of the service logic of the specific service requested by the user. It is assumed that a federation contract between the Home Retailer and at least one retailer supporting the service in the Visited Domain exists. The advantage of this technical solution is mainly reduced direct communication between the user and the Home Retailer during service operation, thus leading to better performance and to reduced charges. In both scenarios at one point a software entity incorporating intelligence (an agent) travels (migrates) and interacts with modules located at different physical computing locations. 5.1 Agents and Communication Economics in the Context of Business Case I The realization of Business Case I involves the development of two intelligent agents: a mobile Subscribed User Agent (SUA) and a stationary Retailer Agent (RA) and a mobile Service Specific Agent (SSA). The SUA is responsible for the selection of the most appropriate retailer for the specific service use on behalf of the user. To select the most appropriate retailer, the SUA checks which RA offers the lowest expected charge for the same service and the same service parameters. The RA negotiates with the connectivity providers in order to select the best possible tariff for the combination of media involved in the specific service. According to [4], after an access session between the user and the Default Retailer is established, the SUA is instantiated. It is initialized with the user profile, a subset of service specific subscription data and the list of all eligible Visited Retailers that offer the requested service. SUA’s role from this point on is to provide the requested service by selecting the most appropriate retailer on behalf of the user. The SUA replicates itself and these replicas migrate concurrently to the nodes where the candidate retailers reside. The SUA replica interacts and negotiates with the respective RA of each candidate retailer on the basis of service requirements and service offerings that are not fixed. To be more precise, each SUA replica poses one-by-one questions to the respective RA regarding the charge of a fully specified service combination [5].

Let us assume for a moment that the SUA is a fixed agent that resides permanently in the Default Retailer’s Domain. In such a case, the interaction and negotiation between the SUA and each RA will be performed remotely since they are located in different physical nodes. The SUA sends a remote procedure call in the form of a request message to the RA, which in turn receives, executes the procedure and sends back a reply message. The request message comprises a fully specified service combination and a question on the total related charge. The reply message consists of the service combination offered and the estimated total charge. Considering the case of a service that depends on many parameters and grades of freedom, the number of possible service combinations would be very large. Consequently, the number of the exchanged request/response would be very large, introducing a significant overhead to the network. After the SUA have acquired a price for all the acceptable service combinations from each RA, SUA will make a decision on the most appropriate retailer offering the service that satisfies as much as possible the user’s requirements and minimizes the total charge. Figure 9 depicts the interaction process between the SUA and the respective RAs; the messages exchanged between the SUA and each RA constitute a different negotiation’s phase. Node N1 SUA SUA

Node N2 RA RA

Node N3

Node Nn

RA RA

RA RA

First Negotiation phase

Second Negotiation phase

th

N Negotiation phase

Fig. 9. Interaction process between SUA and RAs

In order to estimate the communication cost, we shall henceforth consider one of the negotiation phases between the SUA residing in the Default Retailer’s Domain and the RA residing in one of the visited retailer nodes. The results apply to the rest of the negotiation phases. The cost of communication is proportional to the traffic volume created by an interaction phase, assuming that the cost imposed by the distance between the network nodes where SUA and RA are located is negligible. Since the information volume communicated during a negotiation phase depends on the number of exchanged request-response pairs, the number of transferred messages constitutes an important factor for the estimation of the total traffic. The different acceptable service combinations based on the user requirements encoded in the user’s profile determine this number. Non negotiable requirements limit the set of acceptable combinations while flexible requirements result in an increase of the possible service combinations. Moreover, an estimation of the amount of bandwidth required for the transmission of each request/reply message has to be made. Table 1 provides an estimation for the total communication cost resulting in a negotiation phase in terms of bandwidth requirements along with the quantitative

assumptions for the total number of exchanged messages and the amount of information that is encapsulated within each request/response message. We have considered the case of a service with 20 different acceptable service combinations resulting from requirements imposed by the user. The number of messages exchanged between the SUA and RA within a negotiation phase is 40. Furthermore, we have assumed that the successful completion of a remote procedure call is guaranteed, but this is not always the case as messages may be lost. The unreliable transfer of messages will not be further considered, as this case is out of the scope of this paper. Number of exchanged messages between SUA and RA Amount of information carried within each message Total Communication Cost involved in a negotiation phase in terms of bandwidth requirements

20 req. + 20 rep. = 40 msg. 1 Kbytes 40 Kbytes

Table 1. Estimation of Total Communication Cost in case of Remote Procedure Calling.

Let us now see the advantage of the SUA being a mobile agent. In each negotiation phase, a SUA replica migrates to the identified node where the respective RA is located and interacts locally with it. In that case, the total communication cost is (proportional to) the cost created by the agent displacement if we neglect the local interactions between the SUA and the RA. The estimation of this cost depends on the total amount of information that is encapsulated within the agent. This information would be transported along with the agent’s code and state that would be serialized, transported and restarted at the remote node. The information carried by the SUA at the remote node comprises the different acceptable service combinations along with a criterion parameter, which depends on how the user desires the appropriate retailer to be selected. Making the same assumption on the number of different possible service combinations as in the previous case (where the SUA was a fixed agent), we could easily estimate the consumption of network resources (see Table 2). Number of possible service combinations Bandwidth requirements for each service offer Amount of bandwidth required for the set of acceptable service combinations Size of agent’s code and state after the serialization Total Communication Cost resulting from agent’s migration in terms of bandwidth requirements

20 200 bytes 20 * 200 bytes = 4 Kbytes 2 Kbytes 6 Kbytes

Table 2. Estimation of Total Communication Cost resulting from SUA’s displacement

Comparing the SUA’s displacement cost to the communication cost involved in a negotiation phase, the outweighing of agent’s mobility in our scenario can be concluded. 5.2 Agents and Communication Economics in the context of Business Case II We can see the Business Case II as a natural extension of the first one. The principal idea of this scenario is the fetching of the service logic in the visited domain. This

transfer of information appears to be the best solution to the service provisioning problem only if the desired service cannot be supported by any of the local retailers and if direct communication with the Home Retailer is quite expensive. Consequently, in this service provision scenario two different approaches may be followed in order for the user to access and make use of the desired service. Either the Home Retailer will provide the service to the user or a Service Specific mobile Agent (SSA) will be downloaded to the Visited Retailer Domain. The SSA would be responsible for the provision of the service logic of the specific service requested by the user. The first approach (taking into account the distance between the Home Retailer Domain and the Visited Retailer Domain) results in a huge consumption of the network resources from the beginning until the completion of the service provision. It becomes apparent in such a case that the direct communication between the Home Domain and the Visited Domain leads to inefficient management of network resources. The advantage of the use of mobile agent technology is mainly reduced direct communication between the user and the Home Retailer during service, thus leading to better performance and to reduced charges. Let us for a moment consider the case of a user requesting a flight simulation while being in a Visited Retailer Domain which does not support the requested service. The size of a terrain image generated by using vector graphics is approximately 4 Mbytes. Assuming a transmission rate of 25 frames per second, the resulting bandwidth requirements are 100 Mbytes per second. Service provision to the user by the Home Retailer for 1 hour requires 360 Gbytes of network resources (distance is not taken into account for this calculation). The size of the SSA’s code and state (for the specific service) after the serialization phase is not expected to exceed 100 Mbytes. In the above example, direct communication with the Home Domain results to tremendous consumption as well as inefficient management of network resources. Agent’s mobility, enabling transfer of information to the Visited Retailer Domain, still remains the best solution.

6 Related Work Much research on platforms supporting the development of code mobility and mobile agents has been described. However, research and experience addressing the question when and when not mobile agents should be used (e.g. in telecommunications field) has not been discussed in detail. The sweeping statement is often that mobile agents can optimize network bandwidth usage. Only in few cases the disadvantages of using mobility are actually taken into account and differentiated arguments and empirical results are put forward to actually prove the advantage of mobile agents. Such work is for instance presented by Chess et al. [6] assessing the benefits of mobility against other approaches.

7 Conclusions This paper addresses the problem of seamless integration of mobile agents into service creation practice. A qualitative analysis of the requirements that have to be met in order to benefit from mobility is given. The analysis identifies aspects of that have to be considered when introducing mobility: temporal and spatial locality of communication, loose coupling and small size. The aspect of communication is further discussed within a mathematical framework from which a formula for calculating the optimal behavior of mobile service components is deferred. Two scenarios are used to apply the mathematical framework on the economics of agent mobility. It can be concluded that the results from this work can help to apply mobile agent technology, however more empirical work is necessary to further support and extend the presented ideas in future.

References [1] T. Wild, Best practice in inventory management, Woodhead Publishing, Cambridge, England, 1998 (see also http://www.woodheadpublishing.com/institut/new/bestprac.html). [2] M. Breugst, T. Magedanz: Mobile Agents—Enabling Technology for Active Intelligent Network Implementation, IEEE Network Magazine, Vol. 12, No. 3, pp. 53—60, Special Issue on Active and Programmable Networks, August 1998. [3] S. Arao, M. Honda, A. Kind, J. Nicklisch: Component-Based Policy Deployment for Service Level Differentiation in Converging Communication Networks, Proceedings of the International Conference on Communications (ICC ’99), 1999. [4] ACTS Project MONTAGE (AC325), http://montage.ccrle.nec.de. [5] K. Kiniry and D. Zimmerman: A Hands-On Look at Java Mobile Agents, IEEE Internet Computing, 1(4), pp. 21—30, July/August 1997. [6] D. Chess and C. G. Harrison and A. Kershenbaum: Mobile Agents: Are they a good idea? In Mobile Object Systems—Towards the Programmable Internet, LNCS, pp. 25—47, 1997. [7] B. Wind, M. Sammarotto, P. Nicosia, M. Lambrou, and E. Tzifa: Enhancing the TINA Architectural Framework for Personal Mobility Support. [8] ACTS Project MONTAGE (AC325), CEC Deliverable D21, Context Setting for Agentbased Accounting, Charging and Personal Mobility Support, July 1998. [9] ACTS Project MONTAGE (AC325), CEC Deliverable D23, Algorithms, Design and Implementation of Agent-based Accounting and Charging for the Initial Trial, December 1998. [10] K. Nahrstedt, R. Steinmetz: Resource Management in Networked Multimedia Systems, Computer, 28(5), pp. 52—63, May 1995. [11] S. Albayrak and D. Krisch: Agent-based Travel Information Service, Intelligent Agents for Telecommunications Applications, S. Albayrak (Ed.), IOS Press, pp. 171—185, 1998. [12] IEEE Communications Magazine, Special Issue on Mobile Software Agents for Telecommunications, 36(7), July 1998. [13] J. Nicklisch, J. Quittek, A. Kind, S. Arao, “INCA: An Agent-based Network Control Architecture”, LNCS 1437, Proceedings of the International Workshop on Intelligent Agents for Telecommunications Applications, Springer Verlag, pp. 142—155, 1998. [14] H. S. Nwana, “Software Agents: An Overview”, Knowledge Engineering Review, 11(3), pp. 205—244, 1996.