In the show, we cover a full day + 1 session of WCF, 2 sessions of WF, 1 session of CardSpace, and 1 session of WPF. I am doing the WF and WPF sessions.
A common question that is coming up is why this weighted mix instead of a more even spread of coverage?
It has nothing to do with the complexity of the topics. WF is equally as complex and capable for what it is designed to address as WCF is for its purposes. WPF is also very complex and capable. CardSpace has a much narrower focus than the others, but has a fair amount of complexity surrounding it as well.
The mix we came up with has a number of reasons behind it, but one of the most important factors was considering how many development organizations should be considering adoption of each technology at this point in time.
WCF is a remote communications platform that is rock solid, easy to use for simple scenarios, yet has a million knobs and dials that you can twiddle to address almost any remote communications needs. My perspective on WCF is that if you are writing any application from this day forward (even though WCF won’t release until next month) that needs to make remote calls, you should be using WCF and forget that .NET Remoting, ASP.NET Web Services, and Enterprise Services exist. Obviously that has to be tempered with your ability to get .NET 3.0 deployed to the target platforms. But unless there is an unmovable roadblock to you doing that, it is worth your while to make the switch to WCF as soon as possible. Every application of any significant scale has at least a cross process hop to deal with somewhere in its architecture, and WCF works great for addressing those simple scenarios as well as full enterprise scale SOA apps. So I feel WCF should be adopted by most development organizations as soon as possible.
WF is an extremely capable platform for developing workflow driven processing in your enterprise applications. It is very stable and ready for adoption by those who need it. The only downside to WF is that because of some the capabilities that are built in to WF to address enterprise requirements (persistence, tracking, and scheduling to name a few), I don’t think you can really say that simple scenarios are easy to implement with WF. So it takes fairly complex enterprise application requirements to justify the adoption of WF in your application. Additionally, not every application out there really has workflows of any significance (there are a lot of pure CRUD apps still out there). As a result, I think the number of development organizations that should be adopting WF at this time is smaller by at least 1/2 than those who should be looking at WCF.
WPF is a harder one to nail down, and my opinions are likely to incite some flames. I think that there are a lot fewer development organizations that should be bothering with WPF for the near future. The reason mainly has to do with productivity. Even though the runtime bits for WPF will be part of the .NET 3.0 release, the development tools for designing WPF UIs will not. Microsoft is hard at work on a WPF designer for Visual Studio that will hopefully release sometime next year. Alongside that effort is the Expression Suite that includes the Interactive Designer product for allowing designers to put together WPF UIs that they can hand over to developers to complete the hook up of the dynamic behaviors of the application from code. At this point in time and for at least the next 6 months, those products will only be available in a Beta form.
Even with the Visual Studio WPF designer, there is an awful lot missing at this point when compared to the Windows Forms or ASP.NET designers for rapidly designing and implementing UI applications. Even once they release next year, I suspect they will still feel like a v 1.0 designer. Think about how the Windows Forms designer in VS 2002 compares with the VS 2005 designer. Night and day in terms of productivity and producing good maintainable code. Hopefully the gap will not be that large. At the current time, if you want to write WPF apps, you will mostly be banging out XAML markup by hand (thankfully at least with some great intellisense assistance). The current CTP of the Visual Studio Orcas WPF designer does at least work pretty well for visualizing the result of your markup, but it is not really useful for doing a graphical drag/drop layout of your form nor for getting things like data bindings, styles, and resources hooked up.
You also have to consider how bad do you need/want what WPF offers. One of the biggest draws of WPF is that it allows you to write UI applications that are more visually compelling. In short, you could say WPF allows you to create eye-candy that you either couldn’t do before or that was orders of magnitude harder to do. What you have to ask yourself is how bad you really need eye candy? If you are building consumer applications, then definitely eye candy is important. The difference between someone buying/using your app instead of your competitors is often a simple matter of whether they look at it, get a glazed look in their eye, and say “Keewwlll…..” But if you are building internal enterprise business applications that show and manipulate data, do you really need pulsating 3D bar charts? Maybe, but it is a lot harder to sell that as a “requirement” than “I need my web server to be separated from my application server for security/scalability reasons” (i.e. I need WCF).
Don’t get me wrong – I would love to incorporate many WPF features into every Windows app I build from today forward. Using things like styling and subtle opacity animations can make any application look better and more intuitive. Once you have adopted WPF, some of the other features of WPF such as the ability to use Style, Data, and Control Templates is very powerful and will be a welcome new model compared to Windows Forms. But the relative number of apps out there that really need embedded 3D modeling or video I think you can say is considerably less than the number of applications that need to do a cross process, machine, or network hop.
Compounding the problem is the fact that adopting WPF implies that you think you can get .NET 3.0 deployed to all of your client desktop machines to support your application. For an enterprise, that may be true if your organization is savvy about the benefits of adopting new technology and not overly paranoid about the risks of deploying a new version of the .NET Framework. For the open consumer market (yes, the primary ones who would drive you to want to incorporate eye-candy), that is going to be a much tougher nut to crack. For a back end server that you want to run WCF or WF on, having the control to deploy .NET 3.0 to that machine should be a lot easier to satisfy.
So as a result of the current maturity of the tools (equating directly to productivity), the relative importance of the completely new capabilities WPF provides compared to Windows Forms or ASP.NET, and the ability to guarantee that .NET 3.0 is installed on the client machine, I would say that a lot less people should be jumping on WPF for the near term. Once we have a good, near production designer for WPF apps in Visual Studio, my tune will change. Also, for those that really need some aspects of WPF now, by all means go for it. But my primary strategy for most smart client apps at this point would be to build it as a Windows Forms application to address the bulk of your requirements (and complete them in a reasonable timeframe), and then incorporate things like 3D, video, animations, etc. as needed using WPF controls embedded in the Windows application through interop (WPF controls can be hosted in a Windows Forms application and vice versa).
CardSpace’s role in the mix is easier to address because it only really addresses one set of requirements: authentication and identity management. It does it well and provides a great new model for identity management that you should definitely be getting familiar with and thinking about how to incorporate it into your applications. CardSpace too faces some adoption challenges since it requires both a service or site that supports CardSpace and a client that has IE 7 or a smart client app designed to work with CardSpace. It definitely warranted coverage in the roadshow and Michele does an awesome session on it. But it definitely did not warrant more than one session compared to overall complexity and capabilities of the technology compared to WCF, WF, and WPF.
These were some of the considerations that drive the mix of sessions we are offering in the roadshow.
I’d be very interested in some comments on other perspectives on WCF, WPF, or WF adoption.