Sonntag, 24. Juni 2012

Warum Server Pages bleiben werden

Hypes kommen, Hypes gehen – Web-Anwendungen bleiben! Seit sie in den neunziger Jahren aufkamen, werden sie eingesetzt, und es entstehen bis heute täglich neue.

Diejenigen Entwickler, die den freundlich klingenden Begriff der "klassischen Web-Anwendung" rhetorisch verwendeten, um diese von ihren eigenen, demnach moderneren Konzepten abzusetzen, mussten feststellen, dass diese alternativen Konzepte nach kurzer Zeit ihre Bedeutung verloren und allenfalls noch ihre Nischen haben, ihre treuen Fans, aber die Web-Anwendung nicht ersetzen konnten.

HTML-Hasser, CSS-Hasser, JavaScript-Hasser haben diesen Sprachen schon zu unzähligen Malen den Tod an den Hals gewünscht. Dennoch sind sie die Linguae Francae des Webs geblieben, und auf ihnen gründet das Konzept eines für Entwickler offenen User Interfaces.

Was ist der Grund für diese erstaunliche Langlebigkeit? Im Gegensatz zu UI-Technologien wie Web-Dynpro, die die Oberfläche vom Entwickler abschirmen und ihm nur ein graphisches Tool zur Pflege der Seiten überlassen, ist das UI einer Web-Anwendung für jeden Entwickler ein offenes Buch, in dem er lesen kann. Web-Anwendungen sind deshalb flexibel und offen. Sie sind plattform- und geräteunabhängig, laufen auf grossen und kleinsten Geräten (in heiss umkämpften Märkten wie bei den SmartPhones und Tablets ist das ein gewaltiger Vorteil gegenüber den von den Herstellern massiv beworbenen, aber leider gerätespezifischen Apps). Darüberhinaus erlauben Web-Anwendungen clientseitige Validierungen und Ajax, wodurch sie effizient, robust und einfach in der Bedienung werden. Die Zeit der Browser-Hacks, der Workarounds für Unzulänglichkeiten einzelner Browser, nähert sich ihrem Ende. Es war sowieso fast immer nur der Internet Explorer, der Probleme machte, da er nicht standardkonform war (und es auch heute noch nicht ist). Er wurde aber von Release zu Release verbessert.

In der SAP-Welt bedeutet das, dass die Technologie der Business Server Pages das Mittel der Wahl bleiben wird, um Web-Anwendungen zu erstellen - egal, wie das die Marketingabteilung von SAP einschätzt. Glücklicherweise ist es den SAP-Managern nicht möglich, diese Technologie abzuschalten: Um zu verbieten, dass Programmierer mit den Browsern der Welt in den dafür vorgesehenen Sprachen HTML, CSS und JavaScript reden, müssten sie schon den HTTP-Port abschalten. BSP ist ja nicht mehr als ein Toolset, das es dem Entwickler auf eine komfortable Weise ermöglicht, diese HTML-, CSS- und JavaScript-Inhalte zu beschicken. Das Wesentliche ist die Möglichkeit, überhaupt HTTP-Antworten dynamisch zu erstellen, die Technik des Request-Behandlers, das ICF. Was darüber hinausgeht, ist zwar nützlich, aber nicht essentiell. Tools sind ersetzbar.

Das Dreigetier (3-Tier)

Ganz allgemein hat sich herumgesprochen, dass es sinnvoll ist, seine Anwendung in drei Zuständigkeitsbereiche zu gliedern: GUI, Regeln und Datenbank.

Der GUI ist meist in Form eines eigenständigen Programms realisiert und kommuniziert über eine klar definierte Schnittstelle mit der Anwendungslogik. Diese ist das eigentliche Regelwerk der Anwendung, sie wird über den GUI vom Benutzer gesteuert und beschafft und aktualisiert ggf. Daten aus einer Datenbank.

SAP-Transaktionen

SAP R/3 hat diese Architektur mit Hilfe des Dynpro-Konzepts realisiert. Ein Dynpro ist ein einzelner Screen aus einer Folge von Screens, die zusammen eine Transaktion bilden. Das Dynpro wird vom Entwickler mit einer graphischen Oberfläche modelliert ("gemalt") - dem Screen Painter. Die Ausführung des Dynpros, das eigentliche Rendering, ist für den Entwickler eine Black Box. Sie erfolgt in einem eigenständigen User Agent, dem SAP Frontend (SAPGUI). Was darin läuft, kann der Entwickler nicht beeinflussen. Das einzige, was er beeinflussen kann, ist die Position und Eigenschaften der einzelnen Dynpro-Bestandteile wie Dialogboxen, Eingabefenster, Ankreuzfelder, Texte usw.

Web-Anwendungen

Das Charakteristische einer Web-Anwendung ist, dass ein Browser die Rolle des GUI übernimmt, der über eine HTTP-Verbindung mit dem Applikationsrechner kommuniziert. Der Browser kann mit Klartextdokumenten gesteuert werden, die in den Sprachen HTML für die Struktur und den Textinhalt, CSS für die Darstellungsart und JavaScript für die Präsentationslogik (Behaviour) verfasst sind. Diese Dokumente können vom Server dynamisch anhand der konkreten Anfragen des Benutzers erstellt werden.

Business Server Pages (BSP)

In Server Pages – das sind Java Server Pages für Java, Active Server Pages für .NET, Mason für Perl und Business Server Pages für ABAP, auch PHP gehört in diese Kategorie – ist das Konzept der Web-Anwendung geradlinig umgesetzt. Sie verstehen sich als ein Hilfsangebot zum Erzeugen dynamischer Webseiteninhalte. Im Grundelement, dem View oder der Page, werden dynamische mit statischen Inhalten zusammengeführt. Zur Laufzeit wird der Code der Views durchlaufen, wobei schliesslich eine HTML-Antwortseite entsteht. Diese dynamischen HTML-Seiten werden ergänzt durch statische Dokumente (MIME-Objekte, in der Regel CSS, JavaScript und Graphiken) sowie Requestbehandler für Ajax-Anfragen.



So einfach ist es tatsächlich: Server Pages sind nur ein Toolset für Entwickler, um HTTP-Antworten in den Sprachen des Browsers - in HTML, CSS und JavaScript - zu erzeugen. Das ist das Wesentliche. Business Server Pages bieten dies, und darüberhinaus noch einige clevere Ideen für eine gute Organisation des Codes:
  • Der View-Editor ist - inclusice Code-Navigation und Verwendungsnachweis - in die ABAP-Workbench integriert, also in den Ort, wo auch die Anwendungslogik entwickelt wird.
  • Für statische Ressourcen sind BSP-Applikationen an das MIME Repository angeschlossen. CSS- und JavaScript-Files können dort über die Verknüpfung mit einem guten Klartexteditor bearbeitet werden.
  • Mit Hilfe des Model-View-Controller Architekturmusters werden präsentationsnahe und anwendungssteuernde Teile besser von der eigentlichen Anwendungslogik separiert.
  • Mit Hilfe von Tag Libraries kann man für ein Projekt wiederkehrende graphische Komponenten als Element kapseln, das sich in den View wie ein HTML-Element hinschreiben lässt.

Web Dynpro (WD)

Das WebDynpro ist dagegen der Versuch, die Dynpro-Philosophie ins Web zu übertragen: Die Sprachen des Browsers, obwohl als Klartextformate eigentlich zum Nachvollziehen gedacht, werden mit Aufwand unzugänglich gemacht, und das Design der Oberfläche ist nur noch mit einem Screen-Painter-artigen Werkzeug zum "Malen" von Oberflächen möglich, in dem man aus einer standardisierten Palette von Objekten per Drag und Drop auswählen darf. Die eigentliche Generierung der HTML-, CSS- und JavaScript-Inhalte bleibt verborgen und kann auch vom Entwickler nicht beeinflusst werden.[1]

Warum Server Pages für Webanwendungen die Methode der Wahl bleiben

Auf Web-Dynpro-Basis erzeugt man daher keine Web-Anwendung – sondern nur eine Anwendung, die im Browser aufrufbar ist. Das klingt ähnlich, ist aber nicht das Gleiche. Zu einer Web-Anwendung gehören die Sprachen des Web – HTML, JavaScript, CSS – sie sind keine unwichtige Nebensache, auch kein irgendwie "niederer Code", der hinter den Kulissen läuft und vor dessen Anblick man den Entwickler beschützen muss, weil er sonst zur Salzsäule erstarrt. Wer so denkt, benutzt nur die Kommunikationswege des Internets, will aber ansonsten mit dem Web und seiner Philosophie möglichst wenig zu tun haben.

Da der HTML-Code im Web-Dynpro - für den Anwendungsentwickler unsichtbar - hinter den Kulissen generiert wird, muss der Bedarf an neuen graphischen Elementen zwangsweise in Form eines Entwicklungsantrags an Walldorf gerichtet werden. Es ist nicht möglich, eigene Elemente in Form von Kundenentwicklungen hinzuzufügen. Die Elemente werden grundsätzlich in Walldorf entwickelt und können vom Anwendungsentwickler nur eingesetzt werden. Das macht das Web-Dynpro träge für Änderungen. Im Unterschied dazu kann in einer BSP ein neues Feature, das man heute im Internet entdeckt und nützlich findet, schon morgen live gehen.

Das gilt nicht nur für Features der Anwendung selbst: Auch für die Sprachen HTML, CSS und JavaScript bietet das Web eine Fülle von Tools, die die Entwicklung sicherer, schneller und robuster machen: Beispielsweise Validatoren, Farbschema-Generatoren für CSS, UnitTest - Frameworks und JSLint/JSHint für JavaScript, Cross-Browser-Test-Tools, oder Web-Anwendungen wie jsfiddle fürs Prototyping oder Testen von Webanwendungen

Ebenso ist es mit neuen Browsern und Browserversionen. Immer wenn eine solche erscheint, muss SAP erst das Rendering für diese neue Version ausarbeiten und freigeben. Solange diese Freigabe noch nicht ausgeliefert ist, wird die Darstellung der Web-Dynpro-Inhalte komplett unterdrückt, und es erscheint stattdessen die lapidare Meldung "Sorry, your browser/program is not supported by Web Dynpro!" Das kann einem mit Server Pages nicht passieren. Wenn man standardkonformes HTML verfasst, werden die Seiten auf den standardkonformen Browsern (das sind, leicht vereinfacht gesagt, alle Browser mit Ausnahme des Internet Explorers) weiterhin korrekt dargestellt. Natürlich braucht man Skills, um Webanwendungen standardkonform zu entwickeln. Aber das ist eine triviale Aussage. Für alles im Leben braucht man Skills, um es gut zu machen.

Der von einem guten Webandwendungsentwickler auf Basis von Server Pages generierte HTML-Code ist klar lesbar und für jeden, der HTML kennt, nachvollziehbar – im Gegensatz zu dem Code, den das Web-Dynpro generiert: Dieser kann zwar vom Browser ausgeführt werden, ist jedoch für einen Menschen kaum lesbar. Für HTML gilt aber dasselbe wie für jeden Code: Lesbarer Code ist besser wartbar, erweiterbar, änderbar. Die Quelltextanzeige im Browser lässt sich bei Server Pages gut lesen und steht in einem klaren Zusammenhang mit den Pages, die ihn produziert haben.

Aber die Separation of Concerns? Sollte man nicht das Berufsprofil des ABAP-Entwicklers trennen von dem des Webdesigners? Ich habe das im Blog Collaboration of Concerns diskutiert. Nach meiner Ansicht kostet es nur mehr Geld und bringt keinen Nutzen, wenn man diese beiden Tätigkeiten organisatorisch trennt. Natürlich gibt es Entwickler mit unterschiedlichen Arbeitsschwerpunkten. Aber es bewährt sich, wenn alle an einer Webanwendung beteiligten Entwickler den gesamten Prozess vom Datenmodell bis zur Darstellung der Seiten im Browser kennen - so gut kennen, dass sie jederzeit auch in anderen als in ihren Schwerpunktbereichen Änderungen vornehmen können.

Aber Business Server Pages sind doch nicht "strategisch", sagen uns die SAP-Berater. Web Dynpro aber schon. Wirklich? Wenn strategisch im Sinne von langlebig gemeint ist, im Sinne einer Basis, auf der man getrost aufsetzen kann, weil das, was heute vom Stapel geht, auch in einer Dekade noch lauffähig ist - dann sind die strategischsten Standards des Webs, die ich kenne, immer noch HTML, CSS und JavaScript: Seit den 90er Jahren existieren diese Standards, sie sind auch heute quieklebendig – und werden mit grossem Aufwand weiterentwickelt.

[1] Ausnahme es sind CSS-Stylesheets erlaubt, mit denen auf Basis der vorgefertigten und nicht änderbaren HTML-Dokumentstruktur des SAP-Web-Dynpros einige Elemente geändert werden dürfen – Buttons dürfen beispielsweise einen anderen Farbton haben als den von SAP ausgelieferten.

Keine Kommentare :