See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
4 MIN READ
Consuming legacy SOAP Web Services normally requires a middleware integration tool or custom code to develop a modern JSON-based REST Web Service—essentially a wrapper around the legacy SOAP Web Service to improve usability. But acquiring, developing and maintaining an integration tool or custom code for this purpose is a huge overhead. In addition, there is an investment in learning to use the integration tool. I speak from experience, working both as an integration developer and in engineering roles, building products that expose and consume SOAP Web Services.
To help smooth this integration headache, the Kong customer experience team developed a SOAP Transformation plugin that removes the need for an integration layer or custom code.
The plugin can convert JSON to XML SOAP and vice versa, all via configuration. And because the plugin deploys to Kong Gateway using the Kong Lua PDK, it’s fast!
SOAP, Simple Object Access Protocol, Web Services have been around for a long time, and not too long ago was the default when it came to exposing functionality using a common format. SOAP is a standards-based web services access protocol that relies on XML to describe the web service and for all request and response messages. (Learn more about all the different type of APIs.)
While SOAP includes many benefits, the heavy nature of XML and the marshaling and unmarshaling of XML to programmatic entities such as Java objects, impacts performance and scalability. Add to that the learning curve to understand SOAP, and it’s clear why there was a need for an alternative.
REST Web Services are now the de-facto standard. But SOAP Web Services still exist and will be around for a long while yet.
SOAP XML consists of a few main components that we need to consider when utilizing the SOAP Transformation plugin. These elements are:
XML namespaces are another key component of XML SOAP. A namespace is a collection of names that one could use as element or attribute names, and the namespace uniquely describes these elements or attributes to avoid conflicts.
Using an online SOAP Web Service as described here, it sums two numbers and returns the result. Let’s look at the simple XML SOAP request message required to call this Web Service:
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
And the corresponding XML SOAP response from the Web Service:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
As you can see, even though the functionality exposed by the Web Service is simple, the XML SOAP is complicated. And obviously, as the functionality and requirements grow, so does the XML, becoming even more complicated.
Now, let’s look at a JSON over REST equivalent request message:
And equivalent response message:
As you can see, the messages are easier to read and easier to consume. Therefore, marshaling and unmarshaling to programmatic entities will be simpler and quicker, resulting in better performance and scalability.
This plugin transforms a JSON request into a XML SOAP request and then transforms the corresponding XML SOAP response into a JSON response.
Here’s how the transformation of element names from SOAP to JSON and vice versa works:
Using the SOAP Web Service described earlier, the following plugin configuration will perform the JSON to SOAP and SOAP to JSON conversion.
curl --request POST \
--url http://localhost:8001/<My-Service>/plugins \
--header 'Content-Type: application/json' \
To demonstrate the SOAP Transformation plugin in action, I will use Insomnia, an open source REST Client developed by Kong. The plugin has been applied to a service object in Kong Gateway Enterprise via the Kong Admin API using the plugin configuration described above.
I mentioned the plugin execution time was fast! Looking at the response HTTP headers as displayed in the image below, we can see that:
X-Kong-Proxy-Latency is the request and response processing time within Kong Gateway Enterprise and the SOAP Transformation plugin. Below is an extract from Kong documentation on the Response behavior:
Consuming SOAP Web Services is not straightforward, requiring specialist integration tools and knowledge or coding expertise in languages such as Java. Both are heavy investments. For those API Proxy use cases where legacy SOAP Web Services coexist with REST Web Services, the SOAP Transformation plugin can avoid needing an integration layer.
If you are an existing customer and want more information on the SOAP Transformer plugin, contact your Kong Customer Experience Manager.
If you’re not yet a customer, then reach out to your local Kong Sales Team.
Learn how to make your API strategy a competitive advantage.