Introduction to Java EE3-tier System Design Recommendations

3-tier System Design Recommendations 2

Recommendations

Platform Capabiliti

es & Restrictio

ns

Software Design

Principles

Requirement

Specification (use cases)

3-tier System Design Recommendations

3-tier System Design Recommendations 3

3-tier Multilayer Reference Architecture

Application Server

Presentation

Business Logic

Data Access

DBMS

Tables/Triggers/Stored procedures

Client

Browser Internet

3-tier System Design Recommendations 4

Design AssumptionsWe are creating business software system

(business transaction processing system)3-tier architectural style (Client, Application

Server, DBMS)Relational DBMSData consistency is more important than system

performance (CAP theorem: CA is picked)Up to 1000-10000 concurrent usersSystem will evolve in the future

Actually, all systems have to evolve (more or less) But: not all developers do their best to enable easy

system evolution (modifiability/extensibility)!

3-tier System Design Recommendations 5

Design QuestionsUse case implementation should consist of

how many components?How granular components should be?Of what type (stateless/stateful) components

should be?How many components single web page

should/may use?Should we create a separate component for

each web page?

3-tier System Design Recommendations 6

Restriction Example: Data Access Tier (Java EE and .NET)All Web Applications ARE multi-threadedORM is not thread-safe

.Net EntityFramework ObjectContext is not thread-safe too1

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

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

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

is problematic 1 Entity Framework FAQ: ObjectContext

3-tier System Design Recommendations 7

Recommendations – OutlineThe use case model is taken as an input, then for

each use case:1. Determine the use case type:

Request, Conversation, Whiteboard2. Design use case implementation (iterative

process):1. Decide what number of UI forms and business

components is needed to implement the use case2. Apply Software Design Principles (if business

components violate some principles, restructure them)

3. Design with reuse in mind3. Document the design decisions taken (UML)

3-tier System Design Recommendations 8

How to Create a Use Case ModelDifferent software processes dictate different

approachesRecommendations for the second laboratory

work:We start by modelling business process of the

company BPMN diagram is created

Business process contains steps performed manually steps performed with the help of the system being

constructed (automated steps)Automated steps are candidates to become use

cases (or groups of use cases) in the use case model

3-tier System Design Recommendations 9

1. Use Case Types: RequestSingle HTTP request is enough to implement

the use caseUsually one (or at most two) web pages:

the first page has an HTML form collecting some data,

the second shows the resultsExamples:

Register a new student for a selected course Browsing through the web site (data are being

presented in pages in read-only form)

3-tier System Design Recommendations 10

1. Use Case Types: ConversationA use case is of conversation type if:

it needs several forms to be filled with datathere is a clear beginning and an end of

interaction with the userConversation 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 requestsData collected in the beginning of the

conversation must be remembered on the server-side till the end of the conversation

3-tier System Design Recommendations 11

1. Conversation Example

3-tier System Design Recommendations 12

1. Use Case Types: WhiteboardWhiteboard is the way to implement the use case when

several users are allowed to work with the same data concurrentlyhttp://en.wikipedia.org/wiki/WhiteboardingExample: several users are editing the same document

with Google DocsThere is no clear beginning or endNeed for synchronization arises:

maybe I’m editing data that is removed alreadymaybe the same data is being edited by several usersnew 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

3-tier System Design Recommendations 13

2. Design use case implementation Needed business logic (including data

access/modification) is implemented in componentsRemember: Component technologies allow to

separate business logic from middleware servicesTry hard to use one and the same cache for the

whole use case implementationThis way you will not get hit by ORM restrictions

(e.g. trying to put the same entity object into two caches)

=> single cache owner is needed – Use Case Controller

Use Optimistic Locking for long-lived entities!

3-tier System Design Recommendations 14

Collaboration Example

3-tier System Design Recommendations 15

2. Apply Design Principles: TheoryMost important design principles:

Separation of Concerns (Wikipedia) – high-level principle, governing the whole set of more detailed principles (below)

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 decompositionWe will decompose single business component into multiple

components

3-tier System Design Recommendations 16

2. Design Principles: Architect vs. DeveloperSingle class design is usually responsibility of

developer, not architectArchitect 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 CohesionLoose Couplingto functional and non-functional requirements

3-tier System Design Recommendations 17

2. Principles: SoC and CohesionApplying Separation of Concerns and High Cohesion principles

to requirements specification we can distinguish these kinds of requirements1:Localizable functional requirements (implemented in SINGLE

module) Example: Internal bank money transfer

Crosscutting functional requirements (tend to be scattered throughout 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 (Wikipedia) (Interceptor/Proxy Pattern) They always are crosscutting! Examples: transactions, security checks, audit logging, etc.

1 Modularization of Crosscutting Concerns in Requirements Engineering, 2008 (PDF)

3-tier System Design Recommendations 18

2. Kinds of Requirements: Example

3-tier System Design Recommendations 19

2. Loose Coupling PrincipleTechniques 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 object has

some interface)!

3-tier System Design Recommendations 20

2. Loose Coupling PrincipleLoose Coupling is very important for

implementation of crosscutting functional requirements

Modern technological platforms should provide means how to implement crosscutting functional requirements:Without code duplication (DRY principle)With loose coupling (or no coupling at all)

3-tier System Design Recommendations 21

2. Collaboration Example

3-tier System Design Recommendations 22

2. Consider Concurrency Patterns and Asynchronous CommunicationIf use case implementation algorithm takes

long time, consider splitting it to concurrently running parts

Concurrency patterns help to choose best algorithm decomposition schemeProducer-Consumer, Work pool, Map-Reduce,

Fork-Join, etc.Often communication between parts will have

to be asynchronous

3-tier System Design Recommendations 23

2. Consider Concurrency Patterns and Asynchronous CommunicationLocalizable functional requirements

We may NEED asynchronous communication facilities (if computations take a long time)

Crosscutting functional requirementsNot-impacting cross-cut functionality (Observer

Pattern): We may NEED asynchronous communication facilities

Impacting cross-cut functionality (Decorator Pattern) We CANNOT have asynchronous communication here (by

definition)Non-functional requirements

We CANNOT have asynchronous communication here (by definition)

3-tier System Design Recommendations 24

2. Design for ReuseUse cases rarely are subject of reuse

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

and they can be statefulUse case parts (chunks of cohesive

functionality) are mostly the same in all the systems targeting the same Application Domain, and are subject of reuseExample: 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 stateless (if possible)

3-tier System Design Recommendations 25

3. Documenting Design DecisionsUI 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

3-tier System Design Recommendations 26

3. Collaboration Example