Plone streitet im Ring der CMS-Schwergewichte mit

Transkript

1 Plone streitet im Ring der CMS-Schwergewichte mit Herold Christina Plone ist ein komplexes Open-Source Content-Management-System (CMS), welches auf dem Webapplikationsserver Zope und dem zugehörigen Content-Management- Framework (CMF) aufsetzt. Schwerpunktmäßig wird auf die Bereiche Systemarchitektur, Rechte- und Benutzerverwaltung, Workflows und die Integration von Plone in produktiven Umgebungen eingegangen. Hierbei werden jeweils die Probleme, die sich aus den Default-Einstellungen von Plone ergeben, näher erläutert. Eine kurze Beschreibung von Plones Front- und Backendbereich soll den Artikel abrunden. Im Bereich der Content-Management-Systeme (CMS) gibt es viele Tools. Einige unterstützen den Anwender bei der Pflege von einfachen Webseiten, andere bieten aufwendig integrierte Redaktionssysteme, Dokumentenmanagementsysteme, Workflow-, Groupware- und Portalfunktionen. Plone kommt aus dem Open-Source-Umfeld und gehört hinsichtlich seines Funktionsumfanges zu den komplexeren Content-Management-Systemen, vgl. [IhdeM, PilzA]. Das Plone nicht nur eine Modeerscheinung ist, zeigt die Gründung der Plone Foundation im April 2004 mit Sitz in Houston. Die Plone Foundation wahrt die Rechte am Quellcode und am Markennamen. Ferner vertritt sie die Interessen der Plone Community und unterstützt die Verbreitung. Die Weiterentwicklung wird durch eine große Entwicklergemeinschaft, die sich aus Programmierern und weltweitoperierenden Dienstleistern zusammensetzt, vorangetrieben. Einer dieser Dienstleister ist Computer Associates (CA). Sie stellte bei Gründung der Plone Foundation, dieser ca US-Doller zu Verfügung, vgl. [IhdeM, PilzA]. Laut Schmidt Nicola [SchmidtN] soll sich Computer Associates dafür entschieden haben auch andere Open-Source-Projekte zu unterstützen und für sich nutzbar zu machen, indem sie ihre Produkte in die Open-Source-Systeme einbindet. Dazu gehört nicht nur eine enge Zusammenarbeit mit Plone, bei der Plone-Kunden für ihre Software Supportverträge mit Computer Associates abschließen können, sondern auch eine enge Zusammenarbeit mit Zope, JBoss oder Linux. Plone, Zope und das CMF wurden in den Sprachen Python und C programmiert. Nach Maik Ihde [IhdeM, PilzA] soll Plone eine größere Anwender- und Entwicklerbasis als Zope und CMF besitzen und zu Beginn als reine Oberfläche für das CMF unter dem Webapplikationsserver Zope gedient haben. Aus [plonenet] ist ersichtlich, dass Plone vorzugsweise weltweit von Regierungen (Brasilien, Bern) und Einrichtungen (NASA-Marsexpedition [ Amnesty International) eingesetzt wird. Im folgenden wird nur auf die Default-Einstellungen von Plone nach der Installation eingegangen. Systemanforderungen Nach [CooperC] stellt Plone hohe Anforderungen an die Hardware. Demnach sollte ein Server im Produktivbetrieb bei mittlerer Auslastung mindestens über 1 GB RAM und einen 2 GHz Intel- Prozessor verfügen. Die Prozessorgeschwindigkeit ist in diesem Fall eher zweitranig. Plone profitiert viel mehr von leistungsfähigen externen Speichermodulen und schnellen Festplattenzugriffen. Plone unterstützt die Betriebssysteme: Linux, Windows, Mac OS X, BSD,

2 Solaris, OS/2 und andere Unix oder unix-ähnliche Systeme. Desweiteren wird Zope, CMF und eine Pythonumgebung benötigt. Diese Komponenten müssen nicht einzeln installiert werden, sondern sind bereits im Installationsumfang von Plone enthalten. Plone unterstützt folgende Browser: Mozilla, Netscape, Firefox, Camino, Internet Explorer, Opera, Safari und Konqueror. Für alle gilt, dass die neuste Ploneversion auch die neusten Browserversionen optimal unterstützt. Zwar werden auch zum Teil ältere Versionen unterstützt, jedoch können Fehler bei neu implementierten Features auftreten. Zope, CMF und Plone Zope und das zugehörige CMF dienen Plone als Plattform. Plone kann damit auf alle Funktionen, die Zope oder das CMF bieten z.b. Rechteverwaltung und Workflow, zurückgreifen. Zope besteht im Kern aus einem ZServer (Zope Webserver), der objektorientierten und transaktionsfähigen Datenbank ZODB und einem Zope-Kern. Der Zope-Kern kann über das ZMI (Zope Management Interface) verwaltet werden. Über eine Browseroberfläche ist ein Zugriff auf das ZMI möglich. Standardmäßig verwendet Plone seinen eigenen Webserver. Der ZServer bietet nur die grundlegendsten Funktionen eines Webservers und ist damit für den professionellen Einsatz wenig geeignet. Z.B. bietet er keine SSL-Unterstützung. In der Praxis ist man dazu übergegangen einen Apache-Webserver oder einen anderen leistungsfähigen Webserver mit einzubinden. In der ZODB werden standardmäßig alle Daten abgelegt. Eine zusätzliche SQL-Datenbank ist zwar nicht mehr notwendig, aber in einigen Fällen sinnvoll. Zope bietet für die meisten gängigen relationalen Datenbanksysteme (wie MySQL, Oracle, MS-SQL, PostgreSQL) und Dateisysteme (wie LDAP, Active Directory) Schnittstellen an. Plone Plone Fundation ZOPE CMF ZODB ZOPE-ZMI z.b. Oracle, MySQL, relationale DB, LDAP, Active Directory ZServer Webserver: Apache, IIS Abb. 1: Zusammenspiel von Zope, CMF und Plone vgl. [WalerowskiP]. Die Schnittstelle zwischen Zope und Plone stellt das CMF dar. Ursprünglich diente es als Toolkit, auf Basis von Zope, für die Erstellung von Portalseiten. Wurde aber gern als Content-Management- System eingesetzt. CMF stellt Elemente wie skins, tools und eine Web-Schnittstelle bereit, die von Plone verwendet und erweitert werden. Plone besitzt unter anderem in den Bereichen: Features, Usability, Barrierefreiheit und Front-/Backend eigene Entwicklungen (vgl. [CooperC]). Zope arbeitet objektorientiert. Während der Laufzeit generiert Zope Objekte, die baumartig, abgelegt werden. Dies ist im Gegensatz zu CMS mit relationalen Datenbanken etwas ungewöhnlich. Es ist möglich, dass Objekte wiederum andere enthalten und sich wie Ordner verhalten. Jedes Objekt ist in der Lage eine Webseite in HTML, basierend auf seinem Inhalt, zu erstellen. Hierfür wird ein Template mit der Bezeichnung index_html, frontpage oder index_htm erstellt. Im Template werden die Daten abgelegt, die für die Generierung einer HTML-Seite notwendig sind. Mit Hilfe des ZServers werden die Inhalte im Web veröffentlicht. Dafür sucht der ZServer gezielt nach Templates, in der Zope-Baumhierarchie, mit oben genannter Namensgebung. Findet er im aufgerufenen Objekt kein index_html Template sucht er im nächst höheren Verzeichnis. Erhält der

3 ZServer eine Browseranfrage in Form einer URL, sucht Zope das jeweilige Objekt anhand der URL. Wird beispielsweise die Browseranfrage gestellt, so sucht der ZServer nach dem Objekt mayer im übergeordneten Ordnerobjekt mitarbeiter. Ferner unterstützt Zope die Akquisition unter Objekten. Über die Ploneoberfläche können einem Objekt, neben seinem Inhalt, auch Attribute und Dublin- Core-Metadaten vergeben werden. Vorhang auf und Bühne frei Über den Frontend-Bereich können anonyme Benutzer auf das Login-, Navigations- und Kalenderportlet zugreifen. Sie können sich über die neusten News und Events informieren und nach Mitgliedern suchen. Innerhalb des Login-Portlets können sich registrierte Benutzer anmelden oder nicht registrierte Benutzer, sich als neue Benutzer anlegen. Hierfür steht ein vorgefertigtes Formular zu Verfügung. Nachdem ein Vor- und Nachname, Benutzername und eine -Adresse eingetragen wurden, erhält der neue Benutzer ein Passwort per zugesand. Benutzer können sich über RSS-Feeds regelmäßig Informationen zu einem Thema zu kommen lassen. Nach dem sich ein registrierter Benutzer erfolgreich am System angemeldet hat, befindet er sich im Backendbereich. Zusätzlich zu den Protlets Navigation und Kalender, sind die Portlets Revisionsliste und letzte Änderungen hinzugefügt worden. Hier befinden sich die Einstellungen zu jedem Benutzer, also Vor- und Nachname, Benutzername, eine kurze Biografie, bevorzugte Sprache, Foto und die Wahl seines Editors. Hat der angemeldete Benutzer die Rolle eines Autors kann er über den intern eingebundenen Editor Kupu Inhalte erstellen. Kupu ist ein leistungsfähiger Editor zur Erstellung und Bearbeitung von Texten. Er beherrscht die Formate HTML, Plaintext, Structured Text und restructured Text. In seinem Bereich bekommt der Benutzer alle von ihm erstellten Inhalte aufgelistet. Er kann Inhalte verändern, Zugriffsrechte vergeben oder entziehen und den Status, z.b. veröffentlichen oder privat schalten, seiner Inhalte ändern. Bei der Wahl einer bevorzugten Sprache, ändert sich auch die Sprache der Plone-Oberfläche. Diese ist nach [OPS] in 35 Sprachen verfügbar und wird über das Drittanbieterprodukt i18n realisiert. Hinter den Kulissen Die Präsentation der Daten erfolgt bei Plone über Templates. Das Layout wird über CSS (Cascading Style Sheets) definiert. Die Erstellung, Änderung und Verwaltung der Templates erfolgt auf der ZMI-Ebene von Zope. Für die Erstellung und Bearbeitung der Templates werden die Sprachen DTML (Document Template Markup Language), TAL (Template Attribute Language), TALES (Template Attribute Language Expression Syntax) und METAL (Macro Expansion Template Attribute Language) verwendet. DTML gilt als veraltet und wird hier nicht näher erläutert (vgl. [LatteierA,PelletierM]). TAL, METAL und TALES sind Attributsprachen, die Anweisungen als Attribute in bestehende Tags integrieren können. Dies kann in XML, XHTML und HTML zur Anwendung kommen. Ferner muss in XML und XHTML ein XML-Namensraum definiert werden. TAL ermöglicht es Daten aus der Datenbank auszulesen. METAL ermöglicht es, Templates zu strukturieren und in einzelne Module zu zerlegen. Beispielsweise soll das Logo auf jeder Seite an der gleichen Position erscheinen. Anstatt auf jeder HTML-Seite die notwendigen Befehle für das Logo einzufügen, kann über eine METAL-Anweisung der entsprechende Quellcode von einer zentralen Stelle aus aufgerufen werden. Ziel von METAL ist es Quellcode, der häufig benötigt wird, wieder zu verwenden. TALES und TAL hängen nicht miteinander zusammen, sondern sind separat einzusetzende Sprachen. TALES ermöglicht die Abfrage von Daten und das Auswerten von Objekten, um diese darstellen oder in ein Dokument einfügen zu können. Ziel ist es, das Design von der Programmierung zu trennen, d.h. es soll so wenig Programmcode wie möglich in die Templates

4 geschrieben werden (vgl. hierfür [FriedrichH]). Plone verfügt über einige Default-Content-Typen z.b. Bild, Datei, Intelligente Ordner, Link, Nachricht, Ordner, Seite und Termin. Unternehmen und Organisationen, die Plone einsetzen benötigen vielleicht eine abgeänderte Version der vorhanden Content-Typen oder komplett neu definierte Content-Typen. Beispielsweise müssen Sollfelder neu definiert, Eingabemöglichkeiten beschränkt, Schriftgrößen und -arten vorgegeben und das Hinzufügen von Bildern untersagt werden. Um Content-Typen anzupassen oder neu anzulegen stellt Plone drei Möglichkeiten bereit. Zuerst können nicht benötigte vordefinierte Content-Typen auf ZMI-Ebene umgeschrieben werden. Hierfür werden aber neben den Programmierkenntnissen in Python, DTML, TAL, METAL und TALES vor allem Kenntnisse über die Zusammenhänge innerhalb der Zope-Plone-Struktur benötigt. Eine weitere Möglichkeit besteht im Neuentwurf von Content-Typen. Neben den Programmierkenntnissen, sind vor allem Kenntnisse des Dateisystemes von Zope/Plone notwendig. Die dritte und einfachste Möglichkeit bietet Plone über das Framework Archetypes. Archetypes ist ein Drittanbieterprodukt von Plone, welches bei Bedarf nachträglich installiert werden kann. Es besteht aus mehreren Tools (ArchGenXML, Portal Transforms) und ermöglicht eine automatisierte Erstellung von Content-Typen. Für diese Content-Typen erzeugt es automatisch Seiten zum ansehen und editieren, sowie eindeutige UIDs für Objekte, die systemweit referenziert werden können, und Referenzen zwischen Objekten. Während der Entwicklung mit Archetypes werden die Default-Sicherheitseinstellungen für Workflow und Benuterrechte bei den Content-Typen gesetzt, d.h. falls andere Einstellungen in diesen Bereichen vorgenommen wurden, so müssen diese nachträglich beim neuen Content-Typ eingestellt werden. ArchGenXML ist ein Kommandozeilenwerkzeug. Es erzeugt automatisiert aus UML 2.0 Diagrammen im XMI-Format Content-Typen mit allen notwendigen Bestandteilen (wie Templates, Pythoncode, Ordner im Dateiverzeichnis, Workflows, Benutzerrechte). Die Bestandteile können bei Bedarf angepasst werden. UML 2.0 Diagramme sollten mit Werkzeugen entworfen werden, die das XMI-Format beherrschen. UML-Modellierungstool: -ObjectDomain -ArgoUML -Poseidon -Sybase Powerdesinger erstellen UML-Diagramm Export UML-Diagramm in XMI-Format Templates erstellt erstellt ArchGenXML Kommandozeilentool Pythoncode erstellt Ordner im Dateiverzeichnis erstellt erstellt Workflows Benutzerrechte Abb. 2: Funktionsweise von ArchGenXML (vom Autor entworfen). Das ganze basiert auf dem Prinzip des Rapid-Developments, da in sehr kurzer Zeit viele Codeteile erzeugt werden können. Roundtrip- oder Reverse-Engineering sind mit der derzeitigen ArchGenXML-Version noch nicht möglich (vgl. [FriedrichH]).

5 Benutzer- und Rechteverwaltung Bereits nach der Installation stellt Plone eine einsatzfähige Benutzer- und Rechteverwaltung zu Verfügung. Diese kann über das ZMI beliebig angepasst werden. Plone besitzt zwei Workspaces. Einen Memberworkspace und einen Groupworkspace. Der Memberworkspace enthält alle Benutzerordner der Mitglieder. Sobald sich ein Mitglied auf der Ploneseite registriert wird ein Ordner im Memberworkspace mit dem jeweiligen Benutzernamen angelegt. Dieser Benutzerordner enthält alle persönlichen Daten über den Benutzer selbst und alle Inhalte, die der Benutzer erstellt hat. Wird eine Gruppe mit ihren zugehörigen Rollen angelegt, so erhält jede Gruppe im Groupworkspace einen eigenen Ordner. Nach [RapozaJ] kann eine Gruppe auch mehrere andere Gruppen enthalten. Alle Aktionen, die in Plone durchgeführt werden, sind durch Berechtigungen geschützt. Der Wächtermechanismus überprüft, ob der aktuelle Benutzer eine Berechtigung besitzt, bevor die Aktion ausgeführt wird. Programmierer definieren die Berechtigungen, während Administratioren sie an Benutzer oder Skripte vergeben. Rechte können über die Zope-ZMI gelöscht, verändert oder neu hinzugefügt werden. Falls ein Administrator sich selbst versehentlich Zugangsrechte entzieht, kann er über einen Notfallbenutzer, welcher in Plone standardmäßig vorhanden ist, sich im System anmelden und die nötigen Rechte wieder neu vergeben. Der Notfallbenutzer selbst kann nur dem Administrator Rechte geben aber nichts anderes ausführen. Im Folgenden wird die Default- Benutzerverwaltung erläutert. Recht Proxy Rolle Lokale Rolle Rolle Benutzer Gruppe Objekt l Objekt m Objekt n Abb. 3 Rechte, Rollen und Gruppen, vgl. [FriedrichH]. Einzelne Rechte werden nicht direkt an den Benutzer vergeben, da dies nach einiger Zeit zu unübersichtlich wird und zu erhöhtem Verwaltungsaufwand für den Administrator führt. Rechte werden Rollen zugewiesen und Rollen wiederum einem Benutzer oder einer Gruppe. Ein Benutzer kann Berechtigungen von unterschiedlichen Rollen oder Gruppen erhalten. Plone definiert drei unterschiedliche Arten von Rollen: die Proxy-Rolle, lokale Rolle und die normale Rolle. Rollen und lokale Rollen sind direkt mit einem Benutzer verknüpft, d.h. die Rollen hängen mit dem Benutzer zusammen. Bei Rollen wird zwischen zuweisbaren Rollen wie owner, member, reviewer und manager und nicht zuweisbaren Rollen wie anonymous und authenticated unterschieden. Letztere von Beiden werden vom System vergeben, die anderen werden einem Benutzer vom Administrator zugewiesen. Logt sich ein Benutzer mit der Rolle reviewer im System ein, so besitzt dieser die beiden Rollen authenticated und reviewer. Lokale Rollen entziehen sich der Kontrolle des Administrators. Sie vergeben Rechte an einem Objekt, die ein Benutzer sonst nicht hat. Owner von Objekten können anderen Benutzern, über eine lokale Rolle, Rechte an ihren Objekten geben. Z.B. kann ein Mitarbeiter aus der

6 Marketingabteilung einem Mitarbeiter aus der Personalabteilung das Recht geben an seinem Artikel mit zu arbeiten. Lokale Rollen sind für Administratoren im System schwer nach zu vollziehen, da Plone keine Liste der vergebenen lokalen Rollen bereitstellt. Für Benutzer stellen lokale Rollen eine Möglichkeit dar Bereichsgrenzen, die von den Administratoren gesetzt wurden, zu umgehen (vgl. [FriedrichH] [McKayA] und [MeloniJ]). Proxy-Rollen beziehen sich hingegen auf ein Objekt und nicht auf einen bestimmten Benutzer. Jeder Benutzer führt die erlaubten Aktionen auf diesem Objekt mit der angegebenen Proxy-Rolle aus. Verwendung findet sie bei Skripten, die weitreichende Berechtigungen benötigen, die die Benutzer nicht besitzen sollen. Um nicht jedem Benutzer diese Rolle geben zu müssen, wird das Objekt mit einer Proxy-Rolle versehen. Beispielsweise soll es anonymen Benutzern möglich sein, andere Bentutzer aus einer Benutzerliste zu finden. Anonyme Benutzer sollen nur die Benutzer angezeigt bekommen, die mit dem jeweiligen Kontext zusammenhängen. Die Auflistung der Benutzer wird über ein Skript ermöglicht. Um dieses Skript auszuführen brauchen die anonymen Benutzer die notwendigen Rechte, die sie aber nicht erhalten sollen, da dies zu weitreichende Folgen hätte. Somit erhält das Skript eine Proxy-Rolle und kann dadurch auf andere Objekte zugreifen, die für anonyme Benutzer unzugänglich sind (vgl. [McKayA]). Benutzerrecht Proxy-Rolle Objekt r Benutzer m Benutzerrecht Objekt b Proxy-Rolle Objekt s Benutzerrecht Abb. 4 Proxy-Rollen (vom Autor entworfen). Abschließend läßt sich zu den Rechten sagen: Falls ein Benutzer nur ein einziges Zugriffsrecht auf ein Objekt (Medium wie Text, Bild) erhält, kann er trotz Zugriffsverbot(e), auf dieses Objekt zugreifen. Workflow Bei Workflowübergängen kann eingestellt werden, ob der Wächtermechnismus vor oder nach der Aktion aktiv wird. Plone definiert zwei Workflows einen für die Ordner und einen für die restlichen Content-Typen. Defaultmäßig sind die Zustände visible, private, published und pending definiert. Mittels der vordefinierten Übergänge kann zwischen den einzelnen Zuständen gewechselt werden. Die Übergänge sind hide, show, submit, publish, reject und retract. Im Zustand private befinden sich alle Inhalte (Bilder, Texte, Dokumente, Artikel), die von ihrem Besitzer erstellt und noch nicht freigegen wurden. Auf den private -Bereich hat nur der jeweilige Benutzer und Benutzer mit lokalen Rollen zugriff. Andere Mitglieder können in diesen Bereich nicht einsehen. Im Zustand visible befinden sich alle Inhalte die von einem Benutzer freigegeben wurden. In diesem Zustand ist der Inhalt für alle anderen angemeldeten Mitglieder sichtbar. Wird ein Inhalt in den pendig -Zustand überführt, so erscheint er in der Revisionsliste des Redakteurs. Eine automatische Lastverteilung auf unterschiedliche Redakteure ist in Plone nicht defaultmäßig realisiert. Kann aber mit eigenem Entwicklungsaufwand nachgerüstet werden. Inhalte sind für anonyme Benutzer erst sichtbar, wenn diese sich im published -Zustand befinden.

7 Ordner-Workflow Owner haben die Möglichkeit über show ihren Ordner vom private in den visible -Zustand zu überführen. Diesen Vorgang können sie über hide wieder rückgängig machen. Redakteure überprüfen den Inhalt des Ordners und können ihn mit Hilfe von publish für den öffentlichen Bereich freigegeben. Der owner eines Ordners besitzt die Möglichkeit über hide, diesen aus dem öffentlichen Bereich wieder in den privaten Bereich zu überführen oder über retract den Ordner in den visible -Zustand zu überführen. Für beide Aktivitäten benötigt der owner nicht die Erlaubnis des Redakteurs. Benutzer mit der Rolle reviewer haben die Möglichkeit ihre Ordner mittels publish direkt vom privaten Bereich in den öffentlichen Bereich zu transferieren, da sie selbst die Rechte für publish besitzten. published owner:retract reviewer:publish visible reviewer: publish owner:hide owner:show owner:hide private Abb. 5 Ordner-Workflow, vgl. [McKayA]. Default-Workflow von Plone für die Content-Typen Ähnlich wie beim Ordner-Workflow kann der owner über show seine Inhalte vom privaten Bereich in den visible -Zustand transferieren und über hide wieder rückgängig machen. Damit der Redakteur weiß, welche Inhalte er veröffentlichen soll, muss der owner die Inhalte mit submit vom visible in den pendig -Zustand überführen. Der pendig -Zustand ist die Revisionsliste, die dem Redakteur alle zu veröffentlichen Inhalte auflistet. Diese muss der Redakteur abarbeiten. Falls ein Inhalt gelungen ist, kann der Redakteur mit Hilfe von publish diesen veröffentlichen. Er hat aber auch die Möglichkeit einen Inhalt abzulehnen. Der abgelehnte Artikel wird dann wieder über reject in den visible -Zustand überführt. Der owner eines Inhaltes hat im pending -Zustand die Möglichkeit über hide seine Inhalte wieder in den privaten Bereich oder über retract in den visible -Zustand zu wandeln. Falls ein Inhalt bereits veröffentlicht ist, kann der owner diesen ebenfalls über reject, ohne Erlaubnis des Redakteurs, zurück zu ziehen. Benutzer mit der Rolle reviewer können selbst Inhalte erstellen, müssen diese, im Gegensatz zum Ordner-Workflow, vor Veröffentlichung in den visible -Zustand übertragen. Aus dem visible Zustand können sie direkt ihre Inhalte über publish veröffentlichen und mit reject wieder zurück ziehen.

8 owner:hide pending owner: submit reviewer:publish owner: retract reviewer: reject owner: retract published reviewer: reject reviewer: publish private owner:show visible owner:hide Abb. 6 Default-Workflow, vgl. [CooperC]. Problematisch ist die Tatsache, dass owner veröffentlichte Artikel zurück ziehen können. Eigentlich ist die Entscheidung dem Redakteur vorbehalten, welche Artikel und für welche Dauer sie veröffentlicht werden. Owner können nicht, wenn sie nicht gerade selbst die Rolle reviewer besitzen, Artikel veröffentlichen, die nicht von Redakteuren freigegeben wurden. Sie können aber freigegebe Artikel aus dem öffentlichen Bereich zurück ziehen, ohne dass der Redakteur dies unter seiner Kontrolle hat. ZEO und VHM ZEO (Zope Enterprise Object) und VHM (Virtual Host Monster) sind Funktionalitäten von Zope, da Plone auf Zope aufsetzt, können diese Funktionalitäten von Plone verwendet werden. ZEO ermöglicht es mehreren Prozessen gleichzeitig auf eine ZODB zu zugreifen. Dadurch wird es möglich mehrere Instanzen von Plone auf einem oder mehreren verteilten Rechnern zu betreiben. Server können im laufenden Betrieb hinzugefügt oder entfernt werden. Falls ein Server abstürzt, werden die Anfragen von den anderen Servern bearbeitet. Es wird sichergestellt, dass alle Instanzen konsistente Informationen von der selben Datenbank beziehen. ZEO arbeitet in einer Client- /Serverarchitektur. Die einzelnen Ploneprozesse werden durch die ZEO-Clients repräsentiert. Alle Clients sind an einen zentralen ZEO-Server angebunden. Die ZEO-Clients aggieren einerseits als Server für Anfragen aus dem Internet und andererseits als Clients, da sie Daten vom ZEO-Server anfragen (vgl. [LatteierA,PelletierM]). ZEO-Client 1 ZODB ZEO-Server ZEO-Client 2 Internet ZEO-Client n Abb. 7: ZEO-Architektur, vgl. [LatteierA,PelletierM]. Das ZEO-Konzept beherrscht keine Lastverteilung. Diese muss über zusätzliche Hardware- oder Softwarekomponenten realisiert werden. Die einfachste Möglichkeit wäre es, dem Anwender eine Liste von Mirrors anzubieten. Jedoch hat man als Betreiber einer Seite keinen Einfluss darauf, wie viele Anwender einen Mirror wählen. Weitere Möglichkeiten für eine Lastverteilung ist der

9 Einsatz von Round-Robin-DNS mittels eines DNS-Servers und die Verwendung von Layer-4- Switching. Die beiden Softwareprodukte Squid und Pound unterstützen die Lastverteilung auf Softwareebene. Der Flaschenhals in der ZEO-Architektur ist der ZEO-Server und der Zugriff auf die ZODB. Der ZEO-Server sollte über Backup-Systeme verfügen, auf die bei einem Ausfall des ZEO-Servers gewechselt werden kann. Nach [IhdeM, PilzA] und [LatteierA,PelletierM] vertreibt die Zope Corporation ein kostenpflichtiges Produkt, namens Zope Replication Services, welches redundante Datenbankserver ermöglicht. Bei Ausfall des primären Datenbankservers, übernimmt der sekundäre Datenbankserver. Mit Hilfe des VHM können URLs umschrieben werden. Objekte können ihre eigenen URLs generieren. Jedoch enthalten diese URLs immer den Namen des Objektes. Aufgabe des VHM ist es, diese Objekt-URLs umzuschreiben. Beispielsweise kann im ZMI-Verzeichnis von Zope der Ordner Reptilien angelegt werden. Dieser enthält eine ID und ein index_html -Template. Im VHM wird die URL angelegt. Stellt nun ein Internetanwender eine Anfrage an so wandelt das VHM diese Adresse lokal in um. Besteht die Systemlandschaft nur aus ZServer und VHM, dann arbeitet der ZServer auf Port 8080 und VHM auf Port 80. Der ZServer und das VHM weisen nur einen geringen Funktionsumfang auf, dieser ist für Testzwecke ausreichend, jedoch nicht für den produktiven Einsatz geeignet. Zum Beispiel beherrscht der ZServer keine verschlüsselte Übertragung (SSL) und Rewrite-Funktionen. Deshalb ist es in der Praxis üblich einen leistungsfähigeren Webserver wie z.b. Apache vor den ZServer zu schalten und auf VHM ganz zu verzichten, da die Funktionalitäten des VHM vom Apache abgedeckt werden (vgl. [LatteierA,PelletierM]). Der Apache arbeitet auf Port 80 und schreibt die URLs um, d.h. er übernimmt das Virtuelle- Hosting. Hierfür werden Parameter in Apaches mod_rewrite -Modul gesetzt. Zum Beispiel wird die Anfrage in /home/virtualhostroot umgeschrieben. Der Apache leitet die Anfragen an den ZServer, mit Port 8080, weiter. Dieser sucht innerhalb seiner Verzeichnisstruktur nach den angefragten Objekten. Statische Inhalte einer Seite können z.b. im Apacheverzeichnis abgelegt und die dynamischen von Zope generiert werden. Fazit Plone ist nach der Installation, sowohl im Frontend- als auch im Backendbereich, einsatzfähig. Jedoch sind die Defaulteinstellungen nicht für alle Kunden von Plone zufriedenstellend. Das Customizing von Plone setzt einen sicheren Umgang mit Zope, CMF und vor allem Python voraus. Nach [IhdeM, PilzA] hat Python nicht die selbe Verbreitung wie Perl oder PHP auf dem Markt, d.h. PHP-, Perl- oder Java-Know-How sind auf dem Markt leichter zu finden als Python-Know-How. Ein weiteres Problem besteht darin, ein geeignetes Webspace-Angebot zu finden. Da Plone auf Zope und Python aufbaut, wird ein Anbieter benötigt, der Zope-Instanzen inklusive Plone betreibt. Solche Anbieter sind im Gegensatz zu PHP und MySQL rar (vgl. [plonenetpro]). Plones größter Pluspunkt ist, dass es unter Open-Source vertrieben wird. Es unterliegt der GNU General-Public-License. Im Rahmen dieser, darf Plone lizenzfrei im privaten und kommerziellen Bereich, verwendet werden. Ein weiterer Vorteil ist, dass hinter Plone eine Stiftung (die Plone Foundation) und eine freie Community steht. Die Plone Foundation ist Inhaberin der Rechte und für die weitere Entwicklung verantwortlich (vgl. [BJ]). Zusätzlich beteiligen sich Unternehmen, wie Computer Associates, an dieser Stiftung (sowohl finanziell, als auch entwicklungstechnisch) und integrieren Plone in ihre eigenen kommerziellen Anwendungen (vgl. [IhdeM, PilzA]).

10 Literatur [BJ] Burton, Joel: The Plone Foundation exists to further the development, marketing, and legal affairs of Plone and the Plone community, , Mai [CooperC] Cooper, Cameron: Building Websites with Plone An in-depth and comprehensive guide to the Plone content management system, Packt Publishing Ltd., Birmingham 2004, ISBN: [FriedrichH] Friedrich, Hans Jörg: Content Management mit Plone Gestaltung, Programmierung, Anwendung und Administration, Springer-Verlag Berlin, Heidelberg 2006, ISBN: [IhdeM, PilzA] Ihde, Maik; Pilz Alexander: Vielarmige Geste CMS mit Python: Plone 2.1.1, (Hrsg.) Heise Zeitschriften Verlag, in: ix 12/2005, S [LatteierA,PelletierM] Latteier, Amos; Pelletier, Michel; et al: The Zope Book 2_7 Edition, Mai [McKayA] McKay, Andy: Plone Das definitive Handbuch für Administratoren und Entwickler, Addison- Wesley Verlag, München 2005, ISBN: [MeloniJ] Meloni, Julie: Plone Content Management Essentials, Sams Publishing, Indianapolis 2005, ISBN: [OPS] Plone Foundaton, et al: Speaks Your Language, Mai [plonenet] Plone Foundation, et al: Plone Sites, Mai [plonenetpro] Plone Foundaton, et al: Plone Providers, Mai [RapozaJ] Rapoza, Jim: Plone Improves Usability, Flexibility, , April [SchmidtN] Schmidt, Nicola: Neue Offenheit CA stellt Software unter Open-Source-Lizenz, (Hrsg.) Heise Zeitschriften Verlag, in: c't 13/04, S. 57. [WalerowskiP] Walerowski, Peter: Zope, Galileo Press GmbH, Bonn 2004, ISBN: