I was recently tasked with connecting an existing .NET Web API solution with a 3rd party Java API. I read through the external documentation, which stated:
All messages received and returned by services must comply with the following standards: XML, SOAP, WS-Security (WSS) and WS-Addressing (WSA).
I don’t have much experience with Windows Communication Foundation (WCF) but I am aware of Microsoft’s <wsHttpBinding> binding, which seemed like a perfect solution for connecting to the external API. I set up the bindings, endpoints, and behaviors in my web.config, I had the credentials I needed, and even a working call up and running using a tool called Postman. However I could never get a successful API call working through my code.
After doing additional research on the <wsHttpBinding> I discovered that it is only supports SOAP version 1.2. I had noticed another section of the 3rd party documentation that stated the JAVA API only supports SOAP version 1.1, so clearly this was not going to work.
The answer was to create a custom WCF binding that can implement wsHttp-like behavior, which can be transported over HTTPS, and restricts itself to SOAP version 1.1. Here is how it’s done.
Set Up The Custom Binding
In the web.config file, I defined my custom binding like this:
<configuration> <system.serviceModel> <bindings> <customBinding> <binding name="MyBindingName"> <textMessageEncoding messageVersion="Soap11WSAddressing10" /> <security authenticationMode="UserNameOverTransport" enableUnsecuredResponse="true" /> <httpsTransport /> </binding> </customBinding> </bindings> </system.serviceModel> </configuration>
Restricting the binding to use SOAP 1.1 happens with this XML attribute: messageVersion=”Soap11WSAddressing10″.
The <httpsTransport /> node must be declared last on the list and enables this messaging to transport over HTTPS.
Voila, I was finally able to communicate to the oldschool Java API!