Bee-gent: bonding and encapsulation enhancement agent framework for development of distributed systems
Post on 11-Mar-2023
0 Views
Preview:
Transcript
Bee-gent: Bonding and Encapsulation Enhancement Agent
Framework for Development of Distributed Systems
Takahiro Kawamura, Yasuyuki Tahara, Tetsuo Hasegawa, Akihiko Ohsuga, and Shinichi Honiden
Corporate R&D Center, Toshiba Corp., Saiwai, Kawasaki, Japan 210-8501
SUMMARY
With the recent fast expansion of networks, intercon-
nection of heterogeneous systems via networks is drawing
increasing attention. In this context, the authors propose the
Bee-gent (Bonding and Encapsulation Enhancement
aGENT) agent framework, whose objective is to allow
flexible interconnection between legacy systems, data-
bases, and other existing systems by providing coordination
and communication functions for distributed system com-
ponents. With the proposed network, interaction protocols
describing interactions between system components are
divided between global processing related to problem solv-
ing, and component-specific local processing. Coordina-
tion between system components in the global processing
is ensured through consistent control by mobile mediation
agents. This facilitates design and maintenance if the sys-
tem is modified or extended. In the paper the practical
implementation of the proposed system is discussed and
specific practical examples are presented to demonstrate the
effectiveness of the system. © 2000 Scripta Technica, Syst
Comp Jpn, 31(13): 42�56, 2000
Key words: Distributed system; adjustment; com-
munication; mobile agent.
1. Introduction
With recent developments in high-speed network
infrastructure and trends toward open-oriented software,
the demand for interconnectivity between network applica-
tions is increasing [1]. In particular, there is strong interest
in the design and operation of distributed systems that
support the utilization and linking with older special-pur-
pose software (often called legacy systems) or existing
databases. CALS and corporate electronic commerce may
be mentioned as typical fields. Numerous standards (e.g.,
SGML, STEP) are available to implement data exchange
between systems via networks.
However, to ensure consistent operation of a distrib-
uted system, more than knowledge sharing based on data
exchange is required: an important further issue is how to
coordinate interaction between the systems involved. All
the advantages of a distributed system will be reduced by
half unless there is a coordination function to solve this
problem. Unfortunately, few development tools are avail-
able to build distributed systems supporting such coordina-
tion functions. Recently, distributed-object systems that
treat structural components as objects, and multiagent sys-
tems that employ multiple agents for coordination, have
been extensively developed. However, most tools used for
such development are focused mainly on communications
between structural components while providing little or no
support for coordination functions. A framework is required
that would not only ensure communications but also pro-
vide coordination.
In this context, we propose an agent framework,
Bee-gent (Bonding and Encapsulation Enhancement
aGENT) [2], which provides coordination between struc-
tural components of a distributed system for the purpose of
flexible linkage between legacy systems, package software,
and other existing systems. With the proposed framework,
© 2000 Scripta Technica
Systems and Computers in Japan, Vol. 31, No. 13, 2000Translated from Denshi Joho Tsushin Gakkai Ronbunshi, Vol. J82-D-I, No. 9, September 1999, pp. 1165�1180
42
coordination between structural components is imple-
mented via multiple mobile agents rather than by linking
individual components to each other. Other related ap-
proaches are discussed in Section 2, and Section 3 explains
the configuration and features of the proposed system. In
Section 4, the practical implementation and development
examples are discussed. Section 5 discusses possible appli-
cations of the proposed system.
2. Approaches to the Development of
Distributed Systems
Recently, the mainstream in distributed architectures
has been shifting from the previous client-server model
toward the distributed-object model, which offers more
flexibility. However, the distributed-object model normally
requires mutual understanding between the systems to be
connected as well as precise interface specifications. For
example, preliminary knowledge about an object (e.g.,
method name, argument) is required for remote access to
the object. In addition, object descriptions for cooperative
processing of multiple objects are not supported, which
means that the developer has to incorporate cooperative
logic of this kind into each individual object.
On the other hand, in research related to multiagent
models, components of a distributed system are treated as
agents, and some models have been proposed to implement
cooperative processing among multiple objects.
Typical models of this sort include KQML facilitator
and federation architecture [3�5]. In this model, however,
the emphasis is placed on message routing when multiple
agents interact through exchange of KQML messages: no
support is provided for direct coordination to promote
problem solving by individual agents based on sent or
received messages.
COOL [6], JAFMAS [7], and AgenTalk [8] are ex-
amples of agent development tools that offer more direct
coordination. These systems offer general methodologies
for the development of Speech-Act-based [9] multiagent
systems while supporting the description of interaction
protocols (IP, explained in detail in Section 4), which ex-
plicitly represents the interdependencies between KQML
messages. With these tools, however, it is extremely diffi-
cult to produce IPs because they must be tailored to indi-
vidual agents without loss of compatibility. Therefore, an
addition or correction to a problem-solving algorithm
would require a complicated iterative procedure to modify
the overall interaction between agents while avoiding con-
flicts with individual IPs. Such a procedure becomes im-
practicable if there are many agents or complicated
problem-solving algorithms. Besides, it is not an easy task
to verify the total compatibility of individual IPs. In this
context, we propose the agent framework Bee-gent [2],
which provides coordination between structural compo-
nents of a distributed system via mobile agents rather than
introducing complicated IPs into the individual compo-
nents. In the proposed architecture, global IP processing
related to problem solving is separated from local process-
ing related to individual components, and the global proc-
essing is subject to centralized control by mediation agents.
Such an approach facilitates IP development while support-
ing coordination between components, which is indispen-
sable in building an efficient distributed system.
3. Bee-gent Agent Framework
3.1. System configuration
The basic concept of the proposed system is shown
in Fig. 1. The system consists of distributed components
such as applications and databases, agent wrappers [10]
(below referred to as wrappers) that connect these elements
via a network, and mediation agents that realize cooperative
processing between components via wrappers.
A mediation agent supports coordination functions
(assurance of consistent operation of the whole system),
communication functions (communication with wrappers),
and migration functions (movement between wrappers via
Fig. 1. System concept.
43
the network). A variety of functions of agent wrappers are
supported, such as communications with mediation agents
and use of the native interfaces of connected applications
(e.g., SQL queries for databases or http-access for Web
servers), as shown in Fig. 2.
Migration functions provide for the travel of a media-
tion agent among wrappers. A wrapper may also be consid-
ered as a platform that allows operation�simultaneous or
exclusive�of multiple mediation agents. Coordination
functions are implemented by means of mediation agents
acting through their IPs, which will be explained in more
detail later. Communication functions provide message
exchange between mediation agents and wrappers, which
will be described later as well.
The implementation of the system will be explained
in Section 4. Below we describe simple functional links
between mediation agents, wrappers, and connected appli-
cations.
(1) Application A issues an event to connected wrap-
per A using its native interface.
(2) Wrapper A receives the event (if necessary) and
sends a message to the mediation agent by means of the
communication function.
(3) The mediation agent receives the message by
means of the communication function and takes an appro-
priate action in accordance with the IP (in our case, migra-
tion to wrapper B).
(4) Using the migration function, the mediation agent
goes to wrapper B and takes the next action in accordance
with the IP (in our case, sending a message to wrapper B).
(5) The mediation agent sends a message to wrapper
B by means of the communication function.
(6) Wrapper B receives the message by means of the
communication function and (if necessary) accesses appli-
cation B via its native interface.
3.2. Coordination functions
The mediation agent supports coordination functions
to ensure cooperative problem solving among the compo-
nents of the distributed system. The coordination functions
provide interdependence of Speech-Act-based messages
exchanged between wrappers and mediation agents, and are
explicitly defined by the IP.
3.2.1. Interaction protocols
In essence, IPs are based on the organizational theory
of Fox and colleagues [11, 12]. This approach considers, at
the structural level, the problems of coordination between
different subjects, and presupposes a priori knowledge
about interactive processes between such subjects, which
may be considered as a top-down approach. The IP repre-
sents such interactive processes as a dialog between sub-
jects using the rules of Speech-Act-based message
exchange. The IP may also be thought of as a plan that
allows each subject to achieve its own goals while interact-
ing with other subjects. In many cases, this is represented
as a finite state machine, including possible states for a
subject, actions, and transitions to next states. Subject
autonomy appears as a choice between possible states for
transition. Some studies consider dynamic modification of
state transitions during IP run-time [13].
An example of an IP modeled as a state transition
diagram is shown in Fig. 3. In the diagram, the IP performs
requests from one subject to another; in the process, re-
peated message exchanges take place, obtaining the results
(inform Done or failure). The rectangles correspond to
states of the subject that are possible during IP execution,
namely, from top to bottom, precondition, action, and state
transition rule. If a precondition is matched, then the action
included in the states is called. The action (also referred to
as an action function, etc.) determines the subject�s opera-
Fig. 2. Mediation agent and agent wrappers.
44
tion. The state transition rules represent the postconditions
for the choice of the next action.
3.2.2. Unification of IPs related to
problem-solving procedures
As explained above, with previous agent develop-
ment tools supporting coordination functions, an IP is pro-
vided for each subject. In many cases, however, it is
extremely difficult to provide mutually noncontradictory
IPs for every system component.
One reason is that, to provide an IP for each subject,
interactive processes at the system level must be analyzed
as interactions of every subject with all of its counterparts.
When designing IPs for individual subjects, the initial state
is first determined, then all possible combinations of the
subject�s actions and messages from other subjects are
considered, and multiple subsequent states are set. The
same procedure is then repeated for all subsequent states,
and so on until some final state is attained. After this process
is performed for all subjects, total compatibility must be
verified. Moreover, all of these procedures must be carried
out not only at the initial development stage, but also every
time some modification is made, such as addition or altera-
tion of a problem-solving algorithm. Another reason is
related to the coexistence of global processing related to
problem-solving algorithms and subject-dependent local
processing. Basically, states included in the IP are ex-
pressed in Speech-Act form, but in practice, this is not
enough to cover all processing, so that the internal states of
every object naturally become involved. For example, con-
sider a routine in which a DB receives a message, performs
the appropriate search, and returns results. Such a routine
is a part of mutual problem solving with other DBs but,
depending on the DB type, specific requirements may be
imposed on the search method, initialization, and so on,
which means that local processing will be included in the
IP.
In this context, the authors propose a methodology
for IP unification and an architecture based on this method-
ology. In this approach, global processing involved in prob-
lem-solving algorithms is separated from local processing,
and the IPs related to the former are unified. In terms of
architecture, unified problem-solving IPs are assigned to
mediation agents, and IPs describing local processing are
assigned to agent wrappers. The mediation agents promote
problem solving in accordance with the IP and instruct the
wrappers as to what they should do next, thus supporting
cooperative processing. This makes it possible to imple-
ment coordination between subjects, that is, the structural
components of distributed systems, without providing them
with complicated individual IPs.
In IP unification with respect to problem solving,
interactive processes between system objects are consid-
ered laterally from the viewpoint of independently moving
agents rather than analyzed as interactions between other
subjects as seen from some subject. In this situation, pro-
gress in a problem-solving task is indicated by the media-
tion agent�s state. This may be thought of as representing
vertical IPs for individual subjects by means of horizontal
IPs that connect subjects: we believe that the design of such
IPs allows easier realization of the developer�s intentions
(Fig. 4). Now we consider the methodology of IP unifica-
tion.
(1) Definition of distributed elements. The overall
goals and services to be provided are determined for a
distributed system, and the necessary system components
(e.g., customer DB, search engines, WWW servers) are
specified. Subsystems (components) may include both ex-
isting systems and those yet to be developed.
(2) Design of interactive processes between compo-
nents. Using knowledge about the functions of all distrib-
uted components, the general flow of interaction processes
to implement the required services is designed. Normally,
the interactive flow may include conventional workflows,
algorithms for constraint satisfaction, and so on.
(3) Design of unified problem-solving IP. Based on
interactive processes between system components, prob-
lem-solving procedures are instantiated as IPs. To design
such problem-solving IPs, a state in which a request occurs
in some component is taken as the starting point; possible
actions and their results are found, and the next state is
determined. If some different kind of processing becomes
necessary in IP execution (branching of processing), a new
mediation agent may be generated to handle the task. On
the other hand, an IP may be terminated as soon as the action
under its control is no longer needed.
(4) IP design for local processing. The initial and
final state for each component, or specific local algorithms
Fig. 3. Example of IP model.
45
for actions specified by mediation agents, are described
inside wrappers.
3.2.3. Advantages of unified IPs for problem
solving
In addition to the simpler design mentioned above, IP
unification offers other advantages described below. The
unified IP differs from the mere combination of individual
IPs in the conventional architecture in the following re-
spects:
(1) The IP is disengaged from component-dependent
processing, thus focusing on problem solving.
(2) If multiple components have the same states and
actions, this may be described briefly as a loop in the IP
(with a simple global state transition diagram, such loops
may prove impossible because of differences in local algo-
rithms).
(3) If components and processing sequences vary
dynamically in problem solving, causing associated
changes in algorithms, in the conventional approach all
such changes must be described in numerous IPs, while in
the proposed system, sequence-dependent routines are de-
scribed in aggregate form.
Thus, the total number of states in the unified IP is
smaller than in the case of individual IPs connected by
message exchange. Therefore, when modifying or correct-
ing an IP at the development stage, or during operation, the
state space to be searched becomes narrower, which should
be conducive to easier assembly and better maintainability.
Specific examples are given below.
3.3. Communication functions
Mediation agents and agent wrappers offer commu-
nication functions to support information exchange be-
tween components of a distributed system. These
communication functions are implemented as exchange of
Speech-Act-based messages between wrappers and media-
tion agents. ACL (Agent Communication Language [14]),
a communication language that is a modification of KQML
[4] based on Speech Act theory, is used for the purpose.
ACL includes three elements.
x An external language to express agents� intentions
(ACL)
x An internal language (content language) to encode
information exchanged among agents
x Ontologies corresponding to mutual application
areas
The content language, however, is not regulated, al-
though ontologies are presumed to be mutually familiar.
Messages are formatted in XML/ACL, with ACL logic
structures expressed in XML [15]. An example is shown in
Fig. 5. There are other similar approaches such as FACTS
[16].
Using XML to represent ACL has the following
advantages.
x Availability of a full-fledged environment to de-
velop editors, parsers, and so on.
x Connectivity to other XML-based communication
languages via DTD exchange
x Possibility of using hyperlink functions specified
by XML standards for ontology exchange
In response to messages received from wrappers,
mediation agents enable problem-solving IPs. On the other
hand, in response to messages received from mediation
agents, wrappers enable local IPs, for example, function
calls from applications.
Fig. 4. Unification of problem-solving process IPs.
46
4. System Implementation and Examples
of IP Development
In this section, the implementation of the agent
framework Bee-gent is introduced and a specific IP for
distributed solving of the N-Queens problem is described.
4.1. Outline of system implementation
The system is implemented in the Java language. The
architecture levels are shown in Fig. 6.
The basic elements�mediation agents and agent
wrappers�are implemented as Java classes, and access
methods for essential actions (e.g., generation and analysis
of XML/ACL-based messages, message transmission with-
out recognizing physical addresses, generation, migration,
cloning, and deletion of mediation agents, and so on) are
provided in advance. Development of a distributed system
using the proposed framework may be divided in two steps
as follows.
(1) Design of agent wrappers. Special wrapper
classes are produced by incorporating native access meth-
Fig. 6. Architecture levels.
Fig. 5. Example of XML/ACL.
47
ods (using such functions as JNI and JDBC) for component
systems into the basic agent wrapper class.
(2) Design of IPs for mediation agents and wrappers.
IPs are provided as sets of state classes. State classes, being
extensions of basic state classes, are designed by specifying
preconditions, actions called in case preconditions are
matched, and postconditions. The state transition is per-
formed by a state transition manager.
Detailed class structures and lists of methods are not
discussed in this paper. Agent migration is implemented by
means of serialization and http.
4.2. Solving the N-Queens problem in a
distributed system
Below the advantages of unified IP are illustrated by
the example of the well-known N-Queens problem. An
outline of the distributed system developed to solve the
N-Queens problem is given in Fig. 7. The problem is treated
here in 4 u 4 format in terms of a distributed system whose
components are management systems for each queen�s
position. The components are connected via a network by
means of agent wrappers, and position constraints are re-
leased by a mediation agent.
To examine the advantages of the unified IP, the
proposed solution is compared to the conventional architec-
ture with an individual IP assigned to every distributed
component. In the experiments, it is assumed that altera-
tions are made to the developed IP for partial modification
of the method of releasing constraints between queens. In
addition, to confirm the ease of design and the enhancement
of maintainability mentioned in Section 3.2.2, the number
of states searched in the course of IP modification and the
number of actual changes are compared. In particular, con-
sider the case in which the releasing of constraints by a
backtracking algorithm reaches a deadlock. According to
the initial IP, the immediately previous agent devises an
alternative plan, while in the modified IP, such an alterna-
tive is worked out by the first agent.
Figure 8 presents a backtracking algorithm repre-
sented by means of individual IPs before modification, and
Fig. 9 shows the configuration after modification. Arrows
in Figs. 8 and 9 indicate messages exchanged between
queens, while the labels (request, inform, failure) pertain to
each message�s Speech-Act (performative).
As will be seen from Fig. 8, every queen may have
the following states.
init Initial state. For each queen, initialization proc-
essing is performed locally. Here, however, for the sake of
convenience, the initial layout of the queens is always
assumed to violate constraints. (If such an assumption was
not made, then a function would have to be provided to
detect constraint violations.)
solve problem Constraint processing state. The cur-
rent position is changed to another one not violating the
constraints. In this study, a forward position (Queen A for
Queen B) is considered as a partial solution, and modifica-
tion is performed so as not to violate the solution. Queen A
keeps record of its modification, and a move to the same
position is not allowed.
request adjust my pos. Request sending state. The
request is sent backward in order to adjust the partial
solution including the home position. The action is blocked
until the reply comes.
Fig. 7. Distributed system for N-Queens problem.
48
Fig. 8. Individual IPs for backtracking before modification.
Fig. 9. Individual IPs for backtracking after modification.
49
inform Done Positive reply state. The possibility of
modifying the position in accord with the received partial
solution is announced.
failure Negative reply state. The impossibility of
modifying the position in accord with the received partial
solution is announced.
fix position Confirmation state. The modified posi-
tion is confirmed.
error Failure state. Failure to release the constraint is
reported.
The unified IP for backtracking before modification
is shown in Fig. 10, and the modified IP is shown in Fig.
11. In both diagrams, all agent wrappers are provided with
local IPs that support initialization, confirmation, and other
algorithms for the corresponding components. The agent
wrappers operate through requests from the mediation
agent. The local IP for backtracking is presented in Fig. 12.
These local IPs are independent of problem solving
and hence do not require any modification. The IP in Fig.
12 can be used for any queen (A, B, C, D). This only applies,
however, to a homogeneous distributed system like the one
under consideration; in general, not all wrappers necessar-
ily have a common IP.
According to Fig. 10, the mediation agent may take
the following internal states.
request solve problem Request sending state. The
mediation agent specifies the current partial solution to the
agent wrappers, thus requesting to adjust positions in ac-
cord with that solution. However, for Queen A, the partial
solution is assumed empty, and when inform Done is sent
from Queen A, that position is considered a partial solution.
migrate Migration state. The mediation agent mi-
grates to the destination specified at the previous state and
transits to the specified state.
Fig. 10. Unified IP for backtracking before modification.
Fig. 11. Unified IP for backtracking after modification.
50
inform Done Constraint release notification state.
failure Constraint release failure state.
If each queen (or rather each queen management
system in Fig. 7) has its own IP, checking and release of
constraint violations is performed according to its IP. In
case of a unified IP, checking and release of constraint
violations is performed by wrappers according to instruc-
tions from the mediation agent.
In Fig. 9, state c4 returns failure to b2, hence b2
recovers to initial state b0 (init). On the other hand, in Figs.
11 and 12, the IP for local processing at the agent wrapper
goes back to state w0 (init), that is, Figs. 9 and 11 are
logically correlated.
With the methodology of problem-solving unifica-
tion proposed in this study, global interactive processes
intended by the designer are treated laterally among sub-
jects rather than being split vertically. For this purpose, the
mediation agent acts as a third-party subject, depending on
the interactive process context. Hence, Fig. 10 is not a
transformation of Fig. 8.
Consider briefly the design of Fig. 10 in terms of the
methodology described in Section 3.2.2. In a simple prob-
lem such as our example, steps 1 and 2 are determined in a
natural way. On the other hand, with real-world problems,
the two steps are determined with reference to a thorough
domain analysis and to system requirements (e.g., perform-
ance). In steps 3 and 4, the list of internal states for each
queen indicates that some states are related to other com-
ponents (e.g., request, inform) while others are purely in-
ternal (e.g., init, fix). On the other hand, only the former
states are included in the list of states of the mediation agent
(the internal migrate, too, may be considered to be related
to the destination). These two groups of states are treated
separately in steps 3 and 4. In our example, the former states
are associated with problem solving, that is, the backtrack-
ing algorithm. On the other hand, the latter group (internal
states) are defined beforehand depending on the subjects.
Therefore, it seems reasonable to first define the unified IP
related to problem solving, and then to design the local IPs.
4.3. Comparison of interaction protocols
Comparing Figs. 8 and 10, the unified IP for global
problem solving explained in Section 3.2.3 is different from
a simple combination of conventional IPs assigned to every
system component. In Fig. 8, processing related to problem
solving is mixed with component-specific processing (e.g.,
initialization, confirmation); hence it is difficult to track the
whole interaction between components. In addition, al-
though components B and C share the same problem-solv-
ing algorithm, their IPs are not exactly the same because of
involvement in local processing, so that parallel description
of both types of processing becomes complicated. On the
other hand, with unified IPs, component-dependent proc-
essing is separated, and identical algorithms for problem
solving can be represented as a loop, which makes the
processing flow easily comprehensible. Further, in Fig. 8,
constraint release processing is performed in the order A,
B, C, D; to obtain processing in the reverse order from D
through A, each component must be provided with double
IPs that can be switched appropriately. The unified IP,
however, takes care of all order-dependent processing, so
that individual components are not involved.
We now compare Figs. 8 and 9 to Figs. 10 and 11 in
terms of simplicity of design and maintenance in the case
of partial IP modification. Assuming that modifying an IP
requires checking all states of the current IP, the modifica-
tion from Fig. 8 to Fig. 9 involves the checking of a total of
22 states, while only 4 states are involved in the case of
modification from Fig. 10 to Fig. 11. The number of states
to be actually modified (marked by shading) is 4 in the case
of Figs. 8 and 9, but only one in the case of Figs. 10 and 11.
In addition, in the former case, all four states to be modified
belong to different components, while in the latter case, it
would suffice to modify just the mediation agent to which
Fig. 12. Local IP for backtracking.
Table 1. Comparison between individual IPs and
unified problem-solving IP
Total of
individual IPsUnified IP
States to be searched for
algorithm modification
22 4
States to be modified 4 1
Agents to be modified 4 1
51
the unified IP belongs. The above results are summarized
in Table 1.
In this study, IP architectures are compared by means
of the following formulation in order to minimize arbitrari-
ness. First, all actions within a state must be appropriate in
terms of practical implementation. Next, in both cases (an
individual IP for every queen, and a unified IP), meaningful
state sets must be correlated in a natural way. This is
represented in Table 2. With problems like the one under
consideration, the IPs themselves are simple, so that the
proposed formulation should prevent arbitrariness. How-
ever, with real-life IPs, further examination is required in
order to generalize such approach by formalization of IP
description.
5. Discussion
In this section, the features of the proposed system
are discussed in terms of functions, implementation, and
application.
5.1. Functions
5.1.1. Coordination functions
With the proposed framework, we propose a method-
ology for unification of IPs related to problem solving. The
mediation agents control such IPs to ensure coordination
between system components. In other words, IP unification
corresponds to context integration of dialogs between dis-
tributed components (Fig. 13).
This impairs parallelism to some degree. However,
processing is performed in distributed fashion on each
component, and communications are not concentrated at
certain nodes. Furthermore, in solving different problems,
the context is divided appropriately, and processing is per-
formed in parallel by means of multiple mediation agents.
On the other hand, context integration relieves individual
components of the need for such functions as message
routing (forwarding messages to relevant agents and return-
ing replies to senders) or multiple-state management (man-
agement of multiple internal states occurring in case of
multiple simultaneous dialogs). In addition, if the problem-
solving algorithm is to be modified, it will suffice to modify
the mediation agents, with the individual components re-
maining intact.
Fig. 13. Conversation contexts.
Table 2. Comparison of state sets
Individual IPsMediation
agent�s IP
Wrapper�s
IPs
Initial state init (a0, b0,
c0, d0)
init (w0)
Constraint
processing
solve
problem (a1,
b2, c1, d1)
request solve
problem (s0)
solve
problem (w1)
Request
sending
request
adjust my
pos. (a2, b2,
c2)
migrate (s1)
Positive reply inform Done
(b3, c3, d2)
inform Done
(w3)
Negative
reply
failure (b4,
c4, d4)
failure (w2)
Confirmation fix position
(a3, b5, c5,
d3)
inform Done
(s2)
fix position
(w5)
Failure error (a4) failure (s3) error (w4)
52
5.1.2. Communication functions
As regards communication functions, a knowledge of
various component-specific access methods (e.g., method
names, arguments) is no longer required due to the use of
ACL as a language for communication among agents. If
applications of different types and systems from different
fields are interconnected, it is difficult to design direct
access procedures because of a lack of knowledge of the
counterparts, and once it was designed, such a distributed
system would not be extendible. On the other hand, due to
the introduction of the Speech-Act-based common lan-
guage, not only can individual differences be absorbed by
agent wrappers, but also absent information can be obtained
through queries. In addition, the employment of XML/ACL
as the message format will ensure future compatibility with
other XML standards.
5.1.3. Migration functions
Normally, as compared to message passing, mobile
agents generate a greater data volume per one-time com-
munication (in many cases, mobile agents incorporate pro-
grams, and hence their size increases relative to the size of
the messages), but the frequency of communications may
be reduced [17]. This is because mobile agents migrate
together with all necessary information and processing;
thus, processing is performed locally at the destination,
which requires network communication only in the case of
migration. This feature, however, is not necessarily realized
in all cases. In certain circumstances, message passing may
prove more efficient. Therefore, it seems appropriate to
choose between mobile agents and message passing in
every specific instance. The proposed system would also
gain in performance by allowing for choice between mobile
agents and message passing.
Reduction of communication traffic by using mobile
agents is illustrated below by the example of a distributed
DB. Consider three databases (each including a 10 u 10
table) and one application connected by a network; the
application is searching the data located in one of the DBs.
Every DB supports basic search functions (line-by-line
retrieval) but not a specific search function requested by the
application (e.g., dictionary-based similarity search, or
search based on multiple constraints). In the example the
frequency of communications via the network was meas-
ured in the case in which the application searches the DBs
remotely, and in the case in which the application sends a
mobile agent to the DBs together with a specific search
function, and the agent performs local search at the desti-
nation and returns with the results. In 10 runs with ran-
domly changed data locations, the result was an average of
28 communications in the former case, and 3 in the latter
case. Of course, these results are not general, and the
assumptions are beneficial for mobile agents. Nevertheless,
the experimental setup is not impractical, thus providing a
qualitative confirmation. Such a reduction of communica-
tion traffic seems efficient if infrequent communications,
even though involving voluminous data, are preferable (i.e.,
with unstable communication lines). In addition, most trou-
bles in distributed systems may be divided into network-re-
lated and server-related. The reduction of communication
traffic by using mobile agents means a lower probability of
network trouble in the course of a processing cycle.
5.2. Implementation
The performance of the DB system used in our ex-
ample cannot be assessed unconditionally because of a
heavy dependence on the response time of databases and
other components. For example, with the system used to
solve the N-Queens problem above, about 1 second is
required for three to five backtracks.
In addition, when the mediation agent migrates car-
rying a unified IP and the results of partial problem calcu-
lations, its code size may become rather large. In this
context, several solutions are available. For example: data
are acquired by remote loading as needed rather than being
carried from the beginning; data remain in storage at the
wrappers and then are referenced via the network; the IP
and data are carried in compressed format, and then recov-
ered as necessary, and so on.
5.3. Applications
For the time being, the following two applications of
the proposed system are available.
x An equipment shutdown scheduling system for a
distributed electric power network [18]
x A recycling information system based on network
agents
The equipment shutdown scheduling system sup-
ports 10 connected power systems, with up to 24 mediation
agents in use. In the case of the recycling information
system, 14 components are supported, with up to 3 media-
tion agents in use. Space limitations prevent us from giving
more specific detail, and we therefore plan to report on the
applications in a separate publication.
The proposed system is thought to be adequate for
the above applications because they involve partial modifi-
cations in processing flow after operation is started; in
addition, it is desirable to build a distributed system while
utilizing existing systems as much as possible. However, in
order to provide mediation agents with IPs and to encapsu-
late system components in wrappers, the developer must
comprehend the working environment and objectives of the
distributed system to be developed. Therefore, this ap-
53
proach does not apply to problem solving that requires
cooperative operation based on the agents� autonomous
behavior.
Another desired adaptation of existing systems is
their independence as distributed components. Specifically,
if existing applications have internal states and transient
states that depend heavily on another application�s states
and other external factors, it is quite difficult to employ such
systems as components of a distributed system. For exam-
ple, it may well happen that the transactions of individual
databases can be controlled by their wrappers but when a
transaction takes place in a distributed DB, individual da-
tabases are no longer completely independent. As a solution
to handle such applications, one may think of storage and
appropriate switching among transient and intermediate
states, or the use of locks. The former solution may be
illustrated by a distributed scheduling system composed of
multiple schedulers [19], while the latter is employed when
two- or three-phase commitments are applied to multiple
databases.
In addition, the results of problem-solving IP unifi-
cation are likely to be different for distributed systems
composed of homogeneous and heterogeneous compo-
nents. The contribution of IP unification to easier design
and better maintainability is explained primarily by the
three points stated in Section 3.2.3. Point (1) is the most
important point of the present paper. IP unification makes
global processing flow in a distributed system more trans-
parent, which contributes to easier design, including detec-
tion and correction of defects. This advantage appears
unconditional, applying to both homogeneous and hetero-
geneous distributed components (most distributed systems
include both types of components; with the N-Queens
system, too, the first queen is slightly different from the
second and third queens, or from the fourth queen). On the
other hand, point (3) assumes that the processing order is
modified, which is hardly possible with heterogeneous
components. As regards point (2), repetitive processing is
assumed, which may occur periodically with heterogene-
ous components as well (e.g., A-B-C-A-B-C-A-B-C). That
is, IP unification may prove efficient. Thus, the unification
of problem-solving IPs can be considered efficient in gen-
eral, though if the system components are heterogeneous,
the unification effect may be smaller than in a homogeneous
system.
Further study is necessary to estimate the practical
applicability of the proposed IP unification to various do-
mains. At least, the separation of problem-solving IPs
seems possible for the workflow-type processing that con-
stitutes a major part of the applications in corporate distrib-
uted systems. In most cases, even complicated workflow
processing is clearly ordered, with a large part being se-
quential. Therefore, such processing can be represented by
means of mediation agents provided with unified IPs. In
addition, extensive research is under way to analyze inter-
active protocols for various applications (not limited to
workflow processing), and to develop design patterns. The
state of the art in this field is reported in Ref. 20. From the
viewpoint of IP description support, modularization and
reuse of IPs is made possible by the implementation of IP
states as classes. In addition, a graphical environment for
interaction protocol development is being studied in order
to simplify description.
6. Conclusions
This paper proposes the Bee-gent (Bonding and En-
capsulation Enhancement aGENT) agent framework,
whose objective is the flexible integration of legacy sys-
tems, package software, and other existing systems by
providing coordination and communication among the
components of distributed systems.
Topics for further studies in this direction include the
development of a framework for data sharing and negotia-
tion between mediation agents, consistency checking of
IPs, including logical compatibility, deadlocks, and so on,
on-the-fly modification of IPs by users or by mediation
agents themselves, support for interaction with users, and
so on.
Acknowledgment. The authors express their deep
gratitude to Mr. K. Aikawa, Corporate R&D Center,
Toshiba Corp., for providing the opportunity to carry out
this study.
REFERENCES
1. Genesereth MR, Ketchpel SP. Software agents. Spe-
cial Issue on Intelligent Agents. Commun ACM
1994;37:48�53.
2. Bee-gent: multi -agent framework, http://
www2.toshiba.co.jp/beegent/index.html, 1999.
3. Agha G. Actors: A model of concurrent computation
in distributed systems. MIT Press; 1986.
4. Finin T, Wiederhold G. An overview of KQML: A
knowledge query and manipulation language. De-
partment of Computer Science, Stanford University,
1993.
5. Patil PS, Fikes RE, Patel-Schneider PE, McKay D,
Finin T, Gruber TR, Neches R. The DARPA knowl-
edge sharing effort: Progress report. Proc 3rd Int
Conf on Principles of Knowledge Representation and
Reasoning, 1992.
54
6. Barbuceanu M, Fox MS. Cool: A language for de-
scribing coordination in multi agent systems. Proc 1st
Int Conf on Multi-Agent Systems, 1995.
7. Chauhan D. JAFMAS: A Java-based agent frame-
work for multiagent systems development and imple-
mentation. Ph.D. thesis, ECECS Department,
University of Cincinnati, 1997.
8. Kuwahara K, et al. AgenTalk: Cooperative protocol
description for multi-agent systems. Trans IEICE
1996;J79-B-I:346�354.
9. Austin JL (editor). How to do things with words.
Oxford University Press; 1962.
10. Garcia-Molina H, Hammer J, Ireland K, Papakon-
stantinou Y, Ullman J, Widom J. Integrating and
accessing heterogeneous information sources in
TSIMMIS. AAAI Spring Symposium on Informa-
tion Gathering from Heterogenous, Distributed Envi-
ronments, p 61�64, 1995.
11. Fox MS. A common-sense model of the enterprise.
Proc Industrial Engineering Research Conference, p
178�194, 1993.
12. Fox MS, Barbuceanu M, Gruninger M. An organiza-
tion ontology for enterprise modeling: Preliminary
concepts for linking structure and behavior. Proc 4th
Workshop on Enabling Technologies, Infrastructure
for Collaborative Enterprises. IEEE Computer Soci-
ety Pres; 1995. p 237�251.
13. Martin FJ, Plaza E, Rodriguesz-Aguilar JA, Sabater
J. JIM: A Java interagent for multi-agent systems.
Proc AAAI-98 Workshop on Software Tools for De-
veloping Agents.
14. FIPA97 Specification. http://www.cselt.it/fipa/spec/
fipa97/fipa97.htm, 1997.
15. Extensible Markup Language (XML) 1.0.
http://www.w3.org/TR/REC-xmlXML, 1998.
16. FACTS (FIPA Agent Communication Technologies
and Services, ACTS Project AC317).
http://www.labs.bt.com/profsoc/facts/, 1999.
17. White JE. Mobile agents. In: Bradshaw JM. Software
agents. MIT Press; 1997. p 437�472.
18. Kawamura T, et al. Approach to distributed constraint
satisfaction problems using mobile agents. Tech Rep
IEICE 1998;AI98-3.
19. Kawamura T, et al. Development of a distributed
cooperative scheduling system based on negotiation
between schedulers. Trans IEICE 1998;J81-D-
I:505�513.
20. Tahara Y, Ohsuga A, Honiden S. Agent system devel-
opment method based on agent patterns. Proc 21st Int
Conf on Software Engineering, IEEE, p 356�367,
1999.
AUTHORS (from left to right)
Takahiro Kawamura (nonmember) graduated from Waseda University in 1992 and completed the M.E. program in
1998. He then joined Toshiba Corp., and is now at the Computer Networks Lab, Corporate R&D Center. His research interests
include distributed Al, multiagent systems. He is a member of the Japanese Society for Artificial Intelligence and the Information
Processing Society of Japan.
Yasuyuki Tahara (nonmember) received his B.S. degree in mathematics from the University of Tokyo in 1989 and
completed the M.E. program in 1991. He then joined Toshiba Corp. In 1996�97 he was a guest researcher at City University
(United Kingdom), and in 1997�1998 a guest researcher at Imperial College (United Kingdom). He is now at the Computer
Networks Lab, Toshiba Corporate R&D Center. His research interests include agent technologies and software. He is a member
of the Information Processing Society of Japan and the Japan Society for Software Science and Technology.
55
AUTHORS (continued) (from left to right)
Tetsuo Hasegawa (nonmember) received his B.S. degree in electrical engineering from Waseda University in 1985 and
completed the M.E. program in 1987. He then joined Toshiba Corp., and is now at the Computer Networks Lab, Corporate R&D
Center. His research interests include distributed processing technologies, agent systems. He is a member of the Information
Processing Society of Japan.
Akihiko Ohsuga (member) obtained his B.S. degree in mathematics from Sophia University in 1981 and joined Toshiba
Corp. He is now at the Computer Networks Lab, Corporate R&D Center. He has a D.Eng. degree. He was on assignment at the
Institute for New Generation Computer Technology from 1985 to 1989. His research interests include formal methods for
software, agent systems. He received a 1986 Paper Award from the Information Processing Society of Japan. He is a member
of IEEE, the Information Processing Society of Japan, and the Japan Society for Software Science and Technology.
Shinichi Honiden (nonmember) obtained his B.S. degree in electrical engineering from Waseda University in 1976 and
completed the M.E. program in 1978. He then joined Toshiba Corp., and is now at the Computer Networks Lab, Corporate R&D
Center. He holds a D.Eng. degree. He became a lecturer at Waseda University in 1989 and at Osaka University in 1996. His
research interests include agent systems. He received a 1986 Paper Award from the Information Processing Society of Japan.
56
top related