Architekturen für Webanwendungen

Webanwendungen sind Softwareprogramme, die weitgehend über Webbrowser benutzt werden.
Dies kann sowohl im lokalen Netz (Intranet) als auch übers Internet erfolgen.
Die Applikationslogik und Datenhaltung erfolgt größtenteils auf einem zentralen Server.

Inhalt

Webanwendungen, n-Tier-Architektur, Applikationsserver
Technologiekonzepte zur Benutzeroberfläche, Verteilung und Datenhaltung
Programmierumgebungen für dynamische Webseiten

Webanwendungen, n-Tier-Architektur, Applikationsserver

Webanwendungen werden typischerweise in drei Schichten realisiert (3-Tier):

Präsentationsschicht (Webbrowser)
Applikationslogik (Applikationsserver)
Datenbankschicht (außer SQL-DB auch Legacy- und ERP-Systeme)

Vorteile von Webapplikationen über einen Applikationsserver:

Bei den Anwendern muss keine Software installiert werden, ein einfacher Webbrowser reicht;
PC, Laptop, PDA, Smartphone und Handy können unterstützt werden
Die Anwendungen sind multiuser- und netzwerkfähig (Intranet und Internet), viele Benutzer können gleichzeitig arbeiten
Integration mit vorhandenen Datenbanken sowie Legacy- und ERP-Systemen, zum Beispiel SAP R/3®, ist möglich
Anwendungen auf einem zentralen Application Server sind leichter wartbar und die Anwender benutzen stets die aktuellste Softwareversion
Konsistente Datenhaltung und zuverlässiges Backup sind gewährleistet
Sicherheitskritische SQL-Statements und deren Resultate werden nicht zum Client übertragen
Realisierung von Verteilung, Skalierung, Load Balancing, Failover, Ausfallsicherheit, Transaktionsmanagement und Sicherheitsmechanismen wird erleichtert

Weiteres zu Applikationsservern finden Sie unter applicationserver.htm.

Technologiekonzepte zur Benutzeroberfläche, Verteilung und Datenhaltung

Leider werden die klassifizierenden Konzeptbegriffe sehr uneinheitlich und inkonsistent verwendet. Meistens ist folgendes gemeint:

Terminal mit Thin Clients:
Display Engine, die Bildschirminhalte vom Server zum Client und Tastatureingaben und Mausbewegungen vom Client zum Server sendet (z.B. WTS Windows Terminal Server, Citrix, VNC und X11);
Die angeschlossenen Rechner können sehr einfache Rechner sein (auch ohne Festplatte), solche vereinfachten PCs werden auch Thin Client genannt
Webanwendung:
Softwareprogramm, das von einem Webserver geladen und weitgehend über den Webbrowser benutzt wird
Thin Client:
Hier sind keine vereinfachten PCs an Terminal Servern gemeint, sondern "schlanke Webanwendungen";
Ein üblicher Webbrowser genügt zur Ausführung, es muss nichts beim Anwender installiert werden;
Eine solche Thin-Client-Anwendung basiert auf HTML, DHTML und JavaScript;
Bestimmte Widgets und GUI-Funktionen wie Menüleisten, Untermenüs, Kontextmenüs, modale Dialoge, Bäume, Slider, interaktive Tabellen, Tastaturkürzel, Eingabevalidierungen und Drag&Drop sind etwas schwieriger zu realisieren
Rich Client:
Thin Client mit verbesserter GUI-Oberfläche und Interaktion (z.B. per Java)
Rich Thin Client:
Rich Client mit Server-seitiger GUI-Steuerung und schlanker Präsentation auf dem Client (z.B. per speziellem Java Applet, vielleicht 500 KByte groß);
Z.B. als Realisierung des HOPP-Patterns (Half-Object Plus Protocol) mit Server-Side-Swing und Proxies im Client und Server zur transparenten Verbindung per HTTP(S) (oder auch RMI/IIOP)
Rich Fat Client:
Rich Client mit Client-seitiger GUI-Steuerung und mächtigem Client-seitigem Middleware-Framework (z.B. RCP basierend auf Eclipse)
Managed Client:
Erweiterter Rich Fat Client, Server-managed Client Device;
Anwendungsstart, Installation und Software-Update erfolgen per Webbrowser;
Auf dem Anwendungsrechner wird Client-Middleware-Framework installiert inkl. Mechanismus zur Softwareverteilung, Rechteverwaltung, Verschlüsselung und Replikation/Synchronisation
Fat Client:
Desktop-Applikation, die auf dem Anwendungsrechner installiert wird (Datenaustausch zum Server kann z.B. per Web Services erfolgen)

Es folgt ein Vergleich verschiedener Architekturen sowohl für Webanwendungen als auch für Fat Clients. Allen gemeinsam ist Multiuser-Betrieb mit zentraler SQL-Datenbank. Um keine Datenbankzugriffe übers Netz bis zum Client führen zu müssen, sollte ein Applikationsserver zwischengeschaltet sein.

Die genannten Technologien sind nicht unbedingt sich ausschließende Alternativen, sondern können zum Teil auch kombiniert eingesetzt werden.

Technologie	GUI	Applikationslogik	Offline-Betrieb mit Replikation/ Synchronisation	Bemerkung
Thin Client	HTML + JavaScript im Webbrowser	Applikationsserver, z.B. JSP+JavaBeans mit Tomcat, Java-EE-EJB z.B. mit JBoss oder Casabac GUI Server	nein	keine lokalen Installationen, geringster Admininistrationsaufwand; Einschränkungen bei den GUI-Dialogelementen und der Benutzerführung
Portal	Portlets im Webbrowser	Portal-Applikationsserver, z.B. Jetspeed, Jahia oder Cocoon	eher nicht	herstellerübergreifender Standard (IBM, Sun, Oracle, SAP®, teilweise auch Microsoft), per Web Services und WSRP auch mit anderen Portlets bzw. anderen Portalservern programmiersprachenunabhängig (Java, .NET, Delphi) kombinierbar, Integration verschiedener Anwendungen, erleichterte Unterstützung von PDAs und Smartphones; keine lokalen Installationen, geringer Admininistrationsaufwand
Java Applet	HTML + Java-AWT/Swing-GUI, Java Applet im Webbrowser	Sowohl beim Client als auch im Applikationsserver	eher nicht	keine lokalen Installationen (außer Java VM), geringer Admininistrationsaufwand
Rich Thin Client	Java-AWT-GUI in speziellem Java Applet im Webbrowser, XUL	Sowohl beim Client als auch im Applikationsserver, z.B. mit Thinlet	eher nicht	keine lokalen Installationen (außer Java VM 1.1), auch auf kleineren Geräten verwendbar, geringer Admininistrationsaufwand, Open Source (LGPL)
Rich Thin Client	Java-Swing/SWT-GUI in speziellem Java Applet im Webbrowser; HOPP/Server-Side-Swing	Applikationsserver; z.B. AltioLive, AppProjector, Canoo ULC, Droplets oder RSWT (Remote SWT)	eher nicht	keine lokalen Installationen (außer Java VM 2), geringer Admininistrationsaufwand
Rich Fat Client	Z.B. Java-SWT/JFace-GUI	Clientseitiges Framework, z.B. RCP (Rich Client Platform), basierend auf Eclipse und OSGI.	möglich, aber aufwändig	Client-Framework ist plattformabhängig mit unterschiedlichen Versionen für Windows, Linux und Mac
Managed Client: IBM Workplace Client Technology	Clientseitiges Framework: Java-SWT-Plug-ins in Eclipse (etwas vergleichbar wie Portlets für Portale)	Basiert auf RCP; Client-Java-Middleware mit Client-Applikationsserver und Mechanismus zur Softwareverteilung, Rechteverwaltung und Verschlüsselung	ja, per Client-DB Cloudscape	Client-Framework ist plattformabhängig mit unterschiedlichen Versionen für Windows, Linux und Mac; Anwendungen können plattformunabhängig sein; Benötigt im Server den IBM Websphere Portal Server
Managed Client: Microsoft Smart Client	.NET Windows Forms, XAML, "Click Once", Start und Software-Update per Webbrowser	.NET, ASP.NET	ja, per ADO.NET-Cache	plattformabhängig, vorwiegend für Microsoft Windows
Java Webstart	Java-Swing-GUI, Start und Software-Update per Webbrowser	Sowohl beim Client als auch im Applikationsserver	möglich, aber aufwändig	geringer Admininistrationsaufwand
Java Fat Client	Java-GUI	Überwiegend beim Client, Desktop-Applikation	möglich, aber aufwändig	hoher Admininistrationsaufwand
Windows Fat Client (oder Linux etc.)	Windows- oder Linux-GUI, z.B. mit C# oder Delphi	Überwiegend beim Client, Desktop-Applikation	möglich, aber aufwändig	plattformabhängig, verschiedene Versionen für verschiedene Betriebssysteme, hoher Admininistrationsaufwand
Datenbank-Programm	Windows- oder Linux-GUI, z.B. mit 4GL-Tools wie PowerBuilder	Desktop-Applikation mit direkter Datenbankanbindung, ohne Applikationsserver	nein	SQL-Statements und deren Resultate werden übers Netzwerk zum Client übertragen; plattformabhängig, verschiedene Versionen für verschiedene Betriebssysteme, hoher Admininistrationsaufwand

Für in Unternehmen genutzte Software, insbesondere im ERP-Umfeld, haben sich bei allen großen Softwareanbietern (IBM, Oracle, Sun, SAP®, Microsoft) Portale durchgesetzt. Weiteres dazu finden Sie unter Portale.

Programmierumgebungen für dynamische Webseiten

Einige wichtige Programmierumgebungen zur Erzeugung dynamischer Webseiten (in der Regel mit Anbindung an SQL-Datenbank):

CGI, Perl	Per CGI-Schnittstelle (Common Gateway Interface) aufgerufene Perl-Skripte (Practical Extraction and Report Language). Breite Unterstützung und gut geeignet für kleine Anwendung.
PHP, LAMP	PHP (PHP Hypertext Preprocessor) bietet mehr Geschwindigkeit, komfortablere Bibliotheken und wesentlich bessere Möglichkeiten zur Datenbankanbindung. Besonders verbreitet in der LAMP-Kombination (Linux-Apache-MySQL-PHP). Schwächen: sehr spezialisierte Sprache, eingeschränkte Kommunikation mit anderen Applikationen, schwieriges Debugging und nicht-requestgetriebe Hintergrundprozesse umständlich.
ASP.NET, .NET	ASP.NET (Active Server Pages, nicht zu verwechseln mit Application Service Providing) macht fast nur mit dem Microsoft Internet Information Server (IIS) unter Windows Sinn. Ist im Microsoft-Umfeld sehr leistungsfähig, aber wenig bis gar nicht portabel und bedeutet große Abhängigkeit von dem einen Hersteller Microsoft.
JSP + JavaBeans	Java ist besonders bei den großen Software-Herstellern (wie IBM, Sun, Oracle, SAP®) zur bevorzugten Programmiersprache geworden. JSP (JavaServer Pages) hat Ähnlichkeiten zu ASP und bietet vergleichbare Features. Auch bei JSP besteht der Code aus normalem HTML-Code mit eingebetteten durch "<% ... %>" abgetrennten Code-Snippets (Schnipseln). Bei JSP enthalten diese Snippets Java-Code. Der gesamte Java-Sprachumfang samt Bibliotheken, JavaBeans- und Java-SE-/Java-EE-Komponenten, guter Netzwerkfähigkeit sowie komfortabler und schneller Datenbankanbindung steht zur Verfügung. JSP-Anwendungen laufen unverändert z.B. sowohl unter Linux + Apache als auch Windows + IIS sowie auf beliebigen Web Application Servern.
JSP + Enterprise JavaBeans	Anders als einfache JavaBeans sind EJBs (Enterprise JavaBeans) gemanagte Objekte und benötigen eine spezielle Laufzeitumgebung (EJB-Container). Obwohl bereits JSP Teil der Java EE (Java Enterprise Edition) ist, ist mit Java EE meistens die aufwändigere EJB-Technologie gemeint. EJBs bieten genau definierte Strukturen und Aufgabenteilungen. Diese Standardisierung erleichtert Komponenten-Verteilung, Skalierung, Load Balancing, Failover, Enterprise-Funktionen, Transaktionsmanagement und Sicherheitsmechanismen. Nachteilig bei der EJB-Technologie im Vergleich zu "POJOs" (Plain Old Java Objects) ist der erhöhte Einarbeitungsaufwand und die zum Teil nicht mehr realisierbare Vererbung und Polymorphie.
Durchgehend Java	Während bei JSP das im Webbrowser dargestellte Ergebnis eine HTML-Seite ist (eventuell mit eingebettetem JavaScript), und somit vom Entwickler verschiedenste Technologien wie Java, HTML, DHTML, CSS und JavaScript beherrscht werden müssen, sind bei puren Java-Lösungen nur Java-Kenntnisse gefordert und es können komfortablere GUI-Elemente und -Funktionen realisiert werden. Üblich sind z.B. die oben genannten Rich Thin Clients mit speziellen schlanken Java-Applets und Rich Fat Clients mit speziellen Client-Middleware-Frameworks.

Weiteres zu Technologien für dynamische Webseiten finden Sie unter db-web.htm.
Eine Einführung zu JSP finden Sie in JSP-Einführung.