.NET Application Design Considerations

.NET Application Design Considerations
Mark Sapossnek CS 594 Computer Science Department Metropolitan College Boston University This session will focus on .NET architecture and design process and .NET design considerations, such as Performance, Scalability, Security, Deployment, etc.

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

Learning Objectives Understand how to design a .NET application
Understand key design considerations on the following topics: Scalability Performance Availability Security KEY MESSAGE: Design Considerations SLIDE SCRIPT: SLIDE TRANSISTION: Agenda ADDITIONAL INFORMATION FOR PRESENTER:

Agenda Design Model and Process .NET System Architecture
.NET Design Patterns Security Scalability Availability The focus will be on best practices for designing a .NET applications.

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

Design Model and Process Microsoft Enterprise Services Framework (ESF)
Microsoft Readiness Framework (MRF) Microsoft Solutions Framework (MSF) Microsoft® Enterprise Services Frameworks (ESF) Microsoft Enterprise Services Frameworks (ESF) bridge the gap between Microsoft products and technologies and customer solutions. This framework-based approach for consistently capturing and delivering technical knowledge makes it easier for industry partners and customers to prepare for, plan, build, deploy and manage enterprise solutions with Microsoft technologies. This approach draws upon customer, industry and Microsoft experience in implementing and running mission-critical systems based on Microsoft technologies. ESF is made up of three sub-frameworks; each targeted at different, but integral, phases in the life cycle of providing world-class information technology to the enterprise. This specialization allows each framework to supply useful and detailed information, tools and resources on the people, processes, and technologies required for that phase's success. Microsoft Readiness Framework (MRF) MRF is the "prepare" phase within the Microsoft Enterprise Services Framework. MRF includes a comprehensive set of white papers, proven practices, guidance, and learning solutions for technical readiness and sustained customer and partner performance with the Microsoft platform. For more information, see the MRF White Papers at Microsoft Solutions Framework (MSF) MRF provides guidance in the planning, building, and deploying phases of the project life cycle. Such guidance includes white papers, deployment guides, case studies, and courseware in the areas of enterprise architecture, application development, component design, and infrastructure deployment. For more information visit the Microsoft Solutions Framework web site at Microsoft Operations Framework (MOF) MOF offers comprehensive technical guidance for achieving mission-critical production system reliability, availability, and manageability on Microsoft's products and technologies. This guidance takes the form of white papers, operational guides, assessment tools, best practices, case studies, and support tools for effective data center management within today's complex distributed IT environment. For more information, read the MOF White Papers at Microsoft Operations Framework (MOF) Enterprise Architecture

Design Model and Process Microsoft Solutions Framework
Schedule Resources Features Team Model Process Model Microsoft collects best practices from its product developers, IT group, customers, and partners worldwide, and analyzes them for repeatable success factors. These are then integrated into reusable models with measurable milestones that can guide technological decisions in a business context. These MSF Models can be used independently or in combination as needed. A team of peers The Microsoft’s team model is defined as a team of peers working in interdependent and cooperating roles. Each team member has a well-defined role on the project and is focused on a specific mission. This approach encourages ownership and ultimately results in a better product. The leaders of each team are responsible for management, guidance, and coordination, while the team members focus on carrying out their missions. The model is comprised of six clearly defined roles. Unrestricted communication is critical: Product Management—articulates a vision for the product or service, acquires and quantifies customer requirements, develops and maintains the business case and manages customer expectations Program Management— Drives the critical decisions necessary to release the right product or service at the right time, and coordinates the required decisions to deliver it in a manner consistent with organizational standards and interoperability goals. Development—Builds or implements a product or service that meets the specification and customer expectations, delivering a system that is fully compliant with the negotiated functional specification.Testing—Ensures all issues are known before the release of the product or service, exercising user interface, APIs, and integration of new software into existing systems. User education—Maximizes user experience users through performance solutions and training systems. Also reduces support costs by making the product easier to understand and use. The Process Model and Application Model will be discussed in the next few slides. Application Model

Design Model and Process MSF Process Model
Release S T A B I L Z N G I E N V S O G Scope Complete/ First Use Vision/Scope Approved The Envisioning phase Envisioning keeps your organization from investing significant effort on minor needs or making bad processes more efficient. It requires open thinking about how the proposed solution may address not only the most visible current need, but also base issues that cause that need, similar issues in other departments, potential issues that your business may face in the future, and so forth. The Envisioning phase culminates in the VISION/SCOPE APPROVED milestone. Once a new product (or in the case of infrastructure deployment, a new service) gains interest and approval, a project team is assembled to define the product. A vision statement articulates the ultimate goals for the product or service and provides clear direction. Scope is the opposite of vision: it defines the limits for a particular version of the product or service, recognizing that further development may come in future versions. The Planning phase Planning, in Microsoft’s definition, is when customers and team agree on what is to be delivered, and how it will be built. This is an important opportunity to reassess risk, establish priorities, and finalize estimates for schedule and resources. The Planning phase culminates in the PROJECT PLAN APPROVED milestone. The project plan contains the functional specification—the combined plans of each team member as defined in the Solutions Framework team model—and a schedule. The functional specification provides the project team with enough detail to identify resource requirements and make commitments. The Developing phase The Developing phase culminates in the SCOPE COMPLETE/FIRST USE milestone. An approved functional specification and associated project plan provide the baseline for focused development to begin. The development team sets a number of interim delivery milestones, each of which involves a full test/debug/fix cycle. At this milestone, customers and team assess the product's functionality and verify that rollout and support plans are in place. All new development is complete, and deferred functionality is documented for the next release. The Stabilization phase Stabilization requires a change in focus from the creativity of finding elegant development solutions to the rigid operational requirements of thorough and complete testing. The Stabilization Phase culminates in the RELEASE milestone. Testing activities are performed concurrently with code development. During the stabilizing phase these activities take center stage as bug finding and fixing become the primary focus. At this milestone, the product is formally turned over to the operations and support groups. Typically, the project team either begins work on the next release or disperses to other development projects. D E V L O P I G N P L A N I G Project Plan Approved

Design Model and Process Services-Based Application Model
User Services Business Services Data Services Can be implemented as Web Services Three Categories of Services To further refine the distribution characteristics of the network of services, the Solutions Framework application model defines three categories of service that make up an application: User services. The units of application logic that provide an application with its interface. The user of an application can be a person or another application, therefore an application's interface may be a graphical user interface and/or a programmatic interface. Business services. The units of application logic that control sequencing, and enforcement of business rules and the transactional integrity of the operations they perform. Business services transform data into information through the application of business rules. Data services. The units of application logic that provide the lowest, visible level of abstraction used for the manipulation of data. Data services maintain the availability and integrity of both persistent and non-persistent data as a corporate asset. They provide Create, Read, Update and Delete services such that business services (the consumers of data services) need not know where the data is located, how it is implemented, or how it is accessed.

Design Model and Process MSF Design Process Overview
Physical Conceptual Logical Objects and Services, UI, Logical DB Components, UI, Physical DB Scenarios Microsoft’s solutions design model is provides a step-by-step strategy for designing business-oriented solutions driven by a specific business need. This model ties together the Microsoft Solutions Framework application, team, and process models, enabling information system staff to focus resources where they can produce the most value.

Design Model and Process Conceptual Design
Scenarios Logical Objects and Services, UI, Logical DB Physical Components, UI, Physical DB Conceptual Design. The design of a building starts with the architect's sketches. These provide a view of the building for the client. They might contain a site plan, elevations, floor plans, cut away drawings, and other pictures or drawings. This view corresponds to the Conceptual Design for the project. It all starts with an understanding of what the users really need to do and creating an easily communicated set of models that captures this understanding. Other frameworks and methodologies often call this Analysis. The goal of conceptual design is to understand what the users do and to identify business needs. The output is scenarios or use cases.

Design Model and Process Logical Design
Conceptual Logical Objects and Services, UI, Logical DB Physical Components, UI, Physical DB Scenarios The goal of logical design is to lay out the structure of the solution and the communication among elements. The output is a set of objects and services, high-level user interface design, and logical database design.

Design Model and Process
Physical Design Conceptual Physical Components, UI, Physical DB Conceptual Scenarios Logical Objects and Services, UI, Logical DB Physical Design. Finally, contractors' plans are drawn up for the builder, adding detail to the architect's plans, making adjustments for the physical environment of the site and the technology and materials available to build the building. This view directs all the construction activities and may add greater detail such as shop plans for individual subcontractors. This view corresponds to the Physical Design, where we apply the real world constraints of technology to the logical model including implementation and performance considerations. This is the point at which real resources, costs, and schedule can be estimated These perspectives should not be thought of as stages. They do not imply some clear cutoff point or rigid boundary. It is not necessary to complete all of the work involved in one perspective before beginning the next. Elements of the process can easily overlap. Indeed, some parts of a system may be coded while other aspects are still being fleshed out conceptually or logically. If information is available before it would normally be uncovered or targeted in a particular design perspective, it should be used. There is no advantage in waiting to apply information until some predetermined appropriate point is reached. Think of these three perspectives on design as convenient points along a continuum to apply a particular set of techniques and tools, and address the needs of a particular audience. This enables us to describe the design process in a more focused way. At any given point, portions of the design can be re-visited. Design is a continuing process of successive refinement. 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.

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 This set of design principles is based on MSF and practical experience of people who are using MSF.

Design Model and Process Design Principles
Object Stereotypes Design Patterns E.g. Factory, Singleton, Proxy, Flyweight, Iterator, Façade, Memento, Adaptor Entity Service (Control) Boundary (Interface)

.NET Design Patterns Security Scalability Availability

.NET System Architecture Distributed System Architecture
Input/Output Rendering engine I/O Processing Presentation logic Everything Else Business logic Extending the Service-Based Design Model we discussed earlier, here we further define a distributed system architecture as illustrated in the diagram. Data Management Data logic Data engine Database

.NET System Architecture Windows DNA Application Architecture
HTML 3.2 Browser Rendering engine IIS/ASP (.asp) Presentation logic Business logic COM Components Data logic This illustrates the architecture of current Windows DNA, COM-based distributed system. SQL Server Database Data logic Data engine

.NET System Architecture 2-Tier Application Architecture
VB or PowerBuilder Application Rendering engine Presentation logic Business logic Data logic See why these are called “fat client” applications? SQL Server Database Data logic Data engine

.NET System Architecture .NET Application Architecture
HTML 3.2 Browser Rendering engine IIS/ASP (.aspx, .ascx) Presentation logic .NET Assemblies Web Services Business logic Data logic This diagram illustrates a .NET System Architecture based on a scenario of building an internet application. This is just one of many possible ways to design a .NET applications. Data logic SQL Server Database Data engine

.NET System Architecture Web Service Architecture
SOAP Clients Rendering engine Web Service (.asmx) Presentation logic .NET Assemblies Business logic Data logic This diagram illustrates a typical Web Service Architecture. The layered architecture approach allows for relatively easy replacement of base functionality without having to modify the logic in other layers. Fewer changes means more reliable code, and by implementing well-defined interfaces into our underlying layers, we can potentially increase scalability by distributing a single interface on multiple machines. The architectural foundation is divided into five logical layers. Furthest from the client is the data layer, which stores information required by the Web Service. Above the data layer is the data access layer, which presents a logical view of the physical data to the business layer. The data access layer isolates business logic from changes to the underlying data stores and ensures the integrity of the data. The business layer implements the business logic of the Web Service. It is often subdivided into two parts: the business façade and business logic. The business façade provides a simple interface that maps directly to operations exposed by the Web Service. The business façade uses services provided by the business logic layer. The top layer of the five is the presentation layer, where the data of a system is presented to the users of the system. Typically the presentation layer is considered the user interface, but in this case, because we are providing a programming interface as our end result, we will be considering our presentation layer the interface into our services. Our interface is the SOAP Protocol interface, which is exposed for us by the SOAP Toolkit listener that translates SOAP requests into the method calls on our COM objects. SQL Server Database Data logic Data engine

.NET System Architecture Web Services Application Model
Partner Web Service Web Services YourCompany.com Internet + XML This graphic depicts a possible scenario in the near future and some of the key players… The end user interacts/consumes many different services through a variety of devices including PCs, cellular phones, hand-held devices (e.g., the PocketPC). The Internet is the communication channel that facilitates all these interactions. This slide also shows the interaction between different organizations; for example, YourCompany.com and its relationship with its partner companies. You should also consider that the bandwidth per dollar is growing by 300 percent each year. This is even faster than Moore’s Law of microprocessor power. With all this bandwidth, we’re now seeing all kinds of different devices connected to the Internet, including palm computers and wireless phones. Data Access and Storage Tier Application Business Logic Tier Other Applications

.NET Design Patterns Samples Using Uniform Modeling Language (UML)
IBuySpy ( MSDN Sample: Duwamish 7.0 MSDN Sample: Fitch & Mather Stocks 7.0 Using Uniform Modeling Language (UML) Discuss design patterns of each sample application In this section, we will look at 3 .NET sample applications and focus on design patterns of each sample. The IBuySpy sample application is available on internet ( The other two samples are old MSDN samples being ported to .NET. There two samples will be available in Visual Studio.NET Beta 2. We will discuss UML and illustrate UML-based design models for the two MSDN samples.

.NET Design Patterns IBuySpy Portal Sample
The IBuySpy Developer Solution Kits are scenario-focused, real world samples that demonstrate best practices for creating ASP.NET applications. The Solution Kits are organized around a fictional company called IBuySpy and demonstrate how each solution can help run a business. Each Solution Kit includes complete and thoroughly-documented source code, which we encourage you to freely use as a template for building your own applications. The IBuySpy Portal Solution Starter Kit demonstrates how you can use ASP.NET and the .NET Framework to build either an intranet or Internet portal application. It demonstrates a host of developer "best practices" to follow when building ASP.NET applications. It’s best for the instructor to actually show the IBuySpy Portal site:

.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 This is a list of design best practices. It’s a good idea for the instructor to conduct a code walkthrough

.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 This is a list of design best practices. It’s a good idea for the instructor to conduct a code walkthrough

.NET Design Patterns Duwamish Sample Application
Duwamish 7.0 is an enterprise application that is divided into four logical layers. As a result of its design, an enterprise can deploy the application in a variety of distributed and non-distributed configurations. Web Layer The Web layer provides access for clients to the application. This layer is implemented as the Web project in the Duwamish.sln solution file. Business Facade Layer The Business Facade layer provides the business logic to handle accounts, category browsing and book purchasing. This layer is implemented as the BusinessFacade project in the Duwamish.sln solution file. The Business Facade layer serves as an isolation layer, segregating the user interface from the implementation of the various business functions. Apart from low-level system and support functions, all calls to database servers are made through this assembly. Business Rules Layer The Business Rules layer, which is implemented as the BusinessRules project in the Duwamish.sln solution file, contains the implementation of the various business rules. Business rules do tasks such as the validation of customer accounts and book orders. Data Access Layer The Data Access layer provides data services to the Business Facade and Business Rules layers. This layer is implemented as the DataAccess project in the Duwamish.sln solution file.

.NET Design Patterns Duwamish Activity Diagram
The activity diagram illustrates the top-level architecture model for the Duwamish 7.0.

.NET Design Patterns Duwamish Sequence Diagram
This is an example of UML Sequence Diagram. This illustrates the Duwamish Account Management component. The Account Details page displays a user's account information where a user can view and modify information on their account. However, before a user can manage their account through the Account Details page, they must first logon or create a new account through the Logon process.

.NET Design Patterns Duwamish 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 Move processing to the data To move processing to the data, the Duwamish 7.0 data access layer uses stored procedures for all data processing. The benefit is that the application’s data access layer is more resilient to changes in database logic. Pass all data back to the client in a method call In general, stateless objects produce highly scalable solutions. The Duwamish 7.0 data access classes are stateless; that is, they do not keep state in instance data members. The client passes all data required for a particular action to a method and the method passes all resulting data back to the client. This approach simplifies resource management by freeing every data access object following any method call. As a result, the client can use any data access object to make a method call because all the required inputs are passed to the object with the call. Keep database resources for the shortest period of time Database resources are scarce and expensive. The Duwamish 7.0 data access layer postpones database resource allocation as long as possible and frees database resources as soon possible. For Remoting, Duwamish 7.0 uses the Binary/HTTP combination due to its superior performance over SOAP/HTTP. Caching techniques are most critical within Web sites that contain a lot of dynamic data, such as a stock brokerage where the data is changed quite often. ASP applications with dynamic data either retrieve the catalog from a database for each page request or convert it to HTML. ASP.NET can cache the dynamic page for a specified timeframe so that the first page request on any given day caches the output from the page. Careful consideration and implementation of caching can greatly improve the performance of an application.

.NET Design Patterns Duwamish 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

.NET Design Patterns Fitch & 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. The Fitch and Mather 7.0 enterprise sample is essentially a port of the Fitch and Mather 2000 sample to .NET technologies. Although the sample itself is built around a fictitious stock brokerage subsidiary, the primary focus areas of this sample are: Performance Technology porting issues from the Windows DNA (WinDNA) architecture to the .NET Framework, Legacy integration and interoperability Real-life deployment scenarios in a distributed computing environment. The sample does not focus on the functional requirements of the application. Functionally, however, the sample does include a login and logout process, account management, stock research and transaction mechanics, SQL queries, and other typical pages such as home and about. These features, which cover a broad range of .NET technologies, are sufficiently complex to illustrate the primary focus areas. However, Fitch and Mather 7.0 is not a functionally complete stock trading application because it is missing essential broker, fulfillment, and real-time financial services.

.NET Design Patterns Fitch & Mather 7.0 Architecture
The Fitch and Mather 7.0 architecture is divided into three logical layers: User Services Layer (USL) The user services layer provides access for clients to the application. This layer is implemented as the web project under the Enterprise Template Project (ETP) node in the Fitch and Mather 7.0.sln solution file. Business Logic Layer (BLL) The business logic layer provides the business logic to handle accounts, buying and selling shares, and researching companies. This layer is implemented as the BLL project under the Enterprise Template Project (ETP) node in the Fitch and Mather 7.0.sln solution file. Data Access Layer (DAL) The data access layer provides data services to the BLL. This layer is implemented as the DAL project under the Enterprise Template Project (ETP) node in the Fitch and Mather 7.0.sln solution file.

.NET Design Patterns Fitch & Mather 7.0 Activity Diagram
This high-level UML activity diagram describes the activities and options available to a user who enters the Fitch and Mather 7.0 Web site

.NET Design Patterns Fitch & 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 The Fitch & Mather 7.0 design patterns are generally similar to the Dumarish 7.0 sample except for the two topics we highlight here: Transactions and Security. Transaction composability is a key concept in designing flexible and extensible applications. It refers to the design pattern where transactions are composed by a transaction root object from individual transactional or non transactional objects. While the transaction root object starts the transaction, it does not contain any data access routines, it only acts as a composer of the transaction. Data access is performed exclusively by the components called from the transaction root. To support composability, transaction root objects are best located at a layer above the data access layer. This is illustrated in the diagram below. Please note the following two points: None of the objects in the data access layer are marked for requiring new transactions. Objects that perform write operation are at least marked for transaction support To understand why these points are important, let’s consider the following scenario: As in the first scenario, the object at the business logic layer starts a new transaction and makes calls to DAL objects A,B,C and D. Please notice the following differences: Object B does not support transactions and it performs a write operation to the database Object D requires new transaction Both of the above mentioned two points prevent composability of transactions. As object B does not support transactions, there is no way to roll back its write operations if object E for example fails. In addition, the transaction root would need to include some kind of application logic to evaluate the result of the operation of object B and take appropriate actions. As object D requires new transaction, the DTC of COM+ would create a new transaction – Tx2 - which would complete when the call from object D returns. Again, the transaction root would need to contain some application logic to determine the success or failure or object D’s operation. If object D completes successfully but the operation by the next object – E – fails, there is no way to roll back Object D’s operation. As a general rule, to support transaction composability, all objects called by the transaction root must at least support transactions. The only exception could be objects that perform read only operations, in which case program logic in the transaction root could handle exceptions.

.NET Design Patterns Fitch & 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 user’s 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. Forms authentication redirects unauthorized users to an HTML form that prompts them for a userid and password. After the application verifies the credentials, it issues an authentication cookie that includes an authentication ticket. Within the same session, the applicaiton automatically attaches the cookie to the header of subsequent requests. The common language runtime automatically authenticates and authorizes each request. Settings in the web.config file control aspects of forms authenticationby . For Fitch and Mather 7.0, this file specifies the use of forms authentication as follows: <security> <authentication mode="Forms"> <cookie cookie="FMStocks7Auth" loginurl="Login.aspx" decryptionkey="autogenerate"> </cookie> </authentication> </security> When a user requests restricted resources, the common language runtime redirects unauthorized users to Login.aspx . The Fitch and Mather 7.0 web.config file includes a location section for all pages that need to be secured: <location path="AccountSummary.aspx"> <security> <authorization> <deny users="?" /> </authorization> </security> </location> The <deny users="?" /> tag specifies that access to all unauthenticated users should be denied. A better way to implement resource restriction would be to place all resources that require access restriction in a separate directory. In this directory you can then create an additional web.config file that denies unauthorized users access to all content in the directory. Please note that Duwamish is implemented this way. Let's summarize what we have so far. A user who visits the site has access to some resources by default but must log in to access other resources. Does this mean that our website is secure? The answer would be yes (with some minor reservations — see later) . The application itself, however, is far from secure. Anyone who knows about the existence of the various assemblies running behind the Web front end can call into the assemblies and start using them for their own purpose — like depositing your money into their own accounts. This would be a serious security hole in a real application. To remed this security problem, you can use the .Net Framework’s new role-based security. Please note that role-based security is significantly different from what it was in WinDNA. Role-based security provides support for authorization by making information about the principal available to the current thread. A .NET-based application then can make authorization decisions based on either the principal's identity or role membership or both. A role is a named set of users who have the same privileges with respect to security (such as a teller or a manager), and a principal can be a member of one or more roles. Therefore, applications can use role membership to determine whether a principal is authorized to perform a requested action.

.NET Design Patterns UML Models
The UML provides full support for creating object-oriented models of complex software systems. The instructor can show some sample UML models by using the Microsoft Visio tool. In the early stages of a development project, use use case diagrams to describe real-world activities and motivations. You can refine the diagrams in later stages to reflect user interface and design details. Use package diagrams to group related elements in a system. One package can contain subordinate packages, diagrams, or single elements. Use an activity diagram to describe the internal behavior of a method and represent a flow driven by internally generated action Use a statechart diagram to show the sequence of states an object goes through during its life. Use a sequence diagram to show the actors or objects participating in an interaction and the events they generate arranged in a time sequence. Use a component diagram to partition a system into cohesive components and show the structure of the code itself. Use a deployment diagram to show the structure of the run-time system and communicate how the hardware and software elements that make up an application will be configured and deployed. Use static structure diagrams to create conceptual diagrams that represent concepts from the real world and the relationships between them, or class diagrams that decompose a software system into its parts. Use a collaboration diagram to show relationships among object roles such as the set of messages exchanged among the objects to achieve an operation or result.

Security Overview Security is APAIN:
Authentication Who‘s 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?

Security Questions to Ask
Authentication How does the user provide their credentials? Where are credentials stored? Temporary or persistent

Security Authentication Approaches
IIS/Windows Basic, Digest, NTLM, Kerberos, Certificates ASP.NET Windows Forms-based (cookie) authentication Microsoft Passport authentication Custom authentication Authentication in ASP.NET is implemented through Authentication Providers. ASP.NET authentication providers are the code modules that contain the code necessary to authenticate the requestor's credentials. The first version of ASP.NET will ship with support for the following authentication providers: Windows Authentication This method is used in conjunction with IIS authentication. Authentication is performed by IIS in one of three ways: Basic, Digest, or Integrated Windows Authentication. ASP.NET uses the authenticated identity to authorize access. Passport Authentication Passport authentication is a centralized authentication service provided by Microsoft that offers a single sign-in and core profile services for member sites. Cookie Authentication Cookie authentication is generally used to refer to a system whereby unauthenticated requests are redirected to an HTML form (using HTTP client-side redirection). The user provides credentials and submits the forms. If the application authenticates the request, the system issues a cookie that contains the credentials in some form or a key for reacquiring the identity. Subsequent requests are issued with the cookie in the request headers and

Security Forms-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 Form-Based (Cookie) authentication is generally used to refer to a system where unauthenticated requests are redirected to an HTML form (using HTTP client-side redirection). This would be a good choice of providers if your application needs to collect its own user credentials at logon time through HTML forms. The user provides credentials and submits the forms. If the application authenticates the request, the system issues a cookie that contains the credentials in some form or a key for reacquiring the identity. Subsequent requests are issued with the cookie in the request headers and they are authenticated and authorized by an ASP.NET handler using whatever validation method the application specifies. It should be noted that cookie authentication is often used for personalization, where content is customized for a known user. In some of these cases, identification is the issue rather than authentication, so it is enough to merely store the user name (in a durable cookie) and use that cookie to access the user personalization information.

Security Authorization Strategies
ASP.NET Windows Security & ACLs URL Authorization Custom Authorization All applications Declarative Method Authorization Explicit Authorization The purpose of authorization is to determine whether an identity should be granted the requested type of access to a given resource. There are two fundamental ways to authorize an entity access to a given resource: file authorization and URL authorization. File authorization is performed by the file authorization module, and is active when Windows authentication is used. It does an ACL check to determine whether or not a user should have access. Applications can further use impersonation to get resource checks on resources that they are accessing

Scalability How Do You Handle Success?
… Scale up means that you add more processors, typically Symmetric Multi-Processor (SMP), to a server to meet the increasing workload.

Scalability Approach 1 – Scale Up
SMP: Symmetric Multi- Processor … Scale up means that you add more processors, typically Symmetric Multi-Processor (SMP), to a server to meet the increasing workload. Can only get so big Expensive

Scalability Approach 2 – Scale Out
… Alternatively, we can deploy a set of less expensive servers to set up as a server farm to handle the increasing workload – the Scale Out approach. In general, there are two approaches to scale out the servers: Symmetric (Load Balancing): every machine in the server farm has similar configuration and settings and participants in a typically a cluster environment for fail-over and/or load balancing activities. Asymmetric (Partitioning): each server would provide different services based on a certain criteria, such as user identity or incoming IP address. Less expensive, though more to manage Symmetric (load balancing) or asymmetric (partitioning)

Scalability Approach 3 – Partition Database
Scale out with database … … The 3rd approach is focusing on database – either to scale out with database, scale up database, or partition database. We will cover this topic in more details in the next few slides. Scale up database Partition database

Scalability Design 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 It is generally understood that a stateless component or an application can scale better than a stateful one. The main reason is that maintaining a state typically is a bottleneck in term of performance and scalability. Benchmark app requirements to know if it can coexist, and think about how it works so you don't throw two conflicting workloads on one server. This will also help to size servers. This is crucial for log shipping, where one SQL Server may house different workloads and DBs. Coding for a specific release may be a bad idea, especially if log shipping is involved. Your failover plan may not work.

Scalability Use 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 The SQL database normally can perform a better job on managing user session state information. Typically, you will use an user identity as a primary key to retrieve state information.

Scalability Single Stateless Application Server
A single stateless server running your application code Application Code This is the most simple scenario of single stateless application server. The potential performance bottleneck if this single server become overload.

Scalability Multiple Identical Stateless Application Servers
The application code is cloned across a set of identical servers Application Code Application Code Application Code This is a symmetric scale out scenario we discussed earlier.

Scalability Load Balancing
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. Internet Firewall Public Network NLB NLB NLB This slide shows an actual implementation of Network Load Balancing (NLB), a symmetric scale out scenario. Application Code Application Code Application Code Admin Network Private Network

Scalability State 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 A proper way to manage state is one of the key areas for improving scalability. The recommendation here is to use a SQL database to persist state information.

State Management Architecture
Scalability State Management Architecture The database is accessed over the private network. The database is clustered for failover. As page requests arrive on a Web server, the user’s 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 Application Code NLB Application Code NLB Application Code NLB Admin Network This diagram illustrates a recommended architecture for state management. Private Network Database Cluster

Scalability Using 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 Caching is an extremely important technique for building high-performance, scalable Web server applications. The idea is simple: some items that are expensive to construct can be built once and used for a period of time before they are considered invalid. These items are stored in memory where they can be efficiently retrieved without incurring the cost of being reconstructed. Straight out of the box, ASP.NET offers a number of caching mechanisms that enhance Web application performance. For example, all ASP.NET pages are compiled into an instance of the Page class and cached on the server; they are updated in the cache only when the page changes or the caching period expires. Additionally, configuration settings are read the first time an application is started and cached. ASP.NET also exposes caching services that allow developers to modify cache settings as needed. For more information

Scalability Partition 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

Scalability Partition 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

Scalability Partition the Web Tier
Just like database functional partitioning, you can dedicate clusters to application functions 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

Scalability Partition 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

Scalability Recommended Architecture
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 Put everything we have discussed so far, this diagram illustrates a recommended architecture. Private Network Private Network Database Cluster Database Cluster

Scalability Benefits 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

Scalability Benefits 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

Scalability Using Stored Procedures
There is a real performance benefit to stored procedures Compiled code in the database DBA can tune stored procedures Can’t tune embedded SQL Good separation (API) between table structure and application code Tradeoff is database portability

Scalability Using 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 Note that we had discussed the Transactions model for the Fitch & Mather 7.0 sample. This slide essentially summarizes the same concepts.

Scalability Using 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) Using asynchronous programming techniques when ever there are: Opportunities for parallel processing Batch type of operations Interfacing with legacy applications Realtime operations

Scalability Performance 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 The key is to measure performance regularly against the performance and scalability goals.

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 Web Garden: must be explicitly enabled. It’s a performance win in many SMP scenarios Eliminates cross processor lock contention Ideal for large SMP systems Both VB and JScript support early and late binding. The Early Binding provides better performance. A Pre-JIT’ed Assembly is a persisted form of JIT’ed MSIL It’s done at install time or on demand and can reduce start-up time SDK contains several Pre-JIT’ed assemblies Native code has version checks and reverts to runtime JIT if they fail Available for the 1st time in Beta2 (ngen.exe) Finalization: If you’re holding onto an expensive resource don’t wait for finalization. E.g. DB connections, unmgd resources Instead, be sure to: Implement “dispose” method on the object that cleans up your resources Release the reference as soon as you’re done by setting it to null This design pattern is formalized by C#’s IDisposable

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 Value Type: think “OO structs on the stack” Passed by value (default) and reference .NET Framework’s primitive types are value types (for performance reason) Useful for items like Point (x,y coordinates) Strings: Strings are immutable Use the mutable StringBuilder object when building strings in several steps For best inlining performance Minimize the use of virtual methods Use “sealed” types

Scalability ASP.NET Best Practices
Disable “ViewState” if you are not doing Postback Disable session state for all pages or Web Methods that don’t 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 ViewState: ASP.NET allows pages/controls to maintain state across round trips. State stored within “viewstate” hidden field. It can be disabled with “enableviewstate=false”. Some downsides: Increases network payload Performance overhead to serialize this Session state is enabled out of the box by default. It is an overhead if you don’t leverage it. Leverage the built-in ASP.NET built-in caching features can lead to massive performance wins as we discussed earlier. Output Caching Fragment Caching Cache API Data Access: System.Data.SqlClient provides a slight better performance.

Scalability ASP.NET Best Practices
Avoid apartment threaded COM components Migrate apartment threaded components to .NET Alternatively, enable the AspCompat=“true” %> 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) Apartment COM: ASP.NET leverages an MTA Thread Pool, which optimizes for new .NET Components. It provides very sub-optimal performance for apartment threaded components (ie: VB6 COM objects). We strongly recommend deploying web applications in a configuration where pages & components run in the same process Deploying onto remote servers connected via DCOM or Web Services will almost always hurt your performance/scalability Leverage web services only for application to application communication (not intra app .

Availability What 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 Give the following example: You are the Operations manager for a successful e-commerce Web site. You’re going into your busiest day of the week, and are on your way to a record sales day. All of a sudden, the systems monitoring your site start flashing red – it looks like users are being blocked and subsequently, your site comes to a screeching halt. No one can get to it, nor can you get to the database – not even a Query Analyzer window. The CEO comes in asking what’s wrong, and when the site will be up. What’s your contingency plan? Is it tested? Do you have all materials, people, etc. to put the plan into action? If you have nothing, you could have taken a situation where an event like this could have only caused minutes of downtime, instead of potentially hours or days, and lots of lost revenue. Point here is that you need to make them feel the pain. Also, it will come out later to emphasize the point, but definitely stress that without the proper people, plan, and process to drive, a perfectly designed technological solution will not work. Technology alone is not the answer.

Availability High Availability Is Not …
Only a technology solution A scalability solution High Availability is not a technology solution from a vendor. A vendor can provide hardware, software (for example, Windows 2000 & SQL Server 2000), consulting, best practices, etc., in regards to how to implement a successful HA installation. The real success of HA depends on not only this solution but the internal attitudes, discipline and processes put in place by the customer. The vendor solution should only be considered a tool to help put the HA implementation in place. While any end solution should perform well, the goal here is high availability, not the ultimate in scalability. There may be some trade offs somewhere, but do not confuse the two: scalability is for performance only. Careful planning can give you both. Example The technology team (developers, DBAs and operations) should not be proposing a technology solution without fully understanding the business impact to down time. For example: What is the cost of the application being down. If the cost is minor then implementing a very expensive HA system will not give you a good ROI. What is the business impact if the system is down between midnight and 6:00am? If there is not business impact then do not spend the money designing a very expensive 24*7 solution The business unit should not be asking for High Availability if they cannot first go through and define the cost of not having a HA system. For example: A business user asks for 24*7*365 uptime but does not want to spend more than $50K for the solution. If the dollar value is calculated ahead of time and the cost of being down is $100,000.00/hour, then spending more than $50K can be justified.

Availability How 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 = ( # 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 This is a crucial slide. The goal here is to stress that the business need drives the amount of time of availability that the application/database needs to be up. If there is a user agreement that the application needs to be up at least 23 hours a day, leaving 1 hour a day for any maintenance. This totals 365 hours a year of possible planned downtime, resulting in 95.83% uptime for the database/application. This will demonstrate how hard it is to get to the mythical Five Nines. It can be done, but lots of careful planning needs to go into it. IT alone should not drive the solution that is ultimately implemented. You don’t really need to discuss the formulas … it’s more for them to use when they get back.

Availability How Do I Achieve High Availability?
It’s 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 Plan & Prepare – fundamentals, process, and people Deploy – implement the proper hw & sw, as well as manage it. The key to HA is redundancy (i.e. more than one copy) to avoid a single point of failure, but you need the process to surround the technology. Test – self explanatory. Monitor – monitor continuously. Know how to detect abnormalities and prevent downtime. There is a big difference in preventable downtime vs. unplanned (and unwanted) downtime. This does not take into account planned downtime for maintenance.

Availability Basic 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. Tell them to start here at the most fundamental level … forget systems (I.e. hardware and software). Take it to the 10,000 foot level. Know the end user (internal? External? Both?), and their requirements in terms of availability and performance. This comes into play as the DBA does his day-to-day role. Is taking a possible 10 – 20% performance hit for a query execution acceptable if it means greater uptime? The type of activity will affect how the system is architected from an application and hardware perspective – never try to retrofit, because it often doesn’t work. Money is always a factor. You may be able to only do the best with a limited budget – some HA is better than none. This is important – people tend to focus on how much systems cost, but what is the actual cost of downtime? In an e-commerce environment, each second means money lost.

Availability SQL Server 2000 HA Technology
Failover Clustering Log Shipping Replication

Availability SQL 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

Availability Log 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 can’t afford failover clustering

Availability Replication
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 Replication has been a feature of SQL Server for a long time. It has a Publisher and a Distributor, so you have two servers with additional overhead and that need protection. Best for building read only and reporting databases.

Availability NLB 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 This is probably the best method for High Availability and Analysis Services. Network Load Balancing (NLB) is one of the clustering technologies available in Windows 2000 Advanced Server and Windows 2000 Datacenter Server. It provides high availability and high scalability to IP-based applications, such as Web servers and Lightweight Directory Access Protocol (LDAP) servers. Microsoft Application Center 2000 provides NLB on Windows 2000 Server (rather than Advanced Server). NLB distributes incoming IP traffic across a cluster of multiple servers that provide TCP/IP services. It utilizes a common virtual IP address for the entire cluster and transparently partitions client requests across the multiple servers in the cluster. Microsoft Windows NT Load Balancing Service (WLBS) is an older name (and a predecessor on NT systems) for the same product.

Availability Design 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 1st bullet – HA is a mindset, so if your developers are not thinking about it, it won’t be built in. And the cost of retrofitting it into code is usually big (as are any wholesale changes). 2nd bullet – keeps paths separate … don’t mix and mingle, because you’ll never have the “true” build that gets into production 3rd bullet – important to version and have master copies of things to compare in a production environment if something goes awry 4th bullet – critical for IT 5th bullet – for example, if you use failover clustering, use the clustering APIs to make your application cluster aware, or code for graceful error messages and such to handle events. The user experience is key.

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 – don’t leave it to IT Read-only data should be cached if possible to speed up application performance 1st bullet point – this is key if you can do it. Dev should be different from test which should be different from staging to allow different groups to do their job without stepping on the toes of others. Plus there should be one pristine copy that is an exact replica of the production box to assist in troubleshooting so you know you are comparing apples to apples. 2nd bullet – Design HA in from the start – don’t make it an afterthought 3rd bullet – reduce I/O contention and also increase app performance

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 1st bullet point – HA goes to the code level, using Access to build your queries may not be the optimal way. Have your DBAs or qualified T-SQL experts do it, and just have the dev guys build ‘em in. Locking and blocking can bring down a SQL Server … remove any long running queries and transactions Make sure all queries are optimized – use the right indexes to reduce time of execution (which reduces I/O) Extended stored procs are like developing any other piece of C/VB code … treat them as such Auto update stats may not work for everyone, and this can cause potentially longrunning queries, etc. So use DBCCs or drop/rebuild as part of normal maintenance

Availability Improved 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 This is one of the key benefits/improvements that ASP.NET has over the current ASP technology.

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

Resources Microsoft Solutions Framework Microsoft Operations Framework
Microsoft Operations Framework General .NET information .NET Framework SDK

.NET Application Design Considerations

Similar presentations

Presentation on theme: ".NET Application Design Considerations"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

.NET Application Design Considerations

Similar presentations

Presentation on theme: ".NET Application Design Considerations"— Presentation transcript:

Similar presentations

About project

Feedback