Good by Server... Hello Client!

  • 918 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
918
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • \n\n\n\n\n
  • Thema was mir am herzen liegt\nkeine Code Beispiele dafür bilder:)\nParadigmenwechsel: Fat Clients -> Thin Clients -> Richclients\nPerspektive etwas zu ändern\n\nREST Architekturstiel des Internets (REST Vortrag)\nWas tuen wir uns gerade an mit Server Side Webframework\nWas macht die Thin Server Architecture besser?\n
  • Sandro Sonntag \nFirma Adorsys\nJEE Java und Webtechnologie Umfeld, Mobile\n700m von hier B2\nSpiele gerne mal mit neuen Technologien herum. Mittlerweile vermehrt mit Webtechnologien\nJavascript (Hass/Liebe)\nTellerrand\nLarge Scale Architekturen von eBay, Amazon, Twitter und Co\nNoSql DBs\n\n\n
  • \n
  • Thema ist nicht all zu neu\n\nFokus damals auf Services für mich ist der Fokus ehr\n
  • Thema ist nicht all zu neu\n\nFokus damals auf Services für mich ist der Fokus ehr\n
  • Thema ist nicht all zu neu\n\nFokus damals auf Services für mich ist der Fokus ehr\n
  • \n
  • \n
  • 3,5 Jahre für die ersten 1000\n
  • RDF spielt offensichtlich keine Rolle :(\n
  • sind Browser die Systeme\n
  • Salesforce 50 % des Traffics durch APIs\n
  • SIPGate API bei Adorsys\n
  • \n
  • Client-Cloud Applications: The Rebirth of Client/Server Architecture \nEric Knipp, David Mitchell Smith, David W. Cearley, William Clark \n  \nSoftware engineering best practices have rebalanced over the years among monolithic, modular, and object- and service-oriented. A classic "centralization versus decentralization" battle has played out repeatedly as the pendulum swung from "big iron" to "big client" and back again. This dynamic, alongside the emergence of cloud computing and the proliferation of powerful new computing devices, is leading to the client-cloud application style, which borrows from and improves client/server architecture. \n  \nKey Findings \n·     In the next-generation client/server architecture, the "client" is a rich application running on an Internet-connected device, and the "server" is a set of application services hosted in an increasingly elastically scalable cloud computing platform. \n·     Applications consume increasing amounts of server-side computing and storage capacity to satisfy the increasingly complex demands of Web users, but the shift toward usage-metered cloud services, increased demand on networks, robust capabilities of handheld devices and the need to manage bandwidth use on these devices create incentives to minimize the Web application computing and storage footprint, and exploit the intelligence and storage of the client device. \n·     Internet-connected machines continue to decline in cost while growing more powerful, and a growing set of rich application containers offers an opportunity to tap into this power, potentially offloading work from costly servers to user-financed client devices. \n·     Unlike the earlier client/server era, in the cloud-client era, the application elements and data on the client device will generally be installed, managed and mirrored from the cloud services platform through an app store or marketplaces, reducing the complexity and cost of managing the client environment. \n
  • \n
  • \n
  • Alle Rechte vorbehalten von samsungtomorrow\n
  • \n
  • Stichwort Serviceprovider\nStichwort Mashups\n\n
  • Frage: Wer hat Spaß mit dem Programmiermodel heutiger Mainstream Webframeworks?\n Alle Rechte vorbehalten von Johannes Jansson\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Browsernavigation\nunsave Operations (POST)\nState?\n
  • Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung führen häufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks müssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
  • Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung führen häufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks müssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
  • Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung führen häufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks müssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
  • Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung führen häufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks müssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
  • Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung führen häufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks müssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
  • Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung führen häufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks müssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
  • Beispiel Browser back\nBeispiel Multi window\n
  • Beispiel Browser back\nBeispiel Multi window\n
  • Beispiel Browser back\nBeispiel Multi window\n
  • Beispiel Browser back\nBeispiel Multi window\n
  • Beispiel Browser back\nBeispiel Multi window\n
  • Beispiel Browser back\nBeispiel Multi window\n
  • \n
  • Die Geschichte von SEAM und Co. Entity Manager bla\n
  • Die Geschichte von SEAM und Co. Entity Manager bla\n
  • Die Geschichte von SEAM und Co. Entity Manager bla\n
  • Die Geschichte von SEAM und Co. Entity Manager bla\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Beispiel WebGL\n
  • Achtung es gibt noch eine Folie zu den Vorteilen\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • http://en.wikipedia.org/wiki/Single-page_application\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • http://www.techcrunchit.com/2010/03/24/five-reasons-opensocial-will-change-the-enterprise/\n\n\n
  • \n
  • http://code.google.com/intl/de-DE/apis/gadgets/\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Transcript

  • 1. Good by Server... Welcome Client!SOFEA - ein leichtgewichtiger Architekturansatz Sandro Sonntag Adorsys GmbH & Co. KG
  • 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. Ü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. Ursprünge SOFEA
  • 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. 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. 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. einige Trends
  • 9. Jobtrends - HTML5 und Co.
  • 10. 1000 APIs in 9 Monaten
  • 11. SchnittstellenREST und JSON auf dem Vormarsch
  • 12. 1 in 5 APIs Say “Bye XML”
  • 13. 13 milliarden API calls / tagSalesforce 50 % des Traffics durch APIs
  • 14. Anzahl der open API‘s wächst
  • 15. Twitter Saw 600K SignupsYesterday, It Took More Than 16Months To Reach Its First 600K
  • 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. Chrome OSDer Browser als Betriebssystem
  • 18. Aber was ist der Auslöser?
  • 19. Mobile, Smart Pads, iTV,Social Media, DesktopWidgets and smarterWebapps
  • 20. Und andere neueTechnologien
  • 21. Was bedeutet dies fürWebarchitekturen?
  • 22. Services zum Server!Präsentation zum Client!aus „Thin Client“ wird „Thin Server“
  • 23. Zurück zu den AnfängenEs war einmal...Aus Fat-Clients werden Thin-Clients
  • 24. Thin Client Architekturen
  • 25. Daten und Repräsentationsind vermischt Browser Server
  • 26. Daten und Repräsentationsind vermischt Name Foo ➡Datenstrukturen? ➡Datentypen? Nachname Bar Str Laufer-Str 99 Browser Server
  • 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. 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. Schlechte Verteilung derArbeit Rich-Server Client berechnet das Client GUI für jeden Client Client
  • 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. Komplexität Client Code (HTML, JS, CSS) GUI Events Generate State Webframework
  • 32. KomplexitätPräsentationslogik ist am Client undServer Client Code (HTML, JS, CSS) GUI Events Generate State Webframework
  • 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. 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. 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. 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. 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. Fatales Statemanagement
  • 39. Fatales StatemanagementUI State ist am Server
  • 40. Fatales StatemanagementUI State ist am ServerState am Client muss nicht zum Server State passen.Fehlerbehandlung hierfür ist komplex.
  • 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. 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. 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. 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. 5. OfflinefähigkeitEin echtes Problem...
  • 46. 6. Fehlende Interoperabilität
  • 47. 6. Fehlende Interoperabilität HTML Markup ist keine Schnittstelle ... GWT-RPC auch nicht
  • 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. 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. 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. Symptome linderbar,aber nicht fixbar!
  • 52. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/Conversations
  • 53. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page Rendering
  • 54. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page RenderingMulti Windows -> Conversations
  • 55. Symptome linderbar,aber nicht fixbar!Zustand -> HTTPSession/ConversationsAJAX Feeling -> Partitial Page RenderingMulti Windows -> ConversationsBrowserhistory -> Post/Redirect/Get (PRG)
  • 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. 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. 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. Hmm, Code am Server wardoch immer eine gute IdeeJS sucks! Bowser Inkompatibilität! ...und dieSicherheit!
  • 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. Und Heute? HTML5.KV/SQL-DatabaseCanvasCSS3Web WorkersWeb SocketsApplication CacheJS DOM Selector APIWEB-GL tolle neue Möglichkeiten...
  • 62. Motivation SOFEAPräsentation an den Client (seperation of concerns)Services zum ServerSOA - Agnostische WebServicesMulti Device (Mobile, Portal, Webclient, Richclient,APIs)Webscale
  • 63. SOFEA VogelperspektiveZuständigkeiten eines Webframeworks
  • 64. Application Download Webserver Application Network Application- Business Logic Container
  • 65. Presentation Flow Webserver Application Network Application- Business Logic Container
  • 66. Data Interchange Webserver Application Network Application- Business Logic Container
  • 67. Back to basicrichtiges 3 Tier Client HTML Renderer ModelController View Business Logic Server
  • 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. Back to basicrichtiges 3 Tier Client Client Präsentation HTML Renderer Controller View Model Model APIController View Business Logic Business Logic Server Server
  • 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. Vergleich mit JSF Lifecycle
  • 72. und so in JavaScript: DOM 2. getElementById 1. addEventListener Event Listener Function 3. jQuery.ajax /backend
  • 73. Die GretchenfrageThin or Rich (SPA Single Page Application) ?
  • 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. Kompromiss:Rich Thin Clients
  • 76. Kompromiss:Rich Thin ClientsRESTful
  • 77. Kompromiss:Rich Thin ClientsRESTfulviele kleine Downloads
  • 78. Kompromiss:Rich Thin ClientsRESTfulviele kleine Downloadsreduzierte Komplexität
  • 79. Kompromiss:Rich Thin ClientsRESTfulviele kleine Downloadsreduzierte Komplexität
  • 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. Vorteile SOFEA
  • 82. Vorteile SOFEATrennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)
  • 83. Vorteile SOFEATrennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)Keine Serverlatenz bei GUI Operationen
  • 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. 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. 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. 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. No ServersideWebframeworksHTML5 ist das Framework!
  • 89. HTML(5) hat alles was manbrauchtJavaScript für die OberfächensteuerungDOM Selector API um die View zu manipulierenAJAX als Remote HTTP API
  • 90. SOFEA Client Architecture View (HTML) Controller (JS) Network Service / ResourceArchitektur?!‣ein großes Javascript...‣eine HTML Seite...
  • 91. Wohin mit dem State?JS varCookieBrowser DB / local StorageHTML5 History APIURL #
  • 92. Rann an die APIRESTSOAPATOM/RSSComet/Ajax PushWebworker
  • 93. Problem: Same Origin PolicyReverse ProxyJSONPHTML5 - send MessageCross-Side XMLHTTP Request (Mozilla)
  • 94. Gut genug für einfacheAppsoder Thin Clients...
  • 95. Aber wie würden wir Applikationenwie GMail realisieren?
  • 96. MVP (Model View Presenter)Pattern ViewView Model Presenter Controller Model
  • 97. SOFEA Architecture 2.0MVP + EventBus Menü Mail Chat View View View Presenter Presenter Presenter Event Bus Application Controller Network Service
  • 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. SOFEA Architecture 2.0Tests mit Mocks Mail Event Bus Mock Repository
  • 100. SOFEA Architecture 2.0Push Event Bus Application Controller Repository Technologie Poll Network AjaxPush/Comet Long Poll Service Websockets/Webworker
  • 101. SOFEA Architecture 2.0Offline Cache Mail Event Bus Application Controller Repository Online Repository Offline NetworkOffline Apps Lokal StoragePerformance durchCache Service
  • 102. Scaling SOFEA Client Client Server Server
  • 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. 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. 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. 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. Authentication in SOFEA
  • 108. Authentication in SOFEADie meisten Appserver präferieren Session Auth Dadurch ist Server stickiness erforderlich
  • 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. Funktionsweise - OAuth Token Service Client Server (IdP) Service Provider
  • 111. Funktionsweise - OAuth 1. erzeuge Request Token Token Service Client Server (IdP) Service Provider
  • 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. 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. 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. 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. 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. OpenSocial
  • 118. OpenSocialUser ProfileSocial GraphAcivity StreamsGadgets
  • 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. Write GadgetsGoogle DocsGmail - Kontext bezogene sidebar gadgets.Calendar - Gadgets für die Calendar sidebar.iGoogle - Gadgets für das Google „Portal“.
  • 121. SOFEA für Mobile AppsNative Clients Betriebssystemabhängig (Kosten, Skills)Mobile Websites (optimierte Websites für Mobile)Hybrid Mobile Apps
  • 122. Single Source - Hybrid Apps Phonegap/Corona Hybird HTML5 App
  • 123. WebHooksCallbacks im Web My Service poll Payment Service
  • 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. Webhooks - Die Lösung My Application 3. push 1. register My Service Payment Service 2. push Other Service
  • 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. Web Intends Bild auswählen My Application Bild aus Flicker übernehmen
  • 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. High ScalableFull JavaScript Stack Client Client Database Mein Favorit :)
  • 130. Vielen Dank!Sandro Sonntag Adorsys GmbH & Co KG