.NET Application Design Considerations

1
.NET Application Design Considerations

• Mark SapossnekCS 594
• Computer Science Department
• Metropolitan College
• Boston University

2
Prerequisites

• This module assumes that you understand the
  fundamentals of
• Object-oriented programming
• C
• ADO.NET
• ASP.NET
• Web Services
• .NET Framework Class Library

3
Learning Objectives

• Understand how to design a .NET application
• Understand key design considerations on the
  following topics
• Scalability
• Performance
• Availability
• Security

4
Agenda

• Design Model and Process
• .NET System Architecture
• .NET Design Patterns
• Security
• Scalability
• Availability

5
Design Model and Process

• Microsoft Enterprise Services Framework
  Services-Based Application Design Model
• Design Process
• Design Principles

6
Design Model and ProcessMicrosoft Enterprise
Services Framework (ESF)
Microsoft Readiness Framework (MRF)
Microsoft Solutions Framework (MSF)
Enterprise Architecture
Microsoft Operations Framework (MOF)
7
Design Model and ProcessMicrosoft Solutions
Framework
Team Model
Process Model
Application Model
8
Design Model and ProcessMSF Process Model
Release
Scope Complete/First Use
Vision/Scope Approved
Project Plan Approved
9
Design Model and ProcessServices-Based
Application Model
Can be implemented as Web Services
10
Design Model and ProcessMSF Design Process
Overview
11
Design Model and ProcessConceptual Design
The goal of conceptual design is to understand
what the users do and to identify business
needs. The output is scenarios or use cases.
12
Design Model and ProcessLogical Design
Conceptual
Scenarios
The output is a set of objects and services,
high-level user interface design, and logical
database design.
The goal of logical design is to lay out the
structure of the solution and the communication
among elements.
13
Design Model and Process Physical Design
Conceptual
The goal of physical design is to apply
real-world technology constraints to the logical
model, including implementation and performance
considerations. The output is a set of
components, UI design for a particular platform,
and physical database design.
14
Design Model and Process Design Principles

• Understand and solve the business problem
• Communicate effectively with users and project
  teams
• Design based on a modular approach
• Consistent
• Distributable (Web-centric)
• Implementation language-independent
• Flexible
• Reusable
• Reliable
• Balance innovation and discipline through each
  iteration
• Pay attention to the Enterprise Architecture and
  Infrastructure

15
Design Model and Process Design Principles

• Object Stereotypes
• Design Patterns
• E.g. Factory, Singleton, Proxy, Flyweight,
  Iterator, Façade, Memento, Adaptor

Boundary (Interface)
Entity
Service (Control)
16
Agenda

• Design Model and Process
• .NET System Architecture
• .NET Design Patterns
• Security
• Scalability
• Availability

17
.NET System ArchitectureDistributed System
Architecture
Input/Output
Rendering engine
I/O Processing
Presentation logic
Everything Else
Business logic
Data Management
Data logic
Database
Data engine
18
.NET System ArchitectureWindows DNA Application
Architecture
HTML 3.2 Browser
Rendering engine
IIS/ASP (.asp)
Presentation logic
Business logic
COM Components
Data logic
SQL Server Database
Data logic
Data engine
19
.NET System Architecture2-Tier Application
Architecture
VB or PowerBuilderApplication
Rendering engine
Presentation logic
Business logic
Data logic
SQL Server Database
Data logic
Data engine
20
.NET System Architecture.NET Application
Architecture
HTML 3.2 Browser
Rendering engine
IIS/ASP (.aspx, .ascx)
Presentation logic
WebServices
.NET Assemblies
Business logic
Data logic
SQL Server Database
Data logic
Data engine
21
.NET System ArchitectureWeb Service Architecture
SOAP Clients
Rendering engine
Web Service (.asmx)
Presentation logic
.NET Assemblies
Business logic
Data logic
SQL Server Database
Data logic
Data engine
22
.NET System ArchitectureWeb Services Application
Model
Data Access and Storage Tier
Application Business Logic Tier
Other Applications
23
Agenda

• Design Model and Process
• .NET System Architecture
• .NET Design Patterns
• Security
• Scalability
• Availability

24
.NET Design Patterns

• Samples
• IBuySpy (http//www.ibuyspy.com/)
• MSDN Sample Duwamish 7.0
• MSDN Sample Fitch Mather Stocks 7.0
• Using Uniform Modeling Language (UML)
• Discuss design patterns of each sample
  application

25
.NET Design PatternsIBuySpy Portal Sample
26
.NET Design Patterns IBuySpy Design Patterns

• Clean code/HTML content separation using server
  controls
• Pages that are constructed from
  dynamically-loaded User Controls
• Configurable output caching of portal page
  regions
• Modular site layout defined by XML configuration
  file

27
.NET Design Patterns IBuySpy Design Patterns

• XML serialization that maps XML config file to
  custom config classes
• Cached config settings automatically reloaded
  when file changes
• Role-based security to control user access to
  portal content

28
.NET Design PatternsDuwamish Sample Application
29
.NET Design PatternsDuwamish Activity Diagram
30
.NET Design PatternsDuwamish Sequence Diagram
31
.NET Design PatternsDuwamish Design Patterns

• Move processing to the data rather than moving
  data to the processing
• Pass all data back to the client in a method call
  
• Minimize the time that a database resource is
  locked
• Use Binary/HTTP for remoting

32
.NET Design PatternsDuwamish Design Patterns

• Use ASP.NET within its Web layer and utilize the
  ASP.NET caching features
• Publish a single XML Web service named
  CatalogService to expose its book catalog search
  functions to the Internet

33
.NET Design PatternsFitch Mather 7.0 Sample

• A port of the MSDN Fitch Mather 2000 sample to
  .NET technologies
• Not a complete deployable application
• Focus on
• Performance
• Technology porting issues from the Windows DNA
  architecture to the .NET Framework
• Legacy integration and interoperability
• Real-life deployment scenarios in a distributed
  computing environment.

34
.NET Design PatternsFitch Mather 7.0
Architecture
35
.NET Design PatternsFitch Mather 7.0 Activity
Diagram
36
.NET Design PatternsFitch Mather 7.0 -
Transactions

• Transaction Composability
• Transactions are composed by a transaction root
  object from individual transactional or
  nontransactional objects
• Transaction root objects are located at a layer
  above the data access layer
• No objects in data access layer marked for
  requiring new transaction
• Objects that perform write operation must at
  least support transactions

37
.NET Design PatternsFitch Mather 7.0 - Security

• Use forms authentication with the combination of
  forms and role-based security
• Show login page and verify user credentials on
  access to restricted resources
• Issue an authentication cookie as means of
  re-acquiring user identity at a later stage.
• Based on the users identity/roles, replace the
  principal object on the current thread to reflect
  the identity of the user.
• In the application OnAuthenticateRequest event
  handler of Global.asax, automatically replace the
  principal on the thread every time authentication
  happens.
• On BLL and DAL components, place code segments
  into the constructor of each class to verify the
  identity of the user and whether they are
  authenticated. Throw an exception if they are
  not.

38
.NET Design PatternsUML Models
39
Agenda

• Design Model and Process
• .NET System Architecture
• .NET Design Patterns
• Security
• Scalability
• Availability

40
Security Overview

• Security is APAIN
• Authentication Whos there?
• Privacy No eavesdroppers
• Authorization What are you allowed to do?
• Integrity Did the data get changed?
• Nonrepudiation Keep your promises
• As always understand the requirements
• E.g. Search vs. bank account vs. news
• Do you just need personalization?

41
SecurityQuestions to Ask

• Authentication
• How does the user provide their credentials?
• Where are credentials stored?
• Temporary or persistent

42
SecurityAuthentication Approaches

• IIS/Windows
• Basic, Digest, NTLM, Kerberos, Certificates
• ASP.NET
• Windows
• Forms-based (cookie) authentication
• Microsoft Passport authentication
• Custom authentication

43
SecurityForms-Based Authentication

• Easy to implement
• ASP.NET provides redirection
• Custom Login UI (no popup dialogs)
• Custom credential verification
• Custom application roles
• Support for advanced usage
• Application defined data
• Control over cookie lifetime, paths

44
SecurityAuthorization Strategies

• ASP.NET
• Windows Security ACLs
• URL Authorization
• Custom Authorization
• All applications
• Declarative Method Authorization
• Explicit Authorization

45
Agenda

• Design Model and Process
• .NET System Architecture
• .NET Design Patterns
• Security
• Scalability
• Availability

46
Scalability How Do You Handle Success?

47
Scalability Approach 1 Scale Up

• SMP SymmetricMulti-Processor

• Can only get so big
• Expensive

48
ScalabilityApproach 2 Scale Out

• Less expensive, though more to manage
• Symmetric (load balancing) or asymmetric
  (partitioning)

49
Scalability Approach 3 Partition Database

• Scale out with database

• Scale up database
• Partition database

50
ScalabilityDesign for Scalability

• Design a stateless application if possible
• Use a database for state management
• Run on a cluster of Web servers
• Use caching or offline content generation
• Partition the database tier or the Web tier
• Use stored procedures
• Use transactions intelligently
• Use asynchronous programming techniques
• Benchmark your application performance
  measurement and tuning

51
ScalabilityUse a Database for State Management

• Design your Web application to run on a cluster
  of Web servers
• Shared nothing, stateless
• This means you must manage user session state
  somewhere other than the Web server
• Use a database

52
ScalabilitySingle Stateless Application Server

• A single stateless server running your
  application code

Application Code
53
ScalabilityMultiple Identical Stateless
Application Servers

• The application code is cloned across a set of
  identical servers

Application Code
Application Code
Application Code
54
ScalabilityLoad Balancing
Internet
Each server has at least two network cards one
card for receiving requests that are coming in
from the Internet, passing through a fire wall
open on port 80 for HTTP and 443 for HTTPS (SSL),
and a second card for communicating with back-end
servers such as database servers. Often there is
a third card to traffic the NLB heartbeat. Each
Web server is running NLB, which provides dynamic
load balancing.
Firewall
Public Network
NLB
NLB
NLB
Application Code
Application Code
Application Code
Admin Network
Private Network
55
ScalabilityState Management

• Use a database to persist state
• Membership, session state, shopping cart, etc.
• Use a Session GUID to identify a user within the
  application
• A GUID is a 128-bit identifier guaranteed to be
  unique
• Use a cookie, hidden variable, or the query
  string to pass the Session GUID from server
  cluster to browser and back
• Do not fear the performance overhead of the
  database

56
Scalability State Management Architecture

• The database is accessed overthe private
  network.
• The database is clustered for failover.
• As page requests arrive on a Web server, the
  users unique session GUID is used as a key into
  the database to retrieve their session state.
• Session state could be their registration
  properties, or the status of a shopping cart, or
  the information they filled out on a previous
  HTML form.

Public Network
Admin Network
Private Network
Database Cluster
57
ScalabilityUsing ASP.NET Caching

• Output caching
• Serves rendered result of a page from cache
• Big performance win cached pages are as fast as
  static pages
• Cache API
• Enables arbitrary objects to be cached
• Can be a big performance win
• Cache XML/XSL in the Web tier
• Cut down on DB hits
• Internationalize your site
• Expose your data to partners via Web Services

58
ScalabilityPartition the Database Tier

• Functional
• Each functional area of the site gets its own DB
• This allows you control over how you deploy into
  the production environment
• Dedicated hardware to certain functions
• Class of hardware per function
• Table
• Takes some planning
• SQL Server 2000 makes this easier than ever
  before
• Huge scale opportunity for large tables

59
ScalabilityPartition the Database Tier

• Load balance read-only databases
• Read-only databases can be IP-load balanced, just
  like Web servers
• You could load balance your product catalog, for
  example

60
ScalabilityPartition the Web Tier

• Just like database functional partitioning, you
  can dedicate clusters to application functions
• WWW.mydomain.com is handled by one cluster
• SEARCH.mydomain.com is handled by another cluster
• You can also create clusters of clusters
• Use DNS Round Robin to distribute traffic across
  multiple load balanced clusters that serve one
  function

61
ScalabilityPartition the Web Tier

• Use DNS Host names or hardware solutions to
  distribute traffic to dedicated clusters
• Once you have a stateless application, this is
  how you achieve huge scale
• Scalability throttling with inexpensive hardware

62
ScalabilityRecommended Architecture
WWW.mydomain.com
REGISTRATION.mydomain.com
Public Network
Public Network
DNS Host Names can be used to direct traffic to
functional clusters. Databases are
partitioned by function.
NLB
NLB
NLB
NLB
NLB
NLB
App Code
App Code
App Code
App Code
App Code
App Code
Private Network
Private Network
Database Cluster
Database Cluster
63
ScalabilityBenefits of Partitioning

• More control over traffic flow through the
  application
• Users who are searching or registering are moved
  off of the WWW cluster to keep the response time
  of the WWW cluster snappy
• Application and server tuning can be different
  for each function
• Search servers may have more memory, more CPUs
  than the servers handling WWW

64
ScalabilityBenefits of Partitioning

• Different content management techniques can be
  used on different functions
• WWW may be primarily static content or
  dynamically generated offline. WWW may use XML
  and XSL for high performance UI formatting and
  internationalization
• Registration requires real-time database access
  and custom code
• Administration of the clusters can be handled
  separately
• Database partitioning gives you scale-out
  capabilities at the database tier

65
ScalabilityUsing Stored Procedures

• There is a real performance benefit to stored
  procedures
• Compiled code in the database
• DBA can tune stored procedures
• Cant tune embedded SQL
• Good separation (API) between table structure and
  application code
• Tradeoff is database portability

66
ScalabilityUsing Transactions Intelligently

• Transactions are powerful but they do have
  overhead
• Use them intelligently
• Not every COM component requires a transaction
• Design your components with your transactions in
  mind
• Be aware of the transactional semantics of the
  underlying database
• Long-lived locks in the DB will kill application
  performance
• Look for blocking and deadlocks when testing

67
ScalabilityUsing Messaging

• Use store and forward where applicable
• Can provide a high degree of scalability by
  decoupling the user experience from the backend
  processing
• MSMQ
• Underlying messaging technology on Windows
• COM Queued Components
• Combines ease of COM programming with MSMQ
• Tradeoffs
• Manual implementation of 2 phase commit semantics
  (Compensating Transactions)

68
ScalabilityPerformance Tuning

• Performance Tuning is the process by which you
  measure individual operations on your site
• Still a bit of a black art
• Need to measure for detail but analyze with a
  holistic view of the system
• Database performance is key focus there first
• Know your tools
• PerfMon
• WAST
• SQL Server Profiler
• SQL Server Index Tuning Wizard
• SQL Server Query Analyzer

69
Scalability Framework/CLR Best Practices

• Enable Web Garden run applications in multiple
  worker processes (with processor affinity)
• Use Early Binding Late Binding requires work at
  runtime
• Pre-JIT to start up faster (available in beta
  2)
• Make chunky and not chatty calls
• Implement Dispose method on the object that
  cleans up your resources and release the
  reference (set to null) once you are done

70
Scalability Framework/CLR Best Practices

• Use value type for small data
• Do not cache strings or arrays length Strings
  are immutable
• For best inlining performance
• Minimize the use of virtual methods
• Use sealed types if possible

71
Scalability ASP.NET Best Practices

• Disable ViewState if you are not doing Postback
• Disable session state for all pages or Web
  Methods that dont require/need session data
• Set to readonly if you read but do not update
  session state
• Design pages around these ASP.NET built-in
  caching features
• Always use System.Data.SqlClient for SQL Server
  Access
• Use DataReaders for ASP.NET data access

72
Scalability ASP.NET Best Practices

• Avoid apartment threaded COM components
• Migrate apartment threaded components to .NET
• Alternatively, enable the lt_at_ AspCompattrue gt
  directive for pages that utilize apartment COM
  objects
• Always generate early-bound managed wrappers for
  COM components (avoid late bound hit)
• Recommend UI Logic in ASP.NET Pages
• Business and data logic in re-usable components
• User Controls for UI reuse
• Recommend web pages components run in same
  process
• Leverage web services only for application to
  application communication (not intra application)

73
Agenda

• Design Model and Process
• .NET System Architecture
• .NET Design Patterns
• Security
• Scalability
• Availability

74
AvailabilityWhat Is High Availability?

• The question you must ask yourself is
• How much downtime can my organization afford
  without losing productivity, profits, sales,
  etc.?
• It is a combination of people, process, AND
  technology

75
AvailabilityHigh Availability Is Not

• Only a technology solution
• A scalability solution

76
AvailabilityHow Much Availability Do I Need?

• Understand the business need
• Five nines (99.999 uptime) is 5 minutes of
  downtime per year
• Formulas for downtime
• Uptime/year (8760 - of total hours down per
  year)/8760
• Uptime/month ((24 of days in the month) -
  of total hours down in that calendar month)/(24
  of days in the month)
• Uptime/week (168 - of total hours down in
  that week)/168

77
AvailabilityHow Do I Achieve High Availability?

• Its deceptively simple
• Plan and prepare
• Deploy systems to create redundancy this is the
  key to high availability from a technology
  standpoint
• Use more than one method avoid a single point
  of failure
• Test, test, test
• Monitor on a continuous basis

78
AvailabilityBasic Questions To Ask

• Who is the end user? What do they expect in terms
  of availability and performance?
• What type of activity is going to be done within
  the database (i.e. OLTP, DSS, etc.)?
• Are there any budget considerations?
• How much will not having HA hurt the business?
  Calculate how much downtime will actually cost.

79
AvailabilitySQL Server 2000 HA Technology

• Failover Clustering
• Log Shipping
• Replication

80
AvailabilitySQL Failover Clustering

• Feature of SQL Server 2000 Enterprise Edition
• Not a scalability solution
• Automatic failover
• Always the method to lead with
• Requires specialized hardware solutions

81
AvailabilityLog Shipping

• New feature of SQL Server 2000 Enterprise Edition
• Concept has been in use for a long time
• Transaction logs from a primary database are
  applied to a secondary database
• Great primary or secondary method even if you
  cant afford failover clustering

82
AvailabilityReplication

• Not the traditional method of High Availability
  technology has been around for a long time
• Sometimes better than log shipping for
  transactional consistency
• Easy to replicate read-only data
• Possibly more complex, additional resources
• Uses for replication
• Reporting, read-only data, possibly updates
• Partitioned data

83
AvailabilityNLB

• NLB Network Load Balancing service
• Formerly known as Windows Load Balancing Service
  (WLBS)
• Formerly known as Convoy
• Generally used for scalability
• Can be used with databases to give some degree of
  High Availability
• Front end switch for log shipping role change
• Warm standby server
• Protect Analysis Services

84
AvailabilityDesign For High Availability

• Involve your programmers from the start
• Use versioning
• Use source control for all code including SQL
• Take implementation into account build programs
  with clean installs and uninstalls
• Use the right technology

85
AvailabilityDesign For High Availability

• Establish development, testing, staging
  environments, plus one that is an exact code copy
  of production (with current production data)
• Take into account downtime, and how you will
  handle it dont leave it to IT
• Read-only data should be cached if possible to
  speed up application performance

86
AvailabilityDesign For High Availability

• Resolve any application issues that directly
  affect SQL Server
• Locking/blocking
• Optimized queries/indexing schemes
• No ad hoc queries (If possible)
• Ensure no memory leaks or bad code will make an
  extended stored procedure unstable and cause
  availability problems
• Make sure statistics are up to date

87
AvailabilityImproved Availability with ASP.NET

• ASP.NET has been designed with assumption that
  failures will occur on systems
• Designing for failure reduced fragility
• Detects/recovers from common problems
• Access violations, memory leaks, deadlocks
• Preemptive cycling of applications
• Time- and request-based settings
• Net Result Users should never think that an
  ASP.NET application is down or unavailable

88
Conclusion

• Follow design process
• Understand the architecture and design
  trade-offs
• Study design patterns of other .NET applications
• Build security into the overall design
• Chose appropriate design patterns for scalability
  and availability

89
Resources

• Microsoft Solutions Framework
• http//www.microsoft.com/business/microsoft/mcs/ms
  f.asp
• Microsoft Operations Framework
• http//www.microsoft.com/business/microsoft/mcs/mo
  f.asp
• General .NET information
• http//msdn.microsoft.com/net
• .NET Framework SDK