Friday, April 27, 2007

"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:

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?


Thursday, April 19, 2007

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.

Thursday, April 5, 2007

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.

Tuesday, April 3, 2007

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 ( 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, 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