Microsoft exec on .Net 3.0 and WCF

30.01.2007

Instead, most hand-crafted plumbing solutions are proprietary (which hinders reuse, migration, and hiring), are of low quality because most developers are not security or synchronization experts and because the developers were not given the time and resources to develop the plumbing properly. In WCF, all that plumbing is built in! You write business logic, and you let WCF glue it together, expose it as a service, secure it, host it, manage the instances, propagate transactions for you, enlist resources, synchronize access to the service by concurrent client, throttle callers, queue up calls for you etc. This is huge in terms of productivity boost.

Can you highlight some of the common pitfalls in WCF programming and how developers can avoid them?

Developers often think that WCF is about web services, while in fact, it is actually the "new C#" or the new .NET.

Developers try to learn WCF on the job, and that is just not possible. I see all the time developers equating one-way calls with asynchronous calls, or turning off security because they cannot make it work. They must allocate the time to attend training, read the top books and articles, and experiment, before they move to production.

What's the one idea or lesson that people who attend this master class should leave with?