TechEd 2007 - Loose Coupling in Practice: Composite UI Application Block (CAB) in the Real World
Loose Coupling in Practice: Composite UI Application Block (CAB) in the Real World
David Platt
Nowadays many information is placed in remote data stores. This information can be accessed by browser clients (webpages) or rich client applications (windows forms). Generally rich clients beats browser clients because of the overhead on interface loading. When an application is used every days, several times a day the interface performance is essential.
There is a big problem: date is stored over different locations and in different systems.
Mainly systems are application-centric. A user has to access different applications and mentally integrate information. As an example, a patient in the medical context may have access to medical record, personal data and laboratory results in different applications when the best choice would be to have an integrated solution. application-centric systems have a overhead, make people loose time and can lead to catastrophic errors.
On the other hand we have user-centric systems where information is integrated into one application that suites all the user needs (in some specific context). This system can be built as a monolithic application which doesn’t work technically or financially because it is unmanageable and you cannot make everyone change their implementation entirely to integrate.
A better idea seems to be Loose Coupling. Create almost independent blocks which are integrated in an common shell. This way we can have distinct data sources and little uniformity issues. An important question when building these systems is what does the user need? Will there be many kinds of users? Which specific functionality does each one need?
With those questions answered we can start to design an common user interface with shared elements (called shell) and think which interface (methods, events, properties) has each module that will be loaded into the aggregating shell.
In this area Microsoft started with Composite UI Application Block which had a publish/subscribe event system to allow inter-module interaction. It had a good architecture but it wasn’t easy to work with.
After the there was a new evolved system easier than this one and also with a good architecture. It is called Smart Client Software Factory.
This last one allows you to define an interface to a service like authentication, define several implementations and change the implementation that is being used by changing an XML file. You must define the interface, develop your implementation, or collect implementation made by third party companies, register these in your application and configure the application which to use.
You can also make some nice integration stuff with UI. There are two key concepts.
Workspace - A module placement zone
View - just a bunch of controls which display data (can be placed on workspaces)
The modules (different functionalities potentially from different software companies) can be integrated in the application by adding themselves into a workspace in the shell application. This creates a slight dependency: the modules must know the shell UI and their workspaces names.
The workspaces and places to which you can load the modules UIs. But this isn’t enough. There are some functionalities to which people are used to and which need a more integrated UI. For example the main menu in the top of the main window or the status bar. This is possible with UI Extension Sites! You just have to register shared zones to which each module can add items. For example each item can add some items to the main menu.
David Platt has written book published by Microsoft Press focusing this subject.
