Skip to Content

Fakultät fü Informatik TU Wien Distributed Systems Group Distributed Systems Group
Top-level Navigation: Current-level Navigation:

Path: DSG > research > prototypes > VRESCo > Experimentation

Tools: Drucken

Accompanying Material to the Paper
"Towards Cost-based Optimization of Service Compositions"


This web page contains additional information regarding the experimentation presented in Section 6 of the paper Towards Cost-Based Optimization of Service Compositions. The experimentation of this paper has been based on the following case study (for some more details see the paper). We provide a peliminary version of the paper as technical report. The paper is currently under peer-review at IEEE Transactions on Servies Computing.

Case Study. Click to enlarge

We have implemented (parts of) the case study using .NET Windows Communication Foundation (WCF) technology and the VRESCo SOA runtime environment on a server running Windows 2007 SP2. The server machine was equipped with 2 2.99GHz Xeon X5450 processors and 32 GByte RAM. We used a MySQL 5 database as a data backend, and deployed all necessary components on the same server machine to reduce the impact of external aspects such as network latency on our results.

We implemented the case using Windows Workflow Foundation and the Code Behind model (no XAML). Click here to see a graphical representation of the implemented Windows Workflow model. All the orange boxes are Web service invocations carried out using a custom activity, which uses VRESCo to dynamically find a suitable service and invoke it (rebinding proxies, as discussed here). The current Sourceforge version of VRESCo contains this very example project. The Web services which are invoked in the service composition are implemented in the project AssemblyAtomicServices. The composition itself can be found in AssemblyWorkflow. Finally, there is a client application that can be used to issue requests to this service composition (AssemblyClient). See the bottom of this page for some help on installing and running this example.

Training Data Set

In order to train the system we have generated a set of 9796 historical composition instances. These instances were created by executing the service composition repeatedly. In this historical data set, 3660 instances have not been adapted, while one or more adaptation action has been applied in the remaining 6136 instances. Please find the complete data set here. Every line in the file is a single instance. Every line is a whitespace-separated list of values. Some values contain whitespace, they are enclosed with ' ' (e.g., 'Town Car'). The special character ? identifies a missing value. The first value in each row is an UUID identifying the instance. The next 40 values are various metrics which can be monitored from the running instance, such as response times of services, the ordered product, the duration of subbranches, and similar. The remaining values are indicators of whether a given adaptation action has been applied to this instance. 1 indicates that this action has been applied, 0 that it has not been applied. The data set is formatted in WEKA ARFF format, so that the data set can be loaded and analyzed easily using the WEKA machine learning toolkit. The technical definitions of each monitored metric in the data file can be found in the file AssemblyClient\assembly_optimization.cpdl.xml (also part of the Sourceforge VRESCo distribution).

Penalty Functions

For this service composition we have defined 5 Service Level Objectives (SLOs): Order Fulfillment Time (attribute DELIVERY_TIME in the data set), Payment Time (PAYMENT_PROCESSING_TIME ), Shipping Time (SHIPPING_PROCESSING_TIME), Product Quality (QUALITY) and Cost Compliance (ADDITIONAL_COSTS). Order FulFillment Time has been associated with a staged penalty (the minimal penalty is 9000 for a SLO value larger than 37000), Payment Time and Shipping Time have both been associated with a fixed penalty (penalty 1000 for payment time longer than 4150 and 9000 for a shipping time longer than 1300). Product Quality has been associated with a linear penalty with cap (for each quality category worse than 3 a penalty of 2000 has to be paid, up to a maximum of 12000). Finally, Cost Compliance also has been associated with a simple linear penalty. Once again, the exact technical definitions can be found in the file AssemblyClient\assembly_optimization.cpdl.xml.

Basic Statistics of SLOs.

In the table above we have summarized the basic statistics of the SLOs in the training data set (see above). For each SLO we have provided mean value and standard deviation among unadapted and adapted instances, and the violation threshold in the SLA.

Adaptation Actions

Furthermore, we have implemented a set of 39 different adaptation actions which can be used to influence the SLOs. We have defined 3 types actions. Firstly, we can increase the priority of the services used in the activities "schedule_construction", "ship", "generate_invoice", "request_cc_authorization", and "credit_cc". The default priority for each service is 5. We can increase the priority from 6 to 10. Increased priority reduces the product quality and leads to additional cost, but reduces the service invocation time. These actions are conflicting, i.e., for every service only one priority can be set. Furthermore, for the same services it is also possible to set 4 different invocation classes (a to d). These reduce the invocation time further, and are not conflicting. Finally, we have defined three additional actions which add 1, 2 or 3 additional quality steps. Additional quality steps incur costs and increase the process duration, but improve product quality. These 3 actions are mutually exclusive. All actions have been associated with costs. please find some more information on these actions here. This file contains all action names (first column), their costs (second column), and the impact values of the actions as calculated from the training data set (all following columns). The concrete formula for calculating these impacts is described in the paper (Equation 8). Finally, as always, the technical definition of the actions can be found in the file AssemblyClient\assembly_optimization.cpdl.xml.


In the paper some experiments are discussed which have been carried out based on this experimental setup. Please refer to the paper itself for reports on the findings. For your convenience, we provide the raw data and the gnuplot configuration files that have been used to generate the plots in the paper here: Figure 11 Config, Figure 11 Data, Figure 12 Config, Figure 12 Data, Figure 13 Config, Figure 14 Config, Figure 13 Data. The data for Figure 13 and Figure 14 is contained in the same data file.

Background Information: Tool Setup

The experiments and data described in the paper can be (re-)produced using the VRESCo software packages available at Sourceforge and various open source software. In this section we will briefly summarize the necessary setup steps, however, since the setup process is not trivial, we propose to get in touch with us before trying to set up the testbed. This way we can help directly with setting everything up and smooth things along. A more comprehensive installation instruction is still work-in-progress.

  1. The first step is to get the VRESCo software running. Follow the installation instructions available from the VRESCo project web page. Use this package to install VRESCo, it contains the assembly compositiojn example discussed here. Since VRESCo is implemented in the C# programming language and heavily uses Microsoft WCF you need a Windows machine to install VRESCo on. Optimally, this machine should also be running Internet Information Services (IIS).
  2. For these experiments we need a number of different (additional) MySQL databases. Create 3 empty databases "vresco_client", "branimon" and "experiments". Use this DDL file to initialize the experiments database. All other databases will be managed by Hibernate.
  3. Next, you need to install Branimon. Branimon is a Java package available as source code under the Apache 2 licence from the VRESCo Sourceforge home. In a nutshell, Branimon is a relatively small wrapper for the machine learning toolkit WEKA. Download the ZIP file, unpack it, download its dependencies (WEKA, Daios, Apache CXF, MySQL Connector for Java, Hibernate, and Apache Ant, and put all these Jar files into the Branimon lib directory. Execute "ant clean build BranimonLauncher". A small CXF RESTFul Web service should now be starting up.
  4. Now you need to register the Web services used in the case study in the VRESCo service registry. To help you with this task we provide a small tool as part of the VRESCo Sourceforge package (AutomatedServicePublisher). Make sure that the App.config file of this project is configured to access your VRESCo instance, and run the tool. Check that all Web services that are defined in the AssemblyAtomicServices project have been entered into the VRESCo database.
  5. Now you should be good to go. Start up the test Web services (AssemblyAtomicServices), make sure that the Branimon service and the MySQL database are still up and running, and execute the service composition using AssemblyClient. You should see in the console of your Web services that the services are invoked. Check the static fields of the client (in AssemblyClient.Program.cs) to see what parameters you can experiment with. Detailed descriptions of these parameters are still work in progress.

Home / Kontakt / Webmaster / Offenlegung gemäß § 25 Mediengesetz: Inhaber der Website ist die Fakultät für Informatik an der Technischen Universität Wien, 1040 Wien. Die TU Wien distanziert sich von den Inhalten aller extern gelinkten Seiten und übernimmt diesbezüglich keine Haftung. / Disclaimer.