Upload
sen-yoshida
View
213
Download
1
Embed Size (px)
Citation preview
Shine: a peer-to-peer based framework of network community
support systems
Sen Yoshida*, Koji Kamei, Takeshi Ohguro1, Kazuhiro Kuwabara
NTT Communication Science Laboratories, Nippon Telegraph and Telephone Corporation, Japan
Received 9 October 2002; accepted 9 October 2002
Abstract
A discussion is presented on Shine, a framework of communication systems that support network communities. Shine provides a unified
structural design approach to various network community support systems and enables them to share software components and cooperate
with each other. Furthermore, Shine has a peer-to-peer architecture, which enables personal agents to form communities suitable for each
user by exchanging data in a peer-to-peer style. These features of Shine are described and its effectiveness as a framework is verified by
applying it to several systems.
q 2002 Elsevier Science B.V. All rights reserved.
Keywords: Peer-to-peer; Personal agents; Network community; Software architecture; Ubiquitous computing
1. Introduction
An increasing number of network communities are
emerging on the Internet and other public networks.
Members in a network community actively and intimately
communicate with each other by using e-mail, electronic
chat rooms, bulletin board systems, and so on.
Considering this situation, a multitude of projects have
been developing systems to support communications in
network communities by utilizing mobile systems, multi-
media systems, natural language processing, and other
advanced technologies [1]. These systems are called
socialware [2].
As ubiquitous computing develops, our face-to-face
communication activities in the real society as well as
online communication will be supported by computers.
These two societies are going to be merged. Therefore,
socialware is getting much importance and becoming one of
the most promising application area for ubiquitous
computing.
The authors are developing a framework named Shine [3,
4] to help build various socialware applications. The
framework provides a design guideline and enables different
applications to share program components and cooperate.
Shine features a peer-to-peer architecture, in which personal
agents can flexibly form communities suitable for each user
by exchanging information directly to peer agents.
We discuss the significance of a peer-to-peer based
framework of socialware applications in Section 2 and
describe Shine’s structure in detail in Section 3. We then give
some examples of building applications in the Shine
framework in Section 4. We conclude this paper in Section 5.
2. Peer-to-peer based framework of socialware
applications
In this section we explain why a framework is necessary
for socialware applications and why a peer-to-peer archi-
tecture is effective for this purpose. We also compare our
approach with related works.
0140-3664/03/$ - see front matter q 2002 Elsevier Science B.V. All rights reserved.
PII: S0 14 0 -3 66 4 (0 2) 00 2 54 -2
Computer Communications 26 (2003) 1199–1209
www.elsevier.com/locate/comcom
1 Presently with Nippon Telegraph and Telephone East Corporation
(NTT-ME).
* Corresponding author. Address: NTT Communications Science
Laboratories, Japan.
E-mail address: [email protected] (S. Yoshida).
2.1. Necessity of a framework for socialware applications
The word ‘socialware’ represents communication sys-
tems that support network communities. It is easy to think of
many applications of socialware. Here we enumerate those
applications in two categories: those that exploit the merits
of forming communities and those that support community
formation, maintenance, and evolution.
Applications exploiting the merits of forming commu-
nities include:
† Circulation of information via word-of-mouth human
networks, such as recommendations and collaborative
filtering [5];
† Arrangement of informal, suggestive or creative con-
versations, such as brain-storming sessions [6,7];
† Establishment of efficient collaborations for developing
resources such as open source software or databases; and
† Arrangement of localized and informal economic
activities like auctions [8] and flea markets.
Applications that support community formation, main-
tenance, and evolution include:
† Arrangement of effective encounters and support for
becoming aware of potential communities [9,10];
† Maintenance of intimacy and community feelings [11];
† Support for establishing individual identities in
communities.
While we can think of a variety of socialware
applications, certain functions are commonly required
by all of these applications. These functions include
storage of data on community members and flexible
communication utilities that adapt to frequent reorganiz-
ation of the community. At present, however, there is no
framework that can provide these common functions.
Consequently, most socialware applications are devel-
oped as independent systems. Therefore, there is no
cooperation among applications or sharing and reuse of
program components.
In recent years, the importance of software architecture
in software development has widely been recognized [12]. It
is said that there are three advantages of using software
architecture:
† Developers can use it as the basis for creating mutual
understanding, forming consensus, and communicating
with each other.
† It represents the earliest set of design decisions about a
system, and these decisions greatly influence the
system’s remaining development, its service in deploy-
ment, and its maintenance activity.
† It embodies a model that is transferable across
systems and promotes large-scale reuse.
We could have these benefits in building socialware
applications if there were a framework that provided a
software architecture for socialware.
For these reasons, we are developing a framework named
Shine as a common basis of various socialware applications.
2.2. Effectiveness of peer-to-peer architecture for
socialware
We adopt a peer-to-peer based architecture in designing
Shine. In this subsection we explain why the peer-to-peer
approach is effective for socialware.
A network community has the advantage of freedom
from geographical or time constraints over a real-world
community. This freedom, however, brings difficulty in
communication: a member may suffer an information
overflow or hesitate to act and end up isolated in a huge
mass of strangers. Therefore, in designing a socialware
application, we have to keep in mind that the system should
enable people to communicate naturally in a suitable size of
community.
Most of today’s network communities reside on bulletin
board systems, chat systems, or other systems served by
commercial (or non-profit) providers. Unfortunately, those
systems, designed in client–server architecture, do not
enable users to form communities that fit their communi-
cation capabilities. A client–server based socialware
application typically divides a set of users into communities
of interest. However, even if users are divided according to
their interests, the size of each community is still unlimited,
so the possibility of communication overflow remains.
Additionally, dividing the users into communities of
excessively specific interest reduces the variety in members
and consequently the attraction of each community. More-
over, when there are a lot of sites that each serves a small
number of people, each user’s chance to enlarge his/her
acquaintance relations is restricted.
In real society, people have peer-to-peer relations with
their acquaintances and meet unknown others by mediating
or introducing themselves. Consequently, they flexibly
change their peer-to-peer relations and reorganize their
communities in a quite decentralized and cooperative way.
This style of organization makes the real society a small-
world [13], which has a combination of high local clustering
and short global pathlengths.
We can expect that if people in network communities
were able to reorganize their communities in as decen-
tralized and cooperative a way as in real communities, they
could form a small-world even in online society. To realize
such an organization, the most suitable approach is a peer-
to-peer based system where a personal agent dedicated to
each user exchanges information directly with other agents
and forms communities of a preferable size.
In addition, as ubiquitous computing glows, people begin
to carry their personal computers to everywhere and bring
their personal information with the computer. Therefore, it
S. Yoshida et al. / Computer Communications 26 (2003) 1199–12091200
will be natural that each person will have his/her personal
agent in his/her computer and make the agent manage the
personal information. In this situation, such an agent is
expected to support the user’s communication by exchan-
ging necessary information with peer agents.
Furthermore, a lot of peer-to-peer based file sharing
systems and other applications are getting popular [14].
Generally, a peer-to-peer system has advantages over a
client–server system:
† It can distribute loads and therefore does not need a huge
machine to handle a large quantity of service requests.
† It is robust. A client–server based system completely
stops if the server fails, but a peer-to-peer based
system does not stop even if some peers fail.
Considering these reasons, we took the approach of
designing Shine as peer-to-peer based framework.
In our approach, the control mechanisms and data for
communication are distributed to each person. Namely, the
Shine system provides each user an agent that is dedicated
to the person’s social interactions as shown in Fig. 1. A
Shine agent resides in the user’s personal computer, whether
it is desktop, laptop, or palmtop, and is connected to other
agents via wired or radio connections. These agents
exchange personal information with each other and
collaboratively perform the necessary actions such as
mediation or self-introduction in order to dynamically
change community formation.
2.3. Comparisons with related works
The ADIPS Framework [17] is a framework for flexible
distributed systems. Several network applications such as a
flexible video conference system, a flexible asynchronous
messaging system, and a system named CyberOffice have
been developed on top of the ADIPS Framework. The main
feature of the ADIPS Framework is that each node of an
ADIPS application system can be flexibly and dynamically
reconfigured to adapt to changes in its environment such as
QoS or the user’s preferences. To achieve this adaptability,
each module of an ADIPS system’s node is agentified and
exchanges messages with other modules. On the other hand,
we call a node of Shine an agent because it is personalized
and communicates with other personal agents to adapt to
changes in the user’s social situation.
KQML [18] specifies a message format and a set of
message handling protocols that are suitable for knowledge
sharing among agents. There are a number of multi-agent
platforms that implement this specification. KQML speci-
fies an inter-agent communication protocol, but does not
specify anything about realizing a database or an agent
action plan, which are necessary for building a multi-agent
system. Shine provides an architecture that specifies the
internal structure of an agent as well as the inter-agent
communication.
MINDS [19] is a multi-agent system for collaborative
document retrieval. In this system, each personal agent
knows documents stored in its user’s workstation and also
has metaknowledge about who possibly owns documents
about what topic. When a user asks his/her agent for
retrieving documents about a topic, the agent intelligently
submits queries to other agents using this metaknowledge.
MINDS is one of the pioneers in collaborative personal
agents, but its domain is limited to information retrieval.
Shine provides a framework for various socialware
applications including collaborative information retrieval
and others.
There are a lot of agent systems that focus on agent
autonomy, e.g. Plangent [20]. An agent in such a system
plans its own actions by itself with respect to declaration of
the agent’s goal or action rules written by the application
developer. This function works to good effect in developing
applications in which an agent acts to achieve a specific
task, e.g. to schedule a trip. On the other hand, a Shine agent
acts to support the user’s social interaction, which is not
achieved by completing a single task. Accordingly, the
application development style of declaring a goal or action
rule is not suitable for socialware. For this reason, agent
actions are programmed as specific procedures by the
application developer.
3. Internal structure of a Shine agent
In this section we describe the structure of Shine in
detail.
As described in Section 2.2, Shine provides a personal
agent to each user. Fig. 2 shows an overview of a Shine
agent’s internal structure. In a Shine agent, there are several
core modules, i.e. Person database, plan execution module,
and communication module. in addition, one or more
applications are installed in each agent. Specifically, Shine
is implemented with a typed procedural programming
language with network utility, like Java.2 An application
provides its service to the user by using functionalities of
Fig. 1. Personal agents. 2 Java is a trademark of Sun Microsystems Inc.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–1209 1201
the core modules via an application programming interface
(API).
3.1. Person database
The Person database holds data on people and personal
agents. The data include information on the agent and the
user whom the agent is associated with as well as other
agents and people known to the agent. Each application
refers to and modify the data to provide its service. Because
Shine is a peer-to-peer based system, the extent of known
others differs from agent to agent. An agent holds the data
required to form a community that is suitable to the user in
the Person database and exchanges data among other agents
when necessary.
In the Shine architecture, a user and his/her personal
agent correspond in a one-to-one manner. Therefore, in the
Person database, data on both a user and his/her personal
agent are stored without distinguishing between them. Data
on the user includes his/her name and birth date, and data on
the agent includes the agent ID and the address for inter-
agent communication.
In the Person database, ‘name’, ‘birth date’, or ‘agent ID’
are called attributes of data. Data on an attribute is called
attribute values. We denote the set of attributes as A and an
attribute value of the attribute a [ A as xa [ Xa:
Shine’s Person database has a table that maps a pair of a
person and an attribute to an attribute value (Fig. 3). In the
table, each row represents a person or an agent that is
dedicated to the person, and each column represents an
attribute. In other words, a column in the table is a mapping
fa : P ! Xa; where P is the set of people stored in the Person
database. A function is provided as an API to get the
attribute value faðpÞ [ Xa of any person p [ P and an
attribute a by using the mapping.
Data can be stored in the Person database in various
forms. Not only simple numbers or character strings such as
agent IDs or user names but also complex objects can be
stored. For example, in the vector space model, which is
used by information retrieval systems to roughly represent a
person’s interest, data is formed as a keyword vector, i.e.
a collection of pairs of keywords and numeric values, for
instance:
{ktravel; 0:7l; kfood; 0:3l; · · ·}
We can also think of storing a mailbox which archives mails
received from a person into the Person database as an
attribute value of the person.
An attribute whose value can be used to identify a person
is called a key attribute. Namely, an attribute ‘key’ is a key
attribute if and only if, for
Xkey ¼ {fkeyðpÞlp [ P}
there exists a reverse mapping f21key : Xkey ! P and the
attribute value and the person are one-to-one, i.e.:
xkey ¼ fkeyðpÞ , p ¼ f21key ðxkeyÞ
For example, ‘agent ID’ is a key attribute and its values are
used for identifying senders and receivers in inter-agent
communication as well as for writing contents of the Person
database to a file and reading from it. The API for this
purpose provides a function to search a person f21key ðxkeyÞ [
P who has an attribute value xkey [ Xkey:
In Shine, both a mapping from a person to an attribute
value fa : P ! Xa and a reverse mapping from a key
attribute value and a person f21key : Xkey ! P are resolved
rapidly by utilizing a hash process. An API is provided such
that an application can easily get, for instance, an ‘interest’
of a person whose value of the key attribute ‘name’ is
Yoshida, i.e.:
finterestðf21nameðYoshidaÞÞ
The Person database also has an event generation function.
When an attribute value of a person is added, changed, or
removed, an event occurs. other modules such as plan
execution module observe occurrences of these events and
perform appropriate actions in response to them. This event
notification mechanism enables cooperation among different
modules and federations of multiple applications. For
example, when an agent receives a notification of a change
in its user’s interest from another agent and the corresponding
Fig. 2. Internal structure of Shine agent.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–12091202
keyword vector is modified, an event is generated, and an
application catches this event and refreshes its display.
Because socialware is designed to support communities,
the Shine framework needs a mechanism that can explicitly
handle a community of agents in addition to individual
agents. To handle communities, Shine’s Person database
defines for each community a person set (Fig. 3) and
provides operations for dealing with a set of personal
information. Namely, the framework provides a mechanism
to extract the members of a specific community S # P using
a membership function m : Xa £ Xb £ · · · ! {true; false} :
S ¼ {plmðfaðpÞ; fbðpÞ;…Þ ¼ true}
A person set observes each member’s values of attributes
a; b;… that effect his/her membership in order to adjust to
dynamic changes in the organization of the community.
Many socialware applications need a function to broad-
cast messages to the members of a community. In a peer-to-
peer based architecture, unlike a client–server architecture,
determining the range of broadcasting is not obvious. A
Shine agent can flexibly determine the range of broadcasting
by regarding a person set as the destination list.
3.2. Communication module
The communication module is directly connected to a
certain number of other agent’s communication modules so
that the agents can form a peer-to-peer network. These
communication modules exchange messages with each
other.
As described before, Shine’s personal agents are
supposed to reside in a ubiquitous computation environ-
ment. Accordingly, we have to take into account a variety of
conditions for communication: connection is dial-up or
continuous; there’s a firewall or not; the available protocol
is HTTP, SMTP or others; network topology is peer-to-peer
or centralized, etc.
To abstract such variance in communication environ-
ments and prevent this variance from affecting other
modules and applications, Shine’s communication module
is separated into a part that is dependent on the lower-level
communication protocol and a part that is independent
(Fig. 4). The dependent part is called a channel. A channel
encodes and decodes messages to adjust the lower-level
protocol and controls the connection.
Connections among channels are not always peer-to-
peer; it might be centralized depending on the topology of
the lower-level network. Although the network topology in
the layer of channels can be centralized, the logical topology
is always peer-to-peer in the layer of inter-agent communi-
cation. Consequently, every agent manages its address book
of the neighbor agents by itself, and it cannot utilize
functions that are provided by a specific lower-level
communication protocol.
Addressesofotheragents are stored in thePersondatabase.
When the plan execution module or other modules want to
send a message, they construct a message and set a person
Fig. 3. Person database.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–1209 1203
p [ P stored in the Person database as the destination of the
message. The channel in the communication module resolves
the address of p for lower-level communication: faddressðpÞ:
The channel also set the agent’s address faddressðselfÞ as the
message’s sender. Then the channel sends the message to the
receiver agent’s channel. The receiving channel resolves a
person entry of the Person database corresponding to the
sender address: f21addressðsender_addressÞ:The resolved person
entry is attached to the message, which is then passed to the
plan execution module.
A channel uses an attribute for storing addresses
depending on the lower-level communication protocol.
For instance, a channel that uses HTTP as the lower-level
communication looks up addresses in the ‘URL’ attribute
and a channel that uses SMTP looks up addresses in the
‘mail address’ attribute.
More specifically, a message is exchanged via a channel
in the following sequence. To send a message, a channel
needs to implement a method sendðMessageÞ as below.
Here, Message is a type of object that represents messages
and has methods like getTo() for getting the destination and
getContent() for getting the content of the message. The
content of the message extracted using the method
getContent() is assumed to be serializable to a character
sequence and be able to be restored from it. Due to this
requirement, Shine’s communication module can adapt to
protocols that can transmit only characters, e.g. SMTP.
procedure send (Message m) {
/* Gets the destination.
Person is the type for person entries in the Person
Database.*/
Person p ¼ m.getTo();
/* Gets the address.*/
Address a ¼ db.get( p,address);
/* Converts the content of the message into the format
that can be transmitted via the lower-level protocol*/
Data d ¼ convert(m.getContent());
/* Emits the message.*/
emit(a, d );
}
To receive the message, channels execute the following
procedure. When data d is transmitted from b, this
procedure is called with b and d as parameters. Calls of
this procedure can be automatic or non-automatic. In the
case of an automatic call, the lower-level protocol calls the
procedure in response to receiving a message. In the case of
a non-automatic call, the channel performs periodic polling
to check the receipt of messages, and if there are messages
the procedure is called.
procedure receiveðAddress b;Data dÞ {
/* An object for the message to be restored.*/
Message m;
/* Identifies the person entry from the address.*/
Person q ¼ db:identify(b, address);
/* Sets the sender of the message to the identified
person.*/
m:setFrom(q );
/* Restores the content of the message.*/
m.setContent(restore(d ));
/* Passes the restored message to the Plan Execution
Module.*/
planExecution:put(m );
}
3.3. Plan execution module
We call a description of agent action rules a plan. In
Shine, multiple plans are executed concurrently in the plan
execution module. Some plans are prepared to perform
services of applications while other plans are provided by
Shine to do fundamental or common tasks. Fig. 5 shows the
structure of the plan execution module.
A plan acts in response to external events. There are three
types of events:
† receipt of a message from another agent,
† a change of a value stored in the person database, and
† an input from the user.
Fig. 4. Channel.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–12091204
Actions are concretely described in the programming
language in which Shine is implemented. For this
description, an API provided by Shine is used. The
API includes a method to send a message, methods to
handle the Person database as described in Section 3.1,
and others.
The plan execution module has a function to distribute
messages received by the communication module to
appropriate plans. Each message has a field to specify the
message type, and the message is distributed according to
the message type. Namely, Shine agents are typed-message
agents [15]. The distribution mechanism is realized as
follows: each plan registers message handlers that is
invoked by the plan execution module when a message of
the specified type arrives. The API for message handler
registration is:
addHandlerðMessageType;MessageHandlerÞ
where MessageType is a type for objects that represent
message types and MessageHandler is a type for message
handler objects that implements the method handle(Mes-
sage). An agent action is described as the body of the
method handle.
A change in a value stored in the person database is
reflected to agent actions in such a way that each plan
receives the events that notify the change. Using this
mechanism, two plans can cooperate. That is, when a plan
modifies an attribute value of a person, the other plan adapts
to the change by receiving an event that occurs by the
modification of the value. This event is realized as an object
of type PersonDBEvent. Objects of this type implement
methods to get the new attribute value, the old value, the
attribute where the value is stored in, and the person who
owns the value.
Concerning inputs from the user, each application
provides its user interfaces and binds it to a plan.
4. Building applications in the Shine framework
In this section we use some examples to explain how the
Shine framework is applied to socialware applications.
Here, we focus on the examples of community organizer
and Gleams of People, both of which we are developing. We
are building these applications as well as Shine in Java. We
will show that the Shine framework is suitable and effective
for building these applications.
4.1. Community organizer
4.1.1. An overview of community organizer
Community organizer is an application that supports
people in forming new network communities [10]. This
application regards people sharing interests as potential
members of a community of interest and provides them with
a place where they can meet and communicate.
Fig. 6 is a sample of a screenshot that is provided to each
user by community organizer. The view panel shown in the
figure is provided as a place where potential members of a
community meet and communicate. This panel displays a
two-dimension projection of multidimensional space whose
axes are keywords in the vector space model. The user can
put an icon on the panel, and the icon appears on other users’
panels. A keyword vector is attached to each icon and it is
used to determine the position of the icon on the panel. In
determining the position, relative distances among icons are
calculated according to the cosine for each pair of keyword
vectors, so that icons with similar keyword vectors are
placed closer to each other.
The center point of the view has its keyword vector too,
which is indicated by the slide bars next to the view panel.
The user can determine its values by adjusting the slide bars.
The placement of the icons will change following the
change in the value of the center’s keyword vector. When
the user adds a new icon, its keyword vector’s value is set to
the same as the center.
Fig. 5. Plan execution module.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–1209 1205
The user looks around the vector space by changing the
keyword vector of the center with the slide bars to find
potential communities. When the user adjusts the slide bars
to the large value of, for instance, ‘travel’ and ‘food’ and
adds a new icon, he/she consequently expresses to others
that he/she is interested in travel and food. Thus, community
organizer’s view panel is a media to visualize the vector
space with a lot of ‘interest icons’ representing the
expression of having interests.
Community organizer integrates a communication func-
tion with this visualization function. This is done by
providing an interface that allows a user to attach his/her
message to an icon. Other users can read the message by
clicking on the icon and reply to it by placing a new icon at a
closer position and attaching a reply message to it. This
integration of the visualization function and the communi-
cation function produces a utility that is quite suitable for
members of a community of interest.
4.1.2. Community organizer on Shine
At first, we developed community organizer independent
of the Shine framework. The following paragraphs describe
how we revised community organizer to fit the Shine
framework. This revision brings certain advantages to
community organizer.
† By implementing program components under the unified
framework and using a common API, we can preserve
those program codes as libraries. Other applications can
reuse program codes for community organizer, and
community organizer can reuse program codes for other
applications.
† It is possible to make community organizer cooperate
with other applications by means of sharing data on
people with those applications.
† The previous version of community organizer was
designed as a client–server system. After the revision,
the architecture changed to a peer-to-peer based system.
This brings the advantages pointed out in Section 2.2.
The architecture of the Shine-based community organi-
zer is shown in Fig. 7.
An interest icon in community organizer has information
on the user who created the icon, the keyword vector
associated with the icon, and the message attached to the
icon. To store these data into Shine’s person database, an
attribute named ‘interest icons’ is used. An attribute value in
this attribute is a set of interest icons. An object that includes
the keyword vector and the attached message is added to the
set at the cell of the interest icons’ attribute column and the
row for the person who created the icon.
To display an interest icon on the view panel, all icons in
the icon set finterest_iconsðpÞ of each user p are drawn using the
image fimageðpÞ:
On the view panel of community organizer, only
interest icons that have keyword vectors similar to the
center keyword vector are selected and displayed among
all interest icons stored in the database. A person set of
the person database can be utilized in this selection.
Namely, a person set whose membership function selects
icons that have keyword vectors similar to the center
Fig. 6. Sample screenshot of community organizer.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–12091206
keyword vector is prepared, and the elements of this
person set are displayed on the panel.
As described in Section 2.2, Shine adopts a peer-to-peer
based architecture. When community organizer is ported to
Shine, each client program is agentified. Such an agent
exchanges personal information with other agents in a peer-
to-peer manner. As a result, each agent can utilize the small-
world of agents to provide a place that is suitable for each
user.
The community organizer plan in the plan execution
module performs actions such as sending a newly created
interest icon to other agents and storing an interest icon that
is sent from another agent and received by the communi-
cation module into the person database.
4.2. Gleams of people
Gleams of People [11,16] is a communication system
with an unusually simple medium that supports a commu-
nity member to maintain his/her community feeling by
exchanging his/her presence and mood with other members.
The function of this system is, so to speak, the pingcommand among people. A normal ping command is used
to check whether a computer is alive or not by sending a
packet from another computer to receive a reply packet.
Gleams of People works in the same way but among people,
not computers. A message exchanged among Gleams of
People terminals carries not only presence of the sender but
also his/her current mood, which is represented as a color.
Fig. 8 is a sample screenshot of Gleams of People.
Fig. 7. Shine-based community organizer.
Fig. 8. Sample screenshot of Gleams of People.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–1209 1207
This application works as follows. First, the user selects a
color that represents his/her current mood and chooses several
friends as receivers. The chosen friends are displayed on the
screen as circles. When the user double-clicks on an icon, a
ping is sent to the personal agent that is associated with the
corresponding friend. The ping packet is colored to represent
the sender’s current mood. At the other side, when a ping is
received, the corresponding icon’s color changes to the
conveyed one, and an animation is performed so that the
receiver can be aware of that. At the same time, a reply packet
is automatically sent back with the receiver’s current mood.
As with community organizer, Gleams of People was
also developed independent of the Shine framework. The
original system consisted of some personal agents and a
message router called the repeater. Thus the network
topology was centralized so that messages were transmitted
across the repeater. The repeater had a function to spool a
message in case the destination agent was not up.
We have revised this message transmission mechanism
so that it can be adapted to the Shine framework. In the
revised version, the repeater is hidden under the channel
layer (Fig. 9). Accordingly, the logical network topology is
centralized on the channel layer, while the topology on the
inter-agent communication layer is peer-to-peer. Further-
more, we can easily replace the channels with peer-to-peer
based ones.
This application uses the person database’s attributes
such as ‘name’, ‘color’, and ‘mailbox’.
4.3. Considerations for building the two applications on
Shine
Fig. 10 shows a comparison of the total sizes of our
implementation’s Java class files in the Shine framework
(the total size of class files of community organizer without
Shine and other libraries and the total size of class files of
Gleams of People without Shine). The Shine framework
accounts for about 19% of community organizer and 53% of
Gleams of People.
We have integrated community organizer and Gleams of
People on the Shine framework. The two applications work
concurrently on one agent. person database, communication
module, and plan execution module are shared. We can
envision cooperation between the two applications by
sharing some attribute values. For example, the frequency
of ping messages in Gleams of People can be regarded as a
parameter to measure the degree of intimacy, and
community organizer can use this parameter in positioning
icons on the view panel.
5. Conclusions
In this paper, we discussed the necessity of a peer-to-peer
based framework for socialware and described the structure
of the Shine framework that the authors are developing.
Moreover, we illustrated how the Shine framework is
applied to the community organizer and Gleams of People
applications. We showed that Shine is suitable and effective
for building these applications.
We are going to study the function of the plan execution
module in more detail by making some actual plans. For
example, if we implement the intelligent query submission
mechanism of MINDS (Section 2.3), such a plan would be
useful for other applications. Moreover, it is particularly
important to develop a plan to mediate information on other
peers to keep the community organization appropriate.
Much work remains to be done besides studying the plan
execution module. We have to pay attention to a privacy
protection facility, like the peer-to-peer based matchmaking
system Yenta [21] has. We will also achieve combined use
of community organizer and Gleams of People by sharing
data. Finally, it is necessary to provide each user a seamless
access to his/her personal agent from different devices in a
ubiquitous computing environment.
References
[1] T. Ishida (Eds.), Community Computing—Collaboration over Global
Information Networks, Wiley, 1998.
[2] F. Hattori, T. Ohguro, M. Yokoo, S. Matsubara, S. Yoshida,
Socialware: multiagent systems for supporting network communities,
Communications of the ACM 42 (3) (1999) 55–61.
[3] S. Yoshida, T. Ohguro, K. Kamei, K. Funakoshi, K. Kuwabara, A
platform for making network community support systems in a
cooperative distributed architecture, in: Y. Shibata (Ed.), Proceedings
Fig. 9. Hiding a repeater under the channel layer.
Fig. 10. Total size of the Java class files.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–12091208
of the Seventh International Conference on Parallel and Distributed
Systems: Workshops (ICPADS 2000 Workshops), 2000, IEEE
Computer Society, Silver Spring, MD, 2000, pp. 441–446.
[4] S. Yoshida, K. Kamei, T. Ohguro, K. Kuwabara, K. Funakoshi,
Building a network community support system on the multi-agent
platform Shine, in: C. Zhang, V.-W. Soo (Eds.), Design and
Applications of Intelligent Agents—Proceedings of the Third Pacific
Rim International Workshop on Multi-Agents (PRIMA 2000),
Lecture Notes in Artificial Intelligence, vol. 1881, Springer, Berlin,
2000, pp. 88–100.
[5] U. Shardanand, P. Maes, Social information filtering: algorithms for
automating ‘word of mouth’, CHI’95 Proceedings: Conference on
Human Factors in Computing Systems: Mosaic of Creativity, ACM
SIGCHI (1995) 210–217.
[6] K. Mase, Y. Sumi, K. Nishimoto, Informal conversation environment
for collaborative concept formation, in: T. Ishida (Ed.), Community
Computing—Collaboration over Global Information, Wiley, New
York, 1998, pp. 165–205, Chapter 6.
[7] S. Matsubara, T. Ohguro, F. Hattori, CommunityBoard 2: mediating
between speakers and an audience in computer network discussions,
in: O. Etzioni, J.P. Muller, J.M. Bradshaw (Eds.), Proceedings of the
Third Annual Conference on Autonomous Agents, ACM Press, New
York, 1999, pp. 370–371.
[8] S. Klein, Introduction to electronic auctions, International Journal of
Electronic Markets 7 (4) (1997) 3–6.
[9] Y. Nishibe, I. Morihara, F. Hattori, T. Nishimura, H. Yamaki, T.
Ishida, H. Maeda, T. Nishida, Mobile digital assistants for
international conferences, in: T. Ishida (Ed.), Community Comput-
ing—Collaboration over Global Information, Wiley, New York, 1998,
pp. 245–284, Chapter 8.
[10] K. Kamei, E. Jettmar, K. Fujita, S. Yoshida, K. Kuwabara,
Community organizer: supporting the formation of network commu-
nities through spatial representation, The 2001 Symposium on
Applications and the Internet (SAINT 2001), IEEE Computer Society
and IPSJ (Information Processing Society of Japan), IEEE Computer
Society, 2001, pp. 207–214.
[11] T. Ohguro, S. Yoshida, K. Kuwabara, Gleams of People: monitoring
the presence of people with multi-agent architecture, in: N.
Nakashima, C. Zhang (Eds.), Approaches to Intelligent Agents—
Proceedings of the Second Pacific Rim International Workshop on
Multi-Agents, Lecture Notes in Artificial Intelligence, vol. 1733,
Springer, Berlin, 1999, pp. 170–182.
[12] P.C. Clements, L.M. Northrop, Software architecture: an executive
overview, Component-Based Software Engineering—Selected Papers
from the Software Engineering Institute, IEEE, Silver Spring, MD,
1996, pp. 55-68.
[13] D.J. Watts, S.H. Strogatz, Collective dynamics of ‘small-world’
networks, Nature 393 (1998) 440–442.
[14] A. Oram (Eds.), Peer-to-Peer: Harnessing the Power of Disruptive
Technologies, O’Reilly, 2001.
[15] C.J. Petrie, Agent-based engineering, the web, and intelligence, IEEE
Expert 11 (6) (1996) 24–29.
[16] T. Ohguro, Toward agents which are suggestive of ‘awareness of
connectedness’, Transactions of the IEICE E84H-D (8) (2001)
957–967.
[17] T. Kinoshita, K. Suganuma, ADIPS framework for flexible distributed
systems, Proceedings of the First Pacific Rim International Workshop
on Multi-Agents (PRIMA’98), Lecture Notes in Artificial Intelli-
gence, vol. 1599, Springer, Berlin, 1998, pp. 18–32.
[18] T. Finin, R. Fritzson, D. McKay, R. McEntire, KQML—a language
and protocol for knowledge and information exchange, in: K. Fuchi,
T. Yokoi (Eds.), Knowledge Building and Knowledge Sharing,
Ohmsha and IOS Press, 1994.
[19] U. Mukhopadhyay, L. Stephens, M. Huhns, R. Bonnell, An intelligent
system for document retrieval in distributed office environments,
Journal of the American Society for Information Science 37 (1987)
123–135.
[20] A. Ohsuga, Y. Nagai, Y. Irie, M. Hattori, S. Honiden, PLANGENT:
an approach to making mobile agents intelligent, IEEE Internet
Computing 1 (4) (1997) 50–57.
[21] L.N. Foner, Community formation via a distributed, privacy-
protecting matchmaking system, in: T. Ishida (Ed.), Community
Computing and Support Systems: Social Interaction in Networked
Communities, Lecture Notes in Computer Science, vol. 1519,
Springer, Berlin, 1998, pp. 359–376.
Sen Yoshida received B. E. and M. Info.
Sci. degrees from Tohoku University, in
1993 and 1995, respectively. In 1995, he
joined Nippon Telegraph and Telephone
Corporation, and has been engaged in
research on distributed cooperative sys-
tems.
Koji Kamei received B. E. and M. E.
degrees from Kyoto University, in 1995
and 1997, respectively. In 1997, he
joined Nippon Telegraph and Telephone
Corporation, and has been engaged in
research on cooperative systems for
supporting group communications.
Takeshi Ohguro received B. E. and
M. E. degrees in computer science from
Tohoku University, in 1988 and 1990,
respectively. In 1990, he joined Nippon
Telegraph and Telephone Corporation.
He is currently researching alternative
network communication media targeted
at connectedness-oriented communi-
cation. He received 7th JICS prize from
Japan Information-Culturology Society
in 2001. His research interests include
P2P agent systems, communication
media, computer mediated communication and community, and
information design.
Kazuhiro Kuwabara received B. E.,
M. E., and Dr. E. degrees from the
University of Tokyo, in 1982, 1984, and
1997, respectively. In 1984, he joined
Nippon Telegraph and Telephone Public
Corporation, and has been engaged in
research and development on knowl-
edge-based systems, multi-agent sys-
tems and socialware. He was a visiting
research scientist at the University of
Massachusetts at Amherst in 1988-1989.
Currently he is a research group leader at
NTT Communication Science Laboratories.
S. Yoshida et al. / Computer Communications 26 (2003) 1199–1209 1209