If SOAP is now considered overengineered over REST why isn't WCF? [closed]

Question

I'm amazed that years over years IT pretend to simplify communication or software design and a few years later it declare it was over-engineered. EJB, SOAP, so looking at all the WCF stuffs do we as users (not as Microsoft or IBM who need to sell new stuffs) really need it ?

Update: this is a concrete example http://www.go4answers.com/Example/expert-interoperability-issues-ws-736.aspx The guy knows how to call a server with WS-Security using old soap and in WCF it seems it doesn't really help and worst it seems even more complicated as it is said:

"WCF has still some limitation - not all WS-Security configuration are possible without custom development."

Nobody seems to be able to have found a solution.

So can people instead of mere opinions give concrete examples (with source code both in wcf and in soap or rest for comparison) of hard problems (and not easy problems) that can be solved by WCF more easily than can be with traditional soap ?

Answer 1

What I like about WCF is that it can be as simple or as complex as you want it to be. I also really appreciate the separation between contract and binding, where you can clearly define your operations and have the option of choosing which transport to use.

Answer 2

WCF is meant to make a developer's life easier. You can re-write the logic for a service, auto-wire multiple endpoints, and voila...your logic is available via SOAP, REST, Named Pipes, etc.

Unfortunately it's not as easy as it was all made to sound. Personally, though, I still find it a useful tool for re-using my code.

If you really want to jump on the bandwagon and say that REST/JSON is the only way to go...then WCF will definitely seem over-engineered. ASP.NET MVC does a great job at RESTful JSON services if you don't want to deal with the WCF overhead.

Answer 3

With 4.0, they've simplified configuration. I find it very easy to do this. But realize WCF is designed to make a lot of the internals of communication between services transparent. You don't care if its SOAP, REST, etc. All you do is write your service and "hook them up". COde for my services is exactly like I'd write normal code, with the exception of a couple of attributes added to the class and methods and some configuration (with 4.0, very simple imho)