Enterprise Solution Patterns Jose Antonio Silva joseas microsoft com

Enterprise Solution Patterns Jose Antonio Silva joseas@microsoft. com Lisboa 9. 12. 2003 1

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

What Is A Pattern? Context Problem 3 Solution

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

Singleton Pattern v Solution: ///

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

Layered Architecture Pattern 7

Enterprise Solution Patterns Using Microsoft. NET Version 2. 0 David Trowbridge EMEA 8

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

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

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

Integrating Patterns into Tools 12

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

Where do they fit? EMEA 14

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

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

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

Patterns Do Not Live In Isolation 18

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

The Pattern Graph Data Architecture Design Implementation 20 Application Deployment Infrastructure

Patterns – Solutions Language Data Application Deployment Layered Application Architecture Tiered Distribution Layered Services Application Three Layered Application Infrastructure 3 -Tier Design Rich Client Simple Web Implementation 21 Ext. Enterprise Complex Web 4 -Tier

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

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

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

What are patterns clusters? EMEA 25

The Pattern Graph - Clusters Data Application Deployment Infrastructure Architecture Components Design Smart Client Implementation Presentation Framework 26 Security

Current Area Of Focus Root Constraints v OLTP No embedded systems, data warehouse v Object-Oriented Application No procedural or AOP v Layered Application No monoliths v Tiered Distribution No stand-alone desktop apps Cluster Problem Web Presentation How do you create dynamic Web applications? Deployment How do you divide an application into layers and then deploy them onto a multi-tiered hardware infrastructure? Distributed Systems How do you communicate with objects that reside in different processes or different computers? Services How do you use functionality available remotely? How do you expose your application’s functionality over a network? Performance and Reliability How do you create a systems infrastructure that can meet critical operational requirements? 27

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

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

Implementing MVC In ASP. NET Controller Model public class Database. Gateway { public static Data. Set Get. Recordings() {…} public static Data. Set Get. Tracks(…) {…} } View 30 public class Solution : System. Web. UI. Page { private void Page_Load(…) {…} void Submit. Btn_Click(Object sender, Event. Args e) Data. Set ds = Database. Gateway. Get. Tracks (…) My. Data. Grid. Data. Source = ds; My. Data. Grid. Data. Bind … } } { <%@ Page language="c#" Codebehind="Solution. aspx. cs" Auto. Event. Wireup="false" Inherits="Solution" %>

Page Controller v How do you best structure the controller for moderately complex Web applications so that you can achieve reuse and flexibility while avoiding code duplication? w MVC focuses primarily on the separation between the model and the view w Many dynamic Web pages involve similar steps: verifying user authentication, extracting query string parameters etc. w Testing user interface code is time-consuming v Use the Page Controller pattern 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 31

Implementing Page Controller in ASP. NET public class Base. Page : Page { virtual protected void Page. Load. Event(object sender, System. Event. Args e) {} protected void Page_Load(…) { … string name = Context. User. Identity. Name; e. Mail. Text = DBGateway. Retrieve. Address(name); site. Name. Text = "Micro-site"; … Page. Load. Event(sender, e); } } Benefits l Simplicity l Leverages Framework features l Increased reuse 32 Liabilities l One controller page l Deep inheritance trees

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

Implementing Front Controller In ASP. NET Using HTTP Handler public class Handler : IHttp. Handler { public void Process. Request(Http. Context context) { Command command = Command. Factory. Make(context. Request. Params); command. Execute(context); } … } public class Command. Factory { public static Command Make(Name. Value. Collection parms) { string site. Name = parms["site"]; Command command = new Unknown. Command(); if (site. Name == null || site. Name. Equals("micro")) command = new Micro. Site(); else if(site. Name. Equals("macro")) command = new Macro. Site(); return command; } } 34

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

Deployment Cluster Key Points w w w Layers – Logical application structure Tiers – Physical distribution onto server infrastructure Deployment – Application and infrastructure teams map components to tiers Pattern Problem Layered Application How do you structure an application to support such operational requirements as maintainability, reusability, scalability, robustness, and security? Three-Layered Services Application How do you layer a service-oriented application and then determine the components in each layer? Tiered Distribution How should you structure your servers and distribute functionality across them to efficiently meet the operational requirements of the solution? Three-Tiered Distribution How many tiers should you have, and what should be in each tier? Deployment Plan How do you determine which tier you should deploy each of your components to? 36

Layered Application Problem w How do you structure an application to support such operational requirements as maintainability, reusability, scalability, robustness, and security? Forces w w Impact of change Separation of concerns Independent components Operational requirements Solution w 37 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

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

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

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

Tiered Distribution Problem w How should you structure your servers and distribute functionality across them to efficiently meet the operational requirements of the solution? Forces w w Resource Consumption Server Optimization Security Requirements Geographic and licensing constraints Solution w 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 w w w 41 System resource consumption profile Operational requirements Design constraints

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

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

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

Deployment Plan Problem w How do you determine which tier you should deploy each of your components to? Forces w w w Layers != Tiers Different Skill Sets Impact of adding tiers Resource Consumption Constraints, security and operational requirements Performance Impact of distribution Solution w 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 45

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

Distributed Systems Cluster v Key Points w w Distributed Computing Challenges Layered Applications Coarse Grained Interfaces Client versus Server Activation Pattern Problem Broker How can you structure a distributed system so that application developers don’t have to concern themselves with the details of remote communication? Implementing Broker with. Net Remoting (Server Activated) How do you Implement Broker in. Net? Singleton How do you make an instance of an object globally available and guarantee that only one instance of the class is created? Implementing Singleton in. Net How do you Implement Singleton in. Net 47

Services Patterns v Key Points w w w Service vs. Instance interfaces Far Links Web Services are About Interop Pattern Problem Service Interface How do you make pieces of your application's functionality available to other applications, while ensuring that the interface mechanics are decoupled from the application logic? Implementing Service Interface using. NET How do you Implement Service Interface in. Net? Service Gateway How do you decouple the details of fulfilling the contract responsibilities defined by the service from the rest of your application? Implementing Service Gateway with. NET 54 How do you Implement Service Gateway in. Net

Service Interface Problem w How do you expose your application’s functionality over a network so it can be consumed by disparate applications? Forces w Separation of concerns – business logic and service contract issues w Consuming applications may require different channels for optimization Solution w 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. 55

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

Implementing Service Interface using. NET 57

Service Gateway v Context w You are designing an application that consumes services provided by another application. The use of this service is governed by a contract indicating communication protocols, msg formats, etc. v Problem w How do you decouple the contract implementation responsibility from the rest of your application? v Forces w Communication and message details often change at a different rate than business logic w Your application may use a different data format than an external service, therefore the data may need transformation w If the contract changes, you want to localize the impact of the change within your application v Solution w Encapsulate contract implementation code in to a Service Gateway 58

Implementing Service Gateway with. NET v Key Points w w 59 Recording. Catalog is the Gateway Recording and Track are Data Transfer Objects

Implementing Service Gateway In. NET 60

Enterprise Solution Patterns Using Microsoft. NET Version 2. 0 David Trowbridge EMEA 61

Conclusion v. Patterns contain atomic chunks of design information v. They enable reuse of architecture, design and implementation decisions v. Provide a common vocabulary and taxonomy v Strong potential for tool integration 62

E S Patterns at Tech. Ed 2003 By David Trowbridge http: //microsoft. sitestream. com/DEV 361_files/default. htm Last year’s EMEA Architect Tour (Finland) http: //www. dotnetmaailma. com/dotnetmaailma/seminaarit/ online/EMEA+Architects+Tour. htm EMEA 63

Patterns catalog online (complete list) v. Enterprise Solution Patterns (book; v 2. 0) http: //msdn. microsoft. com/practices/type/Patterns/Enterprise/ 27+5 v. Data Patterns (book) http: //msdn. microsoft. com/practices/type/Patterns/Data/ 12 v. Patterns community: w http: //www. gotdotnet. com/team/archticture 64

Longhorn Developer Preview Lisboa, 9 Fevereiro v The road to “Longhorn” w David Chappell v “Avalon”: The Longhorn User Experience w Lester Madden, Microsoft EMEA v “Indigo”: The Longhorn Communications w Clemens Vasters, newtelligence AG v “Win. FS”: The Longhorn File System w Hans Verbeeck, Microsoft EMEA v “Whidbey”: Get ready for Longhorn w Nigel Watling, Microsoft EMEA 65

Connected Applications Tour April 2004 v. Web Services, Biztalk & Indigo 66

Obrigado José António Silva joseas@microsoft. com http: //canoas. com/blog/ EMEA 67