Printer Friendly

Applying peer-to-peer technology to the building of distributed educational systems.

Existing educational systems built for cooperative and collaborative activities are most often based on the client/server paradigm of distributed computing. This article shows that a new model for distributed computing, Peer-to-Peer (P2P), provides new opportunities for building distributed educational applications. It begins by reviewing general aspects of distributed educational applications and the design requirements for building such systems. Then, the applicability of several existing collaborative P2P applications to educational settings is examined. The final portion of the article is devoted to a description of the features offered by Acadia P2P-based Educational eXchange (APEX), an application designed by the authors. APEX is based on the Project JXTA P2P Framework.


With the increased availability of powerful personal computers and fast networks there is a growing trend towards distributed educational applications that emphasize interaction and team work. Groupware or computer-supported cooperative work (CSCW) refers to computer-based systems that provide an interface to a shared environment in order to support groups of people working towards a common goal (CSCW, 2003). One of the most popular models of distributed educational applications is the electronic classroom, in which every student and the teacher have access to a personal computer (Shneiderman, 1995). Another reason for the interest in this area of research is the growing number of universities which have built fully computerized campuses. For example, Acadia University (MacDougall, Muldner, & Tomek, 1998; Tomek & Muldner, 1999) provides each faculty member and full-time student with a laptop computer. In addition, each classroom and dormitory on the Acadia campus contains access points to the campus network. This provides many opportunities for various types of computer-supported interaction. There are two kinds of electronic classrooms using this technology: synchronous, face-to-face systems in which the teacher and students share the same room, and asynchronous, virtual classrooms in which students can be geographically dispersed as is the case with distance education.

Most known implementations of distributed educational applications use standard Java-based technologies (Muldner, 1998). The favored model for building such applications has been client/server, where numerous "thin" client systems containing little application logic interact with a much smaller number of "thick" server systems, which contain the bulk of the application logic (Leighton, 2003). The client/server model has several inherent weaknesses. First, a centralized server creates a bottleneck on the system's performance, scalability, and reliability. The reason for these problems is that the availability of a client/server-based application is entirely dependent on whether these servers are currently operational. Second, client/server applications tend to be monolithic in their design, which makes it difficult to extend an existing application without affecting the original functionality. As an example of a system that encounters these problems, consider an example-driven system, designed to allow students to share examples of programs in C (Muldner & Phang, 1999; Muldner & Shiv, 2000, 2001). In the client/server implementation, a student who wants to share examples with other students has to connect to the server, and leave a copy of these examples on the server, where other students can fetch them. This server creates a bottleneck in the sense mentioned.

Recent security attacks have increased the popularity of firewalls (Zwicky, Cooper, & Chapman, 2000), which provide a means of securing a network from outside attack by limiting the ability of computer systems located outside of the network to connect to computer systems inside the network. At the same time, since IP addresses are a scarce resource, most Internet Service Providers (ISPs) use dynamic IP addresses and network address translation (NAT) schemes (Network Address Translation FAQ, 2003), which provide a mapping between the internal network address of a computer system inside a subnetwork and the external network address that is reported to any systems located outside of the subnetwork. Since most implementations of distributed educational applications are based on the Domain Name System (DNS) (Albitz & Liu, 2001), it is difficult or even impossible to traverse firewalls and reach users who are using an ISP with a NAT scheme.

A new emerging model for distributed computing is peer-to-peer, often referred to as P2P (Leuf, 2002). In place of the traditional client and server roles featured in most existing distributed systems, P2P features a single peer role that is capable of functioning as both client and server at various points during the application life cycle. P2P applications are more fault-tolerant than their client/server counterparts, as a malfunction in any individual peer does not necessarily result in a terminal failure of the entire application. In addition, services on a P2P network are often replicated to several host peers. This leads to a higher rate of availability for these services, and greater scalability since the number of peers hosting a service increases with the number of active peers. Finally, P2P applications can overcome problems with firewalls and NAT schema. Continuing the example of an example-driven system, in a P2P implementation, every student is a peer who can directly connect to other peers.

This article describes various applications of P2P technology to the implementation of distributed educational applications. This discussion includes the specification of all essential goals that distributed educational applications should aim to achieve, such as customizability, extensibility, and reliability. Also included is a list of requirements that all educational distributed systems should strive to satisfy. Next, a review is conducted of three selected applications (Groove Workspace, Onobee, and eZ) to evaluate the potential of each product as an effective educational tool. From the many existing P2P frameworks, Project Juxtapose (JXTA) from Sun Microsystems (JXTA, 2003) has been selected as the foundation on which to design and partially implement Acadia P2P-based Educational eXchange (APEX), an extendable educational application that provides a means for instructors to easily integrate collaborative functionalities into a virtual classroom space. APEX is designed to achieve all goals listed in our article and forms a basis for building a variety of powerful distributed educational applications suited for particular needs. For example, one version of APEX can be customized to be used in synchronous, face-to-face virtual classrooms in which the teacher and students share the same room, and another version can accommodate asynchronous, virtual classrooms in which students can be geographically dispersed.

This article is organized as follows. One section describes general distributed educational applications, their goals, and the requirements for systems that implement such applications. Another section gives a short introduction to P2P; and another provides a description of APEX, which uses a P2P architecture to implement various distributed educational functionalities. The final section concludes this article and describes future work.


This section describes general types of educational applications and the goals and requirements that such applications must satisfy. In the remainder of this article, the concept of an application service is used to refer to any functionality that is available for invocation by users of that application. For example, an application that supports file downloads is said to contain a file downloading service.

A distributed system is one in which data and functionality are distributed across multiple machines connected by a network. These systems are useful because by summing the collective storage and computational power of multiple computers, one obtains a potentially more powerful system that can do the job of multiple computers. Additionally, the duplication of resources means that the failure of one component does not necessarily imply the failure of the system as a whole. Thus, distributed systems provide parallelism and fault tolerance, making them potentially much more powerful than their individual components (Mullender, 1989).

A general, well known class of education applications is called group-ware or computer-supported cooperative work (CSCW). It refers to computer-based systems that provide an interface to a shared environment in order to support groups of people working towards a common goal. Grudin (1994) described the challenges faced by developers of these systems, and Norman (1996) provided a description of the extensive research on using computing technology to help teachers be more effective. A related area, collaborative virtual environments (CVE), is also getting a lot of interest (West & Hubbold, 1998). However, most CSCW systems do not support the creativity of a group; in particular they do not support procedures to achieve a goal or to create a common solution plan.

A specific, widely known education application is the electronic classroom (Muldner & Nicholl, 1996). To support sharing information in electronic classrooms, educational applications provide services such as instant messaging, which allow a group of users to exchange messages within a shared "room." Additionally, they may support whispering, a mode that sends a private message to a specific user, rather than the entire group of users.

Distributed educational applications often support multi-user shared editing sessions, where several users interact and negotiate with each other as they collaboratively edit a document. A file transfer service may be used both inside and outside of the scheduled class meeting time to distribute course-related documents such as course notes, assignments, and assignment solutions. The publisher (such as a professor who creates documents) makes these documents available, and subscribers (such as the students in a course) obtain these documents. The publishers need to be able to make new documents available, replace existing documents, or distribute updates to portions of documents. The subscribers need similar facilities to insert updates provided by the publisher, as well as their own modifications. These modifications may include students' own pages (or even chapters), as well as customizations such as "margin notes" or bookmarks.

Other services typically found in distributed educational applications include scheduling tools, such as a shared calendar to post the dates and locations of class meetings and tutorial sessions, and data-sharing services. A specific example of a data-sharing service is a distributed repository of programming examples, based on the observation that examples consisting of small programs have proven to be an effective method of learning a new programming language (Neal, 1989; Muldner & Phang, 1999; Muldner & Shiv, 2000, 2001). This service supports the so-called example-driven (or example-based) learning process. Consider as an example a specific class for teaching programming in the C programming language, taking place in an electronic classroom. Before the beginning of the class, the instructor makes available examples of C programs to all students in the classroom. Now, the students can browse through these examples and download them to their computers. Then, they can view these examples, export them to their favorite compiler, modify them by creating new versions, and make these versions available to all students, or to specific students. The entire process can result in collaborative development of a useful repository that can be used not only for learning, but also for every-day programming.

To promote flexibility, educational applications should implement document-level security. This allows the creator of a particular document to specify what subsets of users can read or modify this document (there may be various kinds of access permissions, for example, to view, copy, traverse, etc.). For more sensitive data, additional security features should be provided (such as digital signatures or data encryption); otherwise, users are subject to various security risks. For example, messages may be intercepted and read by a third-party, message contents may be modified during transit, and identity spoofing of a message sender may take place.

Goals and Requirements for Distributed Educational Systems

This section lists essential requirements that all distributed educational systems and their services must achieve. Our view of a distributed application is that it consists of entities; each entity may reside on a different node of the network. Different entities may provide different services. Each user employs one entity, which may be virtually connected to other entities.

* Platform Independence: users of heterogeneous systems must be able to access the application. There are several techniques that support portability: (a) using Corba (Corba, 2003); (b) using Web Services and the underlying XML technology (XML, 2003); and (c) using the Java technology. The last technique appears to be the most appropriate solution for educational applications. There must be ubiquitous access to other application instances, regardless of their platform, including all types of digital devices ranging from desktop computers to Personal Digital Assistants (PDAs).

* Security: an application must have an authentication system and must provide a permission system that supports assigning different permissions (access control rules) to different users and groups of users. The following security mechanisms should be supported: (a) authentication, which is a scheme that ensures that users are actually who they claim to be (using, for example, digital signatures); (b) encryption of all data that is transferred between users of the application through the use of private or public key systems (Lloyd & Adams, 1999); and (c) auditing of all application activities.

* Customizability: an application can be customized using menus or through a "drag-and-drop" technique; for example, the customization may involve setting up an environment such as a virtual classroom.

* Extensibility: an application must not have a monolithic design; instead its design should be flexible, allowing new tools to be added without affecting the operation of existing tools. Preferably, the implementation uses an object-oriented programming language and design patterns (Gamma, Helm, Johnson, & Vlissides, 1995).

* Connectivity: users must have the ability to work on course documents while disconnected from the network; upon the next reconnection, the documents must be synchronized so that each user possesses identical local copies of course documents.

* Identification: an application must maintain a roster containing the identities of users who are currently available; to support reliability, the roster must be distributed and replicated to each user. The identity of a user must be independent of his/her current location.

* Categorization: there are two kinds of application services: those offered by a single user and those provided by a group of users (for example, one of the group services may control membership to that group). Nested user groups are supported

* Collaboration: at a minimum, the following tools should be provided by the application to support collaborative activities: threaded discussions, messaging, collaborative viewing, and collaborative editing of shared documents (optionally using a floor control mechanism to prevent contradictory events [Hilt & Geyer, 1997]).

* Discovery: users are able to discover and join course groups; each course group contains a set of services that have been specified by the instructor, and these services are dynamically discovered when a user joins a course group.

* Availability: application services must be hosted by multiple application entities so their accessibility is not dependent on the current availability of any particular application entity.

* Scalability: the application must be designed in such a way that the addition of new entities or services to the network does not significantly hinder application performance.

* Reliability: the availability of the application must not depend on the availability of any single application instance; the automatic replication and synchronization of shared classroom data between members makes it highly unlikely that any document can become truly lost.

* Accessibility: application entities must be able to communicate with one another, even in the presence of dynamic IP addresses, firewalls, or NAT schemes.


This section describes the defining features of P2P systems. P2P architectures feature a greater degree of decentralization of services than is found in the client/server model. Instead of employing a limited number of centralized servers to perform the bulk of processing and return the results to clients, the workload in a P2P system is more evenly distributed among the application's participating peer systems, each of which typically acts in both the client and server roles at different points in the application life cycle. A peer may initiate requests on services hosted by other peers, and is also capable of servicing incoming requests on locally-hosted services which have been initiated by other peers. Since services and resources are distributed across multiple computers, P2P systems tend to be more fault-tolerant than their client/server counterparts. In addition, the replication of application services to multiple systems makes P2P systems less susceptible to "denial of service" attacks from malicious users, in which a single machine on the network is bombarded with more incoming requests than it can service.

One of the key challenges any P2P system must address is the enablement of peers to discover and communicate with one another. The existing Internet infrastructure is primarily based on a centralized model that assumes consistency in terms of location and availability of server machines, while in a decentralized P2P environment a given application service is as likely to be hosted on a desktop computer with a dynamic IP address as on a mainframe server machine with a static IP address. Therefore, traditional resolution techniques such as the Domain Name System (DNS) are not adequate for the P2P environment in which a given machine may leave the network at any time. P2P systems must therefore provide a custom scheme for resolving a peer's identity to the current network location (including the network address and port number) at which it may be contacted.

The decentralized nature of P2P gives it a significant scalability advantage over the client/server model. In particular, a system based on P2P principles may actually see an increase in performance as higher numbers of users participate (Leuf, 2002). The reason is that as more users join the P2P system, shared content is replicated to more peers. This makes it increasingly likely that a peer searching for a particular piece of shared data will find another peer within close geographical proximity that is willing to share the data, and this leads to faster data acquisition speeds.

P2P also enjoys a reliability advantage. If one continues the scenario presented, the impact on the system of any single host leaving the network (possibly due to hardware or network failure, or simply because the end user has elected to temporarily disconnect from the network) becomes less pronounced over time.

In recent years, P2P architectures have been used in the implementation of a variety of different applications, including collaboration (Groove, 2003), instant messaging (ICQ, 2003), file-sharing (Napster, 2003; Kazaa, 2003), anonymous and persistent content publishing (Clarke, Miller, Hong, Sandberg, & Wiley, 2002), computational resource sharing (SETI, 2003), and efficient file distribution (BitTorrent, 2003). In addition, software frameworks for developing P2P applications have begun to emerge, including Sun Microsystems' Project JXTA (JXTA, 2003) and the Windows Peer-to-Peer Networking platform from Microsoft (Windows Peer-to-Peer Networking, 2003).

Examples of Educational P2P applications

This section provides a brief survey of several existing collaborative P2P applications that have applicability to educational environments. One of the most popular applications is Groove Virtual Office (formerly known as Groove Workspace), a P2P product offered by Groove Networks, Inc., which allows end users to form collaborative spaces ("workspaces") in which data may be shared and edited. Several educational institutions have adopted Groove Virtual Office as an aide for teaching and for maintaining communication links between instructors and students, including the Naval Postgraduate School, the University of North Carolina at Chapel Hill, and California State University at San Bernardino.

One of the most significant benefits Groove Virtual Office gives to educators is a logical mapping between the physical classroom and the workspace concept. For instance, an instructor can create a separate workspace for each course they are teaching. After setup of the workspace is completed, only the instructor and enrolled students will be able to access the contents of the workspace, thereby providing a basic level of access control. Identity verification and confidentiality of exchanged messages is also enabled through Groove's support for digital signatures and data encryption, respectively. Groove Virtual Office also has a high degree of customizability. Several ready-made "tools" that provide specific functionality (such as whiteboarding, calendaring, and file transfer) are available for inclusion in a workspace. The course instructor may add a new tool through a simple drag-and-drop operation; subsequently, the new tool will be automatically downloaded and installed by all other peers belonging to the workspace. In addition, a published tools API allows custom tools to be created and incorporated into a workspace.

Several of the existing tools made available by Groove Networks provide immediate benefit when applied to educational contexts. For example, the "Files" tool can be used to track revisions in student projects, the "Bulletin Board" tool can be used by the instructor to post important course announcements, and the "Calendar" tool can be used to provide a dynamic version of the course syllabus, for which any additions or modifications made over the course of the term will be immediately and automatically "pushed" out to all students.

Groove Virtual Office also has excellent support for dynamic connectivity. Instructors and students are able to modify data while offline and have changes incorporated into the workspace upon the next subsequent network connection. This feature is attractive for distance education situations in which all students may not have ready Internet access at hand.

Despite its many advantages, Groove Virtual Office does not provide platform independence, as only Windows environments are supported. This may constitute a significant impediment to the product's adoption within courses in technical and scientific disciplines, where alternative operating systems such as UNIX variants are often used.

There are other collaborative P2P applications, which offer a range of features that would likely prove useful for educators and students alike. Onobee (2003) from PPServer Networks is a Java-based collaboration suite providing common functionalities such as instant messaging and file-sharing, in addition to more advanced features such as support for audio and video conferencing using web cameras. Collaboration in Onobee is centered on the concept of "rooms" in which a "host" user invites other users ("friends") to join. By associating a course instructor with the "host" role, and each student enrolled in the course with the "friend" role, the traditional classroom setting could be easily modeled within Onobee. Each participant in a room may choose to designate files and folders from the local file system to be shared, meaning that other room occupants can browse and download these files onto their own file systems. Instructors could make use of this feature to make lecture notes and assignment descriptions accessible to students through Onobee.

One shortcoming of the Onobee architecture is its failure to address firewall and NAT traversal. This means that it may not be possible for students to connect while off campus. A second drawback to Onobee is the user interface, which consists of 12 "tabbed" panels that require the user to switch tabs each time they wish to perform a different activity (for example, there is a separate panel view for the document editor and the drawing board).

Another promising collaboration suite is the eZ platform from Sigma Design (eZ, 2003). eZ allows instant messaging and e-mail-style exchanges, file sharing, whiteboarding, and group viewing of documents. A "project" concept is used to organize the sharing of files; an eZ user will first create a new project and then choose which files will be shared and which users will be granted access. eZ's support for whiteboarding and collaborative browsing of documents could be employed by an instructor to explain an assignment solution to students, or to conduct an online tutorial session in which students could ask questions on course material and receive instant explanations from the instructor. Much of the logic used to enable file sharing and other collaborative functions appears to be centered on the eZ servers controlled by Sigma Design, which raises some concern over the security of data and forces a total reliance on the availability of the eZ servers. In addition, eZ is limited to Windows environments.


This section describes the design of APEX, a distributed educational application which is currently being developed by the authors of this article. It features a peer-to-peer architecture and is being implemented using the Project JXTA framework. This section begins with a brief enumeration of JXTA's key features and then proceeds to describe the architecture and features of APEX.

Introduction to JXTA

Project JXTA (or JXTA) defines a set of protocols that serve to establish an overlay network on top of existing network protocols such as TCP/IP and HTTP. This overlay network transparently connects systems in a reliable and persistent manner, even in the presence of intervening firewalls and NATs. The atomic entity in the JXTA network is the peer, which is simply a software program that uses the JXTA protocols to interact with other programs (peers). Peers have the ability to join peer groups, which are collections of peers united by a common goal or interest (such as a desire to exchange files, or to share CPU cycles to calculate a complex computation). Functionality in a JXTA application may be added through advertised services. A service may be implemented as a peer service, in which case the functionality is provided by a single peer, or as a peer group service, where the service is hosted by all members of a peer group. Intuitively, the latter type of service enjoys a higher rate of availability since it is hosted by multiple peers and remains accessible as long as even a single host peer remains on the network.

Firewall and network address translator (NAT) traversal is a significant feature of JXTA; this frees peers located behind restrictive firewalls and NATs (the so-called "edges" of the Internet) to act as service providers rather than be forced into a passive consumer role, as is the case in the client/server-centric structure of the World Wide Web. (Figure 1) provides an example in which computers residing within two separate physical subnetworks are connected together into a single, virtual network by the JXTA protocols.


In addition to the regular "edge" peer role, JXTA networks also contain two types of "super-peers," which are simply peers that hold additional responsibilities. Rendezvous peers cache information about which services and resources are offered by edge peers, allowing queries to be handled in an efficient, yet decentralized, manner. In cases where direct physical connectivity between two peers is not possible (due to an intervening firewall or NAT), relay peers act as intermediaries in order to establish a communication path between the edge peers. In addition, they may store messages intended for unreachable edge peers.

To hide the complexities involved in establishing a communication path between peers, the developer of a JXTA application makes use of a pipe abstraction. Pipes serve to connect a sender and one or more receivers in a manner that is independent of the physical network locations of any of the pipe's endpoints. (Figure 2) provides an example of two edge peers, A and D. A is located behind a firewall that only permits outbound HTTP traffic on port 80, and wants to send a message to D, who is located behind a NAT. A chooses to nominate B to act as its relay, in hopes of finding a workable route to D. A communicates with B using HTTP messages, allowing the firewall to be successfully traversed. On the other side, D has chosen C to act as its relay; periodically, D polls C to see if any messages intended for D have arrived. Since D initiates each exchange with C, each response received from C will be mapped by the NAT to D's correct internal address. Since B has no direct relationship with D, a query is sent by B to other known relay peers to see if they hold routing information for D. C responds with the route information, and a transmission route of A-B-C-D is established. The message will be received by D once the next polling of C takes place. The JXTA programmer does not need to know the details of how a route connecting A and D was set up, since he/she only interacts with the pipe binding A to D that has been made available to him/her.

More information on the JXTA protocols and architecture is provided by JXTA (2003).

Introduction to APEX

APEX is more than an educational application with a single goal in mind; it is an architecture to which various components can be added to provide the required functionality. For example, an instant messaging component provides services needed to send and receive messages. Other components may be easily added as required, such as components that support cooperation and collaboration. Since APEX is based on JXTA, it does not suffer from problems other educational systems built using a client-server model experience. Indeed, APEX satisfies all goals previously listed.

Using JXTA to Implement APEX

Several factors resulted in the choice of JXTA as the framework upon which to implement APEX. First, the JXTA protocols are mature: since being released to the open source community in 2001, many individuals have contributed suggestions and code improvements for making the protocols more efficient and robust. Second, the virtual network overlay created by the JXTA protocols is well-suited to the university environment, where frequent firewall traversal is essential to allow students and faculty to collaborate while certain parties are off-campus. Third, there is a logical and convenient mapping between the existing concept of a peer group in JXTA and the classroom. By modelling each course section as a separate JXTA peer group, it is possible to leverage the existing JXTA infrastructure to easily implement separate and secure collaborative environments for each course. A fourth consideration has been JXTA's ability to quickly adapt to changes in network topology: in any collaborative application, it is inevitable that users will frequently join and leave the environment.


The final advantage relates to the incorporation of legacy data and applications. JXTA has been designed from the very beginning to be agnostic in the usage of network transport protocols and service invocation/discovery mechanisms. For example, it would be possible to integrate existing legacy data and applications into a JXTA-based application using the Web Services protocol stack, so that the legacy data (or program) is made accessible to users of the JXTA-based application through the Simple Object Access Protocol (SOAP, 2004), described using the Web Services Description Language (WSDL, 2004), and dynamically discoverable through the Universal Description, Discovery, and Integration standard (UDDI, 2004).

Authentication, User Roles and Access Control

The majority of educational institutions have a pre-existing Intranet infrastructure for sharing data, providing e-mail services, and distributing applications, wherein each student, faculty member, and administrative employee has an associated account login and password used to gain access to the network. Our application performs authentication of each peer as it joins the network through a lookup on the institution's registration records, to determine whether the user is a student or university employee. By using a "single sign-on" setup, each user can employ their existing login and password credentials to authenticate to the application; in addition, existing personal and contact information stored in the institution's student and faculty databases can be viewed from within the application.

In APEX, each course section is modelled as a separate JXTA peer group. Clearly, it is important to distinguish between different classes of application users. For example, only instructors should be allowed to modify shared course documents such as presentation materials and assignment specifications. With this in mind, four user roles are defined:

* Student peers can access shared content within peer groups representing courses that they have registered in. In addition, they may have limited ability to create and modify certain types of documents such as assignment submissions.

* Teaching assistants share the same permissions as students, and can additionally submit marks and make comments on assignment documents submitted by students.

* In addition to sharing the permissions of teaching assistants, instructors can also post course announcements, assignment descriptions, and course materials. They also are authorized to assign (and remove) teaching assistants to (and from) the course and can customize course peer groups by adding and removing components.

* Administrators can create and delete peer groups representing courses, and may define the instructors and students who are associated with each peer group. Holders of this role might include administrative staff of the educational institution (such as employees of the Registrar's Office).

It is important to note that a given user is assigned a separate role designation for each course peer group to which he/she belongs; for instance, a user may hold a teaching assistant's role within a particular course and a student's role in another course.

APEX Actors

There are two types of actor peers in APEX. The user peer is essentially equivalent to the JXTA concept of an "edge" peer, while the second type of peer is called the bootstrap peer and is maintained by the educational institution. The bootstrap peer combines the responsibilities of JXTA's relay and rendezvous peers (that is, to provide a means of establishing a route between peers separated by a firewall/NAT and to cache information on the resources and services being offered by user peers). Bootstrap peers have additional, application-specific responsibilities that relate to initializing user peers when they first reconnect to the network. Only bootstrap peers possess membership in the bootstrap peer group, which is used to enable efficient and secure communication between bootstrap peers. Awareness of this peer group and its membership service is specified a priori to bootstrap peers as part of their configuration, and discovery information for the group is never advertised to user peers. This serves to strictly limit membership in the group to those peers which have been designated by the educational institution to act as bootstrap peers.

Figure 3 provides an illustration of the peer bootstrapping sequence. In Step 1, Peer A has just started an APEX session by joining the APEX peer group. A's first activity is to seek out a bootstrap peer that will provide it with all update messages that were missed while A was disconnected from the APEX network. These updates contain notifications of all changes made to the shared resources of those course peer groups to which A belongs.

Step 2 is entered once a bootstrap peer, B[P.sub.A], has responded to A's query. At this stage, it is vital that A have a means of ensuring that B[P.sub.A] is in fact a bootstrap peer and not an impostor. Otherwise, A may end up subsequently sending its authentication credentials to a party that may use this information to nefarious purpose. For this reason, the response message sent by B[P.sub.A] to A contains a time-stamped token encrypted using a common RSA private key shared by all bootstrap peers. Every peer, including A, possesses the corresponding RSA public key for bootstrap peers and applies it to decrypt the token. Therefore, A will only be able to decrypt this token if B[P.sub.A] is truly a bootstrap peer. The bootstrap peer key pair is periodically regenerated and dispersed throughout the membership of the bootstrap peer group; user peers will be immediately sent the new public key (if currently online) or alternatively during the next peer bootstrap sequence. In the latter case, multiple bootstrap peers are polled to verify that the updated public key is genuine.


Once A has verified the identity of B[P.sub.A], it establishes a secure pipe connection between the two parties. Through this connection, A sends its authentication credentials (such as a username and password). B[P.sub.A] performs a lookup on the institution's records database to determine if A has supplied valid credentials. Within the authentication message, A also attaches a timestamp [t.sub.d], representing the time instant at which the last update message was received by A).

Once A has successfully authenticated, Step 3 is entered. Assume that the credentials supplied by A match those of record R in the records database. B[P.sub.A] determines which courses R is associated with in the administrator, instructor, teaching assistant, or student roles according to information stored in the institution's registration database. Let S = {[S.sub.1], [S.sub.2],..., [S.sub.n]} represent this set of courses, in which each [S.sub.i], 1 [less than or equal to] i [less than or equal to] n denotes an individual course. Then each si will have an associated set of update notifications, [U.sub.i] = {[u.sub.i1], [u.sub.i2],..., []}, m [greater than or equal to] 0 consisting of m update notifications that were issued within the time interval [[t.sub.d], [t.sub.c]]. Here, [t.sub.d] corresponds to the timestamp A sent to B[P.sub.A] in Step 2, and [t.sub.c] represents the current time. B[P.sub.A] then composes a message, M, where and sends it to A.

M = [n.summation over (i=1)][m.summation over (j=1)][u.sub.ij] + C (1)

As illustrated by (1), M concatenates all missed update notifications that A has an interest in knowing about, followed by a set of credentials C = {[c.sub.1], [c.sub.2],..., [c.sub.n]}, where each [c.sub.i] (for 1 [less than or equal to] i [less than or equal to] n) is a credential that indicates the assigned user role for A within course [s.sub.i] (either an administrator, instructor, teaching assistant, or student). Each credential is digitally signed using B[P.sub.A]'s private RSA key.

Once this bootstrapping process concludes, there is no further interaction between A and any bootstrap peer for the duration of the current application session; any update notifications that are broadcast while A remains online will be received directly by A. This serves to limit the dependence of user peers on bootstrap peers to the initial bootstrapping operation, occurring at the very beginning of the user session.

Architecture and Functionality

APEX features a five-tiered architecture, illustrated in (Figure 4). The bottom tier consists of the Java 2 Runtime Environment. On level four are the JXTA protocol bindings for Java. Level three consists of the core APEX components which are common to every course peer group, including peer authentication, user presence tracking, and data replication components. The graphical user interface (GUI) code also forms part of this level. The GUI presents graphical representations of a user's contact roster and allows the end user to interact with the installed components within a course peer group. Level two features the optional components that are available for installation in a course peer group. Each of these components provides a piece of nonessential collaborative functionality, such as instant messaging or whiteboarding. The first level contains the component API, which can be used to write custom components for inclusion in course peer groups. To better illustrate the concept of a component in APEX, consider the example of an instant messaging component. This component enables instructor-to-student and student-to-student conversations to take place. Each member of the course peer group runs an instance of this component, whose responsibilities include maintaining a collection of ongoing conversation sessions involving the local user, associating incoming chat messages with the appropriate conversation session, forwarding outgoing chat messages to the appropriate conversation partner, and displaying an ongoing history of each ongoing conversation session to the end user. The component includes GUI code specifying that the contents of each conversation session are displayed to the end user inside a text area. The end user may enter new messages using a text box.


Addressing of Implementation Requirements

The design of APEX satisfies the implementation requirements previously specified for educational systems. First, platform independence is achieved through use of the Java 2 Standard Edition (J2SE) bindings for JXTA. Java can be run on a wide variety of platforms (including Windows, Linux/Unix, Mac OS).

The need for security is addressed by requiring each user to perform an initial authentication against the institution's registration records to determine which course peer groups the user is authorized to view, and the range of activities the user is permitted to perform within a given peer group. Once the user has successfully authenticated, a signed certificate is returned over a secure connection back to the user; the user then presents this certificate when joining any course peer group. Upon receiving the certificate, the peer group's membership service requests the registration system to verify that it issued the certificate. In addition, peer-to-peer communications taking place within the context of a course peer group can optionally be secured through use of digital signatures and encryption of the message contents.

A high degree of customizability is provided to instructors in determining which features will be included in course peer groups. A catalogue of existing components (such as whiteboard, instant messaging, bulletin board, and calendar tools) is made available. Instructors can browse this catalogue through the application's user interface; individual components can be added to a course peer group through a simple drag-and-drop operation. In addition, extensibility is provided through a component API that allows custom components to be created.

APEX also supports intermittent connectivity of users. Instructors and students are able to modify course documents while offline and have their changes synchronized with those made by other users upon the next subsequent connection to the network. This feature ensures that the state of a course peer group remains consistent while also recognizing the reality that users may not have ready access to the Internet at all times.

Identification of APEX users is performed independently of each user's current network location. As previously mentioned, location transparency is one of the defining features provided by JXTA's overlay network. In addition, each course peer group in APEX contains a dedicated service for monitoring the presence status (i.e., "online" or "offline") of each member of the course, and is responsible for broadcasting presence updates to each peer belonging to the class peer group. Users are able to perform group-level categorization of their contact roster by creating named categories (groups), which may be nested.

Collaboration between members of a course peer group is made possible through the inclusion of components which provide collaborative functionalities such as threaded discussions, instant messaging, and collaborative viewing and editing of shared documents. Instructors are free to use these components in their course peer groups or to create additional collaborative components in order to match the requirements of the particular course and the instructor's preferred teaching style.

Discovery of course peer groups occurs at the beginning of each application session. Each peer authenticates to the institution's registration system and receives updated information on all course peer groups for which the given peer is registered as an instructor, student, administrator, or teaching assistant. When an instructor chooses to add a new component to a classroom peer group, the relevant information is distributed to each participating peer to allow the component to be dynamically downloaded and installed on each peer.

Availability of application services is maximized by having each peer within a course peer group operate local instances of each component that the instructor has chosen to include in the peer group. In addition, shared course data is replicated to each peer's computer, making it available to all members of the course, independent of the current availability of any particular member of the peer group. The scalability of the application is increased by distributing course documents and data for course peer groups to each of its members, rather than centralizing the data and processing load on a limited number of server machines. Reliability of the application is increased by replicating course data to each peer belonging to that course's peer group. This makes the course documents accessible even if data is lost on a particular user's system. Finally, accessibility of application data is possible even in the presence of intervening firewalls or NATs. One implication of this is that access to course data is possible even when a student or instructor is off-campus.


This article reviewed distributed educational applications and their implementations using P2P frameworks. The authors have designed and partially implemented APEX, an educational application, based on JXTA. APEX forms a base for building a variety of powerful distributed educational applications suited for particular needs. Its current implementation proves that JXTA-based framework is sufficiently powerful to achieve all goals that all distributed educational applications should achieve.

Several possibilities for future extensions to APEX exist. Virtually any of the activities and interactions that take place in the traditional classroom setting can be effectively modelled in the application through the introduction of new components. For example, electronic submission and grading of course assignments and projects could all be done within the application: the students would first upload their submissions to the course peer group. Subsequently, the teaching assistant or course instructor would view the submitted document, make comments and assign a grade to the submission. The graded document would then be returned back to the student. In addition, instructors may be allowed to hold virtual office hours at designated times via a group chat feature. The addition of a component for audio/video conferencing would allow instructors to broadcast lectures within the application. This capability would be especially useful in distance education situations in which the instructor and students are separated by geography.

Finally, a dynamic course syllabus could be provided that would be updated throughout the term to specify assignment due dates and scheduling of midterms and final exams. Once an update to the syllabus was made by the instructor, the change would be automatically and immediately "pushed" out to all students enrolled in the course. This ensures that all students would be kept up to date with important course-related announcements.


This article is partly based on Leighton (2003) and Muldner and Leighton (2004). This work has been partially supported by a grant from the Division of Research and Graduate Studies at Acadia University.


Albitz, P., & Liu, C. (2001). DNS and bind, (4th ed). Sebastopol, CA: O'Reilly & Associates.

BitTorrent (2003). Retrieved May 8, 2005 from Torrent

Clarke, I., Miller, S.G., Hong, T.W., Sandberg, O., & Wiley, B. (2002). Protecting free expression online with Freenet. IEEE Internet Computing, 6(1).

Corba (2003). Retrieved May 8, 2005, from

CSCW (2003). Retrieved May 8, 2005, from

eZ (2003). Retrieved May 8, 2005, from

Gamma, E., Helm, R. Johnson, J., & Vlissides, J. (1995). Design patterns: Elements of reusable object-oriented software. Reading, MA: Addison-Wesley.

Groove (2003). Retrieved May 8, 2005, from

Grudin, J. (1994). Groupware and social dynamics: Eight challenges for software developers. Communications of the ACM, 37(1), 93-105.

Hilt, V., & Geyer, W. (1997, September). A model for collaborative services in distributed learning environments. Proceedings of IDMS'97, Darmstadt, Germany (pp. 352-363).

ICQ (2003). Retrieved May 8, 2005, from

JXTA (2003). Retrieved May 8, 2005, from

Kazaa (2003). Retrieved May 8, 2005, from

Leighton. G. (2003). Peer web services: Defining a peer-to-peer framework for web services. Honours Thesis, Acadia University.

Leuf, B. (2002). Peer to peer: Collaboration and sharing over the Internet. Cambridge, UK: Pearson Education.

Lloyd, S., & Adams, C. (1999). Understanding the public-key infrastructure: Concepts, standards, and deployment considerations. Indianapolis, IN: Que Publishing.

MacDougall, G., Muldner, T., & Tomek, I. (1998). Acadia advantage--computerizing a campus. Proceedings of Edmedia'98, Freiburg, Germany. Charlottesville, VA: Association for the Advancement of Computing in Education.

Muldner, T. (1998, November). Analysis of Java client/server and web programming tools for development of educational systems. Proceedings of Webnet'98, Orlando, FL. Charlottesville, VA: Association for the Advancement of Computing in Education.

Muldner, T., & Leighton, G. (2004). Building distributed educational applications using peer-to-peer. Proceedings of EDMEDIA'04, Lugano, Switzerland, (pp. 125-133). Norfolk, VA: Association for the Advancement of Computing in Education.

Muldner, T., & Nicholl, R.A. (1996). Computer-supported human cooperation in electronic classrooms. Journal of Universal Computer Science, 2(10), 679-693.

Muldner, T., & Phang, S.P. (1999, November). An experiment with computer-supported cooperative work: Shared workspace. Proceedings of Webnet'99. Honolulu, HI. Charlottesville, VA: Association for the Advancement of Computing in Education.

Muldner, T., & Shiv, V. (2000, June). Distributed repository of programming examples. Proceedings of EDMEDIA'00, Montreal, Canada. Charlottesville, VA: Association for the Advancement of Computing in Education.

Muldner, T., & Shiv, V. (2001, August). Distributed collaborative learning environments. International Conference on Internet and Multimedia Systems and Applications 2001, Kauai, HI.

Mullender, S. (1989). Distributed systems. New York: ACM Press.

Napster (2003). Retrieved May 8, 2005, from

Neal, L. (1989). A system for example-based programming. Proceedings of CHI 89, (pp. 63-67). New York: ACM Press.

Network Address Translation FAQ (2003). Retrieved May 8, 2005 from

Norman, D.A., & Spohrer, J.C. (1996). Learner-centered education. Communications of the ACM, 39(4), 24-27.

Onobee (2003). Retrieved May 8, 2005, from

Seti (2003). Retrieved May 8, 2005, from

Shneiderman, B., Alavi, M., Norman, K., & Borkowski, E. (1995). Windows of opportunity in electronic classrooms. Communications of the ACM, 38(11).

SOAP (2004). SOAP Version 1.2 Specification, 2004. Retrieved May 8, 2005 from

Tomek, I., & Muldner, T. (1999). Acadia advantage--evolution and experiences. Special Issue: Faculty change & the WWW. Interactive Learning Environments. Lisse, The Netherlands: Swets & Zeitlinger Publishers.

UDDI (2004). Retrieved May 8, 2005, from

West, A., & Hubbold, R. (1998, June). Research challenges for systems supporting collaborative virtual environments. Keynote speech at Collaborative Virtual Environments'98, Manchester, UK.

Windows Peer-to-Peer Networking (2003). Retrieved May 8, 2005, from

WSDL (2004). Retrieved May 8, 2005, from

Extensible Markup Language (2003). XML 1.0 (2nd ed.). Retrieved May 8, 2005, from

Zwicky, D.E., Cooper, S., & Chapman, D.B. (2000). Building internet firewalls, (2nd ed). Sebastopol, CA: O'Reilly & Associates.


Acadia University, Nova Scotia, Canada
COPYRIGHT 2005 Association for the Advancement of Computing in Education (AACE)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2005, Gale Group. All rights reserved. Gale Group is a Thomson Corporation Company.

Article Details
Printer friendly Cite/link Email Feedback
Author:Muldner, Tomasz
Publication:Journal of Interactive Learning Research
Geographic Code:1USA
Date:Sep 22, 2005
Previous Article:The effects of the Collaborative Representation Supporting Tool on problem-solving processes and outcomes in web-based collaborative Problem-Based...
Next Article:A framework for the evaluation of visual languages for instructional design: the case of [E.sup.2]ML.

Related Articles
Unleashing the Power of WORD-OF- MOUTH.
P2P Seeks Respectability In Financial Services Sector.
Learning and discovering at InfoComm.
Learning and discovering at InfoComm.
SuitTorrent: Hollywood vs. downloaders.
Using student peer evaluations to evaluate team taught lessons.
Peer evaluation as an active learning technique.
Project MERLOT: bringing peer review to web-based educational resources.

Terms of use | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters