## 4 StoRfm v2
### Example
#### 4.5.3 Ontology Example
Two factors explain this:

* Firstly, the adapter resides on the local machine and thus the increase in file size is not as influential as it would be if the adapter resided on a remote machine
* Secondly and more importantly, the parsing conducted by the adapter is consistent across all the requests, regardless of file size. This means that, regardless of the increasing file sizes arriving at the adapter, the subsequent RESTful requests emanating from the adapter _are all the same size_. It is interesting to note by comparing Figure 12 with Figure 11 that the penalty imposed by the adapter disappears as the file size increases. The data in Table 1 was generated using a sample industry file of size 1643 bytes. At that file size, the adapter does impose a statistically significant penalty. Point (b) above is best explained with an example. Listing 5 is a sample CSV file segment used by the adapter to map SOAP requests to RESTful HTTP format. Listing 5 states that the SOAP operation _ServiceView_ in the Web Service _BankService_ is mapped to a GET on the URI _[[http://127.0.0.1:3050/RESTServer/BankServices_](http://127.0.0.1:3050/RESTServer/BankServices_)]([http://127.0.0.1:3050/RESTServer/BankServices_](http://127.0.0.1:3050/RESTServer/BankServices_)). The XPath expressions \(\{branchCode\}\) and \(\{accountNo\}\) are used by the adapter to parse these elements from the incoming SOAP message and insert them into the RESTful GET request. Figure 12: Performance–increasing file sizes, static parsing, via adapter. **Listing 5**. : Sample CSV file segment. Listing 6 is the sample _ServiceView_ file used in generating Table 1. On receiving the request in Listing 6, the adapter, informed by the mapping file in Listing 5 generates an HTTP GET request on the URI _[[http://127.0.0.1:3050/RESTServer/BankServices/123456/12345678_](http://127.0.0.1:3050/RESTServer/BankServices/123456/12345678_)]([http://127.0.0.1:3050/RESTServer/BankServices/123456/12345678_](http://127.0.0.1:3050/RESTServer/BankServices/123456/12345678_)). **Listing 6**. : Sample request file that maps to GET. Listing 7 is a larger _ServiceView_ file. The important point here is that, Listing 7 generates the same HTTP GET request even though it is a much larger file-Listing 6 is 1643 bytes in size and Listing 7 is 13,000 bytes in size. ### Parsing requirement

In order to affirm that the penalty imposed by the adapter is a function of the parsing requirement, testing was performed whereby the file size remained constant (the file from Listing 6 was repeatedly used) but the parsing requirement increased. Figure 13 represents the results. As is evident from the graph, the adapter penalty increases in line with the parsing requirement. The correlation value of 0.931 supports this assertion. Thus, there is a strong positive correlation between

Figure 13: Performance–increasing parsing requirement, static file sizes, via adapter. the parsing requirement of the adapter and the response times: the greater the number of XPath expressions to be evaluated by the adapter, the higher the method invocation response times. As stated previously, the authors based their testing on a sample industry file. This file has limited nesting and the evaluation of 10 XPath expressions was more than sufficient. Listing 8 below shows the XPath expressions (enclosed by {}), evaluated by the adapter in the generation of the results for Figure 13. They are listed in order, from 1 to 10, delimited by \"/\". For example, {_branchCode_} requires 1 XPath expression to be evaluated whereas {_branchCode_}/{_accountNo_} requires 2 XPath expressions to be evaluated. Note that the structure of the SOAP message is enterprise-specific which could result in various different levels of nesting within the SOAP message. As a result, we performed extra tests with a different level of nesting. Figure 14 represents the results. The correlation value in this instance is 0.973.