On the Design of a Mobile Agent Web for Supporting Virtual Enterprises
Ad Aerts, Nick Szirbik, Dieter Hammer, Jan Goossenaerts, Hans Wortmann
Eindhoven University of Technology, Postbus 513, 5600 MB Eindhoven, The Netherlands
{a.t.m.aerts ; d.k.hammer}@tue.nl, {n.b.szirbik ; j.c.wortmann ; j.b.m.goossenaerts}@tm.tue.nl
Abstract
In this paper we discuss the design of a mobile
agent based infrastructure for monitoring and
controlling activities in a Virtual Enterprise (VE). We
define the concepts of the Virtual Enterprise and the
Mobile Agent Web (MA-web).
1. Introduction
New organizational concepts pose new challenges to
the ICT systems supporting them. In a Virtual
Enterprise (see section 2) one of the challenges is to
provide flexible support for the co-ordination and
integration of the ICT systems of each of the participant
enterprises without imposing excessive demands on the
systems of these participants. In section 3, we discuss a
design for the integration of the ICT support systems
for a Virtual Enterprise (VE). The design is based on
the mobile software agent paradigm [8] and is one of
the results of an interdisciplinary research project,
named ROVE (Reasoning about Operations in Virtual
Enterprises) at the Eindhoven University of
Technology. We have started to develop a Concordia
[1] platform-based prototype named PROVE (Prototype
for ROVE [10]). The role of the prototype is to identify
the problems, which appear in the Virtual Enterprising
process, and to find the best architectural patterns for
the flexible integration of ICT support systems for
VE’s. We do not discuss alternatives for the mobile
software agent paradigm in this paper (see [8]). Section
4 concludes the paper with some open issues.
2. The Virtual Enterprise
The concept of the Virtual Enterprise is rather novel
and there exist different views about it. We will first
present two examples of Virtual Enterprising and then
discuss the VE and the requirements it poses on its ICT
support. The formation of the VE is not a topic of this
paper. We assume it to be in place. In particular, we
assume that the participants are willing to cooperate
and share data.
2.1 Two examples of Virtual Enterprising
Consider the case of a commercial jet that needs
replacement of a high-value part like an undercarriage,
because the old one was damaged in a rough landing.
International regulations prohibit the airline to repair
this part of the plane by replacing only the severely
damaged components and tinker with the slightly
damaged ones. They ask for a full replacement of the
landing gear. Because the airline companies usually do
not keep spare undercarriages in stock, the airline has
to order a new undercarriage in this situation. The
problem is that 80% of the global commercial fleet
consists of aircraft, which are no longer in production.
Worse still, many of the companies who built the
planes are not on the market any more.
However, the market of high-value replacement
parts is very active. The manufacturing of such parts
requires the collaboration of a number of companies,
which join forces for this particular purpose. For an
undercarriage, about a dozen companies are involved,
which are typically located on different continents.
Note that this case is characterised by a one-of-a-kind
assemble-to-order style.
Consider now the case of a group of specialized
enterprises that sells office furniture, such as desks,
filing cabinets, computers, and other accessories, and
has started a collaboration to offer complete office
solutions via the Internet. Through a Web-portal,
complete workplaces for one or several office workers
are offered, with a choice of popular colours and styles.
Customers, who want to expand an existing branch
office or open a new one, can order any number of
workplaces at a time. The order is split at the Web
portal into sub-orders for the participant companies,
depending on such factors as product and availability of
resources. The products are assembled and sent to a
distribution centre near to the customer, where the
order is collected for delivery. This case is batch
oriented.
 2.2. A definition of the Virtual Enterprise
From the examples above we see that a VE caters to
markets that the individual participants by themselves
cannot access: they need to collaborate. Moreover, the
VE is not their main business, but just a collateral
activity that helps them to fill the gaps in the usage of
their resources, to participate actively in new, global
markets, and to virtually extend their resource types.
This is due to the fact that opportunities leading to
Virtual Enterprising are hard to forecast. For example,
it is impossible to forecast when a landing gear will
break and need replacement. The participants thus will
commit only a small fraction of their resources to the
VE. Virtual Enterprising requires a lot of flexibility and
therefore is based on a global agreement, not on
detailed contracts. To increase the flexibility of the VE
and to avoid orders from being rejected, because the
required resources aren’t available at the right time,
some redundancy of resources should exist and more
than one company with a given production capability
should participate in the VE.
Our definition of a Virtual Enterprise is related to
the concept of virtual capability [9]:
“A group of enterprises, which has the capability of
realising in a collaborative manner, items or services
from a limited portfolio of products, is a Virtual
Enterprise.”
The composition of the group is dynamic.
Enterprises may join or leave the group. The definition
above does not capture the state of a given VE at a
certain moment in time. We introduce a new concept
for that:
“A group of enterprises, members of a bigger
Virtual Enterprise, which is currently involved in the
execution of an order for a customer, is a Cluster.”
Many Clusters can be simultaneously active in a
Virtual Enterprise. The selection of the members of a
Cluster depends on how their resources can be used, in
terms of available time-slots, stocks, past performance,
prices, and possibly customer preference.
For the ICT support of collaborative processes, we
need a structured approach to identify the requirements,
the architecture, and the problems of Virtual
Enterprising.
2.3 Requirements for ICT support for a VE
The business process in a VE starts with an order by
a customer for a composite product, be it a landing gear
or the complete furnishing of an office. The order has
to be decomposed into suborders, which are dispatched
to the participants in the VE, which may be regarded as
subcontractors for a specific component. The
decomposition will follow the BOM (Bill of Material)
of the product ordered by the customer, until a
component is reached that can be produced by a single
enterprise. In a VE, one wants to monitor the process of
the decomposition of the order of a particular customer
and the production of the product ordered [10]. In
addition, one wants to provide decision support for the
management of problems, originating for example from
the fact that one enterprise cannot meet its delivery
date, and has to be replaced by another one in the VE.
The resolution of such problems requires co-operation
among the participants, e.g., to reach an agreement
about who will pay for possible additional costs
incurred by a tardy delivery [11, 12].
In this project, we have chosen to use the mobile
agent paradigm to implement the support for the
monitoring and control of the activities of the
enterprises. Mobile agents can migrate from one
computer to another and execute their code on different
locations, by their own “will”. Because this implies a
high degree of portability, mobile agents are usually
coded in Java [5]. To allow the mobile agents to run on
a computer, we need specialised software, which in
literature is called “mobile agent server”, “mobile agent
dock” or “mobile agent platform”. There are now many
mobile agent development systems, which provide the
functionality of the dock and a basic structure for the
agent, such as IBM’s Aglets [3] and the Mitsubishi
Concordia Mobile Agent Framework [1], which we use
in this project. The development and deployment of
agent-based VE integration includes the installation of
docks at all enterprises involved. The integration task
then amounts to making the agents able to identify and
invoke local functionality. The Mitsubishi Concordia
Mobile Agent Framework has specialized skeleton
modules (Service Bridges) to help making the
interfaces between the agents and the local software.
The installation of such a service bridge is fairly simple
and also the coupling to, e.g. a database, is based on a
broadly accepted standard such as JDBC.
In our project, we have assumed that the members of
the VE are all linked to the Internet, and have mobile
agent docks installed on their computers. We call such
a group of enterprises an MA-web (Mobile Agent Web).
2.4 Design outline
Figure 1 shows an object diagram, depicting the
information needed to support the deployment of agents
to provide monitoring and control at a global level (i.e.
the level above the enterprises). In a mobile agent
system, agents need a Trader to tell them which
resources (machines, stock, or operators) can be found business decisions concern the structure the VE
in the system and their availability. Resources may be business process. The VE needs take commonly agreed
Resource Availability Trader
decisions about how co-operation and overall
performance (especially in terms of customer
0..* 1 1 1
1 1 satisfaction) can be improved. The architectural
1
decisions are related to the ICT support development
0..*
for a VE. They are, however, strongly based on the
Scheduler Agent
0..* business decisions that determine the design variables
1
1 1 1 of a software system. The architecture decisions are
taken by the software and system architects in co-
0..* 1 1 operation with the stakeholders.
Global Schedule Target
1 1
3.1 Business decisions
Figure 1. Co-ordination in the VE.
free for specific periods of time (see Figure 2). When an Decision B1: Adopt a mixed initiative interaction
agent wants to use a resource, it is reserved for that system based on human and software agents. This
agent and becomes unavailable for other agents. When decision is the basic idea in ROVE. It entails the
the enterprise in control of the resource agrees to following consequences:
participate in the execution of an order, the resource − Software agents are empowered to take supply
becomes committed and is no longer available. chain control decisions.
resources
..... type 1
− The human-to-human interaction, which underlies
...... current supply-chain control systems, is replaced
.....
type 2
by an agent-mediated scheme in which some of the
....... decisions are initiated by humans and some by the
.....
type 3 software agents.
.... and other types
current future The first consequence implies that humans will trust
moment time

Figure 2. Availability of resources. the decisions taken by the agents. To ensure this, it is
In addition to a Trader, a Scheduler is needed at a absolutely necessary that the human users understand
global level to support the realisation of the Target. The how the agents work. This puts requirements on the
Target object contains the information about the subsequent architectural decisions (see, e.g., A10).
product that has been ordered: its composition (BOM) In our opinion, the main challenge of the ROVE
and the routing needed to manufacture it. An agent is project is to see how agents can develop more initiative
put in charge of the target and submits the routing data and take some of the routine decision making burden in
to the Scheduler, which combines it with the the VE control system from the human actors.
availability data to produce a (modification to the) Decision B2: For agent-oriented IT support, the
Global Schedule. The global schedule is returned to the parties in a VE rely on a common software provider.
agent in charge of the target. This agent decomposes This SW provider plays a role similar to that of an
the order into components to be manufactured, creates Internet provider or a provider of complex software
an agent to monitor the production of each component, who provide a reliable and trustworthy product. In this
and uses the schedule to send these agents to the case, the agents (dedicated to perform uniform tasks
enterprises in control of the resources reserved to over a large area) are developed by a single provider,
manufacture the particular component. It co-ordinates which we call the SACP (software agent common
the activities of these agents, communicating with them provider). Such a specialized firm can be provider for
to resolve any problem that may arise, until the agents more than one VE. The SACP could be an independent
return with their component and the final product is party, which enjoys a high level of trust and should
assembled. This process repeats itself until a sub- have the following responsibilities:
component is produced as a whole by a single − Develop the required agents and necessary support
enterprise (see also [10]). services and keep record of the parties who are
using them (the VE).
− Help the parties to install the software and teach
3. Design Decisions
users how to use it.
− Maintain and upgrade the system.
We can define two levels of decisions: business and
architecture related decisions, respectively. The
− Help the users with expertise to enact the service
bridges, in order to make local data available to the
agents.
Decision B3: The security of the agent system is
entrusted to a (trusted) third party that provides
monitoring and detection of hostile activities. Because
of the dynamic composition of the VE and its
distributed nature, it is best to contract secure
communication channels as a service, e.g. in the form
of a Virtual Private Network, from a trusted,
specialized provider. This approach is also used for
Extranets.
Decision B4: Centralization of common services. In
the ROVE framework, a central site has, amongst other
things, the following functions:
− Maintain a central repository of data about the
available resources in the VE, updated as often as
possible.
− Calculate Global Schedules for orders.
The rationale behind this decision is that one
consistent body of global information makes it simpler
to generate optimal global schedules, and to avoid the
resource conflicts, inconsistencies and inefficiencies
implied by distributed alternatives. It furthermore
relieves the participant enterprises from the hard task
of developing and maintaining a distributed version of
these services themselves, and lowers the threshold for
participation in the VE.
Decision B5: Enact a Web portal for the VE for the
interaction with the customers. This portal exposes the
portfolio of the VE and permits customers to issue
orders. The roles of SACP, of trusted third party, and of
maintaining a central site and a Web portal may be
attributed to a single company.
Central solutions always have the risks of congestion
(because the central services create bottlenecks) and of
central system breakdown. We envisage about hundreds
to thousands of agents to be active at any time. Since
the agents invoke the central services only in certain,
rare situations, we regard the probability to reach a
state of real congestion as rather low. Also, the system
is not subject to real-time constraints. Since the agents
rely on an asynchronous interaction mechanism, and
can wait a while for the Trader to respond, a small
degree of congestion can be tolerated.
The asynchronous nature of the system also helps to
avoid problems if the central site needs to recover in
case of hardware or software failures.
3.2 Architecture related decisions
Decision A1: Central Repository for Resource
Availability Data. This decision can be viewed as a
natural consequence of Business Decision B4. The
rationale is that the overall functionality of the system
is simplified. It offers the possibility to have global
knowledge about the status of the “controlled” system.
A central repository allows agents to access necessary
data (via the Trader) immediately. In addition, Global
Scheduling can take place using local data, without the
need to collect every time the necessary information.
Also, when the Web portal has access to the global
data, it can provide quick order confirmation including
information about, e.g., delivery dates. If the resources
in the VE are almost fully committed, it is very easy to
refuse orders without keeping the customer waiting.
Because it always takes a finite amount of time to
reflect changes of the local resource availability in the
repository, the latter may not always reflect the latest
state of the VE (the update mechanism is discussed in
the context of decision A4). This is not a real issue,
because resources must be committed locally before
usage. When an agent finds the information kept in the
central repository to be outdated or inconsistent with
the local reality, (because the local scheduler has
assigned the resource to a local production process) an
exception is raised. The agent can invoke the Trader to
find a new available resource of similar type and time-
slot, or it can ask for a calculation of a new Global
Schedule.
The alternative to centralization is to keep the
availability data local (i.e. in the enterprises). In this
case, the scenario of using the agents is quite different.
Each time a customer issues an order, the portal
deploys agents to all sites, where they search and select
the best offers. It is still possible to make a global
schedule, but only after the agents have collected the
data. In architectures without a central repository, the
main activity of the agent will be searching. For
instance, when an agent needs a new resource it has to
send agents throughout the entire VE to find one. Also
in case of delay management, in order to obtain the
value of the penalty to be paid to the customer, a Global
Schedule has to be calculated, which implies collecting
all data again. Also the optimization of the Global
Schedules for different products is very difficult,
because this requires the entire Availability Gantt chart
to be constructed. Another consequence is that the
agents need more functionality (for searching,
navigating, co-ordination, etc) in order to compensate
the lack of a central Trader.
Since the Central Repository is only a (redundant)
copy of the local data, this data can easily be
reconstructed after a failure.
Decision A2: Centralized Global Scheduling. One of
the reasons why Virtual Enterprising exists is better
customer satisfaction, especially in terms of fast order
execution, which is supported by a central scheduler
that uses global knowledge about the available
resources to produce optimal schedules with, e.g.,
minimal lead-times.
The way the schedules are constructed depends on
architecture decision A1. Without a central repository,
the schedules will have to be calculated by the agents
after they have collected all necessary information
about resource availability. Schedules may now be
produced concurrently at different sites for different
orders, based on the same availability data.
Independent construction of schedules can lead to the
allocation of the same resources to different targets. It
is quite difficult to see how these conflicts can be
avoided or how conflict resolution can be done.
A Central Repository for Availability data, Global
Scheduling capabilities and a Trader represent the
minimal centralized infrastructure, leaving unaltered
the inherently distributed nature of the system.
Decision A3: Serial calculation of schedules. Global
Schedules can be calculated at the central site in
parallel or serially. The choice depends on the
scheduling load. The simplest variant is to calculate the
schedules serially. Since the number of sites, of tasks
per product and of available resources is expected to be
low, it should be possible to produce the schedules
within a sufficiently short time. To support parallel
scheduling, a concurrency control mechanism must be
implemented. Also this should not present any
problems, because the schedule generation is taking
place at a single site based on a single set of data.
Decision A4: Use Polling for data collection. There
are two basic approaches for collecting the data for the
central repository: polling and publisher/subscriber. In
a polling approach, the central site has a list of all sites,
and it asks them, via messages or by sending agents,
whether any changes in the availability of the local
resources have occurred within the production horizon
of the VE. This approach has the disadvantage of
complicating the functionality of the central site. It also
increases the communication volume between the local
sites and the central one, and thus the possibility of
congestion. A new updating service is needed.
In a publisher/subscriber approach, the local sites
have to send the information about relevant changes to
the central site. This approach complicates the
functionality of the local service bridges. These service
bridges are pieces of software, which have to be
developed by local programmers and it is better to keep
them as simple as possible. The service bridges are
basically only an interface between docked agents and
local data repositories or humans. Furthermore, if all
sites send the information at the same time, also in this
case congestion can occur. In view of the
maintainability of the system, and the ease of
installation and use we have chosen the polling
approach.
Decision A5: Use Roaming Agents implementation
of the polling approach. We have chosen for the option
to let the central site send agents to gather the
information. It is possible to use only one agent for this
task, when the number of sites is not very high. If
changes have occurred, the agent can send a message to
the central site, or it can reduce the communication
load by storing the data in his own data repository and
uploading the information when it visits the central
site. If the number of sites is high, the VE can be
partitioned in areas, each one with its own roaming
agent. In the event that a site is down, an agent who
can wait, until the communication channel is
operational again, is preferable. Roaming agents have
been proven an efficient mechanism for collecting data
in the context of the World Wide Web [4], where they
are known as spiders or crawlers.
Decision A6: Message Based Communication
between agents. In the Nucleus model [5], the agents
have been able to communicate only through the dock.
When two agents want to communicate, they have to
move to the same dock. In most systems, including
Concordia, Grasshopper, Odyssey, Voyager and BOND
[3], agents have a unique identity and can communicate
via messages between themselves. Because Concordia
is our target implementation tool, and the architecture
must be general enough for other implementations,
direct messaging between agents is used.
Also, it is logical to use message-based
communication for co-ordination tasks. The agents,
who participate, are docked at various sites, tracking
the production of the parts they are responsible for.
There is no need for them to move to another location
just to communicate with another agent.
Decision A7: Use a pull model for the migration of
the agents. There are three possible models [6] for
mobile agent migration in a distributed environment:
Pull: the agents are sent from buyers (assemblers) to
suppliers to look for opportunities.
Push: the agents are sent from suppliers to buyers
with offers.
Broker: both buyers and suppliers are sending agents
to a virtual marketplace, where agents can participate
in auctions and exchange information in various ways.
According to [6] the broker model is best suited for
e-commerce applications and not for VE support. Since
a VE is a customer (buyer) driven environment, the
best model seems to be the pull model. Also the
monitoring task of the agents implies a pull model.
Decision A8: Limit the interaction between agents
to pair wise interaction. The rationale behind this
decision is simplicity. An alternative is teamwork
interaction, but this is extremely difficult to model.
Auction based schemes are using broadcast interaction,
but there is, at present, no need for this in PROVE.
Decision A9: Use BDI as Agent Behavioral Model.
The BDI (Beliefs - knowledge, Desires - goals,
Intentions - agenda) model is the most popular model
in the agent researcher community. In our context, it
has the advantage that the results of the ROVE project
can be compared with other similar approaches.
The agent internal structure has to be developed
keeping in mind the process they have to support [7]. In
our case, timely delivery of the product is a business
goal. This is reflected in the agent by designing it
around the delay management process [12].
Decision A10: Rule-Based Systems for the
implementation of Agent Behavior. This design
decision de-couples the agent behavior from its
implementation. When the behavior is coded directly in
a procedural way (as methods), any modification to the
behavior of the agents implies code re-writing. Using a
rule interpreter [2], we have the possibility to specify
the behavior at a level that is understandable by the
human VE controllers. These users then are more likely
to trust the agents to take (low level) decisions. The
main advantage of rules is that they are much easier to
read than code and have clear semantics even for non-
programmers. Furthermore, we only have to modify the
rule base of the agents to change the application we
want to support. The disadvantage of this approach is
that is quite difficult to see if a specific rule base is
correct or not. In a later stage of the project a proof
mechanism will be developed for this purpose.
4. Conclusions and future work
In this paper we have presented an approach to the
design of ITC support systems for VE’s, which have as
principal requirement a minimal impact on the local
systems in terms of additional work load and software
development effort. We have argued that architectures
based on mobile agents are well suited for this task.
The agents provide support for the dispatching,
monitoring, tracking and negotiation processes. We
have given strong arguments that some centralisation
of data and services for the agents will simplify and
improve the processes and the system structure. We
have identified several of these: a software agent
common provider, a trusted third party to provide
security, and a central site to provide support for
trading and scheduling.
Our future work has two horizons. The short-term
work will comprise mixed initiative experiments with
one-of-a-kind ordering style. In these experiments the
number of simultaneous targets will be kept low. After
that, we will have to deal with batch ordering and
conflicting resource allocation for multiple targets.
5. References
[1] Mitsubishi Concordia Mobile Agent Framework,
http://www.concordia.mea.com/concordia/
[2] “The Java Expert System Shell”,
http://herzberg.ca.sandia.gov/jess/
[3] "Agent Construction Tools",
http://agentbuilder.com/AgentTools
[4] Bowman, C. M. et al. The Harvest Information Discovery
and Access System. Second International World-Wide Web
Conference, Chicago, 1994.
[5] Dalmeijer M., Rietjens E., Soede M., Hammer D.K.,
Aerts A.T.M., (1998), MAF: A Java-Based Implementation of
a Mobile Agent Architecture 1st IEEE International
Symposium on Object-oriented Real-time distributed
Computing (ISORC), April 1998, Kyoto, Japan.
[6] Dasgupta, P., Narasimhan, N., Moser, L.E., Melliar-
Smith, P.M., (1999), “Mobile Agents for Networked
Electronic Trading”, in IEEE Transactions on Knowledge
and Data Engineering, vol. 11, no. 4, pp.509-525.
[7] Goossenaerts, J.B.M., Aerts, A.T.M., Hammer, D.K.,
(1998), “Merging a Knowledge Systematisation Framework
with a Mobile Agent Architecture”, in Information
Infrastructures for Manufacturing II, (Mills & Kimura, eds.),
Kluwer, The Netherlands.
[8] Hammer D.K., Aerts A.T.M., Dalmeijer M., (1998),
Mobile Agents Architectures: What are the design Issues?
International Conference on Engineering of Computer Based
Systems (ECBS), Jerusalem, Israel, March 1998.
[9] Kornelius, L., (1999), “Inter-Organisational
Infrastructures for Competitive Advantage: Strategic
Alignement in Virtual Corporations”, PhD Thesis, Faculteit
Technologie Management, Eindhoven University of
Technology, The Netherlands.
[10] Szirbik, N.B., Hammer, D.K., Goossenaerts, J.B.M.,
Aerts, A.T.M., (1999), “Mobile Agent Support for Tracking
Products in Virtual Enterprises”, in The working papers of
the Workshop on Agent-Based Decision-Support for
Managing the Internet Enabled Supply-Chain, pp.93-100,
AGENTS’99 Conference, Seattle.
[11] Szirbik, N., Wortmann, H., Hegge, H., Goossenaerts, J.,
(1999), “Improving manufacturing cooperation in a virtual
enterprise by tracker mobile agents”, in Proceedings of
EFTA’99, pp.1451-8, Barcelona, IEEE Press.
[12] Szirbik, N.B., Wortmann, J.C., Hammer, D.K.,
Goossenaerts, J.B.M., Aerts, A.T.M., "Mediating
Negotiations in a Virtual Enterprise via Mobile Agents",
AIWoRC’2000: Mobile Technologies and Virtual
Enterprises", Buffalo, April 2000.