Enterprise Solution Patterns

1. Enterprise Solution Patterns Lisboa9.12.2003 Jose Antonio Silvajoseas@microsoft.com

2. Agenda • What are patterns? • Where do they fit? • What are pattern clusters? • Web presentation patterns • Deployment patterns • Distributed systems patterns • Services patterns • Conclusion • Resources

3. What Is A Pattern? Context Problem Solution

4. Singleton Pattern • Context: • Control access to a class by controlling its instantiation process • Problem: • Certain types of data need to be globally accessed and maintained • This data is often unique in the system • E.G. counter class

5. Singleton Pattern • Solution: ///<summary> /// Counter Class (Singleton). ///</summary> publicclass Counter { privatestatic Counter _instance = null; private Counter() {} publicstatic Counter getInstance() { if (_instance==null) { _instance = new Counter(); } return _instance; } //... functions provided by Counter } ///<summary> /// Class Counter (Singleton) ///</summary> publicsealedclass Counter { privatestaticreadonly Counter instance = new Counter(); private Counter(){} publicstatic Counter Instance { get { return instance; } } //.... }

6. Layered Architecture Pattern • Context: • You are designing a complex enterprise application composed of a large number of components across multiple levels of abstraction • Problem: • How do you structure an application to support such operational requirements such as maintainability, reusability, scalability, robustness and security?

7. Layered Architecture Pattern

8. Enterprise Solution PatternsUsing Microsoft .NETVersion 2.0 David Trowbridge

9. Pattern Description Format Context • Is this pattern relevant to my work? Problem • What problem does it solve? Forces • What issues do I need to consider? • What alternatives are there? Solution • Solution Description & Picture • How does it solve the problem? • What else do I have to think about? Example • Refers to associated Impl. Pattern Resulting Context • Benefits and Liabilities Related Patterns • What to read next?

10. What are Patterns? • Description Dimension • Recurring problem • Context • Solution • Tool Integration Dimension • Collection of atomic elements • Description of relationships • Transformations

11. Pattern Descriptions Help Architects And Designers By… • Documenting simple mechanisms that work • Providing a common vocabulary and taxonomy • Enabling solutions to be described concisely as combinations of patterns • Enabling reuse of architecture, design, and implementation decisions

12. Integrating Patterns into Tools

13. Tool Integration Helps Architects and Designers by … • Providing prepackaged “chunks” of design experience • Automated transformation result in: • Enhanced reliability • Reduced coding time • Simplified testing • Flexibility from interchangeable components

14. Where do they fit?

15. Where Do Patterns Fit? • Provide distilled design knowledge • They describe transformations • Patterns are not source code files • Patterns are not distributable components • Patterns are not data structures • Patterns do not have a thread of execution

16. Patterns High-rise Cape Cod Bill of Materials Pole Building Log Home Roofing Qty. Description Spec Plumbing Heating 412 2”x4”x8’ boards Fir, #2 Electrical Walls Tilt-up Truss Frame 200’ ½ “ copper pipe DWV Stick Frame Post and Beam Ceiling Truss Flooring 350’ 12 Ga. Elec. Wire NM 12-2 Foundation 24 48’ Trusses 20 psf load Taxonomy Pre-fab trusses Framing patterns 120 4’x8’x ½” sheet rk ASTM People Wiring patterns Pre-hung doors Covering Joists Concrete Rebar Building a House Analogy ……. Blueprints Guidelines Patterns Taxonomy Materials People Process

17. Patterns Layered Application Tiered Distribution Elements Qty. Description Guidelines 1 Microsoft ASP.NET Broker Model-View-Controller Local – within enterprise 3 Microsoft Windows Server 2003 Gateway Observer Facade Industry - principles 1 Microsoft SQL Server 1 PAG Data Access Component Implementing MVC with ASP.NET 1 Application Controller (Custom) Implementing Singleton with C# Building an Application ……. Blueprints Guidelines Patterns Elements Taxonomy People Process

18. Patterns Do Not Live In Isolation

19. Organizing Our Thinking Data App Deploy Infrastructure Architecture Design Impl.

20. The Pattern Graph

21. TieredDistribution 3-Tier 4-Tier Rich Client Simple Web Ext. Enterprise Complex Web Patterns – Solutions Language Layered Application Layered Services Application Three Layered Application

22. Architecture Deployment Application Infrastructure • Complex Web App • Security • Component Reuse • Manageability • Performance Tradeoff • Tiered Distribution • Scalability • Availability • Performance • Secure • Discrete Logical Layers Data & Functional Analysis • Design Flexibility • Maintainability • Loose Coupling

23. Design Deployment Application Infrastructure Runtime Dependencies Map Processes to Processors • Clusters • Zones • Policies • Protocols • Links • Design Classes & Mechanisms – eg: • Security • Communication • Data Access • Exception Handling • Logging

24. Implementation Deployment Application Infrastructure Configuration Dependencies Distribution Manifest – Components, Machines, Files… • Hardware Spec & Configuration • IP Addressees • Ports • Server & Files Names • Implementation Classes & Mechanisms • Product usage – eg: • .NET remoting

25. What are patterns clusters?

26. Components Presentation Framework The Pattern Graph - Clusters Smart Client Security

27. Current Area Of Focus Root Constraints • OLTP No embedded systems, data warehouse • Object-Oriented Application No procedural or AOP • Layered Application No monoliths • Tiered Distribution No stand-alone desktop apps Clusters

28. Web Presentation Cluster Design Intercepting Filter Page Cache Model-View-Controller Page Controller Front Controller Implementation Implementing MVC with ASP.Net Implementing Page Cache with ASP.Net Implementing Intercepting Filter with ASP.Net Implementing Page Controller with ASP.Net Implementing Front Controller with ASP.Net

29. Separate the modeling of the domain, the presentation, and the actions based on user input into separate classes • Model - manages the behavior and data of the application domain • View - display of information • Controller - interprets the mouse and keyboard inputs Model-View-Controller • How do you modularize the user interface functionality of a Web application so that you can easily modify the individual parts? • User Interface changes more frequently • Same data displayed different ways • Different skill sets required for UI design and App dev

30. Implementing MVC InASP .NET Controller public class Solution : System.Web.UI.Page { private void Page_Load(…) {…} void SubmitBtn_Click(Object sender, EventArgs e) { DataSet ds = DatabaseGateway.GetTracks (…) MyDataGrid.DataSource = ds; MyDataGrid.DataBind … } } Model public class DatabaseGateway { public static DataSet GetRecordings() {…} public static DataSet GetTracks(…) {…} } <%@ Page language="c#" Codebehind="Solution.aspx.cs" AutoEventWireup="false" Inherits="Solution" %> <html> <body> <form id="Solution" method="post" runat="server"> <asp:dropdownlist id="recordingSelect“… /> <asp:button id="submit" … /> <asp:datagrid id="MyDataGrid" … /> </form> </body> </html> View

31. Use the Page Controllerpattern to accept input from the page request, invoke the requested actions on the model, and determine the correct view to use for the resulting page Page Controller • How do you best structure the controller for moderately complex Web applications so that you can achieve reuse and flexibility while avoiding code duplication? • MVCfocuses primarily on the separation between the model and the view • Many dynamic Web pages involve similar steps: verifying user authentication, extracting query string parameters etc. • Testing user interface code is time-consuming

32. Implementing Page Controller in ASP.NET public class BasePage : Page { virtual protected void PageLoadEvent(object sender, System.EventArgs e) {} protected void Page_Load(…) { … string name = Context.User.Identity.Name; eMail.Text = DBGateway.RetrieveAddress(name); siteName.Text = "Micro-site"; … PageLoadEvent(sender, e); } } • Benefits • Simplicity • Leverages Framework features • Increased reuse • Liabilities • One controller per page • Deep inheritance trees

33. Front Controller solves the decentralization problem present in Page Controller by channeling all requests through a single controller Front Controller • How do you best structure the controller for very complex Web applications so that you can achieve reuse and flexibility while avoiding code duplication? • Page controller can lead to overburdened base classes • Inheritance hierarchy is static • Might need to coordinate processes across pages • Might deal with dynamic navigation paths, e.g. a ‘Wizard’ that includes optional pages

34. Implementing Front Controller In ASP .NET Using HTTP Handler public class Handler : IHttpHandler { public void ProcessRequest(HttpContext context) { Command command = CommandFactory.Make(context.Request.Params); command.Execute(context); } … } public class CommandFactory { public static Command Make(NameValueCollection parms) { string siteName = parms["site"]; Command command = new UnknownCommand(); if (siteName == null || siteName.Equals("micro")) command = new MicroSite(); else if(siteName.Equals("macro")) command = new MacroSite(); return command; } }

35. Benefits Flexibility Simplified Views Open for extension, but closed to modification (open-closed principle) Supports URL mapping Thread-safety Liabilities Performance Implications (object creation) Additional complexity Implementing Front Controller In ASP .NET Using HTTP Handler

36. Deployment Cluster Key Points • Layers – Logical application structure • Tiers – Physical distribution onto server infrastructure • Deployment – Application and infrastructure teams map components to tiers

37. Layered Application Problem • How do you structure an application to support such operational requirements as maintainability, reusability, scalability, robustness, and security? Forces • Impact of change • Separation of concerns • Independent components • Operational requirements Solution • Separate the components of your solution into layers. The components in each layer should be cohesive and at roughly the same level of abstraction; Each layer should be loosely coupled to the layers underneath

38. Layered Application • Discussion Points • Dependency management • Strict versus relaxed • Top down versus bottom up • Custom • Reuse existing scheme • Testing considerations • Benefits • Easier maintenance and enhancement • Reuse • Support for distributed dev • Enables tiered distribution • Testability • Liabilities • Layer overhead • Bound data • Complexity • Custom • Change propagation

39. Three Layered Services Application Problem • How do you layer a service-oriented application and then determine the components in each layer? Forces • Minimize impact of adding service to an application • Differing operational requirements by component type • Separation of concerns Solution • Base your layered architecture on three layers – presentation, business, and data

40. 4-Layered Services Application • Discussion Points • Presentation layer • Business layer • Data layer • Foundation services • Benefits • Separation of concerns • Minimal layers • Liabilities • Complex business logic may require more business layers • Complex UI apps may require additional UI layers

41. Tiered Distribution Problem • How should you structure your servers and distribute functionality across them to efficiently meet the operational requirements of the solution? Forces • Resource Consumption • Server Optimization • Security Requirements • Geographic and licensing constraints Solution • Structure your servers and client computers into a set of physical tiers; A tier is composed of one or more computers that share one or more of the following characteristics • System resource consumption profile • Operational requirements • Design constraints

42. Tiered Distribution • Benefits • Tiers optimized for specific task • Different security needs • Operational requirements • Admin and deployment overhead • Liabilities • Performance • Admin overhead • Complexity

43. Three-Tiered Distribution Problem • How many tiers should you have, and what should be in each tier? Forces • Database load • Security policies • Reuse • Scalability Solution • Structure your application around three physical tiers: Client, application, and database

44. Three-Tiered Distribution • Discussion Points • Server optimization • Security • Server farms • Clustering • Benefits • Scalability and fault Tolerance • Support thin client solutions • Security • Collocated app & web server performance • Liabilities • Business logic exposed to client tier • Incremental cost of adding web server

45. Deployment Plan Problem • How do you determine which tier you should deploy each of your components to? Forces • Layers != Tiers • Different Skill Sets • Impact of adding tiers • Resource Consumption • Constraints, security and operational requirements • Performance Impact of distribution Solution • The application architects must meet with the system architects to create a deployment plan that describes which tier each of the application's components will be deployed to

46. Deployment Plan • Discussion Points • Importance of testable requirements • Define Tiers and Components • Map Components to tiers • Models • Simple Web App • Complex Web App • Extended Enterprise App • Smart Client App • Benefits • Equal emphasis on both operational and functional requirements • Increased communication

47. Distributed Systems Cluster • Key Points • Distributed Computing Challenges • Layered Applications • Coarse Grained Interfaces • Client versus Server Activation

48. Services Patterns • Key Points • Service vs. Instance interfaces • Far Links • Web Services are About Interop

49. Service Interface Problem • How do you expose your application’s functionality over a network so it can be consumed by disparate applications? Forces • Separation of concerns – business logic and service contract issues • Consuming applications may require different channels for optimization Solution • Design your application as a collection of software services, each with a service interface through which consumers of the application may interact with the service.

50. Service Interface • Benefits • Application flexibility • Optimized performance • Interoperable • Liabilities • Adds complexity • Discussion Points • Service vs. instance • Specialized kind of Remote Façade • May want to aggregate in to Service Layer