As some of you know, I began working on a WCF book several months ago. Currently I am looking to increase the size of my “Review Crew” (John Robbin’s term). Hopefully I am not opening myself up to hoards of email, but if you are interested in reviewing my book see the last section of this post. My hope is that more viewpoints will ensure the book:

1) addresses the topics developers must know,
2) properly addresses the topics developers are most interested in, and
3) explains WCF at the proper level of detail.

In general, this book is targeted at an advanced audience, and describes WCF internals from the inside-out. I expect to have the book on bookshelves by the Vista launch.

About the book

WCF is fundamentally a service-oriented XML messaging platform. The WCF team has successfully abstracted the XML messaging infrastructure away from the object model developers are most likely to use. Given this fact, three approaches are possible when explaining this technology:

1) Focus strictly on the Object Model (since this is where developers will most likely spend all of their time)
2) Focus strictly on WCF internals and the theory behind WCF
3) Blend the previous two approaches

This book takes the third approach, and I have taken some flack over it. Many believe that #1 is the best approach. Their belief stems from the assumption that the level of abstraction in the WCF platform releases developers from having to consider WCF internals or service-orientation in general.

My counterpoint is pretty straightforward. While it is true that WCF does not force developers to directly deal with the messy business of angle brackets and WS-* protocols, it does not completely release the developer from the responsibility making the mental shift to service-orientation. In much the same way that successful adoption of an object-oriented language like C++ or Java required developers to shift their thinking from procedural programming to object-orientation, successful adoption of WCF requires developers to evolve from a component-oriented mindset to a service-oriented mindset. If we fail to make this shift, we run the risk of missing out on many of the features offered through service orientation.

Even if we do not care about the features service-orientation offers, we should understand WCF infrastructure. In essence, we should know our platform. The CLR offers supporting evidence for this stance. The CLR team did a great job abstracting the Garbage Collector and the JIT Compiler away from the developer. As a result, it is technically possible for us to write .NET applications with little or no knowledge of how these subsystems work. Failing to understand these concepts, however, increases the risk that we will write inefficient applications. For example, a C++ developer moving to C# without any knowledge of the garbage collector will instinctively add a finalizer to all type declarations. Unknowingly, this developer will have increased the time required to allocate these objects and increased the lifetime of these objects. Technically this is not a bug, but it is certainly an inefficiency that could have been averted with a couple of hours spent in a book or a presentation on the topic.

In a similar vein, understanding WCF infrastructure can avert unnecessary inefficiencies in WCF applications, and allows developers to better leverage the functionality available in WCF. For example, changing the reliable session parameter in the constructor of a binding has a dramatic impact on the messaging choreography between endpoints. The WCF team has rightfully abstracted this choreography away from the developer and partially exposed it via compatible bindings. From the perspective of the developer, this messaging choreography is sometimes necessary, and sometimes it is not. It is only through an understanding of this choreography that a developer can make the decision whether or not to use this feature (not to mention what it would take to debug the interaction!). Indirectly, understanding the reliable messaging choreography requires a grasp of service orientation.

This book aims to achieve the right mix of service-orientation concepts and a deep exploration of the WCF programming model, thereby equipping the reader with the knowledge necessary to design, build, maintain, and version WCF applications.

If you disagree with my viewpoint

Feel free to send me an email (justins care of this company) and let me know your approach and why it’s better.

If you would like to be a member of the Review Crew

In general, I am looking for experienced .NET developers and architects that have full lifecycle experience with distributed applications. I am also open to hearing from folks who are experienced with WebSphere, BEA, etc. If you are interested, send me an email at (justins care of this company) that contains the following:

1) What is your experience with .NET
2) What is your experience with distributed applications
3) Are you a professional developer / architect? If so, what company(s) do you work for?

You might be asking yourself, “What’s in it for me?”
1) You will get to read the book before anyone else
2) You will have the satisfaction of a job well-done, and acknowledgement in the book
3) A free dinner next time I am in your area (or next time you are in Atlanta)
4) A signed copy of the book (the signature might actually reduce the value of the book ).

You might also be asking yourself, “What would I be signing up for?”
1) Checking technical accuracy of the book
2) Giving me feedback on how what you think
3) Letting me know what questions you have about the technology
4) Telling me what you would like to see added / removed from the book
5) Reviewing chapters in a timely manner
6) Agreeing in principle to an NDA

I will be accepting new members to the review crew over the next two weeks, so the deadline for submission is April 7.

I look forward to hearing from you!