Objekthierarchie
Wer auf der Suche nach der richtigen Entwicklungsumgebung für die eigene Website ist, sollte mindestens einen Blick auf Zope werfen: basierend auf Python ist es objektorientiert - und kostenlos.
- Frank Tegtmeyer
Zope, ein Produkt der Firma Digital Creations aus Fredericksburg, Virginia (USA), ist eine Zusammenführung der beiden Produkte Bobo und Principia. Bobo hat Digital Creations als objektorientierten Ausweg aus der CGI-Misere entwickelt und als freie Software zur Verfügung gestellt. Principia war ein kommerzieller Applikationsserver, der auf Basis von Bobo entwickelt wurde. Beide sind in Python realisiert - mit einigen C-Einbettungen an performancekritischen Stellen. Und seit der Python-Konferenz 1998 ist auch Principia frei erhältlich. Unter www.zope.org ist außer der Software einiges an Informationen zu finden.
Für den Test der Software kamen Windows NT und Suses Linux 6.0 zum Einsatz. Dabei wurde vor allem auf den geringen Ressourcenverbrauch, die einfache Installation und den Funktionsumfang von Zope Wert gelegt. Mit einer früheren Version von Zope verhakte sich einmal die zugrundeliegende Objektdatenbank, bei der hier betrachteten Version trat das Problem nicht auf. Im ‘Laborbetrieb’ war der Ressourcenverbrauch gering -ein realer Betrieb wurde aber weder simuliert noch realisiert.
Es handelt sich bei Zope um eine Plattform zur Realisierung dynamischer Websites. Das System ist portabel und bietet einen guten Durchsatz bei geringer Systembelastung. Sein Konzept ermöglicht die schnelle und einfache Applikationsentwicklung. Die webbasierte Oberfläche für die Administration weist Ähnlichkeiten mit dem Windows-Explorer auf. Von anderen Applikationsservern unterscheidet dieser Zope sich dadurch, daß nicht das HTML-Dokument die zu verwaltende Einheit ist (zu sogenannten Application Server siehe die beiden iX-Artikel unter ‘Literatur’. Eine HTML-Seite ist hier immer eine externe ‘Sicht’ auf die zugrundeliegenden Objekte. Vom technischen Standpunkt aus gesehen ist Zope also ein System zum Publizieren von Objekten. Diese sind in einer Hierarchie organisiert, und der Server stellt sie bei Bedarf über eine Webschnittstelle zur Verfügung. Das geschieht über die in Abbildung 1 gezeigten Hauptkomponenten - Webserver, Publisher und Object Request Broker (ORB).
Je nach Geschmack kann man sich Zope im Quelltext besorgen und selbst übersetzen oder eine binäre Distribution nutzen, von denen Digital Creations einige anbietet. Die Software integriert einen Python-Interpreter, so daß es nicht notwendig ist, diesen vorher einzuspielen. Im Prinzip läuft das Tool mit Unix-Derivaten wie Solaris und Linux sowie Microsoft-Plattformen.
Die Installation ist unter Unix als Normalnutzer ohne Root-Rechte möglich, da die Software keinen privilegierten Port benutzt: in der Auslieferungsvariante läuft Zope auf Port 9673. Unter Unix beschränkt sich die Arbeit für einen Probelauf auf das Auspacken, den Aufruf von install, die Bearbeitung der Master-Paßwort-Datei (access) und den Start des Servers. Unter Windows NT und Windows 9x sollte die Installation ebenfalls einfach sein. Im Windows-Umfeld ist unter Stabilitätsgesichtspunkten allerdings nur NT als Option anzusehen.
Für NT kommt Zope als selbstentpackendes Archiv. Nach den typischen Schritten wie ‘Verzeichnis auswählen’ muß man sich entscheiden, ob das Werkzeug mit seinem eigenen eingebauten HTTP-Server oder über einen Fremdserver betrieben werden soll. Im ersten Fall wird Zope als Nutzerprogramm gestartet, während es im anderen Fall als Service installiert wird.
Im Gegensatz zur Linux-Variante muß das Master-Paßwort nicht in einer Datei hinterlegt werden, sondern es wird über eine Eingabemaske während der Installation abgefragt.
Bei Apache kommt Digital Creations Persistent CGI (PCGI) zum Einsatz, das ähnlich wie FastCGI arbeitet. Digital Creations stellt auf der Zope-Site Apache-Binaries zur Verfügung, die leider immer ein wenig hinter der aktuellen Apache-Version hinterherhinken. Zope ist zwar auch über CGI mit jedem anderen Webserver nutzbar, dies ist aber nur für Sites ohne jeden Performanceanspruch eine Alternative.
Anbindung externer Datenbanken möglich
Inhalte lassen sich über den Zope Manager durch manuellen Upload oder direkte Bearbeitung pflegen. Zusätzlich ist es möglich, Web-Editoren zu benutzen, sofern diese - wie Zope selbst - Netscapes Publishing-Technik beherrschen. Die Unterstützng von FTP und WebDAV - eine Erweiterung von HTTP 1.1 für verteilte Bearbeitung von Dokumenten und deren Versionierung - ist teilweise schon realisiert (in der Alpha-Release 2.0.0a1). Für WebDAV steht ein eigener Testserver bei Digital Creations zur Verfügung.
Die Nutzung externer (relationaler) Datenbanken ist über Z-SQL möglich. Auch in diesem Bereich haben die Entwickler konsequent die Objektorientierung durchgehalten. Die Architektur ermöglicht es zudem, die Entwicklung von Datenbankapplikationen in die Bereiche Datenzugriff und Layout zu trennen, was eine separate Spezifikation und Realisierung erleichtert. Das notwendige Wissen über den jeweils anderen Bereich wird dadurch auf ein Minimum reduziert, und jeder Entwickler kann sich auf das konzentrieren, was er am besten beherrscht. Datenbankverbindungen hält Zope je nach Benutzung offen, so daß wie bei FastCGI oder mod_perl/Apache::DBI keine Performanceeinbrüche durch jedesmal durchzuführende Datenbank-Connects entstehen. Die integrierte Datenbank bietet eine Versionsverwaltung, eine Undo-Funktion und Sessions, die die Bearbeitung von Inhalten ermöglichen, ohne den aktuellen Inhalt des Servers zu beeinflussen. Testserver sind deshalb nahezu überflüssig.
Ergebnisse von SQL-Abfragen sind wiederum Objekte. Diese erben (besser akquirieren, siehe unten) ebenso wie andere Objekte Eigenschaften und Methoden aus ihrer Umgebung. Sie können aber auch über Python-Klassen mit zusätzlichen Methoden ausgestattet werden, um erweiterte Funktionen zu realisieren. Wie bei anderen Objekten existiert ein direktes Mapping von URLs auf Datenbankanfragen, das sowohl Standardmethoden als auch andere Methodenaufrufe inklusive Parameter einschließt.
Der Manager zur Realisierung von Z-SQL-Methoden bietet zwei Bonbons, die man in vergleichbaren Umgebungen oft vermißt: einen Testmodus sowie die Erzeugung eines Template für das passende HTML-Such-Interface. Dieses kann natürlich eigenen Vorstellungen entsprechend angepaßt werden. Zusätzliche Parameter gestatten die Festlegung der maximalen Anzahl von Ergebnisreihen und des Caching-Verhaltens. Sinnvoll ist die Unterstützung von Batches, die ein seitenweises ‘Blättern’ in einem größeren Datenbestand auf einfache Weise realisiert.
‘Intelligente’ Dokumente
Wie erwähnt, stellt Zope HTML-Dokumente nicht im üblichen Sinne zur Verfügung. Das Werkzeug befreit Autoren davon, alle Aspekte von Dokumenten fest im HTML-Quelltext zu kodieren. Das ist zwar immer noch möglich, jedoch verliert man dadurch weitgehend eine primäre Eigenschaft von Zope-Dokumenten: ihre ‘Intelligenz’.
Dokumente werden üblicherweise in der Skriptsprache Document Template Markup Language (DTML) erstellt. Die Syntax dieser Sprache entspricht wahlweise der von Python oder folgt den Server Side Includes (SSI). Auch andere Ausprägungen sind möglich. Ich beschränke mich hier auf die SSI-Syntax.
Auf den ersten Blick scheint es, daß Zope nichts anderes ist, als ein weiterer Präprozessor für eine SSI-Implementierung. Man kann Dokumentfragmente in sein eigenes Dokument einsetzen, Variablen benutzen und sogar den Ablauf der Auswertung über Flow-Control Anweisungen steuern. Scheinbar nichts Neues.
Diese Betrachtungsweise läßt jedoch außer acht, daß alle Dokumente Objekte sind. Vorsicht übrigens mit dem Begriff Dokument. Er wurde in älteren Zope-Versionen anders als in aktuellen benutzt. Was ursprünglich so bezeichnet wurde, heißt heute Methode. DTML-Dokumente gibt es nach wie vor. Die Unterschiede liegen im Detail, eine einfache Differenzierungsmöglichkeit ist dennoch vorhanden: DTML-Dokumente enthalten anzuzeigenden Inhalt. DTML-Methoden benutzen andere Objekte, um Inhalte darzustellen. DTML-Dokumente sind selbst Objekte, die ihre Eigenschaften von einer Zope-internen Klasse erben, während DTML-Methoden nur innerhalb des Ordners gelten, in dem sie sich befinden. Dies führt unter anderem zu unterschiedlichem Verhalten bei der Akquisition (siehe unten).
Objektiv: Vererbung und Sicherheit
Um die Wirkungsweise von Dokumenten zu verstehen, muß man zunächst auf einen wesentlichen Mechanismus eingehen. Zope verwendet für die Festlegung der Eigenschaften von Objekten nicht nur die klassische Beziehung ‘Objekt A ist ein Objekt B’, sondern außerdem die sogenannte Akquisition. Diese realisiert eine ‘ist enthalten in’-Beziehung. Die Akquisition bezieht sich auf die typische hierarchische Struktur von Webservern, die sich in URLs und bei vielen Servern in der Ablage im Dateisystem widerspiegelt. Am ehesten vergleichbar ist diese Technik mit den Gültigkeitsbereichen von Variablen in Programmiersprachen, die die Definition von Blöcken erlauben. Dort sind Variablen in allen im aktuellen Gültigkeitsbereich definierten Blöcken bekannt, nicht aber außerhalb. Innere Blöcke können die schon einmal definierten Variablen durch eigene Instanzen ersetzen, die allerdings nur bis zum Verlassen des Blockes gelten.
Akquisition sorgt für die Vererbung von Eigenschaften der einer URL übergeordneten Ordner. Zum Beispiel kann man im Root-Ordner eines Angebots den Autor und den Release-Stand als Eigenschaften definieren, die alle untergeordnete Objekten verwenden können. Für einzelne Unterordner lassen sich separate Einstellungen vornehmen. Nicht nur Dateninhalte, sondern auch besondere Fähigkeiten werden vererbt: ist zum Beispiel ein Ordner in der Lage, Mail zu versenden, sind es auch alle Objekte, die hier beziehungsweise in Unterverzeichnissen angesiedelt sind.
Auch bei den Sicherheitsmechanismen kommt Akquisition zum Einsatz. Das Sicherheitsmodell geht von der dezentralen Verwaltung eines Servers aus, das heißt, der Site-Manager delegiert Verantwortung an andere, die wiederum für Teile ihres Verantwortungsbereichs andere Zuständige einsetzen können. Die Einstellungen werden in der entsprechenden Ansicht von Ordnern definiert.
Zope bietet vier wesentliche Komponenten für das Sicherheitsmanagement: Benutzer, Rollen, Rechte und Akquisition. Benutzer (besser: Benutzerobjekte) dienen der Authentifizierung gegenüber dem System (in der Regel eine Nutzer-/Paßwortabfrage). Rollen bilden das Bindeglied zwischen den Benutzern und Rechten, sie entsprechen in etwa dem, was andere Systeme durch Gruppen realisieren.
Die Autorisierung für Operationen legen die Rechte fest. Objekte können auch Rechte erzeugen, die in den Zope-Standardobjekten nicht vorgesehen sind.
Schließlich sorgt die Akquisition dafür, daß sich Rechte in der URL-Hierarchie auch nach ‘unten’ durchsetzen. Auf diese Weise ist es möglich, die Benutzerverwaltung in einem weit ‘oben’ liegenden Ordner anzusiedeln und so den gesamten darunter liegenden Baum zu kontrollieren.
Delegationsmöglichkeiten und die hierarchische Arbeitsorganisation machen es einfach, das Wiederverkäufermodell abzubilden: als Provider kann man problemlos einen Teilbaum der Verwaltung eines Wiederverkäufers anvertrauen, der wiederum Teilbäume an andere abgibt. Die Auflösung eines Vertragsverhältnisses hat kein großes Aufräumen in einer Nutzerdatenbank zur Folge: man kann einfach den betreffenden Teilbaum der Zope-Hierarchie löschen.
Objektnamen wie URLs behandeln
Eine angenehme Eigenschaft ist, daß Zope die Objektnamen auf eine Weise auf URLs abbildet, die an traditionelle Webserver mit statischen Inhalten erinnert. Auch die Objektmethoden sind in diese Abbildung einbezogen, so daß keine ellenlangen Parameterlisten entstehen. Jeder, der einmal eine WebObjects-URL gesehen hat, weiß, was damit gemeint ist. Den hierarchische Namensraum der Objekte stellt der Zope Manager in einer Baumstruktur dar.
Ordner repräsentiert Zope beim Webzugriff immer über das Standardobjekt index_html. Das System ‘weiß’, um welchen Objekttyp es sich handelt - man muß also keine Zuordnung von Dateitypen zu Mime-Typen vornehmen, wie das bei Webservern der Fall ist.
Die typische Vorgehensweise bei der Entwicklung unter Zope ist iterativ: eine schrittweise Verfeinerung der Anwendung. Entwickler lagern Inhalte und Dienste, die sich als allgemeingültig herausstellen, in Objekte aus, die sie für die gemeinsame Nutzung im gleichen Ordner oder weiter oben in der Hierarchie anlegen.
Akquisition funktioniert wie erwähnt nicht nur bei Dokumenten, sondern auch bei Diensten. Wer eine Autorisierung für viele Dokumente benötigt, legt die Zugriffsrechte nicht für jedes Einzelobjekt fest, sondern erzeugt ein Benutzerobjekt (das steuert den Zugriff und die Autorisierung) weit genug oben in der Hierarchie.
Normalerweise arbeitet man an einem laufenden Server. Für diesen Zweck stellt Zope Sessions bereit, die wie Transaktionen in relationalen Datenbanken erst nach einem Commit alle gemachten Änderungen in die Datenbank schreiben. Sessions lassen sich über den Zope Manager eröffnen, indem man einem Ordner ein entsprechendes Objekt hinzufügt.
Man kann mehrere Sessions parallel bearbeiten. Um zu wechseln, muß man jedoch zunächst eine verlassen, um in eine andere einzutreten. Sessions kann der Administrator für bestimmte Nutzer einrichten, so daß zum Beispiel mehrere Teams verschiedene Versionen einer Webanwendung gleichzeitig erzeugen können. Momentan funktioniert das noch nicht völlig unabhängig voneinander. In einer anderen Session veränderte Objekte kann man nicht bearbeiten. Änderungen sind immer erst zu speichern oder zu widerrufen, wenn man Objekte modifizieren will.
Einmal ausgeführte Arbeiten möchte man natürlich wiederverwenden. Deswegen bietet Zope die Möglichkeit, erstellte Applikationen als Vorlage zu benutzen und diese mit einem Konfigurationsinterface auszustatten. Vorlagen heißen ‘Produkt’. Sie können auf einfache Weise integriert werden und stehen danach über den Manager als installierbare Objekte zur Verfügung. Die Zope-Site bietet einige zum Download an, unter anderem ein ECommerce-Produkt. Der Zope Manager’s Guide enthält ein Beispiel, wie ein Produkt generiert wird.
Wie Zope arbeitet, soll ein kurzes Beispiel zeigen: ein Site-Betreiber stellt einen Server bereit, der zur Darstellung der Vereine seiner Heimatstadt dienen soll. Der Startordner, unter dem sich das Angebot hier befindet, ist /vereine. Ist der Ordner angelegt, ergibt sich das in Abbildung 4 gezeigte Bild.
Eine Stadt voller Beispielvereine
Nach Hinzufügen eines Logos in diesem Ordner über das Managementinterface (Upload) wurde die automatisch angelegte index_html-Methode entsprechend Abbildung 5 verändert.
Die Einleitung bildet der Aufruf einer anderen (eventuell über Akquise vererbten) Methode: standard_html_header. Sie kann zum Beispiel HTML-Code enthalten, den alle untergeordneten DTML-Methoden integrieren sollen. Das geschieht in SSI-Syntax, wie sie auch vom Apache-Webserver her bekannt ist. Schließlich sorgt eine solche Methode (auch über Akquise vererbt) für den Abschluß des Dokumentes. Hier läßt sich zum Beispiel ein Menü am unteren Rand der generierten HTML-Seite einblenden - oder die Angabe des Änderungsdatums, eine Kontaktadresse … Der Mittelteil ist reines HTML bis auf die Benutzung eines Objekts, in diesem Fall ein GIF-Bild. Der Aufruf der DTML-Methode sorgt für die Einbindung des entsprechenden IMG-Tags.
Im nächsten Schritt erzeugt der Entwickler drei Unterordner, die jeweils einen Verein aufnehmen (Hundezüchter, Schützen und Schwimmer). Um eine Delegation für die Vereinsordner durchzuführen, ist pro Ordner mindestens ein Nutzer einzurichten, der die Managerrolle bekommt. Vor dem Speichern ist dazu die Managerrolle zu selektieren. In diesem Fall handelt es sich im ‘Hundezüchter’-Ordner um einen Nutzer namens Willi (Abbildung 6).
Öffnet man im linken Frame des Servermanagers durch Anklicken den Ordner hundezuechter und selektiert im rechten Frame die Ansicht Security, kann man sowohl die Vererbungen und auch die Rechte für die im Ordner aktiven Rollen festlegen. Für anonyme Nutzer reicht das Recht zum Ansehen (View) der Objekte über die HTML-Schnittstelle. Die Managerrolle bekommt die zur Pflege notwendigen Rechte zugewiesen - das müssen nicht unbedingt alle sein. Abbildung 7 zeigt die entsprechende Ansicht.
Bei Zope ist mit einer schnellen Weiterentwicklung zu rechnen, das zeigt die rasche Versionsfolge seit Anfang des Jahres. Jede neue Release hat zunächst einmal viele Verbesserungen gebracht - zum Beispiel enthalten Image-Objekte in der aktuellen Version auch Breite und Höhe als Eigenschaften. Diese wird automatisch ermittelt und im HTML-Quelltext in den widht/height-Attributen generiert, ein Muß für benutzerfreundliche Seiten. Geht die Entwicklung so weiter, wird die ‘Zope-Bewegung’ eine große Entwicklergemeinde finden, was zu mehr Feedback und Qualität führen dürfte. Eins gibt’s noch obendrauf: endlich einen zwingenden Grund, Python zu lernen.
FRANK TEGTMEYER
arbeitet als Sicherheitsverantwortlicher bei der Agentur Media Quality International (MQI).
Literatur
[1] Jürgen Diercks; Application Server; Schirmherrschaft; Das Web: Plattform für Firmenanwendungen; iX 1/99, S. 104
[2] Matthias Zepf; Application Server; Zufallsfund; Apples WebObjects 4.0; iX 6/1999, S. 50
iX-TRACT
- Zope ist ein frei erhältliches Web-Publishing-Werkzeug, das dynamische Websites portabel (Python) zu erzeugen hilft.
- Unterschiedliche Zuständigkeitsbereiche lassen sich zuweisen, und Templates ermöglichen die Wiederverwendung einmal generierten Inhalts.
- Zope enthält einen eigenen Webserver, kann aber auch mit jedem CGI-fähigen Webserver arbeiten.
iX-WERTUNG
- [+] durchgängig objektorientierte Arbeitsweise und Portabilität
- [+] gute Performance trotz Komplexität
- [+] Open Source
- [-] eigenständige Welt, nur über Umwege integrierbar
- [-] wenig Programmiererressourcen und Erfahrungen vorhanden
- [-] als Open Source im kommerziellen Bereich schwer verkaufbar
