Software Architecture & Design

 Architecture
 From n-Tier to SOA
 From SOAP to REST
 Technical Debt
 Design
 From SQL to ORM, NoSQL and ODM
 From RAD to MVC
 SOLID principles
 Domain Driven Design (DDD)

Applying patterns on Delphi code using mORMot

Software Architecture & Design

From n-Tier to SOA
From n-Tier to SOA

 Multi-tier architecture
 Logical and Physical Views
 Service-Oriented Architecture (SOA)
 mORMot practicing

From n-Tier to SOA

Multi-tier architecture
… a piece of cake?

From n-Tier to SOA

Multi-tier architecture
… a piece of cake?
Presentation Tier

Application Tier

Business Logic Tier

Data Tier

From n-Tier to SOA

Multi-tier architecture
 Often referred to as n-tier architecture

 Client–server architecture in which:

 Presentation

 Application processing
 Data management

are logically separated processes

 Most widespread use of multi-tier architecture

is the 3-tier architecture
From n-Tier to SOA
Two-tier architecture

 VCL/FMX/IW app

 SQL Database

From n-Tier to SOA

Two-tier architecture

 VCL/FMX/IW app Application Tier

 SQL Database Data Tier

From n-Tier to SOA

Three-tier architecture
Presentation Tier

Logic Tier

Data Tier

From n-Tier to SOA

Four-tier architecture
Presentation Tier

Application Tier

Business Logic Tier

Data Tier

From n-Tier to SOA

Logical and Physical Views
 Most of the time, n-Tier is intended
to be a physical (hardware) view
 e.g. separation between the database server
and the application server
 placing any tier on a separate machine
to facilitate ease of maintenance

From n-Tier to SOA

Logical and Physical Views
 In SOA, we deal with logical layout
 Separation of layers through logic interfaces
 Underlying hardware implementation may,
but will usually not, match the logical layout

From n-Tier to SOA

Logical and Physical Views

From n-Tier to SOA

Logical and Physical Views

PHYSICAL
 Web Client

 Web Server

 SQL Database

From n-Tier to SOA

Logical and Physical Views

PHYSICAL
 Web Client

 Web Server
 Embedded SQLite3 Database

From n-Tier to SOA

Logical and Physical Views

LOGICAL
 Web app Application Tier
Client & Server

 SQL Database Data Tier

From n-Tier to SOA

Logical and Physical Views

LOGICAL
 Web app
Client & Server

Application Tier
 SQL Database
 With stored procedures

Data Tier
From n-Tier to SOA
Logical and Physical Views
Client 1 (Delphi) Client 2 (AJAX)
Presentation Tier
Presentation Tier Presentation Tier

Application Server
Application Tier
Application Tier

Business Logic Tier

Business Logic Tier

DB Server
Data Tier
Data Tier

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 Definition:
Is a flexible set of design principles
used during the phases of
systems development and integration

 Goal:
Package functionality as a suite of
inter-operable services
that can be used within multiple, separate systems
from several business domains

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 The SOA implementations rely
on a mesh of uncoupled software services
 Software Service:
A consumer asks a producer
to act in order to produce a result
 Invocation is free from previous invocation
(stateless), to minimize resource consumption

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 The SOA implementations rely
on a mesh of uncoupled software services
 Those Services comprise
 unassociated, loosely coupled
units of functionality
(each service implements one action)
 that have no direct call to each other
(via protocols, catalogs over a bus)

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 The SOA implementations rely
on a mesh of uncoupled software services
Consumers Service Bus Publishers

Client A Publisher 1 Service 1

Client B Publisher 2 Service 2

Client C Publisher 3 Service 3

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 The SOA implementations rely
on a mesh of uncoupled software services
 Service composition
 Logicalmulti-tier orchestration (transactional)
 A higher level service invokes several services

 Works as a self-contained, stateless service

 Lower-level services can still be stateless

 E.g. application services over business services

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 The SOA implementations rely
on a mesh of uncoupled software services
 Service composition
Business Service Bus Business Publishers

Publisher 1 Service 1
Consumers Application Service Bus Application Publishers

Composition Composition
Client A Publisher 2 Service 2
Publisher Service

Publisher 3 Service 3

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 The SOA implementations rely
on a mesh of uncoupled software services
 Micro Services
 SOLID principles meet SOA
 Favor stateless calls
 Enhance scaling abilities
 Expects services discovery

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 SOA is mainly about decoupling

 It enables implementation independence

in a variety of ways
 Platform

 Location

 Availability

 Versions

From n-Tier to SOA

 Service-Oriented Architecture
(SOA)
Dependency Desired decoupling Decoupling technique

Hardware, Framework or Operating

Standard protocols, mainly Web
Platform System should not constrain choices
services (e.g. SOAP or RESTful/JSON)
of the Services consumers

Consumers may not be impacted by Routing and proxies will maintain

Location
service hosting changes Services access

Maintenance tasks shall be Remote access allows centralized

Availability
transparent support on Server side

New services shall be introduced Contract marshaling can be

Versions
without requiring upgrades of clients implemented on the Server side

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 SOA will help contain the business logic
on the Server side, therefore :
 Favor logical Multi-tier architecture
 Uses less bandwidth than a fat client

 From fat client to rich client

 Leverage resources (DB, cache)

 Easier to upgrade

 Cheaper / Safer for the customer (backup, cloud)

From n-Tier to SOA

Service-Oriented Architecture
(SOA)
 SOA expects a top/down mind :
 Don’t start from the DB, but end-user app
 Define services, not data structures
 Ability to uncouple things
 Identify bounded contexts and needed information
 Modelize your business in reusable services
 Focus on your domain to build tools and maximize ROI
 Cross-cutting features may be delegated
 Emailing, CRM, billing, reporting, UI…

From n-Tier to SOA

mORMot’s SOA

… to be continued
(we will come back here later)
REST is needed!

From n-Tier to SOA

mORMot’s SOA Presentation

AJAX Reporting UI

REST Client i18n

HTTP 1.1

Application

REST Server

Domain
Model

Services
(interface-based)

Entities Aggregates Value Objects

as TSQLRecord as TSQLRecord as record

Data persistence

ORM

Cross-Cutting

Security Tests Filtering

Cache Logging SQLite3
Sessions Mocks/Stubs Validation

External DB

From n-Tier to SOA

mORMot’s SOA
 Services can be implemented as:
 Method-based resource-focused services
 Interface-based services

 RESTful architecture
 Overseveral protocols, e.g. HTTP/1.1
 JSON and UTF-8 based

 KISS / CoC design

From n-Tier to SOA

mORMot’s SOA
 Method-based services
… have already been explained in REST context
 Give full access to the request

 Manual marshalling, e.g. for parameters

 on the server side (error prone)
 on the client side (dedicated code to write)

 Still too close to the metal

From n-Tier to SOA

mORMot’s SOA
 Interface-based services
 Follow Delphi native abstraction of interface
 Safe thanks to strong naming and typing
 Parameters are marshaled via method signature
 Optional dual-way callbacks (WebSockets)

 Client-side wrapper is generated at runtime

 Features RESTful JSON, so AJAX ready
 Tied to mORMot’s RESTful and security model
 Easily integrated with stubbing/mocking features

From n-Tier to SOA

mORMot’s SOA
 Interface-based services
 Abstraction allows loosely coupled relationship
 Design by contract

 Factory driven
 on server side
 on client side

 Auto-marshalling to JSON
 Tied to framework’s security and light sessions

 Instance life-time, and execution threading

From n-Tier to SOA

mORMot’s SOA
 Interface-based services steps:
 Definea contract
 Implement the contract on server side

 Host and publish the service

 Access the service from client side

From n-Tier to SOA

mORMot’s SOA
 Define a contract
type
ICalculator = interface(IInvokable)
['{9A60C8ED-CEB2-4E09-87D4-4A16F496E5FE}']
/// add two signed 32 bit integers
function Add(n1,n2: integer): integer;
end;
 ICalculator interface defines the contract
 Add() method defines the operation

 Handle any kind of parameters

 Including classes, variants, dynamic arrays or records

From n-Tier to SOA

mORMot’s SOA
 Implement the contract on server side
type
TServiceCalculator = class(TInterfacedObject, ICalculator)
public
function Add(n1,n2: integer): integer;
end;

function TServiceCalculator.Add(n1, n2: integer): integer;

begin
result := n1+n2;
end;
 … and that’s all !

From n-Tier to SOA

mORMot’s SOA
 Host and publish the service
Server.ServiceRegister(
TServiceCalculator,[TypeInfo(ICalculator)],sicShared);

 willregister the TServiceCalculator class

 to implement the ICalculator service

 with a single shared instance life time

 to any TSQLRestServer instance

From n-Tier to SOA

mORMot’s SOA
 Host and publish the service
Server.ServiceDefine(
TServiceCalculator,[ICalculator],sicShared);

 willregister the TServiceCalculator class

 to any TSQLRestServer instance

 to implement the ICalculator service

 with a single shared instance life time

From n-Tier to SOA

mORMot’s SOA
 Host and publish the service – instance life time
Lifetime Use case
sicSingle An asynchronous process (may be resource consuming)

sicShared Either a very simple process, or requiring some global data

The best candidate to implement a Business Logic workflow

sicClientDriven
and light transactional process (Unit-Of-Work pattern)

sicPerSession To maintain some data specific to the client application

sicPerUser Access to some data specific to one user

Access to some data shared by a user category

sicPerGroup
(e.g. administrators, or guests)

sicPerThread Thread-oriented process (e.g. for proper library initialization)

From n-Tier to SOA

mORMot’s SOA
 Access the service from client side
Client.ServiceDefine([ICalculator],sicShared);

var I: ICalculator;
begin
if Client.Services['Calculator'].Get(I) then
result := I.Add(10,20);
end;
 Register to any kind of TSQLRestClient
 Execution will take place on the server side
 A “fake” class implementing ICalculator will be created
 Data is transmitted by representation as JSON (array of) values
 Any server-side exception will be transmitted to the client

From n-Tier to SOA

mORMot’s SOA
 Interface-based services routing
 Classes available by default:
TSQLRestRoutingREST TSQLRestRoutingJSON_RPC

Description RESTful mode JSON-RPC mode

Default Yes No
/Model/Interface.Method[/ClientDrivenID]
URI scheme or /Model/Interface/Method[/ClientDrivenID] /Model/Interface
+ optional URI-encoded params
{"method":"MethodName",
JSON array (or object) of parameters
Body content "params":[...]
or void if parameters were encoded at URI [,"id":ClientDrivenID]}

RESTful authentication for each method RESTful authentication for the

Security
or for the whole service (interface) whole service (interface)

 you can define your own class

From n-Tier to SOA

mORMot’s SOA
 Interface-based services execution modes
 Per-method threading behavior
TServiceMethodOptions Description
All methods are re-entrant and shall be coded to be thread-safe
none (default)
(best scaling performance, but may be error prone)
optExecLockedPerInterface Each interface will be protected/locked by its own mutex

optExecInMainThread Methods will be executed in the process main thread

optFreeInMainThread Interface will be released in the process main thread

optExecInPerInterfaceThread Each interface will execute its methods in its own thread
optFreeInPerInterfaceThread Each interface will be freed in its own thread

From n-Tier to SOA

mORMot’s SOA
 Interface-based services security
 Based on framework’s RESTful authentication
 Expects a user to be authenticated
and an in-memory session to be initiated
 Once authenticated, every service is by default allowed
 You can restrain execution per group,
using a fluent interface, e.g.
Server.ServiceDefine(
TServiceCalculator,ICalculator],sicShared).
DenyAll.
AllowAllByName(['Supervisor']);

From n-Tier to SOA

mORMot’s SOA
 Interface-based services analytics
 Every REST call logged in a (SQLite3) DB
 Interface& Method name
 Input & Output parameters (or exceptions)
 User session, Time elapsed
 With no performance penalty (using batch)
 Disabled by default, enabled in one call

 Allows real-time or after-time detailed analytics

 Aspowerful SQL statements
 Remotely accessible from DDD ToolsAdmin

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Specify the callback as an interface parameter
 Native way of coding
 Real-time push notifications over WebSockets
 Upgraded from a standard HTTP connection
 Peer To Peer communication
 No need of a centralized message bus / server

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Specify the callback as an interface parameter
ILongWorkCallback = interface(IInvokable)
…
end;
ILongWorkService = interface(IInvokable)
['{09FDFCEF-86E5-4077-80D8-661801A9224A}']
procedure StartWork(const workName: string;
const onFinish: ILongWorkCallback);
function TotalWorkCount: Integer;
end;

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
ILongWorkCallback = interface(IInvokable)
['{425BF199-19C7-4B2B-B1A4-A5BE7A9A4748}']
procedure WorkFinished(const workName: string;
timeTaken: integer);
procedure WorkFailed(const workName, error: string);
end;
ILongWorkService = interface(IInvokable)
['{09FDFCEF-86E5-4077-80D8-661801A9224A}']
procedure StartWork(const workName: string;
const onFinish: ILongWorkCallback);
function TotalWorkCount: Integer;
end;

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Real-time push notifications over WebSockets

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Real-time push notifications over WebSockets
 Once upgraded, communicates using frames
over a bi-directional socket connection
using application-level protocols
 Security, frames gathering, REST emulation

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Real-time push notifications over WebSockets
 Once upgraded, communicates using frames
over a bi-directional socket connection
using application-level protocols

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Real-time push notifications over WebSockets
 Security, Frames gathering, REST emulation
 TWebSocketProtocolBinary : SynLZ compress + AES-256

 Non-blocking methods with no result

will be asynchronously sent,
optionally gathered as “jumbo frames”
 Regular blocking methods expecting results
will be emulated like regular REST requests,
with REST security and parameters marshalling

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Publish/Subscribe
Pattern
also known as “Observer”

Publisher

Event Event

Subscriber 1 Subscriber 2 Subscriber 3

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Beware of the “race conditions” or “dead locks”
 Use critical sections to protect your shared data
in a multi-threaded server to avoid race conditions
 If your callback triggers another method
which shares the same critical section
in another thread, you may have a dead lock
 Gather all non-blocking callback process
in a background thread using
TSQLRest.AsynchRedirect

From n-Tier to SOA

mORMot’s SOA
 Interface-based services callbacks
 Sample 31
 Long-Work Push Notification
also known as “Sagas”
 Publish/Subscribe
Pattern
also known as “Observer”

From n-Tier to SOA

mORMot’s SOA
 Cross-platform Interface-based services
 Generated client code using Mustache templates
 Delphi:Windows, MacOS, Android, iOS
 FPC: Windows, MacOS, Android, iOS, Linux, …
 (Cross)Kylix: Linux
 SmartMobileStudio: Ajax / HTML5

 Featuring almost all framework abilities

 JSON marshalling, security, instance lifetime

From n-Tier to SOA

From n-Tier to SOA