Comment by ilitirit | Hacker News Reader

Comment by ilitirit | Hacker News Reader

Parent Full thread

It's worth remembering that the technologies you mentioned weren't around when WCF was created.

As far as I can tell, Microsoft doesn't really push WCF any more simply because the use-cases are fewer and/or irrelevant in the current Web Service landscape.

I also get the feeling that many people commenting here didn't need to work with WS-* and associated technologies at the time WCF didn't exist. After its release it really was a choice between the lesser of two evils. But at the time, WCF was the mischievous kid who didn't do his homework, and everything else was the direct spawn of Satan.

A reminder of what WCF is (Wikipedia):

> a runtime and a set of APIs in the .NET Framework for building connected, service-oriented applications

> WCF is a tool often used to implement and deploy a service-oriented architecture (SOA)

For people who were around during the SOA dark ages, I won't be surprised if reading that sent shivers down your spine. Thankfully SOA, as it was evangelized, is pretty much dead. For everything else, these days better data-interchange technologies exist.

Wasn't there web services before WCF to deal with SOAP? And I seem to remember they were easier to use than WCF. I also go the feeling that when WCF was released it killed off quite a bit of the evolving open source stuff.

Could be wrong, but you seem to be downplaying how much of a development drag WCF ended up being on .Net and how poorly it is designed.

I was around that time too, and for me WCF was like a blast from the past even back then. It was like a bad .Net 1.0 library when it was brought out. Almost everything they could design badly and enterprisey, they managed to design badly and enterprisey. It reminded me of that terrible enterprise library they had.

Still pretty useful in consuming Salesforce's terrible api though.

> Wasn't there web services before WCF to deal with SOAP?

Yes, you used Web Services to deal with SOAP messages. But SOAP was never the problem. WS-* was.

> These variety of specifications are the basic web services framework established by first-generation standards represented by WSDL, SOAP, and UDDI.[1] Specifications may complement, overlap, and compete with each other. Web service specifications are occasionally referred to collectively as "WS-", though there is not a single managed set of specifications that this consistently refers to, nor a recognized owning body across them all.

http://en.wikipedia.org/wiki/List_of_web_service_specificati...

I also don't understand why people think that "enterprisey" is inherently a bad thing? It was designed to be used in the enterprise. This is evident in it's relationship to SOA, which is basically its raison d'etre. When you build apps in enterprise environments you have to put with all kinds of crap to appease auditors and to adhere to various acts and governance frameworks and protocols so that you can maintain your position on whatever Stock Exchange etc. That's just the nature of the beast.

Enterprisey doesn't mean designed to work in an enterprise. It never has.

It's a pejorative term, not a descriptive one.

It means an over engineered solution to a simple problem that suffers heavily from YAGNI. It means catering to the 0.1% scenarios over the 99.9% scenarios. It means a complex generic solution where a simple one would have been better with custom code being used to handle the occasional complex scenario.

> It means an over engineered solution to a simple problem

This is exactly my point. SOA in practice is not a simple problem, and it's the reason WCF exists so of course it's going to be complex. The whole idea of SOA means that you're inherently stuck with the problem of communicating with different different systems that talk different languages, by trying to coerce them into communicating via a standard format, which for all intents and purposes was rarely "standard". And of course these things have to be done in a secure fashion, with logging and auditing every step of the way, and with the ability to change configuration properties by editing a text file instead of having to via a Change Control Board and the entire QA process.

My feeling is that people who were using WCF for "simple" problems were probably using the wrong tool, even though in most cases it would have probably worked fine.

SOA in practice is not about the communication framework, it's about the delivery culture and discipline of using published interfaces of any sort in the first place. Amazon is perhaps the most successful example of a CEO-mandated SOA, they didn't really need something like WCF. Netflix used RESTful HTTP mostly for theirs.

Of course everything else you say about logging, changing, etc. is correct - operationalizing a SOA is hard, which is why we see so many frameworks focused on cloud microservices today.

No, the reason WCF exists is to share data between programs. It wasn't just for SOA it was for everything.

Your over enthusiasm for WCF seems to stem from your own lack of understanding of the major uses of WCF, you're citing a minor use case of WCF as if it were the primary one.

Also the hints you're dropping of your work programming environment sounds like a beauracratic nightmare.

Read the first sentence:

https://msdn.microsoft.com/en-us/library/ms731082%28v=vs.110...

> Enterprisey doesn't mean designed to work in an enterprise.

It kind-of does, though "work in" might be more accurately stated "sell to".

enterprisey:enterprise :: militant:military

Reply on news.ycombinator.com