3 ms·

Were doing a coupling to a soap backend. It has been 7 years since I last did .NET and now I've decided to never go back.

by benvds 11y ago

okhudeira 11y ago
SOAP and WCF is a very scary thing. We're in the financial industry and many of the systems we integrate with use .NET and SOAP/WCF. Although Visual Studio does all the heavy lifting for us via 'Add Service Reference', the sheer amount of boilerplate code generated when integrating a SOAP service is terrifying and bloated. We hope to migrate to ASP.NET 5 but we're not sure how well connectivity with SOAP services will be supported. One of our partners actually requires us to host our own SOAP service based on a spec they provide. However, for our own APIs we use ASP.NET Web API and build REST/JSON APIs as highlighted in the stack page (http://engineering.gopangea.com/stack http://engineering.gopangea.com/stack).
junto 11y ago
.NET WCF to another WCF integration is fine, but if you try and hook a .NET SOAP webservice to one written in Java, and you'll have pulled all of your hair out after two weeks. The reverse is just the same. They all have slightly different implementations of the specifications. Make that one week if you have to start dealing with the monster that is called WS-* a.k.a. WS-WTF. I wrote an article on this many moons ago. It is still one of my most frequently read posts: https://benpowell.org/supporting-the-ws-i-basic-profile-password-digest-in-a-wcf-client-proxy/ https://benpowell.org/supporting-the-ws-i-basic-profile-pass... It just goes to show how many SOAP integrations are still going on in the "enterprise".
- deleted 11y ago
 [deleted]
- mohaine 11y ago
 This. WCF is SO broken but you don't notice if you use it on both sides. It has been a few years but it used to require your soap attributes to be in predefined order and would break otherwise. so if it expected: <object> <a>A</a> B <c>C</c> </object> And you sent in: <object> B <c>C</c> <a>A</a> </object> The parsed object was: {"a":null,"b":"B","c":"C"} Java Soap libs normally creates the request by reflection and attribute order depends on the exact JVM and compiler implementation and combination. This one took way to long to figure out.

Were doing a coupling to a soap backend. It has been 7 years since I last did .NET and now I've decided to never go back.

by benvds 11y ago

Were doing a coupling to a soap backend. It has been 7 years since I last did .NET and now I've decided to never go back.

okhudeira 11y ago

SOAP and WCF is a very scary thing. We're in the financial industry and many of the systems we integrate with use .NET and SOAP/WCF. Although Visual Studio does all the heavy lifting for us via 'Add Service Reference', the sheer amount of boilerplate code generated when integrating a SOAP service is terrifying and bloated. We hope to migrate to ASP.NET 5 but we're not sure how well connectivity with SOAP services will be supported. One of our partners actually requires us to host our own SOAP service based on a spec they provide. However, for our own APIs we use ASP.NET Web API and build REST/JSON APIs as highlighted in the stack page (http://engineering.gopangea.com/stack http://engineering.gopangea.com/stack).

junto 11y ago

.NET WCF to another WCF integration is fine, but if you try and hook a .NET SOAP webservice to one written in Java, and you'll have pulled all of your hair out after two weeks. The reverse is just the same. They all have slightly different implementations of the specifications. Make that one week if you have to start dealing with the monster that is called WS-* a.k.a. WS-WTF. I wrote an article on this many moons ago. It is still one of my most frequently read posts: https://benpowell.org/supporting-the-ws-i-basic-profile-password-digest-in-a-wcf-client-proxy/ https://benpowell.org/supporting-the-ws-i-basic-profile-pass... It just goes to show how many SOAP integrations are still going on in the "enterprise".

deleted 11y ago
[deleted]
mohaine 11y ago
This. WCF is SO broken but you don't notice if you use it on both sides. It has been a few years but it used to require your soap attributes to be in predefined order and would break otherwise. so if it expected: <object> <a>A</a> B <c>C</c> </object> And you sent in: <object> B <c>C</c> <a>A</a> </object> The parsed object was: {"a":null,"b":"B","c":"C"} Java Soap libs normally creates the request by reflection and attribute order depends on the exact JVM and compiler implementation and combination. This one took way to long to figure out.