Project Synopsis

Project Title
Database and Service oriented framework for supporting / powering large volume of data

Project Category NNdfdf
Web Services

Location of Implementation Sardar Patel Institute of Technology,
Munshi Nagar, Andheri(W),
Mumbai-400 058 Mumbai-400 058

Number of Team-Members

2

Project Description
This project is aimed at efficient accessing of a service oriented framework for supporting a voluminous database. This database is a large media database which would provide the client with media files using these framework services. The performance of these services is improved by adding caching mechanism to the system.

Languages Used
C, Memcache utility & library, PHP.

Abstract

Nowadays, efficacious accessibility of data stored in large databases is a major aspect of any system which needs to access data stored in such databases especially over the web. In this project report, we first study an existing service oriented framework for supporting a voluminous database created by Mime360. This database is a large media database which would provide the client with media files using these framework services.
The main purpose of this system is to provide accessibility to media files efficiently and only to the authorized users. One of the major quirks in this proposed system is its caching mechanism that will improve the performance of the existing framework.
In this report, we demonstrate the services provided by the system and the type of architecture suitable for such a system i.e. the service oriented architecture. We also illustrate the critical aspects supported to speed up the process of efficient retrieval of data, scalability and fault tolerance used to implement such a system. Lastly, we purport the requirement of various technologies used to create such an efficient system.

List of Figures and Tables:

Figure 4.1: Service Oriented Architecture Table 4.1: Comparison of REST API technologies
Figure 4.2: Mime Architecture Table 4.2: Comparison of Database technologies
Figure 4.3: Load Balancer Table 4.3: Comparison of Web Server technologies
Figure 5.1: Component Diagram Table 8.1: Testing
Figure 5.2: Activity Diagram Table 9.1: Project Time Line
Figure 5.3: Sequence Diagram (Cache Miss) Table 10.1: Task Distribution
Figure 5.4: Sequence Diagram (Cache Hit)
Figure 6.1: Revised Mime Architecture
Figure 6.2: Memcached Diagram
Figure 7.1: Snapshot for adding object to cache
Figure 7.2: Snapshot for retrieving song object
Figure 7.3: Snapshot for retrieving album object
Figure 7.4: Sample XML file for song
Figure 7.5: Sample XML file for album

Table of Contents
i. Project Synopsis ii. Abstract iii. List of Figures and Tables
1. Overview of Project............................................................................................... 01 1.1 Existing Systems.......................................................................................... 01 1.2 Critical Aspects............................................................................................ 01 1.3 Design and Analysis........ ........................................................................... 01 1.4 Implementation, Integration and Testing..................................................... 02
2. Introduction and Motivation............................................................................... 03 2.1 Introduction. ................................................................................................ 03 2.2 Motivation................................................................................................... 04
3. Problem Statement............................................................................................... 05
4. Existing System...................................................................................................... 06 4.1 Architecture................................................................................................... 06 4.2 Critical Aspect.. ............................................................................................ 10 4.2 Technologies Studied.................................................................................... 14
5. Requirement Analysis............................................................................................. 21 5.1 Requirements................................................................................................. 21 5.2 Analysis......................................................................................................... 22
6. Project Design.......................................................................................................... 29 5.1 Architecture................................................................................................. 29 5.2 Technology Used........................................................................................... 30
7. Implementation ...................................................................................................... 38
8. Testing...................................................................................................................... 43

9. Project Time Line.................................................................................................... 45
10. Task Distribution.................................................................................................. 47
11. Conclusion............................................................................................................. 48
12. Limitations............................................................................................................. 49
13. Future Scope......................................................................................................... 50

References................................................................................................................... 51

1. Overview of the Project
The construction of the project can be divided into following parts.
1.1 Existing system:
The system is a service oriented framework supporting large media databases. This system provides various search services to the clients through various applications. These applications get data from this framework. The databases are extremely large and need to be searched whenever there is a data request. This contains following problems:-
1. Response Time
The response time of the system is also very poor as the system needs to search such a large database for every request.

2. Predict trends
The current system doesn’t predicts the future trends which will enable the system to provide additional services like getting the top 20 frequently used songs.

1.2 Critical Aspects:

Our project aims at overcoming the above limitations by adding caching mechnism. Some of the critical aspects in the project are,
1. Scalability: The performance of the system can be increased by increasing the resources when the demand increases. Also, because the original architecture is scalable the added mechanism should also be scalable so that it does not become the bottleneck.
2. Compatibility: The new system must be compatible to the existing system.
3. Efficiency: The caching mechanism that is implemented must not take more time then the database search itself. Otherwise its of no importance.

1.3 Design and Analysis:
Based on the above critical aspects following decisions must be made:
● Appropriate architectural update.
● Appropriate technology selection.
● Appropriate algorithm.

1.4 Implementation, Integration and Testing:
Based on the above design decisions there should be appropriate mapping of design to implementation. This will reduce propagation of errors. It will also create a more foolproof module which will have less bugs. Use appropriate platform and tools to develop the right functionality.
After the implementation is over the module should be integrated using right interfaces of the both the systems. This will be finally tested in various ways to remove errors and then the system will be ready for use.

In the next section, we give an introduction to the project and the motivation behind it. Thus the next section will explain both the existing and the proposed systems in brief.

2.Introduction And Motivation
After a brief overview of the project, this section gives a brief idea of the current scenario and the problem definition. This section starts with an introduction to the project giving a brief idea about the existing and the proposed project followed by the motivation i.e. the reasons for the proposed system.
2.1 Introduction: The system is based on a service oriented framework which can be defined as a loosely coupled system with each module providing different services to the client according to the requirements. They can be developed on a heterogeneous and distributed system. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages. In the era of globalization, the advantages of using this type of the system is that it provides agility, flexibility and localization to some extent. In this report we study a service oriented framework that supports a large media database created by Mime360. Mime360 is a music based company that creates various music related applications across various platforms and uses this framework as a backbone for supporting them. This framework provides various services as follows
● Searching songs of particular album
● Searching songs sung by a particular artist
● Searching songs of different genres
● Searching songs in a particular language
● Searching a particular song
This framework takes input as a HTTP request along with the required search parameters. The response is provided as a XML file. XML stands for EXtensible Markup Language. XML is a markup language like HTML. XML was specially designed to carry data and is designed to be self descriptive [1]. Thus, for every request keywords are extracted, then the databases are searched for the required key word and finally a XML file is created containing the appropriate results. So, the report proposes a caching mechanism to improve the performance of the system. The caching mechanism caches the frequently requested XML files and makes them available for the subsequent requests without searching the database. However, if there is a cache miss i.e. if the file is not present in the cache then the system will search the database for the requested file and return it. Also the cache will be updated. Thus improving the response time which helps in increasing the performance of the system.

2.2 Motivation: As discussed in the introduction, this project proposes a caching mechanism to improve the performance of the system. This section of the report aims at providing the motivation behind such a proposed system.
Existing system: The existing system has consists of a large database, web servers and load balancer. The load balancer distributes the request over the web servers to distribute the load evenly between all the servers. Then each server queries the database for the requested media objects. Finally it creates an XML file and sends the result back to the user.
Proposed Modifications: In the new system, request will first be transferred to the caching system which is attached to all the web servers. It the requested objects are present in cache then they are retrieved from the cache and others are searched in the database.
Improvement : Originally, the system used to search the database for each and every request made by the client. Also the database size being extremely large searching will take a considerable amount of time. However if the system uses caching mechanism then time will be saved in order to retrieve frequently requested data. This will reduce the number of searches on the database. Thus the overall response time reduces. This will make the applications using these services more efficient. Also the proposed system will help in analysing the current trends globally. It will also be helpful in providing additional services available due to the analysis. In the next section, we will discuss the project statement. This will define the scope of the project. It contains a detail problem definition of the project.

3. Problem Statement The original system is a service oriented framework supporting large media database. It contains a complete database of songs in many languages created by many artists and categorised into various albums. The system provides search related services on these databases. These services can be used by many applications across various platforms for different purpose. Some of the services are as follows
● Searching songs of particular album
● Searching songs sung by a particular artist
● Searching songs of different genres
● Searching songs in a particular language
● Searching a particular song
This framework consists of following main components:
Load Balancer:
This component distributes load over the servers. All the requests first come to the load balancer. The load balancer then transfers the request to appropriate server having minimum load.
Web Server:
Request is a HTTP request using REST API i.e. the request itself contains the all the parameters that are required for selecting or updating values to the database. Web server extracts these parameters and generates a query for searching in the database. It also creates a XML file of the result and sends it back to the client.
Database:
It contains all the media related data. This data is also replicated for better scalability and recovery in case of failure.
In addition to the original system, the proposed system contains caching mechanism added to each server. The cache contains most frequently requested objects. So, every web server will first search its cache before searching the database. The cache is implemented using MEMCACHE utility. This utility works with all languages like java, C, PHP, etc. It stores objects as key – value pair. It compares the key for retrieval of corresponding objects. There are two cases which occur with caching mechanism i.e. cache hit or cache miss. In cache hit the data is found in cache and the result is sent. In cache miss the system will search the database. But, the only difference is that after retrieving from the database it will also update the cache. The addition of this module decreases the response time of the system as discussed in previous sections.

In the next topic we will discuss the existing system in more detail along with its architecture and critical aspects and the technologies used currently. This will give us the correct idea of the system and will also help in taking critical decisions for making the caching mechanism.

4. Existing System In the previous sections, we have defined the project statement and the scope of the project in detail. Accordingly in this chapter we will study the existing system in detail by considering its architecture, critical aspects and the technologies used. The existing system is a Mime360 framework supporting a media database.
4.1 Architecture:
The framework is based on a Service Oriented Architecture (SOA). SOA enables application functionality to be provided as a set of services, and the creation of applications that make use of software services. Services are loosely coupled because they use standards-based interfaces that can be invoked, published, and discovered. Services in SOA are focused on providing a schema and message-based interaction with an application through interfaces that are application scoped, and not component or object-based.
A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.
Connections
The technology of Web services is the most likely connection technology of service-oriented architectures. Web services essentially use XML to create a robust connection. The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. A service provider can also be a service consumer.

Figure 4.1 [24]
In connection with this system, the web services are critical in maintaining the framework. A client sends a request message like an HTTP request, GET, POST, etc to the server. The server returns a response message back to the client, in some different form like HTML, an image, XML file, etc. But before it gives the response, it searches the desired file in the database.

Advantages:
● Domain alignment. Reuse of common services with standard interfaces increases business and technology opportunities and reduces cost.
● Abstraction. Services are autonomous and accessed through a formal contract, which provides loose coupling and abstraction.
● Discoverability. Services can expose descriptions that allow other applications and services to locate them and automatically determine the interface.
● Interoperability. Because the protocols and data formats are based on industry standards, the provider and consumer of the service can be built and deployed on different platforms.
● Rationalization. Services can be granular in order to provide specific functionality, rather than duplicating the functionality in number of applications, which removes duplication.
Disadvantages:
● The development of service-oriented architecture depends on the implementation of standards.
● Without standards, communication between applications becomes time and code intensive.
● Service-oriented architecture is not meant for applications with high data transfers, applications that do not require request/response implementation or applications with a short lifespan.

The architecture contains various components present in the architecture are load balancer, web server, database and search services. Each of these components is shown in figure (1). The diagram shown below can be divided into two layers one is the development layer and the other is the production layer. The development layer is used for the development of various components i.e. their implementation, integration and testing. After a service is implemented in the development layer then it ia made available to the client in the production layer through network file systems (NFS). NFS contains all the executables required to provide the required services. The figure below also depicts the critical aspects like replication, scalability and disaster management.
Following is the explanation of the components:
Explanation
The above architecture was designed keeping in mind that the system has to be continuously developing while the SQL databases of the system are being accessed by the LAMP web servers.
Hence, the architecture was divided into two parts:
■ A Production area – where all search queries will be processed.
■ A Development area – where the overall system is continuously being upgraded.
● The Production Area
This area consists of the following:
● Load Balancer - Load balancing is a computer networking methodology to distribute workload across multiple computers. Here, the search queries requested by the user are forwarded to this load balancer. It then forwards the request to multiple Lamp Web Servers for further processing.
● Lamp Web Server – The search requests are forwarded by the load balancer to these servers. In turn, this web server accesses the database to search for the user requested data. Which web server should be operated is decided by the load balancer.
● SQL Databases – These are the active data stores which contain all the volume of data. Each web server is connected a different SQL database. All these databases are replications of each other. This is a crucial aspect to be considered because if there is any partial system failure on any database side, the overall system does not terminate. The query results are sent back to the web servers which send back the results to the user interface display screen.
● The Development Area
This area contains the front-end development server, back-end development server which have their own SQL databases. These two types of web servers rooted to a development operating system form the basic architecture of the development area of the MIME architecture.

Network File system – This is the component block which connects the production area to the development area. All upgrades done to the system are reflected in this file system. It will contain all new upgraded files which can be then accessed by the active Lamp Web Servers.

Mime Architecture

Replicated PRODUCTION DEVELOPMENT
MySQL

MySQL
MySQL
MySQL

Figure 4.2

4.2Critical Aspects
Realizing the critical aspects of the system is very important since the project can’t be designed without understanding the main features, the project can’t be perpetuated.
In this topic, the three critical aspects of the system which were considered are portrayed:
1. Load Balancing – this was an important aspect to be considered since multiple user requests have to be handled by the system. Introducing a load balancer would balance the load on all the multiple Web Servers provided by the system. Hence, a load balancer was introduced in the production area of the system where the user requests would first arrive which would be sent to one of the web servers as decided by the balancer.
2. Scalability – System scalability was one of the first major considerations while designing the existing architecture. As seen in the MIME architecture, the load balancer is connected to multiple Lamp Web Servers which in turn are connected to their own databases. In future, if more number of web servers are required, the architecture can be updated by directly connecting new Web Servers to the load balancer.
3. Disaster Recovery – The system has to serve a big application which was going to be accessed by multiple users in different places and environments. Thus if there is any disaster such as a system failure on any site where the system is loaded, there had to be a way to allow the users to continue using the system without any problem. Thus, all the SQL databases connected to the active web servers are replicas of each other. Thus in case of any disaster, the system will not get terminated but all the user requests will be then forwarded to another web server which will access its own database which contains the same data contained by the terminated database.
These three critical aspects are elaborated as follows:-
● Load Balancing Load balancing is a computer networking methodology to distribute workload across multiple computers or a computer cluster, network links, central processing units, disk drives, or other resources, to achieve optimal resource utilization, maximize throughput, minimize response time, and avoid overload. Using multiple components with load balancing, instead of a single component, may increase reliability through redundancy. The load balancing service is usually provided by dedicated software or hardware, such as a multilayer switch or a Domain Name System server. Functions of load balancing:- Sharing the Load The primary function of the load balancer is to distribute inbound connection requests across multiple web servers. This allows administrators to setup multiple servers and easily share the load between them. Adding additional capacity as demand grows is straightforward and can be achieved by simply adding additional IIS servers to the virtual cluster. Providing Resilience Typically, two load balancer appliances are deployed. This ensures that a single point of failure is not introduced. A heartbeat signal between the pair is used to ensure that should the active unit fail, the passive unit takes over. Web server monitoring is also used to ensure that failed servers are removed from the cluster and client requests are only directed to functional servers. SSL & Certificates For secure web sites & web pages, SSL is used. This ensures that data is encrypted between client and server. SSL certificates can be installed on the load balancer (aka SSL off-loading) or on the web servers. When terminating SSL on the load balancer, it is important to consider that data is not secured between the load balancer and the backend web servers and is transmitted unencrypted. Persistence (aka Server Affinity) Ideally, persistence should be considered at the start of any web server project. A database is typically used to maintain session information. This information is then available to all web servers so that whenever a user connects, any previous session details can be accessed. If this structure is not in place, persistence can be implemented on the load balancer. For HTTP, this can be either based on source IP address or cookies - both ensure that repeated connections within a session are always sent to the same backend web server. Methods of load balancing:

There are various ways in which load balancing can be achieved. The deciding factors for choosing one over the other depends on the requirement, available features, complexity of implementation, and cost. For example, using a hard-ware load balancing equipment is very costly compared to the software version.
○ Round Robin DNS Load Balancing
The in-built round-robin feature of BIND of a DNS server can be used to load balance multiple web servers. It is one of the early adopted load balancing techniques to cycle through the IP addresses corresponding to a group of servers in a cluster.
Pros: Very simple, inexpensive and easy to implement.
Cons: The DNS server does not have any knowledge of the server availability and will continue to point to an unavailable server. It can only differentiate by IP address, but not by server port. The IP address can also be cached by other name servers and requests may not be sent to the load balancing DNS server.
○ Hardware Load Balancing
Hardware load balancers can route TCP/IP packets to various servers in a cluster. These load balancers are often found to provide a robust topology with high availability, but comes for a much higher cost. Pros: Uses circuit level network gateway to route traffic.
Cons: Higher costs compared to software versions.

○ Software Load Balancing
Most commonly used load balancers are software based, and often comes as an integrated component of expensive web server and application server software packages.

Pros: Cheaper than hardware load balancers. More configurable based on requirements. Can incorporate intelligent routing based on multiple input parameters.

Cons: Need to provide additional hardware to isolate the load balancer.
As related to the project, load balancer basically performs following functions:
i. Firstly, the load balancer is used to distribute the queries to multiple servers so that no server is overloaded while others are idle. Thus it distributes the load among the servers. ii. In case of any server crash the load balancer notices the crash and redirects the requests to other servers and thus increases the availability and immunity of the system.

Load Balancer Diagram

Figure: 4.3
● Scalability
Scalability is ability of the software to handle growing amount of work. In web applications this is generally related to the increasing amount of web users or visitors. Alternatively this can be caused by an increasing amount of data. At some point one of the resources reaches hardware limits which are called - a bottleneck. In reality, very often limit is reached because software is not using resources efficiently. Systems designed in a better way would not demand so many resources and would have an improved overall performance.
For example, the distributed nature of the Domain Name System allows it to work efficiently even when all hosts on the worldwide Internet are served, so it is said to "scale well".
To improve scalability, the given practices need to be followed.
1. Offload the database – stay away from the database as much as possible. That means don’t open connections to it and don’t start transactions unless you have to.
2. What a difference a cache makes – caches can greatly offload the database especially for applications accessing the database in read-only mode. In-memory cache is better than an on-disk one, which is better than a remote or a relational database.
3. Cache as coarse-grained objects as possible – caching coarse-grained objects “will save CPU and time required to interrogate n number of cache zones rather than a single cache zone. Furthermore, retrieving a full object graph saves time assembling the object graph.”
4. Do not store transient state permanently – avoid storing transient data, like login session data, in a database records.
5. Location – put things close to where they are supposed to be delivered. Instead of going through a load balancer, a web server, an application server and a database, it is faster and less consuming to go through the load balancer and the web server and retrieve some of the content from a CDN.
6. Constrain concurrent access to limited resources – if more than one request accesses the same resource and performs the same calculation, it is better to proceed with the first and let the others wait until it finishes its job to just use the final results. Letting all the threads to access the resource will only slow down the process.
7. Minimize network chatter – try to make the application as remotely un-talkative as possible because network communications are considerably slower than in-memory ones.

● Disaster Recovery
Disaster recovery is the process, policies and procedures related to preparing for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induced disaster.
These shutdowns can be classified as Malfunctions, disasters or catastrophe. Creating an effective plan to deal with the potential unexpected shutdown is known as Disaster Recovery Planning. Disaster recovery can be broken into the following components:
(a) Business Planning and Preparation
(b) Business Systems and Technology Preparation
(c) Incident Response Planning
Most of businesses are recovered by breaking the operational components into three simple concepts:
(a) Identify the risks
(b) Proactive approach to the potential problem
(c) Creating a response to the potential problem
In this system, when a disaster occurs, the entire framework is shut down, and restarted. And, when it starts, it identifies the cause of the risks, and tries to find a solution to decimate the risk. When the framework loses connection to the database or the GUI, it sends the request again and again till it gets any acknowledgement.
Hence, the critical aspects have been studied and various architectures, database normalization, DMOCS, XML, Load Balancing, Scalability and Disaster Recovery have been taken into view considering the design of the project. Now we will study the technologies used ineach of these components

4.3 Technologies Studied: In this section we will discuss the technologies used for each of the components.

● REST API: REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.
REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines. [13][14][15]
In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.
RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture.
The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components. By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolving nature. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.
In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. [13][14][15]
As a programming approach, REST is a lightweight alternative to Web Services and RPC.
Much like Web Services, a REST service is:
● Platform-independent (you don't care if the server is Unix, the client is a Mac, or anything else),
● Language-independent (C# can talk to Java, etc.),
● Standards-based (runs on top of HTTP), and
● Can easily be used in the presence of firewalls.
Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:
● For security, username/password tokens are often used.
● For encryption, REST can be used on top of HTTPS (secure sockets).
One thing that is not part of a good REST design is cookies: The "ST" in "REST" stands for "State Transfer", and indeed, in a good REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.
Example:
Simple REST query may look like:
The Main Advantages of the REST API is:
● Uses less Bandwidth.
● Easy to handle.
● As Secure as SOAP.
● Less complex.
● With REST you only need a simple network connection and you can easily test its API.
Following technologies can be used to implement REST API
Jersey (and Jaxb) Pion
It is a java based technology. It is a C based technology.
It runs on tomcat server. It runs on apache server.
It has large library and uses Object oriented concepts. It is faster as compared to jersey and also it has inbuilt feature for security as it supports server side SSL & TLS encryption.
Table 4.1 [13][14][15] Pion is used as the REST API technology because of the following reasons:
i. Firstly, we are using apache as the web server. ii. We need the API to be quick so that the search queries will be executed quickly and the response time will be as small as possible. iii. Finally, it can be configured to be very secure. Because of the all the above discussed advantages the existing system uses REST API for getting its request.

● Database Technology (MYSQL):
MySQL, pronounced either "My S-Q-L" or "My Sequel," is an open source relational database management system. It is based on the structure query language (SQL), which is used for adding, removing, and modifying information in the database. First released in January, 1998, MySQL is now one component of parent company MySQL AB's product line of database servers and development tools. Standard SQL commands, such as ADD, DROP, INSERT, and UPDATE can be used with MySQL.
MySQL can be used for a variety of applications, but is most commonly found on Web servers. A website that uses MySQL may include Web pages that access information from a database. These pages are often referred to as "dynamic," meaning the content of each page is generated from a database as the page loads. Websites that use dynamic Web pages are often referred to as database-driven websites. [16][17][18]
Many database-driven websites that use MySQL also use a Web scripting language like PHP to access information from the database. MySQL commands can be incorporated into the PHP code, allowing part or all of a Web page to be generated from database information. Because both MySQL and PHP are both open source (meaning they are free to download and use), the PHP/MySQL combination has become a popular choice for database-driven websites.
Many Internet startups became interested in the original open source version of MySQL as an alternative to the proprietary database systems from Oracle, IBM, and Informix. MySQL is currently available under two different licensing agreements: free of charge, under the GNU General Public License (GPL) open source system or through subscription to MySQL Network for business applications.
MySQL runs on virtually all platforms, including Linux, UNIX, and Windows. It is fully multi-threaded using kernel threads, and provides application program interfaces (APIs) for many programming languages, including C, C++, Eiffel, Java, PHP, Python, etc. [16][17][18]
MySQL is used in a wide range of applications, including data warehousing, e-commerce, Web databases, logging applications and distributed applications. It is also increasingly embedded in third-party software and other technologies. According to MySQL AB, their flagship product has over six million active MySQL installations worldwide. Customers include Cisco, Dun & Bradstreet, Google, Facebook, NASA, Lufthansa, Hyperion, and Suzuki. [16][17][18]
Need for MySQL
MySQL has been chosen as the common database management system for this project. Since it is based on the structure query language (SQL), it is easy for administrators to modify the tables like adding songs, user’s information, removing them and modifying any kind of information in the database. This project need not have very complicated security matters like profiles, local authentication, external authentication, advance security enhancements etc. Also, the cost included for the project would be nil so the customers would download the songs for free.
Comparisons of MySQL with Oracle and SQL Server Topics MySQL SQL Server Oracle
Price It is completely free. It could take a small independent company’s budget. It is very expensive.
Purpose It can either be for large or small companies. It can either be for large or small companies. Oracle is targeted towards large companies with high cost.
Database Security MySQL uses three parameters to authenticate a user namely user name, password and Location. SQL Server also uses three parameters to authenticate a user namely user name, password and Location Oracle uses so many security features like username, password, profiles, local authentication, external authentication, advance security enhancements etc.
Manageability of code Cannot support large tons of extra codes Can support extra code Very useful in maintaining large sections of code
Support and service With such a small staff dispersed over a wide area of expertise, this fact may worry some database administrators. SQL Server, from Microsoft, has a significantly large support program and large staff backing the program. Oracle employs thousands of professional developers, administrators hardly faces an uphill problem.
Running and external programs MySQL does not support other languages being executed from within the system, and neither does it supports XML. SQL Server supports a limited amount of languages and it supports XML for transferring data. Oracle database supports several programming languages to be written, compiled and executed from inside the database. Oracle databases also use XML.
Data Protection MySQL lacks the capability to perform such a backup transaction in an online, or "live" environment. This feature is standard to SQL Server and includes tools to help the database administrator manage the details of the log shipping. Oracle provides different type backup facilities like cold backup, hot backup, export, import, data pump.
Standard Language Support MySQL does not completely follow the ANSI SQL standard if our need for data storage never outgrows the capability of MySQL. SQL Server follows this standard and is geared more toward selecting data so it can be displayed, updated and saved again. Oracle follows all SQL standards and supports add-ons also.
Character Data Types MySQL has CHAR and VARCHAR for character types with maximum length allowed to be 255 and 65,535 Bytes respectively. SQL Server has CHAR and VARCHAR for character types with maximum length allowed to be 255 and 65,535 Bytes respectively. Oracle, on the other hand, supports fours character types namely CHAR, NCHAR, VARCHAR2, and NVARCHAR2 and they have different sizes.
Platform support MySQL can run on all platforms. SQL Server can run only on Windows. Oracle can run on all platforms.
Object Names Some of the MySQL object names like databases and tables are case-sensitive. Some of the SQL Server Object names are case- sensitive. Oracle is case-insensitive to all object names.
Usage MySQL is more popular in websites and PHP integration. SQL Server is used mostly in all business companies like Flat File, Sybase, Mainframe IMS, Informix, etc. Oracle is popular in large databases like Banking, ERP, Insurance, finance companies.
Table 4.2 [16][17][18] Thus MySQL is used as the database technology. Also the databases are replicated to improve the disaster management of the system. The improvement to the system can only be made if the new module is compatible with this technology.
● Web Server (LAMP):

The Apache HTTP Server, commonly referred to as Apache is web server software developed and maintained by an open community of developers under the auspices of the Apache Software Foundation. The application is available for a wide variety of operating systems, including Unix, FreeBSD, Linux, Solaris, Novell NetWare, Mac OS X, Microsoft Windows, OS/2 and TPF. Apache is open-source software. Thus, for Microsoft Windows apache server is called WAMP, for Linux its called LAMP and for cross platform its called XAMPP. Thus, LAMP is also an apache server.
The Apache web server is equipped with a lot of capabilities, enabling it to support various scripts and modules for the web. The server supports the Common Gateway Interface (CGI) and Server Side Includes (SSI). CGI is used as a common means of communication between the external software and the web server, while SSI is a user-friendly scripting language for server. Apache users can also install other modules such as user home directories, URL redirection, user authentication, and anonymous user access among others. Following is the comparison with other popularly used server i.e. Tomcat which is java based server. [19][21]

Apache HTTP Server VS Apache Tomcat

Apache Tomcat

Apache Tomcat (or simply Tomcat), is an open source web server and servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Oracle Corporation. Tomcat should not be confused with the Apache web server, which is a C implementation of an HTTP web server; these two web servers are not bundled together, although they are frequently used together as part of a server application stack. Apache Tomcat includes tools for configuration and management, but can also be configured by editing XML configuration files.

Features Apache HTTP Server Apache Tomcat
Common Gateway Interface Can be interfaced with CGI as well as Fast CGI Can be interfaced only with CGI. Does not support the Fast CGI extension.
Java Servlets Doesn’t include Java Servlets. Java Servlets can be included to extend the capabilities of the server.
Operating System Support Supported by all kinds of OS. Supports all kinds of OS except for eComStation.
Table 4.3 [19][21] Thus, due to above reasons apache was used in the existing system. Configuration of the server can be shown as follows.
Configuration

The Apache HTTP server is configured by text files and the main required file is usually called httpd.conf normally located in the conf directory just under apache's root folder.
Many areas of httpd.conf are broken up into sections or containers delimited or enclosed in start < > and stop tags. For example the container is used where you want to set particular attributes for the server’s filespace. The and directives enclose sections that configure virtual hosts. To make it even more clear the option or function of a section and make managing the configuration easier you can use external text files to hold your directives. These files follow the same rules as the main httpd.conf file and are called into the configuration by using the include directive.
Another configuration file that is used on a per-directory basis is (normally) named .htaccess. This file is placed in the particular directory whose attributes you want to modify so implicitly functions similar to directives added to the directory container in the server configuration. This is typically used to modify the server configuration for a particular virtual host and is thus usually placed in that virtual hosts document root.
It is important to note that .htaccess follows the same syntax of httpd.conf but, unlike httpd.conf where changes take effect only on a server restart, .htaccess directives are examined each time the particular directory that .htaccess is contained within is accessed.

These are the technologies used in the current system. The next topic will focus on the requirements and analysis of these requirements for the proposed system.