Kommunikation zwischen IES und Webserver: Unterschied zwischen den Versionen

Aktuelle Version vom 21. November 2014, 14:30 Uhr

Weiterleitung nach:

IES-Ökosystem

@@ Zeile 1: / Zeile 1: @@
-==Technische Beschreibung der Kommunikationskanäle zwischen dem IES-Server und dem Webserver==
+#REDIRECT [[IES-Ökosystem]]
-Prinzipiell kann der IES-Server in unterschiedlichsten Konstellationen betrieben werden. Eine einfach Installation für kleine und mittlere Anforderungen kann u.U. mit einem System 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) Webserver sinnvoll. Für die Bereitstellung der notwendigen Funktionen müssen technische Voraussetzungen erfüllt sein um mehr oder weniger Funktionen bereit zu stellen.
-Folgende Grafik zeigt die typische Einbindung der einzelnen Komponenten in ein bestehendes Netzwerk mit '''internem Netz''' und '''DMZ''' sowie unterschiedlichen '''Firewalls'''.
-[[Datei:Communication IES-Webserver.jpg|700px|alt=Kommunikationskanäle zwischen dem IES-Server und dem Webserver]]
-Typischerweise wird der IES-Server im internen Netz betrieben. Alle weiteren Ressourcen wie eine Datenbank oder ein NAS sind dort verfügbar und vom Zugriff aus dem Internet geschützt.
-Die Redakteure arbeiten direkt im internen Netz und haben damit Zugriff auf die entsprechenden Komponenten wie z.B. InfoSite.
-Häufig wird im gleichen internen Netz auch ein Webserver für den Intranet-Auftritt gehostet.
-==Kommunikation vom IES-Server zum Webserver==
-''Datentransfer vom IES-Server zu dem Webserver, Trigger bei Änderungen im Datenbestand''
-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.
-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. Details hierzu im Abschnitt [[#Funktionsweise des IES-Webnodes auf den Webservern|IES-Webnode]].
-Bei Änderungen an einzelnen Artikel kann der IES-Server den [[#IES-Webnode|IES-Webnode]] auf dem Webserver auslösen, damit dieser z.B. den Solr-Suchindex partiell aktualisiert.
-==Kommunikation vom Webserver zum IES-Server==
-''Ausführung von Funktionen auf der Website, die Interaktionen mit dem IES-Server erfordern''
-Sind auf der erzeugten Website Funktionen vorgesehen, bei denen Daten vom Webserver an den IES-Server übertragen werden müssen, ist dies über entsprechende Konfigurationen vorzusehen.
-Es wird hier zwischen unterschiedlichen Aufrufen unterschieden.
-<div class="note">Für alle Fälle ist kein direkter Zugriff auf das IES-System notwendig!</div>
-* 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 Apache Tomcat (via JBoss) für die Ausführung von entsprechenden Servlets verantwortlich.
-* Ein direkter Aufruf des JBoss ist nicht notwendig.
-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 mitgesendet (stateless).
-==Funktionsweise des IES-Webnodes auf den Webservern==
-''Auf jedem Webserver wird ein IES-Webnode betrieben, der lokal Dienste für die Website und die Kommunikation mit dem IES übernimmt''
-Technisch ist der IES-Webnode ein embedded Jetty-Server mit einfachen Servlets, die entsprechende Funktionen bereitstellen. Das Update dieses IES-Webnodes wird über das Update des IES angestoßen. Notwendige Module werden über den IES an den IES-Webnode übertragen.
-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.
-: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. Bei entsprechendem Bedarf kann der IES Daten, die vom IES-Webnode durch Funktionen der Website ''gesammelt'' wurden ''pollen'' und so in das System übernehmen.
-:Ein Beispiel hierfür wäre z.B. folgendes Szenario: Ein Nutzer der Website füllt online ein Formular aus. Dieses wird über PHP-Funktionen an den lokalen IES-Webnode übergeben. Dort wird es vorgehalten, bis der IES-Server einen Poll-Request an den IES-Webnode sendet. Die Daten werden dann an den IES übertragen und dort weiter verarbeitet.
-:Ein anderes 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 aus, welches die genannten URLs im Index aktualisiert. Damit ist die Konsistenz der Website gewährleistet.
-Zukünftig werden noch weitere Funktionen über den IES-Webnode bereitgestellt, mit denen neue Anforderungen umgesetzt werden können.
-==Kommunikation bei Verwendung der Personalisierung==
-''Das Modul ProfilePlus ermöglicht durch ein Apache-Modul die Authentifizierung eines Nutzers über die Website am IES-Server''
-Sollen Inhalte auf dem Webserver personalisiert werden bedeutet dies, dass ein Nutzer sich am dem Webserver anmelden muss/kann. Er bekommt 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. Hierbei handelt es sich um ein Apache-Modul, welches die Anmeldung des Nutzers und den Zugriffsschutz der Website steuert.
-Es gibt aktuell drei Möglichkeiten, wie das Modul ProfilePlus einen Nutzer authentifizieren kann:
-* HTTP-Request einer URL vom IES-Server
-* Abfrage eines LDAP-Servers
-* Abfrage einer lokalen MySQL-Datenbank
-Die drei Möglichkeiten können in einer Fallback-Konfiguration nacheinander abgefragt werden. Dies erlaubt die Funktion auch während Wartungsarbeiten am IES-Server zu verwenden. Aktuell wird für die Verwaltung der Sessions und die geschützten URLs eine lokale MySQL-Datenbank vorausgesetzt.
-Zukünftige Funktionsweise:
-Der IES-Webnode wird um einen Service für die Personalisierung erweitert. Das Apache-Modul ProfilePlus authentifiziert dann nur noch gegen des IES-Webnode auf ''localhost''. Eine Datenbank zur Verwaltung der Sessions wird u.U. nicht mehr benötigt.

Kommunikation zwischen IES und Webserver: Unterschied zwischen den Versionen

Aktuelle Version vom 21. November 2014, 14:30 Uhr

Navigationsmenü

Suche