SOAP Transformation With Apache Camel Java DSL
Got a bunch of SOAP services staring you in the face? Fear not!
Join the DZone community and get the full member experience.Join For Free
One of the most common issues that we usually tackle with customers when modernizing legacy integrations is when they have a collection of legacy SOAP web services that don't integrate well enough with the modern RESTful-based clients.
In this article, we are going to use Apache Camel to build a REST endpoint that will translate REST calls to a SOAP envelope, get the response, and send it back to the client.
Apache Camel is a popular open-source integration framework with lots of features and a diverse ecosystem of plugins and libraries. That said, this implementation is a case of Message Transformation. To be more specific, this is a use case of the Normalizer pattern.
The code for this implementation is available on GitHub.
First Things First
If we're going to translate a SOAP service, first we need a SOAP service. For this example, we're going to use Learn Web Services' Temp Converter Service available at this link.
Maven Is Your Friend
Now, we don't actually need to write all the code that is needed to interact with a SOAP web service. We can use the Apache CXF CodeGen Plugin to create the source code from the WSDL. To do that, you just need to add the plugin to the pom.xml
And then run
mvn generate-sources. This will generate all the necessary boilerplate code under the target folder for Camel to interact with the SOAP endpoints.
To make use of autocompletion resources in IDEs, you can, in Eclipse, right-click -> Build Path -> Use as Source Folder.
Talk Is Cheap, Show Me the Code
We're going to use Spring Boot Starter to make life easier for us, so we just need to annotate to create our beans. The first bean that we will create is the Apache CXF Soap Endpoint config. This bean is going to be responsible for making the request and gathering the response.
With this, we're ready to finally go into some Camel code.
Let's build a route that will consume a parameter exposed by a REST service.
Let's break down the code above.
We have two processors, one to create the complex object that will be sent as a SOAP envelope, and one to get the response envelope to an object.
On these two lines below, we get the temperature in Celsius to convert to Fahrenheit.
Now we set two headers — the namespace and the operation name. For more information about SOAP and its building blocks, I recommend this link from W3Schools.
All these values are configured in the application.properties file.
Now we send our request and gather the response:
You may be asking yourself "Ok, we have the Camel route, but how are we going to send the Celsius temperature that we want to convert?" Well, now enters the REST endpoint configuration.
And we're finally done. With this article, I hope that some light can be shed on how to reuse some old SOAP-based web services without rewriting them. And with this Apache Camel approach, we can always apply more patterns to maybe enrich or send the information to multiple destinations, for example.
Opinions expressed by DZone contributors are their own.