Dan Cohen Microsoft Consulting services Microsoft Israel

Transcription

1 Dan Cohen Microsoft Consulting services Microsoft Israel

2 Agenda Learn key architectural styles: client/server layered architecture component-based architecture message-bus architecture service-oriented architecture (SOA) Scenarios, principles, and benefits of each How to choose an appropriate architectural style

3 What Is an Architectural Style? AKA Architecture Pattern A coarse-grained pattern an abstract framework Solutions to frequently recurring problems A set of principles for a family of systems that determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined Introduction to Software Architecture David Garlan and Mary Shaw, January 1994

4 Benefits of Architectural Styles Common language that is also technology-agnostic Defined constraints Exhibits well-known Quality Attributes Enables forecasting architecture impact Enables architecture analysis Promotes design reuse Promotes artifact reuse

5 What Is an Architectural Style? Styles describe different aspects of applications A typical app will implement more than one style Application Aspect Communication Deployment Domain Interaction Structure Architecture styles Service-Oriented Architecture (SOA) Message Bus Pipes and Filters Client/server 3-Tier N-Tier Domain Model Gateway Separated Presentation Component-Based Object-Oriented Layered Architecture

6 3-Tier/N-Tier Architectural Style Category: Deployment Segregates functionality into separate segments (similar to the layered style) Each segment being a physically separate tier Deployment 3-Tier, N-Tier

7 3-Tier/N-Tier Architectural Style Key Principles: Defines the deployment of the layers Characterized by functional decomposition Typically provides improved scalability, availability, manageability, and resource utilization Typically affects latency and response times due to resource distribution Each tier is only dependant on tiers immediately above and below it Deployment 3-Tier, N-Tier

8 3-Tier/N-Tier Architectural Style Benefits: Maintainability Scalability Flexibility Availability Deployment 3-Tier, N-Tier

9 3-Tier/N-Tier Architectural Style Examples: Financial Web application: Security is important Business layer needs to be deployed behind a firewall Forces deployment of the presentation layer on a separate tier in the perimeter A rich client connected application: Presentation layer is deployed on client machines Business layer and data access layer are deployed on the server Deployment 3-Tier, N-Tier

10 3-Tier/N-Tier Architectural Style Consider N-tier or 3-tier Processing in one layer could absorb resources Different security requirements of the layers Share business logic between applications Sufficient hardware to available for each tiers Consider N-tier when: Security requirements dictate that business logic cannot be deployed to the perimeter network Heavy use of resources causes need to offload functionality to separate tiers Deployment 3-Tier, N-Tier

11 Client/Server Architectural Style Segregates a system into two computer programs Typically statefull connection between programs Characteristics: Distributed system Requires 2 separate servers and a connecting network Requesting client Responding server Can use a range of protocols and data formats Deployment Client/Server

12 Client/Server Architectural Style Key Principles: Client initiates one or more requests, waits for replies and processes the replies on receipt Client is connected to one server Client interacts directly with the user (using a UI) Server does not initiate any requests Server responds to requests from connected clients Server typically authorizes the user and only then processes the request Deployment Client/Server

13 Client/Server Architectural Style Benefits: Higher security Centralized data access Ease of maintenance Deployment Client/Server

14 Client/Server Architectural Style Examples: Internet or intranet browser based programs WinForms apps that access back-end services Applications that access remote data stores (such as: readers, FTP clients, database query tools etc.) Tools that manipulate remote systems (such as system management tools and network monitoring tools) Deployment Client/Server

15 Client/Server Architectural Style Considerations: Web-based applications exposed through a browser Business processes used throughout the organization Creating services for application consumption Centralize data storage, backup, and management Support different client types and different devices Server-based application that supports many clients If statefull connection - Quality Attributes limitations: Limited scalability (scale-out) Limited availability (fault-tolerance, redundancy etc.) Deployment Client/Server

16 Client/Server Architectural Style Variations on the client/server style include: Client-Queue-Client systems Peer-to-Peer (P2P) applications Application servers Deployment Client/Server

17 Component-based Architectural Style Decomposes design into reusable components Component are: location-transparent expose defined communication interfaces Structure Component-based

18 Component-based Architectural Style Characteristics: Build applications made up of individual components Emphasizes decomposing systems into functional or logical components that have well-defined interfaces Design approach uses discrete components Components communicate through defined interfaces Interfaces expose methods, events, and properties Hide implementation details behind interfaces Structure Component-based

19 Component-based Architectural Style Key Principles: Reusable Not context-specific Extensible Encapsulated Independent Structure Component-based

20 Component-based Architectural Style Benefits Ease of deployment Reduced cost Ease of development Reusable Mitigation of technical complexity Structure Component-based

21 Component-based Architectural Style Examples: User interface components ( controls ) Helper components (expose specific functionality) Remoting or distributed component scenarios Infrequenly accessed components Resource-intensive Just in Time (JIT) activation approach Queued components (asynchronous, queued, storeand-forward) Structure Component-based

22 Component-based Architectural Style Considerations: Working with components from third-party suppliers Application will execute procedural-style functions Perhaps with little or no data input Combine components written in different languages Create a pluggable architecture To easily replace and update individual components Structure Component-based

23 Layered Architectural Style Separate concerns partitioned to separate layers Hierarchical distribution of roles and responsibilities Role: mode and type of interaction with other layers Responsibility: functionality addressed by layer Structure Layered Architecture

24 Layered Architectural Style Characteristics: Describes decomposition of services Most interactions occur between neighboring layers Layers an application may reside on the same tier Layers may be distributed over separate tiers (N-tiers) Components communicate through well-defined interfaces An inverted pyramid of reuse : each layer aggregates the responsibilities and abstractions of the layer directly beneath it Structure Layered Architecture

25 Layered Architectural Style Key Principles: Abstraction Encapsulation Clearly defined functional layers Reusable High cohesion Loose coupling Structure Layered Architecture

26 Layered Architectural Style Benefits: Abstraction of changes Isolation of technology, lifecycle and implementation Distributing the layers adds scalability, fault-tolerance Testability Independent Structure Layered Architecture

27 Layered Architectural Style Variations on the layered architectural style: Strict layering Layer skipping Black-box layering White-box layering Structure Layered Architecture

28 Layered Architectural Style Considerations: Application is complex Application is part of family of similar application type Suitable layers exist or built for reuse Existing apps exposes reusable business processes Concurrent multi-team development Required complex and/or configurable business rules Apply rules to cross-layer dependencies Top-bottom call-chain No circular dependencies (consider IoC) Structure Layered Architecture

29 Message-bus Architectural Style Messages are based on a set of known formats Communicate without knowing the actual recipient/s Loosely coupled Implicit invocation Typical usages: Messaging router Publish/Subscribe Communication Message-bus

30 Message-bus Architectural Style Characteristics: Interaction accomplished by passing messages over a common bus Typically employs asynchronous communication using a messaging system (such as MSMQ) Requires common schema, data formats, shared infrastructure Communication Message-bus

31 Message-bus Architectural Style Key Principles: Message-oriented communication Complex processing logic Modifications to processing logic Integration with different environments Communication Message-bus

32 Message-bus Architectural Style Benefits: Expandability of connected applications Reduced application communication complexity (...) High performance (limited by how fast the bus is) Scalability Integration support Reduced cross-application complexity Communication Message-bus

33 Message-bus Architectural Style Variations: Enterprise service bus (ESB) Internet service bus (ISB) Communication Message-bus

34 Message-bus Architectural Style Considerations: Existing applications interoperate with each other Task require interaction with external applications Task that requires interaction with applications hosted in different environments Combine tasks into a single operation Potentially multiple recipients per-message Multiple Message Exchange Patterns (MEP s) Advanced message monitoring, management, routing, retry etc. Communication Message-bus

35 Separated Presentation Style Separates user interaction logic, UI view and data MVC MVP Interaction Separated Presentation

36 Separated Presentation Style characteristics: Well-known design patterns Separates: User interaction logic (Controller / Presenter) User interface view (View) Data (Model) Enables separation of development: Graphical designers create a UI view Developers generate the code to drive it Improved testability Interaction Separated Presentation

37 Separated Presentation Style Key Principles: Separation of concerns Improved testability Event-based notification Delegated event handling Interaction Separated Presentation

38 Separated Presentation Style Benefits: Testability Reusability Manageability Composeability Interaction Separated Presentation

39 Separated Presentation Style Considerations: Improved testability Simpler maintenance of UI functionality Creating the UI and UI logic code separately UI view does not contain any request-processing code UI processing code does not implement business logic Requires composable or modifiable UI Complex or modification-prone UI logic Interaction Separated Presentation

40 Service-Oriented Architectural Style Applications expose and consume functionality as a separate service Interfaces are standards-based Schema and message-based interaction A service is application-scoped not component-scoped Communication Service-Oriented Architecture (SOA)

41 Service-Oriented Architectural Style Characteristics: Loosely-coupled Interaction Business processes packaged as interoperable services Can be accessed locally (same tier) or remotely Can use a range of protocols and data formats Communication Service-Oriented Architecture (SOA)

42 Service-Oriented Architectural Style Key Principles: the 4 Tenets Explicit boundaries Distributable, loosely-coupled Services are autonomous Services share schema and contract, not class Compatibility is based on policy Communication Service-Oriented Architecture (SOA)

43 Service-Oriented Architectural Style Benefits: Domain alignment Abstraction Discoverability Communication Service-Oriented Architecture (SOA)

44 Service-Oriented Architectural Style Considerations: Suitable services are accessible or can be purchased Compose variety of services in a single UI / BL Support message-based communication Expose platform-independent functionality Support interoperability and integration Expose / consume dynamically discoverable services Application is oriented towards: Software plus Services (S+S) Software as a Service (SaaS) Cloud-based applications Communication Service-Oriented Architecture (SOA)

45 Pipes-and-Filters Architectural Style Allow information to be processed by multiple components, consecutively. Use configuration to define processing order Manage the components and processing at runtime Communication Pipes-and-Filters

46 Pipes-and-Filters Architectural Style Characteristics: Loosely-coupled Interaction between components Can be manipulated at design-time or run-time Must use a defined contract / interface for all pipes Communication Pipes-and-Filters

47 Pipes-and-Filters Architectural Style Benefits: Configurability Composeability Manageability Reusability Testability Communication Pipes-and-Filters

48 Thank you.