## 1 Introduction  
The Web is designed for humans _i.e._, web pages are designed to be read and understood by humans. The Semantic Web, on the other hand, is designed for computers _i.e._, the information content is structured so that machines can understand it. The Semantic Web is a set of technologies, which provide \"semantics\" or meaning to Web content. On the Semantic Web, information is represented as a set of assertions called _statements_. Statements consist of three parts (or _triples_): subject, predicate and object (in that order). The subject is the concept the statement describes and the predicate is the relationship between the subject and the object. RDF, a W3C specification, is the Semantic Web's data model for representing statements. RDF can be modeled abstractly as a graph. RDF identifiers are URI references and RDF's official standard syntax is RDF/XML [1].  
RDF's strength is describing information. Flexible though it is, RDF lacks explicit support for specifying the semantics behind the descriptions [2]. RDFS (RDF Schema) and the Web Ontology Language (OWL) provide primitives with defined meaning thereby enabling semantics to be added to RDF statements [3, 4]. RDFS provides a type system for RDF. RDFS provides mechanisms to specify classes, properties and hierarchies of both. OWL builds on top of RDFS and provides extra primitives to add further semantics. RDFS and OWL enable ontologies to be constructed. \"_An ontology defines a set of representational primitives with which to model a domain of knowledge_\" [5]. The primitives are typically classes, attributes and the relationships between class members.  
Summary of previous contributions [6]:This paper extends previous work in which the following conclusions are detailed:  
* Implemented, tested and demonstrated a client-side configuration wizard and protocol adapter, collectively named StoRHm (SOAP to RESTful HTTP mapping). Note that the protocol adapter is unchanged between StoRHm v1 (outlined in [6]) and StoRHm v2 (outlined in this paper); where necessary, the version numbers will be used to differentiate between them.
* StoRHm transforms opaque SOAP messages to visible RESTful format supporting all of REST's constraints, enabling the Web and its inherent efficiencies.
* StoRHm enables SOAP clients to interoperate with RESTful WS.
* StoRHm is a gradual migration enabler from SOAP to RESTful WS.
* The protocol adapter in StoRHm imposes a 6-7% time penalty and relates to deployment of the adapter on a local machine.  
There are two constraints imposed:  
* RESTful Web Services responding to PUT/POST receive the SOAP payload untouched.
* Complex SOAP requests which map to more than one logical URI will be mapped to POST with the SOAP payload passed on untouched.  
The problem and motivation for the solutionThe manual nature of the configuration wizard implemented in [6] is outlined in Figure 1:The issue with Figure 1 is that the user must manually type in a lot of data, select multiple drop down list boxes and select various check boxes and radio buttons. This is both time consuming and error prone.  
Our hypothesis is that a state of the art solution leveraging SWS technologies would automate this element. This would reduce the time spent and errors made in generating the mapping file. In addition, as the protocol adapter element of StoRHMm was tested on a local machine, the authors wish to determine its performance when deployed on the Internet.  
The remainder of this paper is organised as follows: Section 2 is Related Work, Section 3 is the Technology Overview, Section 4 describes StoRHMm v2, Section 5 is the Testing section, Section 6 is the Evaluation section and lastly, Section 7 outlines our Conclusions and Future Work.