Konzept
Im Folgenden wird davon ausgegangen, dass die FirstSpirit-Serverdienste auf unterschiedlichen Systemen ablaufen sollen und im Bereich des Application-Servers eine Cluster-Lösung zum Einsatz kommt.
Es ergibt sich dann die in der folgenden Abbildung dargestellte Architektur:
Abbildung: Hochverfügbarkeitscluster mit Lastverteilung
Der FirstSpirit-Client (sowohl der SiteArchitect als auch der ContentCreator) kommuniziert über HTTP(S) mit dem geclusterten Web-Application-Server. Über den HTTP(S)- Load-Balancer werden die FirstSpirit-Sitzungen auf die einzelnen Application-Server des Clusters verteilt. Eine Lastverteilung kann dabei auf URL-Basis und/oder auf HTTP-Session-Basis erfolgen.
Hinter dem Application-Server-Cluster wird eine Reihe von FirstSpirit-Diensten auf verschiedenen Systemen gestartet:
FirstSpirit Master-Server: Der FirstSpirit Master-Server verwaltet zentral alle FirstSpirit-Projekte und übernimmt die Abarbeitung der Anfragen/Änderungen der Benutzer und verteilt die Aufgaben, soweit möglich, auf andere FirstSpirit-Server.
FirstSpirit-Generation-Server: Bei komplexen bzw. häufigen Veröffentlichungsvorgängen sollten mehrere FirstSpirit-Generierungsserver zum Einsatz kommen, um die Belastung bei der Erzeugung der Web-Präsenzen vom Master zu verlagern. Bei Bedarf können so auch mehrere Veröffentlichungen auf verschiedene Server verteilt werden. Ein Generierungsserver enthält einen RORS.
ReadOnly-Repository-Server (RORS): Ein spezieller Repository-Manager bearbeitet die Anfragen von einem Generierungs-Server.
Die einzelnen FirstSpirit-Server entscheiden beim Start, für welchen Aufgabenbereich sie verantwortlich sind und welche Manager dazu gestartet werden müssen. Ein FirstSpirit-Generierungsserver entsteht beispielsweise aus einem "normalen" FirstSpirit-Server, der nur die zur Kommunikation benötigten Dienste und den Generation-Manager startet. Die FirstSpirit Softwarearchitektur ist so aufgebaut, dass (vereinfacht dargestellt) bei der Ausführung eines Auftrags ein Generation-Manager verwendet wird, dem man nicht „ansieht“, ob er lokal oder remote läuft.