Towards Achieving Execution Time Predictability in Web Services Middleware

Towards Achieving Execution Time Predictability
in Web Services Middleware

Vidura Gamini Abhaya
Supervised by
Prof. Zahir Tari and Assoc. Prof. Peter Bertok

Distributed Systems and Networking Group
School of Computer Science and IT
RMIT University
Melbourne, Australia

15th June 2012

-: Completion Seminar :-

Problem Overview Solutions Conclusion

Presentation Structure

1 The Problem Area

2 Research Overview

3 Solutions

4 Conclusion


The Problem

Evolution of the Internet
Transition from:
User-Centric → Application Centric → Fully Automated Web
* Facilitated by the use of Web services.

Example:


The Problem

Web Services Middleware
Container applications services are hosted in. Manages all aspects
of their execution.

Characteristics
Optimised for throughput by design
Requests are accepted unconditionally
Uses thread-pools to execute them in a best-eﬀort manner
Processes multiple requests in-parallel using processor-sharing

* They result in inconsistent execution times


The Problem

Average Execution Time by No. of Requests Executing in Parallel

30000
Average Execution Time (ms)

20000
5000 10000
0

10 20 30 40

Number of Requests

Service has a linear execution time complexity.
Started with 2 requests sharing the processor and increased by ﬁve upto 47
requests sharing the processor.


The Problem

Why is predictability of execution important in web services?
To achieve consistent service execution times.
To make service selections based on guaranteed execution times
Prevent clients from being set-up for failure.
To open up new application areas that require predictability in execution, such
as Industrial control systems, Avionics, Robotics and Medical diagnostic systems
to the use of web services as a communications platform.

Problem Overview Solutions Conclusion Aim and Scope Research Questions Related Work

Research Overview

What is predictability of execution?
Execution of a web service completing within a given deadline in a
consistent and repeatable manner.

Aim
Achieve predictability of service execution in stand-alone and
cluster-based web services middleware

Scope of Research
Use real-time scheduling principles.
Achieving Predictability is limited to the execution within the web services
middleware.
We assume no delays are experienced on the network.


Research Questions

1 How can predictability of execution be achieved in stand-alone
web services middleware?

2 How can predictability of execution be achieved in
cluster-based web service deployments?

3 How can web services middleware be engineered to have
predictable execution times?

4 How can performance models for such systems be derived and
compared against other techniques?


Related Work
Can be categorised broadly into the following,
Admission control mechanisms used to control execution time in web services
[Dyachuk et al., 2007], [Elnikety et al., 2004], [Carlstrom and Rom, 2002], [Erradi and Maheshwari, 2005]
Do not consider any predictability attributes such as a deadline or laxity, in the decisions.

Execution time QoS on stand-alone servers
[Sharma et al., 2003], [Ching-Ming Tien, 2005]
Achieves some level of differentiated processing, but do not consider any predictability attributes.

Request dispatching techniques aimed at improving execution time
[Pacifici et al. 2005], [Garc´ et al., 2009], [Gmach et al., 2008], [Cao et al., 2010]
ıa
Achieves execution times defined in SLAs in a probabilistic manner. Execution times can be inconsistent.

Web services middleware using real-time scheduling
[Helander and Sigurdsson, 2005], [Mathes et al., 2009]
Predictability is achieved in closed environments, Task properties are known at design time of the system.

Performance models for systems using deadline based scheduling
[Li et al., 2007], [Kargahi and Movaghar, 2006], [Chen and Decreusefond, 1996]
Considers M/M/1 systems which assumes service times to be exponentially distributed. Not a good
representation of web service workloads. Only non-preemptive systems are considered.

Problem Overview Solutions Conclusion Q1 Q2 Q3 Q4

Question 1
How can predictability of execution be achieved in stand-alone web
services middleware?


Real-time Scheduling

Arrival Time Deadline
Execution

Waiting
Time Start Time End Time

Laxity
The ability to delay the execution of a task without compromising its deadline.
Laxity = Deadline − Arrival Time − Exec. Time Requirement
Exec. Time Requirement
Can also be deﬁned as, Laxity = (Deadline − Arrival Time)


Predictability of Execution in Stand-alone Middleware

Introduction of an execution deadline
Laxity based admission control
Earliest Deadline First (EDF) scheduling

0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 16 17 18 19 20 21 22 23 24 25

T1

T2

T3
Start Time End Time
T4

T5
Arrival
Time Execution Deadline



Laxity based admission control - Components of analytical model
Remaining Execution Time
Running Laxity - Laxity of a task at a given time
Processor Demand - Units of processing time required (within
a time period)
Loading Factor - Ratio between processor demand and
processing resources available (within a time period)



0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 16 17 18 19 20 21 22 23 24 25

T1
a1 d1
T2
a2 d2
T3
d3
a3
T4 C4
a4
s4 e4 d4

Reference Point
(Arrival of T4)

Laxity based admission control - Components of Analytical Model

Examples:
Remaining Exec. Time (R),
R3 = 3 − 1 = 2 (Remaining Exec. Time of T3)
R2 = 6 − 2 = 4

Running Laxity (L),
L2 = (d2 − a2 ) − 2 = 17 (Running Laxity of T2)
L1 = (d1 − a1 ) − 1 = 24



0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 16 17 18 19 20 21 22 23 24 25

T1
a1 d1
T2
a2 d2
T3
d3
a3
T4 C4
a4
s4 e4 d4

Reference Point
(Arrival of T4)

Laxity based admission control - Components of Analytical Model

Examples:
Processor Demand (h),
h[a , d ) = R3 + C4 = 2 + 4 = 6
4 4
3
h[a ,d ) = j =1 Rj + C4 = 10 + 4 = 14
4 1

Loading Factor (u),
h[a , d )
u[a ,d ) = 4 4 = 6 = 0.86
4 4 d4 −a4 11−4
h[a , d )
14
u[a ,d ) = d 4−a1 = 21−4 = 0.82
4 1 1 4



Arrival of
a Request Repeated seperately, for each request
0 1 2 3 4 5 6 7 8 9 10 1112 13 1415 16 17 18 19 20 21 22 23 24 25 finishing after the new request

T1

T2
Get accepted Get accepted
T3 requests finishing requests finishing
T4 within the lifespan after the
of the new request new request

Calculate Calculate
Loading Factor
Loading Factor
between arrival time
within lifespan of new req. and
of new request deadline of old req.

Can the Will the
new task be new task
Yes compromise deadlines
scheduled to meet Yes
it's deadline? of these requests?

No
No

Request Rejected Request Accepted



Arrival of

T1

T2

Calculate Calculate
Loading Factor
Loading Factor
At the arrival of T4

Proc. Demand within T4 = 6

Loading Factor within T4 = 0.86 ≤ 1 Will the
Can the

No
No




Arrival of

T1

T2

Calculate Calculate
Loading Factor
Loading Factor

Proc. Demand between T4 and deadline of T2 = 10

Loading Factor between T4 and deadline of T2 = 0.62 ≤ 1 Will the
Can the

No
No




Arrival of

T1

T2

Calculate Calculate
Loading Factor
Loading Factor

Proc. Demand between T4 and deadline of T1 = 14

Loading Factor between T4 and deadline of T1 = 0.82 ≤ 1 Will the
Can the

No
No




Arrival of

T1

T2
T4

Calculate Calculate
Loading Factor
Loading Factor

Can the Will the

No
No




Arrival of

T1

T2
T4

Calculate Calculate
Loading Factor
Loading Factor

Proc. Demand within T5 = 6
6
Loading Factor within T5 = 12−7 = 1.2 > 1 ×
Can the Will the

No
No



Stand-alone middleware performance

RT-Axis2 accepts between 18.1% (fastest) and 96.7% (slowest) of the requests.

Unmod. Axis2 RT-Axis2
Inter-arrival times % Acc. % D. Met oﬀ % Acc. % Acc. % D. Met oﬀ % Acc.
(sec)
1.125 (Low) 100 36.2 96.7 100
0.75 62.4 18.3 58.6 100
0.3 55.1 9.1 30.7 99.7
0.175 (High) 28.7 8.8 18.1 96.7



0.25sec − 1sec (Uniform) 0.1sec − 0.5sec (Uniform)

Axis2 Axis2

RT−Axis2 RT−Axis2

0 10000 20000 30000 40000 50000 60000 70000 0 50000 100000 150000 200000

Execution Time (ms) Execution Time (ms)



Comparison of Resultant Laxities − Standalone Setup
RT−Axis2 (RT) vs Axis2 (A)
Comparison of Throughput - Unmod Axis2 vs RT-Axis2
6
Unmod. Axis2
A RT-Axis2
(1.125s) RT-Axis2 (excl. rej.)

RT 5
(1.125s)

Throughput (Tasks per second)
A
(0.625s) 4

RT
(0.625s)
3
A
(0.3s)

RT 2
(0.3s)

A
(0.175s) 1

RT
(0.175s)
0
1.125s 0.625s 0.300s 0.175s
0 2 4 6 8 10 12 Mean inter-arrival times (sec)

Laxity

Unmod. Axis2 RT-Axis2
Mean inter-arrival Throughput (sec−1 ) Throughput (sec−1 ) Throughput (excl.
time rejected)
1.125s (Low) 0.98 0.91 0.88
0.625s 0.83 1.62 0.95
0.300s 0.72 3.40 1.04
0.175s (High) 0.69 5.64 1.02


Question 2
How can predictability of execution be achieved in cluster-based
web service deployments?


Predictability in Cluster-based Middleware

Dispatching Algorithms - Objectives
*Ensures deadline requirement of tasks could be met
*Distribute requests evenly among executors based on a condition
*Avoids executors going into overload conditions

4 algorithms used
RT-RoundRobin
RT-Sequential
RT-ClassBased
RT-LaxityBased


RT-RoundRobin

Details
Requests assignment cycles
through all executors in RR
fashion
Sched. check is done only once
per request
If sched. check fails on selected
server → request rejected

Hightlights
POC for how a simple dispatching algorithm could be made real-time ready
Processing overhead is minimum


RT-Sequential

Details
Requests are assigned in a
sequential manner
Req’s sent to one executor till
sched. check fails, then assigned
to the second and so on
Sched. check happens against
multiple executors till a request
can be assigned

Highlights
If it’s possible to schedule a job within the cluster, it will be guaranteed


RT-ClassBased

Details
Requests are divided into classes
based on a priority scheme
Mapping of requests to executors
is pre-determined and defined
offline
Sched. check is only considered
with the assigned executor
Reference implementation uses
priorities based on task sizes

Highlights
Results in the reduction of variance of task sizes at each executor
Pre-defined mapping of request sizes to executors could be done using
pre-profiled execution times or execution time history


RT-LaxityBased

Details
Laxity = Ability of delaying a
request whilst still meeting its
deadline
Higher the laxity the more
requests an executor could service
Sched. check is done only against
the assigned executor

Highlights
Distribution of requests results in a broad range of laxities at each executor
Keeps track of the last two laxities assigned and prevents them being assigned
for the same executor consecutively


RT-RoundRobin vs Round-Robin

Task Size distribution between 3 Executors (1 - 5000000 (Uniform); 0.1sec - 0.5sec (Uniform) roundrobin 3 exec)
12000
Executor 1
Executor 2
Executor 3

10000

8000

Execution Time (ms)
6000

4000

2000

0
0 500000 1e+06 1.5e+06 2e+06 2.5e+06 3e+06 3.5e+06 4e+06 4.5e+06 5e+06
Task Size

RT-RR accepts between 20.5% (2 Exec. - fastest) and 99.9% (4 Exec. -
slowest) of the requests.


RT-ClassBased vs Class Based

CPU utilisation at each Executor - (1 - 5000000 (Uniform); 0.25sec - 1sec (Uniform) classbased 3 exec)
90
Executor 1
Executor 2
80 Executor 3

70

60

CPU Utilization %
50

40

30

20

10

0
0 50 100 150 200 250 300 350 400
Sample #

RT-CB accepts between 28.6% (2 Exec. - fastest) and 100% (4 Exec. - slowest) of the requests.


RT-Sequential and RT-Laxity

Highest acceptance rate for any algorithm for 2 executors with highest arrival
rate is 38.5% for RT-LaxityBased
RT-Sequential records the lowest percentage of deadlines met out of all
algorithms. However, given its best acceptance rates out of all, the average
number of requests meeting its deadline is second to only RT-LaxityBased.


Question 3
How can web services middleware be engineered to have
predictable execution times?


Infrastructure

Dev Platform and OS
Solaris 10 08/05 is used as the Real-time OS
Sun Real-time Java Speciﬁcation is used as the Dev Platform


Introduction of the Deadline

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> SOAP Envelope
<soapenv:Header>
SOAP Header
<ns1:RealTimeParams xmlns:ns1="http://endpoint.testservice">
<ns1:Deadline>70</ns1:Deadline> Header
<ns1:Period>0</ns1:Period>
<ns1:clientid>Client1</ns1:clientid>
<ns1:ExecTime>28</ns1:ExecTime>
Header
</ns1:RealTimeParams>

</soapenv:Header>
SOAP Body
<soapenv:Body>

<ns1:primeCount xmlns:ns1="http://endpoint.testservice">
<ns1:primeLimt>102155</ns1:primeLimt> Payload
</ns1:primeCount>

</soapenv:Body>

</soapenv:Envelope>

An example of how the processing deadline could be conveyed to
the middleware - using SOAP headers


Priority Model

Three priority levels are introduced (used by the Real-time Scheduler)
High - Cannot be interrupted by GC - Used on a thread to allow execution
Mid - Can be interrupted by the GC - Used on a thread to prevent execution
Low - Can be interrupted by the GC, Highest priority level available on Standard
Java - Used for meta data requests i.e. WSDL


Enhancements made to Axis2

Details
Thread-pools have been replaced with RT-Thread
pools
A Real-time scheduler has been introduced
Multiple execution lanes are used


Enhancements made to Synapse

Details
Enhanced version of Synapse used for dispatching
Thread-pools have been replaced with RT-Thread pools
A Real-time scheduler has been introduced
Multiple execution lanes are used
RT-Axis2 instances used as Executors
Request processing happens at Dispatcher, Service Invocation at Executors


Minimising Priority Inversions

Can be caused by, I/O activities such as reading/writing to files and sockets.

To prevent priority inversions,
Avoid outputs resulting in on-screen messages or log file writes
Use in-memory logging and delayed writes
Use offline debugging techniques/tools
e.g. Oracle Thread Scheduling Visualizer (TSV)


Question 4
How can performance models for such systems be derived and
compared against other techniques?


Performance model

Why model the system?
To derive diﬀerent performance attributes not based on deadlines
To better compare the performance of techniques used, to others that do not
share the same performance attributes
To investigate the behaviour of the system analytically, without having to turn
to implementations


System characteristics

Uses EDF scheduling
Arbitrary number of priority classes
Executions are preemptive-resume (work-conserving)
Waiting time considered to be the primary performance indicator
Requests have arbitrary service times
Requests arrive according to a Poisson process

* The system is modelled as a preemptive-resume M/G /1/./EDF queue.


System parameters

N number of priority classes
Each class assigned with a constant deadline offset. i.e a task from stream i on
its arrival at the system at time t will have a deadline offset of t + di
Priority of a stream is decided by the associated deadline. i.e. i is considered
higher priority if i < j ⇒ di ≤ dj
Difference between deadline offsets denoted by Dj,i = dj − di .
Queueing discipline among priority classes is EDF and within the class is FCFS.
Each priority class has a different arrival rate denoted by λi
The resultant load for each priority class is denoted by ρi

* The work of Chen K. and Decreusefond L., that approximates waiting time for a
non-preemptive EDF system. Our model, extend their work to a preemptive-resume
system.


Performance Model

i i N i −1
Wi = W0 + k=1 ρk Wk + k=i +1 ρk max(0, Wk − Dk,i ) + k=1 ρk min(Wi , Di ,k )

Parameters

In the point of view of a newly arriving request (tagged request)
- Mean waiting time experienced by stream i requests
- Mean residual service time as experienced by stream i requests
- Requests from higher priority classes found in the system by a newly arrived task and are served prior to
the newly arrived.
- Requests from lower priority classes found in the system by a newly arrived task and are served prior to the
newly arrived.
- Requests from higher priority classes arriving at the system after a given task and being serviced prior to it.

t1 t 1 + d1
I

t2 t 2+ d2
Newly Arrived
Request J

( d2- d1)


Performance Model

i i N i −1
Wi = W0 + k=1 ρk Wk + k=i +1 ρk max(0, Wk − Dk,i ) + k=1 ρk min(Wi , Di ,k )

Parameters

In the point of view of a newly arriving request (tagged request)
- Mean waiting time experienced by stream i requests
- Mean residual service time as experienced by stream i requests
- Requests from higher priority classes found in the system by a newly arrived task and are served prior to
the newly arrived.
- Requests from lower priority classes found in the system by a newly arrived task and are served prior to the
newly arrived.
- Requests from higher priority classes arriving at the system after a given task and being serviced prior to it.

t1 t 1 + d1
I

J
t2 t 2+ d2

( d2- d1)


Mean residual service time

For a preemptive M/G /1 queue (not using EDF),

i −1
Ci = Xi + j=1 (λj Ci Xj )

Parameters
- Ci - Mean time required to complete service for a stream i request, including
the time it is preempted
- Xi - Mean of the service time distribution for stream i requests



Ci Ci

s si

i −1
Ci = Xi + j=1 (ρj min(Di ,j , Ci ))

Let j ∗ = subscript j = 1, 2, ..i − 1 such that Di ,j ≤ Ci
′
Let j = subscript j = 1, 2, ..i − 1 such that Di ,j > Ci

Ci = Xi + j ∗ (ρj ∗ Di ,j ∗ ) + j
′ (ρ ′
j
Ci )

Xi + j ∗ (ρj ∗ Di ,j ∗ )
Ci = (1− ′ ρ ′)
j j


Let Pi be the probably of a request from stream i being in service at an arrival. Pi
could be defined as:

Pi = λi Ci

Mean residual service time of a system can be defined as the the sum of all
probabilities of a job of a given class is in service, times the mean residual service time
i
for the given class [Kleinrock, 1976]. Therefore, we could define W0 ,

i i
W0 = k=1 Pk Rk

Replacing Pk we get,

i ρi + j ∗ (ρj ′ Di ,j ∗ )λi
i
W0 = k=1 Rk (1− ′ ρ ′)
j j

2
Xi 2
where Ri = for an M/G /1 system. (Xi is the second moment of the service time distribution for
2Xi
class i requests.


Evaluation - Analytical results with uniformly distributed service times

Comparison of Analytical Waiting Times - Uniform, 2 Priorities Comparison of Analytical Waiting Times - Uniform, 3 Priorities
12000 12000
Preemptive P1 Preemptive P1
Preemptive P3

10000 10000

8000 8000
Waiting Times (ms)

Waiting Times (ms)
6000 6000

4000 4000

2000 2000

0 0
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Overall Load Overall Load

Comparison of Analytical Waiting Times - Uniform, 4 Priorities Comparison of Analytical Waiting Times - Uniform, 5 Priorities
12000 12000
10000 10000 Preemptive P5

8000 8000
Waiting Times (ms)

6000 Waiting Times (ms) 6000

4000 4000

2000 2000

0 0
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9


Evaluation - Analytical results with exponentially distributed service times

Comparison of Analytical Waiting Times - Exponential, 2 Priorities Comparison of Analytical Waiting Times - Exponential, 3 Priorities
30000 25000
Preemptive P3

25000
20000

20000
Waiting Times (ms)

Waiting Times (ms)
15000

15000

10000
10000

5000
5000

0 0
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Comparison of Analytical Waiting Times - Exponential, 4 Priorities Comparison of Analytical Waiting Times - Exponential, 5 Priorities
25000 25000
Preemptive P5
20000 20000
Waiting Times (ms)

Waiting Times (ms)
15000 15000

10000 10000

5000 5000

0 0
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9


Evaluation - Analytical results compared with simple M/G /1 systems

Comparison of Analytical Waiting Times - Uniform, 4 Priorities - P1 Comparison of Analytical Waiting Times - Uniform, 4 Priorities - P2
4500 6000
Pre. M/G/1/./EDF P1 Pre. M/G/1/./EDF P2
Non-Pre. M/G/1/./EDF P1 Non-Pre. M/G/1/./EDF P2
4000 Pre. M/G/1 P1 Pre. M/G/1 P2
Non-Pre. M/G/1 P1 Non-Pre. M/G/1 P2
5000
3500

3000 4000
Waiting Times (ms)

Waiting Times (ms)
2500
3000
2000

1500 2000

1000
1000
500

0 0
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Priority Classes Priority Classes

Comparison of Analytical Waiting Times - Uniform, 4 Priorities - P3 Comparison of Analytical Waiting Times - Uniform, 4 Priorities - P4
8000 30000
Pre. M/G/1/./EDF P3 Pre. M/G/1/./EDF P4
Non-Pre. M/G/1/./EDF P3 Non-Pre. M/G/1/./EDF P4
Pre. M/G/1 P3 Pre. M/G/1 P4
7000 Non-Pre. M/G/1 P3 Non-Pre. M/G/1 P4
25000

6000

20000
Waiting Times (ms)

Waiting Times (ms)
5000

4000 15000

3000
10000

2000

5000
1000

0 0
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Priority Classes Priority Classes


Evaluation - Analytical vs. Simulation results

Comparison of Anlytical and Simulation Waiting Times - Uniform, 2 Priorities Comparison of Anlytical and Simulation Waiting Times - Uniform, 3 Priorities
12000 12000
Analytical P1 Analytical P1
Simulation P1 Analytical P3
Simulation P2 Simulation P1
10000 10000 Simulation P2
Simulation P3

8000 8000
Waiting Times (ms)

Waiting Times (ms)
6000 6000

4000 4000

2000 2000

0 0
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Comparison of Analytical vs Simulation Waiting Times - Uniform, 4 Priorities Comparison of Analytical vs Simulation Waiting Times - Uniform, 5 Priorities
12000 12000
10000 Simulation P1 10000 Analytical P5
Simulation P4
8000 8000 Simulation P5
Waiting Times (ms)

6000 Waiting Times (ms) 6000

4000 4000

2000 2000

0 0
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Problem Overview Solutions Conclusion Contributions Outcomes Future Work Acknowledgements

Summary of Contributions

1 How can predictability of execution be achieved in stand-alone web services
middleware?
Mathematical model and algorithm for run-time laxity based admission control.
Introduction of deadline based scheduling.

2 How can predictability of execution be achieved in cluster-based web service
deployments?
Four request dispatching algorithms based on the laxity property.

3 How can web services middleware be engineered to have predictable execution
times?
Software engineering techniques, algorithms, designs and tools for incorporating
predictability into web services middleware.

4 How can performance models for such systems be derived and compared against
other techniques?
Queueing theory based performance model for a preemptive work conserving
M/G /1/./EDF queue.


Thesis Outcomes

V. Gamini Abhaya, Z. Tari, and P. Bertok. Achieving Predictability and Service Diﬀerentiation in Web
Services. In ICSOC-ServiceWave 09: Proceedings of the 7th International Conference on Service-Oriented
Computing, Stockholm, Sweden, November 24-27, 2009, pages 364-372. Springer, 2009.

V. Gamini Abhaya, Z. Tari, and P. Bertok. Using Real-Time Scheduling Principles in Web Service Clusters
to Achieve Predictability of Service Execution. In Service Oriented Computing: 8th International
Conference, ICSOC 2010, San Francisco, CA, USA, December 7-10, 2010. Proceedings, pages 197-212.
Springer, 2010.

V. Gamini Abhaya, Z. Tari, and P. Bertok. Building web services middleware with predictable service
execution. In Web Information Systems Engineering - WISE 2010: 11th International Conference, Hong
Kong, China, December 12-14, 2010, Proceedings, pages 23-37. Springer-Verlag New York Inc.
(* Won best student paper award)

V. Gamini Abhaya, Z. Tari, and P. Bertok. Building web services middleware with predictable execution
times. World Wide Web Journal, pages 1-60, 28 Mar 2012.
V. Gamini Abhaya, Z. Tari, P. Bertok. P. Zeephongsekul Waiting time analysis for multi-class
preemptive-resume M/G /1/./EDF queues. Journal of Parallel and Distributed Computing. (In Work)


Future Work

Predictability in the network layer
Extending predictability across application boundaries
Reducing request rejections through selective re-transmission
techniques
Improvements to the preemptive M/G /1/./EDF model
Performance models for preemptive G /G /1/./EDF queue


Acknowledgements

Prof. Zahir Tari and Assoc. Prof. Peter Bertok
Prof. Panlop Zeephongsekul
Miss. Dora Drakopoulos and Mrs. Beti Stojkovski
School of Computer Science and IT and its admin staﬀ
Mr. Don Gingrich
DSN staﬀ and students
My Family


Thank You !
&
Questions or Comments ?

Towards Achieving Execution Time Predictability in Web Services Middleware

Recommended

Recommended

More Related Content

Similar to Towards Achieving Execution Time Predictability in Web Services Middleware

Similar to Towards Achieving Execution Time Predictability in Web Services Middleware (20)

Recently uploaded

Recently uploaded (20)

Towards Achieving Execution Time Predictability in Web Services Middleware