Downloaden Sie, um offline zu lesen
Hochgeladen vonJohann-Peter Hartmann
Paradigmenwechsel bei webapplikationen
Das Dokument beschreibt die Entwicklungen und Trends der Softwarearchitektur bei der Mayflower GmbH von 2005 bis 2009, einschließlich verschiedener Präsentationsschichten, Business-Logik und Datenbank-Technologien. Es thematisiert zudem die zukünftigen Plattformen für Rich Internet Applications (RIA) und die Integration von externen Services in Form von Service-Cloud. Der Fokus liegt auf der Flexibilität, Anpassungsfähigkeit und der Wiederverwendbarkeit von Komponenten, wobei JavaScript als die bevorzugte Programmiersprache hervorgehoben wird.
Weitere ähnliche Inhalte
Ähnlich wie Paradigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationen
- 1. Die Applikation ist ein Netz Mayflower GmbH 2009
- 2. Johann-Peter Hartmann 20% 80% Manager Hacker Mayflower GmbH 2009
- 3. Amoeba There is noSpoon Desktop PC Mayflower GmbH 2009
- 4. Präsentationsschicht Business-Logik Datenbank Mayflower GmbH 2005
- 5. Präsentationsschicht HTML Business-Logik PHP / Ruby / python Datenbank Oracle / MySQL Mayflower GmbH 2005
- 6. Präsentationsschicht HTML Business-Logik PHP / Ruby / python Datenbank Oracle / MySQL Mayflower GmbH 2005
- 7. Trend 1 Mayflower GmbH 2009
- 8. Trend 1 Mayflower GmbH 2009
- 9. Trend 1 Mayflower GmbH 2009
- 10. Trend 1 Mayflower GmbH 2009
- 11. Trend 1 Mayflower GmbH 2009
- 12. Trend 1 Mayflower GmbH 2009
- 13. Trend 1 Mayflower GmbH 2009
- 14. Trend 1 Mayflower GmbH 2009
- 15. Trend II Präsentationsschicht Business-Logik Datenbank Mayflower GmbH 2009
- 16. Trend II Präsentationsschicht Ajax Business-Logik Datenbank Mayflower GmbH 2009
- 17. Trend II Präsentationsschicht Ajax Business-Logik Datenbank Mayflower GmbH 2009
- 18. Trend II Präsentationsschicht Ajax Business-Logik Datenbank Mayflower GmbH 2009
- 19. Trend II Präsentationsschicht Ajax Business-Logik Datenbank Mayflower GmbH 2009
- 20. Präsentationsschicht Business-Logik Datenbank Mayflower GmbH 2009
- 21. Präsentationsschicht Business-Logik Business-Logik Business-Logik Datenbank Datenbank Datenbank Mayflower GmbH 2009
- 22. SOA Präsentationsschicht Business-Logik Business-Logik Business-Logik Datenbank Datenbank Datenbank Mayflower GmbH 2009
- 23. Architekturwechsel Präsentationsschicht Server-Side Präsentationsschicht Business-Logik Business-Logik Business-Logik Datenbank Datenbank Datenbank Mayflower GmbH 2009
- 24. Architekturwechsel JS-Applikation Service Service Service Business-Logik Business-Logik Business-Logik Datenbank Datenbank Datenbank Mayflower GmbH 2009
- 25. Architekturwechsel Eigene Browserapplikation Fremd Service Service Service Business-Logik Business-Logik Business-Logik Datenbank Datenbank Datenbank Mayflower GmbH 2009
- 26. Architekturwechsel Eigene Browserapplikation Fremd Service Service Service extern Business-Logik Business-Logik Business-Logik extern Datenbank Datenbank Datenbank extern Mayflower GmbH 2009
- 27. 2-Tier Web Application Fremde Eigene Browserapplikation Applikation Rich Internet Application Externe Services Eigene Services Service-Cloud Mayflower GmbH 2009
- 28. Wo ist derCode? Präsentationsschicht Business-Logik Datenbank Mayflower GmbH 2009
- 29. Wo ist derCode? Präsentationsschicht Business-Logik Datenbank Mayflower GmbH 2009
- 30. Wo ist derCode heute? Fremde Eigene Browserapplikation Applikation Rich Internet Application Externe Services Eigene Services Service-Cloud Mayflower GmbH 2009
- 31. Wo ist derCode heute? Fremde Eigene Browserapplikation Applikation Rich Internet Application Externe Services Eigene Services Service-Cloud Mayflower GmbH 2009
- 32. Wo ist derCode heute? Fremde Eigene Browserapplikation Applikation Rich Internet Application Externe Services Eigene Services Service-Cloud Mayflower GmbH 2009
- 33. Wo ist derCode heute? Fremde Eigene Browserapplikation Applikation Rich Internet Application Externe Services Eigene Services Service-Cloud Mayflower GmbH 2009
- 34. Wo ist derCode heute? Fremde Eigene Browserapplikation Applikation Rich Internet Application Externe Services Eigene Services Service-Cloud Mayflower GmbH 2009
- 35. RIA-Layer • Ist derKern der Applikation Mayflower GmbH 2009
- 36. RIA-Layer • Ist derKern der Applikation • User Interface und Interaction Mayflower GmbH 2009
- 37. RIA-Layer • Ist derKern der Applikation • User Interface und Interaction • Workflowsteuerung Mayflower GmbH 2009
- 38. RIA-Layer • Ist derKern der Applikation • User Interface und Interaction • Workflowsteuerung • Glue-Code-Layer für Services Mayflower GmbH 2009
- 39. RIA-Layer • Ist derKern der Applikation • User Interface und Interaction • Workflowsteuerung • Glue-Code-Layer für Services • Impliziter Deploy Mayflower GmbH 2009
- 40. RIA-Layer • Ist derKern der Applikation • User Interface und Interaction • Workflowsteuerung • Glue-Code-Layer für Services • Impliziter Deploy • Plattform- und Fehlertolerant Mayflower GmbH 2009
- 41. RIA-Plattformen • Der Kandidatfür die Plattform der Zukunft ... Mayflower GmbH 2009
- 42. RIA-Plattformen • Der Kandidatfür die Plattform der Zukunft ... • Microsoft: SilverLight Mayflower GmbH 2009
- 43. RIA-Plattformen • Der Kandidatfür die Plattform der Zukunft ... • Microsoft: SilverLight • Adobe: AIR / Flex Mayflower GmbH 2009
- 44. RIA-Plattformen • Der Kandidatfür die Plattform der Zukunft ... • Microsoft: SilverLight • Adobe: AIR / Flex • Sun: JavaFX Mayflower GmbH 2009
- 45. RIA-Plattformen • Der Kandidatfür die Plattform der Zukunft ... • Microsoft: SilverLight • Adobe: AIR / Flex • Sun: JavaFX • and the Winner is: JavaScript! Mayflower GmbH 2009
- 46. Google Chrome OS Mayflower GmbH 2009
- 47. MashWare-IDEs • Google MashUpEditor • IBM Mashup Center + Project Zero • Intel Mash Maker • MicroSoft PopFly • Yahoo Pipes Mayflower GmbH 2009
- 48.
- 49. Service-Cloud • SaaS? SOA?Amazon EC2? • Es ist gleich, wo der Service herkommt • ... solange er folgende Anforderungen erfüllt: • Flexibel und schnell anpassbar • Fehlertolerant • kann Bestandssysteme integrieren Mayflower GmbH 2009
- 50. Service-Cloud • Der Serviceist die Library/Komponente • Höchste Form der Wiederverwendung von Komponenten • Einfache, flexible Schnittstellen • Bietet Introspektion, Authorisierung und Versionierung Mayflower GmbH 2009
- 51. Service Cloud 2009 Mayflower GmbH 2009
- 52. Service Cloud 2009 Mayflower GmbH 2009
- 53. Kristallkugel • Web 1.0existiert friedlich neben Web 2.0, die Vernetzung wird langsam erfolgen. • Niemand weiss, wie es wirklich aussehen wird, aber neue Software sollte ... • auf Service-Fähigkeit ausgelegt werden • die Nutzbarkeit externer Komponenten prüfen • im Applikationsportfolio geplant sein • JavaScript wird Applikationssprache Mayflower GmbH 2009
- 54. URLs • http://pipes.yahoo.com • Google-Dork: „Mashware: The Future of Web Applications“ SUN / University of Tampere • Blogs: Tim Anderson, Tim O‘Reilly etc ... • http://www.programmableweb.com/apis • http://bit.ly/wxLoQ (Google OS) Mayflower GmbH 2009
- 55. • https://www.xing.com/profile/ JohannPeter_Hartmann • Facebook, Twitter, LinkedIn • hartmann@mayflower.de Mayflower GmbH 2009
Hinweis der Redaktion
- #2 Eigentlich ein 60-Min Vortrag\nDie besten Folien sind die mit den Konsequenzen für die Applikationslandschaft. \nDie habe ich aus Zeitgründen weggekürzt. \n
- #3 - Wer würde sich hier als Tekkie bezeichnen? \n- Wer ist genervt von Techgeek-Vorträgen? \n- Ok, ich beeil mich!\nPython-Entwickler hier? Weiss jemand, wozu Python entwickelt wurde? \n\n
- #4 Andrew Tanenbaum - Massiv verteilt, nur ein Thin Client\nMinix: Fail Amoeba: Win\nAber was passiert genau? \n
- #5 Klassische 3-Tier Architektur in der PHP-Welt: Browser, Webserver, Datenbankserver\nDas hat sich schon geändert, und das wird sich noch deutlicher ändern.\n\n
- #6 Klassische 3-Tier Architektur in der PHP-Welt: Browser, Webserver, Datenbankserver\nDas hat sich schon geändert, und das wird sich noch deutlicher ändern.\n\n
- #7 Klassische 3-Tier Architektur in der PHP-Welt: Browser, Webserver, Datenbankserver\nDas hat sich schon geändert, und das wird sich noch deutlicher ändern.\n\n
- #8 Klassische 3-Tier Architektur in der PHP-Welt: Browser, Webserver, Datenbankserver\nDas hat sich schon geändert, und das wird sich noch deutlicher ändern.\n\n
- #9 Klassische 3-Tier Architektur in der PHP-Welt: Browser, Webserver, Datenbankserver\nDas hat sich schon geändert, und das wird sich noch deutlicher ändern.\n\n
- #10 Trend 1: \nDie Prozessoren werden nicht mehr schneller, Moores Law wird durch die Physik beendet. Aber wenn wir keine schnelleren Prozessoren bekommen brauchen wir eben mehr davon!\n
- #11 Trend 1: \nDie Prozessoren werden nicht mehr schneller, Moores Law wird durch die Physik beendet. Aber wenn wir keine schnelleren Prozessoren bekommen brauchen wir eben mehr davon!\n
- #12 Trend 1: \nDie Prozessoren werden nicht mehr schneller, Moores Law wird durch die Physik beendet. Aber wenn wir keine schnelleren Prozessoren bekommen brauchen wir eben mehr davon!\n
- #13 Trend 1: \nDie Prozessoren werden nicht mehr schneller, Moores Law wird durch die Physik beendet. Aber wenn wir keine schnelleren Prozessoren bekommen brauchen wir eben mehr davon!\n
- #14 Trend 1: \nDie Prozessoren werden nicht mehr schneller, Moores Law wird durch die Physik beendet. Aber wenn wir keine schnelleren Prozessoren bekommen brauchen wir eben mehr davon!\n
- #15 Trend 1: \nDie Prozessoren werden nicht mehr schneller, Moores Law wird durch die Physik beendet. Aber wenn wir keine schnelleren Prozessoren bekommen brauchen wir eben mehr davon!\n
- #16 Trend 1: \nDie Prozessoren werden nicht mehr schneller, Moores Law wird durch die Physik beendet. Aber wenn wir keine schnelleren Prozessoren bekommen brauchen wir eben mehr davon!\n
- #17 Trend 2: der Browser wird mächtiger - Der Execution-Pfad war bisher rein auf dem Webserver\nJetzt findet die Execution auch auf dem Browser statt. -Das ist der Status der aktuellen Entwicklung bei Web-Applikationen. \nUnd noch etwas ist Speziell im Browser: er supported von sich aus mehrere Exekutionspfade. \nUnd nicht zuletzt: Die dort eingesetzte Hardware wird von einer anderen Abteilung bezahlt. Aus genau dieser Änderung folgen aber noch mehr Dinge: \n\n\n\n
- #18 Trend 2: der Browser wird mächtiger - Der Execution-Pfad war bisher rein auf dem Webserver\nJetzt findet die Execution auch auf dem Browser statt. -Das ist der Status der aktuellen Entwicklung bei Web-Applikationen. \nUnd noch etwas ist Speziell im Browser: er supported von sich aus mehrere Exekutionspfade. \nUnd nicht zuletzt: Die dort eingesetzte Hardware wird von einer anderen Abteilung bezahlt. Aus genau dieser Änderung folgen aber noch mehr Dinge: \n\n\n\n
- #19 Trend 2: der Browser wird mächtiger - Der Execution-Pfad war bisher rein auf dem Webserver\nJetzt findet die Execution auch auf dem Browser statt. -Das ist der Status der aktuellen Entwicklung bei Web-Applikationen. \nUnd noch etwas ist Speziell im Browser: er supported von sich aus mehrere Exekutionspfade. \nUnd nicht zuletzt: Die dort eingesetzte Hardware wird von einer anderen Abteilung bezahlt. Aus genau dieser Änderung folgen aber noch mehr Dinge: \n\n\n\n
- #20 Trend 2: der Browser wird mächtiger - Der Execution-Pfad war bisher rein auf dem Webserver\nJetzt findet die Execution auch auf dem Browser statt. -Das ist der Status der aktuellen Entwicklung bei Web-Applikationen. \nUnd noch etwas ist Speziell im Browser: er supported von sich aus mehrere Exekutionspfade. \nUnd nicht zuletzt: Die dort eingesetzte Hardware wird von einer anderen Abteilung bezahlt. Aus genau dieser Änderung folgen aber noch mehr Dinge: \n\n\n\n
- #21 Trend 2: der Browser wird mächtiger - Der Execution-Pfad war bisher rein auf dem Webserver\nJetzt findet die Execution auch auf dem Browser statt. -Das ist der Status der aktuellen Entwicklung bei Web-Applikationen. \nUnd noch etwas ist Speziell im Browser: er supported von sich aus mehrere Exekutionspfade. \nUnd nicht zuletzt: Die dort eingesetzte Hardware wird von einer anderen Abteilung bezahlt. Aus genau dieser Änderung folgen aber noch mehr Dinge: \n\n\n\n
- #22 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #23 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #24 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #25 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #26 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #27 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #28 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #29 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #30 Aber nicht nur im Browser kann parallel ausgeführt werden - er kann auch mit mehreren Servern sprechen. Fazit: Service-Oriented Architectures \nAber damit fängt die Zerlegung gerade erst an... \n
- #31 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #32 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #33 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #34 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #35 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #36 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #37 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #38 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #39 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #40 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #41 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #42 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #43 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #44 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #45 Meistens ist Präsentationsschicht 2 Teile: Client & Server\nMit dieser Architekturänderung und JavaScript verschieben sich auch die Aufgaben: \n* Aus der Präsentationsschicht wird die Browser-Applikation, die zu weiten Teilen direkt im Browser läuft. Dieses Layer bekommt keine Layouts mehr vom Server, sondern wird nur noch mit Daten beliefert - die Serverseite beschränkt sich damit als Datenlieferant und Serviceanbieter.\n* Damit ergibt sich gleichzeitig eine neue Chance: Auch andere Web-Applikationen können auf das eigene Service-Layer zurückgreifen. \n* Und auch der Umkehrschluss gilt: Die eigene Applikation greift auf fremde Services zurück.\n\n
- #46 Es hat sich gleichzeitig der Character der Applikation geändert. \nDie Präsentationsschichten werden abgelöst durch eine Browser-Applikation und Service-Layer. Die Folgen daraus: \n- Es können auch andere Applikationen auf die Services zugreifen\n- Es können auch fremde Services Funktionen in der eigenen Software einnehmen\nFolgefolie: Komplexität Execution Path\n\n
- #47 Aber nicht nur das ändert sich: in der klassischen Web-Applikation war der Execution-Pfad einfach ... \n
- #48 In der RIA / Service-Cloud-Applikation (MashWare in SunDeutsch) weiss der Nutzer nicht, wo welcher Service wann aufgerufen wird. Diese Entscheidung passiert verdeckt in der Browser-Applikation. Dabei können Client-Side-Caches eine Rolle spielen, aber auch Rückkanäle a la COMET\n
- #49 In der RIA / Service-Cloud-Applikation (MashWare in SunDeutsch) weiss der Nutzer nicht, wo welcher Service wann aufgerufen wird. Diese Entscheidung passiert verdeckt in der Browser-Applikation. Dabei können Client-Side-Caches eine Rolle spielen, aber auch Rückkanäle a la COMET\n
- #50 In der RIA / Service-Cloud-Applikation (MashWare in SunDeutsch) weiss der Nutzer nicht, wo welcher Service wann aufgerufen wird. Diese Entscheidung passiert verdeckt in der Browser-Applikation. Dabei können Client-Side-Caches eine Rolle spielen, aber auch Rückkanäle a la COMET\n
- #51 In der RIA / Service-Cloud-Applikation (MashWare in SunDeutsch) weiss der Nutzer nicht, wo welcher Service wann aufgerufen wird. Diese Entscheidung passiert verdeckt in der Browser-Applikation. Dabei können Client-Side-Caches eine Rolle spielen, aber auch Rückkanäle a la COMET\n
- #52 Was heisst das für die Client-Seite in dieser Architektur? \nVorteil: Nutzer bekommt mehr Usability - Nachteil: User will auch mehr Usability. \nDie Workflowsteuerung erfolgt in der Tat durch den Browser getrieben. Diese Steuerung muss aber nicht dick sein, sondern flexibel und schnell anpassbar. Dafür sinken die Kosten in Deployment und die Anforderungen an die Clients. \n
- #53 Was heisst das für die Client-Seite in dieser Architektur? \nVorteil: Nutzer bekommt mehr Usability - Nachteil: User will auch mehr Usability. \nDie Workflowsteuerung erfolgt in der Tat durch den Browser getrieben. Diese Steuerung muss aber nicht dick sein, sondern flexibel und schnell anpassbar. Dafür sinken die Kosten in Deployment und die Anforderungen an die Clients. \n
- #54 Was heisst das für die Client-Seite in dieser Architektur? \nVorteil: Nutzer bekommt mehr Usability - Nachteil: User will auch mehr Usability. \nDie Workflowsteuerung erfolgt in der Tat durch den Browser getrieben. Diese Steuerung muss aber nicht dick sein, sondern flexibel und schnell anpassbar. Dafür sinken die Kosten in Deployment und die Anforderungen an die Clients. \n
- #55 Was heisst das für die Client-Seite in dieser Architektur? \nVorteil: Nutzer bekommt mehr Usability - Nachteil: User will auch mehr Usability. \nDie Workflowsteuerung erfolgt in der Tat durch den Browser getrieben. Diese Steuerung muss aber nicht dick sein, sondern flexibel und schnell anpassbar. Dafür sinken die Kosten in Deployment und die Anforderungen an die Clients. \n
- #56 Was heisst das für die Client-Seite in dieser Architektur? \nVorteil: Nutzer bekommt mehr Usability - Nachteil: User will auch mehr Usability. \nDie Workflowsteuerung erfolgt in der Tat durch den Browser getrieben. Diese Steuerung muss aber nicht dick sein, sondern flexibel und schnell anpassbar. Dafür sinken die Kosten in Deployment und die Anforderungen an die Clients. \n
- #57 Was heisst das für die Client-Seite in dieser Architektur? \nVorteil: Nutzer bekommt mehr Usability - Nachteil: User will auch mehr Usability. \nDie Workflowsteuerung erfolgt in der Tat durch den Browser getrieben. Diese Steuerung muss aber nicht dick sein, sondern flexibel und schnell anpassbar. Dafür sinken die Kosten in Deployment und die Anforderungen an die Clients. \n
- #58 Es gibt zwei generelle Richtungen da: die eine sind Tools, die mächtiger sind und bessere Client-Integration bieten ... Microsoft setzt strategisch auf Silverlight. \nAdobe möchte mit dem Klassiker Flash in neuer Inkarnation mitspielen\nUnd Sun versucht es wieder mit Java ... \n\n
- #59 Es gibt zwei generelle Richtungen da: die eine sind Tools, die mächtiger sind und bessere Client-Integration bieten ... Microsoft setzt strategisch auf Silverlight. \nAdobe möchte mit dem Klassiker Flash in neuer Inkarnation mitspielen\nUnd Sun versucht es wieder mit Java ... \n\n
- #60 Es gibt zwei generelle Richtungen da: die eine sind Tools, die mächtiger sind und bessere Client-Integration bieten ... Microsoft setzt strategisch auf Silverlight. \nAdobe möchte mit dem Klassiker Flash in neuer Inkarnation mitspielen\nUnd Sun versucht es wieder mit Java ... \n\n
- #61 Es gibt zwei generelle Richtungen da: die eine sind Tools, die mächtiger sind und bessere Client-Integration bieten ... Microsoft setzt strategisch auf Silverlight. \nAdobe möchte mit dem Klassiker Flash in neuer Inkarnation mitspielen\nUnd Sun versucht es wieder mit Java ... \n\n
- #62 Es gibt zwei generelle Richtungen da: die eine sind Tools, die mächtiger sind und bessere Client-Integration bieten ... Microsoft setzt strategisch auf Silverlight. \nAdobe möchte mit dem Klassiker Flash in neuer Inkarnation mitspielen\nUnd Sun versucht es wieder mit Java ... \n\n
- #63 Microsoft's existing application stack -- Office-Windows-Windows Server -- is eroding.\n
- #64 Dass der Megatrend JavaScript ist, zeigt sich auch im Development. Diese Tools sind zum Teil in bestehende IDEs integriert, bieten zum Teil eigene Umgebungen und - dies gilt insbesondere für die erfolgreichsten PopFly und Yahoo Pipes - laufen direkt im Browser. \n\n
- #65 Wie sehen diese IDEs konkret aus? Beispiel Yahoo Pipes. \nEs ist aber keineswegs raus, was sich am Ende durchsetzen wird - Google hat zB seinen MashUp-Editor gerade eingestellt, es ist aber abzusehen, dass dort andere Ideen aufkommen werden. Als größter Service-Provider wäre es auch albern, das nicht zu machen. \n
- #66 Auf der Service / Server-Seite gibt es keinen klaren Trend,\nist aber auch gar nicht notwendig\n
- #67 Das, was früher die extern eingekaufte Komponente oder Appliance war, ist heute der externe Service. \nDie Wiederverwendung von Softwarebestandteilen findet nicht nur im SourceCode, sondern auch in der Installation statt. \n\n
- #68 Aktuell Early Adopters, Developer\nREST setzt sich durch, JavaScript wird vermutlich noch stärker\n
- #69 \n
- #70 \n
- #71 \n