Zope - ein einfaches
Content Management System
Brano Ivakovic
... [ Seminar
"Java und Werkzeuge für das Web" ] ... [ Inhaltsverzeichnis
] ... [ zurück ] ... [ weiter ] ...
Übersicht: Content Management-Aspekte
Dieses Kapitel behandelt
die Aspekte, die für einen Einsatz von Zope als Content Management
System unerlässlich sind. Dazu gehören allgemein die Möglichkeit,
Fehler rückgängig zu machen, Revisionsverwaltung, eine
effektive Unterstützung von Zusammenarbeit, ein ausgefeiltes Benutzer-
und Sicherheitskonzept, Zugriff auf relationale Datenbanken, Suchmaschinenfunktionalität
und Skalierbarkeit.
Undo -
Fehler rückgängig machen
Jede Aktion in Zope, die eine Änderung
von Objekten bewirkt, kann über den Undo-Reiter rückgängig
gemacht werden. Dadurch kann der Status vor einem gemachten
Fehler wiederhergestellt werden, wie z.B. ein versehentlich gelöschter
Ordner durch Widerrufen der Delete-Aktion. Die Undo-Funktionalität
wird über den Undo-Reiter gesteuert:
Abb. 10: Die Undo-Ansicht
Die Auswahl der ersten Transaktion /manage_delObjects
und ein Klick auf "Undo" widerruft die letzte Transaktion und stellt somit
den Ordner wieder her. Undo arbeitet auf der ZODB, wobei Änderungen
daran in Transaktionen vor sich gehen. In Zope ist eine
Transaktion als jede Änderung vorstellbar, die bei
einer Aktion eintritt (z.B. Erstellung eines Ordners, Einfügen
von Objekten an einer neuen Stelle). Allerdings kann eine Transaktion,
von der eine spätere Transaktion abhängt, nicht widerrufen werden: Wird
ein Objekt in einen Ordner eingefügt und dann ein Objekt in demselben
Ordner gelöscht, soll z.B. das vorherige Einfügen
widerrufen werden. Die Lösung ist, einfach beide Transaktionen
zu widerrufen. Ein anderes Problem ist, dass ein Undo nicht
rückgängig gemacht werden kann. Deshalb kann
ein neuer Ordner nach Widerruf dieser Aktion nicht durch Rückgängig
machen des Undos zurückerhalten werden. Nur Änderungen
an in Zope gespeicherten Objekten können rückgängig
gemacht werden, nicht jedoch integrierte Daten in einem relationalen
Datenbankserver wie Oracle oder MySQL.
History - Änderungen an Dokumenten verfolgen
Oft ist es nützlich,
nur die Änderung an einem Objekt zu widerrufen.
Wurde z.B. ein Dokument in einer Transaktion bearbeitet,
die auch das Verschieben beinhaltete, soll z.B. zwar die Änderung
am Dokument, nicht aber das Verschieben der Datei widerrufen
werden. Dazu kann die History-Ansicht mit den vorherigen Zuständen
eines Objekts verwendet werden:
Abb. 11: Die
History-Ansicht
DTML-Methoden
und -Dokumente unterstützen sogar den Revisionsvergleich,
um z.B. die aktuellste "neue" Version der Datei mit einer
älteren zu vergleichen. Dieser Vergleich wird im
weitverbreiteten Format namens diff angezeigt.
Unterstützung von Zusammenarbeit
Import und Export von Objekten
Alle Arten von Zope-Objekten
können in Form einer Exportdatei zwischen Zope-Systemen
ausgetauscht werden. Für einen Export
muss der entsprechende Ordner ausgewählt und über
die Schaltfläche "Import/Export" exportiert werden. Die
Exportdatei kann auf den lokalen Rechner heruntergeladen oder auf
dem Server belassen werden. Bei Auswahl von "Save to file on
server" sichert Zope die Datei auf dem selben Rechner, auf dem
Zope läuft. Exportdateien werden in Zopes var-Verzeichnis
auf dem Server geschrieben, mit der Endung .zexp. Meist ist
es praktischer, die Exportdatei auf den lokalen Rechner herunterzuladen,
es sei denn, die Dateigröße verbietet dies, oder
das exportierte Objekt soll lediglich zu einer anderen Zope-Instanz
auf dem selben Rechner bewegt werden. Standardmäßig
werden Exportdateien in Zopes Binärformat exportiert,
mit der Option, im eXtensible Markup Language (XML)-Format
zu exportieren.
Für einen Import
muss die Exportdatei zunächst in das import-Verzeichnis
der Zope-Installation kopiert werden. Nach erfolgreichem
Import sollte ein neues Objekt bzw. eine komplette Ordnerstruktur
im Ordner erscheinen, in dem der Import durchgeführt
wurde.
Versionen
Versionsobjekte helfen, die Arbeit mehrerer
Personen an denselben Objekten zu koordinieren. Dabei können
z.B. folgende Probleme auftreten:
- Ein Dokument wird zur selben Zeit von zwei
Personen bearbeitet und Änderungen der zweiten könnten
Änderungen der ersten Person überschreiben
- Änderungen sollen
erst nach Abschluss öffentlich gemacht werden
Zu Problem 1: Kann immer durch
Verwenden der Undo- und History-Funktionen umgangen werden, ist aber
sehr aufwändig.
Zu
Problem 2: Wird z.B. die Menüstruktur einer Site geändert,
während die Site weiterverwendet wird, kann das Navigationssystem
zeitweilig zerstört werden.
Um dieses Problem zu beheben, hat Zope Versions-Objekte
zum Vornehmen nicht-öffentlicher Änderungen. Zum
Beispiel kann es eine Woche dauern, ein neues Menüsystem fertig
zu stellen. Danach können alle Änderungen auf einmal durch
Freigabe der Version veröffentlicht werden. Durch Klick auf eine
Version wird sie verwendet: Dies öffnet die Ansicht "Join/Leave":
Abb. 12: Anmelden
an einer Version
Die Arbeit an dieser gegenwärtig nicht verwendeten Version wird durch Klick
auf "Start Working in MeineAenderungen" aufgenommen. Von nun
an weist eine Nachricht darauf hin, dass Änderungen nicht
öffentlich sind, sondern in der Version gespeichert werden.
Jedes neu erstellte oder bearbeitete Objekt während der Arbeit
in einer Version wird mit einer kleinen roten Raute nach seiner
Kennung markiert, so z.B. ein neu hinzugefügtes DTML-Dokument
namens new und die Änderung der standard_html_header-Methode in
einer Zeile:
<HTML>
<HEAD>
<TITLE><dtml-var title_or_id></TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<H1>In einer Version geändert</H1>
Nach der Rückkehr zur Version über
"Quit working in MeineAenderungen" verschwindet das während
der Arbeit in der Version erstellte Dokument new und
andere Änderungen. Die standard_html_header-Methode hat jetzt
eine kleine rote Raute und ein Sperrsymbol zur Kennzeichnung,
dass dieses Objekt in einer Version geändert worden ist. Wird
ein Objekt in einer Version geändert, wird es solange gesperrt,
bis die Änderungen in der Version bestätigt oder verworfen
werden. Die Sperrung stellt auch sicher, dass die Versionsänderungen
keine Änderungen anderer Personen überschreiben. Wenn nur eine
Person zu einer bestimmten Zeit an einem Objekt arbeiten soll, kann es
in einer Version geändert werden. Die Verwendung von Versionen
sollte allerdings eingeschränkt werden, weil eine Sperrung die
Bearbeitung gesperrter Objekte behindert. Über "
Start working in
MeineAenderungen" wird alles in den Zustand
vor Verlassen der Version zurückversetzt. In der Ansicht "Save/Discard"
können Änderungen dauerhaft gemacht werden:
Abb. 13: Versionsänderungen
freigeben
Mit "Save" werden Änderungen öffentlich
gemacht und alle in der Version geänderten Objekte sind
jetzt nicht mehr gesperrt. Anschließend muss noch die Arbeit
in der Version beendet werden (Ansicht Join/Leave). Nun sollte
das in der Version erstellte Dokument und die Änderung am
standard_html_header sichtbar sein. Auch Änderungen an Versionen
können rückgängig gemacht werden, allerdings werden
bei Widerruf der Transaktion alle in der Version
vorgenommenen Änderungen rückgängig gemacht.
Benutzer- und Sicherheitskonzept
Als Web-Applikation
und im Besonderen als Content Management System ist es
erforderlich, dass Zope Sicherheitsaspekten Rechnung trägt.
Dies bedeutet z.B., zu kontrollieren, wer Zugang zu einer Applikation
hat und festzulegen, was derjenige dort tun kann. In der Regel
sollte Sicherheit ein wichtiges Design-Element in der Konzeptionsphase
sein.
Grundbegriffe
Authentifizierung:
bedeutet, herauszufinden, wer der Nutzer ist. Der Authentifizierungsprozess wird
beim
Aufruf einer geschützten Ressource (wenn z.B. eine private
Website angesehen wird) ausgelöst, woraufhin zum Login
aufgefordert und nach einem Benutzer-Account gesucht wird. Dies
kann auch geschehen, wenn der Benutzer bereits eingeloggt ist.
Werden nur öffentliche Ressourcen aufgerufen, wird Anonymität
des Nutzers angenommen.
Autorisierung:
bedeutet, festzulegen, was der Nutzer
tun kann bzw. darf. Nach erfolgter Authentifizierung
stellt Zope fest, ob Zugang zu der geschützten Ressource
besteht oder nicht. Dieser
Prozess bezieht zwei vermittelnde Schichten zwischen dem
Nutzer und der geschützten Ressource ein, nämlich
Rollen und Erlaubnisse (roles und permissions).
Rollen: Benutzer haben Rollen, die
beschreiben, was sie tun dürfen, wie etwa "Autor",
"Manager" oder "Redakteur", aber auch "Anonymous" und "Authenticated".
Sie bilden somit Klassen von Benutzern. Wie in UNIX-Gruppen
werden Gruppen von Benutzern abstrahiert, und Zope-Benutzer können
mehr als eine Rolle haben. Zope hat vier eingebaute Rollen:
Manager
|
für Benutzer mit Standard-Verwaltungsfunktionen
(z.B. Anlegen und Bearbeiten von von Zope-Ordnern und Dokumenten)
|
Anonym (Anonymous)
|
darf öffentliche Ressourcen
sehen ("view", z.B. der anonyme Zope-Benutzer), keine Änderungen
von Zope-Objekten
|
Besitzer (Owner)
|
wird automatisch Benutzern
in dem Kontext zugeordnet, wo sie Objekte anlegen
|
Authentifiziert (Authenticated)
|
für Benutzer, die gültige
Authentifizierungsdaten übermittelt haben: Zope "weiß",
wer der bestimmte Benutzer ist
|
Tab. 5: Rollen
in Zope
Erlaubnisse: Erlaubnisse definieren, welche
Aktionen mit Zope-Objekten durchgeführt werden können, wie etwa "Ansehen", "Objekte
löschen" oder "Eigenschaften verwalten".
Sicherheitsregeln: Sicherheitsregeln
teilen Rollen Erlaubnisse zu und autorisieren somit
Benutzer, geschützte Aktionen durchzuführen. Sie legen
fest, wer was tun darf. Zum Beispiel mag eine Sicherheitsregel
die "Manager"-Rolle mit der Erlaubnis "Objekte löschen"
assoziieren.
Authentifizierung und Benutzerverwaltung
Für ein Login unter Zope muss ein
Benutzer-Account vorliegen. Ein Zope-Benutzer hat einen Namen,
ein Passwort und optionale Daten. In Zope können
beliebig viele Managerkonten und andere, eigene Arten von
Benutzern, die bestimmten Gruppen angehören. Um Benutzer-Accounts
anzulegen, werden Benutzer zu Benutzer-Verzeichnissen hinzugefügt
(im Ordner acl_users):
Abb. 14: Hinzufügen
eines Benutzers zu einem Benutzer-Ordner
Das Feld Domains erlaubt die Einschränkung
von Internet-Domains, von denen aus sich der Benutzer
einloggen kann (z.B. "myjob.com myhome.net", oder auch IP-Adressen).
Als
Rolle wird für Verwaltungsaufgaben i.d.R. Manager gewählt,
die "Owner"-Rolle passt meist nicht, weil ein Benutzer der Eigentümer
bestimmter Objekte ist, nicht ein Eigentümer im Allgemeinen.
Zope kann mehrere Benutzer-Ordner an verschiedenen
Stellen der Objekthierarchie enthalten. Ein Zope-Benutzer
hat ausschließlich Zugang zu Ressourcen in dem Benutzer-Ordner,
in dem er definiert ist. Benutzer können in jedem Zope-Ordner
definiert werden. Ein verbreitetes Zope-Verwaltungsmuster ist die
Delegation, d.h. verwandte Objekte in einem Ordner und
dann dort in einem Benutzer-Ordner verantwortliche Personen zu
definieren. Manchmal soll der
Benutzer-Account nicht durch das Web verwaltet werden, wenn
z.B. schon eine Benutzerdatenbank vorliegt. Mit wechselnden Benutzer-Ordnern
können alle Arten von Authentifikationstechniken benutzt werden.
Die wichtigsten sind: LoginManager (erlaubt die Einbindung eigener
Autorisierungsmethoden, z.B. um sich aus einer Datenbank heraus zu authentifizieren),
etcUserFolder (authentifiziert über
Standard-UNIX /etc/password style files), LDAPAdapter (authentifiziert über
einen LDAP-Server) und NTUserFolder (authentifiziert aus NT-Benutzer-Accounts
heraus, funktioniert nur unter Windows NT oder Windows
2000).
Drei besondere Benutzer-Accounts
werden nicht in Benutzer-Ordnern definiert: Anonymer Zope-Benutzer
(Eingebauter Benutzer-Account
für Gäste, die keinen Benutzer-Account haben, nur
Zugriff auf
öffentliche Ressourcen), Notfall-Benutzer (Zweck: Reparieren durcheinandergebrachter
Berechtigungen, z.B. bei versehentlichem Aussperren aus Zope)
und Ursprungs-Manager (wird vom Zope-Installer zum Ermöglichen
eines ersten Logins angelegt).
Autorisierung und Sicherheitsverwaltung
Zope-Sicherheitsregeln definieren, welche
Rollen welche Erlaubnisse in einem bestimmten Teil der Site
haben und kontrollieren somit die Autorisierung. Anstatt
zu definieren, was jeder einzelne Benutzer tun kann, können
einfach ein paar verschiedene Sicherheitsregeln für verschiedene
Benutzerrollen festgelegt werden. Von den vorgestellten vier Standardrollen
reichen für einfache Zope-Sites Manager und Anonym,
für komplexere Sites empfiehlt sich das Anlegen eigener
Rollen.
Rollen definieren: Neue Rollen werden in
der Registerkarte "Security" im Feld "User defined role" festgelegt
und können auf der Ebene der Definition benutzt werden und in
der Objekthierarchie darunter. Im Allgemeinen sollten Rollen für
große Abschnitte einer Site anwendbar sein. Anstatt neue
Rollen anzulegen, ist es oft besser, Sicherheitseinstellungen vorhandener
Rollen zu ändern oder Benutzer tiefer in der Objekthierarchie
zu definieren, um ihren Zugang zu beschränken. Es gibt lokale Rollen,
die einem bestimmten Benutzer besonderen Zugang zu einem
Objekt gewähren (z.B. über die lokale Besitzerrolle).
Im Regelfall sind jedoch Sicherheitseinstellungen für einzelne
Benutzer zu vermeiden.
Über die Registerkarte Security ist z.B. auch einzusehen, dass ein Mail
Host im Gegensatz
zu Ordnern über eine recht eingeschränkte
Erlaubnispalette verfügt:
Abb. 15: Sicherheitseinstellungen
für ein Mail Host Objekt
Sicherheitsregeln definieren: Sicherheitsregeln
legen fest, wer was in einem bestimmten Teil der Site tun kann.
Das Kästchens an der
Kreuzung zwischen einer Berechtigung und einer Rolle ordnet dem Benutzer
mit dieser Rolle diese Berechtigung zu. Diese Regeln können
durch Änderung der Sicherheitseinstellungen im Root-Ordner
angepasst werden. Soll eine Site "privatisiert" werden, muss im entsprechenden
Ordner allen anonymen Benutzern der "View"-Zugang verweigert werden.
Im Root-Ordner bewirkt dies die Privatisierung einer gesamten Site.
Erwerben von Sicherheitsregeln:
Objekte benutzen ihre eigenen Regeln, falls definiert, und erwerben
die Sicherheitsregeln ihrer Haupt-Dokumente. Das Erwerben von Sicherheitsregeln
wird in der Registerkarte Security über "Acquire permission settings" kontrolliert. Im Root-Ordner (ohne
übergeordnetes Hauptdokument) gibt es die äußerste, linke
Spalte nicht. Wenn irgend möglich, sollten Sicherheitseinstellungen
übernommen werden.
Delegation von Kontrolle an lokale Manager:
Dieses
zentrale Sicherheitsmuster sieht vor, etwa Ressourcen in
Ordnern zusammenzufassen und dann Benutzer-Accounts in diesen
Ordnern anzulegen, um den Inhalt zu verwalten. Angenommen, die Verwaltung
des Ordners Verkauf soll der neue Web-Verkaufsmanager Stefan übernehmen.
Um zu verhindern, dass Stefan Änderungen außerhalb
des Ordners Verkauf vornimmt, wird ein neuer Benutzer-Ordner direkt
im Ordner Verkauf angelegt. Nun kann z.B. ein weiterer Benutzer
'Steve' mit der Managerrolle hinzugefügt werden. Stefan kann
sich nun direkt im Ordner Verkauf einloggen, um seinen Bereich zu
verwalten, indem er mit seinem Browser http://www.zopezoo.org/Verkauf/manage
aufruft:
Abb. 16:
Verwaltung des Ordners "Verkauf"
Der lokale Manager 'Steve' kann
sich nun ausschließlich im Ordner Verkauf einloggen,
der im Navigationsbaum auf der linken Seite als Root-Ordner
angezeigt wird. Dieses Muster kann rekursiv angewandt werden:
Stefan kann beispielsweise einen Unterordner für Multi-Level-Marketing-Verkäufe
anlegen und dort Kontrolle weiter an Multi-Level-Marketing-Manager
delegieren.
Datenbankzugriff
Zope benutzt
intern eine Objektdatenbank zur Speicherung von Zope-Objekten. Sie
berücksichtigt viele verschiedene Objekttypen mit unterschiedlichen
Arten von Beziehungen untereinander. Relationale Daten sind jedoch nicht
einfach auf Objekte anzupassen, weil sie ein einfacheres Tabellen-orientiertes
Datenmodell voraussetzen. Daher stellt Zope verschiedene Mechanismen zur
Übernahme relationaler Daten und deren Nutzung in Zopes Objekt-zentrierter
Umgebung bereit, einschließlich Datenbankadapter
und SQL-Methoden.
Die üblichste Verwendung für Zope's relationale Datenbank-Unterstüzung
ist die Bereitstellung vorhandener Datenbanken im Web. Durch Nutzung
von relationalen Daten mit Zope kann von Zope's Vorteilen (einschl. Sicherheit,
dynamische Präsentation, Netzwerkdiensten u.a.) profitiert werden.
Um eine relationale Datenbank in Zope zu benutzen, müssen
zwei verschiedene Zope-Objekte erzeugt werden: Eine "Database Connection"
und eine "Z SQL"-Methode. Database Connections werden benutzt, um Verbindungen zu
externen relationalen Datenbanken herzustellen und zu verwalten. "Z SQL"-Methoden beschreiben die Aktionen,
die auf einer Datenbank ausgeführt werden sollen und müssen
mit einer Database Connection zum Verbindungsaufbau assoziert werden. Datenbankadapter (DAs) stehen für
die Eingangs erwähnten Datenbanken zur Verfügung und für
Gadfly: Gadfly ist ein schnelles, Python-basiertes
relationales Datenbanksystem und dient hauptsächlich Demonstrationszwecken.
Es können keine großen Datenmengen verwaltet werden, weil die
komplette Datenbank in den Speicher gelesen wird. Alle anderen relationalen
Datenbanken laufen als Prozesse extern zu Zope.
Suchmaschine
Zope umfasst
ZCatalog, eine integrierte, leistungsfähige und schnelle Suchmaschine
mit automatischer Index-Generierung. ZCatalog ermöglicht die Kategorisierung
und die Suche nach allen Arten von Zope-Objekten, externen relationalen
Daten, Dateien und Webseiten und kann auch zur Verwaltung von Objektgruppen
verwendet werden. Es wird Volltextsuche sowie gleichzeitige Suche
in mehreren Indizes unterstützt. Ausserdem wacht ZCatalog über
Veränderungen der Metadaten von indizierten Objekten. ZCatalog wird
in der Regel für Massenkatalogisierung (Katalogisierung vieler
Objekte auf einmal) und Automatische Katalogisierung (Katalogisierung
von Objekten bei ihrer Erstellung und Veränderung) eingesetzt. Die Massenkatalogisierung erfordert
drei Arbeitsschritte: Erstellung eines ZCatalogs,
Bestimmung
und Indizierung zu katalogisierender Objekte und Erstellung einer web-basierten
Schnittstelle für die Suche im Katalog.
Mit dem Wissen darüber, wie ein Katalog seine Information
abspeichert, können mit ZCatalog mächtige und komplexe Suchmöglichkeiten
realisiert werden, und der Katalog kann so angepasst werden, dass er
die gewünschte Art Suche zur Verfügung stellt.
Indizes: In ZCatalog werden Objektinformationen und
ihre Inhalte in Indizes gespeichert, wodurch große Informationsmengen
sehr schnell abgelegt und wiedergefunden werden können. Es sind
verschiedene Indizes definierbar, die verschiedene Informationen über
Objekte verwalten, z.B. schließt ein Index den Inhalt von DTML-Dokumenten,
ein anderer Objekte mit bestimmten Eigenschaften ein. Bei einer Suche
im ZCatalog werden nicht die Inhalte der einzelnen Objekte durchsucht.
Vor einer Suche werden die Informationen, für die der ZCatalog eingerichtet
wurde, indiziert. Sodann kann der ZCatalog Objekte zurückliefern,
die bestimmten Suchkriterien genügen. Die Suche in einem Buch z.B.
nach dem Wort Python liefert etwa folgende Angabe: Python: 23, 67, 227. Das bedeutet ein dreimaliges
Vorkommen des Wortes Python auf einer Seite. Ein Index in Zope sucht das
Suchmuster - im Beispiel das Wort Python - in einer Liste von Objekten
anstatt auf Buchseiten.
Skalierbarkeit
Sich häufende
Anfragen können einen Server dermaßen überlasten,
dass sie zu inakzeptablen Antwortzeiten und u.U. sogar zu Abstürzen
führen. Diesem Problem kann durch Einsatz mehrerer Rechner mit identischen
Serverkonfigurationen begegnet werden, so dass bei Ausfall eines Rechners
andere Rechner im Verbund seine Aufgabe übernehmen können.
Bedingung ist, dass auf allen Zope- Instanzen die gleichen Informationen
vorliegen, was insbesondere auf großen Zope-Servern mit Tausenden
sich stetig ändernden Objekten kaum mehr manuell zu bewältigen
ist.
Das ZEO-System ermöglicht den Betrieb einer
Website auf mehreren Rechnern, auch "Cluster" genannt. Mit einer solchen
Anordnung können mittels Lastverteilungskomponente bei stark ansteigender
Anfragelast die Anfragen auf mehrere Rechner verteilt werden. Ausserdem
können im Falle eines Serverausfalles die noch intakten Rechner
die Anfragen bedienen. Mit einem derartigem Serveraufbau kann ein defekter
Rechner ausgetauscht oder repariert werden, ohne das von aussen ein
Serverausfall spürbar wird.
Mit ZEO kann Zope auf mehreren Rechnern betrieben werden.
ZEO garantiert, dass alle beteiligten Zope-Installationen jederzeit
auf genau die selbe Datenbank zugreifen. ZEO benutzt dazu eine Client/Server-Architektur.
Alle Clients verbinden sich mit einer zentralen Instanz, dem ZEO Speicher
Server, so wie auch in Abb. 17 zu sehen ist:
Abb. 17: ZEO-Funktionsweise
Bei Einsatz von ZEO übernimmt Zope zugleich Server-
(für die Beantwortung von Webanfragen) sowie Klientfunktionalität
(um Daten vom ZEO-Server zu erhalten). ZEO Clients und Server kommunizieren
über ein standardisiertes Internetprotokoll. Auf diese Art und
Weise ist es möglich, beide im selben Raum oder aber auch in einem
anderem Land zu betreiben.
Folgende Argumente sprechen für den Einsatz von ZEO:
- Eine
Webseite kann Anfragen nicht mehr zügig beantworten
- Die
Website erfordert eine 24/7-Verfügbarkeit => In diesem Falle
erlaubt ZEO den Einsatz mehrerer sofortiger einsatzfähiger Ersatzserver
- Eine
Website soll global über mehrere Mirror-Sites angeboten werden
und an jedem Standort dieselben Daten per ZEO-Client zugreifen und
schreiben können
- Ein
ZEO-Client soll nach Fehlern untersucht (debuggen) werden, während
die anderen Zeo-Clients weiterhin Webseiten ausliefern
... [ Seminar
"Java und Werkzeuge für das Web" ] ... [ Inhaltsverzeichnis
] ... [ zurück ] ... [ weiter ] ...