A Semantically Automated Protocol Adapter for Mapping SOAP Web Services to RESTful HTTP Format to Enable the Web Infrastructure, Enhance Web Service Interoperability and Ease Web Service Migration
Summary of previous contributions :
- 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 ) 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.
- 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 solution
2. Related Work
2.1. Integration of Web Services into the Semantic Web
2.2. RESTful WS Semantic Annotation Alternatives
2.3. Automation and Data Mediation
3. Technology Overview
3.1. Semantic Web Services (SWS)
- modelReference–associates, via a URI, a WSDL component with a semantic concept. This attribute is typically used on element declarations, type definitions, interfaces (or port types) and operations.
- liftingSchemaMapping–added to element declarations and type definitions for specifying the mapping from XML to the semantic layer.
- loweringSchemaMapping–added to element declarations and type definitions for specifying the mapping from the semantic layer to XML.
- method (the HTTP method used e.g., GET)
- address (the URI used; may be a URI template)
- model–the href attribute points to an ontology concept or instance.
- lifting and lowering–the href attribute points to the transformations to and from the semantic layer respectively.
- Information model–defines the data model of the service.
- Functional semantics–what does the service do when it is invoked. This can be specified by either:
- ○ Categorisation–simple functionality taxonomies where functionality is organised into a hierarchy of categories. WSMO-Lite offers the RDFS class wsl:FunctionalClassificationRoot to distinguish functional classification hierarchies from normal ontology hierarchies.
- ○ Capability–preconditions and effects. In , a telecoms example has a precondition that the client has to have a minimal bandwidth before the service can be executed and the effect identifies the valid outputs as a result of successfully executing the service. WSMO-Lite offers the RDFS class wsl:Capability and the properties wsl:hasPrecondition and wsl:hasEffect so that preconditions and effects can be setup in an ontology.
- Non-functional semantics–these are incidental details specific to the implementation (or running environment) of a service, independent of the central purpose of the service but necessary for successful completion. Examples would be the price of the service or QoS guarantees. Non-functional semantics are often used for ranking e.g., which service is the cheapest. Non-semantic languages such as WS-Policy are often used to express non-functional characteristics. WSMO-Lite provides the class wsl:NonfunctionalParameter to mark items with non-functional semantics.
- Behavioural semantics–defines the sequence of operations that a client needs to follow when invoking a service. This is done in WSMO-Lite by using functional semantics (categories and/or preconditions and effects). The URI’s of these pieces of functional descriptions are attached to the operation (in either SAWSDL as modelReference or MicroWSMO as model). The client can now reason about which operation can be executed at a particular point in time (i.e., at a particular state in the application).
4. StoRHm v2
- a SAWSDL file representing the semantically annotated SOAP WS description.
- a MicroWSMO file representing the semantically annotated RESTful WS description.
- a shared/common ontology outlining the QoS supported by the WS.
4.3. Design Decisions
4.5.1. SAWSDL Example
- “http://www.leitrimmills.ie/ontologies/BankService#ViewService” (line 50, the operation);
- “http://www.leitrimmills.ie/ontologies/BankService#BranchCode” (line 33, first input parameter);
- “http://www.leitrimmills.ie/ontologies/BankService#AccountNo” (line 36, second input parameter).
4.5.2. MicroWSMO/hRESTS Example
- “http://www.leitrimmills.ie/ontologies/BankService#ViewService” (line 13, the operation)
- “http://www.leitrimmills.ie/ontologies/BankService#BranchCode” (line 18, first input parameter)
- “http://www.leitrimmills.ie/ontologies/BankService#AccountNo” (line 23, second input parameter)
4.5.3. Ontology Example
- Web Service Name and SOAP Operation from the SAWSDL file
- RESTful URI and HTTP verb from the MicroWSMO file
- QoS from the ontology
4.5.4. CSV Example
4.5.5. No Lifting/Lowering Necessary
- a) SOAP is a standard message format and thus its structure is well known; this enables the automatic parsing of the SOAP message as far as the SOAP Body element.
- b) the remaining XPath expressions required to parse the SOAP Body element are obtained from the RESTful URI of the CSV file.
4.6. Research Methodology
5.1. Test Environment
5.2. Test Results
|SOAP Statistics (all figures in msecs)||Average||Standard Deviation||Standard Error||zLow 95%||zHigh 95%||Verb||Adapter +/–||Significant Value95% (+/– 1.645)|
5.3. Statistical Analysis of Results
5.4. Linear Regression Analysis
- a) the size of the SOAP request file and/or
- b) the amount of parsing to be conducted by the adapter
Size of SOAP request file
- a) 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
- b) 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.
6.1. Configuration Wizard
6.2. Protocol Adapter
7. Conclusions and Future Work
- One of the constraints imposed by the architecture is that, in situations where the target HTTP verb to be used is PUT or POST, the entity body of the request is sent on untouched. Typically, the outer element of the SOAP Body element contains the operation to be executed e.g., the WSDL wrapped document-literal pattern enforces this. However, this “operation” element is not needed by RESTful HTTP implementations as the “operation” is identified by the URI coupled with the verb. In order to address this, research is required on XSLT transformations to cater for scenarios as described above, where the XML content to be passed on differs from the XML content received.
- This paper is not centered on performance and consequently the performance tests carried out are indicative rather than extensive. The latency performance of the adapter could be extended. This would include: the performance impact of message reliability and the effect of multiple similar requests with efficiencies such as caching and Conditional GET in place.
- The architecture enables SOAP clients to access pre-existing RESTful HTTP Web Services. The adapter is a client-side migration enabler. Research could be conducted to extend the framework to focus on the server i.e., provide a server-side migration enabler from SOAP WS to RESTful WS. Should an enterprise wish to migrate from SOAP WS to RESTful WS, this new extension would be executed first to migrate the server. With the server migrated, the current framework would then be used to enable the enterprise to gradually migrate the clients.
- Resource Description Framework specification. Available online: http://www.w3.org/RDF/ (accessed on 5 April 2012).
- Hebeler, J.; Fisher, M.; Blace, R.; Perez-Lopez, A. Semantic Web Programming; Wiley: Indianapolis, IN, USA, 2009. [Google Scholar]
- RDF Schema specification. Available online: http://www.w3.org/TR/rdf-schema/ (accessed on 5 April 2012).
- Web Ontology Language (OWL) specification. Available online: http://www.w3.org/TR/owl-semantics/ (accessed on 5 April 2012).
- Gruber, T. Ontology. In Encyclopedia of Database Systems; Liu, L., Özsu, M.T., Eds.; Springer-Verlag: Berlin, Germany, 2008. [Google Scholar]
- Kennedy, S.; Molloy, O.; Stewart, R.; Jacob, P. StoRHm: A protocol adapter for mapping SOAP based Web Services to RESTful HTTP format. Electron. Commer. Res. J. 2011, 11, 245–269. [Google Scholar]
- Battle, R.; Benson, E. Bridging the Semantic Web with Representational State Transfer (REST). J. Web Semant. 2008, 6, 61–69. [Google Scholar]
- OWL-S: Semantic Markup for Web Services. Available online: http://www.w3.org/Submission/OWL-S (accessed on 5 April 2012).
- SAWSDL: Semantic Annotations for WSDL and XML Schema. Available online: http://www.w3.org/TR/sawsdl/ (accessed on 5 April 2012).
- Lathem, J.; Gomadam, K.; Sheth, A. SA-REST and (S)mashups: Adding Semantics to RESTful Services. In Proceedings of International Conference on Semantic Computing, Irvine, CA, USA, 17–19 September 2007; pp. 469–476.
- Kopecky, J.; Vitvar, T.; Fensel, D. MicroWSMO and hRESTS, Technical Report 2009. Available online: http://sweet.kmi.open.ac.uk/pub/microWSMO.pdf (accessed on 5 April 2012).
- Gleaning Resource Descriptions from Dialects of Languages (GRDDL) specification. Available online: http://www.w3.org/TR/grddl/ (accessed on 5 April 2012).
- RDF in Attributes (RDFa) specification. Available online: http://www.w3.org/TR/rdfa-syntax/ (accessed on 5 April 2012).
- SOA4All Core Dashboard tool suite. Available online: http://coconut.tie.nl:8080/dashboard/#1304859734132 (accessed on 5 April 2012).
- Yahoo! Pipes. Available online: http://pipes.yahoo.com/pipes/ (accessed on 5 April 2012).
- Sycara, K.; Pauoucci, M.; Ankolekar, A.; Srinivasan, N. Automated discovery, interaction and composition of Semantic Web Services. J. Web Semant. 2003, 1, 27–46. [Google Scholar]
- Fensel, D.; Fischer, F.; Kopecky, J.; Krummenacher, R.; Lambert, D.; Vitvar, T. WSMO-Lite: Lightweight Semantic Descriptions for Services on the Web. Available online: http://www.w3.org/Submission/2010/SUBM-WSMO-Lite-20100823/ (accessed on 5 April 2012).
- Bizer, C.; Heath, T.; Berners-Lee, T. Linked Data – The Story So Far. Int. J. Semant. Web In. Syst. 2009, 5, 1–22. [Google Scholar]
- Paliwal, A.; Shafiq, B.; Vaidya, J.; Ziong, H.; Adam, N. Semantics based automated service discovery. IEEE Trans. Serv. Comput. 2011, 99, 1. [Google Scholar]
- Maleshkova, M.; Pedrinaci, C.; Domingue, J. Semantic annotation of Web APIs with SWEET. In Proceedings of 6th Workshop on Scripting and Development for the Semantic Web at Extended Semantic Web Conference, Crete, Greece, 31 May 2010.
- Protégé. Available online: http://protege.stanford.edu/ (accessed on 5 April 2012).
- Glassfish Open Source Application Server. Available online: http://glassfish.java.net/ (accessed on 5 April 2012).
- Juric, M.; Kezmah, B.; Hericko, M.; Rozman, I.; Vezocnik, I. Java RMI, RMI Tunneling and Web Services Comparison and Performance Analysis. ACM SIGPLAN Notices 2004, 39, 58–65. [Google Scholar]
© 2012 by the authors; licensee MDPI, Basel, Switzerland. This article is an open-access article distributed under the terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/).
Kennedy, S.; Molloy, O.; Stewart, R.; Jacob, P.; Maleshkova, M.; Doheny, F. A Semantically Automated Protocol Adapter for Mapping SOAP Web Services to RESTful HTTP Format to Enable the Web Infrastructure, Enhance Web Service Interoperability and Ease Web Service Migration. Future Internet 2012, 4, 372-395. https://doi.org/10.3390/fi4020372
Kennedy S, Molloy O, Stewart R, Jacob P, Maleshkova M, Doheny F. A Semantically Automated Protocol Adapter for Mapping SOAP Web Services to RESTful HTTP Format to Enable the Web Infrastructure, Enhance Web Service Interoperability and Ease Web Service Migration. Future Internet. 2012; 4(2):372-395. https://doi.org/10.3390/fi4020372Chicago/Turabian Style
Kennedy, Sean, Owen Molloy, Robert Stewart, Paul Jacob, Maria Maleshkova, and Frank Doheny. 2012. "A Semantically Automated Protocol Adapter for Mapping SOAP Web Services to RESTful HTTP Format to Enable the Web Infrastructure, Enhance Web Service Interoperability and Ease Web Service Migration" Future Internet 4, no. 2: 372-395. https://doi.org/10.3390/fi4020372