Design, Specification, and Implementation of a

Distributed Virtual Community System

Tom Gross
Fraunhofer Institute for Applied Information Technology—FIT
Fraunhofer Gesellschaft
Schloss Birlinghoven
53754 St. Augustin, Germany
tom.gross@fit.fraunhofer.de

print archives. They specify a metadata harvesting

Abstract
In this paper we introduce an open distributed virtual
community system that supports knowledge workers with
functionality for searching and browsing in pre-print (e-
print) archives as well as for sharing and exchanging
their findings in virtual communities. Its functionality
combines the strengths of existing systems for information
retrieval of online literature with those for sharing and
exchanging documents in groups or communities. Being
based on open standards such as the Open Archive
Initiatives (OAi) standard and XML-RPC, it allows the
flexible integration of distributed and heterogeneous
components.
1 Introduction
The CYCLADES environment is an open collaborative
virtual archive environment that supports knowledge
workers with functionality for searching and browsing in
pre-print (e-print) archives as well as for sharing and
exchanging their findings in virtual communities.
Existing systems typically only provide a part of the
functionality needed. For instance, systems for
information retrieval of online literature such as the digital
libraries of the ACM and of IEEE for computer science,
Math-Net for mathematics [8], or arXiv for physics [15]
mostly focus on a specific discipline. Systems for sharing
and exchanging documents in groups or communities such
as Wikis [16] or BSCW [6] do not provide functionality
for information retrieval of online literature. Furthermore,
both types of systems are—although often Web-
based—designed and implemented as stand-alone, closed
applications. The CYCLADES environment aims to
combine functionality for information retrieval and for
sharing and exchanging information in groups and
communities. As, it is compliant to the Open Archive
Initiatives (OAi) standard [12], any e-print archives can be
connected to the CYCLADES environment. The OAi
standards provide a technical and organisational framework
facilitating the discovery of content stored in distributed e-
protocol, which supports the communication between
different digital library components.
In this paper we present the functional design of the
system, describe the specification, which was done in a
light-weight UML-like [3, 7] approach, and give details
on the implementation of the overall environment with a
special focus on the component providing the support for
the virtual communities. The focus of attention in this
paper is on the software engineering approach for the
development of the open and distributed CYCLADES
environment. The following chapter describes the
requirements analysis and functional design of the
environment. The next chapter then describes the approach
and outcome of the specification of the environment. A
chapter on presenting the implementation of the
environment follows. Conclusions summarise this paper.
2 Requirements Analysis and Functional
Design
The basic requirements for CYCLADES are to develop
an environment supporting a broad range of functionality
for both individual scholars, who want to search and
browse in open archives as well as for communities of
scholars who want to share and exchange search results. A
multi-disciplinary and distributed team with backgrounds
in digital libraries, databases, information retrieval, Web-
based systems, as well as computer-supported cooperative
work and virtual communities analysed the requirements
for such an environment and designed the basic
functionality. After a first draft for the basic functionality
of the system was finished, the requirements and the
envisioned functionality were presented to prospective
users, and their feedback was captured via a Web-based
questionnaire A detailed report on the questionnaire and its
evaluation can be found in [10].
As a result, the CYCLADES environment integrates a
set of functionalities that support the user when accessing
very large virtual e-print archives with: functionality for
efficient and effective retrieval of relevant information
from many large, distributed and multi-disciplinary digital
archives; feedback on the degree of relevance of the

Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP’04)
1066-6192/04 $20.00 © 2004 IEEE
 retrieved information; regular information about new
publications in the archive environment, which are
relevant to the users’ interests; automatic retrieval of
users’ long-term information needs (user profiling); as
well as rapid dissemination of the search results world-
wide.
A special set of features provides communities of
scholars with functionality for: the dissemination of
relevant information to community members in the form
of recommendations, which are based on collective
profiles and behaviour; very easy on-line annotations on
research results published by members of the community;
carrying out community services such as peer review,
which requires the annotation of on-line manuscripts by
reviewers, and the sharing of these annotations among
editors, authors, and others; as well as enabling
community members to learn from, contribute to, and
collectively build upon the community’s knowledge.
In order to use the CYCLADES environment and its
functionality users have to register with the system. As
the CYCLADES user interface is Web-based, users
simply enter a valid email address in the CYCLADES
registration Web page. A registration email is sent to this
address containing registration information. After the user
has carried out these steps, the user is registered to
CYCLADES and has a login name, password, and
(empty) home folder.
Users can then log in in order to access their home
folder or add some additional user information such as full
name, affiliation, postal address, phone and fax numbers,
and so forth. Furthermore, users can start working with
folders and folder contents. They can create private folders,
community folders, as well as project folders and add
subfolders and documents to them. Private folders and
community folders can contain metadata records and
queries; project folders additionally can contain any type of
document (e.g., PDF-files, slides, text files). The contents
of private folders can be seen, accessed, and changed only
by its owner. The contents of community and project
folders can be seen, accessed, and changed by the
community and project members respectively. Users can
add documents in various ways: they can store records they
found in a search and browse activity, they can upload
documents from the local hard disks, they can add links,
and so forth.
In order to become member of an existing community
users have two options: either they browse a list of names
and descriptions of open communities and subscribe to
them according to their interests or they get invited by
community managers of closed communities. After a user
has become a member, the community folder is visible
and accessible from the user’s home folder. If users leave a
community, the community folder is removed from their
home folder, but is still available for the other community
members. Only when the last community member leaves
the community, the community folder is actually deleted.
For each user the CYCLADES environment generates
recommendations about other users, communities, records,
and collections, which are stored into special
Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP’04)
1066-6192/04 $20.00 © 2004 IEEE
recommendation folders. Users can contact recommended
users, subscribe to recommended communities that are
open or contact the manager of closed communities, store
recommended records, and add recommended collections to
their personal set of collections.
All documents can be rated on a simple scale. The
median of the ratings is then attached to the document and
visible for any user who has access to the respective
document. Additionally, annotations containing free text
can be added to documents. Any user who has access to
the respective document can also see its annotations.
The CYCLADES environment provides two features
for informing users about activities in the CYCLADES
environment: event icons and activity reports. Event icons
are attached to the individual documents and show recent
actions that were performed on the documents (e.g.,
creation, change, read). Activity reports are sent out daily
via email; they contain information about changes to
documents since the last report was sent out.
More detailed information on the functionality as well
as the background in the form of an introduction of grey
literature and e-prints, information exchange, and virtual
communities can be found in [9]. We subsequently present
the specification of this open and distributed CYCLADES
environment.
3 Specification
The specification of the CYCLADES environment was
done with a formal, yet light-weight approach based on
the unified modelling language (UML) [3, 7]. We used
modelling techniques such as use cases, interaction
diagrams, and class specifications, but simplified the
syntax considerably. The simplification was possible and
chosen for two reasons. First, during the beginning of the
project several face-to-face meetings were held, in which
the environment was specified and in which the partners of
the project got a thorough idea of their own services as
well as the services provided by the other project partners.
Secondly, very early in the project the decision was taken
to decompose the overall environment into independent
services, which can treat each other as black boxes and
communicate with each other via XML-RPC [14].
Subsequently we will report on the use cases, interaction
diagrams, and class specifications.
3.1 Use Cases
According to Fowler and Scott a use case can be defined
as: ‘a set of scenarios tied together by a common user
goal’, while a scenario is: ‘a sequence of steps describing
an interaction between a user and a system’ [7, p. 39f].
For the specification of the functionality of the
CYCLADES environment verbal descriptions of use cases
were produced. These verbal descriptions could be produced
easily and rapidly, which was important because the
CYCLADES environment offers a broad range of
functionality and therefore use cases and because the
project schedule did not allow much time for this step.
 For some complex use cases the verbal descriptions were
combined with activity diagrams.
In a first step the overall functionality of the
CYCLADES environment was decomposed into groups of
use cases; the groups identified were: use cases for the
single user, use cases for a community, use cases for a
project, as well as special use cases related to management
activities such as use cases for collection management,
and use cases for archive management. Examples of use
cases can be found in [5].
3.2 Interaction Diagrams
Interaction diagrams can be defined as: ‘models that
describe how groups of objects collaborate in some
behaviour’; typically they: ‘capture the behaviour of a
single use case’ and ‘show a number of example objects
and the messages that are passed between these objects
within the use case’ [7, p.
67]. Two types of interaction
diagrams can be distinguished—sequence diagrams and
collaboration diagrams. In sequence diagrams: ‘an object is
shown as a box at the top of a dashed vertical line’, and in
collaboration diagrams: ‘the example objects are shown as
icons’ [7, p.
67ff]
For the CYCLADES environment interaction diagrams
in the form of sequence diagrams were primarily used to
clarify and model the communication between the different
services, which were developed and are being operated at
different sites across Europe. An example is shown in
Figure 1. The interaction diagram shows the interaction
between two users: the inviter on the left side invites the
invitee on the right side to her folder. If the invitee is
already registered and known to the system, he is simply
added to the folder’s members list, otherwise the invitee
has to register to the system first. Other interaction
diagrams can be found in [5].
3.3 Class Specifications
The classes of the CYCLADES environment were
specified in a very abstract way. Since the different
partners were using heterogeneous programming
languages and development environments, the class
specifications were written for the purpose of
communicating the abstract signature of the individual
classes among partners. A detailed description in the
heterogeneous implementation environments and
languages would go beyond the scope of this paper.

Collaborative
Mediator
Work
Service
Service
Inviter Invitee

request invitation form for adding members to a folder

return invitation form

submit filled-in invitation form with e-mail addresses

(and user names)
create preliminaryusers
indicate new members for e-mail addresses

send registration e-mails

receive
registr.
request user registr. form e-mail
with token
check registr. token
and e-mail address
return user registr. form

submit filled-in user

registr. form

create user and

addUser(userId, name, user’s home folder
passwd)
show folder to which user
has been invited

Figure 1. Interaction diagram for the invitation of another user to a community.

Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP’04)
1066-6192/04 $20.00 © 2004 IEEE

4 Implementation
The CYCLADES environment consists of several
autonomous yet interoperable software components called
services, which run on different machines in different
locations. The individual services have the following
purposes:
• The Mediator Service (MS) acts as a registry for the
other services—any service of the CYCLADES
environment has to register at the MS to be able to
communicate with any other service—and provides
security—that is, it checks if a user is entitled to use
the system, and ensures that the other services are only
called after proper authentication.
• The Collaborative Work Service (CWS) provides a
folder environment for managing records, queries,
collections, documents, and annotations, supports
collaboration between users through folder sharing in
communities and projects. One component or sub-
service of this service is the Rating Management
Service (RMS), which manages ratings.
• The Collection Service (CS) manages collections, thus
allowing a partitioning of the information space
according to the users’ interests and making the
individual archives transparent to the user.
• The Filtering and Recommendation Service (FRS)
provides personalised filtering of queries and query
results, recommendations, and personalised folder
management.
• The Access Service (AS) interacts with the underlying
metadata archives, currently with archives adhering to
Figure 2. Deployment view of the CYCLADES environment.
Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP’04)
1066-6192/04 $20.00 © 2004 IEEE
the Open Archives specification.
• The Search and Browse Service supports the activity of
searching records from the various collections,
formulating and reusing queries, and browsing
schemas, attribute values, and metadata records.
Figure 2 shows the deployment view of the
CYCLADES environment: The cubicles represent
nodes—that is machines on which the individual
components are running. The left-most cubicle represents
the user’s machine with the Web browser and various
windows for the user interfaces of the respective services.
The four cubicles in the middle represent machines
hosting the distributed CYCLADES services. The three
cubicles on the right represent instances of open archive
servers. The dotted lines visualise the calls between the
different components (e.g., the graphical user interface of
the Collaborative Work Service calls the Collaborative
Work Service component, which then in turn calls the
Filtering and Recommendation Service, Collection
Service, and Rating Management Service components).
As a detailed description of all components would go
beyond the scope of this paper, we here only focus on the
implementation of the Collaborative Work Service as an
example component.
4.1 Collaborative Work Service—Internal
Architecture
In this section we will describe the internal architecture
of the Collaborative Work Service component, which was
designed and developed at Fraunhofer FIT. Several aspects
such as the interface to the other services have been
 realised similarly in other components.
The CWS provides its functionality via the graphical
user interface and via an API to the other CYCLADES
services. All user interaction via the graphical user
interface is mediated by the Mediator Service—that is,
both the interaction of the users with the graphical user
interface of the CWS and the interaction of the users with
the graphical user interfaces of other services. Other
services can directly access the CWS functionality via the
CWS API. In the case of graphical user interface the
communication takes place via HTTP and the format is
HTML; in the case of the API the communication takes
place via HTTP and the format is XML and XML-RPC
(cf. below).
The CWS consists of a standard Apache Web server
that transmits incoming HTTP requests via CGI to the
CWS components that serve on the one hand the user
operations and on the other hand the API calls (cf. Figure
3).
browser interface
HTTP responses HTTP responses
HTTP GET/POST
(HTML) (XML-RPC)
requests
Standard
StandardWeb
WebServer
Server
bscw rpc2
BSCW
BSCWKernel
Kernel CWS
CWSAPI
API
CWS
CWS‘Cyclades’
‘Cyclades’package
package
Figure 3. CWS components.
The CWS is based on the Basic Support for
Cooperative Work system (BSCW) [2]. BSCW supports
Web-based shared workspaces (called folders in the
CYCLADES terminology) and provides basic
collaboration support that is adapted and extended for
CYCLADES. The private, project, and community folders
are implemented on top of BSCW shared workspaces. The
BSCW kernel provides a modular extension of the World-
Wide Web’s client-server architecture without requiring
modification to Web clients, servers or protocols. The
core is a standard Web server extended with the BSCW
kernel software, providing the basic shared workspace
functionality. BSCW is extended for implementing the
CWS functionality via BSCW’s package mechanism. A
separate component handles the incoming API calls
(translation and dispatch).
The BSCW package mechanism allows programmers
to enhance the BSCW kernel by additional software
packages, which may be added or removed at run-time.
The implementation of external packages is organised just
like the kernel. It may consist of class definition modules
(cl_*.py), utility modules (bs_*.py), operation handlers
Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP’04)
1066-6192/04 $20.00 © 2004 IEEE
( op_*.py ), interface template files (*.html , *.txt,
*.gif) and configuration modules (config*.py). In order
to facilitate the independent development of kernel code
and package code, packages are stored in a separate
directory, (e.g., packages/Cyclades ). Each package
directory itself is structured like the kernel directory—that
is, it contains a subdirectory src for the code and a
messages directory for user interface templates. The icons
of a package must be stored in the same directory as the
kernel’s icons.
At the highest level of abstraction the CWS can be fur-
ther decomposed into three layers, which deal with user
request and API call handling, method and operation han-
dling, and persistent object storage (cf. Figure 4). In the
user request handling layer the details of the request are
formatted as an internal representation called a Request,
which is then dispatched to a particular operation han-
dler. In the API call handling layer the call is translated
into internal format, its parameters are checked for correct-
ness, and the call is
dispatched to particu-
API interface lar method handler.
Both operation and
method handlers im-
HTTP POST requests
plement the function-
(XML-RPC) ality requested, such
as getting the con-
tents of a community
CGI interfaces folder, or saving re-
sults from a search
and browse session.
The operation and
method handlers inter-
act with the persis-
tent store to process
the request or call,
creating, deleting and modifying objects as necessary,
before generating a response. The response is returned to
the request or call handling layer for translation into a
concrete format suitable for the access method employed.
So, for requests via the API the response format is XML-
RPC, and for requests via the graphical user interface the
format is HTML, which can be displayed in the Web
browser. Each of these three layers provides a well-defined
interface, and it is possible to extend the CWS and
integrate specialised application services at each level. As
well as introducing new request handling components for
different methods of access, new operation handlers can be
added to provide new functionality or as wrappers around
application services, and the persistent store can be
accessed to store new kinds of objects without modifying
the storage routines themselves.
As has been said, a core requirement for the
CYCLADES environment was an open and flexible
architecture allowing the designers and implementers to
run services in a distributed and heterogeneous
environment as well as to easily add and remove
components upon request of the users. One central aspect
 API method call and Method handlers
response handling

Get
call Children
Method call Procedure

bscw
rpc2
HTTP

rpc2
Requests and response checking and Save
translation response dispatching results
Standard Persistent
Web Object
Server request Storage
HTTP
List
bscw
Responses Request and Request and
response response documents
translation response dispatching Add
member

User request and User operation

response handling handlers

Figure 4. CWS server kernel.

of the overall architecture is, therefore, the communication
among components, which will be described subsequently
in detail.
4.2 Communication Protocol
The services of the CYCLADES environment
communicate via HTTP. The internal communication
among the services works with HTTP and XML-RPC.
XML-RPC is a simple protocol for implementing
cross-platform, distributed applications [14]. As its name
suggests, communication between the distributed
applications is done via remote procedure calls. The XML-
RPC protocol is based on Internet standards: method calls
and responses are transmitted using HTTP, and the bodies
of the calls and responses are encoded in XML. Compared
to SOAP [4] XML-RPC is very simple and light-
weight—for instance, the headers that have to be included
in each individual message call are much smaller and
simpler—and consequently very well suited for the
purpose of the CYCLADES environment.
There are implementations for XML-RPC available for
numerous platforms (Unix, Windows and Mac OS X) and
programming languages (C, C++, Java, Perl, PHP,
Python, Tcl and others). Many of the implementations are
open source and free to use. The following example shows
a simple XML-RPC method call (without the HTTP
header).
<methodCall>
<methodName>sample.sumAndDiff</methodName>
<params>
<param><value><int>5</int>
</value></param>
<param><value><int>3</int>
</value></param>
</params>
</methodCall>
Method calls consist of the method name and zero or
more parameters. A method response contains a single
parameter or a fault consisting of a fault code and a fault
string which are encoded in XML.
XML-RPC supports the following six scalar data
types: int: a 32 bit signed integer; boolean: either 1 (true)
or 0 (false); string: a string containing any character
except ‘<’ and ‘&’ (they are encoded as ‘&lt’ and ‘&amp’);
double: a double-precision signed floating point number;
dateTime.iso8601: date and time encoded in the compact
version of the ISO 8601 standard; and base64: base64
encoded binary data; as well as two compound data types
struct: a collection of members consisting of a name and a
value (names are strings and values may be of any XML-
RPC data type) and array: a one-dimensional array of
values encoded as a single data element with any number
of values; values may be of any type including structs and
arrays; mixing of types in one array is possible. A
complete specification of the protocol including the HTTP
header requirements can be found in [14].
In the CYCLADES environment the XML-RPC
protocol is used for the communication between the
services—the input and output parameters of the
individual methods had to correspond to the encoding
described below.
From the XML-RPC definition it is clear that the
input parameter list of a method is a <params> construct
consisting of zero or more single <param>s each having a
<value> of a certain data type, so that the following two
examples are are both legal method calls:
<methodCall>
<methodName>listCollections</methodName>
<params></params>
</methodCall>

Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP’04)
1066-6192/04 $20.00 © 2004 IEEE
 <methodCall>
<methodName>saveRating</methodName>
<params>
<param><value><string>CW_1001</string>
</value></param>
<param><value><double>2.55</double>
</value></param>
</params>
</methodCall>
Consequently, no specific construct is needed for
encoding the tuple of input parameters, even if it is
empty. This is not true for the output parameters. The
definition states that the output of a method in the non-
fault case is a <params> construct consisting of exactly
one <param> having a <value> of a certain data type.
Therefore, an empty output value (void) and a tuple of
output parameters need a specific encoding.
A review of the signatures of the CYCLADES service
methods shows that there are the following kinds of
parameters: booleans; integers (e.g., fault codes); floating
point numbers (e.g., term weights); strings (e.g., object
names and descriptions); timestamps; void representing
the empty return value; object identifiers (e.g., identifiers
of users, folders, records); objects of a certain class (e.g., a
record or a query); tuples (e.g., a pair of object identifier
and string); lists of object identifiers, objects or tuples.
There is currently no use of binary data in
CYCLADES method signatures. We treat the encoding of
the different kinds of parameters in the order they appear in
the above list.
Booleans, integers and floating-point numbers are
encoded in the corresponding XML-RPC scalar types
<boolean> , <int> and <double> . Boolean t r u e is
encoded as <boolean>1</boolean>, and boolean false is
encoded as <boolean>0</boolean>.
Strings are meant to be Unicode strings. If no other
encoding is given in the XML header of the XML-RPC
message, the standard XML encoding UTF-8 is used. For
8-bit strings entered into the system at the browser
interface, it will be impossible to determine the correct
interpretation since the interpretation is a browser setting
not accessible to a service with a user interface. For
instance, for the CWS a Latin-1 interpretation is used as
default.
Timestamps are encoded in the <dateTime.iso8601>
data type, which uses the compact version of the ISO
8601 standard, (e.g., <dateTime.iso8601>20011209T22
:10:01</dateTime.iso8601>. All timestamps are in
Universal Time Coordinated (UTC).
Object identifiers in CYCLADES are printable ASCII
strings (Unicode ordinal numbers 32–127) with a length
greater than three. The first two characters denote the
service, which generated the identifier, the third character
is a separator, an underscore, and the rest of the object
identifier is the service internal object identifier. Service
denotations are: ME: Mediator Service, CO: Collection
Service, FR: Filtering and Recommendation Service, AC:
Access Service, SB: Search and Browse Service, CW:
Collaborative Work Service, and RM: Rating
Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP’04)
1066-6192/04 $20.00 © 2004 IEEE
Management Service. Since object identifiers are strings,
they are encoded like other strings (e.g., <string>
CW_1001</string>).
Objects of a certain CYCLADES class such as records
and queries are encoded as <struct> s where the
<member>s correspond to the class attributes. A record
with attributes id, name and metadata is consequently
encoded as follows:
<struct>
<member>
<name>id</name>
<value>
<string>AC_http://arXiv.org/abs/
alg-geom/9712032</string>
</value>
</member>
<member>
<name>name</name>
<value>
<string>A morphism of intersection
homology</string>
</value>
</member>
<member>
<name>metadata</name>
<value>
<string>?xml version="1.0"?>record>...
/record></string>
</value>
</member>
</struct>
Since nesting of <struct>s and <array>s is possible,
attribute values may also be lists, tuples or other objects.
Class attributes may have no value assigned in a particular
instance (e.g., the classifier label attribute of a record may
be undefined as may be the query string of a query).
Tuples and lists are encoded as <array>s. Since
<array>s may contain values of different types, and since
nesting of a <array> s and <struct>s is possible, no
problems arise with tuples containing objects, lists of
objects or other tuples.
Fault codes are reported in XML-RPC as a distinct type
of method response: a struct having as members a fault
code and a fault string. In CYCLADES, there are general
fault codes and strings to be used by all services in a
unified way. Additionally, there are specific fault codes and
strings that every service may define and use. The exact
values of fault codes and fault strings are defined by the
respective service. CYCLADES fault codes start at 10000,
the assignment to the services is as follows:
• 10,000-10,999: CYCLADES general fault codes
• 11,000-11,999: Access Service fault codes
• 12,000-12,999: Search and Browse Service fault codes
• 13,000-13,999: Filtering and Recommendation Service
fault codes
• 14,000-14,999: Collection Service fault codes
• 15,000-15,999: Collaborative Work Service fault codes
• 16,000-16,999: Rating Management Service fault
codes
 • 17,000-17,999: Mediator Service fault codes
The mapping of XML-RPC data types to the major
programming languages used in CYCLADES—Java and
Python—is done as follows. For Java, the Helma XML-
RPC implementation [11] or its adaptation as Apache
XML-RPC [1] are used. The XML-RPC data types map
to the following Java data types:
• <int> maps to java.lang.Integer
• <boolean> maps to java.lang.Boolean
• <string> maps to java.lang.String
• <double> maps to java.lang.Double
• <dateTime.iso8601> maps to java.util.Date
• <struct> maps to java.util.Hashtable
• <array> maps to java.util.Vector
• <base64> maps to byte[ ]
For Python the xmlrpclib from Secret Labs, which has
three extra classes to cater for some XML-RPC data types
not readily available in Python [13]. The mapping of data
types is as follows:
• <int> maps to int
• <boolean> maps to xmlrpclib.Boolean
• <string> maps to string or unicode
• <double> maps to float
• <dateTime.iso8601> maps to xmlrpclib.DateTime
• <struct> maps to dictionary
• <array> maps to list or tuple
• <base64> maps to xmlrpclib.Binary
This communication is used in many cases. For
instance, the Collaborative Work Service notifies the
Filtering and Recommendation Service when community
folders are created or deleted, or when recommendation
preferences are changed via the FRS API methods
addfolder(), deleteFolder(), setRecommendation-
Preferences().
5 Conclusions
In this paper we have reported on the design,
specification, and implementation of an open collaborative
virtual archive environment. We have presented the
functional design of the system, described the
specification, which was done in a lightweight UML-like
approach, and gave details on the implementation of the
overall environment with a special focus on the
component providing the support for the virtual
communities. The main goal of this paper was to present
an approach for the development of an open, distributed,
and heterogeneous environment based on open standards.
Acknowledgments
The research presented here was carried out in the IST-
2000-25456 project CYCLADES, partly funded by the
EC. I would like to thank my colleagues from the
CYCLADES team at Fraunhofer FIT as well as at
ERCIM, CNR, FORTH, and UNIDO. Thanks to the
Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network-Based Processing (EUROMICRO-PDP’04)
1066-6192/04 $20.00 © 2004 IEEE
anonymous reviewers for comments on the initially
submitted version of this paper.
References
1. Apache
Software
Foundation. XML-RPC - Apache
XML-RPC. http://ws.apache.org/xmlrpc/, 2003.
(Accessed 23/10/2003).
2. Bentley, R., Appelt, W., Busbach, U., Hinrichs, E.,
Kerr, D., Sikkel, K., Trevor, J. and Woetzel, G. Basic
Support for Cooperative Work on the World-Wide Web.
International Journal of Human Computer Studies:
Special Issue on Novel Applications of the WWW
(Spring 1997).
3. Berners-Lee, T., Cailliau, R., Loutonen, A., Nielsen,
H.F. and Secret, A. UML 2001: A Standardisation
Odyssey. Communications of the ACM 29, 10 (Oct.
1999). pp. 29-37.
4. Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
Mendelsohn, N., Nielsen, H.F., Thatte, S. and Winer, D.
Simple Object Access Protocol (SOAP). W3C,
http://www.w3.org/TR/SOAP/, 2003. (Accessed
23/10/2003).
5. Candela, L., Castelli, D., Fischer, G., Fuhr, N., Gross,
T., Kreifelts, T., Pagano, P., Papadopoulos, N.,
Plexousakis, D., Renda, M.E., Sebastiani, F. and
Straccia, U. Detailed System Specification Report.
Deliverable D 3.0.1 of the IST-2000-25456 project
CYCLADES, partly funded by the EC. CNR—Consiglio
Nazionale delle Ricerche, 56124 Pisa, Italy, Feb. 2002.
6. FIT. BSCW Home Page. Fraunhofer FIT and OrbiTeam
Software GmbH, http://bscw.fit.fraunhofer.de, 2003.
(Accessed 23/10/2003).
7. Fowler, M. and Scott, K. UML Distilled: A Brief Guide t o
the Standard Object Modelling Language. Addison-
Wesley, Reading, MA, 2000.
8. Groetschel, M. Math-Net. http://www.math-net.org/,
2002. (Accessed 19/6/2002).
9. Gross, T. CYCLADES: A Distributed System for Virtual
Community Support Based on Open Archives. In
Proceedings of the Eleventh Euromicro Conference o n
Parallel, Distributed, and Network-Based Processing -
PDP 2003 (Feb. 5-7, Genova, Italy). IEEE Computer
Society Press, Los Alamitos, CA, 2003. pp. 484-491.
10. Gross, T. and Kreifelts, T. Sharing and Exchanging
Knowledge in Virtual Communities: The CYCLADES
System. In Proceedings of the Tenth International
Information Management Talks - IDIMT 2002 (Sept. 11-
13, Zadov, Czech Republic). Universitaetsverlag Rudolf
Trauner, Linz, 2002. pp. 71-81.
11. Helma. XML-RPC for Java. http://xmlrpc.helma.org/,
2002. (Accessed 23/10/2003).
12. OAi. Open Archives Initiative. http://www.
openarchives.org/, 2003. (Accessed 25/1/2003).
13. Secret
Labs
AB. XML-RPC for Python. http://www.
pythonware.com/products/xmlrpc, 2003. (Accessed
23/10/2003).
14. UserLand
Software
Inc. XML-RPC Home Page. http://
www.xmlrpc.com/, 2003. (Accessed 23/5/2003).
15. Webmaster. arXiv.org. http://arxiv.org, 2002.
(Accessed 19/6/2002).
16. Wiki. Wiki: Welcome Visitors. http://wiki.org/, 2003.
(Accessed 23/10/2003).