Great piece of news - today in the patterns & practices group we went through our M0 milestone for an exciting asset to assist with Smart Client development.

We are calling it the CAB - which stands for Composite UI Application Block. It is not a great name, because it doesn't tell you much about it either directly or metaphorically (yes, if you have suggestions let us know). Here are other names you could give it:

- Smart Client Portal
- Extensible Shell
- That-Which-Includes-The-Functionality-Of-UIP-Windows-and-More

We will be publishing more about it pretty soon. Here is just a 20.000 feet AGL view.

CAB 101

Complex smart client applications have a growing need to be built and deployed as separate packages, packages that may contain visual and non-visual components that need to collaborate (AKA find, and communicate with) other components to perform the work. Patterns to tackle the ensuing challenges exist and the CAB helps you implement these patterns by providing infrastructure code you'll need.

The main areas the CAB helps with are:
a) Apps built of "modules" or plug-ins. In this scenario, typically a general-purpose shell is built by a "shell development team" or the dev team with a "shell development" hat on and business logic gets deployed as add-ins. Here you'll need common infrastructure like a catalog of plug-ins, a plug-in loader and an interface for your plug-ins with events such as ApplicationStart, BeforeApplicationClose and so on. CAB has an implementation of this that is extensible.

b) Component Collaboration Patterns: Apps may integrate many components visually and non-visually to fulfill a use case. There are many patterns that help here like MVC, Application Controller, BlackBoard, Memento, Service Locator and so on. CAB will have common infrastructure to help with these patterns.

here are some teaser snippets that we are building to - these are either part of our codebase already or will be soon. These are mostly about non-visual component interaction - we'll deal with the visual part in a future post (and that'll give us the team a chance at stabilizing the designs a bit more :) )

Example 1: Simplify finding and connecting to events across components, even with your own eventArgs

public class AAA 

public void UpdatesAvailable(object o, UpdatesAvailableEventArgs)  




public class BBB

public event EventHandler<UpdatesAvailableEventArgs> UpdatesAvailable;  


Example 2: Reuse of use cases encpasulated as a class for a modal interaction:

FindCustomerContext fcx = new FindCustomerContext();
myId = fcx.FindCustomer("WA");

Example 3: Referencing a Controller frm a View (e.g. for MVC), injection style (shown on a field for simplicity):

public class SomeView

    public CustomerUpdatesController myController;


Example 4: Finding infrastructure services, again injection style:

public class AnyComponentYouBuild

    public IMyLogggingService logger;

public void DoSomething()
//use logger ....


Example 5: Adding UIP, or use cases with a strong "process control" need, using UIP whatever-process-style-you-like (e.g. petri nets for the fans out there). This area is not implemented yet but here is a teaser nevertheless:


public class MyProcessDrivenContext  : Context

    [Navigator("My Navgraph")]
    public MyNavigator navigator;

public void DoSomething()
         //or a strong typed flavor, since you've taken the work to build your own Navigator:


CAB Plans

Explaining CAB Plans is better left for eugeniop (our product manager), all I'll say for the moment is that we want to have a technical preview hopefully before august, based on VS.NET 2005 Beta 2 so you can play with it.


A little bit of introspection on CAB...

There's many things I like about this project, from the team, technical and architectural perspective.

Team: Peter Provost is our Dev Lead, with Daniel Cazzulino, Juan Carlos Elichirigoity & John Luif as devs, Rohit Sharma as our test lead, RoAnn and Lin Joyner as our UX arm. Bill Loeffler is keeping us all on track as the PM and Eugenio is the product manager. The team is full of brilliant people and I've enjoyed working on it from day 1. This project has also strong legacy from David Hill and his team - he and Brenton Webster have been working with customers in this scenario for a long time and they help us "mine" the patterns that customers face.

Process: We are following our Smart Client community process. One thing we learnt is that it's good idea to have a staged approach with regards to the announcements of patterns & practices deliverables. So we have modified the process to first have a set of conference calls with the expert advisors only, and expand to include the world in the community by M0. This means that we have had already (3 or 4) roundtable sessions with product group, partners, field and customers to discuss CAB concepts and design. Internally we are doing a TDD, agile, everyone-in-the-same-room-as-much-as-they-can 2 week iteration approach (emphasis on as-much-as-we-can). We are switching to 1-week iterations as of today. We keep all our spec as part of the public documentation in an internal wiki, and a build-per-checkin rythm for continuous integration. So far it's worked out great.

Architecture stuff: One of the things that strike me the most however may even be called predictable. The principles that drive the integration patterns that exist across organizations and SOA-style services somehow get expressed in mostly similar patterns, at a smaller scale within a client application process. Computing and complexity of applications is growing and the patterns we have used to integrate large systems are making their way inside our applications.

Take some inter-system integration things for example - Communication tenets and state ownership best practices to general patterns like event brokering, and process control, are all driven off a basic set of principles that are scale-invariant. Especially as the CPUs applications are built with become capable of more parallelism (HT, multi-core, and so on), we will have to build components that can run concurrently and share information with predictable rules - and it will demand for capabilities that go beyond the lock, mutex and sempahore style that we are used to today. Those things don't scale to share state at the enterprise level (of course, that's not what they are for, but I'm trying to make a point) but in some time in the future they may stop being good ideas as ways of having multiple activities work with data even in the same process on a client.