Bender's Blog

I had the good fortune to attend the PDC pre-conference and was able to attend a day-long WCF session with Juval Lowy and Ron Jacobs.

Juval went first and spoke for most of the day. Juval has been working closely with Microsoft for quite some time, and his COM(+) roots were showing big time. Essentially, Juval is of the opinion that WCF is a .NET killer and should be the way ALL applications are written from here on it.

As Juval has extensive expertise with COM, I think he tends to see everything in terms of that model, and he may have a point. As a result, he made the bold statement in the pre-conf session of referring to WCF as a .NET killer.

While I'm not prepared to follow Juval in claiming .NET dead at the hands of WCF, he makes some good points. If you think of the communication between objects in a system analogous to the communication of services in an architecture, WCF provides some cool abilities that the traditional model in .NET does not.

Services provide metadata about what they are and how to use them. .NET classes do not. WCF allows developers to provide a rich security model around their services. .NET classes have some security abilities, but they are based around determining if a user has specific permissions at runtime. WCF allows you to set timeouts for a service call. The service dies, your application goes on. Calling a method on a .NET class that dies means your entire app dies. WCF allows the way services communicate to be configured at runtime. Reflection makes that possible in .NET, but be ready to build lots of plumbing to implement this. MEF makes this WAY easier, but WCF still has it beat as an out-of-the-box solution. Want to distribute your components on multiple tiers? WCF inherently allows this. Heck, it's WCF's "thing." You can do this in .NET too, if you use WCF. There's more, but those are the big wins for most developers.

Yeah, WCF does offer some advantages. So much so that Juval claims that every class from here on out MUST be a service from now till the end of time.

So why hasn't the development world fallen in line?

WCF offers metadata about it's services and classes don't. True, but let's be honest; if .NET classes did offer that level of metadata how often would it really be used? In most cases I've found having the class implement a contract is sufficient. Presumably, if good naming standards are used, I know what the class does and what methods are available to me. Security in services is great. Security is important. But let's face it; security slows systems down. I'm a big believer of checking security ACL's in every method call (ESPECIALLY if it's a web app!) but that call is relatively cheap compared to how the comparable model in WCF security is implemented. The configuration stuff could be very useful, but one of the biggest complaints I hear about WCF is that the configuration, even with the WCF configuration tool, is difficult and generally a pain to deal with. And any facility to do this with .NET classes would be just as painful.

And let's not forget the two biggest dings

• Performance. A WCF call with the named pipes binding can be VERY fast. But it's still not going to beat inter-process call to an object in the same app domain. Sure, not by much and it would be almost imperceptible to the user, but it's there. Add that to the up-front time needed to spin up a service host and establish connections (especially if security is being used) and it's definitely something to think about.
• Complexity. One of the biggest obstacles to widespread WCF adoption is that it's still perceived as a more complex solution to ASMX web services and .NET Remoting. To be sure, WCF gives you an abundance of options. But having too many options can make things more confusing. And have you ever seen a production WCF configuration file? It's ugly! No argument there.

I don't know which is better. This is because I've never actually built an application the way Juval suggests. But I'm curious to see what an application built in the manner would look like. It goes without saying that it would be designed and developed very differently from the traditional .NET applications we all use today. For every design consideration I can think of sitting here writing this, there are several more that haven't occurred to me yet. In the end the adage holds true: You don't know what you don't know.

So my plan is to pit both of these approaches against each other and see what happens. Over the course of the next few weeks, as time allows, I'm going to write the same application twice. Once as a traditional .NET application and again using the approach Juval is advocating. Here are the ground rules:

This will be a simple application. It will not necessarily mirror and real-life business case. It's sole purpose is to demonstrate each architectural approach in a variety of everyday business situations. That's right, I'm living many a developers dream; using technology for the sake of using technology. Mmmmmm...... self-indulgence....

Both applications will be developed using TDD to the extent that my TDD chops allow. In addition to improving my TDD chops, using  the same unit and UAT test for each application will help ensure parity. Each application must pass ALL tests to ensure that each is delivering the same features. I will be the primary tester, but if anyone would like to volunteer help out that would be great!

Each application will have a standard UI tier (WPF), business tier and data store. Additionally, each application will utilize one service within the application that will mimic and internal Enterprise service and one publicly available web service (TBD)

I'll be posting my progress as I go. Please feel free to add any suggestions or ask any questions in the comments section