Book Reviews

Microsoft Windows Communication Foundation 4.0 Cookbook for Developing SOA Applications by Steven Cheng

ISBN: 1849680760
Publisher: Packt Publishing
Pages: 316

Microsoft's Windows Communication Foundation (WCF) is a .NET framework for building service-oriented applications. The idea is that each service specifies its contract, much like an interface in object-oriented solutions. Clients access each service via an endpoint. That endpoint is defined by a service address and a binding model that specifies the transport mechanism. WCF is quite flexible and allows a bunch of different bindings such as HTTP, TCP or a message bus. Of course, WCF also allows you to specify how the service shall behave with respect to traceability, concurrency, data sizes, etc. With WCF you're able to tweak virtually any aspect of the connectivity, hosting and transport mechanisms. The WCF framework attempts to hide much of the details in a superficially simple programming model. Superficial, since as soon as you need to customize any aspect beyond the standard configurations you're in a world of deep accidental complexity.

I've seen it happen in other frameworks over the years. Even when the individual pieces are quite simple in isolation, the resulting complexity explodes when combined together. A framework typically leads us into a false sense of productivity. We get something up and running fast, but lose the ability to grow the system as we start to spend an non-proportional amount of time bending the framework to our will. This is why I tend to avoid frameworks when given a choice.

Often with frameworks, as in the case of WCF, the configuration is where we spend most of our thinking efforts. It's also the least well-designed part. For example, it isn't obvious that the WCF configuration is stack-like where different features have to be specified in a given order. WCF also adds an additional layer of complexity by providing two different configuration models where you specify your configuration either in an XML file or in code. Not only is it an inconsistent representation; the dual configuration model makes it harder to share knowledge and configurations. At the end I chose to go with the configuration in code (this seems to be the model Microsoft moved towards as well - at least if we judge by more recent frameworks like the ASP.NET Web API).

I bought this cookbook hoping it would provide insights into the different configuration options. For example, getting a service properly configured to deal with large messages isn't trivial. Neither is the combination of WCF with dependency injection techniques. And security is always a tricky topic to get right - there's no room for errors there. From the table of contents it did look as though this book would answer many of my questions. Unfortunately, the book doesn't deliver on its promise. Sure, it contains plenty of interesting receipts. But the explanation is superficial and even incorrect at times.Yes, I understand that a cookbook isn't meant as a tutorial or introduction. A cookbook is something I turn to once I understand the fundamentals of a technology. And even then I realize that I need to study the topic deeper in order to apply the receipts. What I expect from a cookbook is guidelines, context and points to other resources for detailed treatment. The Clojure Data Analysis Cookbook is an excellent example of a successfully executed cookbook. This one isn't.

To start with, the explanations in this book are too thin. Worse, the inaccuracies are dangerous. I spent some time optimizing a service for concurrent access. In WCF you do that by specifying a throttling behavior. According to this book, the default number of allowed concurrent calls to a service is 16. Well, by no means enough for my needs. So I had to figure out how to scale that number based on the cores available. As I profiled my code I noted something odd. Oh, as I looked at the online documentation it turns out the default number of allowed concurrent calls isn't 16 at all - it's 16 times the processor count. Quite a difference and something this book got wrong. After that it became hard to trust the rest of the advice.

To summarize, this book provides little value. Most of the information is available on MSDN already. Combined with the inaccuracies I mention above I cannot see any reason to recommend this book. WCF on other hand is a decent technology if you work exclusively in a .NET environment and get past the initial configuration hurdle. The problem is just that I've got seriously spoiled by Erlang and have come to expect distributed, service-based applications to be straightforward, diagnosable and stable by default. It's a cruel world.

Reviewed January 2015