Developing an Enterprise Application

(1)

A case study

Utveckling av en företagsapplikation En fallstudie

Milos Bogdanovic Semir Huduti

Examensarbete inom information- och programvarusystem,

grundnivå Högskoleingenjör

Degree Project in Information and Software Systems First Level

(2)

(3)

Sammanfattning

Syftet med denna studien är att undersöka och identifiera tillgängliga teknologiska lösningar och tjänster för utveckling av en webbapplikation prototyp, baserad på en crowdfunding idé, för ett nystartat företag. Prototypen kommer att användas för att locka inverterare som är villiga att vidareutveckla prototypen. De grundläggande funktionaliteten såsom social inloggning, och ett användargränssnitt med fokus på statistik och en betaltjänst är implementerat i prototypen.

Projektet utfördes i tre huvudsakliga delar, en undersöknings fas, en utvecklins fas och dokumentations fas. Alla valen som har gjorts under projektets gång har övervägts med andra möjliga val under undersökningsfasen genom att ta fram för och nackdelar.

Avslutningsvis undersöker studien den slutliga prototypen som ett slutresultat, utvärderar designbeslut och lösnings val som har gjorts under forskningsfasen och rekommenderar eventuella tilläggs möjligheter för vidareutveckling. Studien förväntas kunna ge användbar information och en bra utgångspunkt för projekt som överväger att utveckla ett program som bygger på en crowdfunding modell eller ett Enterprise program med liknande teknologi.

Nyckelord: Java EE, PayPal, MySQL, cloud hosting, crowd funding.

(4)

Abstract

The aim of this thesis is to inspect and identify available technologies and services in order to develop a prototype web application, based on a crowd funding idea, for a startup company. The prototype is going to be used for attracting investments, for further development, and it implements essential functionality such as social login, and a user interface focused on statistics and a payment service.

The project was conducted in three main areas, a research phase, a development phase and a documentation phase. All the choices that have been made during the project have been considered with other possible solutions at the research phase by investigating the advantages and disadvantages of the solutions.

In conclusion, the thesis examines the web application prototype as a final result, evaluates design decisions and solution choices made in the research phase and recommends possible extension routes of the system for further application development. The thesis hopes to offer useful information and a good starting point for students that are considering developing an application based on a crowd funding model or an Enterprise application using similar technologies.

Keywords: Java EE, PayPal, MySQL, cloud hosting, crowd funding.

(5)

Terminology

Acronyms

SSO Single Sign-on

UA User Agent

SP Service Provider

IP Identity Provider

VPS Virtual Private Server IaaS Infrastructure as a Service SaaS Software as a Service PaaS Platform as a Service IoC Inversion of Control DAO Data Access Object DTO Data Transfer Object ORM Object Relational Mapping

(10)

(11)

1 Introduction

1.1 Background and discussion of problems

The start-up company has a vision of a crowd funding web application that is going to make it easy for football fans around the world to financially help their favorite clubs by donating a desired amount. This leads to the essential areas of the assignments that consist of creating a complex database, a payment service that can be used for crowd funding, a social login service and a viable hosting service for the web platform.

The primary objective of the platform is to have payment service that can be used to manage donations received. The donations will be initiated twice every year and will start a few months prior to the transaction window and end when the transaction window closes. A transaction window is the time where players are being bought by various different clubs.

Primary problems that can occur during the development of the project are finding a secure and sustainable payment platform for the donations of this crowd funding platform. An analysis had to be executed in order to look into various different providers that offer this service.

A data management system that could handle considerable amounts of data was essential for the system. The problem that can occur when designing the intended database is that the data that is required in the database is too large and to manually enumerate can consume a lot of time. Possible solutions to this problem are trying to find an open source database that can be used, however this will most likely cause additional costs if it is used commercially. It is important to be able to modify the data in the data store but when implementing a external data store the action will most likely not be available, this can cause a demand to have two separate database, one only for gathering information and the other for storing information associated with the web platform.

(12)

Hosting was also intended for the project, finding a suitable hosting service that can manage all the technologies that have been decided on can get difficult. A solution to this problem was trying to find as much relevant information about the various hosting services that can be used for this platform and ultimately pinpoint a suitable candidate.

The social network has in the last few years grown very large and giving users the possibility to login via Facebook, Google etc. will make the application more accessible. This has been taken into consideration when developing this web platform.

The questions that needed to be answered by the end of the project are:

 What are the benefits of social login?

 What payment services providers exist on the market and which would suit best for the prototype?

 What are the hosting possibilities on the market and which solution would suit best for the startup company?

These three questions are related to the core functionalities that needed to be added and answered by the end of the project.

1.2 Overall Objective

The overall objective of the project is to try to create a prototype for a web platform that that can be used for further development. There are some key components that will be part of the overall objective but the most important concern is to make all of the code reusable since these key components will be the essentials for the final product. Furthermore completing the system is impossible in the determined time interval.

In order for this project to be as beneficial as possible for the company a complete documentation is intended so that developers that will take over this project will be able to continue the development of the system with the least amount of time spent on trying to understand how the components are expected to be used. This will be achieved with a good set of comments in the program code, a javadoc that covers all the essential functions and a set of software documents that that explain the design principles, implementation patterns, system requirements, system deployment and finally the architecture of the system.

(13)

Also the security of the web platform is essential since the prototype will be dealing with payments and the liability of the fund transfers is essential, best possible solution is to make the web service responsible for the security in this instance.

1.3 Limitations

The following paragraph mentions aspects that have been limited to the project.

1.3.1 Time Limitation

This project had a pre agreed deadline data that could not be changed under any circumstances and was not only considered to be a limitation but also a risk.

1.3.2 Budget Limitations

Because of the low budget that this company has, a programing language that would not drive up the costs of the project would be the most suitable. This limited the amount of choices that could be used for the prototype.

The programing language was not the only limitation for the project; an open source relational database management system had to be considered too.

Budget limitation was one of the main aspects in choosing a hosting solution. Through research it has been proven that hosting an application in the cloud environment is most suitable solution for a startup company with limited initial budget. This will be discussed in more detail in the theory and methods chapter.

1.4 Delimitations

1.4.1 Testing Unit Testing

Unit testing has not been considered for this project because of the time

(14)

User Testing

Because of the confidentiality agreement no user-testing has been initiated for this project.

1.5 Concrete and Verifiable Targets

The project aims to complete the following components for the crowd funding web application:

 A set of components that can be used to manage payment transactions in a secure manner with a payment provider that supports the requested crowd funding model.

 All the transactions made have to be stored in the database since it is going to be used to track statistics.

 Social login. This component gives the users the ability to login with a social network account. This is an important aspect to in- corporate in the application and has been requested by the company.

 A data storage solution that can manage application data or an external service to can provide the needed data.

 All components that are produced during the project have to be well documented. This will be done in two different ways. A set of software documents will hold all the essential information about the design and architecture and a javadoc that explains the usage of the components.

 The project also strives to find a suitable hosting solution fits in the boundary of the limited budget.

1.6 Outline

This study will discuss a variation of different encounters in development of the system connected to a scientific evaluation. Primarily the study will evaluate the major benefits of having a social login system, implementation of payment services and hosting solutions for a web application in a scientific manner. The study will also discuss some other areas such as the implementation of the interface, data management, layered architecture and the deployment of the application.

(15)

The theory chapter will provide an overview of possible frameworks and solutions for the areas mentioned above, a few advantages and disadvantages with the possible frameworks are presented. With these advantages and disadvantages the conclusion of what frameworks are the most suitable will be further evaluated in chapter three, methods.

In the result chapter the results of the project will be deliberated, what was the outcome and project goals been achieved. The result chapter will be followed by the conclusions where the reflections of the project results are presented and what the effects and drawbacks of the project are, possibly even future works.

1.7 Writers contribution

This thesis has been done in the group of two students by Semir Huduti and Milos Bogdanovic. Both students have been working together on all of the parts of the thesis with equal contribution. Since company that proposed the project is in its start phase students did not work with help of the mentor from the company.

(16)

(17)

2 Theory

2.1 Social Login

Unless otherwise indicated, the text in the following section is based on infor- mation from [1]. [2], [3] and [4].

Most modern web applications of today have various techniques of authenticating users and there are many ways to accomplish this feature. The most common way of authenticating users is by having a logins system coupled with a database, however this technique has been proven to fall out of favor and a more modern login technique called single sign-on is the most favored by users according to a research provided by Microsoft. [1] The research mentions that a 77% of the web applications users prefer the SSO technique over any other login technique.

The web single sign-on technique is a technique that enables the user to access any web application that provides SSO through an already existing account such as Facebook or/and Google. This removes the hassle of the user having to fill out registration forms, and given the fact that social network sites such as Facebook and Google are being used by a big portion of the people with access to internet will greatly improve the amount of users that are willing to log in.

The SSO authentication process has three parties involved when authenticating a user. The parties involved in this process are the user agent (UA) on the client side that is operated by the user via the browser, the service provider (SP) is the web application that offers some sort of service and the identity provider (IP) that is used by the web application for authentication of users. The IP service is not part of the web application itself but is rather an external integrated service. [2]

A typical scenario on how this SSO technology would be utilized in any SP that provides this technique would most likely start of by the UA trying to access restricted resources that the SP yields. If the restricted

(18)

IP where the UA can provide login information and confirm his/her identity. If the UA identity confirmation was successful the UA will be redirected back to the SP and have access to the resources that have been requested in the initial steps. This is being illustrated in a sequence diagram in figure 2.1.

Figure 2.1 Single Sign-On interactions. (Reference: [3])

An open source project that has devoted time into making a SSO system that is easily implemented in any web application is called OpenID and has support for various different sites such as Facebook, Google, Yahoo, AOL, PayPal and many more. An integrated part of the OpenID connect system is the OAuth service that gives the user the ability to access and modify content on the IP platform. A more concrete example would be a user that modifies his Facebook wall through clicking a link on the service provider site.

(19)

An open source project that has devoted time into making a SSO system that is easily implemented in any web application is called OpenID and has support for various different sites such as Facebook, Google, Yahoo, AOL, PayPal and many more. An integrated part of the OpenID connect system is the OAuth service that gives the user the ability to access and modify content on the IP platform. A more concrete example would be a user that modifies his Facebook wall through clicking a link on the service provider site.

Figure 1.2 Social Network Statistics (Reference [4])

Figure 1.2 displays the most popular social networks. This should be taken into consideration when implementing the social login service.

(20)

2.2 Hosting

There are several possibilities available on the market for hosting web application such as shared web hosting, VPS, dedicated hosting, in- house hosting, cloud hosting etc. There is a certain difference in how these services are implemented in terms of sharing server resources with other web applications or virtual environments and the amount of resources that they offer. Some of the hosting solutions are listed below.

2.2.1 Shared Web Hosting

In shared web hosting model hundreds, even thousands, of web pages share the resources of the same physical server. All web pages share same software stack which is somewhat limiting because providers build servers with only most popular and widely used languages in mind. This model is more suitable for static web pages, blogs, and small businesses.

2.2.2 Virtual Private Server

VPS hosting model is also a shared resource model where tens of VPS’s share the resources of the same physical server. A portion of a physical server’s resources is sold as a virtual machine with super user access.

This model does not have any software restrictions as the customer is responsible for providing and maintaining a software stack needed to run the application. Big downside of VPS hosting model is the fact that the resources are shared between numerous VPSs and a possible issue with some other VPS, on the same physical server, can cause the server to crash resulting in application downtime. The VPS infrastructure is illustrated in figure 2.3.

(21)

Figure 2.3 VPS infrastructure.

2.2.3 Dedicated Hosting

Dedicated hosting is a hosting model where hosting provider rents the entire physical server to the user. Hosting provider owns and maintains server, hardware wise, while the user has absolute control over operating system and the software stack. Using this model offers great amount of resources, high performance and security. Monthly costs are relatively high and that is why this model is mostly used by resource demand- ing web application with large volume of traffic. Beside relatively high costs a downside of this model is a single point of failure. Server can crash during the peak hours of usage due to the lack of resources or due to some other issue which causes application downtime.

2.2.4 In-house Hosting

In-house hosting model is somewhat similar to the dedicated hosting model with a difference that customer buys, owns and manages the

(22)

ment. Like dedicated hosting model in-house hosting offers lots of resources, processing power and security but it has some downsides.

Hardware is expensive and there is need of expertise for setting up and configuring the server. After the initial investment there is a fixed monthly cost for electricity, broadband and maintenance.

Furthermore this model is not scalable. In order to scale vertically new hardware components need to be added to the system, as illustrated in figure 2.4, while horizontal scaling requires adding new physical servers to the setup as illustrated in figure 2.5. Adding or changing hardware, software and security updates require downtime. Since there is a single point of failure there is risk that server can crash during peak hours which can result in long downtime.

(23)

Figure 2.4 Vertical Scaling.

Figure 2.5 Horizontal Scaling.

2.2.5 Cloud Hosting

According to National Institute of Standard and Technology (NIST) cloud computing can be defined as follows:

Cloud computing is a model for enabling ubiquitous, convenient, on - demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal

management effort or service provider interaction. [5].

(24)

Figure 2.6 Cloud Computing.

The overview of the cloud computing model can be seen in figure 2.6.

There are three major models of services sold by cloud providers:

 Infrastructure as a Service(IaaS)

 Software as a Service(SaaS)

 Platform as a Service(PaaS)

IaaS. The customer is provided with fundamental computational re- sources and is able to deploy and run arbitrary software. The customer does not manage underlying cloud infrastructure but has control over the software stack.

SaaS. The customer is given the ability to use provider’s applications running in the cloud. The applications are accessible through various devices either using browser or a thin client. The consumer does not have any control whatsoever over the cloud infrastructure or the application itself.

(25)

PaaS. The customer is given the ability to develop, test, run and deploy a customer made application onto the cloud using the software stack supported by the provider. The customer does not have control over underlying cloud infrastructure but has control over deployed application and can configure developing environment.

Some of the characteristics of cloud computing are:

 Computing and storage resources are available and supplied on- demand as needed without human interaction.

 Cloud computing offer rapid elasticity. Additional resources are allocated and released when needed and in some cases fully au- tomatically. All of the cloud platforms offer horizontal scaling while some of them offer vertical scaling as well. It appears to customer as there is unlimited amount of resources at any time.

 Different cloud providers have different pricing models but the general idea is that customer pays only for the amount of resources used.

 There is a huge variety of measuring and monitoring tools of- fered which comes in handy for monitoring and controlling resource usage.

Possible candidates for a cloud hosting solution are Amazon and Jelastic primarily because the support containers needed in order for the application to run successfully.

2.3 Payment Services

Unless otherwise indicated, the text in the following section is based on infor- mation from [6].

A major component for this web application is the underlying payment service. It is used for managing the donations in the crowd funding model that is intended for this web application. During the research phase of the project three reliable providers have been discovered that had support for crowd funding services.

(26)

The three payment service providers found were Stripe, WePay and PayPal. All of them imply a good API that covers most of the needed tools for development of crowd funding web applications.

An important aspect of a crowd funding application that has a underlying payment service provider is to make sure that the payment service providers policy for crowd funding is well elaborated and will not cause any complications. As of march this year PayPal has revisited the policy for crowd funding applications to increase the reliability and security but also make sure that crowd funding platforms do not get their accounts frozen. Some of the major crowd funding platforms that worked closely with PayPal got their accounts frozen and caused a lot of trouble and confusion but this issue has been addressed as of the last revision of the crowd funding policy. [6]

The service that is to be used for this crowd funding application needs to have a model that can support crowd funding the way it has been requested by the project proposers. The model that is set up for this crowd funding web application can be quite complex, not all the initiated donations will be committed. There is a set of constraints that need to be fulfilled in order to commit the transaction. This can make the implementation of payment service that is to be added to the system very complicated.

One of the goals for the company is for the applications to be used globally so possible restrictions that this payment services have need to be taken into account, such as WePay and Stripe that have country restrictions.

All payment services that had been mentioned so far have transaction fees associated with them. These transaction fees may vary depending on the provider, for instance PayPal has a more dynamic approach to the transaction fees. The transaction fee is greater if the donor donates a less amount and decreases the higher the donation goes. WePay and Stripe have a more rigid approach which means the transaction fees remain the same no matter how big or small the donation is. The transaction fees for PayPal vary from 3.4% + €0.35 for the for the smallest donation amount to 1.9% + €0.35 for the biggest donation. The transaction fees for Stripe and WePay are the same, which is 2.9% + €0.22.

(27)

These payment services may have a certain transaction limit. This means that the donors only can donate a limited amount of money. For instance PayPal users can donate up to $10,000 whereas none PayPal users have a transaction limit dependent on the currency. As far as WePay and Stripe there were no limits mentioned

There are a lot of pros and cons with all available payment services that have been mentioned so for. For example the WePay payment service as a very easily integrated API that doesn't redirect the user however it has other flaws such as country restrictions.

2.4 User Interface

Unless otherwise indicated, the text in the following section is based on infor- mation from [7], [8], [9] and [10].

JSF and JSP are the two technologies that have been considered for the user interface. These two technologies are both used in the context of web based user interface. JSP works with servlets and JSF is a XML- based tag library. The benefits of JSF are that a lot of the core functionality features are included but it is possible to extend with additional libraries for more user interactive and rich web components.

JSP is the older technology compared to JSF. The code is written in Java servlets and in order for it to work properly the servlet needs to be compiled, if any changes are done to the servlets the servlet needs to be recompiled. The great benefit of JSP is that the Java code can be directly embedded into HTML code in JSP.

The JSF pages are manage by so-called backing beans. The backing beans are used to manage the data that is sent from and to the web user interface. These beans can have methods that are called whenever the user presses a button or performs an action. Recommended layered structure for JSF is the MVC pattern, where the view layer will consist of backing beans and JSF pages.

The validation user input is a vital point in the construction of user

(28)

validation of the input can be handled on both the client side and on the server. If there are a lot of requests on the server, client-side validation can be to great benefits since the user will not be redirected to any page if the client-side validation fails. There is still the need for the server to validate any input but the amount request against server will be reduced significantly if a client-side validation is implemented.

JSF has the ability to create composite components [8] ; these components are basically components that are written by the developers. This can be useful in situations of certain code is repeated among several pages, using these components will lead to a reduced complexity of the system.

Furthermore, another great feature that JSF provides is the possibility to create template layouts [9] easily by using some of the included libraries.

The template will contain all the components that are repeated amongst all the pages in the web application to avoid rewriting the same code.

During a discussion of the possible solutions for the user interface a decision has been made to extend the default user interface components with an extended library that has richer user interactive components.

Primefaces is an extended library that has a lot of useful components that could be useful in this project; however this extended library does not have any support for JSP. [10]

2.5 Data Persistence Framework

Unless otherwise indicated, the text in the following section is based on infor- mation from [11] and [12].

Data persistence frameworks provide a layer of abstraction between the application and the database. This way the application is being separat- ed of underlying database technology and the mechanisms for storing and retrieving data from the database encapsulated. Persistence frameworks implements Object Relational Mapping technique that persists application objects to data tables in relational database. The aim of the persistence frameworks is to simplify the development process by encapsulating persistence logic. While there is various different persistence frameworks following two emerge as a more popular and widely used:

(29)

 Hibernate. This is an open source, lightweight ORM solution which uses XML file to map a database tables to the application objects. Metadata is mapped to an XML file which then takes care of mapping right table from a database to the right class in the application.

Hibernate introduces Hibernate Query Language a powerful fully object oriented query language. Results returned by the queries are objects ready to be used by the developer.

Hibernate supports various databases from most of the vendors.

Since different databases use different dialects of SQL language Hibernate introduces “dialect” property in a configuration file.

This property can be changed in case of changing the database which makes Hibernate quite versatile. [11]

With its very simple API Hibernate is very attractive for developers that don’t have sharp SQL skills.

 Java Persistence API. JPA is the specification that became standard in Java EE 5. The general idea behind JPA is to make a unified standard API for persistence in Java applications. It incorporates ideas and solutions from all top persistence frameworks and is supported by major Java vendors.

Since JPA is a persistence interface it needs a implementation of a persistence provider to be used. This is one of the JPA strong points, it provides unique platform where any persistence provider can be plug in to it.

JPA uses metadata annotations and XML descriptor file to provide mapping between application and database. Tables from a relational database are being mapped to entities in application domain which are Plain Old Java Objects.

JPA introduces Java Persistence Query Language a SQL like que-

(30)

2.6 Application Server

Unless otherwise indicated, the text in the following section is based on infor- mation from [13] and [14].

During the research phase various different deployment framework solutions have been evaluated. In previous projects the development team have been working with glassfish and found it to be working properly, however for this project the development team want to evaluate the possible solutions for the deployment framework in a greater manner and discuss in more detail what would be the most beneficial approach.

Two possible candidates have been assessed, Glassfish and TomCat. The superb fact about TomCat is that it is a lightweight server container, however the requirements if that are intended for this project may not be possible to accomplish with TomCat. Glassfish on the other hand is not as lightweight as TomCat but has a greater support for what is intended for this project.

A decision had to be made based on what technologies will be used for this project but also keep trying to keep the application server as lightweight as possible since a application that is not lightweight will most likely will lead to increased costs when looking from a hosting perspec- tive.

In order to run a glassfish deployment framework it is not enough to have the Java Runtime Environment but the system needs the Java Development Kit compared to TomCat that only needs Java Runtime Environment in order to properly function. Both these frameworks are written in Java and they are both meant to deploy Java applications. The biggest difference amongst them is the support that these frameworks offer. TomCat only supports servlets and standard JSP whereas Glass- fish has complete support for Java Enterprise Edition version 5 and 6.

Administration for the deployed project can sometimes be very neces- sary and Glassfish has a more diverse approach for the management of projects with the graphical user interface in the admin view. [13]

(31)

Since TomCat is a more lightweight approach it is faster to load but it takes a longer time to redeployed existing project. Glassfish on the other hand has a faster the load time. When it comes to performance both the systems have a somewhat similar performance. [14]

2.7 Multilayered architecture

Unless otherwise indicated, the text in the following section is based on infor- mation from [15], [16] and [17].

Multilayered architecture is a software architecture widely used in development of web applications and applications with user interface.

The general idea behind designing the web application in a layered fashion is decomposing the software components into logical groupings called layers. Components are divided into layers according to the different kind of tasks they perform making it easier to design the application to support reusability of components. The application that is divided in layers with distinct roles and functionalities is much easier to maintain and to optimize the way it works. [15]

An application can consist of a number of different layers and sub layers but the most common three-layer [16] architecture that illustrated in figure 2.7 and consists of following layers:

 Presentation layer. This layer consists of components that imple- ment and display user interface and manage user interactions.

 Business layer. This layer implements the core functionality of the system and encapsulates business logic.

 Data layer. This layer provides access to the data sources such as database or external resources perhaps accessed via services.

Besides deciding what layers are needed in a particular layered design and dividing the components to different layers one of the main steps are determining the rules of interaction between layers. The main reason for this is minimizing dependencies between layers and eliminating circular references. To achieve this, one of the following approaches [17]

can be used:

(32)

 Top-down interaction. Higher level layers can interact with layers below while lower level layer never interacts with a layer above.

 Strict interaction. Each layer interacts only with a layer directly below. Direct benefit of this approach is that making changes to the interface of the layer only affects the layer directly above since the above layer only knows and interacts with the layer directly below. This approach is often used for designing applications that are often going to be changed to add new functionality etc.

 Loose interaction. Higher level layers can bypass layers to interact with lower layers directly. While this approach improves performance it increases dependencies at the same time. Making changes in the lower layers can affect multiple layers higher up.

Figure 2.7 Layered Structure.

(33)

2.8 Software Development Methodology

Software development methodology is a framework used to plan, structure and control the process of software development. There is a wide variety of project development methods that has emerged through years. The evolution of different methods has been driven by the need of more suitable method for a typical project and not necessarily every method suits for every type of a project.

2.8.1 Waterfall method

Development is divided into several phases: requirements analysis, design, implementation, testing (validation), integration and maintenance. These sequential phases are flowing steadily downwards appear- ing as a waterfall and can somewhat overlap each other.

This is the most traditional software development approach and is most suitable for large projects and development of huge informational systems. It is not flexible and not appropriate for the projects where requirements can change over time. Historically it has been blamed for running over budget and time and sometimes failing to deliver requirements.

2.8.2 Incremental Development

The main idea behind this approach is to reduce project risks by dividing the project into smaller segments providing the flexibility and ease of change.

All waterfall phases are performed on segment of the system before proceeding to the next increment. In other words every single segment is analyzed, designed, implemented, tested and then it can be incorporated to the existing system. This way the new functionalities can be incorporated even in the later parts of project and flexibility to requirements changing is provided. There are several different variations of incremental development and all are based around same idea.

(34)

(35)

3 Methodology

3.1 Development Environment

In these following paragraphs a brief summary on the development environments will be discussed.

3.1.1 Windows 7 Professional/Ultimate

The system is developed in two, more or less same operating system. It is not required to develop in a specific operating system since Java is cross platform and works on pretty much on any operating system.

3.1.2 NetBeans 7.4

The integrated development environment for programing with Java is done with NetBeans as a result of the great deal of functionalities it provides and an exceptional project management system. It also has a great support for revision control with GitHub that is easily managed.

3.1.3 MySQL Workbench 6.0 CE

The relation database management system for the project is MySQL Workbench 6.0 CE and at the time this report is written MySQL is the second most used database management system in the world [18]. It is considered to be production quality and is easily implemented.

3.2 Development Method

For development of this prototype web application an iterative and incremental Development method is used. Basic idea behind this method is to develop the system incrementally allowing the developers to take advantage of what is being learned through developing and using earlier incremental deliverable versions of the system. The first step in using this technique for development is to choose and implement the

(36)

the system. At the remaining steps the current implementation is iteratively enhanced adding new features and functionalities to each following version until the whole system is implemented and the requirements are satisfied. Each iterative step consists of choosing next functionality, designing the implementation of the selected functionality, coding and debugging the implementation of the functionality and performing the analysis of this partial implementation developed at this iteration.

Since one of the intended non-functional requirements is that the system needs to be scalable and another is to develop reusable components it is decided to use the well proven MVC logical layered model. First thing, after making the architecture of the whole system was to identify the key functionality. These were going to be the skeleton when developing and putting together all layers. Once all layers were in place and could communicate, other functionality is implemented and integrated to the existing implementation iteratively.

Project is divided into two week long iterations. In each iteration a new functionality is introduced. After each iteration a meeting with the stakeholders is conducted revising the past iteration and planning the new one with a possibility to add new requirements. Key parts of the system that form the skeleton are social login, data storage and payment functionality.

In first iteration database and a social login is developed. Second iteration is dedicated to developing payment functionality. After two iterations the core skeleton is in place and new functionality can be incre- mented. In third iteration various user views are developed connecting all parts together, making user able to view statistical data about player, club, league, country etc. and connecting the user choice to the payment functionality. In fourth and final iteration administrator functionality is developed which makes it possible to manage various data in the database.

3.3 Design Method

(37)

Throughout the early days in the development of web applications there was no significant standard that developers followed in order to get a robust application that will have a low coupling that enables the application to add additional functionality without any major difficulties because of the way the different layers are connected, this connection is often referred to as Inversion Of Control (IoC). [19]

The MVC model is usually a three tier layered architecture that consists of Model, the main container for the structure of the data, View that is used to present information to the user and Controller that is used for communication and executing the business logic.

3.3.1 Model

Model is used to represent the different types of data that is being processed by the controller. It consists of entities that are generated from the database and each entity represents a table in the database. The variables in the entities are private and relate with the columns in the database. This is commonly used with JPA and will be discussed in a later section of the document.

DAO (Data Access Object) are used to manage data from the entities in a more simple and efficient way by defining methods to access specific information from the database using Entities and the Persistent Unit with JPA. Further development of the system might require a non-web based implementation of the admin panel and having DAO objects to access data will be to a great advantage because the interface declared by the DAO object is a lot clearer than working entirely with Entities.

[20]

In some cases transferring partial data is required since all the information to create an entity instance is not available. In these cases using the defined DTO (Data Transfer Object) can be advantages.

(38)

3.3.2 View

The View in the MVC model is used to represent the data granted by the Model to the user. The representation of this data is done with JSF and Backing Beans. The JSF is converted to a HTML presentation and the Backing Beans are used to gather information from the view and render an appropriate response with the information that is sent from the Controller.

3.3.3 Controller

The business logic is handled in the controller and all the processing of information from the user is done in the Controller. The methods in this layer are usually triggered by an action initiated by the user. The Controller has a relation to the Model and the View has a relation to the controller but there is no relation between the Model and the View hence why the user can't access the business logic.

3.4 Frameworks

3.4.1 Facebook

When it came down to what would be the most suitable implementation for the social login that was requested by project proposers the development team had decision that implementing openID would immensely increase the risk of missing the deadline and openID was not within the boundaries of the project scope, what was requested by the project proposers was the ability to login with a social network. The social network that has been decided on was Facebook.

Reasoning behind choosing Facebook as the social login for the SSO implementation is because Facebook has the most active users at the time this project is carried out.

The implementation of the integrated Facebook login system is fairly easily executed with the help of security servlets, a managed bean and the view. The security servlets takes care of the conversations between our web service and Facebook.

The parties involved in a SSO implementation have previously been reviewed; now a more concrete approach will mention who exactly these parties are. The user agent (UA) is the system end-user that is

(39)

trying to access resources on the web application. The service provider (SP) is the web application that has a set of resources available but these resources are restricted, only when the user is successfully authenticated will the resources are available. The identity provider (IP) is Facebook in this instance; Facebook identifies the user that tries to access the restricted resources. If the authentication is successful the user agent will be redirected to the SP with the access to all the requested resources available.

The restricted resources in this case are the ability to donate. While the requirements of the system are to only allow users to donate if they have successfully been login with Facebook. This is being solved by having two rendering options for the donation bar. The default rendering asks the user to login with Facebook along with a Facebook button next to. If the user successfully connect with Facebook this donation bar will be re-rendered. The new view will grant the user the ability to donate.

3.4.2 PayPal

A set of possible payment services has been reviewed in the theory chapter, based on these theories a payment service needed to be selected. PayPal is the dominating option in all researched areas and has been chosen as the payment service that is going to be implemented.

PayPal provides two fundraising models, parallel payment and chained payment. The primary difference of the two models is the flow of the funds. According to PayPal the chained payment, illustrated in figure 3.2 offers a more robust solution since the payments are first sent to project owner. Then the project owner can send the funds to any third party contributors that are involved within the project. [21]

The parallel payment model is a used in cases where the funds are being sent to all parties individually as illustrated in figure 3.1.

(40)

Figure 3.1 PayPal parallel payments.

The business flow model describes in what way the funds are being processes. A potential solution for this is by implementing pre-approved payments. This is the most suitable for our project and is build up around the fact that no money is being charged until some constraint is being approved. When the project owner approves the constraint the pledged money is donated. The primary reason for why this is the most suitable for this project is that no fees are being charged for donations that are not being approved, however the downside to this solution is that if the pledged amount is not available at the time when the funds are being collected no money will be charged. Using this solution makes it possible to achieve all specifications acquired without having to store any sensitive information, therefore improving the security of the system.

(41)

Figure 3.2 PayPal chained payments.

PayPal is always going to fee for transactions that are committed and a certain cut of the entire portion of funds the primary receiver, the company in other words get is going to be collected by PayPal as well as to the project owner. In a chained payment scenario the project owner will collect all the funds and send back a portion of the funds. The project owner has the decision to pay PayPal for the transaction fees or make the third parties pay the transaction fees. The other alternative is to have a parallel payment and predetermine how the fees will be charged. The best possible solution is to have a chained payment where company takes the agreed percentage and then send the remaining funds to the secondary receiver, the clubs in this case. In this model the clubs will have to pay the PayPal fees and the transactions are handled by PayPal.

3.4.3 JSF and Primefaces

Although it may be easier for developers not familiar with web-based user interfaces to use JSP it is important to acknowledge that this is a prototype. Additional functionality and extensions will be added in future development of the project, so with that in mind JSF might be the better solution.

Because Glassfish is the decided as the application server an extended

(42)

plished. JSF is used to present data in a user-friendly manner. The JSF code gets translated to HTML; this makes it possible to view the UI in the browser.

JSF provides a basic taglibs with a set of XML tags used as the most common components, such as an output text field, input text area, input text you etc. It is also possible to include raw HTML code; this will not cause any errors. Furthermore it is possible to extend the amount of components with additional libraries. The project has been extended with a set of libraries but the most noticeable is called Primefaces, this library will be discussed in more detail in the coming paragraphs.

JSF provides the possibility to create composite components and predefined layouts. The composite components are components that may be used in several pages, it is unnecessary to rewrite the same code in multiple pages. This will make the code a lot easier to understand and maintain which is great when developing a prototype that might extend functionalities. The composite components will reduce the complexity of the system. The predefined layouts are basically a template for all the components that are repeated amongst all the pages, such as the header, footer, dynamic menu etc. At that point it is possible to rewrite parts of the UI and leaving everything else the same as in the layouts. As well as the composite components the predefined layouts will also contributes to a less complex code.

Another reason for why JSF is according to the developers the right decision for this project is that it is a standardized Java framework that that is easily linked up with the intended MVC pattern. Besides that it is the newest framework used for component-based web interaction.

Our early intentions were to include an extended JSF library called Primefaces. This library has extensive amounts of rich web-based components. Such is the dynamic menu that is used across all the pages.

This makes the page more alive and improves the user experience because all the easy interacting components.

The set of components the Primefaces provides can be found on the showcase site for all the components can be previewed.

(43)

3.4.4 JPA

Choice of object-relational mechanism depends a lot on underlying database and the needs of the application. Since the relational MySQL database is going to be used, this is not going to be problem for either Hibernate or JPA, both are compatible. Even if the database changes during the application lifecycle Hibernate has the versatility to adapt to various SQL dialect and JPA only cares about the persistence provider below.

Choosing Hibernate for the application is going to be bound to third party vendor specific ORM solution while JPA provides a more generic persistence mechanism that still needs a persistence provider plugged into it. From the point of view for future development a more generic and flexible solution is desirable. Choosing JPA as a standardized Java API opens more possibilities since it can be incorporated with almost any persistence provider getting best from both worlds.

Taking into account the team’s familiarity with JPA and project time constraint the decision is made to proceed with JPA and EclipseLink as persistence mechanism since EclipseLink is the default persistence provider for Glassfish, application server that is being used. This way there is no need for installing and configuring external software and it has been proven through various benchmarks that that chosen combina- tion shows similar performance results as JPA together with Hibernate.

[22]

3.4.5 Glassfish

As mentioned earlier a decision about what deployment framework was the most suitable for this project. After considering the advantages and disadvantages of the two deployment frameworks, Glassfish and TomCat, the decision is made to continue the project with Glassfish.

The main reasoning behind this is the intention to work with EJB and JSF, these feature are mainly supported by Glassfish. Technically it

(44)

The biggest problem with Glassfish is finding a suitable host that could handle the required resources that glassfish needs. As soon as Amazon has been selected as the web host Glassfish became the obvious option for the application server.

The performance of the system is obviously very important and as mentioned before performance difference is very minimal. The benefits of running a Glassfish deployment framework are greater than the benefits from TomCat. Glassfish allows us to use JSF, the benefits of this is the possibility of integrating a richer web application with the help of the components that are provided by Primefaces.

3.5 Data Management

Since this project is just a prototype a relational database seemed to be the best solution and MySQL has an exceptional way of handling relational modeled data stores and it is also open source which means that the implementation of MySQL would be free of cost. This comes to great benefits to the company because of the limited budget for this project.

The design of the database is normalized to 3NF, what that means is the all the table values are functionally dependent to the primary key in the database and there is no redundant information amongst the tables. [23]

More information about the structure and the layout of the database can be found in the “Software Design Document”.

3.6 Hosting Method

One of the most important questions that emerge in the process of analyzing and developing startup web application is how is application going to be hosted? There are few facts that need to be taken in to account while searching for the answer of the mentioned question:

(45)

 Since the employer is a startup company the overall cost of hosting and specially the initial startup cost need to be as low as possible.

 The application is meant to be used worldwide and there is high possibility that number of users is going to increase constantly during the first year, resulting in higher workload and traffic size.

Increased growth rate is directly proportional with the amount of resources needed for hosting the application.

 Business idea of the company depends on end users and their ability to interact with web application so high reliability and uptime is essential.

 Application usage is going to peak during two shorter periods of the year and the rest of the time resource demand is going to be low.

Both shared hosting models are not considered as a possible solution due to the lack of resources and the risk of possible downtime.

Dedicated server and In-house server both offer great amount of resources and security but fail to comply with some of the points above.

Both are pretty costly solutions which greatly raises initial investment for the startup company already running on a tight budget. Furthermore there is the issue of estimating the amount of resources needed. How much resources are needed for startup and how much resources are needed in the future, taking into account application usage, growth rate.

Having too little resources results in less users that can interact with the application. Having too many resources results in unused resources and wasted money. From the periodical application usage peaks time intervals point of view there is the issue of covering all demands during peaks and resource waste during rest of the time.

Hosting in the cloud offers solution to most of these problems. Using this solution greatly reduces setup, deployment time and costs in initial phase. Furthermore cloud rapid elasticity offers the solution to the issue

(46)

released so that there is no waste. The customer is only paying for the amount of resources being used. In addition to this there are monitoring tools available that can be used for resource monitoring and estimation of resources needed in the future. On top of that cloud provider offer over 99% uptime guarantee which means that application is going to be highly available and there is no single point of failure.

Since cloud hosting solutions offer most benefits for this web application and the startup company it appears as the most natural solution. There are a set of possible cloud providers but the decision is made by the project proposers to proceed with Amazon. Amazon is one of the pioneers in cloud computing and it offers a complete platform that the company feels most secure with. Furthermore there are reducing prices for their services on regular bases.

3.7 Risk Management Methods

In the initial stages of the project, a meeting with both the project proposers and the project owner/project manager has been conducted discussing various risks concerning the project. These risks were well- defined and documented in the project plan document followed by possible solution on how to overcome these risks.

Time constraint is one of the risks that had to be managed; this risk has been handled with an incremental and iterative approach where new functionality was added in each iteration. This ensured that at least some parts of the system will be done by the end of project if not the entire system. Obviously we would aim to complete all the tasks that have been set in the project definition but the likelihood of this happen- ing was low.

Since none of members in the development team have ever implemented payment functionality in a system this is treated as a possible risk for this project, however this is a mandatory feature that needs to be working by the end of the project. Not completing this aspect would lead to a disaster. In order to solve this the development team engage this problem as soon as possible this way the probability that this scenario might occur would be put down to a minimal level but adding additional functionality that has been requested would suffer.

(47)

As well as the implementation of payment functionality there was no knowledge in the hosting of web application so this was also a risk. The development team has decided to deal with this possible risk by dedicat- ing more time in the research phase on how hosting in general works.

The lack of skill is also considered to be a risk. A lot of the functionalities are new to the development team. This risk is handled by identifying the critical parts and addressing them as soon as possible, since there are a lot of people at the University that might have extended knowledge in these areas assistance in these areas could be requested.

The project proposers do not want any information about the project to be published on the network. This is considered to be a risk but it is managed by making it so that the written report is not to be published publicly and that no names will be mentioned in the report. If somebody would want this report the actual prints would be available at the University.

Being able to manage all the possible risks in the manner as it was decided is a great benefit, all the risks is identified very early on in the project this gave the members of the company some time to think of possible solutions.

3.8 Documentation Methods

The documentation was another essential part affected by the part that the system that is being developed is a prototype and further development will be initiated when the system is handed over the a new development team.

Five important areas are documented in the set of documents provided with the software and appended to this rapport.

 The software requirement document discusses some of the required parts for the software and project.

 The software architecture document evaluates on the system architecture and the structure of the system in general.

(48)

 The software design document discusses the design of the system in terms of program structure and database design although it mentions other design aspects too.

 The software implementation document explains the implementation patterns for the applications. A vital area to discuss since new developers might continue working on the prototype and knowing the patterns that have been used in previous revision will keep the system standardized.

 The deployment document explains how to run the system on a server and what is required from the server.

3.9 Step-by-Step Progress

This subchapter will briefly cover sequential process for the project.

3.9.1 Evaluation of Requirements

When the developers have come in touch with the project proposers and explained to them that they would like to be part of the project a meeting has been requested. During this meeting the project proposers have been talking about some of the system requirements. As the developers read through the requirements specification theories of how the system could be implemented have been mentioned. No set decisions have yet been made.

After that meeting the developers decided to write the project definition where the project details were specified. This project definition documents mentioned various different topics such as problems/opportunities, project goals, project objectives, project scope, key stakeholders, success criteria and possible risks. This document made it very clear for both the company and the developers what was possible and what were the risks with this project.

3.9.2 Research and Design

The research phase was followed by the evaluation of requirements. In this phase the developers invested time on evaluating the advantages and disadvantages for all the possible frameworks. This gave the developers a better understanding of what would be the most relevant

(49)

decision for the project, since they were also responsible for choosing the majority of the implementations for the project.

Some of the decision the developers made instantly affected what would be the most convenient for another framework, for instance as mentioned before the decision for the layered structure was the MVC pattern for this project and the best UI framework was JSF since they interact well together.

Once most of the decisions have been made the developers started thinking of the design of the system and how it would be structured.

During the design the developers made several UML diagrams and a Database Relation Model.

3.9.3 Programming

After the research and design was successfully completed the breaking down of what the hardest parts to program would be to implement. The two components that were considered to be relatively hard to program were the social login and the payment service so we aimed to get these two components finished as soon as possible, starting with the Facebook login system.

This technique of handling critical parts of the system has ensured to successfully complete these components. The first two weeks of programming the developers have managed to get both the payment module and the social login service to work. Incrementally new functionalities have been added.

3.9.4 Testing

During the testing phase the developers were basically testing all the components that have been produced so far. Some of the components are harder to test in a real life scenario, much like the payment service so the developers did the next best thing with a sandbox that PayPal provides. This sandbox interaction is basically setup with a few test accounts that had some balance and the developers would test if the API calls would move the money around as it is intended.