dube: a web application for the distribution and update of...

Free University of Bolzano/BozenFaculty of Computer Science

Thesis

Dube: A Web Application for the Distributionand Update of Data Processing and

Visualization Components

byFestus Oviarumwense

Submitted in partial fulfillment of the requirements for the degreeof Bachelor of Science in Computer Science at the Free University of

Bolzano/Bozen

Thesis Advisor: Andrea JanesOctober, 2012

Contents

1 Introduction 41.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Problem Description 52.1 Architectural model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Relevant Technologies 63.1 J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Jersey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5 JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.6 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.7 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.8 JUnit4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.9 Sikuli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Solution 104.1 Installation, integration and configuration of Apache, Jersey and other ex-

ternal libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Make a sample/test program using REST to send and get data from the

database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Converting jar file to byte array and Encoding PNG files in the database . . . 124.4 Implementing an auto update tool to update all Java product in the market 124.5 Test the auto update tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.6 Test the entire application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Architectural description 155.1 The 4+1 view model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Logical view of the market component . . . . . . . . . . . . . . . . . . . . . 165.3 Developmental view of the market component . . . . . . . . . . . . . . . . . 175.4 Process view of the market component . . . . . . . . . . . . . . . . . . . . . 205.5 Physical view of the market component . . . . . . . . . . . . . . . . . . . . . 215.6 Scenarios of the market component . . . . . . . . . . . . . . . . . . . . . . . 21

6 Automatic Update 246.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

i

CONTENTS ii

7 Usage of the Dube Library 27

8 Conclusion 28

Abstract

Plugin-based applications are applications in which components can be installed, updated,or removed from the core application without recompiling it.

Plugin-based applications allow users to choose among available plugins and installthem within some core software module. To implement such a system, the developerneeds to a) implement a server to host plugins and b) a library to download, update, orremove the plugin within the core software module.

To support such developers, the Dube framework provides the two mentioned parts: aweb application (the “market”) that displays components on a web site and a library (the“library”) that takes care of all the interaction between the market and the core softwareapplication.

This thesis describes the implementation of these two components, describes the usedtechnologies and algorithms, and discusses possibilities to unit-test the framework.

1

Abstract (Italiano)

2

Abstract (Deutsch)

3

Chapter 1

Introduction

Plugin-based applications are applications in which components can be installed, updated,or removed from the core application without recompiling it.

Plugin-based applications allow users to choose among available plugins and installthem within some core software module. To implement such a system, the developerneeds to a) implement a server to host plugins and b) a library to download, update, orremove the plugin within the core software module.

To support such developers, the Dube framework provides the two mentioned parts: aweb application (the “market”) that displays components on a web site and a library (the“library”) that takes care of all the interaction between the market and the core softwareapplication.

1.1 Purpose

The market concept implemented in this thesis follows a new type of application develop-ment that creates an online distribution environment.

One goal of this thesis is to study new ways to handle the distribution, visualization,and update of Java components. There are lots of web applications that distribute Javacomponents, but do not provide a programmatic way to automatically search, downloadand install an update of each products it distributes.

1.2 Structure of the thesis

This thesis was divided into five parts excluding the Introduction and Conclusion. Thevarious chapters have been fully elaborated and structured to the lowest level of detail.The problem description chapter provides a brief listing of the task to perform for theproject. The relevant technology chapter provides the list of technologies used in theapplication development. The solution chapter speaks more of the problems mentionedearlier in chapter two and possible solution acquired. The project description chaptercontains detailed description of the web application using a 4+1 model (Kruchten 1995a).The auto update chapter speaks of the auto update tool developed to complete the project.

4

Chapter 2

Problem Description

The overall task of this thesis is to create a toolset that allows a developer to store, modify,delete, and update Java components in his or her application. This task is divided into sixdifferent parts:

1. install, integrate and configure the Apache Webserver (Tomcat 2012);

2. make a sample/test program that uses the REST (Vogel 2012) protocol to send andget data from the database;

3. convert files (such as archives or pictures) into a format so that they could be storedin the database;

4. develop an updating server application to update all Java applications;

5. test the update program with an application;

6. test the entire toolset.

2.1 Architectural model

Due to the fact that several architectural models exist in software development, pickingthe model to satisfy the functional and non-functional requirement of a web applicationstill remains difficult. The lack of basic knowledge of technologies such as Apache andother external libraries placed me to choose the prototyping model (Mentor 2010) torepresent the idea, since this model allows the construction and modification of every partof the system. The identification suitable architectural model to implement scalability,performance, and reusability of my application (Liu 2009) was therefore developed usingprototyping. The above mentioned task of the project development will be fully elaboratedin chapter four of this thesis.

5

Chapter 3

Relevant Technologies

The following technologies are relevant for my thesis and will be explained in this chapter:

• J2EE

• Apache Tomcat

• REST

• Jersey

• JSP

• CSS

• Java Script

• JUnit4

• Sikuli

3.1 J2EE

J2EE is a platform that provides solutions to design, develop, deploy and manage multi-tier applications. It helps to minimize application programming and significantly reducesthe cost and complexity of multi-tier programming (Microsystems 2012).

This technology supports a multi-tier model that simply separate the business logicfrom the presentation logic. A multi-tier model can be compared to the MVC model,in which you can expand and redesign the business logic tier layer with a new require-ment without affecting the entire application. This can be implemented using an architec-ture that supports plugins and allows to modify the application whenever a requirementchanges. This approach speeds up the development process.

J2EE implements a three-tier architecture. The client tier implements the user inter-face, the business tier holds the business logic, and the enterprise information system tierat the back-end holds the data. All these tiers rely on the Java programming language andthe Java virtual machine (JVM) (see figure 3.1).

6

CHAPTER 3. RELEVANT TECHNOLOGIES 7

Figure 3.1: J2EE 3tier architecture

3.2 Apache Tomcat

Apache Tomcat is a web application server and Servlet container that implements the JavaServlet and JSP. It provides a Java HTTP environment for Java code to run, and alsocontains an HTTP connector on port 8080 by default which can be used to serve staticHTML (Tomcat 2012). The Apache Tomcat library comprises of 3 major packages whichare Coyote, Catalina and Jasper. This libraries are in charge of functionalities of Servletsand Java Server Pages. They provide an environment for running web components. Adetailed discussion of this technology will follow later.

3.3 REST

REST (Representational state transfer) is an open source architectural style for distributedhypermedia systems that can also be seen as a protocol for exchanging structured infor-mation in the implementation of web service (Rodriguez 2008).

REST tends to create interfaces based on the HTTP standard for common and tra-ditional middleware services such as transactions, messaging, workflows, security andmanagement. It allows low coupling between different services thereby facilitating thetransactions between web servers. REST is seen as a mediator that accept request froma client through a standardized interface and send back response to the client. There isa specific feature of REST which is layering or encapsulation of request that is, lots ofconnectors can be involve in processing the request of a client without each connectorseeing past through its own request. All these connectors, e.g. clients, server, tunnels,cache etc. only see what they are ask to do (request). It is simple to implement and allowsscalability of projects by supporting multiple back end services. In a REST architecture,data and functionality are seen as resources that are accessed through URIs. REST in themarket component was used to interact with the resource in the database by specifyingthe location and the representation of the data. Most often the representations are HTML,JSON or XML but in our case JSON was preferred (see figure 3.2).


Figure 3.2: REST architecture

3.4 Jersey

Jersey is an open source JAX-RS referenced implementation for building RESTful webservices according to the REST protocol (Java 2012). A RESTful web service is the im-plementation of web service using HTTP and the principles of REST (Oracle and affiliates2012). Apart from Jersey implementing JSR-311 API, it provides additional API that canhelp developers extend JSR (Java specification request) to suite their specific need.

3.5 JSP

JSP also known as Java server pages is a technology that allow software developers tocreate web page dynamically, it is seen as high level of abstraction of Java Servlet as it istranslated into a Servlet at run time (Hall 2000). With the technology images, text weredisplayed, and also some computation were made as Java code were embedded insidethe various page. Some of the communication with the Logical module were also donedirectly from the page take for instance request of stored products from the database weremade here. The pages were executed within a Java virtual machine like every other Javaprogram. There are similar technologies such as PHP and ASP.Net.


3.6 CSS

CSS also known as cascading style sheet is a style sheet language used for styling webpage to give a better presentation to documents. The layout, color and the font of thedocuments were designed with this technology. With this technology redundancy wereminimized as multiple pages were able to share a common format, complexity was alsoreduced (Meyer 2000).

3.7 JavaScript

Java script is a scripting language used to add functionality to web pages such as formvalidation and communication with the server (Crockford 2008). The technology wasused to validate most of the form to avoid an invalid value such as empty string, integervalues instead of string values take for instance the upload functionality is always beenvalidated by the script before sending the information passed.

3.8 JUnit4

JUnit is an open source Java framework for writing repeatable test (Mills 2005). ThisFramework support unit testing in software engineering. Unit testing is a way by whichindividual units of source code are tested, it is an instance of white box testing. JUnit4integrates in IDE and Ant, simple and rich . it has new features that the older version donot have, these features made it richer than the older version, first the package importedcomprises of sub-packages including org.junit.Assert.* which make life easier for devel-opers. Two new assertion method has been added to junit4 which are used to comparearrays of objects.

3.9 Sikuli

Sikuli is a visual technology used to automate and test graphical user interface (GUI)using images or screenshots of the software undergoing test (Sikuli 2010). It has anIDE for writing visual script and also include a feature to control a web page and otherapplication.

Chapter 4

Solution

As descripted in chapter 2, the installation and configuration of every part of the systemwas concluded, and a unit testing application was used to test each part of the functional-ity.

4.1 Installation, integration and configuration of Apache, Jer-sey and other external libraries

At the beginning of development lots of research was made online to get the step by stepapproach on installation and configuration of Apache Tomcat on Eclipse IDE (Good 2007).Apache tutorial referred me to some Java docs on the Apache project covering most of theAPI. Below is a typical example of how REST architecture works with Jersey.

I created the following Java class in the project:

1 // The Java class will be hosted at the URI path "/↘

helloworld"

2 @Path ("/helloworld")

3 public class HelloWorldResource {

4

5 // The Java method will process HTTP GET requests

6 @GET

7 // The Java method will produce content identified by the ↘

MIME Media

8 // type "text/plain"

9 @Produces ("text/plain")

10 public String getClichedMessage () {

11 // Return some cliched textual content

12 return "Hello World";

13 }

14 }

Listing 4.1: REST Configuration

The above code represents the syntax of sending and getting data. The system needsto be configurated to know when and where to get the specified package. configuration ofJersey in the file web.xml is as follows.

1 <Servlet >

2 <Servlet -name >Jersey REST Service </Servlet -name >

10

CHAPTER 4. SOLUTION 11

3 <Servlet -class >com.sun.Jersey.spi.container.Servlet.↘

ServletContainer </Servlet -class >

4 <init -param >

5 <param -name >com.sun.Jersey.config.property.packages </↘

param -name >

6 <param -value >it.unibz.RESTserver </param -value >

7 </init -param >

8 <load -on-startup >1</load -on -startup >

9 </Servlet >

Listing 4.2: Jersey Configuration

This tells Jersey that all the classes in the namespace it.unibz.RESTserver have to be read.The communication uses HTTP protocol (Connolly 2004), it is organized according to theREST architecture. After the installation and configuration phase was completed, a simpleJSP file was created to test some basic functionality.

4.2 Make a sample/test program using REST to send and getdata from the database.

This part was the core part of the whole system as it was met to test the MVC (Model-view-controller ) concept. Basically this concepts separates the model which is the datato manipulate; the controller mediates the communication between the model and theview, while the view visualizes the state of the model (data). The model can be an objectrepresenting data or activity, for example a database table (ConnellyBarnes 2012).

The whole system was designed to get a command from the user via JSP page (view)that is directed to the controller (Servlet) which in turn calls the Java classes (model) toeither retrieve or send data to/from the database. REST architecture is used to achievedthis operational part of the MVC pattern called Model.

Figure 4.1: MVC concept


4.3 Converting jar file to byte array and Encoding PNG files inthe database

A database system is powerful and intuitive to use, nevertheless it has its own syntax ofaccessing it.

Uploading of a PNG and ZIP file requires a conversion of the respective file to an arraybyte inside the server daemon which can be accepted by the database. The conversion ofthis file type to byte array needed the importation of some packages via this line of code.

1 FileItemFactory factory=new DiskFileItemFactory () ;

2 ServletFileUpload upload=new ServletFileUpload (factory) ;

3 Java.util.List <FileItem > item=upload.parseRequest (request) ↘

;

Listing 4.3: Jar file conversion

Following the last line of code above, array byte was later extracted from the FileItemobject through a simple line loop that takes the PNG or ZIP file out of the list and stores itin a FileItem object. Below shows the code that finally converted it to an array byte.-

1 FileItem filecontent=item;.

2 byte[] picture=filecontent.get () ;

Downloading of the ZIP file also required the conversion of the byte array data insidethe Servlet to its ZIP file. The following code was later used to accomplish this function-ality: response.getOutputStream().write(bytes). Displaying the picture contents in bytearray data type requires an external library called common-codec-1.5.jar that can encodebinary data using the Base64 encoding. This package provides Base64 encoding and de-coding take for instance Base64.encodeBase64String (bytes) convert the byte to a string.

4.4 Implementing an auto update tool to update all Java prod-uct in the market

Connect, search, authenticate, download and unzip or install an update was the goalof this part. On the other hand how to achieve this goal was an open question. Therequirement for the auto update tool are as follows;

1. It shall be secured to avoid penetration from hijackers, i.e. downloading and runninginjected files from hackers. The system should be able to check signature of any filebefore downloading and unpacking the file.

2. The consent of the user shall be requested before installing the file.

3. In case of crash while downloading it shall be able to pause the downloaded file andrecover from the error state.

4. Shall be able to return to its previous state when deletion of the product occursduring streaming.

5. When updating the auto update feature itself it shall be very fast e.g. 1 min.

6. The feature shall be able to handle exception, display error details and return toprevious status.


7. It shall be able to write new data (file) to a subfolder where the small applicationthat start the main program can redirect to while starting.

8. It shall be able to prompt the user to restart after writing the whole data to thesubfolder.

9. The new update shall fit the procedure of connecting with previous external dataused by the old files. Eg accessing data from database, if there is error it should beable to handle the exception by prompting the user with the details.

10. In terms of compatibility problem it shall be able to return to old subfolder afterprompting the user to restart.

11. It shall notify the client that an update is available and permit the user to update orcancel the update.

12. It shall be able to search and download the update file suited for a particular product.

First I made a template class containing unimplemented method to handle the connectionto the server, list of installed program, current version of update, and lastly the downloadand installation method.

The program was made to send request to the server update asking for available updateof the clients application with clients server architecture under the TCP/IP protocol toensure total transfer of packets to the clients application during download. The lack ofbasic concept of how auto update program works leads me to the development of a paperprototype to help converge my views and idea. Also the analysis of various tools wascarried out to emphasize on the functionality of an auto update (Plus 2011); this can befound in the table below.

AutoUpdate+ TrueUpdate Applife Updatesecurity x x x

Auto permission x xDlls register x

patches (partial replacement) x xother tools compatibility x x

standard design x xupdate log viewer x

.net Framework support xGui update control x x

Presvent system short down x x

Table 4.1: Update tools table

The lack of basic concept of how auto update program works leads me to the develop-ment of a paper prototype to help converge my views and idea.

4.5 Test the auto update tool

Running test on an application to search, download and install of an update wasn’t aneasy task as some of the method runs successfully while other part failed. JUnit test wasrepeatedly run on the entire auto update parts, first the search, download and finally theunzip method (see figure 4.2).


Figure 4.2: Auto update concept

4.6 Test the entire application

Though the functional test of the whole system parts was done, there was still need to testthe entire application (system test). The entire application was tested using regressiontest. Regression test is any type of software testing that seeks to open all sorts of bugs andlow performance due to the introduction of new part to a system.

The entire system went through a thorough regression test to uncover bugs, checkscalability, and performance after the inclusion of every part of the system according tothe requirement. The test was conducted by some developers and non developers bycontinuously rerunning previously run test to check if performance has diminish and newbugs has emerge. Invalid data were entered to see if the application can handle exceptionsof various type.

Each page of the market component went through GUI test using Sikuli test suite tocapture the required part of the page displayed. We begin by capturing a particular partof the web page (in our case a button) using one of the method called click, the buttonimage is then placed as an argument on the click function in the Sikuli IDE (Sikuli 2010).Another part is also captured assumed to be the expected page to display.

In the IDE an assertion method is given taking expect result image as an argument tosee if it exist.

Chapter 5

Architectural description

The market component was separated into two parts; the market and the update library.This chapter speaks of the web application while the update library will be discussed inthe next chapter.

Basically, the market works like every other web application that takes a request fromthe clients usually web browser and transfers the data from the clients to the HTTP serverusing the CGI mechanism. CGI also know as common gateway interface controls the flowof data from the sever to the gateway programs that allow the interaction between theweb and the resources on the server side such as database (Graham 1995). Description ofthe project is done using 4+1 view model.

Figure 5.1: common gateway interface concept

5.1 The 4+1 view model

The 4+1 model view architecture is used to describe the architecture of a software sys-tem, based on multiple concurrent view that can satisfy different stake holder’s interest

15

CHAPTER 5. ARCHITECTURAL DESCRIPTION 16

(Kruchten 1995b). There are four different views with an additional one. They are asfollows:

• Logical view: this view deals with the functionality the system provides to the endusers.

• Developmental view: it deals with the illustration of a system from a programmer’sperspective and the management of the system.

• Process view: deals with the dynamic aspect of the system and focus on the run timebehavior that is, how processes communicate.

• Physical view: it shows the system from a system engineer point of view, describingthe various parts of the system components on a physical layer.

• +1 view (scenarios) : these aspect describe the interaction between the system andthe user.

5.2 Logical view of the market component

The web application is divided into the following features; (see figure 5.2)

• Visualize product categorically- it visualizes the product according to the category.

• All product- displays all the product for users to seeks

• Recent product- it displays recent product uploaded in order for users to see newproduct available

• Recommendation system- recommendation system displays recommended prod-ucts according to the product selected

• Related products- related products are displayed according to a particular product.

• Search product- users can enter keywords to search for product

• Product details- it visualizes the complete information of a particular product andthe owner of the product

• Comment and rate product- users can comment and rate products

• Delete rate and comment- users can delete comment and ratings of their own butnot that of other users as its part of user’s right.

• Upload product- users can easily upload a product with its information to the mar-ket

• Download product- users can download product from the market

• Modify product- products can be easily modified and re-uploaded .

The market component is composed of five different unit that work together to providethe functionality mentioned above.


• Interface unit: The visualization of web page covers various communication. Thoughto users it might seem just a single request response, on the other hand it is morethan that. Web browser interact with web application server using a request re-sponse. The browser retrieve a JSP page according to the URL which in turn retrievethe images, JavaScript, CSS or styles (Wartiak 2007). These set of pages that includethe styles, JavaScript and external Java code is called the interface unit.

• Operational unit: this unit is responsible for the manipulation of data. It is calledby the interface class or unit to execute some operation. This unit can only calls theREST unit for proper transportation of data to/from the storage point. Nevertheless,the call of the operational unit is not always from the interface unit but sometimesfrom the Servlet unit.

• Servlet unit: Servlets are Java classes that are loaded and executed by a Servlet con-tainer, and can run as a Java component in a web-server or Java enterprise Editionapplication server (Data 2010). This unit handles request as in the client server ar-chitecture or rather request response protocol whereby this unit stand as the server.It simply gets the request from the browser via the interface unit, process it usingthe operational and REST unit and simply returns a response to the interface unit.A concrete example of this operation is the upload of a product to the DataBase.

• REST unit: this unit only transport data to and from the database unit. It can onlybe called from the operational unit as it stands as the middle ware between thedatabase unit and the operational unit. This unit carries the uploaded data mentionabove to the database and also get stored data from the database.

• Database unit: At this point data are stored. It keeps record of data that will berequested later by the operational unit take for instance Comments and productsare stored here .

5.3 Developmental view of the market component

The market component as a web application with the specified functionalities above wentthrough general software life cycle; requirements, analysis, design, implementation andtesting. It was develop in a sequential manner using the agile methodologies.

First, the configuration and integration of Apache Tomcat in eclipse IDE (integrateddevelopment environment) using Java SDK (software development kit) was made in or-der to have a smooth environment for developing the web application. Eclipse IDE is adevelopment environment embedded with Java platform, Enterprise Edition, Java EE etc.the platform provides a run time environment and various API ( application programminginterface) for developing and running software such as web application, web service andother network application. The SDK help to run Servlets on a machine. Apache Tomcatprovides a Java HTTP web server environment to run your Java code and also implementsyour JSP and Java Servlet. After the configuration and installation of every piece of appli-cation needed, a new web project was created and targeted to run at the Apache Tomcatdownloaded earlier. The application comprises of Java resources module, libraries andweb content.

• Web content: Web content is a folder that comprises of all the JSP, CSS and JavaScriptfiles. This whole module was used to develop the interface of the market componentin order to ease communication between the user and the server.


Figure 5.2: The market component units communication diagram

• Java Resources:This folder contains all the Business logic of the application. Theyinclude the following packages;

1. Beans package

2. Database package

3. Servers package

4. Utilities package

Beans package: This package comprises of Java beans used for storing data tempo-rally. Java beans or beans are reusable software components that can be developedand assembled easily to create sophisticated applications (Englander 2001). It wasused to encapsulate many objects into a single object or bean, so that it can be car-ried around as a single bean object instead of multiple individual bean. These areJava classes that were written in Java programming language. They include Short-Product, Rating, Product and Counter.

• DataBase package: this package contains the class called ProductOperation thatholds all the functions of the entire application. This package performs most opera-tion by taking the information stored in beans to perform its computation and laterpass the result to REST for delivery take for instance updateProduct (Product), thisfunction takes information of a particular product entered by a user and send it tothe REST for delivery to the database.


• Servers package: This package contains all the Servlets of the application . Theseclasses are simply Java based server side web technology that processes the requestof a client and simply generate a response that is returned back to the client. It usesthe HTTP Servlet which extends the Javax.Servlet.HTTP.HTTPServlet class. Theclasses are as follow;

1. CommentHandler :manages the comments posted by a user2. DeleteCommentHandler : handles the delete comment request3. DeleteProductHandler :handles the delete product request4. DownloadProduct: manages product download5. SearchHandler: handles search request.6. UploadProduct: manages a product deployed by a user

• Utilities package: This package contains classes meant for various computation tohelp enhance the application take for instance Sort.Java class handles the visualiza-tion of recent product deployed, Test case etc.

• Libraries: This folder contains all the external libraries used in actualizing this appli-cation. Most of the libraries were gotten from the installation of the various compo-nent, part of eclipse IDE and others were manually included. The packages includethe following;

• Apache Tomcat 6: This Apache Tomcat library has 3 different component whichwere all useful in the development of the market component; it comprises of 3 majorpackage which are coyote, catalina and Jasper. Catalina is a web container thatwas responsible for mapping of a URL to a particular Servlet , and was also in chargeof the lifecycle of Servlets. Coyote was the server connector that support the protocolfor the application container. It basically listens to all the connection coming in andforward the request to the engine for processing and later send back the response tothe client. Jasper is a Tomcat engines that is responsible for compiling JSP files intoJava code as Servlet.

• Jersey: Jersey manages request from the Product operation class, connect to database,access data and return a JSON message.

• EAR Libraries: this Library is used to package various module into one archive fordeployment.

• Postgresql JDBC: the database was the storage point where all the products, com-ments and ratings were being stored. postgresql database is an object relationaldatabase management system used in the development of the application (Post-greSQL 2012). It supports vast data type up to geometric primitives, UUID andCIDR blocks and MAC addresses. The JDBC driver support six Java environmentand server versions that allow the REST with Java code to connect smoothly withthe database. The server simply connect to the database using the right credentialsprovided via the interface, thus accessing the database if authentication is successful.

• JUnit4: software development undergoes different stage of which testing is part ofit. Developers usually write a piece of code that executes some functionality undera test this process is called unit test. Most of the part of the market componentdeveloped went through a specific test which is part of the software lifecycle, junit 4framework was used in developing a test case.


Figure 5.3: package diagram of the developmental view

5.4 Process view of the market component

The application starts by opening a session through authentication of user input, thereaftercalling the REST to perform the query of recent product from the database. in response tothe query a JSON message (JSON 2002) is sent back with all the required information oth-erwise an exception is thrown. The system has been designed to handle multiple requestfrom users through the Apache multi-processing module (MPM) which is responsible fordispatching threads/process to different connection (Foundation 2012). the great thingabout Apache is keeping in spare an open thread to handle connection even when there isno connection yet, this help to speed up requests.

The web server gets the request and locate the file, then the application call on theoperational module to perform the computation which in turn call on the REST to getthe data from the database. A prepared statement is created using the postgres API toget connection and query statement ready. On return of the result the REST sends backa JSON message to the operational module that will finally transfer the data in a bean tothe JSP.

Figure 5.4 shows a typical example of an upload functionality represented in a UML


activity diagram. The set of rectangles known as activities represent an operation carriedout at a point as a result of a particular functionality triggered by a user. The diamondshape stands as a decision point. Directions of action are represented with arrows indicat-ing the next possible operation. The opened circle indicate the beginning of the process,while the shaded circle represents the end of the process.

Figure 5.4: Activity diagram of process view

5.5 Physical view of the market component

Figure 5.5 represents the UML deployment diagram that describe the physical view of themarket application. The two boxes and the drum represent the nodes, either software orhardware. Physical node is labeled with the stereotype device in order to indicate that it isa physical device such as monitor or desktop. Connections between nodes are representedwith simple lines, and are assigned stereotype such as RMI (remote method invocation)and JDBC to indicate the type of connection (Amber 2010). In a node we can have othernodes or software artifacts, take for instance the Application server which in turn haveREST and Resource nodes.

5.6 Scenarios of the market component

Below is the classification of the user application.

• Security: A login is required to Authenticate users of the application. when anauthentication fails, user is asked to enter a valid username and password otherwiseasked to register.


Figure 5.5: UML deployment diagram of the physical view

• Availability: Users can query list of products according to categories, that is visual-ization and Jobs. When a product of one of the named category is not available amessage is displayed indicating there is no such product yet.

• Modifiability: The user can query the product page by clicking on a particular prod-uct, the product detail is displayed along with the comment, ratings, related productsand recommended product. Users can comment, rate and upload product. They candelete their product, comment and ratings and also delete comments and ratings ofothers on their uploaded product. Comments displayed on the product of other userscannot be deleted by non owners. Uploading a product required a user to insert aZIP file of the product, the name of the product (string), the group, the keyword ina certain order (at most 3 different string separated with space or at least 1 string),the version which requires a float type, the description (string) and an image of .pngtype. When a data outside the above named data type is inserted an exception isthrown indicating the specific problem..


Figure 5.6: Use case diagram of the scenarios

Chapter 6

Automatic Update

An auto-update downloads and runs program files via Internet. It comprises of two ap-plication one in the server side (update server) and the other embedded in the client’sapplication (update client). It is deployed with the application and performs the auto-matic updating. Auto updates sends request every one minute searching for an updatethrough the server using the HTTP protocol with the client server architecture.

Updates are been searched by update process in the auto update tool embedded in theapplication using the parameters from the clients to get the actual update via the pathaccording to Jersey technology. Updates files are deployed to a server where it can belocated by all clients using the right URL to locate the position of the file or update. it canbe two different files;

1. the XML file which has the information regarding the update

2. the real update file

both files can be separated in two different server for security reason or put together(Tech 2010). The XML file Usually consist of the following components; Name of file,

Figure 6.1: Update Routing

Current version of application, New version of application (update), Description of the

24

CHAPTER 6. AUTOMATIC UPDATE 25

update and url of the file that contains the update digital signature. When the XML file isfound using the parameters from the clients update, the auto update process checks thedigital signature if its valid else the file is rejected and considered as malicious file. If thevalidation is successful other information such as the URL to the actual update is used tolocate and download the file.

6.1 Security

Checking the signature of an update file is very important in an auto update system as ittends to be a way of mounting security against malicious files from hijackers. Signaturehelps to confirm the source of a file. It can be stored inside an update package or a separateXML file that holds the steps and messages of the update file nevertheless, it is advisablenot to store signature in a ZIP file as malicious files can be send as ZIP which can causeexploitation of bugs in one’s ZIP unpacking library while trying to unpack it. In our caseit was stored in a separate text file using JSON format.

6.2 Download

Downloading the file from the server is done immediately after the security phase is suc-cessful, but sometimes it is difficult to download a large file due to poor Internet serviceor rather slow Internet connection. Possible solution to such problem is easily fix by usingthe right methodology take for instance BITS of Microsoft windows. During the process ofdownloading a product or update, an interruption might occur ( Internet failure, systemcrash or deletion of that product), this exception is handled with BITS library that simplypause and resume downloads.

6.3 Installation

Running an update is done after the downloading of an update file. Before running anupdate administrative right and signature is check in order not to unzip or write maliciousfile to users program. Services are written to be part of an application in an update clientwhich takes responsibility of the security as it has the required rights to update an appli-cation. When the service is called it performs the check on signature and then execute theupdate. Updates are executed simply by writing the new files to a subfolder that will be

Figure 6.2: Update tool embedded in Java application

placed on a register thereafter prompting the user to restart the application. At the appli-cation start up the little program called stub that starts the main application will executethe new subfolder in the register instead of the old subfolder that contains previous files.When updating an application the service will keep the old files until the update is com-pletely written to the subfolder and executed otherwise the folder is completely erased

CHAPTER 6. AUTOMATIC UPDATE 26

when the program crashes. During the process of executing the update files if there is anexception due to compatibility the service takes the old files and place it in the registerthereafter prompting for restart thus going back to the old status. In some cases patchingtechnology is been used by simply comparing the baseline to the patch subfolder, patchingthe application with the difference between the baseline and the patch subfolder. Thismethod helps to reduce redundancy and make update smaller than the file action whichsimply replaces entire files.

Services of an auto update can be updated by the admin of the tool, which is usuallya light file in order for the downloading and installing of the update to be fast. Most timesuch updates are required to be light files because of the services provided by the serviceprocess.

Chapter 7

Usage of the Dube Library

Figure 7.1 illustrates the overall architecture of the project.Viewing the architecture according to the shapes reveals three distinct parts in the

design of the application: the clients, the mediator and the resources. The rounded rect-angular shapes represents the clients, either web application or desktop application. Themediator is represented in rectangles and the parallelogram stands as the resources to beaccessed by any client. Connections between the mediator is represented with a light ar-row. The thick arrow is use to connect the clients to the mediator which in turn connectsthe resources. This designed architecture separates application functionality into threedistinct abstractions and clarity in the design and implementation phase.

The focus of my work has been on achieving the requirement of creating a dynamicweb application and an auto update to work together. After using different model toachieve various part of the project, I was able to put together the whole part in a way thatthe market library as displayed below became the power house of the whole application;this library gets request, process it and send back a response to both the market and theclient’s application. With this architecture high modularity can easily be achieved.

Figure 7.1: Project Architecture

27

Chapter 8

Conclusion

The aim of this thesis was to study a way to implement a web application that deploysand updates Java plugins. This research led me to deeper knowledge of the familiartechnologies used and also a basic knowledge of the new technologies introduced duringthe project development. The knowledge gain during the studies of the above mentionedtechnologies in chapter 2 gave me a better chance of actualizing my project with the fullyrequired functionalities.

The J2EE platform was proven to be a great platform to develop a well structuredand secured web application as the market. The Java server pages technology gave mea chance of retrieving data dynamically and to perform specific Java Servlet task suchas creating HTTP response in a more natural way. With the successful implementationof REST architecture on the communication phase of the project one can assert that, im-plementation of complex functionality of a web application and an auto update can beachieved using the above mentioned technologies and models.

28

Bibliography

Amber, Scott W. 2010. UML 2 Deployment Diagram. http://www.agilemodeling.com/-artifacts/deploymentDiagram.htm, accessed on September 1st.

ConnellyBarnes. 2012. Model View Controller. http://c2.com/cgi/-wiki?ModelViewController, accessed on September 1st.

Connolly, Dan. 2004, 09. Hyper Text Transfer Protocol HTTP/ 1.1. http://www.w3.org/-Protocols/rfc2616/rfc2616.html, accessed on September 1st.

Crockford, Douglas. 2008. JavaScript: The Good Parts. O’Reilly Media, Inc.

Data, Finnesand. 2010. Servlets Learning. http://w3processing.com.

Englander, Robert. 2001. Developing Java Beans. http://docs.oracle.com/javase/-tutorial/javabeans/index.html, accessed on September 1st.

Foundation, Apache Software. 2012. Multi-Processing Module. http://-httpd.apache.org/docs/2.2/mpm.html, accessed on September 1st.

Good, Nathan A. 2007. developerWorks. http://www.ibm.com/developerworks/-opensource/library/os-eclipse-tomcat, accessed on September 1st.

Graham, IAM. 1995, December. CGI documentation. http://www.utoronto.ca/webdocs/-CGI/cgi1.html, accessed on September 1st.

Hall, martin. 2000. Core Servlets and Java Server Pages. prentice Hall.

Java. 2012. GlassFish jersey. http://jersey.java.net.

JSON. 2002. introducing JSON. http://www.json.org/, accessed on September 1st.

Kruchten, Philippe. 1995a. “The 4+1 View Model of Architecture.” IEEE Softw. 12 (6):42–50 (November).

. 1995b, November. Architectural Blueprints. http://www.ics.uci.edu/ michele/-Teaching/INF117/Krutchtenaccessed on September 1st.

Liu, Henry H. 2009. Software Performance and Scalability. Hoboken, NJ, Wiley.

Mentor, Software Testing. 2010. Prototyping Model. http://-www.softwaretestingmentor.com/sdlc/prototyping-model.php, accessed on Septem-ber 1st.

Meyer, Eric A. 2000. Cascading Style Sheets: The Definitive Guide. 1st. Edited by RichardKoman. Sebastopol, CA, USA: O’Reilly & Associates, Inc.

Microsystems, Sun. 2012. J2ee tutorial. http://docs.oracle.com/javaee/1.4/tutorial/-doc/, accessed on September 1st.

Mills, Ashley J.S. 2005. JUnit Testing Utility Tutorial. http://supportweb.cs.bham.ac.uk/-documentation/tutorials/docsystem/build/tutorials/junit/junit.html, accessed onSeptember 1st.

29

Bibliography 30

Oracle, and affiliates. 2012. Creating a RESTful Root Resource class. http://-docs.oracle.com/javaee/6/tutorial/doc/gilik.html, accessed on September 1st.

Plus, Auto Update. 2011. Auto update plus. http://www.autoupdateplus.com/, accessedon September 1st.

PostgreSQL. 2012. PostgreSQL. http://www.postgresql.org.

Rodriguez, Alex. 2008. Restful Web services. http://www.ibm.com/developerworks/-webservices/library/ws-restful/, accessed on September 1st.

Sikuli. 2009/2010. The Sikuli project. http://www.sikuli.org.

Tech, NBD. 2010. Making time tracking software. http://www.nbdtech.com/-Blog/archive/2007/06/17/How-To-Write-an-Automatic-Update-System-Part-1.aspx,accessed on September 1st.

Tomcat, Apache. 2012. Apache Tomcat. http://tomcat.apache.org, accessed on Septem-ber 1st.

Vogel, L. 2012. REST with Java (JAX-RS) using Jersey - Tutorial.http://www.vogella.com/articles/REST/article.html, accessed on September 1st.

Wartiak, Rastilav. 2007. Performance Testing for Web application. http://-www.ksi.mff.cuni.cz/cs/bp/Example-Wartiak-WebStress-Thesis.pdf, accessed onSeptember 1st.

dube: a web application for the distribution and update of...

Documents