Bee-gent: bonding and encapsulation enhancement agent framework for development of distributed systems

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