## 4 StoRfm v2
### Example
#### 4.5.3 Ontology Example
Thus, with the semantic concepts of MicroWSMO informing StoRHMm _where_ to insert the data in the RESTful URI; and the CSV, with its in-built XPath expressions based on SOAP element names, informing StoRHMm _what_ data to insert; StoRHMm is able to transform the SOAP message to RESTful format without the need for lifting/lowering. This means that the ontology is used for matching operations and determining the QoS associated with the relevant operations. ### Research Methodology

The research strategy used for the software artefacts was design and creation. Experimentation was the strategy used for testing and performance measurement of the framework. The data generation method is document based _i.e._, the generated CSV file, SOAP and RESTful HTTP messages were examined as part of testing. Lastly, the data analysis method is qualitative. ## 5 Testing

StoRHm v2 was tested in an Internet based setting (as opposed to StoRHm v1 which was tested on a local machine). In this section, the test environment is outlined and performance of the adapter is analysed. ### Test Environment

A test environment has been implemented in an Internet based setting (see Figure 10). The client machine is a Dell Optiplex 780 desktop machine running Windows 7 with 4 GB RAM and Intel Core2 Duo CPU processors. The server is a Dell Dimension 8400 running Windows XP with 3 GB RAM. One of the Dell machines hosts the client and protocol adapter software while the other machine hosts the server software and database. Glassfish [22] is the application server used. The server machine is connected to the Internet via a 3 Mb/sec ADSL line. ### Test Results

While performance is not central to this research, performance is an important consideration for any distributed technology and therefore the latency delay due to the introduction of the adapter was

Figure 10: Test environment. measured. One of the standard measurements taken is the \"_round-trip method invocation time_\" which is the time difference between the client invoking the remote method and the remote method returning its results [23]. In Table 1, we present performance tests comparing the round-trip method invocation times (in msecs) of a normal SOAP WS request with that of the same SOAP request routed via the adapter to its equivalent RESTful WS. The Web Services were deliberately chosen so as to map to different HTTP verbs: _ServiceView (GET)_; _ServiceAdd (POST)_; _ServiceDelete (DELETE)_ and _ServiceUpdate (PUT)_. Note that the adapter-based figures represent a worst-case scenario _i.e._, a full round trip on each occasion with no efficiencies such as caching implemented. Each SOAP WS was directly accessed (no adapter) 100 times in order to get an average delay. In addition, the following statistical values were also recorded: the standard deviation, standard error and low and high values (with 95% confidence). The tests were then repeated 100 times with the client accessing the RESTful Web Services via the adapter and the results recorded again. In situations where the adapter maps to PUT or POST, the adapter performs **no** parsing and the entity body (of the RESTful HTTP request) contains the original SOAP message request. As Table 1 shows, there is a 4-8% penalty for inserting the adapter into an infrastructure. ### Statistical Analysis of Results

**Table 1**-In this scenario, a one-tailed test is appropriate. At the 95% significance level, the t-table value is 1.645. All rows are applicable in Table 1. _ServiceView_, _ServiceAdd_, _ServiceDelete_ and _ServiceUpdate_ have test statistic values of 3.45, 2.23, 3.39 and 2.67 respectively. As all values are greater than 1.645, the alternative hypothesis is therefore accepted _i.e._, the average time taken to route