Was ist wichtiger: gute Skalierbarkeit oder Performance?

Das Desaster der Java-Frameworks ist hierfür ein gutes Beispiel. Man erstelle eine Anwendung auf einem üblichen Java-Anwendungsserver und versehe sie mit der Unzahl der verschiedenen vorhandenen Frameworks (Spring, Struts, Faces, und so weiter). Nun verursache man vorsätzlich eine Null-Pointer-Exception und untersuche den Stack-Trace. Dann wird man feststellen, dass dieser Nullwert mehrere Dutzend Schichten durchlaufen hat, bis er endlich eine Ausnahme auslöst.

Völlig unabhängig davon, wo die Ausnahme aufgetreten ist: Die Verarbeitung dieser Variablen verursacht auf jeden Fall einen riesigen Overhead. Bei einem kleinen Perl-, PHP- oder Ruby-Script hingegen hätte die Variable bis zum Auslösen der Runtime-Exception nur wenige Funktionen durchlaufen.

Das ist nur einer der Gründe, warum .NET und Java niemals so schnell sein werden wie nativer Code. Bei der Arbeit mit nativem Code werden nur selten mehrere Schichten zwischen das Betriebssystem und die Anwendung eingefügt. Die massiven Frameworks sind so abstrakt und überladen, dass die Daten oft vielfach kopiert werden, bevor sie ihr eigentliches Ziel erreichen. Dies nur als kleiner Exkurs am Rande, um das Problem zu verdeutlichen.

Genau dasselbe passiert in einer auf Skalierbarkeit, Robustheit und Interoperabilität sowie mögliche zukünftige Erweiterung ausgelegten Web-Architektur mit mehreren Ebenen. Eine mögliche Anfrage des Clients zur Erfassung eines neuen Eintrags in die Datenbank sieht hier etwa folgendermaßen aus:

1. Der http-Server mit Lastausgleich empfängt die Anfrage und führt ein kurzes Parsing durch, bis er festgestellt hat, auf welchen Anwendungs-Servercluster sich die Anfrage bezieht.
2. Der Anwendungs-Cluster empfängt die Anfrage und verarbeitet sie auf Präsentationsschicht-Ebene. Er erkennt die Anforderung zum Einfügen eines Eintrags und erstellt eine SOAP-Abwicklungsanfrage an die Prozesslogikschicht.
3. Der Prozesslogik-Cluster empfängt die Anfrage und muss überprüfen, ob keine anderen Anfragen versuchen, ebenfalls eine zweite Zeile einzufügen, etwa aufgrund eines Doppelklicks auf die Submit-Taste. Er fragt also sich selbst und die anderen Clusterteilnehmer mit Zugang zum gemeinsamen Speicher ab, ob sie die gleiche Tätigkeit ausführen. Falls nein, benachrichtigt er den gemeinsamen Speicher, dass er gerade XYZ ausführt und die anderen Teilnehmer dies nicht ebenfalls zu tun brauchen. Die Geschäftslogikschicht erzeugt eine SOAP-Anfrage an die Datenzugriffsschicht, um die Zeile einzufügen.
4. Die Datenzugriffsschicht empfängt die Anfrage, öffnet sie, stellt fest, welche gespeicherte Prozedur in der Datenbankschicht sie dafür verwenden muss und ruft die gespeicherte Prozedur über eine TCP-IP-Pipeline auf.
5. Die Datenbank empfängt die Anfrage, führt die gespeicherte Prozedur aus und meldet die erfolgreiche Ausführung an den anrufenden Teilnehmer.
6. Die Datenzugriffsschicht empfängt die Statusinformation und meldet den Erfolg als Antwort an die SOAP-Anfrage.
7. Die Geschäftslogikschicht empfängt eine Erfolgsbenachrichtigung, meldet den Vollzug an den gemeinsamen Speicher, sendet eventuell weitere Bestätigungen und meldet sodann eine Erfolgsmeldung an die Präsentation.
8. Die Präsentation wählt eine Bestätigungsnachricht und sendet diese an den Urheber zurück.

Dieser Ablauf ist sogar noch vereinfacht dargestellt, ohne Meldungswarteschlangen und Ähnliches!