Composite UI Application Block

What is this about? You've probably seen some posts in EdJez's blog on the Composite UI Application Block (CAB).

So, are you considering a Smart Client approach to address the challenges of building Line of Business solutions that interact with many backend systems? Ever wondered what would the architecture and design of a complex UI would look like? Do you need to abstract the "plumbing" of such client applications so your business developers can focus their attention on building the business specific components rather than dealing with complex issues like threading, asynchronous requests, etc.? The CAB could be a good candidate.

There are many examples of such UIs. Here's one used by Dell in their call centers:

Each section of this screen shows a different aspect of the agent (end user) tasks. The UI reacts to these interactions in a way that makes the whole experience much richer, faster and more appropriate to a particular context; effrectively empowering the end user to make decisions faster and with better data quality. This consistent UI is in fact interacting with dozens of heterogeneous backend services that take care of specific part of the business process that supports the Dell call center. Dell was able to increase their end user productivity by reducing the call length by 10% and decreasing their training costs by 45% with such an approach; and also increase the efficiency of their development teams. (More information and details on the Dell Call Center case here)

There are many other examples of such solutions and all of them have common design principles.

What are the basic design principles of these applications?

All these applications have the notion of a "container" or Shell for autonomous "parts" (SmartParts as we call them). These SmartParts are assembled together to build a solution or instance of an application. The set of parts that yield an application may be defined by different rules: may be fixed, may be declared in a manifest or configuration file or may depend on the role of the user logging in. In essence, the shell is a hosting environment that controls the lifecycle and provides common infrastructure services to contained SmartParts.

Among the common services that are usually availabe for SmartParts we found:

• Loading
• Updating and deploying
• Aspectual services (like logging, auditing, authorization)
• Common UI services (like menus, toolstrips, status bars, etc.)
• Eventing (generally by providing a mechanism for notifications between SmartParts)
• State management services (to keep data that needs to be shared between SmartParts to complete a given task)

Each one of these SmartParts that make up the whole UI are in fact different and independent components that are composed (thus Composite UI Application Block) to build a particular instance of a solution. Yet, each one of these modules are completely decoupled form each other; and could even be developed by completely different teams. As a matter of fact, we envision three different roles using the CAB:

• The architect, would use CAB to build the reusable infrastructure and define the common services to be used by all applications
• The solution developer would develop SmartParts that could be used anywhere
• The solution assembler would create an instance of an app composing SmartParts and maybe some "glue" code

The CAB is guidance developed by patterns & practices , in the form of an application block that will assist you in creating the common underlying architecture described above; providing the adequate extensibility points that will allow you to customize it to fit your needs.

Last week we pubished our first community drop. Yes, source code for you to look at and experiment! Check it out in the community workspace we set up to publish our intermediate builds and design documents. Any feedback, please send it to pagcabfb AT microsoft.com