NTier SOA Architecture Delphi OpenSource mORMot

1. 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

2. From n-Tier to SOA

3. From n-Tier to SOA
 Multi-tier architecture
 Logical and Physical Views
 Service-Oriented Architecture (SOA)
 mORMot practicing
From n-Tier to SOA

4. Multi-tier architecture
From n-Tier to SOA
… a piece of cake?

5. Multi-tier architecture
From n-Tier to SOA
… a piece of cake?
Presentation Tier
Application Tier
Business Logic Tier
Data Tier

6. 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

7. Two-tier architecture
From n-Tier to SOA
 VCL/FMX/IW app
 SQL Database

8. Two-tier architecture
From n-Tier to SOA
 VCL/FMX/IW app
 SQL Database
Application Tier
Data Tier

9. Three-tier architecture
From n-Tier to SOA
Presentation Tier
Logic Tier
Data Tier

10. Four-tier architecture
From n-Tier to SOA
Presentation Tier
Application Tier
Business Logic Tier
Data Tier

11. 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

12. 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

13. Logical and Physical Views
From n-Tier to SOA

14. Logical and Physical Views
From n-Tier to SOA
PHYSICAL
 Web Client
 Web Server
 SQL Database

15. Logical and Physical Views
From n-Tier to SOA
PHYSICAL
 Web Client
 Web Server
 Embedded SQLite3 Database

16. Logical and Physical Views
From n-Tier to SOA
LOGICAL
 Web app
Client & Server
 SQL Database
Application Tier
Data Tier

17. Logical and Physical Views
From n-Tier to SOA
LOGICAL
 Web app
Client & Server
 SQL Database
 With stored procedures
Application Tier
Data Tier

18. Logical and Physical Views
From n-Tier to SOA
Presentation Tier
Application Tier
Business Logic Tier
Data Tier
Client 1 (Delphi) Client 2 (AJAX)
Application Server
DB Server
Presentation Tier
Application Tier
Presentation Tier
Business Logic Tier
Data Tier

19. 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

20. 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

21. 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

22. Service-Oriented Architecture
(SOA)
From n-Tier to SOA
Consumers Service Bus Publishers
Client A Publisher 1
Publisher 2Client B
Publisher 3Client C
Service 1
Service 2
Service 3
 The SOA implementations rely
on a mesh of uncoupled software services

23. Service-Oriented Architecture
(SOA)
 The SOA implementations rely
on a mesh of uncoupled software services
 Service composition
 Logical multi-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

24. Service-Oriented Architecture
(SOA)
From n-Tier to SOA
 The SOA implementations rely
on a mesh of uncoupled software services
 Service composition
Consumers Application Service Bus Application Publishers
Business Service Bus Business Publishers
Client A
Composition
Publisher
Composition
Service
Publisher 1
Publisher 2
Publisher 3
Service 1
Service 2
Service 3

25. 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

26. 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

27. Service-Oriented Architecture
(SOA)
From n-Tier to SOA
Dependency Desired decoupling Decoupling technique
Platform
Hardware, Framework or Operating
System should not constrain choices
of the Services consumers
Standard protocols, mainly Web
services (e.g. SOAP or RESTful/JSON)
Location
Consumers may not be impacted by
service hosting changes
Routing and proxies will maintain
Services access
Availability
Maintenance tasks shall be
transparent
Remote access allows centralized
support on Server side
Versions
New services shall be introduced
without requiring upgrades of clients
Contract marshaling can be
implemented on the Server side

28. 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

29. 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

30. mORMot’s SOA
From n-Tier to SOA
… to be continued
(we will come back here later)
REST is needed!

31. mORMot’s SOA
From n-Tier to SOA
Presentation
Application
Data persistence
Domain
Model
Cross-Cutting
AJAX
REST Client
REST Server
HTTP 1.1
Cache
UI
i18n
Filtering
Validation
Reporting
ORM
Services
(interface-based)
Security
Sessions
SQLite3
External DB
Value Objects
as record
Entities
as TSQLRecord
Aggregates
as TSQLRecord
Tests
Mocks/Stubs
Logging

32. mORMot’s SOA
 Services can be implemented as:
 Method-based resource-focused services
 Interface-based services
 RESTful architecture
 Over several protocols, e.g. HTTP/1.1
 JSON and UTF-8 based
 KISS / CoC design
From n-Tier to SOA

33. 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

34. 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

35. 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

36. mORMot’s SOA
 Interface-based services steps:
 Define a contract
 Implement the contract on server side
 Host and publish the service
 Access the service from client side
From n-Tier to SOA

37. 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

38. 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

39. mORMot’s SOA
 Host and publish the service
Server.ServiceRegister(
TServiceCalculator,[TypeInfo(ICalculator)],sicShared);
 will register the TServiceCalculator class
 to implement the ICalculator service
 with a single shared instance life time
 to any TSQLRestServer instance
From n-Tier to SOA

40. mORMot’s SOA
 Host and publish the service
Server.ServiceDefine(
TServiceCalculator,[ICalculator],sicShared);
 will register the TServiceCalculator class
 to any TSQLRestServer instance
 to implement the ICalculator service
 with a single shared instance life time
From n-Tier to SOA

41. mORMot’s SOA
 Host and publish the service – instance life time
From n-Tier to SOA
Lifetime Use case
sicSingle An asynchronous process (may be resource consuming)
sicShared Either a very simple process, or requiring some global data
sicClientDriven
The best candidate to implement a Business Logic workflow
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
sicPerGroup
Access to some data shared by a user category
(e.g. administrators, or guests)
sicPerThread Thread-oriented process (e.g. for proper library initialization)

42. 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

43. mORMot’s SOA
 Interface-based services routing
 Classes available by default:
 you can define your own class
From n-Tier to SOA
TSQLRestRoutingREST TSQLRestRoutingJSON_RPC
Description RESTful mode JSON-RPC mode
Default Yes No
URI scheme
/Model/Interface.Method[/ClientDrivenID]
or /Model/Interface/Method[/ClientDrivenID]
+ optional URI-encoded params
/Model/Interface
Body content
JSON array (or object) of parameters
or void if parameters were encoded at URI
{"method":"MethodName",
"params":[...]
[,"id":ClientDrivenID]}
Security
RESTful authentication for each method
or for the whole service (interface)
RESTful authentication for the
whole service (interface)

44. mORMot’s SOA
 Interface-based services execution modes
 Per-method threading behavior
From n-Tier to SOA
TServiceMethodOptions Description
none (default)
All methods are re-entrant and shall be coded to be thread-safe
(best scaling performance, but may be error prone)
optExecLockedPerInterface Each interface will be protected/locked by its own mutex
optExecInMainThread
optFreeInMainThread
Methods will be executed in the process main thread
Interface will be released in the process main thread
optExecInPerInterfaceThread
optFreeInPerInterfaceThread
Each interface will execute its methods in its own thread
Each interface will be freed in its own thread

45. 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

46. 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
 As powerful SQL statements
 Remotely accessible from DDD ToolsAdmin
From n-Tier to SOA

47. 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

48. 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

49. 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

50. mORMot’s SOA
 Interface-based services callbacks
 Real-time push notifications over WebSockets
From n-Tier to SOA

51. 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

52. 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

53. 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

54. mORMot’s SOA
 Interface-based services callbacks
 Publish/Subscribe Pattern
also known as “Observer”
From n-Tier to SOA
Publisher
Subscriber 1
Event
Subscriber 2
Event
Subscriber 3

55. 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

56. 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

57. 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

58. From n-Tier to SOA