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.

"I was told that CAB performance stinks"

I wish I had a nickel every time someone wrote to tell me:

I was told that there is a definite performance hit to using X.

It is absolutely true of course! There is no technology with zero performance impact. So if I told you "the performance is absolutely acceptable" would you believe me?

I hope not! For that response is every bit as unqualified as the accusation.

We really have to understand the application and the environment in which it runs before we can speculate about the probable performance effects of CAB (or anything else). We have to measure the performance before we know for sure.

That's not terribly helpful if you're standing on the cusp of a major architectural decision. You want to know "will CAB sink my application and my career along with it?"

Permit me to rephrase the question: "In general, are WinForm applications written in CAB perceived to perform poorly relative to WinForm applications written in raw .NET ?"

The short answer is "no". I haven't formally benchmarked the two kinds of applications but I have eyeballed the differences with my wrist watch and I can't tell the difference. We have a number of customers writing CAB-based applications (with .NET, Developer Express, and Infragistics control suites) and they do not report performance problems traceable to CAB.

With performance, like the proverbial tree in the forest, if no one sees it fall ... it did not fall.

Developers do report performance problems of course and CAB is oft times suspected. But further investigation typically reveals that the culprit was loading too many complex controls at once or wasteful loops or unfortunate choices in database access or some other of the usual suspects.

I'll bet there are ways to abuse CAB and deliver a dog of an app. It is true that CAB makes extensive use of reflection and there are some opportunities for improvement (e.g., caching previously analyzed type information).

The CAB in your application should be operating at coarse-grained levels such as the initialization of long-lived objects (like views and presenters); these are not the hot-spots where reflection kills you.

I would be grateful for any references to articles or blogs where bad CAB performance is discussed. As I said, I often hear the charge but have yet to see the evidence.

ORM as Vietnam of Computer Science - a response

I just published a response to Ted Neward's critique of Object Relational Mapping on CodeProject at www.codeproject.com/cs/design/ORM_Vietnam.asp

Ted's made quite the name for himself by "smacking down" on object-oriented approaches to data access. His inflammatory style draws attention but I think he is wrong on every point of substance as I explain in my article.

Take a peek and let me know what you think.

Painless Dependency Injection

Jeff Doolittle and I recently performed our "Dependency Injection" play in a webinar attended by ~110 people. That webinar is now available on video, along with the PowerPoint and the example code in both C# and VB. If you ever wanted to know what the fuss is about or just want to see Jeff and me telling jokes ... this is your webinar. So gather the kids and the popcorn ...
www.ideablade.com/regDependencyInjectionWebinarArchived.

Cabana Unleashed!

The long-awaited, heavily revised Cabana is out. Get it (and it's still primitive documentation) at www.ideablade.com/cabana.

It's important to read the "InstallationAndReleaseNotes" because we split the application into two solutions, "our stuff" and "your stuff"; these solutions have to be built in proper sequence. So spare our support team and RTFM.

I should mention that we have a follow-on version in the works that includes Visual Studio templates and wizards to help you generate modules and pages. These aren't quite as nifty as recipes from one of the P&P software factories but they are much easier to write and maintain yourself. I think you'll like 'em.

Truth in Advertising Dept. - I must acknowledge that Cabana is not easily grasped without significant guidance ... and that guidance is missing right now. The class hierarchy is documented as are the twin solutions (at a very very high level). But it really needs much more and, in particular, a friendly video series to walk you through it. That's the next step for us.

Dancing by Silverlight

My company recently posted a brief about Silverlight as we see it. Check it out.

We're really keen on Silverlight for "enterprise applications" (aka "Line of Business" apps).

I've just a few additional opinions to share.

You who know me know I'm impatient with defenders of the browser as host for enterprise applications. Every attempt has been a turkey.

Seriously, I challenge you to show me the browser line-of-business app that is even as half as productive or as functional as a PC app. Google wordprocessing or spreadsheet? Please, spare me. Google's a great company but they can't buy or build a browser-based office application that really works in an office environment (it's ok for grocery lists and the kids homework I guess).

Line-of-business apps are inherently overwhelmingly stateful, interactive, multi-paged, high-touch, workflowed, interrupt driven, etc. Everything the browser is not.

The fundamental premise of the browser app is that the server does the work. AJAX changes the equation only slightly; the moment you move off the page its back to the old "yoo-hoo, is anyone home" request/response paradigm. Do I have to add that it takes skill in about 27 different technologies to write a browser app and the testing/debugging is absurd. The web development effort is 10x for a comparable Windows app.

But I digress ...

"SmartClient" is the way to go because it puts the business logic and data where it belongs: close to the end-user who needs it.

There are two serious obstacles to "smart client": (1) installation, however minimal, is not zero - which means you can't build smart clients for consumers and casual users; (2) corporate paranoids have locked down the PC, effectively blocking any application that puts its foot down outside the browser.

Silverlight 1.1 clears these hurdles by running a reasonable facsimile of the .NET CLR within the confines of the browser sandbox. No installation to trouble the consumer; no footprint to frighten the corporate guardians.

There are a few catches. First, the Silverlight we need (v.1.1) isn't going to be available for at least a year. Second, we don't fully know its limitations (it offers an unspecified subset of the .NET CLR). Third, we're pretty sure its going to be hard to get data in and out except via something web-service like.

Challenges? We love 'em. When the hype dust settles and v.1.1 is approaching release, we (IdeaBlade) are going to have a great offering. We will have a nifty (and easy) solution to the data permeability problem. We've got to work out the kinks (we're likely a year away) but we're confident that you'll be able to write a single application that runs on the PC or in a Silverlight-powered browser (albeit with restrictions). Mark my words.

Cabana Release Imminent

One of my fans complains "two months and no new Cabana release! When is the next drop going to occur? Can you give us a brief synopsis of any new features?"

Ouch! But he's right. We've had our heads down the last few months pounding away at the new version. We're really close to revealing it.

Here's what's coming ...

What is Cabana?

Cabana is a Sales Order Management reference application demonstrating how to combine CAB, Smart Client Software Factory (SCSF), and my company's application framework product called DevForce (see www.ideablade.com to learn more about DevForce and to get a copy of our free "Express" edition).

It really is a composed application with distinct modules (you can make 'em come and go) and pages built up by "Page Controllers" from nested layout and widget views.

What Happened?

Originally, I was just trying to show that DevForce and CAB are complimentary technologies. Then things got out of hand.

"Advanced" DevForce Techniques

I had another reference application called "Funhouse" built on my homebrew composite UI framework. It's purpose was to consolidate the tips and techniques I teach in my "advanced DevForce" classes - to put them in a shared context so you could see how they work together to deliver application value.

That was destined for the ash can as soon as I took CAB seriously. I can't maintain two reference applications nor recommend two competing approaches to application development. So a major goal was to port everything of interest from Funhouse over to Cabana and then kill Funhouse.

This release of Cabana completes that task.

Teach CAB

The best way to learn CAB is to try to teach it. I've probably give over 30 CAB classes in the last year, ranging from 1 hour to four days straight. Every class has sent me scrambling back to the code to rip out some horror and replace it with something that makes more sense and is easier to understand.

Definitely a work in progress, made possible only by the patience and quizzical looks of my indulgent audience; many thanks to you all.

I've given special attention to Model-View-Presenter (MVP), an architectural pattern that everyone claims to love and no one seems to understand.

I've accumulated some "rules of the road" and I think I've got a good programming model for you. It's on full display in this release and will be appearing in a white paper "coming soon."

Support alternate WinForm Control Suites

I was pushed into providing a Cabana version for the Developer Express suite (hang in there, Infragistics lovers).

Nothing puts the stress on MVP like having to support multiple UI control suites.

To keep my sanity, I have to be able to swap a DotNet view for a DevEx view without changing the view's presenter or interface or the orchestrating "Page Controller" that composes and manages the composite views.

I've had to come up with new ways to coordinate view and presenter that are UI control agnostic (see my "ViewUpdateHandler" delegate) and figure out how to swing from one view family to another (see my "ViewFactoryService").

I haven't driven the separation all of the way through - many views are still DotNet controls sitting on a DevEx layout - but the remaining work is "obvious" drudge work that I'll complete "sometime".

The acid test will be my ability to "generate" two or three UI specific releases from a single code base - in under 1/2 hour.

I've got WPF in my sights for a more challenging test of the MVP proposition.

"So what?" you say; "I only want to work with one suite."

Two responses: (1) you may be whistling a different tune when you have to offer a WPF release and (2) view swapping could help simplify intractably complex white-labeling, internationalization, and role-based presentation problems.

Jump Start CAB/DevForce Application Development

I never intended Cabana to be a framework for actual application development. That hasn't stopped a boat-load of customers from trying.

Our market place is amazingly eager to build on CAB now and they don't want to spend the months wandering in the weeds the way I have. They want to take Cabana and use it out of the box.

The customer is always right. So this release takes seriously the proposition that you should be able to

• unzip Cabana
• whack a few projects, files, and references
• start adding your own modules and views
• ship it

You should be able to take the "Cabana" out of Cabana and parade it around as your own work in just a few hours ... as long as you're willing to conform to Outlook-style navigation and the Cabana-style page paradigms.

We're working on the videos to do just that (did a 50 minute dry run the other day).

While this is something of a parlor trick, the real value is that you can learn the mechanics of a real application with the Cabana training wheels on. Once you've found your balance, you'll know how to break them off and ride on your own.

This effort has had startling (and salutary) effects on Cabana

• Vast re-organization with an emphasis on grouping like functionality in folders.


• Many classes were pulled "up" into the IdeaBlade.Cab projects that we have signed-up to maintain; this sharply reduces the number of classes you will have to think about as "yours" when you get started.


• Renaming and refactoring to remove inconsistencies and clarify responsibilities. This work is never done - "ToDos" still litter the code base - but we've made huge strides.


• Eliminated "do nothing" interfaces and presenters while flattening the inheritance hierarchies.

Documentation

There has never been any documentation of Cabana. Just a PowerPoint from my class. We'll publish our first crack at it (over 50 pages). We'll have some how-to scenarios. We'll release some videos on related topics.

I've also be tasked with writing some white papers on topics like MVP and Dependency Injection. Those papers should show up in July.

New Features

Every time I think I'm going to hold the line, someone comes knocking with an urgent request. Here's what I think is new, in no particular order.

It's been so long I've kind of forgotten what was in there. Forgive me if I ballyhoo features that were there previously. The next drop is essentially a code reset anyway.

• Every page and popup editor in its own sandbox; changes in the sandbox are temporary until explicitly saved; saved changes are propagated across the application.


• EntityManagers and EntityManagerService wrap our PersistenceManagers and give them consistent configuration. Plug in strategies for saving and merging objects across EntityManager


• Extended CAB "Visualizer" with EntityManager Inspector for watching changes to the business objects in each sandbox as they happen. Visualizers are cool, easy to write, and great for debugging.
  
  


• ListConverterService delivers just-in-time ListConverters.


• ViewFactoryService for dynamic delivery of "named views."


• Revamped OutlookBar navigation with task links in each bar pane.


• Integrated DevForce Verification Engine (replaces BrokenRules)


• "ViewContexts" supercede view interfaces and other (failed) techniques for communicating between presenters and their (decoupled) page controllers. The base presenter class discovers its ViewContext in its parent WorkItem so no assignment is required. This will take some explaining but it works great so far, especially for complex Controller/Presenter configuration and eventing scenarios.


• Nested grid support (DevEx, Infragistics)


• Support for "Add New Row" feature in grids.


• Data update/insert/delete auditing in the middle tier (works in 2-tier too), configurable via metadata tables in the database.


• "Simple Searcher" feature brings an easy to use (and configure) collapsible search panel to all pages; easily extended to complex query panels.

What's Left?

Are you kidding? There's a bunch of stuff I know how to do but haven't gotten around to yet (pluggable authorization, dynamic menu & toolbar management, controlled shut down) and then there is the stuff I don't know how to do yet. When I channel the dark spirit of Donald Rumsfeld I start to worry about the "unknown unknowns".

I think I'm done with the feature creep (yeah - right). The roadmap has some different, prominent markers on it:

• more documentation
• clear tutorials and videos
• better packaging and templates
• presenter unit testing (my gravest embarassment)
• WPF

Enjoy the ride with me!

Acropolis: Between Elation and Despair

Microsoft announced “Acropolis” at TechEd 2007. Acropolis is a .NET framework and companion tools for building highly interactive applications.

Acropolis shows promise and I really want to love it but this project appears to be in trouble and seems unlikely to deliver on schedule a year from now.

In this lengthy post I offer my impressions of the Acropolis unveiling and of how others around me perceived it.

In recent years we’ve enjoyed an expanding array of .NET technologies to help us build the parts and pieces of an application but we’ve never had anything like Acropolis to help assemble those pieces into a coherent windows application. This is no prototyping tool. It’s a heavy duty application backbone that can stand up to the complex and shifting requirements of large-scale enterprise applications.

Microsoft Patterns and Practices pioneered the approach with its Composition UI Application Block (CAB) and Smart Client Software Factory (SCSF). All of the CAB components and architectural patterns for loosely coupled, service-oriented, dependency-injected applications have their analogs in Acropolis.

Check out Glenn Block's blog for his views and analysis on Acropolis as it relates to CAB. Glenn is the PnP product manager for the client software stack.

CAB has a well-deserved reputation for inscrutability and a steep learning curve. Most developers shy away from it. CAB seems to be appropriate only for projects with multiple modules, lots of screen, and complex application logic.

Acropolis intends to be far more approachable without sacrificing architectural integrity. We should be able to build simple Acropolis applications quickly and then grow them as the waves of requirements roll in – without having to scrap our initial implementation and re-build the foundation.

This will be a neat trick. Can they do it? I think so. But they are off to a rocky start.

Caveats

Caveat #1: I missed the formal presentations because of my duties as an exhibitor. That means I missed David Hill and Kathy Tam. Bummer. Fortunately, I enjoyed the luxury of a 30 minute one-on-one at the Acropolis stand and a two hour presentation / Q&A for vendors. My comments derive from these sessions.

Caveat #2: I have downloaded the bits and looked at the Acropolis movie but I haven’t installed them yet and I’ve deliberately avoided other blogs as I write this. I’m trying to keep these other influences at bay so I can better reflect how the Acropolis introduction came across.

I fully expect to be wrong on many substantive points. I can fix that later. This post is about “market impressions” – what were the immediate, visceral reactions of an interested attendee trying to navigate among the bewildering array of technologies competing for his attention.

Caveat #3: I have CAB experience which means I am preconditioned to comprehend Acropolis and speak enthusiastically about it.

Netting it out

I’m thrilled to see Acropolis out in the open as an announced “future product”. I see its CAB heritage. I see how it fills in some important gaps in CAB and will be easier to learn and easier to use than CAB. Acropolis could be truly great.

On the other hand, I’m dismayed at the lack of tangible progress on every front. Acropolis is supposed to deliver in about a year. The audience did not believe it. The newly released CTP1 is manifestly fragile. Every API is subject to change. There were no feature commitments. There were no architectural commitments. There was not even an inventory of project goals.

“These are our ‘thinkings’,” they said, “we want to know what the community thinks about it.”

We were told to expect a complete “code reset” in the next few months. One observer called it a “code flush”.

I spoke to several industry veterans. They were almost scornful. Acropolis, in their view, was not even half baked.

I’m much more optimistic myself … but then take heed of Caveat #3: I’m a CAB believer and I really want Acropolis to succeed.

What can be done?

The present situation is troubling but I think it can be redeemed.

First, make a clear list of “Acropolis 1.0” priorities and announce them. The team should feel confident they can deliver on these priorities.

Second, pare down the ambitions. Acropolis has been called “CAB 2.0”. It looks like it wants to be “CAB 5.0”. At this rate it will be “CAB 0.5” and runs the risk of delivering in 2010.

Third, be good to the community. Deliver at least as much functionality as “CAB 1.0”. It’s the programmer’s Hippocratic oath: “do no harm”.

That might mean that the declarative and visual design capabilities of Acropolis don’t ship in the first release. So be it. Acropolis will be ok with the many of us who have been getting along just fine without designers. At least we’ll find out if the architecture and base implementation are sound. Visual designers can enhance the development experience but they can’t replace it. They’re just lipstick on a pig if the Acropolis core is porcine.

SHOULD I USE CAB, ACROPOLIS, OR NOTHING?

This question deserves (and will receive) a separate post.

Everyone agrees – including the Acropolis team – that you should not use Acropolis today. Read about it? Absolutely. “Spike” with it? If you can afford the time. But I personally can’t afford to do more than poke at it with a long stick until it is more thoroughly baked.

“Should I use CAB?”

I say “yes”, for five reasons:

1) CAB is the best architecture available for rich UI applications with more than ten screens.

2) CAB and Acropolis rely on many of the same design patterns and implementation techniques.

These patterns and techniques will be new to you (they were new to me). It’s a significant effort to jump from the way you build applications today to the CAB way.

It reminds me of the leap from procedural to object oriented code. Remember how your first objects were thinly disguised procedures? You got over it and learned to appreciate the benefits of object orientation. I’m betting you wouldn’t go back.

Something similar happens as you learn to program in “CAB style”. I would never go back now.

Fortunately, the knowledge and experience you acquire while building a CAB application will translate to Acropolis. You will pick up Acropolis quickly because you made the difficult mental transition during your CAB development.

This fact was glaringly obvious as I looked around the room. The people with CAB backgrounds “got” Acropolis immediately. Those who didn’t were almost completely lost – I saw a lot of glazed eyeballs.

Yes, Acropolis attempts to shield you from the more jarring constructs. I think it will succeed to a degree. But you will have to understand those constructs at some point and that point could come early.

3) You will be able to migrate your code from CAB to Acropolis when the time is ripe. Not directly; Acropolis won’t mimic CAB and I expect that the class hierarchies and behaviors will be completely different. I understand that Patterns and Practices will work on automated migration tools but I shouldn’t have to count on them

Designing in CAB style means factoring your application in a way that will move readily to Acropolis. Imagine the difference between migrating a traditional, green-screen Cobol program to .NET and migrating a Java program to .NET. Neither is automatic. But the structure of the Java program might come across almost intact.

4) There is no better alternative. You could roll your own infrastructure. I’ve done that several times already. Homebrew has one advantage: I (think) I understand what I wrote. Everything else is a negative: I’m working on plumbing instead of product, I’m the only one who understands it, I have to maintain it, it breaks down under the stress of new requirements, I can’t share code or concepts with anyone else, I get sick of it but can’t move on, … and so on.

Oh … did I mention that I’ll be stuck with an application infrastructure that is difficult or impossible to migrate to Acropolis when its ready?

Not an issue? You mean you won’t be able to afford to migrate for years to come? Well CAB is not going anywhere. It’s open source and bound to be better documented than anything you write yourself. Your application will be in better shape with CAB than with your own infrastructure whether you migrate to Acropolis or not.

5) Acropolis may not arrive for quite some time. I don’t want to jinx it. It just looks to me to be far more than a year off the pace. It might ship on time if they trim their ambitions. I can’t bank on it.

That means your CAB application will have a longer life than you expected.

THE GOOD

In this all-too-brief section I report the encouraging signs from the TechEd show.

The Presenter Was Great

I’m going to be dishing some tough love in this post. I want to be sure that we don’t shoot the messenger (and I don’t mean me). The fellow who demonstrated Acropolis knew the product, knew what he was doing, knew the “why” of every step, and clearly loved Acropolis. He was also honest and forthcoming which I sincerely appreciated. Should he have told us that today’s bits were likely to be completely different in CTP2? If that was speaking out school, I can only thank him. Imagine how pissed we’d be if they sprung that switcheroo on us later.

Acropolis Is Real

The demonstrated code worked. The short examples conveyed the key points clearly. He jacked the code around at will, freely straying from the script, and there were no unpleasant surprises.

Ok, that isn’t a particularly high hurdle to clear but at least it wasn’t “slideware”. The Acropolis designer is clumsy – I would almost say it is weird. But it never failed (a tribute to the presenter’s expertise) and showed real promise as a dynamic, visual representation of the application’s components (of what we CAB folks know as the WorkItem).

I hasten to add that he played it extremely safe. He dragged components on to the Acropolis design surface but never removed them; removal and most other alterations were made through direct edits of the Acropolis XAML. This may be forgiven to a degree - we all know that designers are the last and least stable elements of a product – but there was more timidity than I’d like to see when we are presumably only a year from release. We were also given to understand that the ultimate designer would be dramatically different.

The core components seem to be in place. I thought I could identify new versions of my old CAB friends: WorkItem, WorkItemController, service, view, presenter, command, and event.

Navigation and ConnectionPoints

The most obvious Acropolis improvement over CAB is its attention to navigation. The UIExtensionSite is the weakest of the important CAB elements in my view. Acropolis appears to have given this more careful thought with its attention to “Navigators”. I don’t know what they are yet but I can tell I’m going to like them better than UIExtensionSites.

The “ConnectionPoint” unifies properties, commands and events although precisely how escapes me at this time. I was satisfied to see that it gives us a better, easier handle on communications between view and presenter and between presenter and application controller without sacrificing the loose coupling essential to these design patterns. This is one of the most difficult tricks in CAB development so, if they’ve nailed it, that is a significant accomplishment.

Templates and Inheritance

Acropolis seems to have distanced itself from the software factory approach. They have turned to Visual Studio templates instead.

I really like the software factory in concept so this seems a step backward at first. But I think it’s the right call for now.

SCSF ships with a collection of software factory recipes – and I can’t use any of them. That fact never troubled me. I assumed that the given recipes were for demonstration only. The View/Presenter recipe, for example, generates a view that inherits from UserControl, a presenter that inherits from SCSF’s Presenter class, and a “do nothing” interface.

A serious CAB application would use views and presenters that inherited from application-specific base classes. The interface is often unnecessary and, if truly needed, should probably inherit from a base interface. I have to be able to write my own recipes.

Unfortunately, recipe development and deployment is a difficult, time consuming task today. I too have turned to Visual Studio templates which work fine for now.

The Acropolis team is right to focus on the core elements of their platform and leave factories for another day. The Patterns and Practices team could explore and improve Acropolis factory support on its own without impeding Acropolis development. Just making factory development easier would be a hugh accomplishment.

Acropolis intends to ship with a healthy set of starter templates that inherit from base classes. That is a good step but template creation will be as much a requirement of Acropolis development as it is of CAB development. The Acropolis team should provide guidance in this area.

The Visual Studio template macro language seems pretty lame. Maybe I just don’t know how to use it. In any case, the Acropolis demonstration leaned on wizards to extend their templates which should tell you something.

I don’t think wizard writing is going to be easy for anyone outside the Visual Studio team. There was mention of providing Wizard extension points; that is an initiative that gets an enthusiastic vote from me.

THE BAD

Earlier I summarized some reasons for serious concern. I take them up in detail in this section.

Why Acropolis?

The Acropolis team has done a poor job of articulating why Acropolis exists. It has the look of a solution looking for a problem.

The demonstrations I attended didn’t even attempt to explicate the problem that Acropolis addresses.

I know I promised not to look at blogs or documentation – but I peeked any way. There is almost nothing on the “why”. Instead we are taken directly to the “how” and even this story is relentlessly obtuse as in the following representative quote:

“it really boils down to providing a framework that allows you to build modules that encapsulate different client application strategies, providers or patterns, that you can then combine in various combinations to ‘compose', or assemble, an application.”

I can’t sell this to management. I can’t sell it to developers. I’m going to have a hard time getting any kind of adoption.

Moreover, if we can’t explain the value proposition clearly, we are sure to lose our way in setting goals and priorities.

Do I have a “statement of purpose”? Sort of. It starts like this:

“.NET gives us a lot of technology for building the parts of an application. We have some technology for connecting those parts behind the scenes where there are no humans to bear witness.

But we sorely lack technology and guidance for building entire people-oriented applications with their rats nest of screens, navigation, business rules, etc. We’ve had to cobble together this infrastructure for ourselves. We’ve done it over and over and over again. We’ve each spent an enormous percentage of our time on this kind of plumbing, we do a lousy job, and we can rarely reuse our efforts on the next project. As the application grows and requirements change, our infrastructure becomes more frail and less accommodating. A lot of the really bad bugs live down here.

Acropolis provides the application infrastructure we need to build robust applications with rich UIs, applications that can respond well to the addition of new modules, to integration of existing modules, and to sudden changes in application logic.

You’ll want to use Acropolis for applications with just a few screens because it takes only a few hours to get them up and running with a production-ready look-and-feel. But it is not a prototyping tool. Idling under the hood are components and architecture to propel a modularized, distributed application with hundreds of screens and thousands of business rules.”

Sure it sounds like a marketing pitch. But at least I know what the problem is, what Acropolis intends to do about it, to which situations it applies, and how hard it will be for me to get started. It even implies some metrics for success.

No Goals, No Priorities, No White Paper, No Commitments

Maybe they exist but they were not available at the show and I’ll be damned if I can find them online. There don’t even seem to be PowerPoints!

The presenter would say “we’re thinking about doing this” or “we’re thinking about doing that”.

That's nice but what is Acropolis going to do for sure. I asked if there were any announced design goals. “Nope”. Priorities for the first release? “Nope”. Architectural commitments? “Nope”.

How can this be?

I remember well how LINQ hit the scene one year ago. The purpose and goals for LINQ were absolutely clear. There were early bits and we knew things would change. But we there were excellent, detailed white papers and we knew that LINQ syntax was stable. I’m sure it has changed some in the last year but not much.

Contrast that with the Acropolis announcement. No white paper, no goals, no commitments.

Here is the official line on the present state of Acropolis.

“We're fairly early in the development cycle for Acropolis. We decided to
release this CTP release so that we can get your early feedback on the direction and features of Acropolis and to allow you to get involved in its evolution.”

That does not sound like a Microsoft product arriving any time soon. Anders wanted our feedback too. But it wasn’t an open slate. “Hey, Anders – how about moving the Select to the front where it is in SQL?”. I don’t have to ask ‘cause it ain’t going to happen. For good reasons laid out in meticulous detail before I can think to ask the question.

The Acropolis position is practically an invitation for design by committee. Hey David, give us some boundaries, ok?

No Silverlight Story?

As I said, one of the really curious aspects of this announcement was the perpetual refrain “we’re thinking about …”.

In the absence of announced priorities, it is incredibly difficult to plan for Acropolis. Moreover, the few hints of the undisclosed priorities suggest a faulty process. Permit me two examples.

One of the things the Acropolis team is thinking about – seriously I suspect, given that it came up repeatedly – is enabling Acropolis applications that span AppDomains.

Sounds cool, I guess. I remember that the CAB community was polled about this feature several months ago. It didn’t get many votes as I recall.

No wonder. It’s hard to think of an enterprise application that really needs this feature. I can think of only two scenarios in which the ability to load in an AppDomain might be useful.

1) To isolate a new module that might be unstable; if it failed, it couldn’t bring the rest of the app down.

2) To enable de-installation of a module at runtime without terminating the application.

I know these are important scenarios for Visual Studio. I just can’t think of an enterprise application I’ve seen or worked on in the last thirty years that needed either of them. Maybe I’m missing something.

Now contrast this dubious initiative with another capability: running in Silverlight.

I asked if Silverlight support was on the board. I was told it had been discussed but did not have momentum in the team.

How can that be? Silverlight has to be one of the most important technologies around and it bears directly upon the breadth of the opportunity for Acropolis applications.

Acropolis is a technology for building smart client applications. The rap against smart clients is (a) you have to install them and (b) they leave a footprint on the client.

That means we can’t write smart client applications for corporations that lock down their PCs and we can’t write smart client applications for consumers; neither market will tolerate any apparent installation or client footprint.

Silverlight gives us a shot at delivering the smart client experience in a safe browser sandbox which should be unobjectionable to security-conscious businesses and worm-wary consumers.

Maybe it’s just too hard to do in release one. I’m cool with that. But give the feature some love. Don’t talk to me about cross AppDomain applications (which won’t be in release one either); tease me with the future of Acropolis in Silverlight.

Immature Code

It was abundantly obvious that the CTP1 code is no where close to the code that will ship. We were told straight up that we should expect the next few CTPs to be “code resets”.

I appreciate the honesty. It's critical that I know that now rather than discover it later. But knowing it doesn’t help me warm to the prospect of investing serious time with Acropolis now.

It’s great that you want to “allow [me] to get involved in its evolution” but how can I offer help when everything is up for grabs?

Here’s a news flash: I don’t want to design Acropolis, I want to use it.

Unit Testing and Debugging

The Patterns and Practices team have been strong proponents of unit testing. All code is shipped with unit tests. The Model – View – Presenter (MVP) pattern is largely justified on the grounds that it facilitates testing.

Visual designers are wonderful for rapid development but they rarely deliver testable, reusable code. Acropolis is as big on designer-based development as it is on design patterns like MVP. There wasn’t a word about unit testing. I asked about it and was told that the Acropolis team has examples. That’s great but it doesn’t seem to be a consideration intrinsic to the designers. For example, I don’t see evidence that the designers emit a test harness.

Debugging CAB is notoriously difficult. It is not strictly the fault of CAB; both static code analysis and debugging are a challenge for any infrastructure that relies upon significant amounts of indirection.

Intrinsic tracing support and CAB visualizers are two tools that improve our ability to figure out what is going on. What is Acropolis doing about this?

Where Have You Been For A Year?

Acropolis has been in stealth mode since its inception. The last CAB release was December 2005. It’s been frozen solid since then and a number of our customers who bet heavily on CAB have been openly worrying that Microsoft will drop CAB altogether. Anyone not under NDA was kept in the dark.

The long silence seems ill advised. You weren’t interested in my input for the last year and suddenly you want to “allow [me] to get involved in its evolution”! That’s vaguely insulting, don’t you think?

Anyway, the word is out now. Acropolis is “CAB 2.0”. Sweet.

So what have you been doing for the last year and a half? CAB gave you a running start at Acropolis. Where is the CAB inside Acropolis? I think it's in there somewhere - I can hear it rustling around under the covers – but it would be nice to have a clear idea about how the highly successful CAB patterns and practices found expression in Acropolis.

No Reference Apps

None were shown. There were roughly six single screen demos – all very cool - but nothing demonstrating the concerns of building a composite application. There wasn’t anything on the (tiny) scale of the CAB “Bank Teller”. Did the Acropolis team reproduce “Bank Teller” as an Acropolis app?

I realize that teaching tools are not first on the agenda during early stage development. But reference applications are not just educational. They are a proving ground for the product. It is hard to have confidence in Acropolis as a foundation for large, complex, composite applications when there is not a single example of even a simple composite application.

I am hoping that I am wrong and that I’ll find such an application when I unfold the CTP1. Remember that I am reporting impressions from the show. There was not even the hint of a reference app at the show. If it were my product, you can be sure I’d be demo’ing the biggest app in my bag.

What’s up with the documentation?

I’ve already harped on the lack of white papers. I’ve peeked at the help file. It’s really lame; a mere 13 printed pages if you don’t count the reference help generated from XML and the two “walk-throughs”.

I thought the Acropolis team might have learned an important lesson from the CAB project: documentation is critical to product success. CAB adoption has struggled not because it is hard but because it is largely a mystery.

Well there is about 10 times the documentation for CAB as there is for this CTP. The Acropolis team should have booked a tech writer from the start and turned her loose on adapting the CAB documentation to Acropolis. The CAB forums are full of valuable material. I’m not referring to the answers, which likely apply only to CAB. I’m talking about the questions, which will be just as relevant to Acropolis as they were to CAB.

Can any one at Microsoft produce a decent video?

The lone video on the Acropolis website has a great script but it is blurry from the start and seems to get more so the longer it plays. By the end we're looking at the application through a thick gob of Vaseline.

I’m playing it now in Windows Media Player. I can see it was produced with Camtasia. I make Camtasia videos all the time. I deliver them in (horrors) Flash because Flash videos play clearly on all media players and in all browsers.

I’m all for eating the Microsoft dog food but there comes a time when you have to concede that the message is more important than the medium.

Conclusion

Acropolis has a great pedigree in CAB. The CTP1 first look is suggestive of an exciting future. But if the project continues on its present course, that future is years away. Someone had better trim the sails and head for port soon. Until then, this ship is lost at sea.

Goodbye PDC 2007

Microsoft just postponed PDC 2007 into the indefinite future and did so barely five months before the event was due. Be glad you aren't the Los Angelas Convention Center or a Vendor with thousands of "PDC 2007" plush toys.

The buzz is that Microsoft postponed because there wasn't anything futuristic worth saying. See Scoble's blog and Mary Jo Foly's blog for their opinions on this score.

Makes sense but the cynic in me thinks that there is more to the story. There's a ton of technology due at year end and almost all of it is behind schedule. Taking the best and brightest off-line in October for several weeks would have further strained the timeline.

Even if that isn't the reason, it's a good reason. I'd rather have the promised products sooner and in fine shape than endure a dog-and-pony for a half-baked future.

Hope to see you at Tech Ed in Orlando; drop by the IdeaBlade booth.

"Why CAB?" Webinar Feedback

Our "Why CAB?" webinar had tremendous attendance. One hundred twenty showed and people were still registering after it was over. Stay tuned for the link.

Meanwhile, there were many unanswered questions and comments of such general interest that I thought I'd respond here.

Q: The webinar addressed two distinct audiences - managers and architects - but it seemed to speak mostly to the manager. I'm an architect who recommends to management; I think it might have been better if you spoke more to the architect.

A: That's a great observation and a dilemma we suffered through. Although the webinar announcement clearly target the manager, promising to make the business case for CAB, we knew that most of the initial audience members would be architects.

In this webinar, we were trying to prepare architects to explain the business import of CAB to management. Architects tend to be good at speaking to each other - and not so hot at communicating with management. We hoped to arm the architect with material that managers could understand and find persuasive.

It isn't that managers are stupid. Rather, they are accustomed to technical staff proclaiming the "next great thing" without any business rational. They've heard too many hasty and unsubstantiated "better, cheaper, faster" arguments backed by incomprehensible techno-babble.

We made the "better, cheaper, faster" case to be sure. We hope we did so in a cogent fashion, supported by value points in CAB. We tried to explain the tangible substance of CAB - going beyond the marketecture - without dropping into the withering detail that architects crave and manager detest. We hope we made a case you can use with your management - one that speaks to their concerns without talking down.

We did not expect we could fully persuade the architect of CAB's merits; that's a project for another day. On the other hand, we tried to include enough developer meat to persuade the architect that CAB is worth a deeper look.

Q: What is the difference between SCSF and CAB?

A: I don't think we were as clear about this as we could have been. Let me try again.

CAB is an architectural layer for building composite applications with a user interface - with a "client" of some kind. That client could be a smart client, web client, or mobile client and each of these client types can be implemented with different UI technology. CAB is a foundation for building all of them.

You can think of SCSF - The Smart Client Software Factory - as a layer on top of CAB. While CAB is for any client application, SCSF targets "smart clients" in particular. There are parallel "software factories" - Web Client, Mobile Client - that target other client types.

The other key difference is that CAB is just code while SCSF is a "software factory".

Code is something you can take and use. A "software factory" has loftier goals. It provides not just code but all kinds of artifacts (e.g., documentation). Moreover, many of these artifacts are generated on-the-fly according to "recipes" devised by application architects (people like you and me). Executing recipes typically present a wizard; the developer answers the wizard questions and the recipe generates the artifacts.

The application architect can build his or her own recipes and, thereby, direct the development process, guiding application development along well-prepared paths that promise the speed and quality characteristics we expect of a "factory" process.

One final - and crucial - point: you can use CAB without SCSF; you cannot use SCSF without CAB.

Q: Can you recommend something to read about CAB/SCSF?

A: We took a stab at this in the webinar. It's not as easy to read about CAB as it should be. For the most part, you have to poke around in many places and cobble together your own training course.

The place to start is the Microsoft Patterns and Practices site: http://www.codeplex.com/smartclient.

Take the time to read the help files for both CAB and SCSF. I like help files (.chm files) for getting an answer to a question but I prefer reading the printed word if I'm going to cover a large subject. One of our clients printed and bound the CAB help files ... and I am supremely grateful. I suggest you take the time to do the same.

The best whitepaper to my knowledge is Mario Szpuszta's Raiffeisen Bank whitepaper.

David Platt is writing a book, due this summer, and is touring the country with his seminars. I have not been to one myself but I know someone who has and he thought is was very good. I read a few of the page's from David's handouts and they looked darn good to me as well.

There was an article about CAB in the September 2006 issue of MSDN magazine. Be advised: this is not a good introduction to CAB. I found it impenetrable when I first read it; it makes much more sense to me now. Read it after you have a little experience.

At my company, IdeaBlade, we are promoting "The Cabana Project" as a vehicle to learn CAB. It consists of a reference application, training classes, and training materials that show you how to marry CAB and our DevForce product. We're light on the explanatory materials at the moment but that will be changing shortly. Check it out.

The SCSF and CAB "hands-on labs" and reference applications are not "literature" by any means but they are a viable way to explore and learn. Note that the SCSF examples were developed after the CAB examples and reflect some important changes to the preferred patterns. In particular, SCSF recommends MVP over MVC and the use of a WorkItemController instead of subclassing the WorkItem; I strongly agree with these changes.

Which brings me to observe that there are many divergent opinions on the "best way" to build CAB/SCSF applications ... mine among them. Frankly, I have yet to find anyone who understands real world MVP ... except me (ha ha) . I'll be setting the universe straight on that soon.

Q: Is the Cabana version demonstrated in the webinar available for downloading?

A: You can get it from our "The Cabana Project" web page. I am about to update that code this weekend to reflect my latest thinking ... and will follow with a VB version soon after. Go there now if you can't wait.

Q: It doesn't seem that Cabana uses the Windows Forms designer for building the views; is this a CAB restriction?

A: Briefly and emphatically: "No, you can use the visual designers just fine in CAB and SCSF."

Clearly I have some explaining to do - explaining that is outside the scope of this particular blog entry.

In fact, I use the visual designers a lot when it comes to laying out simple "form" views. But, as you may know from some of my other writing, I don't use them at all for grids and it is important to understand how to construct "form" views entirely in code if your application will change the appearance, behavior, or visibility of the widgets on screen at runtime. Cabana demonstrates the role of the presenter in such scenarios.

You may also be highlighting another design preference of mine that gets strong play in Cabana: building by composition. What appears to the user as a single page is actually composed from many individual views, all instantiated, assembled, and coordinated by a "page controller". We talked about this a bit in the webinar and we discuss (and demo) it at length in our CAB classes.

Look for more on this subject in my upcoming CAB video series.

Q: How does the Infragistics CAB Extensibility Kit fit in if you are building apps with CAB and IdeaBlade? How about Developer Express and other third party control suites?

A: Infragistics has been a leader in its support for CAB. For example, they've done a great job of wrapping their UI container controls so that CAB applications can use them as CAB "Workspaces". They wrapped their menus and toolbars for use in CAB "UIExtensionSites". They re-wrote some of the CAB reference apps to demonstrate how to use their controls in a CAB application. And they've provided some instructional materials to help you get going. Check them out.

Espen Schaathun has been doing the same thing for Developer Express controls. I don't think Espen works for Dev Ex; this looks like another contribution from an angel in the CAB community.

Both Infragistics and Dev Ex CAB "extension kits" work fine with our IdeaBlade DevForce product by the way. Contact us to learn more about that.

I don't know what other UI control vendors are doing to support CAB.

Q: Do you have a login module, with users and roles?

A: IdeaBlade offers several login examples suitable for 2-tier and n-tier applications all of which work with CAB. There are two in Cabana if I remember correctly. None of them do anything with roles.

Murray (my co-anchor on the webinar) expressed some thoughts on this topic in the Q&A section of the webinar; you might want to contact him to learn about his experience.

It isn't hard to capture and forward roles. They fit neatly into the .NET IPrinciple interface that we support. We just haven't gotten around to demonstrating how to do it.

It is somewhat harder to settle upon the way you will use roles in your application. This topic is out of scope for today's blog (follow up with me later).

I must add that CAB provides native support for selectively adding and removing modules based on user role. The SCSF "Action Catalog" offers an answer to the question "how should I make my business logic conditional upon user role?" You may want to explore these topics in the help and reference apps.

Q: I have heard of MVC and MVP; what is that all about how would that matter to me?

A: Murray and I agree that Model-View-Presenter (MVP) is a critical, high-level "design pattern", one greatly facilitated (but not required) by CAB + SCSF.

I can't cover the pattern here; I'm going to do a presentation on it some time next month. And if you ask the question this way, don't worry about what MVC is or how it differs from MVP; the distinction is more useful to historians than practitioners.

For now, I'll leave you with these thoughts.

• The most important aspect of the pattern is the separation of your business object (M)odel from the "presentation" which is represented by (V)iew and (P)resenter. Do this even if you never separate (V) from (P).
  
  
• Separation of (V)iew from (P)resenter translates to a separation of visual layout components (the view) from the supporting non-visual code (the presenter). Yes, I'm oversimplifing but, as Jack Nicholson (sort of) said, you aren't ready for the "truth".
  
  
• Do this in order to
  
  
• Identify, isolate, and consolidate the behavior that is common to many or all of your views. Such abstraction and consequent refactoring is all but impossible until you physically separate the idiosyncratic visual material from the hidden logic that the views obscure.
  
  
• Test your UI. It is notoriously difficult and expensive to test the application user interface so almost no one does. Acknowledge this fact and deal with it. Deal with it by pulling out the non-visual logic into a separate class that you can test. Keep pulling until you've left behind in the visual class (the view) whatever it is that you can no longer afford to test.
  
  
• Prepare for migration to different visual technology. This could be as simple as a change of UI control suites. I'm able to switch from .NET to 3rd party controls in my "view" classes rather easily without altering the non-visual, "presenter" classes. Moving to WPF will be harder; but this step - separating visual from non-visual - will make that transition easier than it otherwise would be. The same goes for re-imagining your application as a web or mobile client.

Q: Has anyone heard any word on a VB version soon (or at all) of the Smart Client Software Factory?

A: Our understanding is that this is on the SCSF roadmap.

To be honest, it has been on that roadmap a long time and it keeps getting bumped. The folks at PnP respond to community votes and, it would seem, the voting community wants features more than it wants VB. I think PnP should consider the "silent plurality" and I will say so.

Of course I've been a culprit in this too. I converted the key parts of Cabana to VB once. But I've forged ahead in C# and the VB lagged. I intend for the VB to catch up in the next week or so; but you know where that road leads.

Q: Is CAB meaningful to VB developers?

A: Yes, yes, yes!

Actually, I think CAB itself is available in VB. The SCSF is not in VB yet. But that really shouldn't stop you.

You may say "well the recipes only generate C#". I have a confession. I don't use the recipes. I used them once, to get started and never used them again. Ok, I'm weird. I really would like to use the recipes (and will do so as soon as they fix a few things). Meanwhile, I'm making use of all the rest of the CAB + SCSF goodness.

And I can do so in the language of my choice. If I were you, I'd just leave CAB and SCSF projects in their native C#. Forge ahead with your application in VB.

Of course it won't be perfect. You should be able to read C# if you have to - we should all be able to read either C# or VB. The debugging experience is not as nice when you have to cross a language boundary. But its livable and worth it in my opinion.

I say this from some experience. I translated a lot of Cabana into VB for a client; I left core parts of the infrastructure in C#. It wasn't hard to live in the VB projects.

It beats the alternative.

Q: I notice that PnP hasn't updated the CAB CTP since December 2005. What are Microsoft's future plans with regard to CAB? Will CAB become obsolete?

A: Murray and I try to answer that in the webinar. We've asked the PnP team the same question. Unfortunately, there is not much that we are permitted to tell you.

We can say that CAB is regarded as a big success in Microsoft. I know some heavy hitters in the developer community who have dedicated serious cash, job security, and prestige to their CAB-based apps. CAB may change over time but the fundamentals are sound and it is going to be a part of the .NET eco-system in one form or another for years to come. This is no flavor of the month.

If you are wondering "is CAB worth learning today?" or "is do I risk building with CAB today?", I answer, emphatically, "yes!"

If you have to know more, contact the PnP team yourself; if you are persistent and have a compelling, business-driven need to know, I think you will get the answer that you need.

Q: Does the smart client software factory replace the need for a framework?

A: Absolutely not!

Both CAB and CAB+SCSF are just glue. You have to supply the parts to glue including an enormous amount of foundational material. You can pick up some of the infrastructural components from open sources such as the PnP's own Enterprise Library. Even then, I think you leave yourself with a lot to do.

Here's my shameless commerce moment although I believe it to the depth of my soul: you will save money, time and trouble if you buy application infrastructure from a reputable vendor - like IdeaBlade.

This answer in no way diminishes the considerable accomplishment of CAB + SCSF. It may be "just glue" - but it is great glue and, without it, you'll have a pile of parts and pieces that don't stick together well.

In the webinar we compared CAB to Web Services. I don't think any one would ask "Do Web Services replace the need for an application framework?" We all understand Web Services a little better now; we are pretty clear about what Web Services do and what they don't do.

We lack that clarity vis-a-vis CAB. So people are more likely to think that CAB addresses everything in the way they might once have thought that Web Services solve everything.

Q: Can you learn CAB from the Smart Client Software Factory or do you need to start with the Composite UI Application Block?

A: Please see above where I talk about how to learn CAB + SCSF.

Perhaps it is worth repeating. Every SCSF application is a CAB application. SCSF adds value to the CAB layer. Accordingly, when you examine an application built with SCSF, you are learning CAB and SCSF at the same time.

There are reference applications for both SCSF and CAB. The CAB reference apps happen to be WinForm applications so they are both "smart client" apps (leading to some confusion I suppose).

All of the reference apps are worth a look. Just remember that the SCSF apps apply a slightly different twist to some of the design patterns.

I might as well plug Cabana once again as yet another way to learn CAB and SCSF design principles.

Q: Do CAB or SCSF provide multi-language support?

A: They neither add to nor detract from .NET's mult-language / multi-culture support. At least I am unaware of anything in either CAB or SCSF that addresses this issue specifically.

Q: Is there a Vista upgrade plan?

A: Yes. Vista support should be available "very soon". Really.

Q: Does CAB support Windows Presentation Foundation (WPF)?

A: Actually, CAB supports any kind of client technology. CAB is client agnostic.

The PnP team is developing a WPF version of the Smart Client Software Factory. That should arrive "soon" too.

This really intrigues me because WPF is much more than another control suite (the impression one gets from the marketing). It is far more than XAML and code behind. There is a lot of new architecture in there. Many of the new constructs (dependency properties, routed events, routed commands) have a lot in common with features in CAB that people have claimed are too "mysterious".

If you've been looking at WPF, you'll see instantly how CAB and WPF are made for each other.

That said, I really wonder who is going to do serious WPF development in the absence of adequate visual design tools. It's going to be a long time until Orcas gets here. I'm not a huge fan of wrangling XAML by hand.

Q: Can we integrate WCF into a CAB app today?

A: Sure.

CAB itself doesn't have anything to say on the problems for which WCF is the appropriate solution. There is no specific "home" in CAB for WCF that I am aware of.

CAB concentrates on the plumbing necessary to glue together components within the same process (indeed, within the same AppDomain). WCF concerns bridging process boundaries.

I'm no expert on this, as someone is sure to observe. I think Juval talks about using WCF to wrap access to integers or something like that.

So the PnP folks may have added some WCF sauce that I don't know about. Visit the PnP Smart Client website to find out more.

Q: What was Murray's Blog url again?

A: http://www.geekswithblogs.net/murraybgordon

Validation through Verification

Where have I been the last few days? I've been slogging away at a tutorial and accompaning videos that explain our new mechanism for validation. We call our implementation "Verification" because Microsoft has several "validation" offerings, each with its own "Validation" namespace; talk about confusing!

If you want to check it out, visit our training videos page. It's not completely finished as I write this (apologies especially to my VB friends); I expect to remedy the shortcomings by next week.

Meanwhile, I've been getting ready for the CAB webinar next week (check out our web site for details). I know many people want advice on how CAB works and how to write CAB applications. I'm looking forward to answering that call in print and video (I've been teaching classes about it for over a year).

It has been clarifying to concentrate solely on why CAB makes business sense. It is the rare developer who commands his own budget. Like it or not, we have to explain our choices to a skeptical, non-technical audience. It would be handy to have a ready-made case to present to that audience. I'm hopeful that this webinar can help fill that bill.

Upcoming "Why CAB?" webcast

Have you heard about the "Composite UI Application Block (CAB)" from Microsoft Patterns and Practices? How about the "Smart Client Software Factory (SCSF)"?

They address a gaping hole in the enterprise application development process: how to wire together large applications.

We've got lots of tutorials and sample applications that show how to build a simple screen or solve a single problem. But there is not much available in .NET for assembling the whole enchilada.

It's not like we can avoid the issue. We've all been gluing our apps together in one (unsatisfactory) way or another. I've probably written five separate "application frameworks" in .NET alone. Not because I wanted to. Because there hasn't been an alternative.

Along comes CAB to promise me that I won't have to do that again. Well almost.

CAB combines a tremendous number of solid, established patterns for building large applications as loosely coupled components. On top of CAB there is a "software factory" to help us routinize the application-specific artifacts (especially the application's standard views).

Many find CAB intimidating even when supplemented by SCSF. I was certainly one of that multitude. I'm over the hump now ... and can hardly imagine app development without CAB. Yes, even on small projects.

Now I recognize that these glowing sentiments are possible only because I spent an inordinate amount of time wandering around in the dark, smacking my head on this and that unseen obstacle. There are plenty of us with bruised foreheads and scraped knees. Something has to be done about making CAB/SCSF more accessible ... not just to your average developer (that goal is out of immediate reach) but to your fairly seasoned application architect. I'm working on the education front in my copious spare time.

Is CAB worth it?

I raise a resounding "Yes". I think CAB is transformative technology in much the same way that the shift from procedural to object orientation was transformative.

The "transformation" is not just for geeks. This isn't just another bit of wizardry to learn.

CAB could be most important because it can reduce total life-cycle costs, improve our ability to respond to changing business requirements, make us more productive, and help us shrink the dev team to manageable size. Instead of throwing more bodies at a project (bodies half a world away) we could get the work done close to home - close to the end users who actually understand what we're supposed to build.

CAB could become the basis for a common development culture. Today, each of us is inventing his own application infrastructure - his own private kingdom. Hiring a new developer? You have to show her around the realm; teach her the local dialect, warn her about the trolls over there and the flaming swamp over here. Relax your grip - perhaps to illness, vacation, or insurrection - and your brief reign will not be remembered fondly.

In CAB world everyone speaks the same language. Each of us may have his own idiosyncratic take on the core concepts but at least the major constructs are recognizeable. Show me a CAB app for the first time and I can quickly find North and South, discover the principle landmarks, negotiate its highways.

Murray Gordon (an MS MVP) and I will be talking about all this in a WebCast on April 24, 2007. We're not going to explain CAB - that can't be done in an hour. But we can introduce you to CAB, show you some results, and equip you to explain CAB's potential to management.

Check us out.

My First Blog Post

Welcome to my "Never In Doubt" blog whose title trumpets the arrogance I hope never to display. Fat chance.

Well, actually I intend to maintain a high degree of civility and respectfulness in this blog even as we (you and I) make bold, unflinching pronouncements.

I am the v.p. of Product Management and a founder of IdeaBlade, a .NET enterprise application development framework company (www.ideablade.com). I won't shy away from talking about our product - it is my passion after all - but I'm not here to flog it either.

I am excited by issues surrounding development of enterprise apps such as Smart Client, Object Relational Mapping, data access, web services, WinForm UI development, Microsoft Composite UI Application Block (CAB), deployment, and agile development practices. If you are following along, you'll be reading a lot about these topics and adding your two cents I hope.

"Enterprise Applications" is one of those broad, typically meaningless terms. I have something quite specific in mind - something that many would call "line of business" applications.

These are "sovereign applications" (see Alan Cooper, http://www.cooper.com/articles/art_your_programs_posture.htm) that capture the attention of "knowledge workers" for extended periods almost every day. Think stock traders and travel agents.

You would recognize such apps instantly; they

• fill the screen (rather than a small corner of it)
• sport many "forms" and window panes
• demand crisp user interaction
• support rapid task-oriented "context switches"
• display a lot of rich, often complex data

Such applications still dominate the corporate scene, usually as tried-and-true "client / server" Windows applications. Someone along the way may have tried to migrate them to the browser ... and failed miserably ... at least from the perspective of user productivity.

It always amazes me how many organizations will inflict a poorly performing mess of browser eye-candy on a put-upon work force. The culprit typically has been promoted by the time the company acknowledges that productivity has actually declined. Not that the users didn't scream from day one; it's just that no one seemed to care or they were too powerless to resist the juggernaut of money and senior management committed to the browser app fantasy.

Here comes Ajax, giving mouth-to-mouth to that corpse. We see the chest rise and fall and shout "it lives!" Sorry folks. I think Ajax is great for the one page app but it is hopeless for the multi-page, highly stateful, enterprise app.

That's my rant of the day. Cheers, Ward