Transaction Scheduling for Web Services Computing Applications

This article was downloaded by: [The University of Manchester Library]On: 11 November 2014, At: 07:48Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

Intelligent Automation & Soft ComputingPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/tasj20

Transaction Scheduling for Web Services ComputingApplicationsHong-Ren Chen aa Department of Digital Content and Technology , National Taichung University , 140 Min-Shen Rd , Taiwan , Taichung 403Published online: 01 Mar 2013.

To cite this article: Hong-Ren Chen (2008) Transaction Scheduling for Web Services Computing Applications, IntelligentAutomation & Soft Computing, 14:4, 491-503, DOI: 10.1080/10798587.2008.10643008

To link to this article: http://dx.doi.org/10.1080/10798587.2008.10643008

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/loi/tasj20

http://www.tandfonline.com/action/showCitFormats?doi=10.1080/10798587.2008.10643008

http://dx.doi.org/10.1080/10798587.2008.10643008

http://www.tandfonline.com/page/terms-and-conditions

http://www.tandfonline.com/page/terms-and-conditions

Intelligent Automation and Soft Computing, Vol. 14, No. 4, pp. 491-503, 2008 Copyright © 2008, TSI® Press

Printed in the USA. All rights reserved

491

TRANSACTION SCHEDULING FOR WEB SERVICES COMPUTING

APPLICATIONS

HONG-REN CHEN Department of Digital Content and Technology

National Taichung University 140 Min-Shen Rd.

Taichung 403, Taiwan

ABSTRACT—Web services technology provides a new computing model, which greatly accelerates application processes and responds to changing business needs within and across enterprises. Increasingly, web services transactions are key additions to business processes that access multiple web services and need to string them together. However, many of the previous approaches for scheduling transactions considered a single class of transactions with real-time constraints, whereas in practice not all transactions in web services computing applications have real-time requirements. This work studies the problem of scheduling web services transactions to deal with both real-time and non-real-time constraints existing simultaneously. We present an efficient transaction scheduling policy named the dynamic allocation policy for web services computing (DAP-WS), which aims at minimizing the number of missed real-time web services transactions and maximizing the throughput of non-real-time web services transactions. The presented simulation results demonstrate that the DAP-WS delivers good performance in the web services computing environment. Key Words: Scheduling Policy, Web Services Computing, Transaction Management

1. INTRODUCTION Web services technology is emerging as an important trend in web application development

and integration [1]. The widespread adoption of services offers advantages including: interoperability, stability and implementation reuse [2]. As typical blocks of electronic commerce and enterprise application integration as well as on-demand computing, web services are expected to greatly enhance the promise of distributed computing [3,4]. In the last decade, many of the previous approaches for scheduling transactions considered a single class of transactions with real-time constraints, whereas in practice not all transactions in web services computing applications have real-time requirements. For examples, in a web travel agency application as illustrated in Figure 1, a web services transaction may consist of three web services subtransactions, with the one for booking a flight ticket having real-time constraints, whereas those for accommodation reservation and car rental having not-real-time constraints [5]. In Internet stock trading systems, some of the web services transactions are real-time operations such as stock data updates, while others are non-real-time operations such as system management operations [6, 7]. Satisfying such applications should require the simultaneous execution of both real-time and non-real-time web services transactions. To effectively execute web services transactions, the web services transaction model plays an important role. Each web service needed

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14

492 Intelligent Automation and Soft Computing

by transactions is processed through a web services transaction model (WSTM). While web services transactions are submitted to a WSTM, the transaction is executed by interpreting the script that defines the process. The appropriate service from among a number of web services is selected to be executed.

Nowadays, most studies have addressed the scheduling of real-time transactions so as to both maximize the total obtained values and minimize the number of missed transactions [7, 9-14]. The primary design factor for a scheduling policy is the transaction deadlines. A transaction with an earlier deadline should be assigned a higher priority, as is the case in the earliest deadline policy (ED) [9]. Some application programs may assign a value to the corresponding transaction. When the execution of a transaction is completed before its deadline, the transaction will be assigned a value, as in the highest value policy (HV) [10]. The highest reward and urgency policy (HRU) considers both the deadline and value as design factors, and assigns various weights to these two factors in a real-time scheduling policy [12]. Flexible high reward policy (FHR) is an extension of HRU for a distributed computing environment. It adds the communication delay factor to lessen the unnecessary waiting time for a remote transaction [14].

Figure 1. The business process of the web service travel agency [3, 8].

Many notable research results on real-time transaction scheduling have been presented [7, 9, 10, 12, 14]. However, the transaction scheduling for these approaches is designed on the basis of a single class of transactions with real-time constraints. In this paper, we focus on the design of the dynamic allocation policy to accomplish different performance goals in processing real-time and non-real-time web service transactions at the same time. The performance goal in processing real-time web services transactions is to minimize the number of deadline violations, whilst that when processing non-real-time web services transactions is to maximize the system throughput. In the DAP-WS, the real-time web services transactions are executed first while non-real-time web services transactions can be executed so as to use the slack time to reduce the response time of a web services transaction. Simulation results presented here demonstrate that the DAP-WS can get good performance under different real-time supports in web services computing applications.

The remainder of this paper is organized as follows: Section 2 provides the web services computing environment. Section 3 presents the DAP-WS and the related processes. Section 4 describes the simulation model and performance results, and conclusions are drawn in Section 5.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14

Transaction Scheduling for Web Services Computing Applications 493

2. WEB SERVICES COMPUTING ENVIRONMENT In a web services computing environment, a communication network interconnects a number

of sites as shown in Figure 2. Each site contains a transaction generator, a pre-analysis manager, a communication interface, a scheduling policy, a cache manager, and a resource manager. The transaction generator is responsible for generating the workload for each site. The arrival of data and/or messages at a site is assumed to be independent of the arrivals at other sites. Web services transactions are classified into two types: real-time and non-real-time web services transactions. To effectively execute a web services transaction, the actions of web services needed by transactions must be processed through WSTM. While interpreting the transaction script, the pre-analysis manager selects the appropriate web services from among a number of web services for execution based on the web services selected strategy shown in Figure 3.

Site 1 SOAP messages

SOAP messages

SOAP messages

SOAP messages Site 2

Site 4

UDDIRegistry

Communication Networks

Site 3

database

Disk1Disk2

...

service provider

transaction generater

pre-analysis manager

WSTM

scheduling policy

resource manager

cache manager

CPU1 …CPU2 CPUn

commnunicationinterface

UDDI registry

execution engine

application

WSDL

WSDL

WSDL

WSDL WS1

WS2

WS3

WS4

WS Manager

Figure 2. High-level of the web services computing environment [6, 15, 16].

≥

ii

estimated execuing time of WSexecuting cost of WS = number of web services functions (1-busy degree of network traffic)

×

Figure 3. Pseudo code of the web services selected strategy.

The quality of service is a major concern considering the execution cost for the web services oriented applications [17]. The unpredictable remote service availability results in poor performance for real-time web services transactions. Thus, the selected strategy always picks a

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


web services transaction with the lowest execution cost for submitting to the execution engine in order to complete more web services transactions. The degree of network traffic, the estimated execution time of web services and the number of web services functions are factors considered in the computing phase of the web services execution cost. This means that web services having a lower busyness of network traffic, estimated execution time, and number of web services functions will have a lower execution cost. For instance, web services with an estimated execution time of 10 and with one web services function will have execution costs for adaptive web services of 12.5 ((10/0.8)×1) and 20 ((10/0.5)×1) if the busyness of network traffic is 20% and 50%, respectively. The execution cost will be 40 ((10/0.5)×2) if there are two web services functions and the busyness of network traffic is 50%.

The scheduling policy is based on the transaction scheduling policy given in Section 3. A communication interface at each site is responsible for sending/receiving data or messages to/from other sites. The universal web services registry (UDDI) in which service provider and service requester can publish web services and find desired web services respectively. Once applications are built as web services, they are described by a web services description language (WSDL) to let requesters know how to invoke them. The WSDL and XML metadata of the services are wrapped in a simple object access protocol (SOAP) message that can be sent to the UDDI. For the page fault, the modified LRU page replacement algorithm, which considers both a deadline and the referencing count for each page is used, if no free cache memory space is available [18]. The resource manager provides the I/O and CPU service at each site. The global database is a collection of local databases.

3. THE PROPOSED TRANSACTION SCHEDULING POLICY Transaction scheduling policies for real-time database systems are developed on the basis of

real-time constraints, such as ED, HV, HRU, and FHR. Generally, such systems will execute the transaction with the highest execution priority assigned to it based on a particular formula. We briefly describe the following transaction scheduling policy using the notations as listed below.

Ti a (sub)transaction in the system Ces(Ti) estimated communication delay of transaction Ti Cep(Ti) elapsed communication delay of transaction Ti Crt(Ti) remaining communication delay of transaction Ti, obtained from Ces(Ti)-Cep(Ti) Ees(Ti) estimated execution time of transaction Ti Eep(Ti) elapsed execution time of transaction Ti Ert(Ti) remaining execution time of transaction Ti, obtained from Ees(Ti)-Eep(Ti) P(Ti) priority of transaction Ti R(Ti) the proportion of completed real-time subtransactions within a mixed real-time

transaction S(Ti) slack time of transaction Ti V(Ti) value of transaction Ti W weight of adjusted transaction’s value and urgency

3.1 ED ED assigns high priorities to transactions with early deadlines [9]. All (sub)transactions have

the same deadline as Ti. The priority assignment formula is given by:

ii

1P(T ) D(T )

←

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


3.2 HV The disadvantage of ED is that it does not consider the values of transactions. Assigning high

priorities to transactions with high values is called HV [10]. As ED, all (sub)transactions have the same value. The priority assignment formula is given by:

P(Ti) ← V(Ti)

3.3 HRU In contrast to ED, HV focuses on completing transactions with high values. However, a

transaction’s urgency is not considered. To eliminate the disadvantage, HRU considers both the deadline and value as design factors. It gives a high priority to a transaction with high value and shortest remaining execution time, and the priority assignment formula is given by:

i

i ii

V(T )P(T ) S(T ) W

E (T )rt← − ×

HRU considers the reward ratio of scheduling a transaction and provides an adjustable policy for various system load conditions [7, 12].

3.4 FHR The above three polices were proposed by [7, 9, 10, 12] and are designed for a centralized

real-time database environment. Hence, FHR is designed for a distributed real-time database environment by extending HRU with a communication delay factor to lessen the unnecessary waiting time for a remote transaction. The priority assignment formula is given by:

i i

ii i

V(T ) S(T )P(T )

E (T ) C (T )rt rt← −

3.5 DAP-WS Transaction scheduling policies for web services computing environments that consider both

real-time and non-real-time constraints have not been proposed previously. However, an increasing amount of research concerns the strategy for resolving the concurrent data-accessing problem between different classes of transactions [6, 8, 19, 20]. The adaptive transaction scheduling policy for a mixed set of real-time and non-real-time web services transactions is worthy of study. An efficient transaction scheduling policy called the DAP-WS based on FHR is presented for satisfying the performance requirements of each individual transaction class in the web services computing environment. The conceptual work is to allocate processors to real-time web services transactions first; non-real-time web services transactions can be executed so as to use the slack time to reduce the response time. From this standpoint, the overall system performance can be improved. At the same time, how to eliminate non-real-time web services subtransactions impacting on the performance of real-time web services transactions is also a necessary consideration.

A schematic of the DAP-WS is shown in Figure 4. The processors in the system can execute each individual transaction class. The real-time or non-real-time web services transactions arriving at the system will enter separate ready queues, and wait to be scheduled by a transaction scheduling policy for processor utilization. Each web services transaction enters its own ready queue based on different real-time constraints. This strategy is also used in well-known operating

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


Figure 4. Schematic of the DAP-WS.

systems such as the Linux System [21]. The DAP-WS has two components as shown in Figure 5. The first component is responsible for calculating the priority for each real-time web services transaction. The proposed policy considers the completion ratio as being the factor used to eliminate non-real-time web services subtransactions impacting the performance of real-time web services transactions. In practice, it enabled higher priority in a mixed real-time web services transaction with most percentages of completed real-time web services subtransactions.

∈∀∀ ∈

i mS(T ) E (T ) rtα × ≥

i

i ii i

i i

Exec_cost(T ) calculated by the web services selected strategyV(T ) S(T )P(T ) R(T ) E (T ) Exec_cost(T )rt

←

← × −

Figure 5. Pseudo of the DAP-WS.

In response to the behavior of real world network transmissions, the minimal executing cost was employed. The adaptation of minimal executing cost for the number of web services registered in UDDI is created by a selected strategy described in Section 2. The critical impact of the busy degree of network traffic, the estimated execution time of web services and the number of web services functions are always considered in the computing phase of the web services execution cost. The web services having a lesser degree of network traffic, estimated execution time and number of web services functions have the lower execution costs. The estimated execution time takes advantage of the opportunity for executing non-real-time web services transactions by utilizing slack time. Namely, the system will assign the processor to real-time web services transactions first. This allows the non-real-time web services transaction to be executed if

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


the slack time of executing the real-time web services transaction is enough and one of professors is free. The adjustable value of α is designed in response to the load of the practice system and is used widely in many notable studies [7, 8, 12].

4. SIMULATION MODEL AND PERFORMANCE EVALUATION This section describes the simulation model that was developed using the popular open-

source discrete-event SimJava package to evaluate the performance of the DAP-WS [22]. The architecture of the simulation model as shown in Figure 6 is defined as an open queuing model that has a network of n sites with a single external source and destination for transactions [23, 24]. Tsi indicates a transaction leaving the source for the queue in the site i and Tid presents a transaction leaving the queue in the site i for the destination. A transaction leaving the queue in the site i for the queue in site j is Tij. All local transactions existing in the central subsystem keep circulating from one queue to the next and reenter the system immediately. When a remote transaction issues the remote request, the central subsystem has external arrivals and departures. The simulation model at each site consists of eight CPUs and two disks. This structure is similar to [7, 25, 26].

Transaction Generator

submit nested/flat trans.

Central SubsystemRemote requests

Destination

Site 1

Site i

Site n

SourceTsi Tid

T11T1i

Ti1

TiiTinTni

Tnn

(includes real-time and non-real-time trans.)

Service queue

DISK1

DISK2

Real-Time Service Queue

CPU2

CPU1

CPU8

Non-Real-Time Service Queue

Figure 6. The architecture of simulation model.

Most of the workload parameters had similar values to those used in previous studies [9, 10, 16, 25-27]. Table I lists the workload model parameters and their baseline values. The parameters page_cpu and page_io determine the CPU and disk time needed to access a data page, respectively. The parameter used to model the load of the system is arrival_rate, which specifies the mean rate of transaction arrivals and has a Poisson distribution. In other words, the inter-arrival time of a nested transaction is an exponential distributed with mean 1/arrival_rate.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


Table I. Workload parameters and base values.

Parameter Description Value num_sites number of sites in the system 4 num_proc number of processors in the site 8 page_cpu CPU time for accessing a data page 0.01 ms page_io disk time for accessing a data page 4.2 ms

arrival_rate the rate of real-time transaction arrivals the rate of non-real-time transaction arrivals

60 trans/sec 10 trans/sec

restart_delay delay time to restart a transaction 5 ms remote_trans the ratio of remote transactions in the system 0.3 min_slack minimal slack factor 2 max_slack maximal slack factor 8 mean_value mean value of transaction 100 tran_size number of subtransactions in the web services transaction 8 leaf_size number of operations per subtransaction 6 remote_op the ratio of remote operations for a remote transaction 0.5 db_size number of pages in database 1600 pages write_prob write probability for accessing a data page 0.5 transfer_rate transfer rate of the network 100 Mbps exec_ws average web services call execution time 30 ms num_ws number of web services providers 30 commit_time commit time for completing a decision phase 45 ms comm_delay communication delay between any two sites dynamic

Restart_delay gives the delay time caused by restarting a transaction. Write_prob determines the probability of updating data pages after a transaction has read the data pages. Tran_size represents the number of subtransactions in a web services transaction, which is the mean of a uniform distribution varying range between 0.5× tran_size and 1.5× tran_size. The parameter leaf_size determines the number of operations per subtransaction varying uniformly between 0.25×leaf_size and 1.75×leaf_size. Web services calls in the transaction are requests from web services providers.

For the transaction deadline, we use a method similar to that reported previously [7, 8, 10, 12]. The deadline of each transaction is formulized as:

(Ti) ← A(Ti) + S(Ti) × Rmax + Ces(Ti) + CT(Ti)

where Rmax is the resource requested time of the largest transaction. S(Ti) is a slack time factor that controls the tightness or looseness of deadlines and varies uniformly over the range set by min_slack and max_slack. Ces(Ti) represents the estimated communication delay of a remote service for transferring remote data, and it is calculated dynamically by the following formula:

i

_ _ _C (T ) (β _ )

=1es

remote op tran size leaf sizepage io

× ×← ×∑

The parameter remote_op refers to the ratio of remote web services operations in a transaction varying uniformly between 0.25 and 0.75, which is calculated as the number of remote web services operations of a transaction divided by the total number of operations of a web services transaction. To estimate various communication delays for transferring remote data, we use a dynamic communication delay factor called β that varies uniformly in the range of 0.5 and

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


2.5 for each remote operation. Hence, the simulated traffic condition of a network can more closely emulate the actual conditions of a real-world situation. For instance, there is a remote web services transaction with remote_op=0.2, trans_size=5 and leaf_size=2, we can get two remote web services operations calculated by 0.2×5×2. The constant value of page_io is 4ms for the system setting. If β1=1.5 and β2=0.6, thus the estimation communication delay of a remote web services transaction is 8.4ms as calculated by (1.5×4ms)+(0.6×4ms). That is to say, β1 and β2 imply that these two remote requests take two communication delays of 6ms and 2.4ms, respectively. The CT(Ti) stands for the commit time of a nested transaction. The transaction value is assigned by the function of V(Ti)←Vi, where Vi is the maximum value and varies uniformly between 0.5 and 1.5 times the value of mean_value.

The performance metrics of MissRatio and LossRatio as given in [10, 12, 25] were used:

number of transactions missing the deadline

= 100%total number of submitted transactions

MissRatio ×

total offered value - total final obtained value

= 100%total offered value

LossRatio ×

where the offered value refers to the value given by the application when a transaction is submitted, and the final obtained value indicates the net value after the transaction has completed. We compared the transaction scheduling policies of the ED, HV, HRU, FHR and DAP-WS under various conditions, and also investigated the variety of response times for non-real-time transactions. For the concurrency control protocol, we used two-phase locking with adjustable slack time (2PL-AST) [8] because it is an effective protocol for most types of real-time information research concerning web services computing. It resolves the concurrent data access conflict for both real-time and non-real-time support operations to meet the deadline requirements of real-time web services transaction and maximizing the throughput of non-real-time web services transactions. The essential works of 2PL-AST realizes the fairness principle and includes actions as follows: (1) give prompt data access to real-time requests, (2) utilize the slack time for non-real-time data access, and (3) use the techniques of conditional restart and priority inheritance to avoid the problem of starvation and priority inversion.

4.1 Basic Model In this experiment, we varied the arrival rate from 20 real-time web services

transactions/second (abbreviated as real-time ws-trans/sec) to 120 real-time trans/sec in increasing steps of 20 in order to model different system loads. As shown in Figure 7, the performance order based on the MissRatio and LossRatio metrics is DAP-WS > FHR> HRU > HV > ED (i.e., the DAP-WS performs the best and the ED performs the worst). The excellent performance of the DAP-WS is due to its dynamic allocation of processors to both real-time and non-real-time web services transactions. The real-time web services transactions are executed first to reduce the MissRatio, and the non-real-time web services transactions can also be executed so as to use the slack time to reduce the response time of a real-time web services transaction. We also observed the impact of the arrival rate of real-time web services transactions on the response time of non-real-time web services transactions. Figure 8 shows that under the DAP-WS, the response time increases at a much lower rate than those of the other policies as the load of real-time web services transactions increases. The effective utilization of the completion ratio in the DAP-WS results in more real-time transactions meeting their deadlines, and hence produces a lower MissRatio.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


Arrival Rate (real-time ws-trans/sec)

20 40 60 80 100 120

Mis

sRat

io(%

)

0

10

20

30

40

50

60

70

80

90

100

ED HV HRU FHR DAP-WS


20 40 60 80 100 120

Loss

Rat

io(%

)

0

10

20

30

40

50

60

70

80

90

100

ED HV HRU FHR DAP-WS

Figure 7. MissRatio and LossRatio for basic model.

Arrival Rate (non-real-time ws-trans/sec)

10 20 30 40 50 60

Res

pons

e Ti

me

(ms)

0

500

1000

1500

2000

2500

3000

3500

4000

4500ED HV HRU FHR DAP-WS

Figure 8. Response time for basic model.

4. IMPACT OF VARYING NUMBER OF PROCESSORS This experiment examines the impact of varying the number of processors in the web services

computing environment. The parameters are the same as the basic model shown in Table I except that num_proc is varied as 20. Figure 9 shows the MissRatio results with num_proc set as 20 and arrival_rate ranging from 20 real-time ws-trans/sec to 120 real-time ws-trans/sec. The LossRatio results are similar to MissRatio results and are not plotted. Comparing these results with those in Figure 7, we observe that both MissRatio and LossRatio decrease greatly for all transaction scheduling policies with increasing num_proc under a fixed system load. This fact implies that more web services transactions can be completed before their deadlines if more processors are equipped in the web services computing environment.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14



20 40 60 80 100 120

Mis

sRat

io(%

)

0

10

20

30

40

50

60

70

80

90

100ED HV HRU FHR DAP-WS

Figure 9. MissRatio for num_proc=20

5. CONCLUSIONS The use of services oriented technologies has increasingly accelerated application processes

and the ability to respond to changing business needs for many e-business applications. Web services technology is an important topic for radical construction of distributed applications based on open data communication and a standard data format. However, much of the research in transaction scheduling problems in recent decades has focused on real-time transactions and assumed that all transactions only have real-time constraints. The transaction management issue of effective scheduling transactions in web services computing applications is not presented. Such approaches to real-time scheduling policies are not suitable for web services computing applications due to the existence of non-real-time transactions

This paper proposes the DAP-WS in an attempt to minimize the number of missed real-time web services transactions and reduce the impact on the performance of non-real-time web services transactions. The DAP-WS (1) considers the urgent demand for real-time web services transactions and allocate processors dynamically; (2) uses slack time to execute non-real-time web services transactions; and (3) uses the completion ratio to eliminate the impact on the performance of non-real-time web services subtransactions. The simulation results show that the DAP-WS performs better than the other four approaches analyzed, in terms of the MissRatio, LossRatio, and the effect of a heavy load of real-time web services transactions on the performance of non-real-time web services transactions.

To expect an 80% or greater chance of completing real-time web services transactions on time, the programmer should code a web services transaction with the following limitations: The number of transaction size should be set to less than 5-7 operations, the real-time/non-real-time web services transaction ratio less than 70%, and the read/write ratio higher than 40%. In such settings, 76%-82% of the real-time web services transactions will meet their deadlines, and the response time of the non-real-time transactions falls below 1200ms under the simulation conditions.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


REFERENCES 1. L. Lin, H. Zhao, and S. Rammanathan, “Pricing web services for optimizing resource

allocation: an implementation scheme,” In: the proceeding of Web2003; 2003. 2. M. Atkinson D. DeRoure, A. Dunlop, G. Fox, and P. Henderson. “Web service grids: an

evolutionary approach,” UKeS Technique Report; p.1-13, 2004. 3. H. Kerger. “Web services conceptual architecture,” IBM Software Group, 2001. 4. H. Kerger. “Fulfilling the web services promise,” Communications of the ACM; 2003,

46(6):29-34. 5. C.M. Cram. “E-commerce concepts: illustrated introductory,” Course Technology, Boston;

2001. 6. KY Lam, TW Kuo, B. Kao, SH Lee, and R. Cheng. “Evaluation of concurrency control

strategies for mixed soft real-time database systems,” Info. Sys.; 27:123-149, 2003. 7. HR Chen and YH Chin. “An adaptive scheduler for distributed real-time database

systems,” Info. Scie.: an Intl. J.; 153:55-83, 2003. 8. HR Chen. “An evaluation of concurrency control protocols for web services oriented e-

commerce,” Springer Lec. Note.; 3882:530-540, 2006. 9. R. Abbott and H. Garcia-Molina. “Scheduling real-time transactions: a performance

evaluation,” ACM Trans. Data. Sys.; 17:513-560, 1992. 10. J.R. Haritsa, M.J. Carey, and M. Livny, “Value-based scheduling in real-time database

systems,” VLDB J.;2(2):117-152, 1993. 11. Ö. Ulusoy and G.G. Belford. “Real-time transaction scheduling in database systems,” Info.

sys; 18(8):559-580, 1993. 12. S.M. Tseng, “Design and analysis of value-base scheduling policies for real-time database

systems,” PhD. Thesis, National Chiao Tung University, Taiwan; 1997. 13. VCS Lee, KY Lam, and B. Kao. “Priority scheduling of transactions in distributed real-

time databases,” Real-Time Sys.; 15(1):31-61, 1998. 14. HR Chen, YH Chin, and SM Tseng. “Scheduling value-based transactions in distributed

real-time database systems,” In: Proc. Int. IEEE Symp. Para. and Dist. Proc, San Francisco; p. 978-984, 2001.

15. Ö. Ulusoy. “Processing real-time transactions in a replicated database system,” Dist. and Para. Data; 2(2):405-436, 1994.

16. VCS Lee, KY Lam, and SL Hung. “Impact of high speed network on performance of real-time concurrency control protocol,” J. Sys. Arch.; 42(6-7):531-546, 1996.

17. DA Menasce. “Quality of service issues in web services,” IEEE Internet Computing; 6(6):72-75, 2002.

18. J. Huang and J. Stankovic. “Real-time buffer management,” COINS TR; 90-65, 1990. 19. S. Thomas, S. Seshadri, and JR Haritsa. “Integrating standard transactions in Firm Real-

Time Database Systems,” Info. Sys.; 21(1):3-28, 1996. 20. KY Lam, TW Kuo, and SH Lee. “Strategies for resolving inter-class data conflicts in

mixed real-time database systems,” J. Sys. Soft., 61:1-14, 2002. 21. A. Silberschatz, PB Galvin, and G. Grgne. “Operating System Concepts,” 6rd edn. John

Wiley & Sons; 2003. 22. PA Fishwick. “SimJava: Java-Based Simulation Tool Package,” University of Florida;

1992. 23. R. Jain. “The art of computer systems performance analysis: techniques for experimental

design, measurement, simulation, and modeling,” Wiley, New York; 1991. 24. TG Robertazzi. “Computer networks and systems: queuing theory and performance

evaluation,” 3rd Edition, Springer-Verlag, New York; 2000.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14


25. AA El-Sayed, HS Hassanein, and ME El-Sharkawi. “Effect of shaping characteristics on the performance of nested transactions,” Info. and Soft. Tech.; 43(10):579-590, 2001.

26. R Agrawal, MJ Carey, and M Livny. “Concurrency control performance modeling: alternative and implications,” ACM Trans. Data. Sys.; 12(4):609-654, 1987.

27. K. Ramamritham, SH Son, and LC Dipippo. “Real-Time Database and Data Services,” Real-Time Systems, 28:179-215, 2004.

ABOUT THE AUTHOR

H.-R. Chen received the MS and PhD degrees in computer science in 1998 and 2002 from National Tsing Hua University in Hsinchu, Taiwan. He is currently an assistant professor with the Department of Digital Content and Technology at National Taichung University, Taiwan. His research interests include database management systems, real-time services processing, and web services computing. He is a member of the IEEE Computer Society.

Dow

nloa

ded

by [

The

Uni

vers

ity o

f M

anch

este

r L

ibra

ry]

at 0

7:48

11

Nov

embe

r 20

14

Documents

Transaction Scheduling for Web Services Computing Applications