Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A1 from n tier to soa

950 views

Published on

NTier SOA Architecture Delphi OpenSource mORMot

Published in: Software
  • Be the first to comment

A1 from n tier to soa

  1. 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. 2. From n-Tier to SOA
  3. 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. 4. Multi-tier architecture From n-Tier to SOA … a piece of cake?
  5. 5. Multi-tier architecture From n-Tier to SOA … a piece of cake? Presentation Tier Application Tier Business Logic Tier Data Tier
  6. 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. 7. Two-tier architecture From n-Tier to SOA  VCL/FMX/IW app  SQL Database
  8. 8. Two-tier architecture From n-Tier to SOA  VCL/FMX/IW app  SQL Database Application Tier Data Tier
  9. 9. Three-tier architecture From n-Tier to SOA Presentation Tier Logic Tier Data Tier
  10. 10. Four-tier architecture From n-Tier to SOA Presentation Tier Application Tier Business Logic Tier Data Tier
  11. 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. 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. 13. Logical and Physical Views From n-Tier to SOA
  14. 14. Logical and Physical Views From n-Tier to SOA PHYSICAL  Web Client  Web Server  SQL Database
  15. 15. Logical and Physical Views From n-Tier to SOA PHYSICAL  Web Client  Web Server  Embedded SQLite3 Database
  16. 16. Logical and Physical Views From n-Tier to SOA LOGICAL  Web app Client & Server  SQL Database Application Tier Data Tier
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. mORMot’s SOA From n-Tier to SOA … to be continued (we will come back here later) REST is needed!
  31. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 50. mORMot’s SOA  Interface-based services callbacks  Real-time push notifications over WebSockets From n-Tier to SOA
  51. 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. 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. 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. 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. 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. 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. 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. 58. From n-Tier to SOA

×