3-tier System Design Recommendations - Pradžiadonatas... · Design Assumptions We are creating business software system (business transaction processing system) We are developing

3-tier System Design Recommendations

Recommendations

Platform Capabilities

& Restrictions

Software Design

Principles

Requirement Specification (use cases)

3-tier System Design Recommendations

3-tier System Design Recommendations 2

Design Assumptions We are creating business software system (business

transaction processing system)

We are developing the first version of the system

Business Domain is new to us

Data consistency is more important than system performance

Up to 1000-10000 concurrent users

System will evolve in the future

Actually, all systems have to evolve – so this is more a requirement than assumption

But: not all developers do their best to enable easy system evolution (modifiability/extensibility)!


High-level Design Decisions Business Domain is new:

=> Take “build a monolith” approach

Data consistency is more important than system performance:

=> Pick Relational DBMS

Up to 1000-10000 concurrent users:

=> Monoliths can handle such a load

System will evolve in the future:

=> Apply modifiability/extensibility/reuse patterns

=> All of them require system elements to be loosely coupled


What is a Monolith? Monolith is a single big peace of software, deployed as a

single unit on the server

Monolith is being executed in a single OS process

Parts of the monolith (elements, components) communicate via direct in-process calls

Network communication is NOT being used

Single instance of Application Server hosts a single instance of the monolith

We can have cluster of Application Servers, but each server would still host the whole monolith

Only thin client and DBMS are outside of the monolith:

We get 3 parts: client, monolith, DBMS


3 tier architecture – two flavors


Application Server

Presentation

Business Logic

Data Access

DBMS

Tables/Triggers/Stored procedures

Client

Browser Internet

Lower-level Design Questions Use case implementation should consist of how many

components?

How granular components should be?

Of what type (stateless/stateful) components should be?

What type of communication between components we should choose? Synchronous, asynchronous, event based

How to achieve loose coupling between components?

Approach “who cares; do it as you like” is risky: Tech. platform restrictions might be violated


Restrictions Example: Data Access (Java EE and .NET) All Web Applications ARE multi-threaded ORM is not thread-safe

.Net EntityFramework ObjectContext is not thread-safe too1

One entity cannot be managed/shared by two EntityManagers The same holds for .Net ObjectContext

One relationship cannot be managed/shared by two EntityManagers The same holds for .Net ObjectContext

Problems of these kinds occur when Web pages belonging to a single use case use different components Approach “each Web page must have dedicated component”

is problematic

1 Entity Framework FAQ: ObjectContext


http://social.technet.microsoft.com/wiki/contents/articles/3739.entity-framework-faq-objectcontext.aspx

Single Use Case Design Process Outline (1)1. Analyze Requirements: list and classify use case

responsibilities: Localizable Functional Req., Cross-cutting Functional Req., Non-

functional Requirement

2. Design the Interaction with the user => Use Case Type: Single Request, Conversation, Whiteboard

3. Design the Structure - apply Software Design Principles:1. Separation of Concerns, High Cohesion – Implement different

responsibilities in different places: Presentation, Use Case Controller, Service Component, Data Access

Component

2. Loose Coupling, Reuse – Structural parts (components) should not depend on each other

Dependency Injection, Component Technologies, Event-based Communication (Observer Pattern), Interceptor Pattern, Decorator Pattern


Single Use Case Design Process Outline (2)4. Take into account Quality Characteristics:

1. Performance – how to decrease the response time

Caching; Asynchronous Communication

2. Scalability, Resilience: how well system adopts to increasing number of concurrent users

Automatic memory management: Stateless/Stateful/Singleton components (component pools, passivation/activation)

3. Robustness – data consistency in multi-user environment

Transactions, Optimistic Locking, Automatic thread management

4. Security, Availability, Modifiability/Extensibility, …

Out of scope for this course


Theory: Kinds of RequirementsScientific article: Modularization of Crosscutting Concerns

in Requirements Engineering, 2008 (PDF) Kinds of requirements:

Localizable functional requirements (can be implemented in SINGLE place) Example: Internal bank money transfer

Cross-cutting functional requirements (tend to be scatteredthroughout the whole code-base) Not-impacting cross-cut functionality (Observer Pattern):

Example: if business transaction exceeds some money limit, inform Tax Inspection

Impacting cross-cut functionality (Decorator Pattern) Example: if money are incoming from other bank, charge

commissions

Non-functional requirements (Interceptor Pattern) They always are cross-cutting! Examples: transactions, security checks, audit logging, etc.


http://www.ccis2k.org/iajit/PDF/vol.5,no.2/3-73.pdf

Theory: Use Case Types: Request Single HTTP request is enough to implement the use

case

One HTML form is enough to collect all the data needed for the use case

Examples:

Register a new student for a selected course

Browsing through the web site (data are being presented in pages in read-only form)


Theory: Use Case Types: Conversation A use case is of conversation type if:

it needs several forms to be filled with data

there is a clear beginning and an end of interaction with the user

Conversation is somewhat similar to transaction (actually it is often called business transaction)

either all conversation steps succeed, or all fail

One conversation spans multiple HTTP requests

Data collected in the beginning of the conversation must be remembered on the server-side till the end of the conversation


Theory: Conversation Example


Theory: Use Case Types: Whiteboard Whiteboard is the way to implement the use case when several

users are allowed to work with the same data concurrently http://en.wikipedia.org/wiki/Whiteboarding

Example: several users are editing the same document with Google Docs

There is no clear beginning or end

Need for synchronization arises: maybe I’m editing data that is removed already

maybe the same data is being edited by several users

new data appears constantly

Use cases of whiteboard type obviously span multiple requests

We will not discuss this type further as it is not common for business software systems


http://en.wikipedia.org/wiki/Whiteboarding

Theory: Software Design Principles Most important design principles:

Separation of Concerns (Wikipedia) – different concerns should be implemented in different places

High cohesion (Wikipedia) Loose coupling (Wikipedia, contains good example) SOLID (Wikipedia)

Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion

GRASP (Wikipedia) – General Responsibility Assignment Software Patterns

100 more principles Seriously, the whole Software Engineering theory is applicable here

Most design principles will usually lead to some kind of decomposition => Use case implementation would consist of multiple

communicating parts3-tier System Design Recommendations 16

http://en.wikipedia.org/wiki/Separation_of_concerns

http://en.wikipedia.org/wiki/Cohesion_(computer_science)

http://en.wikipedia.org/wiki/Loose_coupling

http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)

Theory: Design Principles: Architect vs. Developer Single class design is usually responsibility of

developer, not architect

Architect is responsible for high-level design, and design decisions that cross-cut the whole system

Thus we will not talk further about SOLID and GRASP, but concentrate on how to apply principles of:

Separation of Concerns (SoC)

High Cohesion

Loose Coupling


Theory: Separation of Concerns Presentation

Prepare UI (e.g. HTML)

Use Case Controller

Control the flow of use case steps

Manage the state of the whole use case

Data consistency is responsibility of Use Case Controller!

Service (Business Logic Service)

Algorithms, business functionality

Data Access (aka Repository)

Persistence


Theory: Loose Coupling, Reuse Structural parts should not depend on each other Techniques to achieve loose coupling are:

Introduce stable interfaces between communicating components – ripple effect of changes stops at the interface boundary

Separate the code that creates/configures component instances: Design patterns – Abstract Factory, Builder Dependency Injection (DI) techniques – CDI, Spring Framework Stable interfaces are still mandatory!

Totally remove the dependency between the two communicating components: Event-driven techniques (CDI Events, Spring Framework Events,

Actor model, …) Stable interfaces are still mandatory (event payload)!


Theory: Loose Coupling, Reuse How to achieve loose coupling:

Interfaces (depend on abstraction, not on implementation) Decouple object type from object implementation

Dependency Injection, Decouple object usage from object creation

Component Technologies Decouple business logic from middleware services

Mature technological platforms provide following means to achieve loose coupling: Event-based Communication (Observer Pattern) – decouple

source of change from change observer

Interceptor Pattern – decouple non-functional concerns

Decorator Pattern – decouple business concerns


Theory: Reuse Whole use cases rarely are subject of reuse

Thus Use Case Controller components do not have to be reusable/adaptable

Use case parts (chunks of cohesive functionality) are often very similar in all systems targeting the same Business Domain, and are subject of reuse

Example: Money transfer algorithm most probably is very similar in all Internet banking systems

=> Use case parts should be designed for reuse

=> Use case parts should be as much decoupled as possible (loosely coupled)!


Theory: Quality Characteristics Performance – how to decrease the response time

Caching; Asynchronous Communication

Scalability, Resilience: how well system adopts to increasing number of concurrent users

Automatic memory management: Stateless/Stateful/Singleton components (component pools, passivation/activation)

Robustness – data consistency in multi-user environment

Transactions, Optimistic Locking, Automatic thread management

Security, Availability, Modifiability/Extensibility, …

Out of scope for this course


Theory: Concurrency Patterns and Asynchronous Communication If use case implementation algorithm takes long time,

consider dividing it to several parts running concurrently

Concurrency patterns provide us with most common concurrency problem solving methods:

Producer-Consumer, Work pool, Map-Reduce, Fork-Join, etc.

Often communication between parts will have to be asynchronous


3. Documenting Design Decisions UI forms, business components and ORM entities may

be represented in UML collaboration and sequence diagrams

Following UML stereotypes are useful:

«boundary» – denotes element that is used to interact with a user or external system (e.g. web page, WebService)

«control» – denotes system element that performs some kind of business logic (implementation of functional or non-functional requirements)

«Entity» – denotes some data/information entity


Example: Step 1 Use case: Inter-bank money transfer

User story, requirements, responsibilities, qualities: Money first must be moved from customer’s account to the

local bank’s account; then from local bank account to external bank account

Depending on whether external bank is in the same country or not, smaller or bigger commissions must be charged

All operations with money must be audited

If transaction amount exceeds specified limit, State Tax Inspection must be informed (by calling some external Web Service)

All external communications must be monitored for performance (SLA agreement violations)


Step 2: Decide on Use Case Type, Classify Requirements Use Case type: Conversation type Localizable functional req.:

[REQ1] Move money between local accounts [REQ2] Communicate money transaction with external bank

Cross-cutting impacting functional req.: [REQ3] Depending on whether external bank is in the same country

or not, commissions must be charged (smaller or bigger fee)

Cross-cutting non-impacting functional req.: [REQ4] If transaction amount exceeds specified limit, State Tax

Inspection must be informed (by calling some external Web Service)

Non-functional req.: [REQ5] All operations with money must be audited [REQ6] All external communications must be monitored for

performance (SLA agreement violations)


Step 3: Use case Model: Introduce Sub-functions, pick Patterns


Step 4: Apply Separation of Concerns and Loose Coupling


Inter Bank Money Transfer

Controller

Form template 1

Form template N

Local Money Transfer

Communicate with External

Bank

Charge Commisions

Inform Tax Inspection

Audit all Operations

Monitor Performance

Audit Record Persister

Performance Record Persister

Money Transfer Interface

async

event

Controller

Decorator

Observer

Interceptor

Interceptor

Data Access

Data Access

Account Persister

Data Access

Service

Service

Presentation

Step 5: Analyze Quality Characteristics Analyze and apply:

Transactions

Caching

Asynchronous Communication

Optimistic Locking


Step 6: Apply Specific Technological Platform solutions For Java EE that would be:

Simple class vs. CDI enabled class vs. EJB component

EJB component: Stateless, Stateful, Singleton

CDI/EJB: Dependent, RequestScoped, SessionScoped, ConversationScoped, …

Transactions: Required, RequiresNew

Cache (PersistenceContext): Transaction/Extended; Synchronized/Unsynchronized

Asynchronous communication

Thread safety, memory management – automatically being controlled by Application Server, but we have to know the rules


Documents

3-tier System Design Recommendations - Pradžiadonatas... · Design Assumptions We are creating business software system (business transaction processing system) We are developing