Designing Smart Client Based on CAB and SCSF

Architectural Guidance for Composite smart Client

Introduction

Enables the components to communicate in a loosely coupled way so the modules do not really depend on each other.
Different applications are dynamically plugged in to a central infrastructure. Loaded and initialized on demand based on the user's security context.


PART 1 : Architectural Guidance for Composite Smart Clients

CAB providing following functionality

1. Dynamically loading independent yet cooperating modules into a common shell.
2. Event broker for loosely coupled communication between modules and parts of modules.
3. Ready-to-use Command pattern implementation.
4. Base classes for Model-View-control(MVC) pattern implementation.
5. Framework for pluggable infrastructure services ranging, such as authentication services, authorization services, module location, and module loading services.

WorkItem - Container for managing objects. Workspaces holding these objects

Service - encapsulate functionality that is common for the whole client application, for a specific module, or just for WorkItems within a certain hierarchy of WorkItems.

Module - Multiple, logically related WorkItems into a single unit of deployment.

ProfileCatalog - specifies which modules and services need to be loaded into the application.

ModuleLoader - responsible for loading all the modules specified in a profile catalog.

ModuleInit - Each module consists of a ModuleInit class, which is responsible for loading all the services and WorkItems of a module.

Shell application - responsible for initializing the application. It dynamically loading modules, launching the base services, starting the main form(Shell).

Shell - main form of the application. The shell always hosts the root workItem.

Workspace - is a control responsible for holding and displaying user interface elements created by WorkItems. Workspaces are added to the shell.

UIExtensionSite - special placeholders for extending fixed parts of the Shell such as menus, tool strips or status strips.

Command - is a base class of CAB for implementing the Command pattern.

Model - cient side business entity a WorkItem processes.

View - implements only UI logic.

SmartPart - A SmartPart is a .NET Framework user control with the [SmartPart] attribute applied.

Controller - is a class that implements the logic for modifying a model.

Objectbuilder - creating objects that require specific builder strategies to be created or that need features.

DependencyInjection - create or initialize properties/members of objects with dependent objects. ObjectBuilder provides this functionality.


Smart Client Software Factory.

Designing composite smart clients takes place in three iterations

1. Non-UI related functionality that is common to all the use cases are candidates for central services.
2. Create detailed use case diagrams. Use cases are good candidates for becoming WorkItems. Relationships between use cases are candidates for using either the Command pattern or the event broker subsystem of CAB. Close related WorkItems are good candidates for being packaged into modules together.
3. Refine use case diagrams. WorkItems that are reused independently of other packaged into the same module or used isolated from their parent WorkItems so that they are better suited as first-level WorkItems.

Application Shell-Service and Infrastructure Service Design

One of the first parts to design and implement for CAB-based smart client is the shell.
The shell is the actual application that is responsible for

1. loading and initializing base client services
2. loading and initializing modules
3. providing the basic UI of the application
4. hosting the SmartParts loaded by first-level Workitems.

Common user interface elements that need to be added to the shell are the following:

1. Menus, toolbars, and tool strips
2. Navigation controls, such as the Outlook toolbar
3. A common message pane for having a central point to display messages for the user
4. Task panes, taskbars
5. Context panes that display information based on the current situation of the user

These elements are integrated into a shell with Workspaces and UIExtensionSites.
workspaces are used for completely replacing parts of the UI.
UIExtesionSite is used for extending existing parts of the shell.


Infrastructure Services

encapsulate functionality common to all modules and components loaded into the smart client. CAB introduces many infrastructure services, such as an authentication service or a service for loading a catalog of modules configured somewhere (ProfileCatalog.xml)

1. Authorization service
2. Web service agents and proxies encapsulating calls to Web services and offline capability
3. Context services to manage user context across WorkItems
4. Configuration services for accessing application-centric configuration
5. Deployment services using ClickOnce behind the scenes for programmatic, automatic updates

Identifying WorkItems

WorkItems are components responsible for encapsulating all the logic for specific tasks the user wants to complete with the application.
A WorkItem itself contains or knows about one or more SmartParts (views) with their controller classes and models.
Each CAB application has one RootWorkItem that acts as the central entry point for global services and WorkItems added by modules.

There are two ways for identifying WorkItems for your composite smart client

1. use case-driven approach
2. business entity-driven approach

Use Case-Driven Strategy

One use case will be encapsulated into a WorkItem.
Pure sub-use cases are sub-WorkItems that are not accessible from outside their parents.
Use cases used by many other use cases in addition to its own parent need to be accessible either directly or through their parent WorkItem.


The Role of Root Use Cases
They are responsible for managing state required for all sub-WorkItems and providing the right context for all their sub-WorkItems.

It accomplish the following steps when being loaded:

1. Add services required by this set of WorkItems
2. Retrieve service references required by this WorkItem
3. Register commands for launching sub-WorkItems
4. Add UIExtensionSites to allow starting into WorkItem-code via previously registered commands
5. Create instances of sub-WorkItems when they are needed
6. Create and register instances of SmartParts required by the WorkItem itself

Summary
The following steps identify WorkItems based on use case diagrams for CAB-based composite smart clients:

1. Create the use case diagram
2. Map each use case to one WorkItem in CAB
3. Exclude use cases not directly related to your smart client
4. Analise relationships between use cases, If use cases are used by other use cases in addition to their parent, they are candidates for becoming first-level WorkItems
5. Analise requirements of use cases. If use cases do not depend on state or context of their parents, and vice-versa, they are also candidates for first-level WorkItems

Packaging WorkItems into Modules

A module is a unit of deployment for CAB-based smart clients logically related WorkItems that address the same space of business into a module.
Modules are configured in a profile catalog. These modules can be configured based on role membership of a user.
If you want to reuse WorkItems independently from others, it makes sense to encapsulate them into separate modules.


CAB Infrastructure Usage Guidelines

Relationships between use cases represent interactions between use cases.
CAB supports two types of interactions between components

1. Active communication - through an implementation of the command pattern
2. Passive communication - through its event broker system

Using the Event Broker System

provides a pre-built infrastructure for loosely coupled events. That means any component loaded into CAB can publish events, and other components can subscribe to these events without knowing who the publishers are.
The event broker is used while a CAB component wants to provide information to others without getting immediate response and without requiring knowing who receives events.
If you need immediate response or need to know exactly who a component is talking to, the event broker is the wrong system.

Using the Command Pattern

If your component needs something to be done immediately by another component or is passing control on to this other component.
Use commands for launching WorkItems (or sub-WorkItems) instead of events.



Part 2: Developer's Guidance

Steps for creating a CAB-based Smart Client

1. Create a smart client project using SCSF.
2. Creare the shell and its components, and design the shell's UI.
3. (Optional) Create and Register services.
4. (Optional) Configure CAB infrastructure services if you have created ones in step 3.
5. Create CAB modules containing WorkItems with SmartParts and their presenters.
6. Configure and run the application.

1. Create a smart client project using SCSF.

Projects created by the smart client software factory

a) Infrastructure.Interface
Defines interfaces for basic services created by SCSF.

The added services created by SCSF are

1. Entity Translator Base Class - Base classes for building translators of entities.
2. Basic SmartPart Info Classes - when you want to display additional information for a SmartPart when it is being added to a workspace. For example, if you want to display a caption in a tab created within a tabbed workspace.
3. ActionCatalog Service - allows you to define specific methods of your classes as actions.
4. DependentModuleLoader - you can specify that one module depends on others to be loaded before it gets loaded itself.
5. WebServiceCatalog Service - you can retrieve the modules to be loaded at startup of your smart client from a Web service.

b) Infrastructure.Library
Contains the implementations of the additional services generated by SCSF.

c) Infrastructure.Module
An empty module (default root WorkItem for a module) where you can add your own infrastructure service.

d) Infrastructure.Layout
A project SCSF creates if you selected that you want to put the shell's layout into a separate module. It contains a SmartPart and a presenter for this SmartPart for the shell layout.

e) Shell
The actual Windows-based application of the smart client that contains the configuration and the actual main form that hosts the shell layout


2. Creating the shell and its Components

1. Design the basic UI of the shell and add CAB UI components.
2. Register UIExtensionSites for UI parts that are extended but not replaced by loaded modules.
3. Create interfaces for UI-related basic shell services.
4. Implement and register UI-related basic shell services

3. Creating and Registering New Services
You can start creating and registering other services commonly used by components loaded into your smart client.

4. Developing CAB Business Modules
WorkItems themselves are responsible for launching sub-WrokItems and SmartParts as required for completing a use case.

Steps for Creating a CAB Business Module

1. Add the new business module using the Smart Client software Factory.
2. Add new WorkItems to the created module. Each Work Item encapsulates a use case.
3. (Optional) Create a new sub-WorkItem.
4. Add state required for a WorkItem and its sub-WorkItems.
5. Add the SmartParts required for a WorkItem.
6. Create commands for launching first-level WorkItems.
7. Create an ActionCatalog for creating UIExtensionSites.
8. Publish and receive events as required.

4. Configure the Application
There are two parts you need to configure: the catalog containing the list of modules to be loaded and the application configuration itself. The profile catalog understands dependencies between modules.