1 / 71

.NET Application Design Considerations

Learn about .NET system architecture, design patterns, security, scalability, availability, and the application design model and process. Explore Microsoft Enterprise Services framework, design principles, and real-world technology constraints.

watsonjohn
Download Presentation

.NET Application Design Considerations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. .NET Application Design Considerations Mark SapossnekCS 594 Computer Science Department Metropolitan College Boston University A couple of additions And many deletions By Jim Fawcett CSE681 – Software Modeling and Analysis Summer 2003

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

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

  4. Application 1 Application 2 User Services Business Services Data Services Design Model and ProcessServices-Based Application Model Can be implemented as Web Services

  5. Conceptual Logical Physical Scenarios Objects and Services, UI, Logical DB Components, UI, Physical DB http:// Design Model and ProcessMSF Design Process Overview

  6. Conceptual Logical Physical Scenarios Objects and Services, UI, Logical DB Components, UI, Physical DB http:// 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.

  7. Logical Physical Objects and Services, UI, Logical DB Components, UI, Physical DB http:// Design Model and ProcessLogical Design Conceptual 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.

  8. Conceptual Logical Physical Scenarios Objects and Services, UI, Logical DB Components, UI, Physical DB http:// 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.

  9. 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

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

  11. .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

  12. .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

  13. .NET System Architecture.NET Application Architecture HTML 3.2 Browser Rendering engine IIS/ASP (.aspx, .ascx) Presentation logic .NET Assemblies WebServices Business logic Data logic SQL Server Database Data logic Data engine

  14. .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

  15. Partner Web Service Web Services Partner Web Service Internet + XML YourCompany.com .NET System ArchitectureWeb ServicesApplication Model Data Access and Storage Tier Application Business Logic Tier Other Applications

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

  17. .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

  18. IBuySpy Example • E-Commerce Store Front • Selling fictional spy equipment • Shows how to build a portal site • Demonstrates use of ASP.NET applications

  19. .NET Design PatternsIBuySpy Portal Sample

  20. .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

  21. .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

  22. Duwamish Example • A Sales and Inventory system for a book store. • Functions: • Point of Sale • Order Entry • Shipping and Receiving • Catalog

  23. .NET Design PatternsDuwamish Sample Application

  24. .NET Design PatternsDuwamish Activity Diagram

  25. .NET Design PatternsDuwamish Sequence Diagram

  26. .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

  27. .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

  28. Fitch & Mather Example • A Web-based expense reporting system for a fictional company • Original implementation was ASP and COM • Ported to .NET and COM+

  29. What is COM+ ? • COM+ provides the following services: • Transaction services • Security services • Synchronization services • Queued components • Event Service • JIT Activation and Object Pooling • In Memory Database • Load Balancing • Many of these services are available administratively as well as programmatically.

  30. COM+ Application

  31. .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.

  32. .NET Design PatternsFitch & Mather 7.0 Architecture

  33. .NET Design PatternsFitch & Mather 7.0 Activity Diagram

  34. .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

  35. .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 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.

  36. .NET Design PatternsUML Models

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

  38. Security Overview • Security is A PAIN: • 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?

  39. SecurityQuestions to Ask • Authentication • How does the user provide their credentials? • Where are credentials stored? • Temporary or persistent

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

  41. 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

  42. SecurityAuthorization Strategies • ASP.NET • Windows Security & ACLs • URL Authorization • Custom Authorization • All applications • Declarative Method Authorization • Explicit Authorization

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

  44. Scalability How Do You Handle Success? …

  45. Scalability Approach 1 – Scale Up • SMP: SymmetricMulti-Processor … • Can only get so big • Expensive

  46. … … ScalabilityApproach 2 – Scale Out • Less expensive, though more to manage • Symmetric (load balancing) or asymmetric (partitioning)

  47. Scalability Approach 3 – Partition Database • Scale out with database … … • Scale up database • Partition database

  48. 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

  49. 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

  50. ScalabilitySingle Stateless Application Server • A single stateless server running your application code Application Code

More Related