Basisarchitekturen Web-basierter Informationssysteme; Architectures of Web-based information systems;

1 Einfuhrung

Seit seiner Erfindung zu Beginn der 90erJahre hat das World Wide Web (WWW) alsverteiltes Hypertextsystem eine damalswohl kaum geahnte Verbreitung gefunden.Obwohl moderne Websites mit ihren dy-namischen Inhalten und vielfaltigen Inter-aktionsangeboten bei außerer Betrachtungnicht mehr viel mit ihren spartanischenVorgangern gemein zu haben scheinen, be-ruhen sie auf denselben Basiskonzepten,namlich der Bereitstellung von Dokumen-ten, die in der TextauszeichnungsspracheHTML [BeCo95] erstellt sind und auf dieim Allgemeinen uber das Hypertext Trans-fer Protocol (HTTP) [Field99] zugegriffenwird.

Im einfachsten Fall wird ein Webserver da-zu eingesetzt, lediglich unveranderliche In-halte (Bilder, HTML-Seiten) zuganglich zumachen. Zur Abgrenzung von einer sol-chen rein statischen Nutzung der Web-infrastruktur wird im Folgenden untereiner Webanwendung ein Software-An-wendungssystem verstanden, das

& aufbauend auf WWW-Standards(HTML als Basisformat zur Reprasenta-tion von Inhalten, HTTP als Kommuni-kationsprotokoll)

& eine eigene Anwendungslogik realisiert,die

& einen bestimmten Dienst fur ihre An-wender erbringt.

In den letzten Jahren sind die Anforderun-gen an die Anwendungslogik immer mehrgewachsen, vom einfachen HTML-Bestell-formular, dessen Inhalt lediglich in einer

Datenbank erfasst wird, bis zur modernenE-Commerce-Anwendung, die eine Viel-zahl Such-, Darstellungs- und Konfigu-rationsmoglichkeiten bietet. Parallel ent-standen unterschiedlich komplexeBasissysteme zur Realisierung Web-basier-ter Informationssysteme, vom

& Einsatz der relativ einfachen CGI-Schnittstelle zur Anbindung externerProgramme an einen Webserver uber

& Systeme, bei denen Programmcode di-rekt in die HTML-Seiten eingebettetwird (Template-Prozessoren) bis zu

& den modernen Web-Application-Frame-works, welche sich durch die Trennungvon Darstellung und Ablauflogik undeinen objektorientierten Ansatz beson-ders fur die Entwicklung großerer Sys-teme eignen.

Nachfolgend werden in den Kapiteln 2–4diese drei Basisstrukturen von Webapp-likationen vorgestellt und bezuglich ihrerAnwendungsgebiete sowie ihrer Vor- undNachteile beleuchtet. Kapitel 5 zeigt da-nach am Beispiel des Systems Zope dieUmsetzung einiger fortschrittlicher Soft-warekonzepte.

2 CGI-basierte Systeme

Bereits sehr fruh wurde nach einer Mog-lichkeit gesucht, die Verarbeitung vonWeb-Input (z. B. Daten aus HTML-For-mularen) und die Erzeugung von dyna-misch generiertem HTML-Output zu er-moglichen, beispielsweise zur Darstellungder Ergebnisse einer Ad-hoc-Datenbank-abfrage. Dies sollte durch die Anbindungexterner Programme geschehen, die vom

WIRTSCHAFTSINFORMATIK 44 (2002) 3, S. 207–216

Der Autor

Wolfgang Weitz

Uniquon GmbH, Nahestraße 10,66578 Schiffweiler,E-Mail: [email protected]

Basisarchitekturen Web-basierterInformationssysteme

WI – State-of-the-Art

Webserver bei Bedarf gestartet werden, al-so keinen Eingriff in dessen Code erfor-dern. Die dazu benotigte Schnittstelle solltedurch eine moglichst große Zahl der aufden Webserverrechnern ublicherweise ver-fugbaren Programmiersprachen unterstutztwerden, auch, um vorhandenes Program-mier-Know-how unmittelbar nutzen zukonnen.

Aus dieser Situation heraus entwickeltesich das Common Gateway Interface(CGI, [CoRo99]), dessen Funktionsweisein Bild 1 gezeigt wird. Beim Abruf einervorher festgelegten URL startet der Web-server ein zugeordnetes externes Pro-gramm (hier: anmeldung.cgi). Die �ber-gabe der Daten aus der Web-Anfrage(beispielsweise Formular-Eingaben) unddie Ruckgabe der Antwort erfolgt durchdas Umleiten der Standardein- und Stan-dardausgabe des externen Programms. Dadies diejenigen Kanale sind, die ublicher-weise mit „Tastatureingabe“ und „Termi-nalausgabe“ verbunden sind, kann so ohneZusatzaufwand eine breite Palette von Pro-grammiersprachen verwendet werden.Weitere Informationen (etwa die IP-Adres-se des Client-Rechners) werden der ex-ternen Anwendung durch das Setzenbestimmter Umgebungsvariablen undKommandozeilenparameter mitgeteilt. DieAusgabe des Programms (in der Regel einHTML-Dokument) wird dann uber denWebserver als Antwort an den anfragendenClient zuruckgeliefert.

Durch seine geringen Anforderungen andie Implementierungssprache ermoglichteder pragmatische Ansatz des CGI die Lo-sung von Aufgaben wie etwa der Anbin-dung von ursprunglich nicht fur den Web-Einsatz vorgesehenen Legacy-Systemen.Hier genugt es mitunter schon, mit einemCGI-Programm die uber das Web empfan-genen Daten in geeigneter Form an die be-stehende Anwendung durchzureichen unddas Ergebnis in eine HTML-Darstellung

umzuwandeln. Der wesentliche Teil derAnwendungslogik verbleibt im Altsystem.

Mit dem wachsenden Interesse an Web-ba-sierten Informationssystemen und einemsteigenden Anspruch an deren Funktiona-litat entstanden immer mehr Webanwen-dungen, bei denen Kernfunktionalitaten di-rekt zum Webserver verlagert wurden.Dabei zeigten sich mit steigender Komple-xitat der Anforderungen Defizite des CGI-Konzepts.

Durch Verflechtung von Benutzungsober-flache (HTML), Ablauflogik und ggf.Webserverkonfiguration ergeben sich viel-faltige Abhangigkeiten, die ab einem be-stimmten Umfang des Gesamtsystemsschwer zu durchschauen sind und daherPflege und Wartung eines solchen Systemserschweren. So liegt der HTML-Code, derublicherweise sowohl das Aussehen derBenutzungsoberflache einer Webanwen-dung definiert als auch durch Links undFormulare die Abfolge der Dialogschrittevorschreibt, teilweise in Form von stati-schen HTML-Seiten vor, wahrend ein an-derer Teil von CGI-Programmen dyna-misch erzeugt wird. Daneben muss einemCGI-Programm zuvor in der Webserver-konfiguration eine spezielle URL zugeord-net worden sein, die ihrerseits wiederumz. B. in HTML-Links auftreten kann undso eine weitere Abhangigkeit darstellt.

Auch unter Performance-Aspekten erwei-sen sich klassische CGI-Anwendungen alsnicht ideal. Beim Abruf seiner URL wirdein CGI-Programm in der Regel als sepa-rater Prozess vom Webserver gestartet undnach Ruckgabe der generierten Antwortgleich wieder beendet. Insbesondere beiden fur CGI-Anwendungen oft eingesetz-ten interpretierten Programmiersprachenist allein schon der Aufwand, der durch

& Laden und Starten des Interpreterpro-gramms,

& die je nach Programmiersprache mogli-cherweise notwendige �bersetzung desProgramms in einen Zwischencode unddas

& Beenden des Interpreters

verursacht wird, fur einen betrachtlichenAnteil der Rechnerbelastung verantwort-lich, die bei jeder Ausfuhrung des CGI-Programms entsteht. Dieser Zusatzauf-wand fallt umso mehr ins Gewicht, jeeinfacher die im CGI-Programm selbst ab-gebildete anwendungsbezogene Funktio-nalitat ist.

Zur Steigerung der Leistung von CGI-An-wendungen wurden verschiedene Losun-gen entwickelt. Ein gangiger Ansatz ist dieEinbettung eines Skriptsprachen-Interpre-ters in den Webserver selbst, was den ebenerwahnten Overhead deutlich reduzierenkann. So wird beispielsweise in [Schil97]durch Nutzung eines eingebetteten Perl-Interpreters von einer Geschwindigkeits-steigerung um den Faktor 10 fur eine ein-fache Beispielapplikation berichtet.

Ein anderer Weg besteht darin, die CGI-Programme in langlaufende Prozesse ein-zubetten, die parallel zum Webserver lau-fen und uber Protokolle wie FastCGI(http://www.fastcgi.com) mit diesem kom-munizieren. Durch die Wiederverwendungvon CGI-Anwendungsprozessen und diedamit einhergehende Verringerung desAufruf-Overheads wird des Gesamtsys-tems entlastet. Das Prozessmanagementund die Kommunikation mit dem Web-server uber FastCGI erfolgt durch Hilfs-funktionen, welche die weitgehend modifi-kationsfreie Einbindung des bestehendenCGI-Programmcodes ermoglichen und diefur viele in diesem Umfeld verwendetenProgrammiersprachen verfugbar sind.

3 Template-Prozessoren

Mit zunehmender Etablierung von Web-anwendungen entstanden spezielle Werk-zeuge zur schnelleren und einfacherenRealisierung insbesondere solcher Appli-kationen, die uber einen hohen Anteil andynamisch erzeugten Seiten verfugen. EineKlasse solcher Werkzeuge sind die im Fol-genden als Template-Prozessoren bezeich-neten Systeme.

Template-Prozessoren ermoglichen dieEinbettung von Programmcode in eine(HTML-)Vorlage (Template). Bei seinem


www.server.comClient

POST /cgi-bin/anmeldung.cgi …

Ausgabe von

anmeldung.cgi

anmeldung.cgi

Start

Ausgabe

Bild 1 Common Gateway Interface (CGI)

208 Wolfgang Weitz

Abruf wird das Template durch Ausfuh-rung dieses Programmcodes vervollstan-digt und das Ergebnis uber den Webserverzuruckgeliefert (Bild 2). Die Anbindungdes Template-Prozessors an den Webserverkann uber das CGI oder (besser) durchEinbettung in den Webserver erfolgen.

In Bild 3 wird das Prinzip anhand des ver-breiteten Systems PHP [PHP02] gezeigt,bei dem der eingebettete Programmcode(im Bild grau unterlegt) ublicherweise indie Begrenzer „<?php“ und „?>“ einge-fasst wird.

Im Beispiel wird die PHP-Funktion „date“verwendet, um den aktuellen Wochentagherauszufinden. Daraufhin wird eine Hin-tergrundfarbe (grun fur das Wochenende,sonst rot) bestimmt. Schließlich wird zurDarstellung des entsprechend gefarbtenNamens des Wochentags mit Hilfe der„print“-Anweisung der entsprechendeHTML-Code in die umgebende HTML-Vorlage eingefugt.

Typischerweise verfugt eine in einenTemplate-Prozessor eingebaute Program-miersprache uber eine Fulle von Funktio-nen zur Losung gangiger Aufgaben bei derErstellung einer Webanwendung. Beispieledafur sind umfangreiche Moglichkeitenzur Zeichenkettenverarbeitung, einfacherZugriff auf relationale Datenbanken, Un-terstutzung bei der Auswertung vonHTML-Formulardaten oder Versand auto-matisch erzeugter E-Mails. Andere Syste-me (z. B. Microsoft ASP, [Weiss99]) stelleneine programmiersprachenunabhangige In-frastruktur zur Einbettung von Programm-code in Webseiten zur Verfugung, wo-durch alle Programmiersprachen genutztwerden konnen, welche diese Infrastrukturunterstutzen.

Wahrend typische CGI-Anwendungeneine Reihe einzelner Teilprogramme ent-halten, die HTML-Code ausgeben, gehenTemplate-Prozessoren also umgekehrt vorund betten die Ablauflogik in HTML-Templates ein. Dies kann auch als Aus-druck der starkeren Bedeutung der opti-schen Gestaltung von Webanwendungengewertet werden. Solange eine Webanwen-dung uber keine zu umfangreiche Ablauf-logik verfugt, lassen sich auf diese Weisemit verhaltnismaßig wenig Aufwand guteErgebnisse erzielen. Andererseits verleitetdie Einbettung von Programmcode inHTML jedoch dazu, zunachst einenHTML-Prototyp einer Webanwendung zu

erstellen und diesen dann sukzessive durchden Einbau von Programmcode mit der je-weils benotigten Funktionalitat zu ergan-zen. Dadurch leiten Fragen der visuellenGestaltung und der Navigationsstrukturdie Entwicklung des Gesamtsystems – oft

zu Lasten softwaretechnischer Architek-turerwagungen.

Trotz aller Vorteile von Template-Prozesso-ren fehlt also auch hier eine echte Entkopp-lung der Benutzungsoberflache (HTML)


Kernpunkte fur das Management

Bei der Realisierung eines Web-basierten Informationssystems muss eine adaquate tech-nische Basisarchitektur gewahlt werden. Diese Auswahlentscheidung wirkt sich auf Realisie-rungsaufwand, Wartbarkeit und langfristige Ausbaufahigkeit des Systems aus. Der Artikel

& gibt einen �berblick uber drei Ansatze fur solche Basisarchitekturen,& beleuchtet deren Vor- und Nachteile und& zeigt am Beispiel des Systems Zope einige innovative Losungsansatze.

Stichworte: objektorientierte Anwendungsentwicklung, Webanwendung

Basisarchitekturen Web-basierter Informationssysteme 209

von der Ablauflogik, wie sie spatestens seitdem Einzug der Objektorientierung in denBereich der Anwendungssoftware ublichist. Das Fehlen dieser Trennung fuhrt dazu,dass �nderungen der Kundenanforderungan das optische Erscheinungsbild einerWebanwendung, die gestalterisch einfachumzusetzen waren und von außen betrach-tet keine funktionale �nderung mit sichbringen, nicht selten großen Aufwand furdie Reorganisation des eingebetteten Pro-grammcodes nach sich ziehen. �hnlicheProbleme ergeben sich daraus, dass durchdie steigenden Anforderungen sowohl anGestaltung als auch an die Funktionalitatvon Webanwendungen die fruher ublichePersonalunion von Web-Designer undSoftwareentwickler immer seltener anzu-treffen ist. Ein nicht entsprechend ausgebil-deter Designer kann aber schwer abschat-zen, welche Auswirkungen seine�nderungen an einer HTML-Seite auf deneingebetteten Programmcode haben konn-te. Eine weitere Fehlerquelle entsteht durchden Einsatz grafischer HTML-Editoren,die den HTML-Code verbergen und unterUmstanden die in HTML nicht vorgesehe-nen Sondertags des Template-Prozessorsherausfiltern.

4 Frameworksfur Webapplikationen

Neuere Webapplikations-Frameworks un-terstutzen die Realisierung von Web-anwendungen auf Basis einer Mehr-Schich-ten-Architektur, die (zumindest) eineexplizite Trennung der drei Schichten

& Benutzungsoberflache(-n),& Anwendungslogik („business logic“)

und& Datenhaltung bzw. Anbindung anderer

externer Systeme

ermoglicht.

Wie bei Schichtenarchitekturen ublichgreift jede Schicht zur Bewaltigung ihrerAufgaben ausschließlich auf die Diensteder jeweils darunter liegenden Schicht zu-ruck, was eine klare Trennung der Zustan-digkeiten erleichtert.

In der Regel werden auch bei diesen Syste-men HTML-Templates zur Erzeugung derBenutzungsoberflache verwendet. Aller-dings dient der in das HTML eingebetteteZusatzcode hier idealerweise lediglich zurRealisierung von Funktions- oder Metho-

denaufrufen in die Schicht der Anwen-dungslogik hinein. Programmiersprach-liche Konstrukte wie IF-Statements oderSchleifen sind nur eingeschrankt vorhan-den und werden nur fur oberflachenbezo-gene Aufgaben eingesetzt, beispielsweisedie Erzeugung einer HTML-Tabelle durchIteration uber eine Listenstruktur, welchevia Methodenaufruf von der Anwendungs-logik geliefert wurde.

Die Trennung von Benutzungsoberflacheund Anwendungslogik offnet auch denWeg zum Einsatz bewahrter Universalpro-grammiersprachen und -werkzeuge: Durchdie Entfernung Web-spezifischer Anforde-rungen aus der Ebene der Anwendungs-logik ruckt die Entwicklungsarbeit wiedernaher an die klassische Anwendungsent-wicklung heran, wodurch die dort gewon-nenen Erfahrungen fur die erfolgreicheRealisierung großer Webanwendungenleichter nutzbar gemacht werden konnen.

Zunehmend wichtig wird auch die gleich-zeitige Unterstutzung unterschiedlicherFormate im Bereich der Benutzungsober-flache: Inhalte und Funktionen der Web-applikation sollen neben HTML immer of-ter auch in dem Format WML fur denWAP-Zugriff uber das Handy oderVoiceXML zur Steuerung von Sprachapp-likationen verfugbar gemacht werden kon-nen, und das nach Moglichkeit ohne Repli-kation der auf der Mittelschicht realisierterFunktionalitat fur jedes Ausgabemedium.Auch vor diesem Hintergrund zeigt sichdie Notwendigkeit einer klaren Trennungvon Inhalt und dessen Prasentation(en),um ein auf Dauer wart- und erweiterbaresSoftwaresystem zu erhalten. Einige Frame-works unterstreichen diesen Aspekt sogardurch das Einziehen einer eigenen, XML-basierten Zwischenschicht. Hier werdenauszugebende Inhalte zunachst in Formmedienunabhangiger XML-Instanzen er-zeugt und mit Hilfe eines anschließend da-rauf angewandten XSLT-Stylesheet in dasgewunschte Zielformat (wie HTML) trans-formiert.

Um die Erstellung anspruchsvoller Web-anwendungen mit umfangreicher Funktio-nalitat zu erleichtern, entstanden Soft-warepakete, welche (oft objektorientierte)Implementierungen vieler Basisfunktionenals Teile eines modularen Frameworks be-reitstellen. Diese unterstutzen Aspekte wie

& HTML-Erzeugung,& Objektpersistenz,

& Transaktionen,& Zugriff auf relationale Datenbanken,& Verteilung, Skalierbarkeit, Ausfallsicher-

heit und& Zugriffskontrolle.

Die Java 2 Enterprise Edition (J2EE)[Mons00] umfasst eine Reihe solcher Kom-ponenten und ist ein weithin bekanntesBeispiel einer Basis-Infrastruktur fur großeWeb-Applikationssysteme. Ein wenigerbekanntes System, das jedoch einige unge-wohnliche und innovative Konzepte reali-siert, ist Zope („Z Object PublishingEnvironment“), das nachfolgend vor-gestellt wird.

5 Zope

Zope [LaPe00] wurde ursprunglich alskommerzielles Produkt von dem US-Un-ternehmen Digital Creations (heute: ZopeCorporation) entwickelt. Unter dem Ein-fluss eines Venture Capitalist entschlosssich der Hersteller jedoch, sein Produktals Open Source Software kostenlos abzu-geben, die Weiterentwicklung zusammenmit der sich bildenden weltweiten Com-munity voranzutreiben und sein Business-Modell in Richtung Consulting auszurich-ten, was auch erfolgreich umgesetzt wurde[Wash99].

Bis auf einige aus Effizienzgrunden in Crealisierte Module ist Zope in der objekt-orientierten Programmiersprache Python[Lutz96] implementiert und lasst sich indieser Sprache erweitern. Die Ergebnisseeiner empirischen Studie [Prec00] beschei-nigen Python bezuglich Speicherverbrauchund Laufzeit ein Verhalten, das oft besserals bei Java und „nicht deutlich schlechter“als C oder Cþþ ist, dies jedoch bei einerhoheren Produktivitat im Sinne einer kur-zeren Entwicklungszeit bei der Losung desvorgelegten Problems. Der Kern diesesdem Vergleich zu Grunde liegenden Prob-lems bestand in Such- und Zeichenketten-verarbeitungsoperationen, also Aufgaben,die gerade in der Entwicklung Web-basier-ter Informationssysteme nicht selten anzu-treffen sind.

Zur Sicherung der Softwarequalitat existie-ren zu fast allen Zope-Systemkomponen-ten Testklassen, welche die spezifikations-konforme Funktion der Komponenteuberprufen („Unit Tests“). Diese Art eineroperationalisierten Spezifikation, wie sie imRahmen des Extreme-Programming-An-


210 Wolfgang Weitz

satzes [Beck99] vorgeschlagen wurde, un-terstutzt die Qualitatssicherung insbeson-dere auch bei der angestrebten Einbindungvon außerhalb der Zope Corporation ste-henden Mitgliedern der Community in dieWeiterentwicklung des Systems.

Zope erfullt etliche der Anforderungen, diean ein modernes Webapplikations-Frame-work gestellt werden, durch die Bereitstel-lung innovativer Konzepte, die in anderenSystemen in dieser Form noch nicht reali-siert wurden. Einige dieser Konzepte wer-den im Anschluss an eine kurze �bersichtuber die Systemarchitektur vorgestellt.

5.1 Systemubersicht

Bild 4 veranschaulicht das Zusammenwir-ken der Kernkomponenten von Zope. DerZServer stellt die Schnittstelle zum Internetdar. Er nimmt Verbindungsanfragen (bei-spielsweise eine HTTP-Anfrage von einemWeb-Browser) entgegen und ubergibt dieAnfrage zur weiteren Verarbeitung an denZPublisher. Falls gewunscht kann Zopeauch als Erganzung zu einem der bekann-ten Webserver wie Apache oder MicrosoftIIS betrieben und uber Verfahren wieFastCGI oder PCGI (Persistent CGI) andiesen angebunden werden.

Der ZPublisher ubersetzt – abhangig vondem verwendeten Netzwerkprotokoll –Anfragen in Zugriffe auf die Objekte in derdarunterliegenden Zope-Core-Schicht. Erist modular aufgebaut, sodass eine Erweite-rung um weitere Netzwerkprotokolle mitwenig Aufwand moglich ist.

Neben HTTP wird momentan auch derZugriff auf die von Zope verwalteten Ob-jekte uber das FTP-Protokoll unterstutzt.Daruber hinaus sind auf HTTP aufsetzen-de Protokolle wie WebDAV und XML-RPC implementiert. WebDAV (Web Dis-tributed Authoring and Versioning)ermoglicht es, auf Zope wie auf einen FileServer zuzugreifen und die dort abgelegtenInhalte mit der gewohnten Anwendungs-software (z. B. MS Office) zu pflegen.XML-RPC [SLDJ01] auf der anderen Seiteist ein Remote-Procedure-Call-Protokoll,das fur eine Vielzahl von Programmier-sprachen implementiert wurde und einentransparenten Zugriff auf die in Zope ange-legten Objekte von externen Programmenaus uber das Internet ermoglicht.

Die Zope-Core-Schicht enthalt verschiede-ne Dienstobjekte wie beispielsweise einenObjektkatalog, Benutzer- und Rechtever-waltung, eine HTML-basierte Administra-tionsschnittstelle und vieles mehr. Der Ob-jektkatalog indiziert Attribute der in derZope Object Database (ZODB) abgelegtenObjekte und erlaubt so eine schnelle Feld-oder Volltextsuche (einschließlich boole-scher Verknupfungen). Bei Grundoperatio-nen wie Einfugen, Loschen und �ndernkann der Katalog automatisch aktualisiertwerden und ist damit stets auf dem neues-ten Stand.

Die Core-Schicht ist durch zusatzlicheModule (so genannte Products) erweiter-bar, in denen verschiedene Klassen mit Sys-temerweiterungen oder Anwendungslogikbereitgestellt werden. Eine Zope-Anwen-dung setzt sich in der Regel aus (kooperie-renden) Instanzen solcher Klassen zusam-men. Im Bild 4 ist beispielsweise einProduct angedeutet, das den Zugang zueiner externen relationalen Datenbank(RDBMS) realisiert.

Die Zope Object Database dient dazu, dieZustande der in Zope angelegten Objektedauerhaft zu speichern (Objektpersistenz).Da jede Web-Anfrage als einzelne Trans-aktion behandelt wird, konnen, falls wah-rend der Abarbeitung einer Transaktionein Fehler auftritt, alle bis dahin geandertenObjekte wieder in einen konsistenten An-fangszustand zuruckgesetzt werden.

Die ZODB stutzt sich auf ein Storage-Modul, das von dem darunterliegendenSpeichersystem abstrahiert. Durch ein-faches Auswechseln des Storage-Modulskann Zope seine Objektdaten z. B. in einer

einfachen Datei, in einer relationalen Da-tenbank oder (via Netzwerk) auf einem se-paraten Storage-Server verwalten, der sei-nerseits mehrere Zope-Applikationsserverbedient (ZEO – Zope Enterprise Option).

Bei �nderungen eines Objektzustandswird der neue Zustand in die Datenbankaufgenommen, der alte aber nicht gleichuberschrieben. Die ZODB kann ihren Be-nutzern dadurch sehr weitgehende„Undo“-Funktionen anbieten. Sie erlaubtvom einfachen Tippfehler bis zur ver-sehentlichen Loschungen ganzer Objekt-hierarchien eine konsistente Wiederherstel-lung des fruheren Zustands. BeiHTML-Objekten wird zudem der direkteZugriff auf fruhere Stande des Textes un-terstutzt.

Die Anbindung relationaler Datenbankenerfolgt uber ein zweischichtiges Konzept,das einerseits aus SQL-Objekten besteht,welche eine konkrete SQL-Anfrage kap-seln, und andererseits aus Datenbank-Adaptern, auf die sich die SQL-Objektebeziehen und welche den Zugang zu einerkonkreten Datenbank darstellen. Bei Ver-zicht auf syntaktische SQL-Eigenheiten istes durch diese Trennung moglich, alleindurch Auswechseln des Datenbank-Adap-ters eine Umstellung auf ein anderes Da-tenbanksystem zu bewerkstelligen. VieleDatenbank-Adapter ermoglichen zudemeine Integration mit den ZODB-Trans-aktionen (gemeinsames Commit/Abort).

Bereits in der Architekturbeschreibungwurde erwahnt, dass die Abarbeitung bei-spielsweise einer HTTP-Anfrage vomZPublisher in den Aufruf einer Methodeeines Ziel-Objekts umgesetzt wird. Im Ge-


ZopeZServer

ZPublisher

Zope Core

Products

ZODB

http, ftp, …

z. B. DB-FileRDBMS

Storage

Bild 4 Zope-Softwarearchitektur


gensatz zu den meisten anderen Systemen,die zumindest „einfache“ Inhaltsbestand-teile wie Bilder oder statische HTML-Sei-ten als gewohnliche Dateien im Filesystemdes Webservers ablegen, reprasentiert Zopealle Inhalte durchgangig als Objekte undverwaltet sie in der Objekt-Datenbank. Sogenannte Container-Objekte konnen selbstwieder andere Objekte enthalten und bil-den somit die bekannten Ordner bei File-system-basieren Systemen nach. Jedes Ob-jekt verfugt uber einen (innerhalb desumgebenden Containers) eindeutigen Na-men, der beim Anlegen des Objekts anzu-geben ist.

Bei umfangreicheren Anwendungen ist esnicht moglich, alle Objekte gleichzeitig imHauptspeicher zu halten. Zope verwaltetdaher einen (parametrisierbaren) Objekt-Cache und „deaktiviert“ solche Objekte,die langere Zeit unbenutzt blieben. Wirdumgekehrt ein gerade nicht im Hauptspei-cher befindliches Objekt referenziert, sostellt Zope es automatisch aus der Objekt-datenbank wieder her.

Der durchgangige Objektansatz bringt eineReihe offensichtlicher Vorteile mit sich, et-wa die einfache Erweiterung bestehenderStandard-Objekttypen. Beispielsweise istes moglich, abgeleitete Klassen mit zusatz-lichen Attributen zu erzeugen. So kann et-wa ein abgeleiteter Objekttyp fur Bilderbereitgestellt werden, der ein Attribut miteinem beschreibenden Text enthalt und somit wenig Aufwand auch Bilder einer Voll-

textsuche zuganglich macht. Nachteiligwirkt sich der großere Verarbeitungsauf-wand des Objektansatzes dagegen etwa beider Speicherung sehr großer (Audio-, Vi-deo-)Dateien in der Objektdatenbank aus.

Bis auf die Installation neuer Erweite-rungsmodule (Products) lasst sich Zopevollstandig uber eine eingebaute Web-schnittstelle verwalten (Bild 5), welche dieZope-Objekte in der bekannten, einemDateisystem-Explorer nachempfundenenArt prasentiert. Viele Objekte unterstutzenverschiedene Ansichten, die sich uber Rei-ter abrufen lassen. Das Anlegen eines neu-en Objekts erfolgt uber ein Pop-up-Menu,das alle fur den betreffenden Benutzer ver-fugbaren Objekttypen anbietet.

Durch das unten naher behandelte, fein-kornige Zugriffsschutzkonzept ist es mog-lich, die Administration von Container-Objekten („Ordnern“) und deren Inhaltflexibel an andere Benutzer zu delegierenund diesen dabei beliebig weitgehendeRechte (einschließlich des Anlegens undLoschens neuer Benutzer) zu geben, dieaber andererseits strikt auf ihren Containerbeschrankt bleiben. Diese ohne zusatz-lichen Programmieraufwand verfugbareFunktionalitat ist besonderes beim Aufbauvon so genannten Community Sites vongroßem Vorteil, bei denen eine (unter Um-standen sehr große) Anzahl von Mitglie-dern jeweils ihre eigenen Inhalte pflegensoll, ohne sich dabei gegenseitig beein-trachtigen zu konnen.

5.2 Object Publishingund dynamische Vererbung

Eines der Kernkonzepte von Zope ist dasdes „Object Publishing“. Jede (gultige)URL wird vom ZPublisher als eine Pfad-angabe zum Zugriff auf eines der von Zopeverwalteten Objekte (bzw. dessen Attributoder Methode) interpretiert. Die URLhttp://www.demo.de/kunden/meier/be-stellstatus konnte beispielsweise zur Loka-lisierung des Objekts mit dem Namen„meier“ im Containerobjekt „kunden“und anschließend zum Aufruf der Methode„bestellstatus()“ von „meier“ fuhren, wel-che dann eine HTML-Antwort mit den ge-wunschten Informationen erzeugt.

Anzumerken ist dabei, dass jedes Contai-nerobjekt die Zustandigkeit fur das Lokali-sieren „seiner“ Unterobjekte selbst uber-nehmen kann, indem es die entsprechendeMethode re-implementiert. Dadurch lassensich auf einfache Weise beliebig flexibleModifikationen des URL-Interpretations-vorgangs realisieren. So konnte im URL-Beispiel aus dem vorhergehenden Absatzdas Containerobjekt „kunden“ seine Un-terobjekte wie „meier“ auch dynamisch er-zeugen, beispielsweise durch Ruckgriff aufdie aktuellen Daten eines Bestellungsver-folgungssystems. Auch solche dynamischerzeugten Objekte sind voll in die Zope-Infrastruktur eingebunden. So kann in derzuvor vorgestellten Zope-Webschnittstelledas „kunden“-Objekt wie ein gewohn-licher Ordner dargestellt werden, das ge-offnet werden kann und daraufhin die ak-tuell enthaltenen Kundenobjekte anzeigt.�hnliches gilt auch fur die weiter untenvorgestellten Mechanismen wie z. B. denZugriffsschutz.

Ein Alleinstellungsmerkmal von Zope, dasdurch den konsequenten Objektansatz rea-lisierbar wurde, ist eine Art dynamischerVererbung von Attributen und Methoden,die in [GiLo96] beschrieben ist und als Um-gebungsakquisition (environmental acqui-sition) bezeichnet wird. Technisch gesehenhandelt es sich dabei um eine Erweiterungdes Verfahrens zur Namensauflosung (z. B.von Attributen oder Methoden): Versuchtein Objekt auf ein Attribut oder eine Me-thode zuzugreifen, uber die es selbst (auchuber die „normale“, statische Vererbung)nicht verfugt, so werden sukzessive dieNamensraume seiner Containerobjektedurchsucht, bis der Name aufgelost werdenkonnte oder die Wurzel (das außerste Con-


Bild 5 Administrationsschnittstelle

212 Wolfgang Weitz

tainerobjekt) erreicht ist. Das Objekt „ak-quiriert“ im Erfolgsfall aus seiner Umge-bung beispielsweise eine Methode, die sichin ihrer Ausfuhrung (z. B. beim Zugriff aufInstanzvariablen) dann auf dieses Objektselbst bezieht (und nicht auf dasjenige, vomdem sie akquiriert wurde). Man spricht indem Zusammenhang auch vom Akquisi-tionskontext dieserMethode.

Die Vorzuge dieses Konzepts gerade furWebanwendungen lassen sich anhand einesBeispiels verdeutlichen. Zur Wahrung derCorporate Identity seien die Willkom-mens-Webseiten fur alle Abteilungen einesUnternehmens einheitlich zu gestalten; ineine entsprechende Vorlage werden nur derAbteilungsname und das Abteilungslogoeingesetzt. Bild 6 zeigt, wie sich diese Auf-gabe mit Hilfe des Akquisitionsmechanis-mus elegant losen lasst: Das gemeinsameHTML-Template „welcome.html“ ist aufdie Ebene eines gemeinsamen Container-objekts herausgezogen worden. Das Tem-plate enthalt keine abteilungsspezifischenAngaben, sondern lediglich einen HTML-Tag, um ein Bild „logo“ einzubinden, und(in der Abbildung nicht enthalten) einenweiteren Tag, um den Wert eines Abtei-lungsnamen-Attributs einzubetten.

Die Antwort auf eine Anfrage mit derURL „http//www.firma.de/Marketing/welcome.html“ ergibt sich dann wie folgt:Nachdem festgestellt wurde, dass das(Container-)Objekt „Marketing“ im Wur-zel-Containerobjekt enthalten ist, wird in„Marketing“ nach dem Namen „wel-come.html“ gesucht. Da „Marketing“selbst kein Subobjekt dieses Namens hat,akquiriert es dasjenige aus dem ubergeord-neten Wurzelordner. Akquisitionskontextfur „welcome.html“ ist nun das „Marke-ting“-Objekt, daher wird automatisch das„richtige“ Logo referenziert und auch der„richtige“ Abteilungsname eingefugt. DieErzeugung der Willkommensseite fur dieNachbarabteilung „Vertrieb“ fuhrt auchhier auf gleiche Weise zum erwunschtenResultat.

Akquisition ist ein zunachst ungewohnter,aber sehr machtiger Mechanismus, der inZope an vielen Stellen Einsatz findet. Er er-moglicht das „Herausfaktorisieren“ von ge-meinsam genutzten Objekten wie Bildern,SQL-Anfragen oder Zugriffskontroll-Ein-stellungen und ermoglicht bei entsprechen-dem Einsatz auf elegante Weise, Redundan-zen zu vermeiden und dadurch dieWartbar-keit derWebanwendung zu erhohen.

5.3 Zugriffskontrolle

Ein Zugriff auf Zope-Objekte erfolgt stetsunter der Kontrolle eines rollenbasiertenRechtekonzepts. Bei der Implementierungeines Zope-Objekts kann bis auf Metho-denebene herab deklarativ bestimmt wer-den, welche Rechte fur den Zugriff erfor-derlich sind. Diese Rechte kann derImplementierer dabei frei festlegen und be-nennen. Die Zuordnung von Rechten zuRollen wird außerhalb des Objekt-Pro-grammcodes durchgefuhrt, ublicherweiseuber eine Rechtematrix, welche beispiels-weise uber die Webschnittstelle von Zopekonfiguriert werden kann. Dadurch, dassdiese �berwachung der Zugriffskontrolleaußerhalb des Codes der auf Zope aufset-zenden Webanwendung erfolgt, sinkt dieGefahr von Sicherheitslucken durch Fehlerdes Anwendungsentwicklers.

Die Methoden, die zur �berprufung vonZugriffsrechten benutzt werden, stellt einsogenanntes User-Folder-Objekt bereit. JeContainer kann durch Hinzufugen einesentsprechenden User Folders individuellfestgelegt werden, welches Authentifika-tionsverfahren eingesetzt werden soll. Ne-ben dem Standardverfahren von uber einWeb-Interface anlegbaren Benutzerobjek-

ten kann alternativ auf eine UNIX-Pass-wortdatei, einen Windows Domain Con-troller, ein LDAP-Directory oder andereSysteme zuruckgegriffen werden. Durchden Akquisitionsmechanismus ist ein UserFolder automatisch auch fur die Unter-objekte des Containers sichtbar.

5.4 HTML-Generierung

Die dynamische Erzeugung von HTML-Ausgaben gehort naturgemaß zu denKernfunktionen eines Webapplikations-Frameworks. Die momentan verbreitetsteMethode zur Integration der benotigtenKonstrukte (Schleifen, Darstellen von Va-riablenwerten, Bedingungen etc.) in dieHTML-Vorlage, wie sie beispielsweise inProdukten wie Java Server Pages (JSP), Mi-crosoft Active Server Pages (ASP) und an-deren realisiert wird, ist die Einfuhrungneuer Elemente auf der gleichen syntakti-schen Ebene wie die HTML-Tags. Dieskann aus den bereits im Abschnitt 3 dar-gestellten Grunden bezuglich des Einsatzesvon HTML-Editoren bzw. der Anfalligkeitgegen Beschadigungen bei Layout-�nde-rungen problematisch sein. Auch Zope bie-tet mit DTML (Document Template Mark-up Language) eine Templatesprache an, die


VertriebMarketing

M V

logo logo

welcome.html

/

Marketing

M

Vertrieb

V

http://www.firma.de/Marketing/welcome.html http://www.firma.de/Vertrieb/welcome.html

<img

src=logo>

www.firma.de

Bild 6 Beispiel fur Akquisition


auf einer Menge von Spezialtags beruhtund daher ebenso zu bewerten ist.

Aus diesem Grund wurden als Alternativedie so genannten ZopePageTemplates (ZPT)entwickelt, bei denen mit der Template At-tribute Language (TAL) eine ungewohn-liche Losung gefunden wurde. Anstatt neueTags einzufuhren, werden die oben bereitserwahnten Konstrukte in Form von Attri-buten in gewohnliche HTML-Tags einge-bracht. So bewirkt beispielsweise folgendeErweiterung des <title>-Tag

<title tal:content¼“here/dokument-name“>Beispielname</title> ,

dass bei der Darstellung des Templates derInhalt (content) des Tags (hier: „Beispiel-name“) durch das Ergebnis des Ausdrucks„here/dokumentname“ ersetzt wird, wobei„here“ der aktuelle Akquisitionskontextfur das Template ist und „dokumentname“ein Attribut oder eine Methode aus diesemKontext. Analog gibt es Attribute, um dieWiederholungen des umgebenden HTML-Elements (und seines Inhalts) ermoglichenoder ein HTML-Element – abhangig voneiner Bedingung – zu unterdrucken.

Ein Vorzug dieses Ansatzes liegt darin,dass ein Template auf diese Weise Fulltexteenthalten kann, die zwar (wie „Beispiel-name“ oben) bei der Ausfuhrung des Tem-plates von Zope ersetzt werden (also nichtstoren), es aber andererseits ermoglichen,dasselbe Template auch außerhalb vonZope mit einem normalen Browser anzuse-hen und dadurch insbesondere wahrendder Layout-Phase ein realistischeres Bildder Darstellung zu erhalten. Zudem schei-nen grafische HTML-Editoren gegenuberfremden Attributen toleranter zu sein alsgegenuber unbekannten HTML-Tags, dievon einigen dieser Werkzeuge herausgefil-tert werden.

In einer Webapplikation gibt es in der Re-gel ein Basis-Layout (grobe Seitenauftei-lung: Position der Navigationsleiste, einesLogos etc.), nach dem die einzelnenHTML-Seiten der Anwendung zu gestal-ten sind. Dabei werden sich wiederholendeHTML-Blocke aus Grunden der leichteren(zentralen) Anpassbarkeit oft in separateDateien ausgelagert und bei Bedarf uber ei-ne entsprechende Anweisung der Tem-plate-Sprache in die jeweilige HTML-Seitehineinkopiert.

Wahrend dieses Vorgehen bei einfachen, insich abgeschlossenen Strukturen praktika-

bel ist, genugt es nicht, um eine seitenweiteLayout-Vorlage, wie sie oft durch eineHTML-Tabellenstruktur vorgegeben wird,aus den einzelnen Seiten herauszufaktori-sieren. Einfaches Kopieren genugt hiernicht, da gewisse Zellen der Layout-Tabelleabhangig von der referenzierenden Seitegefullt werden mussen. Die Konsequenzist, dass die gemeinsame Layout-Tabellen-struktur mit Varianten auf allen HTML-Seiten repliziert wird. Konsistente Layout-�nderungen werden dadurch rechtaufwandig.

Zope bietet hier mit dem Makro-Mecha-nismus der PageTemplates („metal“) eineLosungsmoglichkeit an, deren Funktions-weise in Bild 7 skizziert ist. In einerHTML-Vorlage werden ein oder mehrereHTML-Elemente durch entsprechendeSpezialattribute als Makros kenntlich ge-macht. Innerhalb eines solchen HTML-Elements konnen wiederum eingeschlosse-ne HTML-Elemente zu so genannten„Slots“ erklart werden, die bei der Verwen-dung des Makros durch Makroparameterersetzt werden konnen.

Zur Verwendung eines Makros wird die-ses zunachst (durch das Spezialattribut„metal:use-macro“) referenziert und danndie Belegung der Slots angegeben (Pfeile1a, 1b). Das Makro ersetzt schließlich inder aufrufenden Seite dasjenige HTML-Element, durch das es referenziert wurde(Pfeil 2) – im Beispiel ist dies die gesamteSeite (das ganze <html>-Element).

Der Makro-Mechanismus erlaubt auf ele-gante Weise das Referenzieren und Parame-trisieren von HTML-Layout-Vorlagen undvermeidet die Replikation von Elementendes Basis-Layouts in die einzelnen Seitenhinein. Globale, konsistente Anpassungendes außeren Erscheinungsbilds der Web-anwendung werden dadurch erleichtert.

5.5 Anwendungsbereiche

Durch seinen modularen Aufbau und seineauf Erweiterbarkeit ausgelegte Architekturlasst sich eine große Spannweite von An-wendungsszenarien mit Zope realisieren.Besonders geeignet erscheint Zope fur dieRealisierung von Systemen, deren Inhalteoft aktualisiert und dabei von unterschied-lichen Personen gepflegt werden mussen(Community Sites, Nachrichten-Portaleetc.). Hier erspart die umfangreiche Rech-teverwaltung mit der Moglichkeit zur

Delegation von Administrationsaufgaben,die eingebaute Web-Administrations-schnittstelle, die Fehlerkorrekturmoglich-keit („undo“-Fahigkeit) und Recherche-moglichkeit (Objektkatalog) der ZODBviel Implementierungsaufwand. Das ZopeContent Management Framework (CMF)bietet zudem u. A. die Unterstutzung vonRedaktionsworkflows sowie Werkzeugefur Personalisierung und Metadaten nachdem DublinCore-Standard an.

Ein Beispiel fur eine mit Zope realisierteCommunity Site ist der Server vonzope.org selbst, auf dem sich interessierteBenutzer einen eigenen Account einrichtenund dort Dokumente oder Software able-gen konnen. Die Organisation dieses Ser-vers liefert ein gutes Anschauungsbeispielfur Einsatz und Zusammenwirken ver-schiedener Zope-Komponenten. So stelltdas integrierte Zugriffsschutzkonzept si-cher, dass jeder Benutzer seinen eigenenArbeitsbereich frei organisieren kann (etwadurch eine individuelle Ordner-Struktur),gleichzeitig aber auch auf diesen Bereichbeschrankt bleibt. Will ein Benutzer ein In-haltsobjekt (etwa einen Erfahrungsbericht)fur alle Besucher der Website freigeben, sodurchlauft das betreffende Inhaltsobjektzuerst einen Redaktionsworkflow, in des-sen Verlauf es einem (anderen) Benutzermit Redakteur-Rolle zur Beurteilung vor-gelegt wird. Nach dessen Bestatigung wer-den die Zugriffsrechte fur dieses Objektdurch die Workflow-Komponente gean-dert und das Inhaltsobjekt wird fur die �f-fentlichkeit sichtbar. Die auf der Websitesichtbaren themenorientierten Zusammen-stellungen von Hilfsdokumenten, Soft-warepaketen usw. werden durch Anfragenan den Zope-Objektkatalog dynamisch er-zeugt. Es ist also nicht notwendig, gleich-artige Inhalte auch nach Typ geordnetzusammen zu speichern. Das Zusammen-wirken der Komponenten Objektkatalog,Workflow und Rechtesystem erlaubt eineindividuelle Verwaltung der Inhalte durchihre Autoren und gleichzeitig eine einheit-liche, benutzerubergreifende und flexibleZusammenstellung zusammengehorigerInhalte zur Prasentation nach außen. Die-ses kleine Beispiel zeigt bereits, wie durchRuckgriff auf die in einem solchen Frame-work bereitgestellten Basisfunktionalitatender eigene Implementierungsaufwand fureine konkrete Webanwendung deutlich re-duziert werden kann.

Weniger geeignet erscheint Zope fur An-wendungen, bei denen viele große Dateien


214 Wolfgang Weitz

abgefragt werden (Audio/Video). Auchgibt es bislang nicht die Fulle von Schnitt-stellen zu externen Systemen, wie sie bei-spielsweise fur Java zur Verfugung stehen.

Die ZODB ist fur hohe Leseraten und (imVergleich dazu) eher seltene Schreibopera-tionen optimiert (eine Konstellation, diefur die meisten Webanwendungen wohlden Regelfall darstellt). Sie implementiertein optimistisches Protokoll beim Schrei-ben („commit“) eines Objektzustands, daseine Transaktion nach dreimaligem Auftre-ten eines Schreibkonflikts zurucksetzt.Dies fuhrt offensichtlich zu Problemen beiAnwendungen mit haufigen, parallelenObjektanderungen.

6 Zusammenfassung

In diesem Artikel wurden drei technischeAnsatze zur Realisierung Web-basierterAnwendungssysteme vorgestellt. Obwohldie Reihenfolge der Prasentation auch diezeitliche Entwicklung und die damit ein-hergehende Etablierung von Webanwen-dungen im Bereich der allgemeinen An-wendungsentwicklung widerspiegelt, sindalle drei Basiskonzepte bis heute in ver-schiedenen Anwendungsbereichen im Ein-satz.

Werkzeugseitig unterstreicht der �bergangvom pragmatischen CGI-Ansatz uber dieGruppe der Template-Prozessoren zu denWeb-Application-Frameworks ebenfallsdie wachsende Spannbreite der Anforde-rungen an diese Art von Anwendungssys-temen und ihre unterschiedlich umfangrei-che Anwendungslogik.

Gleichzeitig wurde deutlich, dass jeder derAnsatze auch heute noch (berechtigterwei-se) zum Einsatz kommt, wobei ein wichti-ges Auswahlkriterium die Komplexitat derzu realisierenden Anwendungslogik ist.Sowohl in der Gruppe der Template-Pro-zessoren wie auch gerade bei den Web-Ap-plication-Frameworks ist mittlerweile eineVielzahl von Implementierungen mit un-terschiedlichen Schwerpunkten verfugbar,von denen hier Zope als ein Beispiel naherbetrachtet wurde.

Vor einer Entscheidung fur eine Software-plattform ist es vor demHintergrund dieserVielfalt umso wichtiger, eine sorgfaltige An-forderungsanalyse fur die gesamte zu ent-wickelnde Webapplikation unter Einbezie-hung aller relevanten Schnittstellen und dertangierten Geschaftsprozesse durchzufuh-ren. Erst auf dieser Grundlage kann eineBasistechnologie ausgewahlt werden, wel-che die Umsetzung der Anforderungenadaquat unterstutzt und die fur den gesam-ten geplanten Lebenszyklus der Anwen-dung ausreichend tragfahig erscheint.

Literatur

[BeCo95] Berners-Lee, T.; Connolly, D.: HypertextMarkup Language – 2.0.http://www1.ics.uci.edu/pub/ietf/html/rfc1866.txt, 1995-11, Abruf am 2002-01-06.

[Berg01] Bergsten, Hans: JavaServer Pages. O’Reil-ly, Sebastopol 2001.

[CoRo99] Coar, Ken A. L.; Robinson, D. R. T.:The WWW Common Gateway Interface.http://cgi-spec.golux.com/draft-coar-cgi-v11-03.txt, 1999-06-25, Abruf am 2002-01-06.

[Field99] Fielding, Roy T. et al.:Hypertext TransferProtocol – HTTP/1.1.http://www.w3.org/Protocols/rfc2616/rfc2616.html, 1999-06, Abruf am2002-01-06.

[GiLo96] Gil, J.; Lorenz, D.: Environmental Ac-quisition – A New Inheritance-Like AbstractionMechanism. Proc. OOPSLA 1996, ACMSIGPLAN, 1996.

[LaPe00] Latteier, Amos; Pelletier, Michel: TheZope Book. New Riders Publ., 2000.

[Lutz96] Lutz, Mark: Programming Python.O’Reilly, Sebastopol 1996.

[Mons00] Monson-Haefel, Richard: EnterpriseJavaBeans. 2. Auflage, O’Reilly, Sebastopol2000.

[PHP02] Apache Software Foundation: PHP: Hy-pertext Preprocessor (Homepage).http://www.php.net, Abruf am 2002-01-12.

[Prec00] Prechelt, Lutz: An empirical comparisonof C, Cþþ, Java, Perl, Python, Rexx, and Tcl fora search/string-processing program. TechnicalReport 2000-5, Universitat Karlsruhe, Fakultatfur Informatik, Marz 2000.http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf, 2000-03, Abruf am 2002-02-09.

[Schil97] Schilli, Michael: Apaches CGI-Ausfuh-rung beschleunigen. In: iX – Magazin fur pro-fessionelle Informationstechnik, 7/1997, S. 154.

[SLDJ01] St. Laurent, Simon; Dumbill, Edd;Johnston, Joe: Programming Web Services withXML-RPC. O’Reilly, Sebastopol 2001.

[Wash99] Washington Business Journal: No-costsoftware can bring unexpected dividends.http://washington.bcentral.com/washington/stories/1999/05/24/focus4.html, 1999-05-24,Abruf am 2002-01-16.

[Weiss99]Weissinger, A. Keyton: ASP in a Nutshell.O’Reilly, Sebastopol 1999.


Abstract

Architectures of Web-based information systems

In the course of time, different concepts for the implementation of Web-based informationsystems have emerged. This article gives an overview over three common approaches andintroduces Zope as an example of a modern object-oriented web application framework.

Keywords: object-oriented application development, web applications

seite

Hauptblock

Lo

goNavigation

M

e

n

ü

News

<html metal:use-macro=“here/vorlage/macros/seite“>

</html>

<img src=“myLogo“ metal:fill-slot=“here/

vorlage/macros/Logo“>

<div metal:fill-slot = “here/vorlage/macros/

Hauptblock“>

Willkommen bei der ABC GmbH!

…

</div>

(1a)

(1b)

(2)

Bild 7 Verwendung eines Makros

216 Wolfgang Weitz

Documents

Basisarchitekturen Web-basierter Informationssysteme; Architectures of Web-based information systems;