ARC312
Smart Client Architecture
Chris J.T. Auld
Managing Director- Kognition
Microsoft Regional Director & MVP
chris@kognition.co.nz
Agenda
Why smart clients?
What is a smart client?
How do you decide between
browser-based and smart client UI?
Changes in n-tier architecture for smart
clients
Drill down on client tier architecture
Data transport
Data containers
(datasets vs. business objects)
A Spiraling Evolution
of Architectures
Advent of networked PC –
Intelligent interfaces improve
productivity
Centralized
Web Server
Centralized
Mainframe
“Dumb” terminals
allow minimal
support for user
activities
Decentralized
Client-Server
Intelligent interfaces
develop cost effective
deployment and data
transport.
Distributed
Smart Client
Intelligent interfaces have no
cost-effective Internet reach.
“Dumb” browsers have
cheap deployment but limited
support for user activities.
Browsers Limitations
HTML not designed as application
interface technology
Minimal GUI elements
Limited control over user interaction
(keystrokes, drag and drop)
Limited client-side data validation
Costly to produce effective UI
Immature security model (“Would you
like to install this component from
Gator Corp?”)
What Is a Smart Client?
No agreement on general definition
Emphasizes intelligence in the UI
Takes full advantage of the client
machine
Typically means a true Windows interface
Client UI has some level of detachment
from the rest of the application
This may mean flexible ways to get and
store data
Often means offline capabilities
Key Decision Points
Do you control the user’s operating environment?
Are offline capabilities required?
Will a better UI translate to productivity gains and
resultant savings?
Is it important for your application to access local
resources on user machines?
Do you need (or would you benefit from)
alternative UI – handwriting or speech recognition?
What security capabilities do you need?
Lesser factors
Distribution of processing overhead
Efficient utilization of bandwidth
Peer-to-peer capabilities
Bottleneck: .NET Framework Required
Limiting factor: the .NET Framework must be
on all client machines
First candidates for distributed smart clients:
Corporate applications (control over desktop)
Commercial or extranet applications where a
minimum platform can be required
.NET Framework becoming ubiquitous
# of Framework installations growing rapidly
Future O/S versions
Service Packs
Other .NET applications
Where are Smart Clients
Most Important?
Corporate apps for distributed
operations
Healthcare, transportation, supply chain
Etc.
Distributed data entry systems
Commercial packages of all kinds,
especially vertical market packages
Applications that require offline
capabilities
Technologies Required
Standard HTTP connection from
each client machine to a web server
A forms engine and execution
environment running on the client
machine
A way to easily and cheaply deploy
the application to the client machine
One or more ways to transport data
to and from a central server
A security model that limits the
ability to do damage to the client
machine
A means to secure access to the
system and the data
Broadband
Windows Forms
Copy and Run /
ClickOnce / etc.
Web Services /
Remoting
Code Access
Security
Authentication /
Authorization
Class Three Tier Architecture for
Client/Server and Web
Presentation Tier
User interface
Middle Tier
Components, Rules
Data Tier
Relational Database
Must be refined for distributed smart clients
Increased processing power on the client
Ability for client to store state information
Data transport options must be handled – both
for now and the future
Many n-Tier Principles Still Apply
Data tier is mostly unchanged
Stored procs may need to support new paging
designs, more robust batch updating, etc.
Middle tier still isolates all database
interaction
Controls connection to RDB with its own
credentials
Parts exposed to web outside firewall, rest of
middle tier inside
Entry points to business tier can include
technologies such as message queue
A Tiered Architecture for Distributed
Smart Clients
UI – Forms and controls
Common components
and controls
Channel Adapter (data façade)
Port 2
e.g. Web Services
Client machine
Local storage
for caching
Web server
Port 1
e.g. Remoting
Business rules, etc.
Application server
Data access layer
Data tier (database)
Database server
Client Layer Drill-Down
Form A
Form B
Form C
Form D
Form E
Etc.
UI – Forms and controls
Data validation
Security
Base forms
Etc.
Common components and controls
Customer
Order
Product
Vendor
Etc.
Channel Adapter (data facade)
Standard interface
for Get / Update / etc.
Local store for
caching
Data transport
channels
Building the Client Tier
Componentize as much logic as possible
Minimize repeated code patterns in routine
forms with frameworks or toolkits
Data validation
Data management
Security
Use high level controller as app-entry point
Isolates security checking, menu building, etc.
If possible, get data validation rules from
database
Key Technologies
Extender Providers in Windows Forms
Dynamic loading of .NET assemblies
Need location of assembly, and name of
type to get instance
Allows apps to have dynamic construction
and single entry point
An Example of Extender Providers
for “Dirty Checking”
Drag and drop checking to see if data
has changed
Demonstration
Note that this is an implementation of
the Observer pattern
Application “Portals”
Complex applications need an
“application shell” or “portal” to
coordinate sub-systems
Flexible plug-in pieces for menuing,
authorization/authentication
Data driven list of user options, with
screens loaded on demand
Process uses dynamic loading of
assemblies
Typical Code to Load a
Dynamic Form
Dim sLocation As String = {set assembly location}
Dim sType As String = {set class name of form}
Dim formAsm As [Assembly] = _
[Assembly].LoadFrom(sLocation)
Dim ClassType As Type = formAsm.GetType(sType)
Dim Classobj As Object
Classobj = Activator.CreateInstance(ClassType)
Dim FormToShow As Form = CType(Classobj, Form)
FormToShow.MdiParent = Me
FormToShow.Show()
A Composite
Application Shell
Data Transport
Presentation
`
XML
UI
Business Logic
Data Access
Data Storage and Management
?
Transport vs. Host
Transport
RPC, Queues, etc.
Host
IIS, Enterprise Services, etc.
Separate but dependant issues
Competing Technologies
RPC
DCOM, RMI, Remoting, Web services
Async Messaging
MSMQ, MQ Series, JMS, Async RPC
Services (SO)
Web services, Indigo, other transports
Today’s Options
Web Svc
Data-centric
Object-oriented
XML/SOAP
Binary
Pass thru firewall
IDE support
Code controlled
Peer to peer
Events/callbacks
Stateful objects
Ent Svcs
Remote
n-Tier
Application 1
Application 2
Presentation
Presentation
UI
UI
Business Logic
Business Logic
Data Access
Service Façade (Data Access)
Data Storage and Management
External Service
DataPortal
UI
Business Logic
DataPortal Façade
DataPortal
Data Access
Data Access
Data Access
Data Access
Data Access
DataPortal
Client facade
Abstracts the server/transport/host
Acts as a channel adapter
Server portal
Abstracts server (transactions, etc.)
Acts as a broker or message router
Channel Adapter / Ports
Drill Down
Order
Product
Vendor
Etc.
Channel Adapter (data façade)
On the client
Customer
Channels
Web Services
Remoting listener
MSMQ
Business rules, etc.
Data validation requiring connected access
Aggregation / disaggregation of data
Data access layer
Etc.
In the middle tier
Ports
Data-Centric (Fat UI)
How Do We Push Data Around?
Objects
Datasets/DTOs (per Martin Fowler)
UI
Logic
Business Logic
Data Access
E.g. Traditional VB3/4/5/6 Client Server
No way to put logic in dataset
Need to use a function library or;
Put logic in UI
Data-Centric (“thin” UI)
UI
Logic
Business Logic
Logic
Data Access
Put logic on separate machine so you can’t cheat.
You will cheat.
You still need to get data to the UI
Distributed Data-Centric
UI
Logic
Business Logic
Data Access
Same flaw as original model- just now have network
connection.
Distributed Objects
UI
Logic
Business Logic
Logic
Data Access
Objects really just pumping data in and out at both ends.
Client-side Objects
UI
Business Logic
Logic
Data Access
Not bad approach.
Populate local intelligent objects on client from DTOs
Mobile Objects/Agents
Fully mobile objects serialized and de-serialized.
Can be useful but has higher overhead at development time
Demonstration
A multi-transport DataPortal
Resources
More Information:
chris@kognition.co.nz
www.syringe.net.nz
Your Feedback
is Important!
Please Fill Out Your Eval
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.