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 der Code?
Präsentationsschicht
Business-Logik
Datenbank
Mayflower GmbH 2009
29. Wo ist der Code?
Präsentationsschicht
Business-Logik
Datenbank
Mayflower GmbH 2009
30. Wo ist der Code heute?
Fremde
Eigene Browserapplikation
Applikation
Rich Internet Application
Externe Services Eigene Services
Service-Cloud
Mayflower GmbH 2009
31. Wo ist der Code heute?
Fremde
Eigene Browserapplikation
Applikation
Rich Internet Application
Externe Services Eigene Services
Service-Cloud
Mayflower GmbH 2009
32. Wo ist der Code heute?
Fremde
Eigene Browserapplikation
Applikation
Rich Internet Application
Externe Services Eigene Services
Service-Cloud
Mayflower GmbH 2009
33. Wo ist der Code heute?
Fremde
Eigene Browserapplikation
Applikation
Rich Internet Application
Externe Services Eigene Services
Service-Cloud
Mayflower GmbH 2009
34. Wo ist der Code heute?
Fremde
Eigene Browserapplikation
Applikation
Rich Internet Application
Externe Services Eigene Services
Service-Cloud
Mayflower GmbH 2009
36. RIA-Layer
• Ist der Kern der Applikation
• User Interface und Interaction
Mayflower GmbH 2009
37. RIA-Layer
• Ist der Kern der Applikation
• User Interface und Interaction
• Workflowsteuerung
Mayflower GmbH 2009
38. RIA-Layer
• Ist der Kern der Applikation
• User Interface und Interaction
• Workflowsteuerung
• Glue-Code-Layer für Services
Mayflower GmbH 2009
39. RIA-Layer
• Ist der Kern der Applikation
• User Interface und Interaction
• Workflowsteuerung
• Glue-Code-Layer für Services
• Impliziter Deploy
Mayflower GmbH 2009
40. RIA-Layer
• Ist der Kern der Applikation
• User Interface und Interaction
• Workflowsteuerung
• Glue-Code-Layer für Services
• Impliziter Deploy
• Plattform- und Fehlertolerant
Mayflower GmbH 2009
43. RIA-Plattformen
• Der Kandidat für die Plattform der
Zukunft ...
• Microsoft: SilverLight
• Adobe: AIR / Flex
Mayflower GmbH 2009
44. RIA-Plattformen
• Der Kandidat für die Plattform der
Zukunft ...
• Microsoft: SilverLight
• Adobe: AIR / Flex
• Sun: JavaFX
Mayflower GmbH 2009
45. RIA-Plattformen
• Der Kandidat für die Plattform der
Zukunft ...
• Microsoft: SilverLight
• Adobe: AIR / Flex
• Sun: JavaFX
• and the Winner is: JavaScript!
Mayflower GmbH 2009
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 Service ist die Library/Komponente
• Höchste Form der Wiederverwendung von
Komponenten
• Einfache, flexible Schnittstellen
• Bietet Introspektion, Authorisierung und
Versionierung
Mayflower GmbH 2009
53. Kristallkugel
• Web 1.0 existiert 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
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
- 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
Andrew Tanenbaum - Massiv verteilt, nur ein Thin Client\nMinix: Fail Amoeba: Win\nAber was passiert genau? \n
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Aber nicht nur das ändert sich: in der klassischen Web-Applikation war der Execution-Pfad einfach ... \n
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Microsoft's existing application stack -- Office-Windows-Windows Server -- is eroding.\n
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
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
Auf der Service / Server-Seite gibt es keinen klaren Trend,\nist aber auch gar nicht notwendig\n
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
Aktuell Early Adopters, Developer\nREST setzt sich durch, JavaScript wird vermutlich noch stärker\n