UIP User Interface Process Overview and Architecture

1
UIPUser Interface ProcessOverview and
Architecture
Michael StuartSr. Consultantmstuart_at_microsoft.co
m
2
Problems with UI Today

• Navigation and workflow are business services not
  UI problems
• Navigation in UI SPAGHETTI CODE
• UI contains stranded state in member variables
• Passing state between views hard/messy
• No way to dehydrate snapshot of current
  interaction
• UI spaghetti
• Un-maintainable
• Un-extensible

3
Goals of UIP

• Main 4 Goals
• Pull all navigation and workflow OUT of UI
• Use same programming model for Windows and Web in
  .NET
• Introduce notion of Task, a persistable entity
  snapshot of an interaction
• Abstract state management out of UI layer into
  UIP

4
Goals of UIP

• Ancillary Goals
• Make code reuse easier between Win/Web by using
  same Manager, State, Controller etc.
• Better enforce layer distinctions architecturally
• Make nav/workflow config-driven for ease of
  maintenance

5
Usage ScenariosConsuming UIP

• Usage Scenario means HOW the UIP will be used
  by developers
• Out-Of-Box
• Only develop Views Controllers, possibly ITask
• Leave State as-is
• Leave StatePersistence as-is
• Strong State
• Develop own derivation of StatemyState State
• myState encapsulates Model data in strongly-typed
  way
• Custom ITask implementation
• Kung Fu Developer
• Strong-typed State
• Custom IStatePersistence Implementation
• Custom IViewManager, IView too possibly

6
UIP Use Case 1DARN MANAGER

• Darn, Manager ComingClose Browser
• Youre shopping online at lunch
• Manager walks by, close browser
• Come back hour laterwould you like to resume?
• Session restored seamlessly

7
UIP Use Case 2HANDLE PRESSURE

• I Cant Handle the Pressure
• Help desk person helping customer
• Interaction is 7 screens deep in 17 screen total
  WinForms application
• Helper needs to hand off session to more
  experienced person
• Helper can dehydrate session, other helper can
  rehydrate across logons and machines

8
UIP Use Case 3NICE APP, IS IT WEB?

• Nice App. Can We Web-Enable It?
• Multi-form WinForms application, a Point of Sale
  app
• Lots of state in forms
• Lots of decision branching
• Calls to multiple back-end Business Objects
• If designed around UIP
• ONLY actual UI needs writing.
• All Controllers, Managers, Config, StatePersist
  can be reused
• State might be rewritten to optimize, but not
  necessarily
• Navigation section in config modified

9
UIP Use Case 4--WIZARD

• Were Writing a Wizard
• Needs Next Back buttons
• Needs Confirm Cancel at end of Interaction
  Graph
• Strongly typed State that is held ephemeral
  until final Confirm
• Classic Wizard

10
UIP Use Case 5--CRUD

• Create, Read, Update, DeleteCRUD
• Classic use case
• Implement as fully-functional UIP CRUD
• Easy to abstract except for actual parameters
• Useful sample application
• To implement your own, cut-and-paste ours

11
UIP Terminology/Scope

• We envision apps centered around coarse Use
  Cases
• These are Navigation Graphs
• Start node, end node, none or many in between
• Allow branching, cyclicity within NG
• Example
• Checkout of online store
• Purchase ticket from airline
• Fill in part of mortgage application
• Create customer trouble ticket for credit card
  processor

12
About Navigation Graphs

• NG is one coarse use casesee previous
• NGs can be chained
• NG may have cyclicity, extensive branching

ltnavigationGraph nameCheckout" state"State"
statePersist"SqlServerPersistState"gt
ltnode viewaddress'gt
ltnavigateTo navigateValuenext" viewCCNum /gt
lt/nodegt ltnode
viewCCNum'gt ltnavigateTo
navigateValuebad" viewTryAgain"/gt
ltnavigateTo navigateValuegood"
viewKaChing' /gt lt/nodegt
ltnode viewShipping'gt
ltnavigateTo navigateValuenext" viewTHANKS'
/gt lt/nodegt ltnode
viewTHANKS'gt lt/nodegt
lt/navigationGraphgt
13
About Navigation Graphs

• In typical use
• Each NavGraph will have
• n Views
• 1 Controller
• 1 State, IStatePersistence
• NavGraphs will be chained together
• Using Manager.StartTask()
• State will be committed to backend at terminus of
  each Graphin most apps, but there are options
• Sharing State between Graphs is not a problem
• If app needs extension
• Add new View(s), write Controller for them
• Insert them into Navigation Config sections
• Rest of app remains unchanged

14
About Navigation Graphs

• HEY! Youve created strong coupling between the
  NavigateValues and the Views/Controllers!
• No we havent. ?
• Yeseach View has one or many outcomes
• Each has a NavigateValue associated
• Each View is totally self-contained Here I am,
  I need State and a Controller
• Each Controller is intimately tied to the problem
  domain of the NavGraph it servesits a façade
• The Controller understands that each View has
  finite outcomes
• There is a final layer of indirection
• navigateValue is related to name node in
  navigateTo
• ltnavigateTo navigateValue"fail" view"error" /gt

15
What about the State object?

• State object used by UIP
• Basic State is a serializable hashtable, acts
  like Session
• You may inherit State and have your own
  strongly-typed State
• State is typically dedicated to one NavGraph
• State acts like Model
• Its contents are the problem domain of the Use
  Case
• By default, State is dehydrated to database on
  each navigation
• Scalable, but may not be as performant
• State acts as ephemeral store of application
  state
• There when Views need it
• Automatically created/loaded by Manager
• Does not affect back-end state
• When you need to commit state changes to backend,
  you must do so in Controller

16
What about the State object (cont)?

• State object used by UIP
• You may choose NOT TO USE State at all
• Commit every change directly to back end via
  Controller
• Like typical stateless high-scale OLTP app
  architecture
• NO state in middle tier, roundtrip to DB each
  time
• You may choose to use it only partially
• Commit most real changes to backend immediately
• Allow some state to stay in State object during
  interaction
• For example, custName, custAddressmight be used
  in 2 Views in NavGraph, keep it in State for
  quick access
• You may choose an optimization
• Reduces portability but gives great perf, scale,
  etc.
• For example
• Use State object, but push all state directly to
  Session
• Get great scalability with Session Server or
  Session SQL
• To migrate to Win app, must rewrite State object
  again

17
How about custom IStatePersistence?

• IStatePersistence used by Manager
• Generic persistence of State objects
• Default is
• SqlServerStatePersistence, binary serialization
• SecureSqlServerStatePersistence, with encryption
• Implement your own IStatePersistence
• Add an IsDirty check to State, persist only as
  needed
• Store state elsewhere, perhaps in RAM or other
  mechanism
• Use our IStatePersistence that thunks directly to
  ASP.NET Session
• Very fast
• Optimizes app for web
• Later migration will require ONLY changing which
  IStatePersistence type that NavGraph uses1 Line
  of Config

18
What about the IViewManager?

• IView and IViewManager abstract Views from
  UIPManager
• Necessary to provide support for Win, Web, and
  later Other (CF, mobile, etc.)
• IViewManager.Activate() actually creates IViews
• Implement your own to support different View
  activations
• For instance Server.Transfer instead of Redirect

19
Whats the Deal with ITask?

• We have a Bootstrapping Problem
• First View of first NavGraph
• Does not have a Controller
• May not yet have a TaskID
• Needs to ask UIPManager for Controller, AND needs
  TaskID
• BUT when it does StartTask(), it dies and goes
  to next View
• How to retrieve TaskID gracefully from first
  StartTask() call?
• Create instance of ITask
• ITask has Get and Create(TaskID) methods
• UIPManager.StartTask(navGraphName, myITask)
• UIPManager asks Get if theres a Task already
• If not, UIPManager calls Create() passing in NEW
  TaskID
• YOUR APP handles Create() call
• YOUR APP can now hook up the new TaskID to
  whatever
• For example, make new Logon-Task DB entry

20
What is the Running Play Architecture?

• Busy web servers dont handle requests
  synchronously
• Take request
• initiate long-running backend process
• Calculate Mean and Standard Deviation for request
  return time
• Give user ticket (token) and a please wait
  page
• Set META-REFRESH to (Mean 2SD) seconds
• User page refreshes, handing back ticket
• 95 probability request is readyalter time to
  suit
• Web server instantiates resources necessary to
  serve request
• BENEFIT? Youre not tying up front-end resources
  waiting for backend jobs

21
What is the Running Play Architecture? (cont)

• Can I do Running Play with UIProcess?
• Of course, or this slide wouldnt be here ?
• Since State is cached by UIPManager
• UIP is perfect platform for Running Play
• Ticket is really TaskID GUID
• All you have to add is machinery to calculate
  Mean Standard Deviation (seconds to request
  complete)
• Views, Controllers all torn down by UIP machinery
  when request is waiting
• When View returns with ticket (TaskID)
• UIPManager recalls TaskID, instantiates
  Controller, hooks up State

22
Migrating Apps to Different Platforms

• Web TO Windows/Windows TO Web
• Views will need migration probably one-to-one
  correspondence of Views between platforms
• Controller will remain same
• State same, unless specialized optimizations made
• Alter configdeclare new Views and their types
• Workflow nodes will remain same

23
Migrating Apps to Different Platforms

• Web-Windows TO Cell phone
• Views need migration
• Web view would split to multiple small cell phone
  Views
• Controller might need modification
• UNLESS you have mitigated, put Navigate() call in
  EVERY method
• Or write new Controller with Navigate() calls in
  more granular places to reflect increased Views
• State same, unless specialized optimizations made
• Alter configdeclare new Views and their types
• Workflow nodes will need change
• Cell phone Views are smaller, so more of them
• Refactor original Views
• Redo workflow nodes with new cell Views

24
UIP Architecture 1
User Interface Process UI Layer
View 1
UIPManager
View 2
ControllerBase
ControllerBase
State
IStatePersistence
config
SQL
Application Layers BL/DAL
25
UIP Architecture 1
3) End delegate fires Manager
4) Manager uses Config to get navigation/type
User Interface Layer (UI)
1) Get Controller w/ attached State
6) Done, Dehydrate State
Manager
View 1
Config
2) View uses Controller
PersistState
5) Manager creates next View
Controller
config
SQL
View 2
State
Data Access Layer (DAL)
Business Objects (BL)
Backend Business Systems
26
UIP Architecture 2
Config, PersistState use Visitor pattern, get
plugged into Manager at runtime to permit
different implementations
User Interface Layer (UI)
View 1
Manager
Config IReadConfig
View 2
Controller State start life as abstract base
classes w/ default concrete implementationsout-o
f-box experience very easy, no new codebut
extension also possible
PersistState IStatePersist
Controller AController
config
SQL
State AState
Data Access Layer (DAL)
Business Objects (BL)
Backend Business Systems
27
UIP Architecture 3
Calls to Controller IDENTICAL between
Win/Webnote state managed by Controller.
User Interface Layer (UI)
View 1 private btn1_click() _controller.AddToCart
(17)
Manager
Config
PersistState
Controller mediates conversation with back-end
business services. Note dichotomy between
ephemeral and durable State
Controller public void AddToCart (int
item) _state.cart.items item _bo.UpdateCart(_
state.cart) this.Next()
config
SQL
State
Data Access Layer (DAL)
Business Objects (BL)
Backend Business Systems
28
Cust Questions

• what about cross-IG state passing? (duh, me)
• eventing, true MVC
• How bad on SQL is persistence
• Ways around it
• IsDirty
• Session
• How to do multiple simultaneous Tasks with
  multiple browser windows? How about Win?
• State management in OLTP large web
  appserialization penalty, roundtripping,
  caching, stateful middle tier in UIP if used
  w/out serialization