Good by Server... Hello Client!
0 gefällt mir1,079 aufrufe
Das Dokument beschreibt das Konzept der 'Sofea'-Architektur, die einen leichtgewichtigen Ansatz für die Webentwicklung darstellt, indem sie die Trennung von Präsentation und Geschäftslogik fördert und die Serverlatenz bei Benutzerinteraktionen reduziert. Es werden Trends und Herausforderungen moderner Webarchitekturen diskutiert, einschließlich der Notwendigkeit für API-Integration und der Nutzung von HTML5 und JavaScript. Außerdem werden die Vorteile des Thin Server-Ansatzes hervorgehoben, darunter bessere Skalierbarkeit, Offline-Funktionalität und Interoperabilität.
Good by Server... Hello Client!
- 1. Good by Server... Welcome Client! SOFEA - ein leichtgewichtiger Architekturansatz Sandro Sonntag Adorsys GmbH & Co. KG
- 2. Thin Server Architektur Web API‘s Entwicklung des Webs REST Inhalt Web-Technologien Potenziale Was hat HTML5 Was ist falsch an Rich mit Architektur zu tun? Server? Best Practices
- 3. Über mich Sandro Sonntag Java Eetwickler - 10 Jahre Java Erfahrung in Enterprise Umfeld Liebe zu Webtechnologien und Webscale Themen Wie REST, JavaScript/Node.JS, Mongo, Couch, Appengine Technical Lead bei Adorsys Unterwegs als Berater und Softwarearchitekt (CPSA) https://www.xing.com/profile/Sandro_Sonntag
- 5. Ursprünge SOFEA 2007 Publikation des Papiers „Live above the Service Tier“ „How to Build Application Front-ends in a Service-Oriented World“ durch Ganesh Prasad, Rajat Taneja, Vikrant Todankar
- 6. Ursprünge SOFEA 2007 Publikation des Papiers „Live above the Service Tier“ „How to Build Application Front-ends in a Service-Oriented World“ durch Ganesh Prasad, Rajat Taneja, Vikrant Todankar Parallel SOUI Publikation - Service Oriented User Interface „MVC is Dead“ Norlan Wright
- 7. Ursprünge SOFEA 2007 Publikation des Papiers „Live above the Service Tier“ „How to Build Application Front-ends in a Service-Oriented World“ durch Ganesh Prasad, Rajat Taneja, Vikrant Todankar Parallel SOUI Publikation - Service Oriented User Interface „MVC is Dead“ Norlan Wright Andere geläufige Bezeichnung: „Thin Server Architecture“
- 9. Jobtrends - HTML5 und Co.
- 10. 1000 APIs in 9 Monaten
- 11. Schnittstellen REST und JSON auf dem Vormarsch
- 12. 1 in 5 APIs Say “Bye XML”
- 13. 13 milliarden API calls / tag Salesforce 50 % des Traffics durch APIs
- 14. Anzahl der open API‘s wächst
- 15. Twitter Saw 600K Signups Yesterday, It Took More Than 16 Months To Reach Its First 600K
- 16. Gartner 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.
- 17. Chrome OS Der Browser als Betriebssystem
- 18. Aber was ist der Auslöser?
- 19. Mobile, Smart Pads, iTV, Social Media, Desktop Widgets and smarter Webapps
- 21. Was bedeutet dies für Webarchitekturen?
- 22. Services zum Server! Präsentation zum Client! aus „Thin Client“ wird „Thin Server“
- 23. Zurück zu den Anfängen Es war einmal... Aus Fat-Clients werden Thin-Clients
- 25. Daten und Repräsentation sind vermischt Browser Server
- 26. Daten und Repräsentation sind vermischt Name Foo ➡Datenstrukturen? ➡Datentypen? Nachname Bar Str Laufer-Str 99 Browser Server
- 27. Daten und Repräsentation sind 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äsentation sind 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 der Arbeit 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ät Präsentationslogik ist am Client und Server Client Code (HTML, JS, CSS) GUI Events Generate State Webframework
- 33. Komplexität Präsentationslogik ist am Client und Server Client Code Webframework ein Codegenerator für (HTML, JS, CSS) HTML & JS(denken in 2 Dimensionen - sehr umständlich) GUI Events Generate State Webframework
- 34. Komplexität Präsentationslogik ist am Client und Server Client Code Webframework ein Codegenerator für (HTML, JS, CSS) HTML & JS(denken in 2 Dimensionen - sehr umständlich) GUI Events Generate HTML muss erst in Server Templates verpackt werden State Webframework
- 35. Komplexität Präsentationslogik ist am Client und Server Client Code Webframework ein Codegenerator für (HTML, JS, CSS) HTML & JS(denken in 2 Dimensionen - sehr umständlich) GUI Events Generate HTML muss erst in Server Templates verpackt werden Debugging in zwei Laufzeitumgebungen (Client/Server) State Webframework
- 36. Komplexität Präsentationslogik ist am Client und Server Client Code Webframework ein Codegenerator für (HTML, JS, CSS) HTML & JS(denken in 2 Dimensionen - sehr umständlich) GUI Events Generate HTML muss erst in Server Templates verpackt werden Debugging in zwei Laufzeitumgebungen (Client/Server) State Der meiste Code dreht sich um das Webframework Event/Request Handling (Serialisierung, Protokoll quirx)
- 37. Komplexität Präsentationslogik ist am Client und Server Client Code Webframework ein Codegenerator für (HTML, JS, CSS) HTML & JS(denken in 2 Dimensionen - sehr umständlich) GUI Events Generate HTML muss erst in Server Templates verpackt werden Debugging in zwei Laufzeitumgebungen (Client/Server) State Der meiste Code dreht sich um das Webframework Event/Request Handling (Serialisierung, Protokoll quirx) Korrektes State Handling unmöglich
- 39. Fatales Statemanagement UI State ist am Server
- 40. Fatales Statemanagement UI State ist am Server State am Client muss nicht zum Server State passen. Fehlerbehandlung hierfür ist komplex.
- 41. Fatales Statemanagement UI State ist am Server State am Client muss nicht zum Server State passen. Fehlerbehandlung hierfür ist komplex. Client muss immer auf den richtigen Server geroutet werden
- 42. Fatales Statemanagement UI State ist am Server State am Client muss nicht zum Server State passen. Fehlerbehandlung hierfür ist komplex. Client muss immer auf den richtigen Server geroutet werden Skalierung und Failover ein echtes Problem (und sehr teuer)
- 43. Fatales Statemanagement UI State ist am Server State am Client muss nicht zum Server State passen. Fehlerbehandlung hierfür ist komplex. Client muss immer auf den richtigen Server geroutet werden Skalierung und Failover ein echtes Problem (und sehr teuer) Speicherverbrauch am Server (Beispiel JSF Component Tree)
- 44. Fatales Statemanagement UI State ist am Server State am Client muss nicht zum Server State passen. Fehlerbehandlung hierfür ist komplex. Client muss immer auf den richtigen Server geroutet werden Skalierung und Failover ein echtes Problem (und sehr teuer) Speicherverbrauch am Server (Beispiel JSF Component Tree) Server behelfen sich mit Sessiontimeouts (Session bleibt meist noch 30 Minuten wenn der User bereits weg ist)
- 45. 5. Offlinefähigkeit Ein echtes Problem...
- 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/Conversations AJAX Feeling -> Partitial Page Rendering
- 54. Symptome linderbar, aber nicht fixbar! Zustand -> HTTPSession/Conversations AJAX Feeling -> Partitial Page Rendering Multi Windows -> Conversations
- 55. Symptome linderbar, aber nicht fixbar! Zustand -> HTTPSession/Conversations AJAX Feeling -> Partitial Page Rendering Multi Windows -> Conversations Browserhistory -> Post/Redirect/Get (PRG)
- 56. Symptome linderbar, aber nicht fixbar! Zustand -> HTTPSession/Conversations AJAX Feeling -> Partitial Page Rendering Multi Windows -> Conversations Browserhistory -> Post/Redirect/Get (PRG) Failover -> Session Repication = BS! (Speicher, Kosten, Network Traffic..)
- 57. Symptome linderbar, aber nicht fixbar! Zustand -> HTTPSession/Conversations AJAX Feeling -> Partitial Page Rendering Multi Windows -> Conversations Browserhistory -> Post/Redirect/Get (PRG) Failover -> Session Repication = BS! (Speicher, Kosten, Network Traffic..)
- 58. Symptome linderbar, aber nicht fixbar! Zustand -> HTTPSession/Conversations AJAX Feeling -> Partitial Page Rendering Multi Windows -> Conversations Browserhistory -> Post/Redirect/Get (PRG) Failover -> Session Repication = BS! (Speicher, Kosten, Network Traffic..) Verhindert echtes Webscale!
- 59. Hmm, Code am Server war doch immer eine gute Idee JS sucks! Bowser Inkompatibilität! ...und die Sicherheit!
- 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-Database Canvas CSS3 Web Workers Web Sockets Application Cache JS DOM Selector API WEB-GL tolle neue Möglichkeiten...
- 62. Motivation SOFEA Präsentation an den Client (seperation of concerns) Services zum Server SOA - Agnostische WebServices Multi Device (Mobile, Portal, Webclient, Richclient, APIs) Webscale
- 63. SOFEA Vogelperspektive Zustä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 basic richtiges 3 Tier Client HTML Renderer Model Controller View Business Logic Server
- 68. Back to basic richtiges 3 Tier Client Client Präsentation HTML Renderer Controller View Model Model API Controller View Business Logic Business Logic Server Server
- 69. Back to basic richtiges 3 Tier Client Client Präsentation HTML Renderer Controller View Model Model API Controller View Business Logic Business Logic Server Server
- 70. Back to basic richtiges 3 Tier Client Client Präsentation HTML Renderer Controller View Model Model API Controller 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 Gretchenfrage Thin or Rich (SPA Single Page Application) ?
- 74. SOFEA (Rich) Clients Nicht RESTful SOFEA verletzt das REST Prinzip HATEOAS (Hypermedia as the Engine of Application State) State ist nicht Bestandteil der URL idR. ein großer Download History und „Browser Back“ problematisch # URI Fragmente können helfen neu: Browser History API Aber: Offline fähig
- 77. Kompromiss: Rich Thin Clients RESTful viele kleine Downloads
- 78. Kompromiss: Rich Thin Clients RESTful viele kleine Downloads reduzierte Komplexität
- 79. Kompromiss: Rich Thin Clients RESTful viele kleine Downloads reduzierte Komplexität
- 80. Kompromiss: Rich Thin Clients RESTful viele kleine Downloads reduzierte Komplexität Aber: nicht offline fähig nicht als Mobile App geeignet Server Roundtripps bei Wechsel der URL/Resource
- 81. Vorteile SOFEA
- 82. Vorteile SOFEA Trennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client)
- 83. Vorteile SOFEA Trennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client) Keine Serverlatenz bei GUI Operationen
- 84. Vorteile SOFEA Trennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client) Keine Serverlatenz bei GUI Operationen Hoch skalierbar Client side state management
- 85. Vorteile SOFEA Trennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client) Keine Serverlatenz bei GUI Operationen Hoch skalierbar Client side state management Offlineanwendungen
- 86. Vorteile SOFEA Trennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client) Keine Serverlatenz bei GUI Operationen Hoch skalierbar Client side state management Offlineanwendungen Mobile Apps
- 87. Vorteile SOFEA Trennung zwischen Präsentation und Geschäftslogik Aufgeräumtes Programmiermodell (GUI läuft am Client) Keine Serverlatenz bei GUI Operationen Hoch skalierbar Client side state management Offlineanwendungen Mobile Apps Interoperability SOFEA fördert „echte“ und qualitative Services Backend kann in jeder Spache geschrieben sein (Ruby, JS, Java, .net...)
- 88. No Serverside Webframeworks HTML5 ist das Framework!
- 89. HTML(5) hat alles was man braucht JavaScript für die Oberfächensteuerung DOM Selector API um die View zu manipulieren AJAX als Remote HTTP API
- 90. SOFEA Client Architecture View (HTML) Controller (JS) Network Service / Resource Architektur?! ‣ein großes Javascript... ‣eine HTML Seite...
- 91. Wohin mit dem State? JS var Cookie Browser DB / local Storage HTML5 History API URL #
- 92. Rann an die API REST SOAP ATOM/RSS Comet/Ajax Push Webworker
- 93. Problem: Same Origin Policy Reverse Proxy JSONP HTML5 - send Message Cross-Side XMLHTTP Request (Mozilla)
- 94. Gut genug für einfache Apps oder Thin Clients...
- 95. Aber wie würden wir Applikationen wie GMail realisieren?
- 96. MVP (Model View Presenter) Pattern View View Model Presenter Controller Model
- 97. SOFEA Architecture 2.0 MVP + 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 2 OpenAjax.hub.publish("de.adorsys.urlaubsantrag.new", "2007.08.05"); OpenAjax.hub.subscribe("de.adorsys.urlaubsantrag.*", function() { //hello }, this);
- 99. SOFEA Architecture 2.0 Tests mit Mocks Mail Event Bus Mock Repository
- 100. SOFEA Architecture 2.0 Push Event Bus Application Controller Repository Technologie Poll Network AjaxPush/Comet Long Poll Service Websockets/Webworker
- 101. SOFEA Architecture 2.0 Offline Cache Mail Event Bus Application Controller Repository Online Repository Offline Network Offline Apps Lokal Storage Performance durch Cache Service
- 102. Scaling SOFEA Client Client Server Server
- 103. Scaling SOFEA Client Client GUI Rendering am Client Konzept: 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 Client GUI Rendering am Client Konzept: 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 Client GUI Rendering am Client Konzept: Stateless Backend REST Server Server Caching (Client/Server) einfache und „billige“ Skalierung durch zusätzliche Hardware keine (sticky) Sessions transparent Failover
- 106. Caching Repository Online RESTful HTTP ist der Schlüssel Network HTTP Client Cache (expires, E-TAG) SQID durch Infrastruktur (Reverse Proxy Cache) Serverside Service Cache Service
- 108. Authentication in SOFEA Die meisten Appserver präferieren Session Auth Dadurch ist Server stickiness erforderlich
- 109. Authentication in SOFEA Die meisten Appserver präferieren Session Auth Dadurch ist Server stickiness erforderlich Lö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. OpenSocial User Profile Social Graph Acivity Streams Gadgets
- 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 Gadgets Google Docs Gmail - Kontext bezogene sidebar gadgets. Calendar - Gadgets für die Calendar sidebar. iGoogle - Gadgets für das Google „Portal“.
- 121. SOFEA für Mobile Apps Native 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. WebHooks Callbacks im Web My Service poll Payment Service
- 124. Webhooks Das Problem... My Service Other Service Other Service Other Service Other Service Other Service Other Service Other Service Poll ist ineffizient poll poll poll hohe 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ösung Anwendungsgebiete 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 Intends Registrieren <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 Scalable Full JavaScript Stack Client Client Database Mein Favorit :)
- 130. Vielen Dank! Sandro Sonntag Adorsys GmbH & Co KG
Hinweis der Redaktion
- #2: \n\n\n\n\n
- #3: Thema was mir am herzen liegt\nkeine Code Beispiele daf&#xFC;r bilder:)\nParadigmenwechsel: Fat Clients -> Thin Clients -> Richclients\nPerspektive etwas zu &#xE4;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
- #4: 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
- #5: \n
- #6: Thema ist nicht all zu neu\n\nFokus damals auf Services f&#xFC;r mich ist der Fokus ehr\n
- #7: Thema ist nicht all zu neu\n\nFokus damals auf Services f&#xFC;r mich ist der Fokus ehr\n
- #8: Thema ist nicht all zu neu\n\nFokus damals auf Services f&#xFC;r mich ist der Fokus ehr\n
- #9: \n
- #10: \n
- #11: 3,5 Jahre f&#xFC;r die ersten 1000\n
- #12: RDF spielt offensichtlich keine Rolle :(\n
- #13: sind Browser die Systeme\n
- #14: Salesforce 50 % des Traffics durch APIs\n
- #15: SIPGate API bei Adorsys\n
- #16: \n
- #17: Client-Cloud Applications: The Rebirth of Client/Server Architecture \nEric Knipp, David Mitchell Smith, David W. Cearley, William Clark \n&#xA0; \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&#xA0; \nKey Findings \n&#xB7; &#xA0; &#xA0; 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&#xB7; &#xA0; &#xA0; 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&#xB7; &#xA0; &#xA0; 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&#xB7; &#xA0; &#xA0; 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
- #18: \n
- #19: \n
- #20: Alle Rechte vorbehalten von samsungtomorrow\n
- #21: \n
- #22: Stichwort Serviceprovider\nStichwort Mashups\n\n
- #23: Frage: Wer hat Spa&#xDF; mit dem Programmiermodel heutiger Mainstream Webframeworks?\n Alle Rechte vorbehalten von Johannes Jansson\n
- #24: \n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: \n
- #34: Browsernavigation\nunsave Operations (POST)\nState?\n
- #35: Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
- #36: Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
- #37: Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
- #38: Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
- #39: Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
- #40: Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
- #41: Beispiel Browser back\nBeispiel Multi window\n
- #42: Beispiel Browser back\nBeispiel Multi window\n
- #43: Beispiel Browser back\nBeispiel Multi window\n
- #44: Beispiel Browser back\nBeispiel Multi window\n
- #45: Beispiel Browser back\nBeispiel Multi window\n
- #46: Beispiel Browser back\nBeispiel Multi window\n
- #47: \n
- #48: Die Geschichte von SEAM und Co. Entity Manager bla\n
- #49: Die Geschichte von SEAM und Co. Entity Manager bla\n
- #50: Die Geschichte von SEAM und Co. Entity Manager bla\n
- #51: Die Geschichte von SEAM und Co. Entity Manager bla\n
- #52: \n
- #53: \n
- #54: \n
- #55: \n
- #56: \n
- #57: \n
- #58: \n
- #59: \n
- #60: \n
- #61: Beispiel WebGL\n
- #62: Achtung es gibt noch eine Folie zu den Vorteilen\n
- #63: \n
- #64: \n
- #65: \n
- #66: \n
- #67: \n
- #68: \n
- #69: \n
- #70: \n
- #71: \n
- #72: http://en.wikipedia.org/wiki/Single-page_application\n
- #73: \n
- #74: \n
- #75: \n
- #76: \n
- #77: \n
- #78: \n
- #79: \n
- #80: \n
- #81: \n
- #82: \n
- #83: \n
- #84: \n
- #85: \n
- #86: \n
- #87: \n
- #88: \n
- #89: \n
- #90: \n
- #91: \n
- #92: \n
- #93: \n
- #94: \n
- #95: \n
- #96: \n
- #97: \n
- #98: \n
- #99: \n
- #100: \n
- #101: \n
- #102: \n
- #103: \n
- #104: \n
- #105: \n
- #106: \n
- #107: \n
- #108: \n
- #109: \n
- #110: \n
- #111: \n
- #112: \n
- #113: http://www.techcrunchit.com/2010/03/24/five-reasons-opensocial-will-change-the-enterprise/\n\n\n
- #114: \n
- #115: http://code.google.com/intl/de-DE/apis/gadgets/\n
- #116: \n
- #117: \n
- #118: \n
- #119: \n
- #120: \n
- #121: \n
- #122: \n
- #123: \n
- #124: \n