WCF in the enterprise, any pointers from your experience?

Question

Looking to hear from people who are using WCF in an enterprise environment.

What were the major hurdles with the roll out? Performance issues? Any and all tips appreciated!

Please provide some general statistics and server configs if you can!

Answer 1

WCF can be configuration hell. Be sure to familiarize yourself with its diagnostics and svcTraceViewer, lest you get madenning cryptic, useless exceptions. And watch out for the generated client's broken implementation of the disposable pattern.

Answer 2

WCF is definitely great for enterprise stuff as it is designed with scalability, extensibility, security, etc... in mind.

as maxidad said, it can be very hard though as exceptions often tell you nearly nothing, if you use security (obvisously for enterprise scenarios) you have to deal with certificates, meaningless MessageSecurityExceptions and so on.

Dealing with WCF services is definitely harder than with old asmx service, but it's worth the effort once you're in.

supplying server configs will not be useful to you as it has to fit to your scenario. using the right bindings is very important, as well as security, concurreny. there is no single way to go when using wcf. just think about your requirements. do you need callbacks, what are your users? what kind of security do you need?

however, WCF will be definitely the right technology for enterprise scale applications.

Answer 3

As already stated, configuration nightmare and exceptions can be cryptic. You can enable tracing and use the trace log viewer to generally troubleshoot a problem but its definitely a shifting of gears to troubleshoot a WCF service, especially once you've deployed it and you are experiencing problems before your code is even executing.

For communication between components within my organization I ended up using [NetDataContract] on my services and proxies which is recommended against (you can't integrate with platforms outside of .NET and to integrate you need the assembly that has the contracts) though I found the performance to be stellar and my overall development time reduced by using it. For us it was the right solution.

Answer 4

I've been recently hired to a company that previously handled their client/server communication with traditional asp.net web services and passing dataset's back and forth.

I re-wrote the core so now there is a Net.Tcp "connected" client... and everything is done through there. It was a week worth of "in-production-discoveries"... but well worth it.

The pain points we had to find out late in the game was: 1) The default throttling blocked the 11th user onward (it defaults to allow only 10). 2) The default "maxBufferSize" was set to 65k, so the first bitmap that needed to be downloaded crashed the server :) 3) Other default configurations (max concurent connections, max concurrent calls, etc).

All in all, it was absolutely worth it... the app is a lot faster just by changing their infrustructure and now that we have "connected" users... the server can send messages down to the clients.

Other beautiful gains is that, since we know 100% who is connected, we can actually enforce our licensing policy at the application level. Before now (and before I was hired) my company had to simply log, and then at the end of the month bill the clients extra for connecting too many times.