1.Introduction

This document is to serve as a software architecture document for the peer-to-peer audio file sharing application to be developed using 802.11b standard on a linux platform for course CS327 Software Engineering I.

1.1Purpose

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made for developing the system.

The document should serve to translate the requirements in terms of use-cases to the actual implementation and is targeted towards developers for the linux-p2p-wifi-audiofilesharing project. The document should help the developers understand the system as a whole, the interactions between the major layers in the system, and the module break up for each layer using a number of architectural views. Essentially, the entire document is structured so as to give the developers architectural details at different levels of abstraction.

1.2 Scope

The document shall serve as a guide to developing the application for the linux-p2p-wifi project. All the major architectural decisions are captured and influenced by this document. The test plan for the project shall be influenced by the sofware architecture design.

1.3 Definitions, Acronyms, and Abbreviations

Wifi – Wireless standard using the 802.11b protocol.

Linux – Unix like operating system.

P2P – peer to peer network

JXTA – short for juxtapose. A set of protocols developed by Sun Microsystems for p2p networking. www.jxta.org

Instant p2p – A p2p implementation using Java and JXTA.

API – application programming interface

1.4 References

All project documentation is available under CVS on sourceforge.net using keyword linux-p2p-wifi or on the class wiki page specified by the link. For further information, please refer to the CM document.

1.4.1 Software Requirements Document for linux-p2p-wifi project

1.4.2 Software Testing Document for p2p-wifi project

1.4.3Use Case briefs and detailed descriptions.

http://wiki.cs.uiuc.edu/SEcourse/Group+38+(Fall+2002)+Use+Case+Briefs

1.4.4 Use Case diagram Document for linux-p2p-wifi project

1.4.5 Project Plan for linux-p2p-wifi project

http://wiki.cs.uiuc.edu/SEcourse/Group+38+(Fall+2002)+Project+Plan

1.4.6 Project Build document for linux-p2p-wifi-project

1.4.7 Class diagrams for linux-p2p-wifi project (iteration 3)

1.4.8 "This product includes software developed by the Sun Microsystems, Inc. for Project JXTA."

1.5 Overview

The entire software architecture document is organised to help visualise the system at different levels of abstraction using different architectural views. The document describes the system in terms of layers, API/Interface between layers, and the module break-up for each layer. It also describes the system using different architectural views such as use-case, logical, and implementation.

2.Architectural Representation

The entire architecture is described in terms of use-case view, logical view, and implementation view (in terms of API). This sections describes what the software architecture is for the current system and how it is represented in terms of these views.

The architecture of the system is designed in terms of three core layers: Application UI Layer, Services Layer, and Core Layer. The reason for splitting up the system in to layers is to provide the necessary flexibility to for future enhancements and changes by hiding most of the implementation details behind a well defined set of API's that allow each layer to communicate with the other layers. This way as long as the system agrees on a set of API's, one or more layers could be modified and it would not affect the rest of the system at all. For e.g, the protocol layer is implemented using JXTA. However, the core layer could easily be changed to implement any other protocol and may use any underlying physical transmission medium without affecting the other layers in the system as long as it still implements the agreed API.

Use-Case View

The use-cases help to capture the functional requirements of the system, thereby essentially capturing functionality that the software architecture is targeting. The document provides a use-case diagram that captures this target functionality.

Logical View

The logical view describes how the system is split up in to layers and the module break up for each otehse layers in terms class diagrams. This should give the developers a good idea of the significant architectural modules and most of the important interactions between them.

Architectural View

This view describes the individual layers and the interactions between these layers in terms of API calls. This should help the developers working on a single layer know just enough about the other layers to be able to integrate their implementation in to the overall system and use the underlying functionality offered by other layers. This is described in terms of the API interfaces offered by each layer.

3.Architectural Goals and Constraints

One of the objectives of the architecture has been to make the system a portable one. The design will be intend to meet this objective by using JAVA as its programming language.

The other most significant objectives that the architecture targets to suffice is reusing available open source code implementing JXTA(core layer). As part of the design decision, we will implement JXTA for the core layer functionality. There is already plenty of open source implementations in Java available for JXTA and architecture intends to take full advantage of this benefit by using one such implementation called Instant-p2p http://instantp2p.jxta.org for our core layer implementation. This is in line with meeting our objective of utilizing the available expertise in the p2p field and helps us keep the project manageable. As part of the design, we will put wrappers around this core layer implementation provided by instant p2p in terms of the API that the architecture defines for the layer.

Since the architecture is divided in to layers, the team shall also be distributed in terms of groups with each group implmenting a particular layer. Hence, we'll have three groups(Application UI, Services, and Core). Although the system is to be developed on a linux platform, the choice of the programming language JAVA helps us implement independently of the underlying platform for the most part.

However, we intend to run our code before putting it under version control on a linux platform as an essential implementation strategy.

Prototyping and Tracer-buller approach( Iteration 3)

In line with our architectural goal of reusing available open source p2p expertise and the RUP process(prototping), we have decided to do prototyping by using available jxta protocol implementations for our core layer and part of our services layer, and adopt a tracer bullet approach while developing our UI layer and our own expertise with developing core and services layer. There are several benefits of using combination of these two approaches.

a) We'll be following RUP as far as prototyping is concerned. This should give us tremendous insight in to the workings of the JXTA p2p protocol and help us further refine our API sets between the three layers.

b) Using a tracer-bullet approach with our UI layer will help us develop our own UI and integrate it with the prototype services and core layers. This should in essence give us a working system at the end of this iteration.

Since auto-detecting is the most important use-case, we'll implement a minimal system that does automatic peer-detection using a combination of in-house and open-source code.

With the insight and confidence gained by following these approaches and putting together a working system, we'll be able to further implement our in-house services and core layer implementation. Such a design strategy will help us comprehend a complex system like ours in its entirety and shall enable us to implement our own design by re-hasing the prototype code in the core layer and the services layer.

The lessons learnt durint this iteration shall go a long way in allowing us to fine tune our API's and layer design.

This iteration does not change our original designed that we've already laid out as part of iteration 2.

The goal of iteration 3 will be to allow us to understand how our current design layout would work when implemented and to further tweak our design based on the lessons learned. Iteration 3 shall be using our in-house developed UI layer, Services API, and GuiAPI code.

Such an integration effort of putting together an entire working system will also give the developers a recognition of how well developed API sets will allow for an easiser intergration in the future and the respective effort involved.

4.Use-Case View

The use cases for the sytem can be found in the SRS document(1.4.1). Most of the use cases span more than one layer thereby having a significant architectural coverage. Some of the more significant use cases are hereby described as follows:

a) Autodetect:

This use case captures the functionality that forms the heart of the system. It requires the system to autodetect peer nodes throughout the lifetime of the system and cache this peer node information for future use. This use case spans all the three layers.

b) Search/Download:

These two use cases the search and download identify another big chunk of functionality that the system's shall be implementing. Essentially they have architectural coverage through all of the three layers.

c) Upload:

Since our p2p application acts as a servent(server + client), this use case identifies the other half of the file sharing functionality that is indentified through b). Again it has architectural coverage through all the three layers.

4.1 Use-case realizations

Please refer to the use-case briefs and details(1.4.3) and the use-case diagram (1.4.4)

5.Logical View

As mentioned before, the entire application is divided architecturally in to three layers of abstraction namely Application UI, Services, and Core.

This section describes how the individual layers are further divided in to classes and the relationships between these classes.

5.1Overview

The entire system is divided in to three layers with each layer offering a certain set of functionality at

a particular set of abstraction. At the highest point of abstraction is the Application UI. This layer

offers the user interface to the end user, sends out requests generated from the UI, and displays

the corresponding responses to the user requests using the UI. The only way interface used by the

Application UI will be the services layer API. It is completely incognizant of the services implementations and the underlying protocol used.

The middle layer is the Service Layer. This layer provides the content management services.

The services layer interface with the UI using the UI Api set and with the core layer using the

core API. Again the services layer is incognizant of the way the UI is implemented or the underlying protocol. The services layer maintains the list of known peers, does the content management services

such as storing user configuration or downloaded audio files. It also provides services to look up

a file for uploading. It works like a event handler where each event is a request to use its service.

Finally, at the lowest level of abstraction is the protocol layer. The protocol layer interfaces only

with the services layer through the services API. The protocol layer encapsulates the entire protocol

implementation(JXTA). Again the protocol layer does not care about what is built on top it in terms of the UI and the services. It hides all the protocol and transmission layer details from the rest of the system.

5.2Architecturally Significant Design Packages

The class diagrams for iteration 3 illustrates this further. The core and services layer class diagrams

are from the prototype code.

6.Process View

The choice of the programming language JAVA has influenced the system's decomposition in to

lightweight processes or threads. Since JAVA already provides multithreading as part of the language itself, we will use this multithreading feature of the language for designing our system.

Essentially, the system shall be decomposed in to three threads: one each for the Application UI,

Services, and the Core Layer. Each of these individual layers could in turn spawn multiple threads.

The data between the threads usually objects shall be exchanged using memory sharing. This should

help us get away from any kind of interprocess communicationg mechanisms normally used between

multiple processes and save us from overhead incurred on running a new process everytime.

7.Deployment View

The system shall be run on a computer with a minimum configuration of Pentium II processor, 64MB of

RAM, with a wifi card(802.11b) on a linux platform with kernel of 2.4 or better. The core layer thread

shall take care of the underlying transmission medium, which is relegated to making system calls. Such a

setup should be able to do run the system as a p2p client+server.

8.Implementation View

This section describes the overall structure of the implementation model, the decomposition of the software into layers and importantly the interaction of the layers through a well-known published

set of APIs.

8.1Overview

As mentioned earlier in the document, the entire system is divided in to three layers/components

namely the Application UI layer, the Services layer, and the Core(protocol) layer. The rules that govern inclusion to any given layer are very logical.

At the top most level is the Application

UI layer. This layer basically implements the User Interface and provides a high level view of the system's where everything works through a set of user interfaces. It interfaces with the immediate layer i.e.

Services layer.

The middle layer is the Services layer that performs most of the logical tasks in the system. It interfaces with both the Application UI layer and the Core layer. It also performs the content management tasks such as storage and retrieval of peer information, user preference, and audio files. However, the majority of the work within the services layer stems from servicing user requests for p2p file sharing as both a client and a server. This layer implements the logic for the application without any knowledge of the existence of the presentation layer(Application UI) or the underlying protocol layer(protocol) and as such is very generic in terms of implementation.

The layer at the lowest level of abstraction is the Core layer or the protocol layer. This layer

takes up requests from services layer to send out a request/response by respectively encoding/decoding the

high level request and converting it in the native protocol format. This layer is strictly to do with

implementing the underlying p2p protocol(in our case its JXTA). It does not really care of however the requests are sufficed or responses generate. It just cares enough to adhere to the p2p protocol.

Interface between layers.

As part of our design and implementation strategy, we've decided to implement the system in terms of

the layers and the API's published by each of these layers. The APIs allow the rest of the system's to interface with an single layer.

The following component diagram shows the relations between the layers.

8.2Layers

Application UI layer

This layer implements the following classes.

a) FileInfo

b) PeerInfo

c) ConfigurationInfo

d) GuiMain

e) MusicProfile

It offers API's for interfacing by implementing the following GuiApi class.

f) GuiApi

The GuiApi class provides the following apis: notifyDownloadVectorChange( ),

notifyUploadVectorChange( ), and notifyFileStatusChange()

Services Layer

This layer implements the following classes:

a) Download Manager(maintains a vector of FileInfo objects)

b) Upload Manager( maitains a vector of FileInfo objects)

c) User Configuration Manager(stores/retrieves user configuration information)

d) Content Manager(retrieves and stores shared files)

e) Peer-Info Manager(retrieves and stores the autodetected peer information)

It offers APIs for interfacing with the services layer by implementing the class ServicesApi

f) ServiceApi

The ServiceApi class provides the following api:

Used by Application UI:

getCurrentConfigInfo( ), getUploadVector( ), getDownloadVector( ), pauseDownload( ), SearchPeer(),

SetCurrentConfigInfo( ), and StartDownload( )

Used by Core:

StartUpload( ), AddNewPeer( ), notifyUploadVectorChange( ), and notify DownloadVectorChange( )

Core Layer

This layer implements a number of classes as part of the instant-p2p implementation of JXTA.

It provides a useful API for the rest of the system to interface with itself.

a) CoreApi class provides the following api:

announcePeerPresence( ), encodeOutgoingMsg( ), and decodeIncomingMsg( ).

NOTE: For the current iteration, the servics and core layer classes are used from existing jxta implementation. The details of this protyped code in the services and core layer can be found in the

iteration 3 class diagrams. This in no way changes our original design that has already been laid out.

9.Data View

This section describes the persistent data stored as part of the system. The only persistent data stored as part of the system is the user preferences and the peer information. The storage and retrieval functionality is implemented as part of the services layer. As such the system is not data-centric.

10.Size and Performance

Since this is a class project, there are no tight contraints on the size and performance of the system.

However, the system is architected in a way so that it can strive to meet any such non-functional requirement at a future date.

11.Quality

Again, since this project is undertaken as a class project, there have not been any quality attributes

or requirements in terms of safety, security, or privacy imposed. The idea is to provide a good architecture

that allows the implementation to be kept as clean and simple as possible, thereby allowing it to meet

any such quality requirements at a future date.

Date	Version	Description	Author
October 5^th, 2002	1	Initial Draft. Based on gnutella p2p protocol.	Abhishek Bhatt
November 2^nd 2002	2	Updaed the design to use jxta protocol.	Abhishek Bhatt
December 9^th, 2002	3	Updated the document to include the prototyping/tracer bullet strategy and the corresponsind design changes related to it.	Abhishek Bhatt