Design Patterns for Mobile Agent-Mediated E-Business

Xinfeng Yang, School of Information Technology, Griffith University, QLD 9726 Australia. Email: X.Yang@griffith.edu.au

Anne T-A Nguyen, School of Information Technology, Griffith University, QLD 9726 Australia. Email: A.Nguyen@griffith.edu.au

Abstract

Most mobile agent systems in e-business to date have been created in an ad hoc fashion. Little work has explored whether design patterns could be used in this specific domain to capture common solutions to recurrent problems, or to avoid the invention and reinvention of similar strategies by different system designers. This paper suggests a group of design patterns specific to the mobile agent-mediated e-business domain. A set of global forces will be identified. Collaboration among various participants in each pattern will be sketched. The advantages and potentials of suggested patterns for agent-based system design will also be discussed.

Keywords: Internet-based e-business, design pattern, mobile agent.

Introduction and motivation

As self-contained entities, mobile agents have been successfully used to enhance the Internet functions of businesses and to reduce the online search costs of customers. A mobile shopping agent might work for its owner to automatically purchase goods from a series of remote e-markets (Dasgupta et al 1998). A mobile selling agent might work for its supplier to market its commodities to a group of potential clients over an open network (Mandry et al 1999). A virtual business operator might maintain a sound market environment, such that trading agents could conduct business activities with their partners (Tsvetovatyy et al 1997).

However, as Deugo and Weiss (1999) noted, most current agent-based systems are established in an ad hoc manner. The many problem-solving strategies behind each concrete system design are not comprehensively surveyed, leading to common solutions being repeatedly invented and reinvented by different system developers to address the same problems. In addition, a higher-level abstraction above the single agent-level implementation is still lacking, hindering the agent technology from being employed to develop large, industrial strength, applications. Design patterns can be used to document solutions to common problems in an agent-based system design, so that this formatted knowledge can be re-used in similar scenarios (Gamma et al 1994).

Object-oriented design patterns are the major candidates for the agent world. The primary reason for this is that most agent system platforms are written in object-oriented languages (White 1994) and an agent itself can be viewed as an active object with a set of agent-specific properties (Lange & Oshima 1998). Based on these observations, Kendall et al (1998) presented a layered agent pattern, where the proposed seven layers include 'Mobility', 'Translation', 'Collaboration', 'Actions', 'Reasoning', 'Beliefs' and 'Sensory'. Each layer is expected to deal with one specific aspect of agency and every neighbouring pair of layers construct a dependency relationship to help the agent performing various tasks in a complex working environment. However, such a layered pattern merely builds a functional agent at structural level. It fails to consider various system-organisation and coordination functionality that might be important to an agent-mediated system design. A set of mobile agent-based design patterns could be found in (Aridor & Lange 1998). Conceptually, the suggested patterns could be divided into three classes: 'Travelling', 'Task' and 'Interaction'. Within the 'Travelling' pattern class, three concrete patterns are included: 'Itinerary', 'Forwarding' and 'Ticket'. Within the 'Task' pattern category, two specific patterns are identified: 'Master-slave' and 'Plan'. And a set of patterns belongs to the 'Interaction' pattern class -- they are 'Meeting', 'Locker', 'Messenger', 'Facilitator' and 'Organised Group'. The primary aim of such classification, as Aridor and Lange (1998) argued, is trying to 'pragmatically fill in the space between high-level agent-specific languages and system-level programming languages and provide a sound foundation for visual agent development environments'. Unfortunately, proposed patterns did not incorporate agent properties with any domain knowledge. Weiss (2001) presented a group of patterns for agent-based e-commerce applications. As Weiss observed, when a virtual business deals with large volumes of data, resources or knowledge distributed over the network, the whole system might be viewed as a society of autonomous entities that collaborate with each other. Therefore, among Weiss' (2001) suggested patterns, the 'Agent Society' pattern is at the top-level, which tries to address the problem of how to organise a group of collaborating agents in a concrete e-business system. The 'Agent-as-Delegate' pattern works for a single user, which is used to assign time-consuming tasks to a software assistant to reduce search costs and balance overloaded information. The 'Agent-as-Mediator' pattern works for a user group, which is used to facilitate inter-agent communication for business transaction. Collections of lower-level patterns are also presented in each general category. However, these agent-based e-business patterns focus on the static agents only, neither the mobile agent-oriented properties nor mobile agent-based system management are taken into consideration, which is regarded as essential to extend agent-based technology to the Internet-supported applications. In fact, many other associated design patterns in (Lyardet et al 1999), (Rossi et al 2000) and (Fernandez et al 2001) etc. meet the similar drawbacks.

In order to overcome the above limitations, this paper tries to suggest a set of patterns specific to the mobile agent-mediated e-business domain. Most mobile agent-related characteristics, such as mobility, communicability and adaptability, will be considered. Most business roles involved in e-business design will be described: a mobile shopping agent and its homeowner, a stationary market-organiser agent and its travelling visitors etc. A collection of global forces that are regarded as the major factors to push and pull a complex problem to different solutions will be investigated. Roughly speaking, they come from two cross-related fields: the mobile agent computing paradigm and the e-business executing environment.

This paper is organised as follows. Section 2 outlines a refined pattern template and associated global forces that are regarded as unique to the mobile agent-based e-business pattern design. A market-organiser pattern, which defines a general way for the mobile buying agents and selling agents to establish local contact in a virtual market, is presented in Section 3. An agent-side comparison-shopping pattern and a server-side comparison-shopping pattern, which are designed to enhance either a mobile shopping agent's self-routing capability or an agent owner's remote-controlling functionality, are proposed in Section 4 and 5. Section 6 suggests an itinerary-balancing pattern which sketches a route-optimisation scheme for a family of mobile agents working for the same task. Finally, a conclusion is presented in Section 7.

A refined pattern template and global forces

In order to record an explored pattern with some basic components, a pattern template needs to be explicitly specified. In fact, there is currently not a uniform template agreed upon in the pattern design society. Differing templates with different components exist in the literature, such as the formats presented by 'Gang of Four' (Gamma et al 1994) and 'Gang of Five' (Buschmann et al 1996), and the re-formatted templates suggested by Lange and Oshima (1998) and Weiss (2001). This paper employs a combined design pattern template, as illustrated in Table 1, which attempts to include both the essential components of general software design as well as optional components that are desirable for the mobile agent-based e-business system design.

Component	Meaning
Intent	A statement to explain what problem is solved
Applicability	A description of where the pattern may apply
Forces	A group of factors that need to be balanced in the pattern design
Participants	The classes taking part in the explored pattern
Collaboration	The relationship among all participants in the pattern
Consequences	The expected results as well as side effects of the suggested pattern
Implementation	A piece of source code to illustrate how to implement the pattern
Related patterns	References to patterns that share similar contexts

Table 1: A pattern template for mobile agent-mediated e-business design patterns

The above pattern template includes a 'forces' component which is expected to be domain-dependent. As Coplien (1996) described, forces reveal the complexity of a problem, and are supposed to impact the proposed patterns in either a positive or a negative way. A good pattern design needs to encapsulate the forces as much as possible, and describes trade-offs that must be made as well. For this reason, some general 'forces' in the study domain need to be investigated before concrete design patterns are explored. In the following part, a number of global forces that are specific to the mobile agent-mediated e-business pattern design will be identified, where some come from mobile agent specification and others come from e-business system maintenance.

Market openness and service quality

One obvious advantage of employing the Internet lies in its openness--artificial boundaries between suppliers and buyers in the physical world become indistinct. Representatives from different locations could negotiate directly and carry out business activities locally. However, with more and more agents gathering at a specific online market, the market management problem appears which may lead to improved quality of services. On the one hand, the market operator is required to provide an open business environment for all the visiting agents to search for their preferred products and services. On the other hand, it is desirable for the market manager to help agents with similar interests to locate each other's business partners for group-trading and negotiation purpose. In other words, the market operator has to serve both the general agent visitors and some specific agent trading groups.

Free mobility and self-control capability

One of the major characteristics of a mobile agent is its capability of searching the Internet and visiting a set of remote hosts, according to a pre-defined itinerary. So it is possible, and desirable, to objectify a mobile agent's itinerary module to facilitate reuse. In a mobile agent-based e-business application, the major work of these shopping delegates is navigating among a number of remote vendors' sites and collecting product information for their owners. Therefore a mobile agent's pre-defined itinerary is always affected by the agent's business activity along the way. Incorporating a mobile agent's self-navigation capability with its business environment en route is a general solution for the mobile agent-based trading system design. The primary aim of such arrangement is to improve a mobile agent's adaptability in complicated market conditions while maintaining the reusability of its modularised navigation plan.

Remote delegation and effective management

Remote delegation is regarded as an important application of agent technology. A mobile agent might represent either a customer or a vendor to travel around the network performing a pre-defined task. The potential advantages of this application could be summarised as light-weight travelling, goal-oriented driven, disconnected operations. Nevertheless, there is still considerable reluctance to adopt mobile agents for such purposes. One major reason has been the security issues involved in allowing the relevant agent to visit remote hosts. A dishonest agent host may analyse a visiting agent's decision-making policy illegally and/or alter its carried information maliciously. Mobile agent protection against malicious hosts remains an open issue in the agent research community. Before this problem is fully addressed, an agent owner has to enhance its control over its child agent's behaviours remotely. One possible solution is to hide some vulnerable information from remote hosts and withdraw some decision-making functions from the travelling agent site to its home site. Admittedly, performance degradation is the major drawback that of this arrangement.

Group delegation and inter-group collaboration

There are two ways for a user to delegate a task to its agents: single delegation and group delegation. For the single delegation, a single agent represents its user, travelling among a set of remote markets in sequence. Technically, it is a kind of sequential computing. For the group delegation, a group of agents are dispatched to a collection of destination-markets. They are expected to stay there and carry out pre-assigned tasks. Such practice could be viewed as a kind of parallel computing. However, in a mobile agent-based e-business environment there are too many online markets available, dispatching a single agent to visit all of them is extremely time-consuming, whereas generating the same number of mobile agents for all the available markets is not efficient either. A common solution is to combine these two forms of delegation dynamically, where a user sends out a limited number of worker agents and they visit available online markets in parallel. Indeed, such an agent group forms an agent family that belongs to the same user and works on the same task. In that case, inter-group collaboration seems quite desirable. Taking the itinerary as an example, the inter-group collaboration needs to make sure the same destination is visited by one of the group members once only. Itinerary balancing is also necessary in order to improve the overall performance of the whole group.

Items presented above are only part of the forces that are observable in the mobile agent-based e-business domain. They demonstrate the complexity of applying mobile agent technology into the e-business field. A successful pattern design is expected to address these problems in a considerate way with the aim of resolving these forces as much as possible. In the following sections, four associated patterns will be suggested: a market-organiser pattern, two comparison-shopping patterns and an itinerary-balancing pattern. All of them will be described and analysed based on the pattern template illustrated in Table 1.

Market-organiser pattern

Intent

The market-organiser pattern provides a way to help seller agents and buyer agents with similar interests to establish local contacts on a specific marketplace more conveniently.

Applicability

This pattern can be employed in the following cases:

When a market operator wants to provide a uniform interface to all the visiting customers to simplify their access to the available services.

When a market operator agent wishes to manage its trading environment in an easy-controllable and easy-extensible manner.

When a market operator tries to organise all the visiting agents based on their interests in order to improve the efficiency of their local communication.

Forces

Market openness and service quality

Participants

Figure 1 shows the structural relationships among the participants of this pattern.

MarketGuide: This object works as a market-guide providing a uniform interface to all the visiting agents and presenting a general directory of all the available trading groups.

TradingGroup: This object is responsible for storing the information associated to all the active agents in a trading group, and keeping the records up to date.

VisitingTrader: This is a concrete mobile agent class, representing either a buyer or a seller visiting a specific market context and expecting to meet business partners there.

Lookup: This is a mobility listener used to equip each mobile trading agent for responding to various mobility events.

Figure 1: Participants in the market-organiser pattern

Collaboration

Collaboration among the participants in this pattern is sketched in Figure 2.

Whenever a mobile seller or buyer agent arrives at a new marketplace, an 'onArrival' method in the 'Lookup' listener is triggered.

A 'marketGuide' object handles a 'Search' message from the newcomer and is responsible for locating a proper trading group for it.

A 'tradingGroup' object searches for the backend database, and implements the 'establish' method to retrieve all the available partners in a proper trading group.

A 'visitingTrader' object enters the group after obtaining all the retrieved partners' proxies from the 'tradingGroup''s reply.

Whenever a mobile trader agent wishes to leave the market, it triggers an 'onDispatching' method in the 'Lookup' listener.

The 'tradingGroup' object erases the leaving agent's identity from the corresponding group after receiving an 'exit' message, the corresponding database is then refreshed.

Figure 2: Collaboration in the market-organiser pattern

Consequences

The market-organiser pattern has the following benefits and drawbacks:

This pattern can be employed at the market manager side to improve its service quality. The functionality of a traditional market guide is extended to help multiple seller and buyer agents in the same market to search for each other's trading partner. This kind of group-trading environment is more like a chat-room with a specific topic. Participants within each room share similar interests, and their communication will not be subject to interference from outside conditions. The market operator takes over all the dirty work such as information filtering and partners locating. Such negotiation places can be created on the fly.

The suggested pattern also has some drawbacks. At first, the identifier of each trading group is difficult to be standardised, especially for those temporary groups generated at run time. A menu-like multilevel location technique might be a possible solution, however, which in turn adds to the complexity of the market organiser's work. Besides, it is not easy to help an agent with more than one interest to look for all of its trading partners at the same time. Proxy cloning is possible but the management work for duplicated proxy becomes more complicated for the market operator.

Implementation

There are four basic classes in the market-organiser pattern. Detailed implementation will be omitted here. A brief summarisation will be given below.

The 'marketGuide' class registers itself with a well-known name on the network, initialising a set of trading spaces and making them accessible to all its visitors. For the 'Search' message from an incoming agent, it will send the 'Establish' result from a specific 'tradingGroup' as a reply.

The 'tradingGroup' class maintains a sellers-database and a buyers-database for each trading group. For the 'Establish' command from the 'marketGuide', it will send back a proxy list for sellers or buyers that are currently active in the group. For the 'Exit' message from a leaving agent, the backend databases will be refreshed accordingly.

The 'Lookup' class extends 'MobilityAdapter', which takes a proxy reference to a concrete mobile agent from its constructor. Two specific methods 'onArrival' and 'onDispatching' are overridden. The former is triggered when a mobile agent arrives at a new market and starts searching for its partner. The latter is called when the agent tries to exit the trading group before leaving. The whole class is supposed to be plugged into an arbitrary trader agent in a ready-to-use fashion.

The 'visitingTrader' class is a base class for the mobile trading agent. It gets an instance of the 'Lookup' listener upon being created. When 'running' in a remote marketplace, the agent tries to register itself as a member in a specific trading group. When completing its given task and preparing for leaving, the agent de-registers from the market organiser's database.

Related patternst

This pattern is inspired by the Meeting pattern defined by Aridor and Lange (1998), where agents could establish local interactions on a specific context. However, the primary aim of the Meeting pattern is to synchronise behaviours of the agents coming from different origins, so the destination ID and partner ID are two principal arguments to help them locating each other. The market-organiser pattern does not assume a visiting agent belongs to any specific group in advance, but provides a uniform interface for all the visiting agents. An incoming trader agent (seller or buyer) may choose a proper group to join in and local communication will be easily established. To some extent, the 'Lookup' listener and the 'marketGuide' object in the market-organiser pattern encapsulate more basic functionality unique to a real virtual market than the meeting manager object suggested in the Meeting pattern. As a known use, this pattern has been successfully employed in a mobile agent-mediated e-shopping system suggested by White (1994). A mobile shopping agent visits different shops in a large e-market to look for its preferred products. Each shop is designed for a specific commodity; all participants in the same shop can exchange information straightforwardly. In the proposed market-organiser pattern, detailed inter-group communication mechanism is ignored, while the trading group organisation functionality is clarified.

Agent-side comparison-shopping pattern

Intent

The agent-side comparison-shopping pattern defines a mobile agent-mediated e-shopping scheme where a mobile shopping agent is equipped with an objectified itinerary and a simplified self-navigation module.

Applicability

This pattern can be employed in the following cases:

When an agent owner wishes to objectify a mobile agent's itinerary and define the agent travelling plan in an easy-extensible and easy-manageable fashion.

When an agent developer wants to enhance a travelling agent's self-navigation capability after it is dispatched into the network and carries out tasks remotely.

When a system designer tries to separate an agent's travel plan from other task-delegation functions in order to improve the maintainability of the whole routing module.

Forces

Free mobility and self-control capability

Participants

Figure 3 shows the structural relationships among the participants of this pattern.

Routing: This is an abstract class that provides a common interface for all the travelling shopping agents with a set of abstract methods defining various routing functions.

myRouting: This class implements the abstract methods defined in the abstract 'Routing' class, comparison-based routing strategies will be specified in order to meet diversified shopping requirements from the agent owner.

shoppingAgent: This is a concrete mobile agent class, which represents a shopping agent travelling around the Internet to collect relative information for its owner. It can decide whether to continue its journey or not based on the collected information and comparison result en route.

Figure 3: Participants in the agent-side comparison-shopping pattern

Collaboration

Collaboration among the participants in this pattern is sketched in Figure 4.

After being created, a shopping agent invokes a 'move' method in its routing class, which will dispatch the agent to its first destination -- remote marketplace 'A'.

The shopping agent carries out 'doCollection' task in the target market and transfers the collecting results to its routing module for 'comparison' purpose.

After comparing the collected offer with a pre-set value, a 'goWhere' method is triggered which will retrieve the next available destination to visit. And finally, the shopping agent is dispatched to the second marketplace 'B'.

The same scenario will happen in the Market 'B'. The shopping agent calls 'doCollection' method, and the routing module fulfils 'compare' and 'goWhere' functions.

The comparison result suggests the shopping agent stop its journey, therefore it will be sent back home from market 'B', not go on its trip to the next proposed destination -- market 'C'.

Figure 4: Collaboration in the agent-side comparison-shopping pattern

Consequences

This pattern has the following benefits and drawbacks:

The agent-side comparison-shopping pattern tries to capture the basic functionality of a mobile shopping agent in an Internet-based e-business environment. Variations of this pattern can be objectified and plugged into a travelling agent in a ready-to-use style. Based on the same destination set, an agent designer may specify different routing strategies to improve its flexibility. In addition, it demonstrates certain feasibility to link an agent's travelling plan with its delegation tasks. Thus an agent can adjust its routing behaviour based on its observations along the way.

The suggested pattern has an obvious drawback. The mobile agent is equipped with both the itinerary information and the self-routing strategy in its memory. Such arrangement brings serious security risks. Because an agent is nearly subordinate to its working platform, a visited host might dishonestly prevent the agent from visiting its competitor's host, or maliciously alter associated information to cheat the agent owner. A possible solution might be using a server-side comparison-shopping pattern discussed in the following section, which withdraws some decision-making functions from the agent-side to its owner's side.

Implementation

There are three basic classes in the agent-side comparison-shopping pattern. Detailed implementation will be omitted here.

The abstract 'Routing' class implements 'Serializable' because the routing object is supposed to be transferred with the shopping agent together. It has a constructor to set the information of the mobile agent's home address and holding a reference to the agent's proxy, which will be used to dispatch the agent to its next destination or send it back home. A couple of abstract methods will be defined explicitly in this class.

The 'myRouting' class extends the generic 'Routing' class. It takes an agent's home address and a routing vector as arguments in its constructor. Two abstract methods defined in the abstract routing class will be implemented here. A 'compare' method is used to compare two input values, whereas a 'goWhere' method is used to retrieve the next available host-address. Both methods are ready to be overridden by different system developers to enrich their individual strategy.

The 'shoppingAgent' class is a simplified mobile agent class extending 'Aglet'. It initialises a routing module with its proxy and instantiates a mobility listener in its constructor. A 'doCollection' method is also implemented which is expected to take a shopping-item string to query a local market operator and perform collection tasks after arriving at a new destination.

Related patterns

This pattern is inspired by the Itinerary pattern defined by Lange and Oshima (1998), where an objectified agent itinerary is used to help a mobile agent travelling among a set of destinations. However, as a static itinerary module without any routing functionality is seldom useful, extending this general pattern with certain self-navigation characteristic seems essential to enhance its operability. In the mobile agent-mediated e-business system design, comparison-shopping function with self-routing capability can be found in many existing systems such as in (Dasgupta et al 1999), (Mandry et al 1999) and (Nguyen et al 2001). In these applications, a mobile agent travels around the Internet, collecting associated information about its preferred products, and then continuing its journey to the next available marketplace. It has been viewed as a classic prototype to demonstrate the applicability of employing mobile agent technology into the e-business field. The suggested agent-side comparison-shopping pattern tries to capture a common solution to this recurrent scenario. A comparison-shopping function and a conditioned-routing function are designed separately but retain some linkage, which improves its feasibility and reusability.

Server-side comparison-shopping pattern

Intent

The server-side comparison-shopping pattern defines another mobile agent-shopping scheme where a home shopper assigns the information-collection task to an itinerant agent but controls its travelling plan from home.

Applicability

This pattern can be employed in the following cases:

When a home shopper wishes to dispatch a shopping agent to a series of marketplaces collecting information about certain products or services.

When an agent owner wants to control a remote working agent's itinerary.

When a mobile agent does not want to carry too much sensitive information along its journey.

Forces

Remote delegation and effective management

Participants

Figure 5 shows the structural relationships among the participants of this pattern.

Collector: This is a concrete mobile agent class providing a simplified skeleton for an information-collecting agent. A 'doCollection' method is used to define its task-delegation capability. Different information-collection approaches will be implemented, querying results are to be sent back home immediately.

homeShopper: This is a stationary agent class which is responsible for generating a mobile collector agent and controlling its visiting itinerary based on its collected information, and finally disposing it off at a remote site.

Policy: This class is a separate functional module implementing the concrete server-side decision-making scheme. Collected offers will be used for comparison, and a suggested destination will be worked out to direct the collector agent's following trip.

Figure 5: Participants in the server-side comparison-shopping pattern

Collaboration

Collaboration among the participants in this pattern is depicted in Figure 6.

A home shopper creates a mobile shopping agent (Collector) and dispatches it to the first remote market 'A'.

The collector agent contacts the local market operator, collecting related information about certain products and sending the results back home.

The 'Policy' module in the server-side is called, a 'compare' method and a 'goWhere' method are employed to decide whether the collector agent needs to go on its journey and where to go for the next stop.

The collector agent is dispatched to the next market 'B', repeating the same work and sending the results back.

The 'compare' method in the 'Policy' module is invoked again, a decision is made to stop the collector agent's trip.

The home shopper disposes off the collector agent remotely.

Figure 6: Collaboration in the server-side comparison-shopping pattern

Consequences

This pattern has the following benefits and drawbacks:

The server-side comparison-shopping pattern provides a generic structure for remote delegation. It hides two types of sensitive information from the remote hosts: well-designed itinerary and decision-making policy. Although the proposed pattern is called 'comparison shopping' and used for a home shopper, it is also feasible for an itinerant agent representing a supplier to visit remote client hosts if only the 'doCollection' method is replaced. It helps a homeowner performing strong control on its worker agent over the network. Normally, the delegated task is simple and the itinerant agent is light.

The presented pattern also has some obvious drawbacks because of the strong control over an itinerant agent. At first, the expected flexibility of a free-roaming agent is seriously hindered. A remote mobile agent has to depend on frequent two-way communication to get the information to continue its journey. Two other problems observable are the working efficiency and communication reliability when choosing this pattern for remote delegation purpose because the delegating agent relies on its home-owner's decision too heavily.

Implementation

There are three basic classes in the server-side comparison-shopping pattern. Detailed implementation will be omitted here.

The 'Collector' class is a base mobile agent class extending 'Aglet', which takes a reference to the home shopper's proxy in its constructor. In its 'onCreation' method, it is equipped with some shopping requirements, which will be used to query the local market operator when 'running' at a remote host and performing 'doCollection' task for its home owner.

The 'homeShopper' class creates and initialises a collector agent with a reference to its proxy and a shopping item string. At the same time, it holds a reference to the 'Policy' object. The current location of the collector agent will be tracked since the agent is dispatched. All the 'dispatch' commands and the final 'dispose' command will be issued from this class.

The 'Policy' class is a modularised decision-making class used on the server side. It maintains a vector with a set of initialised destinations. A 'compare' method is implemented which compares the current offer with a pre-defined expected value. The comparison result will be used in a 'goWhere' method for selecting the next available destination stored in its itinerary vector. The whole class can be viewed as functional module taken from the agent side to the server side.

Related patterns

This pattern is inspired by the Master-Slave pattern defined by Lange and Oshima (1998), where a master agent can delegate a task to a slave agent and control its life cycle. However, when applying this master-slave pattern in the mobile agent-mediated e-business environment, a serious security concern arises because a travelling slave agent carries too much sensitive information in its memory. Among these pieces of information, the mobile agent's pre-defined itinerary and its decision-making policy are two major targets of a dishonest agent host or a malicious third party over the network. The proposed server-side comparison-shopping pattern successfully hides the vulnerable information from the possible attackers. A collector agent follows the command from its owner step by step. The information collected en route will be sent back home immediately and used to compute its next destination. Therefore most attacks launched by a malicious entity become invalid. A known use for this pattern can be found in a mobile agent shopping system suggested by Mandry et al (1999) where private decision-making strategy is suggested to be carried out at home site to satisfy the security requirement. Another obvious advantage of such arrangement is that the proposed mobile collector agent becomes lighter and simpler after these pieces of information taken out of its memory.

Itinerary-balancing pattern

Intent

The itinerary-balancing pattern defines a route-optimisation scheme for a family of mobile agents belonging to the same user and working for the same task.

Applicability

This pattern can be used in the following cases:

When a stationary agent wants to delegate its task to a group of mobile agents who are expected to perform the same task at a number of destinations.

When a group of mobile agents working at different hosts wish to share itinerary information with one another.

When a group of agents need a route balancing mechanism to help them filtering redundant addresses for accomplishing a given task within the group.

Forces

Group delegation and inter-group collaboration

Participants

Figure 7 shows the structural relationships among the participants of this pattern.

itineraryLog: This object runs on a well-known server with a unique identifier. It maintains an itinerary log for a group of agents that have the same job ID. Its major responsibility is helping each individual agent to optimise its itinerary based on the consideration about other group members' itinerary plan.

Employer: This is a basic mobile agent class. A group of employer agents working for the same owner carry out the same task at different destinations. Each agent is able to migrate from one host machine to another while the whole group works in a parallel manner. Inter-group coordination is required to help the group members accomplishing the given task efficiently.

doubleCheck: This class works as a reusable mobility listener which can be used to plug into each agent body responding to various mobility events, especially when the agent arrives at a new destination or leaves for its next stop.

Figure 7: Participants in the itinerary-balancing pattern

Collaboration

Collaboration among the participants in this pattern is depicted in Figure 8.

A group of mobile agents is created and dispatched to a set of remote destinations. Each of them is assigned a unique job ID and equipped with a 'doubleCheck' listener. When an agent arrives at a new destination, an 'onArrival' method in the listener is triggered.

The 'doubleCheck' listener calls a 'doUpdate' method in a 'itineraryLog', which is responsible for registering the agent's current location and corresponding job ID to a backend database.

The 'Employer' agent carries out its task at the current host and gets a list of potential destinations suggested by that host. Before migrating to its next destination, the agent calls the 'check' method to double check its itinerary for inter-group itinerary balancing purpose.

When a 'doBalance' method in the 'itineraryLog' is triggered, the 'itineraryLog' retrieves a number of itinerary plans reported from all the agent members in the same group, a redundant destination will be deleted, a balanced destination will be returned, and finally the corresponding database is refreshed.

Figure 8: Collaboration in the itinerary-balancing pattern

Consequences

The itinerary-balancing pattern has the following benefits and drawbacks:

Benefits of the proposed pattern can be summarised in two aspects. From the task delegation perspective, it provides a generic structure to combine the advantages of single-sequential computing and group-parallel computing together. Improved working efficiency is an obvious merit. From the inter-group collaboration perspective, a centralised 'itineraryLog' coordinator is introduced which helps to optimise multiple agents' itinerary through redundancy filtering and information balancing. A family of agents can use this pattern to coordinate their travelling plan within the group and without their owner's direct involvement.

The suggested pattern also has some limitations. At first, the coordination activity is heavily reliant on a centralised 'itineraryLog', which is easy to become a bottleneck for the overall system performance because frequent communication presents a serious drawback on the system reliability. In addition, the applicability of employing such a pattern on other inter-group collaboration tasks remains an uncertain issue. Due to the diversity of the delegation tasks, it is difficult for the central coordinator to provide a standardised solution in all circumstances.

Implementation

There are three basic classes in the itinerary-balancing pattern. Detailed implementation will be omitted here.

The 'itineraryLog' class registers itself with a well-known address and makes its proxy available to the public. It establishes a separate database (in Hashtable) for each agent group, job ID is the key, 'history' record and 'future' plan from all group members are recorded in its two inner vectors. Two specific methods have to be implemented properly: 'doUpdate' and 'doBalance'. The 'doUpdate' method only updates the history record while the 'doBalance' method will check both history data and future itinerary and return a balanced result.

The 'doubleCheck' class extends 'MobilityAdapter', which takes a reference to the 'itineraryLog' proxy and a job ID string from its constructor. The 'onArrival' method is overridden which will be triggered when an employer agent arrives at a new destination. The 'check' method also needs to be implemented, which sends a message to the remote 'itineraryLog' with a list of visiting plan and waits for the reply.

The 'Employer' class is a base class for one of the agent members. It gets an 'itineraryLog' proxy with a unique job ID in its constructor. A mobility listener 'doubleCheck' is initialised and plugged into the agent's memory. When 'running' at a remote platform, it is required to retrieve some itinerary plan from the current host. This retrieved plan will be sent to the 'itineraryLog' for optimisation before the agent is ready to leave.

Related patterns

This pattern is inspired by the Blackboard pattern presented by Deugo et al (2001), where a 'blackboard' component is provided for a collection of agents to monitor each other's behaviours and mutual progresses. However, a blackboard's function is limited to message notification, which seems rather passive. Additionally, implementing a blackboard pattern in a distributed environment is not an easy task because it lacks a proper management mechanism. In a mobile agent-mediated e-business situation, a group of mobile agents needs a more functional arrangement to coordinate each other's visiting plan. On the one side, a free-travelling agent may encounter many copies of advertising agents at different hosts that may guide the agent to visit the same origin. On the other side, the number of candidate destinations retrieved at each visited site is naturally unbalanced. Therefore the 'itineraryLog' is just designed as a centralised coordinator to perform both the redundant-itinerary filtering and the overall-plan balancing work.

Conclusion

This paper presents a collection of mobile agent-mediated e-business design patterns. To overcome the limitations of most current approaches which simply apply object-oriented techniques for the agent-based e-business pattern design, we suggest viewing the mobile agent-mediated e-business domain as an organic whole. A set of global forces that is unique to this area is identified. Four design patterns are proposed which are related to virtual market management, agent-based shopping and agent-to-agent collaboration respectively. The consequent analysis and some known uses demonstrate the benefits and drawbacks of suggested patterns in concrete system design. This pattern list might be continually extended as the requirements and trade-offs involved in this area are better understood in the future.

References

Aridor, Y. and Lange, D. B. (1998), ‘Agent Design Patterns: Elements of Agent Application Design’, Proceedings of the 2^nd International Conference on Autonomous Agents (Agents '98), St Paul, USA, pp. 108-115.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M. (1996), Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, Chichester.

Coplien, J. O. (1996), Software Patterns, SIGS Books & Multimedia, New York.

Dasgupta, P., Narasimhan, N., Moser, L. E. and Melliar-Smith, P. M. (1998), ‘A Supplier-Driven Electronic Marketplace using Mobile Agents’, Proceedings of the 1^st International Conference on Telecommunications and Electronic Commerce, Nashville, USA, pp. 42-50.

Dasgupta, P., Narasimhan, N., Moser, L. E. and Melliar-Smith, P. M. (1999), ‘MAgNET: Mobile Agents for Electronic Trading’, IEEE Transactions on Knowledge and Data Engineering, Special Issue on Web Technology, Vol. 11, No. 4, pp. 509-525.

Deugo, D. and Weiss, M. (1999), ‘A Case for Mobile Agent Patterns’, Proceedings of the Workshop on Mobile Agents in the Context of Competition and Cooperation (MAC3) at the 3^rd International Conference on Autonomous Agents (AA'99), Mineapolis, USA, pp. 9-22.

Deugo, D., Weiss, M. and Kendall, E. (2001), ‘Reusable Patterns for Agent Coordination, in Coordination of Internet Agents: Models, Technologies, and Applications, eds A. Omicini, F. Zambonelli, M. Klusch and R. Tolksdorf, Springer-Verlag, Berlin, pp. 347-368.

Fernandez, E. B., Liu, Y. and Pan R. Y. (2001), ‘Patterns for Internet Shops’, Proceedings of the 8^th Conference on Pattern Languages of Programming (PLoP'01), Monticello, USA, Available Online: [HREF1] [2004 Feb. 24].

Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1994), Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading.

Hohl, F. (1998), ‘A Model of Attacks of Malicious Hosts against Mobile Agents’, Proceedings of the 4^th Workshop on Mobile Object Systems: Secure Internet Mobile Computations, Brussels, Belgium, pp.105-120.

Kendall, E. A., Murali-Krishna, P. V., Pathak, C. V. and Suresh, C. B. (1998), ‘Patterns of Intelligent and Mobile Agents’, Proceedings of the 2^nd International Conference on Autonomous Agents, St. Paul, USA, pp. 92-99.

Lange, D. B. and Oshima, M. (1998), Programming and Deploying Java Mobile Agents with Aglets, Addison-Wesley, Reading.

Lyardet, F., Rossi, G. and Schwabe, D. (1999), ‘Patterns for Adding Search Capabilities to Web Information Systems’, Proceedings of the 4^th European Conference on Pattern Languages of Programming and Computing (EuroPLoP'99), Irsee, Germany, Available Online: [HREF2] [2004 Jan. 25].

Mandry, T., Pernul, G. and Rohm, W. A. (1999), ‘Mobile Agents on Electronic Markets Opportunities, Risks and Agent Protection’, Proceedings of the 12^th International Bled Electronic Commerce Conference, Bled, Slovenia, pp.1-13.

Nguyen, A., Stewart, I. and Yang, X. (2001), ‘A Mobile Agent Model: Applications for E-Commerce’, Proceedings of the 7^th Australian World Wide Web Conference, Coffs Harbour, Australia, pp. 247-258.

Rossi, G., Lyardet, F. and Scheabe, D. (2000), ‘Patterns for E-commerce Applications’, Proceedings of the 5^th European Conference on Pattern Languages of Programs (EuroPLoP'00), Irsee, Germany, Available Online: [HREF3] [2004 Jan. 17].

Tsvetovatyy, M., Gini, M., Mobasher, B. and Wieckowski, Z. (1997), ‘MAGMA: An Agent-Based Virtual Market for Electronic Commerce’, Journal of Applied Artificial Intelligence, Vol. 11, No. 6, pp. 501-524.

Weiss, M. (2001), ‘Patterns for E-Commerce Agent Architectures: Using Agents as Delegates’, Proceedings of the 8^th Conference on Pattern Languages of Programming (PLoP'01), Monticello, USA, Available Online: [HREF4] [2004 Feb. 29].

White, J. E. (1994), ‘Telescript Technology: The Foundation of the Electronic Marketplace’, General Magic White Paper 1994, General Magic, Inc., USA.

Hypertext References

HREF1: http://jerry.cs.uiuc.edu/~plop/plop2001
HREF2: http://www.argo.be/europlop/index.html
HREF3: http://www.coldewey.com/europlop2000
HREF4: http://www.scs.carleton.ca/~weiss

Copyright

Xinfeng Yang and Anne T-A Nguyen © 2004. 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.