N-Tier, Layered Design, SOA
5 likes8,562 views
This document discusses N-tier and layered application architectures. It defines layers as logical groupings of functionality and components, while tiers describe the physical distribution of those layers across servers or networks. Common layers include presentation, business, and data access layers. These layers can be separated across tiers on different machines. The document provides examples of how layers map to tiers in applications, including user interfaces, APIs, business logic, and data storage. It outlines best practices for separating concerns across layers and distributing components across tiers to achieve benefits like scalability, reusability and testability.
N-Tier, Layered Design, SOA
- 1. N-Tier, Layered Design, SOA
- 2. • 2-tier, 3-tier, N-tier • Layered architecture (object-oriented design principle) • Everywhere we hear of Presentation, Business & Data Access Confusion
- 3. Reference: Layered Application Guidelines http://msdn.microsoft.com/en-us/library/ee658109 Presentation, Business & Data Layers
- 4. Reference: Layered Application Guidelines http://msdn.microsoft.com/en-us/library/ee658109 When Service Layer Comes Up
- 5. • Both Layers and Tiers use the same set of names – Presentation, Business, Services, Data • Layers describe the logical grouping of the functionality and components in an application Distinction Between Layers & Tiers
- 6. • Tiers describe the physical distribution of the functionality and components on separate servers, computers, networks or remote locations • Tiers imply a physical separation! • Quite common to locate more then one layer on the same Tier (physical machine)
- 7. Layered architecture becomes N-tier the following way: Remember: Tiers imply a physical separation! Within a Single Component
- 8. • Presentation (UI and API) • Business Logic • Data Access • Data Storage (RDBMS, File system) Tiers
- 9. Presentation Tier • Web UI • Desktop applications • iPhone, iPad, Android applications • REST, SOAP interfaces etc • Sockets, TCP, UDP etc • FIX, Swift and other protocols • Depends on platform and used technologies!
- 10. Presentation Tier (API) Performs: • Depends on a host process • Defines data tiers and other components to be used • Builds up an application from components • Defines used data sources (connection strings, URLs, configuration) • Manage request context • Stateless
- 11. • receives requests by a protocol • converts requests into business objects • invokes business logic • gets the result from business logic • prepares that result to be sent in a response • catch exceptions from business logic • defines how those exceptions are sent in response according to used protocol Presentation Tier (API)
- 12. Everything outside doesn’t matter: • Host process agnostic • Data access agnostic It means: • Shouldn’t know about Presentation & Data Tiers Business Tier
- 13. • Defines Business logic Public interface • Defines Data access Public interface • Implements Business logic • Defines Business objects (business entities) • Defines meaningful Exceptions (business related) Business Tier (cont’d)
- 14. Performs: • Business processing, business workflow • Authentication and authorization • Auditing • Exception handling (log and re-throw) • Maintain Transactionality (open, commit, rollback) Business Tier (cont’d)
- 15. • Are defined in Business Tier • NEVER exposed via the Presentation Tier • NEVER assume data storage mechanism It means: • No annotations to define XML, JSON, SOAP, SQL Tables, SQL parameters and so one Business Entities
- 16. • Implements Data Access Interface defined in Business Tier • Tightly coupled with Data Storage Tier • Call chain neutral • Stateless • Transactionalable Data Access Tier
- 17. • RDBMS, Object-Oriented DBMS, NoSQL DB • File system, NAS, DAS • Remote storages: Clouds, FTP etc • In-Memory! No business logic here! Data Storage Tier
- 18. • Single implementation of Business Tier • Multiple implementations of Presentation Tier • Multiple implementations of Data access tier • Multiple implementations of Data Storage Tier All Things Together
- 19. • We can mix components (tiers) to deploy required service (select SQL storage and REST API) • Implementation process is Business logic centric • Scalability up and out • Extensibility • Maintainability • Reusability • Testability (unit and integration tests) • Data Tier performance (isolated to optimizations) Benefits
- 20. • Traceability - use EAI patterns and tools) • Complexity - simple operation requires lots of code for all tiers) • Many similar classes - each class contains the tier specific representation of data) • Performance (under question) Drawbacks
- 21. Request-Reply: • When an application sends a message, how can it get a response from the receiver? • Send a pair of Request-Reply messages, each on its own channel. Patterns
- 22. Correlation Identifier: • How does a requestor that has received a reply know which request this is the reply for? • Each reply message should contain a Correlation Identifier, a unique identifier that indicates which request message this reply is for. Patterns (cont’d)
- 23. Books
- 24. • SOA comes up to divide Middleware to separate services • N-tier implementation is in Services grouped by Purpose SOA
- 25. • Think of your application as of an application that have both: UI of any kind and public API • UI should NOT have any logic • UI should ONLY use public API for everything • That API becomes Middleware services and encapsulates all logic • Extract “elemental” service out of it and build the Data access Tier of services Good Practice