nicht angemeldet
Hi,
ich merke schon, dass es wieder Zeit ist für den Vortrag mit dem o.g. Titel.
Warum sind Webanwendungen cool?
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.
2\.) Der Nutzer sitzt am Browser (wir wollen das den Client nennen) vor einem UI (oder GUI ;) und a) navigiert und b) gibt Datenzugriffe der o.g. Art in Auftrag und c) erhält neue "Seiten" (ein neues UI/GUI). Von wer erhält er dieses? Richtig, vom Server mit dem er per HTTP(S) so zu sagen verbunden (bzw. nicht verbunden ;) ist.
Dieses UI/GUI hat einen Status, den er nicht mit dem Server teilt. Beispielsweise Parameter wie die SitzungsID, bestimmte vorher angeforderte Datensatzmengen ("Trefferlisten", einzelne Datensatzinhalte) und der Navigation dienende Parameter. Handlungen des Nutzers, dienen sie der Navigation oder der Datenbasis, werden entweder rein clientseitig per JavaScript oder serverseitig nach Ausführen eines HTTP(S)-Requests bearbeitet.
3\.) Unter dem o.g. Server ist erst einmal ein Webserver zu verstehen, der HTTP(S)-Requests in Empfang nimmt, also bearbeitet. Der Webserver erhält mit jedem Request Daten. Diese Daten reicht er an eine serverseitig installierte Logik (bspw. Perl, PHP) zur Bearbeitung weiter. Nach erfolgter Bearbeitung sendet der Webserver von o.g. Logik erstellte Daten an den Client zurück.
4\.) Wie sehen die Daten nun aus, die der Client zurückerhält? Exakt, typischerweise HTML-Daten, die wiederum auf andere HTTP(S)-Ressourcen verweisen, die dann clientseitig ggf. nachgeladen werden. Hört sich doch alles recht kompliziert an, was ist daran also cool?
5\.) Cool ist daran u.a., dass die ganze Sache so programmiert sein könnte:
a) Die serverseitige Logik erhält eine Datenzugriffsanforderung und reicht diese an das RDBMS (so genannte stored procedures sollten hier zum Einsatz gelangen) weiter. Dieses prüft die Gültigkeit des Sitzungskontextes und gibt ein XML-Dokument zurück.
b) Für dieses ist ein "Style" präpariert und eine XSLTransformation wird durchgeführt und zu HTML transformierte Daten werden an den Client zurückgegeben.
c) Der Client holt sich ggf. noch das CSS-Dokument, auf das in den o.g. Daten verwiesen worden ist und rendert dann.
6\.) Da die möglichen Datenzugriffsanforderungen bekannt sind, wird folgendes benötigt:
a) eine schlanke serverseitige Logik, die der Navigation dient und Datenzugriffsanforderungen ans RDBMS weiterreicht
b) ein Rudel von Datenzugriffsprozeduren (Namensgebung mit Präfixen wie in Punkt 1 beschrieben wäre nicht verkehrt), das XML-Dokumente zurückgibt und auf
c) Styles (XSLT) verweist, die ebenfalls rudelmässig vorliegen
d) CSS-Dokumente für die Präsentation
e) JavaScript-Code, der entweder gleich in den o.g. Styles liegt, bzw. in ausgelagerten Dokumenten
7\.) Cool ist jetzt - da die Trennung der einzelnen Schichten erarbeitet worden ist - bspw. dass unterschiedliche Personen Teilaufgaben getrennt voneinander bearbeiten können. Getreu dem Motto "Bearbeite voneinander unabhängige Sachen unabhängig voneinander!". Man kann also den "Backie" mit den stored procedures sich vergnügen lassen, ohne dass er sich um weiteres kümmern muss. Er hat sein eigenes in sich geschlossenes System.
Dasselbe gilt in Teilen auch für den Mann (oder Frau ;), der die serverseitige Logik verwaltet. Dieser füllt eine wichtige Rolle aus, könnte auch den Projektchef spielen und fordert mal in eine Richtung ("Backies") mal in eine andere Richtung (frontend) Anpassungen/Weiterentwicklungen an.
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.
Ich könnte jetzt noch ein wenig nachlegen und anmerken, dass es ebenfalls cool ist, dass
- es nur einen Datenclient gibt (den auf dem Webserver)
- relevanter Code immer serverseitig ausgeführt wird
- der nur clientseitig verfügbare Status alles einfacher macht
- keine Installations und Wartungsaufwände (nicht zu unterschätzen!) entstehen
- Einfacheit (das A und O der IT) gegeben ist
- vglw. sehr direkt an den Datenstrukturen gearbeitet wird (vgl. bspw. mit MS Windows-Programmen)
Für Entwickler von "Spezialsoftware" (Spiele, SW mit Grafik-Features, CPU-lastige SW u.s.w.) gilt das alles natürlich auch. Leider müssen diese aber (leider und verständlicherweise) auf "fette" SW zurückgreifen.
MFG
silver Karnickel
Der Martin