Improving the Performance of Service-based Applications by Dynamic
Service Execution
Hong Liu Xiaoning Wang Tian Luo Xiaosong Li Wei Li
Institute of Computing Technology of Chinese Academy of Sciences, Beijing, China
Graduate School of the Chinese Academy of Sciences, Beijing, P.R. China
{liuh, wangxiaoning, lixiaosong, luotian, liwei}@ict.ac.cn
Abstract
Distributed applications are increasingly being
built by Web services. This paper explores a dynamic
service execution technique and based on this
technique, we design and implement a virtual machine-
based runtime environment called Abacus Virtual
Machine (AVM). With the help of stateless property of
Web services and a runtime dependence analysis
technique, AVM determines the data dependence of a
service invocation and executes independent service
invocations concurrently. In this way, it is able to
exploit parallelism of service-based applications written
in a sequential programming model, which is a
conventional model for developers. At the same time,
AVM also need to make balancing between the goal of
exploiting parallelism and the cost brought by the
dynamic service execution. Our experiments show that
the cost is no more than 9% of CPU time and 10%
memory cost. We believe that the penalty is acceptable
for the benefits that AVM provides.
1. Introduction
Web Services [12], which is designed to support
interoperable machine-to-machine interaction over a
network, has been an important enabling technology
for distributed systems . Service-based applications are
built by services that have a network-addressable
interface and communicate via standard protocols and
data formats.
Web services in service-based applications are
distributed in different hosts and processes of these
services are inherently able to be executed in parallel. In
current web service programming models, a number of
services need to interact with one or more other
services to complete its functionality. Therefore, it is
feasible that the response time of a service can be
reduced by concurrently executing the invocations
inside this service. Furthermore, overlapping
invocations can also tolerate the latency brought by
the message passing between sites.
The early practices of services-based developing
and hosting environments, such as Apache Axis [2],
offer only synchronous interactions, primary over
HTTP/SOAP. Current service-based environments,
such as Apache Axis 2 [3], supports asynchronous
Web services and asynchronous invocations using
non-blocking clients and transports, which greatly
eases developers from writing complicated concurrent
code to implement simultaneous service invocations.
However, developers still have to explicitly manage the
control flow of concurrent invocations. When the
application’s complexity and scale increases, it will be
hard to optimize the performance of applications by
manually managing control flows. In fact, if the hosting
environment can automatically execute service
invocations concurrently, writing service-based
applications can be easier at the same time the
performance of applications can be improved. However,
there is little effort on offering implicit simultaneous
service invocations in most of current service-based
related environments.
Furthermore, from the standard definition of W3C
[19], a Web service is a stateless entity that can perform
specific functions. This feature make s service
computing different from other distributed systems
such as distributed object system whose entities are
stateful in default. Although in some Web services
architectures [6] [8], state is a matter of concern. The
hosting environments of service-based applications are
capable of knowing whether a service is stateful or
stateless. While in other distributed systems, for
example the distributed object system, it is hard to
analyze whether an invocation of a method will change
the global state of the application.
This paper presents a dynamic service execution
technique with the leverage of stateless property of
Web services to improve the performance of service-
based applications implicitly. Based on this approach, .
we design and implement a distributed virtual machine
called Abacus Virtual Machine (AVM). Using AVM,
developers can write service-based programs in the
conventional sequential programming model. At the
same time, AVM can dynamically schedule service
execution concurrently to improve the performance
while maintaining the correct data flow of application.
The rest of the paper is organized as follows. Section
2 further introduces the motivation of our work. Details
of design and implementation are presented in Section 3.
Section 4 evaluates our system. Section 5 and 6
provides the related work and concluding remarks
respectively.

2. Motivation
Taking advantage of parallelism is one of the most
important methods for improving performance of
distributed applications. In current web service-based
applications, a service is a software agent that
distributed in network [19]. Therefore, service’s
operation is inherently capable of being processed in
parallel and the key is how to make the service
invocations executed concurrently at the caller side.
Currently, the most common approach is writing
concurrent programs by approaches such as
multithread or event-driven programming. That is,
developers should manually analyze which services can
be invoked simultaneously and explicitly write codes to
invoke services in parallel. Some applications,
especially the so-called “embarrassingly parallel”
applications, can fit the concurrent programming model
nicely. However, for applications that is not well
structured and regular, concurrent programming is Figure 1. The Operation Sequence of the
usually a burdensome and error-prone job. Just as Travel Agent Web Service
Sutter and Larus observe [7], “Humans are quickly Another approach is exploiting parallelism via the
overwhelmed by concurrency and find it much more run-time system. For example, in computer hardware
difficult to reason about concurrent than sequential design, a processor can execute several instructions in
code. Even careful people miss possible interleaving pipeline. The success of the run-time approach
among even simple collections of partially ordered depends on techniques to solve two problems , first is
operations”. Consequently, it’s a natural conclusion: how to determine the parts of a program that can be
“Concurrency is fundamentally hard; avoid whenever executed concurrently at the runtime; second is how to
possible”[10]. determine the dependence between concurrent units.
How to avoid concurrent programming while still For example, in CPU, the concurrent part is an
make the modules of programs run concurrently? One instruction and CPU is able to check the dependence
possible solution [13] [16] is automatically exploiting between instructions.
parallelism in sequential programs by compilers. Therefore, in order to support the automatic
However, these automatic techniques mainly focus on parallelism, we should solve the above two problems in
the “embarrassingly parallel”programs but not general- service-based application. We now introduce a use
purpose programs . case, travel agent application provided by W3C [23], to
explain the possibility of a successful run-time
approach.
 Figure 1 shows the operation sequence of the travel
agent Web service. In this example OP1, OP2 and OP3
can be executed concurrently. Because of the data
dependence, OP4 and OP5 can’t be processed until the
OP1, OP2 and OP3 finished. But the OP6, OP7, OP8 is
able to be continued without the return of OP1, OP2
and OP3. Similarly, OPi9, OP10 can’t be executed until
the OP6, OP7 and OP8 returned. OP 11, OP12 and OP13
also have their depended operations.
We can find out that in a service-based application,
the first problem is rather easy. A parallel part is exactly
a service invocation. The difficulty lies in how to
determine whether an invocation is able to be executed.
However, with the run-time data dependence analysis
technique, the run-time environment is able to make the
decision. For example, the OP12 depends on the
reserved ID and the Authorized ID. Therefore, the
runtime environment must check that whether the OP 10
and OP 11 has finished and decide whether OP12 can
be executed.
In this use case, in order to automatically parallelize
the execution of service-based applications, a run-time
environment should first be able to determine the
parallel granularity for a service-based application. Next,
it should be able to analyze the dependence of the
parallel part, which in this case, is a service operation.
At last, when the program is running, it should be able
to dynamically execute independent services
simultaneously. These issues are the most important
considerations when we design and implement the
Abacus Virtual Machine.
3. Design and Implementation of AVM
In this section, we introduce design and
implementation of Abacus Virtual Machine, which is a
run-time environment for service-based application that
supports implicit parallelism via a dynamic service
execution engine.
3.1 Design Objectives of AVM
We have distilled following design objectives central to
the success of our work:
l Sequential programming model for developers:
The developers just write sequential program and
need not explicitly write concurrent program. The
conventional sequential programming model is
maintained.
l Implicit parallelism at service level: For a
sequential service-based application, at runtime,
AVM will automatically detect the data
dependences between service invocations and
execute independent services concurrently.
l Reducing cost: Run-time parallelism detecting
and dynamic service execution will bring extra
processing and memory costs. So another
important design goal is to reducing costs
brought by AVM when bring performance
benefits to service-based applications.
3.2 Design Principles
In Section 2, we summa rized three key issues of the
automatically concurrent run-time environment. First, it
is able to automatically determine the concurrent
granularity; second it is capable of detecting whether
the concurrent unit can be executed. At last, it can
execute independent services invocation
simultaneously.
For the first issue, AVM adopts a service invocation
as the basic unit of parallelism. As mentioned before,
the stateless property of Web service is the key for us
to implement implicit parallelism for service-based
applications. Therefore, AVM needs mechanisms to
recognize which entity is a service. In AVM, service is a
fundamental abstraction, and operations on services,
such as creation, invocation are virtualized to a normal
instruction of virtual machine. The virtual machine just
regards a service invocation as an ordinary operation
that has long and uncertain latency.
For the second issue, the dependence analysis
module of AVM can detect the dependence between
instructions. If instruction i depends on a long-running
instruction j, which is usually a service invocation
instruction, AVM will delay the execution of i until j is
finished. Using an appropriate dependence analysis
policy, the virtual machine can guarantee the
correctness of data flow.
For the third issue, as mentioned in Section 2, the
dynamic execution engine of AVM can execute two or
more service invocations simultaneously. Whether a
service invocation depends on other instruction is
determined by dependence analysis module .
3.3 Overview of AVM’s Implementation
AVM is a language level virtual machine providing
an executing environment for service-based
applications. In AVM , service is a fundamental machine
abstraction, which conforms to the Web services’
definition provided by W3C [19] and the operations on
services are abstracted to instructions of AVM.
On top of AVM, we provide a service-oriented
programming language called Abacus, which is
designed as a language level developing tool. Details of
the language can be found in [20].The core concept of
Abacus is the service construct. In fact, a service is a
first-class object in Abacus language. Due to the
intrinsic loosely-coupled nature of a service, Abacus
does not support inheritance and polymorphism
features of object-oriented programming languages.
Developers write Abacus Language source codes and
compile them to bytecode that is composed of AVM
instructions.
AVM is an innovative hosting environment for
service-based application. But it does not mean that we
have to build it from scratch. Since it is also a process-
level virtual machine, the design of instructions of
AVM refers to a more popular process-level virtual
machine, JVM. To support service operations, AVM
provides a set of service-related instructions. Each
instruction indicates a general operation on services. In
the prototype of AVM, we mainly take three operations
into account: deploying, invoking and destroying a
service. In addition, AVM is built on the top of the
freely available Kaffe virtual machine [14], further
information on AVM can be found in our website [1].
Figure 2. The AVM System Overview
As shown in Figure 2, AVM system is mainly
composed of three parts: dynamic execution engine,
dependence analysis module and embedded service
container. The embedded container has two major
functions. One is to host services of AVM. When a
request arrives, it creates an execution thread to
process the request; the other is to provide an
asynchronous service invocation mechanism. When an
invocation instruction is executed, AVM sends the
message to the destination service and returns
immediately. When the response comes back, the AVM
receives the response message and notifies the
corresponding thread. The asynchronous service
invocation is the foundation of dynamic execution
engine. Due to their importance in this paper, the details
of dynamic execution engine and dependency check
module will be introduced in the following section
separately.
3.4 Dynamic Execution Engine
The dynamic execution engine is the core of AVM
system. Like other process-level virtual machine, AVM
executes the instruction flow of application and
maintains the run-time data structures such as PC
register, heap and stack. AVM has a stack-based
architecture and every instruction operates on data on
stack.
The difference between the execution engine of
AVM and other virtual machine is the dynamic
execution engine which is able to rearrange the
instruction execution. Since service invocation will
bring long and uncertain latency, dynamic execution
engine takes advantage of an asynchronous invocation
mechanism to make the invocation instruction return at
once. If an instruction depends on the data returned by
a former invocation instruction, the execution engine
will issue the next instruction to execute. In this way,
AVM allows the overlapping execution of two or more
invocation instructions.
The idea behind the dynamic execution engine is
similar to that behind the dynamic scheduling
processor. It also implies instruction out-of-order
execution, which introduces the possibility of WAR
and WAW hazards. Like sophisticate dynamic
scheduling techniques used in the design of processor,
for example, Tomasulo approach [25], AVM also use a
software reservation stations to avoid these hazards.
3.5 Dependence Analysis Module
There are two main goals of the dependence
analysis module. First, it must ensure that the
application’s data flow will not be destroyed by the
instruction scheduling; second, with the help of
compiler, it will try its best to find the permission of an
invocation instruction to be executed.
To fulfill the first goal, AVM must analyze the data
dependence and the control dependence of every
instruction and decide whether it can be executed. This
technique has been widely used in the processor
architecture, and we implement a software version.
However, the question is, as the dependence analysis
by hardware can be executed in pipeline, how the
dependence analysis by software will be efficient
enough to not impair the performance. The answers to
this question are: first, unlike the dependence analysis
by hardware, in AVM, the dependence analysis only
happens in the situation that reservation stations is not
empty, which means that some invocations’results
haven’ t returned yet. Indeed the process of
dependence analysis process overlaps some invocation
instructions execution. Second, for most of instructions,
the dependence analysis just cost a few CPU cycles
and does not seem to be a problem in practice. The
results of our e xperime nts validate above analysis.
For the invoke instruction, AVM not only checks its
data dependence, but also checks whether it will
change the state of the application. In AVM, it’s
assumed that the virtual machine is able to know
whether a service will use and change the data not
contained in its input message. A service that don’t
use the data not contained in the input message is
called a stateless service, and a contrary service is
called stateful service.
Because AVM does not know which state that a
called service operation will change, the default
dependence analysis policy is that if an invocation of a
stateful service hasn’t completed, AVM will not execute
any other invocation instructions. With the help of the
abacus compiler, AVM is able to know whether an
operation will change other services’state. Therefore, it
is safe to execute two instructions or invoke
instructions simultaneously if these instructions will
not change other’s state, or these instructions will not
invoke an identical service.
4. Evaluations
We have listed the three objectives in Section3.1.
The first one is a functional objective. In this section,
we will use a set of experiments to measure whether our
system achieves the last two objectives.
4.1 Evaluation Programs
NGB (NAS Grid Benchmarks) [15] is a benchmark
suite for grid computing. It is evolved from NPB (NAS
Parallel Benchmarks) [5], which is widely used on
parallel computing systems. In NGB, there are five basic
tasks (i.e. BT, FT, LU, MG, SP) on behalf of various
type of scientific computation, and these tasks
construct four problems representing four typical
classes of grid applications, named respectively
Embarrassingly Distributed (ED), Helical Chain (HC),
Visualization Pipe (VP), and Mixed Bag (MB). ED
requires no communication, and all tasks are executed
independently. It tests basic functionality of grids and
does not tax their communication performance. HC is
totally sequential. Hence, any time spent on
communicating data between two tasks is fully exposed.
VP requires specifying concurrent execution of tasks
with nontrivial dependences. It allows pipelining and
overlapping communication times with computational
work. MB is similar to VP, but tasks have different
computational work and control flow.
In our implementation of the NGB programs, every
task is a service written by Abacus. We also write a
NGBServer service. Clients can invoke a method of
NGBServer service to perform a specified problem.
Appendix 1 gives the Abacus code of MB problems.
4.2 Test Environme nts.
All measurements reported in this section were
performed in a cluster consists of 9 PC servers with
dual AMD Opteron 248 processors, 2GB of RAM. The
servers are connected by a 1000Mb Ethernet. The
operating systems on these servers are Redhat Linux
with kernel 2.4.21.
The four types of problems have different control
flow and data dependence between tasks. Only problem
ED is able to make use of all machines since each task
of it have no dependence on one another. HC
represents a sequential problem and cannot be
executed in parallel. The VP and MB’ s degree of
parallelism is in the middle and run three tasks
simultaneously at most, so we assigned three servers to
run the two problems.
4.3 NGB Test and Result Analysis.
In order to test AVM ’s ability to automatically
exploit parallelism in programs and the overhead
brought by our implementation, we developed two
versions of execution engine for AVM, one supports
sequential service execution and the other supports
dynamic service execution.
We also wrote a sequential NGB program and a
multi-thread NGB program. For the multi-thread program,
we carefully wrote the service invocation and
synchronization code to exploit the maximal parallelism.
Therefore, the multi-thread NGB program can be regard
as the ideal result.
4.3.1 Performance Comparison
In our experiments, we ran the sequential NGB
program both on the sequential execution engine and
the dynamic execution engine and the multi-thread NGB
program on the sequential execution engine to evaluate
of our approach. The test has been done repeatedly
and the absolute deviation of each result never exceeds
1 second. The average results are showed in Fig. 3, in
which S-NGB stands for the sequential-version of NGB;
T-NGB stands for the thread-version of NGB; SEE
stands for the sequential execution engine and DEE
stands for the dynamic execution engine.
As shown in Figure 3 and Table 1, the results of
execution time of S-NGB program on DEE VM is close
to the results of T-NGB program and is far less than the
 results of S-NGB on SEE VM. Due to the dynamic
execution engine, the DEE VM has great performance
improvement and exploits nearly the same degree of
parallelism as the ideal result in our evaluation
environment.
Considering the overhead of thread, it is not ama zing
that the execution time of ED and HC on DEE VM is a
little shorter than that of T-NGB on SEE VM. The data
dependences between tasks of those two problems are
relative simple and just cost negligible CPU time to
detect them in dynamic execution engine.
800
by dynamic execution engine is acceptable(less than
3% of CPU time). We still need to test the extra
resources consumed such as CPU time and memory.
First, we used UNIX command “time”to measure the
CPU time of the NGB program. The goal of this test is to
reveal the extra CPU cycle used in dynamic execution
engine than the sequential execution engine.
Theoretically, the CPU time of thread-version NGB
program is the CPU time of sequential-version NGB
program adds the CPU time of thread-related operation.
So we only compare the results of sequential-version of
NGB program on DEE VM and those of SEE VM.
２５

700
２０
600
１５ Ｕｓｅｒ　ｔｉｍｅ
500 Ｓｙｓ　ｔｉｍｅ
S-NGB on SEE VM １０ Ｔｏｔａｌ　ｔｉｍｅ
400 T-NGB on SEE VM
S-NGB on DEE VM
300 ５

200
０
ＳＥＥ ＤＥＥ ＳＥＥ ＤＥＥ ＳＥＥ ＤＥＥ ＳＥＥ ＤＥＥ
100
ＥＤ ＨＣ ＶＰ ＭＢ
0
ED HC VP MB Figure 4. CPU Time Comparison
Figure 3. Performance Comparison
Second, we measure the maximal memory cost of the
NGB program in both DEE VM and SEE VM.
Table 1. Speedup of NGB Programs
　 S-NGB on T-NGB on SEE VM S-NGB on DEE ２５００００
SEE VM VM ２０００００
　 Execution Execution Speed Execution Spee １５００００ ＤＥＥ　ＶＭ　Ｍｅｍ（ｋ）
Time Time up Time d up １０００００ ＳＥＥ　ＶＭ　Ｍｅｍ（ｋ）
５００００
ED 670.576 79.34 8.45 79.045 8.48
０
HC 103.49 106.941 0.97 104.924 0.99 ＥＤ ＨＣ ＶＰ ＭＢ

VP 540.033 353.161 1.53 356.385 1.52 Figure 5. Memory Cost Comparison

MB 348.92 133.735 2.61 137.111 2.54
Comparing to the SEE VM, the DEE VM use extra
CPU time to dynamic analyze instruction’s dependence
For programs that have complex control flow inside,
and manage the reservation stations. In addition, DEE
such as VP and MB, the execution time of DEE VM is
VM allocates memory to hold the dependence of every
about 1 to 2 percent more than the T-NGB’ s execution
unit of the runtime stack and the data structure of
time. Thread approach benefits from the manual
reservation stations. The data above reveals that our
configuration of concurrency, while our approach
approach consumes from 4% to 9% total CPU time more
needs to exploit parallelism at run time instead of
than sequential execution engine. At the same time, the
executing a pre -given configuration.
extra memory cost of the dynamic execution engine is
less than 10% of the total memory cost. We believe that
4.3.2 Overhead Anal ysis
the overhead is reasonably acceptable.
The previous test shows that the dynamic execution
engine is able to exploit a satisfactory degree of
parallelism and it also seems that the overhead brought
5. Related Work
To reduce the response time of service-based
applications, it is a feasible approach to invoke services
in an overlapping way. In the current Web services
environments, there are two classes of approaches that
can invoke services in parallel:
The first class is the concurrent programming
approach. WS-Eventing [18] and WS-notification [19]
provides specifications for the asynchronous,
message-based interactions in service-based
interaction, by which, developers can invoke services
by using the event-driven model. I. Silva-Lepe [9]
provides an approach to integrate the message-based
model to the Web services programming model. AXIS2
[3] also provides the asynchronous invocation APIs for
the development of service-based applications. Though
the above work can reduce the complexity of writing
concurrent service-based programs to some extent, the
development of event-driven programs is still far from
easy. Furthermore, event-based programming tends to
obfuscate the control flow of the application [21].
The second class is using business process
execution engine, for example, BPEL [4], by which
developers are able to allow several service invocations
be executed in parallel. M. Nanda [11] introduces a
decentralized approach to increase parallelism and
reduce the amount of network traffic required for a
service-based application. However, firstly,
programming in BPEL still requires developers to deal
with parallelism manually. Second, BEPL is a
programming in large model of language. It mainly used
to describe the interactions between services but not to
implement a service itself.
Besides the service-based environment, there are
also considerable projects aimed at automatic
parallelization technology for distributed applications.
U. Banerjee [16] presents an overview of automatic
program technique. Their technique works
comparatively well for regular applications, but they
handle only a few patterns of irregularity. The zJava
system [24] tries to exploit parallelism among methods
by creating an asynchronous thread of execution for
each method invocation in a program. Methods are
analyzed to determine the data they access at compile
time. Unlike in our system, in which the basic entity,
service, is inherently stateless and distributed, in
method-level-parallel systems the potential for
exploiting parallelism is limited and often need
developers carefully choose the granularity of methods.
Promise pipeline technique [22] is used in actor-
based system to reduce latency in distributed systems .
Using the abstraction of future, the system can execute
RPC in pipeline. With the help of compiler, it can hide a
portion of concurrent process from developers . But
developers are still required to analyze the data
dependence within program manually and write the
concurrent program explicitly.
6. Conclusions and Future Work
In this article, we introduce a dynamic service
execution technique to improve the performance of
service-based application. Using this approach,
developers are able to benefit from the overlapping of
services ’ invocation while avoiding the trouble of
writing tedious, error-prone concurrent programs. We
design and implement a distributed virtual machine run-
time environment to bring this technique into effect.
According to our evaluation, the goals of our technique
are achieved and the cost is reasonable.
We have presented a first cut at dynamic service
executing environment. In the future, with the help of
compiler, we will improve the dependence analysis
policy, which will further exploit parallelism. In addition,
how to manage services in our environment to reduce
the real execution time of service-based applications is
also part of our future work.
Acknowledgement
This work is supported in part by the National
Natural Science Foundation of China (Grant No.
60573102, 90412010), the 973 Program (Grant No.
2003CB317000, 2005CB321800), and the Chinese
Academy of Sciences Hundred-Talents Project (Grant
No. 20044040). The authors are very grateful for these
supports. We would like to thank Hao Wang, Peixu Li,
Rubao Li for their suggestions, ideas and enthusiastic
support.
References
[1] AVM, http://abacus.ict.ac.cn/.
[2] AXIS, http://ws.apache.org/axis/.
[3] AXIS2, http://ws.apache.org/axis2/.
[4] BPEL,
http://www.ibm.com/developerworks/library/ws-bpel/.
[5] D. Bailey, E. Barscz, The NAS Parallel Benchmarks.
Technical Report NAS-94-007, NASA Advanced
Supercomputing (NAS) Division, NASA Ames
Research Center, 1994.
[6] Globus Toolkit 4.0,
http://www.globus.org/toolkit/docs/4.0/.
[7] H. Sutter and J. Larus, Software and the concurrency
revolution. ACM Queue, 3(7), 2005.
[8] I. Foster, J. Frey, S. Graham, S. Tuecke, K.
Czajkowski, D. Ferguson, F. Leymann, M. Nally, T.
Storey and S. Weerawaranna, Modeling Stateful [24] B. Chan, T. Abdelrahman, Run-Time Support for
Resources with Web Services. Globus Alliance, 2004. the Automatic Parallelization of Java Programs. The
[9] I. Silva-Lepe, M. Ward and and F. Curbera, Journal of Supercomputing, 28, 2004.
Integrating Web Services and Messaging, IEEE [25] R. M. Tomasulo, “An efficient algorithm for
International Conference on Web Services, 2006. exploiting multiple arithmetic units”. IBM J.Research
[10] J. K. Ousterhout, Why Threads Are A Bad Idea and Development 11:1, 1967.
(formost purposes). Presentation given at the 1996
Usenix Annual Technical Conference, January 1996.
[11] M. Nanda, S. Chandra, V. Sarkar, Decentralizing
Execution of Composite Web Service. Proceedings of
the 19th annual ACM SIGPLAN conference on Object-
oriented programming, systems, languages, and
applications
[12] O. Zimmermann, M. Tomlinson and S. Peuser,
Perspectives on Web Services. Springer, 2003.
[13] P. Wu and D. Padua. Containers on the
Parallelization of General-purpose Java Programs.
Proceedings of the International Conference on Parallel
Architectures and Compilation Techniques, October,
1999.
[14] Kaffe, http://www.kaffe.org/.
[15] R. Wijngaart and M. Frumkin, NAS Grid
Benchmarks Version 1.0. Technical Report NAS-02-005,
NASA Advanced Supercomputing (NAS) Division,
NASA Ames Research Center, 2002.
[16] U. Banerjee, R. Eigenmann, A. Nicolau, and D.
Padua. Automatic program parallelization. Proceedings
of the IEEE, 81(2):211–243, 1993.
[17] Web Services Eventing (WS-Eventing),
http://www.w3.org/Submission/WS-Eventing/
[18] Web Services Notification, http://www.oasis -
open.org/committees/tc_home.php?wg_abbrev=wsn.
[19] Web Services Architecture,
http://www.w3.org/TR/ws-arch/.
[20] X. Wang, L. Xiao, W. Li, H. Yu, Z. Xu, Abacus: A
Service-Oriented Programming Language for Grid
Applications. IEEE International Conference on
Services Computing, 2005.
[21] R. Behren, J. Condit, and E. Brewer, Why Events
are a Bad Idea (for high-concurrency servers).
Proceedings of the 10th Workshop on Hot Topics in
Operating Systems (HotOS IX), 2003
[22] B. Liskov and L. Shrira. Promises: linguistic support
for efficient asynchronous procedure calls in
distributed systems. Proceedings of the ACM
SIGPLAN 1988 conference on Programming Language
design and Imp lementation, 1988.
[23] Web Services Architecture Usage Scenarios,
http://www.w3.org/TR/2002/WD-ws-arch-scenarios-
20020730/.
Appendix 1 task_input=new BMRequest[1];
This section contains code of a primary service task_input [0]=task_result[2];
extracted from the implementation of MB problem of
task_result[5]=task_manager.getExecutor(5).step(task_input);
NGB. The dataflow of MB problem is as follows [15]:
task_input=new BMRequest[2];
task_input[0]=task_result[3];
task_input[1]=task_result[4];

task_result[6]=task_manager.getExecutor(6).step(task_input);
task_input=new BMRequest[3];
task_input[0]=task_result[3];
task_input[1]=task_result[4];
task_input[2]=task_result[5];

task_result[7]=task_manager.getExecutor(7).step(task_input);
task_input=new BMRequest[1];
task_input[0]=task_result[5];

task_result[8]=task_manager.getExecutor(8).step(task_input);
Figure 6. Dataflow of MB Problem
//waits for all tasks finish ed and get s results
The following code just sequentially describes the int finnum=0;
dataflow of MB problem. AVM is able to automatically BMResults ret[]=new BMResults[dfg.getnumNodes()];
execute this section of code in parallel and the speedup while(finnum<dfg_node_num){
is 2.609 on three machines, which is close to the ideal ss.sleep(1);
for(i=0;i<dfg_node_num;i+=1){
speedup of this problem.
if(dfg.getnode(i).getattribute()==1) continue;
//This service needs a taskmanager service that has already been finnum+=1;
deployed
dfg.getnode(i).setattribute(1);
extern TaskManager TaskManager.task_manager;
dfg.getnode(i).setverified(ret[i].getverified());
ret[i]=task_result[i].getResults();
service NGBServer{
}
IOService ios=new IOService();
}
SystemService ss = new SystemService();

published BMResults[] solve_mb_ problem(BMRequest req){

int i;
DGraph dfg=req.getdfg();
int dfg_node_num = dfg.getnumNodes();

// Initialization
for(i=0;i<dfg_node_num;i+=1){
DGNode nd=dfg.getnode(i);
nd.setverified(1);
dfg.getnode(i).setattribute(0);
}

//invokes each task services in sequnce

BMRequest[] task_input = null;
BMRequest[] task_result = new
BMRequest[dfg_node_num];

task_result[0]=task_manager.getExecutor(0).step(task_input);

t ask_result[1]=task_manager.getExecutor(1).step(task_input);

task_result[2]=task_manager.getExecutor(2).step(task_input);
task_input=new BMRequest[2];
task_input[0]=task_result[0];