Hallo silver,
1.) In diesem kleinen Vortrag wird vorausgesetzt, dass eine Anwendung a) eine Datenbasis, auf der herumgereitet (herumgehühnert) wird, bearbeitet b) diese Datenbasis eine gewisse Komplexität hat und von einem RDBMS verwaltet wird c) Datenzugriffe der Art "CRUDL" (create, read, update, delete, list bzw. SET, GET, LET, DEL und LST) sind bzw. Geschäftsdatenanalysen dienen (wir hätten dann in der Regel zwei Datenhaltungen, da man auf der "transaktionalen" Datenhaltung besser nicht mit Geschäftsanalysen herumreitet, die Geschäftsdatenhaltung ist meist eine Kopie relevanter Teile der "transaktionalen" Datenhaltung) d) einen Sicherheitskontext benötigt, der im RDBMS "abgelegt" wird.
Ja, typische Anforderungen, bei denen Webanwedungen ganz brauchbar sind. Die GUI ist nämlich ziemlich trivial und kümmert sich im wesentlichen "Anfrage erstellen" und "Antwort angucken". Das passt recht gut zu HTML-Formularen und HTTP. Das ganze kann man dann mit JS und CSS noch etwas aufpolieren.
Zentralisierte Anwendungslogik klappt mit Desktopanwendungen natürlich genauso. XSLT und HTML kann man da auch mal einsetzen, wenn man irgend einen Report erzeugen und anzeigen will. Es geht also einfach mehr. So lang man nur GUI-Pradigmen benötigt, die sich gut mit HTML abbilden lassen (Formular ausfüllen, abschicken, antwort angucken), kommt man damit noch ganz gut klar. Braucht man mehr, wird gebastelt.
7.) Cool ist jetzt - da die Trennung der einzelnen Schichten erarbeitet worden ist - bspw. dass unterschiedliche Personen Teilaufgaben getrennt voneinander bearbeiten können.
Software in Schichten und Komponenten aufzutrennen geht immer. Die Tatsache, dass man HTTP dazwischen hat, zwingt ein natürlich zu dieser Trennung. Das Problem ist aber, dass sich die GUI-Schicht einfach schlecht realisieren lässt und dass die Kommunikation zwischen den Schichten über HTTP läuft, was die typische Kommunikation mit Ereignissen schwierig macht.
Und es gibt natürlich noch den "Frontend-Experten", der Styles entwickelt und JavaScript frickelt (Nur damit es sich reimt ;).
Upps, fast vergessen hätte ich den Designer, der auf alles noch schön "CSS" legt.
GUI- und Funktionsschicht lassen sich meist gut trennen, XSLT, JS und CSS werden aber stark aufeinander abgestimmt sein müssen. Das ist alles nicht mehr schön, wenn man über die oben angesprochenen "trivialen" Anforderungen hinaus will. Mit den angesprochenen Technologien, das einigermaßen in den Griff zu bekommen, meinte ich z.B. Java Server Faces oder soweit ich weiß auch ASP.NET. Damit lassen sich Webbassierte GUIs ähnlich aus Komponenten zusammenbauen, wie man das von typischen GUI-Bibliotheken kennt.
- es nur einen Datenclient gibt (den auf dem Webserver)
- relevanter Code immer serverseitig ausgeführt wird
Ja, einfache, zentralisierte Architektur hatte ich ja erwähnt. Stimmt aber nicht wirklich, da das natürlich auch geht, wenn man Clients als Desktopanwendungen realisiert.
- der nur clientseitig verfügbare Status alles einfacher macht
Hä? Bei ein bisschen komplexeren Anwendungen liegt ein Teil des Clientzustands immer auf dem Server (Stichwort "Sessions"), eben weil man kaum Zustand auf dem Client halten kann. Das ist auch etwas, was Webanwendungen umständlich zu implementieren macht.
- keine Installations und Wartungsaufwände (nicht zu unterschätzen!) entstehen
Ja, das ist der Hauptvorteil und vermutlich _der_ Grund, warum Webanwendungen so beliebt sind.
- Einfacheit (das A und O der IT) gegeben ist
Das sehe ich hingegen nicht, Webanwendungen werden oft ziemlich Komplex.
- vglw. sehr direkt an den Datenstrukturen gearbeitet wird (vgl. bspw. mit MS Windows-Programmen)
Was meinst Du damit?
Grüße
Daniel