Requiem for Acropolis; Fanfare for CAB +

“I didn’t attend the funeral but I sent a nice letter saying I approved of it.” – Mark Twain

The official Acropolis obituary is long over due (see http://windowsclient.net/Acropolis/ ). With Acropolis out of the way, Microsoft patterns & practices can rejuvenate its composite application development support. That is why I am celebrating.

I’m not dancing on the grave. Acropolis is noble in conception. The Acropolis team is rich in talent and ideas - ideas that should find their way into the .NET platform some day. Sadly they seemed unable to set realistic goals and execute on them. That in itself is no crime; if it were, I’d be doing ten-to-twenty. But Acropolis’ shortcomings effectively paralyzed the .NET composite smart client application development space by promising too much and stifling alternatives.

The Java folks are way ahead of us in experience with composite applications. They’ve been living with dependency injection since 2000 and there are several DI frameworks competing for their attention. For Microsoft-oriented .NET developers, the Composite UI Application Block (CAB) from patterns & practices was the only comparable game in town. It has been galling to watch our community lag farther behind.

A number of my customers have built large, modular business applications in CAB. The latest release of CAB dates from 2005. That’s an eon ago in technology time. Customers wondered where CAB was going. P&P couldn’t say. Finally, Acropolis went public last summer with its ambitions and first bits; P&P closed the CAB shop.

Suddenly the enterprise application developer faced awful choices: wait for Acropolis to mature, experiment with early Acropolis CTPs, go with an off-brand platform such as Spring.NET, or build on a terminal CAB that had one or two years to live. Choice is good when the choices are good. Well the choices were not good.

Nobody knew what Acropolis was going to be. It was clear to many of us that whatever Acropolis ultimately offered would not arrive for at least two years, probably longer, quite possibly never. Meanwhile, CAB, as good as it was, needs an overhaul and no technology survives without continuing investment – investment it would never receive while Acropolis lived. The Spring (http://www.springframework.net/) route leads away from Microsoft and many shops simply will not stake their futures on an open-source venture.

Microsoft Patterns & Practices Takes Over

With Acropolis out of the picture, Microsoft’s patterns & practices group can rejuvenate the space. That’s not how it should have been – it would be far better to have a composite application development framework in .NET itself. But it’s time to move on. Besides there’s a lot to like in what’s coming and reason to believe we’ll have our hands on a viable framework in a year to eighteen months.

Start by reading Glenn Block’s blog on the transition (http://blogs.msdn.com/gblock/archive/2007/10/26/wpf-composite-client-guidance-it-s-coming.aspx) . Glenn should know: he’s the “Product Planner” for patterns & practices.
Here’s my first take on the announcement and what it means to enterprise application project managers who must decide which composite app pony to ride.

CAB & Windows Forms

I continue to recommend CAB WinForms clients, even for new development.

We’re making terrific progress with our WPF initiatives at my company and I’m bullish on the new breed of WPF applications that should emerge in late 2008. WPF’s superior data binding architecture alone will transform how we construct our UIs.

But let’s get real. WPF development is much harder today than WinForms development. The poverty of WPF design tools and the steep learning curve are going to kill developer productivity for the next year at least. If you intend to deliver a large application in reasonable time, you should think twice before leaving WinForms.

The apparent danger is that you will be left behind. Some wags will chirp that your application will be “legacy” before it is even released. Well you tell them “at least I have a release!” Time to market counts for a lot with everyone, not just software product vendors.

You can build a very slick, modern looking WinForms application that does its job well. While you are delivering, the other guys will be stumbling with glitzy WPF-front ends that crash alot. There’s plenty of talk about how WPF enables the “differentiated UI”. Differentiating the UI may make sense for a public facing application where you have to make a splash to win business. Differentiation for its own sake has no value for the inward facing, productivity applications that are the majority of line of business (LOB) apps. You should be able to “differentiate” on the merits, not the cosmetics.

Don’t get me wrong. I am utterly convinced that a compelling user experience is essential. The question is not “should I invest in the UI?” but “is a WPF UI better than a WinForms UI for LOB apps?” The answer will be “yes” some day. But not today and not in the next year or two.

I have yet to meet the data-driven, LOB application that puts WPF to good use. I immediately discount any UI with white type on shiny black, image reflections, and big animations. I’m as dazzled as the next guy the first time I see my form rotate on a carousel. It gets old around the tenth time. Around the 100th time I’m annoyed and impatient; I want the UI to stop preening and give me the damn form.

I am starting to see some simple WPF effects that matter. An effect matters if it improves the user’s productivity. It should help him or her see an important event or important relationship more quickly and more clearly. It should help the user make better choices faster.

Such effects tend to be subtle. The other day I saw an image that expanded just 5% in order to draw attention to an important application event. It catches your eye without jarring your attention. That’s great. I could use that effect to let the user know a “save” completed successfully; I could avoid the typical, annoying interruption of a popup “Save Completed” dialog box. We’ll invent more of these effects in time and they will enter the lexicon of everyday idioms that we all use to build effective UIs. However, those idioms do not exist right now and even the above average developer is ill-suited to inventing them. Until we have that lexicon, there is little visual advantage to WPF for the LOB developer.

Playing it Safe with CAB 2005

CAB 2005 (plus SCSF) remains the best bet for pure WinForms development. It is stable and reliable. There is a solid community of CAB experience to which you can turn for advice and hired talent. We’ve seen more and better training materials in recent months. The online forum is healthy.

The CAB API is not going to change. That’s good news for those who favor stability and tough news for folks who want to see it grow. The p & p folks have committed to making CAB work on Visual Studio 2008.

CAB for WPF Today

P & P announced a new WPF-only initiative called “WPF Composite Client” (WPFCC). Right now it’s little more than an idea – an idea I’ll talk about below.

If you have to code a WPF composite application today, you’ll want to pick one of the two existing alternative described in Glenn’s blog:

1. SCSF 2007 – The CAB/SCSF combination that supports islands of WPF inside a WinForms application. Use this to embed a WPF part within your CAB app. It’s almost as simple as adding a few dlls. While SCSF 2007 targets existing CAB applications, you might consider it for new development that is mostly WinForms-based when all you need is a few, well-chosen WPF accents.
   
   
2. WPFCAB – This is the route to take if you want to write a pure WPF app right now. Kent Boogaart (with help from Matias Woloski of Southworks) has adapted CAB and its UI components to work with WPF. The APIs are the same as CAB 2005 so if you know (or have read about) CAB for WinForms, you know how to develop in WPFCAB.

WPF Composite Client (WPFCC)

We’re going to need a better name! My poor memory refuses to retain the difference between WPFCC and WPFCAB. A couple more doses of Ginkgo biloba and I’ll be fine.

WPFCC is not CAB. Patterns & practices desperately wants you to know this. There will be no way to automate migration to WPFCC from your CAB 2005, SCSF 2007 or WPFCAB application. Is that clear? Good.

This is absolutely the right decision. We need a new composite application development platform that is fully committed to .NET 3.5 and WPF. If that means leaving CAB behind – and it does – so be it. In my view, an attempt to preserve backward compatibility would be a disaster.

1. We need a dependable, working version of WPFCC “soon” – within a year. To achieve that goal, it must be spare and clean and of reasonable scope. Every feature counts.
   
   
2. CAB never got the traction it deserved in large part because it was too hard to learn and had too many quirks. A new WPFCC, unencumbered by the past, can strive for simplicity and devote more energy to flattening the learning curve.
   
   
3. Supporting WPF will be a challenge. The APIs will have to change. We can’t expect to hide everything under the hood. Yes Kent did a nice job of translating CAB WinForms components into WPF components. However, the WPF architecture is so different that simple translation will not do. Mere translation would prevent the developer from exploiting WPF fully and impose WinForms constraints that hamper performance and foster ill-advised designs. There really is an impedance mismatch between the two that runs deeper than the visual differences familiar to everyone.
   
   
4. WPF isn’t the only new technology at issue. The language enhancements in .NET 3.5 – especially LINQ, lambda expressions, and extension methods – will change our programming style dramatically. WPFCC APIs should demonstrate the best practices of that new style just as they should promote the best practices of WPF development.
   
   
5. CAB is missing some valuable capabilities found in rival composite UI frameworks. The Aspect Oriented Programming (AOP) features of Spring come to mind. The Acropolis people weren’t sitting on their hands the last two years. They’ve been cooking up new stuff and torture testing code under arduous WPF conditions for some time. This is a great opportunity to harvest the best of their efforts and avoid their mistakes. And I’m really looking forward to integrating WCF and WF into the framework rather than bolting them on as we do today.
   
   
6. As with any software, there are a number of false starts and blind alleys in CAB. Let’s get rid of them.
   
   
7. Preserving backward compatibility is hard. P&P is a small team. If we demand backward compatibility, we will lose something we value more – some thing important among the basket of goodies I mentioned above. That’s my intuition anyway.

Will They Deliver?

I have a lot of confidence in the patterns & practices team. These folks have a great track record of saying what they will do and doing what they say. The shop is committed to agile practices and they’ve been living those practices for several years. Rapid iterations are the norm. Code that works is the norm. They are organized to collect feedback and are accustomed to listening to it. I’m consistently impressed.

They also know this space pretty well. After all, they’ve built CAB and they’ve been maintaining it. Not everyone is still around but the new blood know the score and play their instruments well. With luck, we may see some of the Acropolis people join them.

Finally, the WPFCC project will not be caught in the Visual Studio designers trap. The Acropolis team poured their hearts into rich, extensible visual design tools that would give the developer that nifty drag-and-drop development experience. What a nightmare. It may be possible but I think we can all guess how hard this must be. If it were easy, we’d have great WPF design tools in Visual Studio today.

The WPFCC design is wide open at this point but I’m virtually certain that visual designers have been ruled out. I will not fail to remind P & P how much they’ve been burned by the guidance automation tools should they even consider the vastly more difficult challenge of building anything but the simplest designers.

What About the Installed CAB Base?

So you’ve made a huge commitment to CAB and now you learn that WPFCC won’t look like CAB. How can they do that to you?

I’d like to think you got over it earlier this year when you learned about Acropolis. Acropolis was never going to look like CAB. It wasn’t going to be anything like CAB. In fact, we had no idea how much CAB would find its way into Acropolis. So you’ve had months to get used to the idea that there would be no automated migration path to CAB’s successor. Nothing has changed.

Here’s the great news. Until today, you had no idea which CAB concepts would survive in Acropolis. Now you know (because Glenn said so) that critical architectural constructs like modularity, dependency injection, Event Broker, and services will be there. Unit testing was a prominent theme in CAB development (as it seemed not to be in Acropolis); I’m confident we’ll see even more energy devoted to enabling the test-first developer.

There is good reason to believe that a CAB application will port to WPFCC with relative ease. “Relative” to what? Relative to an application built without CAB for sure. The common heritage is going to make a huge difference. The familiarity with the concepts, the decoupled modules, the pub/sub eventing – all of this is going to make the transition surprisingly easy. It just won’t be automated.

For the last year, people have been asking me “should I build in CAB or wait for Acropolis”. I always told them, “build in CAB today because it is the best way to prepare for Acropolis. The leap from CAB to Acropolis will be a hop across a stream; the leap from standard application architectures to Acropolis will be like jumping a river. If you have a choice, it’s better to get going now.”

I’m singing the same song today with just a few changes to the lyrics: “build in CAB 2005 today because it is the best way to prepare for WPFCC”. Now I’m singing it with full-throated conviction.