JOIN Project

[3] ◦ ◦ × ◦

Proposed work ◦ ◦ ◦ ◦

Therefore, we propose a queueing network to model a mashup system to satisfy the QoS requirements of users. Comparison table is shown in Table 2.1. Furthermore, performance analysis and simulation results will be introduced in remaining chapters.

2.5 JOIN Project

JOIN is an application that we can invite friends who have the same interests [19]. The persons who are invited can vote that which place and time they wanted. The architecture of JOIN is shown in Fig. 2.6. During the JOIN service execution duration, there are four steps.

15

TCP/IP TCP/IP

TCP/IP TCP/IP

JOIN Server

Database

Map

Information Audio

Recognition

Figure 2.6: The Architecture of JOIN System

(1) Firstly, once JOIN users login the server and execute the JOIN by choosing the interest-ing groups via the interface on the handsets, they are able to exchange the information with others who in the same group by JOIN server. During this stage, JOIN server will connects to the cloud database server to obtain the information.

(2) Secondly, JOIN server provides the surrounding information (includes businesses and friends) to the users who execute JOIN. During this stage, JOIN server will connects to the cloud database server to obtain the locations of the same interesting friends and connects

to the cloud map information server to obtain the locations of the surrounding businesses.

(3) The user who receives the information from JOIN server can hold the activity by invit-ing the friends, choosinvit-ing one destination and proposinvit-ing the options of the datinvit-ing time.

Once JOIN server receives the information about holding activity, the arranged meeting location and time will be sent to the corresponding users. During this stage, the user might use the audio recognition for ease to use when holding the activity. At that time, the user connected to the cloud audio recognition server through JOIN server.

(4) After voting, the users who are invited will return their preferred dating time to JOIN server. Next JOIN server will collects the data from each user, and sends the final statistics of the vote to all the invited users. This step also stores the result of the activity in the cloud database.

JOIN server is just like a mashup center which integrates the database server, map information server and audio recognition server to provide the users a location-based ser-vice. The service aims to provide the users a real-time location-based service, so the time delay of the service is very important.

17

18

CHAPTER 3

System Model and Problem Formulation

3.1 System Model

In fact, there are abundant and versatile cloud resources in the Internet, such as Google apps, Youtube, Hotmail, etc. Therefore, many cloud applications developers utilize cloud resources of other companies to create their own new applications. As shown in Fig. 3.1, a mashup cloud service architecture consists of mobile users, mashup center and multi-cloud servers. We consider the multi-cloud servers of database, map information, and audio recognition. Denote P₁, P₂ and P₃ as the probabilities of the mashup center requesting to the server of audio recognition, database, and map information, respectively. According to the architecture in Fig. 3.1, we propose a corresponding queuing model for the mashup multi-cloud servers with single- and two-class traffic loads.

3.1.1 Single-Class Traffic Case

To begin with, we first introduce the queueing model for the mashup cloud system in sup-porting the single-class traffic, as shown in Fig. 3.2. The mashup center is composed of

įġįġį

VM1 VM2 VMn

Mashup center

request

Cloud

audio recognition server

p

p

Cloud

Map informat ion

serve 3 r

p

Figure 3.1: A Simple Example of Mashup System.

19

mapper server and reducer sever. When a request enters the mapper server, the service request will be forwarded to audio recognition, database, and map information with prob-ability P1, P2, and P3, respectively. Also, if the service does not require the cloud server, the traffic will leave the mashup system with a probability of P_out. The reducer server will integrate the outcomes of the service request to the servers of database, map information or audio recognition, and then respond the integrated results to the customers.

In Fig.3.2, the mapper server and reducer server are modeled as the M/M/c queue, whereas the database server, map information server and audio recognition server are mod-eled as an M/M/1 queue. We consider the first in first out (FIFO) queue discipline, Poisson distributed arrival process, and the exponential distributed service time for all the servers, including mapper, reducer, database, map information and audio recognition.

3.1.2 Two-Class Traffic Case

Next we consider a two-class traffic case in the mashup system. We classify the users (payers and free users) into two groups. The payers have higher priority to be served than the free users. When a payer asks the service from the mashup system, it will be placed in front of free users, and follow the FIFO queueing discipline for customers with the same class users. When a free user asks for the service, it will line up at the end of the queue if another user is waiting for serving. The service request will enter into the cloud servers or leave the system with the probability P1, P2, P3, and Poutmentioned before. In addition, we also assume that the mapper server and reducer server are modeled as M/M/c queues. Similarly, database server, map information server and audio recognition server are modeled as M/M/1 queue. The arrival rate of the high priority request and the low priority request is Poisson distribution. The service time at the servers are all exponentially distributed.

Mapper Server

Reducer Server

Communication

g

P

P

P

P

Mashup Center

Cloud

Database server

Cloud

Audio recognition

server

Cloud

Map information

server

Figure 3.2: Queueing Model of Mashup System for Single-Class Traffic.

21

Non-Preemptive Priority Service Discipline Only in Mapper Server

In the condition that only service discipline of mapper server is non-preemptive priority, we assume all the requests which are served by mapper server following non-preemptive priority rule and let all the requests entering the cloud servers be treated as the same class.

Hence, we change the queueing model from Fig. 3.2 to Fig. 3.3. We divide the external arrival into two classes. The high priority users is payers. The low priority users is free users. In Fig. 3.3, the service of mapper server discipline is non-preemptive priority and the others discipline is FIFO.

Non-Preemptive Priority Service Discipline in Mashup System

In the condition that all the services in mashup system are non-preemptive priority, we change the queueing model from Fig. 3.2 to Fig. 3.4. There are two kinds of external arrival, payers and free users. When a request of the payer enter mashup system, it will be placed in front of free users, and follow the FIFO queueing discipline for customers with the same class users. When a free user asks for the service, it will line up at the end of the queue if another user is waiting for serving. The service discipline in all the servers of mashup system will follow the rule describing above.