IES-Ökosystem

Ökosystem

Das IES-Ökosystem ist ein individuell für den einzelnen Kunden aufgebautes System, dass üblicherweise aus verschiedenen Servern besteht und auf die Infrastruktur des Kunden angepasst ist. Je nach Anforderung besteht das System aus Standard-Komponenten und –Diensten sowie individuell angepassten oder neu entwickelten Komponenten und Diensten. Die Integration von Diensten, die der Kunde bereits betreibt oder die Integration von Diensten Dritter ist ebenfalls Teil des IES-Ökosystems.

Prinzipiell kann ein IES-Ökosystem in unterschiedlichsten Konstellationen betrieben werden. Eine einfache Installation für kleine und mittlere Anforderungen kann u.U. mit einem Server realisiert werden, bei dem der IES, die Datenbank und der Webserver auf einem Server laufen.

Für größere Installationen ist eine Trennung von IES-Server, Datenbank und (n unterschiedliche) Webservern sinnvoll.

In der Regel ist ein E-Mail-Server ebenfalls Teil des IES-Ökosystems. Dieser existiert im Normalfall bereits beim Kunden und wird im IES-Ökosystem verwendet. Der IES und der/die Web-Server müssen E-Mails versenden können (SMTP) und verwenden hierfür den Email-Server. Je nach Anforderung z.B. bei Verwendung von InfoTicket werden auch IMAP-Konten vom System verwendet.

Existiert beim Kunden ein LDAP-Server der angebunden werden soll wird dieser in das IES-Ökosystems aufgenommen. Hier müssen Nutzer-Daten aus dem LDAP-System ausgelesen und Authentifizierungen gegen den LDAP-Server ausgeführt werden können.

Je nach Kunde ist diese Netzwerkstruktur unterschiedlich. Für den Betrieb des Ökosystems ist es erforderlich, das Komponenten mit Diensten anderer Komponenten Serverübergreifend Kommunizieren können. Je nach Netzwerkstruktur müssen hier ggf. Firewall und/oder Proxy-Regeln zur Gewährleistung der Kommunikation gesetzt werden.

In der Regel gibt es im IES-Ökosystem einen IES-Server, n Web-Server, einen E-Mail-Server und ggf. einen LDAP-Server. Je nach Anforderung des IES-Servers wird die Datenbank auf dem IES-Server selber oder auf einem eigenen Server installiert.

Folgende Grafik zeigt eine beispielhafte Einbindung der einzelnen Komponenten in ein bestehendes Netzwerk mit internem Netz und DMZ sowie unterschiedlichen Firewalls.

IES

Der IES ist ein von Sitepark entwickelter Applikation-Server auf Basis des Jetty. Er ermöglicht Sitepark die Entwicklung von Produkten auf einer einheitlichen Basis und stellt unter anderem ein produktübergreifendes Daten-, und Benutzermanagement bereit. Der IES ist die Technologie-Plattform von Sitepark.

Webserver

Die Webserver im IES-Ökosystem haben unter anderen die Aufgabe Dateien auszuliefern, die vom IES generiert wurden. Meistens besteht die vom IES generierte Website nicht nur aus einfachen Webseiten, sondern enthält Web-Applikationen die in der Webseite genutzt werden (Volltextsuchen, Veranstaltungskalender, Newsletter-Anmeldung, …)

Hier wird die Trennung zwischen CMS (auf IES-Server) und Webserver deutlich. Die Pflege der Daten erfolgt über den IES-Server. Die für eine Webseite relevante Daten werden laufend auf den Webserver übertragen. Damit kann der Webserver weitestgehend autonom vom CMS arbeiten. Nur für interaktive Funktionen der Webseite, bei der Daten direkt vom CMS gelesen oder geändert werden, ist die Kommunikation des Webservers mit dem IES-Server notwendig ist. In diesem Fall kommuniziert der Webserver mit dem IES-Server über RPC-basierte Aufrufe mittels der einer von Sitepark bereitgestellten PHP-API. Ein direkter Zugriff auf den IES-Server aus dem Internet ist i.d.R. nicht erforderlich.

IES-Webnode

Der IES-Webnode ist ein Java-Applikations-Server auf Basis des Jetty. Er wird auf Web-Servern installiert, die vom IES generierte Webseiten ausliefern. Innerhalb des IES-Webnode werden Module installiert, die erweiterte Funktionalitäten für die Webseite bereitstellen (z.B. Volltextsuche). Der IES-Webnode ist der „lange Arm“ des IES zum Webserver, um so IES-Technik auf dem Webserver bereitzustellen. Alle Daten des CMS sind jedoch weiterhin nur über RPC-Aufrufe des Webnodes verfügbar. Prinzipiell erfüllt der IES-Webnode zwei wesentliche Funktionen auf dem Webserver:

• Bereitstellung lokaler Funktionen, die über PHP hinausgehen. Hierzu zählt zum Beispiel die Volltextsuche oder aber auch mögliche Verwendung anderer Services wie Piwik o.ä.
• Gegenstelle des IES auf dem Webserver.

ProfilePlus

Das Modul ProfilePlus ermöglicht durch das Sitepark Auth-Modul die Authentifizierung eines Nutzers über die Website am IES bzw. IES-Webnode. Sollen Inhalte auf dem Webserver personalisiert werden bedeutet dies, dass ein Nutzer sich am Webserver anmelden muss/kann.

Er erreicht dann über die zugewiesenen Gruppenrechte Zugriff auf mehr oder weniger Inhalte der Website. Auch ist der Nutzer für mögliche Online-Funktionen bereits bekannt und kann so z.B. Formulare absenden oder Kommentare posten. Voraussetzung hierfür ist das Modul ProfilePlus von Sitepark. Dieses erlaubt die Anmeldung über die IES-API am IES oder einem anderen konfiguriertem IES-Webnode mit separater Datenbank-Konfiguration. Funktionen zur autonomen Registrierung und Profil-Verwaltung auf der Website werden ebenfalls über dieses Modul bereit gestellt.

Details können je nach Projekt entsprechend abgestimmt werden.

Kommunikation vom IES-Server

Remote-File-System zum Webserver (NFS-mount, rsync, …)

Damit der Webserver autonom vom IES-Server arbeiten kann werden alle relevanten Daten auf das Dateisystem des Webservers übertragen. Hierbei handelt es sich in der Regel um PHP-, CSS- und JavaScript-Dateien, die über Templates vom System stets konsistent generiert werden. Alle verwendeten Medien werden in den tatsächlich verwendeten Formaten mit ausgeliefert. Weiterhin werden Bibliotheken des IES (z.B. PHP IES-API) im DocumentRoot des Webserver kopiert und aktuell gehalten.

Idealerweise ist eine synchrone Verbindung zwischen den beiden Systemen vorzusehen, bei der auf dem Webserver ein Ordner im Dateisystem für den IES-Server freigeben wird. Dieser wird dann vom IES-Server gemountet. Eine entsprechende Performanz dieser Verbindung ist zwingend notwendig. Je nach technischer Reglementierung kann dieser Mount über SSH oder HTTP(S) getunnelt werden und per NFS, WebDAV o.ä. erfolgen. Alternativ kann auch eine Lösung wie ein NAS oder SAN eingesetzt werden.

Ist eine direkte Verbindung zwischen den beiden Systemen technisch nicht möglich kann eine Übertragung der Daten auch per Synchronisation (rsync o.ä.) erfolgen. In diesem Fall müssen aber auf dem IES-System lokale Domains konfiguriert werden über die Redakteure Vorschau-Ansichten erzeugen und aufrufen können. Wird der IES beendet, so kann der Webserver auch weiterhin die lokal gespeicherte Website ausliefern. Alle relevanten Dienste wie z.B. Suchen werden vom Webserver direkt bereit gestellt.

IES-Webnode des Webservers

Der IES hat mit dem IES-Webnode einen klaren, gerichteten Kommunikationskanal zum Webserver. Dieser ist über HTTPS geschützt und erlaubt die Übertragung von Daten des IES auf den Webserver, sowie die Bereitstellung von Information vom Webserver für den IES.

Änderungen an einzelnen Artikel werden vom IES-Server dem IES-Webnode auf dem Webserver kommuniziert, damit dieser z.B. den Solr-Suchindex partiell aktualisiert.

Ein Funktionsbeispiel für den IES-Webnode ist folgendes: Im IES-Server werden vom Redakteur inhaltliche Änderungen an einem Artikel vorgenommen. Der IES generiert alle relevanten Dateien neu. Diese sind über entsprechende Mounts direkt auf dem Webserver verfügbar. Die Volltextsuche ist aber damit nicht mehr aktuell. Für diesen Zweck sendet der IES einen entsprechenden Request an den IES-Webnode und nennt geändert URLs. Der IES-Webnode stößt in diesem Fall dann z.B. das Solr-Modul für die Volltextsuche an, welches die genannten URLs im Index aktualisiert. Damit ist die Konsistenz der Website gewährleistet.

Email-Server

Der IES versendet für verschiedene Anwendungsfälle E-Mails. In der Regel kann hierfür ein bereits vorhandene E-Mail-Server verwendet werden. Je nach gewünschter Konfiguration schickt der IES-Server die E-Mails zunächst an einen SMTP-Dienst auf dem eigenen Server (localhost). Dieser kann dann über Relay-Konfigurationen die E-Mail weiterleiten. Alternativ kann auch direkt der E-Mail-Server des Kunden angesprochen werden.

Einige IES-Applikationen wie z.B. Infoticket benötigen ein oder mehrere IMAP-Konten um eingehende E-Mails zu verarbeiten. In diesem Fall wird der E-Mail-Server des Kunden auch über SMTP angesprochen.

LDAP-Server

Um eine doppelte Pflege von Nutzerdaten zu vermeiden, wird häufig ein LDAP-Server angebunden. Der IES importiert und synchronisiert in regelmäßigen Abständen die Nutzer-Daten, die im IES zur Verfügung stehen sollen. Hierfür wird ein lesender Zugriff auf das LDAP-System benötigt. Erfahrungsgemäß sind die Importregeln von LDAP-Daten individuell. Auf diese Anforderung hat sich Sitepark eingestellt und stellt einen Import zur Verfügung, der bisher alle Anforderungen erfüllten konnte.

Passwörter der LDAP-Nutzer werden nie importiert. Die Authentifizierung der LDAP-Nutzer erfolgt immer direkt gegen den LDAP-Server.

Kommunikation vom Webserver

IES-Server

Sind auf der erzeugten Website Funktionen vorgesehen, bei denen Daten vom Webserver an den IES-Server übertragen oder Daten vom IES-Server abgefragt werden müssen, ist dies über entsprechende Konfigurationen vorzusehen. Es wird zwischen folgenden Aufrufen unterschieden:

Für alle der genannten Fälle ist somit kein direkter Zugriff von Nutzern auf das IES-System notwendig. Alle Zugriffe erfolgen grundsätzlich über den Webserver.

• Zugriff auf sog. Live-GUIs. Dabei handelt es sich um den Aufruf von Modules des IES, die bestimmte Dienstleistungen bereitstellen. Beispiel hierfür ist z.B. der NewsDesk.
• Zugriff auf Funktionen der IES-API in JavaScript oder PHP z.B. über das Verzeichnismodul, bei dem Besucher der Website Beiträge erfassen können.
• Zugriff auf IES-Module wie z.B. den Counter. Auch der Zugriff auf z.B. InfoSite ließe sich auf diese Form konfigurieren.

Die oben genannten Anfragen werden an den Host des Webservers gestellt. Dieser verfügt über fein justierte Proxy-Einstellungen, die entsprechende Anfragen (URL-RegExp z.B. /ies/infosite/control/) über eine weitere Firewall an den IES-Server im internen Netz übertragen. Dieser liefert dann die Antwort an den Webserver, der diese zurück an den Benutzer schickt.

Zwischen dem Webserver und dem IES-Server kann auch eine gut konfigurierte Application-Firewall eingesetzt werden. Diese erlaubt weitere sicherheitsrelevante Konfiguration bzgl. der übertragenen Daten. Auch weitere Proxy-Hosts könnten hier verwendet werden.

Die Kommunikation zwischen dem Webserver und dem IES-Server erfolgt stets über HTTP bzw. HTTPS (Port 80 und 443) und wird auf dem IES-Server vom Apache lokal über weitere Proxy-Regeln an den IES-Prozess geleitet.

• Der IES wird nie direkt angesprochen!
• Im IES ist ein integrierter Jetty-Server für die Ausführung von entsprechenden Servlets verantwortlich.

Der IES fungiert im Prinzip über die genannten Schnittstellen als eine Art Webservice. Bei dem Aufruf der IES-API (RPC-Call) erfolgt die Kommunikation mit dem IES ausschließlich im JSON-Format. Alle relevanten Informationen wie eine Session-ID werden entsprechend mit gesendet (stateless).

Email-Server

In der Regel ist es erforderlich, dass der Web-Server E-Mails versenden kann (z.B. bei Verwendung eines Kontakt-Formulars). Dies sind E-Mails die an konfigurierbare Empfänger gesendet werden. Hier wird normalerweise der E Mail Server des Kunden angebunden.

IES-Update-Server

Der IES besteht aus einem Kern und vielen Modulen, die kontinuierlich weiter entwickelt werden. Für den einfachen und reibungslosen Ablauf eines Updates eine HTTP(S)-Verbindung zum IES-Update-Server erforderlich (https://ies.sitepark.com/updater/).

Kommunikationsdiagramm

Das IES-Ökosystem ist ein auf Kundenwünsche kontinuierlich angepasstes, erweitertes und optimiertes System. Die Erfahrung hat gezeigt, dass eine optimale Unterstützung von Sitepark für die Wartung und Pflege des IES-Ökosystems nur über einen guten Wartungszugang erfolgen kann.

Das IES-Ökosystem kann komplex und sehr individuell sein. Es wird bestmöglich an die Umgebung des Kunden angepasst. Fragen zu auftretende Fehler können daher in der Regel nicht pauschal beantwortet werden, sondern erfordern oft einen Blick in das System.