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.

Good by Server... Hello Client!

1,473 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Good by Server... Hello Client!

  1. 1. Good by Server... Welcome Client!SOFEA - ein leichtgewichtiger Architekturansatz Sandro Sonntag Adorsys GmbH & Co. KG
  2. 2. Thin Server ArchitekturWeb API‘s Entwicklung des Webs REST Inhalt Web-Technologien Potenziale Was hat HTML5 Was ist falsch an Richmit Architektur zu tun? Server? Best Practices
  3. 3. Über michSandro SonntagJava Eetwickler - 10 Jahre Java Erfahrung in Enterprise UmfeldLiebe zu Webtechnologien und Webscale Themen Wie REST, JavaScript/Node.JS, Mongo, Couch, AppengineTechnical Lead bei AdorsysUnterwegs als Berater und Softwarearchitekt (CPSA)https://www.xing.com/profile/Sandro_Sonntag
  4. 4. Ursprünge SOFEA
  5. 5. Ursprünge SOFEA2007 Publikation des Papiers „Live above the ServiceTier“ „How to Build Application Front-ends in a Service-Oriented World“ durch Ganesh Prasad, Rajat Taneja, Vikrant Todankar
  6. 6. Ursprünge SOFEA2007 Publikation des Papiers „Live above the ServiceTier“ „How to Build Application Front-ends in a Service-Oriented World“ durch Ganesh Prasad, Rajat Taneja, Vikrant TodankarParallel SOUI Publikation - Service Oriented User Interface „MVC is Dead“ Norlan Wright
  7. 7. Ursprünge SOFEA2007 Publikation des Papiers „Live above the ServiceTier“ „How to Build Application Front-ends in a Service-Oriented World“ durch Ganesh Prasad, Rajat Taneja, Vikrant TodankarParallel SOUI Publikation - Service Oriented User Interface „MVC is Dead“ Norlan WrightAndere geläufige Bezeichnung: „Thin Server Architecture“
  8. 8. einige Trends
  9. 9. Jobtrends - HTML5 und Co.
  10. 10. 1000 APIs in 9 Monaten
  11. 11. SchnittstellenREST und JSON auf dem Vormarsch
  12. 12. 1 in 5 APIs Say “Bye XML”
  13. 13. 13 milliarden API calls / tagSalesforce 50 % des Traffics durch APIs
  14. 14. Anzahl der open API‘s wächst
  15. 15. Twitter Saw 600K SignupsYesterday, It Took More Than 16Months To Reach Its First 600K
  16. 16. GartnerIn the next-generation client/server architecture, the"client" is a rich application running on anInternet-connected device, and the "server" is aset of application services hosted in an increasinglyelastically scalable cloud computing platform.
  17. 17. Chrome OSDer Browser als Betriebssystem
  18. 18. Aber was ist der Auslöser?
  19. 19. Mobile, Smart Pads, iTV,Social Media, DesktopWidgets and smarterWebapps
  20. 20. Und andere neueTechnologien
  21. 21. Was bedeutet dies fürWebarchitekturen?
  22. 22. Services zum Server!Präsentation zum Client!aus „Thin Client“ wird „Thin Server“
  23. 23. Zurück zu den AnfängenEs war einmal...Aus Fat-Clients werden Thin-Clients
  24. 24. Thin Client Architekturen
  25. 25. Daten und Repräsentationsind vermischt Browser Server
  26. 26. Daten und Repräsentationsind vermischt Name Foo ➡Datenstrukturen? ➡Datentypen? Nachname Bar Str Laufer-Str 99 Browser Server
  27. 27. Daten und Repräsentationsind vermischt Name Foo ➡Datenstrukturen? ➡Datentypen? Nachname Bar Str Laufer-Str 99 Browser Server <html> <body> <span>Name: Foo</span> ➡Daten und Repäsentation gemischt
  28. 28. Daten und Repräsentationsind vermischt Name Foo ➡Datenstrukturen? ➡Datentypen? Nachname Bar Str Laufer-Str 99 Browser Server nd lo w u scht o nsf gemi en tati sch räs ustau ➡P tena Da <html> <body> <span>Name: Foo</span> ➡Daten und Repäsentation gemischt
  29. 29. Schlechte Verteilung derArbeit Rich-Server Client berechnet das Client GUI für jeden Client Client
  30. 30. Hohe Latenz Browser GET POST POST POST Seite 1 Seite 2 Seite 3 Seite 4 Usability erfordert eine flüssige Bedienung. Herkömmliche Webapps reagieren zu langsam auf Benutzer Interaktionen.
  31. 31. Komplexität Client Code (HTML, JS, CSS) GUI Events Generate State Webframework
  32. 32. KomplexitätPräsentationslogik ist am Client undServer Client Code (HTML, JS, CSS) GUI Events Generate State Webframework
  33. 33. KomplexitätPräsentationslogik ist am Client undServer Client CodeWebframework ein Codegenerator für (HTML, JS, CSS)HTML & JS(denken in 2 Dimensionen -sehr umständlich) GUI Events Generate State Webframework
  34. 34. KomplexitätPräsentationslogik ist am Client undServer Client CodeWebframework ein Codegenerator für (HTML, JS, CSS)HTML & JS(denken in 2 Dimensionen -sehr umständlich) GUI Events GenerateHTML muss erst in Server Templatesverpackt werden State Webframework
  35. 35. KomplexitätPräsentationslogik ist am Client undServer Client CodeWebframework ein Codegenerator für (HTML, JS, CSS)HTML & JS(denken in 2 Dimensionen -sehr umständlich) GUI Events GenerateHTML muss erst in Server Templatesverpackt werdenDebugging in zwei Laufzeitumgebungen(Client/Server) State Webframework
  36. 36. KomplexitätPräsentationslogik ist am Client undServer Client CodeWebframework ein Codegenerator für (HTML, JS, CSS)HTML & JS(denken in 2 Dimensionen -sehr umständlich) GUI Events GenerateHTML muss erst in Server Templatesverpackt werdenDebugging in zwei Laufzeitumgebungen(Client/Server) StateDer meiste Code dreht sich um das WebframeworkEvent/Request Handling (Serialisierung,Protokoll quirx)
  37. 37. KomplexitätPräsentationslogik ist am Client undServer Client CodeWebframework ein Codegenerator für (HTML, JS, CSS)HTML & JS(denken in 2 Dimensionen -sehr umständlich) GUI Events GenerateHTML muss erst in Server Templatesverpackt werdenDebugging in zwei Laufzeitumgebungen(Client/Server) StateDer meiste Code dreht sich um das WebframeworkEvent/Request Handling (Serialisierung,Protokoll quirx)Korrektes State Handling unmöglich
  38. 38. Fatales Statemanagement
  39. 39. Fatales StatemanagementUI State ist am Server
  40. 40. Fatales StatemanagementUI State ist am ServerState am Client muss nicht zum Server State passen.Fehlerbehandlung hierfür ist komplex.
  41. 41. Fatales StatemanagementUI State ist am ServerState am Client muss nicht zum Server State passen.Fehlerbehandlung hierfür ist komplex.Client muss immer auf den richtigen Server geroutet werden
  42. 42. Fatales StatemanagementUI State ist am ServerState am Client muss nicht zum Server State passen.Fehlerbehandlung hierfür ist komplex.Client muss immer auf den richtigen Server geroutet werdenSkalierung und Failover ein echtes Problem (und sehr teuer)
  43. 43. Fatales StatemanagementUI State ist am ServerState am Client muss nicht zum Server State passen.Fehlerbehandlung hierfür ist komplex.Client muss immer auf den richtigen Server geroutet werdenSkalierung und Failover ein echtes Problem (und sehr teuer)Speicherverbrauch am Server (Beispiel JSF Component Tree)
  44. 44. Fatales StatemanagementUI State ist am ServerState am Client muss nicht zum Server State passen.Fehlerbehandlung hierfür ist komplex.Client muss immer auf den richtigen Server geroutet werdenSkalierung und Failover ein echtes Problem (und sehr teuer)Speicherverbrauch am Server (Beispiel JSF Component Tree)Server behelfen sich mit Sessiontimeouts (Session bleibtmeist noch 30 Minuten wenn der User bereits weg ist)
  45. 45. 5. OfflinefähigkeitEin echtes Problem...
  46. 46. 6. Fehlende Interoperabilität
  47. 47. 6. Fehlende Interoperabilität HTML Markup ist keine Schnittstelle ... GWT-RPC auch nicht
  48. 48. 6. Fehlende Interoperabilität HTML Markup ist keine Schnittstelle ... GWT-RPC auch nicht Echte Services sind sind häufig nicht von „außen“ zugreifbar (z.B. Spring Services) ... nein, man kann Sie nicht einfach zum Webservice machen! es ist ein fundamentaler Unterschied ob ein Service als WebService oder lokaler Service konzeptioniert wurde (Fehlerbehandlung, Call by Value, Granularität) Ergo: SOA Projekte müssen von 0 starten Risiko das Rad neu zu erfinden
  49. 49. 6. Fehlende Interoperabilität HTML Markup ist keine Schnittstelle ... GWT-RPC auch nicht Echte Services sind sind häufig nicht von „außen“ zugreifbar (z.B. Spring Services) ... nein, man kann Sie nicht einfach zum Webservice machen! es ist ein fundamentaler Unterschied ob ein Service als WebService oder lokaler Service konzeptioniert wurde (Fehlerbehandlung, Call by Value, Granularität) Ergo: SOA Projekte müssen von 0 starten Risiko das Rad neu zu erfinden Fehlender Fokus auf qualitative Schnittstellen („die sind ja nicht von außen erreichbar“)
  50. 50. 6. Fehlende Interoperabilität HTML Markup ist keine Schnittstelle ... GWT-RPC auch nicht Echte Services sind sind häufig nicht von „außen“ zugreifbar (z.B. Spring Services) ... nein, man kann Sie nicht einfach zum Webservice machen! es ist ein fundamentaler Unterschied ob ein Service als WebService oder lokaler Service konzeptioniert wurde (Fehlerbehandlung, Call by Value, Granularität) Ergo: SOA Projekte müssen von 0 starten Risiko das Rad neu zu erfinden Fehlender Fokus auf qualitative Schnittstellen („die sind ja nicht von außen erreichbar“) Präsentation und Geschäftslogik in einem Tier fördert das verschmelzen von beidem zu einem „Brei“
  51. 51. Symptome linderbar,aber nicht fixbar!
  52. 52. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/Conversations
  53. 53. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page Rendering
  54. 54. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page RenderingMulti Windows -> Conversations
  55. 55. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page RenderingMulti Windows -> ConversationsBrowserhistory -> Post/Redirect/Get (PRG)
  56. 56. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page RenderingMulti Windows -> ConversationsBrowserhistory -> Post/Redirect/Get (PRG)Failover -> Session Repication = BS! (Speicher, Kosten,Network Traffic..)
  57. 57. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page RenderingMulti Windows -> ConversationsBrowserhistory -> Post/Redirect/Get (PRG)Failover -> Session Repication = BS! (Speicher, Kosten,Network Traffic..)
  58. 58. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page RenderingMulti Windows -> ConversationsBrowserhistory -> Post/Redirect/Get (PRG)Failover -> Session Repication = BS! (Speicher, Kosten,Network Traffic..)Verhindert echtes Webscale!
  59. 59. Hmm, Code am Server wardoch immer eine gute IdeeJS sucks! Bowser Inkompatibilität! ...und dieSicherheit!
  60. 60. Ja, bis 2005 war das richtig Für viele hat sich die Welt seither nicht weiter gedreht Seit 2005 gibt es viel neues AJAX Browser Events CSS 2/3 JavaScript Programming Patterns (Classes,Events, DOM) jQuery DOM Positioning / Box Models
  61. 61. Und Heute? HTML5.KV/SQL-DatabaseCanvasCSS3Web WorkersWeb SocketsApplication CacheJS DOM Selector APIWEB-GL tolle neue Möglichkeiten...
  62. 62. Motivation SOFEAPräsentation an den Client (seperation of concerns)Services zum ServerSOA - Agnostische WebServicesMulti Device (Mobile, Portal, Webclient, Richclient,APIs)Webscale
  63. 63. SOFEA VogelperspektiveZuständigkeiten eines Webframeworks
  64. 64. Application Download Webserver Application Network Application- Business Logic Container
  65. 65. Presentation Flow Webserver Application Network Application- Business Logic Container
  66. 66. Data Interchange Webserver Application Network Application- Business Logic Container
  67. 67. Back to basicrichtiges 3 Tier Client HTML Renderer ModelController View Business Logic Server
  68. 68. Back to basicrichtiges 3 Tier Client Client Präsentation HTML Renderer Controller View Model Model APIController View Business Logic Business Logic Server Server
  69. 69. Back to basicrichtiges 3 Tier Client Client Präsentation HTML Renderer Controller View Model Model APIController View Business Logic Business Logic Server Server
  70. 70. Back to basicrichtiges 3 Tier Client Client Präsentation HTML Renderer Controller View Model Model APIController View Business Logic Business Logic Server Server
  71. 71. Vergleich mit JSF Lifecycle
  72. 72. und so in JavaScript: DOM 2. getElementById 1. addEventListener Event Listener Function 3. jQuery.ajax /backend
  73. 73. Die GretchenfrageThin or Rich (SPA Single Page Application) ?
  74. 74. SOFEA (Rich) ClientsNicht RESTful SOFEA verletzt das REST Prinzip HATEOAS (Hypermedia as the Engine of Application State) State ist nicht Bestandteil der URL idR. ein großer DownloadHistory und „Browser Back“ problematisch # URI Fragmente können helfen neu: Browser History APIAber: Offline fähig
  75. 75. Kompromiss:Rich Thin Clients
  76. 76. Kompromiss:Rich Thin ClientsRESTful
  77. 77. Kompromiss:Rich Thin ClientsRESTfulviele kleine Downloads
  78. 78. Kompromiss:Rich Thin ClientsRESTfulviele kleine Downloadsreduzierte Komplexität
  79. 79. Kompromiss:Rich Thin ClientsRESTfulviele kleine Downloadsreduzierte Komplexität
  80. 80. Kompromiss:Rich Thin ClientsRESTfulviele kleine Downloadsreduzierte KomplexitätAber: nicht offline fähig nicht als Mobile App geeignet Server Roundtripps bei Wechsel der URL/Resource
  81. 81. Vorteile SOFEA
  82. 82. Vorteile SOFEATrennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)
  83. 83. Vorteile SOFEATrennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)Keine Serverlatenz bei GUI Operationen
  84. 84. Vorteile SOFEATrennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)Keine Serverlatenz bei GUI OperationenHoch skalierbar Client side state management
  85. 85. Vorteile SOFEATrennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)Keine Serverlatenz bei GUI OperationenHoch skalierbar Client side state managementOfflineanwendungen
  86. 86. Vorteile SOFEATrennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)Keine Serverlatenz bei GUI OperationenHoch skalierbar Client side state managementOfflineanwendungenMobile Apps
  87. 87. Vorteile SOFEATrennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)Keine Serverlatenz bei GUI OperationenHoch skalierbar Client side state managementOfflineanwendungenMobile AppsInteroperability SOFEA fördert „echte“ und qualitative Services Backend kann in jeder Spache geschrieben sein (Ruby, JS, Java, .net...)
  88. 88. No ServersideWebframeworksHTML5 ist das Framework!
  89. 89. HTML(5) hat alles was manbrauchtJavaScript für die OberfächensteuerungDOM Selector API um die View zu manipulierenAJAX als Remote HTTP API
  90. 90. SOFEA Client Architecture View (HTML) Controller (JS) Network Service / ResourceArchitektur?!‣ein großes Javascript...‣eine HTML Seite...
  91. 91. Wohin mit dem State?JS varCookieBrowser DB / local StorageHTML5 History APIURL #
  92. 92. Rann an die APIRESTSOAPATOM/RSSComet/Ajax PushWebworker
  93. 93. Problem: Same Origin PolicyReverse ProxyJSONPHTML5 - send MessageCross-Side XMLHTTP Request (Mozilla)
  94. 94. Gut genug für einfacheAppsoder Thin Clients...
  95. 95. Aber wie würden wir Applikationenwie GMail realisieren?
  96. 96. MVP (Model View Presenter)Pattern ViewView Model Presenter Controller Model
  97. 97. SOFEA Architecture 2.0MVP + EventBus Menü Mail Chat View View View Presenter Presenter Presenter Event Bus Application Controller Network Service
  98. 98. OpenAJAX Hub Standard Client Side JavaScript Hub publish/subscribe zum schreiben von Secure Mashups Sandboxing von Mashups aktuell in Version 2OpenAjax.hub.publish("de.adorsys.urlaubsantrag.new", "2007.08.05");OpenAjax.hub.subscribe("de.adorsys.urlaubsantrag.*", function() { //hello}, this);
  99. 99. SOFEA Architecture 2.0Tests mit Mocks Mail Event Bus Mock Repository
  100. 100. SOFEA Architecture 2.0Push Event Bus Application Controller Repository Technologie Poll Network AjaxPush/Comet Long Poll Service Websockets/Webworker
  101. 101. SOFEA Architecture 2.0Offline Cache Mail Event Bus Application Controller Repository Online Repository Offline NetworkOffline Apps Lokal StoragePerformance durchCache Service
  102. 102. Scaling SOFEA Client Client Server Server
  103. 103. Scaling SOFEA Client ClientGUI Rendering am ClientKonzept: Stateless Backend REST Server Server Caching (Client/Server) einfache und „billige“ Skalierung durch zusätzliche Hardware keine (sticky) Sessions transparent Failover
  104. 104. Scaling SOFEA Client ClientGUI Rendering am ClientKonzept: Stateless Backend REST Server Server Caching (Client/Server) einfache und „billige“ Skalierung durch zusätzliche Hardware keine (sticky) Sessions transparent Failover
  105. 105. Scaling SOFEA ein neues Problem die Datenbank? Client ClientGUI Rendering am ClientKonzept: Stateless Backend REST Server Server Caching (Client/Server) einfache und „billige“ Skalierung durch zusätzliche Hardware keine (sticky) Sessions transparent Failover
  106. 106. Caching Repository OnlineRESTful HTTP ist der Schlüssel Network HTTP Client Cache (expires, E-TAG) SQID durch Infrastruktur (Reverse Proxy Cache) Serverside Service Cache Service
  107. 107. Authentication in SOFEA
  108. 108. Authentication in SOFEADie meisten Appserver präferieren Session Auth Dadurch ist Server stickiness erforderlich
  109. 109. Authentication in SOFEADie meisten Appserver präferieren Session Auth Dadurch ist Server stickiness erforderlichLösung: Security Tokens Token basierte Protokolle Eigene Protokolle OAuth OpenID
  110. 110. Funktionsweise - OAuth Token Service Client Server (IdP) Service Provider
  111. 111. Funktionsweise - OAuth 1. erzeuge Request Token Token Service Client Server (IdP) Service Provider
  112. 112. Funktionsweise - OAuth 2. Au th en tis ier er eq ues tT ok en 1. erzeuge Request Token Token Service Client Server (IdP) Service Provider
  113. 113. Funktionsweise - OAuth 2. Au th en tis ier er eq ues 3. redirect request Token tT param ok en 1. erzeuge Request Token Token Service Client Server (IdP) Service Provider
  114. 114. Funktionsweise - OAuth 2. Au th en tis ier er eq ues 3. redirect request Token tT param ok en 1. erzeuge Request Token Token Service Client Server 4. erzeuge Access Token (IdP) Service Provider
  115. 115. Funktionsweise - OAuth 2. Au th en tis ier er eq ues 3. redirect request Token tT param ok en 1. erzeuge Request Token Token Service Client Server 4. erzeuge Access Token (IdP) 5. A PI C all Service Provider
  116. 116. Funktionsweise - OAuth 2. Au th en tis ier er eq ues 3. redirect request Token tT param ok en 1. erzeuge Request Token Token Service Client Server 6. check Token 4. erzeuge Access Token (IdP) 5. A PI C all Service Provider
  117. 117. OpenSocial
  118. 118. OpenSocialUser ProfileSocial GraphAcivity StreamsGadgets
  119. 119. OpenSocial Gadget Opensocial Server Gadget Server Open Social Container get Gadget XML load Gadget Gadget App Server Open Social Server Social Graph data request REST Request Gadget Application REST API Open Social REST API
  120. 120. Write GadgetsGoogle DocsGmail - Kontext bezogene sidebar gadgets.Calendar - Gadgets für die Calendar sidebar.iGoogle - Gadgets für das Google „Portal“.
  121. 121. SOFEA für Mobile AppsNative Clients Betriebssystemabhängig (Kosten, Skills)Mobile Websites (optimierte Websites für Mobile)Hybrid Mobile Apps
  122. 122. Single Source - Hybrid Apps Phonegap/Corona Hybird HTML5 App
  123. 123. WebHooksCallbacks im Web My Service poll Payment Service
  124. 124. WebhooksDas Problem... My Service Other Service Other Service Other Service Other Service Other Service Other Service Other ServicePoll ist ineffizient poll poll pollhohe Latenz poll Payment Service
  125. 125. Webhooks - Die Lösung My Application 3. push 1. register My Service Payment Service 2. push Other Service
  126. 126. Webhooks - Die LösungAnwendungsgebiete My Application Events Notification Data Pipelining 3. push 1. register Plugins My Service Payment Service 2. push Other Service
  127. 127. Web Intends Bild auswählen My Application Bild aus Flicker übernehmen
  128. 128. Code Beispiel Web IntendsRegistrieren<intent action="http://webintents.org/share" type="image/*" href="share.html" />Feuern:var intent = new Intent("http://webintents.org/share", "text/uri-list", "http://news.bbc.co.uk");window.navigator.startActivity(intent);
  129. 129. High ScalableFull JavaScript Stack Client Client Database Mein Favorit :)
  130. 130. Vielen Dank!Sandro Sonntag Adorsys GmbH & Co KG

×