1. Smart Client Program Composite UI Application Block patterns & practices Smart Client Team May 2005

2. Agenda  Vision  Customer scenarios and requirements  Architecture  Timeline  Call to action

3. Smart Client Program Vision Enterprise customers build high quality, mission critical smart clients as their LOB front-ends using Microsoft platform Strategy:  Provide an Application Block to help customers implement common smart client UI composition patterns, focusing on business logic and not the infrastructure required to support it  Provide a Baseline Architecture that illustrates the common patterns for LOB front-end scenarios  Enable community of partners & customers to converge on an extensible architecture, following the Community process

4. Smart Client Program Customer demand  Thompson: Financial Data Portal  Dell: Call Center  Commonwealth Bank of Australia: Teller Application  MSFT Call Centre Framework scenarios

5. Thomson Financials Project Background  Provide integrated Data/Analysis Services To Financial Services Community  Thomson ONE Analytics  Integrated Research and Analysis  Monitoring and Analysis Tools  Access to Research Data  Dual Channel Delivery  Smart Client – Advanced, Premier Users  Integration Of Client-Side Data Sources  Web – Ad Hoc, Casual Users

6. ThomsonONE Goals  Common Architecture for Next-Gen Apps  Streamline Development Process  Customizable & Extensible  User Composed Solutions  Solution Composed of Pluggable Service Agents  User Defined Views  Portfolio & Research Data  Smart Client Platform Services  Deployment, User Interface, etc.

7. ThomsonONE - Analytics

8. Dell Call Centre Project Background  3,000 Telephone Sales Agents  Internal and remote call centers  Integrated View Of The Customer  40+ Disparate Applications  Sales, CRM, Tech Support Tools  Releases of new front-ends took a lot of time  Web based solution +500K lines of javascript

9. Dell Goals  Maximize Agent Productivity  Rich, Responsive and Flexible  Simpler Development Model  Hosted Applications Independently Developed, Tested, Deployed  Solution Profile – Specific Combination Of Hosted Applications  User Role Flexibility  Common Architecture for Next-Gen Apps  Smart Client Platform Services

10. Integrated Dell Desktop

11. Composite UI Application Block Building Enterprise Smart Clients  Value for architecture teams: Quality & Consistency  Create a common development architecture for smart client applications  Have a consistent and predictable way of developing, packaging and rolling out infrastructure components to enforce architectural standards  Scale enterprise-wide guidance on building Enterprise Smart Client solutions  Value for developer teams: Productivity and faster ramp-up  A prescriptive environment that hides complexity and boosts productivity  Through abstraction & separation of concerns, developers can focus on business logic  Increased reusability of infrastructure code  Business goals: increased end-user productivity and agility of business tasks  Business owners can roll out new & updated functionality and tasks in a more agile way  Building UIs that allow end-users to perform tasks faster and with more precision and data quality avoiding data exchange through Alt-Tab, Copy-Paste integration style  Enhanced productivity through consistent UIs lowering training needs

12. Smart Client Scenario Family Smart Client Baseline Architectures Smart Client Patterns Smart Client Block Library Many “application styles” for LOB front end – Outlook hosted is just one Baseline architecture = composition of patterns + blocks Architecture Scenarios Smart Client encompasses a family of architecture scenarios. Customers have prioritized LOB Front End and Mobile scenarios Tool Extensions Making an app self-updatable Adding offline to service agents Creating MVC skeletons Configuring Offline Caches Collaboration with Siemens Distributed authoring under Creative Commons license Using patternshare.org (pattern-focused Wiki) Built on Enterprise Library foundation (logging, caching, etc) AbstractCode-based Specialized Devices Mobile LOB Front End Outlook- Hosted LOB Front End … Smart Client Blocks Updater AB (ev) Offline AB Composite AB Service Agents “Elixir” (OHAB) Composite LOB Front End

13. Asset Lineage How did we get here? UIP1 PAG UIP2 PAG CAB PAG CCF Field Thomson DPE Customer Dell DPE Customer CAB DPE Field FX / Prototype Customer Solution PAG Asset … David Hill David Hill, Brenton Webster et al. [Other field frameworks] This is not an emergent pattern!

14. Composite UI Design “Shell” Customers build “Modules” Modules Contain: SmartParts “Widgets” Support Services Module Configuration Whatever else the app needs Modules typically will contain: Business Logic Infrastructure component 3 rd party vendors Community Partners SmartPart 1 Svc1 [Other Components] SmartPart Y [Other Components] Svc1 Svc2 Svc3

15. CAB + Shell “ SmartParts” Context State “ UI Elements” Workflow & Process management Shell

16. Composite UI Design CAB Global Context CAB Layering Shell Visual Styles Hosting Model CAB “Core” Implementation of UI-less host Contract of Shells Contract of Modules Services Support Services Crosscutting stuff Declarative Shell OtherContext1 Host Service X Module Mgmt Event Broker Service Y (e.g. UIP) User Interface Elements SmartPart Managers SmartPart XSmartPart Y Services SecurityManagementCommunications & State Mgmt

17. CAB Context “Foo” Simple Shell & CAB Together Global Context Shell Host SmartPart 1 Controller 1 User Interface Elements SmartPart Managers & Base Classes Hosted Control Layout MDI StatusStrip UI Element MenuStrip UI Element ToolStrip UI Element Services ModuleCatalog ModuleLoader EventBroker [UI Process?] Context “Foo” Shared State SmartPart X Controller X SmartPart Y Controller Y Main Form Configuration [Authorization?] Biz Logic Devs Infrastructur e Devs Shell Devs

18. Event Broker Challenge:  Notifications & events one-way are necessary in UI design  publishers & subscribers don’t know about each other  You may have sources without handlers and viceversa Solution:  Event Broker  Events identified by an “Event Topic”  event://MyApp/Updates/UpdateAvailable  N publishers and M subscribers  Supporting strong-typed EventArgs between publishers and subscribers  Two scopes: global and WorkItem-wide events

19. Event Broker – Design Overview Event Topic Publishers Event Catalog Service event://UpdatesAvailable 1 * [EventPublication(“event://UpdatesAvailable”)] event EventHandler UpdatesAvailable; … if (UpdatesAvailable != null) { UpdatesAvailable(this, new SomeArg(3) ) } [EventSubscription(“event://UpdatesAvailable”)] Public void NewUpdates(object sender, SomeArg numUpdates) { MessageBox.Show(numUpdates.ToString(), “updates available”); } MethodEvent Publication Subscription Background Worker Background Subscription Subscribers

20. Features of the Event Broker  Strong Typing –  EventHandler lets you pass your own eventArgs type (e.g. MyType : EventArgs) [EventSubscription(“event://foo”,EventScope.Global)] public void DoSomething(object source, MyType stuff) { … }  Subscribe to receive on different Threads  Using the Background worker: [EventSubscription(“event://foo/bar/baz”,EventScope.Global,isBackground=true)]  Event Scoping  Global Events and WorkItem-Wide Events [EventSubscription(“event://foo/bar/baz”,EventScope.Global)] [EventSubscription(“event://foo/bar/baz”,EventScope.WorkIteml)]  Works on components, normal classes and static types  Components and objects get “inspected” when added to a Context or Host  Static types need to be manually registered  Can publish, subscribe to, and fire events programmatically as well as declaratively

21. Event Broker Background Subscriptions  Subscribers can declare the intent to run the subscription in a background worker  No change to publisher or subscriber code!  If the publisher or some other class wants fine-grained control of the background workers, it can EventTopic eventTopic = EventCatalogService[“event://myEvent”]; Examples of control functions eventTopic.RunningBackgroundWorkers.Count; eventTopic.RunningBackgroundWorkers[2]; eventTopic.RunningBackgroundWorkers[subscriberInstance].Cancel; eventTopic.RunningBackgroundWorkers.Cancel();

22. State Persistence  Example Scenarios:  Suspend-And-Continue  Delegate work items  “Checkpoint” and rollback work item state  Problem:  Work Items have shared state elements that may need to be saved  Solution:  Provide a simple mechanism to store & load WorkItem state  Essentially apply memento to the WorkItem (which is an application controller) to allow having a separate State object instead of just member variables and providing a service which acts as a repository for this State object

23. State Persistence  State persistence managed via a service  Provided Implementations:  SQL  Isolated File  File  Optional DPAPI Encryption  Invoking persistence:  Programmatically:  Q: Should we add the Save & Load method to the WorkItem class?  Coming Soon:  At “persist points” in UIP schema (onEnter, onExit states & transitions)  When WorkItems get suspended public interface IStatePersistenceService { void Save(State state); State Load(Guid id); void Remove(Guid id); } //your WorkItem [ServiceDependency] Public IStatePersistenceService persistence; public void SomeMethod() { persistence.Save(this.State); }

24. CAB Context “Foo” Acquiring Services Global Context Host SmartPart 1 Controller 1 Services ModuleCatalog ModuleLoader EventBroker [UI Process?] Context “Foo” Shared State SmartPart X Controller X Configuration [Logging]  Services are singleton components that provide access to infrastructure  Think EventBroker, Authorization, Logging,  Any module may include services  Services can be obtained programmatically or via an IoC declaration from any component  Override - Contexts can have services as well – when a component asks for it it precedes the host service  Services can use other services. Services can declare CompositeUIEvents  Only basic bootstrap services are included in the CAB main assembly: Catalog, Loader, Registry, and EventBroker [Logging]

25. UI Elements  UI Element Controls are portions of UI that modules have to “Share”  Toolbars, menu bars, status bars, notification areas  UI Elements are the ‘ things’ these controls know how to handle  Toolbar Items, menu items, Status Panel, Balloon, “Action Panes”  Shell developers:  1) decide what UIElements their shell will provide  Write implementations of IUserInterfaceElementControl  Write implementations of IUserInterfaceElement  Module Developers:  1) Decide what UI element instances they need (“ Add new customer…” menu)  2) Build Metadata and/or code to add those UIElements  May include ‘hints’ for relative layout, but in the end the shell control implementations decides where things get shown  3) Write code to respond to events from, or display text in, those UI Elements (or whatever the UI Element does)  This means a Module Developer will reference a specific shell, 99% of the time!  To mitigate this, CAB will provide two basic UIElement interfaces all shells should implement:  One for “ Action Commands” – Which a shell may display as menus, command bars, taskbars, etc  One for “Status Display” – Shell may display as status, notification, etc  Very basic UI Elements but lets module developers build shell-agnostic code

26. Demo

27. CAB is not…  A product  It is an Application Block from Microsoft patterns & practices that helps you implement common patterns in development  A library of UI controls useful for Smart Client  It is a set of components to help you structure what lies beneath the UI and the display  A metadata language to define UIs  The interaction between code components could be specified declaratively but you will not find schemas to define forms, fields, etc.  For that look to XAML Avalon & all that  We do intend to help component design that migrates easily to those architectures as they become available

28. Schedule MAR APR MAY JUN JUL AUG … V&S Feature Freeze Dev Start Internal Community M0.NET Beta 2 Expert Advisor Conference Calls Code Drop Content Complete Tech Preview on Beta 2 RTM on.NET 2.0 Code Drop

29. Call to action!  Join the CAB community:  http://workspaces.gotdotnet.com/cab http://workspaces.gotdotnet.com/cab  Download the Code Drop  Tell us what you think!  Stay tuned to the team blogs:  http://blogs.msdn.com/edjez http://blogs.msdn.com/edjez  http://www.peterprovost.com http://www.peterprovost.com  http://blogs.msdn.com/eugeniop http://blogs.msdn.com/eugeniop

30. Thanks!